Bug#959075: Still not working on Debian testing

[Paul Wise]

On Fri, 3 Jul 2020 11:15:30 +0200 richard lucassen wrote:

> Ok, two remaining cometic issues in 2.11 than :-)

Sounds like the issue is fixed then, marked it as fixed.

> # ifup bond0
> /etc/network/if-pre-up.d/ifenslave: 39: echo: echo: I/O error
> /etc/network/if-pre-up.d/ifenslave: 39: echo: echo: I/O error
> 
> You get this error when you try to set a /sys/ option that is not
> allowed, but the script does not tell which option throws an error. See
> diff attached.

I'll apply the patch you sent in another upload.

> Another cosmetic issue:
> 
> # ifdown bond0
> # modprobe -rv bonding
> rmmod bonding
> # ifup bond0
> RTNETLINK answers: File exists
> # 

Is this a regression from 2.9 or just an old bug still present?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#963971: [Pkg-samba-maint] Bug#963971: samba-libs: libndr.so.0 gone from latest version, breaks sssd-ad-common dependency

[Mathieu Parent]

clone 963971 -1
tag 963971 + upstream
tag -1 + upstream fixed-upstream patch
reassign -1 sssd-ad-common

Le lun. 29 juin 2020 à 14:48, Michael Stone  a écrit :
>
> Package: samba-libs
> Version: 2:4.12.3+dfsg-2
> Severity: critical
> Justification: breaks the whole system
>
> The new samba-libs package changes the soname of libndr from libndr.so.0 to
> libndr.so.1 without reflecting this change in the package name. sssd-ad-common
> has a dependency on samba-libs (>= 2:4.11.5+dfsg) and links to libndr.so.0.
> When the samba-libs package is updated and libndr.so.0 disappears sssd fails 
> to
> start, which then makes a system's remote users unavailable. (Worse, this
> doesn't happen until the next time sssd restarts--which may not be until the
> next reboot.)

It looks to be fixed in sssd 2.3.0:
https://github.com/SSSD/sssd/commit/bc56b10aea999284458dcc293b54cf65288e325d

I'm cloning this bug:
- on the samba side I'll add a breaks: sssd-ad-common (<< 2.3.0)
- on the sssd side, an update to 2.3.0+ is needed

Regards
-- 
Mathieu Parent

Bug#919619: [Pkg-utopia-maintainers] Bug#919619: NM 1.24.0 now has basic support for hidden networks with iwd backend

[Andreas Henriksson]

On Sat, Jul 04, 2020 at 12:42:57AM +0200, Michael Biebl wrote:
> Am 04.07.20 um 00:16 schrieb Jonas Smedegaard:
> > Then how about _not_ recommend iwd but just lower from depending on 
> > wpasupplicant to only recommending it.  Because that's what it is: 
> > Recommended for all except special situations.  For now...  Right?
> 
> Hm, no. That's exactly the situation I want to avoid. The user
> installing iwd, removing wpasupplicant in the process, network not
> working anymore. A Recommends makes that even worse. Either iwd works as
> a drop-in replacement (without requiring explicit configuration) or not.
> That's basically my question.
> If it does, I'm happy to add an alternative Depends assuming Andreas is
> fine with that.

I can confirm there's still no automatic fallback to use iwd. It has to
be manually configured to even be attempted to be used. This is
something I'd personally consider a blocker if I where NM Debian
maintainer. I quickly asked upstream a while ago if we couldn't atleast
automatically fall back on iwd if we detect that wpasupplicant isn't
even *installed*, but their responses where negative. They don't seem
to like or support iwd usage at all

Additionally as previously mentioned the iwd backend in NM still needs
more work to be production quality. Current state is that it's fully
usable as far as I can tell, but you'll likely occationally need to
restart NetworkManager.service when NM and iwd gets state out of sync.
(I've experienced this alot, but have not debugged it in detail. There
are likely many small issues to be found and ironed out here.)

At this point I don't think it's safe to allow the general public of NM
users to be able to uninstall wpasupplicant and people who really want
to use iwd with NM and really want to uninstall wpasupplicant to use
an equivs. I however would suggest keeping wpasupplicant around still
in case of emergency, if you're not in a situtation that forces you to
not have wpasupplicant installed for whatever reason (which should be
rare enough that using equivs to solve it seems suitable).

This is the situation as I see it for now. I've also previously
mentioned that I don't see anyone putting work into the situation
improving so I guess it'll remain the same for a forseeable future.

Regards,
Andreas Henriksson

Bug#964238: Please package 0.17.2

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

Hello!

Would you please upload 0.17.2?

It looks like Syncthing needs a newer version of quic-go.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#964234: dpkg-source: Considers missing symlink targets directory traversals

[Guillem Jover]

Control: reassign -1 dpkg-dev
Control: retitle -1 dpkg-source: Considers missing symlink targets directory 
traversals
Control: found -1 1.20.0

On Sat, 2020-07-04 at 01:20:18 +0200, Andreas Beckmann wrote:
> Source: dpkg,firmware-nonfree
> Version: 20190717-2
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source
> Control: found -1 20190717-2
> Control: found -1 1.20.3

> src:firmware-nonfree fails to unpack in sid with latest dpkg:
> 
> dpkg-source: info: extracting firmware-nonfree in firmware-nonfree-20190717
> dpkg-source: info: unpacking firmware-nonfree_20190717.orig.tar.xz
> dpkg-source: info: unpacking firmware-nonfree_20190717-2.debian.tar.xz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: applying gitignore.patch
> Use of uninitialized value $canon_pathname in pattern match (m//) at 
> /usr/share/perl5/Dpkg/Source/Package.pm line 550.
> dpkg-source: error: pathname 
> 'firmware-nonfree-20190717/debian/config/libertas/sd8688_helper.bin' points 
> outside source root
> 
> Since this could also be a dpkg error (see the perl warning before the 
> failure)
> I'm assigning this bug to both packages, please reassign as appropriate.

It is, the pathname above is a symlink to a missing target, which is
definitely not a directory traversal attempt. I'm fixing this now, and
will upload tomorrow.

Thanks,
Guillem

Bug#964111: dpkg-source: False positive 'points outside source root'

[Guillem Jover]

On Fri, 2020-07-03 at 05:27:46 -0700, Felix Lechner wrote:
> Why did you lower the severity instead of releasing a fix?

As explained, because the severity seemed off. Also because there
are still other regressions being dealt with…

> If version 1.20.3 progresses to testing, Lintian loses its last
> functioning CI pipeline. (Our stable-bpo pipeline is optional with a
> reduced test set.)

As long as the autopkgtests show regressions for the involved packages
whatever might end up being the root cause, these packages will not
migrate.

Regards,
Guillem

Bug#964111: dpkg-source: False positive 'points outside source root'

[Guillem Jover]

Hi!

On Fri, 2020-07-03 at 14:12:10 +, Holger Levsen wrote:
> not sure if this is the same bug or just a similar one:

Yeah, related, but not entirely the same.

> [...]
> dpkg-source: info: extracting munin in munin-2.0.63
> dpkg-source: info: unpacking munin_2.0.63.orig.tar.gz
> dpkg-source: info: unpacking munin_2.0.63-1.debian.tar.xz
> dpkg-source: error: pathname 'munin-2.0.63/debian/munin.service' points 
> outside source root
> E: pbuilder: Failed extracting the source
> 
> $ ls debian/munin.service -lart
> lrwxrwxrwx 1 user user 9 Jul  3 16:07 debian/munin.service -> /dev/null

Ah right. Thanks, I'll add an exception for /dev/null.

Thanks,
Guillem

Bug#964237: subversion-tools: svn-hot-backup does not work with python 3

[Arnout Boelens]

Package: subversion-tools
Version: 1.14.0-1
Severity: normal
Tags: patch

There are a couple of bugs in the svn-hot-backup script, probably related to the
upgrade to python 3

See patch below:

--- svn-hot-backup  2020-06-03 19:21:57.0 -0700
+++ /usr/bin/svn-hot-backup 2020-07-03 20:28:14.732657020 -0700
@@ -36,6 +36,7 @@
 ##

 import sys, os, getopt, stat, re, time, shutil, subprocess
+from functools import cmp_to_key

 ##
 # Global Settings
@@ -219,7 +220,7 @@
 raise Exception("Unable to find the youngest revision for repository '%s'"
 ": %s" % (repo_dir, stderr_lines[0].rstrip()))

-  return stdout_lines[0].strip()
+  return stdout_lines[0].strip().decode("utf-8")

 ##
 # Main
@@ -255,7 +256,7 @@
 directory_list = os.listdir(backup_dir)
 young_list = [x for x in directory_list if regexp.search(x)]
 if young_list:
-  young_list.sort(comparator)
+  young_list.sort(key=cmp_to_key(comparator))
   increment = regexp.search(young_list.pop()).groupdict()['increment']
   if increment:
 backup_subdir = os.path.join(backup_dir, repo + "-" + youngest + "-"
@@ -348,7 +349,7 @@
   regexp = re.compile("^" + re.escape(repo) + "-[0-9]+(-[0-9]+)?" + ext_re + 
"$")
   directory_list = os.listdir(backup_dir)
   old_list = [x for x in directory_list if regexp.search(x)]
-  old_list.sort(comparator)
+  old_list.sort(key=cmp_to_key(comparator))
   del old_list[max(0,len(old_list)-num_backups):]
   for item in old_list:
 old_backup_item = os.path.join(backup_dir, item)


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

Kernel: Linux 5.7.0-1-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 subversion-tools depends on:
ii  libapr1 1.6.5-1+b1
ii  libc6   2.30-8
ii  libsvn1 1.14.0-1
ii  subversion  1.14.0-1

Versions of packages subversion-tools recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.94-4
ii  libconfig-inifiles-perl3.03-1
ii  libsvn-perl1.14.0-1
ii  liburi-perl1.76-2
ii  rsync  3.2.1-1
ii  svn2cl 0.14-2

Versions of packages subversion-tools suggests:
pn  ruby-svn  

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/svn-hot-backup (from subversion-tools package)
--- svn-hot-backup  2020-06-03 19:21:57.0 -0700
+++ /usr/bin/svn-hot-backup 2020-07-03 20:28:14.732657020 -0700
@@ -36,6 +36,7 @@
 ##
 
 import sys, os, getopt, stat, re, time, shutil, subprocess
+from functools import cmp_to_key
 
 ##
 # Global Settings
@@ -219,7 +220,7 @@
 raise Exception("Unable to find the youngest revision for repository '%s'"
 ": %s" % (repo_dir, stderr_lines[0].rstrip()))
 
-  return stdout_lines[0].strip()
+  return stdout_lines[0].strip().decode("utf-8")
 
 ##
 # Main
@@ -255,7 +256,7 @@
 directory_list = os.listdir(backup_dir)
 young_list = [x for x in directory_list if regexp.search(x)]
 if young_list:
-  young_list.sort(comparator)
+  young_list.sort(key=cmp_to_key(comparator))
   increment = regexp.search(young_list.pop()).groupdict()['increment']
   if increment:
 backup_subdir = os.path.join(backup_dir, repo + "-" + youngest + "-"
@@ -348,7 +349,7 @@
   regexp = re.compile("^" + re.escape(repo) + "-[0-9]+(-[0-9]+)?" + ext_re + 
"$")
   directory_list = os.listdir(backup_dir)
   old_list = [x for x in directory_list if regexp.search(x)]
-  old_list.sort(comparator)
+  old_list.sort(key=cmp_to_key(comparator))
   del old_list[max(0,len(old_list)-num_backups):]
   for item in old_list:
 old_backup_item = os.path.join(backup_dir, item)

Bug#964233: ifupdown: interfaces man page wrong example for /etc/network/interfaces

[Richard van den Berg]

Package: ifupdown
Version: 0.8.35
Severity: normal

In /usr/share/man/man5/interfaces.5.gz the following example is giving for

   auto eth0
   allow-hotplug eth1

   iface eth0 inet dhcp

   iface eth0 inet6 auto

   iface eth1 inet static
address 192.168.1.2/24
gateway 192.168.1.1

   iface eth1 inet6 static
address fec0:0:0:1::2/64
gateway fec0:0:0:1::1

However using this example causes /lib/systemd/system/networking.service to 
fail with:

Jul  4 00:15:00 debian ifup[359]: RTNETLINK answers: File exists

because there are two "gateway" statements in /etc/network/interfaces

A possible  solution is to put the ipv6 part in /etc/network/interfaces.d/eth0

-- 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/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ifupdown depends on:
ii  adduser   3.118
ii  iproute2  4.20.0-2
ii  libc6 2.28-10
ii  lsb-base  10.2019051400

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.1-2

Versions of packages ifupdown suggests:
pn  ppp 
pn  rdnssd  

-- no debconf information

Bug#964177: chromium: high cpu load and frequent crashes

[Michael Gilbert]

On Fri, Jul 3, 2020 at 3:39 AM Alexis Huxley wrote:
> I've got Debian 10 and apply nightly updates as they become
> available. I was running chromium version 80.0.3987.162 but
> that was upgraded to 83.0.4103.116 a couple of nights ago. Since
> then CPU load at page load time is very high, the interface is
> generally sluggish and it crashes several times per day.

The latest buster version was mistakenly built without optimization.
I am working on an update.

Best wishes,
Mike

Bug#940017: crypto-policies: Incomplete debian/copyright?

[John Scott]

On Wednesday, September 11, 2019 4:03:59 AM EDT Chris Lamb wrote:
> I just ACCEPTed minder from NEW but noticed it was missing attribution
> for at least Tomáš Mráz.

This bug is against crypto-policies, but it appears you accepted minder too 
the same day. Did you mean to file this against minder?

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

Bug#964236: php-redis: After upgrade to php-redis (5.3.0+4.3.0-1), php-fpm crash

[John Wong]

Package: php-redis
Version: After upgrade to php-redis (5.3.0+4.3.0-1), php-fpm crash
Severity: normal

Dear Maintainer,
 After upgrade to php-redis (5.3.0+4.3.0-1), php-fpm crash.

 traps: php-fpm7.4[198823] general protection fault ip:55da0ea4c634 
sp:7ffc14657008 error:0 in php-fpm7.4[55da0e8a8000+268000]
 php-fpm7.4[198824]: segfault at 10001 ip 55da0ea4b3b6 sp 
7ffc14656fb8 error 4 in php-fpm7.4[55da0e8a8000+268000]
 Code: 85 8b 7a e7 ff 48 8b 47 10 48 83 c0 38 48 39 47 18 48 89 c2
 48 89 47 10 48 0f 43 57 18 48 8b 47 50 48 89 57 18 48 85 c0 74 0a
 <48> 8b 10 48 89 57 50 c3 66 90 be 06 00 00 00 e9 96 e5 ff f
 f 66 0f

 Please help, thank you.

*** 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 ***


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

Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#964214: libdebhelper-perl: dh_auto_configure cannot do out-of-tree builds for qmake buildsystem

[Thorsten Glaser]

severity 964214 wishlist
tags 964214 + help
thanks

Hi Niels,

>Interesting.  I am not sure out of source builds have ever been
>supported by qmake (at least not correctly at any rate).  If you know
>how to do it, then I am happy to look at fixing it.

this is my first contact with qmake either, and the KDE/Qt
maintainers are happy it’s used less and less as well…

Sorry,
//mirabilos
-- 
18:47⎜ well channels… you see, I see everything in the
same window anyway  18:48⎜ i know, you have some kind of
telnet with automatic pong 18:48⎜ haha, yes :D
18:49⎜ though that's more tinyirc – sirc is more comfy

Bug#964025: berusky2: New upstream release

[Asher Gordon]

I just realized that readme-debian-mode added my name to README.Debian,
because I removed an entry. You can change/remove that if you wish.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me sprea=
d!
   
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68


signature.asc
Description: PGP signature

Bug#714454: ITP: polyphone -- soundfont editor (.sf2 format 2.01 and 2.04)

[Thorsten Glaser]

tags 714454 + pending
thanks

Dixi quod…

>Packaging status: repository at
>https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/polyphone.git;a=summary

Updated.

>We’re currently held up by some licencing issues:
>
>• https://github.com/davy7125/polyphone/issues/105 (showstopper,
>  but the GPLv2-only code is from MuseScore, whom I asked to relicence)

The request for relicencing has been received, but was not yet
finished progressing. In the meantime, I’ve managed to build a
functioning Polyphone with SF3 support removed (+dfsg1).

>• https://github.com/davy7125/polyphone/issues/106 (fixed in Debian,
>  by adding the necessary info and licence to d/copyright)

Updated to git master (their latest release wouldn’t even install,
and HEAD seems to have only low-risk bugfixes so far), updated the
fontawesome list accordingly.

>• https://github.com/davy7125/polyphone/issues/107 (worked around,
>  by using wolfSSL instead of OpenSSL, might even work)

This does work. Also thanks to Felix Lechner (WolfSSL maintainer)
who responded quick and very helpfully.

>I’m otherwise getting acceptable progress with packaging. I’ll also
>make it use the system copy of sfarklib instead of bundling one, as

This also works. I’ve uploaded an initial package to NEW.

>The upstream-provided .deb crashes quite a lot for me, especially
>on exit. I hope this is a matter of integration and will fix itself
>with a proper build on sid; if not help debugging the C++/Qt5 issues
>is welcome.

It still crashes; I’ve reported the first two upstream.

Polyphone is usable when you make sure to start JACK *first*.
The crash at shutdown occurs when free()ing and is negligible.
I’ll hope upstream fixes them; otherwise, help is welcome.
Also feel free to review the repository / package. It supercedes
the illegal one from upstream and is en par with latest Debian
packaging standards (0 lintian warnings). I’ll forward patches
to upstream, too…

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r

Bug#964234: dpkg,firmware-nonfree: cannot unpack: dpkg-source: error: pathname 'firmware-nonfree-20190717/debian/config/libertas/sd8688_helper.bin' points outside source root

[Felix Lechner]

Hi Andreas,

> dpkg-source: error: pathname
> points outside source root

Maybe the same as Bug#964111?

Kind regards
Felix Lechner

Bug#964235: Patch for error in bsdgames Trek that prevents visual command from working under some circumstances

[James Baldwin-Brown]

Package: bsdgames
Version: 2.17-28
Severity: normal

Dear Debian maintainers,

I was playing the old Trek game from the Debian bsdgames package, and 
I've identified a bug. I've patched it on my system, and the patch 
solves the problem. I sent a merge request to Debian Salsa about 6 
months ago with the complete patch, but never got a response from that. 
Let me know if I am submitting the patch incorrectly, or if I can do 
anything else to help you out. I haven't contributed to Debian packages 
before, so I apologize if I'm not following the protocol correctly.


The bug:

When using the visual command in trek, the game should print the content 
of the three ship-adjacent squares that are closest to the view 
direction specified. So, if the player is at the coordinates 7,3/5,5 and 
types "visual 0", they should see the following:


4,4 . . * 4,6

where 4,4 is the coordinate of the leftmost viewed location, 4,6 is the 
rightmost viewed location, and . . * represent empty space, empty space, 
and a star. Unfortunately, this currently does not occur. When the 
player looks in the downward directions, the view is as expected, but 
when looking upward, some spaces are replaced with a ? character and 
some coordinates are printed incorrectly -- the incorrect coordinates 
are of the form "255 + ship position". So, in the above case, the player 
would see the following:


260,260 ? ? ? 260,6

The explanation:

The bug is caused by an integer overflow in the 'visual.c' file. The 
struct xy, defined in trek.h, uses a pair of unsigned char to hold x,y 
coordinates for the position of starbases in quadrants in kill.c and for 
the position of sectors relative to the ship in visual.c. This works 
fine in kill.c, where the unsigned chars are used to store absolute 
positions that are always positive, but in visual.c, the unsigned chars 
roll over to 255 when they are set to a value of -1, which they are in 
all the cases where a sector is above or to the left of the ship. This 
causes the coordinate values to be incorrect, as above, and for the 
visual command to fail to correctly print all sectors affected by this bug.
My testing indicates that this is fixed by simply changing unsigned char 
to char in trek.h. No uses of struct xy that I know of require numbers 
greater than 7 (the highest number in the quadrant axes), so switching 
to char and losing the ability to store numbers in the range 128-255 
should not be problematic.


The patch:
--- debian/bsdgames/trek/trek.h2019-12-18 10:12:35.003133958 -0700
+++ jgbaldwinbrown/bsdgames/trek/trek.h2019-12-18 10:04:23.612000795 
-0700

@@ -201,7 +201,7 @@

 struct xy
 {
-unsigned charx, y;/* coordinates */
+signed charx, y;/* coordinates */
 };

I am using Debian GNU/Linux 10 (Buster) and Linux kernel 4.19.0-9-amd64 
in a virtual machine for testing.


Best,
Jim

Bug#778750: theme still broken, problem with directory structure and symlink

[Mike Gabriel]

Hi Ivan Sergio,

On  Fr 03 Jul 2020 18:41:19 CEST, Ivan Sergio Borgonovo wrote:


I've just read more carefully your follow up:


The theming folder in /etc/ also needs to be moved a bit:
/etc/horde/themes-available.d/default ->   
/etc/horde/themes-available.d/default/horde


OK, it was on purpose... but it seems it's not working, at least here.

I'm going to try to do some further tests and see if I'd missed  
something with the cache... but once I "fixed" it as described in  
previous post and refreshed the cache it started to work.


I find very unlikely that both the packaged directory structure and  
my structure can both work, one has to be wrong.


Yours was correct, mine was wrong. I have fiddled with the  
themes-enabled.d/ subfolder now and swapped the order compared to  
themes-available.d/:


  /etc/horde/themes-available.d//

vs.

  /etc/horde/themes-enabled.d//

I changed the /usr/share/horde/[/]themes symlink now and point it to

  /etc/horde/themes-enabled.d/

This should fix thing. However, it makes enabling/disabling a theme  
(if there were more than on) more complex. I will see to providing a  
script for this.


Please retry. Thanks for the feedback ping-pong.

MIke
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpuTBl_2WY_M.pgp
Description: Digitale PGP-Signatur

Bug#778750: theme still broken, problem with directory structure and symlink

[Mike Gabriel]

On  Fr 03 Jul 2020 18:41:19 CEST, Ivan Sergio Borgonovo wrote:


I've just read more carefully your follow up:


The theming folder in /etc/ also needs to be moved a bit:
/etc/horde/themes-available.d/default ->   
/etc/horde/themes-available.d/default/horde


OK, it was on purpose... but it seems it's not working, at least here.

I'm going to try to do some further tests and see if I'd missed  
something with the cache... but once I "fixed" it as described in  
previous post and refreshed the cache it started to work.


I find very unlikely that both the packaged directory structure and  
my structure can both work, one has to be wrong.


I forgot to mention:

the latest fixes should be in:

  php-horde 5.2.23+debian0-3
  php-horde-imp 6.2.26-2
  php-horde-gollem 3.0.13-4

I am still unsure what your dpkg problem was. Maybe it is gone now(?).

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp96szqns3x6.pgp
Description: Digitale PGP-Signatur

Bug#778750: theme still broken, problem with directory structure and symlink

[Mike Gabriel]

Hi,

thanks for testing the upgrade. Sorry that it failed again. Let's see...

On  Fr 03 Jul 2020 18:29:40 CEST, Ivan Sergio Borgonovo wrote:


I just safe-upgraded some stuff and I came across 2 different problems:

1)

dpkg: warning: unable to delete old directory  
'/usr/share/horde/themes/default/graphics': Directory not empty


I can't hide those. Most users won't see those. They only occur when  
upgrading from 5.2.23+debian0-1.



...

dpkg: dependency problems prevent configuration of php-horde-imp:
 php-horde-imp depends on php-horde (>= 5.2.23+debian0-2~); however:
  Version of php-horde on system is 5.2.23+debian0-1.

dpkg: error processing package php-horde-imp (--configure):
 dependency problems - leaving unconfigured
Setting up php-horde-service-weather (2.5.4-7) ...
dpkg: dependency problems prevent configuration of php-horde:
 php-horde-service-weather (2.5.4-7) breaks php-horde (<<  
5.2.23+debian0-2~) and is installed.

  Version of php-horde to be configured is 5.2.23+debian0-1.

dpkg: error processing package php-horde (--configure):
 dependency problems - leaving unconfigured
Setting up re2c (1.3-2) ...
dpkg: dependency problems prevent configuration of php-horde-gollem:
 php-horde-gollem depends on php-horde (>= 5.2.23+debian0-1~); however:
  Package php-horde is not configured yet.
 php-horde-gollem depends on php-horde (<< 6.0.0~alpha1); however:
  Package php-horde is not configured yet.

dpkg: error processing package php-horde-gollem (--configure):
 dependency problems - leaving unconfigured


Oh well...


...

Errors were encountered while processing:
 php-horde-imp
 php-horde
 php-horde-gollem

This may be or may not be related to the fact that I made manual  
changes to /etc/horde/ and /usr/share/themes to make them work as I  
thought was expected.


I am not sure, yet. I'll need to investigate deeper.


2)

root@caronte:~# ls /etc/horde/themes-available.d/
default

but

root@caronte:~# ls /usr/share/horde/themes
block  embed.css  facebook.css  feed-rss.xsl  graphics  ie8.css  
info.php  mozilla.css  opera.css  rtl.css  screen.css  smartmobile  
sounds  webkit.css


wouldn't it had to be all this inside /usr/share/horde/themes/default?


Oh yes. You are right! Damn!


furthermore it seems that the content of

/etc/horde/themes-available.d/default/horde

should actually be inside

/etc/horde/themes-available.d/default/


No. All other Horde applications have their own  
/themes/ dir. So this was on purpose.



I think I've manually fixed it...



[...]


Sorry for the hassle once more!

It would be nice if there was a way to refresh the cache without  
tweaking the conf.php file.


Yeah. Maybe I can provide a script for that. Will see...

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp21feW7pxoA.pgp
Description: Digitale PGP-Signatur

Bug#964234: dpkg,firmware-nonfree: cannot unpack: dpkg-source: error: pathname 'firmware-nonfree-20190717/debian/config/libertas/sd8688_helper.bin' points outside source root

[Andreas Beckmann]

Source: dpkg,firmware-nonfree
Version: 20190717-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source
Control: found -1 20190717-2
Control: found -1 1.20.3

Hi,

src:firmware-nonfree fails to unpack in sid with latest dpkg:

dpkg-source: info: extracting firmware-nonfree in firmware-nonfree-20190717
dpkg-source: info: unpacking firmware-nonfree_20190717.orig.tar.xz
dpkg-source: info: unpacking firmware-nonfree_20190717-2.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying gitignore.patch
Use of uninitialized value $canon_pathname in pattern match (m//) at 
/usr/share/perl5/Dpkg/Source/Package.pm line 550.
dpkg-source: error: pathname 
'firmware-nonfree-20190717/debian/config/libertas/sd8688_helper.bin' points 
outside source root

Since this could also be a dpkg error (see the perl warning before the failure)
I'm assigning this bug to both packages, please reassign as appropriate.


Andreas

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Guilhem Moulin]

On Sat, 04 Jul 2020 at 00:54:53 +0200, Vincent Lefevre wrote:
> I suppose that's
> 
> wait_for_dropbear() {
> […]
> }
> 
> Couldn't it also check whether the user has typed the passphrase,
> and quit in this case?

That would introduce back the race condition described in #943459.
configure_networking() runs in the background and might still be running
at init-bottom stage, after the user has unlocked all drives from the
console.  Also dropbear-initramfs isn't only used for remote unlocking
and I don't want to tie the two with adhoc hacks.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#964200: apt-listbugs: transient frozen string error

[Francesco Poli]

On Fri, 03 Jul 2020 18:40:09 +0200 Christoph Anton Mitterer wrote:

> On Fri, 2020-07-03 at 18:08 +0200, Francesco Poli wrote:
[...]
> > What is "en_DE.UTF-8", exactly?
[...]
> > Could this non-existent locale maybe confuse the ruby-unicode
> > library?
> 
> No it is existent... it's just my own locale... which is basically just
> a modification of en_US ... that is everything English, but ISO
> conformant date/time formats, "," as decimal separator and things like
> that.
> 
> Never made a problem so far (and I've been using this for decades ;-)
> ).

Ah, OK, so you created it and manually installed it on your system.

Well, it could be that the ruby-unicode library has some subtle bug which
makes it fail (sometimes) with your custom locale.
Or maybe it's the other way around, I don't know.

[...]
> Well, as said, it didn't even happen with the same locale...

Let's try the following strategy.

If you can (at least sporadically) reproduce the error with the
following minimal Ruby script, please file a bug report against the
ruby-unicode library.

The script is:

  $ cat unicode-ruby.rb 
  #!/usr/bin/ruby

  require 'unicode'
  puts Unicode.width("è")

After giving it execution permissions:

  $ chmod +x unicode-ruby.rb 

just run it:

  $ ./unicode-ruby.rb 
  1

If it fails with your locale, then there seems to be some
incompatibility between your custom locale and ruby-unicode.
On the other hand, if you never see any errors with the minimal script
or again with apt-listbugs, then the issue seems to be unreproducible.

In the meanwhile, I will close this bug report, since the bug does not
seem to be in package apt-listbugs.

Do you agree with this plan?

 

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


pgpPtLXtYAkHb.pgp
Description: PGP signature

Bug#964208: wsjtx: FTBFS without internet access

[tmancill]

Hi Niko,

On Fri, Jul 03, 2020 at 07:47:21PM +0300, Niko Tyni wrote:
> Source: wsjtx
> Version: 2.2.1+repack-1
> Severity: serious
> Tags: ftbfs
> 
> This package fails to build on a system without internet access.
> I suppose it's xsltproc calling out for external resources or something
> like that.
> 
> This is probably the cause for the 2.2.2+repack-1 armhf build failure too;
> I think the conova buildds only have IPv6 connectivity.

Thank you for connecting the dots... I reproduced this exact build
failure on amd64 by disabling the network.

> From the build log:
> 
> a2x: ERROR: "xsltproc" -param man.endnotes.list.enabled 0 -param 
> man.endnotes.are.numbered 0 --stringparam callout.graphics 0 --stringparam 
> navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 
> 0  "/etc/asciidoc/docbook-xsl/manpage.xsl" 
> "/<>/obj-x86_64-linux-gnu/manpages/man/man1/wsjtx.1.xml" 
> returned non-zero exit status 5

Cheers,
tony


signature.asc
Description: PGP signature

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Vincent Lefevre]

On 2020-07-04 00:30:04 +0200, Guilhem Moulin wrote:
> On Sat, 04 Jul 2020 at 00:18:59 +0200, Vincent Lefevre wrote:
> > Note that /usr/share/doc/dropbear-initramfs/README.initramfs
> > says at the end:
> > 
> >  This is non-blocking for the startup process, so when you are at the
> >  console you won't have to wait for the SSHd to complete its startup.
> 
> I happen to maintain dropbear-initramfs and wrote that :-)
> 
> While the init-premount script is non-blocking, the init-bottom is
> blocking.  This is a side effect of the #943459, but I'm not sure it's
> possible to have it both ways.  Need to do some tests to see where the
> link is detected.

I suppose that's

wait_for_dropbear() {
local pid exe timer=60
pid="$(cat "$PIDFILE" 2>/dev/null)" || return 1

# when configure_networking() is run asynchronously dropbear might
# not have started yet; ipconfig doesn't react to SIGTERM so we wait
# for the network stack to be configured (and dropbear to start)
# rather than terminating the shell and its children
while [ $timer -gt 0 ] && exe="$(readlink -f "/proc/$pid/exe" 
2>/dev/null)"; do
if [ "$exe" = "$EXE" ]; then
echo "$pid"
return 0
fi
sleep 1
timer=$(( timer - 1))
done
return 1
}

Couldn't it also check whether the user has typed the passphrase,
and quit in this case? (I assume that the information is available
somewhere or can be made available.)

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

Bug#919619: [Pkg-utopia-maintainers] Bug#919619: NM 1.24.0 now has basic support for hidden networks with iwd backend

[Michael Biebl]

Am 04.07.20 um 00:16 schrieb Jonas Smedegaard:
> Then how about _not_ recommend iwd but just lower from depending on 
> wpasupplicant to only recommending it.  Because that's what it is: 
> Recommended for all except special situations.  For now...  Right?

Hm, no. That's exactly the situation I want to avoid. The user
installing iwd, removing wpasupplicant in the process, network not
working anymore. A Recommends makes that even worse. Either iwd works as
a drop-in replacement (without requiring explicit configuration) or not.
That's basically my question.
If it does, I'm happy to add an alternative Depends assuming Andreas is
fine with that.




signature.asc
Description: OpenPGP digital signature

Bug#963996: /usr/bin/unzip: Bomb detection fails with out of memory error when extracting bzip2-compressed files

[Spencer Harris]

I researched this a bit more and found that Mark Adler patched this in his fork.

See 

and 
.

Bug#963939: lintian: breakout-link wrongly reported against jar files

[Felix Lechner]

Control: tags -1 - pending

Hi Chris,

On Fri, Jul 3, 2020 at 1:02 PM Chris Lamb  wrote:
>
> Please go ahead.

   
https://salsa.debian.org/lintian/lintian/-/commit/8016b7d681f5b1e5a1864ac7d88da4c29fc73af7

I'll try to remember to reopen if you release before this is resolved.

Kind regards
Felix Lechner

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Guilhem Moulin]

Control: reassign -1 dropbear-initramfs 2020.79-1
Control: retitle -1 dropbear-initramfs: init-bottom blocks for 1 minute when 
there is no link
Control: severity -1 normal

On Sat, 04 Jul 2020 at 00:18:59 +0200, Vincent Lefevre wrote:
> Note that /usr/share/doc/dropbear-initramfs/README.initramfs
> says at the end:
> 
>  This is non-blocking for the startup process, so when you are at the
>  console you won't have to wait for the SSHd to complete its startup.

I happen to maintain dropbear-initramfs and wrote that :-)

While the init-premount script is non-blocking, the init-bottom is
blocking.  This is a side effect of the #943459, but I'm not sure it's
possible to have it both ways.  Need to do some tests to see where the
link is detected.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#964215: libwolfssl-dev: #warning "For timing resistance / side-channel attack prevention consider using harden options"

[Felix Lechner]

Hi Thorsten,

On Fri, Jul 3, 2020 at 3:26 PM Thorsten Glaser  wrote:
>
> Whoa, I didn’t mean you had to upload, right today, just for that ☻
> but thanks anyway.

wolfSSL is seeing an increase in popularity. By uploading, I hoped to
avoid additional uncertainty about the compatibility mode.

Kind regards & happy encrypting!
Felix Lechner

Bug#963824: No crash with wayland

[Markus Grunwald]

For what it's worth: If I run sway/wayland, the bug doesn't 
happen.


--
Markus Grunwald
https://www.the-grue.de/~markus/markus_grunwald.gpg

Bug#961792: balsa: needs to set expected server identity (for CVE-2020-13645)

[Daniel Kahn Gillmor]

Version: 2.6.1-1
Control: notfound 961792 2.5.6-2
Control: notfound 961792 2.4.12-3+b1

On Thu 2020-06-25 10:18:54 +0100, Simon McVittie wrote:
> On Fri, 29 May 2020 at 11:24:06 +0100, Simon McVittie wrote:
>> If I'm reading https://gitlab.gnome.org/GNOME/glib-networking/-/issues/135
>> and related issues correctly, fixing CVE-2020-13645 in glib-networking
>> will break SSL certificate validation in balsa, which is believed to be
>> the only widely-used application that is vulnerable to CVE-2020-13645;
>> the new glib-networking version "fails closed", which if I understand
>> correctly will result in balsa failing to validate any server cert.
>> 
>> In each supported suite, balsa should probably be updated first, and
>> then glib-networking (perhaps with versioned Breaks on the old balsa).
>
> Has anyone who uses balsa had a chance to take a look at this security
> issue? I'd prefer not to team-upload balsa, since I don't use it myself,
> and a balsa user would be able to test it a lot better.

I can confirm that this is a problem for Balsa 2.6.0-2: it cannot
connect to a legitimate IMAP server with sensible TLS credentials when
run against glib-networking 2.64.3-1 (from experimental).

I've uploaded Balsa 2.6.1-1 to unstable, which appears to resolve this
problem.  I've also tested these Balsa versions against an IMAP service
with a certificate mismatch -- they do not "fail open", which is good.

I took a look at the version in debian stable (buster, running balsa
2.5.6-2) and oldstable (stretch, running balsa 2.4.12-3+b1) -- and both
of them correctly fail closed when confronted with a certificate
mismatch.

It appears that older versions of Balsa actually use a (rather
complicated) OpenSSL for the TLS connection.  See
libbalsa/{server,libbalsa}.c for more details.  Upstream adopted
glib-networking/gio in 2.5.7 (see upstream commit
d964df60bbd85b00269da62b99bf2ce57ae442cc, a major internal overhaul),
and the certificate name check failed only on that version or later.

Please mark glib-networking 2.64.3-2 as breaking Balsa versions 2.5.7
through 2.6.0.  If you only care about versions of balsa that are
currently in any release of debian, that would be just:

   Breaks: balsa (= 2.6.0-2)

Hope this helps!

Regards,

--dkg



signature.asc
Description: PGP signature

Bug#964215: libwolfssl-dev: #warning "For timing resistance / side-channel attack prevention consider using harden options"

[Thorsten Glaser]

Dixi quod…

>Might wish to keep it open until there’s sufficient documentation
>in the package itself. If you disagree, close it, no complains.

Whoa, I didn’t mean you had to upload, right today, just for that ☻
but thanks anyway.

Good night,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Vincent Lefevre]

On 2020-07-03 16:12:49 +0200, Guilhem Moulin wrote:
> On Fri, 03 Jul 2020 at 12:53:17 +0200, Vincent Lefevre wrote:
> > I don't know really where the problem comes from, but it now takes
> > one minute to unlock the disk of my laptop with a passphrase. Well,
> > I'm not sure whether this comes from cryptsetup or something that
> > comes just after it, but at least the fact that cryptsetup doesn't
> > output any confirmation message doesn't help.
> 
> See https://wiki.debian.org/InitramfsDebug#Saving_debug_information to
> get debug output.  For further detailed debug output you can append `-x`
> to the shebang line of the boot script causing the delay.  See e.g.,
> https://cryptsetup-team.pages.debian.net/cryptsetup/README.debug.html .

I've attached the initramfs.debug file. But I don't know what
is blocking. The unlocking should have been completed before
the following lines appear (since at this time I had entered
the passphrase on the console).

IP-Config: eth0 hardware address 30:8d:99:25:ad:3f mtu 1500 DHCP RARP
IP-Config: no response after 6 secs - giving up
IP-Config: eth0 hardware address 30:8d:99:25:ad:3f mtu 1500 DHCP RARP
IP-Config: no response after 9 secs - giving up
IP-Config: eth0 hardware address 30:8d:99:25:ad:3f mtu 1500 DHCP RARP
IP-Config: no response after 16 secs - giving up
IP-Config: eth0 hardware address 30:8d:99:25:ad:3f mtu 1500 DHCP RARP
IP-Config: no response after 25 secs - giving up

Note that /usr/share/doc/dropbear-initramfs/README.initramfs
says at the end:

  This is non-blocking for the startup process, so when you are at the
  console you won't have to wait for the SSHd to complete its startup.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
+ unset log_output
+ maybe_break top
+ run_scripts /scripts/init-top
+ initdir=/scripts/init-top
+ '[' '!' -d /scripts/init-top ]
+ shift
+ . /scripts/init-top/ORDER
+ /scripts/init-top/all_generic_ide
+ '[' -e /conf/param.conf ]
+ /scripts/init-top/blacklist
+ '[' -e /conf/param.conf ]
+ /scripts/init-top/keymap
+ '[' -e /conf/param.conf ]
+ /scripts/init-top/udev
+ '[' -e /conf/param.conf ]
+ maybe_break modules
+ '[' n '!=' y ]
+ log_begin_msg 'Loading essential drivers'
+ _log_msg 'Begin: %s ... ' 'Loading essential drivers'
+ '[' n '=' y ]
+ printf 'Begin: %s ... ' 'Loading essential drivers'
Begin: Loading essential drivers ... + '[' -n  ]
+ load_modules
+ '[' -e /conf/modules ]
+ read -r m
+ '[' -z e1000e ]
+ printf '%.1s' e1000e
+ com=e
+ '[' e '=' '#' ]
+ modprobe e1000e
+ read -r m
+ '[' n '!=' y ]
+ log_end_msg
+ _log_msg 'done.\n'
+ '[' n '=' y ]
+ printf 'done.\n'
done.
+ '['  ]
+ maybe_break premount
+ '[' n '!=' y ]
+ log_begin_msg 'Running /scripts/init-premount'
+ _log_msg 'Begin: %s ... ' 'Running /scripts/init-premount'
+ '[' n '=' y ]
+ printf 'Begin: %s ... ' 'Running /scripts/init-premount'
Begin: Running /scripts/init-premount ... + run_scripts /scripts/init-premount
+ initdir=/scripts/init-premount
+ '[' '!' -d /scripts/init-premount ]
+ shift
+ . /scripts/init-premount/ORDER
+ /scripts/init-premount/dropbear
+ '[' -e /conf/param.conf ]
+ '[' n '!=' y ]
+ log_end_msg
+ _log_msg 'done.\n'
+ '[' n '=' y ]
+ printf 'done.\n'
done.
+ maybe_break mount
+ log_begin_msg 'Mounting root file system'
+ _log_msg 'Begin: %s ... ' 'Mounting root file system'
+ '[' n '=' y ]
+ printf 'Begin: %s ... ' 'Mounting root file system'
Begin: Mounting root file system ... + . /scripts/local
+ . /scripts/nfs
+ . /scripts/local
+ parse_numeric /dev/mapper/zira--vg-root
+ return
+ maybe_break mountroot
+ mount_top
+ local_top
+ '['  '!=' yes ]
+ '[' n '!=' y ]
+ log_begin_msg 'Running /scripts/local-top'
+ _log_msg 'Begin: %s ... ' 'Running /scripts/local-top'
+ '[' n '=' y ]
+ printf 'Begin: %s ... ' 'Running /scripts/local-top'
Begin: Running /scripts/local-top ... + run_scripts /scripts/local-top
+ initdir=/scripts/local-top
+ '[' '!' -d /scripts/local-top ]
+ shift
+ . /scripts/local-top/ORDER
+ /scripts/local-top/cryptopensc
+ '[' -e /conf/param.conf ]
+ /scripts/local-top/lvm2
  Volume group "zira-vg" not found
  Cannot process volume group zira-vg
  Volume group "zira-vg" not found
  Cannot process volume group zira-vg
+ '[' -e /conf/param.conf ]
+ /scripts/local-top/cryptroot
Please unlock disk sda5_crypt: IP-Config: eth0 hardware address 
30:8d:99:25:ad:3f mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
IP-Config: eth0 hardware address 30:8d:99:25:ad:3f mtu 1500 DHCP RARP
IP-Config: no response after 3 secs - giving up
IP-Config: eth0 hardware address 30:8d:99:25:ad:3f mtu 1500 DHCP RARP
IP-Config: no response after 4 secs - giving up

cryptsetup: sda5_crypt: set up successfully
+ '[' -e /conf/param.conf ]
+ '[' n '!=' y ]
+ log_end_msg
+ _log_msg 'done.\n'
+ '[' n '=' y ]
+ printf 'done.\n'
done.
+ local_top_used=yes
+ '[' -z  ]
+ cat /proc/uptime
+ 

Bug#964214: libdebhelper-perl: dh_auto_configure cannot do out-of-tree builds for qmake buildsystem

[Niels Thykier]

Thorsten Glaser:
> Package: libdebhelper-perl
> Version: 13.1
> Severity: normal
> 
> Apparently, dh7 fails to tell qmake the location of the source directory
> when attempting an out-of-tree build:
> 
> 
> […]
> 
> 
> The qmake invocation syntax error message is somewhat misleading,
> but looking at the invocation command line it becomes somewhat clearer.
> 

Interesting.  I am not sure out of source builds have ever been
supported by qmake (at least not correctly at any rate).  If you know
how to do it, then I am happy to look at fixing it.

~Niels

Bug#919619: NM 1.24.0 now has basic support for hidden networks with iwd backend

[Jonas Smedegaard]

Quoting Michael Biebl (2020-07-03 21:50:36)
> Hi,
> 
> On Tue, 26 May 2020 13:10:27 +0200 Andreas Henriksson 
> wrote:
> > Just wanted to drop a comment about the iwd status in NM.
> > NM has since 1.24.0, which is now in testing/unstable, basic
> > support for connecting to a hidden network using the iwd backend.
> > 
> > There are still many minor bugs remaining in the NM iwd backend
> > both for hidden and any other network. Examples that comes to mind:
> > - Removing a connection in NM doesn't seem to propagate
> >   to iwd known-network list.
> > - NM and iwd sometimes gets out of sync for unknown reasons,
> >   stopping iwd and restarting NetworkManager then browsing menues
> >   to trigger dbus activation of iwd again can be used as a workaround.
> > - nmcli errors out on trying to scan (for a hidden network!) even when
> >   specifying 'hidden yes' on the command line. (Working method to
> >   provision a hidden network includes using the "Connect to hidden
> >   network..." menu entry in gnome-control-center Wi-Fi pane.)
> > - and more...
> > 
> > Many minor workaroundable issues that needs more polish.
> > Unfortunately it doesn't seem like anyone is working on improving
> > the NM iwd backend since quite a while now (except for my basic hidden
> > network contribution, which was a one-off for personal needs).
> 
> That sounds a bit like the iwd is only semi-maintained in NM which makes
> me a bit uncomfortable tbh. What also concerns me a bit is, that ttbomk
> we don't have an automatic fallback to iwd.
> Say I switch the dependency to wpasupplicant | iwd, wpasupplicant is
> removed. NM is not automatically using iwd without explicit
> configuration? Is that correct?

Then how about _not_ recommend iwd but just lower from depending on 
wpasupplicant to only recommending it.  Because that's what it is: 
Recommended for all except special situations.  For now...  Right?

 - Jonas

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

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

signature.asc
Description: signature

Bug#961195: transition: glibc

[Aurelien Jarno]

On 2020-06-04 14:08, Matthias Klose wrote:
> On 6/4/20 2:05 PM, Aurelien Jarno wrote:
> > On 2020-06-04 13:06, Matthias Klose wrote:
> >> On 5/21/20 11:39 AM, Aurelien Jarno wrote:
> >>> Package: release.debian.org
> >>> Severity: normal
> >>> User: release.debian@packages.debian.org
> >>> Usertags: transition
> >>>
> >>> Dear release team,
> >>>
> >>> I would like to get a transition slot for glibc 2.31. It is available in
> >>> experimental for more than 2 months and there are no known issues or
> >>> regression.  It has been built successfully on all release architectures
> >>> and most ports architectures. It fails to build on ia64 and sparc64 due
> >>> to a few testsuite issues that need to be investigated and which are
> >>> similar to existing failures in version 2.30. It doesn't build on
> >>> kfreebsd-*, but this has been the case for a few glibc releases already.
> >>>
> >>> As glibc is using symbol versioning, there is no soname change. That
> >>> said a few packages are using libc internal symbols and have to be
> >>> rebuilt for this transition:
> >>>  - apitrace
> >>>  - bro
> >>>  - dante
> >>>  - gcc-9 (s390x only)
> >>>  - libnih
> >>>  - libnss-db
> >>>  - r-bioc-preprocesscore
> >>>  - unscd
> >>>
> >>> Compare to the previous transition, gcc-10 and gcc-snapshot got removed,
> >>> and r-bioc-preprocesscore got added.
> >>>
> >>> Here is the corresponding ben file:
> >>>   title = "glibc";
> >>>   is_affected = .depends ~ /libc[0-9.]* \(< >>>   is_good = .depends ~ /libc[0-9.]* \(<< 2.32\)/;
> >>>   is_bad = .depends ~ /libc[0-9.]* \(<< 2.31\)/;
> >>>
> >>> In addition a few new symbols have been added that might prevent a few
> >>> other packages to migrate to testing until glibc migrates if they pick
> >>> up the new symbols, however those are really limited in this version.
> >>
> >> there are dozens of packages that ftbfs with this new version.  Please 
> >> could you
> >> at least file bug reports for all of those?
> > 
> > Yes I can do that. Do you have a list available?
> 
> No.

Lucas Nussbaum has been kind enough to do an archive rebuild with glibc
2.31. The logs are available there:

http://qa-logs.debian.net/2020/06/24/

Fortunately there are less than a dozen of build failures caused by this
new version. Here is a classification of those failures with some
explanations:

* Packages affected by the stime removal from the API:
  - busybox_1:1.30.1-4  #955368
  - linuxtv-dvb-apps_1.1.1+rev1500-1.2  #964223
  - log4cpp_1.1.3-1 #964225
  - mandos_1.8.11-1 #964226
  - vdr_2.4.1-4 #964220

* Packages affected by the gettimeofday API change:
  - datefudge_1.23  #964227
  - purelibc_0.4.1-2#964229

* Packages affected by the deprecation of ftime:
  - faketime_0.9.7-3#964231

* Packages affected by the replacement of the __*_finite symbols by
  compat symbols. The API is unchanged, however it affects linking
  static objects built with glibc < 2.30 with static objects built with
  glibc >= 2.31. This is a purely a link time issue, there is not impact
  at runtime:
  - qosmic_1.6.0-2: This package is linking against the flam3 library,
which is only available statically. The flam3 package should
therefore be binNMUed as part of the transition.
  - nageru_2.0.0-3: This package is using lld as the linker instead of
ld, and it is over picky about the usage of the __*_finite functions
in dynamic libraries (here libx264.so). The package builds fine with
ld, so it looks an LLVM issue to me. The easiest workaround is to
binNMU x264 as part of the transition.

* Packages that are (indirectly) part of the transition and will be
  fixed by the binNMUs:
  - cgmanager_0.41-2
  - r-bioc-affy_1.66.0-1
  - r-bioc-makecdfenv_1.64.0-1
  - r-cran-wgcna_1.69-1

* Packages that build-depend on glibc-source and will need a source
  upload after the glibc 2.31 upload to sid:
  - gcc-9-cross_22
  - gcc-10-cross_9


As a summary, we will need to binNMU a few more packages than the one
listed by the tracker. All packages that need fixes now have an entry in
the BTS with a patch. I think the transition can be started in a few
days, we can always NMU those packages.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#964230: debhelper: dh_missing conflicts with global --sourcedir option

[Niels Thykier]

Thorsten Glaser:
> Package: debhelper
> Version: 13.1
> Severity: important
> 
> Something for debhelper compat 14 ;-)
> 
> I’m packaging a piece of s…oftware whose main buildsystem entry
> is in a subdirectory so I’m using --sourcedir=thatsubdir in the
> call to dh7.
> 
> The build then fails because dh_missing complains about every
> file in the tree being not installed. Looking at its manpage
> it abuses --sourcedir for something with completely different
> semantics.
> 

Historical artefact caused by debhelper accepting abbreviations of the
full parameters, which causes this issue.  Honestly, I am not sure
whether dh_install's --sourcedir or dh_auto_* --sourcedir (via
autoabbrev) came first.

Anyhow, based on your report, you can probably resolve this by using
--sourcedirectory=thatsubdir.  The longer form is *only* accepted by the
dh_auto_* tools (making dh_install/dh_missing ignore it).

> I’d have expected something else, like --destdir or, with BSD
> ports terminology, --fakedir, or so.
> 

Sadly, --destdir is also taken... by dh_builddir. >.>

> Of course, dh_missing’s --sourcedir cannot be renamed within
> a compat level. But it should, for the next one.
> 
> [...]
Indeed, it might be overdue to clean up this ancient clashes.

~Niels

Bug#929272: nmap-common: executable distributed in nmap-common detected as malware

[Hilko Bengen]

* Samuel Henrique:

> Looking at nmap changelog, it seems like this issue has been going
> back and forth[0] and had stabilized after some point (I guess that's
> when most AV vendors added the signature), this means that any changes
> in the compilation might trigger the issue again.
>
> Hilko, do you have any thoughts on this?

I am just a tad bit tired of discussing (or even hearing about) this
issue.

So I tried a thing, instead. Piping nse-service.exe through gzip,
base64, tac (in that order) results in a file that is not getting
recognized by the AV swarm stupidity currently[1] enabled in VirusTotal.

I'll be pushing a commit that implements some build-time obfuscation and
install-time deobfuscation.

Cheers,
-Hilko

[1] 
https://www.virustotal.com/gui/file/3b6124713f0af1b4a74129bc26bb1793afe8c0bf91d60ff4fe57f23562b8986d/detection

Bug#964232: ITP: fairy-stockfish -- chess variant engine derived from Stockfish, including Shogi and XiangQi support

[Yann Dirson]

Package: wnpp
Severity: wishlist
Owner: Yann Dirson 

* Package name: fairy-stockfish
  Version : 11.1
  Upstream Author : Fabian Fichter (unknown email)
* URL : https://github.com/ianfab/Fairy-Stockfish
* License : GPLv3+
  Programming Lang: C++
  Description : chess variant engine derived from Stockfish, including 
Shogi and XiangQi support

This is notably the AI engine behind pychess.org.  Supports many
protocols (CECP, UCI, USI, UCCI).

Bug#964231: faketime: FTBFS with glibc 2.31 due to ftime deprecation

[Aurelien Jarno]

Package: faketime
Version: 0.9.7-3
Severity: important
Tags: patch upstream

faketime fails to build from source with glibc 2.31:

| gcc -c -std=gnu99 -Wall -DFAKE_STAT -Werror -Wextra timetest.c
| ./testframe.sh functests
| # Begin Test Suites in functests
| 
| # Begin functests/test_exclude_mono.sh
| # PLATFORM=linuxlike
| timetest.c: In function ‘main’:
| timetest.c:143:5: error: ‘ftime’ is deprecated 
[-Werror=deprecated-declarations]
|   143 | ftime();
|   | ^
| In file included from timetest.c:25:
| /usr/include/x86_64-linux-gnu/sys/timeb.h:39:12: note: declared here
|39 | extern int ftime (struct timeb *__timebuf)
|   |^
| cc1: all warnings being treated as errors
| make[2]: *** [Makefile:12: timetest.o] Error 1
| make[2]: *** Waiting for unfinished jobs


The full build log is available there:
 http://qa-logs.debian.net/2020/06/24/faketime_0.9.7-3_unstable_glibc-exp.log

In glibc 2.31, the ftime function has been marked as deprecated, though
it's still usable. however the tests are run with -Wall -Wextra -Werror,
turning causing this deprecation into an error.

Upstream already has a fix for this issue, although the issue is wrongly
attributed to gcc 9 instead of glibc 2.31:

https://github.com/wolfcw/libfaketime/commit/f19d68ea3231f1af7a6e3913dc6d3c46f73947b2

This patch applies cleanly to the version in debian and correctly fixes
the issue. It would be nice if you can apply it relatively soon so that
we can start the transition.

Regards,
Aurelien

Bug#322694: www.debian.org: Missing link to hd-media/boot.img.gz

[Holger Wansing]

Control: tags -1 + pending


Marvin Stark  wrote (12 Aug 2005 10:38:35 +0200):
> I'am missing the link to hd-media/boot.img.gz in the tutorial howto boot
> debian from a 
> USB-Memory-Stick(http://www.debian.org/releases/stable/i386/ch04s04.html.de).
> It would be nice if you include the link to the boot.img.gz.
> http://http.us.debian.org/debian/dists/Debian3.1r0/main/installer-i386/current/images/hd-media/boot.img.gz

This has been fixed recently in
https://salsa.debian.org/installer-team/installation-guide/-/commit/dd9b6d669c312ce043c87e8ecbffd431fcf1d2d8


So tagging this bug as pending
Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#961676: 5.6 kernel crashes host when using VFIO on KVM guests

[Simon John]

Done some more digging.

I can boot my macos vm using QXL instead of a passthrough GPU, even if i 
passthrough the USB device (not pci controller). So its definitely only 
passing through PCI devices like graphics cards that breaks things.


So this works in qemu terms:

-usb -device usb-host,hostbus=1,hostaddr=3 \

This breaks things:

-device vfio-pci,host=02:00.0,multifunction=on \
-device vfio-pci,host=02:00.1

Oddly enough an Ubuntu 20.04 vm works fine with the gpu and usb passed 
through.


Added the qemu shell scripts to the gist:

https://gist.github.com/sej7278/766043a69c76308f84cfa14b3f3a924f

Regards.

--
Simon John

Bug#900739: crashing in toke.c, keyword plugin pointer is left pointing to an XS module that's been unloaded

[Dominic Hargreaves]

Thanks. The fix hasn't been integrated into the 5.24 maint branch so
any data we can have about it being battle tested is valuable.

Dominic.

On Thu, Jul 02, 2020 at 05:04:10PM -0700, Dean Hamstead wrote:
> We have been running it in prod since before the ticket was raised in
> debian. We were hoping to pull compiling perl out of our pipeline.
> 
> I would add again, that this is a fix from upstream and is included in all
> newer versions of perl.
> 
> 
> Dean
> 
> On 2020-07-02 15:05, Dominic Hargreaves wrote:
> > On Wed, Jul 01, 2020 at 05:07:33PM -0700, Dean Hamstead wrote:
> > > My preference would be to apply the patch as its a genuine bug fix
> > > from
> > > upstream.
> > 
> > Hi Dean
> > 
> > Thanks for the reply. We do just have a chance to get it into the final
> > stretch point release and we do have other changes queued for perl now.
> > You implied in an earlier message that you'd been running a patched
> > Debian package with https://github.com/Perl/perl5/issues/16086 - can
> > I check this is (still) the case? It'd give us a lot more confidence to
> > know that the combination we'd plan to release has been battle tested.
> > 
> > It's up to the stable release managers of course - I will email now.
> > 
> > Cheers
> > Dominic
> 

Bug#964177: Also affects testing/sid

[Boyd Stephen Smith Jr.]

found 964177 83.0.4103.116-2
thanks

Upgraded chromium and its dependencies to testing and segfaults/crashes 
remain.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


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

Bug#779736: Note on manpage

[Calum McConnell]

If you could add a note about this to the manpage, I'd appreciate that
Thanks!
-Calum

Bug#964230: debhelper: dh_missing conflicts with global --sourcedir option

[Thorsten Glaser]

On Fri, 3 Jul 2020, Thorsten Glaser wrote:

> Of course, dh_missing’s --sourcedir cannot be renamed within
> a compat level. But it should, for the next one.

Others, like dh_install, also misuse --sourcedir.

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!

Bug#964016: js8call: New Upstream Available

[Christoph Berg]

Re: Dave Hibberd
> I'm happy to prepare an update on salsa, if no one has any objections!

Fine with me.

Thanks,
Christoph

Bug#964230: debhelper: dh_missing conflicts with global --sourcedir option

[Thorsten Glaser]

Package: debhelper
Version: 13.1
Severity: important

Something for debhelper compat 14 ;-)

I’m packaging a piece of s…oftware whose main buildsystem entry
is in a subdirectory so I’m using --sourcedir=thatsubdir in the
call to dh7.

The build then fails because dh_missing complains about every
file in the tree being not installed. Looking at its manpage
it abuses --sourcedir for something with completely different
semantics.

I’d have expected something else, like --destdir or, with BSD
ports terminology, --fakedir, or so.

Of course, dh_missing’s --sourcedir cannot be renamed within
a compat level. But it should, for the next one.

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

Kernel: Linux 5.6.0-2-amd64 (SMP w/2 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/lksh
Init: sysvinit (via /sbin/init)

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  1.8.1-1
ii  dpkg 1.20.3
ii  dpkg-dev 1.20.3
ii  dwz  0.13-5
ii  file 1:5.38-5
ii  libdebhelper-perl13.1
ii  libdpkg-perl 1.20.3
ii  man-db   2.9.3-1
ii  perl 5.30.3-4
ii  po-debconf   1.0.21

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#964229: purelibc: FTBFS with glibc 2.31 (conflicting gettimeofday prototype)

[Aurelien Jarno]

Source: purelibc
Version: 0.4.1-2
Severity: important
Tags: patch upstream

purelibc fails to build from source with glibc 2.31:

| /bin/bash ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.   
-Wdate-time -D_FORTIFY_SOURCE=2 -g -ggdb -D_GNU_SOURCE -g -Wall -O0 -c -o 
libpurelibc_la-syscalls.lo `test -f 'syscalls.c' || echo './'`syscalls.c
| libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-ggdb -D_GNU_SOURCE -g -Wall -O0 -c syscalls.c  -fPIC -DPIC -o 
.libs/libpurelibc_la-syscalls.o
| syscalls.c:864:5: error: conflicting types for ‘gettimeofday’
|   864 | int gettimeofday(struct timeval *tv, struct timezone *tz){
|   | ^~~~
| In file included from syscalls.c:33:
| /usr/include/x86_64-linux-gnu/sys/time.h:66:12: note: previous declaration of 
‘gettimeofday’ was here
|66 | extern int gettimeofday (struct timeval *__restrict __tv,
|   |^~~~
| syscalls.c:65:12: warning: ‘_pageshift’ defined but not used 
[-Wunused-function]
|65 | static int _pageshift()
|   |^~
| make[2]: *** [Makefile:390: libpurelibc_la-syscalls.lo] Error 1
| make[2]: Leaving directory '/<>'
| make[1]: *** [Makefile:235: all] Error 2
| make[1]: Leaving directory '/<>'
| make: *** [/usr/share/cdbs/1/class/makefile.mk:77: 
debian/stamp-makefile-build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

The full build log is available there:
http://qa-logs.debian.net/2020/06/24/purelibc_0.4.1-2_unstable_glibc-exp.log

The support for timezones in gettimeofday has been removed in glibc
2.31. As a result the second argument of the gettimeofday prototype has
been changed from struct timezone * to void *. The same change needs to
be done in datefudge.

You will find attached a patch fixing that. It would be nice if it can
be fixed relatively soon so that we can start the transition.

Regards,
Aurelien
diff -u purelibc-0.4.1/syscalls.c purelibc-0.4.1/syscalls.c
--- purelibc-0.4.1/syscalls.c
+++ purelibc-0.4.1/syscalls.c
@@ -861,7 +861,7 @@
return _pure_syscall(__NR_getrusage,usage);
 }
 
-int gettimeofday(struct timeval *tv, struct timezone *tz){
+int gettimeofday(struct timeval *tv, void *tz){
return _pure_syscall(__NR_gettimeofday, tv, tz);
 }
 

Bug#963887: UDD: 'duck' importer broken since 2020-05-25

[Christoph Berg]

Re: Baptiste BEAUPLAT
> >> Maybe you could add that to vcswatch?
> 
> The main differences between vcswatch and duck.d.n are:
> 
> - history: duck used to keep 6 runs for each package, reporting only
> after 3 failures. vcswatch only keeps the last run.

vcswatch could be improved by not notifying the users for each error.
At the moment the data model is very simple, but adding that would be
possible I'd think.

> - d/control: duck processed the Homepage as well as the
> Vcs-{Git,SVN,Hg,Darcs} fields. vcswatch has a wider support for all Vcs-*.

There's not much that vcswatch supports on top of that. CVS, but I
don't think anyone is still actively using it, the remaining entries
are just bitrot.

> - d/upstream/metadata: duck processed any urls found here.
> - worker: parallel worker for duck, single instance for vcswatch.

vcswatch can start several workers in parallel, the current config
starts up to 5 workers.

> I'm not convinced that adding those features would result in an
> improvement for vcswatch (Cc'ing Christoph to have his input on that).
> 
> Creating a new sub-project, like vcswatch, to qa.debian.org would be
> more sensible IMHO. The new duck could only take care of the http urls
> and leave Vcs stuff to vcswatch.

You could reuse the vcsimport machinery. It's not very pretty, but
works.

Christoph

Bug#964228: buster-pu: package nmap/7.70+dfsg1-6+deb10u1

[Samuel Henrique]

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

A backported upstream patch [0] is required to fix #940284 [1] on nmap;
Bug title: autogeneration of ssl key in ssl server mode of ncat is broken

The issue itself is well described in both BTS [1] and the upstream
bug report [2], but the summary of it is that the openssl shipped with
Buster requires a key with minimum size of 2048b, while nmap 7.70
generates one sized 1024b. This has been fixed in 7.80 (which is the
version on Testing right now).

The debdiff is attached to this email,

Thanks,

[0] https://github.com/nmap/nmap/commit/25db5fbb0d8fb88b6e7f4f298c862cd05ed0f8b1
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940284
[2] https://github.com/nmap/nmap/pull/1310

-- 
Samuel Henrique 


nmap_7.70+dfsg1-6+deb10u1.debdiff
Description: Binary data

Bug#964218: [Pkg-javascript-devel] Bug#964218: node-yarnpkg: autopkgtest fails with node-uuid 8.2 from experimental - "Cannot read property 'v4' of undefined"

[Paolo Greppi]

Updating that dependency is already in upsream's TODO list
https://github.com/yarnpkg/yarn/issues/6829
.. but they seem to lag on updating dependencies.

I guess it would require fixing against this breaking change:
https://github.com/uuidjs/uuid/blob/master/CHANGELOG.md#-breaking-changes
and upstream the patch ..

Why do you need uuid v8 if I may ask ?

Paolo

Il 03/07/20 21:03, Pirate Praveen ha scritto:
> Package: node-yarnpkg
> Version: 1.22.4-3
> Severity: important
> 
> Full build log is attached. This was run in a clean and uptodate lxc 
> container using salsa.debian.org/ruby-team/meta/build script.

Bug#964227: datefudge: FTBFS with glibc 2.31 (conflicting gettimeofday prototype)

[Aurelien Jarno]

Package: datefudge
Version: 1.23
Severity: important
Tags: patch upstream

datefudge fails to build from source with glibc 2.31

| gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wextra -D_REENTRANT -fpic -c -o datefudge.o 
datefudge.c
| sed -e 's,@VERSION@,1.23,g; s,@MULTIARCH_PATTERN@,/*-*,g; 
s,@LIBDIR@,/usr/lib,g;' \
| < datefudge.man > datefudge.1
| datefudge.c:81:5: error: conflicting types for ‘gettimeofday’
|81 | int gettimeofday(struct timeval *x, struct timezone *y) {
|   | ^~~~
| In file included from datefudge.c:21:
| /usr/include/x86_64-linux-gnu/sys/time.h:66:12: note: previous declaration of 
‘gettimeofday’ was here
|66 | extern int gettimeofday (struct timeval *__restrict __tv,
|   |^~~~
| make[1]: *** [Makefile:40: datefudge.o] Error 1
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j4 "INSTALL=install --strip-program=true" 
returned exit code 2
| make: *** [debian/rules:16: binary] Error 25
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

The full build log is available there:
http://qa-logs.debian.net/2020/06/24/datefudge_1.23_unstable_glibc-exp.log

The support for timezones in gettimeofday has been removed in glibc
2.31. As a result the second argument of the gettimeofday prototype has
been changed from struct timezone * to void *. The same change needs to
be done in datefudge.

You will find attached a patch fixing that. It would be nice if it can
be fixed relatively soon so that we can start the transition.

Regards,
Aurelien
diff -Nru datefudge-1.23/datefudge.c datefudge-1.23/datefudge.c
--- datefudge-1.23/datefudge.c  2019-08-02 18:09:51.0 +
+++ datefudge-1.23/datefudge.c  2020-07-03 20:49:48.0 +
@@ -66,8 +66,8 @@
 
 #endif
 
-int __gettimeofday(struct timeval *x, struct timezone *y) {
-static int (*libc_gettimeofday)(struct timeval *, struct timezone *) = 
NULL;
+int __gettimeofday(struct timeval *x, void *y) {
+static int (*libc_gettimeofday)(struct timeval *, void *) = NULL;
 int res;
 
 if(!libc_gettimeofday)
@@ -78,7 +78,7 @@
 return 0;
 }
 
-int gettimeofday(struct timeval *x, struct timezone *y) {
+int gettimeofday(struct timeval *x, void *y) {
 return __gettimeofday(x,y);
 }
 

Bug#964226: mandos: 1.8.11-1

[Aurelien Jarno]

Source: mandos
Version: 1.8.11-1
Severity: important
Tags: patch upstream

mandos fails to build from source with glibc 2.31:

| g++ -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -fPIC -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DREMOTE_KBD -DSDNOTIFY 
-DLIRC_DEVICE=\"/var/run/lirc/lircd\" -DVIDEODIR=\"/var/lib/video\" 
-DCONFDIR=\"/var/lib/vdr\" -DARGSDIR=\"/etc/vdr/conf.d\" 
-DCACHEDIR=\"/var/cache/vdr\" -DRESDIR=\"/usr/share/vdr\" 
-DPLUGINDIR=\"/usr/lib/vdr/plugins\" -DLOCDIR=\"/usr/share/locale\" 
-I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16   -o 
eitscan.o eitscan.c
| eit.c: In constructor ‘cTDT::cTDT(const u_char*)’:
| eit.c:394:13: error: ‘stime’ was not declared in this scope; did you mean 
‘ctime’?
|   394 | if (stime() == 0)
|   | ^
|   | ctime
| make[2]: *** [Makefile:135: eit.o] Error 1
| make[2]: *** Waiting for unfinished jobs
| make[2]: Leaving directory '/<>'
| dh_auto_build: error: make -j4 "INSTALL=install --strip-program=true" 
PREFIX=/usr VIDEODIR=/var/lib/video LIBDIR=/usr/lib/vdr/plugins SDNOTIFY=1 
VERBOSE=1 returned exit code 2
| make[1]: *** [debian/rules:17: override_dh_auto_build] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:14: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

The full build log is available there:
http://qa-logs.debian.net/2020/06/24/mandos_1.8.11-1_unstable_glibc-exp.log

The stime function has been marked as obsolete for some time, and since
glibc 2.31 it is no longer available to newly linked binaries. The
clock_settime function should be used instead.

You will find attached a patch fixing that. It would be nice if it can
be fixed relatively soon so that we can start the transition.

Regards,
Aurelien
diff -Nru mandos-1.8.11/debian/patches/glibc-stime.patch 
mandos-1.8.11/debian/patches/glibc-stime.patch
--- mandos-1.8.11/debian/patches/glibc-stime.patch  1970-01-01 
00:00:00.0 +
+++ mandos-1.8.11/debian/patches/glibc-stime.patch  2020-07-03 
20:40:43.0 +
@@ -0,0 +1,17 @@
+The obsolete function stime is no longer available to newly linked binaries
+since glibc 2.31. Replace it by clock_settime.
+
+--- a/plugins.d/mandos-client.c
 b/plugins.d/mandos-client.c
+@@ -396,9 +396,8 @@ static bool init_gpgme(const char * cons
+   fprintf_plus(stderr,
+"Setting system clock to key file mtime");
+   }
+-  time_t keytime = keystat.st_mtim.tv_sec;
+-  if(stime() != 0){
+-  perror_plus("stime");
++  if(clock_settime(CLOCK_REALTIME, _mtim) != 0){
++  perror_plus("clock_settime");
+   }
+   ret = lower_privileges();
+   if(ret != 0){
diff -Nru mandos-1.8.11/debian/patches/series 
mandos-1.8.11/debian/patches/series
--- mandos-1.8.11/debian/patches/series 1970-01-01 00:00:00.0 +
+++ mandos-1.8.11/debian/patches/series 2020-07-03 20:40:43.0 +
@@ -0,0 +1 @@
+glibc-stime.patch

Bug#964225: log4cpp: FTBFS with glibc 2.31 (uses removed stime function)

[Aurelien Jarno]

Source: log4cpp
Version: 1.1.3-1
Severity: important
Tags: patch upstream

log4cpp fails to build from source with glibc 2.31:

| g++ -DHAVE_CONFIG_H -I. -I../include -I../include -I../src  -Wdate-time 
-D_FORTIFY_SOURCE=2  -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-unused 
-pedantic -c -o testDailyRollingFileAppender.o testDailyRollingFileAppender.cpp
| testDailyRollingFileAppender.cpp:43:35: warning: invalid suffix on literal; 
C++11 requires a space between literal and string macro [-Wliteral-suffix]
|43 | const char* const nesteddirname = "nesteddir"PATHDELIMITER;
|   |   ^
| testDailyRollingFileAppender.cpp: In function ‘int 
OnlyManualTesting::jumpToFuture(int)’:
| testDailyRollingFileAppender.cpp:235:7: error: ‘stime’ was not declared in 
this scope; did you mean ‘ctime’?
|   235 |   if (stime() == -1) {
|   |   ^
|   |   ctime
| make[3]: *** [Makefile:813: testDailyRollingFileAppender.o] Error 1
| make[3]: Leaving directory '/<>/tests'
| make[2]: *** [Makefile:1161: check-am] Error 2
| make[2]: Leaving directory '/<>/tests'
| make[1]: *** [Makefile:555: check-recursive] Error 1
| make[1]: Leaving directory '/<>'
| dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2
| make: *** [debian/rules:3: build] Error 25
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

The full build log is available there:
http://qa-logs.debian.net/2020/06/24/log4cpp_1.1.3-1_unstable_glibc-exp.log

The stime function has been marked as obsolete for some time, and since
glibc 2.31 it is no longer available to newly linked binaries. The
clock_settime function should be used instead.

You will find attached a patch fixing that. It would be nice if it can
be fixed relatively soon so that we can start the transition.

Regards,
Aurelien
diff -Nru log4cpp-1.1.3/debian/patches/06-glibc-stime.patch 
log4cpp-1.1.3/debian/patches/06-glibc-stime.patch
--- log4cpp-1.1.3/debian/patches/06-glibc-stime.patch   1970-01-01 
01:00:00.0 +0100
+++ log4cpp-1.1.3/debian/patches/06-glibc-stime.patch   2020-07-03 
22:31:02.0 +0200
@@ -0,0 +1,15 @@
+The obsolete function stime is no longer available to newly linked binaries
+since glibc 2.31. Replace it by clock_settime.
+
+--- a/tests/testDailyRollingFileAppender.cpp
 b/tests/testDailyRollingFileAppender.cpp
+@@ -232,7 +232,8 @@ namespace OnlyManualTesting {
+ 
+   now += seconds;
+ 
+-  if (stime() == -1) {
++  struct timespec ts = { .tv_sec = now };
++  if (clock_settime(CLOCK_REALTIME, ) == -1) {
+   std::cerr << "Can not set date. Need admin privileges?" 
<< std::endl;
+   return -1;
+   }
diff -Nru log4cpp-1.1.3/debian/patches/series 
log4cpp-1.1.3/debian/patches/series
--- log4cpp-1.1.3/debian/patches/series 2018-05-12 23:29:11.0 +0200
+++ log4cpp-1.1.3/debian/patches/series 2020-07-03 22:31:02.0 +0200
@@ -2,4 +2,5 @@
 03_aclocal_automake.diff
 04_gcc43.diff
 05_remove_log4cpp_cflags_from_pkgconfig_file.diff
+06-glibc-stime.patch
 fix-abs-call

Bug#964224: package new upstream snapshot from mob

[John Scott]

Source: tcc
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I've found many bugs and quirks are fixed upstream at
https://repo.or.cz/w/tinycc.git

It's very actively maintained and endorsed by the now-inactive author [1].
tcc is also of interest for bootstrappable builds. They don't appear to
intend making a new versioned release, but I would be glad to help test
a snapshot for regressions, e.g. by trying to rebuild Debian packages
against the old and the new.

[1] https://bellard.org/tcc/

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

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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXv+VIQAKCRByvHFIwKst
p3cZAP9BhHdOu7PlmTDZ3UyRF+kx3FCTNbwOf0AH79iYwoTEFAD+O1lS9UeZIszM
bpz5z+rKknghHhpLihmgHvM4O6uZkQw=
=YlVW
-END PGP SIGNATURE-

Bug#964223: linuxtv-dvb-apps: FTBFS with glibc 2.31 (uses removed stime function)

[Aurelien Jarno]

Source: linuxtv-dvb-apps
Version: 1.1.1+rev1500-1.2
Severity: important
Tags: patch upstream

linuxtv-dvb-apps fails to build from source with glibc 2.31:

| CC dvbdate
| dvbdate.c: In function ‘set_time’:
| dvbdate.c:312:6: warning: implicit declaration of function ‘stime’; did you 
mean ‘ctime’? [-Wimplicit-function-declaration]
|   312 |  if (stime(new_time)) {
|   |  ^
|   |  ctime
| /usr/bin/ld: /tmp/cchQDddv.o: in function `set_time':
| ./util/dvbdate/dvbdate.c:312: undefined reference to `stime'
| /usr/bin/ld: ./util/dvbdate/dvbdate.c:312: undefined reference to `stime'
| collect2: error: ld returned 1 exit status
| make[3]: *** [../../Make.rules:82: dvbdate] Error 1
| make[3]: Leaving directory '/<>/util/dvbdate'
| make[2]: *** [Makefile:10: all] Error 2
| make[2]: Leaving directory '/<>/util'
| make[1]: *** [Makefile:14: all] Error 2
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j1 returned exit code 2
| make: *** [debian/rules:4: build] Error 25
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

The full build log is available there:
http://qa-logs.debian.net/2020/06/24/linuxtv-dvb-apps_1.1.1+rev1500-1.2_unstable_glibc-exp.log

The stime function has been marked as obsolete for some time, and since
glibc 2.31 it is no longer available to newly linked binaries. The
clock_settime function should be used instead.

You will find attached a patch fixing that. It would be nice if it can
be fixed relatively soon so that we can start the transition.

Regards,
Aurelien
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/glibc-stime.patch 
linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/glibc-stime.patch
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/glibc-stime.patch 
1970-01-01 00:00:00.0 +
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/glibc-stime.patch 
2020-07-03 20:13:33.0 +
@@ -0,0 +1,16 @@
+The obsolete function stime is no longer available to newly linked binaries
+since glibc 2.31. Replace it by clock_settime.
+
+--- a/util/dvbdate/dvbdate.c
 b/util/dvbdate/dvbdate.c
+@@ -309,7 +309,9 @@ int atsc_scan_date(time_t *rx_time, unsi
+  */
+ int set_time(time_t * new_time)
+ {
+-  if (stime(new_time)) {
++  struct timespec ts = { .tv_sec = new_time };
++
++  if (clock_settime(CLOCK_REALTIME, )) {
+   perror("Unable to set time");
+   return -1;
+   }
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series 
linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series2018-01-23 
17:50:35.0 +
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series2020-07-03 
20:13:33.0 +
@@ -9,3 +9,4 @@
 use-ldflags.patch
 fix-build-libpng16.patch
 dst_test-no-set-id.patch
+glibc-stime.patch

Bug#964222: Upstream is dead, please use the new maintained fork

[Louis-Philippe Véronneau]

Package: src:clj-yaml-clojure
Version: 0.4.0-1

Hi!

Upstream is dead, please use the new maintained fork for this package:
https://github.com/clj-commons/clj-yaml

Cheers,

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



signature.asc
Description: OpenPGP digital signature

Bug#953986: nmap-mac-prefixes outdated

[Samuel Henrique]

Hello Carsten,

Thanks for the report,

I looked into it and confirmed that this file gets updated with each
release of nmap, is there any specific problem you're having with it?

Regards,

-- 
Samuel Henrique 

Bug#964221: googletest: meson support

[Philipp Kern]

Source: googletest
Version: 1.10.0-3

googletest is weirdly special in that it is supposed to be compiled together
with the project that is being tested, using the same flags. As such it ships
with source files and not just a shared library that can be imported using
pkg-config. Right now it supports cmake as-is.

Meson is a (new?) build system that is gaining in popularity. Right now what a
meson-using upstream project can do to manage its dependencies tightly is to
use so-called "wraps" that patch meson.build build system definitions from the
internet on top of an arbitrary upstream source that does not support meson
yet. So for gtest there is [1], which ships a zip for 1.10.0 at [2] that
contains three meson.build files and one LICENSE.build.

Would it be possible for googletest in Debian to ship these meson.build files
alongside the source in the library packages? That way packages could
build-depend on libgtest-dev without requiring them to use CMake.

Kind regards and thanks
Philipp Kern

[1] https://wrapdb.mesonbuild.com/gtest
[2] https://wrapdb.mesonbuild.com/v1/projects/gtest/1.10.0/1/get_wrap

Bug#964220: vdr: FTBFS with glibc 2.31 (uses removed stime function)

[Aurelien Jarno]

Source: vdr
Version: 2.4.1-4
Severity: important
Tags: patch upstream

Dear maintainer,

vdr fail to build from source with glibc 2.31:

| g++ -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -fPIC -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DREMOTE_KBD -DSDNOTIFY 
-DLIRC_DEVICE=\"/var/run/lirc/lircd\" -DVIDEODIR=\"/var/lib/video\" 
-DCONFDIR=\"/var/lib/vdr\" -DARGSDIR=\"/etc/vdr/conf.d\" 
-DCACHEDIR=\"/var/cache/vdr\" -DRESDIR=\"/usr/share/vdr\" 
-DPLUGINDIR=\"/usr/lib/vdr/plugins\" -DLOCDIR=\"/usr/share/locale\" 
-I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16   -o 
eitscan.o eitscan.c
| eit.c: In constructor ‘cTDT::cTDT(const u_char*)’:
| eit.c:394:13: error: ‘stime’ was not declared in this scope; did you mean 
‘ctime’?
|   394 | if (stime() == 0)
|   | ^
|   | ctime
| make[2]: *** [Makefile:135: eit.o] Error 1
| make[2]: *** Waiting for unfinished jobs
| make[2]: Leaving directory '/<>'
| dh_auto_build: error: make -j4 "INSTALL=install --strip-program=true" 
PREFIX=/usr VIDEODIR=/var/lib/video LIBDIR=/usr/lib/vdr/plugins SDNOTIFY=1 
VERBOSE=1 returned exit code 2
| make[1]: *** [debian/rules:17: override_dh_auto_build] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:14: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

The full build log is available there:
http://qa-logs.debian.net/2020/06/24/vdr_2.4.1-4_unstable_glibc-exp.log

The stime function has been marked as obsolete for some time, and since
glibc 2.31 it is no longer available to newly linked binaries. The
clock_settime function should be used instead.

You will find attached a patch fixing that. It would be nice if it can
be fixed relatively soon so that we can start the transition.

Regards,
Aurelien
diff -Nru vdr-2.4.1/debian/patches/glibc-stime.patch 
vdr-2.4.1/debian/patches/glibc-stime.patch
--- vdr-2.4.1/debian/patches/glibc-stime.patch  1970-01-01 00:00:00.0 
+
+++ vdr-2.4.1/debian/patches/glibc-stime.patch  2020-07-03 18:47:22.0 
+
@@ -0,0 +1,15 @@
+The obsolete function stime is no longer available to newly linked binaries
+since glibc 2.31. Replace it by clock_settime.
+
+--- a/eit.c
 b/eit.c
+@@ -391,7 +391,8 @@ cTDT::cTDT(const u_char *Data)
+   if (abs(diff) > MAX_TIME_DIFF) {
+  mutex.Lock();
+  if (abs(diff) > MAX_ADJ_DIFF) {
+-if (stime() == 0)
++struct timespec ts = { .tv_sec = dvbtim };
++if (clock_settime(CLOCK_REALTIME, ) == 0)
+isyslog("system time changed from %s (%ld) to %s (%ld)", 
*TimeToString(loctim), loctim, *TimeToString(dvbtim), dvbtim);
+ else
+esyslog("ERROR while setting system time: %m");
diff -Nru vdr-2.4.1/debian/patches/series vdr-2.4.1/debian/patches/series
--- vdr-2.4.1/debian/patches/series 2019-11-01 12:11:11.0 +
+++ vdr-2.4.1/debian/patches/series 2020-07-03 18:45:29.0 +
@@ -6,3 +6,4 @@
 allow-verbose-libsi-build.patch
 use-cpp-flags.patch
 configurable-pkg-config.patch
+glibc-stime.patch

Bug#929272: nmap-common: executable distributed in nmap-common detected as malware

[Samuel Henrique]

I just realized I accidentally triggered this issue because I enabled
some hardening flags for this executable on the last upload (in
testing and sid right now):

https://salsa.debian.org/pkg-security-team/nmap/-/commit/e8002cd93757bb8e579821da032beac10245dd05

This change caused the binary to end up with a different signature and
it skipped the AVs allowlist.

Looking at nmap changelog, it seems like this issue has been going
back and forth[0] and had stabilized after some point (I guess that's
when most AV vendors added the signature), this means that any changes
in the compilation might trigger the issue again.

Hilko, do you have any thoughts on this?

It was suggested by Dom to move this file to another package and make
nmap Suggests it, I'm inclined towards this solution but haven't
investigated the impacts yet.

[0] 
https://github.com/nmap/nmap/blob/b41c39ea78ac9337a741fd942ef3df3a0dea3156/CHANGELOG#L6911-L6916

--
Samuel Henrique 

Bug#963939: lintian: breakout-link wrongly reported against jar files

[Chris Lamb]

Felix Lechner wrote:

> > I don't think this warning applies to architecture independent jar files.
> 
> After speaking with others about these links, I am not sure our
> existing fix is appropriate. I think it should be reverted until we
> hear from Emmanuel.

Please go ahead.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#964188: chromium: crashes & system crashes after security update to v83

[D]

Package: chromium
Version: 83.0.4103.116-1~deb10u1
Followup-For: Bug #964188

Dear Maintainer,

Had to downgrade from version 83.0.4103.116-1~deb10u1 back to version
80.0.3987.162-1~deb10u1.
Initially highly frequent Chromium crashes, hanging & very slowed down. Now
it's causing system to crash.

Downgrading to previous version has resolved issue, very fast, no crashes.


-- 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:es (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+4
ii  xdg-utils  1.1.3-1+deb10u1

Versions of packages chromium-common recommends:
ii  chromium-sandbox80.0.3987.162-1~deb10u1
ii  fonts-liberation1:1.07.4-9
ii  libgl1-mesa-dri 18.3.6-2+deb10u1
ii  libu2f-udev 1.1.9-1
ii  notification-daemon 3.20.0-4
ii  plasma-workspace [notification-daemon]  4:5.14.5.1-1
ii  upower  0.99.10-1

Versions of packages chromium-sandbox depends on:
ii  libatomic1  8.3.0-6
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libstdc++6  8.3.0-6

Bug#964215: libwolfssl-dev: #warning "For timing resistance / side-channel attack prevention consider using harden options"

[Thorsten Glaser]

severity 964215 wishlist
retitle 964215 libwolfssl-dev: no in-package documentation about necessary 
extra steps
thanks

Felix Lechner dixit:

>> I did consult the Debian-packaged README, but it
>> had no such thing,
>
>The instructions for the OpenSSL layer are not Debian-specific, but I
>will add a note to the README.Debian to bridge the documentation gap.

Thanks. In the meanwhile, I added it.

>> and the code compiles without it.
>
>Sounds like the compatibility layer had everything you needed. I am
>glad to hear it. Which package is it, please?

I’m packaging polyphone (SoundFont editor) from scratch.
We’ll see whether it suffices. It at least implements all needed
functions, and its licence is compatible by Debian standards.

>> Why, if this file is so important, is it not automatically included?
>
>I have asked myself that, as well. Maybe there is a technical reason,
>or maybe the authors would like people to use the native interface.

The native interface seems to want them as well.

>Either way, the library works great once you get over the small
>hurdle!

Great to see that.

>Please feel free to close this bug.

Might wish to keep it open until there’s sufficient documentation
in the package itself. If you disagree, close it, no complains.

Thanks,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.

Bug#919619: NM 1.24.0 now has basic support for hidden networks with iwd backend

[Michael Biebl]

Hi,

On Tue, 26 May 2020 13:10:27 +0200 Andreas Henriksson 
wrote:
> Just wanted to drop a comment about the iwd status in NM.
> NM has since 1.24.0, which is now in testing/unstable, basic
> support for connecting to a hidden network using the iwd backend.
> 
> There are still many minor bugs remaining in the NM iwd backend
> both for hidden and any other network. Examples that comes to mind:
> - Removing a connection in NM doesn't seem to propagate
>   to iwd known-network list.
> - NM and iwd sometimes gets out of sync for unknown reasons,
>   stopping iwd and restarting NetworkManager then browsing menues
>   to trigger dbus activation of iwd again can be used as a workaround.
> - nmcli errors out on trying to scan (for a hidden network!) even when
>   specifying 'hidden yes' on the command line. (Working method to
>   provision a hidden network includes using the "Connect to hidden
>   network..." menu entry in gnome-control-center Wi-Fi pane.)
> - and more...
> 
> Many minor workaroundable issues that needs more polish.
> Unfortunately it doesn't seem like anyone is working on improving
> the NM iwd backend since quite a while now (except for my basic hidden
> network contribution, which was a one-off for personal needs).

That sounds a bit like the iwd is only semi-maintained in NM which makes
me a bit uncomfortable tbh. What also concerns me a bit is, that ttbomk
we don't have an automatic fallback to iwd.
Say I switch the dependency to wpasupplicant | iwd, wpasupplicant is
removed. NM is not automatically using iwd without explicit
configuration? Is that correct?

Michael



signature.asc
Description: OpenPGP digital signature

Bug#963939: lintian: breakout-link wrongly reported against jar files

[Felix Lechner]

Hi Chris,

> I don't think this warning applies to architecture independent jar files.

After speaking with others about these links, I am not sure our
existing fix is appropriate. I think it should be reverted until we
hear from Emmanuel.

Kind regards
Felix Lechner

Bug#964215: libwolfssl-dev: #warning "For timing resistance / side-channel attack prevention consider using harden options"

[Felix Lechner]

Hi Thorsten,

On Fri, Jul 3, 2020 at 12:14 PM Thorsten Glaser  wrote:
>
> I did consult the Debian-packaged README, but it
> had no such thing,

The instructions for the OpenSSL layer are not Debian-specific, but I
will add a note to the README.Debian to bridge the documentation gap.

> and the code compiles without it.

Sounds like the compatibility layer had everything you needed. I am
glad to hear it. Which package is it, please?

> Why, if this file is so important, is it not automatically included?

I have asked myself that, as well. Maybe there is a technical reason,
or maybe the authors would like people to use the native interface.
Either way, the library works great once you get over the small
hurdle!

Please feel free to close this bug.

Kind regards
Felix Lechner

Bug#964167: Chromium heavily loads the processor and crashes

[Cameron H]

Another one here, same bug as of this morning after the upgrade to 83. Very 
high CPU load, even for loading a page like Craigslist. Very clunky response 
times all around. No crashes yet.

Bug#942754: ITP: volatility3 -- advanced memory forensics framework

[Eriberto Mota]

retitle 942754 RFS: volatility3 -- advanced memory forensics framework
noowner 942754
stop


The volatility3 project needs some unlicensed and giant files. I am not sure
if it is DFSG. I am dropping it.

Eriberto

Bug#947684: ITP: treezy -- Swiss army knife for working with directory and file trees

[Eriberto Mota]

retitle 947684 RFS: treezy -- Swiss army knife for working with directory and 
file trees
noowner 947684
stop


The treezy project didn't take off. I am converting my ITP to an RFS.

Eriberto

Bug#964215: libwolfssl-dev: #warning "For timing resistance / side-channel attack prevention consider using harden options"

[Thorsten Glaser]

Felix Lechner dixit:

>Did you '#include ' in each file before using the
>OpenSSL compatibility headers as described in the instructions? [1]

No, of course not. I did consult the Debian-packaged README, but it
had no such thing, and the code compiles without it.

Why, if this file is so important, is it not automatically included?

bye,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

Bug#964218: node-yarnpkg: autopkgtest fails with node-uuid 8.2 from experimental - "Cannot read property 'v4' of undefined"

[Pirate Praveen]

Package: node-yarnpkg
Version: 1.22.4-3
Severity: important

Full build log is attached. This was run in a clean and uptodate lxc 
container using salsa.debian.org/ruby-team/meta/build script.



autopkgtest [18:26:50]: version 5.10
autopkgtest [18:26:50]: host ilvala2; command line: /usr/bin/autopkgtest --user debci --apt-upgrade --log-file=/tmp/node-uuid_8.2.0-1_amd64.Ix8K1VsEM6/autopkgtest/node-yarnpkg.log /home/pravi/forge/js-team/build-area/node-node-uuid_8.2.0-1_all.deb /home/pravi/forge/js-team/build-area/node-uuid_8.2.0-1_all.deb node-yarnpkg -- lxc --sudo autopkgtest-unstable-amd64
autopkgtest [18:27:02]:  test bed setup
Hit:1 http://deb.debian.org/debian unstable InRelease
Hit:2 http://incoming.debian.org/debian-buildd buildd-unstable InRelease
Hit:3 http://deb.debian.org/debian-debug unstable-debug InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
autopkgtest [18:27:05]: testbed dpkg architecture: amd64
autopkgtest [18:27:05]: testbed running kernel: Linux 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07)
autopkgtest [18:27:06]:  apt-source node-yarnpkg
Get:1 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (dsc) [7,508 B]
Get:2 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [6,144 B]
Get:3 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [2,652 B]
Get:4 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [7,888 B]
Get:5 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [2,432 B]
Get:6 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [14.8 kB]
Get:7 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [1,756 B]
Get:8 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [1,440 B]
Get:9 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [2,100 B]
Get:10 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [4,780 B]
Get:11 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [4,604 B]
Get:12 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [2,936 B]
Get:13 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [6,780 B]
Get:14 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [28.0 kB]
Get:15 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [3,212 B]
Get:16 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [6,864 B]
Get:17 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [5,516 B]
Get:18 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (tar) [72.9 MB]
Get:19 http://deb.debian.org/debian unstable/main node-yarnpkg 1.22.4-3 (diff) [12.1 kB]
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/debci/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made Sat 02 May 2020 07:38:13 AM UTC
gpgv:using RSA key D30863E26020E543F4719A838F53E0193B294B75
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./node-yarnpkg_1.22.4-3.dsc
tar: Ignoring unknown extended header keyword 'NODETAR.depth'
tar: Ignoring unknown extended header keyword 'NODETAR.follow'
tar: Ignoring unknown extended header keyword 'NODETAR.ignoreFiles.0'
tar: Ignoring unknown extended header keyword 'NODETAR.ignoreFiles.1'
tar: Ignoring unknown extended header keyword 'NODETAR.ignoreFiles.2'
tar: Ignoring unknown extended header keyword 'NODETAR.package.name'
tar: Ignoring unknown extended header keyword 'NODETAR.package.version'
tar: Ignoring unknown extended header keyword 'NODETAR.package.description'
tar: Ignoring unknown extended header keyword 'NODETAR.package.keywords.0'
tar: Ignoring unknown extended header keyword 'NODETAR.package.keywords.1'
tar: Ignoring unknown extended header keyword 'NODETAR.package.license'
tar: Ignoring unknown extended header keyword 'NODETAR.package.author'
tar: Ignoring unknown extended header keyword 'NODETAR.package.files.0'
tar: Ignoring unknown extended header keyword 'NODETAR.package.main'
tar: Ignoring unknown extended header keyword 'NODETAR.package.repository'
tar: Ignoring unknown extended header keyword 'NODETAR.package.scripts.test'
tar: Ignoring unknown extended header keyword 'NODETAR.package.dependencies.babel-plugin-transform-strict-mode'
tar: Ignoring unknown extended header keyword 'NODETAR.package.dependencies.builtin-modules'
tar: Ignoring unknown extended header keyword 'NODETAR.package.devDependencies.babel-core'
tar: Ignoring unknown extended header keyword 'NODETAR.package.devDependencies.babel-plugin-check-es2015-constants'
tar: Ignoring unknown extended header keyword 'NODETAR.package.devDependencies.babel-plugin-external-helpers'
tar: 

Bug#963703: gnutls28 3.5.8-5+deb9u5 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 963703 = stretch pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: gnutls28
Version: 3.5.8-5+deb9u5

Explanation: fix memory corruption issue [CVE-2019-3829]; fix memory leak; add 
support for zero length session tickets, fix connection errors on TLS1.2 
sessions to some hosting providers

Bug#963614: nfs-utils 1.3.4-2.1+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 963614 = stretch pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: nfs-utils
Version: 1.3.4-2.1+deb9u1

Explanation: fix potential file overwrite vulnerability [CVE-2019-3689]; don't 
make all of /var/lib/nfs owned by the statd user

Bug#963693: libexif 0.6.21-2+deb9u4 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 963693 = stretch pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libexif
Version: 0.6.21-2+deb9u4

Explanation: fix a buffer read overflow [CVE-2020-0182] and an unsigned integer 
overflow [CVE-2020-0198]

Bug#964215: libwolfssl-dev: #warning "For timing resistance / side-channel attack prevention consider using harden options"

[Felix Lechner]

Hi Thorsten,

On Fri, Jul 3, 2020 at 11:21 AM Thorsten Glaser  wrote:
>
> Just using the library (as OpenSSL drop-in for licence compliance
> in Debian terms) produces the following warning:

Did you '#include ' in each file before using the
OpenSSL compatibility headers as described in the instructions? [1]

I know the manual is not that clear, but it works for me every time. I
can also help with porting, if needed.

Kind regards
Felix Lechner

[1] https://www.wolfssl.com/docs/wolfssl-manual/ch13/

Bug#964185: freetype2.pc depends on libbrotlidec.pc without a dependency on the libbrotli-dev package

[Michael Tokarev]

On Fri, 03 Jul 2020 18:45:07 +0900 Mike Hommey  
wrote:
..
> Arguably, freetype2.pc shouldn't depend on libbrotlidec.pc except with a
> Required.private, assuming one doesn't actually need to include
> libbrotli headers or link against libbrotli library (presumably, that's
> the case).

The thing is that libbrotli *is* in Requires.private, and pkg-config still
insists on it to exist.

Current (buggy) version:

$ cat /usr/lib/x86_64-linux-gnu/pkgconfig/freetype2.pc
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib/x86_64-linux-gnu
includedir=/usr/include

Name: FreeType 2
URL: https://freetype.org
Description: A free, high-quality, and portable font engine.
Version: 23.2.17
Requires:
Requires.private: zlib, libpng, libbrotlidec
Libs: -L${libdir} -lfreetype
Libs.private:
Cflags: -I${includedir}/freetype2
$ _

As you can see, libbrotlidec is in Requires.private.
Should pkgconfig skip this?

/mjt

Bug#963205: Next round

[Sebastian Ramacher]

Hi Thomas

On 2020-07-03 09:47:34 +0200, Thomas Orgis wrote:
> I made a new snapshot now. The old one still had a conflict of off_t
> and lfs_alias_t in the suffix-less prototype. I hope this does it!
> 
>   https://mpg123.org/snapshot
> 
> Verify?

Build on both amd64 and i386 and the difference in the headers is gone.
Thanks

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#964215: libwolfssl-dev: #warning "For timing resistance / side-channel attack prevention consider using harden options"

[Thorsten Glaser]

Package: libwolfssl-dev
Version: 4.4.0+dfsg-5
Severity: normal

Just using the library (as OpenSSL drop-in for licence compliance
in Debian terms) produces the following warning:

In file included from /usr/include/wolfssl/openssl/bn.h:33,
 from /usr/include/wolfssl/openssl/rsa.h:28,
 from core/utils.cpp:28:
/usr/include/wolfssl/wolfcrypt/settings.h:2060:14: warning: #warning "For 
timing resistance / side-channel attack prevention consider using harden 
options" [-Wcpp]
 2060 | #warning "For timing resistance / side-channel attack 
prevention consider using harden options"
  |  ^~~


Why is hardening not enabled?

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

Kernel: Linux 5.6.0-2-amd64 (SMP w/2 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/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libwolfssl-dev depends on:
pn  libwolfssl24  

libwolfssl-dev recommends no packages.

libwolfssl-dev suggests no packages.

Bug#963548: Apparently resolved in 83.0.4103.106-2

[Felipe Sologuren]

On Wed, 1 Jul 2020 18:09:10 -0400 Felipe Sologuren 
wrote:
> Hello,
>Today I had 81.0.4044.92-1 installed, update ffmpeg: amd64 (7: 4.2.2-1
+
> b1, 7: 4.3-2) and the error appeared.
>After updating Chrome to 83.0.4103.106-2, the problem disappeared.
> Thank you.

Hello,
   Sorry, chromium 83.0.4103.106-2 is still crashing. Much less frequently,
but the browser exits completely.
   Attached an extract from .xsession-errors. I can't complete backtrace
right now.

Thank you.
Received signal 11 SEGV_MAPERR 7f01a8a79cc7
#0 0x55be3e2c0c69 (/usr/lib/chromium/chromium+0x52b3c68)
#1 0x55be3e21fef3 (/usr/lib/chromium/chromium+0x5212ef2)
#2 0x55be3e2c07f1 (/usr/lib/chromium/chromium+0x52b37f0)
#3 0x7f06d48c9110 (/lib/x86_64-linux-gnu/libpthread-2.30.so+0x1410f)
#4 0x7f06cf9b3d3c (/lib/x86_64-linux-gnu/libc-2.30.so+0x85d3b)
#5 0x7f06cf9b5f33 (/lib/x86_64-linux-gnu/libc-2.30.so+0x87f32)
#6 0x7f06cf9b7bf9 __libc_malloc
#7 0x55be3e2d89be operator new()
#8 0x7f06cfc3ea2c std::__cxx11::basic_string<>::reserve()
#9 0x7f06cfc34498 std::__cxx11::basic_stringbuf<>::overflow()
#10 0x7f06cfc3d04a std::basic_streambuf<>::xsputn()
#11 0x7f06cfc2f714 std::__ostream_insert<>()
#12 0x55be3e2c0d39 (/usr/lib/chromium/chromium+0x52b3d38)
#13 0x55be3e2c1054 (/usr/lib/chromium/chromium+0x52b4053)
#14 0x55be3e232412 (/usr/lib/chromium/chromium+0x5225411)
#15 0x55be3e234548 (/usr/lib/chromium/chromium+0x5227547)
#16 0x55be3c97a12a (/usr/lib/chromium/chromium+0x396d129)
#17 0x55be3c97a17e (/usr/lib/chromium/chromium+0x396d17d)
#18 0x55be3bfcf387 (/usr/lib/chromium/chromium+0x2fc2386)
#19 0x55be3c9333d9 (/usr/lib/chromium/chromium+0x39263d8)
#20 0x55be3c93361e (/usr/lib/chromium/chromium+0x392661d)
#21 0x55be3c97d967 (/usr/lib/chromium/chromium+0x3970966)
#22 0x55be3c9a94c7 (/usr/lib/chromium/chromium+0x399c4c6)
#23 0x55be3c9a977e (/usr/lib/chromium/chromium+0x399c77d)
#24 0x55be3c97a13f (/usr/lib/chromium/chromium+0x396d13e)
#25 0x55be3c97a17e (/usr/lib/chromium/chromium+0x396d17d)
#26 0x55be3bfcf387 (/usr/lib/chromium/chromium+0x2fc2386)
#27 0x55be3c2927a3 (/usr/lib/chromium/chromium+0x32857a2)
#28 0x55be3c6010bc (/usr/lib/chromium/chromium+0x35f40bb)
#29 0x55be3e3f245f (/usr/lib/chromium/chromium+0x53e545e)
#30 0x55be3e3f8a24 (/usr/lib/chromium/chromium+0x53eba23)
#31 0x55be3e3f6b62 (/usr/lib/chromium/chromium+0x53e9b61)
#32 0x55be3e3f582d (/usr/lib/chromium/chromium+0x53e882c)
#33 0x55be3e3ee213 (/usr/lib/chromium/chromium+0x53e1212)
#34 0x55be3e409abb (/usr/lib/chromium/chromium+0x53fcaba)
#35 0x55be3e409de0 (/usr/lib/chromium/chromium+0x53fcddf)
#36 0x55be3e409370 (/usr/lib/chromium/chromium+0x53fc36f)
#37 0x55be3c27bc46 (/usr/lib/chromium/chromium+0x326ec45)
#38 0x55be3c27b76c (/usr/lib/chromium/chromium+0x326e76b)
#39 0x55be3c277eed (/usr/lib/chromium/chromium+0x326aeec)
#40 0x55be3c26e74b (/usr/lib/chromium/chromium+0x326174a)
#41 0x55be3c261044 (/usr/lib/chromium/chromium+0x3254043)
#42 0x55be3c260d75 (/usr/lib/chromium/chromium+0x3253d74)
#43 0x55be3c27f426 (/usr/lib/chromium/chromium+0x3272425)
#44 0x55be3e2de0e0 (/usr/lib/chromium/chromium+0x52d10df)
#45 0x7f06d367eb0f (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.7.0.0+0x23b0e)
#46 0x7f06d367f24f event_base_loop
#47 0x55be3e2de38e (/usr/lib/chromium/chromium+0x52d138d)
#48 0x55be3e27e5d5 (/usr/lib/chromium/chromium+0x52715d4)
#49 0x55be3e256670 (/usr/lib/chromium/chromium+0x524966f)
#50 0x55be3c59c3b3 (/usr/lib/chromium/chromium+0x358f3b2)
#51 0x55be3e2942a9 (/usr/lib/chromium/chromium+0x52872a8)
#52 0x55be3e2d0c9e (/usr/lib/chromium/chromium+0x52c3c9d)
#53 0x7f06d48bdf27 start_thread
#54 0x7f06cfa2b31f clone
  r8: 0077  r9: 0050 r10: 0006 r11: 007c
 r12: 7f06a820 r13: 7f06a830 r14: 7f06a8622420 r15: 0080
  di: 0021  si: 0004  bp: 0020  bx: 7f01a8a79cbf
  dx: 7f06a880  ax: 7f06a8b18700  cx: 7f01a8a79cbf  sp: 7f06c525d440
  ip: 7f06cf9b3d3c efl: 00010202 cgf: 002b0033 erf: 0004
 trp: 000e msk:  cr2: 7f01a8a79cc7
[end of stack trace]
Calling _exit(1). Core file will not be generated.

Bug#930374: node-url-parse 1.0.5-2+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 930374 = stretch pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: node-url-parse
Version: 1.0.5-2+deb9u1

Explanation: sanitize paths and hosts before parsing [CVE-2018-3774]

Bug#912531: exiv2 0.25-3.1+deb9u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 912531 = stretch pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: exiv2
Version: 0.25-3.1+deb9u2

Explanation: fix denial of service issue [CVE-2018-16336]; fix over-restrictive 
fix for CVE-2018-10958 and CVE-2018-10999

Bug#962234: perl 5.24.1-3+deb9u7 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 962234 = stretch pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: perl
Version: 5.24.1-3+deb9u7

Explanation: fix multiple regular expression related security issues 
[CVE-2020-10543 CVE-2020-10878 CVE-2020-12723]

Bug#964214: libdebhelper-perl: dh_auto_configure cannot do out-of-tree builds for qmake buildsystem

[Thorsten Glaser]

Package: libdebhelper-perl
Version: 13.1
Severity: normal

Apparently, dh7 fails to tell qmake the location of the source directory
when attempting an out-of-tree build:


[…]
dpkg-source: info: building polyphone in polyphone_2.2.0+dfsg0-1.dsc
 debian/rules binary
dh binary --sourcedir=sources -B
   dh_update_autotools_config -O--sourcedir=sources -O-B
   dh_autoreconf -O--sourcedir=sources -O-B
   dh_auto_configure -O--sourcedir=sources -O-B
install -d 
/tmp/buildd/polyphone-2.2.0\+dfsg0/debian/.debhelper/generated/_source/home 
/tmp/buildd/polyphone-2.2.0\+dfsg0/debian/.debhelper/generated/_source/xdg-runtime-dir
install -d obj-x86_64-linux-gnu
cd obj-x86_64-linux-gnu && qmake -makefile "QMAKE_CFLAGS_RELEASE=-g -O2 
-fdebug-prefix-map=/tmp/buildd/polyphone-2.2.0+dfsg0=. -fstack-protector-strong 
-Wformat -Werror=format-security  -Wdate-time -D_FORTIFY_SOURCE=2 " 
"QMAKE_CFLAGS_DEBUG=-g -O2 
-fdebug-prefix-map=/tmp/buildd/polyphone-2.2.0+dfsg0=. -fstack-protector-strong 
-Wformat -Werror=format-security  -Wdate-time -D_FORTIFY_SOURCE=2 " 
"QMAKE_CXXFLAGS_RELEASE=-g -O2 
-fdebug-prefix-map=/tmp/buildd/polyphone-2.2.0+dfsg0=. -fstack-protector-strong 
-Wformat -Werror=format-security  -Wdate-time -D_FORTIFY_SOURCE=2 " 
"QMAKE_CXXFLAGS_DEBUG=-g -O2 
-fdebug-prefix-map=/tmp/buildd/polyphone-2.2.0+dfsg0=. -fstack-protector-strong 
-Wformat -Werror=format-security  -Wdate-time -D_FORTIFY_SOURCE=2 " 
"QMAKE_LFLAGS_RELEASE=-Wl,-z,relro -Wl,-z,now -Wl,--as-needed" 
"QMAKE_LFLAGS_DEBUG=-Wl,-z,relro -Wl,-z,now -Wl,--as-needed" QMAKE_STRIP=: 
PREFIX=/usr
Usage: /usr/lib/qt5/bin/qmake [mode] [options] [files]

QMake has two modes, one mode for generating project files based on
[…]


The qmake invocation syntax error message is somewhat misleading,
but looking at the invocation command line it becomes somewhat clearer.

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

Kernel: Linux 5.6.0-2-amd64 (SMP w/2 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/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libdebhelper-perl depends on:
ii  perl  5.30.3-4

libdebhelper-perl recommends no packages.

libdebhelper-perl suggests no packages.

-- no debconf information

Bug#964177: Me Too!

[Boyd Stephen Smith Jr.]

I am also affected by these segfaults since about 24 hours ago.

Can't confirm duplicate of 964167 -- I am not experiencing generally higher 
CPU load.

Please let me know if there is any more information I can provide.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


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

Bug#964213: [Pkg-javascript-devel] Bug#964213: nodejs: FTBFS without internet access

[Jérémy Lal]

Le ven. 3 juil. 2020 à 19:09, Niko Tyni  a écrit :

> Source: nodejs
> Version: 12.18.1~dfsg-1
> Severity: serious
> Tags: ftbfs
>
> This package fails to build on a system without internet access.
>
> From the build log:
>
>   not ok 430 parallel/test-dns-setserver-when-querying
> ---
> duration_ms: 0.137
> severity: fail
> exitcode: 1
> stack: |-
>   assert.js:100
> throw new AssertionError(obj);
> ^
>
>   AssertionError [ERR_ASSERTION]: Missing expected exception.
>   at Object.
> (/<>/test/parallel/test-dns-setserver-when-querying.js:17:12)
>   at Module._compile (internal/modules/cjs/loader.js:1138:30)
>   at Object.Module._extensions..js
> (internal/modules/cjs/loader.js:1158:10)
>   at Module.load (internal/modules/cjs/loader.js:986:32)
>   at Function.Module._load (internal/modules/cjs/loader.js:879:14)
>   at Function.executeUserEntryPoint [as runMain]
> (internal/modules/run_main.js:71:12)
>   at internal/main/run_main_module.js:17:47 {
> generatedMessage: false,
> code: 'ERR_ASSERTION',
> actual: undefined,
> expected: [Object],
> operator: 'throws'
>   }
> ...
>   [...]
> ok 2601 sequential/test-worker-prof
> ---
> duration_ms: 0.332
> ...
>   make[2]: *** [Makefile:510: test-ci-js] Error 1
>   make[2]: Leaving directory '/<>'
>   make[1]: *** [debian/rules:214: override_dh_auto_test-arch] Error 2
>

This is not a bug report that can lead to any kind of resolution. It's
missing:
- environment
- build log
- short explanation of how you came to this

Jérémy

Bug#861182: RFS ete

[Andreas Tille]

On Fri, Jul 03, 2020 at 05:10:32PM +0300, mer...@debian.org wrote:
> On 2020-07-03 13:50, zhao feng wrote:
> > Thanks for your help. I can build the package on buster and bullyseye.
> > Which distribution do you use? I find the version of softwares like
> > python is quite new.
> 
> The package fails to build on clean sid chroot. Most likely some Python
> dependencies are missing from debian/control.

The package at

   https://salsa.debian.org/med-team/python-ete3

builds but is also not finished yet.  I do not remember what had stopped
me from finalising and uploading.  Please checkout and moreover if you
talk next time about "ete packaging repositor" provide a link. :-)

> By the way, packaging of 'ete3' seems to be ongoing in Debian Med team
> as well (adding Andreas in CC):
> https://salsa.debian.org/med-team/python-ete3. I suggest getting in
> touch with them to keep duplicate efforts minimal.

Definitely.  Thanks for spotting.

Kind regards

 Andreas. 

-- 
http://fam-tille.de

Bug#964182: linux-image-5.7.0-1-amd64: more on wifi support

[Thomas]

Package: src:linux
Version: 5.7.6-1
Followup-For: Bug #964182

Interestingly I booted with both wifi automatic connection and an
ethernet cable pluged-in and the system could connect to the AP.


-- Package-specific info:
** Version:
Linux version 5.7.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 
(Debian 9.3.0-14), GNU ld (GNU Binutils for Debian) 2.34) #1 SMP Debian 5.7.6-1 
(2020-06-24)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.7.0-1-amd64 
root=UUID=1f809e6f-2936-4282-bb6c-8804dc40984b ro quiet loglevel=0 
systemd.show_status=auto intel_idle.max_cstate=1 i915.enable_dc=0 
libata.force=noncq

** Tainted: U (64)
 * taint requested by userspace application

** Kernel log:
[0.00] microcode: microcode updated early to revision 0x838, date = 
2019-04-22
[0.00] Linux version 5.7.0-1-amd64 (debian-ker...@lists.debian.org) 
(gcc version 9.3.0 (Debian 9.3.0-14), GNU ld (GNU Binutils for Debian) 2.34) #1 
SMP Debian 5.7.6-1 (2020-06-24)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.7.0-1-amd64 
root=UUID=1f809e6f-2936-4282-bb6c-8804dc40984b ro quiet loglevel=0 
systemd.show_status=auto intel_idle.max_cstate=1 i915.enable_dc=0 
libata.force=noncq
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0006efff] usable
[0.00] BIOS-e820: [mem 0x0006f000-0x0006] ACPI NVS
[0.00] BIOS-e820: [mem 0x0007-0x00085fff] usable
[0.00] BIOS-e820: [mem 0x00086000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x200f] reserved
[0.00] BIOS-e820: [mem 0x2010-0x78588fff] usable
[0.00] BIOS-e820: [mem 0x78589000-0x78788fff] type 20
[0.00] BIOS-e820: [mem 0x78789000-0x79288fff] reserved
[0.00] BIOS-e820: [mem 0x79289000-0x79388fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x79389000-0x793c8fff] ACPI data
[0.00] BIOS-e820: [mem 0x793c9000-0x79ff] usable
[0.00] BIOS-e820: [mem 0xe00f8000-0xe00f8fff] reserved
[0.00] BIOS-e820: [mem 0xfed01000-0xfed01fff] reserved
[0.00] BIOS-e820: [mem 0xffb8-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00017fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.31 by INSYDE Corp.
[0.00] efi:  ACPI 2.0=0x793c8014  ESRT=0x7889cd18  SMBIOS=0x79288000 
[0.00] secureboot: Secure boot could not be determined (mode 0)
[0.00] SMBIOS 2.7 present.
[0.00] DMI: Hewlett-Packard Compaq 15 Notebook PC/2213, BIOS F.16 
04/24/2014
[0.00] tsc: Detected 2166.667 MHz processor
[0.22] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.26] e820: remove [mem 0x000a-0x000f] usable
[0.36] last_pfn = 0x18 max_arch_pfn = 0x4
[0.41] MTRR default type: uncachable
[0.42] MTRR fixed ranges enabled:
[0.45]   0-9 write-back
[0.47]   A-B uncachable
[0.50]   C-F write-protect
[0.51] MTRR variable ranges enabled:
[0.54]   0 base 0FFC0 mask FFFC0 write-protect
[0.56]   1 base 0FFB8 mask 8 uncachable
[0.59]   2 base 0 mask F8000 write-back
[0.61]   3 base 07C00 mask FFC00 uncachable
[0.63]   4 base 07B00 mask FFF00 uncachable
[0.66]   5 base 07AE0 mask FFFE0 uncachable
[0.68]   6 base 1 mask F8000 write-back
[0.69]   7 disabled
[0.000156] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.000261] last_pfn = 0x7a000 max_arch_pfn = 0x4
[0.005866] esrt: Reserving ESRT space from 0x7889cd18 to 
0x7889cd50.
[0.006252] RAMDISK: [mem 0x3409b000-0x36044fff]
[0.006263] ACPI: Early table checksum verification disabled
[0.006268] ACPI: RSDP 0x793C8014 24 (v02 HPQOEM)
[0.006274] ACPI: XSDT 0x793C8120 9C (v01 HPQOEM SLIC-MPC 
0003  0113)
[0.006283] ACPI: FACP 0x793C5000 00010C (v05 HPQOEM SLIC-MPC 
0003 HP   0004)
[0.006292] ACPI: DSDT 0x793B3000 00D48C (v02 HPQOEM SLIC-MPC 
0003 HP   0004)
[0.006299] ACPI: FACS 0x7935 40
[0.006304] ACPI: UEFI 0x793C7000 000236 (v01 HPQOEM INSYDE   
0001 HP   0004)
[0.006310] ACPI: MSDM 0x793C6000 55 (v03 HPQOEM SLIC-MPC 
0001 HP   0004)
[0.006316] ACPI: HPET 0x793C4000 38 (v01 HPQOEM INSYDE   
0003 HP   0004)
[0.006321] ACPI: LPIT 0x793C3000 000104 (v01 

Bug#961377: raspi3-firmware: recent stable update causes non-booting systems

[Gunnar Wolf]

Thorsten Glaser dijo [Fri, Jul 03, 2020 at 04:28:37PM +]:
> Gunnar Wolf, Sun, 24 May 2020 16:03:04 -0500:
> 
> >I will try to build+test+upload this in the next couple of days.
> 
> $ rmadison -u qa raspi3-firmware
>  raspi3-firmware | 1.20161123-2 | stretch/non-free  | source, arm64
>  raspi3-firmware | 1.20190215-1+deb10u3 | buster/non-free   | source, arm64, 
> armel, armhf
>  raspi3-firmware | 1.20200212-1 | bullseye/non-free | arm64, armel, 
> armhf
>  raspi3-firmware | 1.20200212-1 | sid/non-free  | arm64, armel, 
> armhf
> 
> *cough*

Cough indeed!

Thanks for the reminder - I am trying to get some time to fix some
not directly related issues in this package (and failed).

I will try to upload today. I am short on time, but will _surely_ do
an upload by early next week.


signature.asc
Description: PGP signature

Bug#861182: RFS ete

[Andreas Tille]

Hi,

On Tue, Jun 30, 2020 at 12:01:59PM +0300, mer...@debian.org wrote:
> On 2020-06-30 11:56, zhao feng wrote:
> > To access further information about this package, please visit the
> > following URL:
> > 
> >   https://mentors.debian.net/package/ete

I'd love to sponsor any package that is relevant for Debian Med but my
personal policy is to sponsor only from **salsa.debian.org** .  BTW,
there is an ITP for ete (#861182) which was turned into an RFP.  You
should at least claim ownership for this bug and turn it into ITP again.
 
Since the package is clearly in the scope of Debian Med I would like
you to become a member of Debian Med team and maintain the package in
the existing repository[1].

So my suggestion is the following:

   1. I've added zhaofeng to the Debian Med team (guessing its you)
   2. You push all your changes to that repository - feel free to
  be "rude" and change what you consider necessary to change,
  make you also the "Uploader"
   3. You ping me once you consider ready via the mailing list
debian-...@lists.debian.org
   4. I'll welcome you in the Debian Med team and upload the
  package (if Andrius will not beat me in this ;-) )

Does this sound like a good plan to you?

@Andrius: Thanks for keeping me in CC - I would have missed this
otherwise.

Kind regards

  Andreas.


[1] https://salsa.debian.org/med-team/python-ete3

-- 
http://fam-tille.de

Bug#964213: nodejs: FTBFS without internet access

[Niko Tyni]

Source: nodejs
Version: 12.18.1~dfsg-1
Severity: serious
Tags: ftbfs

This package fails to build on a system without internet access.

>From the build log:

  not ok 430 parallel/test-dns-setserver-when-querying
---
duration_ms: 0.137
severity: fail
exitcode: 1
stack: |-
  assert.js:100
throw new AssertionError(obj);
^
  
  AssertionError [ERR_ASSERTION]: Missing expected exception.
  at Object. 
(/<>/test/parallel/test-dns-setserver-when-querying.js:17:12)
  at Module._compile (internal/modules/cjs/loader.js:1138:30)
  at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:1158:10)
  at Module.load (internal/modules/cjs/loader.js:986:32)
  at Function.Module._load (internal/modules/cjs/loader.js:879:14)
  at Function.executeUserEntryPoint [as runMain] 
(internal/modules/run_main.js:71:12)
  at internal/main/run_main_module.js:17:47 {
generatedMessage: false,
code: 'ERR_ASSERTION',
actual: undefined,
expected: [Object],
operator: 'throws'
  }
...
  [...]
ok 2601 sequential/test-worker-prof
---
duration_ms: 0.332
...
  make[2]: *** [Makefile:510: test-ci-js] Error 1
  make[2]: Leaving directory '/<>'
  make[1]: *** [debian/rules:214: override_dh_auto_test-arch] Error 2
 
-- 
Niko Tyni   nt...@debian.org

Bug#964212: net-cpp: FTBFS without internet access

[Niko Tyni]

Source: net-cpp
Version: 2.2.1+dfsg1-4
Severity: serious
Tags: ftbfs

This package fails to build on a system without internet access.
It looks like the build hangs in "http_streaming_client_test".

>From the build log:

  Running tests...
  /usr/bin/ctest --force-new-ctest-process -j1
  Test project /<>/obj-x86_64-linux-gnu
  Start 1: header_test
  1/4 Test #1: header_test ..   Passed0.01 sec
  Start 2: http_client_test
  2/4 Test #2: http_client_test .   Passed4.19 sec
  Start 3: http_streaming_client_test
  E: Build killed with signal TERM after 150 minutes of inactivity
 
-- 
Niko Tyni   nt...@debian.org

Bug#964211: octave-instrument-control: FTBFS without internet access

[Niko Tyni]

Source: octave-instrument-control
Version: 0.5.0-1
Severity: serious
Tags: ftbfs

This package fails to build on a system without internet access.

>From the build log (hopefully I spotted the relevant part):

  [src/tcp/tcp_timeout.cc]
  > /<>/src/tcp/tcp_timeout.cc
  * test
   addr = resolvehost ('gnu.org', 'address');
   a = tcp (addr, 80);
   assert(tcp_timeout(a), -1);
   a.timeout = 2.5;
   assert(tcp_timeout(a), 2500);
   a.timeout = 0;
   assert(tcp_timeout(a), 0);
   a.timeout = -1;
   assert(tcp_timeout(a), -1);
   tcp_close(a);
  ! test failed
  resolvehost: could not lookup IP address
  1 test, 0 passed, 0 known failure, 0 skipped

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

Bug#964209: python-blessed: FTBFS without internet access

[Niko Tyni]

Source: python-blessed
Version: 1.17.6-1
Severity: serious
Tags: ftbfs

This package fails to build on a system without internet access.

>From the build log:

  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 272, in 
build_main
  app = Sphinx(args.sourcedir, args.confdir, args.outputdir,
File "/usr/lib/python3/dist-packages/sphinx/application.py", line 272, in 
__init__
  self._init_builder()
File "/usr/lib/python3/dist-packages/sphinx/application.py", line 328, in 
_init_builder
  self.events.emit('builder-inited')
File "/usr/lib/python3/dist-packages/sphinx/events.py", line 99, in emit
  results.append(callback(self.app, *args))
File "/usr/lib/python3/dist-packages/sphinx/ext/intersphinx.py", line 239, 
in load_mappings
  updated = [f.result() for f in concurrent.futures.as_completed(futures)]
File "/usr/lib/python3/dist-packages/sphinx/ext/intersphinx.py", line 239, 
in 
  updated = [f.result() for f in concurrent.futures.as_completed(futures)]
File "/usr/lib/python3.8/concurrent/futures/_base.py", line 432, in result
  return self.__get_result()
File "/usr/lib/python3.8/concurrent/futures/_base.py", line 388, in 
__get_result
  raise self._exception
File "/usr/lib/python3.8/concurrent/futures/thread.py", line 57, in run
  result = self.fn(*self.args, **self.kwargs)
File "/usr/lib/python3/dist-packages/sphinx/ext/intersphinx.py", line 224, 
in fetch_inventory_group
  logger.warning(__("failed to reach any of the inventories "
File "/usr/lib/python3.8/logging/__init__.py", line 1800, in warning
  self.log(WARNING, msg, *args, **kwargs)
File "/usr/lib/python3/dist-packages/sphinx/util/logging.py", line 124, in 
log
  super().log(level, msg, *args, **kwargs)
File "/usr/lib/python3.8/logging/__init__.py", line 1832, in log
  self.logger.log(level, msg, *args, **kwargs)
File "/usr/lib/python3.8/logging/__init__.py", line 1500, in log
  self._log(level, msg, args, **kwargs)
File "/usr/lib/python3.8/logging/__init__.py", line 1577, in _log
  self.handle(record)
File "/usr/lib/python3.8/logging/__init__.py", line 1587, in handle
  self.callHandlers(record)
File "/usr/lib/python3.8/logging/__init__.py", line 1649, in callHandlers
  hdlr.handle(record)
File "/usr/lib/python3.8/logging/__init__.py", line 946, in handle
  rv = self.filter(record)
File "/usr/lib/python3.8/logging/__init__.py", line 807, in filter
  result = f.filter(record)
File "/usr/lib/python3/dist-packages/sphinx/util/logging.py", line 406, in 
filter
  raise SphinxWarning(message)
  sphinx.errors.SphinxWarning: failed to reach any of the inventories with the 
following issues:
  intersphinx inventory 'https://docs.python.org/3/objects.inv' not fetchable 
due to : 
HTTPSConnectionPool(host='docs.python.org', port=443): Max retries exceeded 
with url: /3/objects.inv (Caused by 
NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary 
failure in name resolution'))
  
  Warning, treated as error:
  failed to reach any of the inventories with the following issues:
  intersphinx inventory 'https://docs.python.org/3/objects.inv' not fetchable 
due to : 
HTTPSConnectionPool(host='docs.python.org', port=443): Max retries exceeded 
with url: /3/objects.inv (Caused by 
NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary 
failure in name resolution'))
  make[1]: *** [debian/rules:13: override_dh_sphinxdoc] Error 2
  make[1]: Leaving directory '/<>'
  make: *** [debian/rules:7: binary] Error 2
 
-- 
Niko Tyni   nt...@debian.org

Bug#964210: octave-nan: FTBFS without internet access

[Niko Tyni]

Source: octave-nan
Version: 3.4.5-2
Severity: serious
Tags: ftbfs

This package fails to build on a system without internet access.

>From the build log:

  [inst/load_fisheriris.m]
  > /<>/inst/load_fisheriris.m
  * test
   load_fisheriris
   assert(all(size(meas)==[150,4]))
   assert(all(size(species)==[150,1]))
  --2020-07-02 22:34:48--  
http://archive.ics.uci.edu/ml/machine-learning-databases/iris/iris.data
  Resolving archive.ics.uci.edu (archive.ics.uci.edu)... failed: Temporary 
failure in name resolution.
  wget: unable to resolve host address ‘archive.ics.uci.edu’
  ! test failed
  fread: invalid stream number = -1
  1 test, 0 passed, 0 known failure, 0 skipped

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

Bug#964208: wsjtx: FTBFS without internet access

[Niko Tyni]

Source: wsjtx
Version: 2.2.1+repack-1
Severity: serious
Tags: ftbfs

This package fails to build on a system without internet access.
I suppose it's xsltproc calling out for external resources or something
like that.

This is probably the cause for the 2.2.2+repack-1 armhf build failure too;
I think the conova buildds only have IPv6 connectivity.

>From the build log:

make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
cd /<>/obj-x86_64-linux-gnu && /usr/bin/cmake -E cmake_depends 
"Unix Makefiles" /<> /<> 
/<>/obj-x86_64-linux-gnu /<>/obj-x86_64-linux-gnu 
/<>/obj-x86_64-linux-gnu/CMakeFiles/wsjt_fort_autogen.dir/DependInfo.cmake
 --color=
a2x: ERROR: "xsltproc" -param man.endnotes.list.enabled 0 -param 
man.endnotes.are.numbered 0 --stringparam callout.graphics 0 --stringparam 
navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 
 "/etc/asciidoc/docbook-xsl/manpage.xsl" 
"/<>/obj-x86_64-linux-gnu/manpages/man/man1/wsjtx.1.xml" returned 
non-zero exit status 5

make[3]: *** [manpages/CMakeFiles/manpages.dir/build.make:73: 
manpages/man/man1/wsjtx.1.gz] Error 1
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:2390: manpages/CMakeFiles/manpages.dir/all] 
Error 2


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

Bug#964207: node-node-rest-client: autopkgtest fails with node-uuid 8.2 in experimental

[Pirate Praveen]

Package: node-node-rest-client
Version: 2.5.0-4
Severity: important

This package's autopkgtest failed with node-uuid 8.2 in experimental 
with error


Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './v1' is not 
defined by "exports" in /usr/share/nodejs/uuid/package.json


Full autopkgtest log (run in a clean lxc container) is attached. The 
severity of this bug will be raised to serious when node-uuid is 
uploaded to unstable.


autopkgtest [17:45:29]: version 5.10
autopkgtest [17:45:29]: host ilvala2; command line: /usr/bin/autopkgtest --user debci --apt-upgrade --log-file=/tmp/node-uuid_8.2.0-1_amd64.xZ6b416lqk/autopkgtest/node-node-rest-client.log /home/pravi/forge/js-team/build-area/node-node-uuid_8.2.0-1_all.deb /home/pravi/forge/js-team/build-area/node-uuid_8.2.0-1_all.deb node-node-rest-client -- lxc --sudo autopkgtest-unstable-amd64
autopkgtest [17:45:44]:  test bed setup
Get:1 http://deb.debian.org/debian unstable InRelease [146 kB]
Get:2 http://deb.debian.org/debian-debug unstable-debug InRelease [42.7 kB]
Get:3 http://deb.debian.org/debian unstable/contrib Sources.diff/Index [27.8 kB]
Get:4 http://deb.debian.org/debian unstable/main Sources.diff/Index [27.9 kB]
Get:5 http://deb.debian.org/debian unstable/contrib amd64 Packages.diff/Index [27.8 kB]
Get:6 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index [27.9 kB]
Get:7 http://deb.debian.org/debian unstable/contrib Sources 2020-07-03-0205.54.pdiff [403 B]
Get:8 http://deb.debian.org/debian unstable/main Sources 2020-07-02-1404.31.pdiff [14.7 kB]
Get:9 http://deb.debian.org/debian unstable/main Sources 2020-07-02-2005.56.pdiff [6,890 B]
Get:10 http://deb.debian.org/debian unstable/main Sources 2020-07-03-0205.54.pdiff [5,060 B]
Get:11 http://deb.debian.org/debian unstable/main Sources 2020-07-03-0807.11.pdiff [9,142 B]
Get:7 http://deb.debian.org/debian unstable/contrib Sources 2020-07-03-0205.54.pdiff [403 B]
Get:11 http://deb.debian.org/debian unstable/main Sources 2020-07-03-0807.11.pdiff [9,142 B]
Get:12 http://deb.debian.org/debian unstable/contrib amd64 Packages 2020-07-02-1404.31.pdiff [212 B]
Get:13 http://deb.debian.org/debian unstable/contrib amd64 Packages 2020-07-03-0205.54.pdiff [563 B]
Get:14 http://deb.debian.org/debian unstable/main amd64 Packages 2020-07-02-1404.31.pdiff [8,049 B]
Get:13 http://deb.debian.org/debian unstable/contrib amd64 Packages 2020-07-03-0205.54.pdiff [563 B]
Get:15 http://deb.debian.org/debian unstable/main amd64 Packages 2020-07-02-2005.56.pdiff [9,235 B]
Get:16 http://deb.debian.org/debian unstable/main amd64 Packages 2020-07-03-0205.54.pdiff [26.6 kB]
Get:17 http://deb.debian.org/debian unstable/main amd64 Packages 2020-07-03-0807.11.pdiff [8,624 B]
Get:17 http://deb.debian.org/debian unstable/main amd64 Packages 2020-07-03-0807.11.pdiff [8,624 B]
Get:18 http://deb.debian.org/debian-debug unstable-debug/main Sources.diff/Index [27.9 kB]
Get:19 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages.diff/Index [27.9 kB]
Get:20 http://incoming.debian.org/debian-buildd buildd-unstable InRelease [39.7 kB]
Get:21 http://deb.debian.org/debian-debug unstable-debug/main Sources 2020-07-02-1404.31.pdiff [5,341 B]
Get:22 http://deb.debian.org/debian-debug unstable-debug/main Sources 2020-07-02-2005.56.pdiff [8,002 B]
Get:23 http://deb.debian.org/debian-debug unstable-debug/main Sources 2020-07-03-0205.54.pdiff [2,158 B]
Get:24 http://deb.debian.org/debian-debug unstable-debug/main Sources 2020-07-03-0807.11.pdiff [6,826 B]
Get:25 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages 2020-07-02-1404.31.pdiff [8,886 B]
Get:24 http://deb.debian.org/debian-debug unstable-debug/main Sources 2020-07-03-0807.11.pdiff [6,826 B]
Get:26 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages 2020-07-02-2005.56.pdiff [25.5 kB]
Get:27 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages 2020-07-03-0205.54.pdiff [11.1 kB]
Get:28 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages 2020-07-03-0807.11.pdiff [6,119 B]
Get:28 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages 2020-07-03-0807.11.pdiff [6,119 B]
Get:29 http://incoming.debian.org/debian-buildd buildd-unstable/main Sources [88.7 kB]
Get:30 http://incoming.debian.org/debian-buildd buildd-unstable/contrib Sources [1,876 B]
Get:31 http://incoming.debian.org/debian-buildd buildd-unstable/contrib amd64 Packages [2,552 B]
Get:32 http://incoming.debian.org/debian-buildd buildd-unstable/main amd64 Packages [118 kB]
Fetched 770 kB in 1s (516 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
  dbus libdbus-1-3
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 454 kB of archives.
After this operation, 2,048 B of additional disk space will be used.
Get:1 http://deb.debian.org/debian 

Bug#778750: theme still broken, problem with directory structure and symlink

[Ivan Sergio Borgonovo]

I've just read more carefully your follow up:


The theming folder in /etc/ also needs to be moved a bit:
/etc/horde/themes-available.d/default ->  
/etc/horde/themes-available.d/default/horde


OK, it was on purpose... but it seems it's not working, at least here.

I'm going to try to do some further tests and see if I'd missed 
something with the cache... but once I "fixed" it as described in 
previous post and refreshed the cache it started to work.


I find very unlikely that both the packaged directory structure and my 
structure can both work, one has to be wrong.



--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net