Bug#443524:

2021-02-28 Thread Cui Lang
-- 
We got your recommendation from a customer and we would like to place some
orders which is needed urgently. Kindly contact me back
- Your FOB Prices and FOB Port of loading.- Your estimated delivery time.
- Your Mode of Payment. ( If by L/C or T/T )

Cui Lang
National Sales Manager
+885 (0)12 336 250
|+885 (0) 12 336 251 | +885 (0) 81 336 251.
amij...@outlook.com
amij...@gmail.com


Bug#983547: [Pkg-julia-devel] Bug#983547: julia-common: julia-config.jl does not find libjulia.so

2021-02-28 Thread Graham Inggs
Mo, Norbert, do you think we should add libjulia-dev to julia's Recommends?



Bug#983547: [Pkg-julia-devel] Bug#983547: julia-common: julia-config.jl does not find libjulia.so

2021-02-28 Thread Graham Inggs
Hi Greg

On Mon, 1 Mar 2021 at 01:57, Gregory None  wrote:
>> Instead of adding the symlink, try installing the libjulia-dev package.
>
> That worked like a charm, thanks!

Thanks for the feedback.

Regards
Graham



Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop

2021-02-28 Thread Gunnar Hjalmarsson

But wait now...

In  you write:


This is caused by the change in the gnome-shell package (Bug#815050)
to add "Recommends: ibus", which breaks any non-ibus input method
framework (Bug#941624),


As far as I understand that is not correct, at least not any longer.

We did have an issue with im-config where the presence of IBus disabled 
im-config and prevented you from configuring some non-IBus input method 
framework. That issue has been fixed, and in Bullseye you will be able 
to configure e.g. Fcitx or UIM via im-config.


https://salsa.debian.org/input-method-team/im-config/-/commit/c2055cc4

It's true that GNOME favors IBus over other frameworks, and it may be 
motivated to default to IBus on GNOME for e.g. Japanese. However, right 
now I fear that you are about to make a few last minute changes for the 
wrong reason.


I may well have missed something here, but it would be good if you could 
try to explain exactly how the mere presence of IBus breaks the previous 
setup for Japanese users.


(I do realize from your merge request that you want to spare the users 
from the trouble of going to Settings and add an input method.)


--
Regards,

Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature


Bug#983748: dh-r: pkg-r-autopkgtest breaks autopkgtests

2021-02-28 Thread Graham Inggs
Source: dh-r
Version: 20210218
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: issue


Hi Maintainer

The recent upload of dh-r causes autopkgtests using pkg-r-autopkgtest
to fail.  See for example the output of r-bioc-affy [1] below.
Presumably caused by this commit [2].

grep: debian/*.substvars: No such file or directory
E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13:
Permission denied)
E: Unable to acquire the dpkg frontend lock
(/var/lib/dpkg/lock-frontend), are you root?
autopkgtest [06:13:16]: test pkg-r-autopkgtest: ---]
autopkgtest [06:13:16]: test pkg-r-autopkgtest:  - - - - - - - - - -
results - - - - - - - - - -
pkg-r-autopkgtestFAIL non-zero exit status 100

Regards
Graham


[1] https://ci.debian.net/packages/r/r-bioc-affy/testing/amd64/
[2] 
https://salsa.debian.org/r-pkg-team/dh-r/-/commit/62a4128c07a17de845e9d7260504fae187c3d193



Bug#950519: : gzip: please default to -n

2021-02-28 Thread Milan Kupcevic
> Package: gzip
> Version: 1.9-3
> Severity: wishlist
> 
> Hi!
> I've run ran into an Y2038 problem when compressing a file with a timestamp
> after that date.  It's a yet another reason to drop including the timestamp
> into .gz files -- something that no other popular compressor does.
> 
> It makes the output unreproducible for the same input.  This results in
> having to manually add -n in thousands of places.
> 
> Then, it breaks logrotate:
> error: Compressing program wrote following message to stderr when compressing 
> log /var/log/exim4/mainlog.1:
> gzip: stdin: warning: file timestamp out of range for gzip format
> error: failed to compress log /var/log/exim4/mainlog.1
> error: Compressing program wrote following message to stderr when compressing 
> log /var/log/syslog.1:
> gzip: stdin: warning: file timestamp out of range for gzip format
> error: failed to compress log /var/log/syslog.1
> 
> We're working on Y2038 bugs all around the kernel, glibc, etc.  The time
> such a fix would be strictly required for gzip is 18 years from now... but
> why not flip the switch already?


Hi Adam,

Gzip can store a timestamp in the range from 1970-01-01 00:00:01 UTC
through 2106-02-07 06:28:15 UTC. If you are having trouble with
timestamps after 2038-01-19 03:14:07 UTC but not later than 2106-02-07
06:28:15 UTC, that is likely due to a limitation present at some other
place i.e. glibc, gcc, filesystem, kernel ...

Milan



Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop

2021-02-28 Thread YOSHINO Yoshihito
Hi,

On Mon, Mar 1, 2021 at 3:32 AM Gunnar Hjalmarsson  wrote:
>
> On 2021-02-28 16:05, YOSHINO Yoshihito wrote:
> > On the GNOME desktop, manual set-up in GNOME Settings is required
> > in order to make ibus-anthy to work.
>
> Right. But does that differ in any way from other IBus input methods?

Yesterday I filed Bug#983623 to ibus-mozc for a similar change and it
has been uploaded to unstable.

gnome-shell now Recommends: ibus, which breaks a fresh bullseye installation of
Japanese (and probably Chinese) default desktop (that is, GNOME desktop.)
In order to work around this issue, in Bug#983653 I have proposed a patch
to add "Recommends: ibus-mozc | ibus-anthy" to task-japanese-gnome-desktop.

Buster Japanese GNOME desktop uses uim, which has worked out of the box.
By adding auto set-up to at least those two ibus-* packages
bullseye Japanese GNOME desktop on any architecture should work out of
the box again.

Regards,

--
YOSHINO Yoshihito 



Bug#983567: Subject: systemd-nspawn: can not run any command related changing the timestamp of files in the i386 bullseye chroot

2021-02-28 Thread binh1.tranhai
Hi Biebl,

>Architecure, debian release etc.
debian-buster:~$ uname -a
Linux debian 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 
GNU/Linux

debian-buster:~$ hostnamectl
  Operating System: Debian GNU/Linux 10 (buster)
Kernel: Linux 4.19.0-14-amd64
  Architecture: x86-64

>Do you use AppArmor, SeLInux,...?
debian-buster:~$ sudo systemctl status apparmor
Active: inactive (dead)

debian-buster:~$ sudo getenforce
Disable

Thanks,
Binh.

From: Michael Biebl 
Sent: Sunday, February 28, 2021 5:49 PM
To: tran hai binh(TSDV Eng 1) ; 
983...@bugs.debian.org <983...@bugs.debian.org>
Subject: Re: Bug#983567: Subject: systemd-nspawn: can not run any command 
related changing the timestamp of files in the i386 bullseye chroot

Am 26.02.2021 um 18:20 schrieb Michael Biebl:
> Control: tags -1 + moreinfo
>
> Hello Binh
>
> Am 26.02.21 um 12:13 schrieb binh1.tran...@toshiba.co.jp:
>> I enter to the bullseye chroot with i386 architecture by
>> systemd-nspawncommand,
>> and i can't run any command related changing the timestamp of files
>> asbelow:
>> debian-buster:~$ mkdir chroot-bullseye-i386
>> debian-buster:~$ sudo debootstrap --arch=i386
>> bullseyechroot-bullseye-i386 http://deb.debian.org/debian/
>> debian-buster:~$ sudo systemd-nspawn -q --resolv-conf=off
>> --timezone=off-D chroot-bullseye-i386
>> root@chroot-bullseye-i386:~# touch /usr/bin/bootctl
>> touch: setting times of '/usr/bin/bootctl': Operation not permitted
>> root@chroot-bullseye-i386:~# date
>> Thu Jan 1 00:00:01 UTC 1970
>>
>> Is this bug of systemd-container package?
>
> Can you describe your host system?

Architecure, debian release etc.
Do you use AppArmor, SeLInux,...?



Bug#983747: apt-listbugs: Needs a batch mode

2021-02-28 Thread eingousef
Package: apt-listbugs
Version: 0.1.35
Severity: normal
X-Debbugs-Cc: eingousef+debb...@rhizogen.es.eu.org

Dear Maintainer,

apt-listbugs needs a batch-mode where the package would be installed
as requested by the original apt command, and where apt-listbugs
findings would be purely informative (displayed on the stdout, or send
by e-mail). Therefore it would not break installation via automated
tools like ansible.

Regards,

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 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 /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages apt-listbugs depends on:
ii  apt 2.1.20
ii  ruby1:2.7+2
ii  ruby-debian 0.3.10+b4
ii  ruby-gettext3.3.3-2
ii  ruby-soap4r 2.0.5-5
ii  ruby-unicode0.4.4.4-1+b1
ii  ruby-xmlparser  0.7.3-4

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.8.3-2

Versions of packages apt-listbugs suggests:
ii  chromium [www-browser] 88.0.4324.182-1
ii  dillo [www-browser]3.0.5-7
ii  elinks [www-browser]   0.13.2-1+b1
ii  firefox [www-browser]  75.0-2
ii  firefox-esr [www-browser]  78.7.0esr-1
ii  links [www-browser]2.21-1+b1
ii  links2 [www-browser]   2.21-1+b1
ii  lynx [www-browser] 2.9.0dev.6-1
ii  reportbug  7.10.2
ii  sensible-utils 0.0.14
ii  surf [www-browser] 2.0+git20201107-1
ii  w3m [www-browser]  0.5.3+git20210102-3
ii  xdg-utils  1.1.3-4

-- no debconf information



Bug#980261: RFS: jgmenu/4.3.0-1 [RFP] -- Simple X11 menu

2021-02-28 Thread Boyuan Yang
Hi,

在 2021-02-28星期日的 21:19 +0100,Mateusz Łukasik写道:
> On 15.02.2021 at 16:40 +0100, Boyuan Yang wrote:
> > Hi,
> > 
> > 在 2021-02-14星期日的 12:09 +0100,Mateusz Łukasik写道:
> > > On 26.01.2021 at 23:25 +0100, Boyuan Yang wrote:
> > > > X-Debbugs-CC: mat...@linuxmint.pl jgm...@gmail.com
> > > > 
> > > > 
> > > > On Sat, 16 Jan 2021 21:38:16 +0100 =?UTF-
> > > > 8?Q?Mateusz_=c5=81ukasik?=
> > > >  wrote:
> > > > > Package: sponsorship-requests
> > > > > Severity: wishlist
> > > > > 
> > > > > Dear mentors,
> > > > > 
> > > > > I am looking for a sponsor for my package "jgmenu":
> > > > > 
> > > > >  * Package name    : jgmenu
> > > > >    Version : 4.3.0-1
> > > > >    Upstream Author : Johan Malm 
> > > > >  * URL : https://jgmenu.github.io/
> > > > >  * License : LGPL-2+, GPL-2+, Expat, LGPL-3+
> > > > >  * Vcs : https://github.com/mati75/jgmenu
> > > > >    Section : x11
> > > > > 
> > > > > It builds those binary packages:
> > > > > 
> > > > >   jgmenu-xfce4-panel-applet - xfce4-panel applet for
> > > > > jgmenu
> > > > >   jgmenu - Simple X11 menu
> > > > > 
> > > > > To access further information about this package, please
> > > > > visit
> > > > > the
> > > > following URL:
> > > > >   https://mentors.debian.net/package/jgmenu/
> > > > > 
> > > > > Alternatively, one can download the package with dget using
> > > > > this
> > > > command:
> > > > >   dget -x
> > > > https://mentors.debian.net/debian/pool/main/j/jgmenu/jgmenu_4.3.0-1.dsc
> > > > > Changes for the initial release:
> > > > > 
> > > > >  jgmenu (4.3.0-1) unstable; urgency=medium
> > > > >  .
> > > > >    * Initial release. (Closes: #882210)
> > > > One major problem: debian/copyright in your work says that the
> > > > whole
> > > > project is licensed under GPL-2+, however the LICENSE file from
> > > > upstream only gives GPLv2 license text. The README file also
> > > > does
> > > > not
> > > > mention that the whole project is licensed under GPLv2 **or
> > > > later**.
> > > > 
> > > > Could you please contact upstream to clarify the case? The best
> > > > output
> > > > would be adding a "the whole project is licensed under GPLv2 or
> > > > later"
> > > > sentense in the README file, which would make things clear to
> > > > everyone.
> > > > 
> > > > P.S. I took a look at upstream's debian/copyright file at
> > > > https://github.com/johanmalm/jgmenu/blob/master/debian/copyright
> > > >  ,
> > > > in
> > > > which the upstream only mentioned GPL-2, not GPL-2+. If
> > > > upstream is
> > > > only willing to release the whole project under GPL-2-only,
> > > > using
> > > > GPL-
> > > > 2+ is wrong and must be fixed.
> > > > 
> > > Fixed in new version uploaded to mentors.
> > 
> > Looking at https://mentors.debian.net/package/jgmenu/ , there are
> > several lintian warnings. This indicates that the grammar of your
> > debian/copyright file is not correct. Please fix these problems.
> > 
> > 
> > W: jgmenu source: missing-license-paragraph-in-dep5-copyright expat
> > (line 20)
> > W: jgmenu source: missing-license-paragraph-in-dep5-copyright gpl-2
> > (line 15)
> > W: jgmenu source: missing-license-paragraph-in-dep5-copyright gpl-
> > 2+
> > (line 63)
> > 
> > 
> > Hint: you either need to paste all license texts under each
> > License:
> > field, or you use "License:xxx" placeholder in each section and
> > provide
> > a separate "License: xxx" plus full license text that does not
> > attach
> > with any "file section" at the bottom of the debian/copyright file.
> > Please read
> > https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> > again (especially section 5.2.1) for the correct way of fixing
> > these
> > lintian warnings.
> > 
> > Thanks,
> > Boyuan Yang
> > 
> I think now it's fixed. Lintian warnings for copyright are clean.
> 

I just uploaded it onto the NEW queue.

Thanks,
Boyuan Yang



Bug#983706: gzip FTBFS on mips64el: FAIL: timestamp

2021-02-28 Thread YunQiang Su
Adrian Bunk  于2021年3月1日周一 上午7:13写道:
>
> Source: gzip
> Version: 1.10-2
> Severity: serious
> Tags: ftbfs
>
> https://buildd.debian.org/status/fetch.php?pkg=gzip&arch=mips64el&ver=1.10-3&stamp=1614531854&raw=0

It seems due to some problem of kernel or filesystem:

On x86:
syq@vm208:~$ touch -t 196912312359.59 in
syq@vm208:~$ ls -l in
-rw-r--r-- 1 syq syq 0 Dec 31  1969 in
syq@vm208:~$ cp -a in in.xx
syq@vm208:~$ ls -l in.xx
-rw-r--r-- 1 syq syq 0 Dec 31  1969 in.xx

On mips:
syq@m530-2:~/tmp/gzip/gzip-1.10/builddir$ ls -l in
-rw-r--r-- 1 syq syq 0 Dec 31  1969 in
syq@m530-2:~/tmp/gzip/gzip-1.10/builddir$ cp -a in in.xx
syq@m530-2:~/tmp/gzip/gzip-1.10/builddir$ ls -l in.xx
-rw-r--r-- 1 syq syq 0 Feb  7  2106 in.xx

>
> ...
> FAIL: timestamp
> ===
>
> + initial_cwd_=/<>/builddir/tests
> + testdir_prefix_
> + printf gt
> + pfx_=gt
> + mktempd_ /<>/builddir/tests gt-timestamp.
> + destdir_=/<>/builddir/tests
> + template_=gt-timestamp.
> + MAX_TRIES_=4
> + destdir_slash_=/<>/builddir/tests/
> + unset TMPDIR
> + d=/<>/builddir/tests/gt-timestamp.TDZE
> + :
> + test -d /<>/builddir/tests/gt-timestamp.TDZE
> + ls -dgo /<>/builddir/tests/gt-timestamp.TDZE
> + perms=drwx-- 2 40 Feb 28 17:04 
> /<>/builddir/tests/gt-timestamp.TDZE
> + :
> + echo /<>/builddir/tests/gt-timestamp.TDZE
> + return
> + test_dir_=/<>/builddir/tests/gt-timestamp.TDZE
> + cd /<>/builddir/tests/gt-timestamp.TDZE
> + gl_init_sh_nl_=
>
> + IFS=
>
> + expr 1 + 128
> + eval trap 'Exit 129' 1
> + trap Exit 129 1
> + expr 2 + 128
> + eval trap 'Exit 130' 2
> + trap Exit 130 2
> + expr 3 + 128
> + eval trap 'Exit 131' 3
> + trap Exit 131 3
> + expr 13 + 128
> + eval trap 'Exit 141' 13
> + trap Exit 141 13
> + expr 15 + 128
> + eval trap 'Exit 143' 15
> + trap Exit 143 15
> + trap remove_tmp_ 0
> + path_prepend_ ..
> + test 1 != 0
> + path_dir_=..
> + abs_path_dir_=/<>/builddir/tests/..
> + 
> PATH=/<>/builddir/tests/..:/<>/builddir:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
> + create_exe_shims_ /<>/builddir/tests/..
> + return 0
> + shift
> + test 0 != 0
> + export PATH
> + TZ=UTC0
> + export TZ
> + oldIFS=
>
> + IFS=~
> + set 19010101 Jan  1  1901
> + time=19010101
> + date=Jan  1  1901
> + IFS=
>
> + touch -t 19010101 in
> + ls -l in
> + ls_l=-rw-rw-r-- 1 buildd buildd 0 Jan  1  1901 in
> + returns_ 2 gzip in
> + fail=1
> + rm -f in.gz in
> + IFS=~
> + set 196912312359.59 Dec 31  1969
> + time=196912312359.59
> + date=Dec 31  1969
> + IFS=
>
> + touch -t 196912312359.59 in
> + ls -l in
> + ls_l=-rw-rw-r-- 1 buildd buildd 0 Dec 31  1969 in
> + returns_ 2 gzip in
> + fail=1
> + rm -f in.gz in
> + IFS=~
> + set 19700101 Jan  1  1970
> + time=19700101
> + date=Jan  1  1970
> + IFS=
>
> + touch -t 19700101 in
> + ls -l in
> + ls_l=-rw-rw-r-- 1 buildd buildd 0 Jan  1  1970 in
> + returns_ 2 gzip in
> gzip: in: warning: file timestamp out of range for gzip format
> + rm -f in.gz in
> + IFS=~
> + set 210602070628.16 Feb  7  2106
> + time=210602070628.16
> + date=Feb  7  2106
> + IFS=
>
> + touch -t 210602070628.16 in
> + ls -l in
> + ls_l=-rw-rw-r-- 1 buildd buildd 0 Feb  7  2106 in
> + returns_ 2 gzip in
> gzip: in: warning: file timestamp out of range for gzip format
> + rm -f in.gz in
> + IFS=~
> + set 19700101.01 Jan  1  1970
> + time=19700101.01
> + date=Jan  1  1970
> + IFS=
>
> + touch -t 19700101.01 in
> + ls -l in
> + ls_l=-rw-rw-r-- 1 buildd buildd 0 Jan  1  1970 in
> + gzip in
> + rm -f in.gz in
> + IFS=~
> + set 203801190314.07 Jan 19  2038
> + time=203801190314.07
> + date=Jan 19  2038
> + IFS=
>
> + touch -t 203801190314.07 in
> + ls -l in
> + ls_l=-rw-rw-r-- 1 buildd buildd 0 Jan 19  2038 in
> + gzip in
> + rm -f in.gz in
> + IFS=~
> + set 203801190314.08 Jan 19  2038
> + time=203801190314.08
> + date=Jan 19  2038
> + IFS=
>
> + touch -t 203801190314.08 in
> + ls -l in
> + ls_l=-rw-rw-r-- 1 buildd buildd 0 Jan 19  2038 in
> + gzip in
> + rm -f in.gz in
> + IFS=~
> + set 210602070628.15 Feb  7  2106
> + time=210602070628.15
> + date=Feb  7  2106
> + IFS=
>
> + touch -t 210602070628.15 in
> + ls -l in
> + ls_l=-rw-rw-r-- 1 buildd buildd 0 Feb  7  2106 in
> + gzip in
> + rm -f in.gz in
> + printf \037\213\10\0\377\377\377\377\0\377\3\0\0\0\0\0\0\0\0\0
> + gzip -Nlv
> method  crc date  time   compresseduncompressed  ratio 
> uncompressed_name
> defla  Feb  7 06:28  20   0   0.0% 
> stdout
> + status=0
> + test 0 -eq 0
> + :
> + gzip --no-name
> + Exit 1
> + set +e
> + exit 1
> + exit 1
> + remove_tmp_
> + __st=1
> + cleanup_
> + :
> + test  = yes
> + cd /<>/builddir/tests
> + chmod -R u+rwx /<>/builddir/tests/gt-timestamp.TDZE
> + rm -rf /<>/builddir/tests/gt-timestamp.TDZE
> + exit 1
> FAIL timestamp (exit status: 1)
>
> 
> Testsuite summary for gzip 1.10
> =

Bug#979688: Simplifying the list of image files for arm64 sunxi boards

2021-02-28 Thread Vagrant Cascadian
On 2021-01-31, harr...@gmx.ph wrote:
> I thought I might as well add the remaining 24 armhf boards to it while
> I was at it, so it now has 26 armhf and 11 arm64 boards, matching what's
> in debian/targets, sorted by U-Boot board name.

Hrm. This turns out to make it hard to consider merging the patch as it
no longer applies, and this aspect isn't really at the heart of this bug
report...

That said, the work you did on that was a huge help and I'll apply the
board-specific changes where appropriate for bullseye (after sorting
them).


> I think it would be nice if this simplification could be included in
> bullseye.  What do you think?

Seems unlikely at this point, sorry I took so long to take a look at
this.


> diff --git a/debian/bin/u-boot-install-sunxi b/debian/bin/u-boot-install-sunxi
> index 4f80e01099..4b862fd3ff 100755
> --- a/debian/bin/u-boot-install-sunxi
> +++ b/debian/bin/u-boot-install-sunxi
...
> + "NextThing C.H.I.P.") TARGET="/usr/lib/u-boot/CHIP" ;;

I know the CHIP can't be installed with this method, so I left this one
out of my patch adding boards. Fairly sure the rest can be...


>   *)
>   echo >&2 "ERROR: Unknown system: ${dtmodelname}"
> - echo >&2 "Specify target: TARGET=/usr/lib/u-boot/UBOOT"
> + echo >&2 "Specify target: 
> TARGET=/usr/lib/u-boot/"
>   exit 1
>   ;;
>   esac

Hrm. Guess it is clearer, but also pretty minor...


> -echo "Writing u-boot SPL image"
> -dd conv=notrunc if=${spl} of="$DEV" bs=8k seek=1
> +imfile="u-boot-sunxi-with-spl.bin"
>
> -if [ -n "$itb" ]; then
> -echo "Writing u-boot FIT image"
> -dd conv=notrunc if=${itb} of="$DEV" bs=8k seek=5
> +if [ ! -f "${TARGET}/${imfile}" ]; then
> + echo >&2 "$0: no ${imfile} image file in ${TARGET}"
> + exit 1
>  fi
>
> -sync "$DEV"
> +echo "Writing U-Boot image to ${DEV}"
> +dd conv=fsync,notrunc if="${TARGET}/${imfile}" of="$DEV" bs=8k seek=1

And this, we'll leave for bookworm...


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#894821: updated upstream snuffleupagus git repo

2021-02-28 Thread Federico Grau
Control: retitle -1 ITP: snuffleupagus -- Security module for php7 - Killing 
bugclasses and virtual-patching the rest 
Control: owner -1 donf...@casagrau.org  
  

Resending with control entries at top.


signature.asc
Description: PGP signature


Bug#894821: updated upstream snuffleupagus git repo

2021-02-28 Thread Federico Grau
Upstream snuffleupagus activity appears to have transitioned to 
https://github.com/jvoisin/snuffleupagus .
Thanks to taffit on #debian-php for help pointing out the stale activity (2018, 
one commit 2020).

Upstream currently compiles well on unstbale, with d/control Build-Depends
addition of dh-php.

Control: retitle -1 ITP: snuffleupagus -- Security module for php7 - Killing 
bugclasses and virtual-patching the rest
Control: owner -1 donf...@casagrau.org





signature.asc
Description: PGP signature


Bug#983746: firejail: with --private=, an existing "bin" directory is read-only

2021-02-28 Thread Vincent Lefevre
Package: firejail
Version: 0.9.64.4-2
Severity: important

When using --private=, an existing "bin" directory in 
is read-only. This is silly: this means that one cannot restart
a firejail session:

zira:~> firejail --private=$HOME/fj-test zsh
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc
Warning: networking feature is disabled in Firejail configuration file

** Note: you can use --noprofile to disable default.profile **

Parent pid 685072, child pid 685073
Child process initialized in 47.87 ms
zira% mkdir bin
zira% touch bin/foo
zira% ls -l bin
total 0
-rw-r--r-- 1 vinc17 vinc17 0 2021-03-01 02:32:19 foo
zira% 

Parent is shutting down, bye...

zira:~> firejail --private=$HOME/fj-test zsh
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc
Warning: networking feature is disabled in Firejail configuration file

** Note: you can use --noprofile to disable default.profile **

Parent pid 685097, child pid 685098
Child process initialized in 51.94 ms
zira% touch bin/blah
touch: cannot touch 'bin/blah': Read-only file system

I don't see the point to have "bin" read-only in this case, as the
purpose of "--private=" is that this "bin" directory is specific to
the firejail session.

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

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

Versions of packages firejail depends on:
ii  libapparmor1  2.13.6-9
ii  libc6 2.31-9
ii  libselinux1   3.1-3

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.64.4-2
ii  iproute2   5.10.0-4
ii  iptables   1.8.7-1
ii  xauth  1:1.1-1
ii  xdg-dbus-proxy 0.1.2-2
ii  xpra   3.0.13+dfsg1-1
ii  xvfb   2:1.20.10-3

firejail suggests no packages.

-- no debconf information

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



Bug#983745: mirror listing update for twitchdarkbot.com

2021-02-28 Thread Roul_
Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: twitchdarkbot.com
Type: leaf
Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el 
s390x
Archive-http: /debian/
Maintainer: Roul_ 
Country: KR Korea, Republic of




Trace Url: http://twitchdarkbot.com/debian/project/trace/
Trace Url: http://twitchdarkbot.com/debian/project/trace/ftp-master.debian.org
Trace Url: http://twitchdarkbot.com/debian/project/trace/twitchdarkbot.com



Bug#983744: mirror submission for twitchdarkbot.com

2021-02-28 Thread Roul_
Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: twitchdarkbot.com
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Roul_ 
Country: KR Korea, Republic of




Trace Url: http://twitchdarkbot.com/debian/project/trace/
Trace Url: http://twitchdarkbot.com/debian/project/trace/ftp-master.debian.org
Trace Url: http://twitchdarkbot.com/debian/project/trace/twitchdarkbot.com



Bug#983743: group.c: use "snprintf()" instead of "sprintf()"

2021-02-28 Thread Bjarni Ingi Gislason
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From edfaa6658b316e4c0c84ce2d452b5bc4102d Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Mon, 1 Mar 2021 00:51:48 +
>Subject: [PATCH] group.c: use "snprintf()" instead of "sprintf()"

  group.c: use "snprintf()" instead of "sprintf()".

Signed-off-by: Bjarni Ingi Gislason 
---
 group.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/group.c b/group.c
index 2045e7b..8819d52 100644
--- a/group.c
+++ b/group.c
@@ -52,6 +52,7 @@ extern int  killed_articles;
 extern int  seq_cross_filtering;
 extern char*default_save_file, *folder_save_file;
 
+extern const size_t NDELAYED_MSG;
 extern char delayed_msg[];
 extern int32db_read_counter;
 
@@ -541,7 +542,7 @@ goto_group(int command, article_header * ah, flag_type 
access_mode)
goto_return(ME_NO_REDRAW);
 
if (gh->first_db_article < gh->last_db_article && gh->current_first <= 
0) {
-   sprintf(buffer, "%s%s%s) ",
+   snprintf(buffer, FILENAME, "%s%s%s) ",
(gh->group_flag & G_UNSUBSCRIBED) ? " UNSUB" : "",
(gh->group_flag & G_MERGE_HEAD) ? " MERGED" : "",
gh->unread_count <= 0 ? " READ" : "");
@@ -641,7 +642,7 @@ get_group_name:
goto_return(ME_NO_REDRAW);
goto get_first;
 }
-sprintf(buffer, "%c", ans1);
+snprintf(buffer, FILENAME, "%c", ans1);
 
 switch (ans1) {
 
@@ -679,7 +680,7 @@ get_group_name:
 #endif
 
*group_file_name = NUL;
-   sprintf(fbuffer, "%s%ld", group_path_name, ah->a_number);
+   snprintf(fbuffer, FILENAME, "%s%ld", group_path_name, 
ah->a_number);
answer = fbuffer;
goto get_folder;
}
@@ -1159,7 +1160,7 @@ merge_and_read(flag_type access_mode, char *mask)
 current_group = &dummy_group;
 
 kb = (kb + 1023) >> 10;
-sprintf(delayed_msg, "Read %ld articles in %ld seconds (%ld kbyte/s)",
+snprintf(delayed_msg, NDELAYED_MSG, "Read %ld articles in %ld seconds (%ld 
kbyte/s)",
(long) db_read_counter, (long) t2, t2 > 0 ? kb / t2 : kb);
 
 menu(merged_header);
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason



Bug#983742: ITP: boolean.py -- boolean algebra library for Python

2021-02-28 Thread Jelmer Vernooij
Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: boolean.py
  Version : 3.8
  Upstream Author : 
* URL : https://github.com/bastikr/boolean.py
* License : BSD-2-clause
  Programming Lang: Python
  Description : boolean algebra library for Python

"boolean.py" is a small library implementing a boolean algebra. It defines two
base elements, TRUE and FALSE, and a Symbol class that can take on one of these
two values. Calculations are done in terms of AND, OR and NOT - other
compositions like XOR and NAND are not implemented but can be emulated with AND
or and NOT. Expressions are constructed from parsed strings or in Python.

This is a dependency for the license-expression module.



Bug#983741: ITP: license-expression -- parse, compare, ' 'simplify and normalize license expressions (such as SPDX license ' 'expressions) using boolean logic.

2021-02-28 Thread Jelmer Vernooij
Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: license-expression
  Version : 1.2
  Upstream Author : 
* URL : https://github.com/nexb/license-expression
* License : Apache-2.0
  Programming Lang: Python
  Description : parse and manipulate SPDX license expressions

license-expression is a small utility library to parse, compare, simplify and
normalize license expressions (e.g. SPDX license expressions) using boolean
logic such as: GPL-2.0 or later WITH Classpath Exception AND MIT.

See also for details:
https://spdx.org/sites/cpstandard/files/pages/files/spdxversion2.1.pdf#page=95&zoom=auto

(this is a dependency for scancode-toolkit)



Bug#963834: isync: new upstream version

2021-02-28 Thread Michael Grant

The upstream version of this now seems to be 1.4.1.  I’d really live to see 
this get into Bullseye!  What needs to be done?  What’s blocking this?

Michael Grant


Bug#983740: gssproxy: Missing default config for nfs clients

2021-02-28 Thread Vincent Danjean
Package: gssproxy
Version: 0.8.2-1
Severity: normal

  Hi,

  On a server I recently installed, I saw its behavior
was different from older ones wrt to gssproxy and NFS
mounts.
  On this new server, I saw that /etc/gssproxy/99-nfs-client.conf
is missing.

  Looking into git log of the packaging, I see two
commit with the same message:
ef6d35f7: Stop providing NFS server config snippet (Closes: #856965)
83da02b8: Fix #856965 by dropping NFS server config snippet

  The problem is that the second one (83da02b8, the older)
is, in fact, removing the NFS *client* config. Is it really
wanted?

  Regards,
Vincent

PS: about the NFS server config snippet, the config file
is removed from new packages, but it is not removed on
machine on upgrades, even if the file has not been modified.


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

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

Versions of packages gssproxy depends on:
ii  libc6 2.31-9
ii  libgssapi-krb5-2  1.18.3-4
ii  libgssrpc41.18.3-4
pn  libini-config5
ii  libk5crypto3  1.18.3-4
ii  libkrb5-3 1.18.3-4
ii  libpopt0  1.18-2
pn  libref-array1 
ii  libselinux1   3.1-2+b2
ii  libverto1 0.3.1-1

gssproxy recommends no packages.

gssproxy suggests no packages.



Bug#982567: openms build-depends on removed package

2021-02-28 Thread Adrian Bunk
On Sat, Feb 20, 2021 at 05:03:45PM +0100, Filippo Rusconi wrote:
> Greetings, Andreas and Michael,
> 
> I hope you are doing fine.
> 
> On Fri, Feb 19, 2021 at 10:19:11PM +0100, Andreas Tille wrote:
> > Hi Filippo,
> > 
> > this is extremely unfortunate.  However, I guess the alternative would
> > have been to keep some RC buggy seqan-dev which would not have helped
> > openms as well.  I tried the same as Peter and replaced the
> > Build-Depends seqan-dev by libseqan2-dev.
> > 
> > I can confirm the observation from Peter about the missing header file.
> > I simply tried to comment those missing headers (next one is also
> > missing):
> > 
> > 
> > // #include 
> > // #include 
> [...]
> 
> Thank you for your trials and explanations. I am no on vacation, which means
> I'll finally find some time to try understand the implications of that SeqAn
> upgrade.
> 
> I'll keep you posted with my findings.

The brute force approach works for me:
1. install seqan-dev from buster (for step 2)
2. cp -a /usr/include/seqan debian/
3. in debian/control remove the seqan-dev build dependency
4. in debian/rules pass -DSEQAN_INCLUDE_DIR=$(DEBIAN_DIR)
   to dh_auto_configure

> Cheers,
> 
> Filippo

cu
Adrian



Bug#983697: FTBFS: Failing tests

2021-02-28 Thread Louis-Philippe Véronneau
I've bypassed the issue by disabling the tests that fail.

See #983738 for an actual fix.

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



OpenPGP_signature
Description: OpenPGP digital signature


Bug#983719: esptool: Version 3.0 fixes critical bugs

2021-02-28 Thread Matthias Urlichs
Package: esptool
Version: 2.8+dfsg-1
Severity: serious
Justification: broken

$ esptool  erase_flash
esptool.py v2.8
Found 3 serial ports
Serial port /dev/ttyUSB0
Connecting
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme 
None
Crystal is 40MHz
MAC: 3c:71:bf:03:2e:0c
Enabling default SPI flash mode...
Erasing flash (this may take a while)...

A fatal error occurred: ESP32 ROM does not support function erase_flash.

... umm ... YES IT DOES.

Version 3.0 works. Please upgrade.


-- System Information:
Debian Release: 10.8
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'unstable'), (550, 'experimental'), (550, 
'oldstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages esptool depends on:
ii  libc6   2.31-9
ii  python3 3.9.1-1
ii  python3-ecdsa   0.13-3+deb10u1
pn  python3-pyaes   
ii  python3-serial  3.4-4

esptool recommends no packages.

esptool suggests no packages.



Bug#983739: folder.c: add information to a prototype and a message

2021-02-28 Thread Bjarni Ingi Gislason
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 2e7a41d46acfda86a5a1073b7949f846b6270ca2 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 28 Feb 2021 23:54:15 +
>Subject: [PATCH] folder.c: add information to a prototype and a message

  Add a data type declaration for an argument to a prototype of "struct
passwd *getpwnam()".

  Add information to a message (msg()).

Signed-off-by: Bjarni Ingi Gislason 
---
 folder.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/folder.c b/folder.c
index 2f42b2f..a50be28 100644
--- a/folder.c
+++ b/folder.c
@@ -53,7 +53,7 @@ int ignore_fancy_select = 0;  /* turn off 
select features
 extern int  fmt_linenum;
 extern char*header_lines;
 
-extern struct passwd *getpwnam();
+extern struct passwd *getpwnam(const char *); /*  */
 
 /*
  * expand ~[user][/...] form
@@ -433,7 +433,7 @@ folder_menu(char *path, int mode)
 if (s_keyboard) {
menu_cmd = ME_NO_REDRAW;
 } else if (n_articles == 0) {
-   msg("Not a folder (no article header)");
+   msg("%s is not a folder (no article header)", folder_name);
menu_cmd = ME_NO_REDRAW;
 } else {
if (n_articles > 1) {
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason



Bug#983738: testsuite fails when the network is disabled

2021-02-28 Thread Louis-Philippe Véronneau
Package: src:trapperkeeper-webserver-jetty9-clojure
Version: 4.1.0-2
Severity: normal
Tags: upstream
Control: forwarded -1 
https://github.com/puppetlabs/trapperkeeper-webserver-jetty9/issues/224

As explained in BTS #983697, the testsuite fails when the network is
disabled during build.

I've debugged the issue and pinged upstream about it, but I'm not
planning to fix the actual issue myself. It'll have to wait
for upstream to fix it for us :)

Meanwhile, I've disabled the failing tests in a patch.

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



OpenPGP_signature
Description: OpenPGP digital signature


Bug#983547: [Pkg-julia-devel] Bug#983547: julia-common: julia-config.jl does not find libjulia.so

2021-02-28 Thread Gregory None
Hi Graham

Le ven. 26 févr. 2021 à 10:39, Graham Inggs  a écrit :

> Hi Gregory
>
> On Fri, 26 Feb 2021 at 02:48, Gregory  wrote:
> > Try for example:
> > $/usr/share/julia/julia-config.jl --allflags
> >
> > It will return (among other things):
> > libjulia.so: cannot open shared object file: no such file or directory
> >
> > Adding a symlink libjulia.so that points to libjulia.so.1.5 (package
> libjulia1)
> > is a workaround of course.
>
> Instead of adding the symlink, try installing the libjulia-dev package.
>

That worked like a charm, thanks!
__
Greg


Bug#983737: open-iscsi: configuration does not finish with sysvinit-core

2021-02-28 Thread Ryutaroh Matsumoto
Package: open-iscsi
Version: 2.1.3-2
Severity: normal
Tags: sid bullseye

Dear Maintainer,

When /sbin/init is sysvinit-core, apt-get install open-iscsi does not finish as
follows. The postinst script is terminated from another tty.

Script started on 2021-03-01 08:42:11+09:00 [TERM="linux" TTY="/dev/tty1" 
COLUMNS="128" LINES="48"]
root@host:~# apt-get install open-iscsi
The following additional packages will be installed:
  libisns0 libopeniscsiusr netbase
The following NEW packages will be installed:
  libisns0 libopeniscsiusr netbase open-iscsi
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 504 kB of archives.
After this operation, 2,211 kB of additional disk space will be used.
Preparing to unpack .../libisns0_0.100-3_amd64.deb ...
Unpacking libisns0:amd64 (0.100-3) ...
Selecting previously unselected package libopeniscsiusr.
Preparing to unpack .../libopeniscsiusr_2.1.3-2_amd64.deb ...
Unpacking libopeniscsiusr (2.1.3-2) ...
Selecting previously unselected package open-iscsi.
Preparing to unpack .../open-iscsi_2.1.3-2_amd64.deb ...
Unpacking open-iscsi (2.1.3-2) ...
Selecting previously unselected package netbase.
Preparing to unpack .../archives/netbase_6.2_all.deb ...
Unpacking netbase (6.2) ...
Setting up libopeniscsiusr (2.1.3-2) ...
Setting up libisns0:amd64 (0.100-3) ...
Setting up netbase (6.2) ...
Setting up open-iscsi (2.1.3-2) ...
Starting iSCSI initiator daemon: iscsidSetting up iSCSI targets:
iscsiadm: No records found
.
Starting iSCSI initiator daemon: iscsidSetting up iSCSI targets:
iscsiadm: No records found
.

dpkg: error processing package open-iscsi (--configure):
 installed open-iscsi package post-installation script subprocess was killed by 
signal (Terminated)
Processing triggers for libc-bin (2.31-9) ...
Processing triggers for initramfs-tools (0.139) ...
update-initramfs: Generating /boot/initrd.img-5.10.0-3-amd64
Errors were encountered while processing:
 open-iscsi
E: Sub-process /usr/bin/dpkg returned an error code (1)
W: Operation was interrupted before it could finish
root@host:~# exit

Script done on 2021-03-01 08:43:48+09:00 [COMMAND_EXIT_CODE="100"]

Best regards, Ryutaroh Matsumoto


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

Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages open-iscsi depends on:
ii  debconf [debconf-2.0]  1.5.75
ii  libc6  2.31-9
ii  libelogind0 [libsystemd0]  246.9.1-1+debian1
ii  libisns0   0.100-3
ii  libkmod2   28-1
ii  libmount1  2.36.1-7
ii  libopeniscsiusr2.1.3-2
ii  libssl1.1  1.1.1j-1
ii  udev   247.3-1

open-iscsi recommends no packages.

open-iscsi suggests no packages.

-- debconf information:
  open-iscsi/downgrade_and_break_system:
  open-iscsi/upgrade_even_with_failed_sessions:
  open-iscsi/upgrade_recovery_error:
  open-iscsi/remove_even_with_active_sessions:



Bug#983736: ponyprog: Package description is outdated

2021-02-28 Thread Adrian Bunk
Package: ponyprog
Version: 3.1.2+ds-1
Severity: minor

...
 Using Ponyprog together with generic USB2serial adapters is currently
 not possible! There are plans on upstream to use libusb to add such
 functionality.


This was added in 3.1.0.



Bug#983735: nbdkit should re-enable building the torrent plugin

2021-02-28 Thread Adrian Bunk
Source: nbdkit
Version: 1.24.1-1
Severity: normal

libtorrent-rasterbar-dev is back in testing,
so the temporary #974574 workaround is obsolete.



Bug#983734: xsane-common: Docs need symlink to be found from GUI

2021-02-28 Thread Gunnar Hjalmarsson

Package: xsane-common
Version: 0.999-9
Tags: patch

Hi!

When selecting "Help -> XSane doc" in the GUI (or pressing "F1"), it 
does not find the docs given the current location of them. The proposed 
symlink in the attached patch works around the issue.


--
Cheers,

Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj
--- xsane-0.999.orig/debian/xsane-common.links
+++ xsane-0.999/debian/xsane-common.links
@@ -1 +1,2 @@
+usr/share/doc/xsane-common/html usr/share/sane/xsane/doc
 usr/share/doc/xsane-common/html/sane-xsane-doc.html 
usr/share/doc/xsane-common/html/index.html


OpenPGP_signature
Description: OpenPGP digital signature


Bug#983733: Enable Linux API support in libcec

2021-02-28 Thread Punit Agrawal
Source: libcec
Severity: normal
Tags: patch

Hi,

libcec has support for Linux API that allows interacting with devices
exposed via "/dev/cec0". The attached patch enables support for this
feature in the package.

Please enable the feature - if possible enabling it in time for the
bullseye release will be ideal.

Thanks,
Punit
>From a78ba8bf9bd08a5aae384e1bc2fafa1c9f36055b Mon Sep 17 00:00:00 2001
From: Punit Agrawal 
Date: Mon, 1 Mar 2021 08:04:58 +0900
Subject: [PATCH] debian/rules: Enable Linux API

libcec has support for the Linux CEC api that enables interaction with
devices that are exposed via "/dev/cec0" on supported systems. Enable
Linux API support in the library to allows users to interact with
media applications using their remote on such systems.
---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 94a2e030668f..0e330e0279a2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,7 +11,8 @@ override_dh_auto_configure:
ln -s /usr/include/cec-platform include/platform && \
dh_auto_configure -- -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=1 
-DCMAKE_INSTALL_LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) \
-DHAVE_EXYNOS_API=1 \
-   -DHAVE_AOCEC_API=1
+   -DHAVE_AOCEC_API=1 \
+   -DHAVE_LINUX_API=1
 
 override_dh_auto_install:
dh_auto_install
-- 
2.30.0



Bug#983732: execute.c: add comments related to "signal()"

2021-02-28 Thread Bjarni Ingi Gislason
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From f1c2df4107c73786e9f46d9a42af23ad4bb16f62 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 28 Feb 2021 22:48:47 +
>Subject: [PATCH] execute.c: add comments related to "signal()"

execute.c:

  Add comments related to "signal()".

  Add data type declarations of arguments to a prototype.

  Added a FIXME: use "sigaction(2)", see "signal(2)"

Signed-off-by: Bjarni Ingi Gislason 
---
 execute.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/execute.c b/execute.c
index ff9e789..04c6afc 100644
--- a/execute.c
+++ b/execute.c
@@ -30,7 +30,7 @@ static char*init_shell = SHELL;
 char   *user_shell;
 char   *exec_chdir_to = NULL;
 
-extern int  errno;
+/* extern int  errno; */ /* defined in errno.h */
 
 
 static int
@@ -54,7 +54,8 @@ int
 execute(char *path, char **args, int toggle_visual)
 {
 int was_raw, pid, i, status;
-sig_type(*quit) (), (*intr) (), (*tstp) ();
+/* "sig_type" is either int or void, defined in "global.h" */
+sig_type (*quit) (int), (*intr) (int), (*tstp) (int);
 
 was_raw = toggle_visual ? visual_off() : unset_raw();
 
@@ -74,6 +75,7 @@ execute(char *path, char **args, int toggle_visual)
exit(20);
}
 }
+/* FIXME, use "sigaction(2)", see "signal(2)" */
 quit = signal(SIGQUIT, SIG_IGN);
 intr = signal(SIGINT, SIG_IGN);
 
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason



Bug#983697: FTBFS: Failing tests

2021-02-28 Thread Louis-Philippe Véronneau
I've been able to reproduce this bug building in a networkless schroot
with sbuild.

With a network access, the testsuite does not fail.

I'll try to debug further and upload a patch.

Thanks,

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



OpenPGP_signature
Description: OpenPGP digital signature


Bug#983326: rich: test failures with TERM=unknown

2021-02-28 Thread Sandro Tosi
On Mon, 22 Feb 2021 13:27:20 +0100 Gianfranco Costamagna
 wrote:
> Hello, looks like the testsuite is failing with TERM=unknown, I don't really 
> know why, but calling dh_auto_test with TERM=linux seems to fix it.
>
> override_dh_auto_test:
> TERM=linux PYBUILD_SYSTEM=custom 
> PYBUILD_TEST_ARGS="PYTHONPATH=$(CURDIR) {interpreter} -m pytest" dh_auto_test
>
>
> I'm not adding the tag "patch" because some bug in the code probably exists.
>
> Example of failure:
> https://launchpadlibrarian.net/524437846/buildlog_ubuntu-hirsute-amd64.rich_9.11.0-1_BUILDING.txt.gz

as mentioned at
https://github.com/willmcgugan/rich/issues/1051#issuecomment-787529446
this is a Ubuntu-specific issue: why did you report it to debian,
where the package builds fine both on buildd and autopkgtest
infrastructures?

this is something you should report to launchpad and fix within ubuntu.



Bug#983731: manpages-dev: many pthread manpages missing (and this bug is not about those found in glibc-doc)

2021-02-28 Thread Thorsten Glaser
Package: manpages-dev
Version: 5.10-1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

Besides those few found in the glibc-doc package (which probably should
just be taken over, given that that package really consists of only a
number of pthread manpages and… imperial tons of changelogs?!), there are
manpages genuinely missing, such as pthread_barrier_init, pthread_barrier_wait
and friends.

Funnily enough, they apparently used to exist (in another package) in
stretch…

Could be useful combing through libc and looking for more undocumented APIs
where such documentation is obtainable elsewhere…


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

Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages manpages-dev depends on:
ii  manpages  5.10-1

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  konqueror [man-browser]  4:20.12.0-4
ii  man-db [man-browser] 2.9.4-2

-- no debconf information


Bug#983730: dir.c: use "snprintf()" instead of "sprintf()"

2021-02-28 Thread Bjarni Ingi Gislason
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 09426e21f08502654275884fc0e148bb427565d7 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 28 Feb 2021 22:22:44 +
>Subject: [PATCH] dir.c: use "snprintf()" instead of "sprintf()"

  dir.c: use "snprintf()" instead of "sprintf()".

Signed-off-by: Bjarni Ingi Gislason 
---
 dir.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/dir.c b/dir.c
index a174c87..f8f1a28 100644
--- a/dir.c
+++ b/dir.c
@@ -144,9 +144,9 @@ int
 list_directory(char *dir, char *prefix)
 {
 if (prefix[0])
-   sprintf(dir_path, "cd %s && echo %s* 2>/dev/null", dir, prefix);
+   snprintf(dir_path, FILENAME, "cd %s && echo %s* 2>/dev/null", dir, 
prefix);
 else
-   sprintf(dir_path, "cd %s && ls 2>/dev/null", dir);
+   snprintf(dir_path, FILENAME, "cd %s && ls 2>/dev/null", dir);
 prefix_lgt = strlen(prefix);
 
 if ((dirf = popen(dir_path, "r")) == NULL)
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason



Bug#976340: jellyfish: Fails to build on some architectures

2021-02-28 Thread Adrian Bunk
Control: reopen -1
Control: tags -1 ftbfs
Control: retitle -1 jellyfish FTBFS with -I in builddir

On Thu, Dec 03, 2020 at 05:06:00PM +0100, Andreas Tille wrote:
> Package: jellyfish
> Version: 2.3.0-7
> Severity: important
> 
> Hi,
> 
> jellyfish does not build on some architectures ( mips64el [1], mipsel,
> ppc64el and s390x ):
> 
> mips64el-linux-gnuabi64-gcc -pthread -Wno-unused-result -Wsign-compare 
> -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat 
> -Werror=format-security -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -fPIC 
> -I/build/jellyfishwEbe4/jellyfish-2.3.0/debian/tmp//usr/include/jellyfish-2.3.0
>  -I/usr/include/python3.8 -c swig_wrap.cpp -o 
> build/temp.linux-mips64el-3.8/swig_wrap.o -std=c++0x
> swig_wrap.cpp:2826:10: fatal error: jellyfish/mer_dna.hpp: No such file or 
> directory
>  2826 | #include 
>   |  ^~~
> compilation terminated.
> error: command 'mips64el-linux-gnuabi64-gcc' failed with exit status 1
> E: pybuild pybuild:353: build: plugin distutils failed with: exit code=1: 
> /usr/bin/python3.8 setup.py build build_ext -L/<>/.libs
> I: pybuild base:232: /usr/bin/python3 setup.py build build_ext 
> -L/<>/.libs
> running build
> running build_py
> copying dna_jellyfish.py -> 
> /<>/.pybuild/cpython3_3.9_dna_jellyfish/build
> running build_ext
> building '_dna_jellyfish' extension
> creating build/temp.linux-mips64el-3.9
> mips64el-linux-gnuabi64-gcc -pthread -Wno-unused-result -Wsign-compare 
> -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat 
> -Werror=format-security -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -fPIC 
> -I/build/jellyfishwEbe4/jellyfish-2.3.0/debian/tmp//usr/include/jellyfish-2.3.0
>  -I/usr/include/python3.9 -c swig_wrap.cpp -o 
> build/temp.linux-mips64el-3.9/swig_wrap.o -std=c++0x
> swig_wrap.cpp:2826:10: fatal error: jellyfish/mer_dna.hpp: No such file or 
> directory
>  2826 | #include 
>   |  ^~~
> compilation terminated.
> error: command '/usr/bin/mips64el-linux-gnuabi64-gcc' failed with exit code 1
> 
> 
> Any idea what might be wrong here?

I: NOTICE: Log filtering will replace 'build/jellyfish-IwEbe4/jellyfish-2.3.0' 
with '<>'
I: NOTICE: Log filtering will replace 'build/jellyfish-IwEbe4' with 
'<>'

Compare with 
-I/build/jellyfishwEbe4/jellyfish-2.3.0/debian/tmp//usr/include/jellyfish-2.3.0

jellyfish-IwEbe4 -> jellyfishwEbe4

This looks like a variant of the -L problem handled with
debian/patches/fix_replacement_of_-L_option.patch


> Kind regards
> 
>  Andreas.
>...

cu
Adrian



Bug#983721: chirp is outdated

2021-02-28 Thread tony mancill
On Sun, Feb 28, 2021 at 10:38:03PM +0100, gpe wrote:
> Le dimanche 28 février 2021 à 21:10 +0100, Christoph Berg a écrit :
> > Control: retitle -1 chirp's python3 support is incomplete
> > 
> > Re: gpe92
> > > chirp in debian is outdaded. Thanks to update to current version
> > > (2021/02/12).
> > 
> > Hi,
> > 
> > the problem is that upstream isn't providing a version that works with
> > Python 3 yet. (And we cannot revert to Python 2 because the Gtk module
> > has already been removed.)
> > 
> > Christoph DF7CB
> 
> Many applications have not moved to python 3. So removing python 2 support
> isn't a good choice in my opinion.

Hi gpe,

Continuing to use Python 2 without any security support is also not a
good choice.  We will not be revisiting the Debian transition [1] for
this package, so if you are keen to have the latest chirp available in
the latest version Debian, you can help by working with upstream on the
Python 3 support [2,3,4].

Of course you are free to compile chirp for yourself locally and run it
with any Python interpreter you like.

Cheers,
tony KG7IEL

[1] https://wiki.debian.org/Python/2Removal
[2] https://chirp.danplanet.com/issues/495
[3] https://chirp.danplanet.com/issues/6327
[4] https://chirp.danplanet.com/issues/7431



Bug#983365: Info received (Bug#983365: linphone-desktop: chat messages)

2021-02-28 Thread Bernhard Schmidt
Hi,

an updated liblinphone has been uploaded to sid yesterday. Could you
please try liblinphone10 and liblinphone++10 from sid (4.4.21-2) and
report back? If it does not work you might need libsoci-core4.0 and
libsoci-sqlite3-4.0 from unstable as well (4.0.1-4).

Thanks,
Bernhard



Bug#983729: nagios-plugins-contrib: Please consider adding monitoring-plugins-systemd as a Recommended package

2021-02-28 Thread Louis-Philippe Véronneau
Package: src:nagios-plugins-contrib
Version: 31.20210225
Severity: wishlist

Dear maintainers,

I've packaged a `check_systemd` script in the monitoring-plugins-systemd
package and it has just passed NEW.

Would it be possible to add it as a `Recommends` in this package? This
way, most people installing the monitoring-plugins-contrib package would
also install a systemd check.

Cheers, and thanks for maintaining this package!

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



OpenPGP_signature
Description: OpenPGP digital signature


Bug#983728: h2o: reduce Build-Depends

2021-02-28 Thread Helmut Grohne
Source: h2o
Version: 2.2.5+dfsg2-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

h2o cannot be cross built from source, because it has unsatisfiable
Build-Depends. Instead of looking into such a difficult problem, I
looked for easily droppable dependencies. ruby-dev seems entirely unused
as h2o uses an embedded mruby to link with rather than the system ruby.
Other than that, a lot of dependencies are only used for testing and can
be annotated . Please consider applying the attached patch
that contains the full list of nocheck-annotatable dependencies.

Helmut
diff --minimal -Nru h2o-2.2.5+dfsg2/debian/changelog 
h2o-2.2.5+dfsg2/debian/changelog
--- h2o-2.2.5+dfsg2/debian/changelog2020-12-16 21:06:10.0 +0100
+++ h2o-2.2.5+dfsg2/debian/changelog2021-02-28 22:35:18.0 +0100
@@ -1,3 +1,12 @@
+h2o (2.2.5+dfsg2-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Drop unused ruby-dev.
++ Annotate test dependencies .
+
+ -- Helmut Grohne   Sun, 28 Feb 2021 22:35:18 +0100
+
 h2o (2.2.5+dfsg2-6) unstable; urgency=medium
 
   * [945c43b] Add gitlab-ci.yml
diff --minimal -Nru h2o-2.2.5+dfsg2/debian/control 
h2o-2.2.5+dfsg2/debian/control
--- h2o-2.2.5+dfsg2/debian/control  2020-05-03 22:12:52.0 +0200
+++ h2o-2.2.5+dfsg2/debian/control  2021-02-28 22:35:17.0 +0100
@@ -6,24 +6,23 @@
 Rules-Requires-Root: no
 Build-Depends: bison,
cmake,
-   curl,
+   curl ,
debhelper-compat (= 12),
-   libio-socket-ssl-perl,
-   libjson-perl,
-   libpath-tiny-perl,
-   libscope-guard-perl,
+   libio-socket-ssl-perl ,
+   libjson-perl ,
+   libpath-tiny-perl ,
+   libscope-guard-perl ,
libssl-dev,
-   libtest-exception-perl,
+   libtest-exception-perl ,
libuv1-dev,
libwslay-dev,
libyaml-dev,
-   netcat-openbsd,
-   nghttp2-client,
+   netcat-openbsd ,
+   nghttp2-client ,
pkg-config,
-   ruby-dev,
ruby,
-   starlet,
-   wget,
+   starlet ,
+   wget ,
zlib1g-dev
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/debian/h2o


Bug#983722: [Pkg-openssl-devel] Bug#983722: libssl1.1: drop upgrade support from old-old-old-stable from maintainer script

2021-02-28 Thread Kurt Roeckx
On Sun, Feb 28, 2021 at 10:00:35PM +0100, Helmut Grohne wrote:
> Hi Kurt,
> 
> On Sun, Feb 28, 2021 at 09:48:04PM +0100, Kurt Roeckx wrote:
> > I think you at least misunderstand the purpose of the script, but
> > we've also not used it in a very long time.
> 
> I think I do understand the purpose, but it does not presently serve the
> stated purpose. Given that the checked version is so ancient, it is
> effectively dead code.

To activate it, the version in the postinst gets updated. But like
I said, it's not been activated in a long time, so maybe it is
dead code.

> > It's meant to restart all services that make use of openssl when a
> > security update is released. I guess I switched to "checkrestart"
> > myself, so never had the need to use it myself anymore.
> 
> That or needrestart. I don't think that the general expectation these
> days is that upgrading a library restarts affected services. Exceptions
> to this rule include nss (libc6) and pam updates as failing to restart
> services can result in them becoming dysfunctional. For most other
> cases, an external checker is the recommended best practice.

I'm not sure users are aware that they need to restart the
services (or reboot) to fix the security issues. We still lack a
way to indicate that to the user. I would really like to see
a general fix for this.

> Unless you wish to reactivate this code with a current version, I think
> it should be deleted. If you do, please close this bug with a wontfix
> tag.

I guess you mean "If you don't".

Anyway, the template code and translations can all be deleted
too if that patch is applied.


Kurt



Bug#983721: chirp is outdated

2021-02-28 Thread gpe
Le dimanche 28 février 2021 à 21:10 +0100, Christoph Berg a écrit :
> Control: retitle -1 chirp's python3 support is incomplete
> 
> Re: gpe92
> > chirp in debian is outdaded. Thanks to update to current version
> > (2021/02/12).
> 
> Hi,
> 
> the problem is that upstream isn't providing a version that works with
> Python 3 yet. (And we cannot revert to Python 2 because the Gtk module
> has already been removed.)
> 
> Christoph DF7CB

Many applications have not moved to python 3. So removing python 2 support
isn't a good choice in my opinion.

gpe



Bug#983657: debian-policy: weaken manual page requirement

2021-02-28 Thread Bill Allombert
On Sun, Feb 28, 2021 at 08:58:44PM +0100, Helmut Grohne wrote:
> On Sun, Feb 28, 2021 at 10:53:20AM -0700, Sean Whitton wrote:
> > Can you post a patch just doing the moving manpages to dependencies part
> > and indicate that you are seeking seconds?  Then we can get that
> > applied.
> 
> I call for seconds on:
> 
> --- a/policy/ch-docs.rst
> +++ b/policy/ch-docs.rst
> @@ -12,9 +12,9 @@
>  "cat page".
>  
>  Each program, utility, and function should have an associated manual
> -page included in the same package. It is suggested that all
> -configuration files also have a manual page included as well. Manual
> -pages for protocols and other auxiliary things are optional.
> +page included in the same package or a dependency. It is suggested that
> +all configuration files also have a manual page included as well.
> +Manual pages for protocols and other auxiliary things are optional.
>  
>  If no manual page is available, this is considered as a bug and should
>  be reported to the Debian Bug Tracking System (the maintainer of the

What matter, I think, is that if a program is installed, then its manual
is available. There are various ways to achieve that, even though I do
not think Recommends cut it.

Cheers,
Bill



Bug#983726: runsv(8) incorrect regarding control/[dx]

2021-02-28 Thread Andras Korn
Package: runit
Version: 2.1.2-39.1
Severity: normal
Tags: upstream

Hi,

runsv(8) says:

CUSTOMIZE CONTROL
   For each control character c sent to the control pipe, runsv first
   checks if service/control/c exists and is executable. If so, it
   starts service/control/c and waits for it to terminate, before
   interpreting the command. If the program exits with return code 0,
   runsv refrains from sending the service the corresponding signal. The
   command o is always considered as command u. On command d first
   service/control/t is checked, and then service/control/d. On command
   x first service/control/t is checked, and then service/control/x. The
   control of the optional log service cannot be customized.

This is, however, not what the code actually does.

For the 'd' control character 
(https://github.com/vulk-archive/runit/blob/master/src/runsv.c#L324):

  case 'd': /* down */
s->want =W_DOWN;
update_status(s);
if (s->state == S_RUN) stopservice(s);
break;

'x' is handled analogously.

The stopservice() function 
(https://github.com/vulk-archive/runit/blob/master/src/runsv.c#L246) looks like 
this:

void stopservice(struct svdir *s) {
  if (s->pid && ! custom(s, 't')) {
kill(s->pid, SIGTERM);
s->ctrl |=C_TERM;
update_status(s);
  }
  if (s->want == W_DOWN) {
kill(s->pid, SIGCONT);
custom(s, 'd'); return;
  }
  if (s->want == W_EXIT) {
kill(s->pid, SIGCONT);
custom(s, 'x');
  }
}

i.e. the control/d or control/x script is only run after runsv sent its child a 
SIGTERM, not before as the manpage suggests.

I would suggest that the code should be changed to reflect the documented 
behaviour, not vice versa. Perhaps the following code would work (but I have 
not tested it):

void stopservice(struct svdir *s) {
  if (s->pid) {
if (s->want == W_DOWN) {
  kill(s->pid, SIGCONT);
  if (custom(s, 'd')) return;
}
if (s->want == W_EXIT) {
  kill(s->pid, SIGCONT);
  if (custom(s, 'x')) return;
}
if (! custom(s, 't')) {
  kill(s->pid, SIGTERM);
  s->ctrl |=C_TERM;
  update_status(s);
}
  }
}

Credits to https://serverfault.com/users/135556/keith for pointing the bug out.

Best regards,

András

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages runit depends on:
ii  libc6   2.31-9
ii  sysuser-helper  1.3.5.1

Versions of packages runit recommends:
ii  runit-init  2.1.2-39.1

Versions of packages runit suggests:
ii  socklog  2.1.0+repack-4+b1

-- Configuration Files:
/etc/runit/1 changed [not included]
/etc/runit/2 changed [not included]
/etc/runit/3 changed [not included]

-- no debconf information

-- 
Laughing stock: cattle with a sense of humour.



Bug#983727: thinkfan should not ship an example in /etc/thinkfan.yaml

2021-02-28 Thread David Prévot
Package: thinkfan
Version: 1.2.1-3
Severity: serious

The “thinkfan Example Config File” currently shipped as
/etc/thinkfan.yaml “is NOT a working config file that can just be
copied” (quotes from the file itself).

Pretending that “The new default configuration might not work for your
system” in NEWS.Debian implies that it could work in some cases, but
that does not seem to be the case at all.

By installing /etc/thinkfan.yaml on systems with a working configuration
in /etc/thinkfan.conf, the daemon simply fails to start (while simply
removing the new /etc/thinkfan.yaml allow one to start it again).

Please, ship the “thinkfan Example Config File” in
/usr/share/doc/thinkfan/examples in order to not break existing
configuration, especially since it can’t work as is anyway.

Regards

David


signature.asc
Description: PGP signature


Bug#983725: admin.c: use "snprintf()" instead of "sprintf" and add an argument to "db_data_path()"

2021-02-28 Thread Bjarni Ingi Gislason
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 903dc0dd6cfcf9aaba6750cc8e6e12a2ec24ce01 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 28 Feb 2021 21:18:29 +
>Subject: [PATCH] admin.c: use "snprintf()" instead of "sprintf" and add an
> argument to "db_data_path()"

  Define a variable for the size of arrays.

  Use "snprintf()" instead of "sprintf()".

  Add an argument to "db_data_path()".

Signed-off-by: Bjarni Ingi Gislason 
---
 admin.c | 41 +
 1 file changed, 25 insertions(+), 16 deletions(-)

diff --git a/admin.c b/admin.c
index bb33404..421aee1 100644
--- a/admin.c
+++ b/admin.c
@@ -127,12 +127,14 @@ loop:
 static int
 admin_confirm(char *action, int must_confirm)
 {
-charbuffer[100];
+size_t  nbuffer = 100;
+charbuffer[nbuffer];
+
 
 if (pre_input && !must_confirm)
return 1;
 
-sprintf(buffer, "Confirm %s  Y)es N)o", action);
+snprintf(buffer, nbuffer, "Confirm %s  Y)es N)o", action);
 
 return get_cmd((char *) NULL, buffer) == 'Y';
 }
@@ -199,7 +201,9 @@ update_master(void)
 static void
 find_files(group_header * gh)
 {
-charcommand[512], name[FILENAME];
+size_t  ncommand = 512;
+charcommand[ncommand], name[FILENAME];
+
 
 if (gh == NULL) {
if (db_data_directory == NULL) {
@@ -207,14 +211,14 @@ find_files(group_header * gh)
return;
}
if (db_data_subdirs) {
-   sprintf(command, "cd %s ; ls -l [0-9] | %s", db_data_directory, 
pager);
+   snprintf(command, ncommand, "cd %s ; ls -l [0-9] | %s", 
db_data_directory, pager);
}
else {
-   sprintf(command, "ls -l %s | %s", db_data_directory, pager);
+   snprintf(command, ncommand, "ls -l %s | %s", db_data_directory, 
pager);
}
 }
 else {
-   sprintf(command, "ls -l %s", db_data_path(name, gh, '*'));
+   snprintf(command, ncommand, "ls -l %s", db_data_path(name, FILENAME, 
gh, '*'));
 }
 
 system(command);
@@ -743,7 +747,9 @@ master_admin(void)
 static void
 log_admin(void)
 {
-charcommand[FILENAME + 100], c;
+size_t  ncommand = FILENAME + 100;
+charcommand[ncommand], c;
+
 
 if (pre_input && *pre_input == NUL) {
c = SP;
@@ -760,7 +766,7 @@ loop:
 
 if (c == '@') {
if (admin_confirm("Truncation", 0)) {
-   sprintf(command, "%s.old", log_file);
+   snprintf(command, ncommand, "%s.old", log_file);
unlink(command);
if (link(log_file, command) < 0)
goto tr_failed;
@@ -782,7 +788,7 @@ tr_failed:
 
if ((groupname = get_groupname()) == NULL)
goto loop;
-   sprintf(command, "fgrep '%s' %s | %s",
+   snprintf(command, ncommand, "fgrep '%s' %s | %s",
groupname, log_file, pager);
system(command);
 
@@ -793,14 +799,14 @@ log_tail:
int n;
 
n = isdigit(c) ? 10 * (c - '0') : 10;
-   sprintf(command, "tail -%d %s", n, log_file);
+   snprintf(command, ncommand, "tail -%d %s", n, log_file);
system(command);
goto loop;
 }
 if (c == '*') {
c = '.';
 }
-sprintf(command, "grep '^%c:' %s | %s", c, log_file, pager);
+snprintf(command, ncommand, "grep '^%c:' %s | %s", c, log_file, pager);
 system(command);
 
 goto loop;
@@ -810,14 +816,15 @@ log_tail:
 static void
 flag_admin(group_header * gh, char *mode_str, int set_flag)
 {
-charbuffer[50];
+size_t  nbuffer = 50;
+charbuffer[nbuffer];
 int new_flag = 0;
 
 tputc(NL);
 
 dump_g_flag(gh);
 
-sprintf(buffer, "%s FLAG", mode_str);
+snprintf(buffer, nbuffer, "%s FLAG", mode_str);
 
 switch (get_cmd(
  "\nA)lways_digest N)ever_digest M)oderated C)ontrol no_(D)ir",
@@ -878,7 +885,9 @@ flag_admin(group_header * gh, char *mode_str, int set_flag)
 static void
 rmgroup(group_header * gh)
 {
-charcommand[FILENAME * 2];
+size_t  ncommand = FILENAME * 2;
+charcommand[ncommand];
+
 char   *rmprog;
 
 if (user_id != 0 && !file_exist(news_active, "w")) {
@@ -906,7 +915,7 @@ rmgroup(group_header * gh)
 tprintf("Program %s not found\n", rmprog);
 return;
 rm_ok:
-sprintf(command, "%s %s", rmprog, gh->group_name);
+snprintf(command, ncommand, "%s %s", rmprog, gh->group_name);
 system(command);
 any_key(0);
 gh->master_flag &= ~M_VALID;/* just for nnadmin */
@@ -934,7 +943,7 @@ have_group:
dirbuf[strlen(dirbuf) - 1] = NUL;
exec_chdir_to = dirbuf;
 }
-sprintf(gbuf, "GROUP %s", gh->group_name);
+snprintf(gbuf, FILENAME, "GROUP %s", gh->group_name);
 
 for (;;) {
switch (get_cmd(
-- 
2.30.1



-- System Information:
Debian Release: bullseye/sid
  APT p

Bug#983657: debian-policy: weaken manual page requirement

2021-02-28 Thread Sean Whitton
control: tag -1 + pending

Hello,

On Sun 28 Feb 2021 at 08:58PM +01, Helmut Grohne wrote:

> I call for seconds on:
>
> --- a/policy/ch-docs.rst
> +++ b/policy/ch-docs.rst
> @@ -12,9 +12,9 @@
>  "cat page".
>
>  Each program, utility, and function should have an associated manual
> -page included in the same package. It is suggested that all
> -configuration files also have a manual page included as well. Manual
> -pages for protocols and other auxiliary things are optional.
> +page included in the same package or a dependency. It is suggested that
> +all configuration files also have a manual page included as well.
> +Manual pages for protocols and other auxiliary things are optional.
>
>  If no manual page is available, this is considered as a bug and should
>  be reported to the Debian Bug Tracking System (the maintainer of the

Seconded, and I'll mark this bug as pending; if discussion on your other
issue gets to the point where wording is proposed, please clone this
bug.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#982984: Mirror blocked due to repeated errors

2021-02-28 Thread Sven Geuer
Hello Eduard,

I am afraid this bug needs to be reopened.

I just discovered that even apt-cacher-ns 3.6.1-1 still results in

   502 Mirror blocked due to repeated errors [IP: ::1 3142]

on my machine when doing for instance an 'apt update'. The root cause
seems to be a too early access to network functions. 

After booting up the machine apt-cacher-ng has logged

   Feb 28 21:57:54 e580sg apt-cacher-ng[896]: [msg] Nameserver 127.0.0.1:53 has 
failed: request timed out.
   Feb 28 21:57:54 e580sg apt-cacher-ng[896]: [msg] All nameservers have failed
   
to syslog although this nameserver is not configured anywhere. It seems
to me apt-cacher-ng reads a /etc/resolv.conf not yet populated by
NetworkManager (my machine, a laptop, runs with wifi only, so it may
take some time to establish the network connection and learn the
nameserver from DHCP).

Restarting apt-cacher-ng per

   systemctl restart apt-cacher-ng

temporarily fixes the issue which shows up again after the next boot cycle.

I also believe apt-cacher-ng should not rely on a nameserver
configuration detected during start-up as /etc/resolv.conf may change
any time, be it for manual re-configuration or for NetworkManager
updating resolv.conf dynamically.

Sven
 
-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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


Bug#982454: lvm2: vgremove segfaults in libc-2.24.so

2021-02-28 Thread Bernhard Übelacker

Dear Maintainer,
I tried to reproduce the issue and got a segfault [2]
when trying to vgremove inside a i386 qemu VM
with version lvm2 2.02.168-2.
Attached file contains the steps taken.

This upstream commit sounds related. [1]

Kind regards,
Bernhard


[1] lvmetad: fix segfault on i386

https://sourceware.org/git/?p=lvm2.git;a=commit;h=46b735c937ce68e72d08997635321bf30240325d

https://sourceware.org/git/?p=lvm2.git;a=patch;h=46b735c937ce68e72d08997635321bf30240325d


[2]
(gdb) bt
#0  __strchr_sse2_bsf () at 
../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S:97
#1  0x0050b29f in config_make_nodes_v (cft=0x64fae0, parent=0x0, pre_sib=0x64fd48, 
ap=0xb92c "\365\nP") at config-util.c:248
#2  0x0050c5f7 in daemon_request_extend_v (r=..., ap=0xb90c 
"\354\224U") at daemon-client.c:218
#3  0x004fe622 in _lvmetad_send (cmd=0x606840, id=) at 
cache/lvmetad.c:435
#4  0x00500b6c in lvmetad_vg_remove_pending (vg=0x66aa28) at 
cache/lvmetad.c:1304
#5  0x004b366c in vg_remove_direct (vg=0x66aa28) at metadata/metadata.c:571
#6  0x004b3d3c in vg_remove (vg=0x66aa28) at metadata/metadata.c:634
#7  0x00455815 in vgremove_single (cmd=0x606840, vg_name=0x648978 "raid1", 
vg=0x66aa28, handle=0x648980) at vgremove.c:79
#8  0x004488b1 in _process_vgnameid_list (process_single_vg=0x455660 
, handle=0x648980, arg_tags=0xbb10, 
arg_vgnames=0xbb18, vgnameids_to_process=0xbb28, read_flags=1048576, 
cmd=0x606840) at toollib.c:1964
#9  process_each_vg (cmd=, argc=, argv=, 
one_vgname=, use_vgnames=, read_flags=1048576, include_internal=, handle=0x648980, process_single_vg=) at toollib.c:2277
#10 0x00455949 in vgremove (cmd=, argc=, 
argv=) at vgremove.c:112
#11 0x004337ee in lvm_run_command (cmd=, argc=, 
argv=) at lvmcmdline.c:1723
#12 0x0043455d in lvm2_main (argc=2, argv=0xbdf4) at lvmcmdline.c:2249
#13 0x0041a537 in main (argc=2, argv=0xbdf4) at lvm.c:22

# Stretch/oldstable i386 qemu VM 2021-02-28


apt update
apt dist-upgrade

apt install gdb lvm2 lvm2-dbgsym
apt build-dep lvm2




mkdir /home/benutzer/source/lvm2/orig -p
cd/home/benutzer/source/lvm2/orig
apt source lvm2
cd






dd if=/dev/zero of=test0 bs=100M count=1
dd if=/dev/zero of=test1 bs=100M count=1

losetup loop0 test0
losetup loop1 test1

pvcreate /dev/loop0
pvcreate /dev/loop1

pvdisplay


mkdir /dev/testvg
mknod /dev/testvg/group c 128 0x
vgcreate raid1 /dev/loop0 /dev/loop1
vgremove raid1




root@debian:~# vgremove raid1
Speicherzugriffsfehler

root@debian:~# gdb -q --args vgremove raid1
Reading symbols from vgremove...(no debugging symbols found)...done.
(gdb) run
Starting program: /sbin/vgremove raid1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__strchr_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S:97
97  ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S: Datei oder 
Verzeichnis nicht gefunden.
(gdb) bt
#0  __strchr_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S:97
#1  0x0050b29f in config_make_nodes_v ()
#2  0x0050c5f7 in daemon_request_extend_v ()
#3  0x004fe622 in ?? ()
#4  0x00500b6c in lvmetad_vg_remove_pending ()
#5  0x004b366c in vg_remove_direct ()
#6  0x004b3d3c in vg_remove ()
#7  0x00455815 in ?? ()
#8  0x004488b1 in process_each_vg ()
#9  0x00455949 in vgremove ()
#10 0x004337ee in lvm_run_command ()
#11 0x0043455d in lvm2_main ()
#12 0x0041a537 in main ()







root@debian:~# gdb -q --args vgremove raid1
Reading symbols from vgremove...Reading symbols from 
/usr/lib/debug/.build-id/e2/859cb481b1f0a843f9d2667c790dba3f2fc901.debug...done.
done.
(gdb) run
Starting program: /sbin/vgremove raid1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__strchr_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S:97
97  ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S: Datei oder 
Verzeichnis nicht gefunden.
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /home/benutzer/source/lvm2/orig/lvm2-2.02.168/libdaemon/client
Source directories searched: 
/home/benutzer/source/lvm2/orig/lvm2-2.02.168/libdaemon/client:$cdir:$cwd
(gdb) directory /home/benutzer/source/lvm2/orig/lvm2-2.02.168/lib
(gdb) bt
#0  __strchr_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S:97
#1  0x0050b29f in config_make_nodes_v (cft=0x64fae0, parent=0x0, 
pre_sib=0x64fd48, ap=0xb92c "\365\nP") at config-util.c:248
#2  0x0050c5f7 in daemon_request_extend_v (r=..., ap=0xb90c "\354\224U") at 
daemon-client.c:218
#3  0x004fe622 in _lvmetad_send (cmd=0x606840, id=) at 
cache/lvmetad.c:435
#4  0x00500b6c in lvmetad_vg_remove_pending (vg=0x66aa28) at 
cache/lvmetad.c:1304
#5  0x004b366c in vg_remove_direct (vg=0x66aa28) at metadata/metadata.c:571
#6  0x004b3d3c in 

Bug#983703: RFS: logrotate/3.18.0-2 -- Log rotation utility

2021-02-28 Thread Christian Göttsche
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: logrotate
   Version : 3.18.0-2
   Upstream Author : https://github.com/logrotate/logrotate/issues
 * URL : https://github.com/logrotate/logrotate
 * License : GPL-3+, GPL-2, BSD-3-Clause
 * Vcs : https://salsa.debian.org/debian/logrotate
   Section : admin

It builds those binary packages:

  logrotate - Log rotation utility

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/l/logrotate/logrotate_3.18.0-2.dsc

Changes since the last upload:

 logrotate (3.18.0-2) unstable; urgency=medium
 .
   * d/patches: cherry-pick relevant commits for Bullseye
 - improve support for running as unprivileged user
   + Open files we want to compress as read-only.
   + Only attempt to set user/group if running as root.
 - documentation updates
   + logrotate.8: make the /var/log/news example consistent
   + Fix a typo in the example logrotate.conf
   * debian: refactor usage of configuration file
 No actual changes in default configuration.


I did perform a content comparison of the buster package with this new
one to ensure no settings are actually changed and no upgrade issues,
similar to #928516, occur.

Regards,
Christian Göttsche



Bug#983724: openboard: FTBFS with new poppler (experimental) [PATCH]

2021-02-28 Thread Gianfranco Costamagna
Source: openboard
Version: 1.5.4+dfsg1-2
Severity: important
tags: patch

Hello, new poppler removed the splash pkgconfig file, so now the package FTBFS 
without it.

The following patch seems to make it build correctly

--- openboard-1.5.4+dfsg1/debian/patches/new-poppler-build-fix.patch
1970-01-01 00:00:00.0 +
+++ openboard-1.5.4+dfsg1/debian/patches/new-poppler-build-fix.patch
2021-02-28 15:42:52.0 +
@@ -0,0 +1,15 @@
+Description: Fix build with new poppler without splash anymore
+Author: Gianfranco Costamagna 
+Last-Update: 2021-02-28
+
+--- openboard-1.5.4+dfsg1.orig/libs.pri
 openboard-1.5.4+dfsg1/libs.pri
+@@ -3,7 +3,7 @@ THIRD_PARTY_PATH="../OpenBoard-ThirdPart
+ linux {
+ CONFIG += link_pkgconfig
+ PKGCONFIG += poppler
+-PKGCONFIG += poppler-splash
++# PKGCONFIG += poppler-splash
+ PKGCONFIG += freetype2
+ 
+ # Find different versions of quazip
diff -Nru openboard-1.5.4+dfsg1/debian/patches/series 
openboard-1.5.4+dfsg1/debian/patches/series
--- openboard-1.5.4+dfsg1/debian/patches/series 2020-12-19 12:57:11.0 
+
+++ openboard-1.5.4+dfsg1/debian/patches/series 2021-02-28 15:42:36.0 
+
@@ -15,3 +15,4 @@
 1008_fix-bashism-in-podcast-pri.patch
 2009_no-or-updated-font-credits.patch
 1009_various-typo-fixes.patch
+new-poppler-build-fix.patch

Please apply it an consider upstreaming it if possible.
Note: I didn't check if the patch works also for the current poppler in sid or 
not (but I guess it works)

Gianfranco



Bug#983722: [Pkg-openssl-devel] Bug#983722: libssl1.1: drop upgrade support from old-old-old-stable from maintainer script

2021-02-28 Thread Helmut Grohne
Hi Kurt,

On Sun, Feb 28, 2021 at 09:48:04PM +0100, Kurt Roeckx wrote:
> I think you at least misunderstand the purpose of the script, but
> we've also not used it in a very long time.

I think I do understand the purpose, but it does not presently serve the
stated purpose. Given that the checked version is so ancient, it is
effectively dead code.

> It's meant to restart all services that make use of openssl when a
> security update is released. I guess I switched to "checkrestart"
> myself, so never had the need to use it myself anymore.

That or needrestart. I don't think that the general expectation these
days is that upgrading a library restarts affected services. Exceptions
to this rule include nss (libc6) and pam updates as failing to restart
services can result in them becoming dysfunctional. For most other
cases, an external checker is the recommended best practice.

Unless you wish to reactivate this code with a current version, I think
it should be deleted. If you do, please close this bug with a wontfix
tag.

Helmut



Bug#973474: gnome: Unable to log back in in after screen lock

2021-02-28 Thread Marcin Owsiany
Just a quick note because I think I have a lead, but won't be able to go
through all your suggestions today.

First of all, I'm also unable to reproduce the issue if I go straight to
logging into the Gnome session after booting my VM.

However I am able to reproduce it if I first log into and log out of a few
other session types.
I'm still trying to figure out the minimal set which triggers the issue
consistently, but so far I can see the issue if I:
- boot the VM
- log into LXDE session and log out
- log into Cinnamon session and log out
- log into "System X11 default" session which I think is LXQT in this case,
and log out
- log into Gnome session
- lock the screen through the menu in upper right-hand corner
- try to unlock

FWIW, the message which "journalctl -f" shows (in an ssh session running in
parallel) when I enter the unlock password is:

lut 28 21:48:52 debian gdm-password][38277]: gkr-pam: unlocked login keyring

A few replies to some of your points below, I'll keep digging whenever I
have some free time in the coming week.

sob., 27 lut 2021 o 22:28 Simon McVittie  napisał(a):

> On Sat, 27 Feb 2021 at 19:21:46 +0100, Marcin Owsiany wrote:
> > Regarding the messages I see in syslog, see the screenshot I had
> attached to my
> > previous message.
>
> On a freshly-installed, up to date test VM, you should find that the gdm
> login screen has a grey background, but the gnome-shell lock screen has a
> dark blue background (it's a blurred version of your desktop background,
> for which the default in Debian 11 is going to be dark blue).


Right, I'm pretty sure the weird behaviour is in the lock screen, not the
gdm login screen.


> It would
> be useful if you could describe the steps you use to reproduce this bug,
> and at each step that involves a login screen, say whether the background
> is grey or blue.
>
> Here is a sequence of screenshots illustrating my
> attempt to reproduce this, together with my system log:
>  (and then after pressing Enter
> for my test user's password, I'm back to my unlocked session, equivalent
> to ). At what point does
> what you see diverge from that?
>
> I'm surprised you see messages from Xorg: those should only appear when
> you start a completely new session, not when you just lock and unlock
> the screen. This suggests that maybe the session is crashing, and instead
> of the gnome-shell lock screen on tty7, you are going back to the gdm
> login screen on tty1.
>

As far as I can tell it's not crashing. Could they have been triggered by
switching between virtual consoles?
Going forward I'll try to use a parallel SSH login rather than messing
around with CTRL+ALT+Fx to keep things simpler.


> Given that you see messages from Xorg, I would also expect to see more
> messages than just those. Before locking the screen, please run
>
> logger "before locking"
>
> to leave a marker in the system log; and then please look back through
> the system log at least as far as that marker.
>
> If you look at the systemd journal (as root) instead of syslog, you'll
> also see "auth" messages, which could be relevant: for instance, when
> you enter a wrong password, that should be logged as an "auth" message
> from PAM.
>
> Please describe the steps you took to install your test VM, including
> any non-default settings used? For example, I wonder whether this is
> locale-sensitive - I'm using en_GB.UTF-8 but you seem to be using a
> non-English locale.
>
> If your test VM does not contain any personal or confidential data,
> and you can can transfer files off it with ssh, a shared filesystem or
> paste.debian.net, it would be useful to see the entire systemd journal
> (starting from boot) for this procedure:
>
> - boot the VM
> - log in as a user
> - lock the screen
> - unlock with a correct password
>
> and compare it with
> .
>
> Or if your test VM contains personal/confidential things, please could
> you try to set up a similar VM without those and reproduce the bug there?
>
> > Is there perhaps some setting I could tweak to convince gnome-shell to
> produce
> > some debug output when I attempt unlocking?
>
> Try these:
>
> systemctl --user edit gnome-shell@x11.service
> systemctl --user edit gnome-shell@wayland.service
> sudo systemctl edit gdm.service
>
> and in each case, add this:
>
> [Service]
> Environment=G_MESSAGES_DEBUG=all
>
> Thanks,
> smcv
>


Bug#983653: task-japanese-gnome-desktop: no Japanese input method available out of the box

2021-02-28 Thread Nobuhiro Iwamatsu
Hi,

2021年2月28日(日) 13:12 YOSHINO Yoshihito :
>
> Package: task-japanese-gnome-desktop
> Version: 3.64
> Severity: grave
> Tags: bullseye l10n patch
> Justification: renders package unusable
> X-Debbugs-Cc: debian-japan...@lists.debian.org
>
> Dear Maintainer,
>
> On a fresh bullseye installation of Japanese GNOME desktop,
> its user cannot type Japanese text out of the box.
>
> A fresh buster installation of Japanese GNOME desktop
> dist-upgraded to bullseye is also affected.
>
> Note that a fresh buster installation of Japanese GNOME desktop itself
> is not affected.
>
> This is caused by the change in the gnome-shell package (Bug#815050) to add
> "Recommends: ibus", which breaks any non-ibus input method framework
> (Bug#941624),
> especially uim (mainly used by Japanese users) and fcitx (mainly used
> by Chinese users),
> while reverting the change is perhaps not feasible to western language
> users for emoji support.
>
> Adding some Japanese input method to the ibus framework should work
> around the problem
> for Japanese users. Specifically, adding Recommends: ibus-mozc (or ibus-anthy 
> on
> architectures where mozc is not available) to this package should work
> around the problem.
> The attached patch should apply the work-around.

This patch seems to work for this issue.
I have confirmed that ibus-mozc is installed in the GNOME environment by
installing the tasksel/task-japanese-gnome-desktop packages with this patch
applied.

Holger, could you apply this patch and upload for bullseye?
Or can I upload as team upload?

Best regards,
  Nobuhiro
>
> Thanks in advance,
> --
> YOSHINO Yoshihito 
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-3-amd64 (SMP w/1 CPU thread)
> Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages task-japanese-gnome-desktop depends on:
> ii  tasksel  3.64
>
> Versions of packages task-japanese-gnome-desktop recommends:
> ii  thunderbird  1:78.7.1-1
> ii  thunderbird-l10n-ja  1:78.7.1-1
>
> task-japanese-gnome-desktop suggests no packages.
>
> -- no debconf information



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6



Bug#983702: voltron: Update package with new upstream release

2021-02-28 Thread Thomas Nyberg
Package: voltron
Version: 0.1.7+git20200109-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Trying to use the packaged voltron version with the current debian testing does
not work. Trying to use e.g.

`import voltron`

or putting

`source /usr/lib/python3/dist-packages/voltron/entry.py`

in the ~/.gdbinit file results in the same problem:

>>> import voltron
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/voltron/__init__.py", line 6, in 

from .main import main
  File "/usr/lib/python3/dist-packages/voltron/main.py", line 9, in 
from .view import *
  File "/usr/lib/python3/dist-packages/voltron/view.py", line 25, in 

from .core import Client
  File "/usr/lib/python3/dist-packages/voltron/core.py", line 18, in 

from werkzeug.wsgi import DispatcherMiddleware, SharedDataMiddleware
ImportError: cannot import name 'DispatcherMiddleware' from 'werkzeug.wsgi' 
(/usr/lib/python3/dist-packages/werkzeug/wsgi.py)

The reason seems to be that the debian testing packaged version of werkzeug is
1.0.1 while the packaged version of voltran does not support it. There is a
commit in the upstream repo that solves this problem:


https://github.com/snare/voltron/commit/ba413dcbc1914c511d03e1d95f3663a91daf349a

Unfortunately that commit is not included in an official release. I'm unsure if
that is required for it to be packaged with debian. Regardless, the older
version does not work as packaged (though the required changes are admittedly
quite minor).

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

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

Versions of packages voltron depends on:
ii  python3  3.9.1-1
ii  python3-blessed  1.17.12-1
ii  python3-flask1.1.2-2
ii  python3-flask-restful0.3.8-5
ii  python3-pygments 2.7.1+dfsg-1
ii  python3-requests 2.25.1+dfsg-2
ii  python3-requests-unixsocket  0.2.0-2
ii  python3-scruffy  0.3.3-2
ii  python3-six  1.15.0-2

voltron recommends no packages.

voltron suggests no packages.

-- no debconf information



Bug#983429: mosquitto: /run/mosquitto is on a tmpfs and should be created dynamically

2021-02-28 Thread Alexandre Detiste
Hi,

I tried to find old discussion about this to plead my case,
but it has been since integrated in the policy:

> 9.1.4 Packages must not include files or directories under /run, or under the 
> older /var/run and /var/lock paths.

Creating only a runtime is the way to go.

Greetings,



Bug#983722: [Pkg-openssl-devel] Bug#983722: libssl1.1: drop upgrade support from old-old-old-stable from maintainer script

2021-02-28 Thread Kurt Roeckx
On Sun, Feb 28, 2021 at 09:26:28PM +0100, Helmut Grohne wrote:
> Package: libssl1.1
> Version: 1.1.1j-1
> Tags: patch
> User: debian-d...@lists.debian.org
> Usertags: dpkg-root-support
> 
> The libssl1.1 package ships a maintainer script whose entire purpose is
> supporting upgrades from old-old-old-stable. Since Debian does not
> support skipping releases, it seems like this code can be safely
> dropped. The good thing about dropping it is that code that isn't there
> doesn't have to support DPKG_ROOT. Please consider applying the attached
> patch.

I think you at least misunderstand the purpose of the script, but
we've also not used it in a very long time.

It's meant to restart all services that make use of openssl when a
security update is released. I guess I switched to "checkrestart"
myself, so never had the need to use it myself anymore.


Kurt



Bug#983657: debian-policy: weaken manual page requirement

2021-02-28 Thread Christoph Berg
Re: Helmut Grohne
> On Sun, Feb 28, 2021 at 10:53:20AM -0700, Sean Whitton wrote:
> > Can you post a patch just doing the moving manpages to dependencies part
> > and indicate that you are seeking seconds?  Then we can get that
> > applied.
> 
> I call for seconds on:
> 
> --- a/policy/ch-docs.rst
> +++ b/policy/ch-docs.rst
> @@ -12,9 +12,9 @@
>  "cat page".
>  
>  Each program, utility, and function should have an associated manual
> -page included in the same package. It is suggested that all
> -configuration files also have a manual page included as well. Manual
> -pages for protocols and other auxiliary things are optional.
> +page included in the same package or a dependency. It is suggested that
> +all configuration files also have a manual page included as well.
> +Manual pages for protocols and other auxiliary things are optional.
>  
>  If no manual page is available, this is considered as a bug and should
>  be reported to the Debian Bug Tracking System (the maintainer of the

Seconded.

Christoph


signature.asc
Description: PGP signature


Bug#983723: rna-star FTBFS on ppc64el due to -march=native

2021-02-28 Thread Helmut Grohne
Source: rna-star
Version: 2.7.8a+dfsg-1
Severity: serious
Tags: ftbfs

rna-star fails to build from source on ppc64el (but previsouly built
there), because it now passes -march=native to g++:

| g++ -c -O3 -std=c++11 -march=native opal.cpp
| g++: error: unrecognized command-line option ‘-march=native’; did you mean 
‘-mcpu=native’?

Helmut



Bug#983657: debian-policy: weaken manual page requirement

2021-02-28 Thread Russ Allbery
Helmut Grohne  writes:

> I call for seconds on:

> --- a/policy/ch-docs.rst
> +++ b/policy/ch-docs.rst
> @@ -12,9 +12,9 @@
>  "cat page".
>  
>  Each program, utility, and function should have an associated manual
> -page included in the same package. It is suggested that all
> -configuration files also have a manual page included as well. Manual
> -pages for protocols and other auxiliary things are optional.
> +page included in the same package or a dependency. It is suggested that
> +all configuration files also have a manual page included as well.
> +Manual pages for protocols and other auxiliary things are optional.
>  
>  If no manual page is available, this is considered as a bug and should
>  be reported to the Debian Bug Tracking System (the maintainer of the

Seconded.

-- 
Russ Allbery (r...@debian.org)  



Bug#983657: debian-policy: weaken manual page requirement

2021-02-28 Thread Helmut Grohne
On Sun, Feb 28, 2021 at 10:53:20AM -0700, Sean Whitton wrote:
> Can you post a patch just doing the moving manpages to dependencies part
> and indicate that you are seeking seconds?  Then we can get that
> applied.

I call for seconds on:

--- a/policy/ch-docs.rst
+++ b/policy/ch-docs.rst
@@ -12,9 +12,9 @@
 "cat page".
 
 Each program, utility, and function should have an associated manual
-page included in the same package. It is suggested that all
-configuration files also have a manual page included as well. Manual
-pages for protocols and other auxiliary things are optional.
+page included in the same package or a dependency. It is suggested that
+all configuration files also have a manual page included as well.
+Manual pages for protocols and other auxiliary things are optional.
 
 If no manual page is available, this is considered as a bug and should
 be reported to the Debian Bug Tracking System (the maintainer of the

Helmut



Bug#983722: libssl1.1: drop upgrade support from old-old-old-stable from maintainer script

2021-02-28 Thread Helmut Grohne
Package: libssl1.1
Version: 1.1.1j-1
Tags: patch
User: debian-d...@lists.debian.org
Usertags: dpkg-root-support

The libssl1.1 package ships a maintainer script whose entire purpose is
supporting upgrades from old-old-old-stable. Since Debian does not
support skipping releases, it seems like this code can be safely
dropped. The good thing about dropping it is that code that isn't there
doesn't have to support DPKG_ROOT. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru openssl-1.1.1j/debian/changelog 
openssl-1.1.1j/debian/changelog
--- openssl-1.1.1j/debian/changelog 2021-02-16 20:50:01.0 +0100
+++ openssl-1.1.1j/debian/changelog 2021-02-28 21:21:43.0 +0100
@@ -1,3 +1,11 @@
+openssl (1.1.1j-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop maintainer script for upgrading libssl1.1 from old-old-old-stable.
+(Closes: #-1)
+
+ -- Helmut Grohne   Sun, 28 Feb 2021 21:21:43 +0100
+
 openssl (1.1.1j-1) unstable; urgency=medium
 
   * New upstream version.
diff --minimal -Nru openssl-1.1.1j/debian/libssl1.1.postinst 
openssl-1.1.1j/debian/libssl1.1.postinst
--- openssl-1.1.1j/debian/libssl1.1.postinst2021-02-16 20:31:27.0 
+0100
+++ openssl-1.1.1j/debian/libssl1.1.postinst1970-01-01 01:00:00.0 
+0100
@@ -1,207 +0,0 @@
-#!/bin/sh
-
-. /usr/share/debconf/confmodule
-
-set -e
-
-package_name()
-{
-echo $(basename $0 .postinst)
-}
-
-# element() is a helper function for file-rc:
-element() {
-local element list IFS
-
-element="$1"
-
-[ "$2" = "in" ] && shift
-list="$2"
-[ "$list" = "-" ] && return 1
-[ "$list" = "*" ] && return 0
-
-IFS=","
-set -- $list
-case $element in
-   "$1"|"$2"|"$3"|"$4"|"$5"|"$6"|"$7"|"$8"|"$9")
-   return 0
-esac
-return 1
-}
-
-# filerc (runlevel, service) returns /etc/init.d/service, if service is
-# running in $runlevel:
-filerc() {
-local runlevel basename
-runlevel=$1
-basename=$2
-while read LINE
-do
-   case $LINE in
-   \#*|"") continue
-   esac
-
-   set -- $LINE
-   SORT_NO="$1"; STOP="$2"; START="$3"; CMD="$4"
-   [ "$CMD" = "/etc/init.d/$basename" ] || continue
-
-   if element "$runlevel" in "$START" || element "S" in "$START"
-   then
-   echo "/etc/init.d/$basename"
-   return 0
-   fi
-done < /etc/runlevel.conf
-echo ""
-}
-
-if [ "$1" = "configure" ]
-then
-if [ ! -z "$2" ]; then
-   if dpkg --compare-versions "$2" lt 1.0.1g-2; then
-echo -n "Checking for services that may need to be restarted..."
-check="amanda-server anon-proxy apache2 apache-ssl"
-check="$check apf-firewall asterisk bacula-director-common"
-check="$check bacula-fd bacula-sd bind9 bip boinc-client"
-check="$check boxbackup-client boxbackup-server bozo cfengine2"
-check="$check cfengine3 citadel-server clamav-daemon 
clamav-freshclam"
-check="$check clamcour collectd-core conserver-server 
courier-imap-ssl"
-check="$check courier-mta-ssl courier-pop-ssl cyrus21-imapd"
-check="$check cyrus21-pop3d cyrus-common cyrus-imspd dovecot-core"
-check="$check ejabberd exim4 fetchmail freeradius ftpd-ssl gatling"
-check="$check globus-gatekeeper inn inn2 libapache-mod-ssl 
lighttpd lldpd"
-check="$check lwresd monit myproxy-server nagios-nrpe-server 
nginx-common"
-check="$check ntp openntpd openssh-server openvpn partimage-server"
-check="$check postfix postgresql-7.4 postgresql-8.0 postgresql-8.1"
-check="$check postgresql-8.2 postgresql-9.1 postgresql-9.2 
postgresql-9.3"
-check="$check proftpd proftpd-ldap proftpd-basic"
-check="$check proftpd-mysql proftpd-pgsql racoon sendmail slapd"
-check="$check spamassassin ssh-nonfree stunnel4 syslog-ng tor 
unbound"
-check="$check vsftpd"
-# Only get the ones that are installed, and configured
-check=$(dpkg -s $check 2> /dev/null | egrep '^Package:|^Status:' | 
awk '{if ($1 ~ /^Package:/) { package=$2 } else if ($0 ~ /^Status: .* 
installed$/) { print package }}')
-# init script rewrites
-check=$(echo $check | sed "
-# The name of proftpd-{ldap,mysql,pgsql,basic} init script 
is
-# same as "proftpd".
-s/proftpd-.*/proftpd/g;
-# dovecot-core ships its init script, but the
-# script name is dovecot for dovecot-{imapd,pop3d}.
-s/dovecot-core/dovecot/g;
-# openssh-server's init script it called ssh
-s/openssh-server/ssh/g;
-# bacula-director-common's init is bacula-director
-s/bacula-director-common/bacula-director/g;
-# citadel server
-

Bug#980261: RFS: jgmenu/4.3.0-1 [RFP] -- Simple X11 menu

2021-02-28 Thread Mateusz Łukasik

On 15.02.2021 at 16:40 +0100, Boyuan Yang wrote:

Hi,

在 2021-02-14星期日的 12:09 +0100,Mateusz Łukasik写道:

On 26.01.2021 at 23:25 +0100, Boyuan Yang wrote:

X-Debbugs-CC: mat...@linuxmint.pl jgm...@gmail.com


On Sat, 16 Jan 2021 21:38:16 +0100 =?UTF-8?Q?Mateusz_=c5=81ukasik?=
 wrote:

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

     * Package name    : jgmenu
   Version : 4.3.0-1
   Upstream Author : Johan Malm 
     * URL : https://jgmenu.github.io/
     * License : LGPL-2+, GPL-2+, Expat, LGPL-3+
     * Vcs : https://github.com/mati75/jgmenu
   Section : x11

It builds those binary packages:

  jgmenu-xfce4-panel-applet - xfce4-panel applet for jgmenu
  jgmenu - Simple X11 menu

To access further information about this package, please visit
the

following URL:

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

Alternatively, one can download the package with dget using this

command:

  dget -x

https://mentors.debian.net/debian/pool/main/j/jgmenu/jgmenu_4.3.0-1.dsc

Changes for the initial release:

     jgmenu (4.3.0-1) unstable; urgency=medium
     .
   * Initial release. (Closes: #882210)

One major problem: debian/copyright in your work says that the
whole
project is licensed under GPL-2+, however the LICENSE file from
upstream only gives GPLv2 license text. The README file also does
not
mention that the whole project is licensed under GPLv2 **or
later**.

Could you please contact upstream to clarify the case? The best
output
would be adding a "the whole project is licensed under GPLv2 or
later"
sentense in the README file, which would make things clear to
everyone.

P.S. I took a look at upstream's debian/copyright file at
https://github.com/johanmalm/jgmenu/blob/master/debian/copyright ,
in
which the upstream only mentioned GPL-2, not GPL-2+. If upstream is
only willing to release the whole project under GPL-2-only, using
GPL-
2+ is wrong and must be fixed.


Fixed in new version uploaded to mentors.


Looking at https://mentors.debian.net/package/jgmenu/ , there are
several lintian warnings. This indicates that the grammar of your
debian/copyright file is not correct. Please fix these problems.


W: jgmenu source: missing-license-paragraph-in-dep5-copyright expat
(line 20)
W: jgmenu source: missing-license-paragraph-in-dep5-copyright gpl-2
(line 15)
W: jgmenu source: missing-license-paragraph-in-dep5-copyright gpl-2+
(line 63)


Hint: you either need to paste all license texts under each License:
field, or you use "License:xxx" placeholder in each section and provide
a separate "License: xxx" plus full license text that does not attach
with any "file section" at the bottom of the debian/copyright file.
Please read
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
again (especially section 5.2.1) for the correct way of fixing these
lintian warnings.

Thanks,
Boyuan Yang


I think now it's fixed. Lintian warnings for copyright are clean.

--
.''`.  Mateusz Łukasik
: :' :  l0calh0st.pl
`. `'   Debian Member - mat...@linuxmint.pl
  `-GPG: D93B 0C12 C8D0 4D7A AFBC  FA27 CCD9 1D61 11A0 6851



Bug#983721: chirp is outdated

2021-02-28 Thread Christoph Berg
Control: retitle -1 chirp's python3 support is incomplete

Re: gpe92
> chirp in debian is outdaded. Thanks to update to current version
> (2021/02/12).

Hi,

the problem is that upstream isn't providing a version that works with
Python 3 yet. (And we cannot revert to Python 2 because the Gtk module
has already been removed.)

Christoph DF7CB



Bug#983720: db.h: add an argumnet to a prototype for "*db_data_path()"

2021-02-28 Thread Bjarni Ingi Gislason
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 25166e6c3bf6eae37747f9ca849a9bad79eea6a7 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 28 Feb 2021 19:57:47 +
>Subject: [PATCH] db.h: add an argumnet to a prototype for "*db_data_path()"

  db.h: add an argumnet to a prototype for "*db_data_path()"

Signed-off-by: Bjarni Ingi Gislason 
---
 db.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/db.h b/db.h
index e583a06..c24af2b 100644
--- a/db.h
+++ b/db.h
@@ -122,7 +122,7 @@ voidsort_groups(void);
 group_header   *lookup_no_alias(char *);
 group_header   *lookup(char *);
 int art_collected(group_header *, article_number);
-char   *db_data_path(char *, group_header *, char);
+char   *db_data_path(char *, size_t, group_header *, char);
 FILE   *open_data_file(group_header *, char, int);
 voiddb_write_group(register group_header *);
 off_t   db_read_art(FILE *);
-- 
2.30.1


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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason



Bug#983721: chirp is outdated

2021-02-28 Thread gpe92
Package: chirp
Version: 1:20200227+py3+20200213-3
Severity: normal

Dear Maintainer,

chirp in debian is outdaded. Thanks to update to current version
(2021/02/12).

BR.

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

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

Versions of packages chirp depends on:
ii  python3   3.9.1-1
ii  python3-future0.18.2-5
ii  python3-serial3.5~b0-1
ii  python3-six   1.15.0-2
ii  python3-wxgtk4.0  4.0.7+dfsg-10

chirp recommends no packages.

chirp suggests no packages.

-- no debconf information



Bug#983718: RM: yash [mips64el mipsel] -- RoQA; no longer builds on mips*

2021-02-28 Thread Adrian Bunk
Package: ftp.debian.org
Severity: normal

See #982817 for background



Bug#983672: linux-image: fails to recognize certain microSD cards

2021-02-28 Thread Salvatore Bonaccorso
Control: tags -1 + moreinfo

hi José,

On Sun, Feb 28, 2021 at 11:01:58AM +0100, José Luis González wrote:
> Package: linux-image-4.19.0-13-amd64
> Version: 4.19.160-2
> Tags: patch upstream
> 
> Certain SD cards set a flag that isn't really defined in the SD spec
> but the mmc should be ignoring. It turns out it doesn't, so the cards
> don't get recognized properly making it impossible to use them.
> 
> There is a bug reported in kernel.org's bugzilla that explains it all:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=202473
> 
> Contained is a very small patch that fixes the problem:
> 
> https://patchwork.kernel.org/project/linux-mmc/patch/20190827081043.15443-1-ulf.hans...@linaro.org/
> 
> Please, incorporate the patch so that we can use these cards.
> 
> I have tested both version 4.19.160-2 and version 5.9.15-1~bpo10+1
> (this from buster-backports), and neither mount my card successfully so
> I understand the patch isn't incorporated to either.
> 
> I'd very much appreciate if the fix got into buster-backports.

then probably the issue you have is another one though. The above
patch was commited upstream as 72741084d903 ("mmc: core: Fix init of
SD cards reporting an invalid VDD range") and landed in 5.3-rc7, and
got backported to several stable series as in 5.2.12, 4.19.70,
4.14.142, 4.9.191, 4.4.191 and 3.16.78.

The report did not contain any further information, so please do
attach as well kernel logs, errors, you are seeing, how/if the card is
detected (when filling the report via reportbug, this information will
be attached).

Regards,
Salvatore



Bug#983717: nn: db.c:

2021-02-28 Thread Bjarni Ingi Gislason
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 7ec8452cf4e3903c75f359a20abbde3cf1e6c4c6 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 28 Feb 2021 19:42:50 +
>Subject: [PATCH] db.c: add two variables, information to the output,
 and some arguments to functions

  Add size of an array to the argument list of some functions.

  Use "snprintf()" instead of "sprintf()".

  Add variable "source" for a file name.

  Add some output with information.

  Add variable "count" to count number of groups.

Signed-off-by: Bjarni Ingi Gislason 
---
 db.c | 47 ---
 1 file changed, 32 insertions(+), 15 deletions(-)

diff --git a/db.c b/db.c
index 51ac2e6..2306c71 100644
--- a/db.c
+++ b/db.c
@@ -850,20 +850,20 @@ art_collected(group_header * gh, article_number art_num)
 
 #ifndef NOV
 char   *
-db_data_path(char *namebuf, group_header * gh, char d_or_x)
+db_data_path(char *namebuf, size_t nnamebuf, group_header * gh, char d_or_x)
 {
 register char  *cp, *np;
 
 if (db_data_directory != NULL) {
 
 #ifdef DB_LONG_NAMES
-   sprintf(namebuf, "%s/%s.%c", db_data_directory, gh->group_name, d_or_x);
+   snprintf(namebuf, nnamebuf, "%s/%s.%c", db_data_directory, 
gh->group_name, d_or_x);
 #else
if (db_data_subdirs)
-   sprintf(namebuf, "%s/%ld/%ld.%c", db_data_directory,
+   snprintf(namebuf, nnamebuf, "%s/%ld/%ld.%c", db_data_directory,
gh->group_num / 100, gh->group_num, d_or_x);
else
-   sprintf(namebuf, "%s/%ld.%c", db_data_directory, gh->group_num, 
d_or_x);
+   snprintf(namebuf, nnamebuf, "%s/%ld.%c", db_data_directory, 
gh->group_num, d_or_x);
 #endif /* DB_LONG_NAMES */
 } else {
np = namebuf;
@@ -892,7 +892,7 @@ open_data_file(group_header * gh, char d_or_x, int mode)
 FILE   *f;
 chardata_file[FILENAME];
 
-db_data_path(data_file, gh, d_or_x);
+db_data_path(data_file, FILENAME, gh, d_or_x);
 
 if (mode == -1) {
if (unlink(data_file) < 0 && errno != ENOTDIR && errno != ENOENT)
@@ -1009,6 +1009,7 @@ err:
 
 
 #ifdef NOV
+
 static void
 readactfile(void)
 {
@@ -1029,13 +1030,16 @@ readactfile(void)
 #ifdef NNTP
 if (use_nntp) {
actfp = nntp_fopen_list("LIST");
-} else
+   source = nntp_server;
+} else {
 #endif /* NNTP */
 
-   actfp = fopen(relative(news_lib_directory, "active"), "r");
+   source = relative(news_lib_directory, "active");
+   actfp = fopen(source, "r");
+}
 
 if (actfp == NULL) {
-   nn_exitmsg(1, "could not fetch active file\n");
+   nn_exitmsg(1, "could not fetch active file from %s\n", source);
 }
 
 /*
@@ -1068,10 +1072,12 @@ readactfile(void)
if ( (nntp_debug || keep_active_file) && (f_user != NULL))
fprintf(f_user, "%s\n", actline);
 
-   stlist_t   *stnew = (stlist_t *) strkeep(actline, 
sizeof(stlisthdr_t), POOL_ACT);
+   stlist_t  *stnew = (stlist_t *) strkeep(actline, sizeof(stlisthdr_t), 
POOL_ACT);
+
if (stnew == NULL) {
-   nn_exitmsg(1, "out of mem for active file (at line %d)\n", count + 
1);
+   nn_exitmsg(1, "Out of memory for active file (at line %d)\n", count 
+ 1);
}
+
if (sthead != NULL) {
stp->n.next = stnew;
stp = stnew;
@@ -1088,6 +1094,7 @@ readactfile(void)
 
 actlist = (char **) calloc(count + 1, sizeof(char *));
 grplist = (char **) calloc(count + 1, sizeof(char *));
+
 if (grplist == NULL) {
nn_exitmsg(1, "can't create active or group list (%d entries)\n",
   count + 1);
@@ -1097,6 +1104,7 @@ readactfile(void)
  * Second pass (in core): Put active lines and group names into string
  * arrays.
  */
+
 for (i = 0, stp = sthead; stp && i < count; stp = stp->n.next, i++) {
char   *p = strchr(stp->str, ' ');
 
@@ -1108,13 +1116,13 @@ readactfile(void)
}
grplist[i] = strkeep(stp->str, 0, POOL_GRP);
 }
+tprintf("done.  %d groups.\n\n", count);
 actlist[count] = NULL;
 grplist[count] = NULL;
 
 /* init the master struct */
 clearobj(&master, sizeof(master), 1);
 master.number_of_groups = count;
-
 }
 
 
@@ -1186,7 +1194,7 @@ readpartactfile(void)
 /* tprintf("%s\n", actline);
nn_exitmsg(1, "Testing ask_server\n");
 */
-   stlist_t   *stnew = (stlist_t *) strkeep(actline, 
sizeof(stlisthdr_t), POOL_ACT);
+   stlist_t *stnew = (stlist_t *) strkeep(actline, sizeof(stlisthdr_t), 
POOL_ACT);
if (stnew == NULL) {
nn_exitmsg(1, "Out of memory for active file (at line %d)\n", count 
+ 1);
}
@@ -1381,6 +1389,7 @@ readtimfile(void)
 chartimline[512];
 FILE   *timfp;
 unsignedhsize;
+unsigned intcount = 0;
 
 if (timtbl != NULL)
 

Bug#983716: r-cran-matrixstats needs Breaks: r-bioc-sparsematrixstats (<< 1.2.1+dfsg-1~)

2021-02-28 Thread Adrian Bunk
Package: r-cran-matrixstats
Version: 0.58.0-2
Severity: serious

I think/hope this will fix the autopkgtest problem
that prevents testing migration.



Bug#983714: gameconqueror: does not start unless xhost +local: is run in the terminal first

2021-02-28 Thread Duco
Package: gameconqueror
Version: 0.17-2
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
I installed gameconqueror and found that it wouldn't start at all.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
First I tried updating my system and restarting my computer, that did not
change anything.
After some searching online I found an issue page on the scanmem github
describing my issue and a workaround to run xhost +local: before starting the
program. The workaround works so the program no longer crashes on startup if I
remember to run xhost +local:.
https://github.com/scanmem/scanmem/issues/263

Thank you for your time :)




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

Kernel: Linux 5.10.15-xanmod1 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gameconqueror depends on:
ii  gir1.2-gtk-3.0  3.24.5-1
ii  policykit-1 0.105-25
ii  python3 3.7.3-1
ii  python3-gi  3.30.4-1
ii  scanmem 0.17-2+b1

gameconqueror recommends no packages.

gameconqueror suggests no packages.

-- no debconf information



Bug#983715: libitext5-java: Please add itext-xtra too

2021-02-28 Thread Thomas Uhle

Package: libitext5-java
Version: 5.5.13-1
Severity: normal

Dear maintainers,

when building a binary package next time, please also add the jar file 
and Maven files for itext-xtra.


Thank you in advance!

Best regards,

Thomas Uhle


-- System Information:
Debian Release: 10.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 4.19.0-14-arm64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
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 /bin/dash
Init: systemd (via /run/systemd/system)

libitext5-java depends on no packages.

libitext5-java recommends no packages.

Versions of packages libitext5-java suggests:
ii  libbcpkix-java1.60-1
ii  libbcprov-java1.60-1
pn  libitext5-java-doc
pn  libxml-security-java  



Bug#978450: freecad: SEGV when editing a spreadsheet

2021-02-28 Thread Łukasz Stelmach
The problem occurs with freecad-python3 too.
-- 
Miłego dnia,
Łukasz Stelmach



Bug#983712: RFS: lebiniou-data/3.55.0-1 -- datafiles for Le Biniou

2021-02-28 Thread Olivier Girondel



Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "lebiniou-data":

  * Package name: lebiniou-data
Version : 3.55.0-1
Upstream Author : Olivier Girondel 
  * URL : https://biniou.net
  * License : GPL-2+
Section : graphics

It builds this binary package:

 lebiniou-data - datafiles for Le Biniou

The package appears to be lintian-clean.

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

   https://mentors.debian.net/package/lebiniou-data

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

   dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou-data/lebiniou-data_3.55.0-1.dsc

Changes since the last upload:

   * New upstream release 3.55.0.
   * debian/tests/control: Add Depends: wget.
   * debian/tests/control: Add Restrictions: needs-internet.

Regards,

--
Olivier Girondel



Bug#983713: RFS: lebiniou/3.55.0-1 -- user-friendly, powerful music visualization / VJing tool

2021-02-28 Thread Olivier Girondel



Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: lebiniou
Version : 3.55.0-1
Upstream Author : Olivier Girondel 
  * URL : https://biniou.net
  * License : GPL-2+
Section : graphics

It builds this binary package:

   lebiniou - user-friendly, powerful music visualization / VJing tool

The package appears to be lintian-clean.

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

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

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

   dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.55.0-1.dsc

Changes since the last upload:

   * New upstream release 3.55.0.
   * debian/control: Build-Depends: Add htmlmin, python3-setuptools.
   * debian/lebiniou.lintian-overrides: Updated.
   * debian/source/lintian-overrides: Updated.
   * debian/tests/control: Depends: Add wget, bump lebiniou-data version.
   * debian/tests/control: Add Restrictions: needs-internet.
   * debian/copyright: Updated.

Regards,

--
Olivier Girondel



Bug#982070: easy-rsa: Update to 3.0.8 to support ed25519

2021-02-28 Thread Michele Orrù
Hi Martin,

I'm really sorry for the late reply on this bug. I updated the salsa
repository (https://salsa.debian.org/debian/easy-rsa) , and you should be
able to run gbp buildpackage.
Please let me know if there's anything that doesn't look right!


Have a great day,
--
Michele.

On Fri, Feb 12, 2021 at 12:57 PM Martin  wrote:

> On 2021-02-12 11:11, Michele Orrù wrote:
> > Last release I had troubles finding a sponsor, could you please be the
> one™
> > ?
>
> With pleasure!
>


Bug#972546: rclone-browser: rclone is not available on mipsel

2021-02-28 Thread Adrian Bunk
Control: retitle -1 rclone-browser should depend on rclone also on mipsel

On Tue, Oct 20, 2020 at 02:14:39PM +0800, Drew Parsons wrote:
> Package: rclone-browser
> Version: 1.8.0-1
> Severity: important
> Control: affects -1 rclone
> 
> rclone has never built reliably on mipsel, and has now been removed
> for mipsel.
> 
> This means rclone-browser is not installable on mipsel since it has
>   Depends: rclone.
> 
> Since rclone is not required to *build* rclone-browser, probably the
> simplest fix is to replace the Depends with
>  Depends: rclone [!mipsel]
> 
> There are two other options:
> - change the Depends to Recommends: rclone

This had been done in an NMU, and should be reverted now that rclone
is available again on mipsel.

> - request that rclone-browser be removed from unstable for mipsel and add
>   Build-Depends: rclone.
>   (this option would track rclone, making rclone-browser work again on
>mipsel if rclone ever builds in the future).
>...

"Build-Depends: rclone" is a good idea in any case, to prevent building 
on architectures where the package is not installable.

cu
Adrian



Bug#983711: ITP: saneyaml -- PyYaml wrapper with sane behaviour to read and write readable YAML safely

2021-02-28 Thread Jelmer Vernooij
Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: saneyaml
  Version : 0.3
  Upstream Author : Philippe Ombredanne
* URL : https://github.com/nexB/saneyaml
* License : Apache-2.0
  Programming Lang: Python
  Description : PyYaml wrapper with sane behaviour to read and write 
readable YAML safely

This micro library is a PyYaml wrapper with sane behaviour to read and write
readable YAML safely, typically when used with configuration files.

With saneyaml you can dump readable and clean YAML and load safely any YAML
preserving ordering and avoiding surprises of type conversions by loading
everything except booleans as strings. Optionally you can check for duplicated
map keys when loading YAML.

This is a dependency for scancode-toolkit.



Bug#983710: put-dns: [INTL:pt] Updated Portuguese translation for debconf messages

2021-02-28 Thread Traduz - DebianPT

Package: put-dns
Version: 0.0.2-3
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for put-dns's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
--
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org
















# Portuguese translation for put-dns messages.
# Copyright (C) 2021 Miguel Figueiredo 
# This file is distributed under the same license as the put-dns package.
# Miguel Figueiredo , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: put-dns\n"
"Report-Msgid-Bugs-To: put-...@packages.debian.org\n"
"POT-Creation-Date: 2021-02-22 08:32+\n"
"PO-Revision-Date: 2021-02-28 18:26+\n"
"Last-Translator: Miguel Figueiredo \n"
"Language-Team: Portuguese \n"
"Language: Portuguese\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Automatically update domain in put-dns.conf?"
msgstr "Atualizar automaticamente o domínio em put-dns.conf?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"If enabled put-dns will, on configuration, try to detect a valid external "
"domain name on the current system and update the put-dns.conf configuration "
"file to use it. If disabled then the configuration will not be automatically "
"updated."
msgstr ""
"Se estiver ativo, durante a configuração o put-dns irá, tentar detetar um "
"nome de domínio externo válido no sistema atual e atualizar o ficheiro de "
"configuração put-dns.conf para o utilizar. Se estiver desabilitado, então "
"o ficheiro de configuração não será atualizado automaticamente."


Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop

2021-02-28 Thread Gunnar Hjalmarsson

On 2021-02-28 16:05, YOSHINO Yoshihito wrote:

On the GNOME desktop, manual set-up in GNOME Settings is required
in order to make ibus-anthy to work.


Right. But does that differ in any way from other IBus input methods?

--
Rgds,

Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature


Bug#983709: nn: back_act.sh:

2021-02-28 Thread Bjarni Ingi Gislason
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 0f46483d7b072826e6ec74221db0a95d3fe8840c Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 28 Feb 2021 18:08:47 +
>Subject: [PATCH] back_act.sh: empty file $ACTIVE after saving it

  back_act.sh: empty file $ACTIVE after saving it

Signed-off-by: Bjarni Ingi Gislason 
---
 back_act.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/back_act.sh b/back_act.sh
index c5cebf4..a99cf7d 100644
--- a/back_act.sh
+++ b/back_act.sh
@@ -29,5 +29,5 @@ do
p=$i
 done
 
-cp $ACTIVE active.0
+cp $ACTIVE active.0 && : > $ACTIVE || :
 chmod 644 active.0
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason



Bug#983708: passdev and systemd use conflicting syntax for keyfile

2021-02-28 Thread schaarsc
Package: cryptsetup-initramfs
Version: 2:2.3.4-2~bpo10+2

systemd  247.2-5~bpo10+1

I recently switched to buster-backports and noticed an issue that (I think) 
could potentially break
systems migrating to bullseye.
On a system having encrypted root, keyfile on usb-stick and multiple btrfs 
subvolumes, the system
fails to mount all subvolumes.

If there is no solution, then maybe a hint in the README could be added.

== Root cause ==

/etc/crypttab is used by passdev and systemd, but using different syntax
passdev expects[1] :
systemd expects[2] :


== Setup ==

/etc/crypttab
(this is in one line, split to avoid random line breaks)
root-luks
/dev/sda2
/dev/disk/by-label/usbkeys:/root.key
luks,keyscript=passdev,initramfs


/etc/fstab
/dev/sda1/boot   ext2
/dev/mapper/root-luks/   btrfs subvol=@
/dev/mapper/root-luks/.snapshots btrfs subvol=@snapshots
/dev/mapper/root-luks/home   btrfs subvol=@home


== Observed issues ==

1. grub starts initramfs
2. cryptsetup-initramfs opens root-luks
3. systemd-cryptsetup-generator starts
4. Error: failed to mount run-systemd-cryptsetup-keydev\\x2droot\\x2dluks.mount
5. .snapshots and home is not mounted because of missing "dependency" for 
root-luks


== Workaround ==

create a systemd-mount file for the usb-stick
/etc/systemd/system/run-systemd-cryptsetup-keydev\\x2droot\\x2dluks.mount
What=/dev/disk/by-label/usbkeys
Where=/run/systemd/cryptsetup/keydev-root-luks
Options=ro

== References ==
1. /usr/share/doc/cryptsetup-initramfs/README.initramfs.gz
2. https://www.freedesktop.org/software/systemd/man/crypttab.html



Bug#931402: could not leave editor on examining a config file conflict

2021-02-28 Thread Norman Rasmussen
Package: dpkg
Version: 1.20.7.1
Followup-For: Bug #931402

I can reproduce this in just the shell that's started. Ctrl-C doesn't
seem to have any immediate effect. However once the shell is exited, the
Ctrl-C causes dpkg to terminate early.

I suspect that dpkg isn't creating a new foreground process group, so
the SIGINT from Ctrl-C is being delivered to dpkg instead of the shell
(or relevant sub-process like the editor).

Adding a setsid or setpgid call somewhere in spawn_shell and/or
show_diff would probably fix it.

-- Package-specific info:

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.30-2
ii  liblzma5 5.2.4-1+b1
ii  libselinux1  3.1-2+b2
ii  tar  1.29b-2
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.1.20
pn  debsig-verify  

-- no debconf information



Bug#983657: debian-policy: weaken manual page requirement

2021-02-28 Thread Sean Whitton
Hello,

On Sun 28 Feb 2021 at 05:41PM +01, Helmut Grohne wrote:

> If we cannot build consensus around that second part, so be it. But
> maybe the other part (moving manual pages to dependencies) can reach
> consensus?

Can you post a patch just doing the moving manpages to dependencies part
and indicate that you are seeking seconds?  Then we can get that
applied.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#983706: gzip FTBFS on mips64el: FAIL: timestamp

2021-02-28 Thread Adrian Bunk
Source: gzip
Version: 1.10-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=gzip&arch=mips64el&ver=1.10-3&stamp=1614531854&raw=0

...
FAIL: timestamp
===

+ initial_cwd_=/<>/builddir/tests
+ testdir_prefix_
+ printf gt
+ pfx_=gt
+ mktempd_ /<>/builddir/tests gt-timestamp.
+ destdir_=/<>/builddir/tests
+ template_=gt-timestamp.
+ MAX_TRIES_=4
+ destdir_slash_=/<>/builddir/tests/
+ unset TMPDIR
+ d=/<>/builddir/tests/gt-timestamp.TDZE
+ :
+ test -d /<>/builddir/tests/gt-timestamp.TDZE
+ ls -dgo /<>/builddir/tests/gt-timestamp.TDZE
+ perms=drwx-- 2 40 Feb 28 17:04 
/<>/builddir/tests/gt-timestamp.TDZE
+ :
+ echo /<>/builddir/tests/gt-timestamp.TDZE
+ return
+ test_dir_=/<>/builddir/tests/gt-timestamp.TDZE
+ cd /<>/builddir/tests/gt-timestamp.TDZE
+ gl_init_sh_nl_=

+ IFS=  

+ expr 1 + 128
+ eval trap 'Exit 129' 1
+ trap Exit 129 1
+ expr 2 + 128
+ eval trap 'Exit 130' 2
+ trap Exit 130 2
+ expr 3 + 128
+ eval trap 'Exit 131' 3
+ trap Exit 131 3
+ expr 13 + 128
+ eval trap 'Exit 141' 13
+ trap Exit 141 13
+ expr 15 + 128
+ eval trap 'Exit 143' 15
+ trap Exit 143 15
+ trap remove_tmp_ 0
+ path_prepend_ ..
+ test 1 != 0
+ path_dir_=..
+ abs_path_dir_=/<>/builddir/tests/..
+ 
PATH=/<>/builddir/tests/..:/<>/builddir:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
+ create_exe_shims_ /<>/builddir/tests/..
+ return 0
+ shift
+ test 0 != 0
+ export PATH
+ TZ=UTC0
+ export TZ
+ oldIFS=   

+ IFS=~
+ set 19010101 Jan  1  1901
+ time=19010101
+ date=Jan  1  1901
+ IFS=  

+ touch -t 19010101 in
+ ls -l in
+ ls_l=-rw-rw-r-- 1 buildd buildd 0 Jan  1  1901 in
+ returns_ 2 gzip in
+ fail=1
+ rm -f in.gz in
+ IFS=~
+ set 196912312359.59 Dec 31  1969
+ time=196912312359.59
+ date=Dec 31  1969
+ IFS=  

+ touch -t 196912312359.59 in
+ ls -l in
+ ls_l=-rw-rw-r-- 1 buildd buildd 0 Dec 31  1969 in
+ returns_ 2 gzip in
+ fail=1
+ rm -f in.gz in
+ IFS=~
+ set 19700101 Jan  1  1970
+ time=19700101
+ date=Jan  1  1970
+ IFS=  

+ touch -t 19700101 in
+ ls -l in
+ ls_l=-rw-rw-r-- 1 buildd buildd 0 Jan  1  1970 in
+ returns_ 2 gzip in
gzip: in: warning: file timestamp out of range for gzip format
+ rm -f in.gz in
+ IFS=~
+ set 210602070628.16 Feb  7  2106
+ time=210602070628.16
+ date=Feb  7  2106
+ IFS=  

+ touch -t 210602070628.16 in
+ ls -l in
+ ls_l=-rw-rw-r-- 1 buildd buildd 0 Feb  7  2106 in
+ returns_ 2 gzip in
gzip: in: warning: file timestamp out of range for gzip format
+ rm -f in.gz in
+ IFS=~
+ set 19700101.01 Jan  1  1970
+ time=19700101.01
+ date=Jan  1  1970
+ IFS=  

+ touch -t 19700101.01 in
+ ls -l in
+ ls_l=-rw-rw-r-- 1 buildd buildd 0 Jan  1  1970 in
+ gzip in
+ rm -f in.gz in
+ IFS=~
+ set 203801190314.07 Jan 19  2038
+ time=203801190314.07
+ date=Jan 19  2038
+ IFS=  

+ touch -t 203801190314.07 in
+ ls -l in
+ ls_l=-rw-rw-r-- 1 buildd buildd 0 Jan 19  2038 in
+ gzip in
+ rm -f in.gz in
+ IFS=~
+ set 203801190314.08 Jan 19  2038
+ time=203801190314.08
+ date=Jan 19  2038
+ IFS=  

+ touch -t 203801190314.08 in
+ ls -l in
+ ls_l=-rw-rw-r-- 1 buildd buildd 0 Jan 19  2038 in
+ gzip in
+ rm -f in.gz in
+ IFS=~
+ set 210602070628.15 Feb  7  2106
+ time=210602070628.15
+ date=Feb  7  2106
+ IFS=  

+ touch -t 210602070628.15 in
+ ls -l in
+ ls_l=-rw-rw-r-- 1 buildd buildd 0 Feb  7  2106 in
+ gzip in
+ rm -f in.gz in
+ printf \037\213\10\0\377\377\377\377\0\377\3\0\0\0\0\0\0\0\0\0
+ gzip -Nlv
method  crc date  time   compresseduncompressed  ratio 
uncompressed_name
defla  Feb  7 06:28  20   0   0.0% 
stdout
+ status=0
+ test 0 -eq 0
+ :
+ gzip --no-name
+ Exit 1
+ set +e
+ exit 1
+ exit 1
+ remove_tmp_
+ __st=1
+ cleanup_
+ :
+ test  = yes
+ cd /<>/builddir/tests
+ chmod -R u+rwx /<>/builddir/tests/gt-timestamp.TDZE
+ rm -rf /<>/builddir/tests/gt-timestamp.TDZE
+ exit 1
FAIL timestamp (exit status: 1)


Testsuite summary for gzip 1.10

# TOTAL: 22
# PASS:  21
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See tests/test-suite.log
Please report to bug-g...@gnu.org

make[5]: *** [Makefile:1674: test-suite.log] Error 1



On the porterbox eller, 1.10-2 fails the same as 1.10-3.
1.10-3 builds in a buster chroot.

The breakage is likely caused or triggered by a change to
some other package like gcc/glibc/...

The linux-mips list is CC'ed.



Bug#983701: krb5-strength FTBFS when passing the nocheck build profile

2021-02-28 Thread Russ Allbery
Helmut Grohne  writes:

> krb5-strength fails to build from source when passing the nocheck build
> profile. When you (Russ) applied my previous patch, you were a little
> too eager and annotated a number of other dependencies  than I
> proposed. However, I already supplied the maximal set that kept
> krb5-strength building. Annotating any of those other dependencies makes
> it FTBFS (unless you also change something about the build system).

Ugh, I'm sorry.  That's *definitely* a bug; none of those dependencies
should be necessary to build the package.  But I'll work on fixing that
upstream and get this fix into Debian in the meantime for the release.

-- 
Russ Allbery (r...@debian.org)  



Bug#981243: libboost-log1.74.0 prevents debootsrap to finish correctly

2021-02-28 Thread Radoslav Bodó
> Adrian Bunk  (2021-02-28):
>> This is a bug in debootstrap which should really use a dependency
>> solver like apt, but AFAIK noone is working on this.
>
> Well debootstrap's goal is what it says in the name, which is
> bootstrapping. Just install a base system first and install whatever
> packages you need using apt afterwards, and voilà.

Hello,

the '--include' has been working fine for years so I suspected a problem
in libboost at first. we've replaced it for 'chroot apt-get' and we'll
proceed with that further on.

Thank you for your replies, I guess the bugreport can be closed.

bodik



signature.asc
Description: OpenPGP digital signature


Bug#983346: Update gitlab to 13.7.7 (installation fails - need help)

2021-02-28 Thread Pirate Praveen
On Sun, 28 Feb 2021 19:04:24 +0530 Pirate Praveen 
 wrote:

> Asking upstream for help
> https://gitlab.com/gitlab-org/gitlab/-/issues/323024

Removing these 3 files makes the upgrade to proceed,
/usr/share/gitlab/config/feature_flags/ops/api_kaminari_count_with 
_limit.yml

/usr/share/gitlab/config/feature_flags/licensed/resource_access_token.yml
/usr/share/gitlab/config/feature_flags/ops/marginalia.yml

Of these 3 
/usr/share/gitlab/config/feature_flags/licensed/resource_access_token.yml

can definitely be removed as it is not present in current version.

I think these are safe to remove, but I will wait a few days for an 
answer from upstream (till there is a new security release).


Or if someone else can confirm, this is safe, I can remove it as well.



Bug#983705: RFS: python-mockito/1.2.2-1 [ITP] -- Spying framework for Python - documentation

2021-02-28 Thread Fabrice Bauzac-Stehly
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-mockito":

 * Package name: python-mockito
   Version : 1.2.2-1
   Upstream Author : https://github.com/kaste/mockito-python/issues
 * URL : https://github.com/kaste/mockito-python
 * License : Expat
 * Vcs : 
https://salsa.debian.org/python-team/packages/python-mockito
   Section : python

It builds those binary packages:

  python-mockito-doc - Spying framework for Python - documentation
  python3-mockito - Spying framework for Python

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

  https://mentors.debian.net/package/python-mockito/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-mockito/python-mockito_1.2.2-1.dsc

Changes since the last upload:

 python-mockito (1.2.2-1) unstable; urgency=low
 .
   * Initial release. Closes: #981067

Best regards
--
Fabrice Bauzac-Stehly
PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6
old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D



Bug#785495: Bug is back on 3.38.2.1-1

2021-02-28 Thread Andre Etienne
On Sun, 28 Feb 2021 00:33:56 + Andre Etienne 
 wrote:

> On Sat, 27 Feb 2021 02:51:22 + Andre Etienne
>  wrote:
> > Hi all,
> >
> >
> > With Buster (gdm3 3.30.2-3 ) using DisallowTCP=false add the "-listen
> > tcp" in command line and I can connect remotely.
> >
> > With gdm3 3.38.2.1-1, using DisallowTCP=false remove the "-nolisten 
tcp"

> > but do not add "-listen tcp" so I can not connect remotely.
> >
> >
> > Thanks
> >
> >
>
> Ok,
>
> I try a little trick:
>
> in gdm-server.c and gdm-x-session.c, I remove the conditional if:
>
> #ifdef HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY (and corresponding #else
> and #endif), leaving the remaining code.
>
> I compile the code and now I have the "-listen tcp"  in command line.
>
> So the problem certainly come from the
> HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY condition.
>
> Cheers
>
>
>
>

Hi All,

I re-download source from Debian site, and meson.build now include 
HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY condition.


This solve my trouble, I have the "-listen tcp"  in command line.

Thanks



Bug#983704: Switch to fcitx5 for Simplified and Traditional Chinese desktop

2021-02-28 Thread Shengjing Zhu
Package: tasksel
Version: 3.64
Severity: important
X-Debbugs-Cc: z...@debian.org, debian-chinese...@lists.debian.org, 
debian-chinese-b...@lists.debian.org

Please replace fcitx with fcitx5 in Bullseye for Chinese desktops.

fcitx doesn't work for Wayland users. And the upstream develop of fcitx
is in maintenance mode.

fcitx5 is developed by same upstream, and works for Wayland.

Fcitx5 reaches its stable version in 2020-11. I and other DDs have used it
for months. And it works well.

So I think it's better to replace fcitx with fcitx5 for Bullseye, instead of
documenting in release notes that tells users to switch to Xorg.


signature.asc
Description: PGP signature


Bug#940613: Any updates?

2021-02-28 Thread Sergio Durigan Junior
On Sunday, February 28 2021, Gard Spreemann wrote:

> Hi,
>
> I see version 1.0 of this software was just released, and has been
> making its way around the web. It looks really neat! Do you think you'll
> be interested in picking back up your packaging efforts for after the
> Bullseye release? I'm happy to lend a hand.

Thank you for your interest.  I'm actually finishing the package right
now.  I should upload it to experimental in the next couple of days.

The problem is that we're in freeze now, so I can't upload it directly
to unstable, but I will talk to the release team and see if they can
make an exception for this one.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/



Bug#983677: Further information

2021-02-28 Thread Rainer Dorsch
Hi,

after I submitted the bug report I made these additional observations:

I can still change to self-added paper formats, but not to pre-defined formats, 
like A4, US Letter, US legal

It seems to be related to ADF, switching first to flatbed, then change the 
paper 
format, then switch back to ADF works.

Thanks
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/



Bug#958787: maven-cache-cleanup: diff for NMU version 1.0.4-1.2

2021-02-28 Thread tony mancill
On Sat, Feb 27, 2021 at 04:16:18PM +0200, Adrian Bunk wrote:
> I've prepared an NMU for maven-cache-cleanup (versioned as 1.0.4-1.2) 
> and uploaded it to DELAYED/1. Please feel free to tell me if I should 
> cancel it.

Thank you Adrian.  I will apply the dsc to packaging repo and
acknowledge in the next upload.



Bug#940613: Any updates?

2021-02-28 Thread Gard Spreemann
Hi,

I see version 1.0 of this software was just released, and has been
making its way around the web. It looks really neat! Do you think you'll
be interested in picking back up your packaging efforts for after the
Bullseye release? I'm happy to lend a hand.


Best,
Gard



Bug#982892: ITP: binutils-or1k-elf -- GNU binary utilities for the Open RISC 1000 processors

2021-02-28 Thread Helmut Grohne
On Sun, Feb 28, 2021 at 03:23:47PM +0100, Nicolas Boulenguez wrote:
> Can you describe the scenarios you want to avoid?  The binutils-* are
> quite different from each other.

Some binutils bug is discovered. Once understood, Matthias is usually
quick at uploading a fixed binutils. However binutils-* are not uploaded
at the same frequency and still exhibit the bug. The bug is usually
closed and it takes a while to figure that we still have a copy of it in
the archive, because some binutils-* wasn't rebuilt.

Reproducibility is another issue. If you natively build an or1k package
and compare it to a cross built one, the cross build usually does not
reproduce the native build, because the cross toolchains are outdated
with respect to the native toolchains.

A solution to both would be regularly uploading the binutils wrapper
packages. However, that's not what is happening in practice. The second
best solution is reducing their number as much as possible. Doing so
makes updating them all remotely feasible.

> Small wrappers like binutils-{bpf,or1k-elf,...} are Built-Using:
> binutils-source.  As long as they build against latest binutils, there
> is no difference with building them from binutils.dsc.  But if/when
> they FTBFS, the failure does not involve unrelated maintainers.

In practice, the wrapper packages are always outdated and for or1k, you
wouldn't expect frequent FTBFS.

> On the other hand, some binutils-* packages keep an old copy the
> binutils source tarball, for example because the patches from the
> hardware vendor have not been rebased yet.  The Debian maintainers
> know very well that this is not ideal, but in this case sharing the
> source package is simply not an option.

For more exotic binutils - in particular those needing patches or older
versions - using a separate source package is reasonable. or1k does not
seem to fall into that category. All we need to do is change one line in
the binutils source package and be done.

Helmut



Bug#983657: debian-policy: weaken manual page requirement

2021-02-28 Thread Helmut Grohne
On Sun, Feb 28, 2021 at 11:58:08AM +0100, Bill Allombert wrote:
> On Sun, Feb 28, 2021 at 08:29:21AM +0100, Helmut Grohne wrote:
> > So this is actually asking for two distinct things:
> >  * Allow moving manual pages to dependencies
> >  * Allow demoting such dependencies to recommends
> > 
> > A possible wording in ch-docs.rst could be:
> >  Each program, utility, and function should have an associated manual
> > -page included in the same package. It is suggested that all
> > +page included in the same package or one of its dependencies or
> > +recommended packages. It is suggested that all
> >  configuration files also have a manual page included as well. Manual
> >  pages for protocols and other auxiliary things are optional.
> > 
> > What do you think?
> 
> The goal is to avoid program to be installed but not their manpages,
> so generally I do not find Recommends to be enough.

If we cannot build consensus around that second part, so be it. But
maybe the other part (moving manual pages to dependencies) can reach
consensus?

Helmut



  1   2   >