Bug#963670: RM: qgis [mipsel] -- ROM; Architecture specific issue

[Sebastiaan Couwenberg]

On 7/11/20 11:25 PM, Sean Whitton wrote:
> On Sat 11 Jul 2020 at 08:37PM +02, Sebastiaan Couwenberg wrote:
>>> Could you confirm this issue is not likely to get fixed anytime soon?
>>
>> 3.10.7+dfsg-1~exp1 FTBFS on eberlin, and 3.10.7+dfsg-1 FTBFS on
>> mipsel-manda-02, both had the same issue: "Error: branch out of range".
>>
>> 3.10.7+dfsg-1 was given back because it was part of the qt transition
>> and succeeded on mipsel-aql-01.
>>
>> I expect a subsequent binNMU or new upload to FTBFS again, so removing
>> qgis from mipsel is still a good idea in my opinion.
>>
>> If we're lucky mips* may not meet the architecture qualifications and be
>> removed for bullseye and this qgis not alway building successfully there
>> will become moot.
> 
> So, you'd say that the successful build was a random success, and it
> *usually* fails?  To be honest it seems odd to me remove something based
> on a random failure, but if it is much more often than not and you think
> the upstream issue is unlikely to get fixed soon, I will trust your
> judgement.

The removal was requested to not block the qt transition.

To be blunt, I have zero faith that the mips* architectures will become
first class citizens able to build complex packages like qgis & mapnik
like the other architectures any time soon.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature

Bug#958024: ITP: openapi-spec-validator -- OpenAPI Spec Validator is a Python library that validates OpenAPI Specs

[merkys]

Hi Joachim,

On 2020-07-11 19:56, Joachim Langenbach wrote:
> I uploaded the openapi-spec-validator package sources to 
> https://salsa.debian.org/jlaba/openapi-spec-validator. 
> 

Thanks a lot. I have a pair of questions/suggestions:

1. Why the Python package is named 'python3-openapi-spec-validator-dev' when 
setup.py gives 'openapi-spec-validator'? Naming policy of Python modules in 
Debian asks to name Python packages as closely to the original module name as 
possible (with 'python3-' prefix of course).

2. Git repository misses 'pristine-tar' and 'upstream' branches. Could you 
please push them as well? I would recommend setting up and using 'salsa push' 
to push all required stuff automagically to salsa.

3. Would you mind maintaining your package inside Debian Python Modules Team?

4. Finally, do you need a sponsor for your package?

Many thanks for working on packaging openapi-spec-validator!

Best,
Andrius

Bug#964915: raspi-firmware: upgrading kernel or firmware causes system to become unbootable on pi 4

[Andres Salomon]

Package: raspi-firmware
Version: 1.20200212-1
Severity: important

On a Raspberry Pi 4B using one of the brand new Pi 4 daily images, I
discovered that installing the firmware-misc-nonfree package would cause
the machine to not boot.

Further investigation found that during the package installation,
/boot/firmware/cmdline.txt was modified in the following manner:

-console=tty0 console=ttyS1,115200 root=LABEL=RASPIROOT rw elevator=deadline 
fsck.repair=yes net.ifnames=0 rootwait
+console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw elevator=deadline 
fsck.repair=yes net.ifnames=0 rootwait

After I changed this back to LABEL=RASPIROOT, the machine was able to boot
again. On the machine in question, there is no such block device:

dilinger@rpi4-20200710:~$ ls -l /dev/mmcblk0p2
ls: cannot access '/dev/mmcblk0p2': No such file or directory
dilinger@rpi4-20200710:~$ ls -lh /dev/mmcblk1p2 
brw-rw 1 root disk 179, 2 Feb 14  2019 /dev/mmcblk1p2

The culprit here is the following in /etc/kernel/postinst.d/z50-raspi-firmware:

cat >/boot/firmware/cmdline.txt <

Bug#963750: RM: chef -- ROM; trademark issues

[Jason Self]

Sean Whitton asked:
> On the other hand you say you think that we should remove the Chef
> package because there are not going to be future upstream releases
> which are free software.  Could you provide me a reference, please?

The problematic pieces appear to be contained within [0]. These two
points appear to eliminate freedom #2 [1] by making exact copies
impossible.

"You may redistribute the applicable Chef open source software under
the terms of the Apache 2.0 license, but you may not use the Chef
Marks in doing so without express written permission from Chef or as
expressly permitted in this Policy."

"We consider your compilation of our open source code into a
distribution for use in your business to be your distribution, not
Chef's distribution. Therefore, the resulting distribution must have
enough of the Chef Marks removed from the source code so as to not
confuse users as to the origin of the distribution."

[0] https://www.chef.io/trademark-policy/
[1] https://www.gnu.org/philosophy/


pgpdaPWYdPjYd.pgp
Description: OpenPGP digital signature

Bug#963761: [Pkg-javascript-devel] Bug#963761: Bug#963761: Bug#963761: node-node-sass: missing versioned dependency relation?: Sass could not find a binding for your current environment

[merkys]

On 2020-07-11 11:00, Jonas Smedegaard wrote:
> Reason I suspect upstream-only tracking is wrong is that also Debian 
> changes can change ABI - either deliberately or accidentally.  Most 
> notibly by adding/changing patches, but possibly also through changes to 
> build-dependencies.

Agree.

> I thought with node-expat I had mimiced the dpkg-shlibdeps resolved hint 
> for libnodeXX but I see now that I did that wrong: Currently that 
> dependency is upstream-only, but that is because the current 
> relationship is for a -1 release where the Debian part is stripped.
>
> I now issued a new node-expat with an improved logic.  Thanks!

I saw your changes in node-expat 2.3.18+ds-3. This is definitely an 
improvement, but having no upper bound on nodejs version will not prevent 
#963060 from happening again once in a while.

Best wishes,
Andrius




signature.asc
Description: OpenPGP digital signature

Bug#964914: live-build: Build for bullseye with security=true fails

[Ron Murray]

Package: live-build
Version: 1:20191221
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Build for bullseye with security=false works fine.
Build for security=true fails with:

> E: The repository 'http://security.debian.org bullseye/updates Release'
> does not have a Release file.

This is presumably because http://security.debian.org/dists/ contains
"bullseye-security" and not "bullseye". This appears to be a recent change.

- -- Package-specific info:

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

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

Versions of packages live-build depends on:
ii  debootstrap  1.0.123

Versions of packages live-build recommends:
ii  apt-utils   2.1.7
ii  bzip2   1.0.8-3
ii  cpio2.13+dfsg-2
ii  file1:5.38-5
ii  live-boot-doc   1:20190614
ii  live-config-doc 11.0.1
ii  live-manual 2:20151217.1
ii  live-manual-epub [live-manual]  2:20151217.1
ii  live-manual-html [live-manual]  2:20151217.1
ii  live-manual-odf [live-manual]   2:20151217.1
ii  live-manual-pdf [live-manual]   2:20151217.1
ii  live-manual-txt [live-manual]   2:20151217.1
ii  wget1.20.3-1+b2
ii  xz-utils5.2.4-1+b1

Versions of packages live-build suggests:
ii  e2fsprogs  1.45.6-1
ii  mtd-utils  1:2.1.1-1
ii  parted 3.3-4

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAl8KfMwOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52F0yg/5Adoryfv267uLrlbnFkRaGaFW0pRQn01cKvEp
i4+8xUFAxDanZFVF82JuIWe0d9MbdiLdFZtR9A4uRHTzpN9R+/C4ihjQlDD/5w1U
jCeDQ6E8do9kQWH4ARirmoSXNI+t98Bkb2f5wYJ3LNnzwQa0u/FoNWYzh1FxfKOT
6pqDdvRE7Jv58Y6GZHvMbSd0K9yc3hykWPvESw4CSRBPRvXStYkqNOt0TDf1i/EV
nOgOIO76Nm6iz1ZgU0dzJvewLNi1zBp15BaBbvsumcc1dz9h7i0uOWKDPgQrqGNE
IEKkiRBp9h/2MmFufO41L2EWR7zEfK9kZm1YZhZbNiLtoag3FEYFAw3+0pD6jXon
SP6yHy/lI+c3BYIfbm38amOdEtLX+tlylsytmPfgreA/PN62UxsxGvXeTWThme0g
xEcYIdzKImKcrvoVrt96JBD0UIxk1givmwUotD0PqlQ7TqufgubRga6BwxfZ+JI0
DKJ7Cbmi6iWWGbcwCSiQxX21GySCB8Bt4Y+ABMNt6oUE8EfNXfFWSC515iCKBZt/
IUMmN8v1VFIl4H9cslqifRRF3hjh2kFKwJ7M+IRvm5iwdO+y7/cWhHPSRzSFciNe
dHt+o/uP0SvY4UBssfX5kfa5SOol+kAMQTCRn4sPXIhet4jgfU7HrfAg1Bh+xoym
s+QM8KQ=
=fOlc
-END PGP SIGNATURE-

Bug#964913: plymouth: man: plymouth(8) refers to unexisting plymouth-set-theme(1)

[Romain Porte]

Package: plymouth
Version: 0.9.4-3
Severity: normal

Dear Maintainer,

On testing, the plymouth(8) man page refers to the non-existing
plymouth-set-theme(1) man page in the SEE ALSO section:

SEE ALSO
   grub(8), plymouth-set-theme(1), plymouthd(8), plymouth(1),
   http://www.freedesktop.org/wiki/Software/Plymouth

However this man page does not exist, nor the program it should cover. I
believe this is a typo as the plymouth-set-default-theme(1) man page
(and program) both exist.

Proposed solution would be to refer to plymouth-set-default-theme(1)
instead of plymouth-set-theme(1) in the plymouth(8) man page.

I have checked very last version upstream (git master branch) and the
fix seems to be already present, as plymouth(8) correctly refers to
plymouth-set-default-theme(1):

https://gitlab.freedesktop.org/plymouth/plymouth/-/blob/master/docs/plymouth.xml

Thanks in advance for your support,

Romain Porte.

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

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

Versions of packages plymouth depends on:
ii  init-system-helpers  1.58
ii  initramfs-tools  0.137
ii  libc62.30-8
ii  libdrm2  2.4.102-1
ii  libplymouth4 0.9.4-3
ii  lsb-base 11.1.0
ii  systemd  245.6-2
ii  udev 245.6-2

plymouth recommends no packages.

Versions of packages plymouth suggests:
ii  desktop-base 10.0.3
ii  plymouth-themes  0.9.4-3

-- Configuration Files:
/etc/plymouth/plymouthd.conf changed [not included]

-- no debconf information


signature.asc
Description: PGP signature

Bug#964188: bug chromium/83.0.4103.116-1~deb10u1

[Rob]

Just wanting to confirm there is a problem here.
Most people are complaining about YouTube -- I wanted to clarify this is 
happening on all websites that push a lot of data.  
I upgraded my Pi 4 x64 build and it sucked this horrible update in:  
chromium/83.0.4103.116-1~deb10u1
I noted Chromium just wasn't acting right almost instantly when  just waiting 
on it to load up and get going.
Thought there was a problem with my Internet, so I went to a speed test site 
and every time I clicked GO -- BOOM. 

I realize this is all development and have always generally had good luck -- 
with other platforms -- in the past.
Just purchased and setup  to find out updates are as bad if not worse than 
WIN10's abomination with their updates breaking everything.
Seriously -- doesn't anyone test these updates and patches before pushing them 
out? 


Happy to help test -- not happy that my test build breaks because of nothing I 
did wrong.  
I have hot spares of the OS ready to roll -- so really no big deal in my case.  
it is still not cool to be breaking people's builds

Rob

Bug#964912: github-backup: GitHub deprecated password authentication, please switch to token based authentication

[Paul Wise]

Package: github-backup
Version: 1.20170301-3+b1
Severity: important
Forwarded: 
https://github-backup.branchable.com/todo/GitHub_deprecated_basic_authentication_using_password/
 https://developer.github.com/changes/2020-02-14-deprecating-password-auth/

Whenever I use github-backup, I get a mail from GitHub saying that they
deprecated password authentication. The linked blog post says that by
November 2020, password authentication will be disabled. Since
authentication is almost essential to avoid the usage limits for
anonymous users, this will make github-backup fairly unusable soon.

https://developer.github.com/changes/2020-02-14-deprecating-password-auth/

   Hi @pabs3,

   On July 12th, 2020 at 01:41 (UTC) you used a password to access an
   endpoint through the GitHub API using github.hs/0.7.4:

   https://api.github.com/repositories/120820726/forks

Basic authentication using a password to the API is deprecated and
will soon no longer work. Visit 
https://developer.github.com/changes/2020-02-14-deprecating-password-auth/
 for more information around suggested workarounds and removal
dates.

Thanks,
The GitHub Team

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-1-nouveau-extra-crash-debug-info-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages github-backup depends on:
ii  git1:2.27.0-1
ii  libatomic1 10.1.0-4
ii  libc6  2.30-8
ii  libdouble-conversion3  3.1.5-5
ii  libffi73.3-4
ii  libgmp10   2:6.2.0+dfsg-6
ii  libstdc++6 10.1.0-4
ii  zlib1g 1:1.2.11.dfsg-2

github-backup recommends no packages.

github-backup suggests no packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#964911: incoming.debian.org: please publish dbgsym packages

[Paul Wise]

Package: ftp.debian.org
Severity: wishlist
User: ftp.debian@packages.debian.org
Usertags: archive

Please publish dbgsym packages in an apt repo on incoming.debian.org.

When upgrading to a newer version of a package from incoming.debian.org
while already having the package and its corresponding dbgsym package
installed, because the newer dbgsym package isn't yet available, I have
to purge the dbgsym package in order to upgrade the main package and
then I have to remember to reinstall the dbgsym package after the main
package reaches the archive and the dbgsym reaches the dbgsym archive.
Including dbgsym packages in incoming.d.o would avoid this dance.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#939481: cxxtest: diff for NMU version 4.4+git171022-1.1

[Sandro Tosi]

Control: tags 939481 + patch
Control: tags 939481 + pending


Dear maintainer,

I've prepared an NMU for cxxtest (versioned as 4.4+git171022-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru cxxtest-4.4+git171022/debian/changelog cxxtest-4.4+git171022/debian/changelog
--- cxxtest-4.4+git171022/debian/changelog	2018-11-25 05:33:15.0 -0500
+++ cxxtest-4.4+git171022/debian/changelog	2020-07-11 21:16:19.0 -0400
@@ -1,3 +1,10 @@
+cxxtest (4.4+git171022-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to python3; Closes: 939481
+
+ -- Sandro Tosi   Sat, 11 Jul 2020 21:16:19 -0400
+
 cxxtest (4.4+git171022-1) unstable; urgency=medium
 
   * New git snapshot release.

Bug#911560: u-boot: Very poor ethernet performance on A20 OLinuXino Lime2 Rev.G2

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2020-07-12 02:33:14)
> Quoting Jonas Smedegaard (2019-12-19 02:00:53)
> > Lime rev.H
> > --
> > 
> > * Uses Micrel PHY
> > * Sold (at least) as flash options
> > * Works in 10Mbit mode with Debian stable kernel and u-boot
> > * Should work in 1Gbit mode with Debian-backports kernel v5.2
> > * Should work in 1Gbit mode with custom kernel
> >   patched to to set CONFIG_MICREL_PHY=y (already done with Debian kernels)
> >   and to include 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3aed3e2
> >   (applied upstream since v5.2)
> 
> Recent u-boot adds an "errata 8688A fix" for Micrel KSZ8061 - 
> perhaps relevant for this issue...?
> 
> https://gitlab.denx.de/u-boot/u-boot/-/commit/baafd99

Seems this new errata fix is irrelevant, as the LIME2rev.H uses Micrel 
KSZ9031

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#739060: Download location do not work anymore

[Henrique de Moraes Holschuh]

Package: freepats
Version: 20060219-1
Followup-For: Bug #739060

New upstream location is:
http://freepats.zenvoid.org/

Direct substitude (needs .sf2 -> .pat conversion, most likely):
http://freepats.zenvoid.org/SoundSets/general-midi.html

The source for the old version is linked at that page.  It is archived
at: http://freepats.zenvoid.org/freepats-20060219.tar.xz

This is just for reference.

-- 
  Henrique Holschuh

Bug#964879: [request-tracker-maintainers] Bug#964879: request-tracker4: FTBFS: broken by libgnupg-interface-perl

[Andrew Ruthven]

Hmmm, this is likely a bug in libgnupg-interface-perl v1.00. It should
be able to work with both gpg v1 and v2.4, and certainly as I was
reviewing the packaging for v1.00 it certainly tries to.

Our RT v4.4.4 packages are forcing the use of gpg v1.

I'll have a look at libgnupg-interface-perl tonight.

Cheers,
Andrew

-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz  |
Catalyst Cloud:| This space intentionally left blank
   https://catalystcloud.nz|

Bug#964846: reportbug-gtk: mua xdg-email: does not work with the GTK UI

[Paul Wise]

On Sat, 2020-07-11 at 18:20 +0100, Simon McVittie wrote:

> Someone (probably Paul Wise? I lost track of the attribution) wrote:
> > > BTW, I think the GTK UI should not be running the MUAs under a VTE
> > > terminal unless the MUA is marked as needing a terminal. Same for any
> > > other commands it runs under a VTE terminal. For xdg-email probably
> > > most of the commands that runs don't need a terminal.

Yes, that was me.

> It might be safer to build a corresponding mailto:
> URI (which is desktop-agnostic and can be done in
> pure Python), and then pass it to whatever is the Python
> binding for g_app_info_launch_default_for_uri_async() (probably
> Gio.AppInfo.launch_default_for_uri_async() or similar).

I suggest adding that as a separate MUA to the xdg-email MUA and when
running with the reportbug GTK UI, make that new MUA the default MUA,
since people not using a terminal are even less likely to want
reportbug to submit to an MTA directly than most reportbug users.

> with 100% less shell script

Sadly, gio still uses a shell script to launch MUAs:

$ strace -f -e trace=execve gio open mailto:f...@bar.com |& grep execve | grep 
-v ENOENT
execve("/usr/bin/gio", ["gio", "open", "mailto:f...@bar.com;], 0x7ffcbf1e3a88 
/* 96 vars */) = 0
[pid 1476622] execve("/bin/sh", ["/bin/sh", "-e", "-u", "-c", "export 
GIO_LAUNCHED_DESKTOP_FILE"..., "sh", "evolution", "mailto:f...@bar.com;], 
0x558b45966000 /* 97 vars */) = 0
execve("/usr/bin/evolution", ["evolution", "mailto:f...@bar.com;], 
0x5607406853f8 /* 98 vars */) = 0

> there is no generic mechanism to choose a per-user or per-desktop
> preferred terminal emulator

This seems like something that should get added to xdg-utils?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#942946: apcupsd: diff for NMU version 3.14.14-3.1

[Sandro Tosi]

Control: tags 942946 + pending


Dear maintainer,

I've prepared an NMU for apcupsd (versioned as 3.14.14-3.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru apcupsd-3.14.14/debian/changelog apcupsd-3.14.14/debian/changelog
--- apcupsd-3.14.14/debian/changelog	2019-08-24 13:14:07.0 -0400
+++ apcupsd-3.14.14/debian/changelog	2020-07-11 20:36:12.0 -0400
@@ -1,3 +1,10 @@
+apcupsd (3.14.14-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch b-d from python-docutils to python3-docutils; Closes: #942946
+
+ -- Sandro Tosi   Sat, 11 Jul 2020 20:36:12 -0400
+
 apcupsd (3.14.14-3) unstable; urgency=medium
 
   * debian/control: bump standard to 4.3.0 (no changes)
diff -Nru apcupsd-3.14.14/debian/control apcupsd-3.14.14/debian/control
--- apcupsd-3.14.14/debian/control	2019-08-24 13:14:07.0 -0400
+++ apcupsd-3.14.14/debian/control	2020-07-11 20:31:45.0 -0400
@@ -12,7 +12,7 @@
 	, mawk | awk
 	, pkg-config
 	, po-debconf
-	, python-docutils
+	, python3-docutils
 	, tcpd
 	, texinfo
 # gconf shall disappear:	, libgtk2.0-dev

Bug#964910: RM: jigl -- ROM; dead upstream, low popcon, alternatives exist

[Nicholas Breen]

Package: ftp.debian.org
Severity: normal

Please remove jigl from the archive.  It has not had any upstream
activity since 2006, and has the lowest popcon count of all remaining
similar tools:

https://qa.debian.org/popcon-graph.php?packages=jigl%2C+llgal%2C+fgallery%2C+lazygal%2C+igal2%2C+imageindex_installed=on_legend=on_date=2010-01-01_date=_date=_fmt=%25Y=1


-- 
Nicholas Breen
nbr...@debian.org

Bug#911560: u-boot: Very poor ethernet performance on A20 OLinuXino Lime2 Rev.G2

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2019-12-19 02:00:53)
> Lime rev.H
> --
> 
> * Uses Micrel PHY
> * Sold (at least) as flash options
> * Works in 10Mbit mode with Debian stable kernel and u-boot
> * Should work in 1Gbit mode with Debian-backports kernel v5.2
> * Should work in 1Gbit mode with custom kernel
>   patched to to set CONFIG_MICREL_PHY=y (already done with Debian kernels)
>   and to include 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3aed3e2
>   (applied upstream since v5.2)

Recent u-boot adds an "errata 8688A fix" for Micrel KSZ8061 - 
perhaps relevant for this issue...?

https://gitlab.denx.de/u-boot/u-boot/-/commit/baafd99


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#964847: reportbug/mailer.py: xdg-email MUA encodes mailto URL instead of using xdg-email command-line parameters

[Paul Wise]

On Sat, 2020-07-11 at 13:10 +0200, Nis Martensen wrote:

> To be honest I don't see any point in doing this. xdg-email basically
> works by constructing a mailto URI from its command-line parameters and
> passing that to whatever else it invokes. Are you aware of anyone
> planning to rewrite xdg-email?

That is an internal implementation detail that cannot and should not be
relied on. It would be much cleaner to rely on the published interface
that xdg-email specifies that it provides.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#954827: dh-make-perl: please install packages using apt instead of dpkg -i when possible

[Paul Wise]

Control: retitle 964909 dh-make-perl: add support for installing with aptitude 
& dpkg -i and/or allow to set installation tool

On Sun, 2020-07-12 at 00:58 +0200, gregor herrmann wrote:

> I agree that "apt-get install" makes more sense than "dpkg -i"
> because of dependencies, and I've changed this in git now.

Thanks.

I'd like to suggest a few more fixes to this:

I see this uses the shell instead of exec because you are passing a
string instead of a list to system(). If the install_package function
ever gets passed a filename containing shell metacharacters, weird
things will happen.

When sudo isn't installed, the code will fail. I'd suggest also
allowing to use pkexec or su where possible. Here is some Python code
to do this. It takes an array and returns an array. You can use the
Perl File::Which module to replace the Python which function and the
Perl String::ShellQuote shell_quote function to replace the Python
shlex.quote function.

def root_cmd(cmd):
if which('sudo'):
return ['sudo'] + cmd
elif which('pkexec'):
return ['pkexec'] + cmd
elif which('su'):
return 'su -c'.split() + [' '.join([shlex.quote(arg) for arg in cmd])]
else:
return None

> I'm cloning the bug for the further possible change to add support
> for aptitude or for selecting tools etc.

There is probably still scope for using `dpkg -i` in some situations,
so I've retitled the bug to include that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)

[Johannes Schauer]

Control: tag -1 + patch

Hi Jessica,

Quoting Jessica Clarke (2020-07-12 00:54:53)
> Is this not the bug I fixed a while ago and you committed upstream
> recently[1]?  There hasn't been a dose3 upload to Debian yet with that fixed.
> 
> Jess
> 
> [1] 
> https://scm.gforge.inria.fr/anonscm/gitweb?p=dose/dose.git;a=commitdiff;h=226e7eb544bd02b128c19be5e79a9b236439159f

you are correct! With that patch, apt-cudf produces the correct conflicts
field.

I'll talk with Ralf about the next release.

Thanks!! :)

cheers, josch

signature.asc
Description: signature

Bug#964161: Bug#964145: fixed in chromium 83.0.4103.116-1~deb10u2

[mappu]

> I still see frequent crashes on 83.0.4103.116-1~deb10u2 after some short
> time using the browser, it crashes with no messages.

Sorry for the double-post, but as a quick follow-up - I can see in
Chromium's built-in Task Manager, that a "New Tab" is using a constant
25% CPU (maxed single core) with no extensions active, perhaps it's related.

Bug#964161: Bug#964145: fixed in chromium 83.0.4103.116-1~deb10u2

[mappu]

On Wed, 08 Jul 2020 20:32:15 + Debian FTP Masters wrote:
> Source: chromium
> Source-Version: 83.0.4103.116-1~deb10u2
> Done: Michael Gilbert
>
> We believe that the bug you reported is fixed in the latest version of
> chromium, which is due to be installed in the Debian FTP archive.

>

I still see frequent crashes on 83.0.4103.116-1~deb10u2 after some short
time using the browser, it crashes with no messages.

Bug#964560: RM: herbstluftwm [s390x] -- ROM; Never worked

[Christoph Egger]

Hi!

On Saturday 11 July 2020 23:28:06 CEST Sean Whitton wrote:
> control: tag -1 + moreinfo
> 
> Hello Christoph,
> 
> On Wed 08 Jul 2020 at 07:15PM +02, Christoph Egger wrote:
> > We recently enabled the testsuite for herbstluftwm. Unfortunately it
> > turns out it is far from run-able on s390x at the moment (and
> > probavbly never worked there). While I'm working with upstream on
> > fixing the issue (that also affects d-ports architectures) I'd like to
> > request removal from unstable for now especially as I guess window
> > managers are of limited use on s390x and the benefit of having the
> > fixes and tests in elsewhere is more important right now.
> 
> If you haven't yet determined for sure that the test failures indicate
> the package is never going to work on s390x, why not just disable the
> tests on that architecture for now?  Removal seems premature.

The problem is within the X11 protocol (and affects the other recent BE 64bit 
architectures as well). Without this sorted the software is pretty much 
useless.

Christoph

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

Bug#954975: dh-make-perl: add support for building in sbuild/pbuilder

[gregor herrmann]

On Thu, 26 Mar 2020 10:36:24 +0800, Paul Wise wrote:

> While recursively building & installing packages for CPAN modules that
> aren't yet in Debian I encountered some git related modules that failed
> to build on my system but when I built them in a clean chroot using
> pbuilder & cowbuilder they built fine. I think they might be
> incompatible with my personal git config or they might not be isolating
> themselves from external git configs well enough. Either issue is
> unlikely to be resolved any time soon, so it would be nice if there
> were support in dh-make-perl for building with pbuilder/sbuild or even
> other commands (for example build on another host via ssh).
> $ dh-make-perl --core-ok --recursive --build --install --cpan 
> Dist::Zilla::PluginBundle::DROLSKY

Thanks for this proposal.

While I see the value behind the idea, I think I shhould mention that
most people involved with dh-make-perl probably never use --build and
--install, because we want to create a rough source package which we
then polish before uploading, so my guess is that this feature
request won't be very high on anybody's TODO list without a patch
from someone who actually wants and uses it.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Kurt Ostbahn & die Chefpartie


signature.asc
Description: Digital Signature

Bug#954827: dh-make-perl: please install packages using apt instead of dpkg -i when possible

[gregor herrmann]

Control: clone -1 -2
Control: retitle -2 dh-make-perl: add support for installing with aptitude 
and/or allow to set installation tool
Control: found -2 0.109
Control: tag -1 + confirmed pending

On Tue, 24 Mar 2020 14:03:11 +0800, Paul Wise wrote:

> Modern apt supports installing local packages like this:
> 
>apt-get install ./foo.deb
> 
> It would be nice for dh-make-perl to support this (possibly also
> aptitude too). Some situations might require different install
> tools so an option might be best. Using apt has the advantage of
> installing any extra dependencies that already exist in the Debian
> archive instead of failing the install. Allowing for use of
> aptitude has the advantage of a much more flexible dependency
> resolver for complicated installs.

Nice catch, thanks.
I agree that "apt-get install" makes more sense than "dpkg -i"
because of dependencies, and I've changed this in git now.

I'm cloning the bug for the further possible change to add support
for aptitude or for selecting tools etc.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Kurt Ostbahn & die Chefpartie


signature.asc
Description: Digital Signature

Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)

[Jessica Clarke]

On 11 Jul 2020, at 23:47, Johannes Schauer  wrote:
> 
> Hi,
> 
> I put Jessica and Ralf in CC because they are the solver experts. :)
> 
> On Wed, 8 Jul 2020 18:27:54 +0200 Adam Borowski  wrote:
>> This problem can't possibly be caused by elogind.  A package may cause a
>> problem only if:
>> 1. some of its code is actually run (preinst, postinst, payload), or
>> 2. it's the first alternative and the solver uses "first alternative only"
>>   or is otherwise unable to use the full solutions space
>> 
>> The docs say:
>>'aspcud' resolver which (in contrast to apt and aptitude) is a real
>>solver (in the math sense) and will thus always find a solution if a
>>solution exists.
>> 
>> Given a set of packages A containing package X, if A - X contains a
>> solution, A with X also does -- ie, no relations declared by X (Breaks,
>> Conflicts, Depends, Provides, ...) may possibly invalidate that solution.
>> 
>> And we have:
>> * unstable: apt resolver, doesn't even consider libelogind0
>> * experimental: aspcud, supposed to be a full solver
>> 
>> Thus, it looks to me like a problem in apt-cudf, almost surely not in the
>> solver itself but in its integration with apt.
> 
> I managed to find out where the problem comes from. The problem is indeed not
> aspcud but apt-cudf. Apt transforms the problem into the EDSP format, and
> libelogind0 looks like this:
> 
> Package: libelogind0
> Architecture: amd64
> Version: 243.7-1+debian1
> APT-ID: 7784
> Multi-Arch: same
> Source: elogind
> Source-Version: 243.7-1+debian1
> Priority: optional
> Section: libs
> APT-Release:
> o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64
> APT-Pin: 500
> APT-Candidate: yes
> Depends: libc6 (>= 2.30), libcap2 (>= 1:2.10)
> Conflicts: libsystemd0, systemd
> Replaces: libsystemd0
> Provides: libsystemd0 (= 243.7)
> 
> That's all good and seems fine. It is then the job of apt-cudf to turn the 
> EDSP
> format into CUDF format which is understood by common CUDF solvers. And that's
> where things go wrong, because the CUDF stanza for libelogind0 reads:
> 
> package: libelogind0%3aamd64
> version: 23683
> depends: libc6%3aamd64 >= 16972 , libcap2%3aamd64 >= 25386
> conflicts: systemd%3aamd64 , --virtual-systemd%3aamd64 , systemd%3aamd64 , 
> --virtual-systemd%3aamd64 , libelogind0%3aamd64
> provides: libelogind0 , --virtual--versioned-libsystemd0%3aamd64 = 23682 , 
> --virtual-libsystemd0%3aamd64 = 2147483646
> installed: true
> priority: optional
> name: libelogind0
> architecture: amd64
> number: 243.7-1+debian1
> source: elogind
> sourcenumber: 243.7-1+debian1
> sourceversion: 23683
> replaces: libsystemd0 , --virtual-libsystemd0
> native: 1
> type: bin
> apt-pin: 500
> apt-id: 7784
> apt-candidate: true
> section: libs
> 
> Looking into the conflicts field, the conflict with libsystemd0 doesn't exist
> anymore. This explains why aspcud happily adds libelogind0 into the solution:
> because it wasn't told, that it conflicts with libsystemd0. If you want to 
> find
> out the above at home, just run sbuild with --build-deps-failed-commands=%s
> like so:
> 
>$ sbuild -d unstable --extra-repository='deb http://deb.debian.org/debian 
> experimental main' --extra-repository='deb-src http://deb.debian.org/debian 
> experimental main' --build-dep-resolver=aspcud 
> --build-deps-failed-commands=%s hplip_3.20.6+dfsg0-1
> 
> and then after build-deps failed to install, run the following to create an
> EDSP file:
> 
>$ APT_EDSP_DUMP_FILENAME=/tmp/dump.edsp apt-get install 
> --with-source=resolver-* --simulate --solver=dump -o 
> APT::Solver::Strict-Pinning=false sbuild-build-depends-main-dummy
> 
> You can then copy the EDSP file out of the schroot and put it into apt-cudf:
> 
>$ apt-cudf -v --solver=aspcud -c 
> "-count(solution,APT-Release:=/a=experimental/),-removed,-changed,-new" 
> /tmp/dump.edsp --dump
> 
> Using the --dump option you can also see the cudf translation. To save you the
> trouble, I put the EDSP file as an attachment to this mail.
> 
> Thanks!
> 
> cheers, josch

Is this not the bug I fixed a while ago and you committed upstream recently[1]?
There hasn't been a dose3 upload to Debian yet with that fixed.

Jess

[1] 
https://scm.gforge.inria.fr/anonscm/gitweb?p=dose/dose.git;a=commitdiff;h=226e7eb544bd02b128c19be5e79a9b236439159f

Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)

[Johannes Schauer]

Hi,

I put Jessica and Ralf in CC because they are the solver experts. :)

On Wed, 8 Jul 2020 18:27:54 +0200 Adam Borowski  wrote:
> This problem can't possibly be caused by elogind.  A package may cause a
> problem only if:
> 1. some of its code is actually run (preinst, postinst, payload), or
> 2. it's the first alternative and the solver uses "first alternative only"
>or is otherwise unable to use the full solutions space
>
> The docs say:
> 'aspcud' resolver which (in contrast to apt and aptitude) is a real
> solver (in the math sense) and will thus always find a solution if a
> solution exists.
>
> Given a set of packages A containing package X, if A - X contains a
> solution, A with X also does -- ie, no relations declared by X (Breaks,
> Conflicts, Depends, Provides, ...) may possibly invalidate that solution.
>
> And we have:
> * unstable: apt resolver, doesn't even consider libelogind0
> * experimental: aspcud, supposed to be a full solver
>
> Thus, it looks to me like a problem in apt-cudf, almost surely not in the
> solver itself but in its integration with apt.

I managed to find out where the problem comes from. The problem is indeed not
aspcud but apt-cudf. Apt transforms the problem into the EDSP format, and
libelogind0 looks like this:

Package: libelogind0
Architecture: amd64
Version: 243.7-1+debian1
APT-ID: 7784
Multi-Arch: same
Source: elogind
Source-Version: 243.7-1+debian1
Priority: optional
Section: libs
APT-Release:
 o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64
APT-Pin: 500
APT-Candidate: yes
Depends: libc6 (>= 2.30), libcap2 (>= 1:2.10)
Conflicts: libsystemd0, systemd
Replaces: libsystemd0
Provides: libsystemd0 (= 243.7)

That's all good and seems fine. It is then the job of apt-cudf to turn the EDSP
format into CUDF format which is understood by common CUDF solvers. And that's
where things go wrong, because the CUDF stanza for libelogind0 reads:

package: libelogind0%3aamd64
version: 23683
depends: libc6%3aamd64 >= 16972 , libcap2%3aamd64 >= 25386
conflicts: systemd%3aamd64 , --virtual-systemd%3aamd64 , systemd%3aamd64 , 
--virtual-systemd%3aamd64 , libelogind0%3aamd64
provides: libelogind0 , --virtual--versioned-libsystemd0%3aamd64 = 23682 , 
--virtual-libsystemd0%3aamd64 = 2147483646
installed: true
priority: optional
name: libelogind0
architecture: amd64
number: 243.7-1+debian1
source: elogind
sourcenumber: 243.7-1+debian1
sourceversion: 23683
replaces: libsystemd0 , --virtual-libsystemd0
native: 1
type: bin
apt-pin: 500
apt-id: 7784
apt-candidate: true
section: libs

Looking into the conflicts field, the conflict with libsystemd0 doesn't exist
anymore. This explains why aspcud happily adds libelogind0 into the solution:
because it wasn't told, that it conflicts with libsystemd0. If you want to find
out the above at home, just run sbuild with --build-deps-failed-commands=%s
like so:

$ sbuild -d unstable --extra-repository='deb http://deb.debian.org/debian 
experimental main' --extra-repository='deb-src http://deb.debian.org/debian 
experimental main' --build-dep-resolver=aspcud --build-deps-failed-commands=%s 
hplip_3.20.6+dfsg0-1

and then after build-deps failed to install, run the following to create an
EDSP file:

$ APT_EDSP_DUMP_FILENAME=/tmp/dump.edsp apt-get install 
--with-source=resolver-* --simulate --solver=dump -o 
APT::Solver::Strict-Pinning=false sbuild-build-depends-main-dummy

You can then copy the EDSP file out of the schroot and put it into apt-cudf:

$ apt-cudf -v --solver=aspcud -c 
"-count(solution,APT-Release:=/a=experimental/),-removed,-changed,-new" 
/tmp/dump.edsp --dump

Using the --dump option you can also see the cudf translation. To save you the
trouble, I put the EDSP file as an attachment to this mail.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#931195: flash-kernel: Add entry for Olimex A64-Olinuxino

[Vagrant Cascadian]

On 2020-07-09, Holger Wansing wrote:
> Jonas Smedegaard  wrote:
>> 2 months have passed by with this issue solved in git but no release.
>> 
>> What is missing for a release to happen?
>
>
> Any objections against such release? That would include:
>
>   [ Heinrich Schuchardt ]
>   * Add FriendlyARM NanoPi NEO Plus2. (Closes: #955374)
>
>   [ Vagrant Cascadian ]
>   * Add support for Pinebook Pro.
>
>   [ Adam Borowski ]
>   * Add support for Pinebook (Closes: #930098)
>
>   [ Sunil Mohan Adapa ]
>   * Add entry for Olimex A64-Olinuxino (Closes: #931195)
>   * Add entry for Olimex A64-Olinuxino-eMMC (Closes: #931195)
>
>   [ Josua Mayer ]
>   * add db entries for SolidRun LX2160A Honeycomb and Clearfog CX.
> (Closes: #958023)
>   * Add entries for SolidRun Cubox-i Solo/DualLite variants.
> (Closes: #939261)
>
>   [ Domenico Andreoli ]
>   * Add entry for Turris MOX (Closes: #961303)
>
>
> I could do a team upload under d-i team, if you want.

No objection from me; I daresay nobody else will probably object
either. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#964907: lightdm: fingerprint auth method buggy

[Benjamin Crawford]

Package: lightdm
Version: 1.30.0-0ubuntu3.1
Severity: normal

Dear Maintainer,

Observed behaviour:
When the fingerprint PAM authentication method is enabled and set-up (fprintd), 
lightdm first requests that the user swipe their fingerprint. While the 
fingerprint sensor is live,
the user still has the option to enter their password as standard. However, if 
the correct password is entered and submitted, the user will not be logged in. 
Instead, the dialog
will hang until the fingerprint sensor times out. Then, a timeout message will 
be displayed and the user will be required to re-enter their credentials.

Expected behaviour:
Once correct password has been entered, the fingerprint sensor is shut down, 
and the user is logged in immediately.

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

Kernel: Linux 5.4.0-40-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lightdm depends on:
ii  adduser3.118ubuntu2
ii  bash   5.0-6ubuntu1
ii  dbus   1.12.16-2ubuntu2.1
ii  debconf [debconf-2.0]  1.5.73
ii  dpkg   1.19.7ubuntu3
ii  libc6  2.31-0ubuntu9
ii  libgcrypt201.8.5-5ubuntu1
ii  libglib2.0-0   2.64.3-1~ubuntu20.04.1
ii  libglib2.0-bin 2.64.3-1~ubuntu20.04.1
ii  libpam-modules 1.3.1-5ubuntu4
ii  libpam-runtime 1.3.1-5ubuntu4
ii  libpam0g   1.3.1-5ubuntu4
ii  libxcb11.14-2
ii  libxdmcp6  1:1.1.3-0ubuntu1
ii  plymouth   0.9.4git20200323-0ubuntu6

Versions of packages lightdm recommends:
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.6-0ubuntu1
ii  xserver-xorg   1:7.7+19ubuntu14

Versions of packages lightdm suggests:
pn  bindfs  

-- debconf information:
  lightdm/daemon_name: /usr/sbin/lightdm
  shared/default-x-display-manager: lightdm

Bug#964906: initramfs can't boot a raid1 btrfs root volume

[Jason Michaelson]

Package: initramfs-tools
Verston 0.137

I just installed a system using the testing netinst cd image [Debian
GNU/Linux bullseye-DI-alpha2 _Bullseye_ - Official Snapshot amd64 NETINST
20200315-11:07]

After install, I converted my btrfs root partition to a raid1 profile, with
the understanding that the Debian installer doesn't support that out of the
box yet. The problem I've had is that while the initramfs does a btrfs
device scan before trying to mount the root file system, when the mount
command in the initramfs executes, the second device in the btrfs
filesystem goes unfound.

If I run a btrfs device scan from the initramfs shell i can mount the root
file system just fine and continue to boot into the installed operating
system.

If i add the script lines from the pre-mount btrfs scripts to the
local_mount_root() in  /usr/share/initramfs-tools/scripts/local right
before the mount command is executed the initramfs works correctly. I have
a hunch this isn't the right solution, despite the fact that it works and I
know that the btrfs device scan in the pre-mount btrfs script does in fact
get executed. I'm simply unsure what the correct solution actually is with
this.

if [ -x /bin/btrfs ]
then
modprobe btrfs ||:
# If asked to be quiet, show only errors
[ "${quiet}" = "y" ] && exec >/dev/null
/bin/btrfs device scan
fi

Bug#964247: qemu-kvm: 5.0-6 breaks macos guests

[Simon John]

From a git bisect, I've narrowed it down to this commit:

https://github.com/qemu/qemu/commit/5d971f9e672507210e77d020d89e0e89165c8fc9

which in terms of debian patches is:

+revert-memory-accept-mismatching-sizes-in-memory_region_access_valid-CVE-2020-13754.patch

Reported upstream: https://bugs.launchpad.net/qemu/+bug/1886318

Not sure how I'd build a new deb minus that patch, would i need to build 
all of these again:


qemu
qemu-block-extra
qemu-efi-aarch64
qemu-efi-arm
qemu-kvm
qemu-system
qemu-system-arm
qemu-system-common
qemu-system-data
qemu-system-gui
qemu-system-mips
qemu-system-misc
qemu-system-ppc
qemu-system-sparc
qemu-system-x86
qemu-utils

?

--
Simon John

Bug#949440: chromium: Blank window when used over ssh tunnel

[Ed Spiridonov]

Issue is still present in 83.0.4103.116-1~deb10u2

Screen is blank, but it looks like chromium works (window title is
changing and so on).

Bug#963750: RM: chef -- ROM; trademark issues

[Sean Whitton]

Hello again Antonio,

On Fri 26 Jun 2020 at 09:22AM -03, Antonio Terceiro wrote:

> As per #959981, Chef packages in Debian have trademark issues
> according to their upstream.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959981
>
> The claims are questionable, are argued by Steve Langasek in a
> corresponding Ubuntu bug.
>
> https://bugs.launchpad.net/chef/+bug/1877462
>
> However, Chef Inc. decided that Chef should no longer be free
> software/open source. I no longer intend to use or maintain Chef, and
> would like it to be removed from Debian.

I'm a bit confused here.  On the one hand you say that there's a
copyright issue, but reading the Ubuntu bug it seems that Ubuntu's
src:chef in fact contains cinc.  I take it Debian's doesn't?  In which
case the copyright issue would seem not to be a relevant reason for
removal?

On the other hand you say you think that we should remove the Chef
package because there are not going to be future upstream releases which
are free software.  Could you provide me a reference, please?  All I can
find online is that there is a new requirement to perform some renaming
in the contents of the package, not that new releases will be
DFSG-nonfree.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#964905: RFP: goatcounter -- easy, meaningful privacy-friendly web analytics

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: goatcounter
  Version : 1.3.1
  Upstream Author : Martin Tournoij 
* URL : https://www.goatcounter.com/
* License : EUPL 1.2
  Programming Lang: Golang
  Description : easy, meaningful privacy-friendly web analytics

GoatCounter is an open source web analytics platform available as a
hosted service (free for non-commercial use) or self-hosted app. It
aims to offer easy to use and meaningful privacy-friendly web
analytics as an alternative to Google Analytics or Matomo.

There are two ways to run this: as hosted service on goatcounter.com,
free for non-commercial use, or run it on your own server (the source
code is completely Open Source/Free Software, and it can be
self-hosted without restrictions).

Features:

 * Privacy-aware; doesn't track users with unique identifiers and
   doesn't need a GDPR consent notice. Also see the privacy policy.


 * Lightweight and fast; adds just ~5K (~2.5K compressed) of extra
   data to your site. Also has JavaScript-free "tracking pixel"
   option, or you can use it from your application's middleware.

 * Easy; if you've been confused by the myriad of options and
   flexibility of Google Analytics and Matomo that you don't need then
   GoatCounter will be a breath of fresh air.

 * Identify unique visits without cookies using a non-identifiable
   hash (technical details).

 * Keeps useful statistics such as browser information, location, and
   screen size. Keep track of referring sites and campaigns.

 * Accessibility is a high-priority feature, and the interface works
   well with screen readers, no JavaScript, and even text browsers
   (although not all features work equally well without JS).

 * 100% committed to open source; you can see exactly what the code
   does and make improvements.

 * Own your data; you can always export all data and cancel at any
   time.

 * Integrate on your site with just a single script tag

 * The JavaScript integration is a good option for most, but you can
   also use a no-JavaScript image-based tracker or integrate in your
   backend middleware.

 * Fast: can handle about 800 hits/second on a $5/month Linode VPS
   using the default settings.

 * Self-contained binary: everything – including static assets – is in
   a single ~7M statically compiled binary. The only other thing you
   need is a SQLite database file or PostgreSQL connection (no way
   around that).



There are many other analytics programs in Debian: goaccess, analog,
webalizer, and probably others. But goatcounter is unique in that it's
one of the few analytics programs that actually makes a genuine
attempt at somewhat anonymizing the data it collects.

I found this program through this LWN article:

https://lwn.net/Articles/822568/

It would be great if some other go team folks would take this on, but
otherwise I might just do it myself in my copious spare time.

It seems the packaging might take some work with dependencies, as
dh-make-golang took its sweet time to just fail with an error:

$ dh-make-golang estimate github.com/zgoat/goatcounter
go get: 25.17 MiBpackage github.com/zgoat/goatcounter/handlers: code in 
directory 
/tmp/dh-make-golang269924867/src/github.com/zgoat/goatcounter/handlers expects 
import "zgo.at/goatcounter/handlers"
go get: 221.47 MiBpackage github.com/zgoat/goatcounter/cmd/check
imports honnef.co/go/tools/code: cannot find package 
"honnef.co/go/tools/code" in any of:
/usr/lib/go-1.11/src/honnef.co/go/tools/code (from $GOROOT)
/tmp/dh-make-golang269924867/src/honnef.co/go/tools/code (from $GOPATH)
package github.com/zgoat/goatcounter/cmd/check
imports honnef.co/go/tools/facts: cannot find package 
"honnef.co/go/tools/facts" in any of:
/usr/lib/go-1.11/src/honnef.co/go/tools/facts (from $GOROOT)
/tmp/dh-make-golang269924867/src/honnef.co/go/tools/facts (from 
$GOPATH)go get: 261.54 MiBpackage github.com/zgoat/goatcounter/cmd/goatcounter
imports arp242.net/sconfig/handlers/html/template: unrecognized import 
path "arp242.net/sconfig/handlers/html/template" (parse 
https://arp242.net/sconfig/handlers/html/template?go-get=1: no go-import meta 
tags ())
2020/07/11 17:26:52 exit status 1

make fails in a similar way:

anarcat@emma:dist(master)$ dh-make-golang make github.com/zgoat/goatcounter
2020/07/11 17:27:29 Downloading "github.com/zgoat/goatcounter/..."
2020/07/11 17:27:40 Determining upstream version number
2020/07/11 17:27:40 Package version is "1.3.0+git20200711.37ad12d"
can't load package: package github.com/zgoat/goatcounter/handlers: code in 
directory 
/tmp/dh-make-golang955010176/src/github.com/zgoat/goatcounter/handlers expects 
import "zgo.at/goatcounter/handlers"
2020/07/11 17:27:41 Could not create a tarball of the upstream source: [go list 
-f {{.ImportPath}} {{.Name}} github.com/zgoat/goatcounter/...]: exit status 1

... and indeed, many packages in go.mod point at zgo.at, which 

Bug#964560: RM: herbstluftwm [s390x] -- ROM; Never worked

[Sean Whitton]

control: tag -1 + moreinfo

Hello Christoph,

On Wed 08 Jul 2020 at 07:15PM +02, Christoph Egger wrote:

> We recently enabled the testsuite for herbstluftwm. Unfortunately it
> turns out it is far from run-able on s390x at the moment (and
> probavbly never worked there). While I'm working with upstream on
> fixing the issue (that also affects d-ports architectures) I'd like to
> request removal from unstable for now especially as I guess window
> managers are of limited use on s390x and the benefit of having the
> fixes and tests in elsewhere is more important right now.

If you haven't yet determined for sure that the test failures indicate
the package is never going to work on s390x, why not just disable the
tests on that architecture for now?  Removal seems premature.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#963750: RM: chef -- ROM; trademark issues

[Antonio Terceiro]

Control: block -1 by 964889 964890 964891 964893 964894

On Sat, Jul 11, 2020 at 11:04:24AM -0700, Sean Whitton wrote:
> control: tag -1 +moreinfo
> 
> Hello,
> 
> On Fri 26 Jun 2020 at 09:48AM -03, Antonio Terceiro wrote:
> 
> > On Fri, Jun 26, 2020 at 09:22:09AM -0300, Antonio Terceiro wrote:
> >> ruby-knife-acl and ohai are part of the Chef ecosystem, and both have
> >> circular dependencies with chef. So, please remove the following source
> >> packages from unstable:
> >>
> >> - chef
> >> - ohai
> >> - ruby-knife-acl
> >
> > actually, please also remove chef-zero, ruby-cheffish, and
> > ruby-compat-resource. they are all part of the chef ecosystem and are
> > pointless without it.
> >
> > So the full list is:
> >
> > chef ohai ruby-knife-acl chef-zero ruby-cheffish ruby-compat-resource
> 
> We need separate RM bugs for each of these, please.

Done.

> Please remove the moreinfo tag from this bug when there are no more
> rdeps for chef itself.

Note however that as I said before ohai and ruby-knife-acl have circular
dependencies with chef so unless you are willing to leave broken
dependencies in the archive you will have to remove them together with
chef.


signature.asc
Description: PGP signature

Bug#964904: RFA: srt

[Federico Ceratto]

Package: wnpp
Severity: normal

I request an adopter or a co-maintainer for the srt package.

Description: Secure Reliable Transport UDP streaming library
 SRT is a latency-aware UDP transport mechanism optimized for video streams.
 It detects and compensates for jitter and bandwidth fluctuations due to
 network congestion. It mitigates packet loss and supports AES encryption.

Bug#963670: RM: qgis [mipsel] -- ROM; Architecture specific issue

[Sean Whitton]

Hello Sebastiaan,

On Sat 11 Jul 2020 at 08:37PM +02, Sebastiaan Couwenberg wrote:

> The FTBFS on mips64el is persistent, and qgis is already removed on that
> architecture via #953671.

Ah right.

>> Could you confirm this issue is not likely to get fixed anytime soon?
>
> 3.10.7+dfsg-1~exp1 FTBFS on eberlin, and 3.10.7+dfsg-1 FTBFS on
> mipsel-manda-02, both had the same issue: "Error: branch out of range".
>
> 3.10.7+dfsg-1 was given back because it was part of the qt transition
> and succeeded on mipsel-aql-01.
>
> I expect a subsequent binNMU or new upload to FTBFS again, so removing
> qgis from mipsel is still a good idea in my opinion.
>
> If we're lucky mips* may not meet the architecture qualifications and be
> removed for bullseye and this qgis not alway building successfully there
> will become moot.

So, you'd say that the successful build was a random success, and it
*usually* fails?  To be honest it seems odd to me remove something based
on a random failure, but if it is much more often than not and you think
the upstream issue is unlikely to get fixed soon, I will trust your
judgement.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#962239: RFP: jc -- converts command output to JSON

[Sudip Mukherjee]

Control: unblock -1 by 962505


On Sat, Jul 11, 2020 at 5:50 PM Kelly Brazil  wrote:
>
> Quick update - v1.12.1 fixes the tests when using an older version of 
> pygments.

Thanks Kelly.


--
Regards
Sudip

Bug#964818: Enable basic subvolume management for rootfs

[Cyril Brulebois]

Hi Nicholas,

Nicholas D Steeves  (2020-07-10):
> My plan is thus:
> 
> 1. After we have installation to subvolumes, add subvolume listing support to 
> the rescue cd.  This has the side-effect of being able to test "boot 
> environments" from the rescue cd.
> 2. Activate boot environment support via grub-btrfs (#941627).
> 3. Long-term: add debian-installer support for user-configurable subvolume 
> layout like Fedora and OpenSUSE have.  Ideally I'd like to work on this as 
> part of a btrfs-enablement team
> 
> Thanks,
> Nicholas
> 
> CCing Cyril for Kibi ACK :-)

Please don't block on me. I'd assume you have much more experience with
btrfs than I do, and I'm not really concerned about possible breakages
with that particular filesystem (upon checking, it appears it doesn't
even appear in the installation guide for some reason).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#964819: rsyncd fails to access some directories

[Samuel Henrique]

> Could you please check if the same issue happens with rsync 3.2.2-2 ?
> This package is currently in unstable and it will reach testing in
> about 24 hours.

I just noticed that 3.2.2-1 is on testing already, this is the first
package version to contain the fix, please update your system and
check if the issue persists.

Thanks,

-- 
Samuel Henrique 

Bug#964819: rsyncd fails to access some directories

[Samuel Henrique]

Hello Winfried,

Thank you for reporting this issue,

Could you please check if the same issue happens with rsync 3.2.2-2 ?
This package is currently in unstable and it will reach testing in
about 24 hours.

Alternatively, you can do the following to test:
comment out (or remove) the following line from
/lib/systemd/system/rsync.service:
"ProtectHome=on"

Then restart the service and see if the issue persists.

This is upstream's changelog entry for 3.2.2:
"The default systemd config was changed to remove the ProtectHome=on
setting since rsync is often used to serve files in /home and /root
and this seemed a bit too strict. Feel free to use systemctl edit
rsync to add that restriction (or maybe ProtectHome=read-only), if you
like. See the 3.2.0 NEWS for the other restrictions that were added
compared to 3.1.3."

Regards,

-- 
Samuel Henrique 

Bug#963247: ignition-fuel-tools FTBFS with Protobuf 3.12.3

[GCS]

Hi,

On Sat, Jul 11, 2020 at 5:53 PM  wrote:
> * Sebastian Ramacher  [2020-07-11 16:54]:
> So it should work if all migrate at the same time, right?
 It would work if all packages migrate at the same time. It will not
do that automatically however, as auto testing will constantly fail.
It tests with the testing version of ignition-fuel-tools and with the
unstable version of protobuf - being incompatible with each other.
I don't think a break of older protobuf libraries would help either,
but might help against partial upgrades of protobuf related packages.

> >This could be avoided if
> >libignition-msgs-dev which contains the protobuf-generated header files
> >would have a stricter dependency on libprotobuf-dev. Since these files
> >are only compatible with the same protobuf upstream version, it would
> >need to depend on the protobuf upstream version it was built with.
 That would prevent setting up the transition testing chroot, but I
don't know how our tools handle such things. I think preventing the
automatic protobuf transition to testing.

> There was a similar discussion in #900429 and also #910964 but no real
> solution was proposed. It would be great if the protobuf package would
> provide some tooling to encode the ABI information to the packages at
> compile time.
> What would be the way forward here? Open a bug with protobuf?
 Without too much thinking I've prepared an update which embeds an ABI
version to the library package (see attached diff) that you can depend
on, but I don't think that would help. It will be the same as
depending on the named library.

Regards,
Laszlo/GCS
diff -Nru protobuf-3.12.3/debian/changelog protobuf-3.12.3/debian/changelog
--- protobuf-3.12.3/debian/changelog	2020-07-08 00:47:38.0 +0200
+++ protobuf-3.12.3/debian/changelog	2020-07-11 21:37:49.0 +0200
@@ -1,3 +1,9 @@
+protobuf (3.12.3-3) unstable; urgency=medium
+
+  * Make libprotobuf provide protobuf-abi with soname version.
+
+ -- Laszlo Boszormenyi (GCS)   Sat, 11 Jul 2020 21:37:49 +0200
+
 protobuf (3.12.3-2) unstable; urgency=medium
 
   * Upload to Sid.
diff -Nru protobuf-3.12.3/debian/control protobuf-3.12.3/debian/control
--- protobuf-3.12.3/debian/control	2020-05-09 20:45:17.0 +0200
+++ protobuf-3.12.3/debian/control	2020-07-11 21:37:49.0 +0200
@@ -65,7 +65,7 @@
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Breaks: libarcus3 (<< 3.3.0-2), cura-engine (<< 1:3.3.0-2.1+b1)
+Provides: protobuf-abi-${pb:ABI}
 Description: protocol buffers C++ library
  Protocol buffers are a flexible, efficient, automated mechanism for
  serializing structured data - similar to XML, but smaller, faster, and
diff -Nru protobuf-3.12.3/debian/rules protobuf-3.12.3/debian/rules
--- protobuf-3.12.3/debian/rules	2020-05-09 20:45:17.0 +0200
+++ protobuf-3.12.3/debian/rules	2020-07-11 21:37:49.0 +0200
@@ -18,6 +18,7 @@
 endif
 
 SONAME=23
+ABI_VERSION=$(SONAME)-0
 
 %:
 	dh $@ --with autoreconf,elpa,python3
@@ -167,3 +168,6 @@
 override_dh_installdocs-indep:
 	dh_installdocs --indep
 	dh_installdocs -Xprotobuf-mode.el  # in protobuf-mode-el
+
+override_dh_gencontrol:
+	dh_gencontrol -- -Vpb:ABI=${ABI_VERSION}

Bug#962047: Bug#962318: libmojolicious-perl: build fails on IPv6-only buildds

[Niko Tyni]

On Mon, Jun 15, 2020 at 09:41:18PM +0300, Niko Tyni wrote:
> On Fri, Jun 12, 2020 at 06:58:15PM +0300, Niko Tyni wrote:
> 
> > I have not had the tuits yet for looking at IO::Socket::IP properly.
> > It seems to me that it could look at the address and pass AI_NUMERICHOST
> > to getaddrinfo(3) if it looks like an IPv4 address. I guess matching
> > against qr/^\d+\.\d+\.\d+\.\d+$/ would suffice.
> 
> Here's a first try at such a patch. Something like this might be
> a better fix for #962047 in libio-socket-ip-perl than the test suite
> change in 0.39-2.
> 
> I've only tested that libio-socket-ip-perl and libtest-tcp-perl build
> and work with this.

That patch was unfortunately buggy. I've since done further testing
and filed #964902 about the wider issue with a hopefully better patch.

So moving this discussion there.
-- 
Niko Tyni   nt...@debian.org

Bug#964876: RFP: nbsdgames -- collection of modern textual cross-platform games

[Hossein Bakhtiarifar]

Package: wnpp
Severity: wishlist

* Package name: nbsdgames
  Version : 3.0.0
  Upstream Author : Hossein Bakhtiarifar 
* URL : http://github.com/abakh/nbsdgames
* License : Public Domain, CC0
  Programming Lang: C
  Description : collection of modern textual cross-platform games

A collection of diverse textual games featuring AI, 2 player mode,
 flexible board size, color, mouse support etc.
.
It includes: battleship, checkers, fifteen, fisher, jewels, memoblocks,
 miketron, mines, muncher, pipes, rabbithole, redsquare, reversi, sos,
 sudoku.

It's a package of lightweight games like bsdgames, pacman4console, etc. It's
trivially easy to build (git clone->make) and has been ported to various other
OSes and packaged for other distros before.

Bug#964903: asql: Method and version fields are not populated when a log file is loaded

[Bat Bast]

Package: asql
Version: 1.6-1
Severity: important
Tags: patch upstream

Dear maintainer and author of the asql tool,

Method and version fields are not populated where asql load an apache
httpd logs file with Combined format.
Form 1.7 version on your personal web site, version field is OK, butmethod not
ok.
I produde a path from the debian version (1.6).

Many thanks for your good tool.



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

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

Versions of packages asql depends on:
ii  libdbd-sqlite3-perl1.64-1+b1
ii  libterm-readline-gnu-perl  1.36-2+b1

asql recommends no packages.

asql suggests no packages.

-- no debconf information
1388c1388
< my $version  = $results->{ 'proto' } || "";
---
> my $version  = $results->{ 'version' } || "";
1392c1392,1393
< my $protocol = $results->{ 'rtype' } || "";
---
> my $method  = $results->{ 'method' }  || "";
> #my $protocol = $results->{ 'rtype' } || "";
1396a1398
> 
1439,1440c1441,1442
< $sth->execute( $host, $path,  $code,  $size,
<$protocol, $refer, $agent, $version,
---
> $sth->execute( $host, $path,  $code,  $size, $method,
>   $refer, $agent, $version,

Bug#964902: libio-socket-ip-perl: AI_ADDRCONFIG breaks many test suites on IPv6-only hosts

[Niko Tyni]

Package: libio-socket-ip-perl
Version: 0.39-2
Severity: serious
Tags: patch ipv6

This is a follow-up for #962047 "fails to build on IPv6-only buildds".

The background here is that a while ago new official build daemons were
added that only have IPv6 connectivity, and this exposed a new class
of build failures, mainly due to getaddrinfo(3) behaviour with the
AI_ADDRCONFIG flag.

Quoting Julien Cristau there:

> FWIW, it seems IO::Socket::IP passes AI_ADDRCONFIG to getaddrinfo, which
> then doesn't return ipv4 addresses because the host doesn't have
> non-local ones, even though the address we're trying to resolve is
> "127.0.0.1".
> 
> Passing either GetAddrInfoFlags => AI_NUMERICHOST or GetAddrInfoFlags =>
> 0 to both IO::Socket::IP->new calls in the test file lets it pass, by
> turning off the smarts in getaddrinfo.

We fixed the test suite of libio-socket-ip-perl itself in 0.39-2 by
making it pass AI_NUMERICHOST in all the tests. However, it turns out
that the problem is much more widespread than this.

I've been testing systematically for these issues by test rebuilding
the whole archive, and found

1) 138 packages that failed to build on a host with an IPv6 address
   on a "real" interface, and IPv4 + IPv6 on lo, but no internet
   connection

2) 8 of those 138 also failed to build on a host with both an IPv6 address
   and an IPv4 address on a "real interface", still without a real internet
   connection (these are regular "needs internet" bugs, not IPv6 specific)

3) only 42 of the remaining 130 packages fail to build with the same setup
   as 1), after applying the patch discussed below to IO::Socket::IP.

So it looks like the AI_ADDRCONFIG default of IO-Socket-IP is causing
88 potential build failures on the new IPv6-only buildds. Examples of
those can be seen on for instance

 https://buildd.debian.org/status/logs.php?pkg=libmojolicious-perl

 https://buildd.debian.org/status/logs.php?pkg=libtest-redisserver-perl

 https://buildd.debian.org/status/logs.php?pkg=libwww-mechanize-perl

The attached patch changes IO-Socket-IP to pass AI_NUMERICHOST to
getaddrinfo(3) when the address looks like an IPv4 numeric address (rather
than a hostname), and special cases a PeerHost value of "localhost"
not to use AI_ADDRCONFIG.

I have tried quite a few variants, and this was the best I could do
without removing AI_ADDRCONFIG (which is a documented feature) altogether.
(TODO: The patch does not currently update the documentation about the
new behaviour.)

It would be good to get something like this upstream of course, and it
will also need to go in src:perl which has a copy of IO::Socket::IP.

I've tested that this makes libio-socket-perl pass its own test suite
without the modifications in 0.39-2, so this supersedes the current test
suite patch.

Build logs can currently (but not guaranteed indefinitely) be found at

 http://perl.debian.net/rebuild-logs/sid-v6only/

 http://perl.debian.net/rebuild-logs/experimental-v6only/

where the latter had a patched libio-socket-ip-perl package pre-installed
in the chroot.

Below is the list of packages detected as fixed by this. I'll bring up the
other IPv6-related build failures on the debian-devel list soonish. Bugs
have already been filed for the handful of "needs internet" issues.

alice_0.19-2
boxbackup_0.13~~git20200326.g8e8b63c-1
gdnsd_2.4.2-1
kgb-bot_1.56-1
libanyevent-connection-perl_0.06-5
libanyevent-connector-perl_0.03-2
libanyevent-memcached-perl_0.08-1
libanyevent-redis-perl_0.24-2
libapache2-authcookie-perl_3.30-1
libapache2-reload-perl_0.13-3
libapache-authenhook-perl_2.00-04+pristine-7
libapache-singleton-perl_0.17-1
libapache-ssllookup-perl_2.00-04-3
libapp-termcast-perl_0.13-3
libaudio-mpd-perl_2.004-2
libcgi-application-plugin-captcha-perl_0.04-2
libcgi-application-server-perl_0.063-2
libcorona-perl_0.1004-4
libcpan-mini-inject-perl_0.35-1
libcrypt-ssleay-perl_0.73.06-1
libdancer-perl_1.3513+dfsg-1
libdanga-socket-perl_1.62-1
libfcgi-engine-perl_0.22-1
libfurl-perl_3.13-2
libgearman-client-perl_2.004.015-1
libhtml-html5-parser-perl_0.301-2
libhttp-async-perl_0.33-1
libhttp-daemon-ssl-perl_1.05-01-2
libhttp-server-simple-mason-perl_0.14-2
libio-socket-ssl-perl_2.067-1
libio-socket-timeout-perl_0.32-1
libjson-validator-perl_3.25+dfsg-1
liblwp-protocol-https-perl_6.07-2
libmime-tools-perl_5.509-1
libmojolicious-perl_8.56+dfsg-1
libmojolicious-plugin-assetpack-perl_2.08-2
libmojolicious-plugin-authentication-perl_1.33-1
libmojolicious-plugin-authorization-perl_1.0302-2
libmojolicious-plugin-basicauth-perl_0.08-1
libmojolicious-plugin-bcrypt-perl_0.14-2
libmojolicious-plugin-cgi-perl_0.40-1
libmojolicious-plugin-i18n-perl_1.60-1
libmojolicious-plugin-mailexception-perl_0.20-1
libmojolicious-plugin-renderfile-perl_0.12-4
libmojo-sqlite-perl_3.003-1
libmonitoring-livestatus-perl_0.80-1
libnanomsg-raw-perl_0.10-1
libnet-facebook-oauth2-perl_0.12-1
libnet-http-perl_6.19-1
libnet-https-nb-perl_0.15-1
libnet-ldap-server-test-perl_0.22-1

Bug#964895: Cancel bug

[Felicia P]

Please cancel this bug.  The error was related to a non-standard pager 
being used for the 'man' command.

Bug#930620: diacli -- diaspora command line interface

[Paulo Henrique de Lima Santana]

control: retitle -1 RFP: diacli -- diaspora command line interface
control: noowner -1

I gave up to package it.

-- 
Paulo Henrique de Lima Santana (phls)
Curitiba - Brasil
Debian Developer
Diretor do Instituto para Conservação de Tecnologias Livres
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450



signature.asc
Description: OpenPGP digital signature

Bug#964901: UTF-8 BOM can be moved while editing

[Nils König]

Package: nano
Version: 3.2-3
Severity: normal

Dear Maintainer,

when editing a UTF8 file in nano that contains a BOM (efbbbf) and inserting a 
character at the beginning, the BOM bytes will move after the inserted 
character. This can lead to breakages when such a file is being parsed by a 
programm as a BOM should, if at all present, only occur at the very beginning 
of the file.
Ideally nano should detect the presence of BOM and not have it be 
editable/moveable.

I've confirmed that this also affects version 4.9.3-1 as currently packaged in 
sid.

The initial file with correct BOM:
$ head -n 1 sample.ass | xxd
: efbb bf5b 5363 7269 7074 2049 6e66 6f5d  ...[Script Info]
0010: 0a

After inserting a leading space with nano:
$ head -n 1 sample-nano.ass | xxd
: 20ef bbbf 5b53 6372 6970 7420 496e 666f   ...[Script Info
0010: 5d0a ].

When doing the same with vim instead:
$ head -n 1 sample-vim.ass | xxd
: efbb bf20 5b53 6372 6970 7420 496e 666f  ... [Script Info
0010: 5d0a ].


I've attached an sample-file with correct and incorrect utf8 bom.

Regards
Nils


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

Kernel: Linux 5.7.8-pc3+fs (SMP w/16 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: openrc
LSM: AppArmor: enabled

Versions of packages nano depends on:
ii  libc6 2.28-10
ii  libncursesw6  6.1+20181013-2+deb10u2
ii  libtinfo6 6.1+20181013-2+deb10u2
ii  zlib1g1:1.2.11.dfsg-1

nano recommends no packages.

Versions of packages nano suggests:
pn  spell  

-- no debconf information

[Script Info]
 [Script Info]
 [Script Info]

Bug#964898: buster-pu: package libpam-radius-auth/1.4.0-3~deb10u1

[Salvatore Bonaccorso]

Hi,

On Sat, Jul 11, 2020 at 09:35:32PM +0200, Salvatore Bonaccorso wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Hi
> 
> libpam-radius-auth is affected by CVE-2015-9542 (cf. #951396) in
> buster as well. A while ago Utkarsh Gupta prepared a QA update for
> unstable.
> 
> libpam-radius-pam should not be included in bullseye if there is not
> active maintainer, but for stable we can fix the CVE based on the
> upload in unstable (minus the packaging changes).
> 
> Attached the debdiff.

The correct debdiff attached now (with the packaging changes
reverted).

Regards,
Salvatore
diff -Nru libpam-radius-auth-1.4.0/debian/changelog 
libpam-radius-auth-1.4.0/debian/changelog
--- libpam-radius-auth-1.4.0/debian/changelog   2018-09-05 21:44:07.0 
+0200
+++ libpam-radius-auth-1.4.0/debian/changelog   2020-07-11 21:24:48.0 
+0200
@@ -1,3 +1,21 @@
+libpam-radius-auth (1.4.0-3~deb10u1) buster; urgency=medium
+
+  * Rebuild for buster.
+  * Revert packaging changes:
+- Lower Standards-Version to 4.2.0
+- Lower Debhelper compat level to 11   
+
+ -- Salvatore Bonaccorso   Sat, 11 Jul 2020 21:24:48 +0200
+
+libpam-radius-auth (1.4.0-3) unstable; urgency=medium
+
+  * QA upload
+  * Add patch to fix buffer overflow in password field.
+(Fixes: CVE-2015-9542) (Closes: #951396)
+  * Bump Standards-Version to 4.5.0 and dh-compat to 12
+
+ -- Utkarsh Gupta   Fri, 21 Feb 2020 15:47:11 +0530
+
 libpam-radius-auth (1.4.0-2) unstable; urgency=medium
 
   * QA upload.
diff -Nru libpam-radius-auth-1.4.0/debian/patches/CVE-2015-9542.fix 
libpam-radius-auth-1.4.0/debian/patches/CVE-2015-9542.fix
--- libpam-radius-auth-1.4.0/debian/patches/CVE-2015-9542.fix   1970-01-01 
01:00:00.0 +0100
+++ libpam-radius-auth-1.4.0/debian/patches/CVE-2015-9542.fix   2020-02-21 
10:52:32.0 +0100
@@ -0,0 +1,31 @@
+Description: This patch fixes CVE-2015-9542.
+Author: Justin Standring 
+Author: Utkarsh Gupta 
+Bug-Debian: https://bugs.debian.org/951396
+Origin: https://github.com/FreeRADIUS/pam_radius/commit/01173ec
+Origin: https://github.com/FreeRADIUS/pam_radius/commit/6bae92d
+Origin: https://github.com/FreeRADIUS/pam_radius/commit/ac2c1677
+Last-Update: 2020-02-21
+
+--- a/src/pam_radius_auth.c
 b/src/pam_radius_auth.c
+@@ -528,6 +528,9 @@
+   length = MAXPASS;
+   }
+ 
++  memcpy(hashed, password, length);
++  memset(hashed + length, 0, sizeof(hashed) - length);
++
+   if (length == 0) {
+   length = AUTH_PASS_LEN; /* 0 maps to 16 */
+   } if ((length & (AUTH_PASS_LEN - 1)) != 0) {
+@@ -535,9 +538,6 @@
+   length &= ~(AUTH_PASS_LEN - 1); /* chop it off */
+   }   /* 16*N maps to itself 
*/
+ 
+-  memset(hashed, 0, length);
+-  memcpy(hashed, password, strlen(password));
+-
+   attr = find_attribute(request, PW_PASSWORD);
+ 
+   if (type == PW_PASSWORD) {
diff -Nru libpam-radius-auth-1.4.0/debian/patches/series 
libpam-radius-auth-1.4.0/debian/patches/series
--- libpam-radius-auth-1.4.0/debian/patches/series  1970-01-01 
01:00:00.0 +0100
+++ libpam-radius-auth-1.4.0/debian/patches/series  2020-02-21 
11:13:05.0 +0100
@@ -0,0 +1 @@
+CVE-2015-9542.fix

Bug#964900: O: kytos-sphinx-theme -- Theme used by kytos with sphinx -- Python

[Paulo Henrique de Lima Santana (phls)]

Package: wnpp
Severity: normal

I intend to orphan the kytos-sphinx-theme package.
I no longer have time to maintain this.

The package description is:
 It is a sphinx theme to be used, for instance, into python-openflow
 documentation and others kytos projects.
 .
 This theme is part of Kytos project. Kytos is a SDN Platform made by Kytos
 Team.

Bug#964486: RM: initz -- RoQA; orphaned; dead upstream; alternatives exist

[Sean Whitton]

control: tag -1 + moreinfo

Hello,

On Tue 07 Jul 2020 at 09:56PM +02, Chris Hofstaedtler wrote:

> Package: ftp.debian.org
> Severity: normal
>
> Dear ftpmasters,
>
> please remove initz, an init files helper for emacsen.
>
> - Orphaned for 8+ years, no interest in the O bug
> - Last upstream release in 2003
> - There are other, more modern helpers for configuring emacs (at least
>   when I last used emacs a few years ago)
> - popcon numbers say there are 6 total installs

I had a look at the README for this package and I do not believe there
is actually something more modern which does what this package does --
was there something in particular you had in mind?

We still ship XEmacs in Debian, and given how much GNU Emacs and XEmacs
have diverged, it seems plausible that someone might want to use this
package to manage those differences.

It is worth noting that we don't ship more than one version of GNU Emacs
in the archive anymore, so if and when XEmacs leaves Debian, there would
seem to be little reason to keep this.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#964899: FTBFS: test suites fails with 1 failures, 8 errors

[Antonio Terceiro]

Source: ruby-net-dns
Severity: serious
Tags: ftbfs
Justification: fails to build from source

ruby-new-dns currently fails to build from source in unstable.

Several tests fail like this:

Error:
Minitest::Result#test_should_return_state_without_exception:
NoMethodError: undefined method `split' for ["192.168.100.1", 
"fe80::1%wlp2s0"]:Array
/<>/lib/net/dns/resolver.rb:1091:in `nameservers_from_name'
/<>/lib/net/dns/resolver.rb:357:in `rescue in block in 
nameservers='
/<>/lib/net/dns/resolver.rb:354:in `block in nameservers='
/<>/lib/net/dns/resolver.rb:351:in `each'
/<>/lib/net/dns/resolver.rb:351:in `nameservers='
/<>/lib/net/dns/resolver.rb:1062:in `parse_config_file'
/<>/lib/net/dns/resolver.rb:255:in `initialize'
/<>/test/unit/resolver_test.rb:79:in `new'
/<>/test/unit/resolver_test.rb:79:in 
`test_should_return_state_without_exception'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:98:in `block (3 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:195:in `capture_exceptions'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:95:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:270:in `time_it'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:94:in `block in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:211:in `with_info_handler'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:93:in `run'
/usr/lib/ruby/vendor_ruby/minitest/reporters.rb:44:in `run_with_hooks'
/usr/lib/ruby/vendor_ruby/minitest.rb:1029:in `run_one_method'
/usr/lib/ruby/vendor_ruby/minitest.rb:339:in `run_one_method'
/usr/lib/ruby/vendor_ruby/minitest.rb:326:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:325:in `each'
/usr/lib/ruby/vendor_ruby/minitest.rb:325:in `block in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
/usr/lib/ruby/vendor_ruby/minitest.rb:352:in `with_info_handler'
/usr/lib/ruby/vendor_ruby/minitest.rb:324:in `run'
/usr/lib/ruby/vendor_ruby/minitest.rb:164:in `block in __run'
/usr/lib/ruby/vendor_ruby/minitest.rb:164:in `map'
/usr/lib/ruby/vendor_ruby/minitest.rb:164:in `__run'
/usr/lib/ruby/vendor_ruby/minitest.rb:141:in `run'
/usr/lib/ruby/vendor_ruby/minitest.rb:68:in `block in autorun'

Full log attached.


ruby-net-dns_amd64-2020-07-11T19:33:26Z.build.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#964898: buster-pu: package libpam-radius-auth/1.4.0-3~deb10u1

[Salvatore Bonaccorso]

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

Hi

libpam-radius-auth is affected by CVE-2015-9542 (cf. #951396) in
buster as well. A while ago Utkarsh Gupta prepared a QA update for
unstable.

libpam-radius-pam should not be included in bullseye if there is not
active maintainer, but for stable we can fix the CVE based on the
upload in unstable (minus the packaging changes).

Attached the debdiff.

Can it be included in the next buster point release?

Regards,
Salvatore

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
diff -Nru libpam-radius-auth-1.4.0/debian/changelog 
libpam-radius-auth-1.4.0/debian/changelog
--- libpam-radius-auth-1.4.0/debian/changelog   2018-09-05 21:44:07.0 
+0200
+++ libpam-radius-auth-1.4.0/debian/changelog   2020-07-11 21:24:48.0 
+0200
@@ -1,3 +1,21 @@
+libpam-radius-auth (1.4.0-3~deb10u1) buster; urgency=medium
+
+  * Rebuild for buster.
+  * Revert packaging changes:
+- Lower Standards-Version to 4.2.0
+- Lower Debhelper compat level to 11   
+
+ -- Salvatore Bonaccorso   Sat, 11 Jul 2020 21:24:48 +0200
+
+libpam-radius-auth (1.4.0-3) unstable; urgency=medium
+
+  * QA upload
+  * Add patch to fix buffer overflow in password field.
+(Fixes: CVE-2015-9542) (Closes: #951396)
+  * Bump Standards-Version to 4.5.0 and dh-compat to 12
+
+ -- Utkarsh Gupta   Fri, 21 Feb 2020 15:47:11 +0530
+
 libpam-radius-auth (1.4.0-2) unstable; urgency=medium
 
   * QA upload.
diff -Nru libpam-radius-auth-1.4.0/debian/control 
libpam-radius-auth-1.4.0/debian/control
--- libpam-radius-auth-1.4.0/debian/control 2018-09-05 21:44:07.0 
+0200
+++ libpam-radius-auth-1.4.0/debian/control 2020-02-21 11:17:11.0 
+0100
@@ -2,8 +2,8 @@
 Maintainer: Debian QA Group 
 Section: admin
 Priority: optional
-Standards-Version: 4.2.0
-Build-Depends: libpam0g-dev | libpam-dev, debhelper-compat (= 11)
+Standards-Version: 4.5.0
+Build-Depends: libpam0g-dev | libpam-dev, debhelper-compat (= 12)
 Rules-Requires-Root: no
 Homepage: https://www.freeradius.org/pam_radius_auth/
 
diff -Nru libpam-radius-auth-1.4.0/debian/patches/CVE-2015-9542.fix 
libpam-radius-auth-1.4.0/debian/patches/CVE-2015-9542.fix
--- libpam-radius-auth-1.4.0/debian/patches/CVE-2015-9542.fix   1970-01-01 
01:00:00.0 +0100
+++ libpam-radius-auth-1.4.0/debian/patches/CVE-2015-9542.fix   2020-02-21 
10:52:32.0 +0100
@@ -0,0 +1,31 @@
+Description: This patch fixes CVE-2015-9542.
+Author: Justin Standring 
+Author: Utkarsh Gupta 
+Bug-Debian: https://bugs.debian.org/951396
+Origin: https://github.com/FreeRADIUS/pam_radius/commit/01173ec
+Origin: https://github.com/FreeRADIUS/pam_radius/commit/6bae92d
+Origin: https://github.com/FreeRADIUS/pam_radius/commit/ac2c1677
+Last-Update: 2020-02-21
+
+--- a/src/pam_radius_auth.c
 b/src/pam_radius_auth.c
+@@ -528,6 +528,9 @@
+   length = MAXPASS;
+   }
+ 
++  memcpy(hashed, password, length);
++  memset(hashed + length, 0, sizeof(hashed) - length);
++
+   if (length == 0) {
+   length = AUTH_PASS_LEN; /* 0 maps to 16 */
+   } if ((length & (AUTH_PASS_LEN - 1)) != 0) {
+@@ -535,9 +538,6 @@
+   length &= ~(AUTH_PASS_LEN - 1); /* chop it off */
+   }   /* 16*N maps to itself 
*/
+ 
+-  memset(hashed, 0, length);
+-  memcpy(hashed, password, strlen(password));
+-
+   attr = find_attribute(request, PW_PASSWORD);
+ 
+   if (type == PW_PASSWORD) {
diff -Nru libpam-radius-auth-1.4.0/debian/patches/series 
libpam-radius-auth-1.4.0/debian/patches/series
--- libpam-radius-auth-1.4.0/debian/patches/series  1970-01-01 
01:00:00.0 +0100
+++ libpam-radius-auth-1.4.0/debian/patches/series  2020-02-21 
11:13:05.0 +0100
@@ -0,0 +1 @@
+CVE-2015-9542.fix

Bug#964484: RM: aewm -- RoQA; orphaned; dead upstream; ftbfs with gcc-10; alternatives exist

[Sean Whitton]

control: tag -1 + moreinfo

Hello Chris,

On Tue 07 Jul 2020 at 09:46PM +02, Chris Hofstaedtler wrote:

> Package: ftp.debian.org
> Severity: normal
>
> Dear ftpmasters,
>
> please remove aewm:
> - has been orphaned for 8+ years, with no interest in the O bug
> - the previous Maintainer is also the upstream, homepage has disappeared
> - currently ftbfs with the coming gcc-10
> - we have enough other options for minimalist window managers, some of
>   them might also work with wayland in the future.
> - popcon tells me usage is virtually non-existent and never really was

The FTBFS has been fixed and it has a popcon of ~40 which does not seem
non-existent.  Is there other reason to think it isn't usable?  Have you
tried it out?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#964897: O: python-openflow -- low level library to parse OpenFlow messages

[Paulo Henrique de Lima Santana (phls)]

Package: wnpp
Severity: normal

I intend to orphan the python-openflow package.
I no longer have time to maintain this.

The package description is:
 If you want to read an OpenFlow packet from an open socket or send a message
 to an OpenFlow switch, this is your best friend. The main features are:
 high performance, latest specification compliance, short learning curve and
 free software license.
 .
 This library is part of Kytos project, a collaborative project between
 SPRACE (from São Paulo State University, Unesp) and Caltech (California
 Institute of Technology). python-openflow was developed to be used with
 Kytos controller, but feel free to use this simple and intuitive library
 in another project with another controller.

Bug#964896: O: kytos-utils -- command line utilities to use with Kytos

[Paulo Henrique de Lima Santana (phls)]

Package: wnpp
Severity: normal

I intend to orphan the kytos-utils package.
I no longer have time to maintain this.

The package description is:
 Command line interface (cli) for Kytos SDN Platform.
 .
 With these utilities you can interact with Kytos daemon and manage
 Network Applications (NApps) on your controller.

Bug#964476: RM: autounit -- RoQA; orphaned; dead upstream; unused

[Sean Whitton]

control: tag -1 + moreinfo

Hello,

On Tue 07 Jul 2020 at 08:56PM +02, Chris Hofstaedtler wrote:

> Package: ftp.debian.org
> Severity: normal
>
> Dear ftpmasters,
>
> please remove autounit:
> - it has been orphaned for 10 years, with no interest to pick it up
> - last QA upload was 5 years ago
> - its a development helper package, and nothing depends or build-depends
>   on it
> - upstream has vanished
>
> Given this is a development tool, and nothing needs it in Debian, I
> think it's safe to say this is an unused thing, and no new software will
> start using it. We can save our QA energy for other packages.

I'm not sure about this; the package is not getting in anyone's way, and
someone might find it useful.

May I ask whether you've written to autou...@packages.debian.org with
notice of the removal?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#964347: RM: biobambam2 [armel armhf i386] -- RoQA; build dependency libmaus2 is no longer available on 32bit

[Adrian Bunk]

Control: tags -1 - moreinfo

On Sat, Jul 11, 2020 at 12:08:56PM -0700, Sean Whitton wrote:
> control: tag -1 + moreinfo
> 
> Hello Adrian,

Hi Sean,

> On Sun 05 Jul 2020 at 11:30PM +03, Adrian Bunk wrote:
> 
> > Package: ftp.debian.org
> > Severity: normal
> >
> > See #934619 for background.
> 
> Seems like bcbio would be broken by this removal.
> 
> Please remove the moreinfo tag when rdeps are fixed.

bcbio is binary-all.

binary-all packages only have to build on amd64,
and it is acceptable when they are not installable
on all architectures.

> Sean Whitton

cu
Adrian

Bug#964895: d-feet man page hangs

[Felicia]

Package: d-feet
Version: 0.3.15-2
Severity: normal

Dear Maintainer,

When trying to view the d-feet man page with the command 'man d-feet'
the console hangs.  It is not even possible to Ctrl-c to kill the
process, the terminal window itself must be killed.


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

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages d-feet depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  gir1.2-glib-2.0  1.64.1-1
ii  gir1.2-gtk-3.0   3.24.20-1
ii  python3  3.8.2-3
ii  python3-gi   3.36.0-3

d-feet recommends no packages.

d-feet suggests no packages.

-- no debconf information

Bug#964891: RM: chef-zero -- ROM; trademark claims against chef

[Antonio Terceiro]

Package: ftp.debian.org
Severity: normal

Please remove chef-zero from Debian. It's part of the chef ecosystem,
which I also want to get removed, and is pointless without it.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963750 for
details.


signature.asc
Description: PGP signature

Bug#964468: RM: libifp -- RoQA; unmaintained; dead upstream; obsolete hardware

[Sean Whitton]

control: tag -1 + moreinfo

Hello Chris,

On Tue 07 Jul 2020 at 08:04PM +02, Chris Hofstaedtler wrote:

> Package: ftp.debian.org
> Severity: normal
>
> Dear ftpmasters,
>
> please remove libifp: communicate with iRiver iFP audio devices.
>
> It has not seen an upload for 9+ years, and is a support library for
> iRiver media players, which I haven't seen in years either.
>
> It does not seem to have any reverse dependencies.
>
> Looks like interest in support for the hardware is just gone.
> There's an open bug to switch to current libusb API, but obviously
> that's also not happening.

Have you written to lib...@packages.debian.org with notice of this
removal?

I'd like to ask you to remove the moreinfo tag from this bug once two
weeks have passed after writing to that address, so we can be sure
no-one wants to maintain it.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#964892: munin: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: munin
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#964888: src:python-cobra: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Source: python-cobra
Version: 0.14.2-2
Severity: serious
Control: close -1 0.18.0-3
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 961224

Dear maintainer(s),

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

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

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

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

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

Paul

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




signature.asc
Description: OpenPGP digital signature

Bug#964889: RM: ohai -- ROM; trademark claims against chef

[Antonio Terceiro]

Package: ftp.debian.org
Severity: normal

Please remove ohai from Debian. It's part of the chef ecosystem and has
a circular dependency with it.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963750 for the details


signature.asc
Description: PGP signature

Bug#964890: RM: ruby-knife-acl -- ROM; trademark claims against chef

[Antonio Terceiro]

Package: ftp.debian.org
Severity: normal

Please remove ruby-knife-acl from Debian. It's part of the chef
ecosystem and has a circular dependency with it.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963750 for the details



signature.asc
Description: PGP signature

Bug#964894: RM: ruby-compat-resource -- ROM; trademark claims against chef

[Antonio Terceiro]

Package: ftp.debian.org
Severity: normal

Please remove ruby-compat-resource from Debian. It's part of the chef
ecosystem, which I also want to get removed, and is pointless without
it.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963750 for
details.


signature.asc
Description: PGP signature

Bug#964893: RM: ruby-cheffish -- ROM; trademark claims against chef

[Antonio Terceiro]

Package: ftp.debian.org
Severity: normal

Please remove ruby-cheffish from Debian. It's part of the chef ecosystem,
which I also want to get removed, and is pointless without it.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963750 for
details.


signature.asc
Description: PGP signature

Bug#964347: RM: biobambam2 [armel armhf i386] -- RoQA; build dependency libmaus2 is no longer available on 32bit

[Sean Whitton]

control: tag -1 + moreinfo

Hello Adrian,

On Sun 05 Jul 2020 at 11:30PM +03, Adrian Bunk wrote:

> Package: ftp.debian.org
> Severity: normal
>
> See #934619 for background.

Seems like bcbio would be broken by this removal.

Please remove the moreinfo tag when rdeps are fixed.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#964887: heat: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: heat
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#964886: src:paramiko: fails to migrate to testing for too long: unresolved RC bug

[Paul Gevers]

Source: paramiko
Version: 2.6.0-2
Severity: serious
Control: close -1 2.7.1-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 960899

Dear maintainer(s),

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

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

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

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

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

Paul

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




signature.asc
Description: OpenPGP digital signature

Bug#963669: RM: python-numpy -- ROM; python2-only; superseeded by src:numpy; no rdeps

[Sandro Tosi]

> Just to explain the hold up, since there are rdeps, it needs an ftp team
> member with python2 transition-specific knowledge to process the
> removal.  So it might take a bit longer.

let me know if i can clarify some aspect of this removal; all the
remaining rdeps have been removed from testing because they are
already RC: removing numpy will just make them "more RC" but not "more
broken"; what i use to check it is:
http://sandrotosi.me/debian/py2removal/python-numpy_1.svg (green
border, not interesting; yellow-ish border, bin pkg from the same src
pkg)

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

Bug#964772: gem2deb: should not install mkmf.log files

[terceiro]

On Fri, Jul 10, 2020 at 10:38:59AM +0100, Chris Lamb wrote:
> Source: gem2deb
> Version: 1.1
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: toolchain buildpath
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
> 
> Hi,
> 
> Whilst working on the Reproducible Builds effort [0] we noticed that
> gem2deb was generating Debian packages that were not reproducible.
> 
> For example, ruby-enumerable-statistics was installing a mkmf.log file
> that contained various absolute build paths, which will make the package
> not reproducible.
> 
> I note that there is code already in gem2deb that attempts to not
> install these (?), but it does not appear to be working.

That's a different code path that this package and others that use
--gem-install don't hit.


> Patch
> attached, although this is just a proof of concept and/or to
> demonstrate the problem a little more.

I'll apply your patch, thanks.


signature.asc
Description: PGP signature

Bug#964051: RM: python-cjson -- ROM; python3 support missing, upstream MIA since a long time

[Sean Whitton]

Hello,

There's some activity upstream but no progress on their bug report for
python3 support, so I'll remove, but with a slightly amended removal reason.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#964885: RM: kerneloops/0.12+git20140509-6

[Adam D. Barratt]

Control: forcemerge 958576 -1

On Sat, 2020-07-11 at 21:49 +0300, Adrian Bunk wrote:
> The kerneloops package is no longer usable since the
> service http://oops.kernel.org is no longer available. (#953172)
> 
> It was already removed from buster. (#958575)

Merging with the existing request.

Regards,

Adam

Bug#964881: RM: getlive/2.4+cvs20120801-1

[Adam D. Barratt]

Control: forcemerge 959492 -1

On Sat, 2020-07-11 at 21:38 +0300, Adrian Bunk wrote:
> getlive is broken due to Hotmail changes (#950452)
> and was already removed from buster (#959491).

Merging with the existing request.

Regards,

Adam

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Sudip Mukherjee]

Hi Joan,

On Sat, Jul 11, 2020 at 10:46 AM Joan Moreau  wrote:
>
> Hello,
>
> I have read so many articles, but I do not find any clear explanation of what 
> I am doing wrong.
>
> I am running debmake / debbuild on the data I packed here : 
> https://grosjo.net/tb.tar.gz
>
>
>
> Can you help ?

Your Makefile is cloning two external github repo, but that is not
possible. The build servers will not have any network access. If you
need to depend on "uniqueinstance" and "kcontrols", then those two
needs to be in Debian before you can start your packaging.


-- 
Regards
Sudip

Bug#964885: RM: kerneloops/0.12+git20140509-6

[Adrian Bunk]

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

The kerneloops package is no longer usable since the
service http://oops.kernel.org is no longer available. (#953172)

It was already removed from buster. (#958575)

Bug#964884: gplaycli does not seem to be suitable for stable releases

[Adrian Bunk]

Package: gplaycli
Severity: serious

gplaycli in buster was broken by Google API changes (#950112)
and already removed (#958231).

This does not give confidence that the package in bullseye
can be kept working for the during the time bullseye is supported.

Bug#964883: RM: gplaycli/0.2.1-1

[Adrian Bunk]

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

gplaycli in buster was broken by Google API changes (#950112)
and already removed in the last buster point release (#958231).

I have confirmed that the older version in stretch is also nonfunctional.

Bug#964882: ITP: templating-maven-plugin - Copying files to an output directory

[Mechtilde Stehmann]

Package: wnpp
Severity: wishlist

* Package name : libtemplating-maven-plugin
  Version : 1.0.0
  Upstream Author : Name 
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description :  Copying files to an output directory

The templating maven plugin handles copying files from a source to a
given output directory, while filtering them. This plugin is useful to
filter Java Source Code if you need for example to have things in that
code replaced with some properties values.



* Why is this package useful/relevant?
* Is it a dependency for another package?

This is a dependency of jcabi-aspects which is a dependency of jlawyer.

* Do you use it yourself?
* If there are other packages providing similar functionality,
  how does it compare?
* How do you plan to maintain it? Do you plan to maintain it
  inside a packaging team?
  (check list at https://wiki.debian.org/Teams)

I want to maintain it in the java-team
* Are you looking for co-maintainers? Do you need a sponsor?

Kind regards

...--
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#964542: kdenlive: Segmentation fault at startup

[christophe . lohr]

Le 10/07/2020 à 15:43, Patrick Matthäi a écrit :
> this looks like a bug in your video driver or Qt5.
> But anyway I have just uploaded 20.04.3-1 to unstable. Could you give it
> a try? Maybe rebuilding against current libraries solves it..

Hi Patrick,
 Many thanks for your help. Unfortunately I still get the same issue
(segfault) with this new release, except that the gdb and the core file
report slightly different errors. Well, this seems to confirm that the
issue is probably due to Mesa or Qt5 libraries (how to check?). You
probably can close (or suspend) this ticket since there is no more else
to do from the kdenlive side but to expect some fix from mesa or qt side.

Best regards
Christophe

Core was generated by `kdenlive'.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Unexpected size of section `.reg-xstate/188984' in core file.
#0  0x7f7b6d314558 in ?? () from
/usr/lib/x86_64-linux-gnu/dri/iris_dri.so
[Current thread is 1 (Thread 0x7f7b169ca700 (LWP 188984))]
(gdb) bt
#0  0x7f7b6d314558 in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#1  0x7f7b6d315251 in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#2  0x7f7b6d4e05a4 in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#3  0x7f7b6d2f0b4d in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4  0x7f7b6d2f18bb in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#5  0x7f7b6c8812bb in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#6  0x55ed3bc5dc6c in  ()
#7  0x7f7b7ed1b6fe in  () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7f7b7feca6e3 in QQuickWindowPrivate::renderSceneGraph(QSize
const&, QSize const&) () at /lib/x86_64-linux-gnu/libQt5Quick.so.5
#9  0x7f7b7fe6f39b in  () at /lib/x86_64-linux-gnu/libQt5Quick.so.5
#10 0x7f7b7fe73837 in  () at /lib/x86_64-linux-gnu/libQt5Quick.so.5
#11 0x7f7b7eb11988 in  () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7f7b7dd6cf27 in start_thread (arg=)
    at pthread_create.c:479
#13 0x7f7b7e67131f in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb)

Bug#964881: RM: getlive/2.4+cvs20120801-1

[Adrian Bunk]

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

getlive is broken due to Hotmail changes (#950452)
and was already removed from buster (#959491).

Bug#964866: Acknowledgement (When upgrade from Stretch to Buster my development environment stop working and Arm (sama5d3) never mount his root on NFS) - Solved

[Daniel Smolik]

Dear maintainer,

please close the bug I found a solution. It looks like that Root on NFS 
require NFSv2. But on Buster is disabled.


To enable it add to /etc/default/nfs-kernel-server RPCNFSDOPTS="-V 2" 
and restart  /etc/init.d/nfs-kernel-server .


Regards

            Dan




--
Mydatex s r.o.
http://www.mydatex.cz
email: smo...@mydatex.cz
mob: 604200362

Bug#963670: RM: qgis [mipsel] -- ROM; Architecture specific issue

[Sebastiaan Couwenberg]

Control: tags -1 - moreinfo

Hi Sean,

On 7/11/20 8:03 PM, Sean Whitton wrote:
> On Thu 25 Jun 2020 at 06:00AM +02, Bas Couwenberg wrote:
> 
>> Please remove qgis from mipsel where it FTBFS due to architecture specific 
>> issues.
> 
> It looks like it FTBFS on mipsel64el not mipsel?

The FTBFS on mips64el is persistent, and qgis is already removed on that
architecture via #953671.

> Could you confirm this issue is not likely to get fixed anytime soon?

3.10.7+dfsg-1~exp1 FTBFS on eberlin, and 3.10.7+dfsg-1 FTBFS on
mipsel-manda-02, both had the same issue: "Error: branch out of range".

3.10.7+dfsg-1 was given back because it was part of the qt transition
and succeeded on mipsel-aql-01.

I expect a subsequent binNMU or new upload to FTBFS again, so removing
qgis from mipsel is still a good idea in my opinion.

If we're lucky mips* may not meet the architecture qualifications and be
removed for bullseye and this qgis not alway building successfully there
will become moot.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature

Bug#964848: sagemath: Integer objects leak memory

[Uoti Urpala]

I investigated this more, and came to the conclusion that Sage is
incompatible with libgmp 6.2 due to the following commit:

https://gmplib.org/repo/gmp-6.2/rev/299ec6187305

This invalidates the assumptions Sage's rings/integer.pyx makes about
libgmp internals. The "global_dummy_Integer" object created there
without an explicit value will now be created using libgmp's new lazy
allocation, and Sage's fast_tp_new() forcibly changing the _mp_d member
of such an object to a new allocation will lead to an inconsistent
state (allocation size still set to 0, but non-dummy pointer set). This
causes libgmp to disregard the existing pointer and leak the memory
when setting a new value in the object.

I believe (haven't tested though) that a quick workaround would be to
change

global_dummy_Integer = Integer()
to 
global_dummy_Integer = Integer(1)
which would force the global default object to use non-lazy allocation.

Bug#964880: [Pkg-javascript-devel] Bug#964880: npm: test failures in ppc64el and s390x

[Xavier]

Control: forcemerge -1 964854
Control: forwarded 964854 https://github.com/npm/cli/issues/1455

Le 11/07/2020 à 19:54, Gianfranco Costamagna a écrit :
> Source: npm
> Version: 6.14.6+ds-1
> Severity: serious
> 
> Hello, looks like one test is failing on ppc64el and s390x.
> Could you please have a look?
> 
> this on s390x
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/n/npm/20200711_092356_eb5fd@/log.gz
> # Subtest: test/tap/legacy-platform-all.js
> # Subtest: setup
> 1..0
> ok 1 - setup # time=2.926ms
> 
> # Subtest: platform-all
> not ok 1 - no error messages
>   ---
>   found: >
> npm ERR! code EBADPLATFORM
>   
> npm ERR! notsup Unsupported platform for 
> npm-test-platform-all@9.9.9-9: wanted
> 
> {"os":"darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd","arch":"arm,arm64,mips,ia32,x64,sparc"}
> (current: {"os":"linux","arch":"s390x"})
>   
> npm ERR! notsup Valid OS:   
> darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd
>   
> npm ERR! notsup Valid Arch:  arm,arm64,mips,ia32,x64,sparc
>   
> npm ERR! notsup Actual OS:   linux
>   
> npm ERR! notsup Actual Arch: s390x
>   
>   
> npm ERR! A complete log of this run can be found in:
>   
> npm ERR!
> 
> /tmp/autopkgtest.TwzxSV/autopkgtest_tmp/smokeh0DzIy/test/npm_cache_legacy-platform-all/_logs/2020-07-11T09_18_58_795Z-debug.log
>   wanted: ''
>   compare: ===
>   at:
> line: 55
> column: 7
> file: test/tap/legacy-platform-all.js
> type: global
> function: installCheckAndTest
>   stack: |
> installCheckAndTest (test/tap/legacy-platform-all.js:55:7)
> f (/usr/lib/nodejs/once/once.js:25:25)
> ChildProcess. (test/common-tap.js:175:5)
>   source: |
> t.is(stderr, '', 'no error messages')
>   ...
> 
> not ok 2 - install went ok
>   ---
>   found: 1
>   wanted: 0
>   compare: ===
>   at:
> line: 56
> column: 7
> file: test/tap/legacy-platform-all.js
> type: global
> function: installCheckAndTest
>   stack: |
> installCheckAndTest (test/tap/legacy-platform-all.js:56:7)
> f (/usr/lib/nodejs/once/once.js:25:25)
> ChildProcess. (test/common-tap.js:175:5)
>   source: |
> t.is(code, 0, 'install went ok')
>   ...
> 
> 1..2
> # failed 2 of 2 tests
> not ok 2 - platform-all # time=767.548ms
> 
> # Subtest: cleanup
> 1..0
> ok 3 - cleanup # time=1.651ms
> 
> 1..3
> # failed 1 of 3 tests
> # time=782.166ms
> not ok 103 - test/tap/legacy-platform-all.js # time=1350.563ms

Adding s390x to supported arch list is not enough, see
https://github.com/npm/cli/issues/1455 issue for more on s390x

> and this on ppc64el
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/ppc64el/n/npm/20200711_093200_7007f@/log.gz
> # Subtest: test/tap/legacy-platform-all.js
> # Subtest: setup
> 1..0
> ok 1 - setup # time=4.916ms
> 
> # Subtest: platform-all
> not ok 1 - no error messages
>   ---
>   found: >
> npm ERR! code EBADPLATFORM
>   
> npm ERR! notsup Unsupported platform for 
> npm-test-platform-all@9.9.9-9: wanted
> 
> {"os":"darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd","arch":"arm,arm64,mips,ia32,x64,sparc"}
> (current: {"os":"linux","arch":"ppc64"})
>   
> npm ERR! notsup Valid OS:   
> darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd
>   
> npm ERR! notsup Valid Arch:  arm,arm64,mips,ia32,x64,sparc
>   
> npm ERR! notsup Actual OS:   linux
>   
> npm ERR! notsup Actual Arch: ppc64
>   
>   
> npm ERR! A complete log of this run can be found in:
>   
> npm ERR!
> 
> /tmp/autopkgtest.RvsIrP/autopkgtest_tmp/smokevhVLkX/test/npm_cache_legacy-platform-all/_logs/2020-07-11T09_24_22_560Z-debug.log
>   wanted: ''
>   compare: ===
>   at:
> line: 55
> column: 7
> file: test/tap/legacy-platform-all.js
> type: global
> function: installCheckAndTest
>   stack: |
> installCheckAndTest (test/tap/legacy-platform-all.js:55:7)
> f (/usr/lib/nodejs/once/once.js:25:25)
>

Bug#963669: RM: python-numpy -- ROM; python2-only; superseeded by src:numpy; no rdeps

[Sean Whitton]

Hello,

On Thu 09 Jul 2020 at 05:14PM -04, Sandro Tosi wrote:

> Hello FTP Masters,
>
> On Wed, Jun 24, 2020 at 11:57 PM Sandro Tosi  wrote:
>>
>> Package: ftp.debian.org
>> Severity: normal
>>
>> cython has just been removed, and the remaining rdeps are not in testing as 
>> RC
>> for other reasons, so let's not wait on them
>
> can you please proceed with this removal? thanks!

Just to explain the hold up, since there are rdeps, it needs an ftp team
member with python2 transition-specific knowledge to process the
removal.  So it might take a bit longer.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#963670: RM: qgis [mipsel] -- ROM; Architecture specific issue

[Sean Whitton]

control: tag -1 +moreinfo

Hello Bas,

On Thu 25 Jun 2020 at 06:00AM +02, Bas Couwenberg wrote:

> Please remove qgis from mipsel where it FTBFS due to architecture specific 
> issues.

It looks like it FTBFS on mipsel64el not mipsel?

Could you confirm this issue is not likely to get fixed anytime soon?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#963750: RM: chef -- ROM; trademark issues

[Sean Whitton]

control: tag -1 +moreinfo

Hello,

On Fri 26 Jun 2020 at 09:48AM -03, Antonio Terceiro wrote:

> On Fri, Jun 26, 2020 at 09:22:09AM -0300, Antonio Terceiro wrote:
>> ruby-knife-acl and ohai are part of the Chef ecosystem, and both have
>> circular dependencies with chef. So, please remove the following source
>> packages from unstable:
>>
>> - chef
>> - ohai
>> - ruby-knife-acl
>
> actually, please also remove chef-zero, ruby-cheffish, and
> ruby-compat-resource. they are all part of the chef ecosystem and are
> pointless without it.
>
> So the full list is:
>
> chef ohai ruby-knife-acl chef-zero ruby-cheffish ruby-compat-resource

We need separate RM bugs for each of these, please.

Please remove the moreinfo tag from this bug when there are no more
rdeps for chef itself.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#964880: npm: test failures in ppc64el and s390x

[Gianfranco Costamagna]

Source: npm
Version: 6.14.6+ds-1
Severity: serious

Hello, looks like one test is failing on ppc64el and s390x.
Could you please have a look?

this on s390x
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/n/npm/20200711_092356_eb5fd@/log.gz
# Subtest: test/tap/legacy-platform-all.js
# Subtest: setup
1..0
ok 1 - setup # time=2.926ms

# Subtest: platform-all
not ok 1 - no error messages
  ---
  found: >
npm ERR! code EBADPLATFORM
  
npm ERR! notsup Unsupported platform for 
npm-test-platform-all@9.9.9-9: wanted

{"os":"darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd","arch":"arm,arm64,mips,ia32,x64,sparc"}
(current: {"os":"linux","arch":"s390x"})
  
npm ERR! notsup Valid OS:   
darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd
  
npm ERR! notsup Valid Arch:  arm,arm64,mips,ia32,x64,sparc
  
npm ERR! notsup Actual OS:   linux
  
npm ERR! notsup Actual Arch: s390x
  
  
npm ERR! A complete log of this run can be found in:
  
npm ERR!

/tmp/autopkgtest.TwzxSV/autopkgtest_tmp/smokeh0DzIy/test/npm_cache_legacy-platform-all/_logs/2020-07-11T09_18_58_795Z-debug.log
  wanted: ''
  compare: ===
  at:
line: 55
column: 7
file: test/tap/legacy-platform-all.js
type: global
function: installCheckAndTest
  stack: |
installCheckAndTest (test/tap/legacy-platform-all.js:55:7)
f (/usr/lib/nodejs/once/once.js:25:25)
ChildProcess. (test/common-tap.js:175:5)
  source: |
t.is(stderr, '', 'no error messages')
  ...

not ok 2 - install went ok
  ---
  found: 1
  wanted: 0
  compare: ===
  at:
line: 56
column: 7
file: test/tap/legacy-platform-all.js
type: global
function: installCheckAndTest
  stack: |
installCheckAndTest (test/tap/legacy-platform-all.js:56:7)
f (/usr/lib/nodejs/once/once.js:25:25)
ChildProcess. (test/common-tap.js:175:5)
  source: |
t.is(code, 0, 'install went ok')
  ...

1..2
# failed 2 of 2 tests
not ok 2 - platform-all # time=767.548ms

# Subtest: cleanup
1..0
ok 3 - cleanup # time=1.651ms

1..3
# failed 1 of 3 tests
# time=782.166ms
not ok 103 - test/tap/legacy-platform-all.js # time=1350.563ms


and this on ppc64el
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/ppc64el/n/npm/20200711_093200_7007f@/log.gz
# Subtest: test/tap/legacy-platform-all.js
# Subtest: setup
1..0
ok 1 - setup # time=4.916ms

# Subtest: platform-all
not ok 1 - no error messages
  ---
  found: >
npm ERR! code EBADPLATFORM
  
npm ERR! notsup Unsupported platform for 
npm-test-platform-all@9.9.9-9: wanted

{"os":"darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd","arch":"arm,arm64,mips,ia32,x64,sparc"}
(current: {"os":"linux","arch":"ppc64"})
  
npm ERR! notsup Valid OS:   
darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd
  
npm ERR! notsup Valid Arch:  arm,arm64,mips,ia32,x64,sparc
  
npm ERR! notsup Actual OS:   linux
  
npm ERR! notsup Actual Arch: ppc64
  
  
npm ERR! A complete log of this run can be found in:
  
npm ERR!

/tmp/autopkgtest.RvsIrP/autopkgtest_tmp/smokevhVLkX/test/npm_cache_legacy-platform-all/_logs/2020-07-11T09_24_22_560Z-debug.log
  wanted: ''
  compare: ===
  at:
line: 55
column: 7
file: test/tap/legacy-platform-all.js
type: global
function: installCheckAndTest
  stack: |
installCheckAndTest (test/tap/legacy-platform-all.js:55:7)
f (/usr/lib/nodejs/once/once.js:25:25)
ChildProcess. (test/common-tap.js:175:5)
  source: |
t.is(stderr, '', 'no error messages')
  ...

not ok 2 - install went ok
  ---
  found: 1
  wanted: 0
  compare: ===
  at:
line: 56
column: 7
file: test/tap/legacy-platform-all.js
type: global
function: installCheckAndTest
  stack: |
installCheckAndTest (test/tap/legacy-platform-all.js:56:7)
f 

Bug#964879: request-tracker4: FTBFS: broken by libgnupg-interface-perl

[Niko Tyni]

Source: request-tracker4
Version: 4.4.4-1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: libgnupg-interface-p...@packages.debian.org

This package fails its test suite with libgnupg-interface-perl_1.00-1,
which recently entered sid.

Many (but not all) of the test suite failures seem to be about 

  gpg: Invalid option "--pinentry-mode"

The build hangs in the end.

I assume this needs to be fixed in request-tracker4 rather than
libgnupg-interface-perl, but feel free to reassign of course.

Some excerpts:

  #   Failed test 'encrypted attachment'
  #   at t/crypt/gnupg/attachments-in-db.t line 38.
  
  #   Failed test 'correct content'
  #   at t/crypt/gnupg/attachments-in-db.t line 40.
  #  got: 'test'
  # expected: anything else
  
  #   Failed test 'no warnings'
  #   at /usr/share/perl/5.30/Test/Builder.pm line 152.
  # There were 3 warning(s)
  #   Previous test 0 ''
  #   gpg: Invalid option "--pinentry-mode"

[...]

  #   Failed test 'has key info.'
  #   at t/mail/gnupg-bad.t line 20.
  #  got: "\x{0a}\x{0a}\x{0a}  
\x{0a}>/t/tmp/mail-gnupg-bad.t-Vm133E7R/3-Modify.html
  
  #   Failed test 'no warnings emitted'
  #   at /<>/lib/RT/Test/Web.pm line 483.
  #  got: '1'
  # expected: '0'
  # got warning: gpg: Invalid option "--pinentry-mode"
  # Some tests failed or we bailed out, tmp directory 
'/<>/t/tmp/mail-gnupg-bad.t-Vm133E7R' is not cleaned
  # Looks like you failed 2 tests of 8.
  t/mail/gnupg-bad.t . 
  Dubious, test returned 2 (wstat 512, 0x200)
 
and so forth.
-- 
Niko Tyni   nt...@debian.org

Bug#964878: libgnupg-interface-perl: breaks monkeysphere-validation-agent

[Niko Tyni]

Package: libgnupg-interface-perl
Version: 1.00-1
Severity: serious
Affects: msva-perl, src:mod-gnutls
X-Debbugs-Cc: msva-p...@packages.debian.org, mod-gnu...@packages.debian.org

The new version of libgnupg-interface-perl breaks
/usr/bin/monkeysphere-validation-agent in msva-perl_0.9.2-1.

This also makes at least mod-gnutls fail to build in current sid.

Filing against libgnupg-interface-perl initially to prevent
accidental testing migration before this is solved.

  # monkeysphere-validation-agent 
  Insecure $ENV{PATH} while running with -T switch at 
/usr/share/perl5/GnuPG/Interface.pm line 336.
  Compilation failed in require at /usr/bin/monkeysphere-validation-agent line 
22.
  BEGIN failed--compilation aborted at /usr/bin/monkeysphere-validation-agent 
line 22.
  Use of uninitialized value $line in pattern match (m//) at 
/usr/share/perl5/GnuPG/Interface.pm line 808.
  Use of uninitialized value $a in split at /usr/share/perl5/GnuPG/Interface.pm 
line 822.
  Use of uninitialized value $a in split at /usr/share/perl5/GnuPG/Interface.pm 
line 822.
  GnuPG Version 1.4 or 2.2+ required at 
/usr/share/perl5/Crypt/Monkeysphere/MSVA.pm line 50.
  Compilation failed in require at /usr/bin/monkeysphere-validation-agent line 
22.
  BEGIN failed--compilation aborted at /usr/bin/monkeysphere-validation-agent 
line 22.
 
It would be good to have an autopkgtest check in msva-perl to spot
breakage such as this automatically.

-- 
Niko Tyni   nt...@debian.org

Bug#964378: libpod: Please upgrade to new upstream version 2.0

[Reinhard Tartler]

I've got some packages updated (mostly in experimental):

- golang-github-vbauerster-mpb_5.0.3-1_source.changes ACCEPTED into
experimental
- golang-github-openshift-api_4.0+git20190508.81d064c-4_source.changes
ACCEPTED into unstable
- golang-github-shirou-gopsutil_2.19.11-2_source.changes ACCEPTED into
unstable
- golang-github-opencontainers-selinux_1.5.1-2_source.changes ACCEPTED into
unstable
- golang-github-containers-storage_1.20.2-1_source.changes ACCEPTED into
experimental
- golang-github-containers-image_5.5.1-2_source.changes ACCEPTED into
experimental
- golang-github-containers-buildah_1.15.0-1_source.changes ACCEPTED into
experimental
- golang-github-containers-psgo_1.5.1-1_source.changes ACCEPTED into
unstable
- golang-github-gorilla-mux_1.7.4-1_source.changes ACCEPTED into unstable
- skopeo_1.1.0-1_source.changes ACCEPTED into experimental

I think most of those packages currently in experimental need coordinated
uploads
because of incompatible changes introduced
in golang-github-vbauerster-mpb_5.0.3-1. But for now,
I think we should be good to update libpod at least in experimental.

Best,
-rt

On Mon, Jul 6, 2020 at 7:36 AM Reinhard Tartler  wrote:

> Source: libpod
> Severity: wishlist
>
> Podman 2.0 is going to be supported in RHEL 8.3 long term and is thus a
> great candidate for inclusion into Debian bullseye. Let's try to get it
> packaged for debian.
>
> I've looked at https://github.com/containers/libpod/blob/v2.0/go.mod to
> understand what packages in Debian needs work for this new upstream.
>
> These packages needs packaging.  In some cases, it might make sense to
> keep the package vendored in the libpod source package. I would suggest
> to prioritize working on these packages:
>
>   github.com/hpcloud/tail v1.0.0 (NOT PACKAGED?)
>   github.com/gorilla/schema v1.1.0 (NOT PACKAGED?)
>   github.com/containers/common v0.14.3 (stuck in NEW)
>
>   github.com/cri-o/ocicni v0.2.0 (NOT PACKAGED?)
>   github.com/opencontainers/runtime-spec
> v1.0.3-0.20200520003142-237cc4f519e2 (NOT PACKAGED?)
>   github.com/uber/jaeger-client-go v2.24.0+incompatible (NOT
> PACKAGED)
>   github.com/uber/jaeger-lib v2.2.0+incompatible // indirect (NOT
> PACKAGED)
>
>
> These are dependencies that we have in debian but in an older
> version. This may or may not be required for podman 2.0, but updating
> them might be a good idea anyways:
>
>   github.com/containers/image/v5 v5.5.1 (have: 5.0.0)
>   github.com/containers/storage v1.20.2 (have: 1.15)
>   github.com/containers/buildah v1.15.0 (have 1.11.6)
>
>   github.com/containernetworking/cni
> v0.7.2-0.20200304161608-4fae32b84921 (have 0.7.1)
>   github.com/containers/conmon v2.0.18+incompatible (have 2.0.9)
>   github.com/containers/psgo v1.5.1 (have 1.4.0)
>   github.com/coreos/go-systemd/v22 v22.1.0 (have 22.0)
>   github.com/google/shlex v0.0.0-20181106134648-c34317bd91bf
> (have 0.0~git20150127)
>   github.com/gorilla/mux v1.7.4 (have 1.7.3)
>   github.com/onsi/ginkgo v1.13.0 (have 1.12.0)
>   github.com/onsi/gomega v1.10.1 (have 1.9.0)
>   github.com/opencontainers/image-spec
> v1.0.2-0.20190823105129-775207bd45b6 (have 1.0.1)
>
>   github.com/opencontainers/selinux v1.5.2 (have 1.3.1)
>   github.com/openshift/imagebuilder v1.1.6 // indirect (have
> 1.1.4)
>   github.com/opentracing/opentracing-go v1.1.0 (have 1.0.2)
>   github.com/seccomp/containers-golang v0.5.0 (have 0.3.2)
>   github.com/sirupsen/logrus v1.6.0 (have 1.3.0)
>   github.com/spf13/cobra v0.0.7 (have 0.0.5)
>   github.com/stretchr/testify v1.6.1 (have 1.4.0)
>   go.etcd.io/bbolt v1.3.5 (have 1.3.3)
>   gopkg.in/yaml.v2 v2.3.0 (have 2.2.2)
>
> These packages are already uptodate, no further action needed:
>
>   github.com/cyphar/filepath-securejoin v0.2.2 (have 0.2.2)
>   github.com/davecgh/go-spew v1.1.1 (have 1.1.1)
>   github.com/docker/distribution v2.7.1+incompatible (have 2.7.1)
>   github.com/docker/go-connections v0.4.0 (have 0.4.0)
>   github.com/docker/go-units v0.4.0 (have 0.4.0)
>   github.com/fsnotify/fsnotify v1.4.9 (have 1.4.9)
>   github.com/ghodss/yaml v1.0.0 (have 1.0.0)
>   github.com/godbus/dbus/v5 v5.0.3 (have: 5.0.3)
>   github.com/google/uuid v1.1.1 (have 1.1.1)
>   github.com/hashicorp/go-multierror v1.0.0 (have: 1.0.0)
>   github.com/json-iterator/go v1.1.10 (have 1.1.10)
>   github.com/mrunalp/fileutils v0.0.0-20171103030105-7d4729fb3618
> (have 0.0~git20200504)
>   github.com/opencontainers/go-digest v1.0.0 (have 1.0.0)
>   github.com/opencontainers/runtime-tools v0.9.0 (have 0.9.0)
>   github.com/pkg/errors v0.9.1 (have 0.9.1)
>   github.com/pmezard/go-difflib v1.0.0 (have 1.0.0)
>   

Bug#964846: reportbug-gtk: mua xdg-email: does not work with the GTK UI

[Simon McVittie]

On Sat, 11 Jul 2020 at 12:31:44 +0200, Nis Martensen wrote:
> At this point I think we need help from someone more familiar with VTE.
> Simon, do you know this stuff or do you know someone who we could ask?

Sorry, I don't know VTE in detail. What I know about VTE is whatever I
find that I need to learn if there is a gnome-terminal regression, and
I usually forget it soon after. I'd suggest trying the GTK/GNOME team
(debian-gtk-gnome mailing list) if you need more VTE or GTK knowledge.

Someone (probably Paul Wise? I lost track of the attribution) wrote:
> > BTW, I think the GTK UI should not be running the MUAs under a VTE
> > terminal unless the MUA is marked as needing a terminal. Same for any
> > other commands it runs under a VTE terminal. For xdg-email probably
> > most of the commands that runs don't need a terminal.

I agree, and this might be a better long-term solution to the problem. If
the GTK UI is launching an email client via xdg-email, it should probably
just run the script, without doing anything special like wrapping it
in a VTE terminal. I'm using mutt.desktop, which has Terminal=true,
in a GNOME desktop, and xdg-email correctly opens a new instance of
my configured terminal (gnome-terminal) and runs mutt inside that; it's
essentially launching it like a GUI application, which happens to be
implemented by combining a terminal with a TUI. So running xdg-email in
a terminal would be redundant.

Unfortunately, xdg-email is a maze of desktop-specific code paths, all
different. I would hope that the various desktop- and toolkit-specific
code paths have approximately the same behaviour as GNOME, because they
should all be using somewhat generic "launch this app" infrastructure,
which should do the right thing... but I can't guarantee that. The
open_generic code path, used on LXQT and Enlightenment, definitely
*doesn't* do the right thing for Terminal=true MUAs (I've opened #964877).

It might be safer to build a corresponding mailto:
URI (which is desktop-agnostic and can be done in
pure Python), and then pass it to whatever is the Python
binding for g_app_info_launch_default_for_uri_async() (probably
Gio.AppInfo.launch_default_for_uri_async() or similar). That ends up doing
the same thing as the GNOME 3, Cinnamon, etc. code path in xdg-email(1),
but with 100% less shell script, using only library code that is a hard
dependency for GTK anyway. This definitely *does* handle Terminal=true
MUAs correctly. The down side of this approach is that you get #773915,
because there is no generic mechanism to choose a per-user or per-desktop
preferred terminal emulator: in Debian we do have the x-terminal-emulator
alternative, but that's Debian-specific (which makes upstreams wary), and
isn't per-user or per-desktop (so if Alice prefers GNOME, and shares a
computer with Bob who prefers KDE, there is no setting for the
x-terminal-emulator alternative that will respect both their preferences).

smcv

Bug#964868: transmission 2.94-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964868 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: transmission
Version: 2.94-2+deb10u1

Explanation: fix possible denial of service issue [CVE-2018-10756]

Bug#964435: glib-networking 2.58.0-2+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964435 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: glib-networking
Version: 2.58.0-2+deb10u2

Explanation: break balsa older than 2.5.6-2+deb10u1 as the fix for 
CVE-2020-13645 breaks balsa's certificate verification

Bug#964435: glib-networking 2.58.0-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 964435 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: glib-networking
Version: 2.58.0-2+deb10u1

Explanation: return bad identity error if identity is unset [CVE-2020-13645]