date:20220208




On 2/8/22 23:55, Andres Salomon wrote:

On 2/8/22 13:25, Matthias Gies wrote:

Hi,

thanks for the quick response.

"echo $XDG_CURRENT_DESKTOP" returns "KDE"

"dbus-update-activation-environment --systemd XDG_CURRENT_DESKTOP" 
does not

return anything.

No change in behavior after restarting Chromium. Still stuck with GTK 
file

dialog.




Alright, so I tried installing KDE (under wayland) and chromium 
97.0.4692.99-1, but when I opened the file dialog it was the gtk one. 
Probably because I'd been previously running cinnamon and gnome on the 
machine, but XDG_CURRENT_DESKTOP *was* set to "KDE". I noticed that 
xdg-desktop-portal-gtk and xdg-desktop-portal-gnome were running in 
the background of my session, and xdg-desktop-portal-kde wasn't 
installed. After installing it and restarting kde, I had kde's file 
dialog.



So then I installed chromium 98.0.4758.80-1, right clicked to download 
a file ("save link as"), and again had kde's file dialog.



That was all tested on unstable, and there's an older version of 
xdg-desktop-portal-kde on stable so the package's behavior may be 
different. Do you have it installed? When you start kde, is it running 
in the background?




Oh, it may actually launch when chromium starts (at least 
xdg-desktop-portal-gtk does, when run under cinnamon; now I'm not 100% 
certain whether it started at kde launch or afterwards). So you'll need 
to check when kde is started if it's running in the background, and also 
after chromium is started.

Bug#1005169: regression: Chromium is not using plasma file dialog anymore since overlast update


On 2/8/22 13:25, Matthias Gies wrote:

Hi,

thanks for the quick response.

"echo $XDG_CURRENT_DESKTOP" returns "KDE"

"dbus-update-activation-environment --systemd XDG_CURRENT_DESKTOP" does not
return anything.

No change in behavior after restarting Chromium. Still stuck with GTK file
dialog.




Alright, so I tried installing KDE (under wayland) and chromium 
97.0.4692.99-1, but when I opened the file dialog it was the gtk one. 
Probably because I'd been previously running cinnamon and gnome on the 
machine, but XDG_CURRENT_DESKTOP *was* set to "KDE". I noticed that 
xdg-desktop-portal-gtk and xdg-desktop-portal-gnome were running in the 
background of my session, and xdg-desktop-portal-kde wasn't installed. 
After installing it and restarting kde, I had kde's file dialog.



So then I installed chromium 98.0.4758.80-1, right clicked to download a 
file ("save link as"), and again had kde's file dialog.



That was all tested on unstable, and there's an older version of 
xdg-desktop-portal-kde on stable so the package's behavior may be 
different. Do you have it installed? When you start kde, is it running 
in the background?

Bug#991036: libhandy: Should this package be removed in bookworm?

2022-02-08 Thread Adrian Bunk

Control: severity -1 serious

libhandy is about to be removed from bookworm due to this,
gnome-authenticator and gnome-metronome need to be updated.

cu
Adrian

Bug#1005211: ufolib2: Replace dh-python-pep517 with pybuild-plugin-pyproject

Source: ufolib2
Version: 0.12.1+dfsg1-1
Severity: normal
Tags: patch

The next dh-python upload will remove support for Build-Depending on
dh-python-pep517.

Please replace this with pybuild-plugin-pyproject.

Thanks,

SR

diff -Nru ufolib2-0.12.1+dfsg1/debian/control 
ufolib2-0.12.1+dfsg1/debian/control
--- ufolib2-0.12.1+dfsg1/debian/control 2021-12-19 01:27:41.0 -0400
+++ ufolib2-0.12.1+dfsg1/debian/control 2022-02-08 22:49:41.0 -0400
@@ -5,7 +5,7 @@
 Uploaders: Yao Wei (魏銘廷) 
 Build-Depends:
  debhelper-compat (= 13),
- dh-python-pep517,
+ pybuild-plugin-pyproject,
  python3-all,
  python3-wheel,
  python3-setuptools,

Bug#1005210: silkaj: Replace dh-python-pep517 with pybuild-plugin-pyproject

Source: silkaj
Version: 0.9.0-3
Severity: normal
Tags: patch

The next dh-python upload will remove support for Build-Depending on
dh-python-pep517.

Please replace this with pybuild-plugin-pyproject.

Thanks,

SR

diff -Nru silkaj-0.9.0/debian/control silkaj-0.9.0/debian/control
--- silkaj-0.9.0/debian/control 2021-12-14 06:07:30.0 -0400
+++ silkaj-0.9.0/debian/control 2022-02-08 22:48:17.0 -0400
@@ -6,12 +6,12 @@
  Jonas Smedegaard ,
 Build-Depends:
  debhelper-compat (= 13),
- dh-python-pep517,
  dh-sequence-bash-completion,
  dh-sequence-python3,
  help2man,
  libtest-command-simple-perl ,
  perl ,
+ pybuild-plugin-pyproject,
  python3,
  python3-base58,
  python3-click (>= 8),

Bug#1005209: python-matrix-nio: Replace dh-python-pep517 with pybuild-plugin-pyproject

Source: python-matrix-nio
Version: 0.18.7-1
Severity: normal
Tags: patch

The next dh-python upload will remove support for Build-Depending on
dh-python-pep517.

Please replace this with pybuild-plugin-pyproject.

Thanks,

SR

diff -Nru python-matrix-nio-0.19.0/debian/control 
python-matrix-nio-0.19.0/debian/control
--- python-matrix-nio-0.19.0/debian/control 2021-12-14 06:36:49.0 
-0400
+++ python-matrix-nio-0.19.0/debian/control 2022-02-08 22:45:40.0 
-0400
@@ -6,9 +6,9 @@
  Jonas Smedegaard ,
 Build-Depends:
  debhelper-compat (= 13),
- dh-python-pep517,
  dh-sequence-python3,
  dh-sequence-sphinxdoc ,
+ pybuild-plugin-pyproject,
  python3,
  python3 (>= 3.7) | python3-dataclasses ,
  python3-aiofiles ,

Bug#1005208: Audacity crashes after about half an hour of recording at the highest sampling rate of 384000

2022-02-08 Thread Peter Mueller

Package: audacity
Version: 2.4.2~dfsg0-5
After about half an hour of recording from Line-In at the highest sampling rate 
384000 audacity crashes although enough of free RAM and storage seems to be 
available. The crash seems to be reproducible if I record from a particular 
music cassette (and not reproducible if I record from another music cassette). 
The last messages on console were these:
“
*** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a 
breakpoint on '_pixman_log_error' to debug
*** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a 
breakpoint on '_pixman_log_error' to debug
*** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a 
breakpoint on '_pixman_log_error' to debug
02:53:32: Debug: AudioIO::GetBestRate() for capture 02:53:32: Debug: 
GetBestRate() suggested rate 44100 Hz 02:53:32: Debug: GetBestRate() Returning 
44100 Hz
[1]+ Getötet audacity
”

Bug#1005207: python-duniterpy: Replace dh-python-pep517 with pybuild-plugin-pyproject

Source: python-duniterpy
Version: 0.62.0-2
Severity: normal
Tags: patch

The next dh-python upload will remove support for Build-Depending on
dh-python-pep517.

Please replace this with pybuild-plugin-pyproject.

Thanks,

SR

diff -Nru python-duniterpy-0.62.0/debian/control 
python-duniterpy-0.62.0/debian/control
--- python-duniterpy-0.62.0/debian/control  2021-12-14 07:09:56.0 
-0400
+++ python-duniterpy-0.62.0/debian/control  2022-02-08 22:35:15.0 
-0400
@@ -7,7 +7,7 @@
 Build-Depends:
  black ,
  debhelper-compat (= 13),
- dh-python-pep517,
+ pybuild-plugin-pyproject,
  dh-sequence-python3,
  dh-sequence-sphinxdoc ,
  mypy ,

Bug#985934: chromium: Built in update feature appears to be enabled

2022-02-08 Thread Dominic Hargreaves

On Tue, Feb 08, 2022 at 06:12:20PM -0500, Andres Salomon wrote:
> On Sun, 28 Mar 2021 18:44:48 +0200 Michel Le Bihan wrote:
> > Hello,
> >
> > Are you sure that you were using Chromium from the Debian package?
> >
> > Michel Le Bihan
> >
> >
> 
> >
> 
> 
> Hi, I don't know if you saw Michel's response. Can you please let us know if
> it was the debian package chromium (the About Chromium page should
> specifically say this), and if it is still a problem in the latest chromium
> package?

I didn't see that, no (the BTS doesn't send messages to bug addresses
to the submitter).

I'm 100% sure that it was a Debian build - I've not ever used anything
else in the machine in question. I haven't seen the behaviour since,
however.

Dominic

Bug#1005206: Split into separate C and C++ API packages

2022-02-08 Thread nurupo

Package: libmsgpack-dev
Version: 3.3.0-4
Severity: wishlist

Dear Maintainer,

MessagePack provides separate C and C++ APIs. If all you want is the C
API, having to install around 150MiB of C++ boost libraries is rather
undesired. It would be nice if the package was split into two -- one
providing the C API and another for C++.

Bug#1005205: RM: pytorch [armhf] -- ANAIS; no longer support armhf, RM to allow migration

2022-02-08 Thread M. Zhou

Package: ftp.debian.org
Severity: normal

(please explain the reason for the removal here)

https://qa.debian.org/excuses.php?package=pytorch
armhf archtecture is no longer supported in the latest source.
Please remove that architecture for pytorch to allow 
testing migration.

Thanks in advance.

Note: this was a request for a partial removal from testing, converted
in one for unstable
Thank you for using reportbug

Bug#1001135: rust-nom: new upstream version needed for full functionality in sniffglue.

2022-02-08 Thread James McCoy

On Sat, Jan 22, 2022 at 10:07:06AM -0500, James McCoy wrote:
> On Sun, Dec 05, 2021 at 03:27:46AM +, Peter Michael Green wrote:
> > Now that those semver transitions are complete I decided to take a look at
> > what would be involved in updating nom.  I came up with the following list.
> 
> Thanks for starting this discussion.  As mentioned on IRC, I'm going to
> start working on this.  I'll upload the new nom packages to
> experimental once minimal-lexical makes it out of NEW.

Staging to experimental has started.  Trying to get a couple
packages/day done.  So far

* nom
* cexpr
* iso8601
* pktparse
* nom-derive-impl

are in experimental.

Just uploaded nom-derive to NEW.

bindgen needs an update to which 4.2.2.

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

Bug#1001823: Ping?

2022-02-08 Thread Jens Rottmann


Would you like me to provide additional info or reformat my patch?

Bug#1005204: ITP: golang-github-amalfra-etag -- A go package to create HTTP ETags

2022-02-08 Thread Benedikt Wildenhain

Package: wnpp
Severity: wishlist
Owner: Benedikt Wildenhain (BO) 

* Package name: golang-github-amalfra-etag
  Version : 1.0.0-1
  Upstream Author : Amal Francis
* URL : https://github.com/amalfra/etag
* License : Expat
  Programming Lang: Go
  Description : A go package to create HTTP ETags

A go package to create HTTP ETags (as defined in RFC 7232) for use in
HTTP responses.

It is needed by owncast.

Bug#898627: man-db: dependency loop

2022-02-08 Thread Colin Watson

Control: reassign -1 dpkg

[For background, the dpkg output from earlier messages in this bug was:

> # apt-get -f install
> dpkg: Cycle in triggers found:
>  Chain of packages, which triggers might be the culprit:
>   man-db -> man-db
>  required triggers of packages that can't be resolved:
>   man-db: /usr/share/man
>   libc-bin: ldconfig
> dpkg: Error while configureing package man-db (--configure):
>  Triggers build a loop, aborted
]

On Mon, May 14, 2018 at 04:35:34PM +0100, Ian Jackson wrote:
> Colin Watson writes ("Re: Bug#898627: man-db: dependency loop"):
> > On Mon, May 14, 2018 at 04:03:51PM +0100, Ian Jackson wrote:
> > > Does the man-db or libc-bin postinst explicitly trigger
> > > /usr/share/man ?
> > 
> > Not as far as I can see.  That would have to be a dpkg-trigger(1) call,
> > right?
> 
> Yes.  (Directly or indirectly, of course.)

I think this can only have been a dpkg bug, since to my knowledge
there's no such explicit triggering going on here, so I'm reassigning
it.  Sorry to have to reassign an old bug that may be hard to reproduce
at this point ...

Thanks,

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

Bug#1005191: ddcutil: requires undocumented manual setup to make it usable

2022-02-08 Thread Sanford Rockowitz

Samuel,

Thanks for your comments.

Questions like these have come up before.  In general, not wanting to be 
a bull in the proverbial system configuration china shop, I've hesitated 
to make system-wide changes.

On Debian, ddcutil requires i2c-tools. File DEBIAN/postinst in the 
i2c-tools .deb package creates group i2c if it does not already exist.  
Package i2c-tools also installs file 
/lib/udev/rules.d/60-i2c-tools.rules, which assigns the /dev/i2c* 
devices to group i2c:

SUBSYSTEM=="i2c-dev",KERNEL=="i2c-[0-9]*", GROUP="i2c", MODE="0660"

File 45-ddcutil-i2c.rules contains:

KERNEL=="i2c-[0-9]*", GROUP="i2c", MODE="0660"

While more precise than ddcutil's rule the one in i2c-tools.rules file 
should make ddcutil's unnecessary.

What installation path did you take that required you to manually 
install 45-ddcutil-i2c-rules?

Ensuring that i2c-dev is either built into the kernel or explicitly 
loaded has been to me less clear.  Would creating 
/etc/modules-load.d/i2c-dev.conf as you suggest always be safe? 
Presumably there would have to be checks as to whether i2c-dev is loaded 
by some other file in modules-load.d or is built into the kernel.

At the start of execution, ddcutil checks for i2c-dev.   If it's 
definitely missing ddcutil issues a message and terminates execution. 
Unfortunately, ddcutil can't always tell (there have been bug reports 
when the user's environment is non-vanilla), in which case there's only 
a warning message.

Bottom line, would forcing the load of i2c-dev always be safe? Would it 
be considered tampering with the user's environment. Should a modprobe.d 
file be created  if i2c-dev is built into the kernel?

Andrey Rahmatullin has been the sponsor for ddcutil.  He's been very 
helpful in getting ddcutil properly packaged, but he's not always been 
quick to respond.  I'm sure he wouldn't mind if you took over.   There's 
also new package ddcui which provides a GUI version of ddcutil, and 
which is in need of a sponsor.

As for maintaining ddcutil in salsa, my understanding is that packages 
there are debianized specifically for Debian.  The ddcutil repo is 
distribution neutral.  I have a collection of build scripts that build 
ddcutil for deb and rpm systems, submitting packages to launchpad, OBS 
(deb and rpm variants), and COPR.  Even within the deb family some files 
differ between Debian, launchpad, and OBS. There's also a feedback loop 
where packages are built for the several targets before the distribution 
tarball is released.  So it seems to me that a salsa repo would just be 
another artifact to manage.  But again, I have only a superficial 
understanding of salsa.

Though things should of course just work without the user having to dig 
through buried documentation, the i2c-dev requirements are documented. 
See pages www.ddcutil.com/config and www.ddcutil.com/kernel_module.  The 
"ddcutil environment" command checks that the user environment is 
adequately set up and makes recommendations.  (With the --verbose 
option, it produces voluminous information that I use for remote 
diagnosis.)

Thank you for whatever help or guidance you can provide.

Sanford

On Tue, 8 Feb 2022 19:14:38 + Samuel Henrique  
wrote:

> Package: ddcutil
> X-Debbugs-Cc: samuel...@debian.org
> Version: 1.2.1-1
> Severity: normal
>
> Hello Sanford, thank you for working on ddcutil :)
>
> I wanted to report on a few manual steps I had to take to make ddcutil
> usable for me (I'm using it through gnome-display-brightness-ddcutil).
>
> I would like to see the ddcutil package automate this setup, or at
> least ask the user if they want this to be done (if there are any
> security concerns). Alternatively there could also be better messaging
> on what's needed so we don't risk leaving users in the dark about it.
>
> First I had to load the kernel module for i2c-dev:
> # echo "i2c-dev" /etc/modules-load.d/i2c-dev.conf
>
> Then I had to copy the udev rule:
> # cp /usr/share/ddcutil/data/45-ddcutil-i2c.rules /etc/udev/rules.d
>
> So to summarize, anything that could be done to help users on these
> two steps would be awesome.
>
> Also, if by any chance you're looking for help, I would be happy to
> sponsor your uploads, and/or co-maintain the package and move it to
> salsa.
>
> Thanks,
>
> --
> Samuel Henrique 
>
>

Bug#1005203: rustc: Please package at least version 1.57

2022-02-08 Thread Mike Hommey

Package: rustc
Version: 1.56.0+dfsg1-2
Severity: important

Dear Maintainer,

Firefox 97 requires rustc 1.57 (released 2 months ago), which is not yet
available in unstable.

Mike

Bug#1001995: libcrypto++: ftbfs on armhf

2022-02-08 Thread Jeffrey Walton

I opened this for the GCC folks:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104455. I'm not sure if
they are aware things no longer work.

Jeff

Bug#1005202: openmolcas: Is the -fno-expensive-optimizations flag still needed?

2022-02-08 Thread João

Source: openmolcas
Version: 21.10-1
Severity: normal

Dear Maintainer,

Is the compiler flag -fno-expensive-optimizations in debian/rules still needed?
This flag was introduced to fix a problem with the arm64 build as reported in 
the bug
https://bugs.debian.org/961704
and associated upstream issue
https://gitlab.com/Molcas/OpenMolcas/-/issues/218

However the following merge request applied upstream
https://gitlab.com/Molcas/OpenMolcas/-/merge_requests/420
suggests that the issue might have been fixed with the flag -ffp-contract=off

Many thanks,
João

Bug#952815: grub2: Please drop TARGET_CCASFLAGS from debian/rules for 2.06 release

2022-02-08 Thread Colin Watson

On Tue, Feb 08, 2022 at 08:39:54PM +0100, John Paul Adrian Glaubitz wrote:
> Just a reminder that this patch can be applied now and the extra 
> TARGET_CCASFLAGS
> for sparc64 can be dropped. I have verified that grub2 still builds and boots 
> fine
> on sparc64 with the TARGET_CCASFLAGS setting removed.

Ah right, sorry, I forgot about this.  Applying to git now.

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

Bug#1001251: [Pkg-rust-maintainers] Bug#1001251: debcargo changed names of a feature package

2022-02-08 Thread Daniel Kahn Gillmor

Hi Ximin--

thanks for the followup.

On Tue 2022-02-08 15:50:31 +, Ximin Luo wrote:
> Is your issue simply this? https://github.com/rust-lang/cargo/issues/7769

I think if this were fixed, then i could probably convince the sequoia
upstreams to mark the optional-dependency features as non-public,
leaving only their explicit, outwardly-defined features.  They're pretty
committed to API stability and they understand these details.

> If so please close this bug as invalid, since it is not debcargo's 
> responsibility.

While cargo closing that bug would solve my specific problem (after i
convince the relevant upstreams to do the work to think it through), I
don't think that's the only way to solve it, and i also don't think it
solves the general problem.

Even if the rust ecosystem were to allow packages to offer non-public
features, there are still situations where public features could be
aliased to one another, and debcargo would need to choose one or the
other of them as a name for the feature package.  It should do this in a
deterministic way, both for simplicity and reliability, and to avoid
unnecessary churn through NEW.

   --dkg

signature.asc
Description: PGP signature

Bug#1005201: boost1.74: outdated embedded data copy: unicode-data

2022-02-08 Thread Paul Wise

Source: boost1.74
Severity: normal
Usertags: embed

Unicode 14 was released and unicode-data 14.0.0-1.1 was uploaded.

The boost1.74 source package contains very very outdated embedded
data copies of several files from Unicode 5.2.0:

   $ head -n1 libs/spirit/workbench/unicode/*.txt
   ==> libs/spirit/workbench/unicode/DerivedCoreProperties.txt <==
   # DerivedCoreProperties-5.2.0.txt
   
   ==> libs/spirit/workbench/unicode/PropList.txt <==
   # PropList-5.2.0.txt
   
   ==> libs/spirit/workbench/unicode/Scripts.txt <==
   # Scripts-5.2.0.txt
   
   ==> libs/spirit/workbench/unicode/UnicodeData.txt <==
   ;;Cc;0;BN;N;NULL

Upstream appears to have converted those files into these files using
before releasing the tarball.

   
libs/spirit/include/boost/spirit/home/support/char_encoding/unicode/script_table.hpp
   
libs/spirit/include/boost/spirit/home/support/char_encoding/unicode/uppercase_table.hpp
   
libs/spirit/include/boost/spirit/home/support/char_encoding/unicode/category_table.hpp
   
libs/spirit/include/boost/spirit/home/support/char_encoding/unicode/lowercase_table.hpp
   libs/spirit/include/boost/spirit/home/support/char_encoding/unicode/query.hpp

Most of these were generated using the create_tables code, which is in
the source package but is not built and run during the build process.
   
   $ grep -r create_tables
   debian/copyright: libs/spirit/workbench/unicode/create_tables.cpp
   $ grep -C5 AUTO libs/spirit/workbench/unicode/create_tables.cpp
   << "    Copyright (c) 2001-2011 Joel de Guzman\n"
   << "\n"
   << "    Distributed under the Boost Software License, Version 1.0. 
(See accompanying\n"
   << "    file LICENSE_1_0.txt or copy at 
http://www.boost.org/LICENSE_1_0.txt)\n"
   << "\n"
   << "    AUTOGENERATED. DO NOT EDIT!!!\n"
   << 
"==*/\n"
   << "#include \n"
   << "\n"
   << "namespace boost { namespace spirit { namespace ucd { namespace 
detail\n"
   << "{"
   $ head -n8 
libs/spirit/include/boost/spirit/home/support/char_encoding/unicode/script_table.hpp
   
/*=
   Copyright (c) 2001-2011 Joel de Guzman
   
   Distributed under the Boost Software License, Version 1.0. (See 
accompanying
   file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
   
   AUTOGENERATED. DO NOT EDIT!!!
   
==*/

One of those files (query.hpp) is generated by a python script instead
and that is not available in the source package, I think this is
therefore a severity serious bug but I'm not sure.
   
   $ head -n9 
libs/spirit/include/boost/spirit/home/support/char_encoding/unicode/query.hpp
   
/*=
   Copyright (c) 2001-2011 Joel de Guzman
   
   Distributed under the Boost Software License, Version 1.0. (See 
accompanying
   file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
   
   Autogenerated by MultiStageTable.py (Unicode multi-stage
   table builder) (c) Peter Kankowski, 2008
   
==*/

These files are then shipped in the libboost1.74-dev binary package.

Please ask upstream to remove the above files from the source package
and instead build-depend on the unicode-data binary package and convert
the relevant files to headers at build time.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1005184: marked as pending in lintian

On Tuesday, February 8, 2022 5:29:08 PM EST Felix Lechner wrote:
> Control: tag -1 pending
> 
> Hello,
> 
> Bug #1005184 in lintian reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/lintian/lintian/-/commit/5566419ffd36c9c05bd12a51e6
> 00e3687d6b5f62
> 
> 
> Mask examples in tests from package-does-not-install-examples. (Closes:
> #1005184)

Thanks for the quick turn-around.  FYI, I looked at the diff and noticed you 
made the new file copyright 2021.  This being 2022, that seemed like it  might 
be a mistake.

Scott K

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

Bug#985934: chromium: Built in update feature appears to be enabled

On Sun, 28 Mar 2021 18:44:48 +0200 Michel Le Bihan wrote:
> Hello,
>
> Are you sure that you were using Chromium from the Debian package?
>
> Michel Le Bihan
>
>

>

Hi, I don't know if you saw Michel's response. Can you please let us 
know if it was the debian package chromium (the About Chromium page 
should specifically say this), and if it is still a problem in the 
latest chromium package?

https://bugs.debian.org/985934

Bug#1000336: Upgrading tbb

2022-02-08 Thread M. Zhou

Hi Diane,

Thank you. I have added that patch in the git repository.

On Tue, 2022-02-08 at 13:49 -0800, Diane Trout wrote:
> Hi,
> 
> After Andreas pointed it out I looked through some of the build
> failures for onetbb and talked to upstream about the i386 failure.
> https://github.com/oneapi-src/oneTBB/issues/370#issuecomment-1030387116
> 
> They have a patch.
> https://github.com/oneapi-src/oneTBB/commit/542a27fa1cfafaf76772e793549d9f4d288d03a9
> 
> I've tested it against a checkout of the 2021.5.0-1 version of onetbb
> on i386 and it does build with it applied. Once there was a test
> failure, and once all tests ran successfully
> 
> I see that you've made some more progress for the memory alignment
> bugs
> so I didn't commit "Detect 32 bit x86 systems while adding -mwaitpkg
> option" i386 patch but could if you want.
> 
> Diane
> 
>

Bug#1000336: Upgrading tbb

2022-02-08 Thread Diane Trout

Hi,

After Andreas pointed it out I looked through some of the build
failures for onetbb and talked to upstream about the i386 failure.
https://github.com/oneapi-src/oneTBB/issues/370#issuecomment-1030387116

They have a patch.
https://github.com/oneapi-src/oneTBB/commit/542a27fa1cfafaf76772e793549d9f4d288d03a9

I've tested it against a checkout of the 2021.5.0-1 version of onetbb
on i386 and it does build with it applied. Once there was a test
failure, and once all tests ran successfully

I see that you've made some more progress for the memory alignment bugs
so I didn't commit "Detect 32 bit x86 systems while adding -mwaitpkg
option" i386 patch but could if you want.

Diane

Bug#1005181: dask: autopkgtest regression: dask/bytes/tests/test_http.py:120: Failed

2022-02-08 Thread Emmanuel Arias

On Tue, Feb 8, 2022 at 4:34 PM Diane Trout  wrote:

> On Tue, 2022-02-08 at 11:40 -0300, Emmanuel Arias wrote:
> > Source: dask
> > Version: 2021.09.1+dfsg-2
> > Severity: important
> > X-Debbugs-Cc: eam...@yaerobi.com
> >
> > Dear Maintainer,
> >
> > The last update of fsspec package[0] cause a regression for dask[1].
> > That is already fixed in upstream[2].
> >
> > Please consider package new upstream release or backport the upstream
> > fix.
>
> Thanks for the report.
>
> Sadly I can't update dask to the latest version yet as they added a new
> dependency which is still in NEW.
>
> Hopefully the patch will backport.
>
Thanks!

>
> Diane
>

Bug#1005200: lintian: prefer-uscan-symlink should to single maintainer packages at most

2022-02-08 Thread Felix Lechner

Control: forcemerge 1001458 -1

Hi,

On Tue, Feb 8, 2022 at 1:33 PM Scott Kitterman  wrote:
>
> It's not clear why this would be better

This tag was implemented at the suggestion of a very reputable fellow
contributor, but I am also not sure I understand the benefit. We may
drop the tag again.

I took the liberty to merge this bug with the bug advocating the removal.

Kind regards
Felix Lechner

Bug#533639: dselect: beeps on window resize

2022-02-08 Thread Guillem Jover

Control: tag -1 moreinfo unreproducible

Hi!

On Fri, 2009-06-19 at 16:16:28 +0200, Piotr Engelking wrote:
> Package: dselect
> Version: 1.15.2
> Severity: minor

> 'dselect select' beeps when the terminal window is resized.
> 
> Please don't beep on window resize.

I cannot reproduce this, when enabling a visual bell (as I have bells
disabled by default).

I'm marking the report as such, and otherwise will be closing in a bit
if I hear nothing.

Thanks,
Guillem

Bug#1003548: transition: libwebp

2022-02-08 Thread Jeff Breidenbach

To make it super clear, here is the updated formal request with updated Ben
file.

===

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello Release Team,

We would like to transition libwebp to a new upstream version 1.2.1-6
that is already uploaded and built in experimental. No build problems
are expected in the reverse dependencies either. This was tested by
rebuilding a subset of packages listed on the transition web page:

https://release.debian.org/transitions/html/auto-libwebp.html

Please let us know if we can proceed with the upload to unstable. Also
a binNMU rebuild of reverse dependencies would be required afterwards.


Ben file:

title = "libwebp";
is_affected = .depends ~ "libwebp6" | .depends ~ "libwebp7";
is_good = .depends ~ "libwebp7";
is_bad = .depends ~ "libwebp6";

Bug#1001995: libcrypto++: ftbfs on armhf

2022-02-08 Thread Jeffrey Walton

Hi Everyone,

My apologies for the late reply.

SL > There are various ways to reconcile this incompatibility between
SL > build options, but given this is armhf which is guaranteed to have
SL > floating-point support, I think the simplest may be as in the
SL > attached patch, which adjusts to using -march=armv7-a+fp instead
SL > of just -march=armv7-a.

I have to admit I am a bit confused. armhf is hard floats, so the
value can only be -mfloat-abi=hard unless it is explicitly changed. We
don't change it.

As far as I know, the code does not need the floating point unit or
neon. In fact, we stopped using -mfloat-abi because we don't care what
it is. The compiler default is fine by us.

Would adding -mfpu=auto [1] be acceptable to you? I think that conveys
the "don't care" attitude when compiling and assembling this source
file.

SL > However, I have not tested that this results in correct
SL > behavior on armel, which is also still a Debian
SL > architecture but not an Ubuntu architecture.

LB > confirmed the problem and the fix as well on armhf in a
LB > Sid chroot. Still need to check it on armel.

armel is going to need CRYPTOPP_DISABLE_ARM_NEON defined in CPPFLAGS
or CXXFLAGS. The reason is my ignorance. I don't know how to
differentiate between armel and armhf in the preprocessor. They both
look the same to us. Preprocessor macros don't change until we start
adding options like -mfpu=neon.

So, we assume armhf and make folks do something special for armel.
armhf is the default because we believe it is the dominant use case.
That is, we think there are more armv7 devices than armv6 or below
devices.

Bug#1005200: lintian: prefer-uscan-symlink should to single maintainer packages at most

Package: lintian
Version: 2.114.0
Severity: minor

The relatively new prefer-uscan-symlink tag suggests it's better to rely
on a setting ~/.devscripts instead of using filenamemangle in
debian/watch.

It's not clear why this would be better in any case and the uscan man
page that is referenced doesn't suggest it, but even if it is better for
some general reason, it's not better for packages maintained by multiple
people.

As a general case, correct package updating should not depend on
non-default local setups.  Doing apt source, changing into the package
directory, and running uscan should work.  I think it would probably be
best to remove this tag entirely.

If there is a sufficient rationale to keep it, that should be added to
the tag description so developers can understand why.

In any case, suggest you skip this check for packages that have an uploaders
field in debian/control.  Making a change to address this tag is sure to
cause confusion for team maintained packages.

Scott K

Bug#990279: Status?

2022-02-08 Thread Timothy Pearson




- Original Message -
> From: "Salvatore Bonaccorso" 
> To: "Timothy Pearson" , "990279" 
> <990...@bugs.debian.org>
> Cc: "Christian König" , "Xi Ruoyao" 
> , "Alex Deucher"
> 
> Sent: Tuesday, February 8, 2022 3:16:32 PM
> Subject: Re: Bug#990279: Status?

> Hi Timothy,
> 
> On Tue, Feb 08, 2022 at 01:23:10PM -0600, Timothy Pearson wrote:
>> I can confirm Bullseye is still affected by this bug.
>> 
>> Is there any chance of this fix being applied to the Bullseye stable
>> kernels?  We're having to maintain kernel builds in our own
>> repositories to fix this regression, and that introduces some lag
>> when e.g. security updates are pushed to Debian.
> 
> This needs someone to submit a (tested) backport patch to
> stable maintainers, so it can be applied in the 5.10.y stable series.

I can confirm the patch in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990279#47 is what we're using 
and that it does work as intended.

If you need me to generate / submit a patch just let me know.

> Christian, would it be possible to do that? Cf.
> https://bugs.debian.org/990279#42 and
> https://bugs.debian.org/990279#52
> 
> Regards,
> Salvatore

Bug#990279: Status?

2022-02-08 Thread Salvatore Bonaccorso

Hi Timothy,

On Tue, Feb 08, 2022 at 01:23:10PM -0600, Timothy Pearson wrote:
> I can confirm Bullseye is still affected by this bug.
> 
> Is there any chance of this fix being applied to the Bullseye stable
> kernels?  We're having to maintain kernel builds in our own
> repositories to fix this regression, and that introduces some lag
> when e.g. security updates are pushed to Debian.

This needs someone to submit a (tested) backport patch to
stable maintainers, so it can be applied in the 5.10.y stable series.

Christian, would it be possible to do that? Cf.
https://bugs.debian.org/990279#42 and
https://bugs.debian.org/990279#52

Regards,
Salvatore

Bug#992493: remind: please update to latest version

2022-02-08 Thread Ana Guerrero Lopez

Hi Jochen,

On Tue, Feb 08, 2022 at 09:56:34PM +0100, Jochen Sprickerhof wrote:
> Hi Ana,
> 
> * Ana Guerrero Lopez  [2021-08-19 13:32]:
> > On Thu, Aug 19, 2021 at 12:37:30PM +0200, Wolfgang Kroener wrote:
> > > Package: remind
> > > Version: 03.03.01-1
> > > Severity: wishlist
> > > 
> > > Hello everyone,
> > > 
> > > please update remind. The latest version is at the moment 3.3.7.
> > > The changelog is at
> > > https://git.skoll.ca/Skollsoft-Public/Remind/src/branch/master/docs/WHATSNEW
> > > Thank you.
> > 
> > Thanks, this has been blocked for long time due to the freeze.
> > Will take care after the summer holidays!
> 
> Did you find time to look into this already?
> 
> I'm maintaining a number of remind related tools upstream and in Debian
> (wyrd) and would be happy to help maintain Remind. Would you be ok if I add
> myself as an uploader?

Thanks for your offer, I'm happy to have you as a co-maintainer. The
pandemy has stolen all my free time :(

Ana

Bug#992493: remind: please update to latest version

2022-02-08 Thread Jochen Sprickerhof


Hi Ana,

* Ana Guerrero Lopez  [2021-08-19 13:32]:

On Thu, Aug 19, 2021 at 12:37:30PM +0200, Wolfgang Kroener wrote:

Package: remind
Version: 03.03.01-1
Severity: wishlist

Hello everyone,

please update remind. The latest version is at the moment 3.3.7.
The changelog is at
https://git.skoll.ca/Skollsoft-Public/Remind/src/branch/master/docs/WHATSNEW
Thank you.


Thanks, this has been blocked for long time due to the freeze.
Will take care after the summer holidays!


Did you find time to look into this already?

I'm maintaining a number of remind related tools upstream and in Debian 
(wyrd) and would be happy to help maintain Remind. Would you be ok if I 
add myself as an uploader?


Cheers Jochen


signature.asc
Description: PGP signature

Bug#1005199: dhomepage: suboptimal error message for non-existent packages

2022-02-08 Thread Jakub Wilk


Package: debian-goodies
Version: 0.87

This is what happens when I ask for a homepage of a package that doesn't 
exist:


  $ dhomepage dkpg
  dkpg has no homepage

This might be technically correct, but not very helpful; it would be 
better if it said that no such package exists.


--
Jakub Wilk

Bug#993920: package rebuilt with fix available

2022-02-08 Thread Antoine Beaupré

I have now deployed a tentative 3.0.1-2+deb11u1 package on this archive:

deb https://db.torproject.org/torproject-admin bullseye main

i'll probably file a request to update the stable version unless someone
object, within a week.

a.

-- 
Advertisers, not governments, are the primary censors of media content 
in the United States today.
- C. Edwin Baker

Bug#1005194: qosmic, build-depends on obsolete package.

2022-02-08 Thread Peter


Hi Peter,

Build dependencies for qosmic have been updated.
I have uploaded the new version to Mentors.
https://mentors.debian.net/package/qosmic/

I assume the usual sponsor is busy.
If you could help with a one-off upload,
that would be much appreciated.


Cheers,
Peter B

Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-02-08 Thread Helmut Grohne

Hi Chris,

On Sun, Jan 23, 2022 at 10:04:34PM +0100, Chris Hofstaedtler wrote:
> I was hoping we could put util-linux' rename into the
> "bsdextrautils" binary package, which has utilities like write, col,
> etc; to avoid putting it into an Essentials: yes package, and to
> avoid a new binary package. However, picking bsdextrautils seems
> ... maybe not ideal if it should Conflict with rename.
> 
> I guess the best thing would be to introduce a new binary package,
> but I am out of ideas on naming it. Open for ideas here.

This paragraph can be vaguely interpreted as an intention to put the
util-linux rename implementation back into some binary package under
some path. Doing so would go a significant way towards what the
submitter of the ctte bug wants.

We've discussed a number of possible ways to put it back (various
packages, various paths, with or without update-alternatives, with or
without Conflicts). From what you said, I understand that:
 * You disagree with putting it in some transitively essential package.
 * You think that Debian should make a choice about the rename API and
   stick to that.
 * You take issue with "rename.ul" as a program name, because it is
   inconsistent with other Linux distributions.
 * You agree on shipping the util-linux rename executable (with
   unspecified filename at this stage) in some Debian binary package in
   principle.

Do you confirm these statements?

Given these, we think that much of the issue can be resolved
cooperatively. To get there we (as ctte) ask you to explain how you
prefer adding the util-linux rename executable as precisely as you see
it at this stage.

In your option,
 * which binary package should contain the util-linux rename?
   - bsdextrautils
   - something else
 * how should it be named?
   - rename
   - rename.ul
   - something else
 * where should it be installed?
   - /usr/bin
   - something else?
 * should it be managed with update-alternatives?
 * should there be a Conflicts or Breaks relation with the perl rename?

If you feel unable to answer any of these, please say so.

Thank you for taking the time to participate in this discussion.

Helmut

Bug#1005198: d/rules also needs updated for PHP 8.1

2022-02-08 Thread Bryce Harrington

Source: php-pecl-http
Version: 4.2.1+php8-2
Severity: normal

4.2.1+php8-2 updated d/control for PHP 8.1, but looks like perhaps
d/rules also needs adjusted to change the default?

  PHP_DEFAULT_VERSION_OVERRIDE := 7.4

s/b:

  PHP_DEFAULT_VERSION_OVERRIDE := 8.1

This may resolve the 'unsatisfiable dependency' migration errors for
php-pecl-http listed at:

  https://qa.debian.org/excuses.php?package=php-pecl-http


-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-91-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_DIE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1005181: dask: autopkgtest regression: dask/bytes/tests/test_http.py:120: Failed

2022-02-08 Thread Diane Trout

On Tue, 2022-02-08 at 11:40 -0300, Emmanuel Arias wrote:
> Source: dask
> Version: 2021.09.1+dfsg-2
> Severity: important
> X-Debbugs-Cc: eam...@yaerobi.com
> 
> Dear Maintainer,
> 
> The last update of fsspec package[0] cause a regression for dask[1].
> That is already fixed in upstream[2].
> 
> Please consider package new upstream release or backport the upstream
> fix.

Thanks for the report.

Sadly I can't update dask to the latest version yet as they added a new
dependency which is still in NEW.

Hopefully the patch will backport.

Diane

Bug#1005197: pcmemtest: please make the build partly reproducible

2022-02-08 Thread Chris Lamb

Source: pcmemtest
Version: 1.5-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
pcmemtest could not be built reproducibly.

This is because the generated ISOs inherit the uid/gid of the build
process, as well as the modification times of (at least) floppy.img

Patch attached that modifies the two Makefiles involved, although this
does not make the ISOs entirely reproducible; there is another part
or parts of the image that elude me right now.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-builds.patch  1969-12-31 16:00:00.0 
-0800
--- b/debian/patches/reproducible-builds.patch  2022-02-08 12:03:57.320136181 
-0800
@@ -0,0 +1,28 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2022-02-08
+
+--- pcmemtest-1.5.orig/build32/Makefile
 pcmemtest-1.5/build32/Makefile
+@@ -125,7 +125,8 @@ esp.img: memtest.efi
+ iso: memtest.mbr floppy.img esp.img
+   @mkdir -p iso/boot
+   cp floppy.img iso/boot/floppy.img
+-  xorrisofs -pad -R -J -volid PCMemTest32 -graft-points -hide-rr-moved 
--grub2-mbr memtest.mbr \
++  find iso -print0 | xargs -0r touch --date="@$(SOURCE_DATE_EPOCH)"
++  xorrisofs -uid 1000 -gid 1000 -pad -R -J -volid PCMemTest32 
-graft-points -hide-rr-moved --grub2-mbr memtest.mbr \
+ -b /boot/floppy.img --efi-boot 
--interval:appended_partition_2:all:: \
+ -part_like_isohybrid -iso_mbr_part_type 0x00 
-append_partition 2 0xef ./esp.img \
+ -o ./memtest.iso /boot=./iso/boot
+--- pcmemtest-1.5.orig/build64/Makefile
 pcmemtest-1.5/build64/Makefile
+@@ -124,7 +124,8 @@ esp.img: memtest.efi
+ memtest.iso: memtest.mbr floppy.img esp.img
+   @mkdir -p iso/boot
+   cp floppy.img iso/boot/floppy.img
+-  xorrisofs -pad -R -J -volid PCMemTest64 -graft-points -hide-rr-moved 
--grub2-mbr memtest.mbr \
++  find iso -print0 | xargs -0r touch --date="@$(SOURCE_DATE_EPOCH)"
++  xorrisofs -uid 1000 -gid 1000 -pad -R -J -volid PCMemTest64 
-graft-points -hide-rr-moved --grub2-mbr memtest.mbr \
+ -b /boot/floppy.img --efi-boot 
--interval:appended_partition_2:all:: \
+ -part_like_isohybrid -iso_mbr_part_type 0x00 
-append_partition 2 0xef ./esp.img \
+ -o ./memtest.iso /boot=./iso/boot
--- a/debian/patches/series 1969-12-31 16:00:00.0 -0800
--- b/debian/patches/series 2022-02-08 11:50:45.010064249 -0800
@@ -0,0 +1 @@
+reproducible-builds.patch

Bug#1005196: calamares-settings-debian: Extend 'Depends:' section to allow for offline installation

2022-02-08 Thread Roland Clobus


Package: calamares-settings-debian
Version: 11.0.5-2
Severity: wishlist

Dear Maintainer,

I've built a GNOME live image using the instructions at:
https://wiki.debian.org/ReproducibleInstalls/LiveImages

When I run the calamares installer in a VM with BIOS and with a 
disconnected network interface, the installation fails because the 
package 'grub-pc' (and its dependencies 'grub-pc-bin' and 
'grub2-common') is not present inside the image.


An alternative testing scenario is to set 'export 
http_proxy=http://localhost:9' (which effectively blocks network 
traffic) before starting calamares.


When the VM is run with an EFI firmware instead, the package 
'grub-efi-amd64' is required instead.


Sidenote: the file bootloader.conf mentions that a choice out of three 
is possible: 'grub', 'sb-shim' and 'systemd-boot'.

https://sources.debian.org/src/calamares-settings-debian/11.0.5-2/calamares/modules/bootloader.conf/
I've not investigated whether a value other than 'grub' would function 
properly.


Additionally the script 'bootloader-config' requires 'cryptsetup' and 
'keyutils'.

https://sources.debian.org/src/calamares-settings-debian/11.0.5-2/scripts/bootloader-config/?hl=17#L17

Unfortunately 'grub-pc' and 'grub-efi-amd64' conflict with each other... 
(for good reasons, but rather awkward for this specific scenario).
When I create a live image with the dependencies explicitly listed, i.e. 
 'grub-common', 'grub2-common', 'ucf' and 'grub-pc-bin' and 
'grub-efi-amd64-bin' and then modify '/usr/sbin/bootloader-config' to 
use the '*-bin' variant instead (and add the other dependencies), I am 
able to finish a completely offline installation.


Please consider to add the mentioned packages as 'Depends' (or at least 
'Recommends'), to ensure that the partitioning will succeed when an 
offline installation is performed, because all required packages will be 
present inside the live image.


With kind regards,
Roland Clobus

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

Kernel: Linux 5.15.0-3-amd64 (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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages calamares-settings-debian depends on:
ii  calamares3.2.50-1
ii  cryptsetup   2:2.4.3-1
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-2
ii  keyutils 1.6.1-2
ii  qml-module-qtquick-window2   5.15.2+dfsg-9
ii  qml-module-qtquick2  5.15.2+dfsg-9

calamares-settings-debian recommends no packages.

calamares-settings-debian suggests no packages.

-- no debconf information


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005195: llvm-13-dev: typos in headers get compiled into other binaries

2022-02-08 Thread Andreas Beckmann

Package: llvm-13-dev
Version: 1:13.0.1-2
Severity: minor

Hi,

/usr/include/llvm-13/llvm/ADT/IntrusiveRefCntPtr.h contains a typo in a
string literal: 'occured' (should be 'occurred') (2 occurrences) that
may get compiled into other applications and make lintian flag the typo
there.

/usr/include/llvm-13/llvm/ADT/IntrusiveRefCntPtr.h:82:   "Destruction 
occured when there are still references to this.");
/usr/include/llvm-13/llvm/ADT/IntrusiveRefCntPtr.h:113:   "Destruction 
occured when there are still references to this.");

I've seen that in libopencl-clang.so.13


Andreas

Bug#952815: grub2: Please drop TARGET_CCASFLAGS from debian/rules for 2.06 release

2022-02-08 Thread John Paul Adrian Glaubitz

Hi Colin!

On 3/1/20 19:48, Colin Watson wrote:
> On Sat, Feb 29, 2020 at 07:42:16PM +0100, John Paul Adrian Glaubitz wrote:
>> The upcoming 2.06 release contains a fix to set -no-PIE in TARGET_CCASFLAGS 
>> [1]
>> such that the current workaround in debian/rules will no longer be necessary.
>>
>> The following patch should be applied to debian/rules once 2.06-1 is uploaded
>> to the archive:
> 
> Ack; thanks for letting us know.

Just a reminder that this patch can be applied now and the extra 
TARGET_CCASFLAGS
for sparc64 can be dropped. I have verified that grub2 still builds and boots 
fine
on sparc64 with the TARGET_CCASFLAGS setting removed.

So, please apply this patch for the next upload:

--- debian/rules.orig   2019-12-16 16:48:45.0 +0100
+++ debian/rules2020-02-29 19:40:17.759252139 +0100
@@ -23,10 +23,6 @@
 export TARGET_CPPFLAGS := -Wno-unused-but-set-variable
 export TARGET_LDFLAGS := -no-pie
 
-ifneq (,$(filter sparc sparc64,$(DEB_HOST_ARCH_CPU)))
-export TARGET_CCASFLAGS := -fno-PIE
-endif
-
 # Ensure that debhelper doesn't try to set these; we need to be careful
 # about HOST_* vs. TARGET_*.
 export CPPFLAGS :=

Thanks,
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#1005170: xserver-xorg-video-nouveau: corrupted display on GT218 [GeForce 210] since Firefox 91 ESR

2022-02-08 Thread Timo Aaltonen


Martin-Éric Racine kirjoitti 8.2.2022 klo 18.59:

On Tue, Feb 8, 2022 at 4:02 PM Martin-Éric Racine
 wrote:


On Tue, Feb 8, 2022 at 3:54 PM Timo Aaltonen  wrote:


Martin-Éric Racine kirjoitti 8.2.2022 klo 14.09:
  > Package: xserver-xorg-video-nouveau
  > Version: 1:1.0.17-1
  > Severity: important
  >

Since ESR 91 replaced ESR 78 in Stable, Firefox randomly triggers nasty bugs in 
nouveau. The content in Firefox gets randomly garbled for several minutes then 
suddenly gets cleaned up. This is highly problematic, since I use the browser 
to access government sites and having to close Firefox and logon again seldom 
is an option.

dmesg shows the following:

[133514.948849] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1510 data 
[133613.222007] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
[133624.336810] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
[133635.477428] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
[133700.776172] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
[133716.072659] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
[133716.355210] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355219] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 12e4 data 
[133716.355232] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355236] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1360 data 
[133716.355247] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355250] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 19c4 data 
[133716.355264] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355267] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1a00 data 
[133716.355279] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355283] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 12e8 data 
[133716.355296] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355299] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 12cc data 
[133716.355312] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355315] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 19bc data 
[133716.355328] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355332] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1380 data 
[133716.355360] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355363] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1594 data 
[133716.355380] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355384] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 12ec data 
[133716.355400] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355403] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 12d4 data 1d01
[133716.355419] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355422] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1688 data 
[133716.355438] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355442] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1534 data 
[133716.355458] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355461] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 13b0 data 
[133716.355477] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355481] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1570 data 
[133716.355498] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355502] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 166c data 
[133716.355518] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355521] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1518 data 
[133716.355537] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355540] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1520 data 
[133716.37] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355560] nouveau :01:00.0: gr: 0010

Bug#1005192: Libinput properties set but have no effect

2022-02-08 Thread Michael Biebl


Am 08.02.22 um 20:26 schrieb Camaleón:

Package: udev
Version: 232-25
Severity: normal

Running Debian 9, XFCE and quite simple mouse device (Microsoft Ready
Mouse, wired, optical, 3 buttons).

I'm trying to speed up my mouse wheel scroll event (now goes up/down by
3 lines). As there's no option to setup the scrolling speed under XFCE
mouse properties, I tried by the hard way:

1. Device detection:

sm01@stt008:~$ grep -i mouse /var/log/Xorg.0.log
[19.297] (==) NOUVEAU(G0): Silken mouse enabled
[19.300] (==) NOUVEAU(0): Silken mouse enabled
[22.569] (II) config/udev: Adding input device ImPS/2 Generic Wheel Mouse 
(/dev/input/event13)
[22.569] (**) ImPS/2 Generic Wheel Mouse: Applying InputClass "libinput pointer 
catchall"
[22.569] (II) Using input driver 'libinput' for 'ImPS/2 Generic Wheel Mouse'
[22.569] (**) ImPS/2 Generic Wheel Mouse: always reports core events
[22.569] (II) input device 'ImPS/2 Generic Wheel Mouse', /dev/input/event13 
is tagged by udev as: Mouse
[22.569] (II) input device 'ImPS/2 Generic Wheel Mouse', /dev/input/event13 
is a pointer caps
[22.600] (II) XINPUT: Adding extended input device "ImPS/2 Generic Wheel 
Mouse" (type: MOUSE, id 9)
[22.600] (**) ImPS/2 Generic Wheel Mouse: (accel) selected scheme none/0
[22.600] (**) ImPS/2 Generic Wheel Mouse: (accel) acceleration factor: 2.000
[22.600] (**) ImPS/2 Generic Wheel Mouse: (accel) acceleration threshold: 4
[22.600] (II) input device 'ImPS/2 Generic Wheel Mouse', /dev/input/event13 
is tagged by udev as: Mouse
[22.600] (II) input device 'ImPS/2 Generic Wheel Mouse', /dev/input/event13 
is a pointer caps
[22.601] (II) config/udev: Adding input device ImPS/2 Generic Wheel Mouse 
(/dev/input/mouse0)

2. I created «/etc/udev/hwdb.d/71-mouse-local.hwdb» file with the
folowing content:

# ImPS/2 Generic Wheel Mouse
mouse:ps2:*:name:ImPS/2 Generic Wheel Mouse:
  MOUSE_WHEEL_CLICK_ANGLE=60

3. Updated udev's database by running:

udevadm hwdb --update

4. Forced udev setup update with:

udevadm trigger /dev/input/event13

5. And finally checked the propertie was already applied with:

root@stt008:/etc/udev/hwdb.d# udevadm info /sys/class/input/event13
P: /devices/platform/i8042/serio1/input/input4/event13
N: input/event13
E: DEVNAME=/dev/input/event13
E: DEVPATH=/devices/platform/i8042/serio1/input/input4/event13
E: ID_BUS=i8042
E: ID_INPUT=1
E: ID_INPUT_MOUSE=1
E: LIBINPUT_DEVICE_GROUP=11/2/5/0:isa0060/serio1
E: MAJOR=13
E: MINOR=77
E: MOUSE_WHEEL_CLICK_ANGLE=60 <- here it is
E: SUBSYSTEM=input
E: USEC_INITIALIZED=9662442

But wheel srolling speed remains the same, I see no changes at all.

Cheers,




You are setting the properties via udev (which apparently worked).
What X/Wayland/libinput does with that is out of udev's control.

Thus closing this bug report against udev as I don't see anything 
actionable in udev here.


Regards,
Michael




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005045: partd: pickle save+load data loss on ppc64el and s390x

2022-02-08 Thread Diane Trout

I forwarded your report to upstream and asked them for their advice
about what to do.

I also wonder if a slight pause might help? or if partd needs some
synchronization code.

Diane

Bug#1005194: qosmic, build-depends on obsolete package.

2022-02-08 Thread peter green


Package: qosmic
Version: 1.6.0-4
Severity: serious
Tags: bookworm, sid

qosmic build-depends on the flam3 binary package which is no longer built by 
the flam3 source package.
The flam3 source package appears to have split different parts into different 
binary packages, please
assess which ones qosmic requires and update your build-dependencies 
accordingly.

Bug#993920: Migration of guests fails on drbd with kvm

2022-02-08 Thread Antoine Beaupre

Package: ganeti
Version: 3.0.1-2
Followup-For: Bug #993920

Hi,

I'd like to prepare a stable update for this, any objections?

I'll build a local package with the patch, in any case, for testing in
our prod environment...

a.


-- System Information:
Debian Release: 11.2
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 ganeti depends on:
ii  adduser  3.118
pn  ganeti-3.0   
pn  ganeti-haskell-3.0   
pn  ganeti-htools-3.0
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  python3  3.9.2-3

Versions of packages ganeti recommends:
pn  drbd-utils | drbd8-utils 
ii  fdisk2.36.1-8+deb11u1
pn  ganeti-instance-debootstrap  
ii  ndisc6   1.0.4-2
ii  qemu-system-x86 [qemu-kvm]   1:5.2+dfsg-11+deb11u1

Versions of packages ganeti suggests:
pn  blktap-dkms  
pn  ganeti-doc   
pn  molly-guard

Bug#1005193: libc6: please split away gconv files

2022-02-08 Thread Adam Borowski

Package: libc6
Version: 2.34-0experimental2
Severity: wishlist

Hi!
The bulk of libc6 package consists of gconv files for obsolete locales.
This costs us 8.2MB per arch, even for minimal containers.

Fedora has done so, then lowered the dependency to Recommends last year:
  https://www.fedoraproject.org/wiki/Changes/Gconv_package_split_in_glibc
They've decided to keep a handful of often used old locales, which is
probably reasonable.

Obviously, such a change would require adding dependencies on the split
out gconv from packages that actually need to handle such locales, and
that's non-trivial work -- but, any such work would require the extra
package to actually exist.

Thus: could you please move the gconv files to a new package; with a
hard dependency from libc6 for now?


Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.17.0-rc3-00017-g9f7865599562 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libc6 depends on:
ii  libgcc-s1  12-20220206-1

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.2-2

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.79
ii  glibc-doc  2.33-5
ii  libc-l10n  2.34-0experimental2
pn  libnss-nis 
pn  libnss-nisplus 
ii  locales2.34-0experimental2

-- debconf information excluded

Bug#990279: Status?

2022-02-08 Thread Timothy Pearson

I can confirm Bullseye is still affected by this bug.

Is there any chance of this fix being applied to the Bullseye stable kernels?  
We're having to maintain kernel builds in our own repositories to fix this 
regression, and that introduces some lag when e.g. security updates are pushed 
to Debian.

Bug#1005192: Libinput properties set but have no effect

2022-02-08 Thread Camaleón

Package: udev
Version: 232-25
Severity: normal

Running Debian 9, XFCE and quite simple mouse device (Microsoft Ready 
Mouse, wired, optical, 3 buttons).

I'm trying to speed up my mouse wheel scroll event (now goes up/down by 
3 lines). As there's no option to setup the scrolling speed under XFCE 
mouse properties, I tried by the hard way:

1. Device detection:

sm01@stt008:~$ grep -i mouse /var/log/Xorg.0.log
[19.297] (==) NOUVEAU(G0): Silken mouse enabled
[19.300] (==) NOUVEAU(0): Silken mouse enabled
[22.569] (II) config/udev: Adding input device ImPS/2 Generic Wheel Mouse 
(/dev/input/event13)
[22.569] (**) ImPS/2 Generic Wheel Mouse: Applying InputClass "libinput 
pointer catchall"
[22.569] (II) Using input driver 'libinput' for 'ImPS/2 Generic Wheel Mouse'
[22.569] (**) ImPS/2 Generic Wheel Mouse: always reports core events
[22.569] (II) input device 'ImPS/2 Generic Wheel Mouse', /dev/input/event13 
is tagged by udev as: Mouse
[22.569] (II) input device 'ImPS/2 Generic Wheel Mouse', /dev/input/event13 
is a pointer caps
[22.600] (II) XINPUT: Adding extended input device "ImPS/2 Generic Wheel 
Mouse" (type: MOUSE, id 9)
[22.600] (**) ImPS/2 Generic Wheel Mouse: (accel) selected scheme none/0
[22.600] (**) ImPS/2 Generic Wheel Mouse: (accel) acceleration factor: 2.000
[22.600] (**) ImPS/2 Generic Wheel Mouse: (accel) acceleration threshold: 4
[22.600] (II) input device 'ImPS/2 Generic Wheel Mouse', /dev/input/event13 
is tagged by udev as: Mouse
[22.600] (II) input device 'ImPS/2 Generic Wheel Mouse', /dev/input/event13 
is a pointer caps
[22.601] (II) config/udev: Adding input device ImPS/2 Generic Wheel Mouse 
(/dev/input/mouse0)

2. I created «/etc/udev/hwdb.d/71-mouse-local.hwdb» file with the 
folowing content:

# ImPS/2 Generic Wheel Mouse
mouse:ps2:*:name:ImPS/2 Generic Wheel Mouse:
 MOUSE_WHEEL_CLICK_ANGLE=60

3. Updated udev's database by running:

udevadm hwdb --update

4. Forced udev setup update with:

udevadm trigger /dev/input/event13

5. And finally checked the propertie was already applied with:

root@stt008:/etc/udev/hwdb.d# udevadm info /sys/class/input/event13
P: /devices/platform/i8042/serio1/input/input4/event13
N: input/event13
E: DEVNAME=/dev/input/event13
E: DEVPATH=/devices/platform/i8042/serio1/input/input4/event13
E: ID_BUS=i8042
E: ID_INPUT=1
E: ID_INPUT_MOUSE=1
E: LIBINPUT_DEVICE_GROUP=11/2/5/0:isa0060/serio1
E: MAJOR=13
E: MINOR=77
E: MOUSE_WHEEL_CLICK_ANGLE=60 <- here it is
E: SUBSYSTEM=input
E: USEC_INITIALIZED=9662442

But wheel srolling speed remains the same, I see no changes at all.

Cheers,

-- 
Camaleón

Bug#973581: apt: Occasional pipelined requests failing against localhost nginx mirror

2022-02-08 Thread Jesse Hathaway

On Sun, 1 Nov 2020 20:55:36 -0800 Stefano Rivera  wrote:
> Recently I noticed repeated sbuild failures during package installation,
> due to connection resets. Can't reproduce with apt 2.1.8 but can with
> >= 2.1.9, so presumably the regression is due to
> fa375493c5a4ed9c10d4e5257ac82c6e687862d3 disabling retries.

I hit this bug as well with our debian mirror, mirrors.wikimedia.org.
We also use nginx to serve our mirror and bullseye clients frequently
receive resets while pulling down packages. I tested reverting commit,
fa375493c5a4ed9c10d4e5257ac82c6e687862d3, and it does indeed stop the
connection resets. I also tested against apache2, but I was unable to
reproduce the issue, so it seems to be nginx specific. I am happy to provide
pcaps as well.

Here is the script I used to reproduce:

  #!/bin/bash

  set -o errexit

  if [[ $EUID -ne 0 ]]; then
printf 'MUST BE ROOT\n' >&2
exit 1
  fi

  sed -i 's/deb.debian.org/mirrors.wikimedia.org/' /etc/apt/sources.list
  apt-get update
  while true; do
apt-get clean
declare -a install_opts=(--yes --download-only --no-install-recommends)
declare -a install_pkgs=(firefox-esr chromium)
if ! apt-get install "${install_opts[@]}" "${install_pkgs[@]}"; then
  printf 'ERROR: We caught a fish!\n' >&2
  tput bel
  exit 1
fi
  done

Here is how I built apt to test the revert:

  #!/bin/bash
  set -o errexit

  echo 'deb-src http://deb.debian.org/debian bullseye main'
>>/etc/apt/sources.list
  apt-get update
  apt-get install --yes git build-essential
  apt-get build-dep --yes apt
  git clone https://salsa.debian.org/apt-team/apt.git
  git config --global user.email "jhatha...@wikimedia.org"
  git config --global user.name "Jesse Hathaway"
  pushd apt
  git checkout 2.2.4
  git checkout -b butter
  git revert --no-edit fa375493c5a4ed9c10d4e5257ac82c6e687862d3
  dpkg-buildpackage -jauto -us -nc -b
  popd
  dpkg -i -- *.deb

I tested with buildah and this Dockerfile:

  FROM docker.io/debian:bullseye
  ENV LANG C.UTF-8
  COPY build /root/
  COPY resets /root/

Bug#1005191: ddcutil: requires undocumented manual setup to make it usable

2022-02-08 Thread Samuel Henrique

Package: ddcutil
X-Debbugs-Cc: samuel...@debian.org
Version: 1.2.1-1
Severity: normal

Hello Sanford, thank you for working on ddcutil :)

I wanted to report on a few manual steps I had to take to make ddcutil
usable for me (I'm using it through gnome-display-brightness-ddcutil).

I would like to see the ddcutil package automate this setup, or at
least ask the user if they want this to be done (if there are any
security concerns). Alternatively there could also be better messaging
on what's needed so we don't risk leaving users in the dark about it.

First I had to load the kernel module for i2c-dev:
# echo "i2c-dev" /etc/modules-load.d/i2c-dev.conf

Then I had to copy the udev rule:
# cp /usr/share/ddcutil/data/45-ddcutil-i2c.rules /etc/udev/rules.d

So to summarize, anything that could be done to help users on these
two steps would be awesome.

Also, if by any chance you're looking for help, I would be happy to
sponsor your uploads, and/or co-maintain the package and move it to
salsa.

Thanks,

-- 
Samuel Henrique

Bug#1005190: gbp dch: add trailing dot when updating changelog?

2022-02-08 Thread Jelmer Vernooij

Package: git-buildpackage
Version: 0.9.25
Severity: wishlist

Hi Guido!

"gbp dch" generates entries for debian/changelog based on Git commit messages.

Best practice in Git is that the first line of a Git commit message is email
subject-style, i.e. without a trailing dot.

(see https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project)

However, the overwhelming practice in Debian (albeit not required or explicitly
recommended by policy) is to use full dots at the end of each item in the
changelog.

(see
https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog
for the part of policy that covers the changelog)

This makes it hard to stick to the convention in both systems while using gbp 
dch;
using commit messages without a trailing dot (per Git convention) means having
to add trailing dots in debian/changelog afterwards.

Would you consider having "gbp dch" add trailing dots in changelog messages if
they're missing?

(background: discussion in 
https://salsa.debian.org/jelmer/debian-janitor/-/issues/248;
the janitor attempts to accomodate "gbp dch" users but ends up violating
Git convention for commit messages by doing so)

Jelmer

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

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

Versions of packages git-buildpackage depends on:
ii  devscripts 2.22.1
ii  git1:2.34.1-1
ii  man-db 2.10.0-2
ii  python33.9.8-1
ii  python3-dateutil   2.8.1-6
ii  python3-pkg-resources  59.6.0-1.2
ii  sensible-utils 0.0.17

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.89
ii  pbuilder  0.231
ii  pristine-tar  1.49
ii  python3-requests  2.25.1+dfsg-2

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.9.9-1
ii  unzip6.0-26

-- debconf-show failed

Bug#1005139: man-db: [INTL:zh_CN] Please include an important Simplified Chinese translation fix

2022-02-08 Thread Colin Watson

Control: tag -1 fixed-upstream

On Mon, Feb 07, 2022 at 02:47:26PM -0500, Boyuan Yang wrote:
> Recently I was notified that an important man-db-manpages zh_CN translation
> error exists in man-db source code, including the latest man-db/2.10. The
> string is at ../../man/man1/man.man1:168, where "cannot be used together" was
> written as "can be used together" in zh_CN translation.
> 
> While I have just submitted the fix via TranslationProject (
> https://translationproject.org/domain/man-db-manpages.html ), I am also
> looking forward to having the patch available to broader audience, especially
> users of the upcoming Ubuntu 22.04 LTS. To achieve this goal, I am looking
> into having the patch applied to Debian's package. Please consider applying
> the attached PO file in the next Debian upload, and ideally before Ubuntu's
> Debian import freeze (Feb 24, 2022). The updated PO file can also be found at
> https://translationproject.org/PO-files/zh_CN/man-db-manpages-2.10.0-pre1.zh_CN.po
> , or as received as man-db upstream.

Thanks for the note about the urgency.  As it happens, I'm intending to
make a new upstream release in the next couple of days (and comfortably
in time for Ubuntu's Debian import freeze) for other reasons anyway, so
I'll include that there rather than making a separate Debian patch
upload.

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

Bug#1005189: gcolor3: FTBFS libportal/portal-gtk3.h: No such file or directory

2022-02-08 Thread Andreas Beckmann

Source: gcolor3
Version: 2.4.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

gcolor3/experimental recently started to FTBFS after some of its build
dependencies got upgraded:

[35/42] cc -Isrc/gcolor3.p -Isrc -I../src -Idata -I../data -I. -I.. 
-I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 
-I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include 
-I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 
-I/usr/include/harfbuzz -I/usr/include/fribidi -I/usr/include/atk-1.0 
-I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 
-I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 
-I/usr/include/x86_64-linux-gnu -I/usr/include/libmount -I/usr/include/blkid 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -g -O2 
-ffile-prefix-map=/build/gcolor3-2.4.0=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pthread -MD -MQ 
src/gcolor3.p/gcolor3-color-selection.c.o -MF 
src/gcolor3.p/gcolor3-color-selection.c.o.d -o 
src/gcolor3.p/gcolor3-color-selection.c.o -c ../src/gcolor3-color-selection.c
FAILED: src/gcolor3.p/gcolor3-color-selection.c.o 
cc -Isrc/gcolor3.p -Isrc -I../src -Idata -I../data -I. -I.. 
-I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 
-I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include 
-I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 
-I/usr/include/harfbuzz -I/usr/include/fribidi -I/usr/include/atk-1.0 
-I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 
-I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 
-I/usr/include/x86_64-linux-gnu -I/usr/include/libmount -I/usr/include/blkid 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -g -O2 
-ffile-prefix-map=/build/gcolor3-2.4.0=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pthread -MD -MQ 
src/gcolor3.p/gcolor3-color-selection.c.o -MF 
src/gcolor3.p/gcolor3-color-selection.c.o.d -o 
src/gcolor3.p/gcolor3-color-selection.c.o -c ../src/gcolor3-color-selection.c
../src/gcolor3-color-selection.c:44:10: fatal error: libportal/portal-gtk3.h: 
No such file or directory
   44 | #include 
  |  ^
compilation terminated.

The package in sid is not affected.


Andreas


gcolor3_2.4.0-1.log.gz
Description: application/gzip

Bug#1005188: Please package newer upstream

2022-02-08 Thread Julien Puydt

Package: libjs-mathjax
Version: 2.7.9+dfsg-1
Severity: wishlist

I see upstream released 3.20 and I have a package with privacy breaches
because it looks outside for mathjax files which are not in the current
version: can you update the package to a newer version?

Thanks,

J.Puydt

Bug#1000980: kubernetes: Please upgrade to golang-1.17

2022-02-08 Thread Janos LENART

I'll get on this. Thanks.

On Tue, 8 Feb 2022 at 17:51, Scott Kitterman  wrote:

> On Thu, 02 Dec 2021 12:29:37 +0800 Shengjing Zhu  wrote:
> > Source: kubernetes
> > Version: 1.20.5+really1.20.2-1
> > Severity: important
> > X-Debbugs-Cc: z...@debian.org
> > Control: block 998747 by -1
> >
> > Dear Maintainer,
> >
> > As part of the effort to limit the number of Go compiler in the
> > archive, please upgrade to golang-1.17.
>
> golang-1.15 is gone now, so bumped to serious.
>
> Scott K



-- 
LÉNÁRT, János

Bug#1000980: kubernetes: Please upgrade to golang-1.17

On Thu, 02 Dec 2021 12:29:37 +0800 Shengjing Zhu  wrote:
> Source: kubernetes
> Version: 1.20.5+really1.20.2-1
> Severity: important
> X-Debbugs-Cc: z...@debian.org
> Control: block 998747 by -1
> 
> Dear Maintainer,
> 
> As part of the effort to limit the number of Go compiler in the
> archive, please upgrade to golang-1.17.

golang-1.15 is gone now, so bumped to serious.

Scott K

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

Bug#1005120: wpewebkit: Fails to build with gstreamer 1.20

2022-02-08 Thread Sebastian Dröge

On Tue, 2022-02-08 at 18:10 +0100, Alberto Garcia wrote:
> On Mon, Feb 07, 2022 at 10:53:56AM -0500, Jeremy Bicha wrote:
> > wpewebkit fails to build from source, apparently because of the recent
> > gstreamer 1.20 uploads.
> > 
> > -- Checking for module 'gstreamer-codecparsers-1.0 >= 1.14.0'
> > --   No package 'gstreamer-codecparsers-1.0' found
> > 
> > That .pc file is provided by libgstreamer-plugins-bad1.0-dev so
> > maybe you just need to Build-Depend on that.
> 
> As far as I'm aware gstreamer-codecparsers-1.0 is not needed in the
> default build, the problem that I'm seeing here is this one:
> 
>    CMake Error at Source/cmake/GStreamerChecks.cmake:50 (message):
>   GStreamerGL is needed for USE_GSTREAMER_GL.
> 
> GStreamerGL is however installed. The reason why this fails is this
> one:
> 
>    # pkg-config --cflags gstreamer-gl-1.0
>    Package gudev-1.0 was not found in the pkg-config search path.
>    Perhaps you should add the directory containing `gudev-1.0.pc'
> 
> So I understand that libgstreamer-plugins-base1.0-dev would need to
> depend on libgudev-1.0-dev, right Sebastian?

Indeed, needs a libgudev-1.0-dev (>= 147) [linux-any] . I've added gbm
and all the other new ones but apparently missed that one.

I'll upload a new version later or tomorrow morning.


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

Bug#1005187: collectd build-depends on package that is not in testing.

2022-02-08 Thread peter green


Package: collectd
Version: 5.12.0-8
Severity: serious
Justification: rc policy: "packages must be buildable within the same release"

collectd build-depends on liboping-dev, which is rc buggy and was removed from
testing recently in an attempt to finish off the perl transition. This makes
collectd rc buggy in testing.

Potential soloutions (in descending order of preference)

1. Fix liboping, it seems there is a patch available but there has been no
   maintainer response for months and I won't NMU myself because I have no
   idea how to test it.
2. Disable liboping support in collectd (the fact that the runtime
   relationship is only a reccomends makes me suspect that this relates
   to optional functionality).

Bug#964504: anacron: Errors in man pages

2022-02-08 Thread Helge Kreutzmann

Package: anacron
Severity: wishlist
Tags: patch l10n

** This is an updated report, including all previously reported issues ***

Dear anacron maintainer,
the manpage-l10n project maintains a large number of translations of
man pages both from a large variety of sources (including anacron) as
well for a large variety of target languages.

During their work translators notice different possible issues in the
original (english) man pages. Sometimes this is a straightforward
typo, sometimes a hard to read sentence, sometimes this is a
convention not held up and sometimes we simply do not understand the
original.

We use several distributions as sources and update regularly (at
least every 2 month). This means we are fairly recent (some
distributions like archlinux also update frequently) but might miss
the latest upstream version once in a while, so the error might be
already fixed. We apologize and ask you to close the issue immediately
if this should be the case, but given the huge volume of projects and
the very limited number of volunteers we are not able to double check
each and every issue.

Secondly we translators see the manpages in the neutral po format,
i.e. converted and harmonized, but not the original source (be it man,
groff, xml or other). So we cannot provide a true patch (where
possible), but only an approximation which you need to convert into
your source format.

Finally the issues I'm reporting have accumulated over time and are
not always discovered by me, so sometimes my description of the
problem my be a bit limited - do not hesitate to ask so we can clarify
them.

I'm now reporting the errors for your project. If future reports
should use another channel, please let me know.

Man page: anacron.8
Issue:B → B(8)

"B is used to execute commands periodically, with a frequency "
"specified in days. Unlike B, it does not assume that the machine "
"is running continuously. Hence, it can be used on machines that are not "
"running 24 hours a day to control regular jobs as daily, weekly, and monthly "
"jobs."
--
Man page: anacron.8
Issue:under with → with

"Any informative messages generated by Anacron are sent to B(8) or "
"B(8) under with facility set to B and priority set to "
"B. Any error messages are sent with the priority B."
--
Man page: anacron.8
Issue:FIXME TZ → B

"Make sure your time-zone is set correctly before Anacron is started since "
"the time-zone affects the date. This is usually accomplished by setting the "
"TZ environment variable, or by installing a I "
"file. See B(3) for more information."
--
Man page: anacron.8
Issue:B → B(8)

"Anacron can be used to execute commands periodically, with a frequency "
"specified in days. Unlike B, it does not assume that the machine "
"is running continuously. Hence, it can be used on machines that aren't "
"running 24 hours a day, to control daily, weekly, and monthly jobs that are "
"usually controlled by B."
--
Man page: anacron.8
Issue:B → B(5)

"When executed, Anacron reads a list of jobs from a configuration file, "
"normally I (see B). This file contains the "
"list of jobs that Anacron controls. Each job entry specifies a period in "
"days, a delay in minutes, a unique job identifier, and a shell command."
--
Man page: anacron.8
Issue:Closing period is missing

"Use specified anacrontab, rather than the default"
--
Man page: anacron.8
Issue 1: TZ → B
Issue 2: B → B(3)

"Make sure that the time-zone is set correctly before Anacron is started. "
"(The time-zone affects the date). This is usually accomplished by setting "
"the TZ environment variable, or by installing a I file. See B for more information."
--
Man page: anacron.8
Issue:The hourly → the hourly

"By default, The hourly activation of anacron will not take place when the "
"system is using battery and no AC power is connected to the computer. It is "
"meant to reduce power usage and extend battery life, but such design might "
"lead to unwanted results."
--
Man page: anacron.8
Issue:in now → how

"Users may disable this feature and let anacron run regardless of power "
"supply. Please read Debian-specific documentation in I file for detailed instruction in now to change such "
"behaviour."
--
Man page: anacron.8
Issue:B → B(5)

"Contains specifications of jobs. See B for a complete "
"description."
-
Man page: anacron.8
Issue:B → B(5), B(8),
B(3)

"B"
-
Man page: anacrontab.5
Issue:line containing → lines containing

"Empty lines are either blank lines, line containing white spaces only, or "
"lines with white spaces followed by a '#' followed by an arbitrary comment."
--
Man page: anacrontab.5
Issue:B → B(8)

"The file I describes the jobs controlled by B. "
"Its lines can be of three kinds: job-description lines, environment "
"assignments, or empty lines."
--
Man page: anacrontab.5
Issue:B → B(8)

"B"

--
Dr. Helge Kreutzmann deb...@helgefjell.de

Bug#1005120: wpewebkit: Fails to build with gstreamer 1.20

2022-02-08 Thread Alberto Garcia

On Mon, Feb 07, 2022 at 10:53:56AM -0500, Jeremy Bicha wrote:
> wpewebkit fails to build from source, apparently because of the recent
> gstreamer 1.20 uploads.
> 
> -- Checking for module 'gstreamer-codecparsers-1.0 >= 1.14.0'
> --   No package 'gstreamer-codecparsers-1.0' found
> 
> That .pc file is provided by libgstreamer-plugins-bad1.0-dev so
> maybe you just need to Build-Depend on that.

As far as I'm aware gstreamer-codecparsers-1.0 is not needed in the
default build, the problem that I'm seeing here is this one:

   CMake Error at Source/cmake/GStreamerChecks.cmake:50 (message):
  GStreamerGL is needed for USE_GSTREAMER_GL.

GStreamerGL is however installed. The reason why this fails is this
one:

   # pkg-config --cflags gstreamer-gl-1.0
   Package gudev-1.0 was not found in the pkg-config search path.
   Perhaps you should add the directory containing `gudev-1.0.pc'

So I understand that libgstreamer-plugins-base1.0-dev would need to
depend on libgudev-1.0-dev, right Sebastian?

Berto

Bug#1005170: xserver-xorg-video-nouveau: corrupted display on GT218 [GeForce 210] since Firefox 91 ESR

2022-02-08 Thread Martin-Éric Racine

On Tue, Feb 8, 2022 at 4:02 PM Martin-Éric Racine
 wrote:
>
> On Tue, Feb 8, 2022 at 3:54 PM Timo Aaltonen  wrote:
> >
> > Martin-Éric Racine kirjoitti 8.2.2022 klo 14.09:
> >  > Package: xserver-xorg-video-nouveau
> >  > Version: 1:1.0.17-1
> >  > Severity: important
> >  >
> > > Since ESR 91 replaced ESR 78 in Stable, Firefox randomly triggers nasty 
> > > bugs in nouveau. The content in Firefox gets randomly garbled for several 
> > > minutes then suddenly gets cleaned up. This is highly problematic, since 
> > > I use the browser to access government sites and having to close Firefox 
> > > and logon again seldom is an option.
> > >
> > > dmesg shows the following:
> > >
> > > [133514.948849] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
> > > Xorg[1785]] subc 3 class 8597 mthd 1510 data 
> > > [133613.222007] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
> > > [133624.336810] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
> > > [133635.477428] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
> > > [133700.776172] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
> > > [133716.072659] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
> > > [133716.355210] nouveau :01:00.0: gr: DATA_ERROR 000d 
> > > [BEGIN_END_ACTIVE]
> > > [133716.355219] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
> > > Xorg[1785]] subc 3 class 8597 mthd 12e4 data 
> > > [133716.355232] nouveau :01:00.0: gr: DATA_ERROR 000d 
> > > [BEGIN_END_ACTIVE]
> > > [133716.355236] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
> > > Xorg[1785]] subc 3 class 8597 mthd 1360 data 
> > > [133716.355247] nouveau :01:00.0: gr: DATA_ERROR 000d 
> > > [BEGIN_END_ACTIVE]
> > > [133716.355250] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
> > > Xorg[1785]] subc 3 class 8597 mthd 19c4 data 
> > > [133716.355264] nouveau :01:00.0: gr: DATA_ERROR 000d 
> > > [BEGIN_END_ACTIVE]
> > > [133716.355267] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
> > > Xorg[1785]] subc 3 class 8597 mthd 1a00 data 
> > > [133716.355279] nouveau :01:00.0: gr: DATA_ERROR 000d 
> > > [BEGIN_END_ACTIVE]
> > > [133716.355283] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
> > > Xorg[1785]] subc 3 class 8597 mthd 12e8 data 
> > > [133716.355296] nouveau :01:00.0: gr: DATA_ERROR 000d 
> > > [BEGIN_END_ACTIVE]
> > > [133716.355299] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
> > > Xorg[1785]] subc 3 class 8597 mthd 12cc data 
> > > [133716.355312] nouveau :01:00.0: gr: DATA_ERROR 000d 
> > > [BEGIN_END_ACTIVE]
> > > [133716.355315] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
> > > Xorg[1785]] subc 3 class 8597 mthd 19bc data 
> > > [133716.355328] nouveau :01:00.0: gr: DATA_ERROR 000d 
> > > [BEGIN_END_ACTIVE]
> > > [133716.355332] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
> > > Xorg[1785]] subc 3 class 8597 mthd 1380 data 
> > > [133716.355360] nouveau :01:00.0: gr: DATA_ERROR 000d 
> > > [BEGIN_END_ACTIVE]
> > > [133716.355363] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
> > > Xorg[1785]] subc 3 class 8597 mthd 1594 data 
> > > [133716.355380] nouveau :01:00.0: gr: DATA_ERROR 000d 
> > > [BEGIN_END_ACTIVE]
> > > [133716.355384] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
> > > Xorg[1785]] subc 3 class 8597 mthd 12ec data 
> > > [133716.355400] nouveau :01:00.0: gr: DATA_ERROR 000d 
> > > [BEGIN_END_ACTIVE]
> > > [133716.355403] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
> > > Xorg[1785]] subc 3 class 8597 mthd 12d4 data 1d01
> > > [133716.355419] nouveau :01:00.0: gr: DATA_ERROR 000d 
> > > [BEGIN_END_ACTIVE]
> > > [133716.355422] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
> > > Xorg[1785]] subc 3 class 8597 mthd 1688 data 
> > > [133716.355438] nouveau :01:00.0: gr: DATA_ERROR 000d 
> > > [BEGIN_END_ACTIVE]
> > > [133716.355442] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
> > > Xorg[1785]] subc 3 class 8597 mthd 1534 data 
> > > [133716.355458] nouveau :01:00.0: gr: DATA_ERROR 000d 
> > > [BEGIN_END_ACTIVE]
> > > [133716.355461] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
> > > Xorg[1785]] subc 3 class 8597 mthd 13b0 data 
> > > [133716.355477] nouveau :01:00.0: gr: DATA_ERROR 000d 
> > > [BEGIN_END_ACTIVE]
> > > [133716.355481] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
> > > Xorg[1785]] subc 3 class 8597 mthd 1570 data 
> > > [133716.355498] nouveau :01:00.0: gr: DATA_ERROR 000d 
> > > [BEGIN_END_ACTIVE]
> > > [133716.355502] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
> > > Xorg[1785]] subc 3 class 8597 mthd 166c data 
> > > [133716.355518] nouveau :01:00.0: gr: DATA_ERROR 000d 
> > >

Bug#996048: postfix-mta-sts-resolver: diff for NMU version 1.0.0-4.1

2022-02-08 Thread Benjamin Hof

Hi Adrian,

On Friday, 04 February 2022, 02:24 +0200, Adrian Bunk wrote:
> Control: tags 996048 + patch
> Control: tags 996048 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for postfix-mta-sts-resolver (versioned as 1.0.0-4.1)
> and uploaded it to DELAYED/14. Please feel free to tell me if I should 
> cancel it.

Please cancel it, the specific issue was fixed upstream :) Marc
Dequènes has uploaded the new version in the mean time.

Thanks,
Benjamin

Bug#1005169: regression: Chromium is not using plasma file dialog anymore since overlast update

On Tue, 08 Feb 2022 12:55:39 +0100 Matthias Gies wrote:
> Package: chromium
> Version: 98.0.4758.80-1~deb11u1
> Severity: normal
> X-Debbugs-Cc: matthiasg...@gmail.com
>
> Dear Maintainer,
>
> I chose to use chromium over firefox because it it used the regular 
plasma file
> dialog. Since the second last security update in bullseye, chromium 
suddenly

> uses the gtk/gnome file dialog when downloading files.
>
> I have not changed my system configuration, i don't have any other 
desktop

> environment installed but kde plasma. I have plasma-browser-integration
> installed, but I guess this does not influence the file dialog.
>
> I assume this is a compiling config issue..?

I believe this is an upstream change, as described in 
https://www.reddit.com/r/openSUSE/comments/pjuf27/leap_fix_gtk_file_dialog_in_recent_version_of/.

What version of xdg-desktop-portal do you have installed? What is the 
value of XDG_CURRENT_DESKTOP (open a terminal and run  "echo 
$XDG_CURRENT_DESKTOP")? And if you run 
"dbus-update-activation-environment --systemd XDG_CURRENT_DESKTOP", and 
then restart chromium, does that fix the issue?

Bug#1004814: r-cran-av: FTBFS with ffmpeg 5.0

2022-02-08 Thread Jeroen Ooms

On Tue, Feb 8, 2022 at 6:33 AM Andreas Tille  wrote:
>
> Control: tags -1 upstream
> Control: forwarded -1 Jeroen Ooms 
>
> Hi Jeroen,
>
> Debian will migrate to ffmpeg5.0 soon.  It would be great if you could
> adapt av to the new ffmpeg version.

Thanks. I have now released av version 0.7.0 to CRAN which works with ffmpeg-5.

Bug#1001251: [Pkg-rust-maintainers] Bug#1001251: debcargo changed names of a feature package

2022-02-08 Thread Ximin Luo

Is your issue simply this? https://github.com/rust-lang/cargo/issues/7769

If so please close this bug as invalid, since it is not debcargo's 
responsibility.

X

Daniel Kahn Gillmor:
> Control: affects 1001251 + src:rust-sequoia-openpgp
> 
> On Tue 2021-12-07 03:47:32 +0400, Daniel Kahn Gillmor wrote:
>> note that previously, …+compression-deflate-dev Provides: a virtual 
>> …+flate2-dev
>> package.  Now, …+flate2-dev Provides: a virtual
>> …+compression-deflate-dev package.
> 
> The same thing is happening for rust-sequoia-openpgp: in 1.3.0 (built
> with debcargo 2.4.4), rust-sequoia-openpgp+crypto-nettle-dev used to
> Provides: rust-sequoia-openpgp+nettle-dev
> 
> but as of 1.7.0 (built with debcargo 2.5.0), it is the opposite:
> rust-sequoia-openpgp+nettle-dev used to Provides:
> rust-sequoia-openpgp+crypto-nettle-dev
> 
> The sequoia-openpgp packages are much more involved in terms of
> features, and i don't really want to get into the business of overriding
> debian/control there, so i'm just passing it on another trip through NEW
> (it's in experimental anyway as it's blocked by the rust-random 0.8
> transition temporarily).
> 
> Just documenting that this is an issue for more than a single crate.
> 
>--dkg
> 
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers


-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git

Bug#1003855: RFS: kotlin-mode/20210917git0-1 [RFP] -- Major mode for kotlin

2022-02-08 Thread Nicholas D Steeves

Hi Joshua,

This is just a gentle ping for a status update.  I hope your semester is
going well :-)

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1005184: lintian: package-does-not-install-examples should not look in tests