Bug#980440: ITP: dde-control-center -- The control panel of Deepin Desktop Environment

[stan clay]

Package: wnpp
Severity: wishlist
Owner: clay stan 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: dde-control-center
  Version : 5.3.0.82
  Upstream Author : linuxdeepin
* URL : https://github.com/linuxdeepin/dde-control-center
  License : GPL-3+
  Programming Lang:  C++
  Description : The control panel of Deepin Desktop Environment.

DDE Control Center is the control panel of Deepin Desktop Environment.

Bug#980326: mutt: mutt recipient parsing memory leak

[Salvatore Bonaccorso]

Hi,

On Mon, Jan 18, 2021 at 08:45:59AM +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Sun, Jan 17, 2021 at 09:01:22PM +0100, Salvatore Bonaccorso wrote:
> > Source: mutt
> > Version: 2.0.2-1
> > Severity: important
> > Tags: security upstream
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> > 
> > 
> > Hi,
> > 
> > This was reported at
> > https://www.openwall.com/lists/oss-security/2021/01/17/2 and upstream
> > apparently at https://gitlab.com/muttmua/mutt/-/issues/323 (not
> > public).
> 
> Upstream issue #323 is now opened.

The commit in the stable branch is
https://gitlab.com/muttmua/mutt/-/commit/4a2becbdb4422aaffe3ce314991b9d670b7adf17

Regards,
Salvatore

Bug#980439: nmu: gst-plugins-bad1.0_1.18.3-1

[Sebastian Dröge]

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

nmu gst-plugins-bad1.0_1.18.3-1 . ANY . unstable . -m "Rebuild against srt 
1.4.2-1.1 with the changed library package name"

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

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

Bug#980438: do not depend on the non-public binutils ABI

[Matthias Klose]

Package: src:bpftrace
Version: 0.11.3-4
Severity: serious
Tags: sid bullseye

bpftrace should not depend on the non-public binutils ABI. This always generated
an upper dependency on libbinutils.  If you think it's worth having this
dependency, please statically link with libbinutils and record the the version
used in a Built-Using flag.

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Sam Hartman]

> "Russ" == Russ Allbery  writes:


>> I have not come to the TC to ask them to overrule the maintainer
>> frivolously nor before exploring as many other options as I
>> could.

Russ> I understand (oh, boy, do I ever) how strained relationships
Russ> are after the long-running init system battles, but it's very
Russ> hard to resolve problems without the TC when one of the
Russ> parties is unwilling to communicate.  There have been a lot of
Russ> other hostile and aggressive threads about init system issues,
Russ> but this specific bug is not one of them as far as I can tell.

Russ> I don't want to force anyone into communicating when they
Russ> don't want to (general rule 2.1.1), but then I think they need
Russ> to welcome NMUs or a co-maintainer who can deal with the
Russ> things they don't want to have to think about or *something*.
Russ> This kind of silent treatment is really demoralizing to other
Russ> people in the project who are not at fault for any of the
Russ> historical init system hostility.

I'd like to second Russ's analysis here.  I was DPL during a chunk of
the relevant time, and was not able to get communication happening even
when relevant parties (Mark in particular) were being constructive.

I totally understand being burned out on the issue of init systems.
I totally understand being a maintainer who doesn't want to deal with
that.
I think the solution Russ proposes is right in that situation: find
someone you trust to NMU or act as a co-maintainer to move things
forward.

I think it is entirely reasonable for the TC to consider factors like
whether a maintainer is  willing to do that.

Yeah, it sucks when we override a maintainer.
Yes, that's demotivating.

So is creating a situation where people who are being constructive
cannot even engage.
It's one thing to engage with a maintainer and have them consider your
arguments and disagree.
It's another thing entirely when people are trying to work
constructively within the spirit of a GR that we as a community passed
and cannot even get their contributions considered.

That drives people away and  discourages Debian from growing.
I don't think we want that culture.


signature.asc
Description: PGP signature

Bug#913997: what is the current maintainer view on this ?

[Pirate Praveen]

On Tue, 19 Jan 2021 00:29:18 +0100 Christian Kastner  wrote:
> Hi all,
> 
> On Sat, 19 Dec 2020 Pirate Praveen wrote:>> Renaming the binary is
> harder, because there are at least two
> >> packages that use yarn from cmdtest during the build: gitano and
> >> vmdb2. they would need to be ported, and that's up to their
> >> maintainers and upstreams, who I assume won't be happy about it.
> > 
> > Now only xauth and vmdb2 shows up as reverse build dependencies. I 
> > have asked their maintainers if they are open to the name change in 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977709
> Ryutaroh and I have been working with vmdb2 upstream on a new release
> with support for more architectures.
> 
> During this process, upstream indicated that vmdb2 will move away from
> yarn (cmdtest) to Subplot (not yet packaged).
> 
> A quick grep of the sources of xauth, the other reverse dependency of
> cmdtest, gets no results for the string 'yarn'. So the conflicting
> binary does not seem to be used there.
> 
> So, strictly from the point of view of its reverse dependencies, holding
> off on renaming the 'yarn' binary would probably not make much sense.
> 
> Best,
> Christian

Thanks Christian for your comment.

Antonio, can we go ahead with the renaming now?

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#980437: libdqlite-dev: missing dependency on libsqlite3-dev

[duck]

Package: libdqlite-dev
Version: 1.6.0-1+b1
Severity: serious


Quack,

Similarly as libdqlite0 depends on libsqlite3-0 this dependency is 
needed too.


Regards.
\_o<

--
Marc Dequènes

Bug#977952: libgoogle-glog-dev: please ship cmake support

[GCS]

Control: tags -1 +confirmed pending

On Tue, Jan 19, 2021 at 2:57 AM Nobuhiro Iwamatsu
 wrote:
> I have created patches that fixes this issue.
> Could you check and apply?
 Thanks, looks just fine. Going to upload this when I get back home
this afternoon.

Cheers,
Laszlo/GCS

Bug#980436: grub-pc should not suggest LVM physical volumes on a RAID1

[Harald Dunkel]

Package: grub-pc
Version: 2.04-12

The grub-pc.postinst script lists all my disks to install grub. It
also provides an option to install grub on /dev/md0 (i.e. my RAID1),
even though there is no valid boot sector. Its a physical volume for
LVM2. It is easy to select /dev/md0 in the debconf menu by accident,
potentially corrupting the physical volume.

parted and others show

# parted /dev/md0 u s p
Error: /dev/md0: unrecognised disk label
Model: Linux Software RAID Array (md)
Disk /dev/md0: 7813770880s
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags:

# lsscsi
[2:0:0:0]diskATA  WDC WD40EFRX-68W 0A82  /dev/sda
[4:0:0:0]diskATA  WDC WD40EFRX-68N 0A82  /dev/sdc
[5:0:0:0]diskATA  WDC WD40EFRX-68N 0A82  /dev/sdb
[6:0:0:0]cd/dvd  HL-DT-ST BD-RE BP06LU10   HL03  /dev/sr0
[N:0:4:1]diskSamsung SSD 970 EVO Plus 1TB__1/dev/nvme0n1

# lsblk
NAME  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda 8:00   3.6T  0 disk
|-sda1  8:10 992.5K  0 part
`-sda2  8:20   3.6T  0 part
sdb 8:16   0   3.6T  0 disk
|-sdb1  8:17   0 992.5K  0 part
`-sdb2  8:18   0   3.6T  0 part
  `-md0 9:00   3.6T  0 raid1
|-vg01-root   253:0032G  0 lvm
|-vg01-swap   253:1032G  0 lvm
`-vg01-export 253:20   3.6T  0 lvm   /export
sdc 8:32   0   3.6T  0 disk
|-sdc1  8:33   0 992.5K  0 part
`-sdc2  8:34   0   3.6T  0 part
  `-md0 9:00   3.6T  0 raid1
|-vg01-root   253:0032G  0 lvm
|-vg01-swap   253:1032G  0 lvm
`-vg01-export 253:20   3.6T  0 lvm   /export
sr011:01  1024M  0 rom
nvme0n1   259:00 931.5G  0 disk
|-nvme0n1p1   259:1032G  0 part  /
|-nvme0n1p2   259:2032G  0 part  [SWAP]
`-nvme0n1p3   259:30 867.5G  0 part  /local

# blkid | sort
/dev/mapper/vg01-export: LABEL="export" UUID="5717b619-2687-4fe0-be84-025c2b289fd1" 
BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/vg01-root: LABEL="root" UUID="c6a4266c-b164-47f3-b40d-c6ce8b0e71c8" 
BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/vg01-swap: LABEL="swap" UUID="3a47b489-62f5-4728-9d52-880efe84e8a0" 
TYPE="swap"
/dev/md0: UUID="gnk29Q-hu2d-1m83-V2Ke-kNxB-r7BR-o2Q0OI" TYPE="LVM2_member"
/dev/nvme0n1p1: LABEL="nvmeroot" UUID="d6b6d2f3-8213-4221-9a69-df7dc69acc45" BLOCK_SIZE="4096" 
TYPE="ext4" PARTUUID="fc91c342-01"
/dev/nvme0n1p2: LABEL="nvmeswap" UUID="4863a5dd-9395-4ec9-a647-02dd64cf80f1" TYPE="swap" 
PARTUUID="fc91c342-02"
/dev/nvme0n1p3: LABEL="nvmelocal" UUID="6b8b2a25-88d1-4292-b957-d701a39d83fd" BLOCK_SIZE="4096" 
TYPE="ext4" PARTUUID="fc91c342-03"
/dev/sda1: PARTLABEL="bios_grub" PARTUUID="dc5b91c4-41ca-4a44-b38f-af7b3bcecec3"
/dev/sda2: LABEL="data10" UUID="cde2182f-6472-4d22-9743-7a6a0211e415" BLOCK_SIZE="4096" TYPE="ext4" 
PARTLABEL="data10" PARTUUID="f669b240-030c-4948-be2a-d40bd677124c"
/dev/sdb1: PARTLABEL="bios_grub" PARTUUID="c941f8dd-f110-4dfe-8faa-0d1b7b95519c"
/dev/sdb2: UUID="6ef149ac-0672-a4c3-5f58-d96e3949124b" UUID_SUB="c794091e-0b56-de68-8452-8692bbcf3e6e" 
LABEL="cecil.afaics.de:0" TYPE="linux_raid_member" PARTLABEL="raid1" 
PARTUUID="8c6a95c1-c412-44ae-8668-3dd8c4c0c2c6"
/dev/sdc1: PARTLABEL="bios_grub" PARTUUID="01b16890-b414-43fd-bf97-c266c32b6bbe"
/dev/sdc2: UUID="6ef149ac-0672-a4c3-5f58-d96e3949124b" UUID_SUB="68a9bcf9-ad9f-581a-2fed-228207918ba0" 
LABEL="cecil.afaics.de:0" TYPE="linux_raid_member" PARTLABEL="raid1" 
PARTUUID="f19cfa57-3786-497e-9edb-a958417e0682"


Please note the TYPE="LVM2_member" for /dev/md0. Should be easy to recognize.

Of course I didn't try if it *really* corrupts /dev/md0.


Regards
Harri

Bug#980428: CVE-2020-28948 write operations with directory traversal affecting Archive_Tar through 1.4.11

[Salvatore Bonaccorso]

Control: retitle -1 Disallow symlinks to out-of-path filenames (CVE-2020-36193)

Hi David,

On Mon, Jan 18, 2021 at 08:03:42PM -0400, David Prévot wrote:
> Package: php-pear
> Version: 1:1.10.9+submodules+notgz-1.1
> Severity: important
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> Hi,
> 
> The latest (1.4.11) Archive_Tar adds a fix related to CVE-2020-28948.
> 
> https://github.com/FriendsOfPHP/security-advisories/pull/525

Seems to have CVE-2020-36193 assigned.

Regards,
Salvatore

Bug#980435: osdsh: Silent SIGSEGV at startup

[Celelibi]

Package: osdsh
Version: 0.7.0-10.4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Nowadays, osdsh crashes without a message.
The cause I identified is that it looks for a symbol "mixerdevice" in
the shared library libosdshmixer.so which doesn't exist.
Since the return of dlsym isn't checked, it dereferences a NULL pointer.

In the function load_plugin in src/osdsh/controlsh.c:
mod_mixerdev = dlsym(module, "mixerdevice");
*mod_mixerdev = mixerdevice;

These lines seems to have been added by the debian patch
06-fix-m-option.patch.

I guess this patch could be reworked to work with the new version.

Best regards,
Celelibi

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

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

Versions of packages osdsh depends on:
ii  libc6 2.31-9
ii  libxosd2  2.2.14-2.1+b1
ii  tk8.6.10

osdsh recommends no packages.

osdsh suggests no packages.

-- no debconf information

Bug#980296: bpfcc-tools: ${lang}gc-bpfcc and ${lang}stat-bpfcc do not work properly

[Vasudev Kamath]

Vasudev Kamath  writes:

> Ritesh Raj Sarraf  writes:
>
>> Hi Vasudev,
>>
>> On Mon, 2021-01-18 at 09:27 +0530, Vasudev Kamath wrote:
>>> Ritesh Raj Sarraf  writes:
>>> 
>>> > I had fixed this some time ago. Looks like the recent new updates
>>> > needed a
>>> > new adaptation. Thanks for reporting this bug
>>> > 
>>> 
>>> I had fixed a couple of paths before but this one I did not find out.
>>> If
>>> you are not considering fixing this I will go ahead and fix it.
>>> 
>>
>> Please do. I think the commit is this one:
>> ce63c32a4ac81d9a960e36adf160aedb3d7407d0
>>
>> It may just need some checks and re-validation.
>
> I don't see anything changed in the commit. I just reformatted very long
> lines into shorter lines nothing was removed from your code.

Never mind I got where I broke the code. I'm on to fixing this.

Cheers,
Vasudev

Bug#902051: [xml/sgml-pkgs] Bug#902051: libxslt: generate-id() not returning unique IDs

[Mattia Rizzolo]

Hi MaJiang,

On Tue, Dec 03, 2019 at 11:21:27AM +0800, ma.ji...@zte.com.cn wrote:
> We have managed to get a unique IDs (without multi-thread). Hope this could 
> help to get a reproducible build.

Thank you for chiming in, and sorry for not getting back to you much
much sooner!!

> Now the ID is generated by a ptr diff. 
> val = (long)((char *)cur - (char *)_address);
> cur is the address of a xmlNsPtr node stored in a hash table(of course, 
> eventually it's in the heap), base_address is a static variable(in a data 
> section);

Right.

> After some debug, we found there are two major disturbances that prevent a 
> reproducible build.
> First, hash functions use a random seed get from time(). So the address of 
> nodes in hash tables(related to cur) is not stable across multi-builds.
> Second, ASLR (Address Space Layout Randomization) changes the base addresses 
> of data section and heap  every time we start a new process.
> 
> To fix the first problem, we could fake a fixed time. We currently use 
> libfaketime, and of course eventually  something like 
> https://gitlab.gnome.org/GNOME/libxslt/commit/e57df303eca25a2a3f9e0625c29f4b20177858cc
>should be applied.
> 
> To fix the second problem, we could change the ptr diff algorithm to 
> val = (long)((char *)cur -  heapStartAddr);
> After this change, ALSR could not disturb ID generation anymore, because we 
> have eliminated the base address of heap.

Unfortunately, that doesn't seem to be enough in this case I tried.
I did the thing with the current debian package where the
SOURCE_DATE_EPOCH commit you linked is already applied, I removed our
(broken as this bug report reports) patch, then added yours instead.

As a test case I used the debian-faq package, and that produces
non-deterministic IDs.


Which makes me curious, in which circumstances would your patch produce
deterministic IDs?

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#980434: u-boot-rockchip: rockpro64-rk3399 and pinebook-pro-rk3399 fail to boot

[Vagrant Cascadian]

Package: u-boot-rockchip
Version: 2021.01+dfsg-1
Severity: serious

More details to follow, but both rockpro64-rk3399 and
pinebook-pro-rk3399 fail to boot with 2021.01 (and rockpro64-rk3399 may
have issues with 2020.10 as well).

Marking serious so as to not migrate to testing for now, may downgrade
later.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#980296: bpfcc-tools: ${lang}gc-bpfcc and ${lang}stat-bpfcc do not work properly

[Vasudev Kamath]

Ritesh Raj Sarraf  writes:

> Hi Vasudev,
>
> On Mon, 2021-01-18 at 09:27 +0530, Vasudev Kamath wrote:
>> Ritesh Raj Sarraf  writes:
>> 
>> > I had fixed this some time ago. Looks like the recent new updates
>> > needed a
>> > new adaptation. Thanks for reporting this bug
>> > 
>> 
>> I had fixed a couple of paths before but this one I did not find out.
>> If
>> you are not considering fixing this I will go ahead and fix it.
>> 
>
> Please do. I think the commit is this one:
> ce63c32a4ac81d9a960e36adf160aedb3d7407d0
>
> It may just need some checks and re-validation.

I don't see anything changed in the commit. I just reformatted very long
lines into shorter lines nothing was removed from your code.

>
>> May be we should also consider using autopkgtest to make sure all
>> utilities are working  as expected.
>
> Yes. Please feel free to add it. I haven't really been on top of
> autopkgtest feature but that's something I know can be very useful.
>
Sure will have a look at this may be at later point of time.

Cheers,
Vasudev

Bug#757582: closed by Bernhard Schmidt (Closing bugs opened for old Gtk client)

[Frank Heckenbach]

> You seem to forget that

What you (and apparently many other maintainers) seem to forget is:

> a) we are all volunteers

Most bug reporters (including me) are volunteers too.

Well managed projects treat good bug reports as a valuable resource
to increase the quality of the project. Others consider them a
nuisance which must be gotten rid of.

Always good to know which kind of project this is. I promise you I
won't bother you with any further bug reports.

Though it would be easier for everyone to know this up front, and
I'm only half kidding here. Maybe a flag can be introduced so
reportbug will say "maintainers don't really want any bug reports,
do you really need to continue?"

> b) we are not upstream

Then forward it to upstream.

Debian strongly recommends users to report bugs via reportbug (see
https://www.debian.org/Bugs/Reporting). That's well and good because
some bugs may be due to Debian specific changes (*cough* openssl).
But you know (I hope) who's upstream and can forward
non-Debian-specific bugs there.

> c) noone has looked at the project for several years

Now that's really bad, especially for such a program. And I guess
the last thing someone did was the change of GUI toolkits which is
of course the most important thing for a phone program (not!).

So I consider linphone a dead project now, that's all.

> d) not all bugs can be clearly reproduced.

We're not talking about all bugs, but one specific bug. My original
bug report gave a very easy and clear description how to reproduce
it. I don't think anyone actually tried to reproduce it.

Did you set it to "wontfix" at least?

Bug#979041: libopempi3: aborts python code due to libfabric fork() issues

[Drew Parsons]

On 2021-01-15 23:14, Alastair McKinstry wrote:

Ugh. Thanks Drew.
What are the contents of  /etc/openmpi/openmpi-mca-params.conf on the 
node?

Does a simple hello world (see Debian/tests/hello* ) work without
errors in the environment ?



Hi Alastair, sorry for the delay replying to these questions.

I'm attaching /etc/openmpi/openmpi-mca-params.conf

In summary, the lines at the end that I think would be dealing with 
libfabric are


# Silence this warning on Debian, as many systems don't have openfabric
# but the warning breaks higher layers or application
btl_base_warn_component_unused=0
# Avoid openib an in case applications use fork: see 
https://github.com/ofiwg/libfabric/issues/6332
# If you wish to use openib and know your application is safe, remove 
the following:

# Similarly for UCX: https://github.com/open-mpi/ompi/issues/8367
btl = ^uct,openib
pml = ^ucx
osc = ^ucx


(the last line with osc doesn't have a newline at the end, but I guess 
that's not important for runtime)



hello world doesn't generate any error. The error seems to be specific 
to python execution, perhaps when forking mpi process from python?  That 
said, petsc4py is not generating the error. mpi4py is probably the most 
direct way of probing the problem.


The test log for hello world is:

$ autopkgtest -B -- null 2>&1 | tee ../openmpi-test.log
autopkgtest [14:37:31]: starting date: 2021-01-19
autopkgtest [14:37:31]: version 5.15
autopkgtest [14:37:31]: host sandy; command line: /usr/bin/autopkgtest 
-B -- null

autopkgtest [14:37:31]: testbed dpkg architecture: amd64
autopkgtest [14:37:31]: testbed running kernel: Linux 5.10.0-1-amd64 #1 
SMP Debian 5.10.5-1 (2021-01-09)

autopkgtest [14:37:31]:  unbuilt-tree .
autopkgtest [14:37:32]: testing package openmpi version 4.1.0-6
autopkgtest [14:37:32]: build not needed
autopkgtest [14:37:32]: test hello1: preparing testbed
autopkgtest [14:37:32]: test hello1: [---
Hello world from processor sandy, rank 0 out of 1 processors
autopkgtest [14:37:37]: test hello1: ---]
autopkgtest [14:37:37]: test hello1:  - - - - - - - - - - results - - - 
- - - - - - -

hello1   PASS
autopkgtest [14:37:37]: test hello2: preparing testbed
autopkgtest [14:37:37]: test hello2: [---
 node   0 : Hello world
autopkgtest [14:37:39]: test hello2: ---]
autopkgtest [14:37:39]: test hello2:  - - - - - - - - - - results - - - 
- - - - - - -

hello2   PASS
autopkgtest [14:37:39]: test hello4: preparing testbed
autopkgtest [14:37:39]: test hello4: [---
 node   0 : Hello world
autopkgtest [14:37:41]: test hello4: ---]
autopkgtest [14:37:41]: test hello4:  - - - - - - - - - - results - - - 
- - - - - - -

hello4   PASS
autopkgtest [14:37:41]:  summary
hello1   PASS
hello2   PASS
hello4   PASS
$ echo $?
0
#
# Copyright (c) 2004-2005 The Trustees of Indiana University and Indiana
# University Research and Technology
# Corporation.  All rights reserved.
# Copyright (c) 2004-2005 The University of Tennessee and The University
# of Tennessee Research Foundation.  All rights
# reserved.
# Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
# University of Stuttgart.  All rights reserved.
# Copyright (c) 2004-2005 The Regents of the University of California.
# All rights reserved.
# Copyright (c) 2006-2017 Cisco Systems, Inc.  All rights reserved
# Copyright (c) 2018  Intel, Inc. All rights reserved.
# $COPYRIGHT$
#
# Additional copyrights may follow
#
# $HEADER$
#

# This is the default system-wide MCA parameters defaults file.
# Specifically, the MCA parameter "mca_param_files" defaults to a
# value of
# "$HOME/.openmpi/mca-params.conf:$sysconf/openmpi-mca-params.conf"
# (this file is the latter of the two).  So if the default value of
# mca_param_files is not changed, this file is used to set system-wide
# MCA parameters.  This file can therefore be used to set system-wide
# default MCA parameters for all users.  Of course, users can override
# these values if they want, but this file is an excellent location
# for setting system-specific MCA parameters for those users who don't
# know / care enough to investigate the proper values for them.

# Note that this file is only applicable where it is visible (in a
# filesystem sense).  Specifically, MPI processes each read this file
# during their startup to determine what default values for MCA
# parameters should be used.  mpirun does not bundle up the values in
# this file from the node where it was run and send them to all nodes;
# the default value decisions are effectively distributed.  Hence,
# these values are only applicable on nodes that "see" this 

Bug#980108: openjdk-11-jre-headless: SIGSGV running tomcat8 application

[tony mancill]

On Thu, Jan 14, 2021 at 03:14:52PM +, John Hall wrote:
> Package: openjdk-11-jre-headless
> Version: 11.0.9.1+1-1~deb10u2
> Severity: important
> 
> Dear Maintainer,
> 
> The tomcat application unexpectedly stopped working. In
> /var/log/tomcat8/catalina.out, there was the following output:
> 
>   # A fatal error has been detected by the Java Runtime Environment:
>   #
>   #  SIGSEGV (0xb) at pc=0x7f03a5afb0f0, pid=818, tid=854
>   #
>   # JRE version: OpenJDK Runtime Environment (11.0.9.1+1) (build
>   # 11.0.9.1+1-post-Debian-1deb10u2)
>   # Java VM: OpenJDK 64-Bit Server VM (11.0.9.1+1-post-Debian-1deb10u2,
>   # mixed mode, sharing, tiered, compressed oops, concurrent mark sweep
>   # gc, linux-amd64)
>   # Problematic frame:
>   # V  [libjvm.so+0x56f0f0]
>   #
>   # No core dump will be written. Core dumps have been disabled. To enable
>   # core dumping, try "ulimit -c unlimited" before starting Java again
>   #
>   # An error report file with more information is saved as:
>   # /tmp/hs_err_pid818.log
>   #
>   # Compiler replay data is saved as:
>   # /tmp/replay_pid818.log

Hi John,

This looks a bit like the JIT bug [1] that was addressed in 11.0.9.1
[1,2].  Thank you for including the error report and compiler replay
data.  I will have a look to see if I can find a corresponding upstream
bug.

Thanks,
tony

[1] https://bugs.openjdk.java.net/browse/JDK-8250861
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975728

Bug#979041: libopempi3: aborts python code due to libfabric fork() issues

[Drew Parsons]

Package: libopenmpi3
Version: 4.1.0-6
Followup-For: Bug #979041
Control: reopen 979041

We need to reopen this bug unfortunately. The libfabric
(RDMAV_FORK_SAFE) issue is still live in python MPI applications.

You can see it in pytest-mpi tests as reported previously,
or in a rebuild of mpi4py, e.g.
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/mpi4py_3.0.3-7.rbuild.log.gz


Drew



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

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

Versions of packages libopenmpi3 depends on:
ii  libc62.31-9
ii  libevent-core-2.1-7  2.1.12-stable-1
ii  libevent-pthreads-2.1-7  2.1.12-stable-1
ii  libfabric1   1.11.0-2
ii  libgcc-s110.2.1-6
ii  libhwloc-plugins 2.4.0+dfsg-3
ii  libhwloc15   2.4.0+dfsg-3
ii  libibverbs1  33.0-1
ii  libnl-3-200  3.4.0-1+b1
ii  libpmix2 4.0.0-3
ii  libpsm-infinipath1   3.3+20.604758e7-6.1
ii  libpsm2-211.2.185-1
ii  libstdc++6   10.2.1-6
ii  libucx0  1.10.0~rc1-4
ii  zlib1g   1:1.2.11.dfsg-2

libopenmpi3 recommends no packages.

libopenmpi3 suggests no packages.

-- no debconf information

Bug#980433: ITP: buf --

[Arnaud Rebillout]

Package: wnpp
Severity: wishlist
Owner: Arnaud Rebillout 

* Package name: buf
  Version : 0.33.0-1
  Upstream Author : Buf Technologies, Inc.
* URL : https://github.com/bufbuild/buf
* License : Apache-2.0
  Programming Lang: Go
  Description : Better way to work with Protocol Buffers

 Buf’s long-term goal is to enable schema-driven development: a future
 where APIs are defined consistently, in a way that service owners and
 clients can depend on.
 .
 Defining APIs using an IDL (Interface Description Language) provides a
 number of benefits over simply exposing JSON/REST services, and today,
 Protobuf is the most stable, widely-adopted IDL in the industry.
 .
 However, as it stands, using Protobuf is much more difficult than using
 JSON as your data transfer format.
 .
 Enter Buf: We’re building tooling to make Protobuf reliable and easy to
 use for service owners and clients, while keeping it the obvious choice
 on the technical merits.



This is needed to build latest version of nomad (https://www.nomadproject.io).

Bug#976301: Fix invalid `changelog` format example

[Guillem Jover]

On Mon, 2021-01-18 at 18:25:55 -0700, Sean Whitton wrote:
> On Thu 03 Dec 2020 at 05:08AM +03, Anatoli Babenia wrote:
> > diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> > index edae8c1..1265c5e 100644
> > --- a/policy/ch-source.rst
> > +++ b/policy/ch-source.rst
> > @@ -126,7 +126,7 @@ That format is a series of entries like this:
> >   [blank line(s), included in output of dpkg-parsechangelog]
> >   * even more change details
> >   [optional blank line(s), stripped]
> > []{+[space]--+} maintainer name [two [-spaces]
> > date-]{+spaces]date+}
> 
> I do not believe that what is already there is invalid or unclear.
> 
> Please explain your motivations.

Oh, but it does look invalid. :) Notice that the trailing maintainer
line starts at the same column as the header line, but the trailer must
be indented by one space. Also the «two spaces» are then followed by
two explicit spaces, which seems confusing.

I guess Anatoli proposed to make the whitespace requirements explicit
to avoid this kind of subtle problems in the future.

Thanks,
Guillem

Bug#980115: connection failure when rx initialized after 08:25:36 GMT 14 Jan 2021

[Benjamin Kaduk]

On Mon, Jan 18, 2021 at 06:04:39PM +, Jeremy Stanley wrote:
> Thanks for pulling this into unstable and testing! Is there any work
> in progress to fix it in stable as well? I took a quick peek in
> Salsa and didn't see any merge requests or an obvious branch for
> Buster's 1.8.2 (just the debian/1.8.2-1 tag).

It is a clear candidate to fix in stable, though the only concrete steps
I've been able to take so far are to confirm with the security team that it
is not a candidate for being fixed via a DSA.

The actual work of backporting the patches should be ~trivial, so the
process work of engaging with the release team will be the dominating
factor.

-Ben

Bug#980249: wiki.debian.org: 408 Request Timeout editing U-boot/Status

[Vagrant Cascadian]

On 2021-01-17, Steve McIntyre wrote:
> On Sat, Jan 16, 2021 at 10:03:13AM -0800, Vagrant Cascadian wrote:
>>Package: wiki.debian.org
>>Severity: normal
>>
>>Sometime in the last few weeks, I'm only able to successfully edit
>>https://wiki.debian.org/U-boot/Status maybe 1 out of every 5 or 10
>>attempts. Either preview or save changes button usually ends with:
>>
>>  Request Timeout
>>
>>  Server timeout waiting for the HTTP request from the client.
>>  Apache Server at wiki.debian.org Port 443
>>
>>I'm using firefox-esr on buster.
>
> Hmmm. I'm not seeing any issues here, also doing test edits with
> Firefox. The page saves and I reliably get a response in less than a
> second on both Save and Preview.

Well, thanks for testing it, that seems to have "fixed" it!


> Can you give us more information about your setup please? Are you
> using IPv4 or IPv6? Do you have any problems editing other pages? Any
> extensions installed that might have an effect?

Not sure what wiki.debian.org requires, but using https-everywhere,
noscript, privacy badger and ublock-origin. I think I enabled javascript
for wiki.debian.org.

I was quite possibly originally connecting via IPV6, and temporarily
disabled my IPV6 connection and then it started working again... even
after re-enabling IPV6. Although it is hard to know weather firefox is
using IPV4 or IPV6...

Not sure how long to leave this bug open with an uncertain resolution...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#953249: ITS: fortune-mod : update to the new 2.16.0 release

[Mattia Rizzolo]

Hello here!

On Sun, Apr 05, 2020 at 10:38:30AM +0300, Shlomi Fish wrote:
> Hi Mattia!
> 
> Thanks for the update.
> 
> On Fri, Apr 3, 2020 at 5:30 PM Mattia Rizzolo  wrote:
> 
> > just a private mail to mention that I didn't forget of this.
> > Sorry for my science, I hope to get to this soon :\

I said this, but it turned out that I forgot.  Fortunately I didn't
archive the thread and it popped up now.

> > https://salsa.debian.org/shlomif-guest/fortune-mod

So, as a review of this.
I see the git repo effectly is quite a mess, with way too generic
commit messages like "debian update files for upstream version" or "fix
lintian warnings" or "debian package" that don't really describe what
and WHY you did such change.  Plus the botchered upstream import at
ee5dc32a2910a3a8411d2a528afd68b3383eb879 that was later on fixed.

I guess I'll just look at the status at the current HEAD rather than the
history...


That said:
* debian/menu:
  + remove the file: Policy v4.0.1 says to not install them anymore
* debian/changelog:
  + squash together those 3 UNRELEASED chagnes, plus it's not an NMU
anymore if you are adopting it (this is an ITS after all)
  + I can't believe you did one and a half screenful of commits with
just those changes...  And indeed looking at the diff is obvious
that you didn't document basically any change.
* debian/compat
  + bump to version 13, plus use the new debhelper-compat notation in
B-D, so drop this.
* debian/control:
  + bump standards-version
  + add Rules-Requires-Root
* debian/copyright:
  + it would be best to rewrite the whole file using
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
though since we are tight with the bullseye release if you wish to
do so at the next upload I would understand it
* debian/*.lintian-overrides:
  + you are the new upstream, right?  then at least set Homepage to
point to your github repo..
* debian/patches:
  + fort.patch: an empty patch??
  + you cleaned out all patches.  did you really integrate them all??
* debian/fortune-mod.manpages:
  + what happened with this file?
* debian/rules:
  + I honestly can't believe such package has such a complicated rules
file -.- even more as since you are upstream I kind of expected to
make your own life easier
  + override_dh_auto_build-indep: pretty sure that's the default anyway
  + this:
 override_dh_auto_install-arch:
dh_auto_install -- prefix=$(CURDIR)/debian/tmp \
-  install-fortune install-util install-man
+   install
+   $(call MYCHRPATH)
I'm pretty sure `dh_auto_install` already calls `install`.  you
should set DH_VERBOSE=1 so to clearly see what dh invokes.
  + you are adding all that handling to call `chrpath`.  can't you fix
the build system to just not save RPATH at all?
  + why skipping the tests?  at least a comment on top is needed


And this is only a "quick" look, I didn't even try to pressure myself
into nitpicking as I usually do.


Trying to build the sources:
dpkg-source: info: local changes detected, the modified files are:
 fortune-mod/INSTALL
 fortune-mod/fortune/fortune-man.part1
 fortune-mod/fortune/fortune-man.part2
 fortune-mod/fortune/fortune.6
 fortune-mod/fortune/gen-fortune-man-page.pl
 fortune-mod/util/strfile.8
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/fortune-mod_3.4.1-0.1.diff.yV3FX6
Basically, all those files are new, drop them from git.  And even
`debian/rules clean` doesn't delete them.  Where are they coming from?


Then I went on to build it and it failed right away:
dh_auto_configure -- \
-D LOCALDIR=/usr/share/games/fortunes \
-D LOCALODIR=/usr/share/games/fortunes/off
dh_auto_configure: warning: Compatibility levels before 10 are deprecated 
(level 9 in use)
install -d obj-x86_64-linux-gnu
cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON "-GUnix Makefiles" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -D 
LOCALDIR=/usr/share/games/fortunes -D LOCALODIR=/usr/share/games/fortunes/off ..
Can't exec "cmake": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 522.

 -.-  → missing Build-Dep
After installing cmake it went on.

lintian also has quite a lot to say:
W: fortune-mod: groff-message usr/share/man/man1/strfile.1.gz 10: warning: 
macro 'Aq' not defined
W: fortune-mod: menu-command-not-in-package usr/share/menu/fortune-mod:5 while
W: fortune-mod source: package-uses-deprecated-debhelper-compat-version 9
W: fortune-mod source: patch-file-present-but-not-mentioned-in-series fort.patch
I: fortune-mod source: out-of-date-standards-version 

Bug#978042: libwebkit2gtk-4.0-37: fails to run plugin

[Ben Chin, KB]

Dear Berto,

Thanks a lot for you reply and provided information. For now we are 
going to apt-mark hold the libwebkit2gtk-4.0-dev package. So we can stay 
on the plugin-enabled version for the remaining life cycle of Debian 10. 
We might download the latest version and build it to enable plugin if we 
find it's very needed. We will also keep a copy of the source of v2.30.5 
just in case we cannot make the latest version work.


Actually during these few days, we have found a quite suitable 
alternative to the WebKit/Plugin architecture. It's called NWJS/NAPI. We 
find it can almost fully fulfill our needs and also quite easy to 
migrate to. The only drawback is, we cannot host the our application 
from network, everything must be at the local machine. Though this 
doesn't bring much negative impact to us.


Therefore, we can still keep on using WebKit/Plugin for some time. I 
will look into your web extension suggestion too.


I thank you and appreciate your kind concern and help.

Regards
Ben


On 19/1/2021 12:14 am, Alberto Garcia wrote:

On Sun, Dec 27, 2020 at 09:11:14AM +0800, Ben Chin, KB wrote:

Dear Alerto,

Thanks for your notification. I am sad to hear that the plugin
support will be removed.

The plugin is our company's in house program to provide a way to
communicate between C/C++ and JavaScript, makes it possible for the
connected primitive hardware to play some roles in the evolving
Internet world.

We don't use the full features of NPAPI, but just the
calling/passing functions and information between the browser and
the underneath lower level system/hardware resources.

If removing of the plugin is inevitable, we will need to find an
alternative of WebKit to fulfill our goal.

Hi Ben, and sorry for the late reply.

There's going to be a new release (2.30.5) one of these days with the
plugin process installed again, but the next stable branch (2.32.x)
won't support NPAPI plugins.

All major web browsers have removed support for these plugins, perhaps
you could use a Web Extension?


https://blogs.igalia.com/carlosgc/2013/09/10/webkit2gtk-web-process-extensions/


Would it be possible to keep an older version of the plugin enabled
WebKit?  Like, the new WebKit would be version 3, and let the old
one survive as WebKit 2 and stay as it is?

You can always keep the latest version that supports plugins
installed. If what you're asking is "Can we keep that package
officially in Debian together with the newer versions?" then I'm
afraid that this is too much of a maintenance burden for this feature.

But you can do that locally, i.e., modify and rebuild the package so
it is co-installable with other versions of webkit. I can maybe help
you if you have problems with that.

Berto

Bug#980418: demote dependency on libdv-bin to Recommends

[Dmitry Smirnov]

On Tuesday, 19 January 2021 5:38:03 AM AEDT Helmut Grohne wrote:
>Thus, I propose demoting libsynfig0a's dependency on
> libdv-bin to Recommends. Does that sound reasonable?

Makes sense, let's do that. Thanks for suggestion.

-- 
Kind regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---


Do your duty as you see it, and damn the consequences.
-- George S. Patton

---

Ignoring the Covid evidence: Far from following the science, the
government turned its back on all available data.
-- Alistair Haimes
   
https://thecritic.co.uk/issues/july-august-2020/ignoring-the-covid-evidence/


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

Bug#980432: ITP: golang-github-jhump-protoreflect -- Reflection (Rich Descriptors) for Go Protocol Buffers

[Arnaud Rebillout]

Package: wnpp
Severity: wishlist
Owner: Arnaud Rebillout 

* Package name: golang-github-jhump-protoreflect
  Version : 1.8.1-1
  Upstream Author : Joshua Humphries
* URL : https://github.com/jhump/protoreflect
* License : Apache-2.0
  Programming Lang: Go
  Description : Reflection (Rich Descriptors) for Go Protocol Buffers

 Reflection APIs for protocol buffers (also known as "protobufs" for short) and
 gRPC. The core of reflection in protobufs is the descriptor. A descriptor is
 itself a protobuf message that describes a .proto source file or any element
 therein. So a collection of descriptors can describe an entire schema of
 protobuf types, including RPC services.



This package is needed as a build-depends of buf (https://buf.build),  which is
itself needed to build the latest versions of nomad 
(https://www.nomadproject.io).

Bug#977952: libgoogle-glog-dev: please ship cmake support

[Nobuhiro Iwamatsu]

Package: libgoogle-glog-dev
Followup-For: Bug #977952

Hi,

I have created patches that fixes this issue.
Could you check and apply?

Best regards,
  Nobuhiro
>From 0999fee0b187f627f1df3154a52fce21dad78af7 Mon Sep 17 00:00:00 2001
From: Nobuhiro Iwamatsu 
Date: Tue, 19 Jan 2021 10:15:04 +0900
Subject: [PATCH 1/2] cmake: Add pkg-config file generation functiuon

Signed-off-by: Nobuhiro Iwamatsu 
---
 ...d-pkgconfig-file-generation-function.patch | 35 +++
 debian/patches/series |  1 +
 2 files changed, 36 insertions(+)
 create mode 100644 
debian/patches/cmake-Add-pkgconfig-file-generation-function.patch

diff --git a/debian/patches/cmake-Add-pkgconfig-file-generation-function.patch 
b/debian/patches/cmake-Add-pkgconfig-file-generation-function.patch
new file mode 100644
index 000..bb16eb8
--- /dev/null
+++ b/debian/patches/cmake-Add-pkgconfig-file-generation-function.patch
@@ -0,0 +1,35 @@
+From 54d91e377727b78f481a463e0fa3dd4e395b62b1 Mon Sep 17 00:00:00 2001
+From: Nobuhiro Iwamatsu 
+Date: Tue, 19 Jan 2021 10:15:41 +0900
+Subject: [PATCH] cmake: Add pkgconfig file generation function
+
+When using CMake, the pkg-config file is not generated.
+This adds a function to generate files in pkg-config.
+
+Signed-off-by: Nobuhiro Iwamatsu 
+---
+ CMakeLists.txt | 11 +++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 808330e..6f2abd1 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -682,3 +682,14 @@ install (FILES
+ 
+ install (EXPORT glog-targets NAMESPACE glog:: DESTINATION
+   ${_glog_CMake_INSTALLDIR})
++
++# pkg-config
++set(VERSION   "${PROJECT_VERSION}")
++set(prefix"${CMAKE_INSTALL_PREFIX}")
++set(exec_prefix   "\${prefix}")
++set(includedir"\${prefix}/include")
++set(libdir"\${prefix}/${LIB_INSTALL_DIR}")
++configure_file(libglog.pc.in libglog.pc @ONLY)
++
++install(FILES ${CMAKE_CURRENT_BINARY_DIR}/libglog.pc
++  DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
+-- 
+2.30.0.rc2
+
diff --git a/debian/patches/series b/debian/patches/series
index f741466..65d1525 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@
 20120621_errnos.diff
 20130313_fix_test_on_ports.diff
 x32_build_fix.patch
+cmake-Add-pkgconfig-file-generation-function.patch
-- 
2.30.0.rc2

>From b99d71c512e985d0e7efdfc87eb5d08ad4576405 Mon Sep 17 00:00:00 2001
From: Nobuhiro Iwamatsu 
Date: Tue, 19 Jan 2021 10:15:21 +0900
Subject: [PATCH 2/2] Change to use cmake

Signed-off-by: Nobuhiro Iwamatsu 
---
 debian/rules | 42 +-
 1 file changed, 37 insertions(+), 5 deletions(-)

diff --git a/debian/rules b/debian/rules
index e159670..4d39560 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,23 +5,55 @@
 #export DH_VERBOSE=1
 
 export DOCDIR=$(CURDIR)/debian/libgoogle-glog-doc/
+DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+BUILDDIR = obj-$(DEB_HOST_MULTIARCH)
+
+CONFIGURE_ARGS= \
+ -DCMAKE_BUILD_TYPE=Release \
+ -DLIB_INSTALL_DIR:STRING="lib/$(DEB_HOST_MULTIARCH)"
 
 override_dh_installdocs-indep:
dh_installdocs
sed -i 's|http.*/favicon.ico||' \
$(DOCDIR)/usr/share/doc/libgoogle-glog-dev/glog.html
 
-override_dh_installchangelogs:
-   dh_installchangelogs ChangeLog
+override_dh_auto_build:
+   # dynamically linked
+   dh_auto_build -B $(BUILDDIR)
+   # statically linked
+   dh_auto_build -B $(BUILDDIR)-static
+
+override_dh_auto_configure:
+   # dynamically linked
+   dh_auto_configure -B $(BUILDDIR) \
+   -- $(CONFIGURE_ARGS) \
+   -DBUILD_SHARED_LIBS=ON \
+   -DBUILD_TESTING=ON
+
+   # statically linked
+   dh_auto_configure -B $(BUILDDIR)-static \
+   -- $(CONFIGURE_ARGS) \
+   -DBUILD_SHARED_LIBS=OFF \
+   -DBUILD_TESTING=OFF
+
+override_dh_auto_install:
+   dh_auto_install -O--buildsystem=cmake -B $(BUILDDIR)
+   find $(CURDIR)/debian/tmp/ -type d -name .cmake | xargs -r rm -rfv
+
+execute_before_dh_install:
+   # put the static libs together with the rest of the stuff
+   cp -v $(BUILDDIR)-static/*.a debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/
+   -$(RM) -r $(BUILDDIR)-static
 
 override_dh_auto_test:
-if [ -f /proc/version ]; then $(MAKE) check; fi
 
 %:
-   dh $@ --with autoreconf
+   dh  $@ --buildsystem=cmake
 
 get-orig-source:
uscan --verbose --force-download --rename
 
-.PHONY: override_dh_installdocs-indep override_dh_installchangelogs \
-   override_dh_auto_test
+.PHONY: override_dh_installdocs-indep override_dh_auto_install \
+   execute_before_dh_install override_dh_auto_build \
+   override_dh_auto_test override_dh_auto_configure
-- 
2.30.0.rc2

Bug#958066: devscripts: mk-origtargz fails silently with bad Files-Excluded line

[Mattia Rizzolo]

Control: tag -1 moreinfo

On Fri, Apr 17, 2020 at 08:40:46PM -0400, Nick Black wrote:
> I'm packaging notcurses, and per my FTPMasters review, I've been attempting to
> move to a uscan-based repack with a Files-Excluded line in debian/copyright. I
> lost an hour or so to uscan failing in mk-origtargz, finally tracking it down
> to a malformed wildcard in debian/copyright. mk-origtargz prints no diagnostic
> in such a case, simply returning 1.

Mhh, could you please provide an example of this?
Last I know, mk-origtargz has this warning:
"No files matched excluded pattern as the last matching glob: 
$info->{glob}\n";
which I believe it was your problem?

So, could you please explain with more details what you were doing that
wasn't reported back?

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#980396: libgdk-pixbuf-2.0-0: should run its trigger on first installation too

[Mattia Rizzolo]

Control: reassign -1 libgdk-pixbuf-2.0-0 2.42.2+dfsg-1
Control: affects -1 inkscape
Control: retitle -1 libgdk-pixbuf-2.0-0: should run its trigger on first 
installation too

Hi!

What a fascinating bug this is!

On Mon, Jan 18, 2021 at 01:29:03PM -0500, Jason Woofenden wrote:
> I installed inkscape on a pretty fresh debian unstable install
> (from a couple months ago).
> 
> inkscape would launch, but very few of the icons in the ui displayed.
> E.g. most tools had the same icon-missing icon. Screenshot attached.

Well, I could reproduce it just fine!

> I tried installing recommended packages and whatnot, especially
> anything to do with pixbuf, I installed all the pixbuf related
> packages that my other computer has installed (where inkscape works
> correctly.)

> my uneducated guess is that maybe this bit is what fixed it:
> 
> Processing triggers for libgdk-pixbuf-2.0-0:amd64 (2.42.2+dfsg-1) ...
> 
> now inkscape works correctly even though gnome-icon-theme in not
> installed anymore. I assume this means that this can only be
> reproduces on a fresh install of debian unstable.

Right, so apparently what used to trigger that was librsvg2-common,
which was pulled in by inkscape through the chain

inkscape → libgtk2.0-0 → adwaita-icon-theme | gnome-icon-theme → 
librsvg2-common

In the alternative dependency, the first is chosen if there are no
reason not to, and adwaita-icon-theme *used to* depend on
librsvg2-common, but then downgraded the dependency to Recommends last
year.  You could "fix" it with gnome-icon-theme because that one didn't
change and still has the dependency on librsvg2-common.


Now, what I *really* wonder abuot is why the trigger (or, well, the code
behind it) is not running by itself on after libgdk-pixbuf-2.0-0.
Usually packages shipping triggers also run it by themselves upon
installation for the first time, even without being triggered to.
I think that's the direction one should dig toward.

In the meantime, I think it's safe to say that's a gdk-pixbuf bug, so
I'm reassigning this.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#976301: Fix invalid `changelog` format example

[Sean Whitton]

control: tag -1 + moreinfo

Dear Anatoli,

On Thu 03 Dec 2020 at 05:08AM +03, Anatoli Babenia wrote:

> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index edae8c1..1265c5e 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -126,7 +126,7 @@ That format is a series of entries like this:
>   [blank line(s), included in output of dpkg-parsechangelog]
>   * even more change details
>   [optional blank line(s), stripped]
> []{+[space]--+} maintainer name [two [-spaces]
> date-]{+spaces]date+}

I do not believe that what is already there is invalid or unclear.

Please explain your motivations.

-- 
Sean Whitton

Bug#967133: fbpanel: Unversioned Python removal in sid/bullseye

[Logan Rosen]

Package: fbpanel
Version: 7.0-4
Followup-For: Bug #967133
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * Build using python2.

Thanks for considering the patch.

Logan
diff -Nru fbpanel-7.0/debian/control fbpanel-7.0/debian/control
--- fbpanel-7.0/debian/control  2017-10-12 07:54:27.0 -0400
+++ fbpanel-7.0/debian/control  2020-04-03 12:14:06.0 -0400
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Ulises Vitulli  
 Build-Depends: debhelper (>= 9), autotools-dev, libgtk2.0-dev, libxmu-dev, 
- libxpm-dev, python-minimal, python-argparse
+ libxpm-dev, python2
 Standards-Version: 4.1.1
 Homepage: https://github.com/aanatoly/fbpanel
 
diff -Nru fbpanel-7.0/debian/patches/python2.diff 
fbpanel-7.0/debian/patches/python2.diff
--- fbpanel-7.0/debian/patches/python2.diff 1969-12-31 19:00:00.0 
-0500
+++ fbpanel-7.0/debian/patches/python2.diff 2020-04-03 12:14:06.0 
-0400
@@ -0,0 +1,40 @@
+Index: b/.config/help
+===
+--- a/.config/help
 b/.config/help
+@@ -1,4 +1,4 @@
+-#!/usr/bin/python
++#!/usr/bin/python2
+ 
+ import re, os, sys, textwrap
+ # Formats help message
+Index: b/.config/repl.py
+===
+--- a/.config/repl.py
 b/.config/repl.py
+@@ -1,4 +1,4 @@
+-#!/usr/bin/python
++#!/usr/bin/python2
+ 
+ import re, sys
+ 
+Index: b/.config/tar.py
+===
+--- a/.config/tar.py
 b/.config/tar.py
+@@ -1,4 +1,4 @@
+-#!/usr/bin/python
++#!/usr/bin/python2
+ 
+ import subprocess as sp
+ import re, tempfile
+Index: b/configure
+===
+--- a/configure
 b/configure
+@@ -1,4 +1,4 @@
+-#!/usr/bin/python
++#!/usr/bin/python2
+ 
+ import sys
+ if sys.version_info < (2, 7):
diff -Nru fbpanel-7.0/debian/patches/series fbpanel-7.0/debian/patches/series
--- fbpanel-7.0/debian/patches/series   2017-10-12 07:54:27.0 -0400
+++ fbpanel-7.0/debian/patches/series   2020-04-03 12:14:06.0 -0400
@@ -5,3 +5,4 @@
 plugins_volume_oss+alsa_hint.patch
 ftbfs-hurd.patch
 nolibexec.patch
+python2.diff

Bug#957193: fbpanel: ftbfs with GCC-10

[Logan Rosen]

Package: fbpanel
Version: 7.0-4
Followup-For: Bug #957193
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/gcc-10.patch: Mark variable as extern to fix FTBFS with GCC 10.

Thanks for considering the patch.

Logan
diff -Nru fbpanel-7.0/debian/patches/gcc-10.patch 
fbpanel-7.0/debian/patches/gcc-10.patch
--- fbpanel-7.0/debian/patches/gcc-10.patch 1969-12-31 19:00:00.0 
-0500
+++ fbpanel-7.0/debian/patches/gcc-10.patch 2021-01-18 20:13:32.0 
-0500
@@ -0,0 +1,11 @@
+--- a/panel/plugin.h
 b/panel/plugin.h
+@@ -9,7 +9,7 @@
+ #include 
+ #include "panel.h"
+ 
+-struct _plugin_instance *stam;
++extern struct _plugin_instance *stam;
+ 
+ typedef struct {
+ /* common */
diff -Nru fbpanel-7.0/debian/patches/series fbpanel-7.0/debian/patches/series
--- fbpanel-7.0/debian/patches/series   2017-10-12 07:54:27.0 -0400
+++ fbpanel-7.0/debian/patches/series   2021-01-18 20:13:19.0 -0500
@@ -4,3 +4,4 @@
 plugins_volume_oss+alsa_hint.patch
 ftbfs-hurd.patch
 nolibexec.patch
+gcc-10.patch

Bug#979523: FTCBFS due to misuse of build system C compiler

[John Scott]

On Monday, January 18, 2021 9:56:58 AM EST you wrote:
> Could you check whether this is compatible with your build process?
Setting the CC variable works, and although the cross built pari-gp binary is 
not identical to the native built one in my run, they differ only in the build 
ID. So overriding the compiler works!

However, for most packages CC gets set to the appropriate cross-compiler by 
dh_auto_configure. Since the package doesn't use it, you'll need the tweaked 
solution:
include /usr/share/dpkg/architecture.mk # or call dpkg-architecture manually
ifeq ($(origin CC),default)
CC := `which $(DEB_HOST_GNU_TYPE)-gcc`
else
CC := /usr/bin/cc
endif

That will replace this new block:
ifeq (,$(CC))
CC := /usr/bin/cc
else
CC := `which $(CC)`
endif

Note that the conditional is always false, since GNU Make sets $(CC) to 'cc' 
automatically. This dilemma of deciding whether CC is user-specified or not is 
what the $(origin) syntax is required for.

With that final change, Pari will be cross-buildable out-of-the-box and you 
should start seeing green at crossqa: http://crossqa.debian.net/src/pari

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

Bug#980431: cmucl: Barely used and does not build on any modern architecture

[Jessica Clarke]

Source: cmucl
Version: 21d-1

Currently, cmucl is only available on i386. 10 years ago this was
perhaps excusable, but today this is a sign of a package that is stuck
in the past, full of legacy cruft, and not in widespread use[1]. It
certainly cannot be anything other than a non-leaf package for any
important packages given foreign dependencies are not permitted on
Debian's buildds[2]. That's all before you get to non-x86 architectures
such as 32-bit and 64-bit Arm. Its popcon is currently 0.02% if you take
the highest across any of the metrics.

I believe it is a waste of project resources to continue supporting such
packages and that they should be left behind rather than trying to drag
them kicking and screaming into the present. If someone is sufficiently
motivated to go and add full amd64 support then they should go ahead,
but otherwise I am of the view that it is time to admit that the package
no longer is of sufficient worth for Debian.

Jess

[1] Upstream does not seem to believe in 64-bit computing and itself
claims that doing a 64-bit port would be hard[2]. The former is no
excuse to not support the native execution mode of almost all
general-purpose consumer hardware that has been for sale in the past
10 years, regardless of personal belief (whether or not it's
recommended for performance reasons is a different matter, though
I'd be astounded if i386 code performed better than amd64 code due
to the pathetic register file size of the former; if pointer size is
really a concern there's nothing stopping it having a 4 GiB heap for
its lisp environment and using a 32-bit index with the 64-bit heap
base pointer). The latter is a sign that the code is poor quality
and has baked-in assumptions about pointers being 32-bit integers.

[2] In fact it has zero reverse dependencies and so can be removed from
the archive with zero disruption.

[3] https://gitlab.common-lisp.net/cmucl/cmucl/-/issues/75

Bug#980426: old pikepdf is blocking qpdf transition

[Sean Whitton]

Dear Jay,

On Mon 18 Jan 2021 at 05:35PM -05, Jay Berkenbilt wrote:

> Package: pikepdf
> Version: 1.17.3+dfsg-2
> X-Debbugs-CC: q...@debian.org
>
> This is a request to please upload the latest pikepdf to sid. Right now, qpdf 
> 10.1.0 is not able to transition to testing because autopkgtest is failing 
> because of a regression in pikepdf. The problem is actually in pikepdf, and 
> the pikepdf author resolved the issue within 24 hours of my release of qpdf 
> 10.1.0.
>
> Reference: https://qa.debian.org/excuses.php?package=qpdf
>
> Please let me know if any additional information is required. (I am the 
> debian maintainer and  upstream author of qpdf.)
>
> Also please let me know if you would like me to do an NMU. I can, but I'd 
> prefer not to have to do it. Thanks.

There are two blockers:

1) we're in the transitions freeze, so updating pikepdf would need
   permission from the release team

2) pikepdf has undergone a license change, and someone on the Debian
   side needs to look over upstream's work in contacting all
   copyright holders and having them okay it, and d/copyright needs
   updating.

Additionally, new releases of pikepdf typically involve a lot of work
updating d/copyright for new test resources.

So, perhaps we could just backport the fix?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#980397: support standard rsync urls

[Sean Whitton]

Hello,

On Mon 18 Jan 2021 at 02:39PM -04, Joey Hess wrote:

> Package: git-remote-gcrypt
> Version: 1.3-1
> Severity: normal
>
>rsync URIs
>   Note that the URI format for the rsync backend  is,  regretably,
>   non-standard.git-remote-gcrypt  uses  rsync://user@host:path
>   whereas   plain   rsync   useseitheruser@host:pathor
>   rsync://user@host/path.
>
> That needs to be supported for backwards compatability, I suppose,
> but is there any reason not to let gcrypt::rsync://user@host/path be used too?

I don't think this would introduce ambiguity.  I'd apply a patch.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#957248: gadmin-proftpd: ftbfs with GCC-10

[Logan Rosen]

Package: gadmin-proftpd
Version: 1:0.4.2-1
Followup-For: Bug #957248
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/05_gcc-10.patch: Mark variables as extern to fix FTBFS with GCC 10.

Thanks for considering the patch.

Logan
diff -Nru gadmin-proftpd-0.4.2/debian/patches/05-gcc_10.patch 
gadmin-proftpd-0.4.2/debian/patches/05-gcc_10.patch
--- gadmin-proftpd-0.4.2/debian/patches/05-gcc_10.patch 1969-12-31 
19:00:00.0 -0500
+++ gadmin-proftpd-0.4.2/debian/patches/05-gcc_10.patch 2021-01-18 
19:54:22.0 -0500
@@ -0,0 +1,15 @@
+--- a/src/apply_user.c
 b/src/apply_user.c
+@@ -51,10 +51,10 @@
+ extern gchar *homedir;
+ 
+ /* The directory checkbox values */
+-gchar *dir_val[19];
++extern gchar *dir_val[19];
+ extern long num_rows;
+ extern int row_pos;
+-char *user_profile;
++extern char *user_profile;
+ 
+ 
+ /* Check if the user exists in the selected server */
diff -Nru gadmin-proftpd-0.4.2/debian/patches/series 
gadmin-proftpd-0.4.2/debian/patches/series
--- gadmin-proftpd-0.4.2/debian/patches/series  2011-03-11 21:56:35.0 
-0500
+++ gadmin-proftpd-0.4.2/debian/patches/series  2021-01-18 19:53:51.0 
-0500
@@ -2,3 +2,4 @@
 02-icondir.patch
 03-desktop.patch
 04-spell_in_binary.patch
+05-gcc_10.patch

Bug#980430: ITP: r-cran-nanotime -- nanosecond resolution date and time calculations for R

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-nanotime
  Version : 0.3.2
  Upstream Author : Dirk Eddelbuettel and Leonardo Silvestri
* URL or Web page : https://github.com/eddelbuettel/nanotime
* License : GPL-2+
  Description : nanosecond resolution date and time calculations for R

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#980291: Bug#980294: libjs-jquery-flot: breaking API change

[Antonio Terceiro]

Hi,

FYI I have reopened this bug in a separate control message.

On Mon, Jan 18, 2021 at 05:09:16PM -0300, Antonio Terceiro wrote:
> On Mon, Jan 18, 2021 at 07:20:12PM +0100, Martin wrote:
> > On 2021-01-18 14:28, Antonio Terceiro wrote:
> > > In special, I need to stop including the standalone plugin files,
> > > because it's already included in the main file. This wasn't the case in
> > > the previous version, and I get that this is how upstream designed it to
> > > be.
> > 
> > Pretty "hacky" idea: How about leaving the main file as intended
> > by upstream, i.e. with all plugins included, and replace the the
> > plugin files with dummies? Or am I misunderstanding the issue?
> 
> That's actually great idea.

The attached patch implements this. I tested with the debci master
branch, without those changes I mentioned earlier in this thread, and it
works flawlessly.

Thanks for the idea.
From 4ce45b96e2296d135417b9506b0d22e7eed0497f Mon Sep 17 00:00:00 2001
From: Antonio Terceiro 
Date: Mon, 18 Jan 2021 21:44:59 -0300
Subject: [PATCH] Provide dummy plugin files for backwards compatibility

libjs-jquery-flot 0.8 provided the main file, jquery.flot.js, and one
had to include the plugin files explicitly. In version 4.2,
jquery.flot.js already includes the plugins, and existing code that
includes them again cause the charts to break in subtle ways.

Providing empty files in the place of the plugins allow existing usage
to continue working.

Thanks to W. Martin Borgert for the idea.

Closes: #980294
---
 debian/libjs-jquery-flot.install |  6 +-
 debian/rules | 13 ++---
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/debian/libjs-jquery-flot.install b/debian/libjs-jquery-flot.install
index 102d532..3eaf78d 100644
--- a/debian/libjs-jquery-flot.install
+++ b/debian/libjs-jquery-flot.install
@@ -1,7 +1,3 @@
-source/jquery.canvaswrapper*.js usr/share/javascript/jquery-flot/
-source/jquery.colorhelpers*.js usr/share/javascript/jquery-flot/
-source/jquery.flot.*.js usr/share/javascript/jquery-flot/
-source/*.map usr/share/javascript/jquery-flot/
 dist/es5/*.js usr/share/javascript/jquery-flot/
-dist/es5/*.js.map usr/share/javascript/jquery-flot/
 dist/es5/*.map usr/share/javascript/jquery-flot/
+plugins/*.js   usr/share/javascript/jquery-flot/
diff --git a/debian/rules b/debian/rules
index 4bc2f33..18e244e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,15 +5,22 @@
 
 override_dh_auto_build:
 	gulp build
-	cd source && for f in *.js; do \
-		echo "Minify source/$$f"; \
-		uglifyjs --source-map -o $${f%%.js}.min.js $$f; \
+	# Provide empty files for plugins for backwards compatibility since
+	# they are now included with the main jquery.flot.js file
+	mkdir plugins
+	cd source && for f in jquery.flot.*.js; do \
+		echo "Provide dummy file for $$f" ; \
+		touch ../plugins/$${f%%.js}.min.js ../plugins/$$f; \
 	done
 	cd dist/es5 && for f in *.js; do \
 		echo "Minify dist/es5/$$f"; \
 		uglifyjs --source-map -o $${f%%.js}.min.js $$f; \
 	done
 
+override_dh_auto_clean:
+	dh_auto_clean
+	$(RM) -r plugins
+
 get-orig-source:
 	OUTDIR=$$PWD ; \
 	MAKEFILE=`echo $(MAKEFILE_LIST) | awk '{ print $$1 }'` ; \
-- 
2.30.0



signature.asc
Description: PGP signature

Bug#913997: what is the current maintainer view on this ?

[Ryutaroh Matsumoto]

Hi all,

> Ryutaroh and I have been working with vmdb2 upstream on a new release
> with support for more architectures.

We are considering NMU of vmdb 0.22. The Salsa repo. is at
https://salsa.debian.org/ckk/vmdb2
Please also have a look at
https://salsa.debian.org/ckk/vmdb2/-/merge_requests/4

Best regards, Ryutaroh Matsumoto

Bug#980334: libvirt FTCBFS: uses the build architecture compiler via dtrace

[Andrea Bolognani]

On Sun, Jan 17, 2021 at 10:58:39PM +0100, Helmut Grohne wrote:
> Source: libvirt
> Version: 6.9.0-1
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> We're getting closer to making libvirt cross buildable. A lot of
> libvirt's dependencies have been fixed. One aspect that resides in
> libvirt is dtrace. dtrace runs a compiler and defaults to the build
> architecture compiler. As such it'll fail finding host architecture
> headers and that happens to break the build. When running dtrace, one
> must export the CC variable with a suitable value. Implementing this
> with meson is not entirely trivial due to
> https://github.com/mesonbuild/meson/issues/266. The attached patch
> therefore implements the suggested workaround. Please consider applying
> it to bring libvirt one step closer to being cross buildable.

Hi Helmut,

I was initially surprised by your report of FTCBFS, since the libvirt
project performs cross-builds on Debian as part of the regular
upstream CI pipelines.

After looking more closely, however, I realized that we're not
installing the foreign systemtap-sdt-dev package in the environments
used for cross-builds, whereas it's listed among Build-Depends in
Debian. So that explains why the upstream pipelines never caught
this issue.

This is a pretty obvious gap in upstream CI coverage, and we should
take the opportunity to address it. When I do, the result is

  https://gitlab.com/abologna/libvirt/-/pipelines/243473913
  
https://gitlab.com/abologna/libvirt/-/commit/f6184ca2629776b935e37f4f6e1acee4564b7843

just as one would expect based on your report; applying your patch on
top results in

  https://gitlab.com/abologna/libvirt/-/pipelines/243475989
  
https://gitlab.com/abologna/libvirt/-/commit/dd0cc0ab8c42e78be56f2939415b096f916e3e77

which is much better :)

Your patch looks reasonable and appears to work, but I'd rather have
it go through upstream, with the additional eyeballs that entails,
and then cherry-pick it into Debian instead of the other way around.

Are you okay with me submitting the patch upstream on your behalf? I
will of course make sure that authorship information are preserved
and that you get sole credit for your contribution.

The patch, as I intend to submit it upstream, is attached. Please let
me know if I can go ahead, and thank you for not only reporting this
issue but going the extra mile and providing a patch that fixes it :)

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.
From f83a95084e975ded6306ff8869ad18b7a8df3b70 Mon Sep 17 00:00:00 2001
From: Helmut Grohne 
Date: Tue, 19 Jan 2021 00:08:23 +0100
Subject: [libvirt PATCH] meson: Fix cross-building of dtrace probes

dtrace invokes the C compiler, so when cross-building we need
to make sure that $CC is set in the environment and that it
points to the cross-compiler rather than the native one.

Until https://github.com/mesonbuild/meson/issues/266
is addressed, the workaround is to call dtrace via env(1).

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

Signed-off-by: Helmut Grohne 
---
 meson.build  | 1 +
 src/meson.build  | 4 ++--
 src/qemu/meson.build | 4 ++--
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/meson.build b/meson.build
index b5277b4cba..84a7c524e8 100644
--- a/meson.build
+++ b/meson.build
@@ -2029,6 +2029,7 @@ if host_machine.system() == 'linux'
   if dtrace_prog.found()
 conf.set('WITH_DTRACE_PROBES', 1)
   endif
+  dtrace_command = [ 'env', 'CC=' + ' '.join(meson.get_compiler('c').cmd_array()), dtrace_prog ]
 endif
 
 if not get_option('host_validate').disabled() and host_machine.system() != 'windows'
diff --git a/src/meson.build b/src/meson.build
index 7c478219d6..56e71f4456 100644
--- a/src/meson.build
+++ b/src/meson.build
@@ -60,14 +60,14 @@ if conf.has('WITH_DTRACE_PROBES')
 out_h,
 input: infile,
 output: out_h,
-command: [ dtrace_prog, '-o', '@OUTPUT@', '-h', '-s', '@INPUT@' ],
+command: dtrace_command + [ '-o', '@OUTPUT@', '-h', '-s', '@INPUT@' ],
   )
 
   dtrace_gen_objects += custom_target(
 out_o,
 input: infile,
 output: out_o,
-command: [ dtrace_prog, '-o', '@OUTPUT@', '-G', '-s', '@INPUT@' ],
+command: dtrace_command + [ '-o', '@OUTPUT@', '-G', '-s', '@INPUT@' ],
   )
 
   custom_target(
diff --git a/src/qemu/meson.build b/src/qemu/meson.build
index 90640b03c6..e3065c3507 100644
--- a/src/qemu/meson.build
+++ b/src/qemu/meson.build
@@ -56,14 +56,14 @@ if conf.has('WITH_DTRACE_PROBES')
 out_h,
 input: infile,
 output: out_h,
-command: [ dtrace_prog, '-o', '@OUTPUT@', '-h', '-s', '@INPUT@' ],
+command: dtrace_command + [ '-o', '@OUTPUT@', '-h', '-s', '@INPUT@' ],
   )
 
   qemu_dtrace_gen_objects += custom_target(
 out_o,
 input: infile,
 output: out_o,
-command: [ dtrace_prog, '-o', '@OUTPUT@', '-G', '-s', '@INPUT@' ],
+command: dtrace_command + [ '-o', '@OUTPUT@', '-G', '-s', '@INPUT@' ],
   )
 
   qemu_dtrace_gen_stp = 

Bug#980416: ITP: jquery-i18n-properties -- lightweight jQuery internationalization plugin

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
debian-edu-pkg-t...@lists.alioth.debian.org

* Package name: jquery-i18n-properties
  Version : 1.2.7
  Upstream Author : Adrian Fish 
* URL : 
https://github.com/jquery-i18n-properties/jquery-i18n-properties
* License : Expat
  Programming Lang: Javascript
  Description : lightweight jQuery internationalization plugin

 Lightweight jQuery plugin for providing internationalization to JavaScript
 from ‘.properties’ files, just like in Java Resource Bundles. It loads
 and parses resource bundles (.properties) based on provided language
 and country codes (ISO-639 and ISO-3166) or language reported by browser.
 .
 This jQuery plugin is a required dependency for the already uploaded
 OpenBoard (at the time of testing and packaging, jquery-i18n-properties
 had been in Debian, however, it got removed some months ago which did
 not catch my intention).
 .
 Thus, re-uploading (with a much newer upstream version).

Bug#980429: g++-10: spurious c++17 mode segmentation fault in append_to_statement_list_1 (tree-iterator.c:65)

[Andreas Beckmann]

Package: g++-10
Version: 10.2.1-6
Severity: serious

Hi,

while rebuilding src:nheko I noticed an ICE with SEGFAULT.
I've somewhat minimized the testcase with delta (from 3.3 MB to 15 KB).

Build the attached code with

x86_64-linux-gnu-g++-10 -std=c++17 -Wno-return-type -c gcc-10-segfault.C

* it needs the -std=c++17 flag, without it no segfault occurs
* -Wno-return-type suppresses warnings caused by minimizing return statements 
away
* it is a regression from GCC-9, which always accepts the code
* it does not segfault always, but very likely needs less than 5 repetitions
  to result in segfault (out of 1000 test compiles 526 died with a segfault)
* there are two similar backtraces that may happen:

$ x86_64-linux-gnu-g++-10 -std=c++17 -Wno-return-type -c gcc-10-segfault.C
In file included from :
/usr/include/stdc-predef.h: In substitution of 'template std::function::function(_Functor) [with 
_Functor = ;  = ; 
 = ]':
gcc-10-segfault.C:283:12:   required from 'static void 
tweeny::detail::easingresolve::impl(FunctionTuple&, 
tweeny::easing::linearEasing, Fs ...) [with int I = 0; TypeTuple = 
std::array; FunctionTuple = std::tuple >; Fs = {}]'
gcc-10-segfault.C:289:64:   required from 'void 
tweeny::detail::easingfill(EasingCollectionT&, EasingT, 
tweeny::detail::int2type<0>) [with TypeTupleT = std::array; 
EasingCollectionT = std::tuple >; 
EasingT = tweeny::easing::linearEasing]'
gcc-10-segfault.C:297:41:   required from 'void 
tweeny::detail::tweenpoint::via(F) [with F = tweeny::easing::linearEasing; 
Ts = {float}]'
gcc-10-segfault.C:294:5:   required from 
'tweeny::detail::tweenpoint::tweenpoint(Ts ...) [with Ts = {float}]'
gcc-10-segfault.C:141:2:   required from 'static constexpr 
std::_Require::__construct_helper<_Tp, _Args>::type>, 
std::is_constructible<_Tp, _Args ...> > > 
std::allocator_traits<_Alloc>::_S_construct(_Alloc&, _Tp*, _Args&& ...) [with 
_Tp = tweeny::detail::tweenpoint; _Args = {float&}; _Alloc = 
std::allocator >; 
std::_Require::__construct_helper<_Tp, _Args>::type>, 
std::is_constructible<_Tp, _Args ...> > > = void; typename 
std::allocator_traits<_Alloc>::__construct_helper<_Tp, _Args>::type = 
std::integral_constant]'
gcc-10-segfault.C:144:14:   required from 'static decltype 
(std::allocator_traits<_Alloc>::_S_construct(__a, __p, 
(forward<_Args>)(std::allocator_traits<_Alloc>::construct::__args)...)) 
std::allocator_traits<_Alloc>::construct(_Alloc&, _Tp*, _Args&& ...) [with _Tp 
= tweeny::detail::tweenpoint; _Args = {float&}; _Alloc = 
std::allocator >; decltype 
(std::allocator_traits<_Alloc>::_S_construct(__a, __p, 
(forward<_Args>)(std::allocator_traits<_Alloc>::construct::__args)...)) = void]'
gcc-10-segfault.C:224:26:   required from 'std::vector<_Tp, _Alloc>::reference 
std::vector<_Tp, _Alloc>::emplace_back(_Args&& ...) [with _Args = {float&}; _Tp 
= tweeny::detail::tweenpoint; _Alloc = 
std::allocator >; std::vector<_Tp, 
_Alloc>::reference = tweeny::detail::tweenpoint&]'
gcc-10-segfault.C:310:21:   required from 'tweeny::tween& 
tweeny::tween::to(T) [with T = float]'
gcc-10-segfault.C:322:47:   required from here
/usr/include/stdc-predef.h:32:111: internal compiler error: Segmentation fault
   32 |whether the overall intent is to support these features; otherwise,
  | 
  ^
   33 |presume an older compiler has intent to support these features and
  |~
   
0xa65400 crash_signal
../../src/gcc/toplev.c:328
0x7f575b1ddd5f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xf09c3b append_to_statement_list_1
../../src/gcc/tree-iterator.c:65
0xf09c3b append_to_statement_list_force(tree_node*, tree_node**)
../../src/gcc/tree-iterator.c:105
0xf09c3b add_stmt(tree_node*)
../../src/gcc/cp/semantics.c:393
0x13a55c2 synthesize_method(tree_node*)
../../src/gcc/cp/method.c:1585
0x64cece maybe_instantiate_noexcept(tree_node*, int)
../../src/gcc/cp/pt.c:25338
0x768644 resolve_overloaded_unification
../../src/gcc/cp/pt.c:22255
0x768644 unify_one_argument
../../src/gcc/cp/pt.c:21801
0x111d442 type_unification_real
../../src/gcc/cp/pt.c:21945
0x111c93f fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* 
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool, 
bool)
../../src/gcc/cp/pt.c:21325
0x111c02a add_template_candidate_real(z_candidate**, tree_node*, tree_node*, 
tree_node*, tree_node*, vec const*, tree_node*, 
tree_node*, tree_node*, int, tree_node*, unification_kind_t, int) [clone 
.isra.0]
../../src/gcc/cp/call.c:3417
0xf538cd add_template_candidate
../../src/gcc/cp/call.c:3502
0xf538cd add_candidates
../../src/gcc/cp/call.c:5855
0x11289ec build_user_type_conversion_1

Bug#980428: CVE-2020-28948 write operations with directory traversal affecting Archive_Tar through 1.4.11

[David Prévot]

Package: php-pear
Version: 1:1.10.9+submodules+notgz-1.1
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

Hi,

The latest (1.4.11) Archive_Tar adds a fix related to CVE-2020-28948.

https://github.com/FriendsOfPHP/security-advisories/pull/525

Regards

David


signature.asc
Description: PGP signature

Bug#884662: fakeroot: regular files sometimes treated as directories

[Mattia Rizzolo]

Control: reassign -1 fakeroot 1.22-1
Control: retitle -1 fakeroot: regular files sometimes treated as directories 
when they are removed without fakeroot knowing
Control: affects -1 jenkins.debian.org

On Thu, Oct 08, 2020 at 01:39:09PM +0200, Christoph Berg wrote:
> > On Mon, 18 Dec 2017 at 23:30:05 +, Simon McVittie wrote:
> > > dpkg-deb: building package 'libglib2.0-data' in 
> > > '../libglib2.0-data_2.54.2-2_all.deb'.
> > > tar: ./usr/share/locale/en_CA/LC_MESSAGES/glib20.mo/: Cannot savedir: Not 
> > > a directory
> > 
> > This seems to be a symptom of some more general problem on the
> > reproducible-builds builders - I would guess it's either the
> > (FUSE?) filesystem, or a LD_PRELOAD hack that intercepts stat(), like
> > fakeroot does.
> 
> This "Not a directory" problem has started popping up in PostgreSQL
> build logs:
> 
> https://buildd.debian.org/status/fetch.php?pkg=pgagent=alpha=4.0.0-7=1602009768=0

yay, at least we can't say it's a r-b infra problem only! \o/

> https://buildd.debian.org/status/fetch.php?pkg=pgagent=sparc64=4.0.0-7=1601991893=0
> 
> It has also been seen on amd64.

> PG extension packages have started to run tests at build time, which
> is done via pg_virtualenv. Internally, for creating the temporary
> PostgreSQL server instance, LD_PRELOAD is unset, and that seems to be
> what confuses the "dh" and dpkg-buildpackage processes that share the
> same fakeroot instance.
> 
> jwilk did some debugging (thanks!) and came up with this simple
> recipe:
> 
> $ fakeroot sh -c 'mkdir foo; env -u LD_PRELOAD rmdir foo; touch bar; stat bar 
> | grep directory' Size: 0   Blocks: 0  IO Block: 4096 
> directory
> 
> So, if "foo" is removed without fakeroot knowing, the "bar" file is
> reported as a directory. (It doesn't get it wrong for me, it depends
> on inode numbers being recycled and similar.)

Thank you for providing such simple reproducer!

The fact that it depends on inode number recylcing also expains why we
saw it more often in tests.r-b.o, since there we have many more
concurrent builds and as such more writes.

> jwilk also noted that glib-2.0's debian/rules unsets LD_PRELOAD for
> the test suite too which strengthens the evidence that fakeroot is to
> blame.

As such, I'm finally reasigning this bug to fakeroot, thank you to all
you involved in debugging the matter!

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#913997: what is the current maintainer view on this ?

[Christian Kastner]

Hi all,

On Sat, 19 Dec 2020 Pirate Praveen wrote:>> Renaming the binary is
harder, because there are at least two
>> packages that use yarn from cmdtest during the build: gitano and
>> vmdb2. they would need to be ported, and that's up to their
>> maintainers and upstreams, who I assume won't be happy about it.
> 
> Now only xauth and vmdb2 shows up as reverse build dependencies. I 
> have asked their maintainers if they are open to the name change in 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977709
Ryutaroh and I have been working with vmdb2 upstream on a new release
with support for more architectures.

During this process, upstream indicated that vmdb2 will move away from
yarn (cmdtest) to Subplot (not yet packaged).

A quick grep of the sources of xauth, the other reverse dependency of
cmdtest, gets no results for the string 'yarn'. So the conflicting
binary does not seem to be used there.

So, strictly from the point of view of its reverse dependencies, holding
off on renaming the 'yarn' binary would probably not make much sense.

Best,
Christian

Bug#980427: garbled message window after terminal resize

[Ryan Kavanagh]

Control: tags -1 + patch

The attached patch fixes this bug. You can apply it with

git am 0001-Clear-the-message-window-on-SIGWINCH-redraw-on-sigwi.patch

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A
From 659998e565c12effa5c647a2578f6b8f72607f27 Mon Sep 17 00:00:00 2001
From: Ryan Kavanagh 
Date: Mon, 18 Jan 2021 18:01:34 -0500
Subject: [PATCH] Clear the message window on SIGWINCH,
 redraw-on-sigwinch.patch (Closes: #980427)

---
 debian/patches/misc/redraw-on-sigwinch.patch | 43 
 debian/patches/series|  1 +
 2 files changed, 44 insertions(+)
 create mode 100644 debian/patches/misc/redraw-on-sigwinch.patch

diff --git a/debian/patches/misc/redraw-on-sigwinch.patch b/debian/patches/misc/redraw-on-sigwinch.patch
new file mode 100644
index 0..a09031b97
--- /dev/null
+++ b/debian/patches/misc/redraw-on-sigwinch.patch
@@ -0,0 +1,43 @@
+From: Richard Russon 
+Date: Mon, 7 Dec 2020 14:21:45 +
+Subject: clear the message window on SIGWINCH (#2756)
+
+When the terminal is resized (or the font-size is changed),
+the screen must be redrawn.  This *used* to involve clearing the entire
+screen.  Soon, it will be delegated to individual windows to refresh
+themselves.
+
+In the mean time, forcibly clear the MessageWindow.
+
+Fixes: #2749
+
+Origin: https://github.com/neomutt/neomutt/commit/88f0b0572da9414550608054e960fd00b8d6b939
+---
+ index.c | 1 +
+ pager.c | 1 +
+ 2 files changed, 2 insertions(+)
+
+diff --git a/index.c b/index.c
+index c29ba8b..af3a18f 100644
+--- a/index.c
 b/index.c
+@@ -1368,6 +1368,7 @@ int mutt_index_menu(struct MuttWindow *dlg)
+ /* force a real complete redraw.  clrtobot() doesn't seem to be able
+  * to handle every case without this.  */
+ clearok(stdscr, true);
++mutt_window_clearline(MessageWindow, 0);
+ continue;
+   }
+ 
+diff --git a/pager.c b/pager.c
+index b08dda2..0e333c0 100644
+--- a/pager.c
 b/pager.c
+@@ -2473,6 +2473,7 @@ int mutt_pager(const char *banner, const char *fname, PagerFlags flags, struct P
+   SigWinch = 0;
+   mutt_resize_screen();
+   clearok(stdscr, true); /* force complete redraw */
++  mutt_window_clearline(MessageWindow, 0);
+ 
+   if (flags & MUTT_PAGER_RETWINCH)
+   {
diff --git a/debian/patches/series b/debian/patches/series
index 06cb026ad..9b54666f6 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@ debian-specific/neomuttrc.patch
 debian-specific/use_usr_bin_editor.patch
 debian-specific/document_debian_defaults.patch
 misc/smime.rc.patch
+misc/redraw-on-sigwinch.patch
-- 
2.30.0



signature.asc
Description: PGP signature

Bug#980427: garbled message window after terminal resize

[Ryan Kavanagh]

Package: neomutt
Version: 20201120+dfsg.1-1
Severity: minor
Tags: upstream
Control: forwarded -1 
https://github.com/neomutt/neomutt/commit/88f0b0572da9414550608054e960fd00b8d6b939
X-Debbugs-Cc: r...@debian.org

neomutt fails to properly redraw its message window after a resize.
This leads to garbled text on the screen.

-- Package-specific info:
NeoMutt 20201120
Copyright (C) 1996-2020 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 5.10.0-1-amd64 (x86_64)
ncurses: ncurses 6.2.20201114 (compiled with 6.2.20201114)
libidn: 1.33 (compiled with 1.33)
GPGME: 1.14.0-unknown
GnuTLS: 3.6.15
libnotmuch: 5.3.0
storage: tokyocabinet

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
{--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec 
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss 
--idn --mixmaster --sasl --tokyocabinet --sqlite --autocrypt

Compilation CFLAGS: -g -O2 
-fdebug-prefix-map=/build/neomutt-Ulxxh7/neomutt-20201120+dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include 
-I/usr/include/lua5.4 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5

Default options:
  +attach_headers_color +compose_to_sender +compress +cond_date +debug 
  +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
  +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
  +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
  +skip_quoted +smtp +status_color +timeout +tls_sni +trash 

Compile options:
  +autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens 
  +getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify 
  -locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +regex +sasl 
  +smime +sqlite +start_color +sun_attachment +typeahead 
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to: 

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages neomutt depends on:
ii  libc6 2.31-9
ii  libgnutls30   3.7.0-5
ii  libgpg-error0 1.38-2
ii  libgpgme111.14.0-1+b2
ii  libgssapi-krb5-2  1.18.3-4
ii  libidn11  1.33-3
ii  liblua5.4-0   5.4.2-2
ii  libncursesw6  6.2+20201114-2
ii  libnotmuch5   0.31.3-2
ii  libsasl2-22.1.27+dfsg-2
ii  libsqlite3-0  3.34.0-1
ii  libtinfo6 6.2+20201114-2
ii  libtokyocabinet9  1.4.48-13
ii  sensible-utils0.0.14

Versions of packages neomutt recommends:
ii  libsasl2-modules  2.1.27+dfsg-2
ii  locales   2.31-9
ii  mime-support  3.66

Versions of packages neomutt suggests:
ii  aspell0.60.8-2
ii  ca-certificates   20200601
ii  gnupg 2.2.20-1
ii  ispell3.4.02-2
pn  mixmaster 
ii  opensmtpd [mail-transport-agent]  6.8.0p2-2
ii  openssl   1.1.1i-2
pn  urlview   

Versions of packages neomutt is related to:
ii  neomutt  20201120+dfsg.1-1

-- no debconf information

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


signature.asc
Description: PGP signature

Bug#980423: 3.12.4 makes several packages FTBFS

[GCS]

On Mon, Jan 18, 2021 at 10:24 PM Laurent Bigonville  wrote:
> Several packages FTBFS since 3.12.4
>
> The autopkgtest catched ignition-msgs and ignition-transport, see
> https://packages.qa.debian.org/p/protobuf.html
>
> I can see that evolution-data-server also FTBFS
[...]
> This is a bit unfortunate that it's happening so late in the developpement 
> cycle.
 Indeed, my fault. Investigating. Hope this can be resolved easily.

Thanks,
Laszlo/GCS

Bug#943874: pure-ftpd: pure-ftp error on upgrade

[Andreas Beckmann]

Followup-For: Bug #943874
Control: tag -1 patch pending

Hi,

I'm attaching a patch that tries to clean up the docdir symlink mess.
The package is already uploaded to DELAYED/5.


Andreas


pure-ftpd_1.0.49-4.1.dsc.diff.xz
Description: application/xz

Bug#788662: Logged-in user no longer granted permission to removable disks

[Josh Triplett]

On Thu, Jan 14, 2021 at 03:13:31PM +0100, Michael Biebl wrote:
> Hi Josh
> 
> Am 15.06.15 um 17:56 schrieb Josh Triplett:
> > On Mon, Jun 15, 2015 at 12:36:45PM +0200, Michael Biebl wrote:
> > > Am 15.06.2015 um 07:34 schrieb Martin Pitt:
> > > > Hey Josh,
> > > > 
> > > > Josh Triplett [2015-06-13 16:23 -0700]:
> > > > > I plugged in a removable USB disk, and its devices showed up as 
> > > > > root:disk 0660,
> > > > > with no ACLs.  Normally, I'd expect removable USB disks to grant
> > > > > read/write permission to the logged-in user.
> > > > > ~$ ls -l /dev/sdb*
> > > > > brw-rw 1 root disk 8, 16 Jun 13 16:17 /dev/sdb
> > > > > brw-rw 1 root disk 8, 17 Jun 13 16:17 /dev/sdb1
> > > > 
> > > > That's expected. As Michael already said, we never explicitly granted
> > > > user access to device nodes. Maybe in the past some devices got that
> > > > through specific group membership, or you had some custom udev rules
> > > > to do that; but throughout the history of pmount, hal, consolekit,
> > > > udev etc. in Debian the device nodes themselves weren't user
> > > > accessible in general. The main exception there that I remember is
> > > > Fedora's/Red Hat's ancient console_helper (or something similar) which
> > > > actually changed the device nodes themselves. But that was some decade
> > > > ago already..
> > > 
> > > I checked wheezy, and it had the following rules:
> > > 91-permissions: SUBSYSTEM=="block", ATTRS{removable}=="1", GROUP="floppy"
> > > 91-permissions: SUBSYSTEM=="block", 
> > > SUBSYSTEMS=="usb|ieee1394|mmc|pcmcia", GROUP="floppy"
> > > 
> > > See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751892
> > > 
> > > Maybe we should merge those two bug reports?
> > 
> > Merging them seems fine, but I do think this functionality from wheezy
> > should be restored.  Not using the "floppy" group or any static group,
> > but using the uaccess mechanism.
> > 
> > Either that, or there should be a NEWS.Debian entry somewhere
> > documenting that direct device access by users was removed and won't
> > come back for security reasons.  But I don't see an obvious reason why
> > removable USB disk devices should not be accessible to users.
> 
> I'm looking at older bug reports and I'm wondering what to do about this
> one. I guess the time for a NEWS entry has passed.
> Regarding granting access to "removable" media write access via uaccess, I'm
> not strictly against that, I just would prefer this to happen and be
> implemented upstream. One problematic issue I can imagine is that it's not
> trivial to reliably determine whether a disk is really removable or not.
> That said, if you are still interested, would you mind filing an upstream
> bug report at https://github.com/systemd/systemd/issues.

Filed upstream as https://github.com/systemd/systemd/issues/18304 .

Thank you again for all your work on systemd and udev, including triage!

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Francesco Poli]

On Sun, 20 Dec 2020 15:34:54 +0100 Francesco Poli wrote:

[...]
> Hello again.
> I've just tested firefox-esr/78.6.0esr-1 from unstable and
> firefox-esr/78.6.0esr-1~deb10u1 from stable/updates.
> 
> They behave exactly as firefox-esr/78.3.0esr-2: after allowing the use
> of the mic, the mic signal does not seem to reach the browser (as if
> the mic were broken).
> 
> But the mic works perfectly with chromium.
> 
> > 
> > I had to downgrade firefox-esr again...  :-(
> 
> And once again, I had to downgrade firefox-esr to version 68.7.0esr-1,
> so that the mic works.
> 
> > 
> > Is there any progress on this bug?
> 
> Is there any progress on this bug?
> Has any developer been able to reproduce it?
> 
> Please recall that, according to another user, the [mic works] on
> firefox-esr without Debian patches. Hence, it seems that the issue is
> caused by one of the Debian patches.
> Could you please investigate in this direction?
> 
> [mic works]: 
> 
> Please let me know.
> I am more and more worried by the need to stay with an old firefox-esr
> version!

Hello again and again and again...

Another test: firefox-esr/78.6.1esr-1
No difference: after allowing the use of the mic, the mic signal does
not seem to reach the browser (as if the mic were broken).

But the mic works perfectly with chromium and with
firefox-esr/68.7.0esr-1 ...

Is there any news on this issue?
Could you please reply?

Thanks for your time!




-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpRjakp3Soky.pgp
Description: PGP signature

Bug#980426: old pikepdf is blocking qpdf transition

[Jay Berkenbilt]

Package: pikepdf
Version: 1.17.3+dfsg-2
X-Debbugs-CC: q...@debian.org

This is a request to please upload the latest pikepdf to sid. Right now, qpdf 
10.1.0 is not able to transition to testing because autopkgtest is failing 
because of a regression in pikepdf. The problem is actually in pikepdf, and the 
pikepdf author resolved the issue within 24 hours of my release of qpdf 10.1.0.

Reference: https://qa.debian.org/excuses.php?package=qpdf

Please let me know if any additional information is required. (I am the debian 
maintainer and  upstream author of qpdf.)

Also please let me know if you would like me to do an NMU. I can, but I'd 
prefer not to have to do it. Thanks.

Bug#980425: RFS: zam-plugins/3.14~repack3-1 -- Collection of LV2, LADSPA, LINUX-VST and JACK plugins

[Dennis Braun]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "zam-plugins":

 * Package name    : zam-plugins
   Version : 3..14~repack3-1
   Upstream Author : Damien Zammit 
 * URL : https://github.com/zamaudio/zam-plugins
 * License : ISC, LGPL-2.1+, GPL-2+, MIT/X11, LGPL-2+, LGPL, CUSTOM
 * Vcs : https://salsa.debian.org/multimedia-team/zam-plugins
   Section : sound

It builds those binary packages:

  zam-plugins - Collection of LV2, LADSPA, LINUX-VST and JACK plugins

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/zam-plugins/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/z/zam-plugins/zam-plugins_3.14~repack3-1.dsc


Changes since the last upload:

 zam-plugins (3.14~repack3-1) unstable; urgency=medium
 .
   * New upstream version 3.14~repack3
   * Fix build with zita-convolver
   * Update d/copyright year for my entry

Regards,
Dennis

Bug#980308: ITP: open-roms -- ROM files for retro computers

[Reiner Herrmann]

Hi László,

On Sun, Jan 17, 2021 at 07:03:06PM +0100, László Böszörményi wrote:
> On Sun, Jan 17, 2021 at 5:21 PM Reiner Herrmann  wrote:
> > * Package name: open-roms
> [...]
> > With these ROM files in main, this would also allow vice (maintainer CC'ed)
> > to move from contrib to main, as it can then be used meaningfully with only
> > free software.
>  Good point! I don't know when they can finish with C64 kernal and
> basic ROMs, but I guess it will take time. :(
> Ping me if you have anything to share.

The ROMs are actually already quite usable. The kernal has most features
implemented, but in basic some commands are still missing.
But it is sufficient to already run several games with it.

If you want to give it a try, the package is available on salsa:
 https://salsa.debian.org/reiner/open-roms

The package will install these three files:
 /usr/share/open-roms/C64/basic
 /usr/share/open-roms/C64/chargen
 /usr/share/open-roms/C64/kernal

To use them with vice:

 $ x64 -basic /usr/share/open-roms/C64/basic -kernal 
/usr/share/open-roms/C64/kernal -chargen /usr/share/open-roms/C64/chargen

Kind regards,
  Reiner


signature.asc
Description: PGP signature

Bug#980424: RFS: ghostwriter/2.0.0~rc3-1 -- Distraction-free, themeable Markdown editor

[passiongnulinux]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "ghostwriter":

 * Package name: ghostwriter
   Version : 2.0.0~rc3-1
   Upstream Author : wereturtle 
 * URL : https://wereturtle.github.io/ghostwriter/
 * License : ISC, CC-BY-SA-4.0, GPL-3.0, Expat, GPL-3.0+
 * Vcs : https://salsa.debian.org/seb95-guest/ghostwriter
   Section : editors

It builds those binary packages:

  ghostwriter - Distraction-free, themeable Markdown editor

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/ghostwriter/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/ghostwriter/ghostwriter_2.0.0~rc3-1.dsc

Changes since the last upload:

 ghostwriter (2.0.0~rc3-1) experimental; urgency=medium
 .
   * New upstream RC release.

Regards,

Bug#980416: ITP: jquery-i18n-properties -- lightweight jQuery internationalization plugin

[Xavier]

Le 18/01/2021 à 21:38, Mike Gabriel a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Mike Gabriel 
> X-Debbugs-Cc: debian-de...@lists.debian.org, 
> debian-edu-pkg-t...@lists.alioth.debian.org
> 
> * Package name: jquery-i18n-properties
>   Version : 1.2.7
>   Upstream Author : Adrian Fish 
> * URL : 
> https://github.com/jquery-i18n-properties/jquery-i18n-properties
> * License : Expat
>   Programming Lang: Javascript
>   Description : lightweight jQuery internationalization plugin
> 
>  Lightweight jQuery plugin for providing internationalization to JavaScript
>  from ‘.properties’ files, just like in Java Resource Bundles. It loads
>  and parses resource bundles (.properties) based on provided language
>  and country codes (ISO-639 and ISO-3166) or language reported by browser.
>  .
>  This jQuery plugin is a required dependency for the already uploaded
>  OpenBoard (at the time of testing and packaging, jquery-i18n-properties
>  had been in Debian, however, it got removed some months ago which did
>  not catch my intention).
>  .
>  Thus, re-uploading (with a much newer upstream version).

This library seems unmaintained: last commit 4 years ago. I don't think
it's a good thing to upload such library in Debian.

Bug#980291: [Pkg-javascript-devel] Bug#980291: Bug#980291: Bug#980294: libjs-jquery-flot: breaking API change

[Xavier]

Le 18/01/2021 à 18:47, Pirate Praveen a écrit :
> 
> On Mon, Jan 18, 2021 at 2:28 pm, Antonio Terceiro 
> wrote:
>> But the fact is that all the other reverse dependencies that used any
>> plugin now need to be changed accordingly. Otherwise we can just wait
>> for their chart features to break in subtle ways in the face of users.
> 
> Not specific to this bug, but in general, we need to be a lot more
> careful and slow when updating node modules that also has libjs-* since
> we don't really have automated tests for them. For, node only parts we
> have tests most of the time, though not all packages have tests. So we
> have to be generally slow down on any major version update.

Maintaining an unsupported version means taking the risk to be unable to
backport a security fix during stable life and LTS (we already have many
examples).
_Before freeze_, I prefer having updated libraries, take the risk to
break sometime something, and patch reverse dependencies (with an
upstream PR when useful): breaking a little testing/unstable is not a
drama. But we are a team, if the team prefer to take the security risk,
then OK, I'll stop updating any libjs-* package (and stop tearing my
hair to patch obsolete packages when a CVE exists).

For the rhythm, most of libjs/node-* packages were strongly outdated in
Buster, the sustained pace of 2020 only partially made up for the
accumulated delay and the related technical debt.

Anyway, we entered freeze, it's not time to update anything not needed,
except minor and tested updates, but I'm happy to have updated a lot of
packages before freeze even if it has broken unstable sometime.
I feel the [1] dashboard better now than before Buster release.

[1]:
https://udd.debian.org/dmd/?email1=pkg-javascript-devel%40lists.alioth.debian.org=html

Bug#980423: 3.12.4 makes several packages FTBFS

[Laurent Bigonville]

Source: protobuf
Version: 3.12.4-1
Severity: serious

Hello,

Several packages FTBFS since 3.12.4

The autopkgtest catched ignition-msgs and ignition-transport, see
https://packages.qa.debian.org/p/protobuf.html 

I can see that evolution-data-server also FTBFS

All seems to FTBFS for more or less the same reasons:

/usr/include/ignition/msgs5/ignition/msgs/version.pb.h:59:51: error: 
‘AuxiliaryParseTableField’ in namespace ‘google::protobuf::internal’ does not 
name a type; did you mean ‘AuxillaryParseTableField’?
   59 |   static const 
::PROTOBUF_NAMESPACE_ID::internal::AuxiliaryParseTableField aux[]
  |   
^~~~
  |   
AuxillaryParseTableField

This is a bit unfortunate that it's happening so late in the developpement 
cycle.

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
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#914056: cclive: diff for NMU version 0.9.3-0.2

[Sudip Mukherjee]

Control: tags 914056 + patch
Control: tags 914056 + pending
Control: tags 953544 + patch
Control: tags 953544 + pending
--

Dear maintainer,

I've prepared an NMU for cclive (versioned as 0.9.3-0.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru cclive-0.9.3/debian/changelog cclive-0.9.3/debian/changelog
--- cclive-0.9.3/debian/changelog   2016-02-18 16:30:48.0 +
+++ cclive-0.9.3/debian/changelog   2021-01-18 20:29:07.0 +
@@ -1,3 +1,12 @@
+cclive (0.9.3-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with boost 1.67. (Closes: #914056)
+- Thanks to Giovanni Mascellani.
+- Rebuild will depend on current libboost packages. (Closes: #953544)
+
+ -- Sudip Mukherjee   Mon, 18 Jan 2021 20:29:07 
+
+
 cclive (0.9.3-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru cclive-0.9.3/debian/patches/fix_ftbfs.patch 
cclive-0.9.3/debian/patches/fix_ftbfs.patch
--- cclive-0.9.3/debian/patches/fix_ftbfs.patch 1970-01-01 01:00:00.0 
+0100
+++ cclive-0.9.3/debian/patches/fix_ftbfs.patch 2021-01-18 20:11:41.0 
+
@@ -0,0 +1,22 @@
+Description: Fix FTBFS with Boost 1.67
+ In Boost 1.67 parameters passed to time constructors must be
+ integral. This does not change the previos behaviour, since
+ the count was already stored as an integer anyway. The only
+ different is that now the conversion must be explicit.
+
+Author: Giovanni Mascellani 
+Bug-Debian: https://bugs.debian.org/914056
+
+---
+
+--- cclive-0.9.3.orig/src/cc/progressbar.h
 cclive-0.9.3/src/cc/progressbar.h
+@@ -316,7 +316,7 @@ private:
+ 
+   static inline std::string eta_from_seconds(const double s)
+   {
+-const pt::time_duration& td = pt::seconds(s);
++const pt::time_duration& td = pt::seconds(static_cast(s));
+ return pt::to_simple_string(td);
+   }
+ 
diff -Nru cclive-0.9.3/debian/patches/series cclive-0.9.3/debian/patches/series
--- cclive-0.9.3/debian/patches/series  2016-02-18 16:19:53.0 +
+++ cclive-0.9.3/debian/patches/series  2021-01-18 20:10:55.0 +
@@ -1,3 +1,4 @@
 fix-rpath.diff
 gcc5.diff
 fix-FTBFS-missing-includes.patch
+fix_ftbfs.patch

Bug#980422: kitchensink-clojure: autopkgtest failure on i386

[Adrian Bunk]

Source: kitchensink-clojure
Version: 3.1.1-2
Severity: serious
Control: block 975207 by -1

https://ci.debian.net/data/autopkgtest/testing/i386/k/kitchensink-clojure/9803014/log.gz

...
autopkgtest [17:24:31]: test unittests: [---
WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: 
puppetlabs.kitchensink.core-test, being replaced by: 
#'puppetlabs.kitchensink.core/boolean?
WARNING: uuid? already refers to: #'clojure.core/uuid? in namespace: 
puppetlabs.kitchensink.core-test, being replaced by: 
#'puppetlabs.kitchensink.core/uuid?
Syntax error (FileNotFoundException) compiling at 
(./test/puppetlabs/kitchensink/core_test.clj:1:1).
Could not locate puppetlabs/kitchensink/testutils__init.class, 
puppetlabs/kitchensink/testutils.clj or puppetlabs/kitchensink/testutils.cljc 
on classpath.

Full report at:
/tmp/clojure-12994910647831856891.edn
autopkgtest [17:24:39]: test unittests: ---]
autopkgtest [17:24:39]: test unittests:  - - - - - - - - - - results - - - - - 
- - - - -
unittestsFAIL non-zero exit status 123
autopkgtest [17:24:39]: test unittests:  - - - - - - - - - - stderr - - - - - - 
- - - -
WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: 
puppetlabs.kitchensink.core-test, being replaced by: 
#'puppetlabs.kitchensink.core/boolean?
WARNING: uuid? already refers to: #'clojure.core/uuid? in namespace: 
puppetlabs.kitchensink.core-test, being replaced by: 
#'puppetlabs.kitchensink.core/uuid?
Syntax error (FileNotFoundException) compiling at 
(./test/puppetlabs/kitchensink/core_test.clj:1:1).
Could not locate puppetlabs/kitchensink/testutils__init.class, 
puppetlabs/kitchensink/testutils.clj or puppetlabs/kitchensink/testutils.cljc 
on classpath.

Full report at:
/tmp/clojure-12994910647831856891.edn
autopkgtest [17:24:39]:  summary
buildPASS (superficial)
unittestsFAIL non-zero exit status 123

Bug#970719: aide: dependency problem aide

[Marc Haber]

On Tue, Sep 22, 2020 at 01:07:19PM +0200, Hans-J. Ullrich wrote:
> I am not quite sure, but please take a look:

I am having a hard time understanding this bug report. Since all active
members of the aide team are German, would you mind re-wording this
bug report in German so that we can rule out language problems?

Greetings
Marc

Bug#980421: libjpeg FTCBFS: fails to compute reasonable compiler identification from cross tools

[Helmut Grohne]

Source: libjpeg
Version: 0.0~git20200925.f145908-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libjpeg fails to cross build from source, because it attempts to include
a file e.g. Makefile_Settings.arm. The "arm" part here comes from an
attempt at extracting a compiler identification from the compiler
variable. The $ac_tool_prefix confuses the parsing code. It needs to be
stripped of. Please consider applying the attached patch to make libjpeg
cross buildable.

Helmut
--- libjpeg-0.0~git20200925.f145908.orig/configure.in
+++ libjpeg-0.0~git20200925.f145908/configure.in
@@ -69,13 +69,13 @@
 # or a generic compiler
 if test "$ac_compiler_gnu" = "yes"; then
 # Define a couple of options concerning the compiler
-  ac_cccmd=`echo ${CC} | cut -f 1 -d ' ' | cut -f 1 -d '-'`
+  ac_cccmd=`echo ${CC} | cut -f 1 -d ' ' | sed "s/^$ac_tool_prefix//" | cut -f 1 -d '-'`
   if test "$ac_cccmd" = "icpc"; then
  ac_cccmd="icc"
   fi
   AC_SUBST(SETTINGS,${ac_cccmd})
 else
-  ac_cccmd=`echo ${CXX} | cut -f 1 -d ' '`
+  ac_cccmd=`echo ${CXX} | sed "s/^$ac_tool_prefix//" | cut -f 1 -d ' '`
   AC_SUBST(SETTINGS,${ac_cccmd})
 fi
 AC_SUBST(COMPILER,${CXX})

Bug#980420: mark python3-pystache Multi-Arch: foreign

[Helmut Grohne]

Package: python3-pystache
Version: 0.5.4-6.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:linphone

linphone cannot be cross built from source, because its dependency on
python3-pystache is not satisfiable. In general, Architecture: all
packages can never satisfy cross Build-Depends unless marked Multi-Arch:
foreign or annotated :any. In this case, a foreign marking is
reasonable, because pystache is a pure Python module. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru pystache-0.5.4/debian/changelog 
pystache-0.5.4/debian/changelog
--- pystache-0.5.4/debian/changelog 2019-12-21 00:01:35.0 +0100
+++ pystache-0.5.4/debian/changelog 2021-01-18 13:28:03.0 +0100
@@ -1,3 +1,10 @@
+pystache (0.5.4-6.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark python3-pystache Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 18 Jan 2021 13:28:03 +0100
+
 pystache (0.5.4-6.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru pystache-0.5.4/debian/control pystache-0.5.4/debian/control
--- pystache-0.5.4/debian/control   2019-12-21 00:00:12.0 +0100
+++ pystache-0.5.4/debian/control   2021-01-18 13:28:01.0 +0100
@@ -11,6 +11,7 @@
 
 Package: python3-pystache
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}, ${python3:Depends}
 Description: Python3 implementation of Mustache
  Pystache is Python3 implementation of Mustache.

Bug#980419: nip2: unused Build-Depend: libgoffice-0.10-dev

[Helmut Grohne]

Source: nip2
Version: 8.7.1-1
Severity: minor
Tags: patch

I noticed that nip2 checks for goffice-0.8, but it Build-Depends on
libgoffice-0.10-dev. As such, it fails to find goffice-0.8 and disables
goffice integration. The libgoffice-0.10-dev dependency is entirely
unused. Please consider dropping it. I'm attaching a patch for your
convenience.

Helmut
diff --minimal -Nru nip2-8.7.1/debian/changelog nip2-8.7.1/debian/changelog
--- nip2-8.7.1/debian/changelog 2020-07-06 19:20:34.0 +0200
+++ nip2-8.7.1/debian/changelog 2021-01-18 21:06:30.0 +0100
@@ -1,3 +1,10 @@
+nip2 (8.7.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused libgoffice-0.10-dev build dependency. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 18 Jan 2021 21:06:30 +0100
+
 nip2 (8.7.1-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru nip2-8.7.1/debian/control nip2-8.7.1/debian/control
--- nip2-8.7.1/debian/control   2020-07-06 19:20:34.0 +0200
+++ nip2-8.7.1/debian/control   2021-01-18 21:06:21.0 +0100
@@ -1,7 +1,7 @@
 Source: nip2
 Section: graphics
 Priority: optional
-Build-Depends: debhelper-compat (= 12), libglib2.0-dev, libpango1.0-dev, 
libatk1.0-dev, libgtk2.0-dev, libvips-dev (>= 8.4), shared-mime-info, 
gnome-icon-theme, hicolor-icon-theme, flex, bison, intltool, fftw3-dev | 
libfftw3-dev, libxml2-dev, pkg-config, libjpeg-dev, zlib1g-dev, libpng-dev, 
libmagickcore-dev, libmagickwand-dev, libfreetype6-dev, libfontconfig1-dev, 
libice-dev, gettext, libgsl-dev, libgoffice-0.10-dev, libgraphviz-dev
+Build-Depends: debhelper-compat (= 12), libglib2.0-dev, libpango1.0-dev, 
libatk1.0-dev, libgtk2.0-dev, libvips-dev (>= 8.4), shared-mime-info, 
gnome-icon-theme, hicolor-icon-theme, flex, bison, intltool, fftw3-dev | 
libfftw3-dev, libxml2-dev, pkg-config, libjpeg-dev, zlib1g-dev, libpng-dev, 
libmagickcore-dev, libmagickwand-dev, libfreetype6-dev, libfontconfig1-dev, 
libice-dev, gettext, libgsl-dev, libgraphviz-dev
 Maintainer: Laszlo Boszormenyi (GCS) 
 Standards-Version: 4.5.0
 Homepage: https://github.com/libvips/nip2

Bug#980418: demote dependency on libdv-bin to Recommends

[Helmut Grohne]

Package: libsynfig0a
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

synfigstudio cannot be cross built from source, its Build-Depends cannot
be installed. It depends on libsynfig0a for both the build architecture
(via synfig) and the host architecture (via libsynfig-dev), which is
fine until libsynfig0a depends on libdv-bin, which is implicitly
Multi-Arch: no. I've looked into why libsynfig0a needs libdv-bin and it
seems like mod_dv uses encodedv. That sounds a lot like an optional
component. A shared library should rarely depend on support tools,
because it is often pulled into a dependency tree via linking. Instead,
the application using the optional component should carry the
dependency. Often times, this means demoting such a dependency to
Recommends. Thus, I propose demoting libsynfig0a's dependency on
libdv-bin to Recommends. Does that sound reasonable?

Helmut

Bug#980417: silx: drop unused *-dbg packages from Build-Depends

[Helmut Grohne]

Source: silx
Version: 0.14.0+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

silx cannot be cross built from source, because its Build-Depends are
not satisfiable. Instead of looking into this difficult problem, I
looked into easily droppable dependencies. It turns out that all of the
*-dbg dependencies but python3-all-dbg can be dropped with no
replacement. Since silx is normally reproducible, one can verify that
dropping them does not affect the result in any way. The build log does
neither exhibit any sign of difference due to these dependencies. Please
consider dropping them. I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru silx-0.14.0+dfsg/debian/changelog 
silx-0.14.0+dfsg/debian/changelog
--- silx-0.14.0+dfsg/debian/changelog   2021-01-06 15:17:45.0 +0100
+++ silx-0.14.0+dfsg/debian/changelog   2021-01-18 19:53:08.0 +0100
@@ -1,3 +1,10 @@
+silx (0.14.0+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused -dbg packages from Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 18 Jan 2021 19:53:08 +0100
+
 silx (0.14.0+dfsg-1) unstable; urgency=medium
 
   * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository, 
Repository-Browse.
diff --minimal -Nru silx-0.14.0+dfsg/debian/control 
silx-0.14.0+dfsg/debian/control
--- silx-0.14.0+dfsg/debian/control 2021-01-06 15:17:45.0 +0100
+++ silx-0.14.0+dfsg/debian/control 2021-01-18 19:53:08.0 +0100
@@ -6,7 +6,6 @@
 Section: science
 Priority: optional
 Build-Depends: cython3 (>= 0.23.2),
-   cython3-dbg (>= 0.23.2),
debhelper-compat (= 12),
dh-python,
help2man,
@@ -14,27 +13,17 @@
python3-all-dbg,
python3-all-dev,
python3-fabio,
-   python3-fabio-dbg,
python3-h5py,
-   python3-h5py-dbg,
python3-mako,
python3-matplotlib,
-   python3-matplotlib-dbg,
python3-numpy,
-   python3-numpy-dbg,
python3-opengl,
python3-pil,
-   python3-pil-dbg,
python3-pyopencl,
-   python3-pyopencl-dbg,
-   python3-pyqt5-dbg,
python3-pyqt5.qtopengl,
-   python3-pyqt5.qtopengl-dbg,
python3-pyqt5.qtsvg,
-   python3-pyqt5.qtsvg-dbg,
python3-qtconsole,
python3-scipy,
-   python3-scipy-dbg,
python3-setuptools,
xauth,
xvfb

Bug#980291: Bug#980294: libjs-jquery-flot: breaking API change

[Antonio Terceiro]

On Mon, Jan 18, 2021 at 07:20:12PM +0100, Martin wrote:
> On 2021-01-18 14:28, Antonio Terceiro wrote:
> > In special, I need to stop including the standalone plugin files,
> > because it's already included in the main file. This wasn't the case in
> > the previous version, and I get that this is how upstream designed it to
> > be.
> 
> Pretty "hacky" idea: How about leaving the main file as intended
> by upstream, i.e. with all plugins included, and replace the the
> plugin files with dummies? Or am I misunderstanding the issue?

That's actually great idea.


signature.asc
Description: PGP signature

Bug#980415: src:edtsurf: fails to migrate to testing for too long: i386 not built anymore but still in unstable

[Paul Gevers]

Source: edtsurf
Version: 0.2009-8
Severity: serious
Control: close -1 0.2009-9
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

Please ask ftp-master to remove edtsurf arch:i386 from unstable.

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:edtsurf in
its current version in unstable has been trying to migrate for 60 days
[2]. Hence, I am filing this bug.

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#980414: RFA: ddccontrol -- program to control monitor parameters

[Miroslav Kravec]

Package: wnpp
Severity: normal

Hello there,

I've lost interest in maintaining the package in my free time, and the
package doesn't receive the attention it needs. I've been practically
ignoring it for a long time.

I'd like it if someone would take over the package. Feel free to
remove me from the maintainer list on the next upload.

Kind regards,
Miro

Bug#980412: O: giflib -- library for GIF images (utilities)

[Mattia Rizzolo]

Package: wnpp

The current maintainer of giflib has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: giflib
Binary: giflib-tools, libgif7, libgif-dev
Version: 5.1.9-1
Maintainer: David Suárez 
Build-Depends: debhelper-compat (= 12), xmlto
Architecture: any
Standards-Version: 4.4.1
Format: 3.0 (quilt)
Files:
 f3e12a7435645c2a2dec229902312403 1933 giflib_5.1.9-1.dsc
 c1df79d223b10b92f44ca649ef5f1459 336304 giflib_5.1.9.orig.tar.bz2
 1451e6d081dc7daf44e13cb1f9c7d896 8308 giflib_5.1.9-1.debian.tar.xz
Vcs-Browser: https://salsa.debian.org/deiv-guest/giflib
Vcs-Git: https://salsa.debian.org/deiv-guest/giflib.git
Checksums-Sha256:
 1d694ffc438056ab3415fa33ab390ef231b1e9943da393b745c9ec1909029e4e 1933 
giflib_5.1.9-1.dsc
 292b10b86a87cb05f9dcbe1b6c7b99f3187a106132dd14f1ba79c90f561c3295 336304 
giflib_5.1.9.orig.tar.bz2
 fa7d879571e40ecbea6934f0fa3100a7cba0f7313c2de8ff61d62294970ad86d 8308 
giflib_5.1.9-1.debian.tar.xz
Homepage: http://giflib.sourceforge.net/
Package-List: 
 giflib-tools deb utils optional arch=any
 libgif-dev deb libdevel optional arch=any
 libgif7 deb libs optional arch=any
Directory: pool/main/g/giflib
Priority: source
Section: libs

Package: giflib
Binary: giflib-tools, libgif7, libgif-dev
Version: 5.2.1-2
Maintainer: Debian QA Group 
Build-Depends: debhelper-compat (= 12), xmlto
Architecture: any
Standards-Version: 4.3.0
Format: 3.0 (quilt)
Files:
 ae0f68f24374f5430e2d26c8c7d1c067 1922 giflib_5.2.1-2.dsc
 6f03aee4ebe54ac2cc1ab3e4b0a049e5 444187 giflib_5.2.1.orig.tar.gz
 92c7939152ab0debe0699c2da9927f38 8344 giflib_5.2.1-2.debian.tar.xz
Vcs-Browser: https://salsa.debian.org/debian/giflib
Vcs-Git: https://salsa.debian.org/debian/giflib.git
Checksums-Sha256:
 b97951c9495d29a0cf9e26b7e497796f18caec5daa1a1ecd9d112a9e7b755b62 1922 
giflib_5.2.1-2.dsc
 31da5562f44c5f15d63340a09a4fd62b48c45620cd302f77a6d9acf0077879bd 444187 
giflib_5.2.1.orig.tar.gz
 6344b4e5ff9941a4f8d2e2da834d40336a81d64a69e25db08aaaf2a1498580de 8344 
giflib_5.2.1-2.debian.tar.xz
Homepage: http://giflib.sourceforge.net/
Package-List: 
 giflib-tools deb utils optional arch=any
 libgif-dev deb libdevel optional arch=any
 libgif7 deb libs optional arch=any
Directory: pool/main/g/giflib
Priority: source
Section: libs


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#980411: O: glbsp -- node builder library for OpenGL-based Doom-style games (headers)

[Mattia Rizzolo]

Package: wnpp

The current maintainer of glbsp, Jonathan Dowland ,
has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: glbsp
Binary: libglbsp-dev, libglbsp3, glbsp
Version: 2.24-5
Maintainer: Debian QA Group 
Build-Depends: dpkg-dev (>> 1.16.1~), debhelper (>= 4.0.0), zlib1g-dev | 
libz-dev
Architecture: any
Standards-Version: 3.9.3
Format: 1.0
Files:
 f1056fbb712d431fc443c685d509baaa 1894 glbsp_2.24-5.dsc
 3f33320cd9cb58075e5e9d76f92940a5 230977 glbsp_2.24.orig.tar.gz
 9019ed79987db73e1505483d8724d6aa 4266 glbsp_2.24-5.diff.gz
Vcs-Browser: https://salsa.debian.org/debian/glbsp
Vcs-Git: https://salsa.debian.org/debian/glbsp.git
Checksums-Sha256:
 41aa35e8e8cfab2ce5ffe8b07c7a3a7ee6de5c24caa4a74adf608892b2e56bed 1894 
glbsp_2.24-5.dsc
 e3b7c4bce21c2f9b77732a9b5920b6877e884b31dd1ed9273776538dba48a75c 230977 
glbsp_2.24.orig.tar.gz
 b38d4eb9470d2a6711422667e379805dab889f26d698f33665436c233a9745c5 4266 
glbsp_2.24-5.diff.gz
Package-List: 
 glbsp deb utils optional arch=any
 libglbsp-dev deb libdevel optional arch=any
 libglbsp3 deb libs optional arch=any
Directory: pool/main/g/glbsp
Priority: source
Section: utils


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#980410: O: oxygencursors -- Oxygen mouse cursor theme

[Mattia Rizzolo]

Package: wnpp

The current maintainer of oxygencursors has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: oxygencursors
Binary: oxygencursors
Version: 0.0.2012-06-kde4.8-4
Maintainer: Debian QA Group 
Build-Depends: debhelper-compat (= 13), inkscape (>= 1.0), x11-apps, cmake
Architecture: all
Standards-Version: 4.5.1
Format: 3.0 (quilt)
Files:
 774e7791d8f60039ab4350f2135f7e1d 1900 oxygencursors_0.0.2012-06-kde4.8-4.dsc
 7dc0f45aacd225e93d70857c17cf4d66 103088 
oxygencursors_0.0.2012-06-kde4.8.orig.tar.gz
 e5d02c790fcc2afa4e4571f2c2e4d759 14536 
oxygencursors_0.0.2012-06-kde4.8-4.debian.tar.xz
Checksums-Sha256:
 ef11a3a2d772f9994abbb7a45562e25bd7da531e96b6a4c8a20ec505b0d62b34 1900 
oxygencursors_0.0.2012-06-kde4.8-4.dsc
 4d8f115cc3bf0a6d13b5129706299708a511dcd2bb4545eb637e4fb116c9cb1a 103088 
oxygencursors_0.0.2012-06-kde4.8.orig.tar.gz
 c3bace13511fcabc7d10e27f484dc9432df3b69b1210707ad335ef97b779624c 14536 
oxygencursors_0.0.2012-06-kde4.8-4.debian.tar.xz
Homepage: https://techbase.kde.org/Projects/Oxygen
Package-List: 
 oxygencursors deb x11 optional arch=all
Directory: pool/main/o/oxygencursors
Priority: source
Section: x11

Package: oxygencursors
Version: 0.0.2012-06-kde4.8-4
Installed-Size: 97224
Maintainer: Debian QA Group 
Architecture: all
Enhances: plasma-theme-oxygen
Description: Oxygen mouse cursor theme
Description-md5: 4c5002a4e592e5cc90c51c07857a8cde
Homepage: https://techbase.kde.org/Projects/Oxygen
Section: x11
Priority: optional
Filename: pool/main/o/oxygencursors/oxygencursors_0.0.2012-06-kde4.8-4_all.deb
Size: 7109316
MD5sum: 223e2a54429366d44d88f11bd4c877e6
SHA256: f53bb4d71f402b6be32eaa1018b84cfa2c05648cd0df8294c04eb2da62286c66


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#980409: O: mercurial-crecord -- Mercurial crecord extension (transitional package)

[Mattia Rizzolo]

Package: wnpp

The current maintainer of mercurial-crecord, Andrej Shadura 
,
has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: mercurial-crecord
Binary: mercurial-crecord
Version: 0.20151121-2
Maintainer: Debian QA Group 
Build-Depends: debhelper-compat (= 12)
Architecture: all
Standards-Version: 4.4.0
Format: 3.0 (quilt)
Files:
 96586ee7871654c598765e6188f0eb2c 1577 mercurial-crecord_0.20151121-2.dsc
 e7a28c9e61b2321280eebde80a34e9c2 18027 
mercurial-crecord_0.20151121.orig.tar.bz2
 e8161f821774865998696720492d9ee4 2412 
mercurial-crecord_0.20151121-2.debian.tar.xz
Checksums-Sha256:
 eae7ded7d077dab7d60f46f95d6caa693217786cc4b8ced28ad6d308469994dc 1577 
mercurial-crecord_0.20151121-2.dsc
 33fe039c6659428e5430b6a75edba89b1965772ffcbba811af791eb9e55d1d7e 18027 
mercurial-crecord_0.20151121.orig.tar.bz2
 e63150b962ba465f01a81cc9ffeeb160276a8301c5b390cfb767810df4305d7a 2412 
mercurial-crecord_0.20151121-2.debian.tar.xz
Dgit: db659293a24079bc50385f0c722d692875f6f468 debian 
archive/debian/0.20151121-2 https://git.dgit.debian.org/mercurial-crecord
Package-List: 
 mercurial-crecord deb oldlibs optional arch=all
Directory: pool/main/m/mercurial-crecord
Priority: optional
Section: misc

Package: mercurial-crecord
Version: 0.20151121-2
Installed-Size: 11
Maintainer: Debian QA Group 
Architecture: all
Depends: mercurial (>= 3.8.1)
Description: Mercurial crecord extension (transitional package)
Description-md5: f0f047000fb3a8cc0eca02e086dc6199
Section: python
Priority: optional
Filename: pool/main/m/mercurial-crecord/mercurial-crecord_0.20151121-2_all.deb
Size: 3564
MD5sum: f18c74316eb8a196a6fadac0d4cd28b8
SHA256: 5365f9ff0e4c8e9528ea7df0aaa4a57e14a33261313ba97279796151c6df1790


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#980407: O: transaction -- Transaction management for Python

[Mattia Rizzolo]

Package: wnpp

The current maintainer of transaction has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: transaction
Binary: python3-transaction
Version: 3.0.0-1
Maintainer: Debian QA Group 
Build-Depends: debhelper-compat (= 12), dh-python, python3-all, 
python3-setuptools, python3-zope.interface, python3-mock
Architecture: all
Standards-Version: 4.4.1
Format: 3.0 (quilt)
Files:
 bc568dc1eddb994cb00893d8ed8e2e5b 1850 transaction_3.0.0-1.dsc
 9a13947c4527aa58a90a46a2a1f3a6a7 72319 transaction_3.0.0.orig.tar.gz
 72ae9f2795417cc1861f362f24f47eb8 3228 transaction_3.0.0-1.debian.tar.xz
Checksums-Sha256:
 d698ec5fc8b5c7b55f7ecfefe5eee80489da415c0c2a464682c148c5c159e20c 1850 
transaction_3.0.0-1.dsc
 3b0ad400cb7fa25f95d1516756c4c4557bb78890510f69393ad0bd15869eaa2d 72319 
transaction_3.0.0.orig.tar.gz
 2dde78da1cb065c8d58105757f2cdd7326727c59a9ca170582699c90d0e76151 3228 
transaction_3.0.0-1.debian.tar.xz
Homepage: https://pypi.python.org/pypi/transaction
Package-List: 
 python3-transaction deb python optional arch=all
Directory: pool/main/t/transaction
Priority: source
Section: python

Package: python3-transaction
Source: transaction
Version: 3.0.0-1
Installed-Size: 226
Maintainer: Debian QA Group 
Architecture: all
Depends: python3-zope.interface, python3:any
Description: Transaction management for Python
Description-md5: b36ac5f482f791c47a0eddd117346a07
Homepage: https://pypi.python.org/pypi/transaction
Section: python
Priority: optional
Filename: pool/main/t/transaction/python3-transaction_3.0.0-1_all.deb
Size: 40868
MD5sum: bb3baa9c23b78c7bc2433fa2537129af
SHA256: 27d64ac297efee9f13a0e94779d9719f23f85d48f618fdefb16c139fdc29e54e


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#980413: O: dh-linktree -- Create symlink trees within a Debian package

[Mattia Rizzolo]

Package: wnpp

The current maintainer of dh-linktree, Raphaël Hertzog ,
has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: dh-linktree
Binary: dh-linktree
Version: 0.8
Maintainer: Debian QA Group 
Build-Depends: debhelper-compat (= 12)
Architecture: all
Standards-Version: 4.5.0
Format: 3.0 (native)
Files:
 381b12085290e6d6fe84c767af4c0cfe 1218 dh-linktree_0.8.dsc
 608c20da0d61ada51ddf1da47a703dcb 6108 dh-linktree_0.8.tar.xz
Vcs-Browser: https://salsa.debian.org/debian/dh-linktree
Vcs-Git: https://salsa.debian.org/debian/dh-linktree.git
Checksums-Sha256:
 4dfb8e8aea4166ec83ccb26a8605783d1146f6607cab0be2204b969b4972b9b5 1218 
dh-linktree_0.8.dsc
 a8827d6ecbfca3d2b9e384fcecb563fbcf654f615f7e05c9ab37bcc8521608ee 6108 
dh-linktree_0.8.tar.xz
Package-List: 
 dh-linktree deb devel optional arch=all
Directory: pool/main/d/dh-linktree
Priority: source
Section: devel

Package: dh-linktree
Version: 0.8
Installed-Size: 33
Maintainer: Debian QA Group 
Architecture: all
Depends: debhelper, libdpkg-perl, perl:any
Description: Create symlink trees within a Debian package
Description-md5: 7ef44f371b55fb620fe2ec953830eab4
Multi-Arch: foreign
Section: devel
Priority: optional
Filename: pool/main/d/dh-linktree/dh-linktree_0.8_all.deb
Size: 10984
MD5sum: a51b58eb89f5bc81bf876238289fbf74
SHA256: 89e33db26edcbc4dbcb114e2fec7f1836f8e65f92874b84a56c54706ee575626


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#980408: O: python-chameleon -- XML-based template compiler

[Mattia Rizzolo]

Package: wnpp

The current maintainer of python-chameleon has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: python-chameleon
Binary: python3-chameleon
Version: 3.8.1-1
Maintainer: Debian QA Group 
Build-Depends: debhelper-compat (= 13), dh-python, python3-all, 
python3-setuptools
Architecture: all
Standards-Version: 4.5.1
Format: 3.0 (quilt)
Files:
 27580adc2a74d2c48da33287233e5a2f 1864 python-chameleon_3.8.1-1.dsc
 5235c1d488325e2c015da85200529dee 137012 python-chameleon_3.8.1.orig.tar.gz
 cd791467f0130a357ee80ae769d5b44e 5900 python-chameleon_3.8.1-1.debian.tar.xz
Checksums-Sha256:
 d909eb110d869205fc7c6c1e39f4f054341353e3b11f7ac692b197817903ba6e 1864 
python-chameleon_3.8.1-1.dsc
 e7599f9edb1de7af601dcca14aa61c2d02ba383642712725d7dcdf0e3f7def1f 137012 
python-chameleon_3.8.1.orig.tar.gz
 0c2da0138b6a2c798f692bf3799cdf731921e7ab0ec29d8c2d284e553cd50884 5900 
python-chameleon_3.8.1-1.debian.tar.xz
Homepage: https://github.com/malthe/chameleon
Package-List: 
 python3-chameleon deb python optional arch=all
Testsuite: autopkgtest
Directory: pool/main/p/python-chameleon
Priority: source
Section: python

Package: python3-chameleon
Source: python-chameleon
Version: 3.8.1-1
Installed-Size: 403
Maintainer: Debian QA Group 
Architecture: all
Depends: python3-pkg-resources, python3:any
Description: XML-based template compiler
Description-md5: cbb9bf2233b8ad702cf1b218f5622119
Homepage: https://github.com/malthe/chameleon
Section: python
Priority: optional
Filename: pool/main/p/python-chameleon/python3-chameleon_3.8.1-1_all.deb
Size: 92564
MD5sum: 0f338354a0e41192afe30d02ebe3c1e4
SHA256: f23e116cbe1b050c7a7c4544ee922a7e7edbed32d883917aea858f63d29c3388


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#980406: node-xterm: likely broken build - JSON.parse: unexpected character at line 1 column 1 of the JSON data Resource

[Pirate Praveen]

Package: node-xterm
Version: 3.8.1-4
Severity: important

When using packaged version of node-xterm in gitlab, the browser error 
console has these errors and it break web IDE of gitlab (the progress 
circle keeps spinning).


Source map error: Error: JSON.parse: unexpected character at line 1 
column 1 of the JSON data Resource URL: 
http://gitlab-buster.lxc/assets/webpack/commons-pages.ide-pages.projects.environments.terminal-pages.projects.jobs.terminal.650166e5.chunk.js 
Source Map URL: 
commons-pages.ide-pages.projects.environments.terminal-pages.projects.jobs.terminal.650166e5.chunk.js.map


Source map error: Error: JSON.parse: unexpected character at line 1 
column 1 of the JSON data Resource URL: 
http://gitlab-buster.lxc/assets/webpack/pages.ide.da3ccd82.chunk.js 
Source Map URL: pages.ide.da3ccd82.chunk.js.map


Source map error: Error: JSON.parse: unexpected character at line 1 
column 1 of the JSON data Resource URL: 
http://gitlab-buster.lxc/assets/webpack/runtime.6c5d081d.bundle.js 
Source Map URL: runtime.6c5d081d.bundle.js.map


When switching to npmjs.com distributed xterm, the error is gone.

gitlab need xterm 3.14.5, so it is likely a version mismatch as well.

I will check with xterm 3.8.1 from npmjs.com to confirm if it is a 
version mismatch or not. If it is a version mismatch I'll retitle this 
as a request for new upstream version.

Bug#980405: O: zc.buildout -- system for managing development buildouts

[Mattia Rizzolo]

Package: wnpp

The current maintainer of zc.buildout, has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: zc.buildout
Binary: python3-zc.buildout
Version: 2.13.2-4
Maintainer: Debian QA Group 
Build-Depends: debhelper (>= 9), dh-python, python3-all, python3-setuptools
Architecture: all
Standards-Version: 4.4.0
Format: 3.0 (quilt)
Files:
 3e90bfcb3cc3afa86275a290ec355304 1876 zc.buildout_2.13.2-4.dsc
 2f151a3016cb279443a11e7a0a7a 166252 zc.buildout_2.13.2.orig.tar.gz
 aeb3795b8101228868b6a1c762707bad 4168 zc.buildout_2.13.2-4.debian.tar.xz
Checksums-Sha256:
 3736b58ce6021b6449bde743700e9dd86074110e67b5640043b6ea4aad833f1b 1876 
zc.buildout_2.13.2-4.dsc
 5dd4de86dda684c46ef8ee9cc84e335ca7f6275d4363a684de82225270d1e328 166252 
zc.buildout_2.13.2.orig.tar.gz
 a170844cc67f3232d4e269247cc879a2e704278a0c7a45fc0c9c37cc6522e917 4168 
zc.buildout_2.13.2-4.debian.tar.xz
Homepage: http://pypi.python.org/pypi/zc.buildout
Package-List: 
 python3-zc.buildout deb zope optional arch=all
Testsuite: autopkgtest
Testsuite-Triggers: python3-zope.testing
Directory: pool/main/z/zc.buildout
Priority: source
Section: zope

Package: python3-zc.buildout
Source: zc.buildout
Version: 2.13.2-4
Installed-Size: 703
Maintainer: Debian QA Group 
Architecture: all
Replaces: python-zc.buildout
Depends: python3-pkg-resources, python3:any
Breaks: python-zc.buildout
Description: system for managing development buildouts
Description-md5: 995cd1b0e94acff6532eba505c4eb6ad
Homepage: http://pypi.python.org/pypi/zc.buildout
Section: zope
Priority: optional
Filename: pool/main/z/zc.buildout/python3-zc.buildout_2.13.2-4_all.deb
Size: 175448
MD5sum: 9456c842b278e95bf4fc81160306e479
SHA256: 90e676cd00cb429d41a57b93383ef3db555cefc6e842608e386ef37813a933e9


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#979543: chromium: watch file

[Bastian Germann]

Control: retitle -1 chromium: make get-orig-source use uscan

On Thu, 7 Jan 2021 23:50:19 +0100 Bastian Germann 
 wrote:
Enclosed is a patch including a watch file. It should be used only in 
modes skipping mk-origtargz. The file exclusion via tar --delete in 
mk-origtargz's current implementation is too inefficient for chromium. 
For downloading incl. repacking, use the existing make target which the 
patch modifies to use uscan.


I just saw 
https://salsa.debian.org/chromium-team/chromium/-/commit/5024391dc8f8706046e947bcf1fd88f3af85291f 
introduced a similar watch file but did not change debian/rules' 
get-orig-source target to obtain the orig tarball via uscan instead of 
wget. I think it would be an improvement as you then have only one url 
that is downloaded from.

Bug#979468: RFS: gdu/4.1.0-1 [ITP] -- Pretty fast disk usage analyzer written in Go

[Daniel Milde]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "gdu":

 * Package name    : gdu
   Version : 4.1.0-1
   Upstream Author : Daniel Milde 
 * URL : https://github.com/dundee/gdu
 * License : MIT
 * Vcs : https://github.com/dundee/gdu
   Section : admin

It builds those binary packages:

  gdu - Pretty fast disk usage analyzer written in Go

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/gdu/

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

  dget -x https://mentors.debian.net/debian/pool/main/g/gdu/gdu_4.1.0-1.dsc

Changes for the initial release:

 gdu (4.1.0-1) unstable; urgency=medium
 .
   * improved debian packaging
   * added man page

Regards,
--
  Daniel Milde

Bug#980404: RFA: ddccontrol -- program to control monitor parameters

[Miroslav Kravec]

Package: wnpp
Severity: normal

Hello there,

I've lost interest in maintaining the package in my free time, and the
package doesn't receive the attention it needs. I've been practically
ignoring it for a long time.

I'd like it if someone would take over the package. Feel free to
remove me from the maintainer list on the next upload.

Kind regards,
Miro

Bug#980400: RFA: picocli -- Tiny command line interpreter library for Java applications

[tony mancill]

On Mon, Jan 18, 2021 at 08:13:42PM +0100, Miroslav Kravec wrote:
> Package: wnpp
> Severity: normal
> X-Debbugs-CC: pkg-java-maintain...@lists.alioth.debian.org
> 
> Hello there,
> 
> I've lost interest in maintaining the package in my free time, and the
> package won't be receiving attention from me.
> 
> I'd like it if someone would take over the package. Feel free to
> remove me from the uploaders list on the next upload.
> 
> Kind regards,
> Miro

Hi Miro,

The package is team-maintained.  I will take care of removing your name
from Uploaders with the next upload.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#980403: libpam-pkcs11: pam_pkcs11.so is in wrong directory

[Bart-Jan Vrielink]

Package: libpam-pkcs11
Version: 0.6.11-3
Severity: important

Dear Maintainer,

PAM looks for modules in /lib/x86_64-linux-gnu/security, but this package
installs pam_pkcs11.so in /lib/security.

Creating a symlink to /lib/x86_64-linux-gnu/security/pam_pkcs11.so makes this
module work.

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages libpam-pkcs11 depends on:
ii  libc6  2.31-9
ii  libcurl4   7.74.0-1
ii  libldap-2.4-2  2.4.56+dfsg-1
ii  libpam0g   1.4.0-2
ii  libpcsclite1   1.9.0-1
ii  libssl1.1  1.1.1i-1

libpam-pkcs11 recommends no packages.

libpam-pkcs11 suggests no packages.

-- no debconf information

Bug#969298: Kerberos authentication broken

[Sudip Mukherjee]

Hi Eric,

On Mon, Aug 31, 2020 at 01:08:54PM -0400, Eric Dorland wrote:
> * Ilias Tsitsimpis (ilias...@debian.org) wrote:
> > Hi Eric,
> > 
> > On Sun, Aug 30, 2020 at 06:32PM, Eric Dorland wrote:
> > > Kerberos authentication appears to be broken.
> > > [...]
> > > Versions of packages offlineimap depends on:
> > > ii  python-imaplib2  2.57-5.1
> > > ii  python-six   1.15.0-1
> > > ii  python2  2.7.18-2
> > > 
> > > Versions of packages offlineimap recommends:
> > > ii  python-socks  1.6.8+dfsg-1.1
> > > 
> > > Versions of packages offlineimap suggests:
> > > pn  python-gssapi  
> > 
> > OfflineIMAP requires `python-gssapi` for Kerberos authentication, which
> > is missing from your system. Could you please install `python-gssapi`
> > and retry?
> 
> Ahh, it looks like python-gssapi has been removed from unstable :(

offlineimap3 is a python3 port of offlineimap and is now available in
unstable and python3-gssapi is also available. It will be great if you
can test offlineimap3 in your setup. Can you give it a try please..


--
Regards
Sudip

Bug#980402: RM: compactheader -- RoQA; abandoned upstream, no longer usable

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: rm

compactheader is no longer usable with current thunderbird.
It has already been removed from unstable:
https://bugs.debian.org/972413


Andreas

Bug#980302: dictionaries-common-dev: vim dictionary support

[Kurt Roeckx]

On Mon, Jan 18, 2021 at 07:34:55PM +0100, Agustin Martin wrote:
> > Note that I need to patch the .aff files to actually make it work
> > properly because vim doesn't implement all the same things
> > hunspell does.
> 
> Knowing that vim does not use standard hunspell files makes things
> more clear. I thought you meant something like what is done for aspell
> or ispell dicts, allowing hashes to be built at postinst stage.
> However, seems that what you would like is to recover something like
> vim-spellfiles, but adapted to current vim.

Vim has it's own file format and implementation that works totally
different than hunspell, and so needs to convert it to it's own
format.

I have no idea what vim-spellfiles was, it only seems to have been
in experimental.

Vim has various files on it's ftp site at:
https://ftp.nluug.nl/vim/runtime/spell/

I assume someone packaged up all the files from the ftp site.

As you can see at
https://github.com/vim/vim/tree/master/runtime/spell
most haven't been updated in the past 10 years, nor is the source
of them actually available, just a patch against something, and
it's unclear to me to which version the patch is. I haven't tried
to run the aap script to see if it can actually still fetch
the source.

If you have the input files, it's easy to generate the files from
it.

> > I was looking at the libhunspell patch upstream, which seems to be
> > going nowhere, the pull requests was closed because it wasn't
> > complete and nobody seems to want to fix it.
> >
> > > On the other hand most hunspell dicts come from libreoffice-dicts and
> > > do not provide a dict-common info file. In my TODO list there is a
> > > point to play with libreoffice-dicts build process to automatically
> > > create a minimal info file, but it has been there for years due to
> > > lack of both time and python skills at that time.
> >
> > I have no idea what those files are used for, so I can't even test
> > that they are correct or not. I assume that it might have something
> > to do with emacs, but I'm a vim user, not an emacs user.
> 
> Note that I was thinking about autobuild, and for ispell and aspell
> some info may be there for hash autobuild, together with for other
> things like Emacs or jed.
> 
> I do not object adding a vim section to policy if there is need to
> coordinate with packages outside the vim environment. However, from
> what I seem to understand, everything is inside vim ecosystem.
> spellchecker is part of vim, hunspell dicts need to be adapted for vim
> and this spellchecking facility seems not to be used outside vim.
> 
> So we would need to have a better understanding of what is expected.
> Will vim files be built from a central package (like libreoffice-dicts
> does for most hunspell dicts) or there will be separate source
> packages for each dict, probably with different maintainers? If the
> second, a vim spellckeck policy and helper scripts are useful. Note,
> however, that I do not use vim, so some help will be needed, where is
> this feature documented?

There is documentation about it in:
/usr/share/vim/vim82/doc/spell.txt
Or online at: https://vimhelp.org/spell.txt.html

I think we should at least ship the files in Debian somehow, the
user shouldn't need to download it.


Kurt

Bug#980256: git-buildpackage: autopkgtest armhf regression: /usr/bin/python: not found

[Paul Gevers]

Hi Guido,

On 18-01-2021 12:54, Guido Günther wrote:
> Is there a way I can debug
> this without an upload to the archive?

You can use porteboxes I guess.
https://salsa.debian.org/mbanck/dd-autopkgtest/-/blob/master/dd-autopkgtest
has tooling to do that.

> Otherwise the only thing we could do is skip the test there. What's the
> recommendd way, s.th. like
> 
>if dpkg-architecture --is armhf
>exit 77
>fi
> 
> and restriction `skippable`?

There's a new field in the spec: Architecture. So you can do
"Architecture: !armhf" (if I have the syntax right).

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#957281: gnomad2: ftbfs with GCC-10

[Logan Rosen]

Package: gnomad2
Version: 2.9.6-5
Followup-For: Bug #957281
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/gcc-10.patch: Fix FTBFS with GCC 10 due to multiple definitions.

Thanks for considering the patch.

Logan
diff -Nru gnomad2-2.9.6/debian/patches/gcc-10.patch 
gnomad2-2.9.6/debian/patches/gcc-10.patch
--- gnomad2-2.9.6/debian/patches/gcc-10.patch   1969-12-31 19:00:00.0 
-0500
+++ gnomad2-2.9.6/debian/patches/gcc-10.patch   2021-01-18 14:01:39.0 
-0500
@@ -0,0 +1,56 @@
+--- a/src/common.h
 b/src/common.h
+@@ -130,25 +130,25 @@
+ } playlist_widgets_t;
+ 
+ /* Globally known widgets */
+-transfer_widgets_t transfer_widgets;
+-data_widgets_t data_widgets;
+-playlist_widgets_t playlist_widgets;
++extern transfer_widgets_t transfer_widgets;
++extern data_widgets_t data_widgets;
++extern playlist_widgets_t playlist_widgets;
+ 
+ /* Global progress bar - not so good but... */
+-GtkWidget *progress_bar;
++extern GtkWidget *progress_bar;
+ 
+ /* Global playlist selection for the popup, not good either ... */
+-GList *jukebox_playlist;
+-GList *selected_target_playlists;
++extern GList *jukebox_playlist;
++extern GList *selected_target_playlists;
+ 
+ /* Global lock variable for the jukebox */
+-gboolean volatile jukebox_locked;
++extern gboolean volatile jukebox_locked;
+ 
+ /* Global cancellation variable for jukebox operations */
+-gboolean volatile cancel_jukebox_operation;
++extern gboolean volatile cancel_jukebox_operation;
+ 
+ /* Global debug level variable (standard = 7) */
+-gint gnomad_debug;
++extern gint gnomad_debug;
+ 
+ /* A proc for hiding dialog windows */
+ GCallback dispose_of_dialog_window(GtkButton * button, gpointer data);
+--- a/src/gnomad2.c
 b/src/gnomad2.c
+@@ -34,7 +34,15 @@
+ guint uevent_device_hooked = 0;
+ #endif
+ 
+-/* This one should be global really */
++transfer_widgets_t transfer_widgets;
++data_widgets_t data_widgets;
++playlist_widgets_t playlist_widgets;
++GtkWidget *progress_bar;
++GList *jukebox_playlist;
++GList *selected_target_playlists;
++gboolean volatile jukebox_locked;
++gboolean volatile cancel_jukebox_operation;
++gint gnomad_debug;
+ GtkWidget *main_window;
+ 
+ /* Local variables */
diff -Nru gnomad2-2.9.6/debian/patches/series 
gnomad2-2.9.6/debian/patches/series
--- gnomad2-2.9.6/debian/patches/series 2016-06-02 03:22:31.0 -0400
+++ gnomad2-2.9.6/debian/patches/series 2021-01-18 13:57:38.0 -0500
@@ -1,3 +1,4 @@
 0001-werror_format_security.patch
 1001-gtk_set_can_default.patch
 1002-gtk2_to_gtk3.patch
+gcc-10.patch

Bug#980401: prosody: Do not use invoke-rc.d in logrotate script

[Guillem Jover]

Package: prosody
Version: 0.11.7-2
Severity: important
Tags: patch

Hi!

The invoke-rc.d interface is intended to be used only from maintainer
scripts, anything else meant to be executed during the normal operation
of the system needs one of the other interfaces to services, such as
service(8), as the boot process will definitely not honor any
invoke-rc.d policy anyway.

Attached a patch fixing this.

Thanks,
Guillem
From 626b7965b70c94cb487a6f6d640f2f8f2c7b1d46 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Mon, 18 Jan 2021 20:02:23 +0100
Subject: [PATCH] Do not use invoke-rc.d in logrotate script

The invoke-rc.d interface is intended to be used only from maintainer
script, anything else meant to be executed during the normal operation
of the system needs one of the other interfaces to services, such as
service(8), as the boot process will definitely not honor any
invoke-rc.d policy anyway.
---
 debian/prosody.logrotate | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/prosody.logrotate b/debian/prosody.logrotate
index 6a71283..5407a18 100644
--- a/debian/prosody.logrotate
+++ b/debian/prosody.logrotate
@@ -5,7 +5,7 @@
 	delaycompress
 	create 640 prosody adm
 	postrotate
-		[ ! -e /run/prosody/prosody.pid ] || /usr/sbin/invoke-rc.d prosody reload > /dev/null
+		[ ! -e /run/prosody/prosody.pid ] || service prosody reload > /dev/null
 	endscript
 	sharedscripts
 	missingok
-- 
2.30.0

Bug#980400: RFA: picocli -- Tiny command line interpreter library for Java applications

[Miroslav Kravec]

Package: wnpp
Severity: normal
X-Debbugs-CC: pkg-java-maintain...@lists.alioth.debian.org

Hello there,

I've lost interest in maintaining the package in my free time, and the
package won't be receiving attention from me.

I'd like it if someone would take over the package. Feel free to
remove me from the uploaders list on the next upload.

Kind regards,
Miro

Bug#980399: RFA: ddccontrol-db -- monitor database for ddccontrol

[Miroslav Kravec]

Package: wnpp
Severity: normal

Hello there,

I've lost interest in maintaining the package in my free time, and the
package doesn't receive my attention anymore. I've been practically
ignoring it for a long time.

I'd like it if someone would take over the package. Feel free to
remove me from the maintainer list on the next upload.

Kind regards,
Miro

Bug#980383: mailman3-web: please make ExecStart in the service file call a script for SE Linux labelling

[Russell Coker]

Package: mailman3-web
Version: 0+20180916-10
Severity: normal

To run a daemon in a unique domain in SE Linux you need a daemon-specific
label on the program that is run.  If the ExecStart line directly runs a
program that's not daemon specific (EG uwsgi, perl, bash, etc) then this
doesn't happen.  The systemctl edit command doesn't allow overwriting the
ExecStart entry, so the only thing to do with the package in it's current
form on SE Linux is to change the /lib/systemd/system/mailman3-web.service
file.

If instead you had ExecStart=/usr/sbin/mailman3-web-start or something
similar then I could have the Debian SE Linux policy assign a specific
label to that file and it would get the right context without any
changes being needed.

NB no change is needed for the mailman3 package because /usr/bin/mailman
is a symlink to /usr/lib/mailman3/bin/mailman which is a program that is
specific to mailman.

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages mailman3-web depends on:
ii  dbconfig-sqlite3   2.0.17
ii  debconf [debconf-2.0]  1.5.71
ii  init-system-helpers1.56+nmu1
ii  lsb-base   11.1.0
ii  python33.9.1-1
ii  python3-django-hyperkitty  1.3.3-1
ii  python3-django-postorius   1.3.3-1
ii  python3-mysqldb1.4.4-2+b3
ii  python3-whoosh 2.7.4+git6-g9134ad92-5
ii  ucf3.0038+nmu1
ii  uwsgi  2.0.19.1-5
ii  uwsgi-plugin-python3   2.0.19.1-5

Versions of packages mailman3-web recommends:
pn  libapache2-mod-proxy-uwsgi | nginx  

Versions of packages mailman3-web suggests:
ii  mariadb-server-10.5 [virtual-mysql-server]  1:10.5.8-3

-- debconf information excluded

Bug#841855: RFP: libghc-tidal -- Domain Specific Language for musical pattern embedded

[tony mancill]

On Sun, Oct 23, 2016 at 10:05:24PM +0100, Alex McLean wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: libghc-tidal
>   Version : 0.8.2
>   Upstream Author : Alex McLean 
> * URL : http://tidalcycles.org/
> * License : GPL3
>   Programming Lang: Haskell
>   Description : Domain Specific Language for musical pattern
> embedded in Haskell
> 
> This is the Haskell library for TidalCycles (aka Tidal), a
> Domain Specific Language for musical pattern.

Looks like this was uploaded in 2017 [1] without referencing the RFP
bug.  The package is being actively maintained by the Debian Haskell
Team [2], so I will close this.

Cheers,
tony

[1] 
https://tracker.debian.org/news/856977/accepted-haskell-tidal-082-1-source-amd64-all-into-unstable-unstable/
[2] https://tracker.debian.org/pkg/haskell-tidal

Bug#980397: support standard rsync urls

[Joey Hess]

Package: git-remote-gcrypt
Version: 1.3-1
Severity: normal

   rsync URIs
  Note that the URI format for the rsync backend  is,  regretably,
  non-standard.git-remote-gcrypt  uses  rsync://user@host:path
  whereas   plain   rsync   useseitheruser@host:pathor
  rsync://user@host/path.

That needs to be supported for backwards compatability, I suppose,
but is there any reason not to let gcrypt::rsync://user@host/path be used too?

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-remote-gcrypt depends on:
ii  git  1:2.30.0-1
ii  gpg  2.2.20-1

Versions of packages git-remote-gcrypt recommends:
ii  curl   7.74.0-1
ii  gnupg  2.2.20-1
ii  rsync  3.2.3-3

Versions of packages git-remote-gcrypt suggests:
pn  rclone  

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#980373: autopkgtest: please consider an upload to buster-backports

[Paul Gevers]

Control: tags -1 pending

Hi Luca,

On 18-01-2021 13:05, Luca Boccassi wrote:
> Newer versions of qemu are available via buster-backports, so
> autopkgtest in buster is affected by:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968598
> 
> Please consider uploading autopkgtest 5.15 to buster-backports.
> 
> If you lack the time, I'd be happy to help and take care of it with an
> NMU.

Uploaded.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980302: dictionaries-common-dev: vim dictionary support

[Agustin Martin]

El lun, 18 ene 2021 a las 13:54, Kurt Roeckx () escribió:
>
> On Mon, Jan 18, 2021 at 01:22:48PM +0100, Agustin Martin wrote:
> > El dom, 17 ene 2021 a las 16:06, Kurt Roeckx () escribió:
> > >
> > > Package: dictionaries-common-dev
> > >
> > > Hi,
> > >
> > > Vim has support for spellchecking using it's own spell check
> > > files. It can be generated based on hunspell .aff/.dic files, or
> > > based on a wordlist. Files currently need to be placed in
> > > /usr/share/vim/vim82/spell/
> > >
> > > It would be good if we had a policy and helper scripts to install
> > > the files so vim can use them, and how to name the packages.
> >
> > Hi, Kurt,
> >
> > This was mentioned a while ago in #490987. It was closed because at
> > that time building vim spell files creation seemed to be very memory
> > intensive and using libhunspell via a redhat patch was under
> > consideration. I have no idea about current status of spellchecking in
> > vim and if those concerns were addressed.
>
> Converting it from .aff and .dic to .spl and .sug takes 2.3
> seconds here and 99 MB of RAM.

Thanks for the info, Kurt.

Some (many) years ago, there used to be a vim-spellfiles package
containing dictionaries for use with vim. It was removed because of
maintainer request (#471285). Reason given by maintainer was "Vim
provides its own method for downloading spellfiles that are needed and
I don't actually have a computer that can build the spellfiles
packages (doing so is quite memory intensive)". Happy to know that
things (or computers) were improved.

> Note that I need to patch the .aff files to actually make it work
> properly because vim doesn't implement all the same things
> hunspell does.

Knowing that vim does not use standard hunspell files makes things
more clear. I thought you meant something like what is done for aspell
or ispell dicts, allowing hashes to be built at postinst stage.
However, seems that what you would like is to recover something like
vim-spellfiles, but adapted to current vim.

> I was looking at the libhunspell patch upstream, which seems to be
> going nowhere, the pull requests was closed because it wasn't
> complete and nobody seems to want to fix it.
>
> > On the other hand most hunspell dicts come from libreoffice-dicts and
> > do not provide a dict-common info file. In my TODO list there is a
> > point to play with libreoffice-dicts build process to automatically
> > create a minimal info file, but it has been there for years due to
> > lack of both time and python skills at that time.
>
> I have no idea what those files are used for, so I can't even test
> that they are correct or not. I assume that it might have something
> to do with emacs, but I'm a vim user, not an emacs user.

Note that I was thinking about autobuild, and for ispell and aspell
some info may be there for hash autobuild, together with for other
things like Emacs or jed.

I do not object adding a vim section to policy if there is need to
coordinate with packages outside the vim environment. However, from
what I seem to understand, everything is inside vim ecosystem.
spellchecker is part of vim, hunspell dicts need to be adapted for vim
and this spellchecking facility seems not to be used outside vim.

So we would need to have a better understanding of what is expected.
Will vim files be built from a central package (like libreoffice-dicts
does for most hunspell dicts) or there will be separate source
packages for each dict, probably with different maintainers? If the
second, a vim spellckeck policy and helper scripts are useful. Note,
however, that I do not use vim, so some help will be needed, where is
this feature documented?

Regards,

-- 
Agustin

Bug#980396: inkscape: most icons missing until gnome-icon-theme installed

[Jason Woofenden]

Package: inkscape
Version: 1.0.2-1
Severity: important

Dear Maintainer,

I installed inkscape on a pretty fresh debian unstable install
(from a couple months ago).

inkscape would launch, but very few of the icons in the ui displayed.
E.g. most tools had the same icon-missing icon. Screenshot attached.

inscape was printing this in the launching terminal:

(org.inkscape.Inkscape:39404): Gtk-WARNING **: 12:40:22.445: Could
not load a pixbuf from
/org/gtk/libgtk/theme/Adwaita/assets/check-symbolic.svg.
This may indicate that pixbuf loaders or the mime database could
not be found.

I tried installing recommended packages and whatnot, especially
anything to do with pixbuf, I installed all the pixbuf related
packages that my other computer has installed (where inkscape works
correctly.)

I tried several different inkscape settings for theme and icon
themes.

The thing that made the icons appear was installing
gnome-icon-theme.

I then purged gnome-icon-theme, and to my surprise, the icons in
inkscape kept working.

Here's the aptitude log:

Performing actions...
Selecting previously unselected package tango-icon-theme.
(Reading database ... 115973 files and directories currently installed.)
Preparing to unpack .../tango-icon-theme_0.8.90-8_all.deb ...
Unpacking tango-icon-theme (0.8.90-8) ...
Setting up tango-icon-theme (0.8.90-8) ...
Press Return to continue, 'q' followed by Return to quit.

Performing actions...
Selecting previously unselected package librsvg2-common:amd64.
(Reading database ... 120287 files and directories currently installed.)
Preparing to unpack .../librsvg2-common_2.50.2+dfsg-1_amd64.deb ...
Unpacking librsvg2-common:amd64 (2.50.2+dfsg-1) ...
Selecting previously unselected package gnome-icon-theme.
Preparing to unpack .../gnome-icon-theme_3.12.0-3_all.deb ...
Unpacking gnome-icon-theme (3.12.0-3) ...
Setting up librsvg2-common:amd64 (2.50.2+dfsg-1) ...
Setting up gnome-icon-theme (3.12.0-3) ...
update-alternatives: using
/usr/share/icons/gnome/scalable/places/debian-swirl.svg to provide
/usr/share/icons/gnome/scalable/places/start-here.svg (start-here.svg)
in auto mode
Processing triggers for libgdk-pixbuf-2.0-0:amd64 (2.42.2+dfsg-1) ...
Press Return to continue, 'q' followed by Return to quit.

Performing actions...
(Reading database ... 126333 files and directories currently installed.)
Removing tango-icon-theme (0.8.90-8) ...
(Reading database ... 122020 files and directories currently installed.)
Purging configuration files for tango-icon-theme (0.8.90-8) ...
Press Return to continue, 'q' followed by Return to quit.

Performing actions...
(Reading database ... 122019 files and directories currently installed.)
Removing gnome-icon-theme (3.12.0-3) ...
update-alternatives: using
/usr/share/icons/gnome/scalable/places/gnome-foot.svg to provide
/usr/share/icons/gnome/scalable/places/start-here.svg (start-here.svg)
in auto mode
update-alternatives: warning: skip creation of
/usr/share/icons/gnome/256x256/places/start-here.png because
associated file /usr/share/icons/gnome/256x256/places/gnome-foot.png
(of link group start-here.svg) doesn't exist


my uneducated guess is that maybe this bit is what fixed it:

Processing triggers for libgdk-pixbuf-2.0-0:amd64 (2.42.2+dfsg-1) ...

now inkscape works correctly even though gnome-icon-theme in not
installed anymore. I assume this means that this can only be
reproduces on a fresh install of debian unstable.




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

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

Versions of packages inkscape depends on:
ii  libatkmm-1.6-1v5   2.28.0-3
ii  libc6  2.31-9
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  libdbus-glib-1-2   0.110-6
ii  libdouble-conversion3  3.1.5-6.1
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.4+dfsg-1
ii  libgc1 1:8.0.4-3
ii  libgcc-s1  10.2.1-6
ii  libgdk-pixbuf-2.0-02.42.2+dfsg-1
ii  libgdl-3-5 3.34.0-1
ii  libglib2.0-0   2.66.4-1
ii  libglibmm-2.4-1v5  2.64.2-2
ii  libgomp1   10.2.1-6
ii  libgsl25   2.6+dfsg-2
ii  libgtk-3-0 3.24.24-1
ii  libgtkmm-3.0-1v5   3.24.2-2
ii  libgtkspell3-3-0   3.0.10-1
ii  libharfbuzz0b  2.6.7-1
ii  libjpeg62-turbo1:2.0.5-2
ii  liblcms2-2 2.12~rc1-2
ii  libmagick++-6.q16-88:6.9.11.57+dfsg-1
ii  libpango-1.0-0 1.46.2-3
ii  libpangocairo-1.0-01.46.2-3
ii  

Bug#980115: connection failure when rx initialized after 08:25:36 GMT 14 Jan 2021

[Jeremy Stanley]

Thanks for pulling this into unstable and testing! Is there any work
in progress to fix it in stable as well? I took a quick peek in
Salsa and didn't see any merge requests or an obvious branch for
Buster's 1.8.2 (just the debian/1.8.2-1 tag).