Bug#929780: linux-image-4.19.0-5-amd64: xps13 crashes on suspend/resume with latest kernel

2019-05-30 Thread Philip Walls
Package: src:linux
Version: 4.19.37-3
Severity: critical
Justification: breaks the whole system

The failure is reproducible 100% of the time. All that is required is to close
the lid on my laptop, wait a moment, and then open the lid.

When the lid is opened, the kernel immediately boots back to the system BIOS.
This almost behaves like a CPU fault. There is no kernel panic visible.

This is a regression from 4.19.0-4. Booting into the 4.19.0-4 kernel fixes
suspend/resume.



-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Dell Inc.
product_name: XPS 13 9350
product_version: 
chassis_vendor: Dell Inc.
chassis_version: 
bios_vendor: Dell Inc.
bios_version: 1.4.12
board_vendor: Dell Inc.
board_name: 09JHRY
board_version: A00

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Skylake Host Bridge/DRAM 
Registers [8086:1904] (rev 09)
Subsystem: Dell Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host 
Bridge/DRAM Registers [1028:0704]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation Iris Graphics 540 
[8086:1926] (rev 0a) (prog-if 00 [VGA controller])
Subsystem: Dell Iris Graphics 540 [1028:0704]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Skylake 
Processor Thermal Subsystem [8086:1903] (rev 09)
Subsystem: Dell Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor 
Thermal Subsystem [1028:0704]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device

00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI 
Controller [8086:9d2f] (rev 21) (prog-if 30 [XHCI])
Subsystem: Dell Sunrise Point-LP USB 3.0 xHCI Controller [1028:0704]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP 
Thermal subsystem [8086:9d31] (rev 21)
Subsystem: Dell Sunrise Point-LP Thermal subsystem [1028:0704]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: intel_pch_thermal
Kernel modules: intel_pch_thermal

00:15.0 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP 
Serial IO I2C Controller #0 [8086:9d60] (rev 21)
Subsystem: Dell Sunrise Point-LP Serial IO I2C Controller [1028:0704]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci

00:15.1 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP 
Serial IO I2C Controller #1 [8086:9d61] (rev 21)
Subsystem: Dell Sunrise Point-LP Serial IO I2C Controller [1028:0704]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci

00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-LP 
CSME HECI #1 [8086:9d3a] (rev 21)
Subsystem: Dell Sunrise Point-LP CSME HECI [1028:0704]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:17.0 RAID bus controller [0104]: Intel Corporation 82801 Mobile SATA 
Controller [RAID mode] [8086:282a] (rev 21)
Subsystem: Dell 82801 Mobile SATA Controller [RAID mode] [1028:0704]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ahci
Kernel modules: ahci

00:1c.0 

Bug#652727: change bug title and owner

2019-05-30 Thread laokz
Control: retitle -1 ITA: simhash -- generate similarity hashes to find
nearly duplicate files
Control: owner -1 !

Hello,

I'v already get assent from current maintainer, and I'll try to take
over this package.

Regards,
laokz



Bug#929776: unblock: rrdtool/1.7.1-2

2019-05-30 Thread Niels Thykier
Control: tags -1 moreinfo confirmed

Jean-Michel Vourgère:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: unblock
> Severity: normal
> 
> Please allow me to add an upstream patch in order to fix segfaults in rrdtool 
> daemon, that occurs when xport'ing an non-existent RRD file.
> 
> unblock rrdtool/1.7.1-2
> 

Please go ahead with the upload and remove the moreinfo tag when it is
ready to be unblocked.

Thanks,
~Niels



Bug#929709: libgdbm6: file exists in libgdbm-dev as well as gdbm

2019-05-30 Thread Luke Kenneth Casson Leighton
On Fri, May 31, 2019 at 5:09 AM Dmitry Bogatov  wrote:

> > Unpacking libgdbm-dev:amd64 (1.18.1-4) ...
> > dpkg: error processing archive 
> > /var/cache/apt/archives/libgdbm-dev_1.18.1-4_amd64.deb (--unpack):
> >  trying to overwrite '/usr/share/info/gdbm.info.gz', which is also in 
> > package libgdbm3:amd64 1.8.3-11
> > Errors were encountered while processing:
> >  /var/cache/apt/archives/libgdbm-dev_1.18.1-4_amd64.deb
>
> Issue, yes. But you are upgrading from rather old version of libgdbm3.
> According to https://tracker.debian.org/gdbm, it predates even
> old-stable.

 ah ok, not a problem then - i thought the existing version was more
recent than that, missed that it was 1.8 rather than 1.18.

l.



Bug#929779: connman-wait-online.service failed

2019-05-30 Thread John Eikenberry
Package: connman
Version: 1.36-2
Severity: normal

When installing connman, it hangs for a couple minutes then fails to start
connman-wait-online.service with this error. My network connection at the time
was to wifi with wpasupplicant (started manually with ifup).

Job for connman-wait-online.service failed because the control process exited 
with error code.
See "systemctl status connman-wait-online.service" and "journalctl -xe" for 
details.

The output of 'systemctl status connman-wait-online.service' is...

systemctl status connman-wait-online.service -l
● connman-wait-online.service - Wait for network to be configured by ConnMan
   Loaded: loaded (/lib/systemd/system/connman-wait-online.service; enabled; 
vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2019-05-30 20:41:28 PDT; 30min 
ago
 Main PID: 5457 (code=exited, status=110)

May 30 20:39:28 ivanova systemd[1]: Starting Wait for network to be configured 
by ConnMan...
May 30 20:41:28 ivanova systemd[1]: connman-wait-online.service: Main process 
exited, code=exited, status=110/n/a
May 30 20:41:28 ivanova systemd[1]: connman-wait-online.service: Failed with 
result 'exit-code'.
May 30 20:41:28 ivanova systemd[1]: Failed to start Wait for network to be 
configured by ConnMan.


-- 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/4 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)

Versions of packages connman depends on:
ii  dbus  1.12.12-1
ii  iptables  1.8.2-4
ii  libc6 2.28-10
ii  libdbus-1-3   1.12.12-1
ii  libglib2.0-0  2.58.3-1
ii  libgnutls30   3.6.6-2
ii  libreadline7  7.0-5
ii  libxtables12  1.8.2-4
ii  lsb-base  10.2019051400

Versions of packages connman recommends:
pn  bluez  
pn  ofono  
ii  wpasupplicant  2:2.7+git20190128+0c1e29f-5

Versions of packages connman suggests:
pn  connman-vpn  

-- no debconf information

-- 

John Eikenberry
[ j...@zhar.net - http://zhar.net ]

"Perfection is attained, not when no more can be added, but when no more
 can be removed." -- Antoine de Saint-Exupery



Bug#929778: dh-runit: install presubj file for reportbug(1)

2019-05-30 Thread Dmitry Bogatov

Package: dh-runit
Version: 2.8.8
Severity: wishlist

Dear Maintainer,

I propose to add new option "presubj" to dh_runit. With this option,
dh_runit should install file into /usr/share/bug, so when user is about
to report a bug in a package with reportbug(1), he will be shown notice,
that if bug is in runit integration, he should add runit mailing list
into CC, to relieve burden from maintainer of service, who unlikely
to use runit init system himself.

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=eo.utf8, LC_CTYPE=eo.utf8 (charmap=UTF-8), LANGUAGE=eo.utf8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages dh-runit depends on:
ii  debhelper  12.1.1

dh-runit recommends no packages.

dh-runit suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/dh_runit (from dh-runit package)


pgpvhoPLdaIvz.pgp
Description: PGP signature


Bug#929709: libgdbm6: file exists in libgdbm-dev as well as gdbm

2019-05-30 Thread Dmitry Bogatov


control: severity -1 minor

[2019-05-29 13:31] lkcl 
> Package: libgdbm6
> Version: 1.18.1-4
> Severity: serious
> Justification: 2
>
> Unpacking libgdbm-dev:amd64 (1.18.1-4) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/libgdbm-dev_1.18.1-4_amd64.deb (--unpack):
>  trying to overwrite '/usr/share/info/gdbm.info.gz', which is also in package 
> libgdbm3:amd64 1.8.3-11
> Errors were encountered while processing:
>  /var/cache/apt/archives/libgdbm-dev_1.18.1-4_amd64.deb

Issue, yes. But you are upgrading from rather old version of libgdbm3.
According to https://tracker.debian.org/gdbm, it predates even
old-stable.

Since Debian does not support skip upgrades, this issue is not
release-critical. Downgrading severity.

I just checked in virtual machine, upgrade stable (1.8.3-14) -> testing
(1.18.1-4) seems fine. Please, consider upgrading gradually.

I doubt that release team would approve unblock for issue of upsupported
upgrade, sorry.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --



Bug#929709: libgdbm6: file exists in libgdbm-dev as well as gdbm

2019-05-30 Thread Dmitry Bogatov


control: severity -1 minor

[2019-05-29 13:31] lkcl 
> Package: libgdbm6
> Version: 1.18.1-4
> Severity: serious
> Justification: 2
>
> Unpacking libgdbm-dev:amd64 (1.18.1-4) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/libgdbm-dev_1.18.1-4_amd64.deb (--unpack):
>  trying to overwrite '/usr/share/info/gdbm.info.gz', which is also in package 
> libgdbm3:amd64 1.8.3-11
> Errors were encountered while processing:
>  /var/cache/apt/archives/libgdbm-dev_1.18.1-4_amd64.deb

Issue, yes. But you are upgrading from rather old version of libgdbm3.
According to https://tracker.debian.org/gdbm, it predates even
old-stable.

Since Debian does not support skip upgrades, this issue is not
release-critical. Downgrading severity.

I just checked in virtual machine, upgrade stable (1.8.3-14) -> testing
(1.18.1-4) seems fine. Please, consider upgrading gradually.

I doubt that release team would approve unblock for issue of upsupported
upgrade, sorry.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --



Bug#929554: O: wmcalclock -- dock.app which simply tells time and date

2019-05-30 Thread Torrance, Douglas
Control: retitle -1 ITA: wmcalclock -- dock.app which simply tells time and date
Control: owner -1 !

On Sun, 26 May 2019 01:36:32 +0200 Pierre-Elliott =?utf-8?B?QsOpY3Vl?= 
mailto:p...@debian.org>> wrote:
> Package: wnpp
>
> The current maintainer of wmcalclock, Kevin Coyner 
> mailto:kcoy...@debian.org>>,
> is apparently not active anymore.  Therefore, I orphan this package now.
>
> Maintaining a package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.
>
> If you want to be the new maintainer, please see
> https://www.debian.org/devel/wnpp/#howto-o for detailed
> instructions how to adopt a package properly.

I intend to adopt this package under the umbrella of the Debian Window Maker 
Team.

Doug



Bug#929764: usbmuxd segfaults on startup

2019-05-30 Thread Bernhard Übelacker
Control: tags -1 + moreinfo


Hallo James Henried,
was just looking through some random bug reports.

Maybe you could install the package systemd-coredump.
That way in the journal would appear a backtrace that
could give some hints where the segmentation fault happens.
Visible in the output of:

journalctl --no-pager

Additional you could install the package gdb and start
usbmuxd with the following command:

script -a ~/gdb-usbmuxd_$(date +%Y-%m-%d_%H-%M-%S).log -c "gdb -q -ex 'set 
width 0' -ex 'set pagination off' -ex 'run' -ex 'info reg' -ex 'display/i \$pc' 
-ex 'bt' -ex 'info share' -ex 'bt full' -ex detach -ex quit --args usbmuxd"

That should generate a file with a better backtrace of
the crashing process that you may forward to this bug report.

Even better would be if before running this you install
some debug symbol packages like described in following link:

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

In your case the package usbmuxd-dbgsym would be the first,
maybe others get requested when a first backtrace is received.

Kind regards,
Bernhard



Bug#917314: Emacs 26 nXML bugs fixed with attached patch

2019-05-30 Thread Vincent Lefevre
Control: tags 917314 patch
Control: tags 917398 patch

I'm using the attached patch formed by various patches from
the emacs-26 branch and others posted upstream[*]. It fixes
both bugs 917314 and 917398 and some other issues.

[*] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18871
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32823
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33887

It includes:
  ca14dd1d4628094dd33d5d94694dcf5f29e843b8 (emacs-26 branch)
  7dab3ee7ab54b3c2e7bc24170376054786c01d6f (emacs-26 branch)
  3a1a36b0b42772f35c70fb7e996ba8fed787e1c2 [1]
  a866e4f4b556fb4a346fa68c62296f10966690a1 [2]
  e4cde42657f8f91f795e6b7041dc50b896dc468d (emacs-26 branch)
  b8c659dc0c6ef41adc19db3c1884f73c1a10c8d8 [3]
  2025fa25f76fd8a2df46fca8807ca386372757d5 [4]
  d1520ab5b94d0f130955800ea11222a3702a5519 [5]
  0c3e6a97f92dec31e7e186dae933c86700034089 [6]
  290bbf4341c58339dafe46ed87b1979115306556 [7]

[1] 0001-Backport-sgml-syntax-propertize-rules-speedup-Bug-33.patch
at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33887#58

[2] 0001-Fix-sgml-syntax-handling-of-quotes-in-comments.patch
at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33887#73

[3] 0001-Keep-nxml-prolog-end-up-to-date-Bug-18871.patch
at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18871#30

[4] 0001-Handle-lone-quote-500-characters-away-from-XML-tag-B.patch
at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33887#94

[5] 0002-Handle-outside-SGML-XML-tags-Bug-33887.patch
at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33887#94

[6] 0001-Don-t-fontify-text-outside-of-SGML-XML-tags-Bug-3388.patch
at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33887#124

[7] 0001-Don-t-sgml-syntax-propertize-inside-XML-prolog-Bug-3.patch
at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32823#39

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Index: emacs-26.1+1/lisp/nxml/nxml-rap.el
===
--- emacs-26.1+1.orig/lisp/nxml/nxml-rap.el
+++ emacs-26.1+1/lisp/nxml/nxml-rap.el
@@ -35,35 +35,25 @@
 ;;
 ;; Our strategy is to keep track of just the problematic things.
 ;; Specifically, we keep track of all comments, CDATA sections and
-;; processing instructions in the instance.  We do this by marking all
-;; except the first character of these with a non-nil nxml-inside text
-;; property. The value of the nxml-inside property is comment,
-;; cdata-section or processing-instruction.  The first character does
-;; not have the nxml-inside property so we can find the beginning of
-;; the construct by looking for a change in a text property value
-;; (Emacs provides primitives for this).  We use text properties
-;; rather than overlays, since the implementation of overlays doesn't
-;; look like it scales to large numbers of overlays in a buffer.
-;;
-;; We don't in fact track all these constructs, but only track them in
-;; some initial part of the instance.
+;; processing instructions in the instance.  We do this by marking
+;; the first character of these with the generic string syntax by setting
+;; a 'syntax-table' text property in `sgml-syntax-propertize'.
 ;;
 ;; Thus to parse some random point in the file we first ensure that we
-;; have scanned up to that point.  Then we search backwards for a
-;; <. Then we check whether the < has an nxml-inside property. If it
-;; does we go backwards to first character that does not have an
-;; nxml-inside property (this character must be a <).  Then we start
-;; parsing forward from the < we have found.
+;; have scanned up to that point.  Then we search backwards for a <.
+;; Then we check whether the < has the generic string syntax.  If it
+;; does we go backwards to first character of the generic string (this
+;; character must be a <).  Then we start parsing forward from the <
+;; we have found.
 ;;
 ;; The prolog has to be parsed specially, so we also keep track of the
 ;; end of the prolog in `nxml-prolog-end'. The prolog is reparsed on
 ;; every change to the prolog.  This won't work well if people try to
 ;; edit huge internal subsets. Hopefully that will be rare.
 ;;
-;; We keep track of the changes by adding to the buffer's
-;; after-change-functions hook.  Scanning is also done as a
-;; prerequisite to fontification by adding to fontification-functions
-;; (in the same way as jit-lock).  This means that scanning for these
+;; We rely on the `syntax-propertize-function' machinery to keep track
+;; of the changes in the buffer.  Fontification also relies on correct
+;; `syntax-table' properties.  This means that scanning for these
 ;; constructs had better be quick.  Fortunately it is. Firstly, the
 ;; typical proportion of comments, CDATA sections and processing
 ;; instructions is small relative to other things.  Secondly, to scan
@@ -79,7 +69,15 @@
   "Integer giving 

Bug#879741: next steps / request for help with phpmyadmin for debian buster

2019-05-30 Thread Felipe Sateler
On Wed, May 29, 2019 at 10:59 AM Blümel Matthias <
matthias.blue...@krumedia.com> wrote:

> Here we go: unit-tests are back in debian/rules :D.
>
> I'm stuggling at the moment with my setup for selenium-tests. This has
> nothing to do with package-related suff, the tests on a git-checkout
> are also failing.
>
> As long as I can see, the unit-tests are only testing basic stuff.
> There seems to be nothing with twig-templates, shapefiles, 2fa,  pdf-
> export, …
>
> Tomorrow is public holiday in Germany, but I already "catched" one of
> our trainees for testing the package and it's dependencies starting on
> friday.
>
> @felipe: can you enable the issues-feature on the project?


Sorry for the delay, done now.


> Are you fine
> with the way I mentioned in comment #62 to update to the current
> version? If so, who triggers the update? Am I able to push to master
> with the "developer"-role?
>

Yes, the developer role should be sufficient. Should any permission be
missing, just tell me.

I think the best plan is what you outlined:

> Make a new update to 4.8.5 based on master and rebase the work currently
laying around in three repositories?

I also have some patches I didn't push so I guess they make more sense to
apply on top (if still needed).

> What do you think is the best way to get the changes into the main
project? pushing directly to master? pushing to a new branch? making a PR?

I think PRs are best for changes that require input from others.
Unfortunately, they are not very good for the upstream/pristine-tar/master
trio needed for a new upstream update. So I think upstream updates should
go directly to master.

I think most teams push directly to master. After all, a revert is not that
difficult to do in case a commit was not ok :)
-- 

Saludos,
Felipe Sateler


Bug#929321: Update for SQLAlchemy to address CVE-2019-7164 CVE-2019-7548

2019-05-30 Thread Thomas Goirand
Dear package maintainer,

We're about to upgrade SQLAlchemy in Buster to address an SQL injection
issue. The fixed package is in unstable, under the version 1.2.18+ds1-2.

In some rare cases, this update may break reverse depenencies, leading
to non-working SQL queries.

This is why I'm writing this email to you today: to ask you to please
test your application with SQLAlchemy 1.2.18+ds1-2 ASAP, to address any
potential unforecast issue before the Buster release.

Details about the discussion can be seen here in the Debian bug #929321.

Best regards,

Thomas Goirand (zigo)



Bug#641746: Hi Dear Please Can we talk??

2019-05-30 Thread Vannessa Evans
Hi Dear Please Can we talk??


Bug#893009: Patch for pkgdata crash

2019-05-30 Thread Scott Talbert

Hi,

This crash has been fixed upstream a while back and the fix (attached) is 
pretty straightforward.  Do you think that this can get applied in stretch 
please?


Thanks,
ScottFrom 0fd799f7eead9e29fa1dd81f8a119b5fbc88ec36 Mon Sep 17 00:00:00 2001
From: Michael Ow 
Date: Fri, 20 May 2016 20:00:53 +
Subject: [PATCH] ICU-12531 Add null check for closeFunction

X-SVN-Rev: 38757
---
 icu4c/source/common/unicode/localpointer.h | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/icu4c/source/common/unicode/localpointer.h b/icu4c/source/common/unicode/localpointer.h
index 35e37765c23..c86429359da 100644
--- icu4c/source/common/unicode/localpointer.h
+++ icu4c/source/common/unicode/localpointer.h
@@ -485,9 +485,6 @@ class LocalArray : public LocalPointerBase {
  * like LocalPointer except that this subclass will use the closeFunction
  * rather than the C++ delete operator.
  *
- * Requirement: The closeFunction must tolerate a NULL pointer.
- * (We could add a NULL check here but it is normally redundant.)
- *
  * Usage example:
  * \code
  * LocalUCaseMapPointer csm(ucasemap_open(localeID, options, ));
@@ -512,12 +509,12 @@ class LocalArray : public LocalPointerBase {
 : LocalPointerBase(src.ptr) { \
 src.ptr=NULL; \
 } \
-~LocalPointerClassName() { closeFunction(ptr); } \
+~LocalPointerClassName() { if (ptr != NULL) { closeFunction(ptr); } } \
 LocalPointerClassName =(LocalPointerClassName &) U_NOEXCEPT { \
 return moveFrom(src); \
 } \
 LocalPointerClassName (LocalPointerClassName ) U_NOEXCEPT { \
-closeFunction(ptr); \
+if (ptr != NULL) { closeFunction(ptr); } \
 LocalPointerBase::ptr=src.ptr; \
 src.ptr=NULL; \
 return *this; \
@@ -531,7 +528,7 @@ class LocalArray : public LocalPointerBase {
 p1.swap(p2); \
 } \
 void adoptInstead(Type *p) { \
-closeFunction(ptr); \
+if (ptr != NULL) { closeFunction(ptr); } \
 ptr=p; \
 } \
 }
@@ -544,7 +541,7 @@ class LocalArray : public LocalPointerBase {
 explicit LocalPointerClassName(Type *p=NULL) : LocalPointerBase(p) {} \
 ~LocalPointerClassName() { closeFunction(ptr); } \
 LocalPointerClassName (LocalPointerClassName ) U_NOEXCEPT { \
-closeFunction(ptr); \
+if (ptr != NULL) { closeFunction(ptr); } \
 LocalPointerBase::ptr=src.ptr; \
 src.ptr=NULL; \
 return *this; \
@@ -558,7 +555,7 @@ class LocalArray : public LocalPointerBase {
 p1.swap(p2); \
 } \
 void adoptInstead(Type *p) { \
-closeFunction(ptr); \
+if (ptr != NULL) { closeFunction(ptr); } \
 ptr=p; \
 } \
 }


Bug#929777: gcc-6: output errors to .gcda file are not checked

2019-05-30 Thread Vincent Lefevre
Package: gcc-6
Version: 6.3.0-18+deb9u1
Severity: normal

When executing a program compiled with profile generation
(-fprofile-generate), the obtained .gcda file is sometimes
empty (apparently due to write errors). The problem is that
the program terminates successfully, so that the issue is
not detected. Well, "gcc -fprofile-use" outputs a warning,
but that's all.

Write failures should be detected, and when this happens,
the program should terminate with a non-zero exit status
as usual.

-- 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.9.0-8-amd64 (SMP w/64 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-6 depends on:
ii  binutils  2.28-5
ii  cpp-6 6.3.0-18+deb9u1
ii  gcc-6-base6.3.0-18+deb9u1
ii  libc6 2.24-11+deb9u4
ii  libcc1-0  6.3.0-18+deb9u1
ii  libgcc-6-dev  6.3.0-18+deb9u1
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgmp10  2:6.1.2+dfsg-1
ii  libisl15  0.18-1
ii  libmpc3   1.0.3-1+b2
ii  libmpfr4  3.1.5-1
ii  libstdc++66.3.0-18+deb9u1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages gcc-6 recommends:
ii  libc6-dev  2.24-11+deb9u4

Versions of packages gcc-6 suggests:
pn  gcc-6-doc 
pn  gcc-6-locales 
ii  gcc-6-multilib6.3.0-18+deb9u1
pn  libasan3-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx2-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information



Bug#754513: CFP - Thailand IRED Joint International Conference - August 2019

2019-05-30 Thread 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 Bangkok, Thailand. The theme for the 2019 Thailand 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, Electronics and 
Communication - ACEC


Official Website: www.acec.theired.org




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


Official Website: www.acsee.theired.org




Track 3: 9th International Conference On Advances in Mechanical and Robotics 
Engineering - AMRE


Official Website: www.amre.theired.org




Track 4: 9th International Conference On Advances in Social Science, Management 
and Human Behaviour - SMHB


Official Website: www.smhb.theired.org


Conference Venue: Hotel Lebua at State Tower, Bangkok, Thailand


Conference Date: 03 - 04 August 2019


Abstract/ Full Paper Submission For Review: 10 June 2019




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 
International conference that has been worldwide.


Kindly refer to the below link to access the conference photographs.




https://gallery.theired.org/previous-conferences/



We Request you to forward this email to your colleagues/Researchers/students in 
order to promote the conference.


The aim of the conference is to provide a platform to the researchers and 
practitioners from both academia as well as industry to meet and share 
cutting-edge development in the field.
Please take the time to explore the website for more details, check on 
important dates, and keep yourself up to date on recent changes. 



Registered Papers (IRED Extended paper guidelines applicable) will be published 
in the various issues of International journals.
Prospective authors are invited to submit full (original) research papers; 
which are NOT submitted or published or under consideration anywhere in other 
conferences or journals; in electronic format via email. 




Thanks Much 
Stefania Wilson
NEWS Division 
IRED
 If you no longer wish to receive mail from us, you can 

unsubscribe
IRED 

Bug#876303: Question regarding status

2019-05-30 Thread sawbona
Good morning:

Could you tell me the status of this bug (876303)?
ie: will it be fixed for 5.0?

Thanks in advance.

Best,Carlos Izzo Videla



Bug#929776: unblock: rrdtool/1.7.1-2

2019-05-30 Thread Jean-Michel Vourgère
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

Please allow me to add an upstream patch in order to fix segfaults in rrdtool 
daemon, that occurs when xport'ing an non-existent RRD file.

unblock rrdtool/1.7.1-2
diff -Nru rrdtool-1.7.1/debian/changelog rrdtool-1.7.1/debian/changelog
--- rrdtool-1.7.1/debian/changelog	2019-02-07 17:08:22.0 +0100
+++ rrdtool-1.7.1/debian/changelog	2019-05-30 22:28:06.0 +0200
@@ -1,3 +1,9 @@
+rrdtool (1.7.1-2) unstable; urgency=medium
+
+  * Cherry pick commit from 1.7.2 to prevent daemon segfault. 
+
+ -- Jean-Michel Vourgère   Thu, 30 May 2019 22:28:06 +0200
+
 rrdtool (1.7.1-1) unstable; urgency=medium
 
   * New upstream version (Closes: #891491, #898184):
diff -Nru rrdtool-1.7.1/debian/patches/segfault-xport rrdtool-1.7.1/debian/patches/segfault-xport
--- rrdtool-1.7.1/debian/patches/segfault-xport	1970-01-01 01:00:00.0 +0100
+++ rrdtool-1.7.1/debian/patches/segfault-xport	2019-05-30 22:28:06.0 +0200
@@ -0,0 +1,21 @@
+From: themylogin 
+Subject: fix segfault on non-existent RRD file when using rrdcached
+ fix segfault on non-existent RRD file when using rrdcached + rrdtool xport
+ (like 814ca69 does for rrdtool graph)
+Applied-Upstream: https://github.com/oetiker/rrdtool-1.x/commit/24b922a2eae193d5d44c01a75786aca4b277a4db
+Date: Wed, 27 Mar 2019 18:09:55 +0100
+Reviewed-by: Tobias Oetiker 
+
+Index: rrdtool/src/rrd_xport.c
+===
+--- rrdtool.orig/src/rrd_xport.c
 rrdtool/src/rrd_xport.c
+@@ -231,7 +231,7 @@ static int rrd_xport_fn(
+ 
+ 
+ /* pull the data from the rrd files ... */
+-if (data_fetch(im) == -1)
++if (data_fetch(im) != 0)
+ return -1;
+ 
+ /* evaluate CDEF  operations ... */
diff -Nru rrdtool-1.7.1/debian/patches/series rrdtool-1.7.1/debian/patches/series
--- rrdtool-1.7.1/debian/patches/series	2019-02-07 16:21:22.0 +0100
+++ rrdtool-1.7.1/debian/patches/series	2019-05-30 22:28:06.0 +0200
@@ -1,2 +1,3 @@
 no-rpath-for-ruby
 breaks-long-man-lines
+segfault-xport


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


Bug#929775: sqlite3: CVE-2019-8457

2019-05-30 Thread Salvatore Bonaccorso
Source: sqlite3
Version: 3.27.2-2
Severity: important
Tags: security upstream
Control: found -1 3.16.2-5+deb9u1
Control: found -1 3.16.2-5

Hi,

The following vulnerability was published for sqlite3.

CVE-2019-8457[0]:
| SQLite3 from 3.6.0 to and including 3.27.2 is vulnerable to heap out-
| of-bound read in the rtreenode() function when handling invalid rtree
| tables.


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-8457
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8457
[1] https://www.sqlite.org/src/info/90acdbfce9c08858

Regards,
Salvatore



Bug#927856: unblock: python-jwcrypto/0.6.0-1

2019-05-30 Thread Paul Gevers
Hi Timo,

On 30-05-2019 13:18, Timo Aaltonen wrote:
> Hi, I don't know how much would have to be backported, but it's probably
> better to just unblock freeipa 4.7.2-3 instead, because python-jwcrypto
> is a dep of freeipa-server (which isn't built on sid/buster).

Do I understand correctly that the code is present to build it, you just
don't do that in Debian? Do you suggest to change this bug to "unblock:
freeipa/4.7.2-3" instead then? (I would be willing to unblock it, but
then python-jwcrypto would go).

> That way
> current client-only freeipa would remain on buster. Custodia is another
> package which depends on -jwcrypto, but it's again a server thing so can
> be removed from buster.

These package are all from the same team, I guess the team agrees?

Paul



Bug#929774: iproute2: please compile with NETNS_RUN_DIR=/run/netns

2019-05-30 Thread Andrew Ayer
Package: iproute2
Version: 4.20.0-2
Severity: normal

Dear Maintainer,

Currently, iproute2 is built with the default NETNS_RUN_DIR of
/var/run/netns[1].  Consequentially, if /var is a separate filesystem,
it is not possible to use ip netns to manage network namespaces early
in boot before /var is mounted[2], because the symlink from /var/run to
/run does not exist.

This can be fixed by adding the following line to debian/rules under
the definition of KERNEL_INCLUDE[3]:

export NETNS_RUN_DIR=/run/netns

Thanks,

Andrew

[1] https://sources.debian.org/src/iproute2/4.20.0-2/Makefile/#L19

[2] for example, in a udev rule to move interfaces to a different namespace

[3] https://sources.debian.org/src/iproute2/4.20.0-2/debian/rules/#L23



Bug#928807: unblock: mesa/18.3.6-2

2019-05-30 Thread Paul Gevers
Control: tags -1 moreinfo

Hi Andreas,

On Sat, 11 May 2019 16:43:45 +0200 Andreas Boll  wrote:
> This unblock request contains a stable upstream release with lots of
> bug fixes for mesa's graphics drivers including fixes for driver
> crashes and visual corruption. It fixes two RC bugs (#922346,
> #926857).

How would a targeted fix look like? New upstream releases don't meet the
freeze policy and the diff is way to big to properly review.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#928746: unblock: zfs-linux/0.7.13-1

2019-05-30 Thread Paul Gevers
Control: tags -1 moreinfo

Hi Mo,

On Thu, 09 May 2019 22:09:18 -0700 Mo Zhou  wrote:
> zfs-linux (= 0.7.13-1) is 66 days in unstable and there is no new bug
> for it.
> Compared to (0.7.12-2), the (0.7.13-1) version in unstable only
> introduces
> bug fixes. Aron has already applied for an unblock but it was rejected.
> Here I'm requesting for unblock again.

I checked bug #923770 again (it was filed by you by the way). As I said
in that bug, I didn't spot anything that was at the level of important
or more severe in Debian BTS terms. I may have been wrong, but then
please point me to the changes so important that you want them in
buster. Please also be prepared to undo the new upstream release and
just fix the bugs that are so important to you.

Be aware that requests like this one are draining energy from the
release team. It isn't nice to turn a maintainer down on a request,
repeating the process is worse. Your changes are huge (your explanation
is appreciated), we get several unblock requests per day and we have a
freeze policy in place to manage it. Please don't push your pet project
so hard if it doesn't meet the policy that you are driving the
volunteers in the release team away. Thanks for also considering our time.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#928741: [pre-a] unblock: julia/1.0.4+dfsg-1

2019-05-30 Thread Paul Gevers
Control: tags -1 moreinfo
Control: retitle -1 unblock: julia/1.0.4+dfsg-1

Hi Mo,

On Thu, 09 May 2019 19:26:06 -0700 Mo Zhou  wrote:
> The current version in testing is 1.0.3, I'm requesting
> unblock for 1.0.4 (not-yet-released) because Julia's
> 1.0.X series is strictly a bug-fix-only branch. As per
> upstream's call-for-community-testing announcement:

I appreciate you want the latest you can get for you package into
buster. However, a new upstream (even for only bug fixes branches) does
not meet the freeze policy. Can you please indicate which bugs in the
changelog you consider important or more severe (in Debian BTS terms)?
How much of the changes would fall in that category?

Paul



signature.asc
Description: OpenPGP digital signature


Bug#928381: unblock: stunnel4/3:5.54~b3-1

2019-05-30 Thread Paul Gevers
Hi Peter,

On 30-05-2019 11:24, Peter Pentchev wrote:
> Just for my information, is there a chance that this upgrade could be
> allowed later on during the buster lifecycle as a stable update?

If it would be suitable for a stable release point update, it would be
suitable now. We're close to releasing, but not that close yet.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#929773: RFS: wf-recorder/0.1-1 ITP

2019-05-30 Thread Birger Schacht
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "wf-recorder"

* Package name : wf-recorder
  Version  : 0.1-1
  Upstream Author  : Ilia Bozhinov
* Url  : https://github.com/ammen99/wf-recorder
* Licenses : Expat
  Programming Lang : C
  Section  : x11

 wf-recorder is a utility program for screen recording of wlroots-based
 compositors (more specifically, those that support wlr-screencopy-v1
 and xdg-output). Its dependences are ffmpeg, wayland-client and
 wayland-protocols.

It builds those binary packages:

  * wf-recorder

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

https://mentors.debian.net/package/wf-recorder

Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/w/wf-recorder/wf-recorder_0.1-1.dsc

Alternatively, you can access package debian/ directory via git from URL:
https://salsa.debian.org/bisco-guest/wf-recorder.git

More information about wf-recorder can be obtained from
https://github.com/ammen99/wf-recorder


cheers,
Birger



Bug#929772: ResidualVM should be built against SDL2 instead of SDL 1.2

2019-05-30 Thread Bastien Bouclet
Package: residualvm

Version: 0.3.1+dfsg-1

I'm an upstream maintainer of ResidualVM and just noticed the version
packaged in Debian was build against SDL 1.2. At this point we recommend
linking against SDL 2, as ResidualVM can take advantage of the new
capabilities of that version. Our support of SDL 1.2 should be considered
as deprecated.

Please switch the dependency to SDL 2, the configure script should detect
it automatically.


Bug#929771: kservice FTCBFS: missing Build-Depends: qttools5-dev

2019-05-30 Thread Helmut Grohne
Source: kservice
Version: 5.54.0-1
Tags: pending
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

kservice fails to cross build from source. This is fixed in git:
https://salsa.debian.org/qt-kde-team/kde/kservice/commit/b676a9cab76774b5165862bfc221f11ab7655c53
Please close this bug with the next upload to trigger a qa rebuild.

Helmut



Bug#929629: mergechanges drops the binary packages from the Binary field when merging source and binary changes

2019-05-30 Thread Simon McVittie
Control: tags -1 + moreinfo

On Mon, 27 May 2019 at 23:15:27 +0100, Simon McVittie wrote:
> On Mon, 27 May 2019 at 16:29:57 +0200, Matthias Klose wrote:
> > mergechanges drops the binary packages from the Binary field when merging 
> > source
> > and binary changes.  Seen when trying to re-upload the binary openjdk-8 
> > packages
> > which were removed from unstable (all files at coccia.d.o:~doko/8).

Are you sure you were using devscripts 2.19.5 as stated in the bug report,
and not the devscripts 2.17.6+deb9u2 installed on coccia or another
stretch system? This looks as though you were using a mergechanges
version where #920470 has not yet been fixed.

It's helpful to run reportbug(1) (or at least reportbug --template)
on the exact system where you can reproduce a bug, to ensure that the
right information is included in the bug report.

> What were the inputs to mergechanges, what arguments and configuration
> did you use for mergechanges, what value did you expect for the Binary
> field, and what value did you actually get? Was it run on coccia or on
> some other system?

I have assumed that the command was the equivalent of:

mergechanges ~doko/8/openjdk-8_8u212-b01-1_{a*,i*,mi*,p*,s*}.changes

Your openjdk-8_8u212-b01-1_multi.changes~ (with the ~) on coccia has only:

Binary: openjdk-8-doc openjdk-8-source

and matches[1] the output that I see when I run the command above using
coccia's devscripts 2.17.6+deb9u2. That's consistent with the symptoms
of #920470, where only the Binary field from the first .changes file
(in this case _all) is used, and the rest are ignored. Am I correct to
assume that this is the output that prompted you to report this bug?

However, when I try that on my unstable system with devscripts 2.19.5,
where #920470 has been fixed, I get the union of all Binary fields:

Binary: openjdk-8-dbg openjdk-8-demo openjdk-8-doc openjdk-8-jdk 
openjdk-8-jdk-headless openjdk-8-jre openjdk-8-jre-headless openjdk-8-jre-zero 
openjdk-8-source

which seems correct to me.

This also matches[1] your openjdk-8_8u212-b01-1_multi.changes (without the
~) on coccia, except that yours has a duplicate mention of openjdk-8-doc
and openjdk-8-source in Binary. Was your _multi.changes constructed by
hand or by a different version of devscripts?

Thanks,
smcv

[1] When I say two .changes files match, I mean: the absence or content
of a PGP signature might differ, the hashes and sizes of the signed
.dsc and .buildinfo files might differ, and everything else is
exactly identical.



Bug#929766: RM: haskell-cabal -- RoQA; now included in src:ghc

2019-05-30 Thread Mattia Rizzolo
Package: ftp.debian.org
Control: clone -1 -2 -3 -4 -5
Control: retitle -2 RM: haskell-text -- RoQA; now included in src:ghc
Control: retitle -3 RM: haskell-stm -- RoQA; now included in src:ghc
Control: retitle -4 RM: haskell-parsec -- RoQA; now included in src:ghc
Control: retitle -5 RM: haskell-mtl -- RoQA; now included in src:ghc
X-Debbugs-Cc: debian-hask...@lists.debian.org

ghc itself now Provides: the binaries previously built by
src:haskell-cabal, so this can be removed now.

Same for src:haskell-text src:haskell-stm src:haskell-parsec
src:haskell-mtl, all the Provided by ghc.

`dak rm` whines about broken build-depends, but I've checked all the
required packages, and they are provided using the proper version (I
mean, versioned provides) by ghc.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#929132: unblock (pre-approval): dbus/1.12.14-1

2019-05-30 Thread Samuel Thibault
Hello,

Simon McVittie, le jeu. 30 mai 2019 19:04:49 +0100, a ecrit:
> The only change that I think could possibly cause regressions
> for d-i's use case (AT-SPI)

d-i doesn't use AT-SPI yet actually.

Samuel



Bug#929132: unblock (pre-approval): dbus/1.12.14-1

2019-05-30 Thread Simon McVittie
On Sun, 19 May 2019 at 15:35:00 +, Niels Thykier wrote:
> Ok. I have added an unblock and age-days 8 hint.  Also CC'ing KiBi for a
> d-i ack before adding an unblock-udeb hint.

This is now only waiting for a d-i ack, and I haven't had any regression
reports. Any opinions?

Full details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929132#5

The only change that I think could possibly cause regressions
for d-i's use case (AT-SPI) is that the tighter validation in
bus/desktop-file.c could break AT-SPI if it ships syntactically invalid
.service files, but /usr/share/dbus-1/services/org.a11y.Bus.service and
/usr/share/dbus-1/accessibility-services/org.a11y.atspi.Registry.service
both seem valid, so that shouldn't be an issue.

smcv



Bug#928735: u-boot-menu: Avoid hard-coding "vmlinuz"

2019-05-30 Thread Karsten Merker
On Thu, 09 May 2019, Vagrant Cascadian  wrote:

> Package: u-boot-menu
> Severity: normal
> Version: 3
> Tags: patch
> 
> Some architectures which might make use of u-boot-menu do not have
> kernel files matching "vmlinuz" (e.g. riscv64 has "vmlinux").
> 
> The attached patch uses "linux-version list --paths" to output the path
> of each versioned kernel, which outputs the matching kernel filenames.

Hello,

may I kindly ping you on this bugreport?  I'm working on d-i
support for riscv64 and would like to use the u-boot-menu package
there, but without Vagrant's patch it isn't usable on riscv64
(and on quite a number of other architectures as well, please see
below).  It would be great if you could upload a new version of
u-boot-menu with the patch applied to unstable.  If you are ok
with the patch but don't have time for preparing an upload, I
would offer doing an NMU if that would be ok for you.

An overview of vmlinuz- vs. vmlinux-using Debian architectures:

vmlinuz: alpha, amd64, arm64, armel, armhf, hppa, i386, ia64,
 s390x, sh4

vmlinux: m68k, mips{,64}{,r6}{,el}, powerpc, powerpcspe, ppc64,
 ppc64el, riscv64, sparc64

Regards,
Karsten
-- 
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.



Bug#929765: debian-security-support: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

2019-05-30 Thread Holger Levsen
On Thu, May 30, 2019 at 01:40:14PM -0300, Adriano Rafael Gomes wrote:
> Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
> tested with msgfmt.

thank you, commited to git, will be included in the upload on Saturday!
:)


-- 
tschau,
Holger

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

Some people say that the climate crisis  is something that we all have created,
but  that is not true,  because if everyone is guilty  then no one is to blame.
And someone is to blame.  Some people, some companies,  some decision-makers in
particular, have known exactly what priceless values they have been sacrificing
to continue making unimaginable amounts of money.


signature.asc
Description: PGP signature


Bug#929765: debian-security-support: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

2019-05-30 Thread Adriano Rafael Gomes

Package: debian-security-support
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

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

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: PGP signature


Bug#929764: usbmuxd segfaults on startup

2019-05-30 Thread James Henried
Package: usbmuxd
Version: 1.1.1~git20181007.f838cf6-1
Severity: important

Dear Maintainer,

Reopening #919630.

Have been running into trouble mounting an iPhone with ifuse. Noticed that 
usbmuxd segfaults on startup:

# usbmuxd
Segmentation fault
# usbmuxd
free(): double free detected in tcache 2
Aborted
# usbmuxd
Segmentation fault
# usbmuxd
free(): double free detected in tcache 2
Aborted
#

When running ifuse, I get similar errors:

# ifuse /media/iphone/
No device found, is it connected?
If it is make sure that your user has permissions to access the raw usb device.
If you're still having issues try unplugging the device and reconnecting it.
double free or corruption (fasttop)
Aborted
#

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

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

Versions of packages usbmuxd depends on:
ii  adduser3.118
ii  libc6  2.28-5
ii  libimobiledevice6  1.2.1~git20181030.92c5462-1
ii  libplist3  2.0.1~git20190104.3f96731-1
ii  libusb-1.0-0   2:1.0.22-2

usbmuxd recommends no packages.

usbmuxd suggests no packages.

-- no debconf information

This has been happening for a while. Previously, I had no problem
mounting an iphone and reading its contents. Now, ifuse doesn't see
it at all.

This is a phone with IOD 10.3.3. It's seen by lsusb:

Bus 001 Device 012: ID 05ad:13a8 Apple, Inc. iPhone5/5C/5S/6

# ideviceinfo
No device found, is it plugged in?
double free or corruption (fasttop)
Aborted
# 



Thanks so much for your help!



Bug#929749: libwebkit2gtk-4.0-37: version 2.24.2-1 does not play some streams

2019-05-30 Thread Alberto Garcia
Control: tags -1 upstream
Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=198377

On Thu, May 30, 2019 at 11:48:19AM +0200, Richard Lucassen wrote:

> I appended this bug to 928044, but Alberto asked me to open a
> new report. In the meantime I installed the unstable version
> 2.24.2-1, but the problems remain the same as in the testing version
> 2.24.1-1. Bug verified on three different computers, all Debian
> testing amd64.

Thanks, I filed it upstream:

https://bugs.webkit.org/show_bug.cgi?id=198377

> B) There is one station that does not play at all:
> 
> 1) Click on "Page menu" (bottom left corner) and choose "jazz"
> 
> 2) Choose Bert's Bytes.
> 
> Version 2.24.0 plays it, 2.24.1/2.24.2 does not. This is a simple
> seekable mp3.

I filed this one as a separate upstream bug (although the root cause
is perhaps the same):

https://bugs.webkit.org/show_bug.cgi?id=198376

Berto



Bug#929588: usat: source tarballs are missing the source of the configure script

2019-05-30 Thread Carsten Schoenert
Hi,

previous and the most recent release of the usat tarballs is missing the
source for the configure script.

http://usat.sourceforge.net/code/lsat-0.9.8.2.zip

For Debian this makes the package [1] non-free due the regulation of the
Debian Free Software Guidelines [2].
It also makes it impossible to build the package on platforms that are
not supported by the provided configure script.

Could you please include the source for the generated configure script?

[1] https://tracker.debian.org/pkg/lsat
[2] https://www.debian.org/social_contract.en.html#guidelines

-- 
Regards
Carsten Schoenert



Bug#929588: lsat missing source for configure

2019-05-30 Thread Carsten Schoenert
Control: tags -1 upstream

On Sun, May 26, 2019 at 08:16:19PM +0200, Helmut Grohne wrote:
> The lsat source package is missing the source code for the file
> ./configure. That file identifies itself as being generated using
> autoconf. The source tarball does not contain any corresponding source.
> This is a DFSG #2 violation and thus justifies severity serious.

This is not only happen within the version in the Debian archive, this
is also a recent issue in the most recent version 0.9.8.2 in the
upstream tarball. Seems upstream should rework their process to create
the tarball.

http://usat.sourceforge.net/code/lsat-0.9.8.2.zip

Regards
Carsten



Bug#929763: runs backup files

2019-05-30 Thread Trent W. Buck
Package: systemd-cron
Version: 1.5.14-2
Severity: normal

This log strongly indicates systemd-cron is trying to "do things" with backup 
files:

2019-05-31T01:29:30+1000 not-omega systemd[1]: cron.target: Wants 
dependency dropin 
/run/systemd/generator/cron.target.wants/cron-ntpsec~-root-0.timer is not a 
valid unit name, ignoring.

This happened after I edited /etc/cron.d/ntpsec-ntpviz, thereby creating a 
backup file /etc/cron.d/ntpsec-ntpviz~.

https://manpages.debian.org/stretch/cron/cron.8.en.html#DEBIAN_SPECIFIC
https://manpages.debian.org/run-parts

Vixie cron ignores backups in /etc/cron.d/, so systemd-cron should, too.
The actual code in Vixie cron is below; it's the same as run-parts(8).
systemd-cron needs similar logic.

pathnames.h:#define SYSCRONDIR  "/etc/cron.d"

database.c: if (!(dir = opendir(SYSCRONDIR))) {

database.c: while (dir != NULL && NULL != (dp = readdir(dir))) {

database.c: /* skipfile names with letters outside the set
database.c:  * [A-Za-z0-9_-], like run-parts.
database.c:  */
database.c: if (!valid_name(dp->d_name))
database.c:   continue;


database.c:/* True or false? Is this a valid filename? */
database.c:
database.c:/* Taken from Clint Adams 'run-parts' version to support lsb 
style
database.c:   names, originally GPL, but relicensed to cron license per 
e-mail of
database.c:   27 September 2003. I've changed it to do regcomp() only once. 
*/
database.c:
database.c:static int
database.c:valid_name(char *filename)
database.c:{
database.c:  static regex_t hierre, tradre, excsre, classicalre;
database.c:  static int donere = 0;
database.c:
database.c:  if (!donere) {
database.c:  donere = 1;
database.c:  if (regcomp(, "^_?([a-z0-9_.]+-)+[a-z0-9]+$",
database.c:  REG_EXTENDED | REG_NOSUB)
database.c:  || regcomp(, "^[a-z0-9-].*dpkg-(old|dist)$",
database.c: REG_EXTENDED | REG_NOSUB)
database.c:  || regcomp(, "^[a-z0-9][a-z0-9-]*$", REG_NOSUB)
database.c:  || regcomp(, "^[a-zA-Z0-9_-]+$",
database.c: REG_EXTENDED | REG_NOSUB)) {
database.c:  log_it("CRON", getpid(), "REGEX FAILED", "valid_name");
database.c:  (void) exit(ERROR_EXIT);
database.c:  }
database.c:  }
database.c:  if (lsbsysinit_mode) {
database.c:  if (!regexec(, filename, 0, NULL, 0)) {
database.c:  return regexec(, filename, 0, NULL, 0);
database.c:  } else {
database.c:  return !regexec(, filename, 0, NULL, 0);
database.c:  }
database.c:  }
database.c:  /* Old standard style */
database.c:  return !regexec(, filename, 0, NULL, 0);
database.c:}



Bug#929747: qa.debian.org: Please add cross-buildability in summary

2019-05-30 Thread Helmut Grohne
Hi,

On Thu, May 30, 2019 at 10:57:52AM +0200, Samuel Thibault wrote:
> https://tracker.debian.org/ has a link to the cross-buildability status
> of a package. It'd be useful to have a tick or cross on the
> https://qa.debian.org/developer.php page, e.g. in the CI/Rep column, as
> a link to the cross-buildability status, to be able to easily check the
> status of one's own packages.

If you do, please consider:
 * crossqa.d.n only works on unstable. If a package is not in unstable,
   there shouldn't be a link. (e.g. gcc-9)
 * crossqa.d.n only fills a page if there is some package built for one
   of the architectures being tested. Therefore no link should be
   emitted for indep-only packages. Currently, we test for any non-x86
   release architecture, so if a package only builds for some x86, it
   will be 404 as well.

If some API is missing in the service, please get in touch with me.

Helmut



Bug#929762: centreon-clib FTCBFS: debian/rules forces build architecture compilers

2019-05-30 Thread Helmut Grohne
Source: centreon-clib
Version: 18.10.0-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

centreon-clib fails to cross build from source, because debian/rules
forces using build architecture compilers as it is using the make
default values. debhelper already takes care of forwarding environment
variables and passes cross tools for cross compilation, so dropping
these variables is all that needs to be done to make centreon-clib cross
buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru centreon-clib-18.10.0/debian/changelog 
centreon-clib-18.10.0/debian/changelog
--- centreon-clib-18.10.0/debian/changelog  2018-11-12 15:56:47.0 
+0100
+++ centreon-clib-18.10.0/debian/changelog  2019-05-30 08:26:37.0 
+0200
@@ -1,3 +1,10 @@
+centreon-clib (18.10.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Don't force build architecture compilers. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 30 May 2019 08:26:37 +0200
+
 centreon-clib (18.10.0-1) unstable; urgency=medium
 
   * Initial release (Closes: #913899)
diff --minimal -Nru centreon-clib-18.10.0/debian/rules 
centreon-clib-18.10.0/debian/rules
--- centreon-clib-18.10.0/debian/rules  2018-11-12 15:56:47.0 +0100
+++ centreon-clib-18.10.0/debian/rules  2019-05-30 08:26:37.0 +0200
@@ -10,8 +10,6 @@
 CXXFLAGS+=$(CPPFLAGS)
 
 export CMAKE_OPTIONS := \
-  -DCMAKE_C_COMPILER="$(CC)" \
-  -DCMAKE_CXX_COMPILER="$(CXX)" \
   -DCMAKE_CXX_FLAGS="$(CXXFLAGS)" \
   -DCMAKE_SHARED_LINKER_FLAGS_RELEASE="$(LDFLAGS)" \
   -DWITH_SHARED_LIB=1 \


Bug#929760: comet-ms FTCBFS: does not pass cross tools to make

2019-05-30 Thread Helmut Grohne
Source: comet-ms
Version: 2018012-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

comet-ms fails to cross build from source, because it does not pass
cross tools to make. The easiest way of doing so - using dh_auto_build -
makes comet-ms cross buildable. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru comet-ms-2018012/debian/changelog 
comet-ms-2018012/debian/changelog
--- comet-ms-2018012/debian/changelog   2018-11-18 10:05:33.0 +0100
+++ comet-ms-2018012/debian/changelog   2019-05-30 10:06:43.0 +0200
@@ -1,3 +1,10 @@
+comet-ms (2018012-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 30 May 2019 10:06:43 +0200
+
 comet-ms (2018012-1) unstable; urgency=low
 
   * New upstream release.
diff --minimal -Nru comet-ms-2018012/debian/rules comet-ms-2018012/debian/rules
--- comet-ms-2018012/debian/rules   2018-11-18 10:05:33.0 +0100
+++ comet-ms-2018012/debian/rules   2019-05-30 10:06:41.0 +0200
@@ -26,5 +26,5 @@
docbook-to-man debian/comet-ms.sgml > debian/comet-ms.1
 
 override_dh_auto_build: manpage
-   make
+   dh_auto_build
 


Bug#929759: wcd FTCBFS: does not pass cross tools to make

2019-05-30 Thread Helmut Grohne
Source: wcd
Version: 5.3.4-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

wcd fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so - using dh_auto_build - makes
wcd cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru wcd-5.3.4/debian/changelog wcd-5.3.4/debian/changelog
--- wcd-5.3.4/debian/changelog  2017-01-08 12:19:45.0 +0100
+++ wcd-5.3.4/debian/changelog  2019-05-30 09:40:54.0 +0200
@@ -1,3 +1,10 @@
+wcd (5.3.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 30 May 2019 09:40:54 +0200
+
 wcd (5.3.4-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru wcd-5.3.4/debian/rules wcd-5.3.4/debian/rules
--- wcd-5.3.4/debian/rules  2017-01-08 12:19:45.0 +0100
+++ wcd-5.3.4/debian/rules  2019-05-30 09:40:52.0 +0200
@@ -28,7 +28,7 @@
 include debian/debian-vars.mk
 
 override_dh_auto_build:
-   $(MAKE) -C src $(MAKE_OPTIONS) all
+   dh_auto_build --sourcedirectory=src -- $(MAKE_OPTIONS) all
 
 override_dh_auto_clean:
$(MAKE) -C src $(MAKE_OPTIONS) clean


Bug#929758: wmifinfo FTCBFS: uses the build architecture compiler as linker

2019-05-30 Thread Helmut Grohne
Source: wmifinfo
Version: 0.10-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

wmifinfo fails to cross build from source, because its Makefile uses two
variables (CC and LD) to supply the compiler, but dh_auto_build only
passes the former. I think it would be best to default LD to CC as in
most cases, that's what you want and it retains the ability to specify
it separately. It also makes wmifinfo cross buildable. Please consider
applying the attached patch.

Helmut
--- wmifinfo-0.10.orig/Makefile
+++ wmifinfo-0.10/Makefile
@@ -12,7 +12,7 @@
 VERSION=0.10
 
 CC = gcc
-LD = gcc
+LD = $(CC)
 INSTALL = install
 CFLAGS = -Wall -O2
 COPTS = -D'VERSION="$(VERSION)"' -D'NAME="$(NAME)"'


Bug#929761: gkremldk FTCBFS: multiple reasons

2019-05-30 Thread Helmut Grohne
Source: gkremldk
Version: 0.9.7-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gkremldk fails to cross build from source. It hard codes the build
architecture pkg-config in Makefile.in. The best way to use pkg-config
is PKG_CHECK_MODULES as that makes missing dependencies fail early (and
uses the correct pkg-config). It also installs with -s, which uses the
wrong strip, breaks DEB_BUILD_OPTIONS=notsrip (#437043) and generation
of -dbgsym packages. The attached patch fixes all of that. Please
consider applying it.

Helmut
diff -u gkremldk-0.9.7/Makefile.in gkremldk-0.9.7/Makefile.in
--- gkremldk-0.9.7/Makefile.in
+++ gkremldk-0.9.7/Makefile.in
@@ -1,13 +1,15 @@
 
 LFLAGS = -shared -lpthread
 CC = @CC@
+GTK_CFLAGS = @GTK_CFLAGS@
+INSTALL = install
 
 INSTALLPATH = $(DESTDIR)/usr/lib/gkrellm2/plugins
 
 all: gkremldk.so
 
 gkremldk.o: mldonkeytools.o  gkremldk.c
-   $(CC) -Wall -fPIC `pkg-config gtk+-2.0 --cflags` -c gkremldk.c
+   $(CC) -Wall -fPIC $(GTK_CFLAGS) -c gkremldk.c
 
 gkremldk.so: gkremldk.o
$(CC) -Wall -shared -lpthread -o gkremldk.so gkremldk.o
@@ -19 +21 @@
-   install -c -s -m 644 gkremldk.so $(INSTALLPATH)
+   $(INSTALL) -c -s -m 644 gkremldk.so $(INSTALLPATH)
diff -u gkremldk-0.9.7/debian/changelog gkremldk-0.9.7/debian/changelog
--- gkremldk-0.9.7/debian/changelog
+++ gkremldk-0.9.7/debian/changelog
@@ -1,3 +1,12 @@
+gkremldk (0.9.7-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Use the correct pkg-config via PKG_CHECK_MODULES.
++ Don't strip during make install.
+
+ -- Helmut Grohne   Thu, 30 May 2019 08:36:34 +0200
+
 gkremldk (0.9.7-3) unstable; urgency=medium
 
   * Fix maintainer email address
diff -u gkremldk-0.9.7/debian/rules gkremldk-0.9.7/debian/rules
--- gkremldk-0.9.7/debian/rules
+++ gkremldk-0.9.7/debian/rules
@@ -4,6 +4,9 @@
 %:
dh $@
 
+override_dh_auto_install:
+   dh_auto_install -- INSTALL='install --strip-program=true'
+
 override_dh_auto_clean:
dh_auto_clean $@
rm -rf Makefile config.h config.log config.status
only in patch2:
unchanged:
--- gkremldk-0.9.7.orig/configure.ac
+++ gkremldk-0.9.7/configure.ac
@@ -21,5 +21,7 @@
 AC_FUNC_MALLOC
 AC_CHECK_FUNCS([bzero gethostbyname socket strdup])
 
+PKG_CHECK_MODULES([GTK],[gtk+-2.0])
+
 AC_CONFIG_FILES([Makefile])
 AC_OUTPUT


Bug#929757: wsclean misbuilds: build/host confusion

2019-05-30 Thread Helmut Grohne
Source: wsclean
Version: 2.6-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

wsclean successfully cross builds a broken package. It confuses build
and host architecture. Refer to man dpkg-architecture for an explanation
of these terms. The attached patch makes it build sanely. Please
consider applying it.

Helmut
diff --minimal -Nru wsclean-2.6/debian/changelog wsclean-2.6/debian/changelog
--- wsclean-2.6/debian/changelog2018-08-06 12:07:06.0 +0200
+++ wsclean-2.6/debian/changelog2019-05-30 09:52:20.0 +0200
@@ -1,3 +1,10 @@
+wsclean (2.6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Fix build/host confusion. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 30 May 2019 09:52:20 +0200
+
 wsclean (2.6-1) unstable; urgency=low
 
   * Push Standards-Versionto 4.2.0. No changes required
diff --minimal -Nru 
wsclean-2.6/debian/patches/Build-and-use-shared-lib-for-libwsclean.patch 
wsclean-2.6/debian/patches/Build-and-use-shared-lib-for-libwsclean.patch
--- wsclean-2.6/debian/patches/Build-and-use-shared-lib-for-libwsclean.patch
2018-06-13 13:04:47.0 +0200
+++ wsclean-2.6/debian/patches/Build-and-use-shared-lib-for-libwsclean.patch
2019-05-30 09:51:50.0 +0200
@@ -34,8 +34,8 @@
  
  install(TARGETS wsclean DESTINATION bin)
 -install(TARGETS wsclean-lib DESTINATION lib)
-+install(TARGETS wsclean-lib DESTINATION lib/${DEB_BUILD_MULTIARCH})
-+install(TARGETS wsclean-shared DESTINATION lib/${DEB_BUILD_MULTIARCH})
++install(TARGETS wsclean-lib DESTINATION lib/${DEB_HOST_MULTIARCH})
++install(TARGETS wsclean-shared DESTINATION lib/${DEB_HOST_MULTIARCH})
  install(FILES interface/wscleaninterface.h DESTINATION include)
  
  # add target to generate API documentation with Doxygen
diff --minimal -Nru wsclean-2.6/debian/rules wsclean-2.6/debian/rules
--- wsclean-2.6/debian/rules2018-06-13 13:04:47.0 +0200
+++ wsclean-2.6/debian/rules2019-05-30 09:52:18.0 +0200
@@ -3,7 +3,8 @@
 
 #export DH_VERBOSE=1
 
-CMAKE_FLAGS += -DDEB_BUILD_MULTIARCH=`dpkg-architecture -qDEB_BUILD_MULTIARCH` 
-DPORTABLE=yes
+include /usr/share/dpkg/architecture.mk
+CMAKE_FLAGS += -DDEB_HOST_MULTIARCH=$(DEB_HOST_MULTIARCH) -DPORTABLE=yes
 
 %:
dh $@


Bug#892929: gambas3: Crashes upon start. [20] Bad Argument. Settings.WriteWindow.388

2019-05-30 Thread Gianfranco Costamagna
 Hello, can you please try gambas from unstable/testing or experimental?
thanks   

G.

Il martedì 28 maggio 2019, 16:18:08 CEST, Paul Pscholka 
 ha scritto:  
 
 Package: gambas3
Version: 3.9.1-3
Followup-For: Bug #892929

Dear Maintainer,


  * What led up to the situation?
program comes up but nothing works on "start wizard".  Blocks with full screen
and connot do anything.  Additionally programs I have already compiled  on
version 3.9, before update, will not run.

  * What exactly did you do (or not do) that was effective (or
    ineffective)?

Nothing can be done.  I tried reinstalling gambas, and debian

  * What was the outcome of this action?

no luck

  did anyone even test this program?  I have tools I need to work that rely on
gambas.

Thanks,
Paul




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

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

Versions of packages gambas3 depends on:
ii  gambas3-gb-args            3.9.1-3
ii  gambas3-gb-cairo            3.9.1-3
ii  gambas3-gb-chart            3.9.1-3
ii  gambas3-gb-clipper          3.9.1-3
ii  gambas3-gb-complex          3.9.1-3
ii  gambas3-gb-compress-bzlib2  3.9.1-3
ii  gambas3-gb-compress-zlib    3.9.1-3
ii  gambas3-gb-crypt            3.9.1-3
ii  gambas3-gb-data            3.9.1-3
ii  gambas3-gb-db-form          3.9.1-3
ii  gambas3-gb-db-mysql        3.9.1-3
ii  gambas3-gb-db-odbc          3.9.1-3
ii  gambas3-gb-db-postgresql    3.9.1-3
ii  gambas3-gb-db-sqlite3      3.9.1-3
ii  gambas3-gb-dbus            3.9.1-3
ii  gambas3-gb-desktop          3.9.1-3
ii  gambas3-gb-desktop-gnome    3.9.1-3
ii  gambas3-gb-desktop-x11      3.9.1-3
ii  gambas3-gb-form-dialog      3.9.1-3
ii  gambas3-gb-form-mdi        3.9.1-3
ii  gambas3-gb-form-stock      3.9.1-3
ii  gambas3-gb-form-terminal    3.9.1-3
ii  gambas3-gb-gmp              3.9.1-3
ii  gambas3-gb-gsl              3.9.1-3
ii  gambas3-gb-gui-opengl      3.9.1-3
ii  gambas3-gb-gui-qt          3.9.1-3
ii  gambas3-gb-gui-qt-webkit    3.9.1-3
ii  gambas3-gb-httpd            3.9.1-3
ii  gambas3-gb-image-effect    3.9.1-3
ii  gambas3-gb-image-imlib      3.9.1-3
ii  gambas3-gb-image-io        3.9.1-3
ii  gambas3-gb-inotify          3.9.1-3
ii  gambas3-gb-libxml          3.9.1-3
ii  gambas3-gb-logging          3.9.1-3
ii  gambas3-gb-map              3.9.1-3
ii  gambas3-gb-markdown        3.9.1-3
ii  gambas3-gb-media            3.9.1-3
ii  gambas3-gb-memcached        3.9.1-3
ii  gambas3-gb-mime            3.9.1-3
ii  gambas3-gb-mysql            3.9.1-3
ii  gambas3-gb-ncurses          3.9.1-3
ii  gambas3-gb-net-curl        3.9.1-3
ii  gambas3-gb-net-pop3        3.9.1-3
ii  gambas3-gb-net-smtp        3.9.1-3
ii  gambas3-gb-openal          3.9.1-3
ii  gambas3-gb-opengl-glsl      3.9.1-3
ii  gambas3-gb-opengl-glu      3.9.1-3
ii  gambas3-gb-opengl-sge      3.9.1-3
ii  gambas3-gb-openssl          3.9.1-3
ii  gambas3-gb-option          3.9.1-3
ii  gambas3-gb-pcre            3.9.1-3
ii  gambas3-gb-pdf              3.9.1-3
ii  gambas3-gb-qt5              3.9.1-3
ii  gambas3-gb-qt5-ext          3.9.1-3
ii  gambas3-gb-qt5-webkit      3.9.1-3
ii  gambas3-gb-report          3.9.1-3
ii  gambas3-gb-report2          3.9.1-3
ii  gambas3-gb-scanner          3.9.1-3
ii  gambas3-gb-sdl-sound        3.9.1-3
ii  gambas3-gb-sdl2            3.9.1-3
ii  gambas3-gb-sdl2-audio      3.9.1-3
ii  gambas3-gb-settings        3.9.1-3
ii  gambas3-gb-util            3.9.1-3
ii  gambas3-gb-util-web        3.9.1-3
ii  gambas3-gb-v4l              3.9.1-3
ii  gambas3-gb-vb              3.9.1-3
ii  gambas3-gb-web              3.9.1-3
ii  gambas3-gb-xml-html        3.9.1-3
ii  gambas3-gb-xml-rpc          3.9.1-3
ii  gambas3-gb-xml-xslt        3.9.1-3
ii  gambas3-ide                3.9.1-3
ii  gambas3-templates          3.9.1-3

gambas3 recommends no packages.

gambas3 suggests no packages.

-- no debconf information

  

Bug#924948: unblock: onedrive/2.2.6-2

2019-05-30 Thread Norbert Preining
Dear Niels,

Please remove onedrive from buster.

Thanks

Norbert

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

Bug#929756: Appease systemd-cron by doing "if P;then C;fi" (not "P&") in crontab

2019-05-30 Thread Trent W. Buck
Package: ntpsec
Version: 1.1.3+dfsg1-2
Severity: wishlist
Tags: patch

When using systemd and systemd-cron (instead of ISC vixie cron),
your cron jobs are marked as "failing" by systemd, because
they have non-zero exit status.

This is because you do

test1 && test2 && do something

So if test1 fails, it's a non-zero exit status, and it shows up in "systemctl 
--state=failed", and
"systemctl status" marks the whole system as "degraded".
Also systemd-crond sends an email about it, which vixie cron only does if 
there's stdout/stderr.

The fix is simple:

- test1 && test2 && do something
+ if test1 && test2; then do something; fi

Here's the actual diff on my running system:

diff --git a/cron.d/ntpsec b/cron.d/ntpsec
index fb2a9b4..57054e1 100644
--- a/cron.d/ntpsec
+++ b/cron.d/ntpsec
@@ -1 +1 @@
-25 6 * * * root [ ! -d /run/systemd/system ] && [ -x 
/usr/lib/ntp/rotate-stats ] && /usr/lib/ntp/rotate-stats
+25 6 * * * root if [ ! -d /run/systemd/system ] && [ -x 
/usr/lib/ntp/rotate-stats ]; then /usr/lib/ntp/rotate-stats; fi
diff --git a/cron.d/ntpsec-ntpviz b/cron.d/ntpsec-ntpviz
index d808c81..c217bcc 100644
--- a/cron.d/ntpsec-ntpviz
+++ b/cron.d/ntpsec-ntpviz
@@ -1,4 +1,4 @@
 53 * * * * root if [ ! -d /run/systemd/system ] ; then ntpviz -p 1 -d 
/var/log/ntpsec -o /var/lib/ntpsec/ntpviz/day  @/etc/ntpviz/options 2> 
/dev/null ; find /var/lib/ntpsec/ntpviz/day  -type f -mtime +1 -delete ; fi
 45 11,23 * * * root if [ ! -d /run/systemd/system ] ; then ntpviz -p 7 -d 
/var/log/ntpsec -o /var/lib/ntpsec/ntpviz/week @/etc/ntpviz/options 2> 
/dev/null ; find /var/lib/ntpsec/ntpviz/week -type f -mtime +7 -delete ; fi
-*/5 ** * * root [ ! -d /run/systemd/system ] && [ -e /run/gpsd.sock ] 
&& [ -x /usr/sbin/ntploggps ] && /usr/sbin/ntploggps -o -l /var/log/ntpsec/gpsd 
2> /dev/null
-*/5 ** * * root [ ! -d /run/systemd/system ] && [ -x 
/usr/sbin/ntplogtemp ] && /usr/sbin/ntplogtemp -o -l /var/log/ntpsec/temps
+*/5 ** * * root if [ ! -d /run/systemd/system ] && [ -e /run/gpsd.sock 
] && [ -x /usr/sbin/ntploggps ]; then /usr/sbin/ntploggps -o -l 
/var/log/ntpsec/gpsd 2>/dev/null; fi
+*/5 ** * * root if [ ! -d /run/systemd/system ] && [ -x 
/usr/sbin/ntplogtemp ]; then /usr/sbin/ntplogtemp -o -l /var/log/ntpsec/temps; 
fi



Bug#929752: installation-guide: left quotes in gpl.xml are not correctly rendered in pdf

2019-05-30 Thread Holger Wansing
Control: retitle -1 Replace grave accents/single quotes by  in 
gpl.xml

Samuel Thibault  wrote:
> Hello,
> 
> Changwoo Ryu, le jeu. 30 mai 2019 22:22:05 +0900, a ecrit:
> > In en/appendix/gpl.xml, ordinary double quotes (") and grave accent
> > character (`)
> > are used for left single/double quotes. But they are not correctly
> > rendered in pdf.
> > 
> > See the English PDF at
> > https://www.debian.org/releases/stable/amd64/install.pdf.en.
> > Opening double quotes are rendered as right double quotes. And grave 
> > accents are
> > rendered just as grave accents, not a left single quotes.
> 
> AIUI we should just replace "" and `' in the xml file with
> .

Exactly!

Renaming this bug accordingly.


Holger


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



Bug#922251: live-build: support syslinux-efi as (additional) bootloader

2019-05-30 Thread Matthijs Kooijman
Hi Adrian,

I just updated the MR with the changes I discussed in my previous mail
(and also listed below). My previous mail also contained some responses
and questions, if you have some time to respond to those that would be
great.

> > >>> 3) Remove ldlinux.c32 for extlinux and syslinux (6fc68c1d)
I moved this into its own MR:
https://salsa.debian.org/live-team/live-build/merge_requests/26

> > Well, I think you should use something else.
> > modules32 is 9 characters long (not 8.3 compatible). What about module32
> > and module64? So that we can reuse the code in the iso side when
> > isolinux is updated to support hybrid isos in efi mode ?
> Good point, hadn't considered 8.3 compatibility. Singular "module32"
> sounds a bit weird to me, but it is probably clearer than something like
> "mods32" or even just "c32" (the latter seems reasonable, except that
> the "c64" directory would then still contain ".c32" files since that's
> what 64-bit syslinux-efi also uses...).
I changed to module32 and module64 now (also using module32 for the bios
modules, for consistency).

> > 6.1)
> > PATH syslinux command is still being written in capital letters in
> > share/bootloaders/syslinux-efi/syslia32.cfg and
> > share/bootloaders/syslinux-efi/syslx64.cfg while it should be written in
> > non-capital letters.
> Good catch, will fix that.
Fixed.

Gr.

Matthijs


signature.asc
Description: PGP signature


Bug#929755: gvfs: CVE-2019-12447 CVE-2019-12448 CVE-2019-12449

2019-05-30 Thread Salvatore Bonaccorso
Source: gvfs
Version: 1.38.1-3
Severity: important
Tags: security upstream
Control: found -1 1.30.4-1

Hi,

The following vulnerabilities were published for gvfs.

CVE-2019-12447[0]:
| An issue was discovered in GNOME gvfs 1.29.4 through 1.41.2.
| daemon/gvfsbackendadmin.c mishandles file ownership because setfsuid
| is not used.


CVE-2019-12448[1]:
| An issue was discovered in GNOME gvfs 1.29.4 through 1.41.2.
| daemon/gvfsbackendadmin.c has race conditions because the admin
| backend doesn't implement query_info_on_read/write.


CVE-2019-12449[2]:
| An issue was discovered in GNOME gvfs 1.29.4 through 1.41.2.
| daemon/gvfsbackendadmin.c mishandles a file's user and group ownership
| during move (and copy with G_FILE_COPY_ALL_METADATA) operations from
| admin:// to file:// URIs, because root privileges are unavailable.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-12447
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12447
[1] https://security-tracker.debian.org/tracker/CVE-2019-12448
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12448
[2] https://security-tracker.debian.org/tracker/CVE-2019-12449
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12449

Please adjust the affected versions in the BTS as needed, please do
though check (all versions in Debian should be affected).

Regards,
Salvatore



Bug#925240: graphite-web: on fresh install managr-graphite command return error (missing settings.py file)

2019-05-30 Thread Jason Rhinelander

On Thu, 21 Mar 2019 17:05:23 +0100 Jacek Jaros  wrote:

   Error: Can't find the file 'settings.py' in the directory containing
   '/usr/bin/graphite-manage'. It appears you've customized things.
   You'll have to run django-admin.py, passing it your settings module.
   (If the file settings.py does indeed exist, it's causing an
   ImportError somehow.)



This is happening because /usr/bin/graphite-manage starts off with 
`#!/usr/bin/python2` but the package has migrated to Python3.


Either changing the 2 -> 3 in the executable, or running as `python3 
/usr/bin/graphite-manage` are workarounds until the package gets fixed.



Jason Rhinelander



Bug#929283: zookeeper: CVE-2019-0201: information disclosure vulnerability

2019-05-30 Thread tony mancill
On Mon, May 27, 2019 at 10:07:38PM -0700, tony mancill wrote:
> On Sun, May 26, 2019 at 08:58:29PM +0200, Moritz Mühlenhoff wrote:
> > Looks fine, but can you please also include the test case upstream added?
> > Given that it's quite complex to reconstruct the specific affected ZK setup,
> > we should at least ship/run the test case.
> 
> I will prepare an upload for 3.4.13 in testing/unstable soon - should be
> in the next day or so.

As an update...

Regarding the upload of a patched 3.4.13 for buster and unstable,
cherry-picking and adapting the upstream patch from the 3.4.14 branch is
straight-forward and complete [1].  The package is building, etc.

The delay is that the tests for the Debian package aren't in a state
where they are easy to run.  This predates this issue, going back to the
changes made when netty 3.9 was removed from Debian.  Since the changes
to the packaging and patches to re-enable tests would be extensive (I am
still working through them), I'm not certain that they will be suitable
for an upload during the freeze.  At a minimum, I intend to get them
working locally and push a branch so that others can verify, as well as
run the updated ZK through some local smoke-testing that validates the
ACL change.

Cheers,
tony

[1] 
https://salsa.debian.org/java-team/zookeeper/commit/41265b610149bd708232e40faf945f3c79b60b85


signature.asc
Description: PGP signature


Bug#929754: Restoration failures due to PID increment rates.

2019-05-30 Thread Gong S.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: criu
Version: 3.11-2
Severity: important

How to reproduce:
1. Dump a process with many threads.
2. Reboot.
3. When trying to restore, it fails with "Pid $PID do not match expected $PID".

The problem is that many thing in the OS creates new processes frequently and 
take up the PID desired.
They create new processes every few seconds, and they are too important (or 
simply impossible) to kill.
For example, "systemd-udevd" now frequently ends and spawns child processes 
after an update.
BTRFS also frequently creates kernel threads.
Even worse, CRIU now set the starting point of new PIDs to the restored 
process' PID,
so no matter how many times you try, it will always fail because the next few 
PIDs are quickly taken.
-
Please limit your reply to 7-bit ASCII.
I refuse to see your idiotic emoji in a TTY.
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsBcBAEBCAAGBQJc792pAAoJENi1YDlFXXQfpaQH/1X37GkNBHkgw+96EgEm
ACL+WfEOewF8AF/MYfuTEcsl3xlAyB/X7JcrnnizN/tiqYqlZYf1sQaAv3Vz
F58jJEu/gJdIL/DKEqRTyI06F38fPOnpj1IR1dOUx/uWK5vYTuaxxnDcdtFX
3vypvFxm8M/jH9OdO3YAKxjVgWpyKH2jWjKAnUdiydDZEd0QfGW1sUb1dvUk
aPLu8c+kzs545Q5e7mRLFLEyNsWg9isIKH+txKgrzlTOMnLdX/Bcpa4VjkZd
PQ80yPtMDp7WZrqPw2zFOTQ96O4tJQFE4vuWYfabhYBTovjtXH61LTnN3sZd
Um3dKbwAzcXI8u6kmV79OaY=
=6MUI
-END PGP SIGNATURE-



publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc
Description: application/pgp-keys


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc.sig
Description: PGP signature


Bug#929752: installation-guide: left quotes in gpl.xml are not correctly rendered in pdf

2019-05-30 Thread Samuel Thibault
Hello,

Changwoo Ryu, le jeu. 30 mai 2019 22:22:05 +0900, a ecrit:
> In en/appendix/gpl.xml, ordinary double quotes (") and grave accent
> character (`)
> are used for left single/double quotes. But they are not correctly
> rendered in pdf.
> 
> See the English PDF at
> https://www.debian.org/releases/stable/amd64/install.pdf.en.
> Opening double quotes are rendered as right double quotes. And grave accents 
> are
> rendered just as grave accents, not a left single quotes.

AIUI we should just replace "" and `' in the xml file with
.

Samuel



Bug#929753: glib2.0: CVE-2019-12450

2019-05-30 Thread Salvatore Bonaccorso
Package: glib2.0
Source: glib2.0
Version: 2.58.3-1
Severity: important
Tags: security upstream
Control: found -1 2.50.3-2

Hi,

The following vulnerability was published for glib2.0.

CVE-2019-12450[0]:
| file_copy_fallback in gio/gfile.c in GNOME GLib 2.15.0 through 2.61.1
| does not properly restrict file permissions while a copy operation is
| in progress. Instead, default permissions are used.


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-12450
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12450
[1] 
https://gitlab.gnome.org/GNOME/glib/commit/d8f8f4d637ce43f8699ba94c9b7648beda0ca174

Regards,
Salvatore



Bug#929751: gnome-boxes: Download functionality doesn't work

2019-05-30 Thread Peter De Wachter
Package: gnome-boxes
Version: 3.30.3-2
Severity: important

When creating a new box, gnome-boxes shows the option "Download an
OS". This option doesn't work.

To reproduce:
- Start gnome-boxes, click "New"
- Click "Download an OS"
- Choose a distro, all (other than RHEL) seem to give the same result.
  Some that I tried:
- Debian 9 i686 (netinst)
- Ubuntu 18.10 x86_64
- Fedora 29 Workstation x86_64 (Live)

You get a screen that says:
> Preparing to create a new box
> Downloading media...

It briefly shows a pop-up message:
> Unsupported protocol "file"

After this, nothing seems to happen. Nothing gets downloaded.


-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (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_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=nl_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-boxes depends on:
ii  dconf-gsettings-backend [gsettings-ba  0.30.1-2
ii  libarchive13   3.3.3-4
ii  libc6  2.28-10
ii  libcairo2  1.16.0-4
ii  libfreerdp2-2  2.0.0~git20190204.1.2693389a+dfsg1-1
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libglib2.0-0   2.58.3-1
ii  libgovirt2 0.3.4-3.1
ii  libgtk-3-0 3.24.5-1
ii  libgtk-vnc-2.0-0   0.9.0-1.1
ii  libgudev-1.0-0 232-2
ii  libosinfo-1.0-01.2.0-1
ii  libosinfo-bin  1.2.0-1
ii  libpango-1.0-0 1.42.4-6
ii  librest-0.7-0  0.8.1-1
ii  libsecret-1-0  0.18.7-1
ii  libsoup2.4-1   2.64.2-2
ii  libspice-client-glib-2.0-8 0.35-2
ii  libspice-client-gtk-3.0-5  0.35-2
ii  libtracker-sparql-2.0-02.1.8-2
ii  libusb-1.0-0   2:1.0.22-2
ii  libvirt-daemon 5.0.0-3
ii  libvirt-glib-1.0-0 1.0.0-1
ii  libwebkit2gtk-4.0-37   2.24.2-1
ii  libxml22.9.4+dfsg1-7+b3
ii  mtools 4.0.23-1
ii  tracker2.1.8-2

Versions of packages gnome-boxes recommends:
ii  qemu-system-x86  1:3.1+dfsg-8

gnome-boxes suggests no packages.

-- no debconf information



Bug#924948: unblock: onedrive/2.2.6-2

2019-05-30 Thread Niels Thykier
Norbert Preining:
> Hi Paul,
> 
> On Thu, 30 May 2019, Paul Gevers wrote:
>> On Tue, 19 Mar 2019 07:50:10 +0900 Norbert Preining
> 
> What a time lag for a release related bug, impressive.
> 

Hi Nobert,

I can understand that the delay in the reply is unsatisfying to you  -
personally, I am not happy about such delays either.

However, I find remarks like the above unhelpful and uncalled for at
best - not to mention draining energy- and motivation-wise.  Please keep
future communication professional.

A much better approach would have been to ask us an update (in a
friendly/professional manner) in case we had forgotten about the
request.  This might have gotten you a reply much earlier.

Thanks,
~Niels



Bug#929752: installation-guide: left quotes in gpl.xml are not correctly rendered in pdf

2019-05-30 Thread Changwoo Ryu
Source: installation-guide
Version: 20190323
Severity: normal

In en/appendix/gpl.xml, ordinary double quotes (") and grave accent
character (`)
are used for left single/double quotes. But they are not correctly
rendered in pdf.

See the English PDF at
https://www.debian.org/releases/stable/amd64/install.pdf.en.
Opening double quotes are rendered as right double quotes. And grave accents are
rendered just as grave accents, not a left single quotes.



Bug#929321: unblock: sqlalchemy/1.2.18+ds1-2 (CVE-2019-7164 CVE-2019-7548)

2019-05-30 Thread Mike Bayer



On 5/30/19 5:23 AM, Paul Gevers wrote:

Hi Mike, zigo,

Thanks for your replies,


I very much think it's safer to just allow SQLAchemy to migrate right
now, to fix the potential SQL insertion vulnerability, rather than
waiting for any (potential, but likely rare) issue in the above reverse
dependencies.

I do think a gentle ping to the maintainers of the above packages would
be nice, but probably mass-filling of bugs isn't needed. How can I
easily gather the list of maintainer? Is there a script somewhere to do
this, or should I write it myself (which shouldn't be hard with some
apt-cache show in a loop...)?

Piotr, Mike, is what I wrote above accurate?

I can confirm Openstack is likely OK, most packages are likely OK, and
if a package is not OK, it's a trivial fix for them.

But as long as they are not fixed, how severe do you expect those issues
to be? I suggest to proceed with contacting them, just so maintainers
can check their package if they care.



severe because they will have queries that won't run.





@zigo, if you have the package name, you can contact the maintainers by
sending to @packages.debian.org. I'm not 100% sure if this
only works for source package names.

Paul





Bug#865830: Copyright concerns regarding Seafile

2019-05-30 Thread Ian Jackson
Andrej Shadura writes ("Re: Copyright concerns regarding Seafile"):
> On Wed, 15 May 2019 at 12:10, Moritz Schlarb  wrote:
> I fully agree. Since the client doesn’t include the code in question,
> it’s out of scope of the issue, so there is no reason to remove it
> >from Debian.

I am very uncomfortable with having code in Debian whose upstream
authors appear to have plagiarised some other people's software, and
then obfuscated it, in order to evade copyright licensing.  Who knows
what other misleading practices they have engaged in, or may do in the
future ?

As a project, we do not have the resources to fully audit all the code
we ingest from upstreams and redistribute to our users.  We must rely
on trust.  That depends on the upstream being trustworthy.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Bug#924948: unblock: onedrive/2.2.6-2

2019-05-30 Thread Norbert Preining
Hi Paul,

On Thu, 30 May 2019, Paul Gevers wrote:
> On Tue, 19 Mar 2019 07:50:10 +0900 Norbert Preining

What a time lag for a release related bug, impressive.

> I fear this request hasn't received a response because it is very
> daunting to review (35 files changed, 1565 insertions(+), 747

As far as I remember, there have been other full version upgrades after
that date, but anyway.

> fixes). Hence the I am seriously wondering if it wouldn't be better to
> remove onedrive from buster and make sure the package is in better shape
> during the bullseye cycle. What do you think?

Feel free to do whatever you think is good. I have no particular
opinion. The version that is in buster now is usable, but does not catch
errors in a good way but crashes. Manual syncing should be fine in most
cases, while background sync / monitor mode might be sub-optimal or
crash rather soon.

Best

Norbert

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



Bug#929676: unblock: lintian/2.15.0

2019-05-30 Thread Alexander Wirt
On Thu, 30 May 2019, Chris Lamb wrote:

> Hi Ivo,
> 
> > > Please consider unblocking lintian 2.15.0 for buster (from 2.9.1). This
> > > was specifically requested in #929577 by Mattia Rizzollo:
> > 
> > This really should have been discussed in advance.
> 
> I completely agree. The problems simply did not occur to me as — as
> #929577 implies — it affects infrastructure that I am not involved
> with and thus I was not experiencing any issue.
> 
> >If you want to maintain the correct version ordering between
> > testing and backports, I suggest you don't do any new uploads to backports
> > before you get confirmation that the corresponding version will be accepted 
> > in
> > buster.
> 
> 100% noted.
Just for the record, lintian has an exception for backports. So please upload
whenever you like.  

Alex - Backports ftpmaster


signature.asc
Description: PGP signature


Bug#929750: debhelper: dh_installdocs errs out on non-matching pattern in v10 mode

2019-05-30 Thread Niels Thykier
Control: tags -1 moreinfo

On Thu, 30 May 2019 13:44:27 +0200 Andreas Metzler  wrote:
> Source: debhelper
> Version: 12.1.1
> Severity: normal
> 
> Hello,
> 
> one of the *changes* in v11 mode is the following:
> | The helpers dh_installdocs, dh_installexamples, dh_installinfo, and
> | dh_installman now error out if their config has a pattern that does
> | not match anything or reference a path that does not exist.
> 
> However I see this behavior for dh_installdocs in v10 mode, too:
> -
> (sid)ametzler@argenau:/tmp/GNUTLS/gnutls-3.6.8$ cat debian/compat
> 10
> (sid)ametzler@argenau:/tmp/GNUTLS/gnutls-3.6.8$ cat debian/gnutls-doc.docs
> doc/gnutls.pdf
> (sid)ametzler@argenau:/tmp/GNUTLS/gnutls-3.6.8$ dh_installdocs 
> -O--builddirectory=b4deb --no-act --verbose -pgnutls-doc ; echo $?
> dh_installdocs: Cannot find (any matches for) "doc/gnutls.pdf" (tried in .)
> 
> 2
> -
> 
> I cannot say when this bug was introduced, it might be long-standing.
> 
> cu Andreas
> 
> [...]
> 

Hi Andreas,

The code is working as intended, but I think you have found the
documentation confusing.

 * Suggestions for improving the docs are welcome.

The root issue here is that "doc/gnutls.pdf" is not a pattern (in the
compat 11 sense).  A pattern would be something like "doc/*.pdf".

The "non-pattern" case has been an error since compat 5[1].  Compat 11
extends that to patterns as well (to match dh_install, where this has
been an error since compat 5 as well).


Thanks,
~Niels

[1] Note: debhelper did have a regression at some point for an extended
period of time where non-patterns did not trigger errors as intended -
though the fix for that regression is not recent (fixed during
debhelper/11 AFAIR), so I doubt it is related to this bug.



Bug#929750: debhelper: dh_installdocs errs out on non-matching pattern in v10 mode

2019-05-30 Thread Andreas Metzler
Source: debhelper
Version: 12.1.1
Severity: normal

Hello,

one of the *changes* in v11 mode is the following:
| The helpers dh_installdocs, dh_installexamples, dh_installinfo, and
| dh_installman now error out if their config has a pattern that does
| not match anything or reference a path that does not exist.

However I see this behavior for dh_installdocs in v10 mode, too:
-
(sid)ametzler@argenau:/tmp/GNUTLS/gnutls-3.6.8$ cat debian/compat
10
(sid)ametzler@argenau:/tmp/GNUTLS/gnutls-3.6.8$ cat debian/gnutls-doc.docs
doc/gnutls.pdf
(sid)ametzler@argenau:/tmp/GNUTLS/gnutls-3.6.8$ dh_installdocs 
-O--builddirectory=b4deb --no-act --verbose -pgnutls-doc ; echo $?
dh_installdocs: Cannot find (any matches for) "doc/gnutls.pdf" (tried in .)

2
-

I cannot say when this bug was introduced, it might be long-standing.

cu Andreas

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

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



Bug#929676: unblock: lintian/2.15.0

2019-05-30 Thread Chris Lamb
Hi Ivo,

> > Please consider unblocking lintian 2.15.0 for buster (from 2.9.1). This
> > was specifically requested in #929577 by Mattia Rizzollo:
> 
> This really should have been discussed in advance.

I completely agree. The problems simply did not occur to me as — as
#929577 implies — it affects infrastructure that I am not involved
with and thus I was not experiencing any issue.

>If you want to maintain the correct version ordering between
> testing and backports, I suggest you don't do any new uploads to backports
> before you get confirmation that the corresponding version will be accepted in
> buster.

100% noted.


Best wishes,

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



Bug#927856: unblock: python-jwcrypto/0.6.0-1

2019-05-30 Thread Timo Aaltonen
On 30.5.2019 10.59, Paul Gevers wrote:
> Control: tags -1 moreinfo
> 
> Hi Timo,
> 
> On Wed, 24 Apr 2019 11:06:36 +0300 Timo Aaltonen 
> wrote:
>> Please unblock package python-jwcrypto
>>
>> The new upstream release is needed to fix:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925457
> 
> Can't we have a targeted fix for that issue? New upstream releases are
> typically not appropriate at this stage of the release. If not, I expect
> we'll just let the package be autoremoved from buster.
> 
> Paul
> 

Hi, I don't know how much would have to be backported, but it's probably
better to just unblock freeipa 4.7.2-3 instead, because python-jwcrypto
is a dep of freeipa-server (which isn't built on sid/buster). That way
current client-only freeipa would remain on buster. Custodia is another
package which depends on -jwcrypto, but it's again a server thing so can
be removed from buster.

-- 
t



Bug#926731: (no subject)

2019-05-30 Thread Marcin Kulisz
If you're still interested in maintaining urlscan in Debian and are looking for
sponsor I think I can help with this, If you could also point me to from where I
could grab your packaging work, it'd be great.

I'm a bit busy lately and don't have much time but would like to see urlscan
better maintained so I'll try to help you with it.



Bug#929263: cloud.debian.org: /usr/sbin not in default $PATH

2019-05-30 Thread Emmanuel Kasper
> 
> At this point, I think it'd be worth revisiting, at the project level,
> the historical tradition of leaving the sbin directories out of non-root
> paths. Setting aside all the single user desktop and laptop systems,
> there are enough alternative ways to grant restricted root (file ACLs,
> etc), and to run in alternate filesystem namespaces (e.g.  containers),
> that the functional distinctions that lead to the original directory
> split are probably applicable in a minority of situations these days.


I also agree we could here revisit the unix tradition ( which btw is not
such a strong one anymore CentOS, and the BSDs have /usr/sbin and /sbin
in path)

However I also I agree that it should be done at the project level, not
in the vagrant box or cloud image , so I will reassign this to the
general pseudo-package.



Bug#929666: ITP: conmon -- An OCI container runtime monitor

2019-05-30 Thread Birger Schacht
Hi Reinhard,

On 5/29/19 3:07 PM, Reinhard Tartler wrote:
> On Tue, May 28, 2019 at 2:18 PM Birger Schacht 
> wrote:
>> I maintain the source package on
>> https://salsa.debian.org/bisco-guest/conmon - but conmon is not a golang
>> project, it is C. But if there is another team that package fits, I'd be
>> happy to team maintain ;)
>>
> 
> Thanks for the clarification.
> 
> I notice that you chose a packaging style that does not include
> the upstream sources, which is not my personal preference.
Actually the current upstream source is in the upstream/0.2.0 tag- gbp
buildpackage looks there for the upstream sources.
Is it not possible to use dgit with having upstream sources in a
separate branch?

> Any chance to convince you to use a style that makes it possible
> to use dgit(1)? If so, I'd be happy to help you with moving this
> package to the "debian" namespace (formerly known as collab-maint)
> which provides access to a audience and thus makes collaboration
> easier, and to sponsor uploads as necessary.
Well, I  like having the upstream sources and the debian/ directory
separated from another, but if it makes it easier for you I can merge
the upstream/0.2.0 tag into master.

Other than that there is only
https://github.com/containers/conmon/issues/30 that keeps the package
from being uploaded.

cheers,
Birger



Bug#920591: lambda-align2: please make the build reproducible

2019-05-30 Thread Chris Lamb
found 920591 2.0.0-5
tags 920591 - patch
thanks

> […]

Unfortunately the package remains unreproducible; I think this patch
was incomplete or is incorrect. (See attached.)


Regards,

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


lambda-align2_2.0.0-5.diffoscope.txt.gz
Description: application/gzip


Bug#928044: libwebkit2gtk-4.0-37: version 2.24.1-1 does not play some streams

2019-05-30 Thread richard lucassen
On Thu, 30 May 2019 11:28:54 +0200
Alberto Garcia  wrote:

> On Wed, May 29, 2019 at 09:37:52AM +0200, Richard Lucassen wrote:
> 
> > I reopen this bug (sorry). 3 issues:
> 
> Hi, thanks for the information. Do you mind to file a new bug?
> 
> I'm going to open a new one upstream for these new problems and I'd
> like to keep it also separate in Debian.

Done:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929749

-- 
richard lucassen
http://contact.xaq.nl/



Bug#929749: libwebkit2gtk-4.0-37: version 2.24.2-1 does not play some streams

2019-05-30 Thread Richard Lucassen
Package: libwebkit2gtk-4.0-37
Version: 2.24.0-1
Severity: normal

Dear Maintainer,

I appended this bug to 928044, but Alberto asked me to open a new report. In 
the meantime I installed the unstable version 2.24.2-1, but the problems remain 
the same as in the testing version 2.24.1-1. Bug verified on three different 
computers, all Debian testing amd64.

3 issues:

-

A) There is a significant difference between the time it takes to open
an HLS stream between the versions 2.24.1-1/2.24.2-1 and 2.24.0-1:

1) Go to http://radio.dos.nl/

2) Go to settings (drop down in right top corner)

3) Click "Choose protocol" until it shows HLS

4) Click on arrow (back to radio)

5) Click on "Page menu" (bottom left corner) and choose "news"

6) switch between the BBC stations (they're all HLS)

(check the Info button on the left top corner, at the bottom of the
info page there is the protocol that is used, it should show "HLS")

2.24.0 takes only tenths of a second (switches almost immediately),
2.24.1/2.24.2 takes several seconds. This is an issue that shows up with HLS
stations. 2.24.0 switches much faster anyway.

-

B) There is one station that does not play at all:

1) Click on "Page menu" (bottom left corner) and choose "jazz"

2) Choose Bert's Bytes.

Version 2.24.0 plays it, 2.24.1/2.24.2 does not. This is a simple seekable mp3.

-

C) Last but certainly not least: switching too fast between two HLS
stations (e.g. 5 Live and BBC Worldservice) makes the whole beast hang.
No way anymore to switch between stations. Note: I use a Debian
unmodified version of the "surf" webbrowser to play these stations. I
need to stop "surf" in order to make it work again.

-

Downgrading to 2.24.0 definitely resolves these issues.

R.

-- 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=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: sysvinit (via /sbin/init)

Versions of packages libwebkit2gtk-4.0-37 depends on:
ii  libatk1.0-0 2.30.0-2
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libegl1 1.1.0-1
ii  libenchant1c2a  1.6.0-11.1+b1
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-3
ii  libgcc1 1:8.3.0-6
ii  libgcrypt20 1.8.4-5
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libgl1  1.1.0-1
ii  libglib2.0-02.58.3-1
ii  libgstreamer-gl1.0-01.14.4-1
ii  libgstreamer-plugins-base1.0-0  1.14.4-1
ii  libgstreamer1.0-0   1.14.4-1
ii  libgtk-3-0  3.24.5-1
ii  libharfbuzz-icu02.3.1-1
ii  libharfbuzz0b   2.3.1-1
ii  libhyphen0  2.8.8-7
ii  libicu6363.1-6
hi  libjavascriptcoregtk-4.0-18 2.24.0-1
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  libnotify4  0.7.7-4
ii  libopenjp2-72.3.0-2
ii  libpango-1.0-0  1.42.4-6
ii  libpng16-16 1.6.36-5
ii  libsecret-1-0   0.18.7-1
ii  libsoup2.4-12.64.2-2
ii  libsqlite3-03.27.2-2
ii  libstdc++6  8.3.0-6
ii  libtasn1-6  4.13-3
ii  libwayland-client0  1.16.0-1
ii  libwayland-egl1 1.16.0-1
ii  libwayland-server0  1.16.0-1
ii  libwebp60.6.1-2
ii  libwebpdemux2   0.6.1-2
ii  libwoff11.0.2-1
ii  libx11-62:1.6.7-1
ii  libxcomposite1  1:0.4.4-2
ii  libxdamage1 1:1.1.4-3+b3
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libxslt1.1  1.1.32-2
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages libwebkit2gtk-4.0-37 recommends:
ii  gstreamer1.0-alsa  1.14.4-1
ii  gstreamer1.0-gl1.14.4-1
ii  gstreamer1.0-plugins-good  1.14.4-1
ii  libgl1-mesa-dri18.3.4-2

Versions of packages libwebkit2gtk-4.0-37 suggests:
pn  libwebkit2gtk-4.0-37-gtk2  

-- no debconf information



Bug#929692: RFP: iwlwifi-dkms -- iwlwifi driver backport in DKMS format

2019-05-30 Thread Anthony Wong
Which git tree and branch do you take it from? If it is
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git
then
the package name is better called backport-iwlwifi-dkms or
iwlwifi-backport-dkms to make the package name clear in reflecting what it
does.

Thanks,
Anthony


Bug#928381: unblock: stunnel4/3:5.54~b3-1

2019-05-30 Thread Peter Pentchev
On Thu, May 30, 2019 at 11:08:02AM +0200, Paul Gevers wrote:
> tags 928381 wontfix
> thanks
> 
> Hi Peter,
> 
> On Fri, 3 May 2019 13:48:43 +0300 Peter Pentchev  wrote:
> > I am aware that new upstream versions are not usually allowed in during
> > a release freeze; however, the upstream author has said that the changes
> > in the stunnel internal operation to fix the thread interlock problem
> > are too extensive to be easily backported :(
> 
> We're too uncomfortable with all the changes (they are too big to
> properly review). I recognize that the bug isn't pretty, but introducing
> new ones at this stage is even less so (that's why we have the freeze).

Thanks for considering this and for the reply; I cannot say that
I didn't expect such a resolution at all.

Just for my information, is there a chance that this upgrade could be
allowed later on during the buster lifecycle as a stable update?

Thanks for everything you are doing for Debian!

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature


Bug#928044: libwebkit2gtk-4.0-37: version 2.24.1-1 does not play some streams

2019-05-30 Thread Alberto Garcia
On Wed, May 29, 2019 at 09:37:52AM +0200, Richard Lucassen wrote:

> I reopen this bug (sorry). 3 issues:

Hi, thanks for the information. Do you mind to file a new bug?

I'm going to open a new one upstream for these new problems and I'd
like to keep it also separate in Debian.

Thanks!

Berto



Bug#929321: unblock: sqlalchemy/1.2.18+ds1-2 (CVE-2019-7164 CVE-2019-7548)

2019-05-30 Thread Paul Gevers
Hi Mike, zigo,

Thanks for your replies,

>> I very much think it's safer to just allow SQLAchemy to migrate right
>> now, to fix the potential SQL insertion vulnerability, rather than
>> waiting for any (potential, but likely rare) issue in the above reverse
>> dependencies.
>>
>> I do think a gentle ping to the maintainers of the above packages would
>> be nice, but probably mass-filling of bugs isn't needed. How can I
>> easily gather the list of maintainer? Is there a script somewhere to do
>> this, or should I write it myself (which shouldn't be hard with some
>> apt-cache show in a loop...)?
>>
>> Piotr, Mike, is what I wrote above accurate?
> 
> I can confirm Openstack is likely OK, most packages are likely OK, and
> if a package is not OK, it's a trivial fix for them.

But as long as they are not fixed, how severe do you expect those issues
to be? I suggest to proceed with contacting them, just so maintainers
can check their package if they care.

@zigo, if you have the package name, you can contact the maintainers by
sending to @packages.debian.org. I'm not 100% sure if this
only works for source package names.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#920595: ukui-themes: please make the build reproducible

2019-05-30 Thread 李剑峰
Hi, Chris Lamb,


Sorry for the late reply and thanks for your work! I have merged your patch and 
now the new version is waiting for sponsorship in mentors:

https://mentors.debian.net/package/ukui-themes


Regards,
handsome_feng






Bug#929748: mxml: VCS unavailable

2019-05-30 Thread Paolo Greppi

Source: mxml
Severity: normal

Dear Maintainer,

the VCS link reported in debian/control file:
https://salsa.debian.org/mckinstry/mxml.git
is broken. Please reinstate it.

Paolo

-- 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/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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



Bug#929747: qa.debian.org: Please add cross-buildability in summary

2019-05-30 Thread Samuel Thibault
Package: qa.debian.org
Severity: normal

Hello,

https://tracker.debian.org/ has a link to the cross-buildability status
of a package. It'd be useful to have a tick or cross on the
https://qa.debian.org/developer.php page, e.g. in the CI/Rep column, as
a link to the cross-buildability status, to be able to easily check the
status of one's own packages.

Samuel

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

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

-- 
Samuel
 FYLG> Tiens, vlà une URL qui va bien :
 FYLG> ftp://127.0.0.1/WaReZ/NiouZeS/WinDoZe/NeWSMoNGeR/SuPeR
 c'est gentil sauf que l'adresse ne fonctionne pas sa me fais une erreur
 -+- Furtif in Guide du Neuneu Usenet :  -+-



Bug#868164: systemd: fakeraid + cryptsetup (root) + lvm results in 90s time out waiting for device at boot

2019-05-30 Thread Sergey Belyashov
Please ignore information about start of debian9 before /var mount in my
previous message. It was caused by strange config possibly kept from
Jessie (/etc/systemd/system/bind9.service.d/override.conf). After removing
it, bind starts after /var mount.

Best regards,
Sergey Belyashov


Bug#924948: unblock: onedrive/2.2.6-2

2019-05-30 Thread Paul Gevers
Control: tags -1 moreinfo

Hi Norbert,

On Tue, 19 Mar 2019 07:50:10 +0900 Norbert Preining
 wrote:
> I am asking to unblock onedrive 2.2.6-2 for buster. This is a new
> upstream release that fixes a considerable amount of (critical) bugs,
> most of which not reported in Debian, but still present. Here are the
> release notes from the CHANGELOG.md file:
> 
> ## 2.2.6 - 2019-03-12
> ### Fixed
> *   Resolve application crash when unable to delete remote folders when 
> business retention policies are enabled
> *   Resolve deprecation warning: loop index implicitly converted from size_t 
> to int
> *   Resolve warnings regarding 'bashisms'
> *   Resolve handling of notification failure is dbus server has not started 
> or available
> *   Resolve handling of response JSON to ensure that 'id' key element is 
> always checked for
> *   Resolve excessive & needless logging in monitor mode
> *   Resolve compiling with LDC on Alpine as musl lacks some standard 
> interfaces
> *   Resolve notification issues when offline and cannot act on changes
> *   Resolve Docker entrypoint.sh to accept command line arguments
> *   Resolve to create a new upload session on reinit
> *   Resolve where on OneDrive query failure, default root and drive id is 
> used if a response is not returned
> *   Resolve Key not found: nextExpectedRanges when attempting session uploads 
> and incorrect response is returned
> *   Resolve application crash when re-using an authentication URI twice after 
> previous --logout
> *   Resolve creating a folder on a shared personal folder appears successful 
> but returns a JSON error
> *   Resolve to treat mv of new file as upload of mv target
> *   Update Debian i386 build dependencies
> *   Update handling of --get-O365-drive-id to print out all 'site names' that 
> match the explicit search entry rather than just the last match
> *   Update Docker readme & documentation
> *   Update handling of validating local file permissions for new file uploads
> ### Added
> *   Add support for install & uninstall on RHEL / CentOS 6.x
> *   Add support for when notifications are enabled, display the number of 
> OneDrive changes to process if any are found
> *   Add 'config' option 'min_notif_changes' for minimum number of changes to 
> notify on, default = 5
> *   Add additional Docker container builds utilising a smaller OS footprint
> *   Add configurable interval of logging in monitor mode
> *   Implement new CLI option --skip-dot-files to skip .files and .folders if 
> option is used
> *   Implement new CLI option --check-for-nosync to ignore folder when special 
> file (.nosync) present
> *   Implement new CLI option --dry-run
> 
> 
> The Debian related diffs are trivial, see attached debdiff, where I
> excluded the actual code changes in the onedrive sources.
> 
> Having 2.2.5 with all the hitherto found bugs in buster would be
> unfortunate.

I fear this request hasn't received a response because it is very
daunting to review (35 files changed, 1565 insertions(+), 747
deletions(-)) and it doesn't comply with the freeze policy (targeted
fixes). Hence the I am seriously wondering if it wouldn't be better to
remove onedrive from buster and make sure the package is in better shape
during the bullseye cycle. What do you think?

Paul



signature.asc
Description: OpenPGP digital signature


Bug#926966: RFA: vim-lastplace

2019-05-30 Thread David Rabel
Hello Yue Lan,

since you are already in touch with James, could you ask him, if he is
willing to sponsor the package?

I have not much time right now and never worked with dh-vim-addon before.

He can also give you access to [0] repo.

Yours
  David

[0] https://salsa.debian.org/vim-team/vim-lastplace


On 5/29/19 3:31 AM, Yue Lan wrote:
> Hello, David.
> 
> 
> I've forked vim-lastplace and create a new branch using dh-vim-addon for
> package-rebuilding[0].
> 
> With James' help[1], I fixed some problem.
> 
> Could you please help me check it out again?
> 
> 
> Yours
> 
>     Yue Lan
> 
> 
> [0]
> https://salsa.debian.org/larue-guest/vim-lastplace/tree/with-dh-vim-addon
> 
> [1] https://salsa.debian.org/vim-team/vim-debian/issues/2
> 
> 
> 

-- 
⚑ libertⒶd ⚑



signature.asc
Description: OpenPGP digital signature


Bug#928175: Could be related?

2019-05-30 Thread Jochen Pawletta
Hello

I just upgraded from Jessie to Stretch 2 days ago and have the
following problem which could be related:

May 30 06:31:46 anton procmail[29067]: Renamed bogus "/var/mail/andrea" into 
"/var/mail/BOGUS.andrea.Lhj1"
May 30 07:24:42 anton procmail[5147]: Renamed bogus "/var/mail/markes" into 
"/var/mail/BOGUS.markes.lej1"
May 30 08:04:21 anton procmail[11334]: Renamed bogus "/var/mail/robert" into 
"/var/mail/BOGUS.robert.1ej1"

There was no such problem before the upgrade.

postfix3.1.12-0+deb9u1
procmail   3.22-25+deb9u1


Jochen

-- 
ZX81 - C64 - Amiga - x86-Linux - iMac (OS X)



Bug#927856: unblock: python-jwcrypto/0.6.0-1

2019-05-30 Thread Paul Gevers
Control: tags -1 moreinfo

Hi Timo,

On Wed, 24 Apr 2019 11:06:36 +0300 Timo Aaltonen 
wrote:
> Please unblock package python-jwcrypto
> 
> The new upstream release is needed to fix:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925457

Can't we have a targeted fix for that issue? New upstream releases are
typically not appropriate at this stage of the release. If not, I expect
we'll just let the package be autoremoved from buster.

Paul



Bug#929108: unblock: gmsh/4.1.5+really4.1.3+ds1-1

2019-05-30 Thread Ansgar
Control: tags -1 - moreinfo
Control: retitle -1 unblock: gmsh/4.1.5+really4.1.3+ds1-1

Ivo De Decker writes:
> On Fri, May 17, 2019 at 11:12:59AM +0200, Ansgar Burchardt wrote:
>> Do you prefer an upload via t-p-u or should I prepare a gmsh
>> 4.1.5+really4.1.3+ds1-1 upload for unstable?
>
> An upload to unstable would be preferred. So please go ahead with that and
> remove the moreinfo tag from this bug once it is in unstable.

gmsh_4.1.5+really4.1.3+ds1-1 was uploaded to unstable yesterday.

Ansgar



Bug#929746: tasksel: Tasks should not recommend dummy transitional packages

2019-05-30 Thread Daniel Lewart
Package: tasksel
Version: 3.53
Severity: normal
Tags: patch

Debian Install System Team,

Weekly Live Builds:
https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/
include the following packages:
  1) aspell-eu-es
Depends: aspell-eu
Description-en: transitional dummy package to aspell-eu
  2) hunspell-gl-es
Depends: hunspell-gl
Description-en: Galician dictionary for hunspell - dummy transitional
  3) hunspell-sv-se
Depends: hunspell-sv
Description-en: Swedish dictionary for hunspell - dummy transitional

Currently:
task-basque   recommends aspell-eu-es
task-galician-desktop recommends hunspell-gl-es
task-swedish-desktop  recommends hunspell-sv-se

Tasks should not recommend dummy transitional packages.

I believe thay should be:
task-basque   recommends aspell-eu
task-galician-desktop recommends hunspell-gl
task-swedish-desktop  recommends hunspell-sv

The **untested** patch below should fix these.

Thank you!
Dan

*** tasksel.diff
diff -ru a/debian/control b/debian/control
--- a/debian/control2019-05-22 22:59:28.0 -0500
+++ b/debian/control2019-05-30 00:00:00.0 -0500
@@ -445,7 +445,7 @@
  to help Basque speaking people use Debian.
 Depends: ${misc:Depends},
 Recommends:
-   aspell-eu-es
+   aspell-eu
 
 Package: task-basque-desktop
 Architecture: all
@@ -1047,7 +1047,7 @@
libreoffice-l10n-gl,
libreoffice-help-gl,
firefox-esr-l10n-gl | firefox-l10n-gl,
-   hunspell-gl-es,
+   hunspell-gl
 
 Package: task-galician-kde-desktop
 Architecture: all
@@ -2155,7 +2155,7 @@
libreoffice-l10n-sv,
libreoffice-help-sv,
firefox-esr-l10n-sv-se | firefox-l10n-sv-se,
-   hunspell-sv-se
+   hunspell-sv
 
 Package: task-swedish-kde-desktop
 Architecture: all



Bug#926180: scilab: FTBFS on all

2019-05-30 Thread Rebecca N. Palmer
Some further searching suggests that Java triggers and catches SIGSEGVs 
as part of normal operation, and hence is expected to not work under gdb 
without "handle SIGSEGV nostop pass".  With this, both 6.0.1 and 6.0.2 
don't crash in gdb, i.e. the crash in gdb probably isn't this bug.


This suggests that the bug could be a subtle kind of baseline violation: 
some assumption that fails on Valgrind's and qemu's emulated CPUs and 
very old real CPUs.  (As noted above, 6.0.2 does crash in Valgrind.)


It also still could be memory corruption that happens not to trigger on 
recent real CPUs, or that is in a code path only used on older CPUs.


I haven't investigated how Ubuntu's 6.0.2 packaging differs from the 
failed attempt at 6.0.2 reported above, or whether it fixes any of our 
other bugs.  However, as the freeze rules do not allow it by default, I 
suggest not uploading it to unstable without asking release team *first*.




Bug#929603: unblock: webkit2gtk/2.24.2-1

2019-05-30 Thread Moritz Muehlenhoff
On Thu, May 30, 2019 at 08:42:42AM +0200, Paul Gevers wrote:
> Control: tags -1 moreinfo
> 
> Hi Alberto,
> 
> On Sun, 26 May 2019 23:08:03 +0200 Alberto Garcia  wrote:
> > Please unblock package webkit2gtk
> > 
> > The new upstream stable release contains (among others) fixes
> > for these three security bugs: CVE-2019-8595, CVE-2019-8607 and
> > CVE-2019-8615.
> 
> Just to get it clear, the security support of webkit2gtk in buster will
> be done by following upstream releases? Does this involve specific
> stable release branches? And this upload/unblock is the same what the
> security team would accept if we would already have released?

Yep, that's the case.

Cheers,
Moritz



Bug#926182: Patch: Use alternatives system for guile-2.2-dev binaries

2019-05-30 Thread Rob Browning
Rob Browning  writes:

> Yep -- I'm not sure yet, but I may lean toward providing:
>
>   bin/guile -> ./guile-2.2  # or whatever the selected alternative is
>   bin/guild -> ./guild-2.2  # or whatever the selected alternative is

OK, I think I'll have an upload this weekend using the built in
./configure --program-suffix support.  That produces a nearly identical
install tree (though I'll need to double check the debs), excepting
changes that should solve our problems, i.e. it installs:

  debian/tmp/usr/bin/guild-2.2
  debian/tmp/usr/bin/guile-tools-2.2 -> guild-2.2
  debian/tmp/usr/bin/guile-config-2.2
  debian/tmp/usr/bin/guile-snarf-2.2
  debian/tmp/usr/bin/guile-2.2

And then we can just move guile-2.2 to its current location and add the
guile-dev postinst/prerm to handle alternatives for the rest.

As pointed out, since we don't allow more than one version of the dev
package to be installed, the utilities can stay in /usr/bin for now.

The --program-suffix also arranges for the scripts to refer to their
corresponding guile-X.Y, which should fix the other potential problem
mentioned.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4



Bug#855092: beets: FTBFS randomly (failing tests)

2019-05-30 Thread Carl Suster

Hi,

I'm an upstream contributor to beets and I was looking into the failures 
you're seeing here. I'm interested in making these tests reliable.


I tried to build the package on my (sid) laptop using sbuild and the 
latest packaging repo from salsa. I'm not able to reproduce these test 
failures. If I remove the Debian patches disabling tests, I'm still not 
able to reproduce any of the failures that led you to add those patches 
in the first case. I'm seeing three categories of tests here:


  1) The test in skip-broken-test. If the failure you're seeing is the 
same error on the GitHub issue you mention in that patch 
('musicbrainz.host'), then my suspicion is that when running the test 
beets is unable to find/read the file beets/config_default.yaml. One way 
this can happen is if beets is being invoked as a zipped egg rather than 
unpacked source (unsupported). Otherwise it might be that the build 
environment has paths set in an unusual way that interferes with beets' 
mechanism to find that YAML file relative to the invoked module.


  2) There are two tests failing due to filesystem access 
(test_no_write_permission and test_add_tags). Maybe we can do a better 
job of mocking here so that the actual filesystem isn't being tested. 
I'll take a look.


  3) The two test_import_task_created* tests exercise a feature based 
on a coroutine implementation (beets.util.pipeline), so I wonder if 
that's related? It's the only unusual thing I can think of off-hand. I 
know that the Debian build infrastructure is a little unusual, but I'm 
not sure what specifically the difference could be here.


If you can help point me in the right direction to reproduce these 
issues that would be appreciated.


Cheers,
Carl



Bug#929603: unblock: webkit2gtk/2.24.2-1

2019-05-30 Thread Paul Gevers
Control: tags -1 moreinfo

Hi Alberto,

On Sun, 26 May 2019 23:08:03 +0200 Alberto Garcia  wrote:
> Please unblock package webkit2gtk
> 
> The new upstream stable release contains (among others) fixes
> for these three security bugs: CVE-2019-8595, CVE-2019-8607 and
> CVE-2019-8615.

Just to get it clear, the security support of webkit2gtk in buster will
be done by following upstream releases? Does this involve specific
stable release branches? And this upload/unblock is the same what the
security team would accept if we would already have released?

If your response is in line with my understanding (or obviously
otherwise satisfactory) I'll unblock it.

Paul



signature.asc
Description: OpenPGP digital signature