Bug#927126: Bug#929342: Bug#930393: RFS: aqemu/0.9.2-2.3 [NMU] [RC] -- Fix #927126 including suggestion from #929342 - aqemu: after updating can't open VMs

[Paul Gevers]

Hi,

On 14-06-2019 21:47, gregor herrmann wrote:
> On Tue, 11 Jun 2019 22:25:06 +0200, Alexis Murzeau wrote:
> 
>> I am looking for a sponsor for a NMU of "aqemu" to fix this RC bug:
>> #927126  - aqemu: after updating can't open VMs [0].
>> This bug was fixed in previous NMU aqemu/0.9.2-2.2 bug after discussion
>> with release team in #929342 [1], I modified the fix before being able
>> to migrate to buster.
>>
>> This NMU remove references to VLANs in the description texts.
> 
> Uploaded. Thanks for your work.

Unblocked, thanks

Paul

Bug#928469: Bug #928469: ITP: uacme -- lightweight client for the RFC8555 ACMEv2 protocol

[Vincent Bernat]

 ❦ 15 juin 2019 07:14 +02, Nicola Di Lieto :

> I have tentatively packaged this already in the git repository, using
> the DEP-14 branch layout at http://dep.debian.net/deps/dep14 - look at
> the debian/master branch. Not sure what to do now to get it into
> debian.

Look at https://mentors.debian.net/sponsors. Notably, there is a "Let's
Encrypt" team (team+letsencrypt@tracker.debian).
-- 
Use the "telephone test" for readability.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#928469: Bug #928469: ITP: uacme -- lightweight client for the RFC8555 ACMEv2 protocol

[Nicola Di Lieto]

Package: wnpp
Severity: wishlist
Owner: 'Nicola Di Lieto' 

*Package Name: uacme
Version : 1.0.14
Upstream Author : Nicola Di Lieto
*URL : https://github.com/ndilieto/uacme
*License : GPL-3.0+
Description : lightweight client for the RFC8555 ACMEv2 protocol

uacme is a lightweight client for the RFC8555 ACMEv2 protocol, written 
in plain C code with minimal dependencies (libcurl and one of GnuTLS, 
OpenSSL or mbedTLS). The ACMEv2 protocol allows a Certificate 
Authority (https://letsencrypt.org is a popular one) and an applicant 
to automate the process of verification and certificate issuance. The 
protocol also provides facilities for other certificate management 
functions, such as certificate revocation.

.
I have tentatively packaged this already in the git repository, using 
the DEP-14 branch layout at http://dep.debian.net/deps/dep14 - look at 
the debian/master branch. Not sure what to do now to get it into 
debian.

Bug#930091: bison is wrongly marked Multi-Arch: foreign

[Chuan-kai Lin]

I finished rebuilding all reverse build dependencies of bison.  And I
found that removing libbison-dev as a dependency of bison (option A)
does not cause any additional FTBFS errors.  All the build failures I
observed were due to existing FTBFS bugs, or due to problems (such as
tests hanging) that are very unlikely to be caused by missing liby.a,
which should cause static linking errors.

So I believe that we can proceed with option A without filing any bugs
on reverse build dependencies of bison.

Bug#930548: julia: Arpack not building with source compiled (packaged) Julia

[Mateusz Kaduk]

Package: julia
Version: 1.1.0+dfsg-1
Severity: important

Dear Maintainer,

When I download Julia 1.1.0 from website, I can add Distributions package which 
depends on Arpack. However, with Debian's packaged Julia, Arpack is failing to 
build for some reason. To reproduce the issue ]add Distributions

Thanks for looking into this.
Mateusz

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (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_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 julia depends on:
ii  julia-common   1.1.0+dfsg-1
ii  libc6  2.28-10
ii  libcholmod31:5.4.0+dfsg-1
ii  libcurl3-gnutls7.64.0-3
ii  libdsfmt-19937-1   2.2.3+dfsg-4
ii  libgit2-27 0.27.7+dfsg.1-0.2
ii  libgmp10   2:6.1.2+dfsg-4
ii  libjulia1  1.1.0+dfsg-1
ii  libllvm6.0 1:6.0.1-11
ii  libmbedcrypto3 2.16.0-1
ii  libmbedtls12   2.16.0-1
ii  libmbedx509-0  2.16.0-1
ii  libmpfr6   4.0.2-1
ii  libopenblas-base   0.3.5+ds-3
ii  libopenlibm2   0.6.0+dfsg-2
ii  libpcre2-8-0   10.32-5
ii  libspqr2   1:5.4.0+dfsg-1
ii  libssh2-1  1.8.0-2.1
ii  libsuitesparseconfig5  1:5.4.0+dfsg-1
ii  libumfpack51:5.4.0+dfsg-1
ii  libunwind8 1.2.1-9
ii  libutf8proc2   2.3.0-1

Versions of packages julia recommends:
ii  git  1:2.20.1-2
ii  openssl  1.1.1c-1

Versions of packages julia suggests:
pn  ess
ii  julia-doc  1.1.0+dfsg-1
ii  vim-julia  0.0~git20190129.84104d0-1

-- no debconf information

Bug#930547: Detect common Android file types

[積丹尼 Dan Jacobson]

Package: file
Version: 1:5.35-4
Severity: wishlist

# apt install anbox
$ set /var/lib/anbox/rootfs/file_contexts.bin
$ file $@
/var/lib/anbox/rootfs/file_contexts.bin: data
$ strings $@|head
8.38 2015-11-23
/dev
/system
/vendor
/data
/mnt
/cache
/sys
u:object_r:rootfs:s0
/fstab\..*
$ hd $@|head -n 2
  8a ff 7c f9 04 00 00 00  0f 00 00 00 38 2e 33 38  |..|.8.38|
0010  20 32 30 31 35 2d 31 31  2d 32 33 07 00 00 00 04  | 2015-11-23.|

That certainly is some well known Android file type I bet, not just data.

Bug#803119: [Debian-rtc-admin] prosody config, status update

[gustavo panizzo]

On Fri, Jun 14, 2019 at 09:42:54AM +0200, Victor Seva wrote:

On Thu, 13 Jun 2019 at 13:09, gustavo panizzo  wrote:


I've been working on how to maintain and update the prosody config

this was my initial attempt using a Makefile
https://salsa.debian.org/rtc-team/prosody-configuration

this is my current attempt using puppet and the module Victor suggested

https://salsa.debian.org/gfa/dsa-puppet/merge_requests/1/diffs

this is depending this merge
https://github.com/voxpupuli/puppet-posix_acl/pull/62 if the merge takes
to long I'll fork the module in salsa

My goal for the first iteration is to have the patch merged by DSA so we
can have a way to deploy changes in the service easily and
auditable, afterwards (help welcomed!) I'll add anti-spam measures and
http_uploads :)

reviews of the MR are very much welcomed



This is great!

Some comments:

* the need of posix_acl maybe is not necessary. This was needed to do
manual changes to the configs. If We can manage the config via puppet I
think is not really needed. Maybe without posix_acl it would be easier to
get approved by DSA. Being able to read /var/log/prosody/ is good enough to


I think is good to let the rest of the team (debvoip) to be able to read
the config files after being generated by puppet
If DSA don't like the posix_acl module i'd resort to call setfacl in an exec [1]



check and debug the service.
* can you please explain and document how to get the "generated" configs.
In other words, how to test this in a VM with puppet masterless.



i'm using puppet bolt, my repo is published [2] but I haven't commited
the prosody config yet, but is just a wrapper class (like
debian_org::prosody) called from hiera


I'm moving next week, don't expect much from me until next
weekend or so


Great work Gustavo. Thank you for this!
Cheers,
Victor


[1] https://puppet.com/docs/puppet/5.5/types/exec.html
[2] https://github.com/gfa/puppet-bolt

--
IRC: gfa
GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5
OLD GPG: 0x44BB1BA79F6C6333

Bug#930546: chromium --incognito crashes with signal 11 SEGV_MAPERR 000000000028

[robles]

Package: chromium
Version: 75.0.3770.90-1
Severity: important

Dear Maintainer,

I start chromium always in the incognito mode. It crashes since the previous
update and with version 75.0.3770.90-1.


*** Start console output ***
robles@debian:~$ chromium --incognito

(chromium:7743): Gtk-WARNING **: 04:11:26.295: Theme parsing error:
gtk.css:127:35: The style property GtkButton:child-displacement-x is deprecated
and shouldn't be used anymore. It will be removed in a future version

(chromium:7743): Gtk-WARNING **: 04:11:26.295: Theme parsing error:
gtk.css:128:35: The style property GtkButton:child-displacement-y is deprecated
and shouldn't be used anymore. It will be removed in a future version

(chromium:7743): Gtk-WARNING **: 04:11:26.295: Theme parsing error:
gtk.css:132:46: The style property GtkScrolledWindow:scrollbars-within-bevel is
deprecated and shouldn't be used anymore. It will be removed in a future
version
[7781:7781:0615/041126.452908:ERROR:vaapi_wrapper.cc(720)]
vaQuerySurfaceAttributes failed VA error: invalid parameter
[7781:7781:0615/041126.452972:ERROR:vaapi_wrapper.cc(611)]
FillProfileInfo_Locked failed for va_profile 0 and entrypoint 1
[7781:7781:0615/041126.452993:ERROR:vaapi_wrapper.cc(720)]
vaQuerySurfaceAttributes failed VA error: invalid parameter
[7781:7781:0615/041126.452998:ERROR:vaapi_wrapper.cc(611)]
FillProfileInfo_Locked failed for va_profile 1 and entrypoint 1
[7781:7781:0615/041126.453004:ERROR:vaapi_wrapper.cc(720)]
vaQuerySurfaceAttributes failed VA error: invalid parameter
[7781:7781:0615/041126.453009:ERROR:vaapi_wrapper.cc(611)]
FillProfileInfo_Locked failed for va_profile 2 and entrypoint 1
[7781:7781:0615/041126.453015:ERROR:vaapi_wrapper.cc(720)]
vaQuerySurfaceAttributes failed VA error: invalid parameter
[7781:7781:0615/041126.453020:ERROR:vaapi_wrapper.cc(611)]
FillProfileInfo_Locked failed for va_profile 3 and entrypoint 1
[7781:7781:0615/041126.453025:ERROR:vaapi_wrapper.cc(720)]
vaQuerySurfaceAttributes failed VA error: invalid parameter
[7781:7781:0615/041126.453030:ERROR:vaapi_wrapper.cc(611)]
FillProfileInfo_Locked failed for va_profile 5 and entrypoint 1
[7781:7781:0615/041126.453035:ERROR:vaapi_wrapper.cc(720)]
vaQuerySurfaceAttributes failed VA error: invalid parameter
[7781:7781:0615/041126.453039:ERROR:vaapi_wrapper.cc(611)]
FillProfileInfo_Locked failed for va_profile 6 and entrypoint 1
[7781:7781:0615/041126.453044:ERROR:vaapi_wrapper.cc(720)]
vaQuerySurfaceAttributes failed VA error: invalid parameter
[7781:7781:0615/041126.453048:ERROR:vaapi_wrapper.cc(611)]
FillProfileInfo_Locked failed for va_profile 7 and entrypoint 1
[7781:7781:0615/041126.453053:ERROR:vaapi_wrapper.cc(720)]
vaQuerySurfaceAttributes failed VA error: invalid parameter
[7781:7781:0615/041126.453057:ERROR:vaapi_wrapper.cc(611)]
FillProfileInfo_Locked failed for va_profile 8 and entrypoint 1
[7781:7781:0615/041126.453062:ERROR:vaapi_wrapper.cc(720)]
vaQuerySurfaceAttributes failed VA error: invalid parameter
[7781:7781:0615/041126.453067:ERROR:vaapi_wrapper.cc(611)]
FillProfileInfo_Locked failed for va_profile 9 and entrypoint 1
[7781:7781:0615/041126.453072:ERROR:vaapi_wrapper.cc(720)]
vaQuerySurfaceAttributes failed VA error: invalid parameter
[7781:7781:0615/041126.453076:ERROR:vaapi_wrapper.cc(611)]
FillProfileInfo_Locked failed for va_profile 10 and entrypoint 1
[7781:7781:0615/041126.453083:ERROR:vaapi_wrapper.cc(441)] GetConfigAttributes
failed for va_profile 5
[7781:7781:0615/041126.453087:ERROR:vaapi_wrapper.cc(441)] GetConfigAttributes
failed for va_profile 6
[7781:7781:0615/041126.453091:ERROR:vaapi_wrapper.cc(441)] GetConfigAttributes
failed for va_profile 7
Received signal 11 SEGV_MAPERR 0028
#0 0x5652bacd72f9 
#1 0x5652bac28846 
#2 0x5652bacd5bc3 
#3 0x5652bacd7285 
#4 0x7f7831990730 
#5 0x5652ba8a88b4 
#6 0x5652ba8a8201 
#7 0x5652ba8a7ef0 
#8 0x5652ba8a8483 
#9 0x5652bac8383d 
#10 0x5652bac8f6db 
#11 0x5652bac91e41 
#12 0x5652bac49101 
#13 0x5652bac8e08f 
#14 0x5652bac6db77 
#15 0x5652ba783c67 
#16 0x5652b8ee9779 
#17 0x5652b8ee9855 
#18 0x5652b8ed5ffc 
#19 0x5652ba75a407 
#20 0x5652ba75a4dc 
#21 0x5652ba75a8cd 
#22 0x5652ba76419a 
#23 0x5652ba758c65 
#24 0x5652b819c2fd ChromeMain
#25 0x7f78297b509b __libc_start_main
#26 0x5652b819c15a _start
  r8: 7ffdb3ba1038  r9: 0001 r10: 50c99814d28c r11:
0001
 r12: 5652c30f3060 r13: 7ffdb3ba0ffc r14: 7ffdb3ba1070 r15:

  di: 0040  si: 5652c14ba7c0  bp: 7ffdb3ba0fe0  bx:

  dx: 5652c35b1fd0  ax: 5652c2e5feb0  cx: 5652c35b1fd0  sp:
7ffdb3ba0f90
  ip: 5652ba8a88b4 efl: 00010202 cgf: 002b0033 erf:
0004
 trp: 000e msk:  cr2: 0028
[end of stack trace]
Calling _exit(1). Core file will not be generated.

*** End console output ***


If I start chromiun without --incognito it works. Then I'm able to start an
incognito session with Strg+Shift+N.

Bug#893572: tracker.debian.org: Debian Maintainer display: [dm] links empty, should be uppercase and use parentheses

[Paul Wise]

On Fri, 2019-06-14 at 16:13 -0300, Herbert Fortes wrote:

> Should dm.txt file be downloaded and read once a day?
> (to update/save new info)

I note there is already code in RetrieveDebianMaintainersTask that
downloads and processes dm.txt so perhaps that should be used.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#893572: tracker.debian.org: Debian Maintainer display: [dm] links empty, should be uppercase and use parentheses

[Herbert Fortes]

 
> Should dm.txt file be downloaded and read once a day?
> (to update/save new info)
> 
> 'class DebianContributor(models.Model)' has 'allowed_packages' and
> 'is_debian_maintainer'
> 
> Or a dictionary.
> 
> I set 'DISTRO_TRACKER_DATA_PATH' + 'cache/dm.txt' for now. But no 
> downloads yet.
> 
> Here is the forked repository:
> https://salsa.debian.org/hpfn/distro-tracker/commit/56b2a5d95f9ce4aa3eaee9e21668a45d54a79094

I did a commit to use 'urlopen' and do not have to worry
about it.



Regards,
Herbert

Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

[Andrew Hayzen]

Hi,

Is there going to be an ACK or NACK decision on this before the buster
release?

As an outsider I understand the advantages of Wayland, but I am
concerned about the implications of Wayland as default at this point to
a "stable" release.

Having the whole session and apps lost if the shell crashes is a large
regression compared to X11. Other issues such as screen-sharing not
working will appear odd to users when it worked before (there is work
upstream here so hopefully this will be fixed for the next stable
release). And there also seem to be other known issues noted in
previous comments such as drag and drop causing crashes and
accessibility issues etc.

Andrew

Bug#930545: ITP: gffread -- GFF/GTF format conversions, region filtering, FASTA sequence extraction

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: gffread -- GFF/GTF format conversions, region filtering, FASTA 
sequence extraction
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: gffread
  Version : 0.11.2
  Upstream Author : Geo Pertea
* URL : https://github.com/gpertea/gffread
* License : MIT
  Programming Lang: C
  Description : GFF/GTF format conversions, region filtering, FASTA 
sequence extraction
 Gffread is a GFF/GTF parsing utility providing format conversions,
 region filtering, FASTA sequence extraction and more.

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

Bug#929824: Backport VMCI PPN64 patch

[Salvatore Bonaccorso]

Hi Adid,

On Thu, Jun 13, 2019 at 09:38:22PM +, Adit Ranadive wrote:
> Dear Maintainer,
> 
> Can you give me any ETA on when the patch in this bug would be applied
> to the Debian linux image?

I think you might want to ask here actually upstream for a backport to
stable series if that matches the criteria for inclusion. If yes, it
will then be picked up for the buster kernel as well when new stable
versions are imported (as it will start to follow at some point newer
imports from 4.19).

Regards,
Salvatore

Bug#930544: konsole: Using Monospace font leads to curser being displayed several spaces ahead of real position

[Bert Schlumwig]

Package: konsole
Version: 4:18.04.0-1
Severity: normal

When changing the font to Monospace (which is standard when creating a new user
profile) the cursor is being displayed several spaces ahead of its real
location.
This makes it hard to edit commands, etc.

Workaround: choose another (installed) font. Then the cursor is being displayed
correctly.

Reproducibility: always

This bug has been persistent since Debian Stretch



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

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

Versions of packages konsole depends on:
ii  kio   5.54.1-1
ii  konsole-kpart 4:18.04.0-1
ii  libc6 2.28-10
ii  libkf5completion5 5.54.0-1
ii  libkf5configcore5 5.54.0-1
ii  libkf5configgui5  5.54.0-1
ii  libkf5configwidgets5  5.54.0-1
ii  libkf5coreaddons5 5.54.0-1
ii  libkf5crash5  5.54.0-1
ii  libkf5dbusaddons5 5.54.0-1
ii  libkf5globalaccel55.54.0-1
ii  libkf5i18n5   5.54.0-1
ii  libkf5iconthemes5 5.54.0-1
ii  libkf5kiowidgets5 5.54.1-1
ii  libkf5notifyconfig5   5.54.0-1
ii  libkf5widgetsaddons5  5.54.0-1
ii  libkf5windowsystem5   5.54.0-1
ii  libkf5xmlgui5 5.54.0-1
ii  libqt5core5a  5.11.3+dfsg1-1
ii  libqt5gui55.11.3+dfsg1-1
ii  libqt5widgets55.11.3+dfsg1-1
ii  libstdc++68.3.0-6

konsole recommends no packages.

konsole suggests no packages.

-- no debconf information

Bug#850644: #850644: RFP: Guix in Debian

[Ludovic Courtès]

Hello,

Vagrant Cascadian  skribis:

> It still needs a way to get the bootstrap binaries (bash, mkdir, tar and
> xz) from Guix; right now they're binaries shipped in the source!
> Ludovic Courtès worked on a patch that would in theory download those at
> run-time, but that is not yet working...

On the ‘core-updates’ branch, these four files are now downloaded as
needed (they are “fixed-output derivations” at the bottom of the
dependency graph):

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=836a85da0e8609d40716581be00802ee43463038

The binaries are gone from that branch.

It may be weeks before it’s merged to master, but we’re making progress!

Ludo’.

Bug#930543: chromium-driver: Will not start browser if a newer chrome is installed

[Chris Halls]

Package: chromium-driver
Version: 73.0.3683.75-1
Severity: important

Hi

My chromiumdriver stopped working recently with an odd error message:

% python3 -c "from selenium import webdriver; webdriver.Chrome()"
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/selenium/webdriver/chrome/webdriver.py", 
line 81, in __init__
desired_capabilities=desired_capabilities)
  File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webdriver.py", 
line 157, in __init__
self.start_session(capabilities, browser_profile)
  File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webdriver.py", 
line 252, in start_session
response = self.execute(Command.NEW_SESSION, parameters)
  File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webdriver.py", 
line 321, in execute
self.error_handler.check_response(response)
  File 
"/usr/lib/python3/dist-packages/selenium/webdriver/remote/errorhandler.py", 
line 242, in check_response
raise exception_class(message, screen, stacktrace)
selenium.common.exceptions.SessionNotCreatedException: Message: session not 
created: Chrome version must be between 70 and 73
  (Driver info: chromedriver=73.0.3683.75,platform=Linux 4.19.0-5-amd64 x86_64)

Given that my chromium was indeed version 73, it took me a while to find
out what was happening. Strace gave the answer:

% strace -q -f -e trace=execve python3 -c "from selenium import webdriver; 
webdriver.Chrome()"
[...]
[pid 12780] execve("/usr/bin/chromedriver", ["/usr/bin/chromedriver", 
"--port=54905"], 0x7f952aeb2df8 /* 62 vars */) = 0
[pid 12787] execve("/usr/bin/google-chrome", ["/usr/bin/google-chrome", 
"--disable-background-networking", "--disable-client-side-phishing-d"..., 
"--disable-default-apps", "--disable-hang-monitor", "--disable-popup-blocking", 
"--disable-prompt-on-repost", "--disable-sync", "--disable-web-resources", 
"--enable-automation", "--enable-blink-features=ShadowDO"..., 
"--enable-logging", "--force-fieldtrials=SiteIsolatio"..., 
"--ignore-certificate-errors", "--load-extension=/tmp/.org.chrom"..., 
"--log-level=0", "--metrics-recording-only", "--no-first-run", 
"--password-store=basic", "--remote-debugging-port=0", "--test-type=webdriver", 
"--use-mock-keychain", "--user-data-dir=/tmp/.org.chromi"..., "data:,"], 
0x7ffefe6e9090 /* 62 vars */) = 0

I have the Chrome stable packages installed (due to an issue with Meet
hanging with Chromium). So my /usr/bin/google-chrome points to

 % readlink -f /usr/bin/google-chrome
/opt/google/chrome/google-chrome

If I move /usr/bin/google-chrome out of the way, it starts chromium
instead:

% sudo mv /usr/bin/google-chrome /usr/bin/google-chrome.disable
% strace -q -f -e trace=execve python3 -c "from selenium import webdriver; 
webdriver.Chrome()"
[...]
[pid 14105] execve("/usr/bin/chromedriver", ["/usr/bin/chromedriver", 
"--port=51095"], 0x7f6b2e777df8 /* 62 vars */) = 0
[pid 14112] execve("/usr/bin/chromium", ["/usr/bin/chromium", 
"--disable-background-networking", "--disable-client-side-phishing-d"..., 
"--disable-default-apps", "--disable-hang-monitor", "--disable-popup-blocking", 
"--disable-prompt-on-repost", "--disable-sync", "--disable-web-resources", 
"--enable-automation", "--enable-blink-features=ShadowDO"..., 
"--enable-logging", "--force-fieldtrials=SiteIsolatio"..., 
"--ignore-certificate-errors", "--load-extension=/tmp/.org.chrom"..., 
"--log-level=0", "--metrics-recording-only", "--no-first-run", 
"--password-store=basic", "--remote-debugging-port=0", "--test-type=webdriver", 
"--use-mock-keychain", "--user-data-dir=/tmp/.org.chromi"..., "data:,"], 
0x7ffc630f6490 /* 62 vars */) = 0

In case someone wants to try to reproduce this, the package providing
/opt/google/chrome/google-chrome is google-chrome-stable from this
repository:

% cat /etc/apt/sources.list.d/google-chrome.list
deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main

Thanks
Chris

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

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

Versions of packages chromium-driver depends on:
ii  chromium 73.0.3683.75-1
ii  libatomic1   8.3.0-6
ii  libc62.28-10
ii  libdbus-1-3  1.12.14-1
ii  libdrm2  2.4.97-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.6-1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.3.0-6
ii  libglib2.0-0 2.58.3-2
ii  libharfbuzz0b2.3.1-1
ii  libicu63 63.1-6
ii  libjpeg62-turbo  1:1.5.2-2+b1

Bug#930542: vlc: VLC becomes zombie when changing video playback speed to 3x and faster

[Bert Schlumwig]

Package: vlc
Version: 3.0.7-1
Severity: normal

When setting video playback speed to more than 2x (e.g. 3x and faster) and then
just closing it normally by hitting the X-button (close button) WHILE the video
is still playing, VLC becomes a zombie process.
It does not terminate and has to be killed with "kill -9"

Reproducibility: Always

Steps to reproduce:

1. Start video playback and set speed to at least 3x
2. While the video is still running, just close VLC
3. Check in process list for VLC, it will still be there



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

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

Versions of packages vlc depends on:
ii  vlc-bin  3.0.7-1
ii  vlc-plugin-base  3.0.7-1
ii  vlc-plugin-qt3.0.7-1
ii  vlc-plugin-video-output  3.0.7-1

Versions of packages vlc recommends:
ii  vlc-l10n   3.0.7-1
pn  vlc-plugin-notify  
pn  vlc-plugin-samba   
pn  vlc-plugin-skins2  
pn  vlc-plugin-video-splitter  
pn  vlc-plugin-visualization   

vlc suggests no packages.

Versions of packages libvlc-bin depends on:
ii  libc62.28-10
ii  libvlc5  3.0.7-1

Versions of packages libvlc5 depends on:
ii  libc62.28-10
ii  libvlccore9  3.0.7-1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.7-1

Versions of packages vlc-bin depends on:
ii  libc6   2.28-10
ii  libvlc-bin  3.0.7-1
ii  libvlc5 3.0.7-1

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-19
ii  libaom0  1.0.0-3
ii  libarchive13 3.3.3-4
ii  libaribb24-0 1.0.3-2
ii  libasound2   1.1.8-1
ii  libass9  1:0.14.0-2
ii  libavahi-client3 0.7-4+b1
ii  libavahi-common3 0.7-4+b1
ii  libavc1394-0 0.5.4-5
ii  libavcodec58 7:4.1.3-1
ii  libavformat587:4.1.3-1
ii  libavutil56  7:4.1.3-1
ii  libbasicusageenvironment12018.11.26-1.1
ii  libbluray2   1:1.1.0-1
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcddb2 1.3.2-6
ii  libchromaprint1  1.4.3-3
ii  libcrystalhd31:0.0~git20110715.fdd2f19-13
ii  libdbus-1-3  1.12.14-1
ii  libdc1394-22 2.2.5-1
ii  libdca0  0.0.6-1
ii  libdvbpsi10  1.3.2-1
ii  libdvdnav4   6.0.0-1
ii  libdvdread4  6.0.1-1
ii  libebml4v5   1.3.6-2
ii  libfaad2 2.8.8-3
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libfribidi0  1.0.5-3.1
ii  libgcc1  1:8.3.0-6
ii  libgcrypt20  1.8.4-5
ii  libglib2.0-0 2.58.3-2
ii  libgnutls30  3.6.7-3
ii  libgpg-error01.35-1
ii  libgroupsock82018.11.26-1.1
ii  libharfbuzz0b2.3.1-1
ii  libixml101:1.8.4-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libkate1 0.4.1-9
ii  liblirc-client0  0.10.1-5.2
ii  liblivemedia64   2018.11.26-1.1
ii  liblua5.2-0  5.2.4-1.1+b2
ii  libmad0  0.15.1b-10
ii  libmatroska6v5   1.4.9-1
ii  libmicrodns0 0.0.10-1
ii  libmpcdec6   2:0.1~r495-1+b2
ii  libmpeg2-4   0.5.1-8
ii  libmpg123-0  1.25.10-2
ii  libmtp9  1.1.16-2
ii  libncursesw6 6.1+20181013-2
ii  libnfs12 3.0.0-2
ii  libogg0  1.3.2-1+b1
ii  libopenmpt-modplug1  0.4.3-1
ii  libopus0 1.3-1
ii  libpng16-16  1.6.36-6
ii  libpostproc557:4.1.3-1
ii  libprotobuf-lite17   3.6.1.3-2
ii  libpulse012.2-4
ii  libraw1394-112.1.2-1+b1
ii  libresid-builder0c2a 2.1.1-15
ii  librsvg2-2   2.44.10-2.1
ii  libsamplerate0   0.1.9-2
ii  libsdl-image1.2   

Bug#930541: gnutls28: Fix autopkgtest on 32-bit architectures

[Julian Andres Klode]

Source: gnutls28
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch


The test suite defaults the size of time_t to 8 if not specified, which
works e.g. during the build, as it gets set there, but it does not work
for autopkgtest, as configure did not run.

The patch below fixes it by looking at whether we support 64-bit dates
in date(1) which is a bit strange, but should work fine, well, until we
transition 32-bit platforms to time64_t.

diff -pruN 3.6.7-3/debian/tests/run-upstream-testsuite 
3.6.7-3ubuntu1/debian/tests/run-upstream-testsuite
--- 3.6.7-3/debian/tests/run-upstream-testsuite 2018-12-16 13:18:19.0 
+
+++ 3.6.7-3ubuntu1/debian/tests/run-upstream-testsuite  2019-05-19 
15:44:56.0 +
@@ -16,6 +16,16 @@ export  CLI=/usr/bin/gnutls-cli \
DCLI=/usr/bin/gnutls-cli-debug \
ENABLE_GOST=1
 
+# Set the sizeof(time_t) to the correct value for the platform, to ensure we
+# run the correct tests.
+if test -z "${ac_cv_sizeof_time_t}"; then
+   if [ "$(date  --date=@2147483648 +%Y 2>/dev/null)" = "2038" ]; then
+   export ac_cv_sizeof_time_t=8
+   else
+   export ac_cv_sizeof_time_t=4
+   fi
+fi
+
 count=1
 for i in $(find ../../tests/ -type f -perm -u+rx | \
grep -Ev 
'tests/pkgconfig.sh|/tests/scripts/slow/|tests/slow/|tests/dtls/dtls-resume|tests/dtls/dtls$|tests/destructive/|/cbc-record-check.sh')
 ; do





-- System Information:
Debian Release: buster/sid
  APT prefers eoan
  APT policy: (991, 'eoan'), (500, 'eoan'), (500, 'cosmic-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#930540: samba-vfs-modules: /usr/lib/x86_64-linux-gnu/samba/vfs/nfs4acl_xattr.so No such file or directory

[Gary Richards]

Package: samba-vfs-modules
Version: 4.9.5+dfsg-4
Severity: normal

Dear Maintainer,

I have been attempting to build a samba ad dc in a buster container to run on a
platform where /var/lib/samba will be an NFSv4 mount. When trying to provision
the domain with samba-tool I receive an error:

ERROR(): Provision failed -
ProvisioningError: Your filesystem or build does not support posix ACLs, which
s3fs requires.  Try the mounting the filesystem with the 'acl' option

Which I believe is because NFSv4 has its own ACL concept, which isn't posix
ACLs.

Further digging has suggested that I probably want to enable the nfs4acl_xattr
vfs module. I tried this as an argument to my samba-tool provision command:

samba-tool domain provision --use-rfc2307 --domain=${SAMBA_DOMAIN}
--realm=${SAMBA_REALM} --server-role=dc --dns-backend=BIND9_DLZ
--adminpass=${SAMBA_DOMAIN_PASSWORD} --option "bind interfaces only = yes"
--option "interfaces = lo net1" --option "vfs objects = nfs4acl_xattr"

But it results in a new error:

Error loading module '/usr/lib/x86_64-linux-gnu/samba/vfs/nfs4acl_xattr.so':
/usr/lib/x86_64-linux-gnu/samba/vfs/nfs4acl_xattr.so: cannot open shared object
file: No such file or directory

I believe this would be expected to come from samba-vfs-modules, but that file
is not in that package. Or any other package as far as I can tell.
Interestingly samba-vfs-modules does seem to contain the following file:

/usr/share/man/man8/vfs_nfs4acl_xattr.8.gz

Which I guess is the man page for the module that i'm trying to use. But the
module isn't there.

Thanks

Gary



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

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

Versions of packages samba-vfs-modules depends on:
ii  libbsd0 0.9.1-2
ii  libc6   2.28-10
ii  libtalloc2  2.1.14-2
ii  libtdb1 1.3.16-2+b1
ii  libtevent0  0.9.37-1
ii  samba-libs  2:4.9.5+dfsg-4

Versions of packages samba-vfs-modules recommends:
pn  libcephfs2   
ii  libdbus-1-3  1.12.12-1
pn  libgfapi0

samba-vfs-modules suggests no packages.

Bug#754513: CFP- International Conference @ University of Westminster, London, UK

[Stefania Wilson]

Dear Friends,


We would like to invite you to submit research article in the 9th Joint 
International Conference organised by Institute of Research Engineers and 
Doctors at University of Westminster, London, UK. The theme for the 2019 UK 
conference is to bring together innovative academics and industrial experts to 
a common forum. We would be delighted to have you present at this conference to 
hear what the technology experts and researchers have to share about the 
technology advancements and their impact on our daily lives.


Joint International Conference Consists of following tracks:




Track 1: 9th International Conference on Advances in Computing, Control and 
Networking - ACCN


Official Webiste: www.accn.theired.org




Track 2: 9th International Conference On Advances in Civil, Structural and 
Mechanical Engineering - ACSM


Official Webiste: www.acsm.theired.org




Track 3: 9th International Conference On Advances in Applied Science and 
Environmental Technology - ASET


Official Webiste: www.aset.theired.org




Track 4: 9th International Conference On Advances in Economics, Social Science 
and Human Behaviour Study - ESSHBS​




Official Webiste: www.esshbs.theired.org​




Conference Venue: University of Westminster, London, UK


Conference Date: 20 - 21 July 2019


Abstract/ Full Paper Submission in Final Round For Review: 23 June 2019


*Paper Acceptance will be sent on or before: 26 June 2019





About University of Westminster (Conference Venue):
--The University of Westminster is a public university in London, United 
Kingdom. Its antecedent institution, the Royal Polytechnic Institution, was 
founded in 1838 and was the first polytechnic institution in the UK. 
Westminster was awarded university status in 1992 meaning it could award its 
own degrees.


--Its headquarters and original campus are in Regent Street in the City of 
Westminster area of central London, with additional campuses in Fitzrovia, 
Marylebone and Harrow. It operates the Westminster International University in 
Tashkent in Uzbekistan.


--Westminster's academic activities are organised into seven faculties and 
schools, within which there are around 45 departments. The University has 
numerous centres of research excellence across all the faculties, including the 
Communication and Media Research Institute, whose research is ranked in the 
Global Top 40 by the QS World University Rankings. Westminster had an income of 
£170.4 million in 2012/13, of which £4.5 million was from research grants and 
contracts.


--Westminster is a member of the Association of Commonwealth Universities, the 
Association of MBAs, EFMD, the European University Association and Universities 
UK.


About Publication:​

All the registered papers will proudly be published by IRED-CPS and stored in 
the SEEK digital Library 

(www.seekdl.org). Each Paper will be assigned DOI (Digital Object Identifier) 
from CROSSREF. The Proc. will be submitted to ISI Thomson for Review and 
Indexing. Proc. will also be published in International Journals with ISSN 
Numbers.


Remote Presentation via Skype can also be arranged.


We would also like to share some conference photographs of previous held 
Intern

Bug#930539: upowerd cannot start due to searching the wrong libssl version

[A. Heydwolff]

Package: upower
Version: 0.99.10-1
Severity: important

Dear Maintainer,

Stretch with some backport packages on a Skylake laptop with KDE. Since a few 
weeks closing the lid does no longer suspend the laptop. It can only be done 
manually because powerdevil stopped working. When resuming after suspend the 
login dialog appears only after a long time. Now I may have found the reason as 
upowerd does not start. On startup and resume syslog shows like 15 attempts at 
starting upowerd for the duration of almost a minute. The multiple similar 
messages are

Jun 14 21:10:58 karfiol upowerd[15367]: /usr/lib/upower/upowerd: error while 
loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No 
such file or directory
Jun 14 21:10:58 karfiol systemd[1]: upower.service: Main process exited, 
code=exited, status=127/n/a
Jun 14 21:10:58 karfiol systemd[1]: Failed to start Daemon for power management.
Jun 14 21:10:58 karfiol systemd[1]: upower.service: Unit entered failed state.
Jun 14 21:10:58 karfiol systemd[1]: upower.service: Failed with result 
'exit-code'.
Jun 14 21:10:58 karfiol systemd[1]: upower.service: Service hold-off time over, 
scheduling restart.
Jun 14 21:10:58 karfiol systemd[1]: Stopped Daemon for power management.
Jun 14 21:10:58 karfiol systemd[1]: Starting Daemon for power management...

Installed are 
-rw-r--r-- 1 root root 349K Oct  7  2017 libssl3.so
-rw-r--r-- 1 root root 422K Feb 27 21:58 libssl.so.1.0.2
-rw-r--r-- 1 root root 576K Apr 16 21:31 libssl.so.1.1

I created a 1.0.0 symlink to 1.0.2 but this didn't work, and I seem to remember 
that one attempted tweak, maybe even this one, then elicited a similar 
seemingly version related error with libcrypto. Doing the same for libcrypto 
did not solve the problem, so maybe both links need to be reviewed in the part 
of upowerd that wants to call them.

Regards and thanks
Andreas

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

Kernel: Linux 4.14.124-karfiol.0 (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US:tr (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages upower depends on:
ii  dbus   1.10.28-0+deb9u1
ii  libc6  2.27-6
ii  libglib2.0-0   2.50.3-2
ii  libgudev-1.0-0 230-3
ii  libimobiledevice6  1.2.1~git20180302.3a37a4e-1~bpo9+1
ii  libplist3  1.12+git+1+e37ca00-0.3
ii  libupower-glib30.99.10-1
ii  libusb-1.0-0   2:1.0.21-1
ii  udev   232-25+deb9u11

Versions of packages upower recommends:
ii  policykit-1  0.105-18+deb9u1

upower suggests no packages.

-- no debconf information

Bug#930538: kwin-x11: The active virtual desktop is no longer remembered between sessions

[Krzysztof Gajdemski]

Package: kwin-x11
Version: 4:5.14.5-1
Severity: normal
Tags: upstream

The active virtual desktop isn't remembered between kwin sessions. The correct
desktop number is saved into session/kwin* but it isn't taken into account.
This bug has been reported and fixed upstream, so appropriate patch is
available. See:
https://bugs.kde.org/show_bug.cgi?id=390295


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

Kernel: Linux 4.19.0-5-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 kwin-x11 depends on:
ii  kwin-common4:5.14.5-1
ii  libc6  2.28-10
ii  libepoxy0  1.5.3-0.1
ii  libgcc11:8.3.0-6
ii  libkf5configcore5  5.54.0-1
ii  libkf5coreaddons5  5.54.0-1
ii  libkf5crash5   5.54.0-1
ii  libkf5i18n55.54.0-1
ii  libkf5quickaddons5 5.54.0-1
ii  libkf5waylandserver5   4:5.54.0-1
ii  libkf5windowsystem55.54.0-1
ii  libkwineffects11   4:5.14.5-1
ii  libkwinglutils11   4:5.14.5-1
ii  libkwinxrenderutils11  4:5.14.5-1
ii  libqt5core5a   5.11.3+dfsg1-1
ii  libqt5gui5 5.11.3+dfsg1-1
ii  libqt5widgets5 5.11.3+dfsg1-1
ii  libqt5x11extras5   5.11.3-2
ii  libstdc++6 8.3.0-6
ii  libx11-6   2:1.6.7-1
ii  libxcb-composite0  1.13.1-2
ii  libxcb-cursor0 0.1.1-4
ii  libxcb-keysyms10.4.0-1+b2
ii  libxcb-randr0  1.13.1-2
ii  libxcb-render0 1.13.1-2
ii  libxcb-shape0  1.13.1-2
ii  libxcb-xfixes0 1.13.1-2
ii  libxcb11.13.1-2
ii  libxi6 2:1.7.9-1

kwin-x11 recommends no packages.

kwin-x11 suggests no packages.

-- no debconf information

Bug#927126: Bug#930393: RFS: aqemu/0.9.2-2.3 [NMU] [RC] -- Fix #927126 including suggestion from #929342 - aqemu: after updating can't open VMs

[gregor herrmann]

On Tue, 11 Jun 2019 22:25:06 +0200, Alexis Murzeau wrote:

> I am looking for a sponsor for a NMU of "aqemu" to fix this RC bug:
> #927126  - aqemu: after updating can't open VMs [0].
> This bug was fixed in previous NMU aqemu/0.9.2-2.2 bug after discussion
> with release team in #929342 [1], I modified the fix before being able
> to migrate to buster.
> 
> This NMU remove references to VLANs in the description texts.

Uploaded. Thanks for your work.
 

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#930530: pcscd: Runs with possibly unnecessary privileges

[Ludovic Rousseau]

Le 14/06/2019 à 18:02, Kevin Locke a écrit :

Package: pcscd
Version: 1.8.24-1
Severity: normal

Dear Maintainer,


Hello Kevin,


pcscd currently runs as root.  This is a security risk (as pointed out
in the SECURITY file shipped with pcscd).  It was previously fixed in
Bug #606142 and regressed back to root when systemd support was added
(setgid was removed in 798d03c).

Is there a reason that pcscd needs to run as root, rather than a normal
user with access to the necessary device files?  If so, could the
rationale be documented in the SECURITY file?  If not, what would be
required to run as a non-root user and would you accept patches that
make the necessary changes?


You are completely right.
It is a known task on my TODO list. See 
https://salsa.debian.org/rousseau/PCSC/issues/10

I know systemd has many features that could help.
Please provide patches upstream (it is not a problem limited to Debian).

You can use https://salsa.debian.org/rousseau/PCSC or 
https://github.com/LudovicRousseau/PCSC to provide pull requests.

Maybe you should first discuss ideas and solutions on the pcsclite-muscle 
mailing list.
https://lists.infradead.org/mailman/listinfo/pcsclite-muscle

Bye

--
 Dr. Ludovic Rousseau

Bug#930514: libgles2-mesa-dev: glesv2.pc missing

[Timo Aaltonen]

Hi,

On 14.6.2019 12.34, Guido Günther wrote:
> Package: libgles2-mesa-dev
> Version: 19.1.0-1
> Severity: normal
> 
> Hi,
> The package config file went missing in 19.1.0-1:
> 
>https://packages.debian.org/experimental/arm64/libgles2-mesa-dev/filelist
> 
> I noticed when rebuilding wlroots against that version.

it's not generated anymore when built with GLVND

https://bugs.freedesktop.org/show_bug.cgi?id=110141
https://github.com/NVIDIA/libglvnd/pull/86

Bug#930537: at fails to install and to be removed afterwards even with dpkg --force-all

[Bert Schlumwig]

Package: at
Version: 3.1.23-1
Severity: grave
Justification: renders package unusable

at fails to install:

E: at: »installiertes at-Skript des Paketes post-installation«-Unterprozess gab
den Fehlerwert 1 zurück

Vorbereitung zum Entpacken von .../archives/at_3.1.23-1_amd64.deb ...
Entpacken von at (3.1.23-1) ...
at (3.1.23-1) wird eingerichtet ...
Created symlink /etc/systemd/system/multi-user.target.wants/atd.service →
/etc/systemd/system/atd.service.
Failed to start atd.service: Unit atd.service has a bad unit file setting.
See system logs and 'systemctl status atd.service' for details.
invoke-rc.d: initscript atd, action "start" failed.
● atd.service - Deferred execution scheduler
   Loaded: bad-setting (Reason: Unit atd.service has a bad unit file setting.)
   Active: inactive (dead)
 Docs: man:atd(8)

Jun 14 20:58:18  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 20:58:20  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 20:58:20  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 21:00:42  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 21:00:46  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 21:00:46  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 21:00:46  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 21:02:28  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 21:02:28  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 21:02:28  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
dpkg: Fehler beim Bearbeiten des Paketes at (--configure):
 »installiertes at-Skript des Paketes post-installation«-Unterprozess gab den
Fehlerwert 1 zurück
Trigger für man-db (2.8.5-2) werden verarbeitet ...
Trigger für systemd (241-5) werden verarbeitet ...
Fehler traten auf beim Bearbeiten von:
 at
E: Sub-process /usr/bin/dpkg returned an error code (1)
Ein Paket konnte nicht installiert werden. Wiederherstellung wird versucht:
at (3.1.23-1) wird eingerichtet ...
Failed to start atd.service: Unit atd.service has a bad unit file setting.
See system logs and 'systemctl status atd.service' for details.
invoke-rc.d: initscript atd, action "start" failed.
● atd.service - Deferred execution scheduler
   Loaded: bad-setting (Reason: Unit atd.service has a bad unit file setting.)
   Active: inactive (dead)
 Docs: man:atd(8)

Jun 14 21:00:42  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 21:00:46  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 21:00:46  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 21:00:46  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 21:02:28  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 21:02:28  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 21:02:28  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 21:02:30  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 21:02:32  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 21:02:33  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
dpkg: Fehler beim Bearbeiten des Paketes at (--configure):
 »installiertes at-Skript des Paketes post-installation«-Unterprozess gab den
Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
 at


--

Purging  with Synaptic  fails too:

E: at: »installiertes at-Skript des Paketes pre-removal«-Unterprozess gab den
Fehlerwert 1 zurück

Entfernen von at (3.1.23-1) ...
Failed to stop atd.service: Unit atd.service not loaded.
invoke-rc.d: initscript atd, action "stop" failed.
dpkg: Fehler beim Bearbeiten des Paketes at (--remove):
 »installiertes at-Skript des Paketes pre-removal«-Unterprozess gab den
Fehlerwert 1 zurück
Failed to start atd.service: Unit atd.service has a bad unit file setting.
See system logs and 'systemctl status atd.service' for details.
invoke-rc.d: initscript atd, action "start" failed.
● atd.service - Deferred execution scheduler
   Loaded: bad-setting (Reason: Unit atd.service has a bad unit file setting.)
   Active: inactive (dead)
 Docs: man:atd(8)

Jun 14 21:00:46  systemd[1]: atd.service: Service has no ExecStart=, ExecStop=,
or SuccessAction=. Refusing.
Jun 14 21:02:28  systemd[1]: atd.ser

Bug#893572: tracker.debian.org: Debian Maintainer display: [dm] links empty, should be uppercase and use parentheses

[Herbert Fortes]

On 6/13/19 6:14 PM, Raphael Hertzog wrote:
> Hi,
> 
> On Thu, 13 Jun 2019, Herbert Fortes wrote:
>> I found where to make the change. But the information about
>> who gave the permission I do not know where it is at *debian.org.
>>
>> In distro_tracker/vendor/debian/rules.py file:
>>
>> _add_dm_entry function - extra.append({'display': 'dm'})
>>
>> 'link': "https://ftp-master.debian.org/dm.txt";
>> 'description': "Debian Maintainer upload allowed by Andreas Henriksson"
> 
> In https://ftp-master.debian.org/dm.txt behind each package, there's a
> fingerprint between parenthesis. This fingerprint is the fingerprint
> of the key who signed the addition of the DM right. So if you can map
> that back to a name, then you're good.
> 
> There's some code doing that already with the help of the GPG keyring
> that we have configured, see verify_signature() in
> distro_tracker/core/utils/__init__.py (in particular
> ctx.get_key(...)).
> 

Ok.

What I did seems to work. I added two tests for a function that I
created - allowed_by(pkg).

Initial lines are copy&paste from verify_signature (it does not work
when passing a fingerprint to it).

The function reads dm.txt file to get the fingerprint and gives it to
gpg.Context().get_key(). One test added to return 'None'. One test 
added to return 'PTS Tests'.

I edited these files:

 - distro_tracker/core/tests/tests-data/cache/dm.txt - one DM
 - distro_tracker/core/tests/tests_utils.py
 - distro_tracker/core/utils/__init__.py
 - distro_tracker/vendor/debian/rules.py
 - distro_tracker/vendor/debian/tests.py

It is a first step.

Should dm.txt file be downloaded and read once a day?
(to update/save new info)

'class DebianContributor(models.Model)' has 'allowed_packages' and
'is_debian_maintainer'

Or a dictionary.

I set 'DISTRO_TRACKER_DATA_PATH' + 'cache/dm.txt' for now. But no 
downloads yet.

Here is the forked repository:
https://salsa.debian.org/hpfn/distro-tracker/commit/56b2a5d95f9ce4aa3eaee9e21668a45d54a79094



Regards,
Herbert

Bug#930469: chromium: Insta-segfault on start

[Michael Brade]

I can confirm this, I have exactly the same experience, even though I
upgraded from 74 to 75. Now I went back to 73.

Due to chromium's intelligence of saving the tabs on a crash, this crash
makes me lose all my 170 tabs, therefore I won't try it again with
--temp-profile. But maybe this helps: starting it with --debug works.
Maybe this is kind of equivalent to --temp-profile?

Bug#930065: ansible: CVE-2019-10156: templating causing an unexpected key file to be set on a remote node

[Salvatore Bonaccorso]

Hi Lee,

On Fri, Jun 14, 2019 at 03:52:45PM +0200, Lee Garrett wrote:
> Hi,
> 
> the updated pull request now also contains tests, which made it easier
> for me to reproduce the issue. I will prepare an update for sid on
> Sunday/Monday, and evaluate if this also applies for stable. AFAICS this
> has a low impact, as it requires an attacker to provide the template
> files (or a user to write faulty templates and not verify the output),
> which already has grave security implications by itself.
> 
> Then again the RH bug tracker hints that it might be used to leak
> passwords [0] (through the authorized_key module?), though the pull
> request does not contain any changes there. Information on this CVE is
> unfortunately rather vague.

Thanks for looking into and your assessment. So in case it affects
stable as well I guess we can safely mark it no-dsa and schedule a fix
via an upcoming point release.

For sid/buster, please keep in mind that the last date for requesting
unblocks is approaching quickly, so if you can fix it for buster that
would be great.

OTOH, I see there is 2.7.7+dfsg-1 and a newer upstream version
2.7.8+dfsg-1 in sid, so a targeted fix via testing-proposed-updates
would be needed for buster.

Regards,
Salvatore

Bug#930536: unblock: distro-info-data/0.41

[Stefano Rivera]

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

Please unblock package distro-info-data

This is a pure-data package, tracking Debian and Ubuntu releases. As the
release date is now known, it needs an update.

Since the last update, the most recent Ubuntu release has also received
an animal name, so that is included, too.

unblock distro-info-data/0.41

Thanks,

SR

diff -Nru distro-info-data-0.40/debian/changelog 
distro-info-data-0.41/debian/changelog
--- distro-info-data-0.40/debian/changelog  2019-04-23 12:14:38.0 
-0700
+++ distro-info-data-0.41/debian/changelog  2019-06-14 10:50:04.0 
-0700
@@ -1,3 +1,11 @@
+distro-info-data (0.41) unstable; urgency=medium
+
+  * Add final animal name for Ubuntu 19.10 Eoan Ermine.
+  * Set release date for Buster (and matching creation date for Bullseye).
+It has been announced.
+
+ -- Stefano Rivera   Fri, 14 Jun 2019 10:50:04 -0700
+
 distro-info-data (0.40) unstable; urgency=medium
 
   * Correct EOL date for trusty. (LP: #1825553)
diff -Nru distro-info-data-0.40/debian.csv distro-info-data-0.41/debian.csv
--- distro-info-data-0.40/debian.csv2019-04-23 12:14:38.0 -0700
+++ distro-info-data-0.41/debian.csv2019-06-14 10:50:04.0 -0700
@@ -13,8 +13,8 @@
 7,Wheezy,wheezy,2011-02-06,2013-05-04,2016-04-26
 8,Jessie,jessie,2013-05-04,2015-04-25,2018-06-06
 9,Stretch,stretch,2015-04-25,2017-06-17
-10,Buster,buster,2017-06-17
-11,Bullseye,bullseye,2019-08-01
+10,Buster,buster,2017-06-17,2019-07-06
+11,Bullseye,bullseye,2019-07-06
 12,Bookworm,bookworm,2021-08-01
 ,Sid,sid,1993-08-16
 ,Experimental,experimental,1993-08-16
diff -Nru distro-info-data-0.40/ubuntu.csv distro-info-data-0.41/ubuntu.csv
--- distro-info-data-0.40/ubuntu.csv2019-04-23 12:14:38.0 -0700
+++ distro-info-data-0.41/ubuntu.csv2019-06-14 10:50:04.0 -0700
@@ -29,4 +29,4 @@
 18.04 LTS,Bionic Beaver,bionic,2017-10-19,2018-04-26,2023-04-26
 18.10,Cosmic Cuttlefish,cosmic,2018-04-26,2018-10-18,2019-07-18
 19.04,Disco Dingo,disco,2018-10-18,2019-04-18,2020-01-18
-19.10,Eoan EANIMAL,eoan,2019-04-18,2019-10-17,2020-07-17
+19.10,Eoan Ermine,eoan,2019-04-18,2019-10-17,2020-07-17

Bug#930535: bts: enable subscribing to multiple bugs simultaneously

[John Scott]

Package: devscripts
Version: 2.19.5
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It's tedious subbing to many bugs to have to run bts multiple times with
the various bug numbers. It'd be more handy if syntax like
bts subscribe 90 91 92 ...
could work.

- -- Package-specific info:

- --- /etc/devscripts.conf ---

- --- ~/.devscripts ---
DEBSIGN_KEYID=D6223890E7C4625B2C1468D1AB181FDB41DD41C4
DEBSIGN_MAINT="John Scott"
BTS_MAIL_READER="kmail --view %s"
BTS_INTERACTIVE=yes
DEBCOMMIT_SIGN_TAGS=yes
DEBCOMMIT_SIGN_COMMITS=yes
USCAN_VERBOSE=no
WHOUPLOADS_DATE=yes

- -- System Information:
Debian Release: 10.0
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'testing-debug'), (500, 
'testing')
Architecture: amd64 (x86_64)

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.7
ii  fakeroot  1.23-1
ii  file  1:5.35-4
ii  gnupg 2.2.12-1
ii  gpgv  2.2.12-1
ii  libc6 2.28-10
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-1
ii  libmoo-perl   2.003004-2
ii  libwww-perl   6.36-2
ii  patchutils0.3.4-2
ii  perl  5.28.1-6
ii  python3   3.7.3-1
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.2
ii  at  3.1.23-1
ii  curl7.64.0-3
ii  dctrl-tools 2.24-3
ii  debian-keyring  2019.02.25
ii  dput1.0.3
ii  equivs  2.2.0
ii  libdistro-info-perl 0.21
ii  libdpkg-perl1.19.7
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.16-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.15.0
ii  man-db  2.8.5-2
ii  patch   2.7.6-3
ii  python3-apt 1.8.4
ii  python3-debian  0.1.35
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.21.0-1
ii  python3-unidiff 0.5.4-1
ii  python3-xdg 0.25-5
ii  strace  4.26-0.2
ii  unzip   6.0-23
ii  wget1.20.1-1.1
ii  xz-utils5.2.4-1

Versions of packages devscripts suggests:
ii  adequate 0.15.2
ii  autopkgtest  5.10
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-1
ii  build-essential  12.6
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper12.1.1
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
ii  duck 0.13
pn  faketime 
ii  gnuplot  5.2.6+dfsg1-1
ii  gnuplot-qt [gnuplot] 5.2.6+dfsg1-1
ii  how-can-i-help   16
ii  libauthen-sasl-perl  2.1600-1
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-1
ii  libnet-smtps-perl0.09-1
ii  libterm-size-perl0.209-1+b1
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
pn  mozilla-devscripts   
pn  mutt 
ii  openssh-client [ssh-client]  1:7.9p1-10
ii  piuparts 1.0.0
pn  postgresql-client
ii  quilt0.65-3
pn  ratt 
pn  reprotest
ii  svn-buildpackage 0.8.7
pn  w3m  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARMIAB0WIQQd3xxna2VescxVfdXYKFckL7guMwUCXQPk8AAKCRDYKFckL7gu
M04+AP4jeEXPsNhXeQ9aFgsQqFY4i4VvB1pjSjwSn8Aet2m4OAEAuYPt7I78aQTu
qvwrSQHNZttpU1YMgaHc7fZqCr8YQdQ=
=7m1C
-END PGP SIGNATURE-

Bug#916997: clang-tidy: manpage is empty (bug #916997)

[David Sanders]

Dear maintainer,

Actually more than just the clang-tidy-7 manpage is blank in Buster.

All of the following llvm/clang manpages are empty files:

clang-apply-replacement-7
clang-check-7
clang-include-fixer-7
clang-query-7
clang-rename-7
clang-reorder-fields-7
clang-tidy-7
lli-7
llvm-dwarfdump-7
llvm-mc-7
llvm-mcmarkup-7
llvm-objdump-7
llvm-ranlib-7
llvm-rtdyld-7
llvm-size-7
modularize-7
sancov-7

In addition, lld.1.gz is a dangling link (ie lld-7.1.gz is not present).

Please rebuild the relevant packages so that these manpages will be 
generated.


I suspect the severity should be higher than minor.

Thank you,

David

Bug#763321: Kiwix Desktop 2

[John Scott]

On Tue, 08 May 2018 14:42:56 + "Amy Kos"  wrote:
> There is no code published yet, only screenshots so far,
> but there will be a rewritten kiwix-desktop Qt version.
Several beta releases have been issued, and since libkiwix and aria2 have been 
packaged, it appears that the dependencies are taken care of.
https://github.com/kiwix/kiwix-desktop

Bug#930372: Provide node-bootstrap (install package.json and symlink dist to /usr/lib/nodejs)

[Pirate Praveen]

On Tue, 11 Jun 2019 20:49:38 +0500 Pirate Praveen
 wrote:
> Package: libjs-bootstrap4
> severity: wishlist
> version: 4.3.1+dfsg2-1
> 
> gitlab uses webpack and expects bootstrap node module. Please provide 
> this in addition to libjs.

On a closer look I found this is already there but without version for
provides. I think it will be better to add version like below,

Provides: node-bootstrap (= ${source:Version})

Bug#930521: tracker.d.o: during freezes dont complain about packages only in experimental

[Paul Wise]

Control: clone -1 -2
Control: reassign -2 release.debian.org
Control: retitle -2 release.debian.org: provide machine-readable
information about the freeze period for each release
Control: block -1 by -2

Hi Release Team,

In order to implement the request below (hide some suggestions from
tracker.d.o during the freeze (and possibly other things)), we need a
machine-readable information source about the current stage of the
freeze and what that means for new upstream releases. I suggest that
this come in the form of a YAML/JSON file in the testing directory
containing start dates for each stage of the freeze and an end date
once that is known. Each stage could be accompanied by some sort of
metadata about the freeze policy, so that the tracker could also give
advice on what to upload and what not to upload.

https://release.debian.org/testing/freeze.yaml

On Fri, Jun 14, 2019 at 9:15 PM Holger Levsen wrote:

> package: tracker.debian.org
> severity: wishlist
> x-debbugs-cc: debian...@lists.debian.org
>
> On Thu, Jun 06, 2019 at 09:19:14PM +0800, Paul Wise wrote:
> > On Thu, Jun 6, 2019 at 6:20 PM Holger Levsen wrote:
> [tracker.d.o tells me that]
> > > - new upstream version only available in experimental (yes, because
> > >   buster is frozen)
> >
> > I think it is appropriate to file a bug asking that this be disabled
> > when the freeze is on. As far as I can tell there is no
> > machine-readable indicator that buster is frozen, but there used to be
> > one for stretch in the release team's calendar file. So this would
> > require the release team to create a machine-readable way for the
> > tracker to know if testing is currently frozen.
> >
> > https://release.debian.org/release-calendar.ics
>
> filing a bug for this as suggested.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#930533: racket: please clean up mentions of plt-scheme

[David Bremner]

Package: racket
Version: 7.1+dfsg1-1~bpo9+1
Severity: wishlist


plt-scheme hasn't existed for almost a decade. The description and
transitional packages can probably be cleaned up.

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

Kernel: Linux 4.19.0-0.bpo.5-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages racket depends on:
ii  libc6  2.24-11+deb9u4
ii  libffi63.2.1-6
ii  racket-common  7.1+dfsg1-1~bpo9+1

Versions of packages racket recommends:
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgtk2.0-0  2.24.31-2
ii  libjpeg62-turbo  1:1.5.1-2
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpng16-16  1.6.28-1+deb9u1
ii  libssl1.11.1.0j-1~deb9u1
ii  racket-doc   7.1+dfsg1-1~bpo9+1

racket suggests no packages.

-- no debconf information

Bug#929737: [Debian GNUstep maintainers] Bug#929737: gnumail.app: gnumail freezes when 'quit' is clicked

[Yavor Doganov]

On Thu, 30 May 2019 00:35:25 +0300,
Svetlana Tkachenko wrote:
> Package: gnumail.app

> I clicked 'quit'.
> 
>* What was the outcome of this action?
> 
> The 'quit' menu item remained highlighted and gnumail remained open.
> 
>* What outcome did you expect instead?
> 
> Instant quit.

Could you please check the console output and eventually run the
program in gdb as explained in #929738?  Also check if it doesn't
interfere with a manual GNUMail installation.

> -- System Information:
> Debian Release: buster/sid
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')

I wonder what system this is.  Stretch upgraded to testing?

Bug#930532: xymon: imaps reports "unexpected service response"

[Ari Sovijarvi]

Package: xymon
Version: 4.3.28-5
Severity: normal

After upgrading from Debian 9 to 10, Xymon has issues checking imaps service. 
This
appears to relate to SSL somehow, as if I change the imaps definition in 
protocols.cfg
to drop SSL and change port to non-SSL, it works as expected.

In the other end I have Dovecot with a valid certificate and I can connect to 
with with
openssl's s_client without problems.

In short, this works:
[imaps]
   send "ABC123 LOGOUT\r\n"
   expect "* OK"
   options banner
   port 143

This does not:
[imaps]
   send "ABC123 LOGOUT\r\n"
   expect "* OK"
   options ssl,banner
   port 993

Dovecot shares the certificate with Apache, which provices web mail, SSL 
connection to
Apache seems to work. Also, even when the imaps protocol test doesn't work, the 
certificate
appears correctly in the sslcert-test in Xymon.

This does not seem to leave anything in any of the Xymon's log files.


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

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

Versions of packages xymon depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc-ares2 1.14.0-1
ii  libc6  2.28-10
ii  libldap-2.4-2  2.4.47+dfsg-3
ii  libpcre3   2:8.39-12
ii  librrd81.7.1-2
ii  libssl1.1  1.1.1b-2
ii  lsb-base   10.2019051400
ii  xymon-client   4.3.28-5

Versions of packages xymon recommends:
ii  apache2 [httpd-cgi]  2.4.38-3

Versions of packages xymon suggests:
ii  rename   1.10-1
ii  rrdtool  1.7.1-2

-- Configuration Files:
/etc/apache2/conf-available/xymon.conf changed [not included]
/etc/xymon/alerts.cfg changed [not included]
/etc/xymon/analysis.cfg changed [not included]
/etc/xymon/critical.cfg.bak [Errno 2] No such file or directory: 
'/etc/xymon/critical.cfg.bak'
/etc/xymon/protocols.cfg changed [not included]
/etc/xymon/xymonserver.cfg changed [not included]

-- debconf information:
  hobbit-client/automatic-xymon-migration: true

Bug#930531: grub2-common: grub-install --force-extra-removable does not work properly with Secure Boot

[Steve McIntyre]

Package: grub2-common
Version: 2.02+dfsg1-18
Severity: serious

Hey Colin,

Now that we have shim and signed binaries in the archive, the extra
code to install grubXXX.efi to the removable media path has to take
this into account too, or people using secure boot will end up with
broken systems that won't boot.

Looking into code to do this now.

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/tack--vg-lv_root / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda2 /boot ext2 rw,relatime,block_validity,barrier,user_xattr,acl,stripe=4 
0 0
/dev/sda1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
/dev/mapper/tack--vg-lv_scratch /scratch ext4 rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_scratch /var/www/mirror ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_home /home ext4 rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/buster-amd64-ae95d8fb-ca7e-4d82-8da8-45d8e8dc78bc ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_home 
/run/schroot/mount/buster-amd64-ae95d8fb-ca7e-4d82-8da8-45d8e8dc78bc/home ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/buster-amd64-ae95d8fb-ca7e-4d82-8da8-45d8e8dc78bc/tmp ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-410245e6-819e-42a5-a194-9ae0b254ef7f ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_home 
/run/schroot/mount/sid-410245e6-819e-42a5-a194-9ae0b254ef7f/home ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-410245e6-819e-42a5-a194-9ae0b254ef7f/tmp ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-4568a602-5a45-4ec9-9103-fb115cc4f1a4 ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_home 
/run/schroot/mount/sid-4568a602-5a45-4ec9-9103-fb115cc4f1a4/home ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-4568a602-5a45-4ec9-9103-fb115cc4f1a4/tmp ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-6544df41-9ed7-490a-8f32-df7aa7cb09cb ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_home 
/run/schroot/mount/sid-6544df41-9ed7-490a-8f32-df7aa7cb09cb/home ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-6544df41-9ed7-490a-8f32-df7aa7cb09cb/tmp ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-6616ad0e-5db2-4d38-96a4-2680a17ca733 ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_home 
/run/schroot/mount/sid-6616ad0e-5db2-4d38-96a4-2680a17ca733/home ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-6616ad0e-5db2-4d38-96a4-2680a17ca733/tmp ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-9471e88b-b7e3-4973-b8d2-07dd531b56a8 ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_home 
/run/schroot/mount/sid-9471e88b-b7e3-4973-b8d2-07dd531b56a8/home ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-9471e88b-b7e3-4973-b8d2-07dd531b56a8/tmp ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-96cd9c31-1413-45a3-aa51-fc4ab220b5e9 ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_home 
/run/schroot/mount/sid-96cd9c31-1413-45a3-aa51-fc4ab220b5e9/home ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-96cd9c31-1413-45a3-aa51-fc4ab220b5e9/tmp ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-9b8885af-ce11-40f2-8ded-b907cf102d0f ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_home 
/run/schroot/mount/sid-9b8885af-ce11-40f2-8ded-b907cf102d0f/home ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-9b8885af-ce11-40f2-8ded-b907cf102d0f/tmp ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-c39fecac-ca7e-4f75-a800-5137c3adfb35 ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_home 
/run/schroot/mount/sid-c39fecac-ca7e-4f75-a800-5137c3adfb35/home ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-c39fecac-ca7e-4f75-a800-5137c3adfb35/tmp ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-cb9d44d0-9848-4bb1-b9d2-09c4cb0b0723 ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_home 
/run/schroot/mount/sid-cb9d44d0-9848-4bb1-b9d2-09c4cb0b0723/home ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run/schroot/mount/sid-cb9d44d0-9848-4bb1-b9d2-09c4cb0b0723/tmp ext4 
rw,relatime,errors=remount-ro 0 0
/dev/mapper/tack--vg-lv_root 
/run

Bug#929738: gnumail.app: gnumail freezes when i click 'info > preferences'

[Yavor Doganov]

Здравствуйте, Светлана!

On Sat, 01 Jun 2019 00:00:31 +0300,
Svetlana Tkachenko wrote:
> 2019-06-01 06:59:34.014 GNUMail[21423:21423] Bad application class '(null)' 
> specified
> 2019-06-01 06:59:34.531 GNUMail[21423:21423] Problem posting notification: 
>  NAME:NSInvalidArgumentException REASON:[NSURL 
> initFileURLWithPath:] nil string parameter INFO:(null)

Hm, this shouldn't happen -- I suspect that's the culprit.  Please
install the relevant -dbgsym packages, run GNUMail in gdb and put a
break on NSException -raise; like this:

$ gdb GNUMail
(gdb) break -[NSException raise]
Function "-[NSException raise]" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (-[NSException raise]) pending.
(gdb) run

When you reach the breakpoint, type "bt" at the gdb prompt and post
the backtrace.

С уважением,
Явор

Bug#930294: Nautilus slow to respond and consumes 100% CPU resource

[Vikram Vincent]

Package: nautilus
Followup-For: Bug #930294

Nautilus found files with duplicate filenames in some libreoffice templates in
the Templates folder and was looping on that.  The moment I deleted the
content, nautilus behaviour came back to normal.
Question is why was nautilus looping forever?



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

Kernel: Linux 4.19.0-5-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 nautilus depends on:
ii  bubblewrap 0.3.1-4
ii  desktop-file-utils 0.23-4
ii  gsettings-desktop-schemas  3.28.1-1
ii  gvfs   1.38.1-5
ii  libatk1.0-02.30.0-2
ii  libc6  2.28-10
ii  libcairo-gobject2  1.16.0-4
ii  libcairo2  1.16.0-4
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libgexiv2-20.10.9-1
ii  libglib2.0-0   2.58.3-2
ii  libglib2.0-data2.58.3-2
ii  libgnome-autoar-0-00.2.3-2
ii  libgtk-3-0 3.24.5-1
ii  libnautilus-extension1a3.30.5-2
ii  libpango-1.0-0 1.42.4-6
ii  libpangocairo-1.0-01.42.4-6
ii  libseccomp22.3.3-4
ii  libselinux12.8-1+b1
ii  libtracker-sparql-2.0-02.1.8-2
ii  nautilus-data  3.30.5-2
ii  shared-mime-info   1.10-1
ii  tracker2.1.8-2

Versions of packages nautilus recommends:
ii  gnome-sushi  3.30.0-2
ii  gvfs-backends1.38.1-5
ii  librsvg2-common  2.44.10-2.1

Versions of packages nautilus suggests:
ii  eog 3.28.4-2+b1
ii  evince [pdf-viewer] 3.30.2-3
pn  nautilus-extension-brasero  
ii  nautilus-sendto 3.8.6-3
ii  totem   3.32.0-1
ii  vlc [mp3-decoder]   3.0.7-1
ii  xdg-user-dirs   0.17-2

-- no debconf information

Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3

[Ilias Tsitsimpis]

Hi again,

Sorry for the late reply. Hopefully we can still fix this.

On Sat, Jun 08, 2019 at 10:35PM, Paul Gevers wrote:
> I *think* we could also binNMU in experimental. And we could just try a
> couple of packages that you know that won't work right now.

I tried to find a package which has as fewer Haskell dependencies as
possible and found happy, which build-depends only on ghc.

The current version of happy on ARMEL is broken:

objdump -d /usr/bin/happy |grep  uxth
  15c0ac:   e6ff1072uxthr1, r2
  15c184:   e6ff2073uxthr2, r3
  1ab0ac:   e6ff107euxthr1, lr
  1ab0e8:   e6ff1073uxthr1, r3
  1ab158:   e6ff107euxthr1, lr
  1ab19c:   e6ff1073uxthr1, r3
  ...

(notice that the UXTH command is supported only on ARMv6 or later [1])

[1] http://infocenter.arm.com/help/topic/com.arm.doc.dui0489i/CIHHJCFE.html

and I can trigger the above instruction with:

$ gdb -q -ex 'b *(0x1ab0ac)' -ex 'run' -ex 'x/i $pc' -ex 'quit' --args 
happy example.y
Reading symbols from happy...(no debugging symbols found)...done.
Breakpoint 1 at 0x1ab0ac
Starting program: /usr/bin/happy example.y
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/arm-linux-gnueabi/libthread_db.so.1".

Breakpoint 1, 0x001ab0ac in ?? ()
=> 0x1ab0ac:uxthr1, lr
A debugging session is active.

Inferior 1 [process 29559] will be killed.

Quit anyway? (y or n) y

As input, I used the attached example taken from [2].

[2] https://www.haskell.org/happy/doc/html/sec-using.html

I then rebuild ghc with the proposed patch on abel, and used that to
rebuild happy. The final binary does not contain the UXTH instruction.

I have uploaded both ghc and happy here, in case you need Emanuele to
verify that the current version of happy fails, whereas the new one
works:

https://www.iliastsi.net/ghc/ghc_8.4.4+dfsg1-2+armel0_armel.deb
  sha256: 5d8dae44d79545aeee34755baa6c51ffe80db8309051978aaa9ac8857d6efde9 
https://www.iliastsi.net/ghc/ghc-doc_8.4.4+dfsg1-2+armel0_all.deb
  sha256: bffaf0957deb767d75e251f92dd8a59c6277c5b986241219fbb26ea3400284fa
https://www.iliastsi.net/ghc/ghc-prof_8.4.4+dfsg1-2+armel0_armel.deb
  sha256: 8fde49d87ad410ae5fec77ac89af4da11f4a2dd0924f0085a2f5f9c6e93fc09c
https://www.iliastsi.net/ghc/happy_1.19.9-6+armel0_armel.deb
  sha256: c560c02e7369c08de18f7151bcb53245a1c7f4ab83e9c07265beef7ca0e24921

So, it seems that the proposed patch does indeed resolve the issue.
Unfortunately, I cannot provide any guarantee that it will not introduce
any bugs that weren't there before, but I believe the only way to find
out is to upload a fixed version of GHC on unstable and schedule the
required binNMUs. If all of them succeed, we can then unblock them.

-- 
Ilias
{
module Main where
}

%name calc
%tokentype { Token }
%error { parseError }

%token 
  let { TokenLet }
  in  { TokenIn }
  int { TokenInt $$ }
  var { TokenVar $$ }
  '=' { TokenEq }
  '+' { TokenPlus }
  '-' { TokenMinus }
  '*' { TokenTimes }
  '/' { TokenDiv }
  '(' { TokenOB }
  ')' { TokenCB }

%%

Exp   : let var '=' Exp in Exp  { Let $2 $4 $6 }
  | Exp1{ Exp1 $1 }

Exp1  : Exp1 '+' Term   { Plus $1 $3 }
  | Exp1 '-' Term   { Minus $1 $3 }
  | Term{ Term $1 }

Term  : Term '*' Factor { Times $1 $3 }
  | Term '/' Factor { Div $1 $3 }
  | Factor  { Factor $1 }

Factor
  : int { Int $1 }
  | var { Var $1 }
  | '(' Exp ')' { Brack $2 }

{

parseError :: [Token] -> a
parseError _ = error "Parse error"

data Exp  
  = Let String Exp Exp
  | Exp1 Exp1
  deriving Show

data Exp1 
  = Plus Exp1 Term 
  | Minus Exp1 Term 
  | Term Term
  deriving Show

data Term 
  = Times Term Factor 
  | Div Term Factor 
  | Factor Factor
  deriving Show

data Factor 
  = Int Int 
  | Var String 
  | Brack Exp
  deriving Show

data Token
  = TokenLet
  | TokenIn
  | TokenInt Int
  | TokenVar String
  | TokenEq
  | TokenPlus
  | TokenMinus
  | TokenTimes
  | TokenDiv
  | TokenOB
  | TokenCB
 deriving Show


lexer :: String -> [Token]
lexer [] = []
lexer (c:cs) 
  | isSpace c = lexer cs
  | isAlpha c = lexVar (c:cs)
  | isDigit c = lexNum (c:cs)
lexer ('=':cs) = TokenEq : lexer cs
lexer ('+':cs) = TokenPlus : lexer cs
lexer ('-':cs) = TokenMinus : lexer cs
lexer ('*':cs) = TokenTimes : lexer cs
lexer ('/':cs) = Toke

Bug#930530: pcscd: Runs with possibly unnecessary privileges

[Kevin Locke]

Package: pcscd
Version: 1.8.24-1
Severity: normal

Dear Maintainer,

pcscd currently runs as root.  This is a security risk (as pointed out
in the SECURITY file shipped with pcscd).  It was previously fixed in
Bug #606142 and regressed back to root when systemd support was added
(setgid was removed in 798d03c).

Is there a reason that pcscd needs to run as root, rather than a normal
user with access to the necessary device files?  If so, could the
rationale be documented in the SECURITY file?  If not, what would be
required to run as a non-root user and would you accept patches that
make the necessary changes?

Thanks,
Kevin


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

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

Versions of packages pcscd depends on:
ii  libc6   2.28-10
ii  libccid [pcsc-ifd-handler]  1.4.30-1
ii  libpcsclite11.8.24-1
ii  libsystemd0 241-5
ii  libudev1241-5
ii  lsb-base10.2019051400

pcscd recommends no packages.

Versions of packages pcscd suggests:
ii  systemd  241-5

-- no debconf information

Bug#863293: Bug#863255: Please rename/provide libjs-jquery-atwho

[Pirate Praveen]

On Thu, 25 May 2017 09:30:05 +1000 Ben Finney 
wrote: > > […] Also consider providing node-at.js as I may need it for new
> > version of gitlab (9.x) which depends on all node modules and uses
> > webpack directly (instead of depending on libjs packages).
> 
> This is a separate request, so I'm opening a new bug report based on
> that request.

Please review
https://salsa.debian.org/debian/pkg-jquery-at.js/merge_requests/1



signature.asc
Description: OpenPGP digital signature

Bug#930365: CUDA 10.1 Update 1 is now available

[Graham Inggs]

Hi all

On 2019/06/12 14:23, Andreas Beckmann wrote:

Nice. I'll look into this next month (after buster was released).


I was keen to try the new version to see if it solved a problem with 
p2pBandwidthLatencyTest locking up on a machine with two TITAN X GPUs, 
so I went ahead and pushed a 10.1update1-ginggs branch [1] to git.  The 
problem ended up being with the 418 driver, and upgrading to 430 seems 
to have solved it.


As of now, my packaging attempt builds on amd64 and ppc64el, and I'll be 
running some tests on it next week.


There are still some Lintian warnings and errors, and I'd like some 
suggestions on which should be fixed and which can be overridden, please.


E: nsight-systems: binary-or-shlib-defines-rpath 
usr/lib/nsight-systems/Host-x86_64/libicudata.so.56 /home/qt/icu_install/lib
W: nsight-systems: shared-lib-without-dependency-information 
usr/lib/nsight-systems/Host-x86_64/libicudata.so.56
E: nsight-systems: binary-or-shlib-defines-rpath 
usr/lib/nsight-systems/Host-x86_64/libicui18n.so.56 /home/qt/icu_install/lib
E: nsight-systems: binary-or-shlib-defines-rpath 
usr/lib/nsight-systems/Host-x86_64/libicuuc.so.56 /home/qt/icu_install/lib

W: nsight-systems: binary-without-manpage usr/bin/nsight-sys

W: nvidia-nsight: jar-not-in-usr-share 
usr/lib/nvidia-nsight/configuration/org.eclipse.osgi/201/data/1519573780/content.jar
W: nvidia-nsight: jar-not-in-usr-share 
usr/lib/nvidia-nsight/configuration/org.eclipse.osgi/210/data/listener_1925729951/artifacts.jar
W: nvidia-nsight: jar-not-in-usr-share 
usr/lib/nvidia-nsight/configuration/org.eclipse.osgi/210/data/listener_1925729951/content.jar
W: nvidia-nsight: jar-not-in-usr-share 
usr/lib/nvidia-nsight/configuration/org.eclipse.osgi/74/0/.cp/lib/Tidy.jar
W: nvidia-nsight: jar-not-in-usr-share 
usr/lib/nvidia-nsight/configuration/org.eclipse.osgi/74/0/.cp/lib/commons-cli-1.0.jar


W: nsight-compute: binary-without-manpage usr/bin/nv-nsight-cu
W: nsight-compute: binary-without-manpage usr/bin/nv-nsight-cu-cli

W: nvidia-cuda-toolkit: binary-without-manpage usr/bin/bin2c
W: nvidia-cuda-toolkit: binary-without-manpage usr/bin/cudafe++
W: nvidia-cuda-toolkit: binary-without-manpage usr/bin/fatbinary
W: nvidia-cuda-toolkit: binary-without-manpage usr/bin/gpu-library-advisor
W: nvidia-cuda-toolkit: binary-without-manpage usr/bin/nvlink
W: nvidia-cuda-toolkit: binary-without-manpage usr/bin/ptxas

Regards
Graham


[1] 
https://salsa.debian.org/nvidia-team/nvidia-cuda-toolkit/tree/10.1update1-ginggs

Bug#928099: Shc's License

[Tong Sun]

On Tue, Jun 11, 2019 at 7:45 AM Tong Sun wrote:
>
> > On Tue, Jun 11, 2019 at 4:40 AM Bart Martens wrote:
> >
> > On Mon, Jun 10, 2019 at 4:26 PM Tong Sun wrote:
> > >
> > > On Thu, Jun 6, 2019 at 8:05 AM Tong Sun wrote:
> > > >
> > > > On Wed, Jun 5, 2019 at 8:32 PM Tong Sun wrote:
> > > > >
> > > > > On Sat, Jun 1, 2019 at 10:24 AM Tong Sun wrote:
> > > > > >
> > > > > > On Sat, May 25, 2019 at 9:02 AM Tong Sun wrote:
> > > > > >
> > > > > > > Thx. I'll change the license to GPL-3+.
> > > > > >
> > > > > > Hi Bart,
> > > > > >
> > > > > > Do think the following change OK?
> > > > > >
> > > > > > https://salsa.debian.org/debian/shc/commit/933d1a533842e3ddaf3e79ac3e1580842f4fef12
> > > > >
> > > > > I've fixed the GPL thing:
> > > > > https://salsa.debian.org/debian/shc/blob/master/debian/copyright
> > > > >
> > > > > I double-checked when you asked me the GPL or LGPL question, but
> > > > > didn't find anything prompted your question myself.
> > > > >
> > > > > Anyway, the reason I'm asking whether you think the change was OK, is
> > > > > that I don't know how to properly express within the debian/copyright
> > > > > file that the original author, Francisco, was using GPL-2+ license,
> > > > > while new version, from https://github.com/neurobin/shc, is using
> > > > > GPL-3+.
> > > > >
> > > > > So once again, This is the way I'm expressing it:
> > > > >
> > > > > Files: *
> > > > > Copyright:
> > > > >  Francisco Rosales , Copyright 1994-2015
> > > > > License: GPL-2.0+
> > > > > Files: *
> > > > > Copyright:
> > > > >  Md Jahidul Hamid , Copyright 2015-2019
> > > > > License: GPL-3+
> > > > >
> > > > > However, I've got a warning:
> > > > >
> > > > > shc source: 
> > > > > global-files-wildcard-not-first-paragraph-in-dep5-copyright
> > > > > (paragraph at line 10)
> > > > >
> > > > > Would that be OK, or there IS a proper way to express it?
> > > >
> > > > Ah, I now remember, there is a way to suppress lintian warnings.
> > > > IMHO, it is the best way so far...
> > > >
> > > > Thx
> > >
> > > ping
> > >
> > > Pong. Has my past feedback been fully used? Are my past e-mails still 
> > > somewhere
> > > in your mailbox?
> > >
> Sorry, please remind me how did you suggest me to do with this?
>
> shc source: global-files-wildcard-not-first-paragraph-in-dep5-copyright
> (paragraph at line 10)

Hi Bart,

I don't know how to properly express within the debian/copyright
file that the original author, Francisco, was using GPL-2+ license,
while new version, from https://github.com/neurobin/shc, is using
GPL-3+.

And I need your kind help to do it properly.

As for the most of the time in the message trail above and in the
history, I've guessed wrong about what you meant from your short
message. If you can give detailed help, that'd be most appreciated,

Thanks

tong

Bug#930529: Use packaged version of pikaday - fix Sass::SyntaxError: File to import not found or unreadable

[Pirate Praveen]

Package: gitlab
version: 11.8.10+dfsg-1
Severity: wishlist
Control: block 930404 by -1

When trying to use packaged node-pikaday, webpack fails to find scss 
files of node-pikaday. We will have to tell gitlab to look in system 
path for scss files as well (like how we do it for js modules and 
loaders).


rake aborted!
Sass::SyntaxError: File to import not found or unreadable: 
../../../node_modules/pikaday/scss/pikaday.

Load paths:
 /usr/share/gitlab/app/assets/images
 /usr/share/gitlab/app/assets/javascripts
 /usr/share/gitlab/app/assets/stylesheets
 /usr/share/gitlab/vendor/assets/javascripts
 /usr/share/gitlab/vendor/assets/stylesheets
 
/usr/share/rubygems-integration/all/gems/peek-rblineprof-0.2.0/app/assets/javascripts
 
/usr/share/rubygems-integration/all/gems/peek-rblineprof-0.2.0/app/assets/stylesheets
 
/usr/share/rubygems-integration/all/gems/peek-1.0.1/app/assets/javascripts
 
/usr/share/rubygems-integration/all/gems/peek-1.0.1/app/assets/stylesheets
 
/usr/share/rubygems-integration/all/gems/gettext_i18n_rails_js-1.3.0/lib/assets/javascripts
 
/usr/share/rubygems-integration/all/gems/gettext_i18n_rails_js-1.3.0/vendor/assets/javascripts

 /usr/share/ruby-font-awesome-rails/app/assets/fonts
 /usr/share/ruby-font-awesome-rails/app/assets/stylesheets
 
/usr/share/rubygems-integration/all/gems/ace-rails-ap-4.1.1/vendor/assets/javascripts
 
/usr/share/rubygems-integration/all/gems/bootstrap_form-4.2.0/app/assets/stylesheets
 
/usr/share/rubygems-integration/all/gems/graphiql-rails-1.4.10/app/assets/javascripts
 
/usr/share/rubygems-integration/all/gems/graphiql-rails-1.4.10/app/assets/stylesheets
 
/usr/share/rubygems-integration/all/gems/doorkeeper-4.4.2/app/assets/stylesheets
 
/usr/share/rubygems-integration/all/gems/doorkeeper-4.4.2/vendor/assets/stylesheets

 /usr/share/gitlab/vendor/gems/actioncable-5.1.6.1/lib/assets/compiled
 /usr/share/gitlab/vendor/gems/actionview-5.1.6.1/lib/assets/compiled
 /usr/share/rubygems-integration/all/gems/gemojione-3.3.0/assets/png
 /usr/share/gitlab/vendor/assets/fonts
 /usr/share/gitlab/node_modules/@gitlab/svgs/dist
 /usr/share/gitlab/node_modules/xterm/src
 /usr/share/rubygems-integration/all/gems/gemojione-3.3.0/assets/png
 /usr/share/gitlab/vendor/assets/fonts
 /usr/share/gitlab/node_modules/@gitlab/svgs/dist
 /usr/share/gitlab/node_modules/xterm/src
/usr/share/gitlab/app/assets/stylesheets/application.scss:15

Caused by:
Sass::SyntaxError: File to import not found or unreadable: 
../../../node_modules/pikaday/scss/pikaday.

Load paths:
 /usr/share/gitlab/app/assets/images
 /usr/share/gitlab/app/assets/javascripts
 /usr/share/gitlab/app/assets/stylesheets
 /usr/share/gitlab/vendor/assets/javascripts
 /usr/share/gitlab/vendor/assets/stylesheets
 
/usr/share/rubygems-integration/all/gems/peek-rblineprof-0.2.0/app/assets/javascripts
 
/usr/share/rubygems-integration/all/gems/peek-rblineprof-0.2.0/app/assets/stylesheets
 
/usr/share/rubygems-integration/all/gems/peek-1.0.1/app/assets/javascripts
 
/usr/share/rubygems-integration/all/gems/peek-1.0.1/app/assets/stylesheets
 
/usr/share/rubygems-integration/all/gems/gettext_i18n_rails_js-1.3.0/lib/assets/javascripts
 
/usr/share/rubygems-integration/all/gems/gettext_i18n_rails_js-1.3.0/vendor/assets/javascripts

 /usr/share/ruby-font-awesome-rails/app/assets/fonts
 /usr/share/ruby-font-awesome-rails/app/assets/stylesheets
 
/usr/share/rubygems-integration/all/gems/ace-rails-ap-4.1.1/vendor/assets/javascripts
 
/usr/share/rubygems-integration/all/gems/bootstrap_form-4.2.0/app/assets/stylesheets
 
/usr/share/rubygems-integration/all/gems/graphiql-rails-1.4.10/app/assets/javascripts
 
/usr/share/rubygems-integration/all/gems/graphiql-rails-1.4.10/app/assets/stylesheets
 
/usr/share/rubygems-integration/all/gems/doorkeeper-4.4.2/app/assets/stylesheets
 
/usr/share/rubygems-integration/all/gems/doorkeeper-4.4.2/vendor/assets/stylesheets

 /usr/share/gitlab/vendor/gems/actioncable-5.1.6.1/lib/assets/compiled
 /usr/share/gitlab/vendor/gems/actionview-5.1.6.1/lib/assets/compiled
 /usr/share/rubygems-integration/all/gems/gemojione-3.3.0/assets/png
 /usr/share/gitlab/vendor/assets/fonts
 /usr/share/gitlab/node_modules/@gitlab/svgs/dist
 /usr/share/gitlab/node_modules/xterm/src
 /usr/share/rubygems-integration/all/gems/gemojione-3.3.0/assets/png
 /usr/share/gitlab/vendor/assets/fonts
 /usr/share/gitlab/node_modules/@gitlab/svgs/dist
 /usr/share/gitlab/node_modules/xterm/src

Tasks: TOP => assets:precompile
(See full trace by running task with --trace)

Bug#930528: unblock: grml-debootstrap/0.89

[Michael Prokop]

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

Please unblock package grml-debootstrap v0.89, which fixes two major
issues:

1) The generated /etc/network/interfaces file might contain wrong
   interface names, e.g. for virtio drivers that have properties like
   ID_NET_NAME_PATH=enp0s18 and ID_NET_NAME_SLOT=ens18. If we check
   only for ID_NET_NAME_PATH, then we end up with a network
   configuration for enp0s18, while the actual network interface name
   will be ens18 on next boot.
   This fixes #929810

2) When installing with debootstrap/mmdebstrap variants
   essential/minbase, the directory /etc/network doesn't exist yet (due
   to absense of ifupdown/netbase packages) and setting up
   /etc/network/interfaces fails.
   This fixes #930468

I just uploaded grml-debootstrap/0.89 towards unstable,
related debdiff is at the end of the mail.

Thanks for consideration!

unblock grml-debootstrap/0.89

regards
-mika-

diff -Nru grml-debootstrap-0.88/debian/changelog 
grml-debootstrap-0.89/debian/changelog
--- grml-debootstrap-0.88/debian/changelog  2019-03-02 11:27:00.0 
+0100
+++ grml-debootstrap-0.89/debian/changelog  2019-06-14 14:47:02.0 
+0200
@@ -1,3 +1,12 @@
+grml-debootstrap (0.89) unstable; urgency=medium
+
+  * [2860f13] Fix detection of predictable network interface names
+(Closes: #929810)
+  * [7a11723] Ensure /etc/network exists before setting up
+/etc/network/interfaces (Closes: #930468)
+
+ -- Michael Prokop   Fri, 14 Jun 2019 14:47:02 +0200
+
 grml-debootstrap (0.88) unstable; urgency=medium

   [ Michael Prokop ]
diff -Nru grml-debootstrap-0.88/grml-debootstrap 
grml-debootstrap-0.89/grml-debootstrap
--- grml-debootstrap-0.88/grml-debootstrap  2019-03-02 11:27:00.0 
+0100
+++ grml-debootstrap-0.89/grml-debootstrap  2019-06-14 14:47:02.0 
+0200
@@ -1730,37 +1730,58 @@

   # add dhcp setting for Predictable Network Interface Names
   if [ -x /bin/udevadm ]; then
-for interface in $(udevadm info -e | sed -n -e 's/E: 
ID_NET_NAME_PATH=\([^$*]\)/\1/p'); do
-  DEFAULT_INTERFACES="${DEFAULT_INTERFACES}
+tmpfile=$(mktemp)
+for interface in /sys/class/net/*; do
+  udevadm info --query=all --path="${interface}" > "${tmpfile}"
+  # skip virtual devices, like bridges, vboxnet,...
+  if grep -q 'P: /devices/virtual/net/' "${tmpfile}" ; then
+continue
+  fi
+
+  # iterate over possible naming policies by precedence (see 
udev/net/link-config.c),
+  # use and stop on first match to have same behavior as udev's 
link_config_apply()
+  for property in ID_NET_NAME_FROM_DATABASE ID_NET_NAME_ONBOARD 
ID_NET_NAME_SLOT ID_NET_NAME_PATH ID_NET_NAME_MAC ; do
+if grep -q "${property}" "${tmpfile}" ; then
+  interface=$(grep "${property}" "${tmpfile}" | sed -n -e "s/E: 
${property}=\([^\$*]\)/\1/p")
+  DEFAULT_INTERFACES="${DEFAULT_INTERFACES}
 allow-hotplug ${interface}
 iface ${interface} inet dhcp
 "
+  break
+fi
+  done
 done
+rm -f "${tmpfile}"
   fi

   if [ -n "$NOINTERFACES" ] ; then
 einfo "Not installing /etc/network/interfaces as requested via 
--nointerfaces option" ; eend 0
   elif [ -n "$USE_DEFAULT_INTERFACES" ] ; then
 einfo "Installing default /etc/network/interfaces as requested via 
--defaultinterfaces options."
+mkdir -p "${MNTPOINT}/etc/network"
 echo "$DEFAULT_INTERFACES" > "${MNTPOINT}/etc/network/interfaces"
 eend $?
   elif [ -n "$VIRTUAL" ] ; then
 einfo "Setting up Virtual Machine, installing default 
/etc/network/interfaces"
+mkdir -p "${MNTPOINT}/etc/network"
 echo "$DEFAULT_INTERFACES" > "${MNTPOINT}/etc/network/interfaces"
 eend $?
   elif [ -r /etc/network/interfaces ] ; then
 einfo "Copying /etc/network/interfaces from host to target system"
+mkdir -p "${MNTPOINT}/etc/network"
 cp $VERBOSE /etc/network/interfaces "${MNTPOINT}/etc/network/interfaces"
 eend $?
   else
 ewarn "Couldn't read /etc/network/interfaces, installing default 
/etc/network/interfaces"
+mkdir -p "${MNTPOINT}/etc/network"
 echo "$DEFAULT_INTERFACES" > "${MNTPOINT}/etc/network/interfaces"
 eend $?
   fi

   # install config file providing some example entries
   if [ -r /etc/network/interfaces.examples ] && [ ! -r 
"$MNTPOINT/etc/network/interfaces.examples" ] ; then
- cp /etc/network/interfaces.examples 
"$MNTPOINT/etc/network/interfaces.examples"
+mkdir -p "${MNTPOINT}/etc/network"
+cp /etc/network/interfaces.examples 
"$MNTPOINT/etc/network/interfaces.examples"
   fi

   if [ -n "${SSHCOPYID}" ] ; then


signature.asc
Description: Digital signature

Bug#927711: CVE-2019-10044

[Moritz Mühlenhoff]

On Sat, May 11, 2019 at 05:38:50PM +0300, Коля Гурьев wrote:
> As John Preston said, there was no a special fix of the issue in 1.5.12.
> It is mistake that this version is considered to contain the fix.
> And as far as I can see, Telegram Desktop has no a fix of this CVE yet.

Ack, ok.

Cheers,
Moritz

Bug#930527: linux-image-4.19.0-5-amd64: when logging out, not the whole screen is erased, leaving private information

[Vincent Lefevre]

Package: src:linux
Version: 4.19.37-3
Severity: grave
Tags: security
Justification: user security hole

When logging out, a part of the previous session is still visible.
This might be used to compromise the user's account or leak other
private information, depending on what was written on the screen.

-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 
root=UUID=e3631277-c4d0-460e-a2a3-6de16013e050 ro quiet

** Tainted: I (2048)
 * Working around severe firmware bug.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Hewlett-Packard
product_name: HP Z800 Workstation
product_version: 
chassis_vendor: Hewlett-Packard
chassis_version: 
bios_vendor: Hewlett-Packard
bios_version: 786G5 v01.17
board_vendor: Hewlett-Packard
board_name: 0AECh
board_version: 

** Loaded modules:
devlink
cpufreq_powersave
cpufreq_conservative
cpufreq_userspace
bnep
bluetooth
drbg
ansi_cprng
ecdh_generic
binfmt_misc
nfsd
auth_rpcgss
nfs_acl
nfs
lockd
grace
fscache
sunrpc
smsc47b397
loop
firewire_sbp2
parport_pc
ppdev
lp
parport
nft_counter
ip6_tables
nft_compat
nf_tables
x_tables
nfnetlink
nouveau
mxm_wmi
video
intel_powerclamp
coretemp
kvm_intel
ttm
snd_hda_codec_realtek
drm_kms_helper
snd_hda_codec_generic
kvm
snd_hda_intel
drm
snd_hda_codec
hp_wmi
i2c_algo_bit
sparse_keymap
snd_hda_core
rfkill
irqbypass
snd_hwdep
evdev
snd_pcm
wmi_bmof
wmi
snd_timer
sg
intel_cstate
intel_uncore
serio_raw
snd
iTCO_wdt
iTCO_vendor_support
i7core_edac
soundcore
pcc_cpufreq
button
acpi_cpufreq
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
crypto_simd
cryptd
glue_helper
aes_x86_64
hid_generic
usbhid
hid
sr_mod
cdrom
sd_mod
ahci
mptsas
libahci
firewire_ohci
mptscsih
mptbase
psmouse
libata
crc32c_intel
scsi_transport_sas
ehci_pci
uhci_hcd
firewire_core
ehci_hcd
crc_itu_t
tg3
lpc_ich
scsi_mod
usbcore
libphy
floppy
usb_common

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 5520 I/O Hub to ESI Port 
[8086:3406] (rev 13)
Subsystem: Hewlett-Packard Company 5520 I/O Hub to ESI Port [103c:130b]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:01.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI Express 
Root Port 1 [8086:3408] (rev 13) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:03.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI Express 
Root Port 3 [8086:340a] (rev 13) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:07.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI Express 
Root Port 7 [8086:340e] (rev 13) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:10.0 PIC [0800]: Intel Corporation 7500/5520/5500/X58 Physical and Link 
Layer Registers Port 0 [8086:3425] (rev 13) (prog-if 00 [8259])
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:10.1 PIC [0800]: Intel Corporation 7500/5520/5500/X58 Routing and Protocol 
Layer Registers Port 0 [8086:3426] (rev 13) (prog-if 00 [8259])
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

00:11.1 PIC [0800]: Intel Corporation 7500/5520/5500 Routing & Protocol Layer 
Register Port 1 [8086:3428] (rev 13) (prog-if 00 [8259])
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 
Kernel driver in use: i7core_edac
Kernel modules: i7core_edac

00:14.

Bug#930526: incron creates zombie processes

[Dmitry Nezhevenko]

Package: incron
Version: 0.5.12-1
Severity: important
Tags: patch

Dear Maintainer,

After updating two machines from current stable to buster I've got a lot
of zombie processes caused by incron.

It looks like this known issue and was already fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=1656939

I'm attaching copy of patch from Fedora package that fixes this issue for
me.

It would be cool to have this applied to Buster release

-- 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 5.1.9 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, 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: systemd (via /run/systemd/system)

Versions of packages incron depends on:
ii  adduser  3.118
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10
ii  libgcc1  1:8.3.0-7
ii  libstdc++6   8.3.0-7
ii  lsb-base 10.2019051400

incron recommends no packages.

incron suggests no packages.

-- Configuration Files:
/etc/incron.allow [Errno 13] Permission denied: '/etc/incron.allow'
/etc/incron.deny [Errno 13] Permission denied: '/etc/incron.deny'

-- no debconf information

-- 
WBR, Dmitry
diff -Nur incron-0.5.12.orig/icd-main.cpp incron-0.5.12/icd-main.cpp
--- incron-0.5.12.orig/icd-main.cpp	2019-01-05 11:43:19.722640603 -0800
+++ incron-0.5.12/icd-main.cpp	2019-01-05 11:45:41.236340779 -0800
@@ -105,6 +105,7 @@
   g_fFinish = true;
   break;
 case SIGCHLD:
+  do {} while (waitpid((pid_t)-1, 0, WNOHANG) > 0); /* Prevent zombies */
   // first empty pipe (to prevent internal buffer overflow)
   do {} while (read(g_cldPipe[0], g_cldPipeBuf, CHILD_PIPE_BUF_LEN) > 0);
   

Bug#901586: [PATCH] Switch git log encoding to ensure it is utf-8

[Jiří Paleček]

tags -1 +patch
thanks

Hello,

this patch fixes the problem with non-utf8 git commit authors (at
least for me :) ) It does that by (temporarily) changing the git
output encoding to utf8. This doesn't still ensure the output will be
valid utf8 (ie. if invalid utf8 is already in the repository),
however, it deals with theproblem with other encodings.

Regards
Jiri Palecek

---
 gbp/git/repository.py | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/gbp/git/repository.py b/gbp/git/repository.py
index dfc8e55..6607122 100644
--- a/gbp/git/repository.py
+++ b/gbp/git/repository.py
@@ -1626,7 +1626,21 @@ class GitRepository(object):
 paths = [paths]
 args.add_cond(paths, paths)

+# switch git log encoding
+oldenc, ret = self._git_getoutput('config', ['--local', 
'i18n.logoutputencoding'])
+if ret:
+oldenc = None
+else:
+oldenc = oldenc[0].decode()[:-1]
+
+self._git_command('config', ['--local', 'i18n.logoutputencoding', 
'utf-8'])
+
 commits, ret = self._git_getoutput('log', args.args)
+if oldenc is None:
+self._git_command('config', ['--local', '--unset', 
'i18n.logoutputencoding'])
+else:
+self._git_command('config', ['--local', 'i18n.logoutputencoding', 
oldenc])
+
 if ret:
 where = " on %s" % paths if paths else ""
 raise GitRepositoryError("Error getting commits %s..%s%s" %
@@ -1693,7 +1707,7 @@ class GitRepository(object):
 """
 commit_sha1 = self.rev_parse("%s^0" % commitish)
 args = 
GitArgs('--pretty=format:%an%x00%ae%x00%ad%x00%cn%x00%ce%x00%cd%x00%s%x00%f%x00%b%x00',
-   '-z', '--date=raw', '--no-renames', '--name-status',
+   '-z', '--date=raw', '--no-renames', '--name-status', 
'--encoding=utf-8',
'--no-show-signature', commit_sha1)
 out, err, ret = self._git_inout('show', args.args)
 if ret:
--
2.20.1

Bug#930524: Rainloop suggests packages not in buster

[Evilham]

Package: rainloop
Version: 1.12.1-2

As the subject mentions, the rainloop package is suggesting 
packages that are not available on buster.


Specifically:

- php5-sqlite
- php5-mysql
- php5-pgsql

Since the rainloop documentation only says "PHP >= 5", maybe 
suggesting the versionless (php-*) packages instead is in order?


Thank you for starting this package,
--
Evilham

Bug#930522: linux: task md5_raid6:203 blocked for more than 120 seconds

[Thorsten Glaser]

On Fri, 14 Jun 2019, Thorsten Glaser wrote:

> Currently hanging processes:

Of course, sending the bug mail also failed, while I could
still do “virsh -c qemu:///system list --all”, which was
almost certainly not in the cache.

13610 ?D  0:00 /usr/sbin/postdrop -r
13615 ?D  0:00 cleanup -z -t unix -u -c

Funny thing though, trying to write a mail with pine showed
a temporary text file comprised of only 0x55 (and a hanging
alpine process) while others worked:

tglase@tglase:~ $ touch down
tglase@tglase:~ $ echo down >downdown
tglase@tglase:~ $ ll
[…]
-rw-r--r--   1 tglase tglase 0 Jun 14 16:03 down
-rw-r--r--   1 tglase tglase 5 Jun 14 16:03 downdown
[…]
tglase@tglase:~ $ cat downdown
down
tglase@tglase:~ $ cat ./\#pico13934\#
UUU[…]


I eventually had to reboot by power-cycling, and all those
files never showed up in ls after it, whereas /lost+found
is still empty; fsck (and RAID rebuild) messages were a lot
during the new boot though… so, _something_ probably made
it to disc.

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

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#930525: xcftools: files created with gimp-2.10 are not supported

[Diego Caraffini]

Package: xcftools
Version: 1.0.7-6
Severity: important

Dear Maintainer,

The current version of xfctools prints the following message:

Warning: XCF version 11 not supported (trying anyway...)

when converting an image created with the suggested version of gimp.
The resulting image (example command: xcf2png test.xcf -o test.png)
consists of a transparent layer only.

This makes the tool unusable with all xcf files that are modified using
the latest (and suggested)d version of gimp.



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

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

Versions of packages xcftools depends on:
ii  libc62.28-10
ii  libpng16-16  1.6.36-6
ii  xdg-utils1.1.3-1

Versions of packages xcftools recommends:
ii  mime-support  3.62

Versions of packages xcftools suggests:
ii  gimp2.10.8-2
ii  x11-common  1:7.7+19

-- no debconf information

Bug#930523: unblock: znc/1.7.2-3

[Patrick Matthäi]

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

Please unblock package znc

It fixes a critical security bug. Fix is also accepted for stable + testing
by the security team.
diff:

diff -Naur '--exclude=.svn' 1.7.2-2/debian/changelog 1.7.2-3/debian/changelog
--- 1.7.2-2/debian/changelog2019-03-26 12:58:06.264919659 +0100
+++ 1.7.2-3/debian/changelog2019-06-14 13:06:35.239889318 +0200
@@ -1,3 +1,10 @@
+znc (1.7.2-3) unstable; urgency=high
+
+  * Add upstream patch CVE-2019-12816 to fix a remote code execution by
+elevating privileges as described in CVE-2019-12816.
+
+ -- Patrick Matthäi   Fri, 14 Jun 2019 11:14:11 +0200
+
 znc (1.7.2-2) unstable; urgency=high

   * Add upstream patch 01-CVE-2019-9917 to fix a crash on invalid encoding,
diff -Naur '--exclude=.svn' 1.7.2-2/debian/patches/02-CVE-2019-12816.diff 
1.7.2-3/debian/patches/02-CVE-2019-12816.diff
--- 1.7.2-2/debian/patches/02-CVE-2019-12816.diff   1970-01-01 
01:00:00.0 +0100
+++ 1.7.2-3/debian/patches/02-CVE-2019-12816.diff   2019-06-14 
13:06:35.251889255 +0200
@@ -0,0 +1,88 @@
+# Fix security issue which causes elevating privileges by existing remote
+# non-admin user, and remote code execution.
+
+diff -Naur znc-1.7.2.orig/include/znc/Modules.h znc-1.7.2/include/znc/Modules.h
+--- znc-1.7.2.orig/include/znc/Modules.h   2019-06-13 11:13:33.035495175 
+0200
 znc-1.7.2/include/znc/Modules.h2019-06-13 11:16:33.966506967 +0200
+@@ -1600,6 +1600,7 @@
+   private:
+ static ModHandle OpenModule(const CString& sModule, const CString& 
sModPath,
+ CModInfo& Info, CString& sRetMsg);
++static bool VerifyModuleName(const CString& sModule, CString& sRetMsg);
+
+   protected:
+ CUser* m_pUser;
+diff -Naur znc-1.7.2.orig/src/Modules.cpp znc-1.7.2/src/Modules.cpp
+--- znc-1.7.2.orig/src/Modules.cpp 2019-06-13 11:13:32.979495481 +0200
 znc-1.7.2/src/Modules.cpp  2019-06-13 11:16:33.970506945 +0200
+@@ -1624,11 +1624,30 @@
+ return nullptr;
+ }
+
++bool CModules::VerifyModuleName(const CString& sModule, CString& sRetMsg) {
++for (unsigned int a = 0; a < sModule.length(); a++) {
++if (((sModule[a] < '0') || (sModule[a] > '9')) &&
++((sModule[a] < 'a') || (sModule[a] > 'z')) &&
++((sModule[a] < 'A') || (sModule[a] > 'Z')) && (sModule[a] != 
'_')) {
++sRetMsg =
++t_f("Module names can only contain letters, numbers and "
++"underscores, [{1}] is invalid")(sModule);
++return false;
++}
++}
++
++return true;
++}
++
+ bool CModules::LoadModule(const CString& sModule, const CString& sArgs,
+   CModInfo::EModuleType eType, CUser* pUser,
+   CIRCNetwork* pNetwork, CString& sRetMsg) {
+ sRetMsg = "";
+
++if (!VerifyModuleName(sModule, sRetMsg)) {
++return false;
++}
++
+ if (FindModule(sModule) != nullptr) {
+ sRetMsg = t_f("Module {1} already loaded.")(sModule);
+ return false;
+@@ -1781,6 +1800,10 @@
+
+ bool CModules::GetModInfo(CModInfo& ModInfo, const CString& sModule,
+   CString& sRetMsg) {
++if (!VerifyModuleName(sModule, sRetMsg)) {
++return false;
++}
++
+ CString sModPath, sTmp;
+
+ bool bSuccess;
+@@ -1799,6 +1822,10 @@
+
+ bool CModules::GetModPathInfo(CModInfo& ModInfo, const CString& sModule,
+   const CString& sModPath, CString& sRetMsg) {
++if (!VerifyModuleName(sModule, sRetMsg)) {
++return false;
++}
++
+ ModInfo.SetName(sModule);
+ ModInfo.SetPath(sModPath);
+
+@@ -1911,15 +1938,8 @@
+ // Some sane defaults in case anything errors out below
+ sRetMsg.clear();
+
+-for (unsigned int a = 0; a < sModule.length(); a++) {
+-if (((sModule[a] < '0') || (sModule[a] > '9')) &&
+-((sModule[a] < 'a') || (sModule[a] > 'z')) &&
+-((sModule[a] < 'A') || (sModule[a] > 'Z')) && (sModule[a] != 
'_')) {
+-sRetMsg =
+-t_f("Module names can only contain letters, numbers and "
+-"underscores, [{1}] is invalid")(sModule);
+-return nullptr;
+-}
++if (!VerifyModuleName(sModule, sRetMsg)) {
++return nullptr;
+ }
+
+ // The second argument to dlopen() has a long history. It seems clear
diff -Naur '--exclude=.svn' 1.7.2-2/debian/patches/series 
1.7.2-3/debian/patches/series
--- 1.7.2-2/debian/patches/series   2019-03-26 12:58:06.280919560 +0100
+++ 1.7.2-3/debian/patches/series   2019-06-14 13:06:35.251889255 +0200
@@ -1 +1,2 @@
 01-CVE-2019-9917.diff
+02-CVE-2019-12816.diff




unblock znc/1.7.2-3

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8

Bug#930065: ansible: CVE-2019-10156: templating causing an unexpected key file to be set on a remote node

[Lee Garrett]

Hi,

the updated pull request now also contains tests, which made it easier
for me to reproduce the issue. I will prepare an update for sid on
Sunday/Monday, and evaluate if this also applies for stable. AFAICS this
has a low impact, as it requires an attacker to provide the template
files (or a user to write faulty templates and not verify the output),
which already has grave security implications by itself.

Then again the RH bug tracker hints that it might be used to leak
passwords [0] (through the authorized_key module?), though the pull
request does not contain any changes there. Information on this CVE is
unfortunately rather vague.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1717311

Regards,
Lee

On 06/06/2019 14:16, Salvatore Bonaccorso wrote:
> Source: ansible
> Severity: important
> Tags: security upstream
> Forwarded: https://github.com/ansible/ansible/pull/57188
> 
> Hi,
> 
> The following vulnerability was published for ansible, can you check
> for which Debian versions this is relevant and adjust the found
> versions?
> 
> CVE-2019-10156[0]:
> templating causing an unexpected key file to be set on remote node
> 
> 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-10156
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10156
> [1] https://github.com/ansible/ansible/pull/57188
> 
> Regards,
> Salvatore
> 

Bug#930522: linux: task md5_raid6:203 blocked for more than 120 seconds

[Thorsten Glaser]

Package: linux-image-4.19.0-5-amd64
Version: 4.19.37-3
Severity: important

We’re back to tasks hanging, 99% of CPU being in wait.
This is somewhat similar to #913138 but not identical:
HDD reads seem to still work, as do some new writes,
but not all of them (e.g. I can run reportbug, but not
“man reportbug”; I can start new shells, which call
ansiweather and store the result, but I cannot run a
new Firefox instance; I can run sudo dmesg (below),
but not zless the linux-image-4.19.0-5-amd64 changelog).

dmesg has this:

[0.00] microcode: microcode updated early to revision 0x1d, date = 
2018-05-11
[0.00] Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) 
(gcc version 8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 
root=/dev/mapper/vg--tglase-lv--tglase ro rootdelay=5 net.ifnames=0 
syscall.x32=y vsyscall=emulate kaslr l1tf=flush,nosmt
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009dbff] usable
[0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xcfec] usable
[0.00] BIOS-e820: [mem 0xcfed-0xcfed0fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcfed1000-0xcfed] ACPI data
[0.00] BIOS-e820: [mem 0xcfee-0xcfef] reserved
[0.00] BIOS-e820: [mem 0xf400-0xf7ff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00062fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Gigabyte Technology Co., Ltd. X58-USB3/X58-USB3, BIOS F5 
09/07/2011
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 3064.513 MHz processor
[0.005423] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.005427] e820: remove [mem 0x000a-0x000f] usable
[0.005436] last_pfn = 0x63 max_arch_pfn = 0x4
[0.005443] MTRR default type: uncachable
[0.005444] MTRR fixed ranges enabled:
[0.005445]   0-9 write-back
[0.005447]   A-B uncachable
[0.005448]   C-CDFFF write-protect
[0.005449]   CE000-E uncachable
[0.005450]   F-F write-through
[0.005451] MTRR variable ranges enabled:
[0.005453]   0 base 0 mask F write-back
[0.005455]   1 base 0E000 mask FE000 uncachable
[0.005456]   2 base 0D000 mask FF000 uncachable
[0.005458]   3 base 1 mask F write-back
[0.005459]   4 base 2 mask E write-back
[0.005460]   5 base 4 mask C write-back
[0.005462]   6 base 5 mask F write-back
[0.005463]   7 base 6 mask FC000 write-back
[0.006397] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.006911] e820: update [mem 0xd000-0x] usable ==> reserved
[0.006918] last_pfn = 0xcfed0 max_arch_pfn = 0x4
[0.016355] found SMP MP-table at [mem 0x000f5a60-0x000f5a6f]
[0.029287] Base memory trampoline at [(ptrval)] 97000 size 24576
[0.029295] BRK [0x33d401000, 0x33d401fff] PGTABLE
[0.029297] BRK [0x33d402000, 0x33d402fff] PGTABLE
[0.029299] BRK [0x33d403000, 0x33d403fff] PGTABLE
[0.029341] BRK [0x33d404000, 0x33d404fff] PGTABLE
[0.029345] BRK [0x33d405000, 0x33d405fff] PGTABLE
[0.029479] BRK [0x33d406000, 0x33d406fff] PGTABLE
[0.029504] BRK [0x33d407000, 0x33d407fff] PGTABLE
[0.029528] BRK [0x33d408000, 0x33d408fff] PGTABLE
[0.029577] BRK [0x33d409000, 0x33d409fff] PGTABLE
[0.030140] RAMDISK: [mem 0x34252000-0x36120fff]
[0.030152] ACPI: Early table checksum verification disabled
[0.033915] ACPI: RSDP 0x000F7200 14 (v00 GBT   )
[0.033921] ACPI: RSDT 0xCFED1040 48 (v01 GBTGBTUACPI 
42302E31 GBTU 01010101)
[0.033930] ACPI: FACP 0xCFED1100 74 (v01 GBTGBTUACPI 
42302E31 GBTU 01010101)
[0.033939] ACPI: DSDT 0xCFED11C0 00391C (v01 GBTGBTUACPI 
1000 MSFT 010C)
[0.033946] ACPI: FACS 0xCFED 40
[0.033951] ACPI: MSDM 0xCFED4CC0 55 (v03 GBTGBTUACPI 
42302E31 GBTU 01010101)
[0.033957] ACPI: HPET 0xCFED4D80 38 (v01 GBTGBTUACPI 
42302E31 GBTU 0098)
[0.033964] ACPI: MCFG 0xCFED4E00 3C (v01 GBTGBTUACPI 
42302E31 GBTU 01010101)
[0.033970] ACPI: EUDS 0xCFED4E40 0004D0 (v01 GBT 
  )
[0.033976] ACPI: MATS 0xCFED5310 34 (v01 GBT 
  )
[

Bug#930448: [Pkg-privacy-maintainers] Bug#930448: Bug#930448: onioncircuits: autopkgtest seems to be unreliable

[intrigeri]

Hi Ulrike,

Ulrike Uhlig:
> But it lacks an explanation why the flaky flag was removed.

I think the explanation is the other changelog entry:

>   * Make autopkgtest more resilient when circuits are missing.
> Closes: 909275

FWIW there's a bit more info on the corresponding bug report.

But indeed, given the tests are still flaky despite these
improvements, IMO they should be marked as such until someone has time
to make them more robust :)

Cheers,
-- 
intrigeri

Bug#930271: iw: cannot scan if two cells on 2.4Ghz and 5Gz have same SSID

[Martin Monperrus]

Hi Paride,

Thanks for your answer. Would you recommend to report it on 
https://bugzilla.kernel.org/?

--Martin

Bug#929450: caml-crush, build-dependencies unsatisfiable on armel

[Thomas Calderon]

OK, let's have them removed, when I will push an updated version, I will
make sure to remove armel from the list of targets.

Do I need to do anything else for now?

Thanks,

Thomas

On Thu, Jun 13, 2019 at 8:02 PM Peter Green 
wrote:

> On 13/06/19 10:00, Thomas Calderon wrote:
> > Hi there,
> >
> > It's unfortunate that OCaml has removed the support for ocamlopt for
> armel, it sounds like CamlCrush will not be able to ship for armel.
> > Is it required that I create an updated Debian release excluding armel
> as a target or as you said, ftpmaster can just remove the binaries?
> Removing the binaries is enough in cases like this, they won't be rebuilt
> until/unless their build-dependencies become available again.
>
> I'm not sure if the binary removal will propagate automatically from
> unstable to testing during the freeze or if one needs to ask the release
> team for that.
>
>

Bug#930521: tracker.d.o: during freezes dont complain about packages only in experimental

[Holger Levsen]

package: tracker.debian.org
severity: wishlist
x-debbugs-cc: debian...@lists.debian.org

On Thu, Jun 06, 2019 at 09:19:14PM +0800, Paul Wise wrote:
> On Thu, Jun 6, 2019 at 6:20 PM Holger Levsen wrote:
[tracker.d.o tells me that]
> > - new upstream version only available in experimental (yes, because
> >   buster is frozen)
> 
> I think it is appropriate to file a bug asking that this be disabled
> when the freeze is on. As far as I can tell there is no
> machine-readable indicator that buster is frozen, but there used to be
> one for stretch in the release team's calendar file. So this would
> require the release team to create a machine-readable way for the
> tracker to know if testing is currently frozen.
> 
> https://release.debian.org/release-calendar.ics

filing a bug for this as suggested.

Thanks for maintaining tracker.d.o!


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#929868: midori: Segmenation fault on opening Youtube.com

[Avinash Sonawane]

On Fri, 14 Jun 2019 13:52:03 +0200
Bernhard Übelacker  wrote:

> If you can still reproduce the crash, maybe you could
> install the following debug information packages before,
> and repeat the 'midori -g' step:
> 
> midori-dbgsym libwebkitgtk-1.0-0-dbgsym

Sure!

$ midori -g
Launching command: '/usr/bin/gdb' --batch -ex 'set print thread-events
off' -ex run -ex 'set logging on /run/user/1000/midori/gdb.bt' -ex 'bt'
--return-child-result --args midori [Thread debugging using
libthread_db enabled] Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".

Thread 1 "midori" received signal SIGSEGV, Segmentation fault.
WebCore::RenderLayer::convertFromContainingViewToScrollbar
(this=0x7fff7791d900, scrollbar=0x0, parentPoint=...)
at ../Source/WebCore/rendering/RenderLayer.cpp:2816
2816../Source/WebCore/rendering/RenderLayer.cpp: No such file
or directory. #0
WebCore::RenderLayer::convertFromContainingViewToScrollbar
(this=0x7fff7791d900, scrollbar=0x0, parentPoint=...)
at ../Source/WebCore/rendering/RenderLayer.cpp:2816 #1
0x7403ab29 in WebCore::RenderBox::clientWidth
(this=this@entry=0x7fff7791d900)
at ../Source/WebCore/rendering/RenderBox.cpp:489 #2  0x7419b904
in WebCore::RenderBox::contentWidth (this=0x7fff7791d900)
at ../Source/WebCore/rendering/RenderBox.h:210 #3
WebCore::RenderBox::contentBoxRect (this=0x7fff7791d900)
at ../Source/WebCore/rendering/RenderBox.h:163 #4
WebCore::RenderView::repaintViewRectangle (this=,
repaintRect=..., immediate=)
at ../Source/WebCore/rendering/RenderView.cpp:626 #5
0x74131222 in WebCore::RenderObject::repaintUsingContainer
(this=0x7fff463b1540, repaintContainer=repaintContainer@entry=0x0,
r=..., immediate=immediate@entry=false,
shouldClipToLayer=shouldClipToLayer@entry=true)
at ../Source/WebCore/rendering/RenderObject.cpp:1242 #6
0x740e1610 in WebCore::RenderLayer::updateLayerPositions
(this=this@entry=0x574ebf60,
geometryMap=geometryMap@entry=0x7fffcca0, flags=flags@entry=13)
at ../Source/WebCore/rendering/RenderLayer.cpp:444 #7
0x740e125e in WebCore::RenderLayer::updateLayerPositions
(this=this@entry=0x574f9b30,
geometryMap=geometryMap@entry=0x7fffcca0, flags=flags@entry=13)
at ../Source/WebCore/rendering/RenderLayer.cpp:486 #8
0x740e1680 in
WebCore::RenderLayer::updateLayerPositionsAfterLayout
(this=this@entry=0x574f9b30, rootLayer=0x574f9b30,
flags=flags@entry=13)
at ../Source/WebCore/rendering/RenderLayer.cpp:390 #9
0x73f78492 in WebCore::FrameView::layout
(this=this@entry=0x7fff46bf9c00, allowSubtree=allowSubtree@entry=true)
at ../Source/WebCore/page/FrameView.cpp:1331 #10 0x73f79229 in
WebCore::FrameView::visibleContentsResized (this=0x7fff46bf9c00)
at ../Source/WebCore/page/FrameView.cpp:2194 #11 0x7473c9d4 in
WebCore::ScrollView::updateScrollbars (this=this@entry=0x7fff46bf9c00,
desiredOffset=...) at ../Source/WebCore/platform/ScrollView.cpp:618 #12
0x7473da9c in WebCore::ScrollView::setContentsSize
(this=this@entry=0x7fff46bf9c00, newSize=...)
at ../Source/WebCore/platform/ScrollView.cpp:343 #13 0x73f77d50
in WebCore::FrameView::setContentsSize (this=this@entry=0x7fff46bf9c00,
size=...) at ../Source/WebCore/page/FrameView.cpp:549 #14
0x73f77eb7 in WebCore::FrameView::adjustViewSize
(this=this@entry=0x7fff46bf9c00)
at ../Source/WebCore/page/FrameView.cpp:579 #15 0x73f7892f in
WebCore::FrameView::layout (this=0x7fff46bf9c00,
allowSubtree=allowSubtree@entry=true)
at ../Source/WebCore/page/FrameView.cpp:1321 #16 0x73b25cb3 in
WebCore::Document::implicitClose (this=0x7fff9254ca00)
at ../Source/WebCore/dom/Document.cpp:2462 #17 0x73ebe15b in
WebCore::FrameLoader::checkCompleted (this=this@entry=0x7fff47fc8088)
at ../Source/WebCore/loader/FrameLoader.cpp:845 #18 0x73ebe206
in WebCore::FrameLoader::finishedParsing
(this=this@entry=0x7fff47fc8088)
at ../Source/WebCore/loader/FrameLoader.cpp:769 #19 0x73b27076
in WebCore::Document::finishedParsing (this=0x7fff9254ca00)
at ../Source/WebCore/dom/Document.cpp:4459 #20 0x73d4258d in
WebCore::HTMLConstructionSite::finishedParsing (this=)
at ../Source/WebCore/html/parser/HTMLConstructionSite.cpp:392 #21
0x73d6c0aa in WebCore::HTMLTreeBuilder::finished
(this=)
at ../Source/WebCore/html/parser/HTMLTreeBuilder.cpp:3025 #22
0x73d47981 in WebCore::HTMLDocumentParser::end
(this=this@entry=0x7fff47fc8c00)
at ../Source/WebCore/html/parser/HTMLDocumentParser.cpp:439 #23
0x73d479ce in
WebCore::HTMLDocumentParser::attemptToRunDeferredScriptsAndEnd
(this=this@entry=0x7fff47fc8c00)
at ../Source/WebCore/html/parser/HTMLDocumentParser.cpp:450 #24
0x73d4978e in WebCore::HTMLDocumentParser::prepareToStopParsing
(this=0x7fff47fc8c00)
at ../Source/WebCore/html/parser/HTMLDocumentParser.cpp:165 #25
0x73d47a79 in WebCore::HTMLDocumentParser::finish
(this=0x7fff47fc8c00)
at ../Source/WebCore/html/parser/HTMLDocumentPar

Bug#930367: cloud.debian.org: vagrant images: use systemd-networkd for virtualbox provider

[Emmanuel Kasper]

Le 11/06/2019 à 17:07, Antonio Terceiro a écrit :
> Control: retitle -1 vagrant images: network setup in libvirt images are not 
> consistent with Debian defaults
> 
> On Tue, Jun 11, 2019 at 04:15:12PM +0200, Nicolas Quiniou-Briand wrote:
>> Package: cloud.debian.org
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> I noticed a difference between providers for the same box
>> (debian/stretch64):
>>
>> * with libvirt provider, `systemd-networkd` service is enabled and started
>> after first boot of VM.
>>
>> * with virtualbox provider, `systemd-networkd`
>> service is disabled and stopped after first boot of VM.
>>
>> It will be better to have only one way to manage network for the same image
>> with different providers.
> 
> actually, the correct fix would be to make the libvirt images use the
> same setup as virtualbox (which is the same as a regular Debian install
> created by the Debian installer).
> 

vmdeboostrap is unable to create a networked VM using ifudown, ( the
/etc/network/interfaces handler and Debian default) as configuring the
VM with ifupdown would require a non predictable network interface like
eth0 to work on all VMs config. [1]

Unfortunately, non predictable network interfaces are only set in
vmdebootstrap for systemd-networkd,

The attached (untested) patch should fix the bug in vmdeboostrap.
The patch adds non predictable network interface when using ifupdown,
and lets the Debian default of having predictable when using systemd.

Unfortunately again :) vmdeboostrap itself is more or less EOL, its
maintainer Lars required the package to be removed from the archive.

Then longterm fix would be to switch to fai-diskimage like other cloud
images are doing. I am planning to do this for the Debian 11 release.


[1] Otherwise you would end up with en0p3s1 on one VM or en4p1s6 as NIC
name when booting on different VM.

[2] As systemd-networkd can cope with a globbing like e*, which will
match all network interfaces, persistent named or not, and does not need
to have predictable interfaces disabled.
-- 
You know an upstream is nice when they even accept m68k patches.
  - John Paul Adrian Glaubitz, Debian OpenJDK maintainer
diff --git a/bin/vmdebootstrap b/bin/vmdebootstrap
index d9a697d..29eb81a 100755
--- a/bin/vmdebootstrap
+++ b/bin/vmdebootstrap
@@ -322,7 +322,7 @@ class VmDebootstrap(cliapp.Application):  # pylint: 
disable=too-many-public-meth
 network.setup_wheezy_networking(rootdir)
 else:
 if self.settings['systemd-networkd']:
-network.systemd_support(rootdir)
+network.enable_systemd_networkd(rootdir)
 network.enable_systemd_resolved(rootdir)
 else:
 # /etc/network/interfaces.d/
diff --git a/vmdebootstrap/network.py b/vmdebootstrap/network.py
index 25f3155..1d3cfc6 100644
--- a/vmdebootstrap/network.py
+++ b/vmdebootstrap/network.py
@@ -62,15 +62,7 @@ class Networking(Base):
 def setup_networking(self, rootdir):
 self._write_network_interfaces(
 rootdir, 'source-directory /etc/network/interfaces.d\n')
-
-def systemd_support(self, rootdir):
-"""
-Handle the systemd-networkd setting
-"""
-if self.settings['systemd-networkd']:
-self.enable_systemd_networkd(rootdir)
-else:
-self.mask_udev_predictable_rules(rootdir)
+self.mask_udev_predictable_rules(rootdir)
 
 def mask_udev_predictable_rules(self, rootdir):
 """

Bug#930072: dctrl-tools: join-dctrl segfaults

[Guillem Jover]

Hi!

On Fri, 2019-06-14 at 12:17:27 +0200, Rhonda D'Vine wrote:
> severity 930072 important
> thanks

> On 6/12/19 10:35 PM, Peter Pentchev wrote:
> > On Thu, Jun 06, 2019 at 04:04:39PM +0200, Guillem Jover wrote:
> >> Package: dctrl-tools
> >> Version: 2.24-3
> >> Severity: serious

> >> The join-dctrl command segfaults with the attached files.
> >>
> >>   ,---
> >>   $ join-dctrl Packages-A Packages-B
> >>   Segmentation fault (core dumped)

> > From what I think I see, I believe that this is less wrong behavior
> > and more lack of error detection and proper error messages.
> > The manual page states that some field joining options must be
> > specified - some combination of -j, -1, and -2. A command like:
> 
>  I have to agree with Peter here.  While I don't disagree with that it
> is a bug that needs to get addressed, it doesn't fall under the category
> of release-critical because the manpage states that a join field must be
> specified.

Right, sorry, I think I tried with -1, -2 but the segfaults threw me
away. So, it also states that -1 and -2 can be used instead of -j, and
each of these segfault when used standalone, or just do not work
(depending on the order!) at all when used together:

  ,---
  $ join-dctrl -1Package Packages-A Packages-B
  Segmentation fault (core dumped)
  $ $ join-dctrl -2Package Packages-A Packages-B
  Segmentation fault (core dumped)
  $ join-dctrl -1Package -2Package Packages-A Packages-B
  join-dctrl: the join field of the second file has already been specified.
  $ join-dctrl -2Package -1Package Packages-A Packages-B
  Package: aaa
  Version: 1.0
  Package: aaa
  Version: 1.1
  `---

So, it only works when -2 goes before -1. It all feels at least
extremely user unfriendly, and a bit serious to me TBH. :) But I'm not
a regular user of this command, just thought I needed it for some task,
but that ended up not being the case. :) But I think I'd probably given
up anyway and write something using libdpkg-perl, given the hurdles.

Thanks,
Guillem

Bug#930448: [Pkg-privacy-maintainers] Bug#930448: onioncircuits: autopkgtest seems to be unreliable

[Ulrike Uhlig]

Hi!

On 12.06.19 23:10, Simon McVittie wrote:
> Source: onioncircuits
> Version: 0.5-4
> Severity: important
> User: debian...@lists.debian.org
> Usertags: flaky
> 
> The onioncircuits autopkgtest seems to fail occasionally, then succeed
> when retried. Because the unstable-to-testing migration software now
> blocks on regressions in testing, flaky tests, i.e. tests that flip
> between passing and failing without changes to the list of installed
> packages, can be problematic for the release process. Please either fix
> the test to be more robust, or mark this particular test as "flaky" like
> .

debian/changelog says

onioncircuits (0.5-4) unstable; urgency=medium

  * Make autopkgtest more resilient when circuits are missing.
Closes: 909275
  * Remove flaky flag for autopkgtest for now.

 -- Sascha Steinbiss   Sun, 10 Feb 2019 09:21:55 +0100

But it lacks an explanation why the flaky flag was removed.

Cheers!
u.

Bug#929868: midori: Segmenation fault on opening Youtube.com

[Bernhard Übelacker]

Hello Avinash Sonawane,
I just tried to help triaging this crash.
Unfortunately I could not reproduce this crash
in a minimal stretch VM.

If you can still reproduce the crash, maybe you could
install the following debug information packages before,
and repeat the 'midori -g' step:

midori-dbgsym libwebkitgtk-1.0-0-dbgsym

They are in a separate repository described here:

https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

Kind regards,
Bernhard

Bug#916610: closed by Jakob Haufe (Bug#916610: fixed in spacenavd 0.6-1.1)

[Svjatoslav Agejenko]

Thank you ! :)

On Thu, 2019-06-13 at 20:45 +, Debian Bug Tracking System wrote:
> We believe that the bug you reported is fixed in the latest version
> of
> spacenavd, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 916...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Jakob Haufe  (supplier of updated spacenavd package)

Best regards
-- 
Svjatoslav Agejenko
XMPP/Jabber: svjatos...@xmpp.jp
WWW: http://svjatoslav.eu

Bug#881496: No updates → closing

[Ulrike Uhlig]

No news on this bug since 1 year and unreproducible by Sascha and
intrigeri → I propose to close this bug.

Bug#930520: xfdesktop4: regression : doesn't have the Thunar's custom actions

[Johann]

Package: xfdesktop4
Version: 4.12.4-2
Severity: normal

Dear Maintainer,

Illustration : try to right click on xfdesktop's background : you don't have 
"open terminal"
Try to do it in thunar : you have it.

Try this on stretch's xfdesktop : you have it.

I asked on xfce forum and they replied :
> The Thunarx API, the one that provides these menu items,  was updated in 
> Thunar 1.8.
> xfdesktop relies on the Thunarx API to display those items. Unfortunately, 
> xfdesktop's
> support of the newer Thunarx API doesn't appear until xfdesktop version 
> 4.13.2.

>From : https://forum.xfce.org/viewtopic.php?id=12491

I want to appeal for an update on this, because it's kind of cool to have for 
people trying to "pimp" their actions for beginers purpose.
But it might be too late :/

Cheers.

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_CRAP
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 xfdesktop4 depends on:
ii  exo-utils0.12.4-1
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libdbus-1-3  1.12.14-1
ii  libdbus-glib-1-2 0.110-4
ii  libexo-1-0   0.12.4-1
ii  libgarcon-1-00.6.2-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2
ii  libgtk2.0-0  2.24.32-3
ii  libnotify4   0.7.7-4
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libwnck222.30.7-6
ii  libx11-6 2:1.6.7-1
ii  libxfce4ui-1-0   4.12.1-3
ii  libxfce4util74.12.1-3
ii  libxfconf-0-24.12.1-1
ii  xfdesktop4-data  4.12.4-2

Versions of packages xfdesktop4 recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.14-1
ii  dbus-x11 [dbus-session-bus]   1.12.14-1
ii  librsvg2-common   2.44.10-2.1
ii  tumbler   0.2.3-1
ii  xdg-user-dirs 0.17-2

Versions of packages xfdesktop4 suggests:
pn  menu  

-- no debconf information

Bug#930500: ITP: intel-undervolt -- tool for undervolting Intel CPUs

[Ben Hutchings]

On Fri, 14 Jun 2019 01:33:02 +0200 Stephan Lachnit 
 wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Stephan Lachnit 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> * Package name: intel-undervolt
>   Version : 1.6
>   Upstream Author : kitsunyan 
> * URL : https://github.com/kitsunyan/intel-undervolt
> * License : GPL-3
>   Programming Lang: C
>   Description : tool for undervolting Intel CPUs
> 
>  intel-undervolt is a tool for undervolting CPUs,
>  working with Intel CPUs since Generation Haswell.
>  It can also change power and temperature limits.
>  Note: undervolting can cause stability issues
[...]

Please don't do this.  It will probably cause crashes and bug reports
against other packages, which waste the time of other maintainers.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.




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

Bug#930519: missing versioned dependencies

[Marc Haber]

Package: exim4
Version: 4.92-8
Severity: normal

Hi,

for some possibly historical reason, the dependencies between the exim
packages are not versioned. This might lead to the latest security
updates not being installed if some people just do apt install exim4
instead of the recommended apt upgrade.

I think that our packages should more closly depend on each other to
avoid running an older exim4-daemon with a later exim4-base, forcing
daemon upgrades even if somebody only upgrades exim4.

Greetings
Marc

Bug#842420: electron packaging

[Paolo Greppi]

I just filed a couple of RFPs for electron apps and immediately added this one 
as a blocker:
https://bugs.debian.org/842420

So yes there are some trending messaging apps and code editors built with 
electron !

Packaging it would be a huge task also because it is a mixed-language project.
sloccount reports:
cpp:  59225 (61.39%)
javascript:   29379 (30.46%)
ansic: 3833 (3.97%)
python:3205 (3.32%)
sh: 824 (0.85%)
But electron is definitely part of the js ecosystem (exactly as nodejs) so we 
should be brave and pick it up.

The first step would be to evaluate which of the electron apps we (as js-team) 
want to focus on.
Next find out if a single electron version can be used.
From a first look, it seems problematic:

- atom: "electronVersion": "3.1.10"
- beaker: "electron": "5.0.0"
- franz: "electron": "5.0.2",
- mattermost-desktop: "electron": "^4.0.0"
- riot-web: "electronVersion": "4.2.4",
- signal-desktop: "electron": "4.2.2"
- ssb-patchwork: "electron": "^4.2.4",
- vscode: target "4.2.4"
(for vscode it is not in package.json, I found it here (?): 
https://github.com/microsoft/vscode/blob/master/.yarnrc)

Paolo

Bug#930238: unblock: zfs-linux/0.7.12-2+deb10u1 [t-p-u]

[Aron Xu]

Hi,

I have tested the package in a virtual machine on amd64 for
linux/4.19.37-3 (buster) and a locally built updated linux kernel that
breaks zfs-linux/0.7.12-2. The dkms package builds fine with both of
the versions and zpool create/export/import works fine. Therefore,
please unblock the t-p-u update for buster, thanks.

Regards,
Aron

Bug#930518: ssb-patchwork -- A decentralized messaging and sharing app built on top of the SSB protocol

[Paolo Greppi]

Package: wnpp
Severity: wishlist

* Package name: ssb-patchwork
  Version : 3.13.0
  Upstream Author : Secure Scuttlebutt Consortium
* URL : https://github.com/ssbc/patchwork
* License : AGPL-3.0
  Programming Lang: JavaScript
  Description : A decentralized messaging and sharing app built on top of 
the SSB protocol

Patchwork is a decentralized messaging and sharing app built on top of the
SSB (Secure Scuttlebutt) protocol.
Secure Scuttlebutt is a "gossip protocol" which supports end-to-end encrypted,
private messages.
Each user produces a chronologically ordered list of "messages" which is
initially only stored on the device they install the client on, so that the data
and hence the identity of each user is tied to a single device.
Users sync their entire archive of messages between "friends" only when they're
on the same Wi-Fi network or connected to the same "pub" server.
The protocol is server-less and "pubs" only help with syncing.
All data is decentralized and after syncing can be also consumed offline.

==

SSB is a social network for sailing paranoids as such it could find a solid 
user base within Debian and derivatives.

Patchwork is the most polished among the SSB clients, and targeted for 
non-geeks.
For more info of SSB see: https://www.scuttlebutt.nz/

Note: it is an Electron app.

Upstream names this app "patchwork" but the name is contended, see:
https://bugs.debian.org/703226#61
Since there hasn't been progress on that other RFP for over 1 year, I would 
suggest trying to negotiate the name again ;-)

Paolo
   

Bug#930072: dctrl-tools: join-dctrl segfaults

[Rhonda D'Vine]

severity 930072 important
thanks

   Hi,

On 6/12/19 10:35 PM, Peter Pentchev wrote:
> On Thu, Jun 06, 2019 at 04:04:39PM +0200, Guillem Jover wrote:
>> Package: dctrl-tools
>> Version: 2.24-3
>> Severity: serious
>>
>> Hi!
>>
>> The join-dctrl command segfaults with the attached files.
>>
>>   ,---
>>   $ join-dctrl Packages-A Packages-B
>>   Segmentation fault (core dumped)
> 
> Hi,
> 
> From what I think I see, I believe that this is less wrong behavior
> and more lack of error detection and proper error messages.
> The manual page states that some field joining options must be
> specified - some combination of -j, -1, and -2. A command like:

 I have to agree with Peter here.  While I don't disagree with that it
is a bug that needs to get addressed, it doesn't fall under the category
of release-critical because the manpage states that a join field must be
specified.

 So long,
Rhonda

Bug#827314: this project is deprecated

[Paolo Greppi]

See: https://medium.com/@wolovim/mist-migration-patterns-6bcf066ac383
Quote: "Mist Browser and Ethereum Wallet are no longer supported"

See: https://medium.com/@avsa/sunsetting-mist-da21c8e943d2
Quote: "Mist, the browser has outlived it’s usefulness: the ecosystem has matured so 
much that now the user has tons of great options of wallets and browsers on both mobile 
and desktop"

Bug#930428: debootstrap should ensure matching _apt uid

[Michael Schaller]

Patch proposal:
https://salsa.debian.org/installer-team/debootstrap/merge_requests/32

Patch note: This patch introduces the 'setup_users_groups' function
which is inspired by the existing 'setup_dselect_method' function.

Bug#930515: RFP: beaker -- Peer-to-peer web browser

[Paolo Greppi]

Package: wnpp
Severity: wishlist

* Package name: beaker
  Version : 0.8.8
  Upstream Author : Blue Link Labs
* URL : https://github.com/beakerbrowser/beaker
* License : MIT
  Programming Lang: JavaScript
  Description : Peer-to-peer web browser

Beaker is an experimental browser for exploring and building the peer-to-peer
web based on the Dat protocol, while remaining compatible with the rest of the
world wide web.

Dat (dat:// ) is a data distribution protocol for publishing versioned data
sets and generic file archives. As such it can be used to distribute in a
peer-to-peer (hostless) fashion websites and JavaScript applications.
Dat is similar to IPFS (InterPlanetary File System) but more targeted to data
science and hostless apps.

Main functionalities of the Beaker browser:
- browsing over http and https
- browsing and seeding over dat
- inspect all the files that make up a dat file archive ("view source")

==

The Beaker browser seems like the easiest entry point in the Dat ecosystem,
See:
- htps://dat.foundation/
- https://datprotocol.github.io/how-dat-works/
Note: it is an Electron app.

Bug#930514: libgles2-mesa-dev: glesv2.pc missing

[Guido Günther]

Package: libgles2-mesa-dev
Version: 19.1.0-1
Severity: normal

Hi,
The package config file went missing in 19.1.0-1:

   https://packages.debian.org/experimental/arm64/libgles2-mesa-dev/filelist

I noticed when rebuilding wlroots against that version.

Cheers and thanks for keeping up so quickly with mesa releases,
 -- Guido

Bug#930513: libgles2-mesa-dev: libglesv2.pc went missing

[Guido Günther]

Package: libgles2-mesa-dev
Version: 18.3.4-2
Severity: normal



-- Package-specific info:
glxinfo:

name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_context_flush_control, GLX_ARB_create_context, 
GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_libglvnd, GLX_EXT_no_config_context, 
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGIS_multisample, 
GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
GLX_SGI_make_current_read
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_context_flush_control, GLX_ARB_create_context, 
GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, 
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, 
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_video_sync
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) Haswell Mobile  (0xa16)
Version: 18.3.4
Accelerated: yes
Video memory: 1536MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile 
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.4
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
GL_3DFX_texture_compression_FXT1, GL_AMD_conservative_depth, 
GL_AMD_draw_buffers_blend, GL_AMD_multi_draw_indirect, 
GL_AMD_query_buffer_object, GL_AMD_seamless_cubemap_per_texture, 
GL_AMD_shader_trinary_minmax, GL_AMD_vertex_shader_layer, 
GL_AMD_vertex_shader_viewport_index, GL_ANGLE_texture_compression_dxt3, 
GL_ANGLE_texture_compression_dxt5, GL_APPLE_object_purgeable, 
GL_ARB_ES2_compatibility, GL_ARB_ES3_1_compatibility, 
GL_ARB_ES3_compatibility, GL_ARB_arrays_of_arrays, GL_ARB_base_instance, 
GL_ARB_blend_func_extended, GL_ARB_buffer_storage, 
GL_ARB_clear_buffer_object, GL_ARB_clear_texture, GL_ARB_clip_control, 
GL_ARB_compressed_texture_pixel_storage, GL_ARB_compute_shader, 
GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, 
GL_ARB_copy_buffer, GL_ARB_copy_image, GL_ARB_cull_distance, 
GL_ARB_debug_output, GL_ARB_depth_buffer_float, GL_ARB_depth_clamp, 
GL_ARB_derivative_control, GL_ARB_direct_state_access, 
GL_ARB_draw_buffers, GL_ARB_draw_buffers_blend, 
GL_ARB_draw_elements_base_vertex, GL_ARB_draw_indirect, 
GL_ARB_draw_instanced, GL_ARB_enhanced_layouts, 
GL_ARB_explicit_attrib_location, GL_ARB_explicit_uniform_location, 
GL_ARB_fragment_coord_conventions, GL_ARB_fragment_layer_viewport, 
GL_ARB_fragment_shader, GL_ARB_fragment_shader_interlock, 
GL_ARB_framebuffer_no_attachments, GL_ARB_framebuffer_object, 
GL_ARB_framebuffer_sRGB, GL_ARB_get_program_binary, 
GL_ARB_get_texture_sub_image, GL_ARB_gpu_shader5, GL_ARB_gpu_shader_fp64,

Bug#929908: unblock: tomcat9/9.0.16-4

[Emmanuel Bourg]

Control: tags -1 - moreinfo

Le 13/06/2019 à 08:53, Paul Gevers a écrit :

> Please upload the package soon and remove the moreinfo tag when it can
> be unblocked.

Hi Paul,

Thank you, the package has been uploaded.

Emmanuel Bourg

Bug#902493: SSL Issue

[Jean-Louis Dupond]

We had the test2 version running for some days on a machine.
But we noticed a quite important issue with it.

The configuration has a lot of SSL certificates.
Now when doing a lot of sequential requests, it happens that Apache was 
returning the wrong (default) certificate instead of the certificate of 
the supplied servername.

This happend on like 1/5 requests.

Wanted to test Apache 2.4.38 from Buster to see if it worked fine there, 
but was not able to build it on Stretch.


So better not push this patched version to Stretch :)

Bug#930512: libvtk7-jni: library dependencies not found

[Brett Ryland]

Package: libvtk7-jni
Version: 7.1.1+dfsg1-12+b1
Severity: important

Dear Maintainer,

The dependencies of the libraries aren't found (at least on my system), e.g. 
running:
> find /usr/lib -name "lib*.so" -exec sh -c 'ldd {} | grep not\ found' \; -print
gives many results like:
> libjawt.so => not found
> libvtkCommonExecutionModelJava.so => not found
> libvtkCommonDataModelJava.so => not found
> libvtkCommonCoreJava.so => not found
> /usr/lib/x86_64-linux-gnu/jni/libvtkRenderingCoreJava.so
Adding the paths /usr/lib/x86_64-linux-gnu/jni and 
/usr/lib/x86_64-linux-gnu/gcj-6-17
to a conf file in /etc/ld.so.conf.d/ fixes this issue.

I stumbled across this while debugging an unrelated dependency issue in
pytorch.

Best regards,
Brett.

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (900, 'unstable'), (300, 'experimental'), (200, 'stable')
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_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libvtk7-jni depends on:
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-7
ii  libstdc++6  8.3.0-7
ii  libvtk7.1   7.1.1+dfsg1-12+b1

libvtk7-jni recommends no packages.

libvtk7-jni suggests no packages.

-- no debconf information

Bug#923996: diffoscope: --exclude doesn't work too well with sub-archives

[Chris Lamb]

Hi,

> diffoscope: --exclude doesn't work too well with sub-archives

Just for visibility, there is conversation happening "upstream" here:

  https://salsa.debian.org/reproducible-builds/diffoscope/issues/53#note_91292


Best wishes,

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

Bug#930508: installation-reports: Corrupt display after grub as soon as kernel loads - buster netinst iso

[Steve McIntyre]

On Fri, Jun 14, 2019 at 06:31:04AM +0200, Fab Stz wrote:
>Package: installation-reports
>Severity: normal
>
>Dear Maintainer,
>
>I'm booting the latest weekly netinst iso to install Buster.
>I'm facing corrupt display as soon as grub starts loading the kernel.
>Grub's display is fine. [1]
>The only workaround I found working is setting these parameters to the
>kernel vga=794 or vga=791 for example.
>
>My System is ASUS Prime B450M-A with AMD Athlon 200GE CPU (with
>integrated vega graphics), and no additional video card.
>
>This is with the latest weekly netinst iso for buster (10/Jun/2019)
>It also happened with the one of 27/May. I don't know if this is a
>regression from previous versions (buster or stretch) since I didn't test them
>with that hardware

Hi!

Are you booting vie UEFI or BIOS on this machine? I'm guessing UEFI -
the splash menu should say "UEFI" on it if so...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

Bug#926042: [Pkg-privacy-maintainers] Bug#926042: drawbacks of not having tbl in testing..

[Ulrike Uhlig]

Hi!

On 27.05.19 15:02, Holger Levsen wrote:
> On Mon, May 27, 2019 at 02:18:54PM +0200, Ulrike Uhlig wrote:
>> It would be useful to know with which statements or assumptions you do
>> not agree with and why - so that the discussion may become more
>> productive & helpful.
>  
> "cannot be maintained in stable". I think this can at least be tried.
> And IMO its better to have tbl in stable until the 5th or 7th
> pointrelease and then have it removed (if it has to be done), than not
> having tbl at all, never.
> 
>>> anyway, i just want to point out that 'maintaining tbl in stretch via
>>> stretch-backports' doesnt work because tbl is not in buster and thus, if
>>> this bug gets retitled to 'tbl should not be part of bullseye',
>>> maintaining tbl in buster via bullseye-backports will also not work.
>> Do you have any suggestion on how to handle this?
> 
> maintain tbl in stable.

I have re-read intrigeri's arguments [1] and I entirely agree with his
assessments:

1. updates are required because of changes of GPG keys, TLS certs etc.
2. apparmor profiles regularly need updates because of upstream changes
   that we are generally not made aware of in time by upstream and only
   discover after the fact. There is a huge lack of communication here.
3. lack of time & energy to backport fixes on a regular basis.

i.e. I don't see us maintaining tbl in stable. That is certainly a sad
state. But reality is that most of us have too many other things on
their plate and do not see this as a priority. I volunteer to update the
Debian wiki page to document how to install torbrowser-launcher once
Buster is out.

That said, if *you* want to maintain tbl in stable I have no objections.

Cheers!
Ulrike

[1] Message-Id: <87zhpcb569.fsf@manticora>, email from march 30, 2019

Bug#930511: rdesktop exit with error "Failed to negotiate protocol, retrying with plain RDP"

[Antonio]

Package: rdesktop
Version: 1.8.4-1
Severity: normal

Dear Maintainer,
The current version of rdesktop 1.8.6-1 does not start, it immediately comes
out generating the error "Failed to negotiate protocol, retrying with
plain RDP".

Note that the previous version 1.8.4-1, in testing repository, works correctly.

Thanks,
Antonio


-- DETAILS --

$ rdesktop indirizzo-server
Autoselected keyboard map it
Failed to negotiate protocol, retrying with plain RDP.
NOT IMPLEMENTED: PDU 8
ERROR: rdp.c:128: rdp_recv(), unexpected stream overrun
 03 00 01 82 02 f0 80 68 00 01 03 eb 70 81 73 08 ...hp.s.
0010 00 02 03 1d c3 6f 06 c1 6a 5d b0 9b 08 88 4d 1b .o..j]M.
...



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

Kernel: Linux 5.1.9-custom (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=it_IT, LC_CTYPE=it_IT (charmap=ISO-8859-1) (ignored:
LC_ALL set to it_IT), LANGUAGE=it (charmap=ISO-8859-1) (ignored:
LC_ALL set to it_IT)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rdesktop depends on:
ii  libasound21.1.8-1
ii  libc6 2.28-10
ii  libgssglue1   0.4-2+b2
ii  libpcsclite1  1.8.25-1
ii  libssl1.1 1.1.1c-1
ii  libx11-6  2:1.6.7-1
ii  libxrandr22:1.5.1-1

rdesktop recommends no packages.

Bug#928185: unblock: openjdk-11/11.0.3+7-4

[Matthias Klose]

On 12.06.19 00:37, Moritz Mühlenhoff wrote:
> On Mon, Jun 10, 2019 at 09:46:41PM -0700, tony mancill wrote:
>> I am not a member of the OpenJDK team and contributed far less to the
>> JDK 8 -> 11 transition than Emmanuel has.  If he and Matthias are in
>> agreement and the plan is palatable to the Release and Security Teams,
>> that's ideal.
> 
> I don't have any preference either, just adding my 2 cents here; with
> our buster release set to 6th of July and the next Oracle CPU set for
> July 16, we'll ship a non-GA release of Java for maybe two, at most three
> weeks (as buster-security will rebase to the next openjdk-11 following
> the CPU). I'm also fairly sure we've shipped non-GA releases for openjdk-8
> before?

yes, until reccently we didn't have any source releases, so I prepared packages
from the last tag leading to the GA release, and then we applied the security
patches on top of that.

Matthias

Bug#930510: radare2: CVE-2019-12802

[Salvatore Bonaccorso]

Source: radare2
Version: 3.2.1+dfsg-5
Severity: important
Tags: security upstream
Forwarded: https://github.com/radare/radare2/issues/14296

Hi,

The following vulnerability was published for radare2.

CVE-2019-12802[0]:
| In radare2 through 3.5.1, the rcc_context function of
| libr/egg/egg_lang.c mishandles changing context. This allows remote
| attackers to cause a denial of service (application crash) or possibly
| have unspecified other impact (invalid memory access in
| r_egg_lang_parsechar; invalid free in rcc_pusharg).


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-12802
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12802
[1] https://github.com/radare/radare2/issues/14296

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#910143: (no subject)

[Emmanuel Kasper]

I rebuilt and uploaded the 12 boxes concerned by this bug, should be OK now.

Bug#930482: Workaround

[Jö Fahlke]

For anyone looking for a workaround, apparently setting OPENBLAS_CORETYPE in
the environment helps, see https://gitlab.dune-project.org/docker/ci/issues/9

A list of possible values can be found here:
https://github.com/xianyi/OpenBLAS/blob/develop/driver/others/dynamic.c#L712

Regards,
Jö.

-- 
Jorrit (Jö) Fahlke, Institute for Computational und Applied Mathematics,
University of Münster, Orleans-Ring 10, D-48149 Münster
Tel: +49 251 83 35146 Fax: +49 251 83 32729

Das Erststudium soll bis zum berufsqualifizierenden Abschluss
gebührenfrei bleiben, also bis zur Erlangung der Taxi-Lizenz.
-- Akrützel, Ausgabe vom 16.5.2002 (www.akruetzel.de)


signature.asc
Description: PGP signature

Bug#803119: [Debian-rtc-admin] prosody config, status update

[W. Martin Borgert]

On 2019-06-14 08:49, gustavo panizzo wrote:
> we'll need more from DSA to administer the service, for example sudo to
> prosody user to further troubleshoot issues when they arise, list users
> (how to enable http_uploads without knowing that?)

What is the position of DSA regarding this service anyway?
I wasn't around when the service came into life, so I wonder,
whether we should directly ask DSA team what they expect from
us = RTC team. Expectations might have shifted over time.

About listing users: Maybe there is an adhoc command for that,
so we can even do it over XMPP? Currently, not many adhoc
commands are activated, however.

Bug#930509: tuned: can't read /etc/sysconfig/irqbalance: No such file or directory

[Renaud Manus]

Package: tuned
Version: 2.10.0-1
Severity: important

Dear Maintainer,


   * What led up to the situation?
# tuned-adm apply cpu-partitioning

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Check the log file : /var/log/tuned/tuned.log

   * What was the outcome of this action?
2019-06-04 11:27:01,431 INFO tuned.plugins.plugin_systemd: setting 
'CPUAffinity' to '0 1' in the '/etc/systemd/system.conf'
2019-06-04 11:27:01,432 INFO tuned.plugins.plugin_script: calling script 
'/usr/lib/tuned/cpu-partitioning/script.sh' with arguments '['start']'
2019-06-04 11:27:01,480 ERRORtuned.plugins.plugin_script: script 
'/usr/lib/tuned/cpu-partitioning/script.sh' error output: 'sed: can't read 
/etc/sysconfig/irqbalance: No such file or directory
/usr/lib/tuned/cpu-partitioning/script.sh: 43: 
/usr/lib/tuned/cpu-partitioning/script.sh: cannot create 
/etc/sysconfig/irqbalance: Directory nonexistent

/etc/sysconfig/irqbalance is RH/Centos specific, on Debian it should be 
/etc/default/irqbalance

   * What outcome did you expect instead?
No error after applying the profile



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

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

Versions of packages tuned depends on:
ii  dbus   1.12.12-1
ii  ethtool1:4.19-1
ii  gawk   1:4.2.1+dfsg-1
ii  hdparm 9.58+ds-1
ii  policykit-10.105-25
ii  procps 2:3.3.15-2
ii  python33.7.3-1
ii  python3-configobj  5.0.6-3
ii  python3-dbus   1.2.8-3
ii  python3-decorator  4.3.0-1.1
ii  python3-gi 3.30.4-1
ii  python3-pyudev 0.21.0-1
ii  virt-what  1.19-1

Versions of packages tuned recommends:
ii  linux-cpupower  4.19.37-3

tuned suggests no packages.

-- Configuration Files:
/etc/tuned/active_profile changed:
cpu-partitioning

/etc/tuned/bootcmdline changed:
TUNED_BOOT_CMDLINE="skew_tick=1 nohz=on nohz_full=2-15 rcu_nocbs=2-15 
tuned.non_isolcpus=0003 intel_pstate=disable nosoftlockup"
TUNED_BOOT_INITRD_ADD="/tuned-initrd.img"

/etc/tuned/cpu-partitioning-variables.conf changed:
isolated_cores=2-15

/etc/tuned/profile_mode changed:
manual


-- no debconf information

Bug#916221: node-prismjs: Unable to install due to missing node-clipboard

[Pirate Praveen]

On Tue, 11 Dec 2018 17:21:56 +0100 Andreas Tille  wrote:
> $ sudo apt-get install node-prismjs
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> 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:
>  node-prismjs : Depends: node-clipboard (>= 1.7.1) but it is not installable
> 
> 
> There is no package node-clipboard available in Debian.
> 

Both packages were in NEW but only node-prismjs cleared

rmadison node-clipboard
node-clipboard | 1.7.1-1   | new| source, all



signature.asc
Description: OpenPGP digital signature

Bug#803119: [Debian-rtc-admin] prosody config, status update

[Victor Seva]

On Thu, 13 Jun 2019 at 14:50, Jonas Smedegaard  wrote:

> I am not familiar with Puppet so cannot help review that.
>
> It seems to me noone else in the team is familiar with it either -
> including Victor who wrote previously that he has "no idea how to test
> this and see what the result would be."
>

Just to be clear, I had some experience with puppet in an environment that
I was able to log into the machine and test the changes. My problem here is
how to reproduce the machine in a VM.

Cheers,
Victor

Bug#803119: [Debian-rtc-admin] prosody config, status update

[Victor Seva]

On Thu, 13 Jun 2019 at 13:09, gustavo panizzo  wrote:

> I've been working on how to maintain and update the prosody config
>
> this was my initial attempt using a Makefile
> https://salsa.debian.org/rtc-team/prosody-configuration
>
> this is my current attempt using puppet and the module Victor suggested
>
> https://salsa.debian.org/gfa/dsa-puppet/merge_requests/1/diffs
>
> this is depending this merge
> https://github.com/voxpupuli/puppet-posix_acl/pull/62 if the merge takes
> to long I'll fork the module in salsa
>
> My goal for the first iteration is to have the patch merged by DSA so we
> can have a way to deploy changes in the service easily and
> auditable, afterwards (help welcomed!) I'll add anti-spam measures and
> http_uploads :)
>
> reviews of the MR are very much welcomed
>

This is great!

Some comments:

* the need of posix_acl maybe is not necessary. This was needed to do
manual changes to the configs. If We can manage the config via puppet I
think is not really needed. Maybe without posix_acl it would be easier to
get approved by DSA. Being able to read /var/log/prosody/ is good enough to
check and debug the service.
* can you please explain and document how to get the "generated" configs.
In other words, how to test this in a VM with puppet masterless.

Great work Gustavo. Thank you for this!
Cheers,
Victor

Bug#924552: jquery-caret.js: Please provide node-jquery.caret and install package.json

[Pirate Praveen]

On Fri, 15 Mar 2019 11:06:39 +1100 Ben Finney 
wrote:> Sure, I'd love for you to fork the repository
> https://salsa.debian.org/debian/pkg-jquery-caret.js>
> and propose a merge request that I can review.
> 
> Alternatively, I'd be happy with files attached to this bug report.

Please review
https://salsa.debian.org/debian/pkg-jquery-caret.js/merge_requests/1



signature.asc
Description: OpenPGP digital signature