Bug#961959: apt-show-versions: ensure cached files are world-readable

[McIntyre, Vincent (CASS, Marsfield)]

Package: apt-show-versions
Version: 0.22.11
Severity: normal
Tags: patch

Dear Maintainer,


when root has a restrictive umask, the files it writes in
/var/cache/apt-show-versions end up not being readable by
normal users, which is somewhat irritating.

The attached patch addresses this. It was inspired by
https://github.com/rickysarraf/apt-offline/pull/115

Kind regards
Vince


-- System Information:
Debian Release: 10.4
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-debug')
Architecture: amd64 (x86_64)

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

Versions of packages apt-show-versions depends on:
ii  apt  1.8.2.1
ii  libapt-pkg-perl  0.1.34+b1
ii  perl [libstorable-perl]  5.28.1-6

apt-show-versions recommends no packages.

apt-show-versions suggests no packages.

-- no debconf information

Bug#961957: librdkafka: Please stop disabling PIE

[Adrian Bunk]

Source: librdkafka
Version: 1.4.2-1
Severity: important
Tags: patch

PIE became default in the Debian gcc in stretch.

Before that explicitly enabling PIE in the hardening
options broke building shared libraries.

After that hardening=-pie disables the default PIE.
This is unwanted for many application, but more important
it breaks static libraries: They cannot be linked into
programs unless the program is built without PIE.

Fix:

--- debian/rules.old2020-05-31 04:30:21.498327888 +
+++ debian/rules2020-05-31 04:30:28.082322749 +
@@ -4,7 +4,7 @@
 #export DH_VERBOSE=1
 
 export DPKG_EXPORT_BUILDFLAGS=1
-export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow,-pie
+export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow
 include /usr/share/dpkg/buildflags.mk
 
 %:

Bug#961913: kmail: the access and reading of the received messages is often very slow

[Martin Steigerwald]

tags 961913 upstream
thanks

Dear Merlin.

merlin - 31.05.20, 14:01:27 CEST:
> Package: kmail
> Version: 4:20.04.1-1
> Severity: important
[…]
>  the access and reading of the received messages is often very slow a
> message appears
> "Reception of the content of the folder  please wait" Same problem for
> the trashing of messages.
> The CPU increase to 100%
> an akonadictl fsck or akonadictl vacuum does not improved .
> Its new

Thank you very much.

I recommend to create an upstream bug report at https://bugs.kde.org as 
well. It is an upstream bug which has nothing to do with the Debian 
packaging. Once you created it, please share a link to it to the Debian 
bug report.

However… first, please make sure you have some more information at hand 
that can help to debug the issue. Currently the only thing developers 
can do about your bug report is to ask for further information. Well or 
do nothing about it.

If it is your goal to see your issue fixed, then it is helpful to help 
the developer to help you by providing any information that may be 
helpful.

At the very least I'd include the following in the upstream bug report:

- Of course exact versions of the involved components.

- Your setup. So you use POP3 with local maildir or anything else? Which 
resources do you have configured and so on. Anything special settings you 
use?

- Start Akonadi from a shell window and report any log messages that may 
be related to the issue. Or state that you checked the log and there are 
none if that is the case. Of course redact as needed for privacy.

- Steps to reproduce the problem as best to your current knowledge.

- Detailed information on what happens on your system when you do those 
steps. 100% CPU usage is not very detailed. It would help already to 
know which processes are using the CPU. "pidstat", contained in package 
"sysstat", or atop can provide good insight on what is going on. You may 
even share an atop recording with 10 second interval if you feel 
comfortable with others knowing what processes ran on your system at 
that time. Otherwise I bet some lines of "pidstat" output will also do. 
Also when did the "Reception of the content of the folder, please wait" 
message appear? On clicking another folder while mail retrieval / 
filtering was still working in the background? Things like that.

- Is it a regression and if so since when? You wrote "It's new", but not 
since which version. For Debian the developer can guess it was 19.08, 
cause that was the previous version in Debian, however the upstream 
developers may not know about that. Also you could have upgraded from 
Debian Stable to Unstable and then the previous version would have been 
a much older one.

- Also I suggest to use the Akonadi component, if unsure just select 
Akonadi and do not specify a subsystem of it or set the subsystem to 
"general" or something like that. The upstream bug tracker is a bit more 
detailed on this.

So if you really like to see your issue fixed, I suggest you invest some 
additional time.

Also see:

"The body of the report" in https://www.debian.org/Bugs/Reporting

In the page there is the recommendation not to report upstream. I can 
say already that this is very, very likely an upstream bug, so you can 
help by creating an upstream report.

In case IMAP is involved also see:

How To Create Useful Bugreports for the Akonadi IMAP Resource

https://community.kde.org/PIM/Akonadi/Debug_IMAP

I thought there would be a generic bug reporting page for Akonadi, but I 
did not find one.

Thanks,
-- 
Martin

Bug#961958: librdkafka++1: Zero-size library on several architectures

[Adrian Bunk]

Package: librdkafka++1
Version: 1.4.2-1
Severity: grave
Tags: patch fixed-upstream
Forwarded: https://github.com/edenhill/librdkafka/pull/2874

https://buildd.debian.org/status/fetch.php?pkg=librdkafka&arch=amd64&ver=1.4.2-1&stamp=1589341196&raw=0

...
librdkafka++1_1.4.2-1_amd64.deb
...
-rw-r--r-- root/root 0 2020-05-13 03:17 
./usr/lib/x86_64-linux-gnu/librdkafka++.so.1
...

Bug#961907: ca-certificates: Remove expired mozilla/AddTrust_External_Root.crt

[Martin Bagge / brother]

On Mon, Jun 1, 2020 at 1:29 AM Axel Beckert  wrote:

> > You will need to workaround this. As such this motivates critical me
> think.
>
> I think "grave" is severe enough, as it "only" breaks HTTPS including
> apt with HTTPS-based mirrors (as the one mentioned above) and hence
> only "unrelated software/packages", not the whole system (like the
> kernel or the bootloader would do if the system won't boot anymore
> after an upgrade).
>

ok.
I read the description about unrelated software a bit differently indeed.
("makes unrelated software on the system (or the whole system) break, or
causes serious data loss, or introduces a security hole on systems where
you install the package.")


> > just doing a straight up curl will hang until timeout. With the expired
> > cert disabled this is bypassaed (without curl -k).
>
> Nope. curl exits immediately for me, at least in unstable (7.68.0-1):
>

Indeed. Sorry, me being inaccurate. I was testing this on old stable.
As you noted later on as well =)

Ack, stretch is affected, too, at least with lynx and — funnily again
> — curl (7.52.1-5+deb9u10).
>

Thanks for digging further into this issue.

Bug#961949: wrk FTCBFS: builds for the build architecture

[Helmut Grohne]

Hi Stephen,

On Sun, May 31, 2020 at 11:47:38PM -0500, Stephen Gelman wrote:
> I just published 4.1.0-3 which applies your changes. If you’d be willing to 
> point me in the right direction as to an easy way to reproduce the failures 
> you were seeing I’d be happy to dig into the luajit issues you are seeing. I 
> don’t have any experience cross-building packages (and minimal experience 
> cross-building in general) but I’m always happy to learn something new!

Thank you. Cross building Debian packages is relatively simple these
days. If you are using sbuild, you pass --host=$SOMEARCH and if you are
using pbuilder, you pass --host-arch $SOMEARCH. No special setup needed.
Another easy way is waiting a few days and checking
http://crossqa.debian.net/src/wrk to have it built by qa.

The luajit issue is none for the faint of heart unfortunately. The
luajit tool produces ELF objects containing the byte code when being
given the -b flag. Unfortunately, there doesn't seem to be a way to tell
luajit which architecture we need ELF objects for. So this issue needs
to be fixed on the luajit side first. It's not entirely clear whether
this can be fixed with reasonable effort, but having build logs that
show how this fails (such as wrk) makes it much easier to reason about
this on the luajit side. I suggest that you leave it as is unless you
look for a time sink.

I also think that luajit is wrongly marked Multi-Arch: foreign for this
reason.

Helmut

Bug#881719: libcdio 2.1.0 and lubcdio++

[Vasyl Gello]

Hi Gabriel!

>The package is now on mentors:
>
>https://mentors.debian.net/package/libcdio
>
>Balint, could you review it and, if everything is fine, sponsor it?
>(I'm asking because Vasyl mentioned you are guiding the packaging of
>Kodi, if I got it right)

Yes, you are correct. I also did upload two Kodi dependencies, but they are 
covered by separate
RFS.
-- 
Vasyl Gello

signature.asc
Description: PGP signature

Bug#961744: devscripts: uscan: please add capability to download gzipped content

[Xavier]

Le 31/05/2020 à 20:07, Gianfranco Costamagna a écrit :
> control: forcemerge 961744 -1
> 
>>
>> thanks, I'll look at this. Note that this is a server side bug: it
>> should not send compressed data if request doesn't specify
>> "Accept-Encoging: gzip"
>>
> 
> Hello, yes we know this is a server issue, but meh, we can't fix the internet 
> :)
> 
> Did you look at the patch in: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952738 ?
> 
> Not sure how and why, but the patch is really more trivial than my approach!
> 
> G.

Hi,

yes see
https://salsa.debian.org/debian/devscripts/-/merge_requests/196/diffs

Cheers,
Xavier

Bug#954444: Updated neomutt to 20200501 in salsa

[Don Armstrong]

I've update the packaging of neomutt to 20200501 to fix some annoying maildir 
sync
issues I've been facing.

Feel free to merge directly from https://salsa.debian.org/don/neomutt if
you'd like. [I'd create a merge request, but not sure if anyone is
following along with that.]

[I had to disable some of the tests which require a separate git repo;
not sure exactly how you all want to handle that.]

-- 
Don Armstrong  https://www.donarmstrong.com

"That is why I am still tyrant of [Ankh-Morpork]. The way to retain
power, I have always thought, is to ensure the absolute unthinkability
of oneself not being there."
 -- Terry Pratchett _Unseen Academicals_ p391

Bug#961940: libsqlite3-0:i386: trying to overwrite shared '/usr/share/doc/libsqlite3-0/changelog.gz', which is different […]

[GCS]

Control: tags -1 +pending

On Sun, May 31, 2020 at 9:45 PM Thorsten Glaser  wrote:
> On Sun, 31 May 2020, Thorsten Glaser wrote:
> > These files indeed differ:
> >
> > - a. Extending FTS5 → requires sqlite3_bind_pointer() to find the
> > + a. Extending FTS5 -> requires sqlite3_bind_pointer() to find the
 Ouch. Didn't expect character set conversion. First, locale setting
should be the same on all buildds and lynx should only dump the text.

> Fix looks trivial: adding…
>
> export LC_ALL:=C.UTF-8
>
> … after the first two lines of debian/rules ought to do the trick.
 I did local builds for i386 and amd64 to test if the generated
changelog - those were same. But it seems some buildds may use
somewhat different locale setting. Strange.

Thanks for the help,
Laszlo/GCS

Bug#961949: wrk FTCBFS: builds for the build architecture

[Stephen Gelman]

On May 31, 2020, at 12:41 AM, Helmut Grohne  wrote:
> 
> Source: wrk
> Version: 4.1.0-2
> Severity: minor
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> wrk fails to cross build from source, because it does not pass cross
> tools to make and the Makefile hard codes the build architecture
> pkg-config. An easy way to fix the former is using dh_auto_build. The
> attached patch fixes both. After applying it, wrk continues to fail
> cross building, because luajit still produces a build archtecture object
> file. It's not obvious how to fix that. However, it would help to see
> such failures in cross build logs. Therefore, I'm asking you to apply
> this partial solution to make the real issue more visible. Thanks for
> considering.
> 
> Helmut
> 

Helmut,

I just published 4.1.0-3 which applies your changes. If you’d be willing to 
point me in the right direction as to an easy way to reproduce the failures you 
were seeing I’d be happy to dig into the luajit issues you are seeing. I don’t 
have any experience cross-building packages (and minimal experience 
cross-building in general) but I’m always happy to learn something new!

Thanks,

Stephen

Bug#924290: [rfc] information about EFI partitions

[McIntyre, Vincent (CASS, Marsfield)]

On Fri, May 29, 2020 at 11:29:17PM +0200, Holger Wansing wrote:
>Hi,
>
>"McIntyre, Vincent (CASS, Marsfield)"  wrote:
>> diff --git a/en/appendix/preseed.xml b/en/appendix/preseed.xml
>> index d7570d6b3..817749bb9 100644
>> --- a/en/appendix/preseed.xml
>> +++ b/en/appendix/preseed.xml
>> @@ -1206,6 +1211,20 @@ d-i partman-auto/choose_recipe select atomic
>>  # system labels, volume group names and which physical devices to include
>>  # in a volume group.
>>
>> +## Partitioning for EFI
>> +# If your system needs an EFI partition you could add something like
>> +# this to the recipe above, as the first element in the recipe:
>> +#   538 538 1075 free  \
>> +#  $iflabel{ gpt } \
>> +#  $reusemethod{ } \
>> +#  method{ efi }   \
>> +#  format{ }   \
>> +#   .  \
>> +#
>> +# The fragment above is for the amd64 architecture; the details may be
>> +# different on other architectures. The 'partman-auto' package in the
>> +# D-I source repository may have an example you can follow.
>> +
>>  # This makes partman automatically partition without confirmation, provided
>>  # that you told it what to do using one of the methods above.
>>  d-i partman-partitioning/confirm_write_new_label boolean true
>> @@ -1213,6 +1232,16 @@ d-i partman/choose_partition select finish
>>  d-i partman/confirm boolean true
>>  d-i partman/confirm_nooverwrite boolean true
>>
>> +# Force UEFI booting ('BIOS compatibility' will be lost). Default: false.
>> +#d-i partman-efi/non_efi_system boolean true
>> +# Ensure the partition table is GPT - this is required for EFI
>> +#d-i partman-basicfilesystems/choose_label string gpt
>> +#d-i partman-basicfilesystems/default_label string gpt
>> +#d-i partman-partitioning/choose_label string gpt
>> +#d-i partman-partitioning/default_label string gpt
>> +#d-i partman/choose_label string gpt
>> +#d-i partman/default_label string gpt
>
>I might wonder why this is needed: to set the same setting in three different
>packages...
>However there seem to be a reason for this?
>

I went back and double-checked (this _was_ marked RFC...).
The partman/ questions don't appear to exist, doh! Sorry about that.

partman-basicfilesystems/{choose,default}_label
  refer to a +filesystem+ label, tsk. So shouldn't be needed either.

partman-partitioning/default_label
  has a platform-specific default that also depends on the disk size
  (packages/partman-partitioning/lib/disk-label.sh)

Revised patch below. I'll test it on amd64 and let you know
if it works.

Regards
Vince

diff --git a/en/appendix/preseed.xml b/en/appendix/preseed.xml
index d7570d6b3..9757883b3 100644
--- a/en/appendix/preseed.xml
+++ b/en/appendix/preseed.xml
@@ -1206,6 +1211,20 @@ d-i partman-auto/choose_recipe select atomic
 # system labels, volume group names and which physical devices to include
 # in a volume group.
 
+## Partitioning for EFI
+# If your system needs an EFI partition you could add something like
+# this to the recipe above, as the first element in the recipe:
+#   538 538 1075 free  \
+#  $iflabel{ gpt } \
+#  $reusemethod{ } \
+#  method{ efi }   \
+#  format{ }   \
+#   .  \
+#
+# The fragment above is for the amd64 architecture; the details may be
+# different on other architectures. The 'partman-auto' package in the
+# D-I source repository may have an example you can follow.
+
 # This makes partman automatically partition without confirmation, provided
 # that you told it what to do using one of the methods above.
 d-i partman-partitioning/confirm_write_new_label boolean true
@@ -1213,6 +1232,12 @@ d-i partman/choose_partition select finish
 d-i partman/confirm boolean true
 d-i partman/confirm_nooverwrite boolean true
 
+# Force UEFI booting ('BIOS compatibility' will be lost). Default: false.
+#d-i partman-efi/non_efi_system boolean true
+# Ensure the partition table is GPT - this is required for EFI
+#d-i partman-partitioning/choose_label string gpt
+#d-i partman-partitioning/default_label string gpt
+
 # When disk encryption is enabled, skip wiping the partitions beforehand.
 #d-i partman-auto-crypto/erase_disks boolean false
 

Bug#961873: [Pkg-javascript-devel] Bug#961873: npm2deb: Both node-$module and node-$module-$version get created, with two copies of debian dir

[Wookey]

Opps, spurious leftover line on end of patch in previous mail. This one should 
actually work.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
diff -Nru npm2deb-0.3.0/debian/changelog npm2deb-0.3.0/debian/changelog
--- npm2deb-0.3.0/debian/changelog	2020-04-30 15:06:06.0 +0100
+++ npm2deb-0.3.0/debian/changelog	2020-06-01 03:51:22.0 +0100
@@ -1,3 +1,10 @@
+npm2deb (0.3.0-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove initial directory if uupdate succeeds (Closes: #961873)
+
+ -- Wookey   Mon, 01 Jun 2020 02:51:22 +
+
 npm2deb (0.3.0-4) unstable; urgency=medium
 
   * Team upload
diff -Nru npm2deb-0.3.0/debian/patches/fix-961873-cleanup-initial-debian-dir.patch npm2deb-0.3.0/debian/patches/fix-961873-cleanup-initial-debian-dir.patch
--- npm2deb-0.3.0/debian/patches/fix-961873-cleanup-initial-debian-dir.patch	1970-01-01 01:00:00.0 +0100
+++ npm2deb-0.3.0/debian/patches/fix-961873-cleanup-initial-debian-dir.patch	2020-06-01 03:51:22.0 +0100
@@ -0,0 +1,25 @@
+Description: Remove initial temporary debian dir if uupdate succeeds
+Author: Wookey 
+Bug-Debian: https://bugs.debian.org/961873
+Last-Update: 2020-06-01
+
+--- npm2deb-0.3.0.orig/npm2deb/__init__.py
 npm2deb-0.3.0/npm2deb/__init__.py
+@@ -100,6 +100,9 @@ class Npm2Deb(object):
+ 
+ new_dir = '%s-%s' % (self.debian_name, self.upstream_version)
+ utils.change_dir('../%s' % new_dir)
++# copy over non-duplicate changelog
++_os.rename('../%s/debian/changelog' % self.debian_name, 'debian/changelog')
++_rmtree('../%s' % self.debian_name) 
+ self.run_buildpackage()
+ self.edit_changelog()
+ 
+--- npm2deb-0.3.0.orig/npm2deb/templates.py
 npm2deb-0.3.0/npm2deb/templates.py
+@@ -1,4 +1,4 @@
+-CHANGELOG = """%(debian_name)s (%(version)s-1) UNRELEASED; urgency=low
++CHANGELOG = """%(debian_name)s (%(version)s-1) UNRELEASED; urgency=medium
+ 
+   * Initial release (Closes: #)
+ 
diff -Nru npm2deb-0.3.0/debian/patches/series npm2deb-0.3.0/debian/patches/series
--- npm2deb-0.3.0/debian/patches/series	2020-04-30 15:04:16.0 +0100
+++ npm2deb-0.3.0/debian/patches/series	2020-06-01 03:51:22.0 +0100
@@ -2,3 +2,4 @@
 switch-install-to-pkg-js-tools.diff
 switch-to-debhelper-compat.diff
 fix-warnings.diff
+fix-961873-cleanup-initial-debian-dir.patch


signature.asc
Description: PGP signature

Bug#961873: [Pkg-javascript-devel] Bug#961873: npm2deb: Both node-$module and node-$module-$version get created, with two copies of debian dir

[Wookey]

On 2020-05-31 16:44 +0530, Pirate Praveen wrote:
> 
> This is a known issue, node-npm-run is temporary and used to create
> node-npm-run-5.0.1 with uscan and uupdate.
> node-npm-run should be deleted to avoid confusion.

OK. Attached is a patch to do this.

I don't write python so this may be less than idiomatic.

I decided to use 'did we cd into the new dir' as the 'it worked, so
the temp dir can be binned' test. You could test whether uupdate ran OK instead.

This is a bit fiddly because the cd is hidden inside a function which
does not pass back any status.

> > node-npm-run-5.0.1/debian/changelog had an extra copy of the stanza for
> > the same version:
> 
> This is added by uupdate.

OK, this is clearly wrong in terms of making a clean package. There
doesn't appear to be a uupdate command for 'don't make a new changelog
entry on update', not a debchange 'remove an entry' option. So after a
bit of thought the neatest way to deal with this seems to be to just
copy the original changelog-made-from-template into the final package
dir, then remove the original temp dir.

If we do this immediately after the chdir into the new dir then we can
be sure that uupdate worked and the new dir was created, so the old
one is no longer wanted.

debdiff attached, but the core of it is:
@@ -100,6 +100,9 @@ class Npm2Deb(object):
 
 new_dir = '%s-%s' % (self.debian_name, self.upstream_version)
 utils.change_dir('../%s' % new_dir)
+# copy over non-duplicate changelog
+_os.rename('../%s/debian/changelog' % self.debian_name, 'debian/ch
angelog')
+_rmtree('../%s' % self.debian_name) 
 self.run_buildpackage()
 self.edit_changelog()
 
(And change changelog template to say 'medium' as the default is no
longer 'low', unless you really do want all these packages to be
'low')

> > node-npm-run (5.0.1-1) UNRELEASED; urgency=medium
> > 
> >   *
> > 
> >  -- Wookey   Sat, 30 May 2020 16:09:20 +
> > 
> > node-npm-run (5.0.1-1) UNRELEASED; urgency=low
> > 
> >   * Initial release (Closes: #)
> > 
> >  -- Wookey   Sat, 30 May 2020 16:09:11 +


If you don't like the above approach for some reason then the
edit_changelog function could be made to tidy up if there are two
matching stanzas. Something along the lines of the below, but that
need saving the output of processes, and maybe copying result in/out
of pipes, which seems overkill, and is beyond my python-foo in the time
available.

Psuedocode for what needs doing:
# remove spurious repeat changelog entry if present
_call(
'parsechangelog --all | grep " %s (%s-1)" | wc -l' % self.name, 
self.upstream_version, shell=True)
if result = 2
_call(
"sed -i '1-6 d' debian/changelog", shell=True)

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
diff -Nru npm2deb-0.3.0/debian/changelog npm2deb-0.3.0/debian/changelog
--- npm2deb-0.3.0/debian/changelog	2020-04-30 15:06:06.0 +0100
+++ npm2deb-0.3.0/debian/changelog	2020-06-01 03:51:22.0 +0100
@@ -1,3 +1,10 @@
+npm2deb (0.3.0-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove initial directory if uupdate succeeds (Closes: #961873)
+
+ -- Wookey   Mon, 01 Jun 2020 02:51:22 +
+
 npm2deb (0.3.0-4) unstable; urgency=medium
 
   * Team upload
diff -Nru npm2deb-0.3.0/debian/patches/fix-961873-cleanup-initial-debian-dir.patch npm2deb-0.3.0/debian/patches/fix-961873-cleanup-initial-debian-dir.patch
--- npm2deb-0.3.0/debian/patches/fix-961873-cleanup-initial-debian-dir.patch	1970-01-01 01:00:00.0 +0100
+++ npm2deb-0.3.0/debian/patches/fix-961873-cleanup-initial-debian-dir.patch	2020-06-01 03:51:22.0 +0100
@@ -0,0 +1,25 @@
+Description: Remove initial temporary debian dir if uupdate succeeds
+Author: Wookey 
+Bug-Debian: https://bugs.debian.org/961873
+Last-Update: 2020-06-01
+
+--- npm2deb-0.3.0.orig/npm2deb/__init__.py
 npm2deb-0.3.0/npm2deb/__init__.py
+@@ -100,6 +100,9 @@ class Npm2Deb(object):
+ 
+ new_dir = '%s-%s' % (self.debian_name, self.upstream_version)
+ utils.change_dir('../%s' % new_dir)
++# copy over non-duplicate changelog
++_os.rename('../%s/debian/changelog' % self.debian_name, 'debian/changelog')
++_rmtree('../%s' % self.debian_name) 
+ self.run_buildpackage()
+ self.edit_changelog()
+ 
+--- npm2deb-0.3.0.orig/npm2deb/templates.py
 npm2deb-0.3.0/npm2deb/templates.py
+@@ -1,4 +1,4 @@
+-CHANGELOG = """%(debian_name)s (%(version)s-1) UNRELEASED; urgency=low
++CHANGELOG = """%(debian_name)s (%(version)s-1) UNRELEASED; urgency=medium
+ 
+   * Initial release (Closes: #)
+ 
diff -Nru npm2deb-0.3.0/debian/patches/series npm2deb-0.3.0/debian/patches/series
--- npm2deb-0.3.0/debian/patches/series	2020-04-30 15:04:16.0 +0100
+++ npm2deb-0.3.0/debian/patches/series	2020-06-01 03:51:22.0 +0100
@@ -2,3 +2,4

Bug#961954: lirc: Disable embedding of build path in documentation

[Vagrant Cascadian]

Source: lirc
Version: 0.10.1-6.2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in the generated documentation, which breaks
reproducibility when built from a different path.

The attached patch sets "FULL_PATH_NAMES = NO", which changes the
behavior to only embed the unique part of the filename.

There are other outstanding issues reproducibility issues, but applying
this patch makes it easier to identify and troubleshoot the remaining
issues.

Thanks for considering!

live well,
  vagrant

From 11911fc80b2772aa48f06cd8ab36a85bc2b52e59 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 1 Jun 2020 02:10:44 +
Subject: [PATCH] doc/Doxyfile: Do not embed build path in documentation.

Disable FULL_PATH_NAMES to make documentation builds reproducible.

---
 doc/Doxyfile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/Doxyfile b/doc/Doxyfile
index 1960b07..7997407 100644
--- a/doc/Doxyfile
+++ b/doc/Doxyfile
@@ -119,7 +119,7 @@ INLINE_INHERITED_MEMB  = NO
 # path before files name in the file list and in the header files. If set
 # to NO the shortest path that makes the file name unique will be used.
 
-FULL_PATH_NAMES= YES
+FULL_PATH_NAMES= NO
 
 # If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag
 # can be used to strip a user-defined part of the path. Stripping is
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#961953: devscripts: dch provides no way to remove a version stanza

[Wookey]

Package: devscripts
Version: 2.20.3
Severity: wishlist

It is recommended to manipulate changelog files with dch where
possible to avoid scripts and regexps in utilities that go out of
date. To fix bug #961873 it is necessary to remove the 2nd
copy of a version stanza, but I see that dch does not provide a
--delete option, which leaves seddery or other things that will
probably break one day.

I realise it's an uncommon case, but it seems to me that dch is the
right place for this functionality.

If you agree that this is functionality worth having I could try and knock up a 
patch. 

--
Wookey

Bug#961851: Processed: make-dfsg breaks cross-toolchain-base autopkgtest: debian/kernelarch.make:5: *** empty variable name

[Ben Hutchings]

On Sun, 2020-05-31 at 18:06 -0700, Manoj Srivastava wrote:
>   Error verifying signature: security library: improperly formatted 
> DER-encoded message. (-8183) - Decoder failed
> notfound 961851 make-dfsg/4.3-1
> thanks
> 
> Hi,
> 
> The file NEWS.Debian for make-dfsg states:
> ,
> >   * WARNING: Backward-incompatibility!
> > Previously appending using '+=' to an empty variable would result in a 
> > value
> > starting with a space.  Now the initial space is only added if the 
> > variable
> > already contains some value.  Similarly, appending an empty string does 
> > not
> > add a trailing space.
> `

It's pretty sad that make upstream keeps making incompatible changes
without a compelling reason for them.

> The bug lies here:
> ,[ debian/kernelarch.make ]
> > # Black-belt magic
> > , := ,
> > space :=
> > space +=
> > $(space) := 
> > $(space) +=
> `

Anyway, this is what Kbuild does; hopefully this hasn't broken too:

empty   :=
space   := $(empty) $(empty)

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer




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

Bug#951118: Current status

[Olivier Mehani]

Hey Evangelos,

Sorry for not replying earlier. I've had your email sitting in my inbox, 
but should have ACKed it. Busy times.


On Sun 31 May 2020 at 18:52:06 +0200, Evangelos Ribeiro Tzaras wrote:

i wanted to ask how the packaging is coming along.
I had previously written you an email and CC'ed the DebianOnMobile
maintainers mailinglist, but have not yet received an answer, so I
thought it would give it a try on this more public channel.


Unfortunately, I am a bit short on time at the moment, and haven't been 
able to get back to the packaging work so far.


Thank you for your comments, though, they are useful.  Unfortunately, 
I'm not sure when I'll get some time to act on them, If you are eager to 
see progress, please feel free to build upon my PR, and to sync with the 
main developer of the project.


--
Olivier Mehani 
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE  F5F9 F012 A6E2 98C6 6655
Confidentiality cannot be guaranteed on emails sent or received unencrypted.

Bug#961851: Processed: make-dfsg breaks cross-toolchain-base autopkgtest: debian/kernelarch.make:5: *** empty variable name

[Manoj Srivastava]

notfound 961851 make-dfsg/4.3-1
thanks

Hi,

The file NEWS.Debian for make-dfsg states:
,
|   * WARNING: Backward-incompatibility!
| Previously appending using '+=' to an empty variable would result in a 
value
| starting with a space.  Now the initial space is only added if the 
variable
| already contains some value.  Similarly, appending an empty string does 
not
| add a trailing space.
`
The bug lies here:
,[ debian/kernelarch.make ]
| # Black-belt magic
| , := ,
| space :=
| space +=
| $(space) := 
| $(space) +=
`

Manoj

--
flannister, n.: The plastic yoke that holds a six-pack of beer together.
-- "Sniglets", Rich Hall & Friends
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature

Bug#961839: closure-compiler: FTBFS: is not abstract and does not override abstract method test(Object) in Predicate

[Sandro Tosi]

> If that helps, building closure-compiler with source/target=8 should fix
> this issue. I did that for Gradle this week to fix the same issue.

if you guys fix this bug, can you also take care of #942965 at the
same time? it should be just a matter of
s/python-docutils/python3-docutils/

thanks!

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

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

Bug#961938: Debootstrap log

[Michel Le Bihan]

You can find my debootstrap log here: 
https://lebihan.pl/files/debootstrap.log

Bug#961907: ca-certificates: Remove expired mozilla/AddTrust_External_Root.crt

[Axel Beckert]

Hi,

Axel Beckert wrote:
> Certificate chain
>  0 s:OU = Domain Control Validated, OU = Globe Standard SSL, CN = 
> mirror.sinavps.ch
> i:C = US, ST = DE, L = Wilmington, O = "Globe Hosting, Inc.", CN = 
> GlobeSSL DV Certification Authority 2
>  1 s:C = US, ST = DE, L = Wilmington, O = "Globe Hosting, Inc.", CN = 
> GlobeSSL DV Certification Authority 2
>i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN 
> = USERTrust RSA Certification Authority
>  2 s:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN 
> = USERTrust RSA Certification Authority
>i:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = 
> AddTrust External CA Root
> ---

https://archive.raspberrypi.org/ also seems to have been affected
(four hours ago, about 20:30 UTC) but is no more as of writing this
mail. Common demoniater with the affected https://mirror.sinavps.ch/
is the above mentioned "USERTrust RSA Certification Authority"
certificate.

> The longer I think about the more I think it is a bug in both OpenSSL
> and GnuTLS, because the certificate above is totally valid because the
> second last CA is actually no more an Intermediate CA but in
> ca-certificates, too.
> 
> But for some reason, even though the third certificate in the chain is
> trusted, both, OpenSSL and GnuTLS seem to see the fourth certificate
> and only seem to check if that one is trusted and not any inbetween.

This might be related to the used Intermediate CA certificate used on
the server side.

Because if https://archive.raspberrypi.org/ could be fixed on the
server side, this smells a lot like the Intermediate CA certificate.

So if that Intermediate CA certificate on the server includes the
"USERTrust RSA Certification Authority" certification, the client
doesn't seem to trust it even if a certificate with the same serial is
in it's own list of trusted certificates, and it tries to verify the
included signature, which is from the expired AddTrust.

So the amount of "bug" which could be argued is in OpenSSL and GnuTLS
is probably rather small. It's more a kind of missing feature to check
every Intermediate CA certificate if it is also by chance in the local
list of trusted CAs.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#961483: vlc-plugin-bittorrent: vlc crashes (SIGSEGV) on quit via Ctrl+q or Quit menu item

[Paul Wise]

Control: tags -1 + fixed-upstream
Control: forwarded -1 https://github.com/johang/vlc-bittorrent/issues/38 
https://github.com/johang/vlc-bittorrent/commit/90c80e3654c090511333f25a3e5e97345700493d
Control: severity -1 minor

On Mon, 2020-06-01 at 01:17 +0200, Petter Reinholdtsen wrote:

> Upstream just commited a fix for this issue listed as
> https://github.com/johang/vlc-bittorrent/issues/38 >.  I have
> not tested the patch myself.

I have confirmed that it fixes the issue. Since this is really a minor
issue, no need to do an update just for it, wait for the next release.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#961907: ca-certificates: Remove expired mozilla/AddTrust_External_Root.crt

[Axel Beckert]

Control: affects -1 + lynx libwww-perl wget links links2 apt aptitude w3m curl 
openssl dillo mpv epiphany vlc luakit surf aptitude-robot

Hi,

Rémi Denis-Courmont wrote:
> The AddTrust_External_Root.crt certificate has expired, and its
> continued inclusion in the ca-certificates set is causing GnuTLS-based
> client applications (and OpenSSL 1.0.x) to barf on a lot of sites.

Not only OpenSSL 1.0.x, also OpenSSL in unstable is affected:


→ openssl version
OpenSSL 1.1.1g  21 Apr 2020
→ openssl s_client -connect mirror.sinavps.ch:443
CONNECTED(0003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = 
AddTrust External CA Root
verify error:num=10:certificate has expired
notAfter=May 30 10:48:38 2020 GMT
verify return:1
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = 
AddTrust External CA Root
notAfter=May 30 10:48:38 2020 GMT
verify return:1
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN 
= USERTrust RSA Certification Authority
verify error:num=10:certificate has expired
notAfter=May 30 10:48:38 2020 GMT
verify return:1
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN 
= USERTrust RSA Certification Authority
notAfter=May 30 10:48:38 2020 GMT
verify return:1
depth=1 C = US, ST = DE, L = Wilmington, O = "Globe Hosting, Inc.", CN = 
GlobeSSL DV Certification Authority 2
notAfter=Sep  9 23:59:59 2024 GMT
verify return:1
depth=0 OU = Domain Control Validated, OU = Globe Standard SSL, CN = 
mirror.sinavps.ch
notAfter=Jul 16 23:59:59 2021 GMT
verify return:1
---
Certificate chain
 0 s:OU = Domain Control Validated, OU = Globe Standard SSL, CN = 
mirror.sinavps.ch
i:C = US, ST = DE, L = Wilmington, O = "Globe Hosting, Inc.", CN = GlobeSSL 
DV Certification Authority 2
 1 s:C = US, ST = DE, L = Wilmington, O = "Globe Hosting, Inc.", CN = GlobeSSL 
DV Certification Authority 2
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = 
USERTrust RSA Certification Authority
 2 s:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = 
USERTrust RSA Certification Authority
   i:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust 
External CA Root
---
[...]


> It could probably be argued that this is a bug in GnuTLS rather than
> ca-certificates,

The longer I think about the more I think it is a bug in both OpenSSL
and GnuTLS, because the certificate above is totally valid because the
second last CA is actually no more an Intermediate CA but in
ca-certificates, too.

But for some reason, even though the third certificate in the chain is
trusted, both, OpenSSL and GnuTLS seem to see the fourth certificate
and only seem to check if that one is trusted and not any inbetween.

Because "USERTrust RSA Certification Authority" is actually not
expired, just a certificate, which signed it (obviously as shown
above):

(on a buster system)

$ openssl x509 -in /etc/ssl/certs/USERTrust_RSA_Certification_Authority.pem 
-noout -text | egrep 'Not After|Subject:'
Not After : Jan 18 23:59:59 2038 GMT
Subject: C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST 
Network, CN = USERTrust RSA Certification Authority
$ openssl x509 -in /etc/ssl/certs/AddTrust_External_Root.pem -noout -text | 
egrep 'Not After|Subject:'
Not After : May 30 10:48:38 2020 GMT
Subject: C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, 
CN = AddTrust External CA Root


> but I don't see the point in keeping an expired certificate here.

Ack.

> The problem is confirmed to affect Epiphany and VLC.

Tons more: I ran into it with aptitude-robot (via aptitude and apt)
first and was able to confirm it in nearly all browsers and streaming
videoplayer I could think of. The only exceptions were firefox-esr,
chromium, and — to my surprise — qutebrowser.

Martin Bagge / brother wrote:
> severity: critical
> Thanks
> 
> You will need to workaround this. As such this motivates critical me think.

I think "grave" is severe enough, as it "only" breaks HTTPS including
apt with HTTPS-based mirrors (as the one mentioned above) and hence
only "unrelated software/packages", not the whole system (like the
kernel or the bootloader would do if the system won't boot anymore
after an upgrade).

> just doing a straight up curl will hang until timeout. With the expired
> cert disabled this is bypassaed (without curl -k).

Nope. curl exits immediately for me, at least in unstable (7.68.0-1):


→ time curl https://mirror.sinavps.ch
curl: (60) SSL certificate problem: certificate has expired
More detai

Bug#961483: vlc-plugin-bittorrent: vlc crashes (SIGSEGV) on quit via Ctrl+q or Quit menu item

[Petter Reinholdtsen]

[Paul Wise]
> They are quite different crashes AFAICT (SIGSEGV vs SIGABRT0 and
> different backtraces), but maybe the underlying cause is the same.

Upstream just commited a fix for this issue listed as
https://github.com/johang/vlc-bittorrent/issues/38 >.  I have not
tested the patch myself.

JFYI.

-- 
Happy hacking
Petter Reinholdtsen

Bug#923438: NMU to fix SSL issue in tinc experimental

[Don Armstrong]

I've just made an upload to delay-3 to address the SSL issue. Debdiff
attached. Let me know if I should delete the upload.

-- 
Don Armstrong  https://www.donarmstrong.com

"You know," said Arthur, "it's at times like this, when I'm trapped in
a Vogon airlock with a man from Betelgeuse, and about to die from
asphyxiation in deep space that I really wish I'd listened to what my
mother told me when I was young."
"Why, what did she tell you?"
"I don't know, I didn't listen."
 –- Douglas Adams _The Hitchhikers Guide To The Galaxy_
diff -Nru tinc-1.1~pre17/debian/changelog tinc-1.1~pre17/debian/changelog
--- tinc-1.1~pre17/debian/changelog	2018-10-09 19:58:42.0 -0700
+++ tinc-1.1~pre17/debian/changelog	2020-05-31 15:11:34.0 -0700
@@ -1,3 +1,10 @@
+tinc (1.1~pre17-1.2) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch to fix EVP_DecryptUpdate issue. Closes: #923438
+  
+ -- Don Armstrong   Sun, 31 May 2020 15:11:34 -0700
+
 tinc (1.1~pre17-1.1) experimental; urgency=medium
 
   * Non-maintainer upload.
diff -Nru tinc-1.1~pre17/debian/patches/fix_use_of_decrypt tinc-1.1~pre17/debian/patches/fix_use_of_decrypt
--- tinc-1.1~pre17/debian/patches/fix_use_of_decrypt	1969-12-31 16:00:00.0 -0800
+++ tinc-1.1~pre17/debian/patches/fix_use_of_decrypt	2020-05-31 15:11:00.0 -0700
@@ -0,0 +1,16 @@
+Description: Fix EVP_EncryptUpdate use (use EVP_DecryptUpdate)
+Author: Don Armstrong 
+Origin: https://www.tinc-vpn.org/pipermail/tinc-devel/2019-February/000941.html
+Last-Update: 2020-05-31
+
+--- tinc-1.1~pre17.orig/src/openssl/cipher.c
 tinc-1.1~pre17/src/openssl/cipher.c
+@@ -189,7 +189,7 @@ bool cipher_decrypt(cipher_t *cipher, co
+ 	} else {
+ 		int len;
+ 
+-		if(EVP_EncryptUpdate(cipher->ctx, outdata, &len, indata, inlen)) {
++		if(EVP_DecryptUpdate(cipher->ctx, outdata, &len, indata, inlen)) {
+ 			if(outlen) {
+ *outlen = len;
+ 			}
diff -Nru tinc-1.1~pre17/debian/patches/series tinc-1.1~pre17/debian/patches/series
--- tinc-1.1~pre17/debian/patches/series	2017-09-05 12:02:21.0 -0700
+++ tinc-1.1~pre17/debian/patches/series	2019-03-28 18:23:53.0 -0700
@@ -1 +1,2 @@
 fix-version-number
+fix_use_of_decrypt

Bug#931418: closed by Niko Tyni (Re: Bug#931418: perl: no errors with strict subs and bareword following a minus operator)

[Vincent Lefevre]

On 2020-05-31 15:45:11 +, Debian Bug Tracking System wrote:
> Unary plus has no effect, so the result is a bareword that is illegal
> under "strict subs".  Unary minus turns the bareword into a string with
> "-" prepended.  This is no longer a bareword, and hence legal under
> "strict subs".

As I understand it, since this is described in the perlop(1) man page,
this operation is done at execution time, like the other operations.
Thus at compilation time (where "strict subs" takes effect), it should
still be a bareword. Anyway, even if the transformation is done at
compilation time, there was first a bareword...

> Programming Perl: 3rd Edition also has mentions it. On page 92:
> 
>   One effect of these rules is that -bareword is equivalent to
>   "-bareword".  This is most useful to Tk programmers.

But "strict subs" changes the default behavior by forbidding some
constructs (at compilation time).

> I think it's clear that this is not a bug and is not going to change.
> Feel free to take it up upstream if you disagree.

As I disagree, I've reported the bug upstream:

  https://github.com/Perl/perl5/issues/17822

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

Bug#961938: libreoffice: Installing Debian with Debootstrap and gnome included results in broken install

[Michel Le Bihan]

Source: libreoffice
Version: 6.4.4-1
Severity: grave
Justification: renders package unusable

Installing Debian with:
debootstrap --include=linux-image-amd64,grub-pc,xserver-xorg-video-all,gnome
--arch amd64 bullseye /mnt/hd http://ftp.pl.debian.org/debian/

fails at

W: Failure while configuring base packages.  This will be re-attempted up to
five times.
W: See /mnt/hd/debootstrap/debootstrap.log for details (possibly the package
libreoffice-writer is at fault)
W: Failure while configuring base packages.  This will be re-attempted up to
five times.
W: See /mnt/hd/debootstrap/debootstrap.log for details (possibly the package
libreoffice-writer is at fault)
W: Failure while configuring base packages.  This will be re-attempted up to
five times.
W: See /mnt/hd/debootstrap/debootstrap.log for details (possibly the package
libreoffice-writer is at fault)
W: Failure while configuring base packages.  This will be re-attempted up to
five times.
W: See /mnt/hd/debootstrap/debootstrap.log for details (possibly the package
libreoffice-writer is at fault)
W: Failure while configuring base packages.  This will be re-attempted up to
five times.
W: See /mnt/hd/debootstrap/debootstrap.log for details (possibly the package
libreoffice-writer is at fault)

A quick inspection confirms that libreoffice package caused the issue:

chroot /mnt/hd apt --fix-broken install
Reading package lists... Done
Building dependency tree... Done
Correcting dependencies... Done
The following additional packages will be installed:
  libpaper-utils libreoffice-core
The following packages will be REMOVED:
  libreoffice-core-nogui
The following NEW packages will be installed:
  libpaper-utils libreoffice-core
0 upgraded, 2 newly installed, 1 to remove and 0 not upgraded.
6 not fully installed or removed.
Need to get 18.3 kB/30.8 MB of archives.
After this operation, 5728 kB of additional disk space will be used.
Do you want to continue? [Y/n]

I have no clue why `libreoffice-core-nogui` was pulled.



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

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

Bug#961952: Should depend on libpcre3-dev

[Josh Triplett]

Package: libgit2-dev
Version: 1.0.0+dfsg.1-1
Severity: important

Without libpcre3-dev installed:

$ pkg-config --cflags libgit2
Package libpcre was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpcre.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libpcre', required by 'libgit2', not found

With libpcre3-dev installed, the same command completes successfully
with no errors.

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

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

Versions of packages libgit2-dev depends on:
ii  libgit2-1.0 1.0.0+dfsg.1-1
ii  libhttp-parser-dev  2.9.2-2
ii  libmbedtls-dev  2.16.5-1
ii  libssh2-1-dev   1.8.0-2.1
ii  zlib1g-dev  1:1.2.11.dfsg-2

libgit2-dev recommends no packages.

libgit2-dev suggests no packages.

-- no debconf information

Bug#881719: libcdio 2.1.0 and lubcdio++

[Gabriel F. T. Gomes]

On 31 May 2020, Gabriel F. T. Gomes wrote:
>
>we will need a sponsor.

The package is now on mentors:

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

Balint, could you review it and, if everything is fine, sponsor it?
(I'm asking because Vasyl mentioned you are guiding the packaging of
Kodi, if I got it right)


Cheers,
Gabriel

Bug#961905: RFS: sane-backends/1.0.30-1~experimental2 -- API library for scanners -- utilities

[Adam Borowski]

On Sun, May 31, 2020 at 09:48:19AM +0200, Jörg Frings-Fürst wrote:
>Package name: sane-backends
>Version : 1.0.30-1~experimental2

> Changes since the last upload:
> 
>* debian/not-installed:
>  - Add usr/share/doc/libsane/backend-writing.txt.
>* debian/libsane1.symbols:
>  - Add (arch=!hurd-i386) to cmsg@Base.

Hi!
Since it's experimental, I've uploaded as-is, but moving the .so links from
libsane1 to libsane-dev means both of us will need to check how upgrades
from stable/unstable to the version in experimental go.

(The package libsane1 doesn't exist outside experimental.)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#881719: libcdio 2.1.0 and lubcdio++

[Gabriel F. T. Gomes]

Hi, Vasyl,

On 24 May 2020, Vasyl Gello wrote:
>
>Yes experimental is OK for me, even though I uploaded libshairplay & 
>libudfread to unstable queue. Balint asked me initially to target Kodi 19.0 to 
>experimental so I will probably re-upload both libraries to experimental to 
>keep everything consistent.

Awesome.

I accepted your merge request and I prepared the package for
experimental. It will take a while to get there though, because I'm not
a DD yet (my process is still ongoing), so we will need a sponsor.

Also, since it adds new binary packages, it will also have to go
through the new queue.


Cheers,
Gabriel

Bug#961429: Subject: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.

[Matthew Fernandez]

> On May 31, 2020, at 07:54, Vasyl Gello  wrote:
> 
> Dear Mattia and Matthew!
> 
> First of all I would like to thank you for all the efforts you did to teach 
> me how to do proper Debian packaging.
> Your reviews made me rethink some practices I followed and it already helps 
> me in my activities outside of Debian.
> 
> Yesterday I found out the original Cryptopass Chrome extension is no longer 
> maintained and its repository archived.
> While I fixed the issues spotted in previous reviews and pushed the new 
> upstream version 1.1.0 and corresponding
> Debian repo on Salsa, I would like to withdraw the package from the queue.
> 
> Earlier I mentioned the passwordmaker-cli package I found long after I wrote 
> cryptopass. Its Android app is actively
> maintained, in contrast to the CLI sources, so I will likely propose the 
> fixes incorporating cryptopass scheme into
> Password Maker (https://www.passwordmaker.org 
> ). Once there is new upstream release, I will 
> coordinate with
> Cord Beermann (the pm-cli maintainer) to have it packaged.
> 
> I do still appreciate additional reviews on packaging and security of 
> cryptopass, because I thought it could be a great
> example of "making a small pavkage to learn Debian packaging". Maybe I will 
> even write a series of blog posts about
> Debian packaging and my experience with it.
> 
> Sincerely,
> -- 
> Vasyl Gello

No problem, Vasyl. I hope my comments were helpful. Good luck with your future 
work!

Bug#961951: network-manager: MAC address is not assigned automatically to Ethernet over USB interface

[alfa omega]

Package: network-manager
Version: 1.14.6-2+deb10u1
Severity: important
Tags: a11y upstream
 
Dear Maintainer,
 
When I connect Ethernet over USB interface (Cellphone Tethering) the connection 
is not available in NetworkManager. Then I need to assign manull MAC address 
and then the connection becomes automatically.
 
To make useful the connection I need to run the following command as root:
 
root#link set dev  enp0s20f0u1 address 00:00:00:00:00:01
 
The MAC address (00:00:00:00:00:01) can be a random value.
 
/var/log/messages
May 30 12:02:55 nameofpc kernel: rndis_host 1-1:1.0 eth0: register 'rndis_host' 
at usb-:00:14.0-1, RNDIS device, 00:00:00:00:00:00
May 30 12:02:55 nameofpc NetworkManager[1317]:   [1590832975.9829] 
manager: (eth0): new Ethernet device 
(/org/freedesktop/NetworkManager/Devices/10)
May 30 12:02:55 nameofpc mtp-probe[22190]: checking bus 1, device 24: 
"/sys/devices/pci:00/:00:14.0/usb1/1-1"
 
May 30 12:02:57 nameofpc systemd-udevd[11330]: Using default interface naming 
scheme 'v240'.
May 30 12:02:57 nameofpc systemd-udevd[11330]: link_config: autonegotiation is 
unset or enabled, the speed and duplex are not writable.
May 30 12:02:57 nameofpc kernel: rndis_host 1-1:1.0 enp0s20f0u1: renamed from 
eth0
May 30 12:02:57 nameofpc NetworkManager[1317]:   [1590832977.8099] device 
(eth0): interface index 10 renamed iface from 'eth0' to 'enp0s20f0u1'
May 30 12:02:57 nameofpc NetworkManager[1317]:   [1590832977.8192] device 
(enp0s20f0u1): state change: unmanaged -> unavailable (reason 'managed', 
sys-iface-state: 'external')
May 30 12:02:57 nameofpc NetworkManager[1317]:   [1590832977.8196] 
platform-linux: do-change-link[10]: failure changing link: failure 99 
(Requested address cannot be assigned)
May 30 12:02:57 nameofpc kernel: IPv6: ADDRCONF(NETDEV_UP): enp0s20f0u1: link 
is not ready
May 30 12:02:57 nameofpc mtp-probe[31016]: checking bus 1, device 24: 
"/sys/devices/pci:00/:00:14.0/usb1/1-1"
May 30 12:02:57 nameofpc mtp-probe[31016]: bus: 1, device: 24 was not an MTP 
device
May 30 12:02:59 nameofpc NetworkManager[1317]:   [1590832979.9337] device 
(enp0s20f0u1): carrier: link connected
May 30 12:02:59 nameofpc NetworkManager[1317]:   [1590832979.9344] device 
(enp0s20f0u1): state change: unavailable -> disconnected (reason 
'carrier-changed', sys-iface-state: 'managed')
May 30 12:02:59 nameofpc NetworkManager[1317]:   [1590832979.9392] 
keyfile: add connection /run/NetworkManager/system-connections/Wired conection 
2.nmconnection (267b823d-d35a-3de0-a5db-3a47f5a88258,"Wired conection 2")
May 30 12:02:59 nameofpc NetworkManager[1317]:   [1590832979.9397] 
settings: (enp0s20f0u1): created default wired connection 'Wired conection 2'
May 30 12:02:59 nameofpc NetworkManager[1317]:   [1590832979.9400] 
policy: auto-activating connection 'Wired conection 2' 
(267b823d-d35a-3de0-a5db-3a47f5a88258)
May 30 12:02:59 nameofpc NetworkManager[1317]:   [1590832979.9405] device 
(enp0s20f0u1): Activation: starting connection 'Wired conection 2' 
(267b823d-d35a-3de0-a5db-3a47f5a88258)
May 30 12:02:59 nameofpc NetworkManager[1317]:   [1590832979.9480] device 
(enp0s20f0u1): state change: disconnected -> prepare (reason 'none', 
sys-iface-state: 'managed')
May 30 12:02:59 nameofpc NetworkManager[1317]:   [1590832979.9486] device 
(enp0s20f0u1): state change: prepare -> config (reason 'none', sys-iface-state: 
'managed')
May 30 12:02:59 nameofpc NetworkManager[1317]:   [1590832979.9492] device 
(enp0s20f0u1): state change: config -> ip-config (reason 'none', 
sys-iface-state: 'managed')
May 30 12:02:59 nameofpc NetworkManager[1317]:   [1590832979.9495] dhcp4 
(enp0s20f0u1): activation: beginning transaction (timeout in 45 seconds)
May 30 12:02:59 nameofpc NetworkManager[1317]:   [1590832979.9506] dhcp4 
(enp0s20f0u1): dhclient started with pid 31019
May 30 12:02:59 nameofpc avahi-daemon[1331]: Joining mDNS multicast group on 
interface enp0s20f0u1.IPv6 with address fe80::853b:382:134e:8753.
May 30 12:02:59 nameofpc avahi-daemon[1331]: New relevant interface 
enp0s20f0u1.IPv6 for mDNS.
May 30 12:02:59 nameofpc avahi-daemon[1331]: Registering new address record for 
fe80::853b:382:134e:8753 on enp0s20f0u1.*.
May 30 12:02:59 nameofpc dhclient[31019]: DHCPREQUEST for 192.168.42.15 on 
enp0s20f0u1 to 255.255.255.255 port 67
May 30 12:03:00 nameofpc dhclient[31019]: DHCPACK of 192.168.42.15 from 
192.168.42.129
May 30 12:03:00 nameofpc NetworkManager[1317]:   [1590832980.0326] dhcp4 
(enp0s20f0u1):   address 192.168.42.15
May 30 12:03:00 nameofpc NetworkManager[1317]:   [1590832980.0326] dhcp4 
(enp0s20f0u1):   plen 24 (255.255.255.0)
May 30 12:03:00 nameofpc NetworkManager[1317]:   [1590832980.0326] dhcp4 
(enp0s20f0u1):   gateway 192.168.42.129
May 30 12:03:00 nameofpc NetworkManager[1317]:   [1590832980.0326] dhcp4 
(enp0s20f0u1):   lease time 3600
May 30 12:03:00 nameofpc NetworkManager[1317]:   [1590832980.0326] dhcp4 
(enp0s20f0u1):   hostname 'nameofpc'
May 30 12:03:00 nameofpc 

Bug#961950: add config for lighttpd

[Joseph Nahmias]

Package: smokeping
Version: 2.7.3-2
Severity: wishlist
Tags: patch

Hello,

Thanks for packaging smokeping for Debian! It's great that you include a
config for Apache; however, I use Lighttpd... I've created a config file
that can be used with file layout provided by the Debian smokeping
package, please see attached.

Easiest (for the [potential] users) would be to arrange for this to be
installed as something like /etc/lighttpd/conf-available/45-smokeping.conf.
That will allow the admin to simply run the following to have smokeping
available at the usual location [http://machine.example.org/smokeping/]:

$ sudo /usr/sbin/lighttpd-enable-mod smokeping && sudo invoke-rc.d lighttpd 
reload

Bonus points for automatically doing this in postinst/prerm (conditional on
the existance of lighttpd-{en,dis}able-mod).

Thanks,
--Joe

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores)
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 smokeping depends on:
ii  adduser   3.118
ii  debianutils   4.8.6.1
ii  fping 4.2-1
ii  libcgi-fast-perl  1:2.13-1
ii  libconfig-grammar-perl1.12-2
ii  libdigest-hmac-perl   1.03+dfsg-2
ii  libjs-cropper 1.2.2-1
ii  libjs-prototype   1.7.1-3
ii  libjs-scriptaculous   1.9.0-2
ii  librrds-perl  1.7.1-2
ii  libsnmp-session-perl  1.14~git20130523.186a005-4
ii  liburi-perl   1.76-1
ii  libwww-perl   6.36-2
ii  lsb-base  10.2019051400
ii  msmtp-mta [mail-transport-agent]  1.8.3-1
ii  perl  5.28.1-6
ii  ucf   3.0038+nmu1

Versions of packages smokeping recommends:
pn  apache2 | apache2 | httpd  
ii  dnsutils   1:9.11.5.P4+dfsg-5.1+deb10u1
ii  echoping   6.0.2-10
ii  libsocket6-perl0.29-1+b1
ii  lighttpd [httpd-cgi]   1.4.53-4
# /etc/lighttpd/conf-available/45-smokeping.conf
# Configuration for smokeping CGI program


server.modules += ( "mod_fastcgi", "mod_rewrite" )

$HTTP["url"] =~ "^/smokeping/" {
server.document-root = "/usr/share/"
url.rewrite-once = (
"^/smokeping/($|\?)" => "/smokeping/smokeping.cgi?${qsa}",
"^/smokeping/(.*)" => "/smokeping/www/$1",
)
fastcgi.server = (
"/smokeping/smokeping.cgi" => (
"localhost" => (
"bin-path" => "/usr/lib/cgi-bin/smokeping.cgi",
"socket" => "/run/lighttpd/smokeping-fcgi.socket",
)
),
)
}

# vim: set ts=4 sw=4 et:

Bug#942876: openjdk-11-jre-dcevm: Doesn't start up anymore after updating openjdk-11-jre

[Emmanuel Bourg]

Le 14/05/2020 à 17:10, Ruedi Steinmann a écrit :

> According to upstream the issue is fixed now.

Just tried the version 11.0.7+1 and it looks good now. Uploading soon.

Emmanuel Bourg

Bug#960069: capstone-tool: Please consider moving to utils section

[Hilko Bengen]

control: tag -1 pending

capstone/4.0.2-1 fixes this issue and is currently waiting in NEW for
experimental.

Bug#961222: "/usr/bin/ucf: 85: local: root.root: bad variable name" when showing differences

[Thorsten Glaser]

Christoph Biedl dixit:

>Quite frankly, I haven't checked which shell implementation does not
>follow the specification, if any, or if this is just another bashism.

This depends.

If “local” is a “declaration utility” (like export and readonly),
then dash does not follow the spec.

If “local” is not a “declaration utility”, then bash and mksh
don’t follow the spec (except for the next release explicitly
permitting this).

However, “local” is not in POSIX (or ksh93 nor ksh2020, for that
matter) and is a Debian-local addition to the requirements for
/bin/sh on Debian only.

POSIX 2017/2018 is quiet on declaration utilities, they only show
up in the minutes 535, and among them is:

|Implementations are permitted to provide extensions that serve as
|declaration utilities, such as 'typeset' or 'local', or even a way to
|define a function that can behave as a declaration utility.

Policy §10.4 is quiet on this as well.

I’d still report this as a bug, severity important or normal, to
dash for consistency and to match user expectations; declaration
utilities in POSIX (XBD 3) are defined as “A utility which can
take arguments that cause variable assignments (of the form
varname=value) which will persist in the current shell environment.”
and it stands to presume that, if “local” is present, it certainly
fits this definition.

Do note that “command” is a declaration utility forwarder, i.e. if
“command” is followed by “export”, “readonly”, etc. it will also
act as a declaration utility.

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

Bug#961926: rr: record fails on i386

[Bernhard Übelacker]

Hello Stephen,

Am 31.05.20 um 22:52 schrieb Stephen Kitt:
> On Sun, 31 May 2020 18:03:01 +0200, Bernhard Übelacker
>  wrote:
>> Unfortunately I found recording not working in a small test [1].
>>
>> A git bisect led to a helper function introduced by upstream in [2].
>> This helper uses a function parameter of type off_t.
>> But the pwrite64 from glibc uses off64_t.
>> Therefore offset values with the highest bit set get incorrectly
>> converted to the 64 bit type, e.g.: 0xb622 -> 0xb622
>> Therefore the write fails and rr stops.
>>
>> Attached patch makes rr work on i386 and passing most tests
>> in my test VM, except [3]. Have not tested for side effects at amd64.
>>
>> I am going to try to forward this to upstream too,
>> will update this bug then.
> 
> Ah, I assumed it would work, and I didn’t even test, let alone run the test
> suite.
> 
> Thanks for the patch, I’ll see if the failing tests mean anything to me...
> 
> Regards,
> 
> Stephen


I reported to upstream this issue:
   https://github.com/mozilla/rr/issues/2597
Let's see what they think about it.

The failing tests might be related to me using a VM maybe ...
To do the make test I had to link rr_page_* and rr_exec_stub from
rr-5.3.0/debian/rr/usr/lib/rr/ to rr-5.3.0/build/bin/../lib/rr/.
Therefore I don't know if the failures might be a result of
just some more files missing not found ...

Kind regards,
Bernhard

Bug#961926: rr: record fails on i386

[Stephen Kitt]

Control: severity -1 grave

On Sun, 31 May 2020 18:03:01 +0200, Bernhard Übelacker
 wrote:
> Unfortunately I found recording not working in a small test [1].
> 
> A git bisect led to a helper function introduced by upstream in [2].
> This helper uses a function parameter of type off_t.
> But the pwrite64 from glibc uses off64_t.
> Therefore offset values with the highest bit set get incorrectly
> converted to the 64 bit type, e.g.: 0xb622 -> 0xb622
> Therefore the write fails and rr stops.
> 
> Attached patch makes rr work on i386 and passing most tests
> in my test VM, except [3]. Have not tested for side effects at amd64.
> 
> I am going to try to forward this to upstream too,
> will update this bug then.

Ah, I assumed it would work, and I didn’t even test, let alone run the test
suite.

Thanks for the patch, I’ll see if the failing tests mean anything to me...

Regards,

Stephen


pgpVignf4umZV.pgp
Description: OpenPGP digital signature

Bug#961948: daa2iso FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: daa2iso
Version: 0.1.7e-1.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

daa2iso fails to cross build from source, because it does not pass cross
tools to make. The easiest way of fixing that is using dh_auto_build.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru daa2iso-0.1.7e/debian/changelog 
daa2iso-0.1.7e/debian/changelog
--- daa2iso-0.1.7e/debian/changelog 2020-01-21 21:23:25.0 +0100
+++ daa2iso-0.1.7e/debian/changelog 2020-05-31 21:56:02.0 +0200
@@ -1,3 +1,10 @@
+daa2iso (0.1.7e-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 31 May 2020 21:56:02 +0200
+
 daa2iso (0.1.7e-1.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff --minimal -Nru daa2iso-0.1.7e/debian/rules daa2iso-0.1.7e/debian/rules
--- daa2iso-0.1.7e/debian/rules 2020-01-21 21:23:25.0 +0100
+++ daa2iso-0.1.7e/debian/rules 2020-05-31 21:56:01.0 +0200
@@ -9,7 +9,7 @@
dh_clean src/*.o src/*.exe src/daa2iso
 
 override_dh_auto_build:
-   $(MAKE) -C src PREFIX=/usr
+   dh_auto_build --sourcedirectory=src -- PREFIX=/usr
 
 override_dh_auto_install:
$(MAKE) -C src PREFIX=/usr DESTDIR=$(CURDIR)/debian/daa2iso install

Bug#961949: wrk FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: wrk
Version: 4.1.0-2
Severity: minor
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

wrk fails to cross build from source, because it does not pass cross
tools to make and the Makefile hard codes the build architecture
pkg-config. An easy way to fix the former is using dh_auto_build. The
attached patch fixes both. After applying it, wrk continues to fail
cross building, because luajit still produces a build archtecture object
file. It's not obvious how to fix that. However, it would help to see
such failures in cross build logs. Therefore, I'm asking you to apply
this partial solution to make the real issue more visible. Thanks for
considering.

Helmut
diff --minimal -Nru wrk-4.1.0/debian/changelog wrk-4.1.0/debian/changelog
--- wrk-4.1.0/debian/changelog  2020-05-16 19:47:51.0 +0200
+++ wrk-4.1.0/debian/changelog  2020-05-31 07:15:46.0 +0200
@@ -1,3 +1,12 @@
+wrk (4.1.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Make pkg-config substitutable.
+
+ -- Helmut Grohne   Sun, 31 May 2020 07:15:46 +0200
+
 wrk (4.1.0-2) unstable; urgency=medium
 
   * Fix FTBFS on armel.
diff --minimal -Nru wrk-4.1.0/debian/patches/debian-changes 
wrk-4.1.0/debian/patches/debian-changes
--- wrk-4.1.0/debian/patches/debian-changes 2020-05-16 19:47:51.0 
+0200
+++ wrk-4.1.0/debian/patches/debian-changes 2020-05-31 07:15:46.0 
+0200
@@ -10,26 +10,27 @@
 repository.
 --- wrk-4.1.0.orig/Makefile
 +++ wrk-4.1.0/Makefile
-@@ -1,5 +1,5 @@
+@@ -1,5 +1,6 @@
++PKG_CONFIG ?= pkg-config
  CFLAGS  += -std=c99 -Wall -O2 -D_REENTRANT
 -LIBS:= -lpthread -lm -lssl -lcrypto
 +LIBS+= -lpthread -lm -lssl -lcrypto
  
  TARGET  := $(shell uname -s | tr '[A-Z]' '[a-z]' 2>/dev/null || echo unknown)
  
-@@ -17,6 +17,11 @@ else ifeq ($(TARGET), freebsd)
+@@ -17,6 +18,11 @@ else ifeq ($(TARGET), freebsd)
LDFLAGS += -Wl,-E
  endif
  
-+CFLAGS   += $(shell pkg-config --cflags luajit)
-+LIBS += $(shell pkg-config --libs luajit)
++CFLAGS   += $(shell $(PKG_CONFIG) --cflags luajit)
++LIBS += $(shell $(PKG_CONFIG) --libs luajit)
 +
 +CFLAGS   += $(CPPFLAGS)
 +
  SRC  := wrk.c net.c ssl.c aprintf.c stats.c script.c units.c \
ae.c zmalloc.c http_parser.c
  BIN  := wrk
-@@ -51,8 +56,7 @@ clean:
+@@ -51,8 +57,7 @@ clean:
$(RM) -rf $(BIN) obj/*
  
  $(BIN): $(OBJ)
@@ -39,7 +40,7 @@
  
  $(OBJ): config.h Makefile $(DEPS) | $(ODIR)
  
-@@ -60,15 +64,13 @@ $(ODIR):
+@@ -60,15 +65,13 @@ $(ODIR):
@mkdir -p $@
  
  $(ODIR)/bytecode.o: src/wrk.lua
diff --minimal -Nru wrk-4.1.0/debian/rules wrk-4.1.0/debian/rules
--- wrk-4.1.0/debian/rules  2020-05-16 19:47:51.0 +0200
+++ wrk-4.1.0/debian/rules  2020-05-31 07:15:45.0 +0200
@@ -14,4 +14,4 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) WITH_LUAJIT=/usr WITH_OPENSSL=/usr VER=debian/$(DEB_VERSION)
+   dh_auto_build -- WITH_LUAJIT=/usr WITH_OPENSSL=/usr 
VER=debian/$(DEB_VERSION)

Bug#961947: genwqe-user FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: genwqe-user
Version: 4.0.18-3.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

genwqe-user fails to cross build from source, because it builds for the
build architecture. The makefile at hand can be instructed to perform a
cross build by setting the CROSS variable. The attached patch implements
that. Unfortunately, doing so does not make genwqe-user cross buildable
as it uses help2man. Fixing help2man is non-trivial and often times, the
best way is not using help2man at all. Please consider applying the
attached patch to add the CROSS assignment leaving the help2man issue
unresolved.

Helmut
diff --minimal -Nru genwqe-user-4.0.18/debian/changelog 
genwqe-user-4.0.18/debian/changelog
--- genwqe-user-4.0.18/debian/changelog 2020-04-10 15:38:27.0 +0200
+++ genwqe-user-4.0.18/debian/changelog 2020-05-31 22:09:13.0 +0200
@@ -1,3 +1,10 @@
+genwqe-user (4.0.18-3.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: pass CROSS= to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 31 May 2020 22:09:13 +0200
+
 genwqe-user (4.0.18-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru genwqe-user-4.0.18/debian/rules 
genwqe-user-4.0.18/debian/rules
--- genwqe-user-4.0.18/debian/rules 2020-04-10 14:47:52.0 +0200
+++ genwqe-user-4.0.18/debian/rules 2020-05-31 22:09:13.0 +0200
@@ -21,7 +21,7 @@
 # The tarball below is a workaround so the test does not need to
 # download it.
tar czvf cantrbry.tar.gz -C misc .
-   $(MAKE) tools lib VERSION=$(VERSION) V=2
+   $(MAKE) tools lib VERSION=$(VERSION) V=2 $(if $(filter 
$(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)),,CROSS=$(DEB_HOST_GNU_TYPE)-)
 
 override_dh_auto_install:
dh_auto_install -- \

Bug#961946: ITP: metabat -- robust statistical framework for reconstructing genomes from metagenomic data

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: metabat -- robust statistical framework for reconstructing 
genomes from metagenomic data
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: metabat
  Version : 2.15
  Upstream Author : The Regents of the University of California,
* URL : https://bitbucket.org/berkeleylab/metabat/wiki/Home
* License : BerkeleyLabs
  Programming Lang: C
  Description : robust statistical framework for reconstructing genomes 
from metagenomic data
 MetaBAT integrates empirical probabilistic distances of genome abundance
 and tetranucleotide frequency for accurate metagenome binning. MetaBAT
 outperforms alternative methods in accuracy and computational efficiency
 on both synthetic and real metagenome datasets. It automatically forms
 hundreds of high quality genome bins on a very large assembly consisting
 millions of contigs in a matter of hours on a single node.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/metabat

Bug#961944: buster-pu: package php-horde/5.2.20+debian0-1+deb10u2

[Mike Gabriel]

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

Dear release team,

I have just uploaded this php-horde update to buster, fixing a no-dsa CVE:

+  * CVE-2020-8035: Don't allow to view images inline if opened directly.
+  * debian/patches/0001-Fix-rewrite-base.patch: Trivial rebase.

Greets,
Mike

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_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
diff -Nru php-horde-5.2.20+debian0/debian/changelog 
php-horde-5.2.20+debian0/debian/changelog
--- php-horde-5.2.20+debian0/debian/changelog   2019-12-14 03:13:53.0 
+0100
+++ php-horde-5.2.20+debian0/debian/changelog   2020-05-31 21:45:26.0 
+0200
@@ -1,3 +1,10 @@
+php-horde (5.2.20+debian0-1+deb10u2) buster; urgency=medium
+
+  * CVE-2020-8035: Don't allow to view images inline if opened directly.
+  * debian/patches/0001-Fix-rewrite-base.patch: Trivial rebase.
+
+ -- Mike Gabriel   Sun, 31 May 2020 21:45:26 +0200
+
 php-horde (5.2.20+debian0-1+deb10u1) buster; urgency=high
 
   * Fix CVE-2019-12095: Stored XSS vuln in the Horde Cloud Block.
diff -Nru php-horde-5.2.20+debian0/debian/patches/0001-Fix-rewrite-base.patch 
php-horde-5.2.20+debian0/debian/patches/0001-Fix-rewrite-base.patch
--- php-horde-5.2.20+debian0/debian/patches/0001-Fix-rewrite-base.patch 
2019-12-14 03:13:53.0 +0100
+++ php-horde-5.2.20+debian0/debian/patches/0001-Fix-rewrite-base.patch 
2020-05-31 21:45:26.0 +0200
@@ -6,11 +6,9 @@
  horde-5.2.20/.htaccess | 1 +
  1 file changed, 1 insertion(+)
 
-diff --git a/horde-5.2.20/.htaccess b/horde-5.2.20/.htaccess
-index 89eaf0a..348046e 100644
 --- a/horde-5.2.20/.htaccess
 +++ b/horde-5.2.20/.htaccess
-@@ -5,6 +5,7 @@ allow from all
+@@ -10,6 +10,7 @@
  
  
  RewriteEngine On
diff -Nru 
php-horde-5.2.20+debian0/debian/patches/0003-CVE-2020-8035-dont-allow-to-view-images-inline.patch
 
php-horde-5.2.20+debian0/debian/patches/0003-CVE-2020-8035-dont-allow-to-view-images-inline.patch
--- 
php-horde-5.2.20+debian0/debian/patches/0003-CVE-2020-8035-dont-allow-to-view-images-inline.patch
   1970-01-01 01:00:00.0 +0100
+++ 
php-horde-5.2.20+debian0/debian/patches/0003-CVE-2020-8035-dont-allow-to-view-images-inline.patch
   2020-05-31 21:45:26.0 +0200
@@ -0,0 +1,28 @@
+From 64127fe3c2b9843c9760218e59dae9731cc56bdf Mon Sep 17 00:00:00 2001
+From: Jan Schneider 
+Date: Mon, 20 Apr 2020 23:07:51 +0200
+Subject: [PATCH] Don't allow to view images inline if opened directly.
+
+This services is supposed to process and view images inside a web page.
+---
+ services/images/view.php | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/horde-5.2.20/services/images/view.php 
b/horde-5.2.20/services/images/view.php
+index bc7da534..f5b0cb25 100644
+--- a/horde-5.2.20/services/images/view.php
 b/horde-5.2.20/services/images/view.php
+@@ -84,6 +84,7 @@
+ 
+ /* Check if no editing action required and send the image to browser. */
+ if (empty($action)) {
++header('Content-Disposition: attachment');
+ $image->display();
+ exit;
+ }
+@@ -132,4 +133,5 @@
+ /* Write out any changes to the temporary file. */
+ file_put_contents($file_name, $image->raw());
+ 
++header('Content-Disposition: attachment');
+ $image->display();
diff -Nru php-horde-5.2.20+debian0/debian/patches/series 
php-horde-5.2.20+debian0/debian/patches/series
--- php-horde-5.2.20+debian0/debian/patches/series  2019-12-14 
03:13:53.0 +0100
+++ php-horde-5.2.20+debian0/debian/patches/series  2020-05-31 
21:45:26.0 +0200
@@ -1,2 +1,3 @@
 0001-Fix-rewrite-base.patch
 0002-CVE-2019-12095-Fix-XSS-vuln-in-the-Horde-Cloud-Block.patch
+0003-CVE-2020-8035-dont-allow-to-view-images-inline.patch

Bug#961945: stretch-pu: package php-horde/5.2.13+debian0-1+deb9u2

[Mike Gabriel]

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

Dear release team,

I have just uploaded this php-horde update to stretch, fixing a no-dsa CVE:

+  * CVE-2020-8035: Don't allow to view images inline if opened directly.
+  * debian/patches/0001-Fix-rewrite-base.patch: Trivial rebase.

Greets,
Mike

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_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
diff -Nru php-horde-5.2.13+debian0/debian/changelog 
php-horde-5.2.13+debian0/debian/changelog
--- php-horde-5.2.13+debian0/debian/changelog   2019-12-14 03:10:06.0 
+0100
+++ php-horde-5.2.13+debian0/debian/changelog   2020-05-31 21:45:26.0 
+0200
@@ -1,3 +1,10 @@
+php-horde (5.2.13+debian0-1+deb9u2) stretch; urgency=medium
+
+  * CVE-2020-8035: Don't allow to view images inline if opened directly.
+  * debian/patches/0001-Fix-rewrite-base.patch: Trivial rebase.
+
+ -- Mike Gabriel   Sun, 31 May 2020 21:45:26 +0200
+
 php-horde (5.2.13+debian0-1+deb9u1) stretch; urgency=high
 
   * Fix CVE-2019-12095: Stored XSS vuln in the Horde Cloud Block.
diff -Nru php-horde-5.2.13+debian0/debian/patches/0001-Fix-rewrite-base.patch 
php-horde-5.2.13+debian0/debian/patches/0001-Fix-rewrite-base.patch
--- php-horde-5.2.13+debian0/debian/patches/0001-Fix-rewrite-base.patch 
2019-12-14 03:10:06.0 +0100
+++ php-horde-5.2.13+debian0/debian/patches/0001-Fix-rewrite-base.patch 
2020-05-31 21:45:26.0 +0200
@@ -6,11 +6,9 @@
  horde-5.2.13/.htaccess | 1 +
  1 file changed, 1 insertion(+)
 
-diff --git a/horde-5.2.13/.htaccess b/horde-5.2.13/.htaccess
-index 89eaf0a..348046e 100644
 --- a/horde-5.2.13/.htaccess
 +++ b/horde-5.2.13/.htaccess
-@@ -5,6 +5,7 @@ allow from all
+@@ -10,6 +10,7 @@
  
  
  RewriteEngine On
diff -Nru 
php-horde-5.2.13+debian0/debian/patches/0003-CVE-2020-8035-dont-allow-to-view-images-inline.patch
 
php-horde-5.2.13+debian0/debian/patches/0003-CVE-2020-8035-dont-allow-to-view-images-inline.patch
--- 
php-horde-5.2.13+debian0/debian/patches/0003-CVE-2020-8035-dont-allow-to-view-images-inline.patch
   1970-01-01 01:00:00.0 +0100
+++ 
php-horde-5.2.13+debian0/debian/patches/0003-CVE-2020-8035-dont-allow-to-view-images-inline.patch
   2020-05-31 21:45:26.0 +0200
@@ -0,0 +1,28 @@
+From 64127fe3c2b9843c9760218e59dae9731cc56bdf Mon Sep 17 00:00:00 2001
+From: Jan Schneider 
+Date: Mon, 20 Apr 2020 23:07:51 +0200
+Subject: [PATCH] Don't allow to view images inline if opened directly.
+
+This services is supposed to process and view images inside a web page.
+---
+ services/images/view.php | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/horde-5.2.13/services/images/view.php 
b/horde-5.2.13/services/images/view.php
+index bc7da534..f5b0cb25 100644
+--- a/horde-5.2.13/services/images/view.php
 b/horde-5.2.13/services/images/view.php
+@@ -84,6 +84,7 @@
+ 
+ /* Check if no editing action required and send the image to browser. */
+ if (empty($action)) {
++header('Content-Disposition: attachment');
+ $image->display();
+ exit;
+ }
+@@ -132,4 +133,5 @@
+ /* Write out any changes to the temporary file. */
+ file_put_contents($file_name, $image->raw());
+ 
++header('Content-Disposition: attachment');
+ $image->display();
diff -Nru php-horde-5.2.13+debian0/debian/patches/series 
php-horde-5.2.13+debian0/debian/patches/series
--- php-horde-5.2.13+debian0/debian/patches/series  2019-12-14 
03:10:06.0 +0100
+++ php-horde-5.2.13+debian0/debian/patches/series  2020-05-31 
21:45:26.0 +0200
@@ -1,2 +1,3 @@
 0001-Fix-rewrite-base.patch
 0002-CVE-2019-12095-Fix-XSS-vuln-in-the-Horde-Cloud-Block.patch
+0003-CVE-2020-8035-dont-allow-to-view-images-inline.patch

Bug#961943: Upstream has archived the GitHub repository

[Franklin Yu]

Package:  powerlevel9k
Version:  0.6.7-2
Severity: wishlist

The upstream repository, https://github.com/Powerlevel9k/powerlevel9k, has been
archived. Both the repository description and the ReadMe file say that the
repository is deprecated, and redirect user to
https://github.com/romkatv/powerlevel10k. Shall we create a new package
"powerlevel10k", or do we upgrade this package directly? The version number
seems compatible if we want to upgrade in-place.

Bug#961860: make: Broken symlinks: /usr/bin/gmake, /usr/share/man/man1/gmake.1.gz

[Thorsten Glaser]

Package: make
Version: 4.3-1
Followup-For: Bug #961860

adequate also reports it, and manual inspection of the package confirms
that these symlinks are broken.

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

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

Versions of packages make depends on:
ii  libc6  2.30-8

make recommends no packages.

Versions of packages make suggests:
ii  make-doc  4.3-2

-- no debconf information

Bug#961907: This is grave

[Martin Bagge / brother]

severity: critical
Thanks

You will need to workaround this. As such this motivates critical me think.

just doing a straight up curl will hang until timeout. With the expired
cert disabled this is bypassaed (without curl -k).

1. Edit /etc/ca-certificates.conf and put a bang/exclamation mark (!)
before mozilla/AddTrust_External_Root.crt
2. Run update-ca-certificates

Bug#961916: gccgo-go fails to build golang-github-cloudflare-tableflip

[Pirate Praveen]

On Mon, Jun 1, 2020 at 3:17 am, Shengjing Zhu  wrote:
On Sun, May 31, 2020 at 9:51 PM Pirate Praveen 
 wrote:


 Package: gccgo-go
 Version: 2:1.14~1~bpo10+1
 Severity: important
 X-debbugs-cc: debian-backpo...@lists.debian.org

 Changing build dependency to golang-go (>= 2:1.14~) from golang-any 
(>=

 2:1.14~) works. I wonder why gccgo-go is selected over golang-go in
 buster-backports though. It builds fine in sid when gccgo-go (>=
 2:1.14~) is used as build dependency.



gccgo-go (>= 2:1.14)  doesn't mean this version implements go1.14 
features.

As in buster-backports, the gccgo-go points to gccgo-8, which
implements go1.10 features.
You can always check what version of go spec is implemented, by
running `go version`.


Its a bit misleading, but thanks for explaining. I thought it could be 
the older gcc version, hence confirmed on sid with newer gcc version.


Can't gccgo-8 then provide gloang-any (=2:1.10)?




 Command used to build the backport is,

 sbuild -A -s --force-orig-source -c buster-amd64-sbuild
 --extra-repository='deb http://deb.debian.org/debian 
buster-backports
 main' --extra-repository='deb 
http://incoming.debian.org/debian-buildd

 buildd-buster-backports main' --build-dep-resolver=aptitude
 --no-run-lintian

 github.com/cloudflare/tableflip
 # github.com/cloudflare/tableflip
 src/github.com/cloudflare/tableflip/fds.go:82:13: error: reference 
to

 undefined identifier ‘net.ListenConfig’
   lc *net.ListenConfig
  ^


This is the go1.11 feature. See 
https://github.com/golang/go/issues/9661


As gcc maintainers are unlikely to backport gcc, so there's nothing we
can do to make gccgo build this.

What can be fixed is why your build env picks up gccgo instead of 
golang-go.




That will also work. I think if gccgo-8 did not Provide golang-any 
2:1.14 (and instead provided only golang-any 2:1.10), aptitude 
(build-dep resolver) would have picked golang-go correctly.



--
Shengjing Zhu

Bug#961942: mono: mono-source: Embeds time, user, group, etc. in mono-source.tar.xz

[Vagrant Cascadian]

Source: mono
Version: 6.8.0.105+dfsg-3
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps buildpath locale username
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The time, user id, group id, locale, and in some cases build path change
the resulting /usr/src/mono-source.tar.xz

Attached is a patch which should consistantly produce the same
mono-source.tar.xz regardless of the above variations.

While this doesn't fix all of the reproducibility issues in the mono
source package; it should make the mono-source binary package
reproducible. The diff for mono-source is currently large enough that
diffoscope often times out tests.reproducible-builds.org when comparing,
which makes it harder to diagnose and troubleshoot other outstanding
issues.

Thanks!


live well,
  vagrant

From b2a35ebc9e29cde7b87cab4d0a14021f2de9c453 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 30 May 2020 18:57:52 +
Subject: [PATCH 1/2] mono-source: Ensure reproducible mono-source.tar.xz.

Pass flags to tar to sort the input, specify mtime, user id, group id,
format, locale and directory name to ensure reproducible builds:

  https://reproducible-builds.org/docs/archives/
---
 debian/rules | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 71531b6b2b..eae72ddb36 100755
--- a/debian/rules
+++ b/debian/rules
@@ -125,7 +125,12 @@ endif
 
 source: source-stamp
 source-stamp:
-	cd $(DEBIAN_DIR) && tar cJf mono-source.tar.xz --exclude=mono-source.tar.xz -C ../.. $$(cd ..; basename $$(pwd))
+	LC_ALL=C.UTF-8 tar cJf debian/mono-source.tar.xz --exclude=mono-source.tar.xz \
+		--sort=name \
+		--mtime="@${SOURCE_DATE_EPOCH}" \
+		--owner=0 --group=0 --numeric-owner \
+		--format=gnu \
+		--transform="s|^\.|$(DEB_SOURCE_NAME)-$(UPVERSION)+dfsg|" .
 	touch $@
 
 autoreconf: autoreconf-stamp
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#961941: RM: gmetric4j -- ROM; No longer used, low popcon

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the gmetric4j package, it was only used by dropwizard-metrics
but isn't anymore since the version 3.2.6-1.

Thank you,

Emmanuel Bourg

Bug#961929: rsync: syntax for multiple files from remote host seems not working when files are in different modules

[Paul Slootman]

On Sun 31 May 2020, furio wrote:
> 
> using this rsyncd.conf:
> 
> --
>   use chroot = yes
>   [a]
>   comment = a folder
>   path = /home/rsync-test/files/a
>   [b]
>   comment = b folder
>   path = /home/rsync-test/files/b
> --
> 
> The command
> 
>   rsync 127.0.0.1::b/y ::b/z .
> 
> runs as expected, synchronizing files y and z with no errors. However, a 
> problem appears when the files are located in different modules:
> 
>   rsync 127.0.0.1::b/y ::a/x .
> 
> fails with
> 
>   rsync: change_dir "/a" (in b) failed: No such file or directory (2)
>   rsync error: some files/attrs were not transferred (see previous 
> errors) (code 23) at main.c(1677) [generator=3.1.3]
> 
> y has been synchronized, but x was not.  The situation remains the same when 
> the host is explicitly added to the second argument. Similarly, adding the 
> quotes (old style syntax) does not help. 
> 
> Possibly I am misunderstanding something; this behaviour baffles me.

When using modules, rsync makes a connection to the daemon, and requests
connection to that module. That module specifies a path that is the root
of the transfer, and may also specify exclusions, user and group IDs,
and all sorts of extra settings e.g. lock file, syslog facility, read
only, etc. . It is way too complicated to be able to switch modules on
the fly during one connection, so the specification only allows one
module to be used with an rsync daemon per connection.

You can see that it assumes that "::a/x" means the file "a/x" in the
module already specified: "b", hence the error "change_dir "/a" (in b)
failed:".

There is very little chance of your usage being supported anytime,
simply due to just about any option being able to be set differently per
module. There is also not much advantage in combining usage of more than
one module per connection, there is little overhead compared to an ssh
connection.


Paul

Bug#961940: libsqlite3-0:i386: trying to overwrite shared '/usr/share/doc/libsqlite3-0/changelog.gz', which is different […]

[Thorsten Glaser]

On Sun, 31 May 2020, Thorsten Glaser wrote:

> These files indeed differ:
> 
> - a. Extending FTS5 → requires sqlite3_bind_pointer() to find the
> + a. Extending FTS5 -> requires sqlite3_bind_pointer() to find the

Fix looks trivial: adding…

export LC_ALL:=C.UTF-8

… after the first two lines of debian/rules ought to do the trick.

Reproducible Builds would also have caught that, but this was quicker.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#961940: libsqlite3-0:i386: trying to overwrite shared '/usr/share/doc/libsqlite3-0/changelog.gz', which is different […]

[Thorsten Glaser]

Package: libsqlite3-0
Version: 3.32.1-1
Severity: grave
Justification: renders package unusable

[…]
Preparing to unpack .../179-libsqlite3-0_3.32.1-1_x32.deb ...
De-configuring libsqlite3-0:i386 (3.31.1-5) ...
Unpacking libsqlite3-0:x32 (3.32.1-1) over (3.31.1-5) ...
Preparing to unpack .../180-libsqlite3-0_3.32.1-1_i386.deb ...
Unpacking libsqlite3-0:i386 (3.32.1-1) over (3.31.1-5) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-D2l5oU/180-libsqlite3-0_3.32.1-1_i386.deb (--unpack):
 trying to overwrite shared '/usr/share/doc/libsqlite3-0/changelog.gz', which 
is different from other instances of package libsqlite3-0:i386
[…]

These files indeed differ:

- a. Extending FTS5 → requires sqlite3_bind_pointer() to find the
+ a. Extending FTS5 -> requires sqlite3_bind_pointer() to find the


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

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

Versions of packages libsqlite3-0:i386 depends on:
ii  libc6  2.30-8

libsqlite3-0:i386 recommends no packages.

libsqlite3-0:i386 suggests no packages.

-- no debconf information

Bug#961939: bind9: CVE-2020-8616 CVE-2020-8617

[Salvatore Bonaccorso]

Source: bind9
Version: 1:9.16.2-3
Severity: grave
Tags: security upstream
Justification: user security hole
Control: fixed -1 1:9.11.5.P4+dfsg-5.1+deb10u1 
Control: fixed -1 1:9.10.3.dfsg.P4-12.3+deb9u6
Control: found -1 1:9.11.5.P4+dfsg-5.1
Control: found -1 1:9.10.3.dfsg.P4-12.3+deb9u5
Control: found -1 1:9.10.3.dfsg.P4-12.3

Hi,

The following vulnerabilities were published for bind9. Filling mainly
for tracking and making sure there is not stable -> unstable
regression.

CVE-2020-8616[0]:
| A malicious actor who intentionally exploits this lack of effective
| limitation on the number of fetches performed when processing
| referrals can, through the use of specially crafted referrals, cause a
| recursing server to issue a very large number of fetches in an attempt
| to process the referral. This has at least two potential effects: The
| performance of the recursing server can potentially be degraded by the
| additional work required to perform these fetches, and The attacker
| can exploit this behavior to use the recursing server as a reflector
| in a reflection attack with a high amplification factor.


CVE-2020-8617[1]:
| Using a specially-crafted message, an attacker may potentially cause a
| BIND server to reach an inconsistent state if the attacker knows (or
| successfully guesses) the name of a TSIG key used by the server. Since
| BIND, by default, configures a local session key even on servers whose
| configuration does not otherwise make use of it, almost all current
| BIND servers are vulnerable. In releases of BIND dating from March
| 2018 and after, an assertion check in tsig.c detects this inconsistent
| state and deliberately exits. Prior to the introduction of the check
| the server would continue operating in an inconsistent state, with
| potentially harmful results.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-8616
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8616
[1] https://security-tracker.debian.org/tracker/CVE-2020-8617
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8617

Regards,
Salvatore

Bug#961916: gccgo-go fails to build golang-github-cloudflare-tableflip

[Shengjing Zhu]

On Sun, May 31, 2020 at 9:51 PM Pirate Praveen  wrote:
>
> Package: gccgo-go
> Version: 2:1.14~1~bpo10+1
> Severity: important
> X-debbugs-cc: debian-backpo...@lists.debian.org
>
> Changing build dependency to golang-go (>= 2:1.14~) from golang-any (>=
> 2:1.14~) works. I wonder why gccgo-go is selected over golang-go in
> buster-backports though. It builds fine in sid when gccgo-go (>=
> 2:1.14~) is used as build dependency.
>

gccgo-go (>= 2:1.14)  doesn't mean this version implements go1.14 features.
As in buster-backports, the gccgo-go points to gccgo-8, which
implements go1.10 features.
You can always check what version of go spec is implemented, by
running `go version`.

> Command used to build the backport is,
>
> sbuild -A -s --force-orig-source -c buster-amd64-sbuild
> --extra-repository='deb http://deb.debian.org/debian buster-backports
> main' --extra-repository='deb http://incoming.debian.org/debian-buildd
> buildd-buster-backports main' --build-dep-resolver=aptitude
> --no-run-lintian
>
> github.com/cloudflare/tableflip
> # github.com/cloudflare/tableflip
> src/github.com/cloudflare/tableflip/fds.go:82:13: error: reference to
> undefined identifier ‘net.ListenConfig’
>   lc *net.ListenConfig
>  ^

This is the go1.11 feature. See https://github.com/golang/go/issues/9661

As gcc maintainers are unlikely to backport gcc, so there's nothing we
can do to make gccgo build this.

What can be fixed is why your build env picks up gccgo instead of golang-go.

-- 
Shengjing Zhu

Bug#961937: stretch-pu: package ssvnc/1.0.29-3+deb9u1

[Mike Gabriel]

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

Dear release team,

I just uploaded this ssvnc update to Debian stretch:

+  * Non-maintainer upload by the LTS team.

@Magnus: Thanks for fixing ssnvc in testing/unstable regarding below CVE
issues. I saw that those issues haven't been covered for in stretch+buster,
so I was so brisk and dput fixes straight away.

+  * Porting of libvncclient security patches (Closes: #945827):
+- CVE-2018-20020: heap out-of-bound write vulnerability inside structure
+  in VNC client code.
+- CVE-2018-20021: CWE-835: Infinite loop vulnerability in VNC client code.
+- CVE-2018-20022: CWE-665: Improper Initialization vulnerability.
+- CVE-2018-20024: null pointer dereference that can result DoS.

@release team: The upload fixes the not-so-critical CVEs given above.

Thanks+Greets,
Mike

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_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
diff -Nru ssvnc-1.0.29/debian/changelog ssvnc-1.0.29/debian/changelog
--- ssvnc-1.0.29/debian/changelog   2016-07-30 23:10:11.0 +0200
+++ ssvnc-1.0.29/debian/changelog   2020-05-31 20:59:43.0 +0200
@@ -1,3 +1,15 @@
+ssvnc (1.0.29-3+deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload by the LTS team.
+  * Porting of libvncclient security patches (Closes: #945827):
+- CVE-2018-20020: heap out-of-bound write vulnerability inside structure
+  in VNC client code.
+- CVE-2018-20021: CWE-835: Infinite loop vulnerability in VNC client code.
+- CVE-2018-20022: CWE-665: Improper Initialization vulnerability.
+- CVE-2018-20024: null pointer dereference that can result DoS.
+
+ -- Mike Gabriel   Sun, 31 May 2020 20:59:43 +0200
+
 ssvnc (1.0.29-3) unstable; urgency=low
 
   * debian/rules: Add call to dh_strip_nondeterminism.
diff -Nru ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20020.patch 
ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20020.patch
--- ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20020.patch   
1970-01-01 01:00:00.0 +0100
+++ ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20020.patch   
2019-12-16 19:37:52.0 +0100
@@ -0,0 +1,22 @@
+Description: CVE-2018-20020
+ heap out-of-bound write vulnerability inside structure in VNC client code that
+ can result remote code execution
+---
+
+Author: Abhijith PA 
+Origin: 
https://github.com/LibVNC/libvncserver/commit/7b1ef0ffc4815cab9a96c7278394152bdc89dc4d
+Bug: https://github.com/LibVNC/libvncserver/issues/250
+Bug-Debian: https://bugs.debian.org/916941
+Last-Update: 2018-12-23
+
+--- a/vnc_unixsrc/vncviewer/corre.c
 b/vnc_unixsrc/vncviewer/corre.c
+@@ -76,7 +76,7 @@
+ FillRectangle(rx, ry, rw, rh, gcv.foreground);
+ #endif
+ 
+-if (!ReadFromRFBServer(buffer, hdr.nSubrects * (4 + (BPP / 8
++if (hdr.nSubrects > BUFFER_SIZE / (4 + (BPP / 8)) || 
!ReadFromRFBServer(buffer, hdr.nSubrects * (4 + (BPP / 8
+   return False;
+ 
+ ptr = (CARD8 *)buffer;
diff -Nru ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20021.patch 
ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20021.patch
--- ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20021.patch   
1970-01-01 01:00:00.0 +0100
+++ ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20021.patch   
2019-12-16 19:37:52.0 +0100
@@ -0,0 +1,22 @@
+Description: CVE-2018-20021
+ CWE-835: Infinite loop vulnerability in VNC client code. Vulnerability allows
+ attacker to consume excessive amount of resources like CPU and RAM
+---
+
+Author: Abhijith PA 
+Origin: 
https://github.com/LibVNC/libvncserver/commit/c3115350eb8bb635d0fdb4dbbb0d0541f38ed19c
+Bug: https://github.com/LibVNC/libvncserver/issues/251
+Bug-Debian: https://bugs.debian.org/916941
+Last-Update: 2018-12-23
+
+--- a/vnc_unixsrc/vncviewer/rfbproto.c
 b/vnc_unixsrc/vncviewer/rfbproto.c
+@@ -3156,7 +3156,7 @@
+   if (db) fprintf(stderr, "Raw: %dx%d+%d+%d\n", 
rect.r.w, rect.r.h, rect.r.x, rect.r.y);
+   area_raw += rect.r.w * rect.r.h;
+ 
+-  while (rect.r.h > 0) {
++  while (linesToRead && rect.r.h > 0) {
+   if (linesToRead > rect.r.h) {
+   linesToRead = rect.r.h;
+   }
diff -Nru ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20022.patch 
ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20022.patch
--- ssvnc-1.

Bug#959914: Xarchiver failed to extract multi-part passworded 7z

[Markus Koschany]

Control: forwarded -1 https://github.com/ib/xarchiver/issues/92





signature.asc
Description: OpenPGP digital signature

Bug#961936: buster-pu: package ssvnc/1.0.29-4+deb10u1

[Mike Gabriel]

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

Dear release team,

I just uploaded this ssvnc update to Debian buster:

+  * Non-maintainer upload by the LTS team.

@Magnus: Thanks for fixing ssnvc in testing/unstable regarding below CVE
issues. I saw that those issues haven't been convered in stretch+buster,
so I was so brisk and dput fixes straight away.

+  * Porting of libvncclient security patches (Closes: #945827):
+- CVE-2018-20020: heap out-of-bound write vulnerability inside structure
+  in VNC client code.
+- CVE-2018-20021: CWE-835: Infinite loop vulnerability in VNC client code.
+- CVE-2018-20022: CWE-665: Improper Initialization vulnerability.
+- CVE-2018-20024: null pointer dereference that can result DoS.

@release team: The upload fixes the not-so-critical CVEs given above.

Thanks+Greets,
Mike


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_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
diff -Nru ssvnc-1.0.29/debian/changelog ssvnc-1.0.29/debian/changelog
--- ssvnc-1.0.29/debian/changelog   2018-06-24 19:39:53.0 +0200
+++ ssvnc-1.0.29/debian/changelog   2020-05-31 20:58:21.0 +0200
@@ -1,3 +1,15 @@
+ssvnc (1.0.29-4+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload by the LTS team.
+  * Porting of libvncclient security patches (Closes: #945827):
+- CVE-2018-20020: heap out-of-bound write vulnerability inside structure
+  in VNC client code.
+- CVE-2018-20021: CWE-835: Infinite loop vulnerability in VNC client code.
+- CVE-2018-20022: CWE-665: Improper Initialization vulnerability.
+- CVE-2018-20024: null pointer dereference that can result DoS.
+
+ -- Mike Gabriel   Sun, 31 May 2020 20:58:21 +0200
+
 ssvnc (1.0.29-4) unstable; urgency=low
 
   * default-jdk-headless is enough to build.
diff -Nru ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20020.patch 
ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20020.patch
--- ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20020.patch   
1970-01-01 01:00:00.0 +0100
+++ ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20020.patch   
2019-12-16 19:37:52.0 +0100
@@ -0,0 +1,22 @@
+Description: CVE-2018-20020
+ heap out-of-bound write vulnerability inside structure in VNC client code that
+ can result remote code execution
+---
+
+Author: Abhijith PA 
+Origin: 
https://github.com/LibVNC/libvncserver/commit/7b1ef0ffc4815cab9a96c7278394152bdc89dc4d
+Bug: https://github.com/LibVNC/libvncserver/issues/250
+Bug-Debian: https://bugs.debian.org/916941
+Last-Update: 2018-12-23
+
+--- a/vnc_unixsrc/vncviewer/corre.c
 b/vnc_unixsrc/vncviewer/corre.c
+@@ -76,7 +76,7 @@
+ FillRectangle(rx, ry, rw, rh, gcv.foreground);
+ #endif
+ 
+-if (!ReadFromRFBServer(buffer, hdr.nSubrects * (4 + (BPP / 8
++if (hdr.nSubrects > BUFFER_SIZE / (4 + (BPP / 8)) || 
!ReadFromRFBServer(buffer, hdr.nSubrects * (4 + (BPP / 8
+   return False;
+ 
+ ptr = (CARD8 *)buffer;
diff -Nru ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20021.patch 
ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20021.patch
--- ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20021.patch   
1970-01-01 01:00:00.0 +0100
+++ ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20021.patch   
2019-12-16 19:37:52.0 +0100
@@ -0,0 +1,22 @@
+Description: CVE-2018-20021
+ CWE-835: Infinite loop vulnerability in VNC client code. Vulnerability allows
+ attacker to consume excessive amount of resources like CPU and RAM
+---
+
+Author: Abhijith PA 
+Origin: 
https://github.com/LibVNC/libvncserver/commit/c3115350eb8bb635d0fdb4dbbb0d0541f38ed19c
+Bug: https://github.com/LibVNC/libvncserver/issues/251
+Bug-Debian: https://bugs.debian.org/916941
+Last-Update: 2018-12-23
+
+--- a/vnc_unixsrc/vncviewer/rfbproto.c
 b/vnc_unixsrc/vncviewer/rfbproto.c
+@@ -3156,7 +3156,7 @@
+   if (db) fprintf(stderr, "Raw: %dx%d+%d+%d\n", 
rect.r.w, rect.r.h, rect.r.x, rect.r.y);
+   area_raw += rect.r.w * rect.r.h;
+ 
+-  while (rect.r.h > 0) {
++  while (linesToRead && rect.r.h > 0) {
+   if (linesToRead > rect.r.h) {
+   linesToRead = rect.r.h;
+   }
diff -Nru ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20022.patch 
ssvnc-1.0.29/debian/patches/libvncclient_CVE-2018-20022.patch
--- ssvnc-1.0.29/debian/pa

Bug#961206: improve sphinx usage for cross building

[Dmitry Shachnev]

Hi Drew!

On Fri, May 29, 2020 at 01:34:16AM +0800, Drew Parsons wrote:
> Source: sphinx
> Followup-For: Bug #961206
>
> I've just updated numba from Build-Depends: python3-sphinx
> to Build-Depends: sphinx as recommended here (#961741).
>
> The change is giving me a lintian error:
>
> E: numba source: missing-build-dependency-for-dh-addon sphinxdoc => 
> python-sphinx | python3-sphinx | dh-sequence-sphinxdoc
>
> Should the lintian test be updated for the new sphinx structure (e.g.
> to include sphinx as an alternative)?

Good catch. Submitted a merge request for Lintian:

https://salsa.debian.org/lintian/lintian/-/merge_requests/315

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#961744: devscripts: uscan: please add capability to download gzipped content

[Gianfranco Costamagna]

control: forcemerge 961744 -1

> 
> thanks, I'll look at this. Note that this is a server side bug: it
> should not send compressed data if request doesn't specify
> "Accept-Encoging: gzip"
> 

Hello, yes we know this is a server issue, but meh, we can't fix the internet :)

Did you look at the patch in: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952738 ?

Not sure how and why, but the patch is really more trivial than my approach!

G.

Bug#947438: RM: llvm-toolchain-7 -- ROM; Less versions of llvm, the better

[Gianfranco Costamagna]

control: tags -1 -moreinfo
Hello,

flang (out from testing) is the last blocker, I asked on 947437 if we can 
proceed
with this.

is it possible to remove it anyway, or break the build of it?

(ccing Alastair)

G.

Bug#961660: DebHelper dh_bash-completion broken since Stretch OS, Bash Completion scripts not installed anymore into Path according to debian/.bash-completion

[Gabriel F. T. Gomes]

On 27 May 2020, Jürgen Kuri wrote:
>
>When I build the packages for Debian Jessie, everything works as expected, 
>both completion scripts are installed into the path:
>
>   $  ls -la /etc/bash_completion.d/
>   total 24
>   drwxr-xr-x  2 root root  4096 May 26 16:58 .
>   drwxr-xr-x 92 root root  4096 May 18 12:12 ..
>   -rw-r--r--  1 root root   933 May 18 17:26 fsmtool2-completion
>   -rw-r--r--  1 root root   980 May 18 17:26 fsmtool2_mtest-completion

For some time (I don't know exactly how long, because I only adopted
bash-completion about 2 years ago), the default installation path for
completion is /usr/share/bash-completion/completions/, as you have
noticed. So, I'd say that dh_bash-completion is doing the rigth thing.

>When I build the packages for Debian OS Stretch or Buster, bash-completion 
>does not work for both command line tools any more cause the completion 
>scripts are installed below:
>
>   * /usr/share/bash-completion/completions/fsmtool2-completion 
>   * /usr/share/bash-completion/completions/fsmtool2_mtest-completion 

On the other, you are saying that the completions do not work from this
location, and that's puzzling me. Could you provide more details about
the problem you are actually getting? Bash-completion is supposed to
work with files in this location.


Cheers,
Gabriel

Bug#961917: pppoe: Home page is wrong and version in Debian is old

[Dianne Skoll]

Package: pppoe
Severity: normal

Dear Maintainer,

The home page of RP-PPPoE has moved; it is now:

https://dianne.skoll.ca/projects/rp-pppoe/

Additionally, RP-PPPoEE 3.14 isavaileble:

https://dianne.skoll.ca/projects/rp-pppoe/download/rp-pppoe-3.14.tar.gz
https://dianne.skoll.ca/projects/rp-pppoe/download/rp-pppoe-3.14.tar.gz.sig

Regards,

Dianne.

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

Kernel: Linux 5.6.13 (SMP w/12 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages pppoe depends on:
ii  libc6  2.28-10
ii  ppp2.4.7-2+4.1+deb10u1

pppoe recommends no packages.

pppoe suggests no packages.

Bug#947437: flang in bullseye - llvm 11 ?

[Gianfranco Costamagna]

On Sat, 18 Apr 2020 17:09:35 +0200 Sylvestre Ledru  wrote:
> Le 18/04/2020 à 16:10, Alastair McKinstry a écrit :
> > Hi,
> > 
> > flang is now merged into LLVM base.
> > 
> > I can build flang/f18 from the LLVM main install, but this targets llvm-11.
> > 
> > Are we likely to have llvm-11 (not necessarily default) in Debian
> > Bullseye ? what approach should be taken ?
> Quite likely.
> I think llvm 11 will be released end of 2020 / early 2021
> and is already available in experimental.
> 
> Cheers,
> Sylvestre
> 
> 
> 

So, since flang is the last llvm-toolchain-7 reverse-dependency, what about 
removing it
for now or break it so we can drop llvm-7 while 11 becomes available in sid?

G.

Bug#950535: [pkg-netfilter-team] Bug#950535: iptables-restore segfaults on nat table

[Alberto Molina Coballes]

This bug has been fixed upstream and it will go in 1.8.5 release.

Thanks for reporting.

Alberto

Bug#961935: gdm3 fails to display uid=501

[Graeme Vetterlein]

Package: gdm3
Version: 3.30.2-3
Severity: important
Tags: d-i

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


I have just installed debian 10.4 . I opted to install multiple desktops
including cinnamon, gnome3 and xfce
I need to set my uid to 501 as I use NFSv3 an my NAS allocates normal users in
the range 501 to 999

Two issues (possibly related)

1: My username does not appear as a choice on gdm3 (the documentation says all
above 500 should) [ I cannot find a config setting to chnage this ]
<
https://help.gnome.org/admin/gdm/3.26/configuration.html.en#generalsessionconfig
>

2. If I manually type my name and logon , using the "cog" to select say
cinnamon, the I get cinnamon
  2a If I log off & on again, I stoll get cinnamon
  2b If I reboot, it goes back to gnome3

I created a new user (user666)

$ sudo useradd -c "uid is 666" -m -u 666 user666

$ sudo passwd user666
New password:
Retype new password:
passwd: password updated successfully

Then at GDM3 login:

I turned on debug and saw:

4 matches for "Error" in buffer: gdm3.debug3
517:May 28 19:02:10 real gdm-password]: AccountsService: Error calling
GetAll() when retrieving properties for /org/freedesktop/Accounts/User666:
Operation was cancelled
   1313:May 28 19:04:53 real gdm-launch-environment]: AccountsService: Error
calling GetAll() when retrieving properties for
/org/freedesktop/Accounts/User117: Operation was cancelled
   1314:May 28 19:04:53 real gdm-launch-environment]: AccountsService: Error
calling GetAll() when retrieving properties for
/org/freedesktop/Accounts/User117: Operation was cancelled
   1531:May 28 19:05:26 real gdm-password]: AccountsService: Error calling
GetAll() when retrieving properties for /org/freedesktop/Accounts/User666:
Operation was cancelled

If I were to guess, I'd say the limit had been set to 1000 , not 500 as per
docs. But in anycase I'd like to override back to around 200. The lack of
persistance of the the desktop session choice seem to affect users in the same
pid range (<1000)



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

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.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 gdm3 depends on:
ii  accountsservice   0.6.45-2
ii  adduser   3.118
ii  cinnamon [x-window-manager]   3.8.8-1
ii  cinnamon-session [x-session-manager]  3.8.2-1
ii  dconf-cli 0.30.1-2
ii  dconf-gsettings-backend   0.30.1-2
ii  debconf [debconf-2.0] 1.5.71
ii  gir1.2-gdm-1.03.30.2-3
ii  gnome-session [x-session-manager] 3.30.1-2
ii  gnome-session-bin 3.30.1-2
ii  gnome-settings-daemon 3.30.2-3
ii  gnome-shell   3.30.2-11~deb10u1
ii  gnome-terminal [x-terminal-emulator]  3.30.2-2
ii  gsettings-desktop-schemas 3.28.1-1
ii  libaccountsservice0   0.6.45-2
ii  libaudit1 1:2.8.4-3
ii  libc6 2.28-10
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libgdm1   3.30.2-3
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libglib2.0-bin2.58.3-2+deb10u2
ii  libgtk-3-03.24.5-1
ii  libkeyutils1  1.6-6
ii  libpam-modules1.3.1-5
ii  libpam-runtime1.3.1-5
ii  libpam-systemd241-7~deb10u4
ii  libpam0g  1.3.1-5
ii  librsvg2-common   2.44.10-2.1
ii  libselinux1   2.8-1+b1
ii  libsystemd0   241-7~deb10u4
ii  libwrap0  7.6.q-28
ii  libx11-6  2:1.6.7-1
ii  libxau6   1:1.0.8-1+b2
ii  libxcb1   1.13.1-2
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  10.2019051400
ii  muffin [x-window-manager] 3.8.2-1
ii  mutter [x-window-manager] 3.30.2-9~deb10u1
ii  policykit-1   0.105-25
ii  procps2:3.3.15-2
ii  ucf   

Bug#961934: RFS: gtick/0.5.5-1 -- Metronome application

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gtick"

 * Package name: gtick
   Version : 0.5.5-1
   Upstream Author : Alex Roberts 
 * URL : http://www.antcom.de/gtick/
 * License : GPL-3
 * Vcs : https://salsa.debian.org/debian/gtick
   Section : sound

It builds those binary packages:

  gtick - Metronome application

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/g/gtick/gtick_0.5.5-1.dsc

Changes since the last upload:

   * QA upload.
   * New upstream version 0.5.5
 - New version fixes FTBFS with gcc-10. (Closes: #957318)
   * Update AppStream Metadata.
   * Update Standards-Version to 4.5.0
 - Update priority to optional
   * Use debhelper-compat.
 - Update to compat level 13.
   * Fix AppStream metadata location.
   * Orphan the package. (See: #837460)
   * Add Vcs link to salsa.
   * Remove duplicate homepage.


-- 
Regards
Sudip

Bug#961839: closure-compiler: FTBFS: is not abstract and does not override abstract method test(Object) in Predicate

[Emmanuel Bourg]

Le 31/05/2020 à 19:36, tony mancill a écrit :

> Thank you for the bug report.  This is due to the recent Guava update
> from 19.0 -> 29.0.  test() was introduced in version 21.  Somewhat
> ironically, test() appears to lack any Javadoc [1] because it was added
> to more closely emulate java.util.function.Predicate [2] and use of the
> Guava Predicate is discouraged by its authors anyway [3].


If that helps, building closure-compiler with source/target=8 should fix
this issue. I did that for Gradle this week to fix the same issue.

Emmanuel Bourg

Bug#961933: odt2txt: autopkgtest failure: file: command not found

[Paul Gevers]

Source: odt2txt
Version: 0.5-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package odt2txt, great.
However, it fails. Currently this failure is blocking the migration to
testing [1]. Can you please investigate the situation and fix it?

I copied some of the output at the bottom of this report. Seems like
you're missing a test dependency.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=odt2txt

https://ci.debian.net/data/autopkgtest/testing/amd64/o/odt2txt/5614340/log.gz

autopkgtest [09:10:31]: test command2: cp debian/tests/file.odt
$AUTOPKGTEST_TMP;   odt2txt --raw --output=$AUTOPKGTEST_TMP/file.xml
$AUTOPKGTEST_TMP/file.odt;   file $AUTOPKGTEST_TMP/file.xml
autopkgtest [09:10:31]: test command2: [---
bash: file: command not found
autopkgtest [09:10:31]: test command2: ---]



signature.asc
Description: OpenPGP digital signature

Bug#961932: nethack-lisp: broken and unmaintained

[Markus Koschany]

Package: nethack-lisp
Version: 3.6.6-1
Severity: serious

I have just updated nethack to the latest upstream version to fix
several security vulnerabilities and a compilation error with GCC 10.
Unfortunately the Debian specific lisp patches don't work anymore with
the current release. I could fix a few minor errors but there are more
issues and I'm not really interested in maintaining a fork of nethack.
Though I guess someone else can fix it. I have pushed all lisp related
patches to a new lisp branch in Git.

I wonder if we should drop nethack-lisp completely or try to upstream
the code. It is quite obvious that the additional work to make the
lisp port work prevents more regular updates.

Bug#961839: closure-compiler: FTBFS: is not abstract and does not override abstract method test(Object) in Predicate

[tony mancill]

On Sat, May 30, 2020 at 02:13:25AM -0400, Sandro Tosi wrote:
> Source: closure-compiler
> Version: 20130227+dfsg1-10
> Severity: serious
> 
> 
>
> [javac] 
> /build/closure-compiler-20130227+dfsg1/src/com/google/javascript/jscomp/Scope.java:67:
>  error:  is not abstract and 
> does not override abstract method test(Var) in Predicate
> [javac]   new Predicate() {
> [javac]^

Hi Sandro,

Thank you for the bug report.  This is due to the recent Guava update
from 19.0 -> 29.0.  test() was introduced in version 21.  Somewhat
ironically, test() appears to lack any Javadoc [1] because it was added
to more closely emulate java.util.function.Predicate [2] and use of the
Guava Predicate is discouraged by its authors anyway [3].

Since closure-compiler is hopelessly old, I think we should reevaluate
where we are with respect to the necessary build-dependencies to update
to a modern version of closure-compiler.

Cheers,
tony

[1] 
https://www.javadoc.io/doc/com.google.guava/guava/29.0-jre/src-html/com/google/common/base/Predicate.html#line.77
[2] 
https://cr.openjdk.java.net/~iris/se/11/latestSpec/api/java.base/java/util/function/Predicate.html#test(T)
[3] https://github.com/google/guava/wiki/FunctionalExplained#caveats


signature.asc
Description: PGP signature

Bug#961923: python-debian: Please support easily editing debian/control

[Jelmer Vernooij]

On Sun, May 31, 2020 at 04:40:26PM +0100, Federico Ceratto wrote:
> Thanks for developing python-debian.
> It would be very nice if it could support easy and "pythonic"
> editing of debian/control:
> - Load the whole file into a tree of dicts and lists
> - Allow updating it and writing to file
> - Preserve the order of items in lists e.g. dependencies
> 
> This would be useful for creating linting tools similar to
> lintian-brush.

FWIW lintian-brush actually has an interface that does this for both
debian/control and other control files (based on python-debian). I can
split it out into a separate module if that would be useful, though it
should also already be usable as is:

from lintian_brush.control import ControlUpdater

with ControlUpdater('debian/control') as updater:
updater.source['Maintainer'] = 'Joe Example '

Will update debian/control while preserving whitespace, and will raise
an exception when it can't.

Jelmer

Bug#961432: RFP: picom -- lightweight compositor for X11

[Lev Lamberov]

Вс 31 мая 2020 @ 17:29 Nikos Tsipinakis :

> On 31/05, Lev Lamberov wrote:
>> Yep, but as I understand they are in situation where some distributions
>> picked their fork at the times it was not renamed to picom. Now this
>> causes troubles. So the rename and migration plan. Since in Debian we
>> are starting from scratch, I don't think we need these hacks. Anyway,
>> migrating from compton to picom will require manually installing a new
>> package, so users are already know that they need to learn about that
>> new thing and to change their configuration. Alternatively, I'd choose
>> update-alternatives way, but since there are almost no alternatives in
>> terms of maintained X11 compositors, I personally don't think it
>> deserves any time investment.
>
> Makes sense, will leave as-is then.
>
>> Ouch! And tags are also missing from your repository. Since you use gbp,
>> then gbp push is to the rescue.
>
> That's intentional, since I'm not sure which revision will end up uploaded
> currently I haven't tagged it yet to avoid force updates.
>
>> Will look again at the picom package this evening.
>
> Looking forward to it :)

So, I looked into the package. Did some tweaks to d/copyright, you'll
find them in MR. I think the package is ready to be uploaded. In fact,
it is quite good. Thanks for your contribution!

Please, finalize your work, add tags and ping me. I'll upload it to the
Debian archive.

Congrats!

Cheers!
Lev

Bug#496009: perl-modules: time summary from Benchmark contains extra space

[Niko Tyni]

Control: tag -1 moreinfo

On Fri, Aug 22, 2008 at 01:24:43AM +, brian m. carlson wrote:
> Package: perl-modules
> Version: 5.10.0-13
> Severity: minor
> Tags: upstream
> 
> In Benchmark, the default style for timestr is %5.2f.  However, when
> running tests using prove (which indirectly uses Benchmark), this
> produces an extra space before the parenthesis:
> 
>   Files=1, Tests=2,  0 wallclock secs ( 0.02 cusr +  0.00 csys =  0.02 CPU)
> 
> This looks odd and unbalanced.

Hi, sorry that nobody answered this before.

I'm reviewing some old bugs and while the Benchmark output in this one
hasn't changed in twelve years AFAICS, I'm not sure I get the problem.

What extra space are you referring to above? I see some *after* the first
parenthesis, but the one between 'secs' and '(' seems appropriate.

In case you mean the space after the first parenthesis, that's a direct
result of the documented default %5.2f format you mentioned, right?

 % perl -MBenchmark -le '$t1 = Benchmark->new; sleep 1; $t2 = Benchmark->new; 
print timestr(timediff($t2, $t1))'
  1 wallclock secs ( 0.00 usr +  0.00 sys =  0.00 CPU)

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

Bug#961925: cppcheck-gui: reports errors from python when running python addons

[Joachim Reichel]

Hi Jiri,

indeed, this must have slipped when updating to cppcheck 2.0. Setting
PYTHONPHOME to /usr seems to work as well and should work in the more general
case of other python interpreters. Will upload a fixed package shortly.

Best regards,
  Joachim

Bug#961931: ITP: netcdf-java -- netCDF Java library

[Vincent Prat]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-scie...@lists.debian.org, debian-j...@lists.debian.org

* Package name    : netcdf-java
  Version : 5.3.2
  Upstream Author : University Corporation for Atmospheric
Research/UnidataName 
* URL : https://www.unidata.ucar.edu/software/netcdf-java/
* License : BSD-3
  Programming Lang: Java
  Description : netCDF Java library

The netCDF Java library provides an interface for scientific data
access. It can be used to read scientific data from a variety of file
formats including netCDF, HDF, GRIB, BUFR, and many others. By itself,
the netCDF-Java library can only write netCDF-3 files. It can write
netCDF-4 files by using JNI to call the netCDF-C library. It also
implements Unidata's Common Data Model (CDM) to provide data geolocation
capabilities.

This package is a dependency of HDFView.

It will be maintained under the umbrella of the Debian Science Team.

Bug#961429: Subject: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.

[Mattia Rizzolo]

On Sun, May 31, 2020 at 02:54:34PM +, Vasyl Gello wrote:
> I do still appreciate additional reviews on packaging and security of
> cryptopass, because I thought it could be a great example of "making a
> small pavkage to learn Debian packaging".

From my side, the only thing that I would have to say about the new
release, is that since there is now an upstream testsuite, it would be
good to have an autopkgtest.
Apart from that, I notice that some of my previous comments have not
been applied, but those are not new by definition :)

I reckon that asking for review of a small package is indeed a great way
to learn; nevertheless, thank you for thinking more deeply about the
package and retract the RFS.

I would have also wanted to ask you to close this RFS, but I see bartm's
script is too quick these days, removing the package as soon as you
removed it from mentors u.U

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#951118: Current status

[Evangelos Ribeiro Tzaras]

Hello Olivier,

i wanted to ask how the packaging is coming along.
I had previously written you an email and CC'ed the DebianOnMobile
maintainers mailinglist, but have not yet received an answer, so I
thought it would give it a try on this more public channel.

The DebianOnMobile team has prepared packaging of the dependencies
(axc[1], and libomemo[2]) and has also done some packaging of our own on
lurch [3].
libomemo has not yet been uploaded to ftp masters because of a possible
bug which still needs investigating.

We are interested in purple-lurch because it would enable encrypted
messaging in our libpurple client chatty [4].

I look forward to your reply

[1] https://salsa.debian.org/DebianOnMobile-team/libaxc
[2] https://salsa.debian.org/DebianOnMobile-team/libomemo
[3] https://salsa.debian.org/DebianOnMobile-team/purple-lurch
[4] https://salsa.debian.org/DebianOnMobile-team/chatty

Bug#959156: transmission-daemon: Service file contains erroneous ExecStop directive

[Alexandre Rossi]

Hi,

For the record, this is in
debian/patches/transmission-daemon_execstop_service.patch

upstream thinks it is not a good idea.
https://github.com/transmission/transmission/issues/138

Thanks,

Alex

Bug#961930: ITP: pinball-table-gnu -- GNU Pinball table for emilia pinball

[Philippe Coval]

Package: wnpp
Severity: wishlist
Owner: Philippe Coval 

* Package name: pinball-table-gnu
  Version : 0.0.0
  Upstream Author : Ben Asselstine ,
Philippe Coval 
* URL : https://github.com/rzr/pinball-table-gnu
* License : GPL+ and Other free licences
  Programming Lang: C++
  Description : GNU Pinball table for emilia pinball



Extra table for emilia pinball already shipped into debian:

https://packages.qa.debian.org/p/pinball.html

To avoid license mess, extra tables are maintained separately:

https://github.com/rzr/pinball/issues/4


As upstream developer and debian maintainer,
and for developer convenience
I already started to package it in upstream tree.
Effort can also be tracked at:

https://github.com/rzr/pinball-table-gnu/issues/3


Co-maintainers (ie debian-games) are also welcome,
feel free to contact us here or un above link.

Note, package is not yet released, I plan do it very soon.

Then I will upload to mentors.debian.net,
but I am looking for sponsorship.

PS: pinball is orphaned too,
I plan to adopt it too and release new upstream version too.


Also the 1st extra table is in still NEW since 2020-05-01 :

https://ftp-master.debian.org/new/pinball-table-hurd_0.0.20200312-1.html# 

Regards

Bug#961929: rsync: syntax for multiple files from remote host seems not working when files are in different modules

[furio]

Package: rsync
Version: 3.1.3-6
Severity: normal

Dear Maintainer,

I am trying to rsync individually named multiple files using the rsync daemon.

In the ADVANCED USAGE section, the manual page says

The syntax for requesting multiple files from a remote host is done by
specifying additional remote-host  args in the same style as the first,
or with the hostname omitted.  For instance, all these work:

rsync -av host:file1 :file2 host:file{3,4} /dest/
rsync -av host::modname/file{1,2} host::modname/file3 /dest/
rsync -av host::modname/file1 ::modname/file{3,4}

Older versions of rsync required using quoted spaces in the SRC, like 
these examples:

rsync -av host:’dir1/file1 dir2/file2’ /dest
rsync host::’modname/dir1/file1 modname/dir2/file2’ /dest

I created a test file tree using

mkdir /home/rsync-test
mkdir /home/rsync-test/conf
mkdir /home/rsync-test/files
mkdir /home/rsync-test/files/a
mkdir /home/rsync-test/files/b
echo "file x" > /home/rsync-test/files/a/x
echo "file y" > /home/rsync-test/files/b/y
echo "file z" > /home/rsync-test/files/b/z

and then run 

/usr/bin/rsync --daemon --config=/home/rsync-test/conf/rsyncd.conf 
--address=127.0.0.1

using this rsyncd.conf:

--
use chroot = yes
[a]
comment = a folder
path = /home/rsync-test/files/a
[b]
comment = b folder
path = /home/rsync-test/files/b
--

The command

rsync 127.0.0.1::b/y ::b/z .

runs as expected, synchronizing files y and z with no errors. However, a 
problem appears when the files are located in different modules:

rsync 127.0.0.1::b/y ::a/x .

fails with

rsync: change_dir "/a" (in b) failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous 
errors) (code 23) at main.c(1677) [generator=3.1.3]

y has been synchronized, but x was not.  The situation remains the same when 
the host is explicitly added to the second argument. Similarly, adding the 
quotes (old style syntax) does not help. 

Possibly I am misunderstanding something; this behaviour baffles me.

Thanks for the attention

Furio


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

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

Versions of packages rsync depends on:
ii  base-files   10.3+deb10u4
ii  init-system-helpers  1.56+nmu1
ii  libacl1  2.2.53-4
ii  libattr1 1:2.4.48-4
ii  libc62.28-10
ii  libpopt0 1.16-12
ii  lsb-base 10.2019051400

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:7.9p1-10+deb10u2
ii  openssh-server  1:7.9p1-10+deb10u2

-- no debconf information

Bug#961641: Icewm needs too the X11 en_US locales, removed by localepurge v. 0.7.3.9

[Martintxo]

Hello

(Puting icewm maintainer in CC for he to know...)

I was searching how to solve a recent bug "in icewm", and now, thanks to
this bug report, I find it.

The bug sintoms are that the window titles (in firefox for example) with some
locale especial character, like accent marks and so, get truncated at this
special character point. And in the Icewm About window, the CodeSet field
changes from UTF-8 (in my case) to ANSI_X3.4-1968...

The problem was, too, that localepurge 0.7.3.9 had delete the files in
/usr/share/X11/locale/en_US.UTF-8.

Apliying the sugested workaround in this bugreport by Michel Casabona (many
thanks!!) solved the problem:
 - sudo dpkg-reconfigure localepurge, and select to NO purge en_US.UTF-8
 - sudo apt install --reinstall libx11-data
 - logout and login to Icewm. Solved!!

For you to know, my locale set in /etc/default/locale is: 
 LANG=eu_ES.UTF-8

So, yes, localepurge need to keep en_US.UTF-8 in /usr/share/X11/locale/.

Greetings. Martintxo.


Sustrai Erakuntza: respuesta jurídico-técnica a proyectos insostenibles.
  proiektu jasangaitzei erantzun juridiko-teknikoa.
  https://www.fundacionsustrai.org
  https://www.sustraierakuntza.org

Bug#961928: perl: incomplete transition away from Locale-Codes and B-Debug

[Niko Tyni]

Package: perl
Version: 5.30.2-1
Severity: minor

Locale-Codes and B-Debug were deprecated in 5.28 and removed in 5.30.

It looks like we forgot to remove them from lib/deprecate.pm
(debian/deprecate-with-apt.diff). Also, perl-modules-5.30 still
Breaks: liblocale-codes-perl (<< 3.56), which should probably
have been removed along with libb-debug-perl around commit
c9e5f8647fd0a4c7cf9ab32ca3b5121991ca5244 .

I expect this doesn't matter much in practice.
-- 
Niko Tyni   nt...@debian.org

Bug#961927: amule: aMule can not initiate server list

[Michal Wysokinski]

Package: amule
Version: 1:2.3.2+git20200530.3a77afb-1
Severity: important

Dear Maintainer,

When launching aMule without any previous configuration in home directory
(~/.aMule) it tries to download server list from default address
http://upd.emule-security.org/server.met. Unfortunately it is not able to
download this file even though file exists and can be downloaded using Firefox.
The same situation occures when aMule tries to boots strap nodes for kademilla
network.

Without server or nodes aMule is not able to operate so it is unusable.

Regards,
Michal



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

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), 
LANGUAGE=pl_PL.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 amule depends on:
ii  amule-common   1:2.3.2+git20200530.3a77afb-1
ii  libboost-system1.67.0  1.67.0-18
ii  libc6  2.30-8
ii  libcrypto++6   5.6.4-9
ii  libgcc-s1  10-20200502-1
ii  libgeoip1  1.6.12-6
ii  libixml10  1:1.8.4-2
ii  libstdc++6 10-20200502-1
ii  libupnp13  1:1.8.4-2
ii  libwxbase3.0-0v5   3.0.5.1+dfsg-1
ii  libwxgtk3.0-gtk3-0v5   3.0.5.1+dfsg-1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages amule recommends:
ii  amule-utils  1:2.3.2+git20200530.3a77afb-1
ii  unzip6.0-25

Versions of packages amule suggests:
pn  amule-utils-gui  

-- no debconf information

Bug#961926: rr: record fails on i386

[Bernhard Übelacker]

Package: rr
Version: 5.3.0-3
Severity: normal

Dear Maintainer,
thank you for building i386 again.

Unfortunately I found recording not working in a small test [1].

A git bisect led to a helper function introduced by upstream in [2].
This helper uses a function parameter of type off_t.
But the pwrite64 from glibc uses off64_t.
Therefore offset values with the highest bit set get incorrectly
converted to the 64 bit type, e.g.: 0xb622 -> 0xb622
Therefore the write fails and rr stops.

Attached patch makes rr work on i386 and passing most tests
in my test VM, except [3]. Have not tested for side effects at amd64.

I am going to try to forward this to upstream too,
will update this bug then.

Kind regards,
Bernhard




[1]
$ /usr/bin/rr record /bin/ls
rr: Saving execution to trace directory `/home/benutzer/.local/share/rr/ls-0'.
[FATAL /build/rr-wu2MDM/rr-5.3.0/src/AddressSpace.cc:320:map_rr_page()] 
 (task 6291 (rec:6291) at time 14)
 -> Assertion `child_fd == -EACCES' failed to hold. Unexpected error mapping 
rr_page
Tail of trace dump:
[FATAL /build/rr-wu2MDM/rr-5.3.0/src/DumpCommand.cc:180:dump_events_matching()] 
TraceTaskEvent times non-increasing
=== Start rr backtrace:
/usr/bin/rr(_ZN2rr13dump_rr_stackEv+0x43)[0x6489e3]
/usr/bin/rr(_ZN2rr15notifying_abortEv+0x5a)[0x648a8a]
/usr/bin/rr(_ZN2rr12FatalOstreamD1Ev+0x53)[0x569723]
/usr/bin/rr(+0x6f175)[0x521175]
/usr/bin/rr(_ZN2rr4dumpERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS_9DumpFlagsERKSt6vectorIS5_SaIS5_EEP8_IO_FILE+0x8d)[0x521c5d]
/usr/bin/rr(+0xb7985)[0x569985]
/usr/bin/rr(_ZN2rr21EmergencyDebugOstreamD2Ev+0x81)[0x569c11]
/usr/bin/rr(_ZN2rr12AddressSpace11map_rr_pageERNS_18AutoRemoteSyscallsE+0x8b8)[0x50d188]
/usr/bin/rr(_ZN2rr12AddressSpace17post_exec_syscallEPNS_4TaskE+0x88)[0x50f7b8]
/usr/bin/rr(_ZN2rr4Task17post_exec_syscallEv+0x46)[0x625b26]
/usr/bin/rr(+0xf989f)[0x5ab89f]
/usr/bin/rr(+0x114183)[0x5c6183]
/usr/bin/rr(_ZN2rr19rec_process_syscallEPNS_10RecordTaskE+0xa3)[0x5cd1c3]
/usr/bin/rr(_ZN2rr13RecordSession21syscall_state_changedEPNS_10RecordTaskEPNS0_9StepStateE+0xe5d)[0x59143d]
/usr/bin/rr(_ZN2rr13RecordSession11record_stepEv+0x45b)[0x5978bb]
/usr/bin/rr(_ZN2rr13RecordCommand3runERSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE+0xf68)[0x58c6d8]
/usr/bin/rr(main+0x298)[0x5054a8]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0xb791bef1]
/usr/bin/rr(_start+0x31)[0x505611]
=== End rr backtrace
Abgebrochen



[2] 
https://github.com/mozilla/rr/commit/531062cca8670f13ae99de3322df650e43269784



[3]
98% tests passed, 20 tests failed out of 1157
Total Test time (real) = 3370.80 sec
The following tests FAILED:
440 - quotactl (Failed)
441 - quotactl-no-syscallbuf (Failed)
512 - sem (Failed)
513 - sem-no-syscallbuf (Failed)
534 - shm (Failed)
535 - shm-no-syscallbuf (Failed)
536 - shm_unmap (Failed)
537 - shm_unmap-no-syscallbuf (Failed)
708 - std_random (Failed)
709 - std_random-no-syscallbuf (Failed)
962 - vsyscall_reverse_next (Failed)
963 - vsyscall_reverse_next-no-syscallbuf (Failed)
1110 - shm_checkpoint (Failed)
 - shm_checkpoint-no-syscallbuf (Failed)
1116 - signal_stop (Failed)
1117 - signal_stop-no-syscallbuf (Failed)
1118 - signal_checkpoint (Failed)
1119 - signal_checkpoint-no-syscallbuf (Failed)
1132 - step_signal (Failed)
1133 - step_signal-no-syscallbuf (Failed)
Errors while running CTest




-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 5.6.0-2-686-pae (SMP w/4 CPU cores)
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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rr depends on:
ii  libc6   2.30-8
ii  libcapnp-0.7.0  0.7.0-6
ii  libgcc-s1   10.1.0-3
ii  libstdc++6  10.1.0-3
ii  python3 3.8.2-3
ii  sse2-support5

rr recommends no packages.

rr suggests no packages.

-- no debconf information
>From bd04f8a1a3ac113a25f38f8e4da66945a98fac32 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Sun, 31 May 2020 13:25:50 +0200
Subject: [PATCH 1/1] i386: Use off64_t instead of off_t.

A offset value of 0xb622 in pwrite_all_fallible gets converted
to a value of 0xb622 in __libc_pwrite64.
This gets visible just at 32bit.

Got introduced by commit 531062cca8670f13ae99de3322df650e43269784.

[FATAL /build/rr-wu2MDM/rr-5.3.0/src/AddressSpace.cc:320:map_rr_page()]
 (task 6291 (rec:6291) at time 14)
 -> Assertion `child_fd == -EACCES' failed to hold. Unexpected error mapping rr_page
---
 src/util.cc | 2 +-
 src/util.h  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Index: rr-5.3.0/src/util.cc

Bug#961913: kmail: the access and reading of the received messages is often very slow

[merlin]

Package: kmail
Version: 4:20.04.1-1
Severity: important

Dear Maintainer,

 the access and reading of the received messages is often very slow a message
appears
"Reception of the content of the folder  please wait" Same problem for the
trashing of messages.
The CPU increase to 100%
an akonadictl fsck or akonadictl vacuum does not improved .
Its new



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

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

Versions of packages kmail depends on:
ii  akonadi-server   4:20.04.1-2
ii  kdepim-runtime   4:20.04.1-1
ii  kio  5.70.1-1
ii  libc62.30-8
ii  libgcc-s110.1.0-3
ii  libgpgmepp6  1.13.1-7+b1
ii  libkf5akonadiagentbase5 [libkf5akonadiagentbase5-20.04]  4:20.04.1-2
ii  libkf5akonadicontact5 [libkf5akonadicontact5-20.04]  4:20.04.1-1
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-20.04]4:20.04.1-2
ii  libkf5akonadimime5 [libkf5akonadimime5-20.04]4:20.04.1-1
ii  libkf5akonadisearch-bin  4:20.04.1-1
ii  libkf5akonadisearch-plugins  4:20.04.1-1
ii  libkf5akonadisearchdebug5 [libkf5akonadisearchdebug5-20.04]  4:20.04.1-1
ii  libkf5akonadisearchpim5 [libkf5akonadisearchpim5-20.04]  4:20.04.1-1
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-20.04]  4:20.04.1-2
ii  libkf5bookmarks5 5.70.0-1
ii  libkf5calendarcore5abi2  5:5.70.0-1
ii  libkf5calendarutils5 [libkf5calendarutils5-20.04]4:20.04.1-1
ii  libkf5codecs55.70.0-1
ii  libkf5completion55.70.0-1
ii  libkf5configcore55.70.0-1
ii  libkf5configgui5 5.70.0-1
ii  libkf5configwidgets5 5.70.0-1
ii  libkf5contacts5  5:5.70.0-1
ii  libkf5coreaddons55.70.0-1
ii  libkf5crash5 5.70.0-1
ii  libkf5dbusaddons55.70.0-1
ii  libkf5followupreminder5 [libkf5followupreminder5-20.04]  4:20.04.1-1
ii  libkf5grantleetheme-plugins  20.04.1-1
ii  libkf5gravatar5abi2 [libkf5gravatar5-20.04]  4:20.04.1-1
ii  libkf5guiaddons5 5.70.0-1
ii  libkf5i18n5  5.70.0-1
ii  libkf5iconthemes55.70.0-1
ii  libkf5identitymanagement5 [libkf5identitymanagement5-20.04]  20.04.1-1
ii  libkf5itemmodels55.70.0-1
ii  libkf5itemviews5 5.70.0-1
ii  libkf5jobwidgets55.70.0-1
ii  libkf5kcmutils5  5.70.0-1
ii  libkf5kiocore5   5.70.1-1
ii  libkf5kiofilewidgets55.70.1-1
ii  libkf5kiowidgets55.70.1-1
ii  libkf5kontactinterface5 [libkf5kontactinterface5-20.04]  20.04.1-1
ii  libkf5ksieveui5 [libkf5ksieveui5-20.04]  4:20.04.1-1
ii  libkf5libkdepim5 [libkf5libkdepim5-20.04]4:20.04.1-1
ii  libkf5libkdepimakonadi5 [libkf5libkdepimakonadi5-20.04]  4:20.04.1-1
ii  libkf5libkleo5 [libkf5libkleo5-20.04]4:20.04.1-1
ii  libkf5mailcommon5abi2 [libkf5mailcommon5-20.04]  4:20.04.1-1
ii  libkf5mailtransport5 [libkf5mailtransport5-20.04]20.04.1-1
ii  libkf5mailtransportakonadi5 [libkf5mailtransportakonadi5-20  20.04.1-1
ii  libkf5messagecomposer5abi1 [libkf5messagecomposer5-20.04]4:20.04.1-1
ii  libkf5messagecore5abi1 [libkf5messagecore5-20.04]4:20.04.1-1
ii  libkf5messagelist5abi1 [libkf5messagelist5-20.04]4:20.04.1-1
ii  libkf5messageviewer5abi1 [libkf5messageviewer5-20.04]4:20.04.1-1
ii  libkf5mime5abi1 [libkf5mime5-20.04]  20.04.1-1
ii  libkf

Bug#690773: perl: Module::Build creates non group-writable site directories

[gregor herrmann]

On Sun, 31 May 2020 11:50:49 +0300, Niko Tyni wrote:

> On Wed, Oct 17, 2012 at 04:04:02PM +0300, Niko Tyni wrote:
> > Package: perl
> > Version: 5.14.2-14
> > 
> > Quoting the Debian policy, section 9.1.2:
> >  http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2
> > 
> >  The `/usr/local' directory itself and all the subdirectories
> >  created by the package should (by default) have permissions 2775
> >  (group-writable and set-group-id) and be owned by `root:staff'.
> > 
> > We have patched ExtUtils::MakeMaker for ages to set umask appropriately
> > for site install directories. See
> >  
> > http://patch-tracker.debian.org/patch/series/view/perl/5.14.2-14/debian/writable_site_dirs.diff
> >  
> > http://patch-tracker.debian.org/patch/series/view/perl/5.10.1-17squeeze3/debian/extutils_hacks.diff

These are now the following patches in src:perl:

debian/patches/debian/writable_site_dirs.diff
debian/patches/fixes/respect_umask.diff

which basically set 'umask 02'

> > It looks like Module::Build needs similar patching:
> > 
> >   % sudo rm -rf /usr/local/share/perl /usr/local/lib/perl
> >   % cpan -i File::BOM
> >   [...]
> > sudo ./Build install  -- OK
> >   % ls -dl /usr/local/lib/perl /usr/local/share/perl
> >   drwxr-sr-x 3 root staff 4096 Oct 17 15:58 /usr/local/lib/perl
> >   drwxr-sr-x 3 root staff 4096 Oct 17 15:58 /usr/local/share/perl
> 
> This still seems to be the case.

Ack.


The following patch:

#v+
% diff -u /usr/share/perl5/Module/Build/Base.pm~ 
/usr/share/perl5/Module/Build/Base.pm
--- /usr/share/perl5/Module/Build/Base.pm~  2020-01-30 16:23:22.0 
+0100
+++ /usr/share/perl5/Module/Build/Base.pm   2020-05-31 17:47:33.792186505 
+0200
@@ -3562,6 +3562,7 @@
   my ($self) = @_;
   require ExtUtils::Install;
   $self->depends_on('build');
+  umask oct(02);
   # RT#63003 suggest that odd circumstances that we might wind up
   # in a different directory than we started, so wrap with _do_in_dir to
   # ensure we get back to where we started; hope this fixes it!
#v-

leads to:

% ls -dl /usr/local/lib/x86_64-linux-gnu/perl /usr/local/share/perl 
/usr/local/man
drwxrwsr-x 3 root staff 4096 May 31 17:47 /usr/local/lib/x86_64-linux-gnu/perl
drwxrwsr-x 3 root staff 4096 May 31 17:47 /usr/local/man
drwxrwsr-x 3 root staff 4096 May 31 17:47 /usr/local/share/perl

which looks better :)

(Except that this change probably applies to _all_ created
directories and not only the ones in /usr/local, 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: The Doors: Spanish Caravan


signature.asc
Description: Digital Signature

Bug#938451: scribus: Python2 removal in sid/bullseye

[Mattia Rizzolo]

Indeed there is the option for me to package a SVN checkout, but I really
don't quite like that option if I can save it, since there are quite a few
changes since 1.5.5 and I'm sure upstream won't be keen on supporting that.

Note that it's possible that the next release will be 1.6.0, not 1.5.6
(i.e. fully considered production ready, the 1.5.5 I was forced to upload
due to the Qt4 deprecstion is not officially considered "production ready").


On Sun, 31 May 2020, 1:00 pm Philip Rinn,  wrote:

> Control: usertag -1 + py3available
>
>
> Hi,
>
> just to keep the bug report up to date: the upcoming version of Scribus
> (1.5.6)
> will be ready for Python3, see
>
> http://lists.scribus.net/pipermail/scribus/2019-October/055776.html
>
> No idea when it will be released though.
>
> Best,
> Philip
>

Bug#961923: python-debian: Please support easily editing debian/control

[Federico Ceratto]

Package: python3-debian
Version: 0.1.37
Severity: wishlist

Thanks for developing python-debian.
It would be very nice if it could support easy and "pythonic"
editing of debian/control:
- Load the whole file into a tree of dicts and lists
- Allow updating it and writing to file
- Preserve the order of items in lists e.g. dependencies

This would be useful for creating linting tools similar to
lintian-brush.

Thanks!
--
Federico

Bug#961924: lintian: error with wrong-debian-qa-group-name

[Sudip Mukherjee]

Package: lintian
Version: 2.78.0
Severity: important

Dear Maintainer,

The latest version of lintian is giving error with orphan packages.

Like, bwbasic is an orphan packages and the Maintainer is having:
Debian QA Group  but still lintian gives the error:

bwbasic source: wrong-debian-qa-group-name "Debian QA Group" 


I have tested with few more orphan packages and they all give the same
error.

--
Regards
Sudip

Bug#926854: sysv-rc: remove check for .legacy-bootordering

[Thorsten Glaser]

On Sun, 31 May 2020, Dmitry Bogatov wrote:

> I can't bring anything back. I gave up all Debian-related credentials.

Yeah, I can; it’s in the debian group on Salsa. I wrote this before
checking that. I feel sufficiently “in” for a team upload.

> > Dmitry, sorry to disturb but, if I may ask, what, other than “we don’t
> > enable legacy-bootordering any more and require insserv” motivated the
> > commit?
> 
> Nothing else.

OK, thanks.

> From purity poing of view, I would disagree: if you have very special
> situation that you can't configure bootloader to set /proc/cmdline /and/
> need sequencial boot, then peeking on implementation detail and removing
> /etc/.depend.* is fine answer.

Yeah, I probably could influence /proc/cmdline for my sid systems, but
I actually ran into this (due to mistakenly creating the flag file before
installing sysvinit-core) in a Debian environment in a Docker container
in which I run sysvinit (as I need two services plus supervision for CGI
scripts so I need an init anyway); there you don’t have /proc/cmdline,
but everything else will work mostly fine (I’ll write this up some day,
probably in July when the current project’s over).

> On other hand, from practicality point of view, we are talking about
> mere 3 lines, and if they can keep somebody's old-and-tried setup
> working, then it worth it.

I’d prefer that, yes.

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#953116: [petsc-maint] 32 bit vs 64 bit PETSc

[Drew Parsons]

On 2020-05-27 22:00, Junchao Zhang wrote:

On Wed, May 27, 2020 at 12:09 AM Drew Parsons 
wrote:


On 2020-05-24 10:01, Drew Parsons wrote:

On 2020-05-23 23:45, Satish Balay wrote:


One more issue: Most externalpackages don't support

64bit-indices.
...

We haven't tried using MUMPS in this mode with PETSc


This will be the interesting test. I'll start with the 64-bit

build of

MUMPS and see how tests hold up.


The PETSc mumps tests seem to be robust with respect to 64 bit.
(64 bit MUMPS in the form of -DPORD_INTSIZE64, not all-integer
-DINTSIZE64)

That is, 32 bit PETSc passes its tests with 64 bit (PORD) MUMPS
and 64 bit PETSc passes its tests with 32 bit MUMPS.

The test in question that's passing is src/snes/tutorials/ex19, run
with
'make runex19_fieldsplit_mumps'
Perhaps it's not stress-testing 64 bit conditions.


Could you provide more details, e.g., the error stack trace?




Hi Junchao, PETSc's mumps test runs fine, there is no error to trace as 
such, just a diff with the reference output.


With 32-bit PETSc and 64-bit [PORD] MUMPS,

$ mpirun -n 2 ./ex19 -pc_type fieldsplit -pc_fieldsplit_block_size 4 
-pc_fieldsplit_type SCHUR -pc_fieldsplit_0_fields 0,1,2 
-pc_fieldsplit_1_fields 3 -fieldsplit_0_pc_type lu -fieldsplit_1_pc_type 
lu -snes_monitor_short -ksp_monitor_short  
-fieldsplit_0_pc_factor_mat_solver_type mumps 
-fieldsplit_1_pc_factor_mat_solver_type mumps


returns the result:

lid velocity = 0.0625, prandtl # = 1., grashof # = 1.
  0 SNES Function norm 0.239155
0 KSP Residual norm 0.235858
1 KSP Residual norm < 1.e-11
  1 SNES Function norm 6.81968e-05
0 KSP Residual norm 2.30906e-05
1 KSP Residual norm < 1.e-11
  2 SNES Function norm < 1.e-11
Number of SNES iterations = 2


where output/ex19_fieldsplit_5.out has

lid velocity = 0.0625, prandtl # = 1., grashof # = 1.
  0 SNES Function norm 0.239155
0 KSP Residual norm 0.239155
1 KSP Residual norm < 1.e-11
  1 SNES Function norm 6.81968e-05
0 KSP Residual norm 6.81968e-05
1 KSP Residual norm < 1.e-11
  2 SNES Function norm < 1.e-11
Number of SNES iterations = 2


So the diff in this case is

$make runex19_fieldsplit_mumps
3c3
< 0 KSP Residual norm 0.239155
---

0 KSP Residual norm 0.235858

6c6
< 0 KSP Residual norm 6.81968e-05
---

0 KSP Residual norm 2.30906e-05

Bug#961432: RFP: picom -- lightweight compositor for X11

[Nikos Tsipinakis]

On 31/05, Lev Lamberov wrote:
> Yep, but as I understand they are in situation where some distributions
> picked their fork at the times it was not renamed to picom. Now this
> causes troubles. So the rename and migration plan. Since in Debian we
> are starting from scratch, I don't think we need these hacks. Anyway,
> migrating from compton to picom will require manually installing a new
> package, so users are already know that they need to learn about that
> new thing and to change their configuration. Alternatively, I'd choose
> update-alternatives way, but since there are almost no alternatives in
> terms of maintained X11 compositors, I personally don't think it
> deserves any time investment.

Makes sense, will leave as-is then.

> Ouch! And tags are also missing from your repository. Since you use gbp,
> then gbp push is to the rescue.

That's intentional, since I'm not sure which revision will end up uploaded
currently I haven't tagged it yet to avoid force updates.

> Will look again at the picom package this evening.

Looking forward to it :)

- Nikos

Bug#950473: Please stop using deprecated and headers

[Laurent Bigonville]

Hello,

libselinux 3.1 rc1 has been uploaded in experimental and I'm planning to 
upload the final version in unstable as soon as it's released in the 
upcoming days/weeks.


Could you please make sure that your package is ready? This will make 
your package FTBFS as the  and 
 headers will be gone.


I'll bump these bugs to RC as soon as the upload is made.

Please contact me if you have any questions.

Kind regards,

Laurent Bigonville

Bug#961921: buster-pu: package php-horde-gollem/3.0.12-3+deb10u1

[Mike Gabriel]

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

Dear release team,

I just uploaded an update for php-horde-gollem, fixing CVE-2020-8034.

+  * debian/patches:
++ Add CVE-2020-8034.patch. Fix XSS vulnerability in breadcrumb output
+  (Reported by: polict of Shielder). (Closes: #961649, CVE-2020-8034).
+

Greets,
Mike

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_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
diff -Nru php-horde-gollem-3.0.12/debian/changelog 
php-horde-gollem-3.0.12/debian/changelog
--- php-horde-gollem-3.0.12/debian/changelog2018-05-15 15:16:48.0 
+0200
+++ php-horde-gollem-3.0.12/debian/changelog2020-05-31 16:20:16.0 
+0200
@@ -1,3 +1,11 @@
+php-horde-gollem (3.0.12-3+deb10u1) buster-security; urgency=medium
+
+  * debian/patches:
++ Add CVE-2020-8034.patch. Fix XSS vulnerability in breadcrumb output
+  (Reported by: polict of Shielder). (Closes: #961649, CVE-2020-8034).
+
+ -- Mike Gabriel   Sun, 31 May 2020 16:20:16 +0200
+
 php-horde-gollem (3.0.12-3) unstable; urgency=medium
 
   * Update Standards-Version to 4.1.4, no change
diff -Nru php-horde-gollem-3.0.12/debian/patches/CVE-2020-8034.patch 
php-horde-gollem-3.0.12/debian/patches/CVE-2020-8034.patch
--- php-horde-gollem-3.0.12/debian/patches/CVE-2020-8034.patch  1970-01-01 
01:00:00.0 +0100
+++ php-horde-gollem-3.0.12/debian/patches/CVE-2020-8034.patch  2020-05-31 
16:19:48.0 +0200
@@ -0,0 +1,44 @@
+From a73bef1aef27d4cbfc7b939c2a81dea69aabb083 Mon Sep 17 00:00:00 2001
+From: Jan Schneider 
+Date: Wed, 4 Mar 2020 18:54:06 +0100
+Subject: [PATCH] [jan] SECURITY: Fix XSS vulnerability in breadcrumb output
+ (Reported by: polict of Shielder, CVE-2020-8034).
+
+---
+ doc/changelog.yml | 3 ++-
+ lib/Gollem.php| 5 +++--
+ 2 files changed, 5 insertions(+), 3 deletions(-)
+
+#diff --git a/doc/changelog.yml b/doc/changelog.yml
+#index dbad6ef..3e429bd 100644
+#--- a/doc/changelog.yml
+#+++ b/doc/changelog.yml
+#@@ -18,7 +18,8 @@
+#   license:
+# identifier: GPL-2.0
+# uri: http://www.horde.org/licenses/gpl
+#-  notes:
+#+  notes: |
+#+[jan] SECURITY: Fix XSS vulnerability in breadcrumb output (Reported by: 
polict of Shielder, CVE-2020-8034).
+# 3.0.12:
+#   api: 3.0.0
+#   state:
+diff --git a/gollem-3.0.12/lib/Gollem.php b/gollem-3.0.12/lib/Gollem.php
+index 9a4a7cd..ec255e7 100644
+--- a/gollem-3.0.12/lib/Gollem.php
 b/gollem-3.0.12/lib/Gollem.php
+@@ -692,10 +692,11 @@ public static function directoryNavLink($currdir, $url)
+ $dir = implode('/', $part);
+ if ((strstr($dir, self::$backend['root']) !== false) &&
+ (self::$backend['root'] != $dir)) {
++$part = htmlspecialchars($parts[($i - 1)]);
+ if ($i == $parts_count) {
+-$label[] = $parts[($i - 1)];
++$label[] = $part;
+ } else {
+-$label[] = Horde::link($url->add('dir', $dir), 
sprintf(_("Up to %s"), $dir)) . htmlspecialchars($parts[($i - 1)]) . '';
++$label[] = Horde::link($url->add('dir', $dir), 
sprintf(_("Up to %s"), $dir)) . $part . '';
+ }
+ }
+ }
+
diff -Nru php-horde-gollem-3.0.12/debian/patches/series 
php-horde-gollem-3.0.12/debian/patches/series
--- php-horde-gollem-3.0.12/debian/patches/series   1970-01-01 
01:00:00.0 +0100
+++ php-horde-gollem-3.0.12/debian/patches/series   2020-05-31 
16:19:48.0 +0200
@@ -0,0 +1 @@
+CVE-2020-8034.patch

Bug#961922: stretch-pu: package php-horde-gollem/3.0.10-1+deb9u1

[Mike Gabriel]

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

Dear release team,

I just uploaded an update for php-horde-gollem to stretch, fixing
CVE-2020-8034.

+  * debian/patches:
++ Add CVE-2020-8034.patch. Fix XSS vulnerability in breadcrumb output
+  (Reported by: polict of Shielder). (Closes: #961649, CVE-2020-8034).

Greets,
Mike

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_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
diff -Nru php-horde-gollem-3.0.10/debian/changelog 
php-horde-gollem-3.0.10/debian/changelog
--- php-horde-gollem-3.0.10/debian/changelog2016-12-18 21:55:24.0 
+0100
+++ php-horde-gollem-3.0.10/debian/changelog2020-05-31 16:43:57.0 
+0200
@@ -1,3 +1,11 @@
+php-horde-gollem (3.0.10-1+deb9u1) stretch; urgency=medium
+
+  * debian/patches:
++ Add CVE-2020-8034.patch. Fix XSS vulnerability in breadcrumb output
+  (Reported by: polict of Shielder). (Closes: #961649, CVE-2020-8034).
+
+ -- Mike Gabriel   Sun, 31 May 2020 16:43:57 +0200
+
 php-horde-gollem (3.0.10-1) unstable; urgency=medium
 
   * New upstream version 3.0.10
diff -Nru php-horde-gollem-3.0.10/debian/patches/CVE-2020-8034.patch 
php-horde-gollem-3.0.10/debian/patches/CVE-2020-8034.patch
--- php-horde-gollem-3.0.10/debian/patches/CVE-2020-8034.patch  1970-01-01 
01:00:00.0 +0100
+++ php-horde-gollem-3.0.10/debian/patches/CVE-2020-8034.patch  2020-05-31 
16:43:57.0 +0200
@@ -0,0 +1,44 @@
+From a73bef1aef27d4cbfc7b939c2a81dea69aabb083 Mon Sep 17 00:00:00 2001
+From: Jan Schneider 
+Date: Wed, 4 Mar 2020 18:54:06 +0100
+Subject: [PATCH] [jan] SECURITY: Fix XSS vulnerability in breadcrumb output
+ (Reported by: polict of Shielder, CVE-2020-8034).
+
+---
+ doc/changelog.yml | 3 ++-
+ lib/Gollem.php| 5 +++--
+ 2 files changed, 5 insertions(+), 3 deletions(-)
+
+#diff --git a/doc/changelog.yml b/doc/changelog.yml
+#index dbad6ef..3e429bd 100644
+#--- a/doc/changelog.yml
+#+++ b/doc/changelog.yml
+#@@ -18,7 +18,8 @@
+#   license:
+# identifier: GPL-2.0
+# uri: http://www.horde.org/licenses/gpl
+#-  notes:
+#+  notes: |
+#+[jan] SECURITY: Fix XSS vulnerability in breadcrumb output (Reported by: 
polict of Shielder, CVE-2020-8034).
+# 3.0.12:
+#   api: 3.0.0
+#   state:
+diff --git a/gollem-3.0.10/lib/Gollem.php b/gollem-3.0.10/lib/Gollem.php
+index 9a4a7cd..ec255e7 100644
+--- a/gollem-3.0.10/lib/Gollem.php
 b/gollem-3.0.10/lib/Gollem.php
+@@ -692,10 +692,11 @@ public static function directoryNavLink($currdir, $url)
+ $dir = implode('/', $part);
+ if ((strstr($dir, self::$backend['root']) !== false) &&
+ (self::$backend['root'] != $dir)) {
++$part = htmlspecialchars($parts[($i - 1)]);
+ if ($i == $parts_count) {
+-$label[] = $parts[($i - 1)];
++$label[] = $part;
+ } else {
+-$label[] = Horde::link($url->add('dir', $dir), 
sprintf(_("Up to %s"), $dir)) . htmlspecialchars($parts[($i - 1)]) . '';
++$label[] = Horde::link($url->add('dir', $dir), 
sprintf(_("Up to %s"), $dir)) . $part . '';
+ }
+ }
+ }
+
diff -Nru php-horde-gollem-3.0.10/debian/patches/series 
php-horde-gollem-3.0.10/debian/patches/series
--- php-horde-gollem-3.0.10/debian/patches/series   1970-01-01 
01:00:00.0 +0100
+++ php-horde-gollem-3.0.10/debian/patches/series   2020-05-31 
16:40:31.0 +0200
@@ -0,0 +1 @@
+CVE-2020-8034.patch

Bug#961920: RM: pidgin-encryption -- ROM; abandoned upstream

[Leo Antunes]

Package: ftp.debian.org
Severity: normal

Hi ftp-master,

As mentioned in the RFA bug[0], this package is long abandoned, has
better alternatives and low popcon score.

Cheers
Leo Antunes

[0] https://bugs.debian.org/899195

Bug#961429: Subject: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.

[Vasyl Gello]

Dear Mattia and Matthew!

First of all I would like to thank you for all the efforts you did to teach me 
how to do proper Debian packaging.
Your reviews made me rethink some practices I followed and it already helps me 
in my activities outside of Debian.

Yesterday I found out the original Cryptopass Chrome extension is no longer 
maintained and its repository archived.
While I fixed the issues spotted in previous reviews and pushed the new 
upstream version 1.1.0 and corresponding
Debian repo on Salsa, I would like to withdraw the package from the queue.

Earlier I mentioned the passwordmaker-cli package I found long after I wrote 
cryptopass. Its Android app is actively
maintained, in contrast to the CLI sources, so I will likely propose the fixes 
incorporating cryptopass scheme into
Password Maker (https://www.passwordmaker.org). Once there is new upstream 
release, I will coordinate with
Cord Beermann (the pm-cli maintainer) to have it packaged.

I do still appreciate additional reviews on packaging and security of 
cryptopass, because I thought it could be a great
example of "making a small pavkage to learn Debian packaging". Maybe I will 
even write a series of blog posts about
Debian packaging and my experience with it.

Sincerely,
-- 
Vasyl Gello

signature.asc
Description: PGP signature