date:20220608




On 9 June 2022 9:38:59 am IST, Yadd  wrote:
>On 09/06/2022 05:05, Nilesh Patra wrote:
>> Package: wnpp
>> Severity: normal
>> X-Debbugs-Cc: pkg-javascript-de...@alioth-lists.debian.net
>> Control: affects -1 src:node-node-sass
>> 
>> I intend to orphan the node-node-sass package.
>> 
>> This was one of the first difficult to do packages that I did, more
>> than 2 years ago.
>> But now I have no personal bandwidth to keep
>> maintaining it, and it is time that I let it go.
>> 
>> The package description is:
>>   Node-sass is a library that provides binding for Node.js to LibSass.
>>   .
>>   LibSass is the C version of the popular stylesheet preprocessor, Sass.
>>   .
>>   It allows you to natively compile .scss files to css at
>>   incredible speed and automatically via a connect middleware.
>>   .
>>   Node.js is an event-based server-side JavaScript engine.
>
>Hi,
>
>this package owns to JS Team, why doing a O here ?

Aren't you supposed to orphan it even if you're an uploader?
Atleast I have seen several orphan bugs like these.

If not, what's the official procedure to say " I'm not taking care of it 
anymore"?

Best,
Nilesh

Bug#1012550: [Pkg-javascript-devel] Bug#1012550: O: node-node-sass -- Wrapper around libsass

2022-06-08 Thread Yadd


On 09/06/2022 05:05, Nilesh Patra wrote:

Package: wnpp
Severity: normal
X-Debbugs-Cc: pkg-javascript-de...@alioth-lists.debian.net
Control: affects -1 src:node-node-sass

I intend to orphan the node-node-sass package.

This was one of the first difficult to do packages that I did, more
than 2 years ago.
But now I have no personal bandwidth to keep
maintaining it, and it is time that I let it go.

The package description is:
  Node-sass is a library that provides binding for Node.js to LibSass.
  .
  LibSass is the C version of the popular stylesheet preprocessor, Sass.
  .
  It allows you to natively compile .scss files to css at
  incredible speed and automatically via a connect middleware.
  .
  Node.js is an event-based server-side JavaScript engine.


Hi,

this package owns to JS Team, why doing a O here ?

Bug#991113: libpam-chroot: pam_chroot.so installed in wrong place - Not able to login after upgrade

2022-06-08 Thread Javier Fernandez-Sanguino

Dear Michael,

Thanks for the proposed patch. I will try to review and submit a new
package version is the coming days.

Saludos,

Javier

El mié, 8 jun 2022 20:45, M. Buecher  escribió:

> I had a look at the package source and only the paths in the file
> debian/rules [1] have to be changed.
> Extend all `lib/$(DEB_HOST_MULTIARCH)` to
> `lib/$(DEB_HOST_MULTIARCH)/security` (added suffix `/security`).
>
> [1] https://sources.debian.org/src/libpam-chroot/0.9-5/debian/rules/
>
> Here the changed lines I tested successfully:
>
> ```
>  mkdir -p
> $(CURDIR)/debian/libpam-chroot/lib/$(DEB_HOST_MULTIARCH)/security
>  # Add here commands to install the package into debian/libpam-chroot
>  $(MAKE) install DESTDIR=$(CURDIR)/debian/libpam-chroot
> LIBDIR=$(CURDIR)/debian/libpam-chroot/lib/$(DEB_HOST_MULTIARCH)/security
> INSTALL="install --strip-program=true"
> ```
>
> Enable source repositories, install build tools and dependencies, then
> build and install:
>
> ```
> nano /etc/apt/sources.list
> apt-get update
> apt-get install devscripts build-essential
> cd /var/tmp
> apt-get build-dep libpam-chroot
> apt-get source libpam-chroot
> cd libpam-chroot-0.9*/
> sed -i -e 's#lib/\$(DEB_HOST_MULTIARCH)\(
> \|$\)#lib/\$(DEB_HOST_MULTIARCH\)/security\1#' debian/rules
> debuild -us -uc
> #
> cd /var/tmp
> dpkg -i libpam-chroot_0.9*.deb
> ```
>

Bug#1007717: Draft resolution for "Native source package format with non-native version"

2022-06-08 Thread Sean Whitton

Hello,

On Wed 08 Jun 2022 at 09:07pm +02, Helmut Grohne wrote:

> I find it interesting that you seem to equate git-first with dgit. My
> mental model separated those concepts and considered git-first workflows
> on salsa as well. And once you equate them, you can derive a lot of
> conclusions. In my previous mail, I stated that dgit provides the sort
> of uniformity I was looking for quite many aspects. I'm less sure that
> all git-first users are dgit users though.
>
> I think I take more issue with non-dgit git-first workflows than with
> dgit ones, because dgit is so well documented and is a workflow that is
> already shared by a noticeable fraction of the archive.

Didn't mean to equate them, sorry.  We can state the following:

dgit should have support for all git-first workflows.  I am not sure
whether there are any git-first workflows in use on salsa for which you
can't 'dgit push-source' atm.  If there are, those are dgit bugs.

> What is not entirely clear to me is why dgit requires the 1.0-with-diff
> format features. It seems to me that it quite happily deals with a
> number of 3.0 (quilt) packages already. I suppose that you'll now
> explain to me how some git trees are not representable as 3.0 (quilt)
> packages, but do those exist in practice or are those mostly
> pathological?

Sorry, didn't mean to suggest that dgit requires 1.0-with-diff.  It does not.

>> The goal is to attack this problem on two fronts:
>>
>> 1. reduce the need for uniformity by making it possible for people to
>>get their cross-archive work done using 'dgit clone'
>
> I've seen this argument multiple times already and indeed dgit solves
> part of the uniformity issues. However, dgit history often lacks
> maintainer history (and in that way is little better than apt source)

Right, (1) is about making it easy for people to be using 'dgit
push-source' such that the maintainer history is there when you 'dgit clone'.

> and it also lacks a collaboration feature that would save me from
> sending a .debdiff to the bts. Possibly, such a collaboration feature
> is out-of-scope for dgit, but then maybe it is not the kind of tool
> solving the problem of streamlining cross-archive work.

Not out of scope, we have some notes for 'dgit nmudiff' in the BTS.
Would be cool to collaborate with you on finishing that up.

> Either way, my understanding is that unless maintainers switch to
> using dgit primarily, we just gain a secondary workflow here.

No -- (1) is all about ensuring that maintainers don't have to change
their workflows aside from how they do the actual upload.

>> 2. develop git-first workflows that solve all the existing usecases.
>
> Can i rephrase that as follows? Implement so many features into dgit
> that its workflow covers the needs of existing workflows and hope for
> maintainers to migrate to dgit.
>
> It feels a bit like https://xkcd.com/927/ (14 competing standards ->
> 15). On the other hand, dgit is remarkably successful already.

I don't think it can be rephrased that way.

Firstly, (1) is about dgit, but (2) is about tools like git-debrebase(1)
and workflows such as dgit-maint-merge(7).

More substantially, (1) is about attaching maintainer histories to the
dgit view, and (2) is about developing workflows which enables the
maintainer and dgit views to be identical.  That's what I mean when I
say that (1) and (2) are attacking the problem on two fronts.

(2) is particularly important for submitting NMU changes to the
maintainer -- it enables using salsa merge requests, for example.

> I had hoped that we could kinda trim the available workflows eventually.
> It seems like you want to let them all die slowly and concurrently.
>
> [...]
>
> I don't think there is "the git-first work".  Instead there is lots of
> concurrent git-first workflows that are all somewhat similar and yet
> subtly different. Those subtle differences is what I would like to get
> rid of.
>
> Now we've turned a discussion about source package formats into a
> discussion about workflows and git. So when I reason about uniformity, I
> effectively want those idiosyncratic workflows to go away. If dgit
> requires 1.0-with-diff for now, then maybe we could phrase it as an
> exception that is specific to dgit and limited until a better solution
> (such as the format proposed by Ian) is mature. If there are more
> git-first workflows beyond dgit that we want to support, maybe we can
> require declaring a working Vcs-Git for 1.0-with-diff uploads?

My own appraisal of the situation is that we do not know enough yet to
be thinking about cutting back on features and workflows.  But I
certainly agree that it would be better to have a better solution, like
Ian's sketch.

I think Ian has already suggested adding text to our resolution
recommending the development of such a source format.  To be honest I
don't think it's really necessary as everyone agrees it would be better
to have it, but if you think it should be said explicitly then let's

Bug#1012551: O: node-mermaid -- Markdownish syntax for generating flowcharts,

Package: wnpp
Severity: normal
X-Debbugs-Cc: pkg-javascript-de...@alioth-lists.debian.net
Control: affects -1 src:node-mermaid

I intend to orphan the node-mermaid package.
It is a pretty cool package that I packaged approx 2 years ago.
But owing to lack of personal bandwidth, I need to let it go.
It was fun maintaining it, while it lasted.

The package description is:
 sequence diagrams, class diagrams, gantt charts and git graphs.
 .
 It can help visualize flowcharts, diagrams, ganttcharts and git charts can be
 scripted in a markdown syntax, with a varitety of different symbols and chart
 types available. Since the diagram source is text based,
 it can be part of production scipts.
 .
 Automates the diagram generation instead of making it manually.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#1012550: O: node-node-sass -- Wrapper around libsass

Package: wnpp
Severity: normal
X-Debbugs-Cc: pkg-javascript-de...@alioth-lists.debian.net
Control: affects -1 src:node-node-sass

I intend to orphan the node-node-sass package.

This was one of the first difficult to do packages that I did, more
than 2 years ago.
But now I have no personal bandwidth to keep
maintaining it, and it is time that I let it go.

The package description is:
 Node-sass is a library that provides binding for Node.js to LibSass.
 .
 LibSass is the C version of the popular stylesheet preprocessor, Sass.
 .
 It allows you to natively compile .scss files to css at
 incredible speed and automatically via a connect middleware.
 .
 Node.js is an event-based server-side JavaScript engine.

--
Best,
Nilesh

Bug#997264: seriousproton: ftbfs FIX

2022-06-08 Thread David (Plasma) Paul

Attached is a patch to fix Debian bug #997264.

-- 
Plasma


seriousproton_2020.01.15+dfsg-1.1.debdiff
Description: Binary data

Bug#1008642: guix pull complains about "No such file or directory"

2022-06-08 Thread Yuxuan Wang

Thank you, Vagrant!

That is certainly helpful. I found out that I also need to remove
$HOME/.cache/guix, but after that I'm now able to start from scratch again.

On Wed, Jun 8, 2022 at 6:50 PM Vagrant Cascadian  wrote:

> On 2022-06-08, Vagrant Cascadian wrote:
> > On 2022-03-29, Yuxuan Wang wrote:
> >> $ guix pull
> >> Updating channel 'guix' from Git repository at '
> https://git.savannah.gnu.org/git/guix.git'...
> >> Authenticating channel 'guix', commits 9edb3f6 to 1d62b15 (100 new
> commits)...
> >> Building from this channel:
> >>   guix  https://git.savannah.gnu.org/git/guix.git   1d62b15
> >> guix pull: error: opening file
> `/gnu/store/046lwac3v42aw2ggvm7kgps143n4r768-xz.drv': No such file or
> directory
> >
> > You might be able to "guix build --repair" the individual missing items,
> > but it is probably easier to completely remove /var/guix and start from
> > scratch...
>
> This would also have helped if you had arbitrary missing or corrupt
> items:
>
>   guix gc --verify=contents,repair
>
> But since you know everything was removed, still probably best to start
> from scratch.
>
>
> live well,
>   vagrant
>

Bug#1012549: [riscv] lscpu --all --extended output is empty

2022-06-08 Thread 肖盛文

Package: util-linux
Version: 2.38-4
Severity: minor
Tags: upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: atzli...@sina.com, debian-ri...@lists.debian.org

Hi,

  My board is starfive[1], it's CPU is sifive u74.
  
lscpu --all --extended output is empty:

lscpu --all --extended
CPU ONLINE
  -  -
  -  -

If only run lscpu, the output is OK.

lscpu
Architecture:  riscv64
  Byte Order:  Little Endian
CPU(s):2
  On-line CPU(s) list: 0,1


cat /proc/cpuinfo 
processor   : 0
hart: 0
isa : rv64imafdc
mmu : sv39
uarch   : sifive,u74-mc

processor   : 1
hart: 1
isa : rv64imafdc
mmu : sv39
uarch   : sifive,u74-mc

[1] https://linux-hardware.org/?probe=4c36218f66

Thanks!
xiao sheng wen(肖盛文)

-- System Information:
Distributor ID: Atzlinux
Description:Tongwandou (atzlinux) 11
Release:11.3
Codename:   bullseye
Architecture: riscv64

Kernel: Linux 5.18.0-starfive-5.18 (SMP w/2 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages util-linux depends on:
ii  libblkid1 2.38-4
ii  libc6 2.33-7
ii  libcap-ng00.7.9-2.2+b2
ii  libcrypt1 1:4.4.27-1.1
ii  libmount1 2.38-4
ii  libpam0g  1.4.0-13
ii  libselinux1   3.4-1
ii  libsmartcols1 2.38-4
ii  libsystemd0   251.2-2
ii  libtinfo6 6.3+20220423-2
ii  libudev1  251.2-2
ii  libuuid1  2.38-4
ii  util-linux-extra  2.38-4
ii  zlib1g1:1.2.11.dfsg-4

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.2-1
ii  kbd 2.3.0-3
pn  util-linux-locales  

-- no debconf information

Bug#1008642: guix pull complains about "No such file or directory"

On 2022-06-08, Vagrant Cascadian wrote:
> On 2022-03-29, Yuxuan Wang wrote:
>> $ guix pull
>> Updating channel 'guix' from Git repository at 
>> 'https://git.savannah.gnu.org/git/guix.git'...
>> Authenticating channel 'guix', commits 9edb3f6 to 1d62b15 (100 new 
>> commits)...
>> Building from this channel:
>>   guix  https://git.savannah.gnu.org/git/guix.git   1d62b15
>> guix pull: error: opening file 
>> `/gnu/store/046lwac3v42aw2ggvm7kgps143n4r768-xz.drv': No such file or 
>> directory
>
> You might be able to "guix build --repair" the individual missing items,
> but it is probably easier to completely remove /var/guix and start from
> scratch...

This would also have helped if you had arbitrary missing or corrupt
items:

  guix gc --verify=contents,repair

But since you know everything was removed, still probably best to start
from scratch.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1008642: guix pull complains about "No such file or directory"

Control: retitle 1008642 purge /gnu/store and /var/guix when guix is purged

On 2022-03-29, Yuxuan Wang wrote:
> I have been using both guix and nix-setup-systemd on this machine for a while,
> until one day I run out of inodes on the root partition. At the time that
> happened I knew it would be caused by one of guix and nix, but not sure which,
> so I deleted both (by using `apt purge guix nix-setup-systemd` then
> `rm -Rf /nix /gnu`).

You also will need to remove /var/guix as well, as this has databases of
what is in the /gnu/store...

> When deleting both I realized that it's actually nix causing excessive inodes
> used, not guix, so I tried to reinstall guix by `apt install guix`.
>
> But after reinstalled guix it's no longer usable. Whenever I try guix pull it
> throws:
>
> $ guix pull
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Authenticating channel 'guix', commits 9edb3f6 to 1d62b15 (100 new 
> commits)...
> Building from this channel:
>   guix  https://git.savannah.gnu.org/git/guix.git   1d62b15
> guix pull: error: opening file 
> `/gnu/store/046lwac3v42aw2ggvm7kgps143n4r768-xz.drv': No such file or 
> directory

You might be able to "guix build --repair" the individual missing items,
but it is probably easier to completely remove /var/guix and start from
scratch...

I guess "apt purge guix" should actually delete /var/guix and
/gnu/store, though that could be an expensive operation and hard to
revert if done by mistake... a bit tricky to handle correctly if someone
transitions away a .deb packaged guix, though. But I guess in that case
they should remove and *not* purge guix.

live well,
  vagrant

signature.asc
Description: PGP signature

Bug#1012405: guix: Guix command uses less but less does not exist in dependent software

2022-06-08 Thread Taiju HIGASHI

Hi Vagrant,

Thanks for checking.
I think there is also a problem with the code and will work on a fix.
However, I still wonder if we should also change the Debian package definitions.
The recommended packages for git include less, but I think it would be more 
user-friendly to include less in the recommended packages for guix as well.

Thank you in advance for your consideration.

--
Taiju

Bug#1012548: libwebkit2gtk-4.1-0: Offline renderer SIGSEGV on i386

2022-06-08 Thread karogyoker

Package: libwebkit2gtk-4.1-0
Version: 2.36.3-1
Severity: normal
X-Debbugs-Cc: karogyoker2+deb...@gmail.com

Dear Maintainer,

The problem is reproducible if I try to open this webpage in epiphany-browser:
https://www.microsoft.com/en-us/software-download/windows10ISO

The problem is that Gnome Web is displaying Oops! Something went wrong while
displaying this page. Please reload or visit a different page to continue.
Instead it should display the page I want to open.

I'm using the latest Debian Testing i386.

I tried opening the page with this trick: $ JavaScriptCoreUseJIT=0 epiphany
It didn't work.

I have turned off "Website Data Storage" in Preferences.
It worked, I can open the page with this setting turned off.

I've installed the same debian testing netinst i386 .iso into a virtual machine
(VirtualBox) on a newer PC (Intel Core i5 Haswell).
It works even with the "Website Data Storage" turned on.

cat /var/log/kern.log | grep webkit
debian kernel: [ 6021.658455] traps: ffline renderer[26566] general protection
fault ip:b5717218 sp:983a6f50 error:0 in
libwebkit2gtk-4.1.so.0.1.7[b440b000+27af000]

gdb
Thread 18 "ffline renderer" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xaa2fbac0 (LWP 6857)]
0xb56f7218 in ?? () from target:/lib/i386-linux-gnu/libwebkit2gtk-4.1.so.0
(gdb) set disassembly-flavor intel
(gdb) x/i $eip
=> 0xb56f7218:  ldmxcsr DWORD PTR [esp+0x28]
(gdb) x/d $esp+0x28
0xaa2faf78: 40896
(gdb) i r a
eax0x9fc0  40896
ecx0x0 0
edx0x1f9ea00   33155584
ebx0xb7f38e00  -1208775168
esp0x982fef50  0x982fef50
ebp0x0 0x0
esi0x1f9ea00   33155584
edi0xac44  44100
eip0xb576f218  0xb576f218
eflags 0x210206[ PF IF RF ID ]
cs 0x73115
ss 0x7b123
ds 0x7b123
es 0x7b123
fs 0x0 0
gs 0x3351
st00   (raw 0x)
st10   (raw 0x)
st20   (raw 0x)
st30   (raw 0x)
st40   (raw 0x)
st51.79769313486231570815e+308 (raw 0x43fef800)
st61.03879187898976521609 (raw 0x3fff84f721ddce436000)
st70   (raw 0x)
fctrl  0x37f   895
fstat  0x4027  16423
ftag   0x  65535
fiseg  0x0 0
fioff  0x0 0
foseg  0x0 0
fooff  0x0 0
fop0x0 0
xmm0   {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 =
0x0}
xmm1   {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 =
0x0}
xmm2   {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 =
0x0}
xmm3   {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 =
0x0}
xmm4   {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 =
0x0}
xmm5   {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 =
0x0}
xmm6   {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 =
0x0}
xmm7   {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 =
0x0}
mxcsr  0x1f80  [ IM DM ZM OM UM PM ]
mm0{uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0,
0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}
mm1{uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0,
0x0}, v8_int8 = {0x0, 0x0, 0x0,

Bug#1012538: knocked out usability - module 'collections' has no attribute 'Callable'

2022-06-08 Thread Tyler Schwend

The Debian packaged version is much older than the current version.

On Wednesday, June 8, 2022, Arnaldo Pirrone  wrote:
> Package: chirp
> Version: 1:20200227+py3+20200213-3
> Severity: grave
> X-Debbugs-Cc: it9...@gmail.com
>
> Just tried using this software to program my radio and found out it
stopped
> working. I remember it was everything fine a few months ago. Probably
this is
> caused by changes in Python 3.10.5
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.17.13-xanmod1 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 chirp depends on:
> ii  python3   3.10.4-1+b1
> ii  python3-future0.18.2-6
> ii  python3-serial3.5-1
> ii  python3-six   1.16.0-3
> ii  python3-wxgtk4.0  4.0.7+dfsg-13
>
> chirp recommends no packages.
>
> chirp suggests no packages.
>
> -- no debconf information
>
>

Bug#1012547: linux: disable user namespaces per default

2022-06-08 Thread Philippe Cerfon

Source: linux
Version: 5.17.11-1
Severity: normal
Tags: security

Hi.

Some time ago, Debian decided to enable user namespaces per default.

Since then we've had numerous security holes which would have been
prevented when user namespaces were disabled.

I vaguely recall at least around 6-7 such holes, and a quick google
search seems to reveal that at least those would have been mitigated
by unprivileged user namespaces being disabled:
CVE-2019-18198
CVE-2020-14386
CVE-2022-0185
CVE-2022-24122
CVE-2022-25636
CVE-2022-1966 resp. CVE-2022-32250

And these are just the ones from more recent years.
A longer list can be found e.g.
https://security.stackexchange.com/questions/209529/what-does-enabling-kernel-unprivileged-userns-clone-do
.

It also doesn't look as if userns just needed some polishing and "now"
they'd be finally secure - it rather seems like just a matter of time
when one can read next, that some hole can be mitigated by disabling
userns.

It rather seems that this feature is only of special use, namely for
those people who use user namespaces with containers or similar - by
far no default on a average server or desktop.

Even "jailing" tools like bubblewrap do IMO not really justify this
being a default:
a) it's only used by certain programs, e.g. bubblewrap isn't a
standard tool found on every install
b) such tools could just ship a default sysctl config or rather ask a
debconf question whether such questionable functionality should be
enabled
c) there is anyway no such thing as a true "jail" - software makers
should rather try to secure their code, than believing that some magic
tool would do the job for them, which use a feature which seems still
not stable from the security PoV.

So if the feature is anyway easily configurable - why choosing a
default which has proven insecure numerous times?
Why do all users - especially those who do not even use the feature -
have to suffer from it working out of the box, just for a few special
use cases (who could also just enable it)?

So please reconsider the previous choice, don't ship insecure defaults
and disable unprivileged userns per default, until at least some at
least 5-10 years no further hole is going to be found, which would
have been prevented with them being disabled.

Just my 2 cents,
Philippe.

PS: As for (d), it would be really bad if all programs who can make
use of userns now simply ship their own /etc/sysctl.d/foo.conf, making
it even more difficult for people who deliberately not want that
feature to keep it disabled for sure. There should be rather a
convention that such tools would enable it in a common file like
/etc/sysctl.d/userns.conf.

Bug#1012546: clog: Please implement extended regular expressions with -E command line switch

2022-06-08 Thread Patrik Schindler

Package: clog
Version: 1.3.0-1+b1
Severity: wishlist
Tags: upstream

As said in the subject: Please implement extended regular expressions with -E
command line switch.

I've finished cleanup of some logcheck rules and wanted to use clog for adding
helpful colors. Unfortunately, I need to rework those rules from extended regex
to normal regex syntax. This essentially doubles work.

Thanks for considering.

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

Kernel: Linux 5.10.0-14-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/bash
Init: sysvinit (via /sbin/init)

Versions of packages clog depends on:
ii  libc62.31-13+deb11u3
ii  libgcc-s1 [libgcc1]  10.2.1-6
ii  libstdc++6   10.2.1-6

clog recommends no packages.

clog suggests no packages.

-- no debconf information

Bug#1012544: libworkflow1: Broken shared library packaging

2022-06-08 Thread Guillem Jover

Package: libworkflow1
Version: 0.9.10-1
Severity: serious

Hi!

This package has several problems:

 - It contains a shared library without a SOVERSION

   ,---
   $ objdump -p /usr/lib/x86_64-linux-gnu/libworkflow.so | grep SONAME
   SONAME   libworkflow.so
   `---

   This means any binary package linked against this shared library
   misses relevant ABI information and can break on any ABI change.
   The SONAME should contain the SOVERSION, in this case I'd assume
   that to be 1, from the binary package name, but given the version
   used in the fully versioned shared library filename, perhaps that
   should have been libworkflow0, and then SONAME should be
   libworkflow.so.0.

 - The shared library object should be the one with the full version,
   say libworkflow.so.0.9.10, the SONAME should be the symlink, so
   say libworkflow.so.0 → libworkflow.so.0.9.10, and the unversioned
   .so symlink for build-time linking should also be a symlink (or in
   some cases a linker script), libworkflow.so → libworkflow.so.0.9.10.

 - The versioned shared library filenames should go into the versioned
   shared library package.

 - The unversioned shared and static library filenames should go into
   the -dev package.

Please refer to debian-policy section §8 for further information. I
think in this case lintian would have flagged these as errors.

Thanks,
Guillem

Bug#1009169: please package new emacs version 28.1

2022-06-08 Thread Xiyue Deng

Package: emacs
Followup-For: Bug #1009169

Hi Rob, 

Thanks for maintaining Emacs in Debian!  I've been a long time Emacs
user and would like to help in anyway you prefer.  I had some
experiences in Debian packaging a few years ago and have been
relearning everything from the docs like [1] and [2].  If there's
anything that I can help with (e.g. testing, bug triaging, etc.)
please let me know.

[1] https://www.debian.org/doc/devel-manuals#debmake-doc
[2] https://www.debian.org/doc/devel-manuals#devref

Bug#1012004: srpc: Unorthodox binary package content organization

2022-06-08 Thread Guillem Jover

On Wed, 2022-06-08 at 14:03:06 +, Lance Lin wrote:
> > Ideally the .a archive and the .so linked script (which just redirects
> > the linker to always use the .a archive, so there's no actual shared
> > library), should be moved into the libsrpc-dev package as the usual
> > convention. The versioned .so symlink (libsrpc.so.0.9.5) should be
> > removed, as there should be no object dynamically linked against that
> > (given that it points back to the .so linker script which does not
> > resolve at run-time) to avoid confusion.
> 
> Please help me understand. When I packaged 'workflow' for the upstream
> authors, I created libworkflow1 and libworkflow-dev. libworkflow1 provides
> the libraries/objects while the -dev package depends on libworkflow1 and
> includes the header files. I thought this was the convention?

Not really no. The workflow packages look like needing further fixing
too, I'll file a report for that one separately. :)

The .a and .so pathnames are shipped in the -dev package because they
are only useful during development, and because they contain unversioned
pathnames that would otherwise conflict with their counterparts from
other supposedly co-installable shared library packages.

The point of versioning the shared library packages is precisely so
that they can be co-installed, which makes (distro) transitions and
system upgrades way smoother. Say bin-pkg-a links against libsome1
from the libsome source package, then libsome gets updated and bumps
its shared library package to libsome2 which bin-pkg-b links against.
This means a user can happily have bin-pkg-a → libsome1 and
bin-pkg-b → libsome2 installed at the same time while the others get
rebuilt, this also means packages can be rebuilt against a later version
libsome-dev → libsome2 even if they transitively Build-Depends on
something that depends on libsome1, otherwise that build-dependency
chain could not be installed.

This is covered in debian-policy §8.

> > Then the srpc_generator program would be moved into a new libsrcp-bin
> > binary package to make this separation more clear. And the libsrpc
> > binary package can then be dropped. (All with the required
> > Replaces/Breaks relationships.)
> > 
> 
> > At that point the libsrpc-dev can be marked as Multi-Arch: same, and
> > the libsrpc-bin (assuming the generated contents are arch-independent)
> > can be marked Multi-Arch: foreign.
> 
> OK. This is doable. I was unsure how to structure the package to include
> this binary.
> 
> I based my packaging of SPRC based on workflow and both passed the mentors
> list. If there is a better or more standard away of doing things, I am
> happy to adjust.

See above.

> Is there a system in Debian that flags this "unorthodox" organization for
> review?

It seems lintian does not have any check for something like this, it
does notice other things, such as the Section for libsrpc-dev being
wrong and the Architecture, but nothing more. I guess the problem is
the combination of unversioned shared library package, with no actual
shared library and instead a linker script, which all are rather
unusual.

> I'm curious how you came across this since workflow was done in a
> very similar fashion but no one commented. I am always learning and want
> to make sure I fix errors made in the past and avoid them in the future.

This specific case I noticed as I tend to check any unversioned shared
library package that appears as a new package on aptitude. Otherwise
I'd probably have not noticed, like the workflow one.

Also I guess not all reviews are made equal. :)

> Do you have a reference package I could look at? It would be helpful
> to base my work off of something that meets the standard.

The libbsd source package also ships a linker script as its .so
pathname, even though that one contains an actual shared library
with a versioned SONAME.

For a more usual package, perhaps libmd would do.

Thanks,
Guillem

Bug#1012541: xdg-desktop-portal: Filesystem 'fuse.portal' is not recognised as a valid filesystem

2022-06-08 Thread tmcconnell168

Well, hopefully the patch gets applied soon. 
Thanks for the information. 
Tim

On Wed, 2022-06-08 at 23:06 +0100, Simon McVittie wrote:
> Control: reassign -1 tiger
> Control: forcemerge 987512 -1
> Control: affects -1 + xdg-desktop-portal
> 
> On Wed, 08 Jun 2022 at 16:45:21 -0500, Tim McConnell wrote:
> >  test -x /usr/sbin/tigercron && { [ -r "$DEFAULT" ] && . "$DEFAULT"
> > ; nice
> > -n$NICETIGER /usr/sbin/tigercron -q ; }
> > --CONFIG-- [con010c] Filesystem 'fuse.portal' used by 'portal' is
> > not
> > recognised as a valid filesystem
> 
> xdg-desktop-portal does not control what filesystems tiger recognises
> as
> "valid". tiger already has a bug report about this (#987512), with a
> patch.
> 
>     smcv

Bug#1012536: guix: Debian's guix tries using Guix' glibc locales installed in /var/guix/profiles/... instead of Debian's glibc locales

2022-06-08 Thread Maxime Devos

Vagrant Cascadian schreef op wo 08-06-2022 om 14:43 [-0700]:
> So do you now have...
> 
>   ExecStart=/usr/bin/guix-daemon --build-users-group=_guixbuild
>   Environment=LC_ALL=C.UTF-8
> 
> 
> Does this mean the build environment that guix-daemon creates are
> running in the C.UTF-8 locale,

Unless there's a hole in the build containeer, the builds (unless you
count "guix perform-download" and "guix substitute" as builds) do not
have access to Debian's /usr/etcetera and likewise they don't have
access to guix-daemon's environment variables (*).  So the builds use
guix' locale data or no locales at all, and they don't use the C.UTF-8
locale.

> or does guix-daemon normalize the locale that builds are performed in
> to use a "default" locale from guix;

AFAICT only "guix-daemon", "guix perform-download", "guix substitute"
and maybe "guix offload" will see the LC_ALL=C.UTF-8.

As written previously, the builds themselves do not have access to the
LC_ALL(*) of the build daemon.  However, the guix daemon does not
perform any normalisation (except for removing all environment
variables, including LC_ALL, starting a build) -- the locale will be
set by the _builder_, in 'install-locale' in (guix build gnu-build-
system), and the builder will only have access to Guix locales (and
only if the package is built with a glibc-locales package in its
(native-)inputs) because of the build sandbox.

(*) with some exceptions: the fixed-output derivations for downloading
git repositories have access to the http_proxy and LC_ALL of the _user_
that is running "guix build" or the like.  However, ‘regular’ builds
like "guix build hello" do not have access to any leaked environment
varibables.

> C.UTF-8 isn't yet present in guix's glibc, could this cause issues?

No, because guix's glibc is not involved here (sandboxing).

(Usual caveats apply, if my understanding of Guix is incorrect then my
answer might be incorrect, etc., my proposed change hasn't seen much
practical testing ...)

Greetings,
Maxime.


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

Bug#1012541: xdg-desktop-portal: Filesystem 'fuse.portal' is not recognised as a valid filesystem

2022-06-08 Thread Simon McVittie

Control: reassign -1 tiger
Control: forcemerge 987512 -1
Control: affects -1 + xdg-desktop-portal

On Wed, 08 Jun 2022 at 16:45:21 -0500, Tim McConnell wrote:
>  test -x /usr/sbin/tigercron && { [ -r "$DEFAULT" ] && . "$DEFAULT" ; nice
> -n$NICETIGER /usr/sbin/tigercron -q ; }
> --CONFIG-- [con010c] Filesystem 'fuse.portal' used by 'portal' is not
> recognised as a valid filesystem

xdg-desktop-portal does not control what filesystems tiger recognises as
"valid". tiger already has a bug report about this (#987512), with a patch.

smcv

Bug#1012543: debhelper: setting HOME/XDG* for {override,execute_{before,after}}_dh_auto_*

2022-06-08 Thread Andreas Beckmann

Package: debhelper
Version: 13.7.1
Severity: normal

Hi,

I just encountered again the execute_after_dh_auto_build-indep target in
src:pyopencl which builds the documentation and therefore indirectly calls
sphinx which insists on having a writable home directory ...

It would be great if debhelper could make the writable temporary HOME
that is used for the dh_auto_* commands available to the corresponding
override_dh_auto_* and execute_before/after_dh_auto_* targets. too.


Andreas

Bug#1012542: RFS: streamlink/4.1.0-1 -- CLI for extracting video streams from various websites to a video player

2022-06-08 Thread Alexis Murzeau

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 4.1.0.

 * Package name: streamlink
   Version : 4.1.0-1
   Upstream Author : Streamlink Team
 * URL : https://streamlink.github.io/
 * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
   Section : python

It builds those binary packages:

  python3-streamlink - Python module for extracting video streams from
various websites
  python3-streamlink-doc - CLI for extracting video streams from various
websites (documentation)
  streamlink - CLI for extracting video streams from various websites to
a video player

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/streamlink


Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_4.1.0-1.dsc

Changes since the last upload to unstable:
streamlink (4.1.0-1) unstable; urgency=medium

  * d/salsa-ci.yml: adjust config to disable non working ones
  * New upstream version 4.1.0
  * Update patches

 -- Alexis Murzeau   Wed, 08 Jun 2022 23:38:11 +0200


Regards,
-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



















signature.asc
Description: OpenPGP digital signature

Bug#1012537: vim-addon-manager: Error when processing 02tlib plug in

2022-06-08 Thread James McCoy

Control: reassign -1 vim-tlib
Control: forcemerge 996477 -1

On Wed, Jun 08, 2022 at 03:25:42PM -0500, Tim McConnell wrote:
> What led up to the situation? Unknown, error just started appearing.
> 
> What exactly did you do (or not do) that was effective (or ineffective)?
> Unknown if an update caused this.
> 
> What was the outcome of this action? when I try to launch VIM or GVIM, etc. I
> get this error(?) every time:
> Error detected while processing /var/lib/vim/addons/plugin/02tlib.vim:
> line   77: E1208: -complete used without allowing argumentsPress ENTER or type
> command to continue

The error is being reported from /var/lib/vim/addons/plugin/02tlib.vim.
The problem is in the vim-tlib package, not vim-addon-manager.

The issue is that Vim became more strict about how user commands are
defined and this plugin is violating that.  It's defining a command that
doesn't accept any arguments (-nargs=0) but is then specifying a
mechanism to define completions for arguments to the command
(-complete=command).

Reassigning to the vim-tlib package and marking it as a duplicate of the
existing issue.

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

Bug#1012541: xdg-desktop-portal: Filesystem 'fuse.portal' is not recognised as a valid filesystem

2022-06-08 Thread Tim McConnell

Package: xdg-desktop-portal
Version: 1.14.4-1
Severity: normal
X-Debbugs-Cc: tmcconnell...@gmail.com

Dear Maintainer,

What led up to the situation? Unsure, I started getting these after Tiger tries
to run a cron job.

What exactly did you do (or not do) that was effective (or ineffective)?
No Idea.

What was the outcome of this action?
Multiple reports of this:
 test -x /usr/sbin/tigercron && { [ -r "$DEFAULT" ] && . "$DEFAULT" ; nice
-n$NICETIGER /usr/sbin/tigercron -q ; }
--CONFIG-- [con010c] Filesystem 'fuse.portal' used by 'portal' is not
recognised as a valid filesystem
--CONFIG-- [con010c] Filesystem 'fuse.portal' used by 'portal' is not
recognised as a valid filesystem

What outcome did you expect instead? For the file system to be recognized.


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

Kernel: Linux 5.17.0-1-rt-amd64 (SMP w/2 CPU threads; PREEMPT)
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 xdg-desktop-portal depends on:
ii  bubblewrap0.6.2-1
ii  dbus-user-session [default-dbus-session-bus]  1.14.0-1
ii  dbus-x11 [dbus-session-bus]   1.14.0-1
ii  fuse3 3.11.0-1
ii  init-system-helpers   1.63
ii  libc6 2.33-7
ii  libfuse3-33.11.0-1
ii  libgdk-pixbuf-2.0-0   2.42.8+dfsg-1
ii  libglib2.0-0  2.72.1-1
ii  libjson-glib-1.0-01.6.6-1
ii  libpipewire-0.3-0 0.3.51-1
ii  libsystemd0   250.4-1

xdg-desktop-portal recommends no packages.

xdg-desktop-portal suggests no packages.

-- no debconf information

Bug#1012536: guix: Debian's guix tries using Guix' glibc locales installed in /var/guix/profiles/... instead of Debian's glibc locales

On 2022-06-08, Maxime Devos wrote:
> In /etc/systemd/system/guix-daemon.service, there's the line:
>
> Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale'
>  LC_ALL=en_US.utf8
>
> However, I'm using Debian's guix so shouldn't it look for glibc's
> locales instead?  (Also, I'm not installing anything as root, so I'd
> like to remove /var/guix/profiles/per-user/root.)

Thanks for the report! These are good questions...


> I reverted the ExecStart=... line to ExecStart=/usr/bin/guix-daemon.
> I removed the GUIX_LOCPATH=... assignment.  However, that resulted
> in 'guix substitute' not finding the locale:
>
> $ guix build --source snap
> substitute: hint: Consider installing the `glibc-utf8-locales' or 
> `glibc-locales' package and
> substitute: defining `GUIX_LOCPATH', along these lines:
> substitute: 
> substitute:  guix install glibc-utf8-locales
> substitute:  export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
> substitute: 
> substitute: See the "Application Setup" section in the manual, for more info.
> substitute: 
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> 113,0 MB will be downloaded: [etc etc].
>
> To resolve the issue, I replaced LC_ALL=en_US.utf8 by LC_ALL=C.UTF-8
> (LC_ALL=C.utf8 doesn't work for whatever reason) and did a
> "systemctl daemon-reload" + "systemctl restart guix-daemon", after which
> the locale warnings didn't appear again.

So do you now have...

  ExecStart=/usr/bin/guix-daemon --build-users-group=_guixbuild
  Environment=LC_ALL=C.UTF-8


Does this mean the build environment that guix-daemon creates are
running in the C.UTF-8 locale, or does guix-daemon normalize the locale
that builds are performed in to use a "default" locale from guix;
C.UTF-8 isn't yet present in guix's glibc, could this cause issues?

I'll admit I'm a little confused at the multiplicity of potentially
relevent locales; in which environments are which locales
used... etc. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1011875: golang-github-opencontainers-runtime-tools: FTBFS unreproducible

2022-06-08 Thread Reinhard Tartler

My hunch might have been correct, the fresh upload did build successfully
on buildds. yay!

On Sun, Jun 5, 2022 at 7:12 AM Reinhard Tartler  wrote:

> Just a hunch, is it possible that your build environment did not have the
> package 'ca-certificates' present whereas mine does?
>
> I wonder whether I need to add 'ca-certificates' to "Build-Depends". What
> do you think?
>
> On Sun, Jun 5, 2022 at 7:10 AM Reinhard Tartler 
> wrote:
>
>> Please find the buildlog of my attempt attached to this email
>>
>> As far as I can tell, the tests are executing in the same way as in your
>> logs, but I may be missing something.
>>
>
>
> --
> regards,
> Reinhard
>


-- 
regards,
Reinhard

Bug#1012540: pelican: The contents of man of "pelican" and "pelican-plugins" seem to be wrong.

2022-06-08 Thread KenichiroMATOHARA

Package: pelican
Version: 4.7.1+dfsg-2
Severity: normal

Dear Maintainer,

It seems that the content of "man pelican-plugins" is that of "pelican", and
the content of "man pelican" is an old version (3.7.1).

> $ man pelican-plugins | head -1
> PELICAN(1)User Commands
PELICAN(1)
> $ man pelican-plugins | tail -1
> pelican 4.0.1  January 2021
PELICAN(1)
> $ man pelican | tail -1
> pelican 3.7.1  January 2017
PELICAN(1)


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

Kernel: Linux 5.17.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 pelican depends on:
ii  python33.10.4-1+b1
ii  python3-blinker1.4+dfsg1-0.5
ii  python3-dateutil   2.8.1-6
ii  python3-docutils   0.17.1+dfsg-2
ii  python3-feedgenerator  1.9-3
ii  python3-jinja2 3.0.3-1
ii  python3-markdown   3.3.7-1
ii  python3-pkg-resources  59.6.0-1.2
ii  python3-pygments   2.11.2+dfsg-2
ii  python3-rich   12.4.4-1
ii  python3-tz 2022.1-1
ii  python3-unidecode  1.3.4-1

pelican recommends no packages.

Versions of packages pelican suggests:
ii  pandoc   2.9.2.1-3+b2
pn  pelican-doc  
ii  python3-bs4  4.11.1-1

-- no debconf information

Bug#1011863: guix: FTBFS: tests fail

Control: forwarded 1011863 https://issues.guix.gnu.org/55506
Control: tags 1011863 fixed-upstream

On 2022-06-08, Vagrant Cascadian wrote:
> On 2022-05-26, Vagrant Cascadian wrote:
>> On 2022-05-26, Lucas Nussbaum wrote:
>>> During a rebuild of all packages in sid, your package failed to build
>>> on amd64.
> ...
 PASS: tests/channels.scm - latest-channel-instances, missing introduction 
 for 'guix' 
 FAIL: tests/channels.scm - authenticate-channel, wrong first commit signer 
 FAIL: tests/channels.scm - authenticate-channel, .guix-authorizations 
 FAIL: tests/channels.scm - latest-channel-instances, authenticate 
 dependency 
 PASS: tests/combinators.scm - fold2, 1 list 
>> ...
 PASS: tests/git-authenticate.scm - unsigned commits 
 FAIL: tests/git-authenticate.scm - signed commits, SHA1 signature 
 FAIL: tests/git-authenticate.scm - signed commits, default authorizations 
 FAIL: tests/git-authenticate.scm - signed commits, .guix-authorizations 
 FAIL: tests/git-authenticate.scm - signed commits, .guix-authorizations, 
 unauthorized merge 
 FAIL: tests/git-authenticate.scm - signed commits, .guix-authorizations, 
 authorized merge 
 FAIL: tests/git-authenticate.scm - signed commits, .guix-authorizations 
 removed 
 PASS: tests/glob.scm - string->sglob, "foo" 
> ...
>> Will do a local build to see if I can reproduce the failure, various
>> dependencies have since the last guix upload which might trigger some of
>> these issues...
>
> Still had the issues in my builds... but this issue is very likely the
> one fixed upstream:
>
>   https://issues.guix.gnu.org/55506
>   ‘tests/channels.scm’ and ‘tests/git-authenticate.scm’ GPG-related test 
> failures
>
> In short, the openpgp keys used in the test-suite expired. They fixed it
> by removing the expiration dates on the keys... will try to do the same.

Fixed upstream:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=3ae7632ca0a1edca9d8c3c766efb0dcc8aa5da37

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1012405: guix: Guix command uses less but less does not exist in dependent software

Control: forwarded 1012405 https://issues.guix.gnu.org/55845

On 2022-06-06, Taiju HIGASHI wrote:
> * What led up to the situation?
> A situation that was being verified with the help of an acquaintance.
>
> Note: This is occurring in a container executed with the following command.
>
> docker run --rm -it debian:sid-20220527 bash
>
> * What exactly did you do (or not do) that was effective (or ineffective)?
> $ apt update -y
> $ apt install guix
> $ guix package -s gcc
>
> * What was the outcome of this action?
> The following error occurred.
>
> In execvp of less: No such file or directory
>
> * What outcome did you expect instead?
> I want to make sure that less is included in the dependent software and that 
> it will work correctly when installed in an environment without less.

Thanks for taking this upstream!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1011863: guix: FTBFS: tests fail

On 2022-05-26, Vagrant Cascadian wrote:
> On 2022-05-26, Lucas Nussbaum wrote:
>> During a rebuild of all packages in sid, your package failed to build
>> on amd64.
...
>>> PASS: tests/channels.scm - latest-channel-instances, missing introduction 
>>> for 'guix' 
>>> FAIL: tests/channels.scm - authenticate-channel, wrong first commit signer 
>>> FAIL: tests/channels.scm - authenticate-channel, .guix-authorizations 
>>> FAIL: tests/channels.scm - latest-channel-instances, authenticate 
>>> dependency 
>>> PASS: tests/combinators.scm - fold2, 1 list 
> ...
>>> PASS: tests/git-authenticate.scm - unsigned commits 
>>> FAIL: tests/git-authenticate.scm - signed commits, SHA1 signature 
>>> FAIL: tests/git-authenticate.scm - signed commits, default authorizations 
>>> FAIL: tests/git-authenticate.scm - signed commits, .guix-authorizations 
>>> FAIL: tests/git-authenticate.scm - signed commits, .guix-authorizations, 
>>> unauthorized merge 
>>> FAIL: tests/git-authenticate.scm - signed commits, .guix-authorizations, 
>>> authorized merge 
>>> FAIL: tests/git-authenticate.scm - signed commits, .guix-authorizations 
>>> removed 
>>> PASS: tests/glob.scm - string->sglob, "foo" 
...
> Will do a local build to see if I can reproduce the failure, various
> dependencies have since the last guix upload which might trigger some of
> these issues...

Still had the issues in my builds... but this issue is very likely the
one fixed upstream:

  https://issues.guix.gnu.org/55506
  ‘tests/channels.scm’ and ‘tests/git-authenticate.scm’ GPG-related test 
failures

In short, the openpgp keys used in the test-suite expired. They fixed it
by removing the expiration dates on the keys... will try to do the same.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1012532: inkscape: PDF import no longer works

2022-06-08 Thread Graeme Smecher


Hi Dennis,

On 2022-06-08 13:35, Dennis Braun wrote:
This looks very similar to this old bug 
https://bugs.launchpad.net/inkscape/+bug/1276871


On a hunch, I ensured libpoppler was up-to-date - an apt-get upgrade 
libpoppler* corrected the problem and I am now able to import PDFs again.


Please feel free to close the bug. I'm not sure whether this breakage is 
an indication that a dependency isn't properly tracked; I'll leave that 
up to you.


Thanks for all you do.

best,
Graeme

Bug#1012538: knocked out usability - module 'collections' has no attribute 'Callable'

2022-06-08 Thread Arnaldo Pirrone

Package: chirp
Version: 1:20200227+py3+20200213-3
Severity: grave
X-Debbugs-Cc: it9...@gmail.com

Just tried using this software to program my radio and found out it stopped
working. I remember it was everything fine a few months ago. Probably this is
caused by changes in Python 3.10.5


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

Kernel: Linux 5.17.13-xanmod1 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 chirp depends on:
ii  python3   3.10.4-1+b1
ii  python3-future0.18.2-6
ii  python3-serial3.5-1
ii  python3-six   1.16.0-3
ii  python3-wxgtk4.0  4.0.7+dfsg-13

chirp recommends no packages.

chirp suggests no packages.

-- no debconf information

Bug#1007717: Draft resolution for "Native source package format with non-native version"

2022-06-08 Thread Lucas Nussbaum

On 08/06/22 at 21:07 +0200, Helmut Grohne wrote:
> Now we've turned a discussion about source package formats into a
> discussion about workflows and git. So when I reason about uniformity, I
> effectively want those idiosyncratic workflows to go away. If dgit
> requires 1.0-with-diff for now, then maybe we could phrase it as an
> exception that is specific to dgit and limited until a better solution
> (such as the format proposed by Ian) is mature. If there are more
> git-first workflows beyond dgit that we want to support, maybe we can
> require declaring a working Vcs-Git for 1.0-with-diff uploads?

I think that the workflow used by the Debian X team is such a git-first
workflow that is not using dgit. That workflow combines Debian-specific
patches managed by quilt, and commits cherry-picked from upstream
directly applied to the source in git (outside of quilt).
See 

There are 89 packages maintained by Debian X among the 607 packages in
testing still using 1.0.

Lucas

Bug#1007717: Draft resolution for "Native source package format with non-native version"

2022-06-08 Thread Lucas Nussbaum

On 08/06/22 at 21:07 +0200, Helmut Grohne wrote:
> I think I take more issue with non-dgit git-first workflows than with
> dgit ones, because dgit is so well documented and is a workflow that is
> already shared by a noticeable fraction of the archive.

I'm curious: how do you measure dgit usage?

You cannot just look at the list of repositories at
https://browse.dgit.debian.org/, since that just says that at some point
in the past, someone used dgit to work on that package, right?
For example, the keepass2 package has a repo there, but it is completely
outdated compared to what is in unstable.

Lucas

Bug#1012537: vim-addon-manager: Error when processing 02tlib plug in

2022-06-08 Thread Tim McConnell

Package: vim-addon-manager
Version: 0.5.10
Severity: normal
X-Debbugs-Cc: tmcconnell...@gmail.com

Dear Maintainer,

What led up to the situation? Unknown, error just started appearing.

What exactly did you do (or not do) that was effective (or ineffective)?
Unknown if an update caused this.

What was the outcome of this action? when I try to launch VIM or GVIM, etc. I
get this error(?) every time:
Error detected while processing /var/lib/vim/addons/plugin/02tlib.vim:
line   77: E1208: -complete used without allowing argumentsPress ENTER or type
command to continue

What outcome did you expect instead?
No errors. I can still use VIM and it's other packages if I hit ENTER but it's
annoying to have to do it every time and I can't find the add on in the path
shown.



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

Kernel: Linux 5.17.0-1-rt-amd64 (SMP w/2 CPU threads; PREEMPT)
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 vim-addon-manager depends on:
ii  ruby1:3.0+1
ii  vim-common  2:8.2.4793-1

Versions of packages vim-addon-manager recommends:
ii  vim  2:8.2.4793-1
ii  vim-gtk3 [vim]   2:8.2.4793-1
ii  vim-motif [vim]  2:8.2.4793-1
ii  vim-nox [vim]2:8.2.4793-1

vim-addon-manager suggests no packages.

-- no debconf information

Bug#1012536: guix: Debian's guix tries using Guix' glibc locales installed in /var/guix/profiles/... instead of Debian's glibc locales

2022-06-08 Thread Maxime Devos

Package: guix
Version: 1.2.0-4
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Previously, I used a Guix compiled by Guix as the guix daemon.
I would like to switch back to Debian's guix and remove the root
user's Guix profile (because I didn't use it for anything except
for updating the Guix daemon), but I encountered some trouble:

In /etc/systemd/system/guix-daemon.service, there's the line:

Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale'
 LC_ALL=en_US.utf8

However, I'm using Debian's guix so shouldn't it look for glibc's
locales instead?  (Also, I'm not installing anything as root, so I'd
like to remove /var/guix/profiles/per-user/root.)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I reverted the ExecStart=... line to ExecStart=/usr/bin/guix-daemon.
I removed the GUIX_LOCPATH=... assignment.  However, that resulted
in 'guix substitute' not finding the locale:

$ guix build --source snap
substitute: hint: Consider installing the `glibc-utf8-locales' or 
`glibc-locales' package and
substitute: defining `GUIX_LOCPATH', along these lines:
substitute: 
substitute:  guix install glibc-utf8-locales
substitute:  export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
substitute: 
substitute: See the "Application Setup" section in the manual, for more info.
substitute: 
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
113,0 MB will be downloaded: [etc etc].

To resolve the issue, I replaced LC_ALL=en_US.utf8 by LC_ALL=C.UTF-8
(LC_ALL=C.utf8 doesn't work for whatever reason) and did a
"systemctl daemon-reload" + "systemctl restart guix-daemon", after which
the locale warnings didn't appear again.

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

Kernel: Linux 5.10.0-13-amd64 (SMP w/8 CPU threads)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=nl_BE:nl
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages guix depends on:
ii  guile-2.2   2.2.7+1-6
ii  guile-2.2-libs  2.2.7+1-6
ii  guile-gcrypt0.3.0-3
ii  guile-git   0.4.0-3
ii  guile-gnutls3.7.1-5
ii  guile-json  4.3.2-2
ii  guile-lzlib 0.0.2-2
ii  guile-sqlite3   0.1.3-2
ii  guile-ssh   0.13.1-4
ii  guile-zlib  0.0.1-3
ii  libbz2-1.0  1.0.8-4
ii  libc6   2.31-13+deb11u3
ii  libgcc-s1   10.2.1-6
ii  libgcrypt20 1.8.7-6
ii  libsqlite3-03.34.1-3
ii  libssh-dev  0.9.5-1+deb11u1
ii  libstdc++6  10.2.1-6
ii  zlib1g  1:1.2.11.dfsg-2+deb11u1

Versions of packages guix recommends:
ii  nscd 2.31-13+deb11u3
ii  systemd  247.3-7

guix suggests no packages.

-- Configuration Files:
/etc/guix/acl [Errno 13] Toegang geweigerd: '/etc/guix/acl'

-- no debconf information

Bug#995636: transition: openssl

2022-06-08 Thread Sebastian Ramacher

On 2022-06-05 19:50:33 +, Sebastian Andrzej Siewior wrote:
> On 5 June 2022 19:03:17 UTC, Kurt Roeckx  wrote:
> >The suggestion was to make an openssl.cnf that's compatible with 1.1.1,
> >and so remove or comment out everything related to providers.
> >
> 
> Ah okay. In that case let me so that tomorrow and close that rc bug with this 
> change.

That would be much appreciated, thanks!

Cheers

> 
> >
> >Kurt
> >
> 
> 
> -- 
> Sebastian
> 

-- 
Sebastian Ramacher

Bug#1012535: cantor: fails to build from source

2022-06-08 Thread Paul Gevers

Source: cantor
Version: 4:21.12.3-1
Severity: serious
Tags: ftbfs
Justification: ftbfs

Hi,

As part of the pseudo libluajit transition [1] I scheduled a rebuild
of cantor. It failed to build everywhere [2]. As can be seen on the
reproducible build project page, the build already fails in bookworm,
so not related to the libluajit changes in unstable.

Paul

[1] https://release.debian.org/transitions/html/libluajit2-support.html
[2] https://buildd.debian.org/status/package.php?p=cantor
[3] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/cantor.html

Bug#1012534: Description about not saving state across reboots is outdated

2022-06-08 Thread Ari Pollak

Package: power-profiles-daemon
Version: 0.10.1-3
Severity: minor

The package description says:

 Note that power-profiles-daemon does not save the currently active
 profile across system restarts and will always start with the "balanced"
 profile selected.

However, I believe this paragraph can now be removed as of 0.9. From
https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/blob/e83b4556bfd6a42fb9d969b8c5931dc8fc6de581/NEWS#L51
:

- Finally, the last used profile is now remembered across reboots.

Perhaps the upstream README.md can also be included in
/usr/share/doc/power-profiles-daemon, as it contains some useful
information.

Bug#1012533: ftp.debian.org: Please consider a firmware component for bookworm

2022-06-08 Thread Jonathan Carter

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: j...@debian.org

Dear FTP team

Recently, Steve McIntyre initiated a discussion[1] on debian-devel on
the future of firmware in Debian, and how we want to address it
as a project.

There are many viewpoints on this, but, it seems that we have some general
concensus that if we make an image with firmware on it more prominent to our
users, then it would be ideal to include only the firmware on such an image,
rather than enabling the entire non-free by default, which may lead to users
inadvertently installing non-free software on their computer (which is the
current status-quo on our non-free firmware-enabled images).

Paul's suggestion[2] of copying out firmare to non-free/firmware seems to
make a tremendous amount of sense. This will allow us to generate images
that have only firmware enabled for non-free packages by default, improving
the current status quo, and, it wouldn't require a GR.

Additionally, I think Paul's suggestion of starting with a package selection
of packages that starts with firmware-* or that puts files in /lib/firmware,
along with the cpu microcode packages, is a good starting point of what should
be included in there.

So, I'm asking the FTP team to please consider implementing this. Ideally,
reasonably soon, since we're about half a year away from entering the initial
stages of the freeze period, and having this in place sooner, rather than
later, would aid in making sure that image generation and other parts that
may depend on this could also have some kinks ironed out well ahead of the
release.

Thanks,

-Jonathan

[1] https://lists.debian.org/msgid-search/20220419002746.gt14...@tack.einval.com
[2] 
https://lists.debian.org/msgid-search/56b88c450a464743f84a2f451d20d554d81c3546.ca...@debian.org

Bug#1012532: inkscape: PDF import no longer works

2022-06-08 Thread Graeme Smecher

Package: inkscape
Version: 1.2-1
Severity: important
X-Debbugs-Cc: gsmec...@threespeedlogic.com

Dear Maintainer,

Versions 1.2-1 and 1.1.2-3+b1 are both currently unable to import PDFs.
Searching on-line suggests that a poppler dependency was missing or disabled at
build time.

Symptoms: (lightly edited to obscure path and filename)

$ inkscape /path/to/file.pdf
PDFInput::open: error opening document: file:///path/to/file.pdf
/path/to/file.pdf:1: parser error : Start tag expected, '<' not found
%PDF-1.6
^
ink_file_open: '/path/to/file.pdf' cannot be opened!
InkscapeApplication::document_open: Failed to open: /path/to/file.pdf
ConcreteInkscapeApplication::on_open: failed to create document!


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

Kernel: Linux 5.14.0-4-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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 inkscape depends on:
ii  lib2geom1.1.0  1.1-2+b1
ii  libatkmm-1.6-1v5   2.28.2-1
ii  libboost-filesystem1.74.0  1.74.0-14
ii  libc6  2.33-7
ii  libcairo-gobject2  1.16.0-5
ii  libcairo2  1.16.0-5
ii  libcairomm-1.0-1v5 1.12.2-4
ii  libcdr-0.1-1   0.1.6-2
ii  libfontconfig1 2.13.1-4.4
ii  libfreetype6   2.11.1+dfsg-1
ii  libgc1 1:8.0.6-1.1
ii  libgcc-s1  12-20220319-1
ii  libgdk-pixbuf-2.0-02.42.8+dfsg-1
ii  libglib2.0-0   2.72.0-1+b1
ii  libglibmm-2.4-1v5  2.66.2-2+b1
ii  libgomp1   12-20220319-1
ii  libgsl27   2.7.1+dfsg-3
ii  libgspell-1-2  1.9.1-4
ii  libgtk-3-0 3.24.33-1
ii  libgtkmm-3.0-1v5   3.24.5-1
ii  libharfbuzz0b  2.7.4-1
ii  libjpeg62-turbo1:2.1.2-1
ii  liblcms2-2 2.12~rc1-2
ii  libmagick++-6.q16-88:6.9.11.60+dfsg-1.3+b2
ii  libpango-1.0-0 1.50.6+ds-2
ii  libpangocairo-1.0-01.50.6+ds-2
ii  libpangoft2-1.0-0  1.50.6+ds-2
ii  libpangomm-1.4-1v5 2.46.2-1
ii  libpng16-161.6.37-3
ii  libpoppler-glib8   20.09.0-3.1
ii  libpoppler118  22.02.0-3
ii  libpotrace01.16-2
ii  libreadline8   8.1.2-1
ii  librevenge-0.0-0   0.0.4-6+b1
ii  librsvg2-common2.52.5+dfsg-3+b1
ii  libsigc++-2.0-0v5  2.10.4-2
ii  libsoup2.4-1   2.74.1-1
ii  libstdc++6 12-20220319-1
ii  libvisio-0.1-1 0.1.7-1+b1
ii  libwpg-0.3-3   0.3.3-1
ii  libx11-6   2:1.7.2-2+b1
ii  libxml22.9.13+dfsg-1
ii  libxslt1.1 1.1.34-4
ii  python33.9.8-1
ii  zlib1g 1:1.2.11.dfsg-4

Versions of packages inkscape recommends:
ii  aspell   0.60.8-4
ii  fig2dev  1:3.2.8b-1
ii  imagemagick  8:6.9.11.60+dfsg-1.3+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3+b2
ii  libimage-magick-perl 8:6.9.11.60+dfsg-1.3
ii  libwmf-bin   0.2.12-5
ii  python3-lxml 4.8.0-1
ii  python3-numpy1:1.21.5-1
ii  python3-scour0.38.2-2

Versions of packages inkscape suggests:
pn  dia   
pn  inkscape-tutorials
pn  libsvg-perl   
pn  pstoedit  
pn  python3-cssselect 
ii  python3-packaging 21.3-1
pn  python3-uniconvertor  
ii  ruby  1:2.7.6

-- no debconf information

Bug#1012531: chmod: changing permissions of any.ndb Operation not permitted

2022-06-08 Thread Tim McConnell

Package: clamav-unofficial-sigs
Version: 3.7.2-2.1
Severity: normal
X-Debbugs-Cc: tmcconnell...@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

What led up to the situation?
Installing the package

What exactly did you do (or not do) that was effective (or ineffective)?
Let cron run as per installation.

What was the outcome of this action?
Receive multiple errors:
chmod: changing permissions of '/var/cache/clamav-unofficial-sigs/ss-
dbs/porcupine.ndb': Operation not permitted
chmod: changing permissions of '/var/cache/clamav-unofficial-sigs/ss-
dbs/porcupine.ndb.sig': Operation not permitted

curl: (6) Could not resolve host: clamav.securiteinfo.com
curl: (6) Could not resolve host: clamav.securiteinfo.com
curl: (6) Could not resolve host: clamav.securiteinfo.com
curl: (6) Could not resolve host: clamav.securiteinfo.com
curl: (6) Could not resolve host: clamav.securiteinfo.com
curl: (6) Could not resolve host: clamav.securiteinfo.com
curl: (6) Could not resolve host: clamav.securiteinfo.com
curl: (6) Could not resolve host: clamav.securiteinfo.com
curl: (6) Could not resolve host: clamav.securiteinfo.com

Found on line information to comment out a DB and it still complains about DBs

What outcome did you expect instead? No errors and protection from additional
malware.

*** End of the template - remove these template lines ***


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

Kernel: Linux 5.17.0-1-rt-amd64 (SMP w/2 CPU threads; PREEMPT)
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 clamav-unofficial-sigs depends on:
ii  bind9-dnsutils [dnsutils]  1:9.18.1-1
ii  bind9-host [host]  1:9.18.1-1
ii  clamav 0.103.6+dfsg-1
ii  curl   7.83.0-1
ii  gnupg  2.2.35-2
ii  rsync  3.2.4-1

clamav-unofficial-sigs recommends no packages.

Versions of packages clamav-unofficial-sigs suggests:
ii  clamav-daemon  0.103.6+dfsg-1

-- no debconf information

-- debsums errors found:
debsums: changed file 
/usr/share/clamav-unofficial-sigs/conf.d/00-clamav-unofficial-sigs.conf (from 
clamav-unofficial-sigs package)

Bug#1012440: linux-image-amd64: Long time to load ACPI module battery.ko

2022-06-08 Thread Luca

Package: linux-image-5.10.0-14-amd64
Version: 5.10.0-14-amd64
Followup-For: Bug #1012440
X-Debbugs-Cc: macgyv...@gmail.com

> If you have a Thinkpad, then you should be able to update fw using fwupd 
> package. Also see https://fwupd.org/ for more info.
> If your device is not supported, then 'nagging' Lenovo about providing 
> updates through that site/service is your best chance. Using the Lenovo 
> forums may also help as when I last looked there, I wasn't the only one using 
> Linux ;-)

Unfortunately my laptop is a ThinkBook and seems not supported by fwupd. Anyhow 
I did non know of this project, thanks for the information: as suggested I will 
try to push Lenovo to consider adding my laptop model to the supported 
platforms.

> That's good as it means it's not entirely broken.

Yes, I must admint that with my present workaround I am quite happy anyhow.

> They all show the same delay, which strengthens my idea that it is a BIOS 
> issue. So AFAIC, no further test are needed.

ok.

> I think your best course of action is starting (or if one with your issues 
> already exists, joining) a thread on Lenovo's forums and/or try other ways to 
> contact their support. It's best to provide a full dmesg/kernel log and let 
> any filtering up to them. Other messages may give them clues which are not 
> immediate apparent to you.

I already posted [1] to Lenovo forum (concerning that many error coming from 
ACPI) few weeks ago with no answer up to now. I will update my post with the 
problem of battery module loading and mentioning this mail exchange. If no 
answer for some time I will try to contact support as well.

Thank you very much for your support!

Luca

[1] 
https://forums.lenovo.com/t5/Debian/Pleasse-fix-ACPI-on-next-BIOS-release/m-p/5148100

Bug#1012530: 4ti2: package header files

2022-06-08 Thread Torrance, Douglas


Source: 4ti2
Version: 1.6.9+ds-4
Severity: wishlist
X-Debbugs-Cc: dtorra...@debian.org

Dear Maintainer,

4ti2 exists as a shared library.  Currently, the library files themselves
are shipped for the 4ti2 binaries' use, in /usr/lib//4ti2.
However, the header files for use with these libraries are not packaged.

Would it be possible to ship these header files with the package, or possibly
in a new lib4ti2-dev binary package?  Then they could be used to build other
packages that depend on the 4ti2 library, e.g., LattE.

Thanks!
Doug


signature.asc
Description: PGP signature

Bug#1012529: libkf5xmlgui5: KDE doesn't remember window sizes

2022-06-08 Thread Felicia P

Package: libkf5xmlgui5
Version: 5.78.0-2
Severity: important

Dear Maintainer,

This is related to this bug: https://bugs.kde.org/show_bug.cgi?id=427875
and also mentioned here: 
https://www.reddit.com/r/kde/comments/pp08tg/kde_forgetting_window_size_and_placement/

KDE does not remember window sizes for windows.  Thus, when windows are
re-opened, they always are reset to a default size which is usually very
small and inconvenient because it is necessary to constantly be resizing
windows.

This bug has been attributed to the use of a second monitor and I can
confirm that at one point in the past I had an external monitor
connected to my laptop although it is no longer connected.



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

Kernel: Linux 5.16.0-0.bpo.4-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libkf5xmlgui5 depends on:
ii  libc6 2.31-13+deb11u3
ii  libkf5attica5 5.78.0-2
ii  libkf5configcore5 5.78.0-4
ii  libkf5configgui5  5.78.0-4
ii  libkf5configwidgets5  5.78.0-2
ii  libkf5coreaddons5 5.78.0-4
ii  libkf5globalaccel-bin 5.78.0-3
ii  libkf5globalaccel55.78.0-3
ii  libkf5guiaddons5  5.78.0-3
ii  libkf5i18n5   5.78.0-2
ii  libkf5iconthemes5 5.78.0-2
ii  libkf5itemviews5  5.78.0-2
ii  libkf5widgetsaddons5  5.78.0-2
ii  libkf5xmlgui-data 5.78.0-2
ii  libqt5core5a [qtbase-abi-5-15-2]  5.15.2+dfsg-9
ii  libqt5dbus5   5.15.2+dfsg-9
ii  libqt5gui55.15.2+dfsg-9
ii  libqt5network55.15.2+dfsg-9
ii  libqt5printsupport5   5.15.2+dfsg-9
ii  libqt5widgets55.15.2+dfsg-9
ii  libqt5xml55.15.2+dfsg-9
ii  libstdc++610.2.1-6

Versions of packages libkf5xmlgui5 recommends:
ii  libkf5xmlgui-bin  5.78.0-2

libkf5xmlgui5 suggests no packages.

-- no debconf information

Bug#1007717: Draft resolution for "Native source package format with non-native version"

2022-06-08 Thread Helmut Grohne

Hi Sean,

On Tue, Jun 07, 2022 at 04:35:24PM -0700, Sean Whitton wrote:
> I disagree with you that this is primarily about package ownership, and
> I think that we agree on more than you realise we do :)

Hmm. It's not that obvious. While it would be possible to remove the
choice of workflow from strong package ownership, the way we practice
package ownership presently grants that freedom. Therefore I think they
still are closely related.

> The git-first people are not making a trade-off between the maintainer's
> convenience and the convenience of others who want to work with the
> package.  The most important reason for wanting both (i) git-first
> workflows and (ii) uploads done with dgit, is to make it easier for
> people other than the maintainer to work with the package.  So, your
> priorities are quite in agreement with those of Ian, Sam, Russ and I.

I find it interesting that you seem to equate git-first with dgit. My
mental model separated those concepts and considered git-first workflows
on salsa as well. And once you equate them, you can derive a lot of
conclusions. In my previous mail, I stated that dgit provides the sort
of uniformity I was looking for quite many aspects. I'm less sure that
all git-first users are dgit users though.

> In other words, I would like to make weaker package ownership more
> possible, in a project with Debian's history, by improving our tools for
> dealing with packages for which you're not primary maintainer.

I do see how this is a dgit goal. It just seems to me that dgit bolts a
secondary workflow onto packages that maintainers are free to ignore
entirely. Some choose to use that dgit workflow exclusively and others
don't. In a sense, the problem with dgit is that it leaves too much
freedom to maintainers (and in a project like Debian, it really has to
do exactly that or it would run into straight opposition).

> What we disagree about is the extent to which the current tooling
> amounts to a failed experiment, such that we should give up on it and
> fall back to 'apt-get source'.  Many people strongly prefer 'dgit clone'
> to 'apt-get source' already, and the number of people switching to
> upload with 'dgit [--gbp] push-source' is steadily rising.  Against this
> backdrop, some of us are interested in git-first workflows for reducing
> the distance between the output of 'debcheckout' and 'dgit clone'.

Indeed, dgit kinda faces a chicken & egg problem and it seems that it is
quite good at solving it: The usefulness of dgit grows with its
adoption. I have looked into replacing my apt source workflow with dgit
clone a number of times already and will continue trying.

> It's completely reasonable that you're more sceptical about the
> prospects of solving the outstanding issues in this programme than
> others are, but surely we can agree that this is an ongoing piece of
> work rather than something we're sure we can reject?  And if keeping an
> old source package format around is needed for that work to continue,
> then that's a compelling reason to keep it around.

I think I take more issue with non-dgit git-first workflows than with
dgit ones, because dgit is so well documented and is a workflow that is
already shared by a noticeable fraction of the archive.

What is not entirely clear to me is why dgit requires the 1.0-with-diff
format features. It seems to me that it quite happily deals with a
number of 3.0 (quilt) packages already. I suppose that you'll now
explain to me how some git trees are not representable as 3.0 (quilt)
packages, but do those exist in practice or are those mostly
pathological?

> > How would you go about reducing them to a sane number?
> 
> The goal is to attack this problem on two fronts:
> 
> 1. reduce the need for uniformity by making it possible for people to
>get their cross-archive work done using 'dgit clone'

I've seen this argument multiple times already and indeed dgit solves
part of the uniformity issues. However, dgit history often lacks
maintainer history (and in that way is little better than apt source)
and it also lacks a collaboration feature that would save me from
sending a .debdiff to the bts. Possibly, such a collaboration feature is
out-of-scope for dgit, but then maybe it is not the kind of tool solving
the problem of streamlining cross-archive work.

Either way, my understanding is that unless maintainers switch to using
dgit primarily, we just gain a secondary workflow here.

> 2. develop git-first workflows that solve all the existing usecases.

Can i rephrase that as follows? Implement so many features into dgit
that its workflow covers the needs of existing workflows and hope for
maintainers to migrate to dgit.

It feels a bit like https://xkcd.com/927/ (14 competing standards ->
15). On the other hand, dgit is remarkably successful already.

I had hoped that we could kinda trim the available workflows eventually.
It seems like you want to let them all die slowly and concurrently.

> > You can

Bug#1012528: plasma-desktop-data: Application Launcher (Kickoff) search not working

2022-06-08 Thread Felicia P

Package: plasma-desktop-data
Version: 4:5.20.5-4
Severity: normal

Dear Maintainer,

The search bar in the Application Launcher (i.e. Kickoff) doesn't work.
This is probably related to this bug: 
https://bugs.kde.org/show_bug.cgi?id=443131

In my case, at one point in time I had an external monitor connected to
my laptop which is no longer connected.  I have also switched from the
default Application Launcher to Kickoff/Grid
(https://store.kde.org/p/1317546).  However, even after switching back
to the original Application Launcher, the search bar no longer works.




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

Kernel: Linux 5.16.0-0.bpo.4-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-desktop-data depends on:
ii  python3  3.9.2-3

Versions of packages plasma-desktop-data recommends:
ii  plasma-framework  5.78.0-3
ii  plasma-workspace  4:5.20.5-6
ii  qml-module-org-kde-activities 5.78.0-2
ii  qml-module-org-kde-kwindowsystem  5.78.0-2
ii  qml-module-org-kde-newstuff   5.78.0-4
ii  qml-module-qtquick-dialogs5.15.2-2

plasma-desktop-data suggests no packages.

-- no debconf information

Bug#1012527: kde-config-gtk-style: $HOME/.config/gtkrc-2.0 contents overwritten by KDE

2022-06-08 Thread Felicia P

Package: kde-config-gtk-style
Version: 4:5.20.5-2
Severity: normal

Dear Maintainer,

KDE is overwriting the contents of $HOME/.config/gtkrc-2.0   For
example, I have interface customizations in the file, yet when the file
gets overwritten by KDE, the customizations are erased.

The top of the file contains the line:

  # created by KDE Plasma, Wed Jun 8 11:07:53 2022

But no warning is given to the user that the contents of the file will
be overwritten.  

Due to the fact that the file is overwritten, it makes it impossible for
the user to provide their own customizations.

I did some research on this and it was suggested that it was xsettingsd
that is overwriting the file, however I uninstalled xsettingsd from my
system and the behavior is still occuring.  It has also been suggested
that the background service "GNOME/GTK Settings Syncrhonization Service"
is performing the overwriting.  I attempted to disable this background
service however it is still enabled.

Even if it is overwriting gtkrc-2.0, that does not seem to be the
correct behavior.

There is potentially more info about this here: 
https://bugs.kde.org/show_bug.cgi?id=417534



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

Kernel: Linux 5.16.0-0.bpo.4-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kde-config-gtk-style depends on:
ii  libc6 2.31-13+deb11u3
ii  libglib2.0-0  2.66.8-1
ii  libgtk-3-03.24.24-4+deb11u2
ii  libkdecorations2-5v5  4:5.20.5-1
ii  libkdecorations2private7  4:5.20.5-1
ii  libkf5configcore5 5.78.0-4
ii  libkf5configwidgets5  5.78.0-2
ii  libkf5coreaddons5 5.78.0-4
ii  libkf5dbusaddons5 5.78.0-2
ii  libkf5guiaddons5  5.78.0-3
ii  libqt5core5a  5.15.2+dfsg-9
ii  libqt5dbus5   5.15.2+dfsg-9
ii  libqt5gui55.15.2+dfsg-9
ii  libqt5svg55.15.2-3
ii  libstdc++610.2.1-6

Versions of packages kde-config-gtk-style recommends:
pn  xsettingsd | xsettings-kde  

Versions of packages kde-config-gtk-style suggests:
ii  kde-config-gtk-style-preview  4:5.20.5-2

-- no debconf information

Bug#1012513: apache2: CVE-2022-31813 CVE-2022-26377 CVE-2022-28614 CVE-2022-28615 CVE-2022-29404 CVE-2022-30522 CVE-2022-30556

2022-06-08 Thread Moritz Muehlenhoff

On Wed, Jun 08, 2022 at 07:51:28PM +0200, Yadd wrote:
> Hi,
> 
> those CVEs are tagged low/moderate by upstream, why did you tag this bug as 
> grave ?

Anything moderate or above should get fixed by the next Debian release IOW RC 
severity.

Cheers,
Moritz

Bug#991113: libpam-chroot: pam_chroot.so installed in wrong place - Not able to login after upgrade

2022-06-08 Thread M. Buecher

I had a look at the package source and only the paths in the file 
debian/rules [1] have to be changed.
Extend all `lib/$(DEB_HOST_MULTIARCH)` to 
`lib/$(DEB_HOST_MULTIARCH)/security` (added suffix `/security`).


[1] https://sources.debian.org/src/libpam-chroot/0.9-5/debian/rules/

Here the changed lines I tested successfully:

```
    mkdir -p 
$(CURDIR)/debian/libpam-chroot/lib/$(DEB_HOST_MULTIARCH)/security

    # Add here commands to install the package into debian/libpam-chroot
    $(MAKE) install DESTDIR=$(CURDIR)/debian/libpam-chroot 
LIBDIR=$(CURDIR)/debian/libpam-chroot/lib/$(DEB_HOST_MULTIARCH)/security 
INSTALL="install --strip-program=true"

```

Enable source repositories, install build tools and dependencies, then 
build and install:


```
nano /etc/apt/sources.list
apt-get update
apt-get install devscripts build-essential
cd /var/tmp
apt-get build-dep libpam-chroot
apt-get source libpam-chroot
cd libpam-chroot-0.9*/
sed -i -e 's#lib/\$(DEB_HOST_MULTIARCH)\( 
\|$\)#lib/\$(DEB_HOST_MULTIARCH\)/security\1#' debian/rules

debuild -us -uc
#
cd /var/tmp
dpkg -i libpam-chroot_0.9*.deb
```

Bug#1012457: calibre: segfault on startup for different locales

2022-06-08 Thread yokota

Tags: confirmed

It also reproduce with other non-UTF-8 locales.

1. Edit "/etc/locale.gen" and setup non-UTF-8 locale
2. Use non-UTF-8 locale for Calibre
  $ LANG=ja_JP.EUC-JP calibre
  $ LANG=en_US.ISO-8859-15 calibre
3. Segmentation fault

>   If LC_CTYPE=ro_RO then calibre segfaults on startup
>   If LC_CTYPE is unset (or LC_ALL=C) then calibre starts and works normally.

> Locale: LANG=en_GB.UTF-8, LC_CTYPE=ro_RO (charmap=ISO-8859-2), 
> LANGUAGE=en_GB:en

Current Linux system recommends UTF-8 based locale.
"ro_RO" uses legacy encoding "ISO-8859-2" and it's not recommended for
modern Linux systems.
Use UTF-8 based ro_RO locale "ro_RO.UTF-8" to avoids this bug.

1. Edit "/etc/locale.gen" and adds "ro_RO.UTF-8" locale support.
Use "dpkg-reconfigure locales" command for easy setup.
It also drops legacy locale support.
 # dpkg-reconfigure locales
2. Use "ro_RO.UTF-8" for Calibre
 $ LC_CTYPE=ro_RO.UTF-8 calibre
 $ LANG=ro_RO.UTF-8 calibre
3. Works well.

> The offcial calibre version 5.43.0 does not segfault on the same machine.
> This is a debian specific issue.

Official calibre uses embedded Python, and not uses system Python.
Embedded Python uses limited locale support, and this avoids locale problems.

--
YOKOTA Hiroshi

Bug#1012526: psmisc: killall doesn't work with kernels older than 5.3

2022-06-08 Thread Emil

Package: psmisc
Version: 23.5-1
Severity: normal

$ killall fetchmail
fetchmail(662): Function not implemented
fetchmail: no process found

__NR_pidfd_send_signal is defined in /usr/include/asm-generic/unistd.h
and the my_send_signal function in killall.c will syscall pidfd_send_signal
which is not implemented in kernels older than 5.3 and it fails.

There should be a test at compile time to use kill(pid, sig) instead for
older kernels.

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

Kernel: Linux 4.14.269 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=ro_RO (charmap=ISO-8859-2), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages psmisc depends on:
ii  libc6  2.33-7
ii  libtinfo6  6.3+20220423-2

psmisc recommends no packages.

psmisc suggests no packages.

-- no debconf information

Bug#1011339: [Pkg-javascript-devel] Bug#1011339: [Pkg-openssl-devel] Bug#1011339: openssl: missing errors strings on mipsel

2022-06-08 Thread Jérémy Lal

Hi Sebastian,

Le dim. 29 mai 2022 à 16:27, Jérémy Lal  a écrit :

>
>
> Le jeu. 26 mai 2022 à 19:23, Sebastian Andrzej Siewior <
> sebast...@breakpoint.cc> a écrit :
>
>> On 2022-05-26 13:49:13 [+0200], Jérémy Lal wrote:
>> > Thanks for the feedback.
>> np.
>>
>> > Indeed, the latest nodejs version (18.x) embeds an updated openssl.cnf,
>> > which is exactly the one
>> > of the openssl debian package, without the [ssl_sect] part at the end.
>> >
>> > Why this fails only on mipsel is a mystery to me, maybe some race
>> condition
>> > when initializing openssl,
>> > but this is not a bug.
>>
>> me, too. If there is anything you want me to look at, just yell. For now
>> I consider this handled.
>
>
>
> This succeeds:
> ./node test/parallel/test-crypto-key-objects.js
>
> This fails only on mipsel (tested on eller porterbox)
> OPENSSL_CONF=/etc/ssl/openssl.cnf ./node
> test/parallel/test-crypto-key-objects.js
>
> I suppose the problem comes from openssl:
> - nodejs code calling OPENSSL_init_ssl doesn't depend on mips
> - nodejs runs on other "slow" architectures, if it was a race condition we
> would see it there sometimes.
>

Any hint or idea about this ? Even wild ideas that I could try,
before I have to remove the files from mips.

Jérémy

Bug#1012525: gensquashfs: double free detected in tcache 2

2022-06-08 Thread Marvin Renich

Package: squashfs-tools-ng
Version: 1.1.4-1
Severity: minor

In mknode.c:fstree_mknode, if the parent directory link count is too
large, the tree_node_t that was just calloc'ed is free'd before
returning.  However, it has already been linked to the parent's children
list.  This causes a double free of that pointer when the parent is
subsequently free'd.  Also, all of the other children may not be free'd
and/or free may be called with invalid pointers, depending on whether
the just-freed memory gets reallocated and used before exit.

This is only a minor bug, because gensquashfs is about to exit with an
error, but it clutters stderr with irrelevant messages.

I didn't follow the error return path to be sure, but I think if the
call to free(n) just before errno = EMLINK is removed, everything will
get properly freed farther up the call stack.

...Marvin


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

Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages squashfs-tools-ng depends on:
ii  libc6 2.33-7
ii  liblzma5  5.2.5-2.1
ii  liblzo2-2 2.10-2
ii  libselinux1   3.3-1+b2
ii  libsquashfs1  1.1.4-1
ii  libzstd1  1.5.2+dfsg-1
ii  zlib1g1:1.2.11.dfsg-4

squashfs-tools-ng recommends no packages.

squashfs-tools-ng suggests no packages.

-- no debconf information

Bug#1012524: libass: PGP signature and i386 assembly

2022-06-08 Thread Oneric

Source: libass
Version: 1:0.16.0-1
Severity: minor

Hi!

I noticed 7a4ee5d47246b80de8bb16ee75faf65bd9cd91b5 recently added the PGP 
key used to sign the last release for future verification. However, as the
0.16.0 release notes and the MAINTAINERS file note, future releases may
also be signed with a few other keys listed in the MAINTAINERS file.

To my understanding something like the following will allow uscan to match 
with any of the authorised keys (alternatively fetch from a keyserver by 
IDs as found in MAINTAINERS):

  alias gpg_t='gpg --no-default-keyring --keyring /tmp/tmp.keys'
  curl https://github.com/astiob.gpg | gpg_t --import -
  curl https://github.com/TheOneric.gpg | gpg_t --import -
  curl https://github.com/rcombs.gpg | gpg_t --import -
  gpg_t --export --export-options export-minimal --armor > 
debian/upstream/signing-key.asc
  # To verify which keys are included
  gpg --list-packets debian/upstream/signing-key.asc


While updating to 0.16.0 --with-pic was also added for i386 assembly.
However, it appears the nasm dependency is still limited to any-amd64,
after it was in the past[1] removed from i386 due to being not PIC.
The build log[2] confirms that no assembly is built on i386.
Can this be reenabled now that PIC assembly is supported?

Something to take note of is that previously assembly was enabled also for
kfreebsd-i386. Since then, we changed[3] the 32bit assembly configuration 
for BSD systems upstream to fix an issue with regular FreeBSD.
If it truly worked before on kfreebsd-i386 (other than non-PIC being at
odds with the guidelines), then this change may inadvertently have broken 
kfreebsd-i386.
I tried to test it, but the old kfreebsd-i386 installer I found always 
crashes or gets stuck early on in my VM and I wasn't able to set up a 
chroot or multiarch from a kfreebsd-amd64 host either. I can however 
confirm that on kfreebsd-64 the assembly works as intended.


Cheers

Oneric


[1]: 
https://salsa.debian.org/multimedia-team/libass/-/commit/d9eae1f0aefacf9b8c838cb5108dcc100f336e0b
[2]: 
https://buildd.debian.org/status/fetch.php?pkg=libass=i386=1%3A0.16.0-1=1652520467=0
[3]: 
https://github.com/libass/libass/commit/3855299b0721acfeb5391a140cd6df65ce2b73d2


signature.asc
Description: PGP signature

Bug#1012523: gnuplot: Please review the build-dependencies

2022-06-08 Thread Laurent Bigonville

Source: gnuplot
Version: 5.4.2+dfsg2-2
Severity: normal

Hello,

gnuplot is not building on some ports due to the build-dependencies
against some Qt libraries (mainly QtWebkit), but looking in the code it
seems that some of these are not needed anymore (removing these BD
results in the same binary packages)

In the configure I see: PKG_CHECK_MODULES_NOFAIL(QT, [Qt5Core Qt5Gui Qt5Network 
Qt5Svg Qt5PrintSupport])

So AFAICS, at least libqt5webkit5-dev and libqt5opengl5-dev are not
needed anymore

Could you please check?

Kind regards,
Laurent Bigonville


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

Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#1012513: apache2: CVE-2022-31813 CVE-2022-26377 CVE-2022-28614 CVE-2022-28615 CVE-2022-29404 CVE-2022-30522 CVE-2022-30556

2022-06-08 Thread Yadd

Hi,

those CVEs are tagged low/moderate by upstream, why did you tag this bug as 
grave ?

Cheers,
Yadd

Le Mercredi, Juin 08, 2022 17:49 CEST, Moritz Mühlenhoff  a 
écrit:

> Source: apache2
> X-Debbugs-CC: t...@security.debian.org
> Severity: grave
> Tags: security
>
> Hi,
>
> The following vulnerabilities were published for apache2.
>
> CVE-2022-31813[0]:
> | Apache HTTP Server 2.4.53 and earlier may not send the X-Forwarded-*
> | headers to the origin server based on client side Connection header
> | hop-by-hop mechanism. This may be used to bypass IP based
> | authentication on the origin server/application.
>
> CVE-2022-26377[1]:
> | Inconsistent Interpretation of HTTP Requests ('HTTP Request
> | Smuggling') vulnerability in mod_proxy_ajp of Apache HTTP Server
> | allows an attacker to smuggle requests to the AJP server it forwards
> | requests to. This issue affects Apache HTTP Server Apache HTTP Server
> | 2.4 version 2.4.53 and prior versions.
>
> CVE-2022-28614[2]:
> | The ap_rwrite() function in Apache HTTP Server 2.4.53 and earlier may
> | read unintended memory if an attacker can cause the server to reflect
> | very large input using ap_rwrite() or ap_rputs(), such as with
> | mod_luas r:puts() function.
>
> CVE-2022-28615[3]:
> | Apache HTTP Server 2.4.53 and earlier may crash or disclose
> | information due to a read beyond bounds in ap_strcmp_match() when
> | provided with an extremely large input buffer. While no code
> | distributed with the server can be coerced into such a call, third-
> | party modules or lua scripts that use ap_strcmp_match() may
> | hypothetically be affected.
>
> CVE-2022-29404[4]:
> | In Apache HTTP Server 2.4.53 and earlier, a malicious request to a lua
> | script that calls r:parsebody(0) may cause a denial of service due to
> | no default limit on possible input size.
>
> CVE-2022-30522[5]:
> | If Apache HTTP Server 2.4.53 is configured to do transformations with
> | mod_sed in contexts where the input to mod_sed may be very large,
> | mod_sed may make excessively large memory allocations and trigger an
> | abort.
>
> CVE-2022-30556[6]:
> | Apache HTTP Server 2.4.53 and earlier may return lengths to
> | applications calling r:wsread() that point past the end of the storage
> | allocated for the buffer.
>
> As usual Apache fails to directly identify fixing commits at
> https://httpd.apache.org/security/vulnerabilities_24.html
>
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2022-31813
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31813
> [1] https://security-tracker.debian.org/tracker/CVE-2022-26377
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26377
> [2] https://security-tracker.debian.org/tracker/CVE-2022-28614
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28614
> [3] https://security-tracker.debian.org/tracker/CVE-2022-28615
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28615
> [4] https://security-tracker.debian.org/tracker/CVE-2022-29404
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29404
> [5] https://security-tracker.debian.org/tracker/CVE-2022-30522
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30522
> [6] https://security-tracker.debian.org/tracker/CVE-2022-30556
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30556
>
> Please adjust the affected versions in the BTS as needed.
>

Bug#991113: libpam-chroot: pam_chroot.so installed in wrong place - Not able to login after upgrade

2022-06-08 Thread M. Buecher

Package: libpam-chroot
Version: 0.9-5
Followup-For: Bug #991113
X-Debbugs-Cc: maddes+deb...@maddes.net

Dear Maintainer,

the library pam_chroot.so is installed in the wrong location, therefore it 
cannot be loaded.
This prevents anyone (incl. root) to log into systems that require that module.
Changed the pam module to optional via a live linux and found an error message 
in auth.log:
```
Jun  8 19:30:16 test-debian11 sshd[459]: PAM unable to dlopen(pam_chroot.so): 
/lib/security/pam_chroot.so: cannot open shared object file: No such file or 
directory
Jun  8 19:30:16 test-debian11 sshd[459]: PAM adding faulty module: pam_chroot.so
```

Current wrong location: `/usr/lib/x86_64-linux-gnu/pam_chroot.so`
Correct location: /lib/security/pam_chroot.so -> 
/usr/lib/x86_64-linux-gnu/security/

Workaround:
Boot from a live linux system and move/copy/link file to correct location.
`ln -v -s -r -t /usr/lib/x86_64-linux-gnu/security/ 
/usr/lib/x86_64-linux-gnu/pam_chroot.so`

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

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

Versions of packages libpam-chroot depends on:
ii  libc6 2.31-13+deb11u3
ii  libpam0g  1.4.0-9+deb11u1

libpam-chroot recommends no packages.

libpam-chroot suggests no packages.

-- no debconf information

Bug#1012522: gensquashfs: "creating tree node: Too many links" error message is confusing and uninformative

2022-06-08 Thread Marvin Renich

Package: squashfs-tools-ng
Version: 1.1.4-1
Severity: minor

The error text "Too many links" from EMLINK is intended to refer to the
number of hard links to an inode, but is misused in fstree_mknode
(mknode.c) to mean "directory has too many entries" (perhaps a squashfs
limit?).  This is confusing and doesn't help the user find the offending
part of the directory structure.  Reading the source code was required
to determine the real problem.

Also, the name of the offending directory is not printed, so once the
real problem is identified, finding the directory requires a little
shell scripting to be used with find -exec to get the information that
could have been printed by gensquashfs with the error message.

In fstree_from_dir.c:populate_dir where fstree_mknode is called, you
could check errno for EMLINK and print a more informative message
instead of calling perror.  I did not look at calls to fstree_mknode in
other files, but there are only a few to check; perhaps they would also
benefit from a similar fix.

Thanks...Marvin


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

Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages squashfs-tools-ng depends on:
ii  libc6 2.33-7
ii  liblzma5  5.2.5-2.1
ii  liblzo2-2 2.10-2
ii  libselinux1   3.3-1+b2
ii  libsquashfs1  1.1.4-1
ii  libzstd1  1.5.2+dfsg-1
ii  zlib1g1:1.2.11.dfsg-4

squashfs-tools-ng recommends no packages.

squashfs-tools-ng suggests no packages.

-- no debconf information

Bug#977530: vtk7: reproducible builds bugs not fixed

It does not appear that these bugs were actually fixed in vtk7:

  vtk7: reproducible builds: unpredictible ordering in documentation
  vtk7: reproducible builds: Embeds running kernel into XdmfConfig.h
  vtk7: reproducible builds: build timestamps in documentation

It still fails to build reproducibly:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/vtk7.html

No versions uploaded to debian ever built reproducibly:

  https://tests.reproducible-builds.org/debian/history/amd64/vtk7.html

I'm not sure if the patches were once included and then reverted, or
never applied... regardless, please consider applying them in the next
upload!


Thanks for maintaining vtk7!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1012521: RM: python3-freecontact [armel] -- RoQA; broken due to libfreecontact0v5 removal on armel

2022-06-08 Thread Sebastian Ramacher

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: sramac...@debian.org, debian-med-packag...@lists.alioth.debian.org

Same as #1012520

Cheers
-- 
Sebastian Ramacher

Bug#1012520: RM: libfreecontact-perl [armel] -- RoQA; broken due to libfreecontact0v5 removal

2022-06-08 Thread Sebastian Ramacher

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: sramac...@debian.org

The removal of libfreecontact0v5 on armel (#1008786) renders
libfreecontact-perl uninstallable. So please also remove it.

Cheers
-- 
Sebastian Ramacher

Bug#1012519: pmdk: FTBFS on ppc64el due to test failure

2022-06-08 Thread Andreas Hasenack

Package: pmdk
Version: 1.12.0-1
Severity: normal

Dear Maintainer,

pmdk is failing[1] to build on ppc64el due to a test failure on that platform:

obj_ctl_arenas/TEST3: SETUP (check/pmem/nondebug/drd)
obj_ctl_arenas/TEST3 failed with Valgrind. See drd3.log. Last 20 lines below.
obj_ctl_arenas/TEST3 drd3.log ==3541982==by 0x491954B: _Malloc (alloc.c:72)
obj_ctl_arenas/TEST3 drd3.log ==3541982==by 0x491967F: Zalloc (alloc.c:100)
obj_ctl_arenas/TEST3 drd3.log ==3541982==by 0x493883B:
heap_arena_new (heap.c:184)
obj_ctl_arenas/TEST3 drd3.log ==3541982==by 0x493A007:
heap_arena_create (heap.c:1215)
obj_ctl_arenas/TEST3 drd3.log ==3541982==by 0x494F3F7:
ctl__create_runnable (pmalloc.c:797)
obj_ctl_arenas/TEST3 drd3.log ==3541982==by 0x491FD8F:
ctl_exec_query_runnable (ctl.c:255)
obj_ctl_arenas/TEST3 drd3.log ==3541982==by 0x49206AB: ctl_query (ctl.c:307)
obj_ctl_arenas/TEST3 drd3.log ==3541982==by 0x494C62F:
pmemobj_ctl_execU (obj.c:3344)
obj_ctl_arenas/TEST3 drd3.log ==3541982==by 0x494C62F:
pmemobj_ctl_exec (obj.c:3380)
obj_ctl_arenas/TEST3 drd3.log ==3541982==by 0x1844FB:
worker_arenas_flag (obj_ctl_arenas.c:164)
obj_ctl_arenas/TEST3 drd3.log ==3541982==by 0x48B462F: ??? (in
/usr/libexec/valgrind/vgpreload_drd-ppc64le-linux.so)
obj_ctl_arenas/TEST3 drd3.log ==3541982==by 0x49B8107:
start_thread (pthread_create.c:481)
obj_ctl_arenas/TEST3 drd3.log ==3541982== Other segment start (thread 2)
obj_ctl_arenas/TEST3 drd3.log ==3541982==(thread finished, call
stack no longer available)
obj_ctl_arenas/TEST3 drd3.log ==3541982== Other segment end (thread 2)
obj_ctl_arenas/TEST3 drd3.log ==3541982==(thread finished, call
stack no longer available)
obj_ctl_arenas/TEST3 drd3.log ==3541982==
obj_ctl_arenas/TEST3 drd3.log ==3541982==
obj_ctl_arenas/TEST3 drd3.log ==3541982== For lists of detected and
suppressed errors, rerun with: -s
obj_ctl_arenas/TEST3 drd3.log ==3541982== ERROR SUMMARY: 4 errors from
3 contexts (suppressed: 44 from 44)
RUNTESTS: stopping: obj_ctl_arenas/TEST3 failed, TEST=check FS=any
BUILD=nondebug



1. https://buildd.debian.org/status/logs.php?arch=ppc64el=pmdk=1.12.0-1

Bug#1012492: /etc/adduser.conf.dpkg-save created by postinst

2022-06-08 Thread Jason Franklin

On Wed, Jun 08, 2022 at 06:01:11PM +0200, Marc Haber wrote:
> On Wed, Jun 08, 2022 at 10:11:48AM -0400, Jason Franklin wrote:
> > Personally, I think we should simply install a default adduser.conf file
> > and remove all of the debconf stuff from the post install script.
> 
> That was like the gist of a short discussion I initiated in March, see
> https://lists.debian.org/debian-boot/2022/03/msg00099.html

Aha! Wonderful. There is precedent for this idea.

This thread also explains the context in which this debconf question had
been useful (i.e., the installer). I had not been able to guess this.

We would also be able to finally close this one:

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

> We just need to make sure to make a smooth transitoin, testing
> installation and upgrades from a system with a locally changed
> adduser.conf, a locally removed adduser.conf and adduser.conf unchanged
> from the package. Local changes must be preserved.

I had thought this would be gracefully handled by Dpkg, but maybe my
understanding is not complete here.

Simply changing the debian/install file to properly install the default
/etc/adduser.conf file would work, I had thought (also removing all of
the newly obsolete stuff in the maintscripts).

The result would be that installing/upgrading adduser would prompt for
whether or not you want to keep the local version or take the
maintainer's version, etc.

This prompt would depend on whether, for example, --force-confmiss or
--force-conf{old,new} are passed to Dpkg, usually via apt.

At least I thought that's how it would work.

If we're on the same page here, should I put a patch together?

-- 
Jason Franklin

Bug#1012518: python3-distutils: CFLAGS and CPPFLAGS leaking in LD flags

2022-06-08 Thread Laurent Bigonville

Package: python3-distutils
Version: 3.9.12-1
Severity: important

Hello,

When trying to build matplotlib (that uses hardening +pie) on x32,
-specs=/usr/share/dpkg/pie-compile.specs ends up being added to the
flags passed to the linker. This breaks the build with:

x86_64-linux-gnux32-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
-specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro -Wl,-z,now -g -O2 
-ffile-prefix-map=/tmp/matplotlib-3.5.1=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_bezier_arc.o
 
build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_curves.o
 
build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_image_filters.o
 
build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_trans_affine.o
 
build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_vcgen_contour.o
 
build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_vcgen_dash.o
 
build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_vcgen_stroke.o
 
build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_vpgen_segmentator.o
 
build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/src/_backend_agg.o 
build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/src/_backend_agg_wrapper.o
 
build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/src/checkdep_freetype2.o
 
build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/src/py_converters.o
 -o 
build/lib.linux-x86_64-3.9/matplotlib/backends/_backend_agg.cpython-39-x86_64-linux-gnux32.so
 -lfreetype
/usr/bin/ld: /tmp/cc7JfqHN.ltrans3.ltrans.o: warning: relocation against 
`PyExc_ValueError' in read-only section `.text'
/usr/bin/ld: /tmp/cc7JfqHN.ltrans0.ltrans.o: relocation R_X86_64_PC32 against 
undefined symbol `_Py_NoneStruct' can not be used when making a shared object; 
recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

Looking in distutils code (/usr/lib/python3.9/distutils/sysconfig.py) it
seems that the CFLAGS and CPPFLAGS are leaking in the flags passed to
the linkers (LDFLAGS/LDSHARED)

Is that expected?

Kind regards,
Laurent Bigonville


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

Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages python3-distutils depends on:
ii  python3  3.10.4-1+b1
ii  python3-lib2to3  3.9.12-1

python3-distutils recommends no packages.

python3-distutils suggests no packages.

-- no debconf information

Bug#1012517: rust-coreutils: FTBFS on some platforms

2022-06-08 Thread Sylvestre Ledru

Package: rust-coreutils
Version: 0.0.6-1~exp1
Severity: normal

Hello myself,

Opening this bug to list dependencies to unbreak the builds on other platforms

We are blocked by:
https://github.com/byllyfish/exacl/issues/107
https://github.com/rust-num/num-traits/issues/239
(at least)

Cheers,
Sylvestre


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'oldstable-updates'), (500, 
'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, 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 rust-coreutils depends on:
ii  libc6  2.33-1
ii  libgcc-s1  11.2.0-12

rust-coreutils recommends no packages.

rust-coreutils suggests no packages.

-- no debconf information

Bug#790943: Root and local certificate location clash

2022-06-08 Thread Sergey Ponomarev

You made a very good investigation on the topic.

I agree that a public cert shouldn't be placed into the same folder as
CA certs. There is some mention of a weird bug
https://serverfault.com/a/840191/442430
Instead I think that both private key and cert should be merged into a
one file and placed into /etc/ssl/private/.
It looks like there were a lot of discussions but we didn't come to a
single agreement about the place to store certs and how to manage
them.
Please read my proposition here
https://github.com/certbot/certbot/issues/1425#issuecomment-1150116062
I'll appreciate any feedback.

Regards,
Sergey Ponomarev, stokito.com

Bug#1009431: skimage: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.9 3.10" returned exit code 13

2022-06-08 Thread Graham Inggs

Control: tags -1 + patch ftbfs
Control: unblock -1 by 1010595

The attached patch, based on an imageio upstream commit [1], fixes the
issue with Pillow 9.1 for me.


[1] https://github.com/imageio/imageio/pull/775
Description: handle PIL palettes with <256 colors
 based on https://github.com/imageio/imageio/pull/775
Bug-Debian: https://bugs.debian.org/1009431
Author: Graham Inggs 
Last-Update: 2022-06-08

--- a/skimage/io/_plugins/pil_plugin.py
+++ b/skimage/io/_plugins/pil_plugin.py
@@ -160,7 +160,8 @@
 if pil_image.mode != 'P':
 raise ValueError('pil_image.mode must be equal to "P".')
 # get palette as an array with R, G, B columns
-palette = np.asarray(pil_image.getpalette()).reshape((256, 3))
+# Note: starting in pillow 9.1 palettes may have less than 256 entries
+palette = np.asarray(pil_image.getpalette()).reshape((-1, 3))
 # Not all palette colors are used; unused colors have junk values.
 start, stop = pil_image.getextrema()
 valid_palette = palette[start:stop + 1]

Bug#1012347: arm64 CPU Phytium FT-2000/4 cpuinfo

2022-06-08 Thread Helge Kreutzmann

Hello Punit,
On Wed, Jun 08, 2022 at 09:40:08AM +0100, Punit Agrawal wrote:
> Helge Kreutzmann  writes:
> > On Tue, Jun 07, 2022 at 09:47:03AM +0100, Punit Agrawal wrote:
> >> "xiao sheng wen(肖盛文)"  writes:
> >> 
> >> > 在 2022/6/5 21:18, Helge Kreutzmann 写道:
> >> >>> CPU implementer: 0x70
> >> >> If you happen to know a table of "CPU implementer" for ARM (i.e. a
> >> >> mapping of the number to the company), then I can easily add even
> >> >> more :-))
> >> 
> >> You can see the list of currently assigned implementer codes in the
> >> description of the MIDR_EL1 register[0] in the Arm developer
> >> documentation.
> >> 
> >> [0] 
> >> https://developer.arm.com/documentation/ddi0595/2021-06/External-Registers/MIDR-EL1--Main-ID-Register
> >
> > Thanks a lot, I added those, should greatly improve detection on Arm.
> > Interestingly, though, the recently reported "Phytium" is not on the
> > list. (Which what this report was initially about)
> 
> Indeed, I noticed it too after sending the mail. Sorry, I don't know
> what's going on there. Probably need somebody from Arm.com to add their
> 2c.

I don't think we need to bother, the current state is now vastly
improved, and I take Phytium as a "bonus".

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1012490: zh_CN.po translate for linuxinfo package

2022-06-08 Thread Helge Kreutzmann

Hello xiao,
On Wed, Jun 08, 2022 at 05:51:18PM +0800, xiao sheng wen (肖盛文) wrote:
> O, the attachment file zh_CN.po is repeat in the last bugreport, sorry!
> 
> Only need use one.

thanks a lot! 

I'll include it on the weekend.

Greetings

   Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1012494: gdb: FTBFS on ppc family: No rule to make target 'info' in build/default/sim/ppc

2022-06-08 Thread Simon McVittie

Control: tags -1 + fixed-upstream patch

On Wed, 08 Jun 2022 at 12:53:42 +0100, Simon McVittie wrote:
> I think the solution to this might be upstream commit acbf56d7 (trying it
> now on the ppc64el porterbox).

That seems to have been successful. MR available here:
https://salsa.debian.org/gdb-team/gdb/-/merge_requests/12

smcv

Bug#1012502: [Pkg-sssd-devel] Bug#1012502: sssd: authentication fails with latest sssd

2022-06-08 Thread Michael Stone


On Wed, Jun 08, 2022 at 05:41:00PM +0300, Timo Aaltonen wrote:

Did you have 2.7.0 at some point?


2.7.0-1 was installed 2022-05-27
2.7.0-1+b1 was installed 2022-05-29

no issues with either of those; I reverted to 2.6.3 just because it was 
easier to grab from the mirrors.

Bug#1012492: /etc/adduser.conf.dpkg-save created by postinst

2022-06-08 Thread Marc Haber

On Wed, Jun 08, 2022 at 10:11:48AM -0400, Jason Franklin wrote:
> Personally, I think we should simply install a default adduser.conf file
> and remove all of the debconf stuff from the post install script.

That was like the gist of a short discussion I initiated in March, see
https://lists.debian.org/debian-boot/2022/03/msg00099.html

We just need to make sure to make a smooth transitoin, testing
installation and upgrades from a system with a locally changed
adduser.conf, a locally removed adduser.conf and adduser.conf unchanged
from the package. Local changes must be preserved.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1012516: sox: CVE-2022-31650 CVE-2022-31651

Source: sox
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerabilities were published for sox.

CVE-2022-31650[0]:
| In SoX 14.4.2, there is a floating-point exception in
| lsx_aiffstartwrite in aiff.c in libsox.a.

CVE-2022-31651[1]:
| In SoX 14.4.2, there is an assertion failure in rate_init in rate.c in
| libsox.a.

https://sourceforge.net/p/sox/bugs/360/

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-31650
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31650
[1] https://security-tracker.debian.org/tracker/CVE-2022-31651
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31651

Please adjust the affected versions in the BTS as needed.

Bug#1012515: dwarfutils: CVE-2022-32200

Source: dwarfutils
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for dwarfutils.

CVE-2022-32200[0]:
| libdwarf 0.4.0 has a heap-based buffer over-read in
| _dwarf_check_string_valid in dwarf_util.c.

https://github.com/davea42/libdwarf-code/issues/116
https://www.prevanders.net/dwarfbug.html#DW202205-001

Fixed by: 
https://github.com/davea42/libdwarf-code/commit/8151575a6ace77d005ca5bb5d71c1bfdba3f7069

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-32200
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32200

Please adjust the affected versions in the BTS as needed.

Bug#1012513: apache2: CVE-2022-31813 CVE-2022-26377 CVE-2022-28614 CVE-2022-28615 CVE-2022-29404 CVE-2022-30522 CVE-2022-30556

Source: apache2
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for apache2.

CVE-2022-31813[0]:
| Apache HTTP Server 2.4.53 and earlier may not send the X-Forwarded-*
| headers to the origin server based on client side Connection header
| hop-by-hop mechanism. This may be used to bypass IP based
| authentication on the origin server/application.

CVE-2022-26377[1]:
| Inconsistent Interpretation of HTTP Requests ('HTTP Request
| Smuggling') vulnerability in mod_proxy_ajp of Apache HTTP Server
| allows an attacker to smuggle requests to the AJP server it forwards
| requests to. This issue affects Apache HTTP Server Apache HTTP Server
| 2.4 version 2.4.53 and prior versions.

CVE-2022-28614[2]:
| The ap_rwrite() function in Apache HTTP Server 2.4.53 and earlier may
| read unintended memory if an attacker can cause the server to reflect
| very large input using ap_rwrite() or ap_rputs(), such as with
| mod_luas r:puts() function.

CVE-2022-28615[3]:
| Apache HTTP Server 2.4.53 and earlier may crash or disclose
| information due to a read beyond bounds in ap_strcmp_match() when
| provided with an extremely large input buffer. While no code
| distributed with the server can be coerced into such a call, third-
| party modules or lua scripts that use ap_strcmp_match() may
| hypothetically be affected.

CVE-2022-29404[4]:
| In Apache HTTP Server 2.4.53 and earlier, a malicious request to a lua
| script that calls r:parsebody(0) may cause a denial of service due to
| no default limit on possible input size.

CVE-2022-30522[5]:
| If Apache HTTP Server 2.4.53 is configured to do transformations with
| mod_sed in contexts where the input to mod_sed may be very large,
| mod_sed may make excessively large memory allocations and trigger an
| abort.

CVE-2022-30556[6]:
| Apache HTTP Server 2.4.53 and earlier may return lengths to
| applications calling r:wsread() that point past the end of the storage
| allocated for the buffer.

As usual Apache fails to directly identify fixing commits at
https://httpd.apache.org/security/vulnerabilities_24.html

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-31813
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31813
[1] https://security-tracker.debian.org/tracker/CVE-2022-26377
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26377
[2] https://security-tracker.debian.org/tracker/CVE-2022-28614
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28614
[3] https://security-tracker.debian.org/tracker/CVE-2022-28615
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28615
[4] https://security-tracker.debian.org/tracker/CVE-2022-29404
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29404
[5] https://security-tracker.debian.org/tracker/CVE-2022-30522
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30522
[6] https://security-tracker.debian.org/tracker/CVE-2022-30556
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30556

Please adjust the affected versions in the BTS as needed.

Bug#1012512: libengine-gost-openssl1.1: CVE-2022-29242

Source: libengine-gost-openssl1.1
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for libengine-gost-openssl1.1.

CVE-2022-29242[0]:
| GOST engine is a reference implementation of the Russian GOST crypto
| algorithms for OpenSSL. TLS clients using GOST engine when ciphersuite
| `TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC` is agreed and the
| server uses 512 bit GOST secret keys are vulnerable to buffer
| overflow. GOST engine version 3.0.1 contains a patch for this issue.
| Disabling ciphersuite `TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC`
| is a possible workaround.

https://github.com/gost-engine/engine/security/advisories/GHSA-2rmw-8wpg-vgw5

Patches:
https://github.com/gost-engine/engine/commit/7df766124f87768b43b9e8947c5a01e17545772c
 (v3.0.1)
https://github.com/gost-engine/engine/commit/b2b4d629f100eaee9f5942a106b1ccefe85b8808
 (v3.0.1)
https://github.com/gost-engine/engine/commit/c6655a0b620a3e31f085cc906f8073fe81b2fad3
 (v3.0.1)

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-29242
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29242

Please adjust the affected versions in the BTS as needed.

Bug#1012511: www.debian.org: securing-debian-manual mentions "nessus" which has been removed from Debian due to license issues in 2009

2022-06-08 Thread Axel Beckert

Package: www.debian.org
Severity: important

Hi,

https://www.debian.org/doc/manuals/securing-debian-manual/sec-tools.en.html
mentions "nessus" as being part of Debian (and actually even recommends
it) despite nessus has been removed from Debian due to license issues
back in 2009:

https://bugs.debian.org/534501

Additionally this sentence should be removed completely from the same
chapter as it's a topic of the past, not the future anymore:

»This software, due to export restrictions in the US, was not
distributed along with the main distribution but included only in non-US
sites.«

I've X-Debbugs-Cc'ed Javier Fernández-Sanguino Peña as the author of the
securing-debian-manual. By chance he was also the package maintainer of
nessus and the one who requested its removal.

Setting severity to important as this is kinda indirect DFSG
violation. ;-)

Bug#995636: transition: openssl