Bug#910084: tried today running caja either with command-line or under gdb but get the same result.

[shirish शिरीष]

Dear all,

Even when the package itself is updated, the issue is still far from
resolved. Please let me know if anybody has any more ideas.

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

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

Versions of packages caja depends on:
ii  caja-common   1.22.1-1
ii  desktop-file-utils0.24-1
ii  gvfs  1.38.1-5
ii  libatk1.0-0   2.33.3+really2.32.0-4
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libcaja-extension11.22.1-1
ii  libexempi82.5.1-1
ii  libexif12 0.6.21-5.1
ii  libgail-3-0   3.24.10-1
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.60.6-2
ii  libglib2.0-bin2.60.6-2
ii  libglib2.0-data   2.60.6-2
ii  libgtk-3-03.24.10-1
ii  libice6   2:1.0.9-2
ii  libmate-desktop-2-17  1.22.1-1
ii  libnotify40.7.8-1
ii  libpango-1.0-01.42.4-7
ii  libpangocairo-1.0-0   1.42.4-7
ii  libselinux1   2.9-2+b2
ii  libsm62:1.2.3-1
ii  libstartup-notification0  0.12-6
ii  libx11-6  2:1.6.7-1
ii  libxml2   2.9.4+dfsg1-7+b3
ii  mate-desktop  1.22.1-1
ii  shared-mime-info  1.10-1

Versions of packages caja recommends:
ii  gvfs-backends  1.38.1-5

Versions of packages caja suggests:
ii  engrampa1.22.1-1
ii  gstreamer1.0-tools  1.16.0-2.1
ii  meld3.20.0-2

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#936016: meteo-qt crashes immediately

[Judicael Courant]

Package: meteo-qt
Version: 1.0.0-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

My installation of meteo-qt in buster crashes as soon as I start it:

judicael:~$ meteo-qt
ERROR: 6 days forcast not available : HTTP Error 401: Unauthorized - 1858
:meteo_qt
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/meteo_qt/meteo_qt.py", line 1383, in
done
self.overviewcity()
  File "/usr/lib/python3/dist-packages/meteo_qt/meteo_qt.py", line 325, in
overviewcity
rise_str = self.utc('Sunrise', 'weatherdata')
  File "/usr/lib/python3/dist-packages/meteo_qt/meteo_qt.py", line 445, in utc
self.weatherDataDico[rise_set].split('T')[1].split(':')
AttributeError: 'NoneType' object has no attribute 'split'
Abandon
judicael:~$ echo $?
134

(In my locale (French) "Abandon" is the word for "Aborted")

If I remove the config file ~/.config/meteo-qt/meteo-qt.conf, meteo-qt starts
normally
and asks me to provide an API key. If I provide it the wrong one, I can not add
any city:
I get an "Error: 401 Unauthorized" when typing "Paris" in the "Start typing the
city or
the geographic coordinates "latitude, longitude" search box.
If I provide the right one, I can find Paris in that search box, I can select
"Paris, FR", click the OK button in the "Cities" window. I am then back in the
main
parameter window. As soon as I click on "Apply" or "OK", meteo-qt crashes with
the same error
message.

My configuration (API key removed):

--
~$ cat ~/.config/meteo-qt/meteo-qt.conf | sed -e 's/APPID=.*/APPID=/'
[General]
APPID=
CitiesTranslation={}
City=Paris
CityList=['Paris_FR_2988507']
Country=FR
ID=2988507
Proxy=False
Unit=metric

[Logging]
Level=INFO

[SearchCity]
Geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\a\x80\0\0\0\0\0\0\n\xa3\0\0\x1\x35\0\0\a\x82\0\0\0\0\0\0\n\xa1\0\0\x1\x33\0\0\0\x2\0\0\0\0\a\x80)
--

Yours,

J. Courant.




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

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

Versions of packages meteo-qt depends on:
ii  python33.7.3-1
ii  python3-lxml   4.3.2-1
ii  python3-pyqt5  5.11.3+dfsg-1+b3
ii  python3-sip4.19.14+dfsg-2

Versions of packages meteo-qt recommends:
ii  meteo-qt-l10n  1.0.0-1

meteo-qt suggests no packages.

-- no debconf information

Bug#930363: faad2: fix build with gcc-9 [patch]

[Gianfranco Costamagna]

control: severity -1 serious
On Tue, 11 Jun 2019 15:06:01 +0200 Gianfranco Costamagna 
 wrote:
> Source: faad2
> Version: 2.8.8-3
> Severity: normal
> tags: patch
> 
> Hello, looks like gcc-9 is adding wl,asneeded flag in compilation, so libs 
> passed as CFLAGS are not correctly
> used by gcc anymore, because only LIBS is added at the end of the compilation 
> line.
> 
> The following patch fixes the issue, and starts then using again the glib 
> implementation of the library.
> (without the patch, the bundled version is used everywhere, and the build 
> fails only on i386 because of an implementation mismatch of a long/int data 
> type)
> 
> I reported the patch already upstream
> https://sourceforge.net/p/faac/bugs/242/
> 
> 
> patch: 
> http://launchpadlibrarian.net/427773869/faad2_2.8.8-3_2.8.8-3ubuntu1.diff.gz
> 
> 


Now this bug is RC, and preventing CVE fixes from Migration.
Hugo, can you please reupload with the Ubuntu patch?
https://launchpad.net/ubuntu/+source/faad2/2.8.8-3.1ubuntu1
I rebased it with the upstream version

Gianfranco

Bug#936015: ceph: CVE-2019-10222

[Salvatore Bonaccorso]

Source: ceph
Version: 12.2.11+dfsg1-2.1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/ceph/ceph/pull/2996

Hi,

The following vulnerability was published for ceph.

CVE-2019-10222[0]:
unauthenticated clients can crash RGW

For the 12.2.x series this is only triggerable if an experimental
feature is enabled. Thus I think this does not warrant a DSA but would
be potentially nice to have fixed in the next point release.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-10222
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10222
[1] https://github.com/ceph/ceph/pull/2996
[2] https://www.openwall.com/lists/oss-security/2019/08/28/9

Regards,
Salvatore

Bug#936014: dovecot: CVE-2019-11500

[Salvatore Bonaccorso]

Source: dovecot
Version: 1:2.3.4.1-5
Severity: grave
Tags: security upstream
Justification: user security hole
Control: found -1 1:2.2.27-3+deb9u4
Control: found -1 1:2.2.27-3
Control: fixed -1 1:2.2.27-3+deb9u5
Control: fixed -1 1:2.3.4.1-5+deb10u1

Hi,

The following vulnerability was published for dovecot.

CVE-2019-11500[0]:
| Nick Roessler and Rafi Rubin discovered that the IMAP and ManageSieve
| protocol parsers in the Dovecot email server do not properly validate
| input (both pre- and post-login). A remote attacker can take advantage
| of this flaw to trigger out of bounds heap memory writes, leading to
| information leaks or potentially the execution of arbitrary code.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-11500
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11500
[1] https://dovecot.org/pipermail/dovecot-news/2019-August/000418.html

Regards,
Salvatore

Bug#935796: closed

[linuxonlinehelp]

closed

Bug#834331: failed tests work only in GUI

[Changwoo Ryu]

I found that the RH ibus package also disables three tests,
ibus-compose, ibus-keypress and test-stress:

https://src.fedoraproject.org/rpms/ibus/blob/f31/f/ibus.spec#_329

I believe that the failed tests are assumed to be run in a GUI
session. Then they will break buildd and CI. Why not just disable
them?

Bug#936013: console-setup doesn't apply until after root is mounted even when encrypted root is used

[Joshua]

Package: console-setup
Version: 1.191
Severity: normal
Tags: l10n

When installing on an encrypted root filesystem, console-setup doesn't load its 
configuration
until after the encrypted root is mounted; this leads to problems trying to 
mount root.

System for which this report is for is not the system which the report is being 
made on.

Bug#935948: can't start containers with different names but same prefix (xxxxxxxxxxx-1 and xxxxxxxxxxx-2)

[Trent W. Buck]

Michael Biebl wrote:
> Am 28.08.19 um 13:11 schrieb Trent W. Buck:
>
> > If this is an unavoidable limitation due to Linux, please at least
> > warn about it in the systemd-nspawn manpage.
>
> I've forwarded this upstream to
> https://github.com/systemd/systemd/issues/13417 where it was mentioned
> that this topic had already come up and the fix was to document this
> limitation. See
>
> https://github.com/systemd/systemd/pull/11989/commits/6cc68362d529ca8b99fd6ca55b0fc7143e696aea
>
> Have you seen this paragraph in systemd-nspawn?

I missed that somehow.
Probably I was looking at a v241 manpage, which predates that commit.

I agree this ticket can be closed.  Sorry for wasting your time :-(

Bug#936012: pulseaudio: manpage missing

[westlake]

Package: pulseaudio
Version: 12.2-4
Severity: normal

manpage missing for daemon.conf

https://www.debian.org/doc/debian-policy/ch-docs.html#manual-pages
"If no manual page is available, this is considered as a bug and should 
be reported to the Debian Bug Tracking System (the maintainer of the 
package is allowed to write this bug report themselves, if they so 
desire). Do not close the bug report until a proper man page is available. "

Bug#849974: openmpi: not enough slots available

[Drew Parsons]

On 2019-08-29 05:44, Graham Inggs wrote:

I know this is an old bug report, but anyway...


But the ability to oversubscribe doesn't explain the bug here.  Why
does openmpi think only 2 slots are available when in fact 4 
processors

are available?


As per the ark.intel.com page for this CPU [1]:

# of Cores 2
# of Threads 4

So openmpi seems to be (correctly, IMHO) counting cores here, rather
than threads.


[1]
https://ark.intel.com/content/www/us/en/ark/products/88190/intel-core-i5-6300u-processor-3m-cache-up-to-3-00-ghz.html



Ah, of course, that's what Thibaut was saying too.

That makes it a bit awkward if nproc is returning number of threads not 
cores. Heinrich said /proc/cpuinfo reports 4 CPUs.


Drew

Bug#935968: texlive-latex-extra: Font U/esint/m/n/10.95=esint10 at 10.95pt not loadable: Metric (TFM) file not found

[Thorsten Glaser]

Norbert Preining dixit:

>> I just uploaded a corrected version on CTAN. I think it will be soon
>
>Thanks a lot for the quick fix, great!

Thanks from me (affected end user) as well!

Goodnight,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#903161: Same issue here; solution found

[Josh Triplett]

On Wed, Aug 28, 2019 at 05:43:27PM -0700, Josh Triplett wrote:
> So if the stats sockets don't exist at *all*, deliver won't complain.
> 
> To disable those stats sockets, add the following configuration to a
> file in /etc/dovecot/conf.d/ :

Update: sadly this doesn't fully work, as it produces the following
spurious errors in the logs:

Aug 28 17:54:27 cloud dovecot[3168]: imap-login: Error: 
net_connect_unix(/var/run/dovecot/stats-writer) failed: No such file or 
directory
Aug 28 17:54:27 cloud dovecot[3168]: auth: Error: 
net_connect_unix(/var/run/dovecot/stats-writer) failed: No such file or 
directory
Aug 28 17:54:27 cloud dovecot[3168]: auth: Error: stats: open(old-stats-user) 
failed: No such file or directory
Aug 28 17:54:28 cloud dovecot[3168]: auth: Error: 
net_connect_unix(/var/run/dovecot/stats-writer) failed: No such file or 
directory
Aug 28 17:54:28 cloud dovecot[3168]: auth-worker(3182): Error: stats: 
open(old-stats-user) failed: No such file or directory
Aug 28 17:54:28 cloud dovecot[3168]: imap: Error: 
net_connect_unix(/var/run/dovecot/stats-writer) failed: No such file or 
directory

So while deliver has no problem ignoring such errors, the rest of
dovecot unfortunately doesn't like that configuration.

I'd like to have a "disable all stats" configuration, rather than having
to make a stats socket available to the user running deliver.

Bug#903161: Same issue here; solution found

[Josh Triplett]

I ran into a similar issue here, whenever I ran the "deliver" process as
a user to deliver mail into IMAP folders (invoked from getmail).
"deliver" delivered the mail but then produces the error about writing
statistics, so getmail correctly concluded that the process errored.

I don't want to make statistics-writing available to all users. I don't
actually care about the statistics. So I figured out how to disable
statistics.

I found this commit in the changelog:

2017-12-22 13:27:48 +0200 Timo Sirainen  (aa572aa74)

lib-master: Hide connect(stats-writer) errors when running via CLI

Only hide errors that occur if the stats process isn't running, i.e. when
socket isn't found or there's no listener. This way e.g. permission errors
are still logged, which points to a wrong configuration.


So if the stats sockets don't exist at *all*, deliver won't complain.

To disable those stats sockets, add the following configuration to a
file in /etc/dovecot/conf.d/ :

service stats {
  unix_listener stats-reader {
mode = 0
  }
  unix_listener stats-writer {
mode = 0
  }
}

service old-stats {
  fifo_listener old-stats-mail {
mode = 0
  }
  fifo_listener old-stats-user {
mode = 0
  }
  unix_listener old-stats {
mode = 0
  }
}

(Per https://wiki2.dovecot.org/Services , setting mode to 0 disables the
socket entirely.)

Then restart dovecot, and then delete /run/dovecot/stats-* and
/run/dovecot/old-stats-*. You can then run deliver without errors.

Hope that helps.

Bug#936011: pytimechart: should this package be removed?

[Sandro Tosi]

Package: pytimechart
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Hello,
As part of the effort to remove Python 2 from Debian
(https://wiki.debian.org/Python/2Removal) i came across pytimechart; it seems a
very useful tools, but it's still python2-only and there hasnt been a new
upstream release in almost 10 years.

I've looked on github and other source hosting website and there's no version
supporting python3.

I believe we should remove this package.  If i dont hear anything back in 10
days with reasons to keep this around, i'll file a RM bug.

Regards,
Sandro


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

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

Versions of packages pytimechart depends on:
ii  python2.7.16-1
pn  python-chaco  
pn  python-enthoughtbase  
pn  python-fonttools  
ii  python-gtk2   2.24.0-6
ii  python-kiwisolver 1.0.1-2+b1
ii  python-wxgtk3.0   3.0.2.0+dfsg-8

pytimechart recommends no packages.

pytimechart suggests no packages.

Bug#935993: nwchem: NWChem compiled with long int lapack/blas interface?

[Mo Zhou]

Hi Giacomo and nwchem maintainer,

I should provide you some important hints at this point.

> However, lapack and blas libs with 64 bit integer interfaces just appeared
> on debian experimental, and have been available for some time in the 
> non-free (but packaged in non-free) Intel MKL libs.

I forgot to mention in the changelog of src:lapack that CBLAS64 (the
64bit
indexing C interface) is not yet available, while the rest are fine.
Patching work was planned but currently lacks support from upstream.
Currently libraries that provide CBLAS64 ABI are: libblis64-2,
libmkl-rt.

> export BLAS_SIZE=8
> export BLAS_LIB=-lmkl_blas95_ilp64 -Wl,--start-group -lmkl_gf_ilp64 
> -lmkl_intel_thread -lmkl_core -Wl,--end-group 
> ...
> export BLASOPT="-lmkl_blas95_ilp64 -lmkl_lapack95_ilp64 -lmkl_scalapack_ilp64 
> -Wl,--start-group -lmkl_gf_ilp64 > -lmkl_intel_thread -lmkl_core 
> -lmkl_blacs_openmpi_ilp64 -Wl,--end-group -liomp5 -lpthread -lm -ldl"
> export BLACS=$(SCALAPACK)

If nwchem decides to link against MKL, it has to leave the main section.
If nwchem's 64-bit indexing mode doesn't call the CBLAS64 API, you can
go ahead and link the program against src:lapack's libblas64.so and
liblapack64.so . The update-alternatives mechanism will allow you
to switch the backend to MKL at runtime.

Bug#935004: cups-filters: print test page problem solved by upgrading to github version (1.25.1)

[frederik]

You need to change the "deb" line in /etc/apt/sources.list to use the
unstable archive:

 deb http://deb.debian.org/debian/ unstable main contrib non-free

Then 'apt update' followed by 'apt install cups-filters'.

I do not see any benefit in updating the other other packages, but it
should not do any harm.


I think it is not so simple as that on Raspbian, first of all I don't want 
*all* new packages to come from Debian Unstable, so I should have some command 
that specifies this archive is to be used for just one package. Besides, if it 
is true that CUPS doesn't work on Raspbian Buster then that should probably be 
fixed. But again no one else has reported it so maybe it is something on my 
end. FWIW when I ran 'apt update' I got:

W: GPG error: http://deb.debian.org/debian unstable InRelease: The following 
signatures couldn't be verified because the public key is not available: 
NO_PUBKEY 04EE7237B7D453EC NO_PUBKEY 648ACFD622F3D138



Also, is there a reason why you think the new version would fix the
problem? Perhaps since my time is limited and no one else has reported
this bug, we should regard it as a potential misconfiguration, or an
issue that may have arisen from my trying to install and then
uninstall the Github cups-filters package as I explained in my
original report.


Testing is best done with the latest version. You have described your
issue well, but we have little to go on. My inability to reproduce it
on unstable would incline me to close the report.


I don't mind if you close the report.


(The avahi-browse output would still be useful my records).



> > What might also prove useful later on is avahi.log from
> >  avahi-browse -art > avahi.log
> > avahi-browse is in the avahi-utils package.


Thanks for reminding me, I'm attaching the output although I'm not sure why you 
need it. The printer is a USB printer, I thought Avahi was network-related 
(like mDNS and stuff?).


A full error log would be useful. It will compress very well with gzip
before being sent as an attachment.



Would you also do (as root)



 cupsfilter -p /etc/cups/ppd/ -m printer/foo -e 
/usr/share/cups/data/default-testpage.pdf > out.dat
2>log



and post log.


Here's the entire error log after running the above cupsfilter command:

$ less /var/log/cups/error_log
E [28/Aug/2019:23:37:42 +] HP_Photosmart_Plus_B210_series: File 
\"/usr/lib/cups/filter/hpcups\" not available: No such file or directory
E [28/Aug/2019:23:37:42 +] [Job 71] Unknown MIME type 
application/vnd.cups-pdf-banner for file 1.

Note that this file does indeed exist:

$ file /usr/lib/cups/filter/hpcups
/usr/lib/cups/filter/hpcups: ELF 32-bit LSB executable, ARM, EABI5 version 1 
(SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 
3.2.0, BuildID[sha1]=ddd2c08496a0a15afb812660a6a0c6c4fe269f0e, stripped

I've been seeing the error about "File \"/usr/lib/cups/filter/hpcups\" not 
available: No such file or directory" at other times as well, but I couldn't reproduce it so I 
didn't submit a bug.

It was interesting to learn about cupsfilter and avahi-browse, thank you.

Taking a step back, it seems that if CUPS is complaining about 'Unsupported format 
"text/plain"' when the test page is a PDF, and when text/plain is supported, and when the 
actual error has to do with \"/usr/lib/cups/filter/hpcups\" not existing, even though it 
does exist  then I think it might be that we should prioritize getting CUPS to have better 
error reporting, rather than what we are doing.

Thanks,

Frederick


cupsfilter.tar.gz
Description: application/gzip
+   eth0 IPv6 HP Photosmart Plus B210 series @ musa Internet Printer
 local
+   eth0 IPv6 Brother DCP-7065DN @ musa Internet Printer
 local
+   eth0 IPv4 HP Photosmart Plus B210 series @ musa Internet Printer
 local
+   eth0 IPv4 Brother DCP-7065DN @ musa Internet Printer
 local
+   eth0 IPv4 Brother DCP-7065DN @ thutmose Internet Printer
 local
+   eth0 IPv4 HP Photosmart Plus B210 series USB @ thutmose Internet Printer
 local
+   eth0 IPv4 P1102_remote @ thutmose   Internet Printer
 local
+   eth0 IPv4 HP Photosmart Plus B210 series @ thutmose Internet Printer
 local
+   eth0 IPv6 HP Photosmart Plus B210 series @ musa Secure Internet 
Printer local
+   eth0 IPv6 Brother DCP-7065DN @ musa Secure Internet 
Printer local
+   eth0 IPv4 HP Photosmart Plus B210 series @ musa Secure Internet 
Printer local
+   eth0 IPv4 Brother DCP-7065DN @ musa Secure Internet 
Printer local
+   eth0 IPv4 Brother DCP-7065DN @ thutmose Secure Internet 
Printer local
+   eth0 IPv4 HP Photosmart Plus B210 series USB @ thutmose Secure Internet 
Printer local
+   eth0 IPv4 P1102_remote @ thutmose   Secure Internet 
Printer local
+   eth0 IPv4 HP Photosmart Plus B210 series @ 

Bug#936010: rust-pangocairo build-dependencies unsatisfiable

[peter green]

Package: rust-pangocairo
Version: 0.6.0-1
Severity: serious
Tags: sid

According to wanna-build rust-pangocairo's build-dependencies are 
unsatisfiable. It looks like librust-cairo-rs-0.5+default-dev has been replaced 
with librust-cairo-rs-0.7+default-dev .

Bug#935794: xfce4-sntray-plugin FTBFS

[peter green]

It looks like that class was dropped from vala-panel in 
https://gitlab.com/vala-panel-project/vala-panel/commit/87493a6dfab9868f77b7b19b57fca40a06fe80af

Unfortunately the commit message doesn't give any clues to what if-anything it 
should be replaced with.

If a proper fix cannot be found then one option would be to drop the vala-panel 
support from this package. The popcon figures for the vala-panel variant are 
the lowest of any of the variants. 
https://qa.debian.org/popcon.php?package=xfce4-sntray-plugin . I decided to go 
ahead and do that in raspbian for the moment to complete the transition there.

A debdiff should appear soon at 
https://debdiffs.raspbian.org/main/x/xfce4-sntray-plugin . No intent to NMU in 
Debian.

There does seem to be some upstream activity on xfce4-sntray-plugin at 
https://github.com/rilian-la-te/xfce4-sntray-plugin but I can't find anything 
relavent to this issue.

Bug#935128: aspell: potentially unbounded buffer over-read in GNU Aspell 0.60.*

[Kevin Atkinson]

On Thu, 29 Aug 2019, Agustin Martin wrote:


This message is sent to all packages that depend in some way on
libaspell15 (pdo addresses bcc'ed)

A potentially unbounded buffer over-read has been found in in GNU
Aspell 0.60.*. Package aspell 0.60.7-1 has been uploaded to Debian
experimental, including upstream patch to deal with this problem.


It looks like you just applied the patches from Git.  This will not work with 
a release as Aspell uses a lot of generated source files which are not checked 
into git.  You need to run 'maintainer/autogen' to update them after applying 
the patch. Assuming the normal Debian build process rebuilds the automake/conf 
related bits then you can likely get away with just doing a:


  cd auto/
  perl -I ./ mk-src.pl
  perl -I ./ mk-doc.pl
  touch auto
  cd ..

There are some tests in test/.  There not very expensive and will make sure 
that that Aspell is correctly patched with the new interface intended for 
working with wide-characters  You should be able to run the tests by doing a


  make -C test

The tests are completely independent of the normal build process.  The build 
process reconfigures and rebuilds aspell into test/build and installs it 
locally into test/inst.  It does configure with --enable-maintainer-mode so it 
might update some files in the source directory.  If that is a problem you can 
easily patch the Makefile beforehand.  I can also fix that upstream to make 
it easier to disable.


Kevin
(Aspell Maintainer)

Bug#936009: shim-unsigned:amd64 cannot be installed alongside shim-unsigned:i386

[adrian15 adrian15]

Package: shim-unsigned
Version: 15+1533136590.3beb971-7
Severity: normal

Dear Maintainer,

I want to be able to build a live cd that has both ia32 and x64 Secure
Boot UEFI support.
So I need both shim-signed:amd64 and shim-signed:i386 installed.

Those two packages depend on shim-unsigned:amd64 and shim-unsigned:i386
among other packages.
I cannot install those unsigned packages hence neither I can install the
signed ones.

After adding and apt i386 architecture to an amd64 system if I run:

apt-get install shim-unsigned:amd64 shim-unsigned:i386

I get this output:


Reading package lists... Done
Building dependency tree
Reading state information... Done
shim-unsigned is already the newest version (15+1533136590.3beb971-7).
shim-unsigned set to manually installed.
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 shim-unsigned : Conflicts: shim-unsigned:i386 but 15+1533136590.3beb971-7
is to be installed
 shim-unsigned:i386 : Conflicts: shim-unsigned but 15+1533136590.3beb971-7
is to be installed
E: Unable to correct problems, you have held broken packages.


I would like to be able to install both packages at the same time
because generated binaries do not collide between them.

It would seem those packages are lacking some multi-arch declaration on
the package metadata.

This same problem was fixed for shim-signed on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928486 and fixed there.
Associated commit to that fix:
https://salsa.debian.org/efi-team/shim-signed/commit/f3393e69ed073007cda61d57c60e5c907c4faf51
.

I suspect that shim-helpers-amd64-signed and shim-helpers-i386-signed
packages will need a similar workaround but I'm not sure on this one.


Thank you very much!

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

-- no debconf information

Bug#935968: texlive-latex-extra: Font U/esint/m/n/10.95=esint10 at 10.95pt not loadable: Metric (TFM) file not found

[Norbert Preining]

Hi Eddie,

> I just uploaded a corrected version on CTAN. I think it will be soon

Thanks a lot for the quick fix, great!

> available. The cause of this problem is the automatic corrector of my
> editor...

Yes, I suspected the same ... but I am used to this on Android with
swipe input, not from editors.

Thanks

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#936008: jigl: "rotate" bails out with "if: Expression Syntax." if multiple files are passed as parameter

[Axel Beckert]

Package: jigl
Version: 2.0.1+20060126-5
File: /usr/bin/rotate

"rotate -h" states:


 rotate [[-f|-flip|--flip] [horizontal | vertical]
 [-r|-rotate|--rotate] [90 | 180 | 270] 
 [-tp|-transpose|--transpose]
 [-tv|-transverse|--transverse]]
 files

 Options:
 ---
 […]

 files
  The files you want to rotate. Wildcards are acceptable.


rotate(1) states:


SYNOPSIS
   rotate { options } file [ file ... ]


Note that in both cases, multiple files as parameter are explicitly
documented.

Nevertheless if you pass more than one file on the command line, rotate
errors out (independent of /usr/bin/csh being the real csh or the tcsh):


→ rotate -r 90 DSCN4743.JPG DSCN4744.JPG
if: Expression Syntax.


This happens at least on Debian 9 Stretch and Debian Sid/Bullseye as of
this writing.

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages jigl depends on:
ii  imagemagick  8:6.9.10.23+dfsg-2.1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
ii  jhead1:3.03-3
ii  perl 5.28.1-6

Versions of packages jigl recommends:
ii  csh [c-shell]20110502-4+b1
ii  libjpeg-turbo-progs [libjpeg-progs]  1:1.5.2-2+b1
ii  tcsh [c-shell]   6.21.00-1

jigl suggests no packages.

-- no debconf information

Bug#935980: jackd2: Segfaults when qjackctl patchbay is activated

[Bernhard Übelacker]

Dear Maintainer,
I tried to reproduce the issue, but unfortunately I
receive no segmentation fault, instead a floating point exception.
(By using the button with the play symbol at the middle bottom.)

This happens there because the divisor frame_rate is zero.
For this issue I could not find an upstream bugreport or even patch.

Kind regards,
Bernhard


(gdb) bt
#0  Jack::JackTransportEngine::SyncTimeout (this=this@entry=0x7f6fbf12b140, 
frame_rate=frame_rate@entry=0, buffer_size=buffer_size@entry=0) at 
../common/JackTransportEngine.cpp:54
#1  0x7f6fbeeca382 in Jack::JackTransportEngine::CycleEnd 
(this=0x7f6fbf12b140, table=table@entry=0x56138aad5708, frame_rate=0, 
buffer_size=0) at ../common/JackTransportEngine.cpp:221
#2  0x7f6fbeedacbd in Jack::JackEngineControl::CycleEnd 
(table=0x56138aad5708, this=) at 
../common/JackEngineControl.h:160
#3  Jack::JackEngine::Process (this=0x56138aad56c0, cur_cycle_begin=1105829020, 
prev_cycle_end=1104805827) at ../common/JackEngine.cpp:186
#4  0x7f6fbeed59de in Jack::JackLockedEngine::Process 
(prev_cycle_end=, cur_cycle_begin=, 
this=) at ../common/JackLockedEngine.h:261
#5  Jack::JackAudioDriver::ProcessGraphAsyncMaster (this=0x56138ab22820) at 
../common/JackAudioDriver.cpp:249
#6  0x7f6fbeed5ad5 in Jack::JackAudioDriver::ProcessGraphAsync 
(this=this@entry=0x56138ab22820) at ../common/JackAudioDriver.cpp:236
#7  0x7f6fbeed645e in Jack::JackWaiterDriver::ProcessNull 
(this=0x56138ab22820) at ../common/JackTimedDriver.cpp:79
#8  0x7f6fbeee445a in Jack::JackWaitThreadedDriver::Execute 
(this=0x56138ad16150) at ../common/JackWaitThreadedDriver.cpp:46
#9  0x7f6fbeed28d6 in Jack::JackPosixThread::ThreadHandler 
(arg=0x56138ad16168) at ../posix/JackPosixThread.cpp:59
#10 0x7f6fbee6efa3 in start_thread (arg=) at 
pthread_create.c:486
#11 0x7f6fbe9be4cf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

(gdb) list JackTransportEngine.cpp:54
50
51  // compute the number of cycle for timeout
52  void JackTransportEngine::SyncTimeout(jack_nframes_t frame_rate, 
jack_nframes_t buffer_size)
53  {
54  long buf_usecs = (long)((buffer_size * (jack_time_t)100) / 
frame_rate);
55  fSyncTimeLeft = fSyncTimeout / buf_usecs;
56  jack_log("SyncTimeout fSyncTimeout = %ld fSyncTimeLeft = %ld", 
(long)fSyncTimeout, (long)fSyncTimeLeft);
57  }
58

# Buster/stable amd64 qemu VM 2019-08-28

apt update
apt dist-upgrade

apt install systemd-coredump xserver-xorg lightdm openbox xterm fakeroot gdb 
jackd2 jackd2-dbgsym libjack-jackd2-0-dbgsym
apt build-dep jackd2


reboot


export DISPLAY=:0
jackd -R -d net -a 10.0.2.15


export DISPLAY=:0
LANG=C qjackctl


# press the play button in the middle
# jackd gets a floating point exception



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



##



benutzer@debian:~$ LANG=C jackd -R -d net -a 10.0.2.15
jackdmp 1.9.12
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2017 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
NetDriver started in async mode without Master's transport sync.
Waiting for a master...
Initializing connection with ...
 Network parameters 
Name : debian
Protocol revision : 8
MTU : 1500
Master name : 
Slave name : debian
ID : 0
Transport Sync : no
Send channels (audio - midi) : -1 - -1
Return channels (audio - midi) : -1 - -1
Sample rate : 0 frames per second
Period size : 0 frames per period
Network latency : 5 cycles
SampleEncoder : Float
Slave mode : async

Recv fd = 7 err = Resource temporarily unavailable
Recv connection lost error
Driver is restarted
JackTimedDriver::Process XRun = 12 usec
Restarting driver...
JackTimedDriver::Process XRun = 4 usec
NetDriver started in async mode without Master's transport sync.
JackTimedDriver::Process XRun = 3 usec
JackTimedDriver::Process XRun = 3 usec
JackTimedDriver::Process XRun = 3 usec
Waiting for a master...
JackTimedDriver::Process XRun = 4 usec
JackTimedDriver::Process XRun = 3 usec
Initializing connection with ...
 Network parameters 
Name : debian
JackTimedDriver::Process XRun = 4 usec
Protocol revision : 8
MTU : 1500
Master name : 
Slave name : debian
ID : 0
Transport Sync : no
Send channels (audio - midi) : -1 - -1
Return channels (audio - midi) : -1 - -1
Sample rate : 0 frames per second
Period size : 0 frames per period
Network latency : 5 cycles
SampleEncoder : Float
JackTimedDriver::Process XRun = 3 usec
Slave mode : async

Bug#935128: aspell: potentially unbounded buffer over-read in GNU Aspell 0.60.*

[Agustin Martin]

On Mon, Aug 19, 2019 at 04:33:40PM -0400, Kevin Atkinson wrote:
> On Mon, 19 Aug 2019, Salvatore Bonaccorso wrote:
>
> > See https://lists.gnu.org/archive/html/aspell-announce/2019-08/msg0.html
>
> > Within Debian the "pumpa" will need an update. Others might be
> > required as well. Kevin Atkinson might be up for help if needed.
> Also see http://aspell.net/buffer-overread-ucs.txt for a slightly improved
> version of the announcement that I edited for clarity.

Hi all,

This message is sent to all packages that depend in some way on
libaspell15 (pdo addresses bcc'ed)

A potentially unbounded buffer over-read has been found in in GNU
Aspell 0.60.*. Package aspell 0.60.7-1 has been uploaded to Debian
experimental, including upstream patch to deal with this problem.

Unfortunately this fix may break applications that use null-terminated
UCS-2 or UCS-4 strings with the C API.  These applications will need
to be fixed to make use of the new more secure API in order to
continue to have a functional spell checker.

Most applications use UTF-8 strings and thus do not need to be fixed.

Please read http://aspell.net/buffer-overread-ucs.txt (and the
original announcement in
https://lists.gnu.org/archive/html/aspell-announce/2019-08/msg0.html)
for details and check if your package is affected. That file and new
aspell manual, contain information about what to do if that happens.

I would like to leave aspell package in experimental for one week to
allow possibly affected packages to be checked and fixed if
appropriate. Since there is no longer a dict-common-dev mailing list,
please use this bug report to notify if your package is affected and
if you need more time before new aspell with that fix is uploaded to
sid. If you need additional help, please contact the aspell-devel
mailing list (https://lists.gnu.org/mailman/listinfo/aspell-devel).

Regards,

Bug#928620: Re : totem : bottom controls not working

[topaze666]

Just to confirm exactly the same problem as discribed, on my system :

Linux station1 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08)
x86_64 GNU/Linux
AMD® Sempron(tm) 3850 apu with radeon(tm) r3 × 4
Gnome 3.30.2

Bug#934457: installation in chroot failing with Unknown device "/dev/fuse": No such device

[GCS]

Control: tags -1 +moreinfo

On Sun, Aug 11, 2019 at 11:24 AM Patrick Schleizer  wrote:
> The following code from /var/lib/dpkg/info/fuse.postinst is failing.
>
> if [ -e /dev/fuse ]
> then
>  udevadm test --action -p  $(udevadm info -q path -n /dev/fuse)
> > /dev/null 2>&1
> fi
 It's very strange. I've tried several ways to reproduce this, without
any luck. Especially that [ -e /dev/fuse ] is checking for the fuse
device and only run udevadm if it's there.
I've tried hard to reproduce this on a real system and in chroots
(Buster and Sid) without success. Just for the record, what kind of
architecture do you try this on?

> + [ -e /dev/fuse ]
> + udevadm info -q path -n /dev/fuse
> Unknown device "/dev/fuse": No such device
>
> Happening inside a Debian buster chroot.
 How did you create that Buster chroot? Mine was created with
'pbuilder create' and I do have the fuse device in the chroot.
As noted above, if the fuse device is not there, the udevadm is not
run due to the check for that being false. One thing came into my mind
is that you have the chroot on a mount point that has the nodev
option. Can you check that please?

Regards,
Laszlo/GCS

Bug#931939: ITA: acpitool -- command line ACPI client

[jathan]

Hi,

I want to keep going on this in the right way to start maintaining
acpitool since now. Could someone help me to start please?

Best regards
Jathan

-- 
Por favor evita enviarme adjuntos en formato de word o powerpoint, si
quieres saber porque lee esto:
http://www.gnu.org/philosophy/no-word-attachments.es.html
¡Cámbiate a GNU/Linux! http://getgnulinux.org/es



signature.asc
Description: OpenPGP digital signature

Bug#936003: libsbuild-perl: always cleans apt cache even if "$apt_clean = 0;" is in .sbuildrc

[Johannes Schauer]

Quoting Alexis Murzeau (2019-08-28 23:43:26)
> Well, just found that my bug is a duplicate of #933723.  You suggested in
> that bug to add an option to be used in .sbuildrc.
> 
> I can make a patch to do that (with the default value being enabled to keep
> the current behavior as the default one).

Ah indeed -- please go ahead!


signature.asc
Description: signature

Bug#936007: stretch-pu: package libu2f-host/1.1.2-2+deb9u1

[Nicolas Braud-Santoni]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Control: block 923874 by -1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear release team,

I would like to backport the fix for CVE-2019-9578 in the next point release
for stretch.  Please find enclosed the proposed debdiff.


Best,

  nicoo

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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl1m+nIRHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7Mt6SxAAr7eu5OYjhIpecngn+g35hCagOawJEUG7
T9iw/fussQ/g1Afxrvoi50Wl7tFBaHI0rLpMmvPb3ZihqW5jv0IJmBtLzgd5B/Bq
SwN6uGhPyaden8Q79h/VI/Cuma/Tmv2B6Y5tGR0/sAsw0+raGWoAilt9oAdD7fbJ
T6Eot0yS7dCLB6rnkzyckKaIiJkbxRSzJCKOxOFsaZFTb+cS8Nj90cqgp5koNzIi
iGTuKoCmC1AN7XF68YDKU2/ZB3Lbp35TPVDGAB8g/qxs+Q4/vgHSLKugaKbqPaGG
dnFvjtx/OWHR20Fbf06bN3NP8dKxwe42Pq4OLwtslyc9iS60dAj0HXS2tsDFDyHc
pfIeQEbGFsgWlPz1ztCFzdo2kDH1rfxDJIRYozcL8vieiaUdDz4F1i1lmHA6DUqc
x4evcQe7K+m2qFDJLOPcphQh0KzivoFn9ttxSEi3lGvImyES3IAuVkZbA8KIb3zR
66YSFG0yiiz8aZn5vajdGJ4ate2sHc+SrvGDCsOb6AbNywMz7pWvRwXGiIEXKEgG
Qgbyobv8xOyE8F61E4HllvuAwmLxDdDSLbQnhckfygw6Wkaxe5yK+CaODEalnbzd
X+ML4b7X8Hhi0iVlJb3YXfmyftww0RXVICFtNeftHCgizdHG6iJnC1+0uWI0iXvr
OGExa2tojgI=
=cc+K
-END PGP SIGNATURE-
diff -Nru libu2f-host-1.1.2/debian/changelog libu2f-host-1.1.2/debian/changelog
--- libu2f-host-1.1.2/debian/changelog  2019-02-08 21:42:16.0 +0100
+++ libu2f-host-1.1.2/debian/changelog  2019-08-28 23:52:13.0 +0200
@@ -1,3 +1,10 @@
+libu2f-host (1.1.2-2+deb9u2) stretch; urgency=medium
+
+  * Backport fix for CVE-2019-9578 (Closes: #923874)
+  * Configure git-buildpackage for stretch
+
+ -- Nicolas Braud-Santoni   Wed, 28 Aug 2019 23:52:13 +0200
+
 libu2f-host (1.1.2-2+deb9u1) stretch-security; urgency=high
 
   * Backport patch for CVE-2018-20340 (Closes: #921725)
diff -Nru libu2f-host-1.1.2/debian/gbp.conf libu2f-host-1.1.2/debian/gbp.conf
--- libu2f-host-1.1.2/debian/gbp.conf   2019-02-08 21:42:16.0 +0100
+++ libu2f-host-1.1.2/debian/gbp.conf   2019-08-28 23:52:13.0 +0200
@@ -1,3 +1,7 @@
 [DEFAULT]
+debian-branch = debian/stretch
 pristine-tar = True
 sign-tags = True
+
+[buildpackage]
+dist = stretch
diff -Nru libu2f-host-1.1.2/debian/patches/Fix-CVE-2019-9578.patch 
libu2f-host-1.1.2/debian/patches/Fix-CVE-2019-9578.patch
--- libu2f-host-1.1.2/debian/patches/Fix-CVE-2019-9578.patch1970-01-01 
01:00:00.0 +0100
+++ libu2f-host-1.1.2/debian/patches/Fix-CVE-2019-9578.patch2019-08-28 
23:52:13.0 +0200
@@ -0,0 +1,60 @@
+Subject: fix filling out of initresp
+
+---
+ u2f-host/devs.c | 35 +++
+ 1 file changed, 23 insertions(+), 12 deletions(-)
+
+diff --git a/u2f-host/devs.c b/u2f-host/devs.c
+index 0c50882..dc2120b 100644
+Origin: vendor
+Bug: CVE-2019-9578
+Bug-Debian: 923874
+From: Klas Lindfors 
+Reviewed-by: Nicolas Braud-Santoni 
+Last-Update: 2019-08-28
+Applied-Upstream: yes
+
+--- a/u2f-host/devs.c
 b/u2f-host/devs.c
+@@ -246,18 +246,29 @@ init_device (u2fh_devs * devs, struct u2fdevice *dev)
+   (devs, dev->id, U2FHID_INIT, nonce, sizeof (nonce), resp,
+) == U2FH_OK)
+ {
+-  U2FHID_INIT_RESP initresp;
+-  if (resplen > sizeof (initresp))
+-{
+-  return U2FH_MEMORY_ERROR;
+-}
+-
+-  memcpy (, resp, resplen);
+-  dev->cid = initresp.cid;
+-  dev->versionInterface = initresp.versionInterface;
+-  dev->versionMajor = initresp.versionMajor;
+-  dev->versionMinor = initresp.versionMinor;
+-  dev->capFlags = initresp.capFlags;
++  int offs = sizeof (nonce);
++  /* the response has to be atleast 17 bytes, if it's more we discard 
that */
++  if (resplen < 17)
++  {
++return U2FH_SIZE_ERROR;
++  }
++
++  /* incoming and outgoing nonce has to match */
++  if (memcmp (nonce, resp, sizeof (nonce)) != 0)
++  {
++return U2FH_TRANSPORT_ERROR;
++  }
++
++  dev->cid =
++  resp[offs] << 24 | resp[offs + 1] << 16 | resp[offs +
++ 2] << 8 | resp[offs +
++3];
++  offs += 4;
++  dev->versionInterface = resp[offs++];
++  dev->versionMajor = resp[offs++];
++  dev->versionMinor = resp[offs++];
++  dev->versionBuild = resp[offs++];
++  dev->capFlags = resp[offs++];
+ }
+   else
+   

Bug#936006: fonts-dejavu-core: Invalid rendering of 'ż' at serveral different sizes

[Łukasz Stelmach]

Package: fonts-dejavu-core
Version: 2.37-1
Severity: normal

Dear Maintainer,

In some applications (notably Firefox) 'ż' (\u017c) character from
DejaVu Sans (14px, 16px, 19px, 22px) and DejaVu Serif (15px, 16px) is
rendered improperly. The dot above is not centered and there is a pixel
or two of extra space to the left of the character.

Steps to reproduce:

1. Open the attached zhet.html file in Firefox or
2. Run: xfd -fa 'DejaVu Sans:size=12'


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

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

-- no debconf information

-- 
Miłego dnia,
Łukasz Stelmach


zhet.html
Description: Binary data

Bug#935977: RM: gnuplot [mipsel] -- ROM; FTBFS on deprecated platform (mipsel)

[Scott Kitterman]

Mipsel is still a release architecture.  It's mips that was dropped.  Does that 
change your mind about the rm?

Scott K

On August 28, 2019 3:42:15 PM UTC, Anton Gladky  wrote:
>Package: ftp.debian.org
>Severity: normal
>
>Dear FTP team,
>
>gnuplot fails to compile on mipsel. As this architecture
>considered to be removed from official archs, I do not
>see a motivation to fix it there.
>
>Thanks
>
>Anton

Bug#935972: debian-installer: Package "fuse" installation failed in debian-installer

[Bernhard Übelacker]

Hello,
this sounds related to these bugs:
https://bugs.debian.org/935916
https://bugs.debian.org/935496

Kind regards,
Bernhard

Bug#936003: libsbuild-perl: always cleans apt cache even if "$apt_clean = 0;" is in .sbuildrc

[Alexis Murzeau]

Control: merge 933723 936003

Hi,

Le 28/08/2019 à 23:33, Johannes Schauer a écrit :
> 
>> I've used "$apt_cache = 0" option before which worked well without the need
>> of a server on localhost so searched why it wasn't working after a sbuild
>> update.  Since then, as a workaround, I'm hand-editing ResolverBase.pm to
>> comment the "print $F qq(APT::Keep-Downloaded-Packages "false";\n);" line and
>> this makes sbuild keep downloaded package cached.
>>
>> I would prefer to make "$apt_cache = 0" works (that is, keep downloaded
>> packages) than installing an additional server instead, as the patch is
>> really easy to implement (just add an "if" in ResolverBase.pm, I can provide
>> an test that patch myself).
> 
> Unfortunately, sbuild is a bit more complex than you might think as it 
> supports
> several backends. I am still pondering about the best solution for this issue.
> 

Well, just found that my bug is a duplicate of #933723.
You suggested in that bug to add an option to be used in .sbuildrc.

I can make a patch to do that (with the default value being enabled to
keep the current behavior as the default one).

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#849974: openmpi: not enough slots available

[Graham Inggs]

I know this is an old bug report, but anyway...

> Here you meant
>  mpirun --oversubscribe -np 4 python -c "print 'hello'"

Indeed, thanks.

> But the ability to oversubscribe doesn't explain the bug here.  Why
> does openmpi think only 2 slots are available when in fact 4 processors
> are available?

As per the ark.intel.com page for this CPU [1]:

# of Cores 2
# of Threads 4

So openmpi seems to be (correctly, IMHO) counting cores here, rather
than threads.


[1] 
https://ark.intel.com/content/www/us/en/ark/products/88190/intel-core-i5-6300u-processor-3m-cache-up-to-3-00-ghz.html

Bug#875092: [polkit-qt-1] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sat, Sep 09, 2017 at 10:19:00PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: polkit-qt-1
> Usertags: qt4-removal

With the removal of src:kde4libs, the Qt4 packages can now go away, patch 
attached.

Cheers,
Moritz
diff -Naur polkit-qt-1-0.112.0.orig/debian/control polkit-qt-1-0.112.0/debian/control
--- polkit-qt-1-0.112.0.orig/debian/control	2018-11-08 07:29:36.0 +0100
+++ polkit-qt-1-0.112.0/debian/control	2019-08-28 23:37:04.361158804 +0200
@@ -8,7 +8,6 @@
debhelper (>= 11~),
libpolkit-agent-1-dev (>= 0.98),
libpolkit-gobject-1-dev (>= 0.98),
-   libqt4-dev (>= 4:4.4.0),
pkg-kde-tools (>= 0.11),
qtbase5-dev (>= 5.1.0)
 Standards-Version: 4.2.1
@@ -16,45 +15,6 @@
 Vcs-Browser: https://salsa.debian.org/qt-kde-team/extras/polkit-qt-1
 Vcs-Git: https://salsa.debian.org/qt-kde-team/extras/polkit-qt-1.git
 
-Package: libpolkit-qt-1-dev
-Section: libdevel
-Architecture: any
-Multi-Arch: same
-Depends: libpolkit-qt-1-1 (= ${binary:Version}), libqt4-dev, ${misc:Depends}
-Description: PolicyKit-qt-1 development files
- PolicyKit is an application-level toolkit for defining and handling the policy
- that allows unprivileged processes to speak to privileged processes.
- .
- It is a framework for centralizing the decision making process with respect to
- granting access to privileged operations (like calling the HAL Mount() method)
- for unprivileged (desktop) applications.
- .
- libpolkit-qt-1 provides convenience classes and methods for Qt/KDE
- applications that want to use PolicyKit-1.
- .
- This package contains the development libraries and headers.
-
-Package: libpolkit-qt-1-1
-Architecture: any
-Multi-Arch: same
-Pre-Depends: ${misc:Pre-Depends}
-Depends: libpam-systemd [linux-any],
- ${misc:Depends},
- ${shlibs:Depends}
-Description: PolicyKit-qt-1 library
- PolicyKit is an application-level toolkit for defining and handling the policy
- that allows unprivileged processes to speak to privileged processes.
- .
- It is a framework for centralizing the decision making process with respect to
- granting access to privileged operations (like calling the HAL Mount() method)
- for unprivileged (desktop) applications.
- .
- libpolkit-qt-1 provides convenience classes and methods for Qt/KDE
- applications that want to use PolicyKit.
- .
- This package contains the files necessary for running applications that use
- the libpolkit-qt-1 library.
-
 Package: libpolkit-qt5-1-dev
 Section: libdevel
 Architecture: any
diff -Naur polkit-qt-1-0.112.0.orig/debian/control~ polkit-qt-1-0.112.0/debian/control~
--- polkit-qt-1-0.112.0.orig/debian/control~	1970-01-01 01:00:00.0 +0100
+++ polkit-qt-1-0.112.0/debian/control~	2018-11-08 07:29:36.0 +0100
@@ -0,0 +1,93 @@
+Source: polkit-qt-1
+Section: libs
+Priority: optional
+Maintainer: Debian Qt/KDE Maintainers 
+Uploaders: Modestas Vainius ,
+   Maximiliano Curia ,
+Build-Depends: cmake (>= 2.8.11),
+   debhelper (>= 11~),
+   libpolkit-agent-1-dev (>= 0.98),
+   libpolkit-gobject-1-dev (>= 0.98),
+   libqt4-dev (>= 4:4.4.0),
+   pkg-kde-tools (>= 0.11),
+   qtbase5-dev (>= 5.1.0)
+Standards-Version: 4.2.1
+Homepage: https://projects.kde.org/projects/kdesupport/polkit-qt-1
+Vcs-Browser: https://salsa.debian.org/qt-kde-team/extras/polkit-qt-1
+Vcs-Git: https://salsa.debian.org/qt-kde-team/extras/polkit-qt-1.git
+
+Package: libpolkit-qt-1-dev
+Section: libdevel
+Architecture: any
+Multi-Arch: same
+Depends: libpolkit-qt-1-1 (= ${binary:Version}), libqt4-dev, ${misc:Depends}
+Description: PolicyKit-qt-1 development files
+ PolicyKit is an application-level toolkit for defining and handling the policy
+ that allows unprivileged processes to speak to privileged processes.
+ .
+ It is a framework for centralizing the decision making process with respect to
+ granting access to privileged operations (like calling the HAL Mount() method)
+ for unprivileged (desktop) applications.
+ .
+ libpolkit-qt-1 provides convenience classes and methods for Qt/KDE
+ applications that want to use PolicyKit-1.
+ .
+ This package contains the development libraries and headers.
+
+Package: libpolkit-qt-1-1
+Architecture: any
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
+Depends: libpam-systemd [linux-any],
+ ${misc:Depends},
+ ${shlibs:Depends}
+Description: PolicyKit-qt-1 library
+ PolicyKit is an application-level toolkit for defining and handling the policy
+ that allows unprivileged processes to speak to privileged processes.
+ .
+ It is a framework for centralizing the decision making process with respect to
+ granting access to privileged operations (like calling the HAL Mount() method)
+ for unprivileged (desktop) applications.
+ .
+ libpolkit-qt-1 provides convenience classes and methods for Qt/KDE
+ applications that want to use 

Bug#906258: stretch-pu: package yubico-piv-tool/1.4.2-2

[Nicolas Braud-Santoni]

On Thu, Aug 22, 2019 at 09:28:18PM +0100, Adam D. Barratt wrote:
> Ping on a new upload? There's just over a week if you want to get this
> in to 9.10.

Thanks for the reminder; uploaded.


signature.asc
Description: PGP signature

Bug#936003: libsbuild-perl: always cleans apt cache even if "$apt_clean = 0;" is in .sbuildrc

[Johannes Schauer]

Hi,

Quoting Alexis Murzeau (2019-08-28 23:30:27)
> Le 28/08/2019 à 23:06, Johannes Schauer a écrit :
> > Quoting Alexis Murzeau (2019-08-28 22:58:32)
> >> I'm using a slow internet connection and, when repeatedly testing
> >> a package I've modified with sbuild, it takes a long time downloading
> >> packages for dependencies of the built package.
> > I'm in the same situation. What stops you from using apt-cacher or
> > apt-cacher-ng to cache packages?
> I admittedly did not searched for caching solution as I'm not using multiple
> computers.

neither am I. The software runs on your local computer.

> I've used "$apt_cache = 0" option before which worked well without the need
> of a server on localhost so searched why it wasn't working after a sbuild
> update.  Since then, as a workaround, I'm hand-editing ResolverBase.pm to
> comment the "print $F qq(APT::Keep-Downloaded-Packages "false";\n);" line and
> this makes sbuild keep downloaded package cached.
> 
> I would prefer to make "$apt_cache = 0" works (that is, keep downloaded
> packages) than installing an additional server instead, as the patch is
> really easy to implement (just add an "if" in ResolverBase.pm, I can provide
> an test that patch myself).

Unfortunately, sbuild is a bit more complex than you might think as it supports
several backends. I am still pondering about the best solution for this issue.


signature.asc
Description: signature

Bug#936005: asmix FTCBFS: strips with the wrong strip

[Helmut Grohne]

Source: asmix
Version: 1.5-4.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

asmix fails to cross build from source, because it strips using the
wrong strip during make install. Beyond breaking cross compilation, this
also breaks DEB_BUILD_OPTIONS=nostrip as well as generation of -dbgsym
packages. It is best to defer all stripping to dh_strip. Please consider
applying the attached patch.

Helmut
diff -u asmix-1.5/debian/changelog asmix-1.5/debian/changelog
--- asmix-1.5/debian/changelog
+++ asmix-1.5/debian/changelog
@@ -1,3 +1,10 @@
+asmix (1.5-4.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 28 Aug 2019 21:56:46 +0200
+
 asmix (1.5-4.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -u asmix-1.5/debian/rules asmix-1.5/debian/rules
--- asmix-1.5/debian/rules
+++ asmix-1.5/debian/rules
@@ -5,0 +6,2 @@
+export STRIP=/bin/true
+export INSTALL=/usr/bin/install --strip-program=true

Bug#936003: libsbuild-perl: always cleans apt cache even if "$apt_clean = 0;" is in .sbuildrc

[Alexis Murzeau]

Le 28/08/2019 à 23:06, Johannes Schauer a écrit :
> Quoting Alexis Murzeau (2019-08-28 22:58:32)
>> I'm using a slow internet connection and, when repeatedly testing
>> a package I've modified with sbuild, it takes a long time downloading
>> packages for dependencies of the built package.
> 
> I'm in the same situation. What stops you from using apt-cacher or
> apt-cacher-ng to cache packages?

I admittedly did not searched for caching solution as I'm not using
multiple computers.

I've used "$apt_cache = 0" option before which worked well without the
need of a server on localhost so searched why it wasn't working after a
sbuild update.
Since then, as a workaround, I'm hand-editing ResolverBase.pm to comment
the "print $F qq(APT::Keep-Downloaded-Packages "false";\n);" line and
this makes sbuild keep downloaded package cached.

I would prefer to make "$apt_cache = 0" works (that is, keep downloaded
packages) than installing an additional server instead, as the patch is
really easy to implement (just add an "if" in ResolverBase.pm, I can
provide an test that patch myself).

> 
> Thanks!
> 
> cheers, josch
> 


-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#936004: gedit-plugins: FTBFS with gedit 3.33

[Steve Langasek]

Package: gedit-plugins
Version: 3.32.0-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

gedit 3.33.90 in experimental has moved libgedit off of the linker path and
now ships it in /usr/lib/$arch/gedit/ as a private library.  As a result,
gedit-plugins fails to build because dh_shlibdeps fails to find it.

To fix this, dh_shlibdeps needs to be told to look in the private directory
for dependencies, as in the attached patch.

I have confirmed in Ubuntu that the gedit-plugins-draw-spaces package built
this way successfully loads in gedit, with libgedit in the private directory.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gedit-plugins-3.32.0/debian/rules gedit-plugins-3.32.0/debian/rules
--- gedit-plugins-3.32.0/debian/rules   2019-03-10 18:13:09.0 -0700
+++ gedit-plugins-3.32.0/debian/rules   2019-08-28 14:12:10.0 -0700
@@ -2,12 +2,16 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,-O1 -Wl,--as-needed
+export DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
 export PYTHON = /usr/bin/python3
 
 %:
dh $@ --with gnome,python3
 
+override_dh_shlibdeps:
+   LD_LIBRARY_PATH=/usr/lib/$(DEB_HOST_MULTIARCH)/gedit dh_shlibdeps 
+
 override_dh_autoreconf:
NOCONFIGURE=true dh_autoreconf ./autogen.sh
 

Bug#935588: nmu: rdepends of libbabeltrace1/buster

[Adam D. Barratt]

On Wed, 2019-08-28 at 14:31 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On 2019-08-24 14:59, Adam D. Barratt wrote:
> > On Sat, 2019-08-24 at 12:06 +0200, Andreas Beckmann wrote:
> > > As a followup to tightening the versions in the libbabeltrace1
> > > symbols file rebuild gdb to tighten the libbabeltrace1
> > > dependency.
> > > (See #931147)
> > > 
> > > Actually all rdepends need to be rebuilt, since all have ldd
> > > report
> > >   libbabeltrace-ctf.so.1 => not found
> > > on some binary if libbabeltrace1 1.5.1-1 is installed.
> > > 
> > > Checking reverse dependencies...
> > > # Broken Depends:
> > > babeltrace: babeltrace
> > > libbabeltrace-ctf1
> > > libbabeltrace-dev
> > > python3-babeltrace
> > > ceph: ceph-common
> > > gdb: gdb [amd64 armel armhf i386 mips mipsel s390x]
> > >  gdb-multiarch [amd64 armel armhf i386 mips mipsel s390x]
> > > gdb-mingw-w64: gdb-mingw-w64
> > > linux: linux-perf-4.19
> > > lttv: lttv
> > 
> > It sounds like there will be a new kernel upload before the point
> > release, so we'll be skipping the rebuilds for that.
> 
> Scheduled the remainder.

gdb-mingw-w64 was already at +b1 in unstable.

I've scheduled +b10 there, and will follow up with +b2 for buster.

Regards,

Adam

Bug#936003: libsbuild-perl: always cleans apt cache even if "$apt_clean = 0;" is in .sbuildrc

[Johannes Schauer]

Hi,

Quoting Alexis Murzeau (2019-08-28 22:58:32)
> I'm using a slow internet connection and, when repeatedly testing
> a package I've modified with sbuild, it takes a long time downloading
> packages for dependencies of the built package.

I'm in the same situation. What stops you from using apt-cacher or
apt-cacher-ng to cache packages?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#936003: libsbuild-perl: always cleans apt cache even if "$apt_clean = 0;" is in .sbuildrc

[Alexis Murzeau]

Package: libsbuild-perl
Version: 0.78.1-2
Severity: normal
X-Debbugs-Cc: vagr...@debian.org

Dear Maintainer,

Forenote: I'm Cc'ing vagr...@debian.org because he reported a related issue to 
this one
and the fix for this issue might impact him.


I'm using a slow internet connection and, when repeatedly testing
a package I've modified with sbuild, it takes a long time downloading
packages for dependencies of the built package.

So I've made the /var/cache/apt/archive directory persistent in the schroot
by binding it to a directory on the host.
So downloaded packages by apt are kept even after the schroot session is ended.

But, even if I disable "$apt_clean" option, sbuild always download dependencies
packages at each invocation.

I've found in "/usr/share/perl5/Sbuild/ResolverBase.pm", that sbuild is using
APT::Keep-Downloaded-Packages "false"

This makes all downloaded packages by apt deleted after installation.
As this apt option is used unconditionally, sbuild always download, install
dependencies for the built package and then delete the downloaded packages
from the cache at each invocation.


APT::Keep-Downloaded-Packages option was introduced to fix this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861762


I suggest to set `APT::Keep-Downloaded-Packages` to "false" only if the option
"$apt_clean" option is set to 1, else set it to "true".

The current description of the apt_clean option is:
  APT clean.  1 to enable running "apt-get clean" at the start of each
  build, or 0 to disable.

If accepted, I suggest to amend this description accordingly.

I can provide a patch if this solution is accepted.

What do you think about that solution ?


Related commit: 
https://salsa.debian.org/debian/sbuild/commit/1159497b26aabbb3380ac3475c11aff556ca1de2


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

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

Versions of packages libsbuild-perl depends on:
ii  apt  1.8.1
ii  dpkg-dev 1.19.6
ii  gnupg2.2.13-2
ii  libdpkg-perl 1.19.6
ii  libexception-class-perl  1.44-1
ii  libfilesys-df-perl   0.92-6+b4
ii  libmime-lite-perl3.030-2
ii  perl 5.28.1-6

Versions of packages libsbuild-perl recommends:
ii  autopkgtest  5.10
ii  schroot  1.6.10-6+b1

Versions of packages libsbuild-perl suggests:
pn  default-mta | mail-transport-agent  
ii  libwww-perl 6.36-2

-- no debconf information

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#874868: [Pkg-ime-devel] Bug#874868: [fcitx] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Fri, Oct 06, 2017 at 09:23:23PM +0800, Aron Xu wrote:
> On Fri, Oct 6, 2017 at 9:20 PM, Lisandro Damián Nicanor Pérez Meyer
>  wrote:
> > On 6 October 2017 at 07:51, Aron Xu  wrote:
> >> Hi,
> >>
> >> I'd like to remove Qt4 support from fcitx in the last minute of our
> >> actions because quite some users do depend on part of it to input text
> >> into Qt4 applications. Will keep an eye on the progress, thank you.
> >
> > Would this be just for fcitx or for all the ficitx-* packages?
> >
> > fcitx 874868
> > fcitx-kkc 874869
> > fcitx-libpinyin 874871 -> see qt4webkit removal page
> > fcitx-skk 874879
> >
> 
> Only fcitx is relevant, we'll try to migrate all other fcitx-*
> packages as soon as possible.

Gentle ping :-)

Cheers,
Moritz

Bug#936002: shim-signed FTBFS with DEB_BUILD_OPTIONS=nocheck

[Helmut Grohne]

Source: shim-signed
Version: 1.33
Tags: ftbfs patch

shim-signed fails to build from source when one supplies
DEB_BUILD_OPTIONS=nocheck. The code run by dh_auto_test is meaningful
and required for a proper build. Move it from the check target to the
all target to run it by dh_auto_build unconditionally. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru shim-signed-1.33/Makefile shim-signed-1.33+nmu1/Makefile
--- shim-signed-1.33/Makefile   2019-06-09 18:16:05.0 +0200
+++ shim-signed-1.33+nmu1/Makefile  2019-08-28 22:50:48.0 +0200
@@ -1,6 +1,4 @@
 all:
-
-check:
mkdir -p build
# Verifying that the image is signed with the correct key.
sbverify --cert MicCorUEFCA2011_2011-06-27.crt 
shim$(EFI_ARCH).efi.signed
diff --minimal -Nru shim-signed-1.33/debian/changelog 
shim-signed-1.33+nmu1/debian/changelog
--- shim-signed-1.33/debian/changelog   2019-06-09 18:32:54.0 +0200
+++ shim-signed-1.33+nmu1/debian/changelog  2019-08-28 22:50:51.0 
+0200
@@ -1,3 +1,10 @@
+shim-signed (1.33+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with DEB_BUILD_OPTIONS=nocheck. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 28 Aug 2019 22:50:51 +0200
+
 shim-signed (1.33) unstable; urgency=medium
 
   * Build against new signed binaries corresponding to

Bug#935858: nftables: lacks documentation

[westlake]

actually there's still no mention of chain names able to be stored in 
capitals.


The migratory tools automatically make capitals from iptables, and users 
would be tempted to try out documented commands. (even the link provided 
says nothing)


.. so you re-consider adding this as a side-note.

new users are tempted to try,
"nft list chain filter output
Error: No such file or directory
list chain filter output
   ^^
"

the nft syntax is difficult to grasp, and the output here is not even clear.

If the output (I would say upstream is to blame)  was actually more 
clear, then I would not need to report on confusion about this, and not 
have to dwell on telling you to provide some insight on what migratory 
tools actually do.


The fact that error output and online documentation mentions nothing 
about having capitals for chain names, is the reason why I decided to 
file this report.


The fact that many users also use migratory tools and likely face this 
same issue, is another reason why I think many users would actually 
benefit from a note or two in the README.Debian file.


You should take the perspective that new adopters face this issue, and 
that I wouldn't be the only one facing this.


Let it not be a main reason why NFT has not been widely adopted on 
Debian, because the least thing you could have done is to show me where 
I am wrong.


Show me where it is documented. Show me where it says that chain names 
can be in capitals.


Otherwise document it in README.Debian.

^ It's a Debian policy, and if you don't do it, then I will have to 
complain to the top leader about you being such a baby and revoke your 
abilities in maintaining this package.


You also closed my other bugreport without a real good explanation on 
why you need to have nft binary executables at the header of .conf 
files.  To me that is not just silly but impractical.  Online 
documentation sources mention about using "nft list ruleset > 
nftables.conf" and effectively that overwrites the header.


Use a bit of logic in maintaining this package.

thanks

Bug#935999: buster-pu: package libu2f-host/1.1.9-1+deb10u1

[Nicolas Braud-Santoni]

On Wed, Aug 28, 2019 at 10:29:02PM +0200, Nicolas Braud-Santoni wrote:
> I would like to backport the following patches for libu2f-host to stretch:
> 
>   + Fix for CVE-2019-9578 (Closes: #923874)

I was confused, this is a minor security issue for which no CVE was assigned.
(CVE-2019-9578 / #923874 impacts stretch, and should be addressed in stretch-pu)

An updated debdiff is attached.


Best,

  nicoo
diff -Nru libu2f-host-1.1.9/debian/changelog libu2f-host-1.1.9/debian/changelog
--- libu2f-host-1.1.9/debian/changelog  2019-03-08 11:59:52.0 +0100
+++ libu2f-host-1.1.9/debian/changelog  2019-08-28 22:23:32.0 +0200
@@ -1,3 +1,19 @@
+libu2f-host (1.1.9-1+deb10u1) buster; urgency=medium
+
+  * Backport patches from upstream
++ Fix for a minor security issue (uninitialized buffer access)
++ Support for new hardware devices
+  - Kensington Verimark
+  - KeyID U2F
+  - Ledger Nano S and X
+  - Longmai mFIDO
+  - SoloKeys (Closes: #925274)
+  - Trezor
+
+  * Configure git-buildpackage for buster
+
+ -- Nicolas Braud-Santoni   Wed, 28 Aug 2019 22:23:32 +0200
+
 libu2f-host (1.1.9-1) unstable; urgency=high (security fix)
 
   * New upstream version 1.1.9
diff -Nru libu2f-host-1.1.9/debian/gbp.conf libu2f-host-1.1.9/debian/gbp.conf
--- libu2f-host-1.1.9/debian/gbp.conf   2019-03-08 11:59:52.0 +0100
+++ libu2f-host-1.1.9/debian/gbp.conf   2019-08-28 22:23:32.0 +0200
@@ -1,3 +1,7 @@
 [DEFAULT]
+debian-branch = debian/buster
 pristine-tar = True
 sign-tags = True
+
+[buildpackage]
+dist = buster
diff -Nru 
libu2f-host-1.1.9/debian/patches/0001-Add-udev-rule-for-additional-devices.patch
 
libu2f-host-1.1.9/debian/patches/0001-Add-udev-rule-for-additional-devices.patch
--- 
libu2f-host-1.1.9/debian/patches/0001-Add-udev-rule-for-additional-devices.patch
1970-01-01 01:00:00.0 +0100
+++ 
libu2f-host-1.1.9/debian/patches/0001-Add-udev-rule-for-additional-devices.patch
2019-08-28 22:23:32.0 +0200
@@ -0,0 +1,62 @@
+Subject: Add udev rule for additional devices
+
++ Ledger Nano S and X
++ Kensington Verimark
++ Longmai mFIDO
++ KeyID U2F
++ SoloKeys
++ Trezor
+---
+ 70-u2f.rules | 24 
+ 1 file changed, 20 insertions(+), 4 deletions(-)
+
+diff --git a/70-u2f.rules b/70-u2f.rules
+index 682e45f..8ab5bcf 100644
+Origin: vendor
+Bug-Debian: 925274
+From: Nicolas Stalder 
+Reviewed-by: Nicolas Braud-Santoni 
+Last-Update: 2019-08-28
+Applied-Upstream: yes
+
+--- a/70-u2f.rules
 b/70-u2f.rules
+@@ -25,10 +25,10 @@ KERNEL=="hidraw*", SUBSYSTEM=="hidraw", 
ATTRS{idVendor}=="2581", ATTRS{idProduct
+ # Neowave Keydo and Keydo AES
+ KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1e0d", 
ATTRS{idProduct}=="f1d0|f1ae", TAG+="uaccess", GROUP="plugdev", MODE="0660"
+ 
+-# HyperSecu HyperFIDO
++# HyperSecu HyperFIDO, KeyID U2F
+ KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="096e|2ccf", 
ATTRS{idProduct}=="0880", TAG+="uaccess", GROUP="plugdev", MODE="0660"
+ 
+-# Feitian ePass FIDO, BioPass FIDO2
++# Feitian ePass FIDO, BioPass FIDO2, KeyID U2F
+ KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="096e", 
ATTRS{idProduct}=="0850|0852|0853|0854|0856|0858|085a|085b|085d", 
TAG+="uaccess", GROUP="plugdev", MODE="0660"
+ 
+ # JaCarta U2F
+@@ -52,7 +52,23 @@ KERNEL=="hidraw*", SUBSYSTEM=="hidraw", 
ATTRS{idVendor}=="20a0", ATTRS{idProduct
+ # Google Titan U2F
+ KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="18d1", 
ATTRS{idProduct}=="5026", TAG+="uaccess", GROUP="plugdev", MODE="0660"
+ 
+-# Tomu board + chopstx U2F
+-KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="0483", 
ATTRS{idProduct}=="cdab", TAG+="uaccess", GROUP="plugdev", MODE="0660"
++# Tomu board + chopstx U2F + SoloKeys
++KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="0483", 
ATTRS{idProduct}=="cdab|a2ca", TAG+="uaccess", GROUP="plugdev", MODE="0660"
++
++# SoloKeys
++KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1209", 
ATTRS{idProduct}=="5070|50b0", TAG+="uaccess", GROUP="plugdev", MODE="0660"
++
++# Trezor
++KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="534c", 
ATTRS{idProduct}=="0001", TAG+="uaccess", GROUP="plugdev", MODE="0660"
++KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1209", 
ATTRS{idProduct}=="53c1", TAG+="uaccess", GROUP="plugdev", MODE="0660"
++
++# Ledger Nano S and Nano X
++KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="2c97", 
ATTRS{idProduct}=="0001|0004", TAG+="uaccess", GROUP="plugdev", MODE="0660"
++
++# Kensington VeriMark
++KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="06cb", 
ATTRS{idProduct}=="0088", TAG+="uaccess", GROUP="plugdev", MODE="0660"
++
++# Longmai mFIDO
++KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="4c4d", 
ATTRS{idProduct}=="f703", TAG+="uaccess", GROUP="plugdev", MODE="0660"
+ 
+ LABEL="u2f_end"
diff -Nru 
libu2f-host-1.1.9/debian/patches/0002-Initialize-the-respone-buffer-to-0.patch 

Bug#936001: magic FTCBFS: hard codes the build architecture ld

[Helmut Grohne]

Source: magic
Version: 8.1.223+ds.1-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

magic fails to cross build from source, because scripts/defs.mak.in hard
codes the build architecture ld rather than using the one detected by
configure. The attached patch fixes that and makes magic cross
buildable. Please consider applying it.

Helmut
--- magic-8.1.223+ds.1.orig/scripts/defs.mak.in
+++ magic-8.1.223+ds.1/scripts/defs.mak.in
@@ -48,8 +48,8 @@
 CP = cp
 AR = ar
 ARFLAGS= crv
-LINK   = ld -r
 LD = @LD@
+LINK   = $(LD) -r
 M4		   = @M4@
 RANLIB = @RANLIB@
 SHDLIB_EXT = @SHDLIB_EXT@

Bug#936000: cheese-dev requires undeclared libgstreamer-plugins-bad1.0-dev in its pkg-config file

[Diego Escalante Urrelo]

Package: cheese
Version: 3.33.90.1-1
Severity: normal

cheese-dev in experimental requires libgstreamer-plugins-bad1.0-dev to be
used in pkg-config successfully:

pkg-config --cflags cheese
Package gstreamer-plugins-bad-1.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gstreamer-plugins-bad-1.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gstreamer-plugins-bad-1.0', required by 'cheese', not found

This dependency is currently not declared or enforced in the deb package.

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

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

Versions of packages cheese depends on:
ii  cheese-common  3.33.90.1-1
ii  gnome-video-effects0.5.0-1
ii  libc6  2.29-0experimental1
ii  libcanberra-gtk3-0 0.30-7
ii  libcheese-gtk253.33.90.1-1
ii  libcheese8 3.33.90.1-1
ii  libclutter-1.0-0   1.26.2+dfsg-12
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libgdk-pixbuf2.0-0 2.39.2-3
ii  libglib2.0-0   2.61.2-2
ii  libgnome-desktop-3-17  3.32.2-2
ii  libgstreamer1.0-0  1.16.0-2.1
ii  libgtk-3-0 3.24.10-1

Versions of packages cheese recommends:
ii  gvfs  1.41.91-1
ii  yelp  3.32.2-1

Versions of packages cheese suggests:
pn  gnome-video-effects-frei0r  

-- no debconf information

Bug#935999: buster-pu: package libu2f-host/1.1.9-1+deb10u1

[Nicolas Braud-Santoni]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Control: block 923874 by -1
Control: block 925274 by -1
Control: tag 923874 + pending buster
Control: tag 925274 + pending buster

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear release team,

I would like to backport the following patches for libu2f-host to stretch:

  + Fix for CVE-2019-9578 (Closes: #923874)
  + Support for new hardware devices
- Kensington Verimark
- KeyID U2F
- Ledger Nano S and X
- Longmai mFIDO
- SoloKeys (Closes: #925274)
- Trezor

All patches are from upstream's 1.1.10 release, packaged in sid and bullseye.
The proposed debdiff is enclosed.


Best,

  nicoo


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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl1m5AwRHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7MtaOg//ZIySdhqMtcwvIiBsTjT//R48EoAm+XHm
IL8sV1m969472zIxVGofJC5sTDeBor7pdxMKYf2163gsL5v8DONYTM0qIIjWD0ml
cBrFrEVpF7WsNQpcMN97RO7VE1Cdvu8/9nltS/v+hRuWMfrA4CMGPKVYdH9T0pOx
kFPHmRqa09BhoIOQieVFU8STmN8o33O4soj0nKRQMJmOw4SyZ1MyDbLrVTGiqF2z
/i6jxaWco7BApj9ZohPpBwoxx+PgH7poQaUwaCmtUG0SvXh//AdBmpSatzipFFh9
MqvDDpTtTcXP8PR65jVC3epKf6bQe0jyiQjbOmXfa6fRhxSKjHudkotkdX0sZU2u
cNt3zQgdAbDU03fi6AZVFry/3iVT4gilo3GhcVwKyVZ3P2yAqlWKxCUkenCqT99o
upu1CS1pRJbOhwT17Nw1iVXYn4zjeO6ez3OVLK6eTYaXh1NgtmJwoSc1Qasr9xks
ypNuiuIPaadvE2kiRQsRNHKeDuJipm59MpMt86exv0wtty1R5GWGPFLRJPxPf14A
S3xT9mcHwDrsK96F1eYUl8bbuq0ZOaQOAQJ3qP2ZcL2bzhK5h1xp6IZptzoPKcfD
bEumK8QfY7vLvber0K7cB2qtFqaBCbAtwZ/Jz0r4jt0TQfx/TFpC2Y39m1tdN4xm
YHz3HRpI1/A=
=nfNQ
-END PGP SIGNATURE-

Bug#935998: haskell-blaze-html: unsatisfiable build-depends due to version constraint.

[peter green]

Package: haskell-blaze-html
Version: 0.9.1.1-3
Severity: serious
Tags: sid

haskell-blaze-html build-depends on libghc-quickcheck2-dev (< 2.12) but 
unstable now has version 2.12.6.1-2

Bug#935896: add support for xrandr hotplug_mode_update property

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Control: forwarded -1 https://bugzilla.xfce.org/show_bug.cgi?id=15897

On Wed, 2019-08-28 at 21:13 +0200, Martin wrote:
> Bug is filed upstream in the xfce bugtracker:
> 
> https://bugzilla.xfce.org/show_bug.cgi?id=15897

Thanks,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl1m2/MACgkQ3rYcyPpX
RFsk2gf9GJkKakRLiNnEyz+4ndQADeprjkNy5St5BpzPaAzNlHREFIBvFIHcCvoz
3QzehO56jetQgy0agt4KlpTAGDgCUpyYJV2sMUoB7tQSTMfeekxCdUuKA5KiElZr
Vm03UyjzAOpu9SInucX9AXfAKKO9nrfCN0UJEU0ViSXgb7vZ+yEXDvyDfJu8qGHZ
1KO48hcoqar/FfQmR820dUqppkjWAsPLGqPF/vXu0xzxqfmVJ8AKVqM0zugVZuex
1QJlZ7SLl2Xk8QAdihTSvtvSoLJ9mPk7IV1eR092BEM7FrsQnln4Wy0DekJ4YMB5
On+z/1C+IHd86vy8rK13UkMnaZ88bg==
=t2Cy
-END PGP SIGNATURE-

Bug#932130:

[Mmobilea]

I downloaded the buster di alpha image, and successfully installed a debian 10 
buster. There was a 1 error, while installing a gnome desktop. Before selecting 
a desktop, installer asked me, that I want to restart „libpam” or somethink 
like that. I don’t remember exact name of this service. I pressed 1, agreeing 
to it. After 90% of installing gnome, there was an error. I tried again 
downloading the same set of software, and it ended without any errors.
Thank you.
Sorry for my English because I’m from Poland.

Wysłane z aplikacji Poczta dla Windows 10

Bug#935997: dh-runit: Avoid useless dependency on runit-helper

[Lorenzo Puliti]

Package: dh-runit
Version: 2.8.13.2
Severity: wishlist

Hi,

I recently try to add a runscript to openssh-server but it look
that dh-runit added a dependency on runit-helper also to
openssh-client. 
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935937
and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935936

My bad, I didn't realise that before sending the patch; next time 
i will pay more attention and use a fix like in 
https://salsa.debian.org/ssh-team/openssh/commit/e4d758fc1d3ee62f8aa1ee47ecb52128176cdd6d

but i wonder if dh-runit code can limit the dependency of runit-helper only to
the package that really ships the runscript

Thanks,
Lorenzo

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

Kernel: Linux 4.20.3-van (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages dh-runit depends on:
ii  debhelper12.5.3
ii  libfile-copy-recursive-perl  0.44-1
ii  libfile-slurp-perl   .27-1
ii  libtext-hogan-perl   2.01-1

dh-runit recommends no packages.

dh-runit suggests no packages.

-- no debconf information

Bug#858549: desktop resize not working on jessie

[Martin]

A bug report is filed upstream in the xfce bugtracker for this problem:

https://bugzilla.xfce.org/show_bug.cgi?id=15897


(Debian bug report for xfce4 package:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935896)

Bug#935939: Does not respect local admin changes and recreates files in /etc/sv

[Lorenzo Puliti]

Package: dh-runit
Version: 2.8.13.2
Followup-For: Bug #935939

Hi Michael,

> Since I have no use for runit, I removed the /etc/sv directory.
> Unfortunately, if the openssh-server package is upgraded (or
> reinstalled), the local admin choice is not respected and the files in
> /etc/sv are recreated.

This is the directory that contains runit services; openssh-server
is also shipping a /etc/init.d and a /lib/systemd/system directories.
Do you consider a bug the fact that, if I'm going to remove the 
/etc/init.d directory because I don't use sysv, 
it will be recreated on upgrade?

I suspect as long as Debian keep supporting more than one init we all
have to live with files we don't use.

>> Empty directories also come back no matter what you do, so even after
>> fixing this, /etc/sv/ssh/.meta and /etc/sv/ssh/log would still come
>> back.

> Urgh, that's ugly. Please consider creating those directories
> dynamically then and don't ship them in the package.

It's not possible for /etc/sv/ssh/log as it's the directory of the
appendant log service

About /etc/sv/ssh/.meta, maybe you can have a look at

https://salsa.debian.org/debian/init-system-helpers/merge_requests/10

and help figuring out an alternative solution, if it exists.
Preserving local admin choices about enabled/disabled
services is also a job for `update-rc.d`.

Lorenzo


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

Kernel: Linux 4.20.3-van (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages dh-runit depends on:
ii  debhelper12.5.3
ii  libfile-copy-recursive-perl  0.44-1
ii  libfile-slurp-perl   .27-1
ii  libtext-hogan-perl   2.01-1

dh-runit recommends no packages.

dh-runit suggests no packages.

-- no debconf information

Bug#935996: libpam-fscrypt: Should provide a manpage

[Matthijs Kooijman]

Package: libpam-fscrypt
Version: 0.2.4-2
Severity: normal

Hi,

I'm trying to use libpam-fscrypt, but I'm missing a manpage that
describes its usage.

I've found /usr/share/doc/fscrypt/README.md.gz which has some info on
the module, but is mostly limited to examples (for example, it is not
clear what parts the "auth" and "session" invocation of the module play
in the unlocking of encrypted files.

Having a complete manpage would be helpful in this sense.

Gr.

Matthijs

Bug#935896: add support for xrandr hotplug_mode_update property

[Martin]

Bug is filed upstream in the xfce bugtracker:

https://bugzilla.xfce.org/show_bug.cgi?id=15897

Bug#935995: python3-notebook: in browser terminal using term.js doesn't work.

[Diane Trout]

Package: python3-notebook
Version: 5.7.8-1
Severity: normal
Tags: patch

Dear Maintainer,

I tried hitting "new -> terminal" from the notebook file browser. A
gray screen with no terminal appeared.

I hacked a fix in for me, but my knowledge of javascript is limited and
I think term.js isn't designed to work with requirejs modules, so this
fix ends up cluttering the global javascript namespace. (And I have no
idea how to rebuild the minified .js so I switched terminal.html to use
the unminified source.)

Also trying to load components/xterm.js-css/index.css was 404ing so I
removed it.

Diane

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 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

Versions of packages python3-notebook depends on:
ii  fonts-font-awesome 5.0.10+really4.7.0~dfsg-1
ii  libjs-backbone 1.3.3~dfsg-5
ii  libjs-bootstrap3.4.1+dfsg-1
ii  libjs-bootstrap-tour   0.12.0+dfsg-2
ii  libjs-codemirror   5.43.0-1
ii  libjs-es6-promise  4.2.8-5
ii  libjs-jed  1.1.1-1
ii  libjs-jquery   3.3.1~dfsg-3
ii  libjs-jquery-typeahead 2.10.6+dfsg1-1
ii  libjs-jquery-ui1.12.1+dfsg-5
ii  libjs-marked   0.5.1+dfsg-1
ii  libjs-mathjax  2.7.4+dfsg-1
ii  libjs-moment   2.24.0+ds-1
ii  libjs-requirejs2.3.6-1
ii  libjs-requirejs-text   2.0.12-1
ii  libjs-term.js  0.0.7-1
ii  libjs-text-encoding0.7.0-1
ii  libjs-underscore   1.9.1~dfsg-1
ii  python33.7.3-1
ii  python3-ipykernel  4.9.0-1
ii  python3-ipython-genutils   0.2.0-1
ii  python3-jinja2 2.10.1-1
ii  python3-jupyter-client 5.2.3-1
ii  python3-jupyter-core   4.5.0-2
ii  python3-nbconvert  5.4-2
ii  python3-nbformat   4.4.0-1
ii  python3-prometheus-client  0.6.0-1
ii  python3-send2trash 1.5.0-1
ii  python3-terminado  0.8.2-2
ii  python3-tornado5.1.1-4
ii  python3-traitlets  4.3.2-1
ii  python3-zmq17.1.2-3

Versions of packages python3-notebook recommends:
pn  python3-ipywidgets  

Versions of packages python3-notebook suggests:
ii  python-notebook-doc  5.7.8-1

-- no debconf information

--- notebook/static/terminal/js/terminado.js	2019-08-28 11:34:32.605416308 -0700
+++ /usr/lib/python3/dist-packages/notebook/static/terminal/js/terminado.js	2019-08-28 10:46:44.570493664 -0700
@@ -1,5 +1,6 @@
-define ([], function(Terminal) {
+define(function(require, exports, module) {
 "use strict";
 function make_terminal(element, ws_url) {
+require('/static/components/term.js/term.js');
 var ws = new WebSocket(ws_url);
 var term = new Terminal({cols: 80, rows: 24});
--- notebook/templates/terminal.html	2019-08-28 09:45:57.028871925 -0700
+++ /usr/lib/python3/dist-packages/notebook/templates/terminal.html	2019-08-28 11:07:22.413702027 -0700
@@ -16,5 +16,4 @@
 {{super()}}
 
-
 {% endblock %}
 
@@ -33,4 +32,4 @@
 {{super()}}
 
-
+
 {% endblock %}


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

Bug#935902: libcppunit-dev: segfault when using with a program compiled with g++-9

[Sorin Manolache]

On 28/08/2019 18.04, Rene Engelhard wrote:

[ Cc'ing the GCC maintainers ]

Hi,

On Tue, Aug 27, 2019 at 03:47:50PM +0200, Sorin Manolache wrote:

When compiling a program with g++-9 (4:9.2.1-3) and linking with libcppunit
then I get a segfault if the program uses std::stack.


Hrmpf.


For example:

void f() {
 std::stack s1;
 std::stack s2;

 std::string str;
 CPPUNIT_ASSERT(r.empty()); // segfault here
}


That isn't a complete testcase? r doesn't exist (did you mean str?) or
some of s1,s2 (empty stack)?

Does it only happen if you CPPUNT_ASSERT it or also on "normal"
std::stack usage? But I assume you file it here because it only happens
with cppunit?


Sorry, I cannot reproduce the problem any more. Maybe I had some weird 
combination of g++ packages/libs on my system that some upgrade resolved.


Anyway, here is the real test case:

#include 
#include 
#include 

class X {
private:
std::stack s1;
std::stack s2;
};

int
main(int argc, char *argv[]) {
X *x = new X();
//  delete x;
std::string r;
CPPUNIT_ASSERT(r.empty());
return 0;
}

Both valgrind and gdb reported that the problem was in the destructor 
~Message, called by CPPUNIT_ASSERT. Message contains a 
std::deque and std::stack is implemented by a std::deque.


Anyway it was quite weird because it did not crash if I had just one 
stack in class X. I had to have two of them in order to have the crash.


std::stack alone, without cppunit, worked fine.

Anyway, as said, I cannot reproduce it any more. Sorry for the false alarm.

Best regards,
Sorin

Bug#935993: nwchem: NWChem compiled with long int lapack/blas interface?

[Giacomo Mulas]

Package: nwchem
Version: 6.8.1-5
Severity: wishlist

Dear Maintainer,

I am a long time NWChem (ab)user.  I always have to compile NWChem myself,
instead of using the binary version provided by debian, because for large
enough molecules matrices become too big for the 32 bit int interface, and 
only run if NWChem was compiled with a 64 bit int lapack/blas.
I understand the need to provide a version of NWChem in debian that works
with free libs available in debian as well, hence the need (so far) to 
compile it using the 64 to 32 bit conversion of ints on 64 bit machines.
However, lapack and blas libs with 64 bit integer interfaces just appeared
on debian experimental, and have been available for some time in the 
non-free (but packaged in non-free) Intel MKL libs.
Apparently, this would require limited changes in the debian/rules file.
Would you consider building (also) such a version of nwchem, compiled with
long int blas/lapack libs? If you want to retain the current version, it 
could be a conflicting package with a slightly different name. 
Here are the environment variable definitions that would need to be included:

export BLAS_SIZE=8
export BLAS_LIB=-lmkl_blas95_ilp64 -Wl,--start-group -lmkl_gf_ilp64 
-lmkl_intel_thread -lmkl_core -Wl,--end-group -liomp5 -lpthread -lm -ldl
export LAPACK_SIZE=8
export LAPACK_LIB=-lmkl_blas95_ilp64 -lmkl_lapack95_ilp64 -Wl,--start-group 
-lmkl_gf_ilp64 -lmkl_intel_thread -lmkl_core -Wl,--end-group -liomp5 -lpthread 
-lm -ldl
export USE_SCALAPACK=yes
export SCALAPACK_SIZE=8
export SCALAPACK_LIB=-lmkl_blas95_ilp64 -lmkl_lapack95_ilp64 
-lmkl_scalapack_ilp64 -Wl,--start-group -lmkl_gf_ilp64 -lmkl_intel_thread 
-lmkl_core -lmkl_blacs_openmpi_ilp64 -Wl,--end-group -liomp5 -lpthread -lm -ldl
export SCALAPACK=-lmkl_blas95_ilp64 -lmkl_lapack95_ilp64 -lmkl_scalapack_ilp64 
-Wl,--start-group -lmkl_gf_ilp64 -lmkl_intel_thread -lmkl_core 
-lmkl_blacs_openmpi_ilp64 -Wl,--end-group -liomp5 -lpthread -lm -ldl
export HAS_BLAS="yes"
export BLASOPT="-lmkl_blas95_ilp64 -lmkl_lapack95_ilp64 -lmkl_scalapack_ilp64 
-Wl,--start-group -lmkl_gf_ilp64 -lmkl_intel_thread -lmkl_core 
-lmkl_blacs_openmpi_ilp64 -Wl,--end-group -liomp5 -lpthread -lm -ldl"
export BLACS=$(SCALAPACK)

and "make 64_to_32" and "make 32_to_64" would have to be commented out.

The libglobalarrays-dev package would also need to be compiled with the 
same lapack/blas/scalapack libs and int sizes (requiring 3 lines to be 
edited in the corresponding debian/rules).

Of course, I would be willing to help, even if I am not an official 
Debian Developer.

Thanks in advance, best regards
Giacomo Mulas

Bug#935896: add support for xrandr hotplug_mode_update property

[Martin]

Hello Yves.

Thanks for your hints. I just wanted to express that XFCE4 is unusable
in this special situation with SPICE. Bug reports should contain a line
of what the software is expected to do. Perhaps I got the wording wrong
as I'm no native speaker. I know FOSS is often maintained in free time
and appreciate that.

Nevertheless I would classify this behaviour as "bug", not "wishlist".
I will file a bug in the xfce bugtracker.

If this would be fixed in XFCE4 upstream, will it get into buster as a
fixup?

Regards,
Martin

Bug#935992: gnome-builder crashes trying to install missing flatpak platform/runtime/sdk

[Diego Escalante Urrelo]

Package: gnome-builder
Version: 3.32.0-1
Severity: important
Tags: patch

If you try to load a project that needs to download its SDK from
flatpak, it will crash gnome-builder.

To reproduce simply make sure you don't have any of the GNOME sdks
installed in flatpak and then try to setup/clone any project like Polari
or gedit, when it tries to install the missing sdk it will crash.

(trace attached)

The problem can be work-around'd by patching something very simple like
a check for NULL (attached) but according to upstream this problem was
fixed by reworking other internal APIs, thus, not easily backportable.

I'm attaching a proof of concept patch that seems to work for me.

There's also the fact that gnome-builder is trying to add
gnome.flatpakrepo, which seems to be deprecated upstream, I'm attaching
the relevant upstream commit that disabled that. That said I'm not
100% sure if it even matters (I believe it should be silently failin).

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

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

Versions of packages gnome-builder depends on:
ii  clang1:7.0-47.1
ii  dconf-gsettings-backend [gsettings-backend]  0.33.2-1
ii  exuberant-ctags  1:5.9~svn20110310-12
ii  gir1.2-dazzle-1.03.33.90-1
ii  gir1.2-ggit-1.0  0.28.0.1-1
ii  gir1.2-glib-2.0  1.60.1-1
ii  gir1.2-gtk-3.0   3.24.10-1
ii  gir1.2-gtksource-3.0 3.24.11-1
ii  gir1.2-gtksource-4   4.3.1-2
ii  gir1.2-jsonrpc-1.0   3.32.0-1
ii  gir1.2-peas-1.0  1.22.0-4
ii  gir1.2-template-1.0  3.32.0-1
ii  gir1.2-vte-2.91  0.57.90-2
ii  gir1.2-webkit2-4.0   2.25.4-1
ii  libatk1.0-0  2.33.3+really2.33.3-1
ii  libc62.29-0experimental1
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libclang1-7  1:7.0.1-9+b1
ii  libdazzle-1.0-0  3.33.90-1
ii  libdevhelp-3-6   3.32.0-1
ii  libenchant1c2a   1.6.0-11.1+b1
ii  libflatpak0  1.4.2-2
ii  libfontconfig1   2.13.1-2+b1
ii  libgdk-pixbuf2.0-0   2.39.2-3
ii  libgirepository-1.0-11.60.1-1
ii  libgit2-glib-1.0-0   0.28.0.1-1
ii  libgladeui-2-6   3.22.1-3
ii  libglib2.0-0 2.61.2-2
ii  libgspell-1-11.6.1-2
ii  libgtk-3-0   3.24.10-1
ii  libgtksourceview-4-0 4.3.1-2
ii  libjson-glib-1.0-0   1.4.4-2
ii  libjsonrpc-glib-1.0-13.32.0-1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  libpcre3 2:8.39-12+b1
ii  libpeas-1.0-01.22.0-4
ii  libsoup2.4-1 2.67.92-2
ii  libtemplate-glib-1.0-0   3.32.0-1
ii  libvala-0.44-0   0.44.7-1
ii  libvala-0.44-dev 0.44.7-1
ii  libvte-2.91-00.57.90-2
ii  libwebkit2gtk-4.0-37 2.25.4-1
ii  libxml2  2.9.8+dfsg-1+b1
ii  python3  3.7.3-1
ii  python3-gi   3.33.1-1
ii  sysprof  3.32.0-1
ii  valac-0.44-vapi  0.44.7-1

Versions of packages gnome-builder recommends:
ii  build-essential  12.7
ii  flatpak-builder  1.0.8-2
ii  gettext  0.19.8.1-9
ii  meson0.51.2-1
ii  pkg-config   0.29-6
ii  python3-jedi 0.14.1-1
ii  python3-lxml 4.4.1-1
pn  valgrind 

gnome-builder suggests no packages.

-- no debconf information
13:15:55.0181  main[ 5833]:  MESSAGE: 
Initializing with GNOME desktop and GTK+ 3.24.10.

Bug#935991: dh-runit: please avoid excessive/dangerous chown/chmod

[Daniel Kahn Gillmor]

Package: dh-runit
Version: 2.8.13.2
Tags: security
Control: affects -1 tor openssh-server

by default, dh-runit sets up logging runscripts like this:


1 #!/bin/sh
2 chown -R runit-log:adm '/var/log/runit/tor'
3 chmod 750 '/var/log/runit/tor'
4 chmod u+rw,g+r,o-rwx '/var/log/runit/tor'/*
5 exec chpst -u runit-log svlogd -tt '/var/log/runit/tor'


Lines 2 and 4 are dangerous due to linking attacks.

hardlinks and chown (line 2)


If /var/log/runit/tor happens to be on the same filesystem as another
interesting file, and fs.protected_hardlinks is not set to 1, then the
runit-log user can get read/write access to that data by hard-linking to
it, and waiting for line 2 to trigger at the next launch of the logging
process.

Even if fs.protected_hardlinks is set to 1, line 2 permits the runit-log
user to gain ownership of any file in the same filesystem that they
merely have read-write access to.

Note that fs.protected_hardlinks just protects *creation* of a hardlink
while that sysctl property is set.  So even a single reboot into a
kernel with fs.protected_hardlinks=0 by default, or a brief switch to
fs.protected_hardlinks=0 provides a window of opportunity for the
hardlink to be created, which sets the stage for the subsequent
compromise when this runscript is launched again later.  As long as the
link is made, the compromise happens at the next launch, even if
fs.protected_hardlinks is back to 1 at that point.


symlinks and chmod (line 4)
---

line 4 permits the runit-log user to change the permissions in the
specified way on *any* file in the filesystem, just by symlinking to
that file from within the specified directory.  from chmod(1):

   However, for each symbolic link listed on the command line, chmod
   changes the permissions of the pointed-to file.  In contrast,
   chmod ignores symbolic links encountered during recursive
   directory traversals.

fs.protected_symlinks=1 offers no protection against this because
/var/log/runit/tor/ is not a sticky world-writable directory.

granted, these are fairly standard constrained permissions, and won't be
a serious security risk for many files, but it is a surprising side
effect that the runit-log user gets this sort of power over any file
anywhere in the filesystem.


how to fix
--

It is a better policy to non-recursively chown/chmod the top-level
directory (/var/log/runit/tor in this example) and to not touch any file
below there.

If that strategy fails, it fails because something is already wrong in
that directory.

If the goal of this promiscuous chown/chmod action is to provide group
adm with read access to the files in question, it is better to have the
runit-log user do that explicitly (i.e. to implement it in svlogd,
perhaps with acls?).

--dkg


signature.asc
Description: PGP signature

Bug#935990: mkgmap: Boundary preprocessor and splitter throw exceptions, likely dependency issue

[Melvin Vermeeren]

Package: mkgmap
Version: 0.0.0+svn4262-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It appears something is seriously wrong with dependency versions, linkage or
similar, as both mkgmap's boundary preprocessor and mkgmap-splitter are broken,
throwing exceptions.

I cannot determine what the problem is exactly, but from what I read similar
errors often are caused by dependency version mismatches, especially with
protobuf. Perhaps the classes are compiled with a mismatched protobuf compiler
version (compared to runtime)?

Upstream pre-compiled download ships with versions:
fastutil-6.5.15-mkg.1b.jar
osmpbf-1.3.3.jar
protobuf-java-2.5.0.jar

Upstream mkgmaps-splitter ships, in addition to the above three, with versions:
xpp3-1.1.4c.jar

If I use upstream's zip file, and the upstream-provided libraries/dependencies,
everything works fine. I use an utility called vermosm for generating the maps,
the following steps will reproduce the problem using the tiny country Luxembourg
to avoid downloading big files and to avoid long processing time. Around 300MiB
will be downloaded, processing will fail very quickly after downloading.

git clone https://git.mel.vin/osm/vermosm.git vermosm
cd vermosm
# Check required dependencies in README.md, optionals not needed to reproduce.
./vermosm.sh -c luxembourg -r europe -t asset/typ/freizeitkarte_contrast.txt -v

mkgmap boundary preprocessor throws:

java.util.concurrent.ExecutionException: java.lang.UnsupportedOperationException
java.util.concurrent.ExecutionException: java.lang.UnsupportedOperationException
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
at 
uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryPreprocessor.runPreprocessing(BoundaryPreprocessor.java:186)
at 
uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryPreprocessor.main(BoundaryPreprocessor.java:129)
Caused by: java.lang.UnsupportedOperationException
at crosby.binary.Fileformat$BlobHeader.dynamicMethod(Unknown Source)
at com.google.protobuf.GeneratedMessageLite.dynamicMethod(Unknown 
Source)
at com.google.protobuf.GeneratedMessageLite.isInitialized(Unknown 
Source)
at com.google.protobuf.GeneratedMessageLite.isInitialized(Unknown 
Source)
at 
com.google.protobuf.GeneratedMessageLite.checkMessageInitialized(Unknown Source)
at com.google.protobuf.GeneratedMessageLite.parseFrom(Unknown Source)
at crosby.binary.Fileformat$BlobHeader.parseFrom(Unknown Source)
at crosby.binary.file.FileBlockHead.readHead(Unknown Source)
at crosby.binary.file.FileBlock.process(Unknown Source)
at crosby.binary.file.BlockInputStream.process(Unknown Source)
at 
uk.me.parabola.mkgmap.reader.osm.bin.OsmBinHandler.parse(OsmBinHandler.java:57)
at 
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.parse(OsmMapDataSource.java:171)
at 
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:152)
at 
uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryPreprocessor.createRawData(BoundaryPreprocessor.java:97)
at 
uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryPreprocessor.run(BoundaryPreprocessor.java:74)
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Bnd files converted in 1148 ms

mkgmap-splitter throws:

java.lang.UnsupportedOperationException
at crosby.binary.Fileformat$BlobHeader.dynamicMethod(Unknown Source)
at com.google.protobuf.GeneratedMessageLite.dynamicMethod(Unknown 
Source)
at com.google.protobuf.GeneratedMessageLite.isInitialized(Unknown 
Source)
at com.google.protobuf.GeneratedMessageLite.isInitialized(Unknown 
Source)
at 
com.google.protobuf.GeneratedMessageLite.checkMessageInitialized(Unknown Source)
at com.google.protobuf.GeneratedMessageLite.parseFrom(Unknown Source)
at crosby.binary.Fileformat$BlobHeader.parseFrom(Unknown Source)
at crosby.binary.file.FileBlockHead.readHead(Unknown Source)
at crosby.binary.file.FileBlock.process(Unknown Source)
at crosby.binary.file.BlockInputStream.process(Unknown Source)
at 
uk.me.parabola.splitter.OSMFileHandler.process(OSMFileHandler.java:98)
at uk.me.parabola.splitter.OSMFileHandler$1.run(OSMFileHandler.java:148)
uk.me.parabola.splitter.SplitFailedException: ERROR: file 
build/osm/vermosm_europe_benelux_germany_switzerland_austria.osm.pbf caused 
exception
at 

Bug#935989: ITP: python-pomegranate -- Fast, flexible and easy to use probabilistic modelling

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: python-pomegranate -- Fast, flexible and easy to use 
probabilistic modelling
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: python-pomegranate
  Version : 0.11.1
  Upstream Author : Copyright:  
* URL : https://github.com/jmschrei/pomegranate
* License : MIT
  Programming Lang: C
  Description : Fast, flexible and easy to use probabilistic modelling
 pomegranate is a package for probabilistic models in Python that is
 implemented in cython for speed. It's focus is on merging the easy-to-use
 scikit-learn API with the modularity that comes with probabilistic
 modeling to allow users to specify complicated models without needing to
 worry about implementation details. The models are built from the ground
 up with big data processing in mind and so natively support features
 like out-of-core learning and parallelism.

Remark: This package is maintained by Debian Python Modules Team at
   https://salsa.debian.org/python-team/modules/python-pomegranate

Bug#935988: buster-pu: package reportbug/7.5.2+nmu1~deb10u1

[Andreas Beckmann]

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

reportbug/buster does not know about buster being stable ...

I've just uploaded a fix to unstable via DELAYED/2, so it should be in
unstable before the weekend, still hoping for a maintainer upload.

I've included all the fixes already present in the master branch since
they are trivial:
- fix a crash
- suggest a non-transitional emacs package (that also exists in buster)
- remove some debugging output

Reviewing the diff I noticed that the .idea/ tree went missing as it is
not present in the git repository - but it is not used by the build
process, so this should do no harm.

I'll upload this to DELAYED/2, too.

Andreas

PS: I'm writing this request from 7.5.2+nmu1 running on stretch+x - and
didn't have to fix up the metadata for the first time :-)


reportbug_7.5.2+nmu1~deb10u1.dsc.diff.xz
Description: application/xz

Bug#935986: icedtea-netx: javaws eats all memory, crashing machine

[Ondrej Zary]

Package: icedtea-netx
Version: 1.7.2-2
Severity: important

Dear Maintainer,
when trying to launch (at least) iDRAC9 virtual console, javaws eats up all
the memory, machine starts thrashing to the point it requires hard reset in
a couple of seconds. Downgrading icedtea-netx to 1.6.2-3.1+deb9u1 (keeping
openjdk-11 as default) fixes the problem.

*** 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: 10.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'stable'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-5-686 (SMP w/1 CPU core)
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)

Versions of packages icedtea-netx depends on:
ii  default-jre  2:1.11-71
ii  librhino-java1.7.7.1-1
ii  libtagsoup-java  1.2.1+-1

icedtea-netx recommends no packages.

icedtea-netx suggests no packages.

-- debconf-show failed

Bug#931609: Update release names after the Buster release.

[Sandro Tosi]

please cancel the NMU, i'll update reportbug with this patch today. I
will not take care of stables uploads tho

On Wed, Aug 28, 2019 at 1:30 PM Andreas Beckmann  wrote:
>
> Control: tag -1 patch pending
>
> On Sat, 24 Aug 2019 10:11:31 +0200 Andreas Beckmann  wrote:
> > Raising the severity to serious since having a reportbug that does not
> > know about the current stable release makes its usage harder for a lot
> > of users.
> >
> > This will also need an update in stretch.
> >
> > Also oldstable_pu needs to be reenabled in debbugs.py, partially
> > reverting ef50a18677aef5d92ed3e229dabdb490b758185f (#902379).
>
> I've now uploaded a NMU (7.5.2+nmu1) to DELAYED/2 with these fixes.
> The delay is so short that the changes reach unstable before the window
> for the next buster and stretch point releases closes on the weekend.
> I intent to rebuild this as 7.5.2+nmu1~deb10u1 for buster and
> cherry-pick the relevant change for stretch.
> I've included the changes already present in the master branch in git,
> since they are trivial and suitable for buster, too: fixing a crash,
> suggesting a non-transitional emacs package, removing debug output.
>
> I've forked the repository at
> https://salsa.debian.org/anbe/reportbug.git
> The master branch is already updated, buster and stretch branches will
> follow. I'll push signed tags once the packages have been accepted by
> ftp-master.
>
> Andreas
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#935987: node-browser-resolve (build) dependency is unnecessary

[Pirate Praveen]

Package: node-rollup-plugin-node-resolve
version: 3.4.0-1

 
does not have browser-resolve in dependency.

Bug#935968: texlive-latex-extra: Font U/esint/m/n/10.95=esint10 at 10.95pt not loadable: Metric (TFM) file not found

[Eddie Saudrais]

Hi,

I just uploaded a corrected version on CTAN. I think it will be soon 
available. The cause of this problem is the automatic corrector of my 
editor...


Best

Eddie

Hi Karl, hi Eddie,


Processing file esint.dtx (muffle) -> esint10.mf)

Yes, this is wrong, since the tag in the dtx file is "mffile".
Changing the .ins file fixes everything.

Should I ask CTAN to update this little hussle so that we can re-import
from CTAN into TL?

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#935985: python3-ldap3: Value "0" not accepted for "pwdLastSet" attribute

[Lorenz Kaestle]

Package: python3-ldap3
Version: 2.4.1-1
Severity: normal
Tags: patch

Dear Maintainer,
My usecase is the creation of new accounts within a windows active directory 
enviroment.
The new account gets a one-time password which has to be changed on first login.
To use this functionality, the "pwdLastSet" attribut of the account has to be 
set to 0,
but the validation functionality of ldap3 only permits the value -1.

The problem is in the file
"/usr/lib/python3/dist-packages/ldap3/protocol/formatters/validators.py" and I
fixed it with this patch:

69c69
< """Accept -1 only (used by pwdLastSet in AD)
---
> """Accept -1 or 0 only (used by pwdLastSet in AD)
72c72
< if input_value == -1 or input_value == '-1':
---
> if input_value == -1 or input_value == '-1' or input_value == 0 or 
> input_value == "0":
76c76,77
< if len(input_value) == 1 and input_value == -1 or input_value == '-1':
---
> if (len(input_value) == 1 and input_value == -1 or input_value == 
> '-1' or
> input_value == 0 or input_value == "0"):


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-ldap3 depends on:
ii  python3 3.7.3-1
ii  python3-pyasn1  0.4.2-3

python3-ldap3 recommends no packages.

python3-ldap3 suggests no packages.

-- no debconf information
69c69
< """Accept -1 only (used by pwdLastSet in AD)
---
> """Accept -1 or 0 only (used by pwdLastSet in AD)
72c72
< if input_value == -1 or input_value == '-1':
---
> if input_value == -1 or input_value == '-1' or input_value == 0 or 
> input_value == "0":
76c76,77
< if len(input_value) == 1 and input_value == -1 or input_value == '-1':
---
> if (len(input_value) == 1 and input_value == -1 or input_value == 
> '-1' or
> input_value == 0 or input_value == "0"):
69c69
< """Accept -1 only (used by pwdLastSet in AD)
---
> """Accept -1 or 0 only (used by pwdLastSet in AD)
72c72
< if input_value == -1 or input_value == '-1':
---
> if input_value == -1 or input_value == '-1' or input_value == 0 or 
> input_value == "0":
76c76,77
< if len(input_value) == 1 and input_value == -1 or input_value == '-1':
---
> if (len(input_value) == 1 and input_value == -1 or input_value == 
> '-1' or
> input_value == 0 or input_value == "0"):

Bug#931609: Update release names after the Buster release.

[Andreas Beckmann]

Control: tag -1 patch pending

On Sat, 24 Aug 2019 10:11:31 +0200 Andreas Beckmann  wrote:
> Raising the severity to serious since having a reportbug that does not
> know about the current stable release makes its usage harder for a lot
> of users.
> 
> This will also need an update in stretch.
> 
> Also oldstable_pu needs to be reenabled in debbugs.py, partially
> reverting ef50a18677aef5d92ed3e229dabdb490b758185f (#902379).

I've now uploaded a NMU (7.5.2+nmu1) to DELAYED/2 with these fixes.
The delay is so short that the changes reach unstable before the window
for the next buster and stretch point releases closes on the weekend.
I intent to rebuild this as 7.5.2+nmu1~deb10u1 for buster and
cherry-pick the relevant change for stretch.
I've included the changes already present in the master branch in git,
since they are trivial and suitable for buster, too: fixing a crash,
suggesting a non-transitional emacs package, removing debug output.

I've forked the repository at
https://salsa.debian.org/anbe/reportbug.git
The master branch is already updated, buster and stretch branches will
follow. I'll push signed tags once the packages have been accepted by
ftp-master.

Andreas

Bug#935983: node-browser-resolve tests fail with node-resolve 1.12.0 in experimental

[Pirate Praveen]

package: node-browser-resolve
version: 1.11.3-1
severity: important

While trying to update node-resolve, I found the autopkgtest and build 
is failing with this error,


1) index.js of module dir
 ✓ alternate main
 ✓ string browser field as main
 ✓ string browser field as main - require subfile
 ✓ string alt browser field as main - require subfile
 ✓ object browser field as main
 ✓ object browser field as main
 2) deep module reference mapping
 3) deep module reference mapping without file extension - .js
 4) deep module reference mapping without file extension - .json
 ✓ object browser field replace file
 ✓ test foobar -> module-b replacement
 ✓ test core -> module-c replacement
 ✓ test core -> module-c replacement with alt browser
 ✓ test foobar -> module-b replacement with transform
 ✓ test ./x -> ./y replacement
 ✓ test foobar -> module-i replacement with transform in replacement
 ✓ object browser field replace file - no paths
 ✓ replace module in browser field object
 ✓ override engine shim
 ✓ alt-browser field
 5) alt-browser deep module reference mapping
 ✓ alt-browser fallback to "browser" on deps of deps
 6) not fail on accessing path name defined in Object.prototype

 18 passing (103ms)
 6 failing

 1) index.js of module dir:
Uncaught AssertionError [ERR_ASSERTION]: Input A expected to 
strictly equal input B:

+ expected - actual

- {
-   main: 'fixtures'
- }
+ undefined
 at /tmp/tmp.4CFPpTZnNa/test/modules.js:11:16
 at /usr/lib/nodejs/browser-resolve/index.js:269:13
 at /usr/share/nodejs/resolve/lib/async.js:93:25
 at maybeUnwrapSymlink 
(/usr/share/nodejs/resolve/lib/async.js:35:9)

 at /usr/share/nodejs/resolve/lib/async.js:89:24
 at ondir (/usr/share/nodejs/resolve/lib/async.js:264:27)
 at onex (/usr/share/nodejs/resolve/lib/async.js:161:32)
 at /usr/share/nodejs/resolve/lib/async.js:11:20
 at FSReqWrap.oncomplete (fs.js:155:5)

 2) deep module reference mapping:
Uncaught AssertionError [ERR_ASSERTION]: ifError got unwanted 
exception: Cannot find module 'module-l/direct' from 
'/tmp/tmp.4CFPpTZnNa/test/fixtures'

 at /tmp/tmp.4CFPpTZnNa/test/modules.js:95:16
 at /usr/lib/nodejs/browser-resolve/index.js:265:24
 at /usr/share/nodejs/resolve/lib/async.js:99:17
 at /usr/share/nodejs/resolve/lib/async.js:97:35
 at processDirs (/usr/share/nodejs/resolve/lib/async.js:244:39)
 at ondir (/usr/share/nodejs/resolve/lib/async.js:265:13)
 at load (/usr/share/nodejs/resolve/lib/async.js:137:43)
 at onex (/usr/share/nodejs/resolve/lib/async.js:162:17)
 at /usr/share/nodejs/resolve/lib/async.js:13:69
 at FSReqWrap.oncomplete (fs.js:154:21)

 3) deep module reference mapping without file extension - .js:
Uncaught AssertionError [ERR_ASSERTION]: ifError got unwanted 
exception: Cannot find module 'module-n/foo' from 
'/tmp/tmp.4CFPpTZnNa/test/fixtures'

 at /tmp/tmp.4CFPpTZnNa/test/modules.js:106:16
 at /usr/lib/nodejs/browser-resolve/index.js:265:24
 at /usr/share/nodejs/resolve/lib/async.js:99:17
 at /usr/share/nodejs/resolve/lib/async.js:97:35
 at processDirs (/usr/share/nodejs/resolve/lib/async.js:244:39)
 at ondir (/usr/share/nodejs/resolve/lib/async.js:265:13)
 at load (/usr/share/nodejs/resolve/lib/async.js:137:43)
 at onex (/usr/share/nodejs/resolve/lib/async.js:162:17)
 at /usr/share/nodejs/resolve/lib/async.js:13:69
 at FSReqWrap.oncomplete (fs.js:154:21)

 4) deep module reference mapping without file extension - .json:
Uncaught AssertionError [ERR_ASSERTION]: ifError got unwanted 
exception: Cannot find module 'module-n/bar' from 
'/tmp/tmp.4CFPpTZnNa/test/fixtures'

 at /tmp/tmp.4CFPpTZnNa/test/modules.js:113:16
 at /usr/lib/nodejs/browser-resolve/index.js:265:24
 at /usr/share/nodejs/resolve/lib/async.js:99:17
 at /usr/share/nodejs/resolve/lib/async.js:97:35
 at processDirs (/usr/share/nodejs/resolve/lib/async.js:244:39)
 at ondir (/usr/share/nodejs/resolve/lib/async.js:265:13)
 at load (/usr/share/nodejs/resolve/lib/async.js:137:43)
 at onex (/usr/share/nodejs/resolve/lib/async.js:162:17)
 at /usr/share/nodejs/resolve/lib/async.js:13:69
 at FSReqWrap.oncomplete (fs.js:154:21)

 5) alt-browser deep module reference mapping:

 Uncaught AssertionError [ERR_ASSERTION]: 
'/tmp/tmp.4CFPpTZnNa/test/fixtures/node_modules/alt-browser-field/direct.js' 
== 
'/tmp/tmp.4CFPpTZnNa/test/fixtures/node_modules/alt-browser-field/chromeapp-direct.js'

 + expected - actual

 
-/tmp/tmp.4CFPpTZnNa/test/fixtures/node_modules/alt-browser-field/direct.js
 
+/tmp/tmp.4CFPpTZnNa/test/fixtures/node_modules/alt-browser-field/chromeapp-direct.js


 at /tmp/tmp.4CFPpTZnNa/test/modules.js:292:16
 at /usr/lib/nodejs/browser-resolve/index.js:269:13
 at /usr/share/nodejs/resolve/lib/async.js:93:25
 at maybeUnwrapSymlink 
(/usr/share/nodejs/resolve/lib/async.js:35:9)

 at /usr/share/nodejs/resolve/lib/async.js:89:24
 

Bug#935984: freerdp-x11: crashes with illegal instruction, winpr libraries contain SSE2 instructions on i386

[Ondrej Zary]

Package: freerdp-x11
Version: 1.1.0~git20140921.1.440916e+dfsg1-13+deb9u3
Severity: important

Dear Maintainer,
freerdp is not usable on i386 machines without SSE2 - crashes immediately:

$ freerdp 1.2.3.4
WARNING: Using deprecated command-line interface!
1.2.3.4 -> /v:1.2.3.4
connected to 1.2.3.4:3389
Password:
Illegal instruction

winpr libraries are compiled with SSE2 instructions:

$ cat ~/sse2_test.sh
#!/bin/sh
echo "$1"
objdump -d "$1" | grep xmm

/usr/lib/i386-linux-gnu$ find . -type f -name \*winpr\* -exec ~/sse2_test.sh 
\{\} \;
./libwinpr-interlocked.so.0.1.0
 a8a:   f3 0f 7e 44 24 18   movq   0x18(%esp),%xmm0
 a98:   66 0f 7e c0 movd   %xmm0,%eax
 aa0:   66 0f 73 d0 20  psrlq  $0x20,%xmm0
 aa5:   66 0f 7e c2 movd   %xmm0,%edx
 b09:   f3 0f 7e 44 24 28   movq   0x28(%esp),%xmm0
 b0f:   66 0f d6 44 24 0c   movq   %xmm0,0xc(%esp)
./libwinpr-file.so.0.1.0
./libwinpr-error.so.0.1.0
./libwinpr-crt.so.0.1.0
./libwinpr-rpc.so.0.1.0
3a3f:   66 0f ef c0 pxor   %xmm0,%xmm0
3a43:   0f 12 82 ec 03 00 00movlps 0x3ec(%edx),%xmm0
3a4a:   0f 16 82 f4 03 00 00movhps 0x3f4(%edx),%xmm0
3a51:   0f 13 00movlps %xmm0,(%eax)
3a54:   0f 17 40 08 movhps %xmm0,0x8(%eax)
./libwinpr-sysinfo.so.0.1.0
./libwinpr-sspi.so.0.1.0
6476:   f3 0f 7e 42 08  movq   0x8(%edx),%xmm0
647b:   66 0f d6 46 08  movq   %xmm0,0x8(%esi)
6489:   f3 0f 7e 48 08  movq   0x8(%eax),%xmm1
648e:   66 0f d6 4e 10  movq   %xmm1,0x10(%esi)
65c5:   f3 0f 7e 46 08  movq   0x8(%esi),%xmm0
65ca:   66 0f d6 00 movq   %xmm0,(%eax)
65d7:   f3 0f 7e 4e 10  movq   0x10(%esi),%xmm1
65dc:   66 0f d6 48 08  movq   %xmm1,0x8(%eax)
66a1:   66 0f ef c0 pxor   %xmm0,%xmm0
66c1:   0f 12 01movlps (%ecx),%xmm0
66c4:   0f 16 41 08 movhps 0x8(%ecx),%xmm0
66c8:   0f 13 40 f0 movlps %xmm0,-0x10(%eax)
66cc:   0f 17 40 f8 movhps %xmm0,-0x8(%eax)
66f1:   66 0f ef c0 pxor   %xmm0,%xmm0
670e:   0f 12 00movlps (%eax),%xmm0
6711:   0f 16 40 08 movhps 0x8(%eax),%xmm0
6718:   0f 13 01movlps %xmm0,(%ecx)
671b:   0f 17 41 08 movhps %xmm0,0x8(%ecx)
6810:   f3 0f 7e 86 34 0a 00movq   0xa34(%esi),%xmm0
6818:   66 0f d6 86 2c 0a 00movq   %xmm0,0xa2c(%esi)
6a60:   f3 0f 7e 86 3c 0a 00movq   0xa3c(%esi),%xmm0
6a68:   f3 0f 7e 8e 44 0a 00movq   0xa44(%esi),%xmm1
6a7d:   66 0f d6 44 24 2c   movq   %xmm0,0x2c(%esp)
6a83:   66 0f d6 4c 24 34   movq   %xmm1,0x34(%esp)
6ac9:   f3 0f 7e 96 44 0a 00movq   0xa44(%esi),%xmm2
6ad1:   66 0f d6 57 10  movq   %xmm2,0x10(%edi)
6c40:   f3 0f 7e 8d 2c 0a 00movq   0xa2c(%ebp),%xmm1
6c48:   66 0f d6 48 08  movq   %xmm1,0x8(%eax)
6c4d:   f3 0f 7e 95 44 0a 00movq   0xa44(%ebp),%xmm2
6c55:   66 0f d6 50 10  movq   %xmm2,0x10(%eax)
6c90:   f3 0f 7e 9d 3c 0a 00movq   0xa3c(%ebp),%xmm3
6c98:   66 0f d6 18 movq   %xmm3,(%eax)
6d11:   66 0f ef c0 pxor   %xmm0,%xmm0
6d15:   0f 12 44 24 5c  movlps 0x5c(%esp),%xmm0
6d1a:   0f 16 44 24 64  movhps 0x64(%esp),%xmm0
6d1f:   0f 13 00movlps %xmm0,(%eax)
6d26:   0f 17 40 08 movhps %xmm0,0x8(%eax)
7084:   66 0f ef c0 pxor   %xmm0,%xmm0
7088:   0f 12 80 4c 0a 00 00movlps 0xa4c(%eax),%xmm0
708f:   0f 16 80 54 0a 00 00movhps 0xa54(%eax),%xmm0
7096:   0f 13 80 5c 0a 00 00movlps %xmm0,0xa5c(%eax)
709d:   0f 17 80 64 0a 00 00movhps %xmm0,0xa64(%eax)
70e4:   66 0f ef c0 pxor   %xmm0,%xmm0
70e8:   0f 12 80 6c 0a 00 00movlps 0xa6c(%eax),%xmm0
70ef:   0f 16 80 74 0a 00 00movhps 0xa74(%eax),%xmm0
70f6:   0f 13 80 7c 0a 00 00movlps %xmm0,0xa7c(%eax)
70fd:   0f 17 80 84 0a 00 00movhps %xmm0,0xa84(%eax)
721b:   66 0f ef c0 pxor   %xmm0,%xmm0
7222:   0f 12 07movlps (%edi),%xmm0
7225:   0f 16 47 08 movhps 0x8(%edi),%xmm0
722e:   0f 13 00movlps %xmm0,(%eax)
7231:   0f 17 40 08 movhps %xmm0,0x8(%eax)
741e:   66 0f ef c0 pxor   %xmm0,%xmm0
7422:   0f 12 07movlps (%edi),%xmm0
7425:   0f 16 47 08 movhps 0x8(%edi),%xmm0
7429:   0f 13 02movlps %xmm0,(%edx)
742c:   0f 17 42 08 movhps %xmm0,0x8(%edx)
78b9:   f3 0f 7e 00 movq   (%eax),%xmm0

Bug#935982: chromium: DRM TV doesn't work

[Christian Marillat]

Package: chromium
Version: 76.0.3809.100-1
Severity: normal

Dear Maintainer,

I can't acces my TV channels protected by DRM

May be related to another library. I downgraded to 75.0.3770.80-1 uplaoded
in june 2019 and the problem is still here wqere I was able to wath TV with
this version.

Christian

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

Kernel: Linux 4.19.68 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages chromium depends on:
ii  chromium-common  76.0.3809.100-1
ii  libasound2   1.1.8-1
ii  libatk-bridge2.0-0   2.32.0-6
ii  libatk1.0-0  2.33.3+really2.32.0-4
ii  libatomic1   9.2.1-6
ii  libatspi2.0-02.32.1-4
ii  libavcodec58 10:4.2-dmo4
ii  libavformat5810:4.2-dmo4
ii  libavutil56  10:4.2-dmo4
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcups2 2.2.12-1
ii  libdbus-1-3  1.12.16-1
ii  libdrm2  2.4.99-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.7-1
ii  libflac8 1.3.3-1
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.60.6-2
ii  libgtk-3-0   3.24.10-1
ii  libharfbuzz0b2.6.1-2
ii  libicu63 63.2-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3+b1
ii  liblcms2-2   2.9-3+b1
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.21-2
ii  libnss3  2:3.45-1
ii  libopenjp2-7 2.3.0-2
ii  libopus0 1.3-1+b1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpci3  1:3.6.2-2
ii  libpng16-16  1.6.37-1
ii  libpulse012.99.2-1
ii  libre2-5 20190801+dfsg-1
ii  libsnappy1v5 1.1.7-1+b1
ii  libstdc++6   9.2.1-6
ii  libvpx6  1.8.1-dmo1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2.1
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages chromium recommends:
pn  chromium-sandbox  

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

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

Versions of packages chromium-common recommends:
pn  chromium-sandbox 
pn  fonts-liberation 
ii  libgl1-mesa-dri  19.1.4-1
pn  libu2f-udev  
ii  notification-daemon  3.20.0-4
pn  system-config-printer
pn  upower   
ii  xfce4-notifyd [notification-daemon]  0.4.4-1

-- no debconf information

Bug#935981: akonadi: Akonadi stops anwsering any requests and ends in deadlock

[Sandro Knauß]

Source: akonadi
Version: 4:18.08.3-5
Severity: important
Forwarded: https://bugs.kde.org/show_bug.cgi?id=399167

Symptoms:

After a while Akonadi stops responing any request and you can not
interact with Akonadi anymore. It seems to hit many people rather badly
-- akonadi won't answer to any requests once hitting that bug, and even
a reboot only help very temporarily (until the faulty folder gets synced
again).

Upstream has already proposed patches for this bug see either
https://bugs.kde.org/show_bug.cgi?id=399167

these to patches should fix this bug:
https://commits.kde.org/akonadi/15c91a0ac93051465b37807efceb6e9fd36cb73b
https://commits.kde.org/akonadi/4fb179ce46ad3e7da8b25c921b0c8a68f9dfb4ee

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

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

Bug#935948: can't start containers with different names but same prefix (xxxxxxxxxxx-1 and xxxxxxxxxxx-2)

[Michael Biebl]

Am 28.08.19 um 13:11 schrieb Trent W. Buck:

> If this is an unavoidable limitation due to Linux, please at least
> warn about it in the systemd-nspawn manpage.

I've forwarded this upstream to
https://github.com/systemd/systemd/issues/13417 where it was mentioned
that this topic had already come up and the fix was to document this
limitation. See

https://github.com/systemd/systemd/pull/11989/commits/6cc68362d529ca8b99fd6ca55b0fc7143e696aea

Have you seen this paragraph in systemd-nspawn?

I invite you to join the upstream bug tracker if you have further feedback.
Otherwise I'm going to close this bug report as this limitation is
actually documented:

>Note that on Linux network interface names may have a length of 15 
> characters at maximum, while container names may have a length up to 64 
> characters. As this option derives the host-side interface name from the
>container name the name is possibly truncated. Thus, care needs to 
> be taken to ensure that interface names remain unique in this case, or even 
> better container names are generally not chosen longer than 12
>characters, to avoid the truncation. Alternatively, the 
> --network-veth-extra= option may be used, which allows free configuration of 
> the host-side interface name independently of the container name — but might
>require a bit more additional configuration in case bridging in a 
> fashion similar to --network-bridge= is desired.




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#935980: jackd2: Segfaults when qjackctl patchbay is activated

[Christopher David Howie]

Package: jackd2
Version: 1.9.12~dfsg-2

jackd segfaults whenever the qjackctl patchbay is activated with a
non-empty set of patches.  It's not clear to me exactly why this
happens, but it happens every time.

I run jackd like so:

$ jackd -R -d net -a 192.168.3.3

Here is jackd's output:

--8<--
jackdmp 1.9.12
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2017 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
NetDriver started in async mode without Master's transport sync.
Waiting for a master...
Initializing connection with burke...
 Network parameters 
Name : liz
Protocol revision : 8
MTU : 1500
Master name : burke
Slave name : liz
ID : 5
Transport Sync : no
Send channels (audio - midi) : 12 - 0
Return channels (audio - midi) : 14 - 0
Sample rate : 44100 frames per second
Period size : 256 frames per period
Network latency : 5 cycles
SampleEncoder : Float
Slave mode : async

JackGraphManager::Connect already connected port_src = 64 port_dst = 41
JackGraphManager::Connect already connected port_src = 65 port_dst = 42
JackGraphManager::Connect already connected port_src = 47 port_dst = 41
JackGraphManager::Connect already connected port_src = 48 port_dst = 42
JackGraphManager::Connect already connected port_src = 52 port_dst = 41
JackGraphManager::Connect already connected port_src = 53 port_dst = 42
JackGraphManager::Connect already connected port_src = 43 port_dst = 78
JackGraphManager::Connect already connected port_src = 90 port_dst = 78
JackGraphManager::Connect already connected port_src = 44 port_dst = 82
JackGraphManager::Connect already connected port_src = 91 port_dst = 82
JackGraphManager::Connect already connected port_src = 59 port_dst = 41
JackGraphManager::Connect already connected port_src = 60 port_dst = 42
JackGraphManager::Connect already connected port_src = 73 port_dst = 41
JackGraphManager::Connect already connected port_src = 74 port_dst = 42
JackGraphManager::Connect already connected port_src = 77 port_dst = 49
JackGraphManager::Connect already connected port_src = 77 port_dst = 70
JackGraphManager::Connect already connected port_src = 89 port_dst = 49
JackGraphManager::Connect already connected port_src = 89 port_dst = 70
JackGraphManager::Connect already connected port_src = 64 port_dst = 41
JackGraphManager::Connect already connected port_src = 65 port_dst = 42
JackGraphManager::Connect already connected port_src = 1 port_dst = 27
JackGraphManager::Connect already connected port_src = 59 port_dst = 41
JackGraphManager::Connect already connected port_src = 60 port_dst = 42
JackGraphManager::Connect already connected port_src = 43 port_dst = 78
JackGraphManager::Connect already connected port_src = 44 port_dst = 82
JackGraphManager::Connect already connected port_src = 77 port_dst = 49
JackGraphManager::Connect already connected port_src = 77 port_dst = 70
JackGraphManager::Connect already connected port_src = 90 port_dst = 78
JackGraphManager::Connect already connected port_src = 91 port_dst = 82
--8<--

At this point, I enable the patchbay in qjackctl.  jackd immediately
terminates with "Segmentation fault" and no further output.

-- 
Chris Howie
http://www.chrishowie.com
http://en.wikipedia.org/wiki/User:Crazycomputers

If you correspond with me on a regular basis, please read this document:
http://www.chrishowie.com/email-preferences/

PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5


IMPORTANT INFORMATION/DISCLAIMER

This document should be read only by those persons to whom it is
addressed.  If you have received this message it was obviously addressed
to you and therefore you can read it.

Additionally, by sending an email to ANY of my addresses or to ANY
mailing lists to which I am subscribed, whether intentionally or
accidentally, you are agreeing that I am "the intended recipient," and
that I may do whatever I wish with the contents of any message received
from you, unless a pre-existing agreement prohibits me from so doing.

This overrides any disclaimer or statement of confidentiality that may
be included on your message.

Bug#935946: iputils-arping: -w (deadline) broken

[Noah Meyerhans]

Control: tags -1 + confirmed upstream

On Wed, Aug 28, 2019 at 11:52:15AM +0200, Lucas Nussbaum wrote:
> arping -w doesn't work anymore. Instead of exiting when the deadline is
> reached, it just hangs.
> 
> # arping -w 2 -f -I eno1 172.17.49.5
> ARPING 172.17.49.5 from 172.16.72.51 eno1
> 
> Sent 172 probes (172 broadcast(s))
> Received 0 response(s)
> 
> It worked fine with 3:20180629-2:
> # arping -w 2 -f -I eno1 172.17.49.5
> ARPING 172.17.49.5 from 172.16.72.51 eno1
> Sent 3 probes (3 broadcast(s))
> Received 0 response(s)

Git bisect indicates that it was broken with upstream commit
67e070d08dcbec990e1178360f82b3e2ca4f6d5f

There's a followup commit to that,
84ca65ca980315c73f929fed8b6f16bbd698c3a0, which includes in its log "Oh
my, that is pretty much as wrong the code could have been." I suspect
that not all the issues have been sorted out there.

noah

Bug#935968: texlive-latex-extra: Font U/esint/m/n/10.95=esint10 at 10.95pt not loadable: Metric (TFM) file not found

[Norbert Preining]

Hi Karl, hi Eddie,

> Processing file esint.dtx (muffle) -> esint10.mf)

Yes, this is wrong, since the tag in the dtx file is "mffile".
Changing the .ins file fixes everything.

Should I ask CTAN to update this little hussle so that we can re-import
from CTAN into TL?

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#934122: borgmatic: "validate-borgmatic-config" is not found

[Sebastien Badia]

Hi Johan,

I just prepared two merge-request in order to update borgmatic to the
latest version.

  https://salsa.debian.org/debian/borgmatic/merge_requests/1
  https://salsa.debian.org/debian/borgmatic/merge_requests/2

Thanks in advance !

Cheers,


signature.asc
Description: PGP signature

Bug#935607: lintian: classify "Starting $DESC" in init.d scripts

[Dmitry Bogatov]

control: tags -1 -moreinfo

[2019-08-27 10:23] "Chris Lamb" 
> Hi Dmitry,
>
> > [ Should I tag '-moreinfo' on reply, or you prefer doing it yourself? ]
>
> Please. A wishlist bug with "moreinfo" means (at least for me) that it
> is blocking on input from the reporter/requester and, if you believe
> you have resolved all the outstanding queries, then it makes sense to
> remove it so that it's easier to find things in the BTS that are ready
> to be worked on. Does that make sense?

Sure, it does. Just double-checked to not disrupt your workflow.

> > > > [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
> > >
> > > Can you describe what is wrong with this? (So we can add it to the
> > > long description at the very least...)
> > 
> > Both behaviours are fine, as long they are used consistently.
>
> Oh, I think I see. Well, actually I was confused about this bug and
> indeed am not sure enough to implement anything yet. The problem is
> the use of the conditional checking of $VERBOSE, regardless of the
> action?
>
> I think what would be good is bunch of "good" and "bad" examples here
> to help me be 100% sure.

Again, there is no "good" and "bad" yet. Here is pseudo-code:

for line in lines(/etc/init.d/script) {
next unless if line =~ 'log daemon msg "(Starting|Stopping)';
if line =~ '$VERBOSE' {
classify 'do check for VERBOSE'
} else {
classify 'do NOT check for VERBOSE'
}
}

When we see, which of these styles is majority, we can proclaim other
unwanted and to be fixed.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#934500: dh-runit: permissions of supervise directory

[Dmitry Bogatov]

[2019-08-27 16:35] Jan Braun 
> > > Personally, I'd prefer linking /etc/sv/foo/supervise to a place of my
> > > choosing and expect that link to be preserved. Not sure how others
> > > would feel, or how they'd try to deal with the issue.
> > 
> > Why would you need it? Content of 'supervise' directory is transient,
> > there is nothing valuable in it.
>
> Except the permissions, if non-default.

Okay.

> > While I understand desire to make things as configurable as possible, it
> > will put burden of /properly/ purging things from dpkg to me, which I'd
> > rather avoid.
>
> Are you saying "me" as in the Debian maintianier of runit, or "me" as in
> the local admin of the machine in question?

As Debian maintainer.

> When I add files in non-default locations, I expect dpkg/maintainer
> scripts not to touch them,

This. Maintainers scripts is my burden.

> and possibly dpkg to message me "directory /some/path not empty, not
> removed" when purging the package, alerting me that I might need to
> clean up manually. I think that kind of behaviour is required by
> debian policy, it has worked whenever I needed it in the past, and
> AFAICT it works with the runit* packages right now. So there should be
> no additional burden on you, the Debian maintainer.

That is the point. dpkg manages files that are part of package (as of
dpkg -L), that is why I want make /etc/sv/foo/service symlink part of
package.

If I create something in maintainer script, I have to purge it in
maintainer script, with all kinds of interesting corner cases (e.g
#848239 #848240)

> If you meant the purging of /var/lib/runit/supervise/foo in case the
> runit* packages decide to put things there by default, that's an
> unconditional "rm -rf" in the appropriate maintainer script and not much
> of a burden. Or am I missing something there?

If admin put something valuable in /var/lib/runit/supervise/foo I have
to re-implement (see runit-helper source) "directory not empty, not
removing" logic.

> As to where Debian's runit should point the symlink by default:
>
> /var/lib/runit/supervise/foo:
> + persists non-default supervise dir permissions at no cost to the
>   local admin.
> - unneccessarily persists the rest of the supervise dir.
> /run/runit/supervise/foo:
> - requires admin effort to get persistent non-default supervise dir
>   permissions.
> + saves writes to a durable medium during operation.
>
> I don't really have a preference here.

Thanks for this summary. I did not thought about saving writes.

As I pointed above I have strong preference for /run/runit. Actually, I
consider /var/lib/runit/supervise major design error of mine.

> And I don't need to. :) Because on my machines, I'm back to a ramdisk on
> /etc/service, which:
> + persists exactly what it's told to (by placing it in /etc/sv )
> + saves writes to durable storage
> - requires a reboot or other admin action to apply their /etc/sv
>   changes to the ramdisk. :(
>
> I doubt that's an acceptable default configuration for Debian, but it's
> implemented as an option with very little effort:
> * a few lines setting up the ramdisk in /etc/runit/2 (conditional on
>   /etc/service being a symlink to /run/service),
> * a one-line change preventing /lib/runit/invoke-run from dying to
>   the changed path¹,
> * a new script (or patch to update-service) to implement said
>   admin action without rebooting.
> Holler if you're interested in adding it to Debian. (Which would be
> nice, but I can live very well on my local modifications too.) Not sure
> if having this as an option should tilt the /run vs. /var decision.

While I see advantages of your setup, I am not ready to support it
Debian-wide, in numerous Debian configurations. What I can offer is
following:

 * I can bundle your /etc/runit/2 in /usr/share/doc/runit/contrib, with
   clear notice that this setup is not officially supported by Debian,
   but is succesfully used by some admins.

 * You can propose patch for update-service. As long it still work
   with default configuration and does not introduces too much
   complexity, I am okay to apply it. Lorenzo knows better about
   `update-service` than me.

 * You can file bug on `invoke-run`, we will see what can be amended.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#935902: libcppunit-dev: segfault when using with a program compiled with g++-9

[Rene Engelhard]

[ Cc'ing the GCC maintainers ]

Hi,

On Tue, Aug 27, 2019 at 03:47:50PM +0200, Sorin Manolache wrote:
> When compiling a program with g++-9 (4:9.2.1-3) and linking with libcppunit
> then I get a segfault if the program uses std::stack.

Hrmpf.

> For example:
> 
> void f() {
> std::stack s1;
> std::stack s2;
> 
> std::string str;
> CPPUNIT_ASSERT(r.empty()); // segfault here
> }

That isn't a complete testcase? r doesn't exist (did you mean str?) or
some of s1,s2 (empty stack)?

Does it only happen if you CPPUNT_ASSERT it or also on "normal"
std::stack usage? But I assume you file it here because it only happens
with cppunit?

> It suffices to rebuild the package by compiling it with g++-9 and the segfault
> does not occur any more.

Strictly speaking this would be a bug (or some known change?) in
gcc/libstdc++6 then?

Regards,

Rene

Bug#935979: node-object-assign: Don't publish object.assign module

[Xavier Guimard]

Package: node-object-assign
Version: 4.1.1-2
Severity: important

node-object-assign publishes a /usr/lib/nodejs/object.assign link, this
is bad since object.assign is a different module with different
functions (getPolyfill function for example).

Bug#935951: fonts-noto-color-emoji: was updated on August 2019 to support Unicode 12.0 Emoji

[Jeremy Bicha]

On Wed, Aug 28, 2019 at 7:27 AM Ryutaroh Matsumoto
 wrote:
> Google updated the font to support Unicode 12.0 on August 2019 at
> https://github.com/googlefonts/noto-emoji/blob/master/NotoColorEmoji.ttf

Google has not officially released the font update. Google tends to
not make an official release of the Unicode update until the new
Android version is released. Android 10 is expected to be released in
a few days.

https://github.com/googlefonts/noto-emoji/releases

Thanks,
Jeremy Bicha

Bug#935968: texlive-latex-extra: Font U/esint/m/n/10.95=esint10 at 10.95pt not loadable: Metric (TFM) file not found

[Karl Berry]

esint10.mf
is empty, besides comments and a lone
\endinput

Is this on purpose?

No, I just didn't notice. In the 2019/07/19 update of esint, esint10.mf
is supposed to be generated from esint.dtx, while only that stub file in
fact shows up. I am not sure. Running the .ins shows:

Processing file esint.dtx (muffle) -> esint10.mf)

And I wonder if that "muffle" should be "mffile", as the dtx has:
%<*mffile>
% Computer Modern Math Extension 10 point
..

I can't dig further right now. Eddie, help, please?

By the way, once the real esint10.mf is there again, the tfm will be
made automatically.

Also, the real esint10.mf is available in any previous release.

Thanks,
Karl

Bug#935978: vala-panel-appmenu: drop recommends: on obsolete, removed appmenu-qt

[Steve Langasek]

Package: vala-panel-appmenu
Version: 0.7.3+dfsg1-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear maintainers,

The vala-panel-appmenu binary packages all recommend the obsolete and
now-removed appmenu-qt, which is qt4-based.

The packages should drop the recommends, so that on upgrade this obsolete
qt4 package is not kept installed on user systems.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru vala-panel-appmenu-0.7.3+dfsg1/debian/control 
vala-panel-appmenu-0.7.3+dfsg1/debian/control
--- vala-panel-appmenu-0.7.3+dfsg1/debian/control   2019-08-06 
16:21:45.0 -0700
+++ vala-panel-appmenu-0.7.3+dfsg1/debian/control   2019-08-28 
08:46:23.0 -0700
@@ -32,8 +32,7 @@
  appmenu-registrar (>= 0.7.1),
  ${misc:Depends},
  ${shlibs:Depends},
-Recommends: appmenu-qt,
-appmenu-qt5,
+Recommends: appmenu-qt5,
 libdbusmenu-glib4,
 libdbusmenu-gtk3-4,
 libdbusmenu-gtk4,
@@ -54,8 +53,7 @@
  appmenu-registrar (>= 0.7.1),
  ${misc:Depends},
  ${shlibs:Depends},
-Recommends: appmenu-qt,
-appmenu-qt5,
+Recommends: appmenu-qt5,
 libdbusmenu-glib4,
 libdbusmenu-gtk3-4,
 libdbusmenu-gtk4,
@@ -75,8 +73,7 @@
  appmenu-registrar (>= 0.7.1),
  ${misc:Depends},
  ${shlibs:Depends},
-Recommends: appmenu-qt,
-appmenu-qt5,
+Recommends: appmenu-qt5,
 libdbusmenu-glib4,
 libdbusmenu-gtk3-4,
 libdbusmenu-gtk4,
@@ -96,8 +93,7 @@
  appmenu-registrar (>= 0.7.1),
  ${misc:Depends},
  ${shlibs:Depends},
-Recommends: appmenu-qt,
-appmenu-qt5,
+Recommends: appmenu-qt5,
 libdbusmenu-glib4,
 libdbusmenu-gtk3-4,
 libdbusmenu-gtk4,

Bug#829445: Be more clever about branch names

[Guido Günther]

Hi,
On Wed, Aug 28, 2019 at 05:23:42PM +0200, Andrej Shadura wrote:
> On Sun, 3 Jul 2016 13:31:07 +0200 Guido Günther  wrote:
> > Having to adjust gbp.conf when going from debian/sid to
> > debian/experimental and back isn't helpful. It would be better if we'd
> > drive the debian branch from the changelog and:
> > 
> > * don't complain about not matching branches if the entry is UNRELEASED
> > * complain if the current branch doesn't match the distribution in the
> >   changelog
> > 
> > Does this make sense?
> I think this (and #829444) could be technically implemented by adding a
> substitution variable, "release" or such and defaulting the branches to
> debian/%(release)s etc.
> 
> I’m also thinking detecting the branch format automatically could also
> be useful (master or %(release)s + upstream or debian/master or
> debian/%(release)s + upstream/*).

i'd be happy to see patches for this.
 -- Guido

> 
> -- 
> Cheers,
>   Andrej
> 

Bug#935977: RM: gnuplot [mipsel] -- ROM; FTBFS on deprecated platform (mipsel)

[Anton Gladky]

Package: ftp.debian.org
Severity: normal

Dear FTP team,

gnuplot fails to compile on mipsel. As this architecture
considered to be removed from official archs, I do not
see a motivation to fix it there.

Thanks

Anton

Bug#935976: stretch-pu: package node-ws/1.1.0+ds1.e6ddaae4-3+deb9u1

[Xavier Guimard]

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

Hi,

During buster release, we fixed CVE-2016-10542 for node-ws. The same
patch can be applied in Stretch.

Cheers,
Xavier
diff --git a/debian/changelog b/debian/changelog
index e9c9c75..a9bedaf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-ws (1.1.0+ds1.e6ddaae4-3+deb9u1) stretch; urgency=medium
+
+  * Add patch to fix upload size to a sane value
+(Closes: #927671, CVE-2016-10542)
+
+ -- Xavier Guimard   Wed, 28 Aug 2019 17:25:11 +0200
+
 node-ws (1.1.0+ds1.e6ddaae4-3) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/node-ads-120.diff b/debian/patches/node-ads-120.diff
new file mode 100644
index 000..2862cd2
--- /dev/null
+++ b/debian/patches/node-ads-120.diff
@@ -0,0 +1,19 @@
+Description: Fix upload default size to a sane value
+Author: Arnout Kazemier 
+Origin: upstream, 
https://github.com/websockets/ws/commit/0328a8f49f004f98d2913016214e93b2fc2713bc
+Bug: https://www.npmjs.com/advisories/120
+Bug-Debian: https://bugs.debian.org/927671
+Reviewed-By: Xavier Guimard 
+Last-Update: 2019-04-21
+
+--- a/lib/WebSocketServer.js
 b/lib/WebSocketServer.js
+@@ -37,7 +37,7 @@
+ disableHixie: false,
+ clientTracking: true,
+ perMessageDeflate: true,
+-maxPayload: null
++maxPayload: 100 * 1024 * 1024
+   }).merge(options);
+ 
+   if (!options.isDefinedAndNonNull('port') && 
!options.isDefinedAndNonNull('server') && !options.value.noServer) {
diff --git a/debian/patches/series b/debian/patches/series
index e26c50c..23aa21f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -5,3 +5,4 @@ rm-redundant-legacy-include
 disable-debian-failing-tests
 fix-failing-tests
 increase-test-timeout
+node-ads-120.diff

Bug#829445: Be more clever about branch names

[Andrej Shadura]

On Sun, 3 Jul 2016 13:31:07 +0200 Guido Günther  wrote:
> Having to adjust gbp.conf when going from debian/sid to
> debian/experimental and back isn't helpful. It would be better if we'd
> drive the debian branch from the changelog and:
> 
> * don't complain about not matching branches if the entry is UNRELEASED
> * complain if the current branch doesn't match the distribution in the
>   changelog
> 
> Does this make sense?
I think this (and #829444) could be technically implemented by adding a
substitution variable, "release" or such and defaulting the branches to
debian/%(release)s etc.

I’m also thinking detecting the branch format automatically could also
be useful (master or %(release)s + upstream or debian/master or
debian/%(release)s + upstream/*).

-- 
Cheers,
  Andrej

Bug#935975: ITP: r-cran-rslurm -- Submit R Calculations to a Slurm Cluster

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-rslurm -- Submit R Calculations to a Slurm Cluster
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-rslurm
  Version : 0.4.0
  Upstream Author : Copyright: (FIXME: year)-2017 Philippe Marchand,
* URL : https://cran.r-project.org/package=rslurm
* License : GPL-3
  Programming Lang: GNU R
  Description : Submit R Calculations to a Slurm Cluster
 Functions that simplify submitting R scripts to a Slurm workload
 manager, in part by automating the division of embarrassingly parallel
 calculations across cluster nodes.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-rslurm

Bug#935771: openafs-modules-source: Tries to use missing cc-wrapper with ctfutils installed

[Aaron M. Ucko]

Benjamin Kaduk  writes:

> Sure, and thanks for the report -- upstream made this change in

Thanks for the explanation; I'd gathered something of the sort from
commit logs.

> I'd be vaguely curious if you wanted to drop in the cc-wrapper from a full
> source tree and see if it produced anything useful, though I agree that
> just configuring with --without-ctf-tools would be a fine workaround for
> now.

I'd be surprised to see any practical benefit to pushing forward on
Linux.  (kFreeBSD or Dyson might get something out of it, though.)  That
said, I suppose it probably wouldn't hurt, apart from moderately(?)
increasing the footprint of module builds on affected hosts. At any
rate, please note that cc-wrapper bakes in the detected paths to these
tools, so if you do push forward, you should either drop in
cc-wrapper.in or add a build dependency on ctfutils.  (AFAICT, in the
latter case you could still leave openafs-modules-*'s dependencies as is.)

> Thanks for the report,

Thanks for looking into it!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#935974: xfce4-time-out-plugin: Please, add xfce4-time-out-plugin to official repos

[jEsuSdA]

Package: xfce4-time-out-plugin
Severity: wishlist

Dear Maintainer,

Hi!

Please, could you add the xfce4-time-out-plugin to the Debian repository.

This is a nice utility and it is available in other distros, some Debian based
distros included like Ubuntu.

In fact, I tried to install the ubuntu package and it works well.

Thanks a lot.



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

Kernel: Linux 5.2.0-9.1-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), 
LANGUAGE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#914641: faad2: CVE-2018-19502 CVE-2018-19503 CVE-2018-19504 CVE-2019-6956

[Hugo Lefeuvre]

Hi Fabian,

> > Please let me know if you want me to change anything, otherwise I am
> > waiting for your ack to upload.
> 
> Please go ahead!

OK, uploaded.

> Is the list of closed CVEs complete?

Yes, everything fixed in sid!

cheers,
Hugo

-- 
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C


signature.asc
Description: PGP signature

Bug#935973: debian-installer: cryptsetup-initramfs will not be installed even when using full-disk encryption.

[Mad Horse]

Package: debian-installer
Severity: important

Dear Maintainer,

The package "cryptsetup-initramfs" will not be installed even root file
system
is configured to be on a logical volume on an LVM PV inside a LUKS,
making the
installed system stuck in initramfs, unless we manually install cryptsetup-
initramfs with rescue mode, or possibly before rebooting from
debian-installer
when installation is "finished".



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

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

Bug#923851: RFP: ghidra -- Ghidra is a software reverse engineering framework

[Yangfl]

Debian's Java toolchain is virtually broken; see blocking bug #926714

Gmail  于2019年8月28日周三 下午10:09写道：
>
> On Thu, 21 Mar 2019 11:22:28 +0800 Yangfl wrote:
>
> I'm willing to package it, as long as they publish its source!
>
>
>
> Any update on this?
>
> As Antonio mentioned the Ghidra source has been published: 
> https://github.com/NationalSecurityAgency/ghidra
>
> Best,
> Harsha