Bug#1003298: vim-gtk3: Wrong colors and font in terminal in 2:8.2.3995-1

[Håvard Moen]

On Sunday, January 9th, 2022 at 8:05 AM, James McCoy  
wrote:
> There were a couple of issues in Vim that led to this change in
>
> behavior, due to wanting the terminal running Vim's normal colors to be
>
> used if Vim's highlight groups didn't specify any colors.
>
> -   https://github.com/vim/vim/issues/2361
>
> -   https://github.com/vim/vim/issues/9058
>
> However, the documentation also looks like this is intended behavior.
>
> From “:help terminal-size-color”:
>
> For a color terminal the 'background' option is used to decide whether the
>
> terminal window will start with a white or black background.
>
> To use a different color the Terminal highlight group can be used, for
>
> example: >
>
>   hi Terminal ctermbg=lightgrey ctermfg=blue guibg=lightgrey 
> guifg=blue
>
>
>
> Does adding “au ColorScheme * hi link Terminal Normal” to your vimrc
>
> behave more like you're expecting?
>
> If not, maybe the changes for terminal Vim and an adverse effect on GUI

Hi

"au ColorScheme * hi link Terminal Normal" in vimrc did not work, but just "hi 
link Terminal Normal" worked and everything is correct again.

Thanks so much for the help.

Regards
Håvard

Bug#934926: [Pkg-zsh-devel] Bug#934926: update (overridding of default fpath causes uncessary complexity and pain for software providing zsh completions)

[Axel Beckert]

Hi Daniel,

Daniel Shahaf wrote:
> That's not to say that things can't be improved going forward.

The big question to me seems "how?".

> […], or /etc/zsh/zshrc.d/ could be added (there's a separate ticket
> for that but my quick grep didn't find it),

You probably had https://bugs.debian.org/776663 in mind which has been
filed against zsh-common, not zsh (but src:zsh), so I suspect you
haven't it found because of that.

There's also an Ubuntu bug report on a similar topic at
https://bugs.launchpad.net/ubuntu/+source/zsh/+bug/1800280 which is
specifically about parsing /etc/profile, i.e. the same file bash
parses.

> Indeed, this ticket seems a bit open-ended.  What's being asked
> here?

Ack!

And JFTR: I actually don't have an opinion on this, either, as I'm too
far away from knowing the non-debian conventions.

I'd though would like to see a consensus inside the Debian Zsh team on
how (and where) to go forward. I'd especially would be happy to hear
about Frank's (Cc'ed) opinion as he and Daniel are those who are most
clued about upstream things and especially upstream conventions. (And
because I know that Frank has a quite clear opinion on #776663 — where
I actually do have an opinion, too, albeit a different one than Frank.)

Joey: I re-added the actual bug report title to the subject to make it
clear about what topic the discussion is.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 1/9/22 00:56, Andres Salomon wrote:


On 1/8/22 15:57, Mattia Rizzolo wrote:

On Thu, Jan 06, 2022 at 02:55:20AM -0500, Andres Salomon wrote:
If you want to try with chromium 97; it now builds as an official 
build, so

those DCHECKs shouldn't even be compiled in. It also supports wayland
automatically, in case that's related to your slowdowns.

https://salsa.debian.org/dilinger/chromium/-/tree/v97

I wanted to do this, but could it be that this version is for some
reason taking much more space than the previous one?  Here I have ~40 GB
free, and v96 built just fine (though I wasn't looking when it was
running), but now this failed already twice due to ENSPC.

I'll try looking for someplace more spacy but it's odd :)



Yeah, I think it's the debugging info; it's also breaking lld. It's a 
result of enabling official build, I'm working on it.



In debian/rules, along with is_official_build=true, you can set 
symbol_level=#. With is_official_build=false (which is the way it used 
to build), it used level 0. The default for is_official_build=true is 
level 2, which results in a lot more space (it used 50gb on my last 
build) and also means I run out of ram linking the final chrome binary 
on my 8gb build machine.


I'm not sure what we should use, as I'm not sure if 0 will break any of 
the dbgsym packaging yet. I'm currently trying a build with symbol_level=1.


Fedora doesn't set it, and instead manually patches BUILD.gn to -g0. 
Ungoogled-chromium sets it to 1. Arch sets it to 0 if strip is set. Mint 
sets it to 0.

Bug#1003298: vim-gtk3: Wrong colors and font in terminal in 2:8.2.3995-1

[James McCoy]

On Sun, Jan 09, 2022 at 03:47:40AM +, Håvard Moen wrote:
> On Sunday, January 9th, 2022 at 2:30 AM, James McCoy  
> wrote:
>  
> 
> > Some more details about how things differ would be useful. Maybe even
> > 
> 
> > screen shots.
> 
> Attaching screenshots showing the difference. I also see that popups as used 
> for instance by https://github.com/junegunn/fzf.vim also has the wrong colors.
> Another thing I now see and which is show in the screenshots, is that when 
> going to normal mode in the terminal, the part of the terminal without text 
> get the right color.

There were a couple of issues in Vim that led to this change in
behavior, due to wanting the terminal running Vim's normal colors to be
used if Vim's highlight groups didn't specify any colors.

* https://github.com/vim/vim/issues/2361
* https://github.com/vim/vim/issues/9058

However, the documentation also looks like this is intended behavior.
From “:help terminal-size-color”:

For a color terminal the 'background' option is used to decide whether 
the
terminal window will start with a white or black background.

To use a different color the Terminal highlight group can be used, for
example: >
hi Terminal ctermbg=lightgrey ctermfg=blue guibg=lightgrey 
guifg=blue

Does adding “au ColorScheme * hi link Terminal Normal” to your vimrc
behave more like you're expecting?

If not, maybe the changes for terminal Vim and an adverse effect on GUI
Vim.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB


signature.asc
Description: PGP signature

Bug#1003378: More data for Bug 1003378

[Kingsley G. Morse Jr.]

I tried again.

This time, I did

$ aptitude install kde-standard

and then tried adding the same .mp4 file to
Kdenlive's project bin.

Kdenlive didn't crash this time, but it

1.) openned an orange error window that says

"Cannot open file
/home/kingsley/doc/movies/public_domain/
Twelve+Days+of+Christmas+(Instrumental)+(feat.
+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"

and

2.) printed this on the console

=== REG FOCUS:  true
qml: item not found
=== REG FOCUS:  false
/// starting to add bin clips
/// found list 
(QUrl("file:///home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"))
/// creatclipsfromlist 
(QUrl("file:///home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"))
 true "-1"
/// createClipFromFile 
"/home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"
 "-1"
=== GOT DROPPED MIME:  "video/mp4"
/// final xml "\n /home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4\n\n"
== STARTING TASK FOR:  4
/// creatclipsfromlist return false
STARTING LOAD TASK FOR:  
"/home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"
 

:::
QFSFileEngine::open: No file name specified
// WARNING EMPTY CLIP HASH: 
== READY FOR TASK DELETION ON:  4
= REMOVING MASTER PRODUCER; CURRENT COUNT:  0 
:::

You can try to replicate it with the video at

https://invidious.snopyta.org/watch?v=F-b6WYUHBWY

Download the version...

"audio/mp4 @ 131.141k audio only"

I wonder if a bug is in 

creatclipsfromlist

or

createClipFromFile

Thanks,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#813771: reportbug: It can't unselect item in 'Do any of the following apply to this report' page.

[Takahide Nojima]

Dear Nis Martensen,

 I registered my account to salsa.

 And I implemented all your requests shown below,

> > - Is it possible to more clearly highlight the selected row(s)?
Some
> > of
> > the menus can be quite long with a lot of text, and the radiobutton
> > or
> > checkbox is relatively tiny. It would be nice if the selected
> > option(s)
> > stand out more.
> > 
> >  - Also to mark a row it is now necessary to click on the
radiobutton
> > or
> > checkbox. Is it possible to have a click anywhere on a row toggle
the
> > selection status of that option?
> > 
> >  - Is it possible, when using checkboxes, to have a way to enforce
> > that
> > not more than option is selected? The mailer selection menu is an
> > example menu where it should be possible to not have any option
> > selected, but where being able to select more than one option does
> > not
> > make sense either.

 I sent a merge request shown as below,
https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/71

 I'm grateful to review and merge this request.

Regards,

 Takahide Nojima

Bug#1003138: Some related links

[Yousen Zhang]

A related/similar post on Windows is
https://stackoverflow.com/questions/44153858/linking-against-boost-python-3-6-cant-find-boost-python-instead-of-boost-pytho

As I had set using python 3.9, but ld will always tried to link
libboost_python instead of libboost_python3.9

I also checked the header  /usr/include/boost/python/detail/config.hpp
It shows
#define BOOST_LIB_NAME BOOST_PYTHON_CONCAT(boost_python, PY_MAJOR_VERSION,
PY_MINOR_VERSION)

I suspect this package won't work properly out the PY_MAJOR_VERSION and
PY_MINOR_VERSION defined in /usr/include/python3.9/Python.h

Bug#1003380: ITP: golang-github-goccy-go-yaml -- yet another golang library for YAML support

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-goccy-go-yaml
  Version : 1.9.4
  Upstream Author : Masaaki Goshima
* URL : https://github.com/goccy/go-yaml
* License : Expat
  Programming Lang: Go
  Description : yet another golang library for YAML support

 YAML support for the Go language.
 This adds some features compared to the golang standard YAML library.
  * Pretty format for error notifications
  * Supports Scanner or Lexer or Parser as public API
  * Supports Anchor and Alias to Marshaler
  * Allow referencing elements declared in another file via anchors
  * Extract value or AST by YAMLPath ( YAMLPath is like a JSONPath )

Bug#1003379: last-align: reproducible-builds: cpu-specific features embedded in manpages

[Vagrant Cascadian]

Source: last-align
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: cpu
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Various manpages embed the relevent SIMD variant of the CPU used in the
build environment:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/i386/last-align.html

  /usr/share/man/man1/last-merge-batches.1.gz

  .B·last-merge-batches-avx
vs.
  .B·last-merge-batches-avx2

The attached patch to debian/rules and debian/bin/dispatch-simd creates
an environment variable, SIMD_LIST, which is set in debian/rules to
ensure none of the variants match, falling back to the "plain" variants.

Another option might be to postprocess the manpage...


With this patch applied, last-align should at least build reproducibly
on tests.reproducible-builds.org once it migrates to bookworm/testing,
as build paths are currently only varied in unstable and experimental
which trigger other reproducibility issues.


Thanks for maintaining last-align!


live well,
  vagrant
From 6fe1d0e3cfe3efd8f9bc5c1a3ffcd7ea84316352 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 9 Jan 2022 05:43:58 +
Subject: [PATCH] debian/rules, simd-dispatch: Pass an environment variable to
 use the plain variant to when building manpages with help2man.

The relevent simd variant of the build environment is embedded in the
manpage, breaking build reproducibility depending on the cpu features
of the running build environment.
---
 debian/bin/simd-dispatch | 3 ++-
 debian/rules | 4 
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/debian/bin/simd-dispatch b/debian/bin/simd-dispatch
index aa3bef8..5faf6b2 100755
--- a/debian/bin/simd-dispatch
+++ b/debian/bin/simd-dispatch
@@ -14,7 +14,8 @@ function test_and_run () {
 	fi
 }
 
-for SIMD in avx2 avx sse4.1 ssse3 sse3 sse2 sse mmx ; do test_and_run ${SIMD} "$@" ; done
+SIMD_LIST=${SIMD_LIST:-"avx2 avx sse4.1 ssse3 sse3 sse2 sse mmx"}
+for SIMD in $SIMD_LIST ; do test_and_run ${SIMD} "$@" ; done
 
 # fallback to plain option
 $BASE-plain "$@"
diff --git a/debian/rules b/debian/rules
index 2812ffd..73bfc74 100755
--- a/debian/rules
+++ b/debian/rules
@@ -22,6 +22,10 @@ export DEB_LDFLAGS_MAINT_APPEND += -pthread
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+# Ensure the COMMAND-plain variants is used to generate the manpages
+# for reproducible builds
+export SIMD_LIST = fallback-to-plain-simd
+
 BUILT_USING=$(shell dpkg-query -f '$${source:Package} (= $${source:Version}), ' -W "libsimde-dev")
 
 %:
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 1/8/22 15:57, Mattia Rizzolo wrote:

On Thu, Jan 06, 2022 at 02:55:20AM -0500, Andres Salomon wrote:

If you want to try with chromium 97; it now builds as an official build, so
those DCHECKs shouldn't even be compiled in. It also supports wayland
automatically, in case that's related to your slowdowns.

https://salsa.debian.org/dilinger/chromium/-/tree/v97

I wanted to do this, but could it be that this version is for some
reason taking much more space than the previous one?  Here I have ~40 GB
free, and v96 built just fine (though I wasn't looking when it was
running), but now this failed already twice due to ENSPC.

I'll try looking for someplace more spacy but it's odd :)



Yeah, I think it's the debugging info; it's also breaking lld. It's a 
result of enabling official build, I'm working on it.

Bug#1001979: ITS: libxml-tokeparser-perl

[Bas Couwenberg]

Source: libxml-tokeparser-perl
Followup-For: Bug #1001979
X-Debbugs-Cc: Nathan Scott 

Dear Maintainer,

libxml-tokeparser-perl (0.05-4) has been uploaded to unstable (DELAYED/7) to 
fix #999272 per the Package Salvaging process:

 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging

The debdiff with changes is attached.

Kind Regards,

Bas
diff -Nru libxml-tokeparser-perl-0.05/debian/changelog 
libxml-tokeparser-perl-0.05/debian/changelog
--- libxml-tokeparser-perl-0.05/debian/changelog2021-01-03 
13:57:25.0 +0100
+++ libxml-tokeparser-perl-0.05/debian/changelog2022-01-09 
06:35:51.0 +0100
@@ -1,3 +1,25 @@
+libxml-tokeparser-perl (0.05-4) unstable; urgency=medium
+
+  * Team upload.
+(closes: #1001979)
+  * Restructure control file with cme.
+  * Make Debian Perl Group the Maintainer, move Nathan to Uploaders.
+  * Add Vcs-* URLs.
+  * Add gbp.conf to use pristine-tar & --source-only-changes by default.
+  * Update watch file to use version 4 and metacpan.org.
+  * Update Homepage and Source URL to use metacpan.org.
+  * Update copyright file to use copyright-format 1.0.
+  * Use dh sequencer and compat level 12.
+(closes: #999272)
+  * Bump Standards-Version to 4.6.0, changes:
+- copyright-format 1.0
+- Vcs-* fields
+  * Improve package description.
+  * Use autopkgtest-pkg-perl Testsuite.
+  * Enable Salsa CI.
+
+ -- Bas Couwenberg   Sun, 09 Jan 2022 06:35:51 +0100
+
 libxml-tokeparser-perl (0.05-3.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru libxml-tokeparser-perl-0.05/debian/compat 
libxml-tokeparser-perl-0.05/debian/compat
--- libxml-tokeparser-perl-0.05/debian/compat   2010-10-03 02:00:43.0 
+0200
+++ libxml-tokeparser-perl-0.05/debian/compat   1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-7
diff -Nru libxml-tokeparser-perl-0.05/debian/control 
libxml-tokeparser-perl-0.05/debian/control
--- libxml-tokeparser-perl-0.05/debian/control  2010-10-03 02:23:34.0 
+0200
+++ libxml-tokeparser-perl-0.05/debian/control  2021-12-13 09:28:48.0 
+0100
@@ -1,27 +1,33 @@
 Source: libxml-tokeparser-perl
+Maintainer: Debian Perl Group 
+Uploaders: Nathan Scott 
 Section: perl
 Priority: optional
-Build-Depends: debhelper (>= 7)
-Build-Depends-Indep: perl (>= 5.6.0-12), libxml-parser-perl (>= 2)
-Maintainer: Nathan Scott 
-Standards-Version: 3.9.1
-Homepage: http://search.cpan.org/dist/XML-TokeParser/
+Build-Depends: debhelper-compat (= 12)
+Build-Depends-Indep: perl,
+ libxml-parser-perl
+Standards-Version: 4.6.0
+Vcs-Browser: 
https://salsa.debian.org/perl-team/modules/packages/libxml-tokeparser-perl
+Vcs-Git: 
https://salsa.debian.org/perl-team/modules/packages/libxml-tokeparser-perl.git
+Homepage: https://metacpan.org/release/XML-TokeParser
+Testsuite: autopkgtest-pkg-perl
 
 Package: libxml-tokeparser-perl
 Architecture: all
-Depends: ${perl:Depends}, ${misc:Depends}, libxml-parser-perl (>= 2)
-Description:  Simplified interface to XML::Parser
+Depends: libxml-parser-perl,
+ ${perl:Depends},
+ ${misc:Depends}
+Description: Simplified interface to XML::Parser
  XML::TokeParser provides a procedural ("pull mode") interface to XML::Parser
  in much the same way that Gisle Aas' HTML::TokeParser provides a procedural
  interface to HTML::Parser. XML::TokeParser splits its XML input up into
- "tokens," each corresponding to an XML::Parser event.
+ "tokens", each corresponding to an XML::Parser event.
  .
- A token is a bless'd|"XML::TokeParser::Token" reference to an array whose
- first element is an event-type string and whose last element is the literal
- text of the XML input that generated the event, with intermediate elements
- varying according to the event type.
+ A token is a bless'd reference to an array whose first element is an
+ event-type string and whose last element is the literal text of the XML
+ input that generated the event, with intermediate elements varying according
+ to the event type.
  .
- Each token is an object of type
- XML::TokeParser::Token|"XML::TokeParser::Token". Read
- "XML::TokeParser::Token"|"XML::TokeParser::Token" to learn what methods are
- available for inspecting the token, and retrieving data from it.
+ Each token is an object of type XML::TokeParser::Token. Read
+ XML::TokeParser::Token in the XML::TokeParser(3pm) manpage to learn what
+ methods are available for inspecting the token, and retrieving data from it.
diff -Nru libxml-tokeparser-perl-0.05/debian/copyright 
libxml-tokeparser-perl-0.05/debian/copyright
--- libxml-tokeparser-perl-0.05/debian/copyright2010-10-03 
02:33:19.0 +0200
+++ libxml-tokeparser-perl-0.05/debian/copyright2021-12-13 
09:07:24.0 +0100
@@ -1,44 +1,30 @@
-Format-Specification:
-http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=196
-Upstream-Maintainer: Copyright (c) 2003 D.H. aka PodMaster (curre

Bug#1000336: Upgrading tbb

[Andreas Tille]

Hi Mo,

thanks a lot.  I asked on IRC for priorisation of this
package.

Kind regards

  Andreas.

Am Sat, Jan 08, 2022 at 08:30:57PM -0500 schrieb M. Zhou:
> Hi all,
> 
> The good news is that I managed to upgrade onetbb. It 
> is in the NEW queue now:
> https://ftp-master.debian.org/new/onetbb_2021.4.0-1~exp1.html
> All changes have been pushed onto salsa (master branch).
> 
> SOVERSION was bumped from 2 to 12 so NEW is inevitable.
> There are also some non-trivial API changes. So I guess the
> transition won't be easy.
> 
> On Wed, 2021-12-29 at 23:27 -0800, Diane Trout wrote:
> On Thu, 2021-12-23 at 11:03 -0500, M. Zhou wrote:
> > Hi all,
> > 
> > I'm back.
> > 
> > I've just finished my final exams so I could do something during
> > the holiday. That TBB repository is still work-in-progress and
> > FTBFS from the master branch is something expected. I will finalize
> > it soon. Andreas said in previous posts that we prefer a faster
> > NEW queue process. I understand that but we cannot bypass NEW
> > process
> > this time as upstream has bumped the SONAME. So I'm changing the
> > source name as well following the upstream since NEW is inevitable.
> > 
> > As for llvmlite, the latest upstream RC release v0.38.0rc1 seems
> > to support python 3.10 . Should I upload the RC release?
> > 
> > BTW, what else should I do? I've been out of sync from the mailing
> > list for a long while.
> 
> 
> Have you managed to make much progress?
> 
> I fiddled with the packaging and got it to build and trying to run
> the
> autopkgtests with 2021.4.0-1
> 
> What'd help me is to have a package I could build locally and test
> numba against. If you got it working could you commit what you have
> to
> a salsa branch and let me know where it is?
> 
> Thanks,
> Diane
> 
> 
> 
> 

-- 
http://fam-tille.de

Bug#934926: update

[Daniel Shahaf]

Joey Hess wrote on Sat, Jan 08, 2022 at 16:27:53 -0400:
> The simple fact is that as an upstream author who used the debian
> locations because they were the ones that worked on my system, I get bug
> reports from users of other systems that it's not right for wider uses
> of zsh. And Debian seems to be leaving it up to me to deal with it,

The right thing to do *at this time* is fairly straightforward:

- Packages that are part of Debian should install to
  /usr/share/zsh/vendor-*.

- Upstream packages have three options:

  + Install to /usr/local/share/zsh/site-functions (regardless of their
own $PREFIX _and_ of zsh's $PREFIX)

  + Install to ${PREFIX of the zsh build}/share/zsh/site-functions

  + Install to some other place and use a post-install message to direct
the user to amend their $fpath manually.

That's not to say that things can't be improved going forward.  Of
course they can.  I'm just trying to document the best practice at this
time.

Going forward, perhaps the vendor-* convention could be upstreamed, or
upstream could make it easier to discover its prefix, or /etc/zsh/zshrc.d/
could be added (there's a separate ticket for that but my quick grep
didn't find it), or…

Indeed, this ticket seems a bit open-ended.  What's being asked here?
Just to add /usr/share/zsh/site-functions [sic] to Debian's zsh's
default $fpath?  Or something more general, e.g., "Ensure there are as
few obstacles as possible to developers of third-party autoloadable
functions"?

Cheers,

Daniel

Bug#1003378: QFSFileEngine::open: No file name specified...

[Kingsley G. Morse Jr.]

Package: kdenlive
Version: 21.12.1-1
Severity: important

Hi Padrick,

Thank you for maintaining Debian's kdenlive
package.

It can be a lot of fun!

I seem to have found a bug after upgrading to version 21.12.1-1.

I ran kdenlive on the command line

user$ kdenlive &

then followed the menu path

"Add Clip or Folder"





Then I see this in the console

=== REG FOCUS:  false
/// found list 
(QUrl("file:///home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"))
/// creatclipsfromlist 
(QUrl("file:///home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"))
 true "-1"
/// createClipFromFile 
"/home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"
 "-1"
=== GOT DROPPED MIME:  "video/mp4"
/// final xml "\n /home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4\n\n"
== STARTING TASK FOR:  2
/// creatclipsfromlist return false
STARTING LOAD TASK FOR:  
"/home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"
 

:::
QFSFileEngine::open: No file name specified
// WARNING EMPTY CLIP HASH: 
== READY FOR TASK DELETION ON:  2
= REMOVING MASTER PRODUCER; CURRENT COUNT:  0 
:::
terminate called after throwing an instance of 'std::out_of_range'
  what():  _Map_base::at

After I wait maybe about a minute, kdenlive
crashed.

I expected it to add the video file to kdenlive's
project bin and keep working.

Feel free to suggest what I might try next.

Thanks again,
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages kdenlive depends on:
ii  breeze 4:5.23.4-1
ii  breeze-icon-theme  4:5.88.0-2
ii  ffmpeg 7:4.4.1-1
ii  gstreamer1.0-plugins-bad   1.18.4-2
ii  kded5  5.77.0-2
ii  kdenlive-data  21.12.1-1
ii  kinit  5.77.0-2
ii  kio5.88.0-1
ii  libc6  2.33-2
ii  libgcc-s1  11.2.0-13
ii  libkf5archive5 5.88.0-1
ii  libkf5bookmarks5   5.88.0-1
ii  libkf5completion5  5.88.0-1
ii  libkf5configcore5  5.88.0-1
ii  libkf5configgui5   5.88.0-1
ii  libkf5configwidgets5   5.88.0-1
ii  libkf5coreaddons5  5.88.0-1
ii  libkf5crash5   5.88.0-1
ii  libkf5dbusaddons5  5.88.0-1
ii  libkf5declarative5 5.88.0-1
ii  libkf5filemetadata35.77.0-2
ii  libkf5guiaddons5   5.88.0-1
ii  libkf5i18n55.88.0-2
ii  libkf5iconthemes5  5.88.0-1
ii  libkf5itemviews5   5.88.0-1
ii  libkf5jobwidgets5  5.88.0-1
ii  libkf5kiocore5 5.88.0-1
ii  libkf5kiofilewidgets5  5.88.0-1
ii  libkf5kiogui5  5.88.0-1
ii  libkf5kiowidgets5  5.88.0-1
ii  libkf5newstuff55.88.0-1
ii  libkf5newstuffcore55.88.0-1
ii  libkf5notifications5   5.88.0-2
ii  libkf5notifyconfig55.77.0-2
ii  libkf5purpose-bin  5.77.0-2
ii  libkf5purpose5 5.77.0-2
ii  libkf5service-bin  5.88.0-1
ii  libkf5service5 5.88.0-1
ii  libkf5solid5   5.88.0-1
ii  libkf5textwidgets5 5.88.0-1
ii  libkf5widgetsaddons5   5.88.0-2
ii  libkf5xmlgui5  5.88.0-1
ii  libmlt++7  7.4.0-1
ii  libmlt77.4.0-1
ii  libqt5core5a   5.15.2+dfsg-14
ii  libqt5dbus55.15.2+dfsg-14
ii  libqt5gui5 5.15.2+dfsg-14
ii  libqt5multimedia5  5.15.2-3
ii  libqt5network5 5.15.2+dfsg-14
ii  libqt5networkauth5 5.15.2-2
ii  libqt5qml5 5.15.2+dfsg-9
ii  libqt5quick5-gles  5.15.2+dfsg-3
ii  libqt5quickcontrols2-5 5.15.2+dfsg-2
ii  libqt5quickwidgets55.15.2+dfsg-2
ii  libqt5svg5 5.15.2-3
ii  libqt5widgets5 5.15.2+dfsg-14
ii  libqt5xml5 5.15.2+dfsg-14
ii  libstdc++6 11.2.0-13
ii  melt   6.24.0-1
ii  qml-m

Bug#1003160:

[Batwam]

as an update to the report above, I since noticed that this issue also
occurs if I try to boot from the 5.10.0-10 kernel instead of the
original 5.10.0-09

Bug#1003377: getmail6: Ignores netrc_file configuration settings

[Olaf Meeuwissen]

Package: getmail6
Version: 6.18.4-2
Severity: normal
X-Debbugs-Cc: Olaf Meeuwissen 

Dear Maintainer,

I tried moving my credentials to $HOME/.authinfo by setting

  use_netrc = true
  netrc_file = $HOME/.authinfo

and removing the username and password from a working configuration
file.

That resulted in

  $ getmail --dump --rcfile=ucv

  Exception: please read docs/BUGS and include the following information in any 
bug report:

getmail version 6.18.4
Python version 3.9.9 (main, Dec 16 2021, 23:13:29)
  [GCC 11.2.0]

  Unhandled exception follows:
  File "/usr/bin/getmail", line 799, in main
  netrc_object = netrc.netrc(
  File "/usr/lib/python3.9/netrc.py", line 29, in __init__
  with open(file) as fp:
FileNotFoundError: [Errno 2] No such file or directory: '/home/olaf/.netrc'

  Please also include configuration information from running getmail
  with your normal options plus "--dump".

Checking upstream, I noticed that this has been fixed there already and
the fix has been released as part of v6.18.6 (just a few hours ago ;-).

Please upgrade to the latest version, thanks.

-- System Information:
Architecture: x86_64

Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages getmail6 depends on:
ii  python3  3.9.7-1

getmail6 recommends no packages.

getmail6 suggests no packages.

-- no debconf information

--
Olaf MeeuwissenFSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

Bug#1003376: ITP: python-circuitbreaker -- Python "Circuit Breaker" implementation

[Paul Wise]

Package: wnpp
Severity: wishlist
Owner: Paul Wise 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org
Control: block 1003372 by -1

* Package name: python-circuitbreaker
  Version : 1.3.2
  Upstream Author : Fabian Fuelling
* URL : https://github.com/fabfuel/circuitbreaker
* License : BSD
  Programming Lang: Python
  Description : Python "Circuit Breaker" implementation

This is needed by oci-python-sdk (#1003372).

The package will be maintained within the Python team.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#1003375: clfft: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: clfft
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/clfft.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

Alternately, updating the packaging to debhelper compat level 14 should
fix this, although it is currently an experimental compat level.


With this patch applied, clfft should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining clfft!


live well,
  vagrant
From 9eff952ac22144e4bf09e537cb2bc4e364de126a Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 9 Jan 2022 03:21:02 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index 08d4d3c..b16d997 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,6 +17,7 @@ BUILD_OPTIONS = \
 	-DBUILD_RUNTIME=ON \
 	-DBUILD_SHARED_LIBS=ON \
 	-DBUILD_TEST=OFF \
+	-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON \
 	-DSUFFIX_LIB="/$(DEB_TARGET_MULTIARCH)"
 
 %:
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1003374: ITP: golang-github-aquasecurity-go-version -- A Go library for parsing and verifying versions and version constraints.

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-aquasecurity-go-version
  Version : 0.0~git20210121.637058c
  Upstream Author : Aqua Security
* URL : https://github.com/aquasecurity/go-version
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library for parsing and verifying versions and version 
constraints
 go-version is a library for parsing versions and version constraints, and
 verifying versions against a set of constraints. go-version can sort a
 collection of versions properly, handles prerelease versions, etc.
 .
 go-version provides two packages:
 .
  * semver (/pkg/semver)
* Semantic Versioning (https://semver.org/)
* MAJOR.MINOR.PATCH-PRERELEASE+BUILDMETADATA (e.g. 1.1.3-alpha+110)
  * version (/pkg/version)
* Semantic Versioning like versioning
* Accept more than 3 numbers (e.g. 2.3.1.4)

Bug#1001591: [Pkg-matrix-maintainers] Bug#1002380: drops attributes used by reverse dependencies

[Sandro Tosi]

> I am eager to revert mistune (and therefore django-hyperkitty) back to
> previous versions, and to open bugs against reverse deps, with new
> uploads in experimental for both mistune and django-hyperkitty.

this would be great indeed, thanks!

> I consider a delay between bug opening and making them RC on the
> reverse-deps of a month, which, added to the removal delay, means around
> mid-march I'll probably reupload mistune 2.0.0 and django-hyperkitty in
> unstable.

from what i have seen, many of the downstream projects developers were
rather surprised by the sudden release of a mistune 2.0 version, and
they were uncertain how to move forward in a proper way, given the
vast number of differences and incompatible changes.

There also seems to be a complete lack of guidance from mistune
upstream on how to port projects from 0.8.x to 2.x: do you think any
effort will be spent by mistune upstream to provide any such
documentation? without it, i'm afraid 1 month is not enough
(anecdotally, the 2.x upload in unstable was a little more than a
month ago, and i dont think any upstream project mas ported to it, so
that should provide some guidance on how long to wait to make it RC)

> Last but not least, do you have appropriate tooling to file bugs against
> mistune reverse deps a bit more efficiently than "mail by mail"?

`mass-bug` from devscripts

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1003373: go-for-it: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: go-for-it
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/go-for-it.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

Alternately, updating the packaging to debhelper compat level 14 should
fix this, although it is currently an experimental compat level.


With this patch applied, go-for-it should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining go-for-it!


live well,
  vagrant
From 28760e375706a2058dc93757ee93ed3376bd96bc Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 9 Jan 2022 02:29:03 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index 679502c..5f65a55 100755
--- a/debian/rules
+++ b/debian/rules
@@ -18,4 +18,5 @@ export DEB_LDFLAGS_MAINT_APPEND =
 
 override_dh_auto_configure:
 	dh_auto_configure -- \
+	-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON \
 	-DUSE_GRANITE=1
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1003372: ITP: oci-python-sdk -- Oracle Cloud Infrastructure Python SDK

[Paul Wise]

Package: wnpp
Severity: wishlist
Owner: Paul Wise 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-cl...@lists.debian.org

* Package name: oci-python-sdk
  Version : 2.53.1
  Upstream Author : Vyas Bhagwat and others
* URL : https://github.com/oracle/oci-python-sdk/
* License : UPL or Apache
  Programming Lang: Python
  Description : Oracle Cloud Infrastructure Python SDK

This package is needed by my employer for managing their OCI instances.

I plan to maintain it within the Debian Cloud Team after joining it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#1003371: libavif: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: libavif
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libavif.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

Alternately, updating the packaging to debhelper compat level 14 should
fix this, although it is currently an experimental compat level.


With this patch applied, libavif should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining libavif!


live well,
  vagrant
From 710784e88a6ac4e469b236bf820779856cfd97be Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 9 Jan 2022 02:10:45 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index 71386fc..29bf3cc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -32,5 +32,6 @@ override_dh_auto_configure:
 	-DAVIF_BUILD_APPS=ON \
 	-DAVIF_CODEC_DAV1D=ON \
 	-DAVIF_CODEC_AOM=ON \
+	-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON \
 	$(LIBGAV1_FLAG) \
 	-DAVIF_BUILD_GDK_PIXBUF=ON
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1003370: libxtrxll: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: libxtrxll
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libxtrxll.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

Alternately, updating the packaging to debhelper compat level 14 should
fix this, although it is currently an experimental compat level.


With this patch applied, libxtrxll should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining libxtrxll!


live well,
  vagrant
From e75abe79f71c2e54c6ee1ed8043218db1a3ff1e3 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 9 Jan 2022 01:48:11 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index c748d13..452bd34 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,6 +8,7 @@ include /usr/share/dpkg/architecture.mk
 override_dh_auto_configure:
 	dh_auto_configure -- \
 		-DLIB_SUFFIX="/$(DEB_HOST_MULTIARCH)" \
+		-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON \
 		-DXTRXLL_STATIC=OFF
 
 override_dh_installudev:
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1003313: [pkg-gnupg-maint] Bug#1003313: libgpg-error FTCBFS for musl: refuses to use generic lock object detection

[Daniel Kahn Gillmor]

Control: forwarded 1003313 https://dev.gnupg.org/T5762

On Sat 2022-01-08 01:15:16 +0100, Helmut Grohne wrote:
> A while ago, libgpg-error gained a feature that enabled configure to
> introspect lock objects without running code (via objdump).
> Unfortunately, this code is only used for glibc. When cross building for
> e.g. musl, it falls back to the old way where you'd have to collect the
> results. And since those aren't collected, it fails. The objdump trick
> should work on all Linux systems regardless of the C library in used.

Thanks for this suggestion.  It looks like upstream used to permit this
for all C libraries, and i don't understand why they changed it either.

I've forwarded the suggestion upstream (see the URL above).  If upstream
is ok with it, i'm happy to apply it in debian.

 --dkg


signature.asc
Description: PGP signature

Bug#1003298: vim-gtk3: Wrong colors and font in terminal in 2:8.2.3995-1

[James McCoy]

Control: found -1 2:8.2.3995-1
Control: notfound -1 2:8.2.2434-3+deb11u1

On Fri, Jan 07, 2022 at 07:30:35PM +0100, Håvard Moen wrote:
> I upgraded vim-gtk3 to version 2:8.2.3995-1 that is in unstable, but
> noticed that the colors and font in the terminal (:terminal) is not
> set from my configuration. In the version in testing
> (2:8.2.2434-3+deb11u1) it works as it should.

Note, that is stable, not testing.  Adjusting found/notfound values
according to your description.

Some more details about how things differ would be useful.  Maybe even
screen shots.

There /was/ a bug fix in Vim in regard to the handling of
g:terminal_ansi_colors, but that was to fix an issue where it was
showing incorrect colors before and now shows the correct colors.  So,
are you sure the colors you're seeing now are /wrong/ or just different
than you're used to?

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1000336: Upgrading tbb

[M. Zhou]

Hi all,

The good news is that I managed to upgrade onetbb. It 
is in the NEW queue now:
https://ftp-master.debian.org/new/onetbb_2021.4.0-1~exp1.html
All changes have been pushed onto salsa (master branch).

SOVERSION was bumped from 2 to 12 so NEW is inevitable.
There are also some non-trivial API changes. So I guess the
transition won't be easy.

On Wed, 2021-12-29 at 23:27 -0800, Diane Trout wrote:
On Thu, 2021-12-23 at 11:03 -0500, M. Zhou wrote:
> Hi all,
> 
> I'm back.
> 
> I've just finished my final exams so I could do something during
> the holiday. That TBB repository is still work-in-progress and
> FTBFS from the master branch is something expected. I will finalize
> it soon. Andreas said in previous posts that we prefer a faster
> NEW queue process. I understand that but we cannot bypass NEW
> process
> this time as upstream has bumped the SONAME. So I'm changing the
> source name as well following the upstream since NEW is inevitable.
> 
> As for llvmlite, the latest upstream RC release v0.38.0rc1 seems
> to support python 3.10 . Should I upload the RC release?
> 
> BTW, what else should I do? I've been out of sync from the mailing
> list for a long while.


Have you managed to make much progress?

I fiddled with the packaging and got it to build and trying to run
the
autopkgtests with 2021.4.0-1

What'd help me is to have a package I could build locally and test
numba against. If you got it working could you commit what you have
to
a salsa branch and let me know where it is?

Thanks,
Diane

Bug#993857: [pkg-gnupg-maint] Bug#993857: Bug#993857: gnupg2: Please remove librsvg2-bin from BD

[Daniel Kahn Gillmor]

On Sat 2022-01-08 21:39:25 +0100, Laurent Bigonville wrote:
> My understanding of the policy has always been that the source tarball 
> shipped in debian must indeed contain all the files in their "preferred 
> form of modification" but the fact that the resulting artifact has to be 
> rebuilt during the build of the package was merely a recommendation.

This is almost certainly not the case for executable code -- if someone
upstream shipped an x86_64 binary, as a debian user i would be pretty
upset if the upstream binary was just passed through directly.

But whether executable code or not, the requirement isn't just that the
source code is available, but that the toolchain is also all free
software, right?  (there may be some exceptions for bootstrapping
tooling, but afaict we're working on trying to fix even that with
diverse dual compiling, rebootstrap, and reproducible builds projects).

The only way that i can see to be confident that the toolchain is
present is to actually do the build, right?  and if we do the build and
it's different than the generated object shipped by upstream, which one
should we prefer?

> My main concern here was to be certain that gnupg can build all 
> architectures even the one without rust support and your proposal allows 
> this, so it's good for me and if you think it's better to rebuild the 
> image during the build I've no objections.

makes sense (and i share your goal)!

> The fact that there is a rendering problem with the .png shipped in the 
> upstream tarball should be reported in any case I think.

Agreed, though i'd just as soon ask upstream to stop shipping the png in
their tarball :)

  --dkg


signature.asc
Description: PGP signature

Bug#998426: man reports a "malformed .lf request"

[Colin Watson]

Control: tag -1 fixed-upstream

On Thu, Nov 04, 2021 at 12:45:59AM +, Bjarni Ingi Gislason wrote:
>* What led up to the situation?
> 
> man -l groff/contrib/gpinyin/gpinyin.1.man (or groff/build/contrib/...)
> 
>* What was the outcome of this action?
> 
> /usr/bin/man: -:250: warning: malformed .lf request, ignoring
[...]
>   The line is:
> 
> .lf (\n[gpinyin*.c] + 25) \" XXX part 2: Restore input line counter.
> 
>   This is a valid line for troff.

It is, but it isn't one that man-db can reasonably parse, so as a result
post-zsoelim line numbers are going to be wrong.  As a compromise, I've
demoted this to a debug message, so that people will probably see it if
they're digging around to try to work out what's going on, but otherwise
it won't bother people.

  
https://gitlab.com/cjwatson/man-db/-/commit/025690e4f26d26e9e546f097f17be6a27591bed7

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1001577: m17n-lib: internal vs external symbols

[Harshula]

Hi Boyuan,

On 14/12/21 21:47, Boyuan Yang wrote:


I wasn't aware of the issue around internal & external symbols. Sorry for the
issue! Since the change was made back in 2018, I could not recall my exact
thought when I made those changes. Please feel free to correct the symbol
file.


Done. The next problem is Commit 
8c35a402074808db7355a00f4581afb4611c9abe (Modernize packaging). The 
commit dropped dh_makeshlibs directives that should have been kept.


Regards,
Harshula

Bug#971009: man-db: bad documentation for $MANROFFSEQ

[Colin Watson]

On Sat, Sep 26, 2020 at 09:33:20AM +0200, Jakub Wilk wrote:
> The man(1) man page reads: "Firstly, the command line option -p or the
> environment variable $MANROFFSEQ is interrogated. If -p was not used and the
> environment variable was not set, the initial line of the nroff file is
> parsed for a preprocessor string."
> 
> This seems to imply that $MANROFFSEQ takes precedence over '\" declarations;
> but AFAICT it's the other way round.

MANROFFSEQ predates me, and is something I've never personally found it
convenient to use.  However, on the assumption that it's useful to
somebody, its current precedence seems very weird.  My normal preference
would be to have the following priority, from highest to lowest:

 * command-line option
 * environment variable
 * filesystem state

This is because command-line options are explicit rather than ambient,
and environment variables are usually more easily changed than
filesystem state.

What would you think about changing the implementation rather than the
documentation?

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1003368: dino-im: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: dino-im
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dino-im.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

Alternately, updating the packaging to debhelper compat level 14 should
fix this, although it is currently an experimental compat level.


With this patch applied, dino-im should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining dino-im!


live well,
  vagrant
From 8c3c63418abe865fd8ebfed453004856093b8bae Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 9 Jan 2022 00:26:47 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index fe5b4e2..a431d6e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,6 +6,6 @@ DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 	dh $@ --buildsystem=cmake+ninja
 
 override_dh_auto_configure:
-	SHARED_SIGNAL_PROTOCOL=1 dh_auto_configure -- -DBIN_INSTALL_DIR=/usr/bin -DLIB_INSTALL_DIR=/usr/lib/$(DEB_HOST_MULTIARCH)/dino-im
+	SHARED_SIGNAL_PROTOCOL=1 dh_auto_configure -- -DBIN_INSTALL_DIR=/usr/bin -DLIB_INSTALL_DIR=/usr/lib/$(DEB_HOST_MULTIARCH)/dino-im -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
 
 override_dh_auto_test:
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#970482: "lexgrog" uses UTF-8 encoding in its output, not "locale"

[Colin Watson]

Control: tag -1 fixed-upstream

On Thu, Sep 17, 2020 at 02:58:30AM +, Bjarni Ingi Gislason wrote:
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> lexgrog -d /usr/share/man/man7/groff_me.7.gz
[...]
>* What outcome did you expect instead?
> 
>   The text in the locale charset.
> (without the -d option:
> 
> /usr/share/man/man7/groff_me.7.gz: "groff_me - "me" macro package for
> formatting documents with GNU roff"

Thanks, fixed for the next upstream release:

  
https://gitlab.com/cjwatson/man-db/-/commit/84b6689805b971b1a229f060a92658571c1daa07

(This runs the whatis description through iconv rather than specifically
converting the quotes, so, depending on the details of what iconv
decides to do, the quotes may disappear rather than being rendered as
ASCII quotes.  This is in line with the behaviour of apropos(1) and
whatis(1) since man-db 2.5.0 in 2007, and I don't think it's worth
having a special case for handling quotes; it will handle letters with
diacritics as long as the appropriate glyphs exist in the target
character set, and it will at least avoid mojibake in the output.)

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#996328: further information

[David Christensen]

debian bug 996328:

I have been testing video playback and browser graphics/ javascript (?) 
issues on Debian 9, 10, and 11 with Xfce on two computers:


1.  Dell Latitude E6520 with Intel i7-2720QM processor (Intel HD 
Graphics 3000) and NVIDIA NVS 4200M (NVIDIA Optimus).


2.  Tower desktop with Intel DQ67SW motherboard and Intel i7-2600S 
processor (Intel HD Graphics 2000).



Amazon Prime video, YouTube video, and eBay image browsing seems to work 
okay on the Intel DQ67SW for Debian 9, 10, and 11.



Amazon Prime video, YouTube video, and eBay image browsing seems to work 
okay on the Dell Latitude E6520 for Debian 9.



Amazon Prime video, YouTube video, and eBay image browsing locks up/ 
crashes/ freaks out within minutes on Debian 10.



Amazon Prime video, YouTube video, and eBay image browsing locks up/ 
crashes/ freaks out within tens of minutes on Debian 11.



David

Bug#1003259: firejail should blacklist rxvt when Perl is blacklisted

[Vincent Lefevre]

Control: tags -1 fixed-upstream

On 2022-01-07 03:57:46 +0100, Vincent Lefevre wrote:
> I've submitted a pull request upstream. The corresponding patch:
> https://github.com/netblue30/firejail/pull/4831/commits/ed5c259fcc106b8b07f056f65e828c680fec9562

This has been merged.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1003367: upgrade-reports: samba seriously broken after upgrade - major config changes

[Karl Schmidt]

Package: upgrade-reports
Severity: important

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

My previous release is: buster
I am upgrading to: bullseye
Upgrade date: Jan 06 2021
uname -a after upgrade: Linux malaysia 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 
(2021-12-08) x86_64 GNU/Linux

Method: comand line - $ wajig distupgrade

Contents of /etc/apt/sources.list:
eb http://mirrors.edge.kernel.org/debian bullseye main contrib non-free
deb http://deb.debian.org/debian-security/ bullseye-security main contrib 
non-free
deb http://deb.debian.org/debian bullseye-updates main contrib non-free

#security
deb http://security.debian.org/ buster/updates main contrib non-free
deb http://security.debian.org/debian-security buster/updates main contrib 
non-free

#deb http://ftp.us.debian.org/debian/ wheezy main
#Seamonkey
#deb http://downloads.sourceforge.net/project/ubuntuzilla/mozilla/apt all main

#backports
#deb http://ftp.debian.org/debian/ buster-backports main non-free contrib
deb http://files.freeswitch.org/repo/deb/debian-release bullseye  main


- Were there any non-Debian packages installed before the upgrade?  If
  so, what were they?
  
  Just freeswitch - not an issue

- Did any packages fail to upgrade?

Only rkhunter.. had a problem 

- Were there any problems with the system after upgrading?

Yes

Further Comments/Problems:

- samba broke - looks like support for a simple workgroup share is now gone - 
wish there had been some warning. 

Bug#951354: wget2: Please package new version (1.99.2)

[Boyuan Yang]

X-Debbugs-CC: n...@debian.org

Dear maintainer,

It has been a while; is there any update on packaging new wget2? If you are in
lack of time doing packaging, please let us know so that those interested can
have a chance to step in.

Thanks,
Boyuan Yang

On Fri, 15 Oct 2021 16:34:47 -0400 Boyuan Yang  wrote:
> Control: retitle -1 wget2: Please package new 2.0.0 version
> 
> On Fri, 14 Feb 2020 22:22:36 -0500 Boyuan Yang  wrote:
> > Source: wget2
> > Version: 1.99.1-2.1
> > Severity: normal
> > 
> > Dear wget2 maintainer,
> > 
> > A new release of wget2 (wget2 1.99.1) is now available. Please consider
> > packaging it in Debian. Thanks!
> 
> Dear Debian wget2 packge maintainer,
> 
> The upstream has released the 2.0.0 new version. Please consider packaging
it
> in Debian. Thanks!
> 
> Regards,
> Boyuan Yang



signature.asc
Description: This is a digitally signed message part

Bug#1002065: scipy build-depenencies unsatisfiable in testing/unstable

[Drew Parsons]

On 2022-01-08 19:44, Laurent Bigonville wrote:

On Tue, 21 Dec 2021 11:09:02 + Peter Michael Green
 wrote:

scipy build-depends on python3-pybind11 (<< 2.8) but testing and 
unstable

have version 2.8.1-3


FTR, the package builds fine with python3-pybind11 2.9

Could you drop that restriction or is it really broken with higher 
versions?


They're conservative with their official releases. From 
scipy/pyproject.toml: "This to prevent that a future 
backwards-incompatible release will break the source build of a SciPy 
release.".


It's more relevant for local user pip builds in a virtualenv, keeping 
the virtualenv constrained to known-good package versions.


It's not so crucial for Debian since we maintain our own package 
self-consistency.  In fact the upper bound is only applied upstream to 
the release versions. The development version has no upper bound (still 
set at "pybind11>=2.4.3")


So it should be safe to remove the upper bound for us.  It's a pity 
apt-rdepends doesn't support reverse build-dependencies yet, it would 
make it simpler to keep track of these things when testing new releases.


Drew

Bug#1003366: reportbug: open-iscsi-udeb : iscsid unable to start. Missing libsystemd.so.0 in installer environment

[Eugene]

Package: open-iscsi
Version: 2.1.3-5
Severity: important
Tags: d-i




-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages open-iscsi depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u2
ii  libisns0   0.100-3
ii  libkmod2   28-1
ii  libmount1  2.36.1-8
ii  libopeniscsiusr2.1.3-5
ii  libssl1.1  1.1.1k-1+deb11u1
ii  libsystemd0247.3-6
ii  udev   247.3-6

open-iscsi recommends no packages.

open-iscsi suggests no packages.

-- debconf information excluded

*** /tmp/open-iscsi-bugreport
open-iscsi-udeb : iscsid unable to start. Missing libsystemd.so.0 in installer 
environment

PACKAGE:
open-iscsi-udeb (only a bug in the installer environment)

FIX REQUIRED:
* Add libsystemd0 to following packages in:
https://salsa.debian.org/linux-blocks-team/open-iscsi
debian/control
open-iscsi "Depends"
open-iscsi-udeb "Depends"

LOGIC/REASONING:
1) libsystemd is a "Build-Depends" for this package (but is omitted in the 
run-time dependency list "Depends" 

---

2) When running the debian-installer (partman-iscsi), this calls open-iscsi 
package to setup ISCSI drives at install time

2.1) The iscsi setup fails because "/sbin/iscsid" cannot run due to being 
unable to find "libsystemd0.so"

2.2) Further checks on the installer environment show that "libsystemd.so.0" is 
not present in /lib directory

---

3) "libsystemd.so.0" is present once installed (so this is purely installer 
related)

---

*) It also complains about missing "/etc/iscsi/initiatorname.iscsi" - but I am 
hoping that is setup automatically once the daemon starts




STEPS TO REPRODUCE:
1) Run installer on an environment with a iSCSI Target setup (I used tgt on 
QEMU)
2) On "Detect Disks" and "Partition Disks" go to "Configure iSCSI volumes"
3) Enter the host details for the iscsi target
-- FAILS --
4) Review the logs (Console and /var/logs/syslog)
-4.1 Shows that cannot start "iscsid"

Expected behavior is
1) iscsi daemon starts - and so can find the drives
2) Failing the above should be able to use the console from installer mode, to 
discover the iSCSI drives on the target

Bug#900253: nslcd: disabling ppolicy breaks authentication

[Arthur de Jong]

On Sat, 2022-01-08 at 20:19 +0100, Nicolas Peugnet wrote:
> I just ran into this bug. If I understand correctly it should have
> been fixed by this commit:
> 
> which is in Debian since version 0.9.12-1.
> 
> Just to be sure Arthur, would setting this option to "no" indeed make
> the OpenLDAP server stop logging entries like the following?
> 
> slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1

Yes, the pam_authc_ppolicy option is used to disable requesting that
control, see
https://arthurdejong.org/nss-pam-ldapd/nslcd.conf.5#pam_authc_ppolicy

While the option was added in 0.9.7 it was non-functional until it was
fixed in 0.9.12.

> And would it be a good idea to back-port this patch to stable ?

The missing control logged by the LDAP server should not be harmful in
any way because it is marked as not critical which means it is just a
warning that can be ignored.

I doubt this would be severe enough an issue to warrant an update for
bullseye.

-- 
-- arthur - art...@arthurdejong.org - https://arthurdejong.org/ --



signature.asc
Description: This is a digitally signed message part

Bug#1003365: projectm-pulseaudio: Doesn't work on Thinkpad T410 with Iron Lake GPU

[Michael Jarosch]

Package: projectm-pulseaudio
Version: 3.1.12-1
Severity: normal

Dear Maintainer,

as I tried to startup a projectM-session with my oldy laptop, I got that 
output

from command-line:


projectM-pulseaudio
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use
QT_QPA_PLATFORM=wayland to run on Wayland anyway.
Default config: /usr/share/projectM/config.inp
reading /home/mitsch/.projectM/config.inp
[projectM] config file: /home/mitsch/.projectM/config.inp
Failed to compile shader 'Vertex: v2f_c4f'. Error: 0:1(10): error: GLSL 
ES 3.00

is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES

Failed to compile shader 'Vertex: v2f_c4f_t2f'. Error: 0:1(10): error: 
GLSL ES

3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES

Failed to compile shader 'Vertex: blur1'. Error: 0:1(10): error: GLSL ES 
3.00

is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES

Failed to compile shader 'Vertex: blur2'. Error: 0:1(10): error: GLSL ES 
3.00

is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES
#

…and the graphics of projectM lacks colors and I got two big, white boxes
instead of music visualisation - exactly as user prg318 in this thread:

https://github.com/projectM-visualizer/projectm/issues/101

He was told to build projectM with "--enable-gles" flag and as he did so, he
got projectM working. So, I guess, this could be the clue and that's why 
I ask

you kindly, if you could build it with the same flag…?

BTW: projectM-jack has exactly the same problem.


greets!
Mitsch


-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 projectm-pulseaudio depends on:
ii libc6 2.33-1
ii libgcc-s1 11.2.0-13
ii libgl1 1.3.4-2+b1
ii libpulse0 15.0+dfsg1-3
ii libqt5core5a 5.15.2+dfsg-14
ii libqt5gui5 5.15.2+dfsg-14
ii libqt5opengl5 5.15.2+dfsg-14
ii libqt5widgets5 5.15.2+dfsg-14
ii libstdc++6 11.2.0-13
ii pulseaudio 15.0+dfsg1-3

projectm-pulseaudio recommends no packages.

projectm-pulseaudio suggests no packages.

-- no debconf information

Bug#1003364: RM: python-asynctest -- RoQA; Orphaned; Unused; Upstream Inactive; RC-Buggy

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Dear FTP Masters,

As discussed in https://bugs.debian.org/954554 , this package is orphaned, RC-
buggy (FTBFS) and no longer needed. Please consider removing python-asynctest
from Debian archive.

I just checked and this package has no reverse dependencies and reverse build-
dependencies.

-- 
Regards,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

On Thu, Jan 06, 2022 at 02:55:20AM -0500, Andres Salomon wrote:
> If you want to try with chromium 97; it now builds as an official build, so
> those DCHECKs shouldn't even be compiled in. It also supports wayland
> automatically, in case that's related to your slowdowns.
> 
> https://salsa.debian.org/dilinger/chromium/-/tree/v97

I wanted to do this, but could it be that this version is for some
reason taking much more space than the previous one?  Here I have ~40 GB
free, and v96 built just fine (though I wasn't looking when it was
running), but now this failed already twice due to ENSPC.

I'll try looking for someplace more spacy but it's odd :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#954554: python-asynctest: FTBFS, maybe-RM

[Boyuan Yang]

X-Debbugs-CC: jo...@jones.dk andrew.shad...@collabora.co.uk

Hi,

I just checked the condition in Debian Sid, and it looks like no package still
depends or build-depends on package python3-asynctest.

As a result, I am going to submit a RM bug to have this package removed soon.

Thanks,
Boyuan Yang

On Mon, 29 Jun 2020 20:38:29 +0100 "Rebecca N. Palmer" 
 wrote:
> Is the above intended as a proposal to remove asynctest?
> 
> The rdeps in Debian are hypercorn, python-aioresponses, and (for 
> autopkgtest only) python-fakeredis.
> 
> hypercorn upstream have stopped using it:
>
https://gitlab.com/pgjones/hypercorn/-/commit/80e2ad5db107c42d42471ea64764d2b42202349c
> 
> The other two still list it in upstream requirements*.  In the case of 
> aioresponses, this has been reported as a bug, with no reply as yet:
> https://github.com/pnuckowski/aioresponses/issues/162
> 
> Skipping the affected tests is probably an option, though obviously a 
> non-ideal one.


signature.asc
Description: This is a digitally signed message part

Bug#1002962: recode: Please switch to upstream as redirected by GNU

[Boyuan Yang]

Hi,

在 2022-01-04星期二的 22:59 +，Reuben Thomas写道：
> On Tue, 4 Jan 2022 at 22:09, Santiago Vila  wrote:
> > 
> > Working on it now.
> 
> Great!
> 
> > (I'm curious: In which way is this bug different than #961136, also
> > reported by you?)
> 
> Looks to me like the sort of memory failure I am often guilty of!
> Reuben(2020) would report a bug and then Reuben(2021), 18 months
> later, would forget and report it again.

This should be the case. Feel free to merge this bug with #961136 since they
are essentially reporting the same issue.

Thanks,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part

Bug#1003363: installation-reports: Cubietruck installation - No USB

[noreply]

Package: installation-reports Boot method: MMC Image version:
https://deb.debian.org/debian/dists/stable/main/installer-armhf/current/
images/netboot/SD-card-images/ Date: 05.01.2022 Machine: Cubietruck Base
System Installation Checklist: [O] = OK, [E] = Error (please elaborate
below), [ ] = didn't try it Initial boot: [O] Detect network card: [O]
Configure network: [O] Detect media: [E] Load installer modules: [O]
Detect hard drives: [O] Partition hard drives: [O] Install base system:
[O] Clock/timezone setup: [O] User/password setup: [O] Install tasks:
[O] Install boot loader: [O] Overall install: [E] Comments/Problems: USB
devices didn't work. Wasn't able to use my keyaboard for installation,
nor using an installer ISO from an USB stick. Same problem after
installing the system with a serial cable and wanting to type in the
LUKS password with a keyboard during boot. After adding the modules
below to the initramfs, I was able to type in the password. The missing
modules are probably axp20x_ac_power axp20x_battery axp20x_adc 


This email was sent using www.SendEmail.in Requires: No Login No
Password. Just Send Email
Sent on:Saturday, January 08, 2022 4:43:24 PM from computer IP
Address:104.244.74.121

Bug#1003362: Git repository no longer updated

[Philippe Grégoire]

Source: isc-dhcp
Version: 4.4.1-2.3


According to https://packages.debian.org/source/sid/isc-dhcp
the Git repository of the package is on Salsa. However, looking
at the repository, it has been inactive for more than 2 years
and the latest patches are not part of it. See:
https://salsa.debian.org/dhcp-team/isc-dhcp/activity

Using `apt-get source` does provide the latest patches; using
a mixture of Salsa and package repository.

```
root@bullseye:~# apt-get source isc-dhcp
Reading package lists... Done
NOTICE: 'isc-dhcp' packaging is maintained in the 'Git' version control system 
at:
https://salsa.debian.org/dhcp-team/isc-dhcp.git
Please use:
git clone https://salsa.debian.org/dhcp-team/isc-dhcp.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 1281 kB of source archives.
Get:1 http://deb.debian.org/debian bullseye/main isc-dhcp 4.4.1-2.3 (dsc) [2684 
B]
Get:2 http://deb.debian.org/debian bullseye/main isc-dhcp 4.4.1-2.3 (tar) [1190 
kB]
Get:3 http://deb.debian.org/debian bullseye/main isc-dhcp 4.4.1-2.3 (diff) 
[88.1 kB]
Fetched 1281 kB in 0s (2985 kB/s)
dpkg-source: info: extracting isc-dhcp in isc-dhcp-4.4.1
dpkg-source: info: unpacking isc-dhcp_4.4.1.orig.tar.gz
dpkg-source: info: unpacking isc-dhcp_4.4.1-2.3.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying dhclient-script-exit-status.patch
dpkg-source: info: applying dhclient-dividebyzero.patch
dpkg-source: info: applying dhclient-release.patch
dpkg-source: info: applying dhcrelay-listen.patch
dpkg-source: info: applying dhcpd-conf.patch
dpkg-source: info: applying fix-exit-hook-manpage.patch
dpkg-source: info: applying fix-manpage-macro.patch
dpkg-source: info: applying fix-spelling.patch
dpkg-source: info: applying disable-nsupdate.patch
dpkg-source: info: applying system-bind.patch
dpkg-source: info: applying bind-includes.patch
dpkg-source: info: applying configure.patch
dpkg-source: info: applying Fixed_gcc_10_compilation_issues.patch
dpkg-source: info: applying 4.4.2.CVE-2021-25217.patch
W: Download is performed unsandboxed as root as file 'isc-dhcp_4.4.1-2.3.dsc' 
couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
```

Cheers

Bug#970721: xom: new releases available

[tony mancill]

Hi Andrius,

On Sat, Jan 08, 2022 at 09:58:18AM +0200, Andrius Merkys wrote:

> > * diffoscope_198: not enough disk space to rebuild locally, will look
> > for another machine.
> 
> Does not fail with xom_1.3.7+ds-2.

I was also able to build diffoscope_199 successfully with xom 1.3.7:

(diffoscope-199) sbuild 
--extra-package=/data/debian/sponsor/xom/build-area/libxom-java_1.3.7+ds-2_all.deb

> > After sorting these out I will upload xom v1.3.7 to unstable, unless
> > there are objections, of course.
> 
> This is my plan after the weekend.

Thank you for the update and clear communications regarding your
progress.

Cheers,
tony

Bug#1003339: findutils: find manpage definition of "-delete" misses that it can delete directories

[Chris Davies]

On 08/01/2022 17:41, Andreas Metzler wrote:


Given that manpage and info are part of the upstream release I have

submitted a suggested patch to sync the wording.



Thank you. Appreciated



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1002850: journalctl -f for SD card in USB adapter.

[peter]

From bi...@debian.org, Sat, 8 Jan 2022 20;29:23 +0100,

Are you sure you have a custom udev rules file in /etc/udev/rules.d?


Oops, 10-local.rules is attached but the preceding exercise was
misguided, inadvertently of course.

With reference to /dev/disk/by-label/GRNSD in /etc/fstab, the
relevant lines in 10-local.rules were commented out.

I can activate the last rule (KERNEL=="sd?1" ...) and try again.

   ... P.
# udev rules added to mebius by peter, 2021.12.26.
# The Kingston USB.
KERNEL=="sd?1", ATTR{size}=="499712", SYMLINK+="KingstonUSB", OWNER="peter", 
GROUP="peter"

# The green Nexttech SDHC card.
# KERNEL=="mmcblk0p1", ATTR(size)=="7434340", SYMLINK=="GRNSD", OWNER=="peter", 
GROUP=="peter"
#KERNEL=="mmcblk0p1", ENV{ID_SERIAL_SHORT}=="0201202010201000", 
SYMLINK+="GRNSD", OWNER="peter", GROUP="peter"
#KERNEL=="sd?1", ATTR(size)=="7434340", SYMLINK+="GRNSD", OWNER="peter", 
GROUP="peter"

Bug#976811: [pkg-php-pear] Bug#976811: Bug#976811: transition: php8.1

[David Prévot]

Hi,

Le 08/01/2022 à 17:38, Paul Gevers a écrit :

On 01-01-2022 14:20, Ondřej Surý wrote:

[…]

I also see some autopkgtest regressions which have this (eg. [1, 2]):
"""
PHPUnit requires the "dom" extension.
"""
where should that get fixed?


There are several php7.4-* packages pulled in those logs, so it’s not 
really a surprise that doesn’t end well (php-xml 2:7.4+76 is probably 
not the expected version either).


[1] 
https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-monolog/18158564/log.gz 

[2] 
https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-doctrine-cache/18158566/log.gz 


Regards

David


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001591: [Pkg-matrix-maintainers] Bug#1002380: drops attributes used by reverse dependencies

[Pierre-Elliott Bécue]

Jonas Smedegaard  wrote on 22/12/2021 at 23:52:11+0100:

> [[PGP Signed Part:No public key for 2C7C3146C1A00121 created at 
> 2021-12-22T23:52:06+0100 using RSA]]
> Quoting Pierre-Elliott Bécue (2021-12-22 21:42:41)
>> 
>> Jonas Smedegaard  wrote on 22/12/2021 at 21:55:13+0100:
>> 
>> > [[PGP Signed Part:No public key for 2C7C3146C1A00121 created at 
>> > 2021-12-22T21:55:09+0100 using RSA]]
>> > Quoting Pierre-Elliott Bécue (2021-12-22 17:08:46)
>> >> Jonas Smedegaard  wrote on 22/12/2021 at 
>> >> 12:37:21+0100:
>> >> > Releasing a new major release of mistune has caused several 
>> >> > packages to no longer be usable at all.
>> >> >
>> >> > I consider this a serious issue, and have raised severity 
>> >> > accordingly.
>> >> >
>> >> > At least python-m2r have no support for mistune v2 in sight (and 
>> >> > its newer fork - python-m2r2 - does not either). Concretely I 
>> >> > propose to revert this by a (messy) 2.0.0+really0.8.4 release 
>> >> > until reverse dependencies can use the newer major version of 
>> >> > mistune.
>> >> >
>> >> > It seems that a release of python3-django-hyperkitty requiring 
>> >> > mistune v2 has already been uploaded to unstable as well.  That 
>> >> > is very unfortunate, and will need to be rolled back as well.  
>> >> > Mailman maintainers cc'ed.
>> >> >
>> >> > Please in future make sure to check reverse dependencies *before* 
>> >> > releasing a major new upstream release to unstable, because 
>> >> > reversal is messy (complicates package versioning).
>> >> >
>> >> >
>> >> > Kind regards, and thanks for maintaining mistune,
>> >> 
>> >> The issue is that many reverse dependencies of mistune are not 
>> >> maintained.
>> >
>> > I assume (in good faith) that you did not mean to say that the 
>> > _Debian_ packages reverse depending on mistune are all unmaintained.
>> 
>> I'm not sure that there is anything to assume. I wrote "many reverse 
>> dependencies of mistune are not maintained", and making it mean "the 
>> _Debian_ packages reverse depending on mistune are all unmaintained" 
>> would require some hard work.
>> 
>> > Please note that I did not propose to wait until _upstreams_ of 
>> > reverse dependencies can use newer major version of mistune.
>> 
>> Well, I was under the impression that
>> 
>> >>> Concretely I propose to revert this by a (messy) 2.0.0+really0.8.4 
>> >>> release until reverse dependencies can use the newer major version 
>> >>> of mistune.
>> 
>> meant indeed to wait until the reverse dependencies were sorted out 
>> which generally requires to wait until upstream fixes the issue 
>> (except if one likes big quilt patches and maintaining the software's 
>> code on their own).
>
> That is precisely what I did *not* imply (so it seems it was good that I 
> mentioned my non-assumption since apparently you _did_ assume stuff).  
>
> Let me try avoid false assumptions by expanding:
>
> I propose to revert this by a (messy) 2.0.0+really0.8.4 release until 
> reverse dependencies somehow (with or without upstream cooperation) can 
> use the newer major version of mistune (or, if taking unreasonably long, 
> kick any reverse dependencies from testing).
>
>
>> > My proposal is to *collaborate* with your peers in Debian now - not 
>> > continue(!) to make choices without coordination with those packages 
>> > directly affected by those choices.
>> 
>> Maybe you wanted to suggest that I should *collaborate* more, but you 
>> did not write that and, as I tend to try not to assume what one says, 
>> writes or means, I did not read that.
>
> Sorry!
>
> I did indeed mean to encourage more collaboration, and apologize if that 
> failed to get across.
>
>
>> >> If I follow your opinion on this, the following issues arise:
>> >> 
>> >>  1. There is no proper way for software to be mistune 0.8.4 and 
>> >> mistune 2.0.0 compatible at the same way, so the reverse 
>> >> dependencies won't be able to update without mistune 2.0.0 
>> >> being in unstable
>> >
>> > Not sure what you imply by "proper".
>> 
>> appropriate, suitable, relevant, reasonable, …
>> 
>> > There are alternatives to abruptly abandoning support for existing 
>> > functionaling packages already in Debian testing.
>> 
>> Note that since the upload, autopkgtests for the involved 
>> reverse-dependencies were failing and therefore mistune was not 
>> planned to migrate from unstable to testing. There was therefore no 
>> chance mistune would break these packages in testing, and I was not 
>> pressing anyone to sort that out.
>>
>> Now that a serious bug against mistune is opened, even if these 
>> autopkgtests get sorted out because these very reverse-dependencies 
>> are updated, mistune will not migrate anyway (which will prevent to 
>> break other reverse-dependencies).
>
> Yes, I am aware, and that is what I describe as "abruptly": Now that 
> mistune v1 is gone, there is no way to work on any package depending on 
> that except for switching to v2.
>
> ...which is the reason I 

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Paul Gevers]

Hi,

Back from holidays.

On 01-01-2022 14:20, Ondřej Surý wrote:

Some rebuilds failed, e.g. php-horde-lz4 [6],


The FTBFS is unrelated to PHP 8.1 transition


php-wmerrors [7], owfs [8].


These two need upstream update.


I see no activity and no bug reports. Can somebody please update these 
packages or file appropriate bugs?


I also see some autopkgtest regressions which have this (eg. [1, 2]):
"""
PHPUnit requires the "dom" extension.
"""
where should that get fixed?

While we're waiting for php-redis in NEW, can we have a version of 
php-redis that doesn't need to pass NEW?


Looking at the regression caused by php-apcu in symfony [3], are we 
missing some versioned dependency tracking somewhere (or a versioned 
breaks)?


Paul

[1] 
https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-monolog/18158564/log.gz
[2] 
https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-doctrine-cache/18158566/log.gz
[3] 
https://ci.debian.net/data/autopkgtest/testing/amd64/s/symfony/18158567/log.gz


OpenPGP_signature
Description: OpenPGP digital signature

Bug#996997: marked as done (buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster"))

[Christoph Biedl]

[ Thanks for pinging ]

Adam D. Barratt wrote...

> How does this sound as text for an SUA?

To me, it seems worth a idea describing the impact a bit more in detail,
so ...

> "
> http-parser is a parser for HTTP messages, designed to be used in high
> performance HTTP applications.
> 
> The update to http-parser included in the 10.10 point release introduced
> a regression affecting dependent applications

, possibly leading to a crash.

> This update resolves that
> regression.
> 
> If you use http-parser, we strongly recommend that you install this
> update.

But perhaps that's just too much fuzz, I leave the decision to you.

Otherwise it's good.

Regards,

Christoph



signature.asc
Description: PGP signature

Bug#993857: [pkg-gnupg-maint] Bug#993857: Bug#993857: gnupg2: Please remove librsvg2-bin from BD

[Christoph Biedl]

Daniel Kahn Gillmor wrote...

> So the debian-generated image is both more policy-compliant and more
> correct.  We shouldn't stop building it from source.

Quite frankly, I don't think even it's necessary to stress the policy
here, shipping a "more correct" PNG should be motivation enough. And it
seems you have a plan how to achieve both the above goal and Laurent's
interest to have GnuPG built on kfreebsd, so just go ahead.

Christoph


signature.asc
Description: PGP signature

Bug#1003352: Acknowledgement (mdadm: Intel RST RAID not detected because /sys/firmware/efi/efivars wasn't mount)

[CUI Hao]

So the same issue was fixed in Arch Linux by explicitly mounting
efivars inside initramfs:
- https://bugs.archlinux.org/task/52768
- 
https://github.com/archlinux/mkinitcpio/commit/70511e5ccb7e2500213e04173a70c067a7c9aa35

Maybe the issue should be transferred to Debian's counterpart (initramfs-tools).

Bug#811294: ITP: tabview -- curses command-line CSV and list (tabular data) viewer

[Louis-Philippe Véronneau]

On 2022-01-08 07 h 41, Yuri D'Elia wrote:
> I'd be glad if you could take over on the packaging

I'm currently not planning to, as tabview is only an optional dependency
of a package I'm maintaining because it's a build-dep for another
package that is a build-dep of a package I care about :)

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature

Bug#993620: vip-manager: test failure with some network configurations

[Paul Gevers]

Control: severity -1 serious

Hi,

On Fri, 3 Sep 2021 12:17:10 -0600 Dan Bungert 
 wrote:

vip-manager behavior_test can fail, depending on the device network
configuration.  If the test device has a network device of type ether
and a zero hardware address, and it selects this network device as the
one to use, the tests will fail.


We're currently seeing this as a flaky test on amd64 on the Debian 
ci.d.n infrastructure and it's blocking glibc from migrating (for now, a 
retry or two will probably "fix" that).


https://ci.debian.net/packages/v/vip-manager/testing/arm64/

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

On Fri, Jan 07, 2022 at 06:34:06AM -0300, Leandro Cunha wrote:
> > > I also haven't heard from anyone on the chromium team yet - should I
> > > add myself as an uploader and do a normal (non-NMU) upload? Do any of
> > > them care?
> >
> > Without hearing from them, adding yourself to Uploaders would be
> > inappropriate.
> 
> If there is no response from someone on the team and someone wants to continue
> the work, how is it done? I was thinking about it when I read this email.

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#non-maintainer-uploads-nmus
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging

Plus, I suppose, the technical committee has the power to enforce
maintainer changes (though I don't think this has been used in… at least
a decade?).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1001668: downgrading severity

[Paul Gevers]

Control: severity -1 serious

Hi Gordon,

On Fri, 7 Jan 2022 15:50:43 + Gordon Ball  wrote:

Reducing severity to `normal`, since this does not appear to happen
consistently. Looking through the CI logs, there are occasional failures
on ppc64el, but since it does not appear to happen consistently, I don't
_think_ this justifies RC severity, unless anyone can reproduce it in
actual usage.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests. The previous time, a Release Team member checked why glibc was 
blocked, in this case, a Release Team member investigated why glibc was 
blocked. That's why we file these bugs as RC, please either fix them or 
don't run the test on architectures where you experience flaky behavior. 
In this case it seems you should just increase the timeout of that 
particular (or maybe all) tests.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002976: installation-reports: Installer Does Not Provide Screen Reader in Accessible Installation

[Samuel Thibault]

Hello,

D.J.J. Ring, Jr., le lun. 03 janv. 2022 20:47:17 -0500, a ecrit:
> Here's the files from the Buster installation from /var/log/installer -
> attached.

Ok, thanks!

So the "ALC888: SKU not ready 0x0100" message was already there at
the time. What's new in bullseye is 

snd_hda_intel :00:03.0: couldn't bind with audio component
snd_hda_intel :00:03.0: HSW/BDW HD-audio HDMI/DP requires binding with gfx 
driver

I remember having troubles with hda intel and the i915 graphic driver
missing. Could you try this image which includes the i915 driver:

https://people.debian.org/~sthibault/tmp/mini.iso 

(again all the logs are useful to provide since we don't know precisely
what we want to look at)

Samuel

Bug#1003361: ITP: mlyacc-polyml -- LALR parser generator for Standard ML

[Ryan Kavanagh]

Package: wnpp
Severity: wishlist
Owner: Ryan Kavanagh 
X-Debbugs-Cc: debian-de...@lists.debian.org, r...@debian.org

* Package name: mlyacc-polyml
  Version : x.y.z
  Upstream Author : Name 
* URL : https://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : LALR parser generator for Standard ML

An implementation of mlyacc ported from mlton to poly/ml.

I also ITP mllex-polyml. Perhaps the packages should be renamed to
polyml-mllex/polyml-mlyacc, instead of upstream's mllex-polyml and
mlyacc-polyml. https://bugs.debian.org/1003358

These ports may be eventually useful for sml compiler bootstrapping
efforts.

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#1003360: golang-github-satori-go.uuid: Remove prior to bookworm release

[Mathias Gibbens]

Source: golang-github-satori-go.uuid
Version: 1.2.0-2
Severity: important
Tags: bookworm

  The upstream project github.com/satori/go.uuid appears to be dead,
and the community seems to be migrating to github.com/gofrs/uuid, which
is a maintained fork of that library. github.com/gofrs/uuid is already
packaged for Debian, so hopefully the work of updating rdeps will be
fairly straightforward.

gibmat@builder:~$ build-rdeps golang-github-satori-go.uuid-dev
Reverse Build-depends in main:
--

balboa
containerd
crowdsec
deck
docker.io
gitlab-ci-multi-runner
golang-github-azure-azure-sdk-for-go
golang-github-containerd-stargz-snapshotter
golang-github-containers-buildah
golang-github-containers-common
golang-github-containers-image
golang-github-containers-storage
golang-github-crewjam-saml
golang-github-duo-labs-webauthn
golang-github-fsouza-go-dockerclient
golang-github-hashicorp-go-azure-helpers
golang-github-jackc-pgx
golang-github-kong-go-kong
golang-github-opencontainers-runtime-tools
golang-github-openshift-imagebuilder
golang-github-optiopay-kafka
golang-github-russellhaering-goxmldsig
golang-github-samalba-dockerclient
golang-github-sylabs-sif
golang-github-tombuildsstuff-giovanni
golang-github-tonistiigi-fsutil
golang-go-patricia
golang-gocloud
hugo
libpod
nomad
nomad-driver-lxc
nomad-driver-podman
packer
prometheus
prometheus-alertmanager
prometheus-mysqld-exporter
prometheus-postfix-exporter
restic
singularity-container
skeema
skopeo
vuls

Found a total of 43 reverse build-depend(s) for golang-github-satori-
go.uuid-dev.


signature.asc
Description: This is a digitally signed message part

Bug#1003359: golang-github-dgrijalva-jwt-go: Remove prior to bookworm release

[Mathias Gibbens]

Source: golang-github-dgrijalva-jwt-go
Version: 3.2.0-3
Severity: important
Tags: bookworm

  The upstream project github.com/dgrijalva/jwt-go is no longer
maintained, and users are being instructed to switch to
github.com/golang-jwt/jwt. github.com/golang-jwt/jwt has just recently
been packaged for Debian, so hopefully the work of updating rdeps will
be fairly straightforward.

gibmat@builder:~$ build-rdeps golang-github-dgrijalva-jwt-go-dev
Reverse Build-depends in main:
--

consul
crowdsec
docker-libkv
docker.io
etcd
gitlab-ci-multi-runner
gitlab-shell
go-cve-dictionary
go-exploitdb
golang-github-appleboy-gin-jwt
golang-github-azure-azure-sdk-for-go
golang-github-azure-go-autorest
golang-github-containerd-stargz-snapshotter
golang-github-containers-buildah
golang-github-containers-common
golang-github-containers-image
golang-github-containers-storage
golang-github-crewjam-saml
golang-github-docker-leadership
golang-github-duo-labs-webauthn
golang-github-fsouza-go-dockerclient
golang-github-getsentry-sentry-go
golang-github-go-kit-kit
golang-github-grpc-ecosystem-go-grpc-middleware
golang-github-hashicorp-go-azure-helpers
golang-github-hashicorp-go-discover
golang-github-labstack-echo
golang-github-labstack-echo.v2
golang-github-labstack-echo.v3
golang-github-micromdm-scep
golang-github-newrelic-go-agent
golang-github-openshift-imagebuilder
golang-github-optiopay-kafka
golang-github-prometheus-common
golang-github-samalba-dockerclient
golang-github-tombuildsstuff-giovanni
golang-github-tonistiigi-fsutil
golang-github-xordataexchange-crypt
golang-gitlab-gitlab-org-labkit
golang-gocloud
gost
goval-dictionary
hugo
influxdb
libpod
nomad
nomad-driver-lxc
nomad-driver-podman
packer
prometheus
prometheus-alertmanager
prometheus-apache-exporter
prometheus-blackbox-exporter
prometheus-elasticsearch-exporter
prometheus-mysqld-exporter
prometheus-postfix-exporter
prometheus-postgres-exporter
prometheus-snmp-exporter
prometheus-sql-exporter
restic
shoelaces
singularity-container
skeema
skopeo
victoriametrics
vip-manager
vuls

Found a total of 67 reverse build-depend(s) for golang-github-
dgrijalva-jwt-go-dev.


signature.asc
Description: This is a digitally signed message part

Bug#993857: [pkg-gnupg-maint] Bug#993857: Bug#993857: gnupg2: Please remove librsvg2-bin from BD

[Laurent Bigonville]

On 8/01/22 20:04, Daniel Kahn Gillmor wrote:

Control: reopen 993857
Control: retitle 993857 gnupg2: gnupg-module-overview.png is not built from 
source

On Wed 2021-12-15 23:40:23 +0100, Christoph Biedl wrote:

Control: tags 993857 pending

Laurent Bigonville wrote...


Could you please drop librsvg2-bin from the build-dependencies?

(...)

Comparing the built packages before and after removing that build
dependency shows no differences, so it should be safe to drop it.

[...]
So the debian-generated image is both more policy-compliant and more
correct.  We shouldn't stop building it from source.

What's the right way to go to build this on systems where we don't have
rust?  Here's one idea (i haven't tried it yet):

- ensure that gnupg-module-overview.png is shipped in an
   architecture-independent package (e.g. gnupg itself, which is an
   Architecture: all metapackage).  This is where it is today, so far so
   good.

- move the build-deps for it (including imagemagick and librsvg2-bin)
   into the Build-Depends-Indep: section

- maybe put those build-deps behind a  build profile flag for
   minimizing dependencies (see https://wiki.debian.org/BuildProfileSpec)

- ensure that the binary packages build cleanly anyway

- ensure that the arch-independent builds actually do rebuild the .png
   (we might need to delete it before the build depending on the
   timestamps in the tarball)

Laurent, would that approach satisfy your concerns on rust-less
architectures?  Those arches could of course install the
arch-independent packages that were built on platforms like amd64 which
have rust available.


Thanks for your feedback.

My understanding of the policy has always been that the source tarball 
shipped in debian must indeed contain all the files in their "preferred 
form of modification" but the fact that the resulting artifact has to be 
rebuilt during the build of the package was merely a recommendation. 
Here we have both the .svg and the .png file shipped in the tarball, so 
that looks DFSG compatible to me.


My main concern here was to be certain that gnupg can build all 
architectures even the one without rust support and your proposal allows 
this, so it's good for me and if you think it's better to rebuild the 
image during the build I've no objections.


The fact that there is a rendering problem with the .png shipped in the 
upstream tarball should be reported in any case I think.


Kind regards,

Laurent Bigonville

Bug#934926: update

[Joey Hess]

The simple fact is that as an upstream author who used the debian
locations because they were the ones that worked on my system, I get bug
reports from users of other systems that it's not right for wider uses
of zsh. And Debian seems to be leaving it up to me to deal with it,
which just makes me want to not include zsh completions, honestly.

(I got another bug report about this today, for etckeeper.)

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1000152:

[Andreas Hasenack]

Hi,

Bug #1002697 and #1000152 are duplicates of #1003355 which I just
filed, with an upstream fix and salsa PR at
https://salsa.debian.org/debian/cyrus-sasl2/-/merge_requests/8

Ubuntu jammy (devel release) has the same issue and it boils down to
SPNEGO being disabled accidentally in the cyrus-sasl2 build.

Could someone with more bug-control knowledge than I please mark these
dupes accordingly? It doesn't matter which one is a dupe of which,
just pick one.

Thanks!

Bug#1003358: ITP: mllex-polyml -- lexical analyzer generator for Standard ML

[Ryan Kavanagh]

Package: wnpp
Severity: wishlist
Owner: Ryan Kavanagh 
X-Debbugs-Cc: debian-de...@lists.debian.org, r...@debian.org

* Package name: mllex-polyml
  Upstream Author : Takayuki Goto
* URL : https://github.com/eldesh/mllex-polyml
* License : Apache and HPND
  Programming Lang: Standard ML
  Description : lexical analyzer generator for Standard ML

And implementation of mllex ported from mlton to poly/ml.

I also ITP mlyacc-polyml. Perhaps the packages should be renamed to
polyml-mllex/polyml-mlyacc, instead of upstream's mllex-polyml and
mlyacc-polyml.

These ports may be eventually useful for sml compiler bootstrapping
efforts.

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#1002326: python-schema-salad: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13]

[Andreas Tille]

Control: blocked -1 by 1001591

- Weitergeleitete Nachricht von Sandro Tosi  -

Date: Fri, 7 Jan 2022 21:01:30 -0500
From: Sandro Tosi 
To: Andreas Tille , 1002...@bugs.debian.org
Cc: "Michael R. Crusoe" 
Subject: Re: Bug#1002326: python-schema-salad: FTBFS: dh_auto_test: error: 
pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned
exit code 13


another victim of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001591


-- 
http://fam-tille.de

Bug#1002709: webext-ublock-origin-firefox: ublock-origin makes firefox-esr 91 consumes 100% of a CPU core

[Amr Ibrahim]

On Thu, 06 Jan 2022 17:27:13 +0100 Markus Koschany 
wrote:
> It seems this issue is fixed in Firefox 95
> but the fix has not been backported to
> Firefox ESR yet. Let's wait for an update.

For reference, here is the bug against firefox-esr:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002868

Bug#1003357: src:view3dscene: fails to migrate to testing for too long: FTBFS on armel

[Paul Gevers]

Source: view3dscene
Version: 3.18.0-4
Severity: serious
Control: close -1 4.0.0-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1002961

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:view3dscene has been trying to migrate for 
62 days [2]. Hence, I am filing this bug. (Yes, I know this is due to 
cge being unable to rebuild *and* the fpc transition).


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=view3dscene



OpenPGP_signature
Description: OpenPGP digital signature

Bug#999249: Package will now be considered for auto-removal

[John Paul Adrian Glaubitz]

Hello!

On 1/8/22 20:35, Graham Inggs wrote:
> The release team no longer [1] considers popcon a criterion for
> inclusion in the list of key packages [2].
> 
> This email is a courtesy reminder of this bug, and should prevent
> instant auto-removal once the rule is changed in britney.

discover has an installation count of nearly 200.000. Do we really remove
a package that is being installed on so many machines?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1003356: fontconfig-config: fonts-conf(5) man page: undocumented

[Vincent Lefevre]

Package: fontconfig-config
Version: 2.13.1-4.2
Severity: minor

In the fonts-conf(5) man page:

   
   Alias  elements  provide a shorthand notation for the set of
   common match operations needed to substitute one font family
   for  another.   They  contain a  element followed by
   optional ,  and   elements.   Fonts
   matching the  element are edited to prepend the list
   of ed families before the matching ,  append
   the  able  families  after the matching  and
   append the  families to the end of the family list.

No mention of the binding attribute, while it is used in various
config files under the /etc/fonts/conf.avail directory.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 fontconfig-config depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  fonts-croscore 20201225-1
ii  fonts-dejavu-core  2.37-2
ii  fonts-freefont-otf 20120503-10
ii  fonts-freefont-ttf 20120503-10
ii  fonts-liberation   1:1.07.4-11
ii  fonts-liberation2  2.1.5-1
ii  fonts-texgyre  20180621-3.1
ii  fonts-urw-base35   20200910-1
ii  ttf-bitstream-vera 1.10-8.1
ii  ucf3.0043

fontconfig-config recommends no packages.

fontconfig-config suggests no packages.

-- debconf information excluded

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1003355: cyrus-sasl2: GSS-SPNEGO not detected with autoconf 2.71

[Andreas Hasenack]

Package: cyrus-sasl2
Version: 2.1.27+dfsg2-2

Dear Maintainer,

with autoconf 2.71, there is an undetected error in the ./configure
run that results in GSS-SPNEGO being disabled:

>From 
>https://buildd.debian.org/status/fetch.php?pkg=cyrus-sasl2&arch=amd64&ver=2.1.27%2Bdfsg2-2&stamp=1637264771&raw=0:
...
checking for SPNEGO support in GSSAPI libraries... ../configure: line
18854: ac_fn_c_try_run: command not found
no

Upstream has a fix that was merged:
https://github.com/cyrusimap/cyrus-sasl/pull/644/

Bug#1003354: src:jupyter-client: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: jupyter-client
Version: 6.1.12-1
Severity: serious
Control: close -1 7.1.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1000271

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:jupyter-client has been trying to migrate 
for 62 days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.



This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=jupyter-client



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003353: lintian: Cannot use brackets in suppression rules?

[Samuel Thibault]

Package: lintian
Version: 2.114.123
Severity: normal

Hello,

Seeing that qa.debian.org is using version 2.114.123 of lintian, I
upgraded my lintian from its git tree, only to find that it seems I
cannot update my suppression rule according to the new output:

W: libbrlapi-dev: bad-whatis-entry 
[usr/share/man/man3/brlapi_authClientPacket_t.3.gz]
W: libbrlapi-dev: mismatched-override bad-whatis-entry 
[usr/share/man/man3/brlapi_*] [usr/share/lintian/overrides/libbrlapi-dev:2]

I did have updated this rule to include brackets:

bad-whatis-entry [usr/share/man/man3/brlapi_*]

but that doesn't seem to be working. I also tried to use escaping (which
had fixed things for the ${} case), but to no avail:

bad-whatis-entry \[usr/share/man/man3/brlapi_*\]

Lintian has recently been annoying enough that I'm unsure I'd continue
monitoring its output any more.

Samuel

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 depends on:
ii  binutils2.37-10.1
ii  bzip2   1.0.8-5
ii  diffstat1.64-1
ii  dpkg1.21.1
ii  dpkg-dev1.21.1
ii  file1:5.41-2
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  iso-codes   4.8.0-1
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.27-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.27-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-1
ii  libdevel-size-perl  0.83-1+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.1
ii  libemail-address-xs-perl1.04-1+b3
ii  libencode-perl  3.16-1
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-1
ii  libio-prompt-tiny-perl  0.003-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.120-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libperlio-utf8-strict-perl  0.008-1+b1
ii  libproc-processtable-perl   0.634-1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libsort-versions-perl   1.62-1
ii  libsyntax-keyword-try-perl  0.26-1
ii  libterm-readkey-perl2.38-1+b2
ii  libtext-glob-perl   0.11-2
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.13-1
ii  libtext-xslate-perl 3.5.9-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.10-1
ii  libwww-mechanize-perl   2.06-1
ii  libwww-perl 6.60-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.83+ds-1
ii  lzip [lzip-decompressor]1.22-5
ii  lzop1.04-2
ii  man-db  2.9.4-4
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.32.1-6
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

Versions 

Bug#1003352: mdadm: Intel RST RAID not detected because /sys/firmware/efi/efivars wasn't mount

[CUI Hao]

Package: mdadm
Version: 4.2~rc2-7
Severity: normal
X-Debbugs-Cc: cuihao@gmail.com

Dear Maintainer,

I installed Debian bullseye on a Intel RST (also known as IMSM/PCH RAID) RAID 1 
volume. The system couldn't boot itself because the RAID volume which the 
rootfs is on wasn't detected.

I am aware of Bug #962844 and #995047. I know the issue is that 
/sys/firmware/efi/efivars was missing. I manually upgraded mdadm to 4.2~rc2-7 
from testing repo, which had fixed both issues. However, my issue remains -- 
efivars wasn't mounted in initramfs and mdadm didn't detect the RAID volume. I 
had to manually execute:

```
$ mount -t efivarfs none /sys/firmware/efi/efivars
$ mdadm -As
$ exit
```

in the busybox shell. Then the system continued to boot without error.

I can confirm that the efivarfs module had been loaded. But nobody mounted the 
efivars folder. I was wondering if the mdadm initramfs hook or something else 
(systemd-udevd?) should do it.

-- Package-specific info:
--- mdadm.conf
HOMEHOST 
MAILADDR root
ARRAY metadata=imsm UUID=c8dad6bb:dc99d681:830dc792:854d95b2
ARRAY /dev/md/Volume0 container=c8dad6bb:dc99d681:830dc792:854d95b2 member=0 
UUID=c0ffcd21:d15949d6:34933387:da5287ad

--- /etc/default/mdadm
AUTOCHECK=true
AUTOSCAN=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=false

--- /proc/mdstat:
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] 
[raid10] 
md126 : active raid1 nvme0n1[1] nvme1n1[0]
  890806272 blocks super external:/md127/0 [2/2] [UU]
  [==>..]  resync = 72.8% (648784704/890806272) 
finish=20.1min speed=200246K/sec
  
md127 : inactive nvme0n1[1](S) nvme1n1[0](S)
  10402 blocks super external:imsm
   
unused devices: 

--- /proc/partitions:
major minor  #blocks  name

 2590  937692504 nvme0n1
 259   12 523264 nvme0n1p1
 259   13  890281967 nvme0n1p2
 2591  937692504 nvme1n1
 259   10 523264 nvme1n1p1
 259   11  890281967 nvme1n1p2
   8   32 3750738264 sdc
   80 3750738264 sda
   8   48 3750738264 sdd
   8   16 3750738264 sdb
   9  126  890806272 md126
 259   14 523264 md126p1
 259   15  890281967 md126p2

--- LVM physical volumes:
LVM does not seem to be used.
--- mount output
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs 
(rw,nosuid,relatime,size=263986580k,nr_inodes=65996645,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs 
(rw,nosuid,nodev,noexec,relatime,size=52800792k,mode=755)
none on /sys/firmware/efi/efivars type efivarfs (rw,relatime)
/dev/md126p2 on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs 
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
cgroup2 on /sys/fs/cgroup type cgroup2 
(rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=21636)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl 
(rw,nosuid,nodev,noexec,relatime)
/dev/md126p1 on /boot/efi type vfat 
(rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs 
(rw,nosuid,nodev,relatime,size=52800788k,nr_inodes=13200197,mode=700,uid=1000,gid=1000)

--- initrd.img-5.10.0-10-amd64:
206023 blocks
03ab13a39840b2eafad82735ce075acb  ./etc/mdadm/mdadm.conf
d3be82c0f275d6c25b04d388baf9e836  ./etc/modprobe.d/mdadm.conf
192ccafcfe38eabf0f5184786764c4a9  ./scripts/local-bottom/mdadm
f3b648ca1c912da30940f0b821b7e9e6  ./scripts/local-block/mdadm
bab647efe57c79e3e7f6d8057d2acb77  
./usr/lib/modules/5.10.0-10-amd64/kernel/drivers/md/raid0.ko
4fa940a4c4714756644462e40a7b6fa0  
./usr/lib/modules/5.10.0-10-amd64/kernel/drivers/md/linear.ko
4f4087ef5cf6e4782cf8e6cbfd09c9c2  
./usr/lib/modules/5.10.0-10-amd64/kernel/drivers/md/raid1.ko
8ae6e2d0e68fd320700e69204c54dbe3  
./usr/lib/modules/5.10.0-10-amd64/kernel/drivers/md/md-mod.ko
f729dba2a3adfec83fbf1d291f95b879  
./usr/lib/modules/5.10.0-10-amd64/kernel/drivers/md/raid10.ko
926e474b3d31ef8262e1621340d491bb  
./usr/lib/modules/5.10.0-10-amd64/kernel/drivers/md/raid456.ko
0d088936b5658e0a547941fdbf4

Bug#1000681: linux-image-5.15.0-1-amd64: 5.15 upgrade causes all apps to flicker

[Salvatore Bonaccorso]

Source: linux
Source-Version: 5.16~rc8-1~exp1

On Sat, Jan 08, 2022 at 06:15:16PM +0100, Stefan Fritsch wrote:
> 
> On 09.12.21 23:14, Stefan Fritsch wrote:
> > There is discussion and a fix for this issue at
> > 
> > https://lists.freedesktop.org/archives/nouveau/2021-December/039597.html
> > https://lists.freedesktop.org/archives/nouveau/2021-December/039609.html
> > 
> 
> The fix is in 5.15.13

Thanks for tracking it down, indeed this is 67f74302f45d
("drm/nouveau: wait for the exclusive fence after the shared ones v2")
in 5.16-rc8 and which is backported as 2ee1296e0655 in 5.15.13.

Adjusting the metadata and closing it already with 5.16~rc8-1~exp1.

Another 5.15.y upload is currently in the works.

Regards,
Salvatore

Bug#1003351: Update package to upstream version 5.0 (patches provided)

[Nils König]

Source: libunibreak
Version: 1.1-2.1
Severity: wishlist
Tags: patch

Dear Maintainer,

while there aren't any known grave issues with the packaged version 1.1,
released 2013, this is severely lagging behind upstream's newest version
5.0 released in late 2021.
Upgrading to 5.0 brings the benefit of an updated linebreaking behaviour
following the current revision of Unicode and additional API-entrypoints
and new API regarding graphemes and pictographics.
Thus I believe it would be a good idea to upgrade; patches to update
the Debian package to 5.0 are attached (also fixing lintian warnings).

One noteworthy incompatible change is that in 5.0 the signature of the
set_linebreaks (without suffix) function from linebreakdef.h changed its
signature. However as far as I can tell currently the only user of
libunibreak in the Debian archives is libzltext, which does not use this
function, so this is probably not an issue.
https://github.com/adah1972/libunibreak/commit/a6bcee2daf6fb884edd1ff78ce58521ab31f9826

  $ ls -l ~1/libzltext.so.0.13
  lrwxrwxrwx 1 user user 20  1. Sep 2019  /tmp/libzltext.so.0.13 -> 
libzltext.so.0.12.10
  $ nm -gDC ~1/libzltext.so.0.12.10 | grep -E '^ +U' | grep -E 
'lb_|ub_|unibreak|break'
   U init_linebreak
   U set_linebreaks_utf8


The patches are split in 6 parts in hopes to make review easier.
As one of the patches is large'ish (~1.5MiB) due to adding some data files
otherwise fetched from the network, I compressed all of them into a
xz-compressed tar-archive before attaching. Some further notes:

The changelog is using the ~local suffix and my own name; this will
need to be changed to reflect the actual uploader and drop the suffix.

Upstream tarballs contain prebuilt documentation including some javascript,
to resolve the errors resulting from the sourceless javascript I'm using
Files-Excluded to repackage the tarball without the docs.
This works, but perhaps there's a softer approach to resolve this?

It appears like most packages, include a copyright declaration for debian/*
with past and current maintainers as copyright holders; this package does not,
but obviously I cannot choose a licence for someone else. If this is required,
what licence did/do you intend Eugene?

I made sure to resolve all lintian hints >= pedantic, but I only packaged for my
personal use before, so there might be some things I missed and not caught by
lintian, or just superior alternative approaches I don't know about.
Nonetheless I'm hoping the patches are helpful in getting the package back in
sync with upstream.


Cheers
Nils König



-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'
), (500, 'stable'), (10, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-10-amd64 (SMP w/16 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: openrc-init
LSM: AppArmor: enabled

Versions of packages libunibreak1 depends on:
ii  libc6  2.31-13+deb11u2


libunibreak-5.0-patches.tar.xz
Description: application/xz


signature.asc
Description: PGP signature

Bug#1002521: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#999730: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#1002360: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#1002143: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#1002192: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#1001841: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#1000896: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#999249: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#999037: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#998999: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#998516: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#997763: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#997652: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#997601: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#997406: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#997367: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#997287: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#997194: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#993882: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#993716: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Bug#993350: Package will now be considered for auto-removal

[Graham Inggs]

Hi Maintainer

The release team no longer [1] considers popcon a criterion for
inclusion in the list of key packages [2].

This email is a courtesy reminder of this bug, and should prevent
instant auto-removal once the rule is changed in britney.

Regards
Graham


[1] 
http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html
[2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi