Bug#933250: u-boot-imx: booting via grubarm.efi fails

[Heinrich Schuchardt]

Package: u-boot-imx
Version: 2019.01+dfsg-7
Severity: normal
Tags: patch

Dear Vagrant,

booting via GRUB fails on the Wandboard. The problem stems from caches
with incorrect content.

A patch is available at

efi_loader: re-enable GRUB workaround on 32bit ARM
https://patchwork.ozlabs.org/patch/1137733/

Non i.MX6 system will also be struck by the problem.

Best regards

Heinrich


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

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

-- no debconf information


[0.00] Internal error: Oops: 5 [#1] SMP ARM
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.55-armmp #10
[0.00] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[0.00] PC is at fdt_check_header+0xc/0x80
[0.00] LR is at __unflatten_device_tree+0x4c/0x274
[0.00] pc : []lr : []psr: 20d3
[0.00] sp : c1201ec0  ip : c1201ed0  fp : c1201ecc
[0.00] r10: c1316340  r9 :   r8 : c135e308
[0.00] r7 :   r6 : 6fd0  r5 : c1074be8  r4 : c1074be8
[0.00] r3 : c1074be8  r2 : c135e308  r1 :   r0 : 6fd0
[0.00] Flags: nzCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM
Segment none
[0.00] Control: 10c5387d  Table: 6820404a  DAC: 0051
[0.00] Process swapper (pid: 0, stack limit = 0x(ptrval))
[0.00] Stack: (0xc1201ec0 to 0xc1202000)
[0.00] 1ec0: c1201efc c1201ed0 c09696dc c0ae9d48 c1074be8
c1074be8 c1209900 8fff
[0.00] 1ee0: 8ff75000 c1349838 e7fffe00 c1316340 c1201f1c
c1201f00 c1075f0c c096969c
[0.00] 1f00:  c1201f10 c0358230 c1082f34 c1201fa4
c1201f20 c1004a38 c1075ed4
[0.00] 1f20:  10c5387d c03bcd50 c03bc83c c0d61908
c0d6349c c1205dcc c1201fbc
[0.00] 1f40: c0e340c8 f000 c1201fa4 c1201f58 c1022158
c0af8b54 c1205dcc c1205dcc
[0.00] 1f60: c1205dcc  c1201f94 c1201f78 c03bd0c8
 c1201f9c 
[0.00] 1f80: c1205dcc c1205dcc  c1205dc0 412fc09a
10c5387d c1201ff4 c1201fa8
[0.00] 1fa0: c1000c2c c10040f8   
  c1091e40
[0.00] 1fc0:    c1000330 0051
10c0387d  17d0
[0.00] 1fe0: 412fc09a 10c5387d  c1201ff8 
c1000bbc  
[0.00] [] (fdt_check_header) from []
(__unflatten_device_tree+0x4c/0x274)
[0.00] [] (__unflatten_device_tree) from []
(unflatten_device_tree+0x44/0x54)
[0.00] [] (unflatten_device_tree) from []
(setup_arch+0x94c/0xd88)
[0.00] [] (setup_arch) from []
(start_kernel+0x7c/0x504)
[0.00] [] (start_kernel) from [<>] (  (null))
[0.00] Code: e89da800 e1a0c00d e92dd800 e24cb004 (e5903000)
[0.00] random: get_random_bytes called from
print_oops_end_marker+0x34/0x5c with crng_init=0
[0.00] ---[ end trace  ]---
[0.00] Kernel panic - not syncing: Attempted to kill the idle task!
[0.00] ---[ end Kernel panic - not syncing: Attempted to kill
the idle task! ]---

Bug#785381: ax25-tools: AX25-tools : unable to use kissattach with 6PACK option.

[Thomas Osterried]

Hello Ugo,

what you described sounds like a kernel bug.
ax25-apps/-tools, here kissattach, does the system calls for the kernel to 
bring up an interface.
The userspace tools configure the interface (call, ip address), and that's all. 
kissattach's only job is to keep the interface up; it does zero I/O, and the 
userspace utilities have no idea about what is IPv4.

Handling IP packets for interfaces is the kernel's job.


Just tested it on a debian jessie at our repeater:
  Linux db0blo-pr 4.9.0-6-686 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) i686 
GNU/Linux


Here, the kernel behaves correctly, on kiss and on 6pack interfaces. I pinged 
from a router outside to the IP address of the interface.

=> It was a kernel bug that has been fixed some time ago.


vy 73,
- Thomas  dl9sau


On Fri, 15 May 2015 15:51:55 +0200 Ugo Poddine  wrote:
> Package: ax25-tools
> Version: 0.0.10-rc2+cvs20120204-4
> Severity: normal
> Justification: renders package unusable (6PACK) mode
> 
> Dear Maintainer,
> 
> trying to establish an AX25 interface using 6PACK in place of kiss, using 
> kissattch -6 option, the interface sp0 is created and activated.
> The interface answers to a self ping (that means : pinging from the same 
> machine to the iface IP is ok), pinging the same interface from any other 
> machine it's impossible.
> Pinging from the sp0 interface gives "host unreachable" error also if the 
> other ip address is alive.
> Please consider :
> 
> a) that I have skipped any radio software simply using virtualized serial 
> lines (VirtualBox) or SOCAT pipes.
> b) that exactly the same testbed (same machines, same scripts, same address, 
> same routing) runs correctly if I don't use the -6 option
> 
> Please consider also that, differently from the ax0 interface, the sp0 one 
> doesn't show the broadcast address in IPCONFIG (it shows it in IP ADDR)
> 
> Please take also into consideration :
> 
> 1) that the same happens on Fedora21
> 2) that doing the same from a Debian Wheezy system always generates a Kernel 
> crash (!!) when pinging an "ax25" address from the sp0 interface.
> 
> Please let me know if you need further details, but in any case the problem 
> is easily replicable.
> 
> Thank-you for your support, regards
> 73 Ugo
> 
> 
> 
> 
> -- System Information:
> Debian Release: 8.0
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 3.16.0-4-586
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages ax25-tools depends on:
> ii  libax25  0.0.12-rc2+cvs20120204-3
> ii  libc62.19-18
> ii  zlib1g   1:1.2.8.dfsg-2+b1
> 
> ax25-tools recommends no packages.
> 
> Versions of packages ax25-tools suggests:
> ii  ax25-apps  0.0.8-rc2+cvs20130510-4
> pn  talkd  
> 
> -- no debconf information
> 
> 

Bug#933251: DEB_BUILD_PROFILES=nocheck is ignored by pkg-js-tools

[Pirate Praveen]

Package: pkg-js-tools
Version: 0.8.2
Severity: important

DEB_BUILD_OPTIONS=nocheck works, but both should be supported. Build options 
don't filter build dependencies so we can't use it when circular test only 
dependencies prevent builds.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#933252: apt-listbugs should use https by default, patches included

[htxo8e+1eqk0555yrfxs]

Package: apt-listbugs
Version: 1:2.5.1
Severity: important

apt-listbugs uses insecure http port 80 by default. It can easily be moved to 
https via port 443, although additional hardening against tampering should be 
verified later to prevent mitm attacks.

lib/aptlistbugs/logic.rb appears to validate https endpoints properly, but not 
sure about lib/aptlistbugs/debian/btssoap.rb from testing against 
https://untrusted-root.badssl.com

Here are the two relevant diffs to move to https as default. Tested and appears 
to work fine.

$ diff lib/aptlistbugs/logic.rb.orig lib/aptlistbugs/logic.rb
97c97
< @port = 80
---
> @port = 443
866c866
<   tmp.puts "\nhttp://bugs.debian.org/#{bug.bug_number}\";>##{bug.bug_number}"
---
>   tmp.puts "\n href=\"https://bugs.debian.org/#{bug.bug_number}\";>##{bug.bug_number}"
917c917
< maker.channel.link = "http://bugs.debian.org/";
---
> maker.channel.link = "https://bugs.debian.org/";
926c926
< item.link = "http://bugs.debian.org/#{bug.bug_number}";
---
> item.link = "https://bugs.debian.org/#{bug.bug_number}";
942c942
< url  = "http://bugs.debian.org/#{id}";
---
> url  = "https://bugs.debian.org/#{id}";

$ diff lib/aptlistbugs/debian/btssoap.rb.orig lib/aptlistbugs/debian/btssoap.rb
26,27c26,27
<   def initialize(host = "bugs.debian.org", port = 80)
< @server="http://#{host}:#{port}/cgi-bin/soap.cgi";
---
>   def initialize(host = "bugs.debian.org", port = 443)
> @server="https://#{host}:#{port}/cgi-bin/soap.cgi";






Sent using Guerrillamail.com
Block or report abuse: 
https://www.guerrillamail.com//abuse/?a=UlR2CAQUY7YAjx369HsdexXJA8WC1Q%3D%3D

Bug#864841: Processed: Re: Bug#864841: Mixed paths

[Thomas Osterried]

Hello,

if I remember correctly, it was me who recommended /var/ax25.
In this directory, we have data like mheard/mheard.dat, ax25rtd's data, node/ 
or pms/ -- but also axcall stores downloads in this directory.
=> It's a mix of data you may search in /var/lib, /var/cache or /var/spool ; 
/var/ax25 is more intuitive.

Unfortunately, there's (afaik) no standard definition for looking in 
/usr/include for the path in the system at compile time.
And I think our project is too small (and our needs are too insignificant) for 
getting that variable to /usr/include/paths.h

Any ideas?


vy 73,
- Thomas  dl9sau


On Tue, 27 Jun 2017 11:24:57 +0100 Dave Hibberd  wrote:
> Morning all!
> 
> Brian, thanks for raising this to our attention - that's helpful.
> 
> The reason that URONode doesn't line up with ax25-tools in this case is
> that I was clearing the Lintian error "non-standard-dir-in-var", which
> as you can see here [1] ax25-tools still carries. It has been raised as
> a bug in the past here [2] and a few other times. 
> 
> The elegant solution to this I would say is for the FHS to recognise
> /var/ax25 as valid in the next major release, and this bug exists here
> [3] - I discussed this before the last release of FHS but they deemed it
> not important enough to include.
> We can always try again! 
> 
> The inelegant solution in the time being is to change the uronode debian
> package to target /var/ax25 - this will generate errors on our system,
> but it'll ensure compatability. As we've hit stable and this isn't
> security vital, it probably won't go into the main distribution, but I
> plan to create a backport version from testing with other feedback from
> the uronode mailing list anyway, so it can be lined up there.
> 
> As an aside, ax25-apps is at least listed as being in the
> distribution[4], so there must have been lag in the repos.
> 
> Regards,
> 
> DH
> 
> --
> 
> [1]
> https://lintian.debian.org/maintainer/poue...@debian.org.html#ax25-tools_0.0.10-rc4-1
> [2] https://lists.debian.org/debian-hams/2007/12/msg00024.html
> [3] https://bugs.linuxfoundation.org/show_bug.cgi?id=1021
> [4] https://packages.debian.org/stretch/ax25-apps
> 
> 
> On Thu, 15 Jun 2017, at 08:48 PM, Debian Bug Tracking System wrote:
> > Processing control commands:
> > 
> > > reassign -1 ax25-tools 0.0.10-rc4-1
> > Bug #864841 [ax25-tools] Mixed paths
> > Ignoring request to reassign bug #864841 to the same package
> > Bug #864841 [ax25-tools] Mixed paths
> > Marked as found in versions ax25-tools/0.0.10-rc4-1.
> > 
> > -- 
> > 864841: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864841
> > Debian Bug Tracking System
> > Contact ow...@bugs.debian.org with problems
> > 
> 
> 

Bug#933066: [DRE-maint] Bug#933066: ruby-gnome2: autopkgtest regression with GLib 2.60.x: format_size now uses non-breaking space

[dai]

Control: tags -1 - confirmed

Ah, sorry, I misunderstand it occurs in unstable.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#933251: [Pkg-javascript-devel] Bug#933251: DEB_BUILD_PROFILES=nocheck is ignored by pkg-js-tools

[Xavier]

Le 28/07/2019 à 09:17, Pirate Praveen a écrit :
> Package: pkg-js-tools
> Version: 0.8.2
> Severity: important
> 
> DEB_BUILD_OPTIONS=nocheck works, but both should be supported. Build
> options don't filter build dependencies so we can't use it when circular
> test only dependencies prevent builds.

pkg-js-tools just provides a debhelper plugin. The check of "nocheck",
is done by dh, not in plugins. This is different when using an
"override_dh_*": debhelper skips its step (so also pkg-js-tools step)
and give the hand to the aintainer script

Bug#933066: [DRE-maint] Bug#933066: ruby-gnome2: autopkgtest regression with GLib 2.60.x: format_size now uses non-breaking space

[dai]

Control: tags -1 + confirmed

Thank you for your reports.
But currently ruby-gnome2 failed to build due to ruby2.5's build flag (maybe).
see: https://lists.debian.org/debian-ruby/2019/07/msg00020.html
As soon as it is fixed, I will upload ruby-gnome2 with this fix.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#933254: Auto detection of components is broken when used in webpack

[Pirate Praveen]

Package: pkg-js-tools
Version: 0.8.2
Severity: grave

Reproducible in node-webpack master.

dh_auto_configure --buildsystem=nodejs
mkdir node_modules  mkdir webpack-cli/node_modules
ln -s ../eslint-scope node_modules/eslint-scope
ln -s ../../eslint-scope webpack-cli/node_modules/eslint-scope  
ln -s ../webpack-cli node_modules/eslint-scope


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#933253: systemsettings: Crash when opening Keyboard and input devices -> Mouse if Wayland is used and no mouse is connected

[johan]

Package: systemsettings
Version: 4:5.14.5-1.1
Severity: normal

Dear Maintainer,

Opening Mouse settings under keyboard and input devices causes systemsettings5
to crash when Wayland is used and no mouse is connected (only laptop touchpad
and trackpoint are used). The KDE crash report application gave the following
information:




Application: Järjestelmäasetukset (systemsettings5), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fc854a25cc0 (LWP 1029))]

Thread 6 (Thread 0x7fc8377fe700 (LWP 1046)):
[KCrash Handler]
#6  0x7fc858915f6c in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#7  0x7fc858911194 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#8  0x7fc858a48f73 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#9  0x7fc858a4fa0c in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#10 0x7fc858a46b7c in QQmlDataBlob::tryDone() () from
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#11 0x7fc858a46dde in QQmlTypeLoader::setData(QQmlDataBlob*,
QQmlDataBlob::SourceCodeData const&) () from /usr/lib/x86_64-linux-
gnu/libQt5Qml.so.5
#12 0x7fc858a4753a in QQmlTypeLoader::setData(QQmlDataBlob*, QString
const&) () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#13 0x7fc858a485e8 in QQmlTypeLoader::loadThread(QQmlDataBlob*) () from
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#14 0x7fc858a487ed in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#15 0x7fc858ab7fb4 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#16 0x7fc858ab868a in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#17 0x7fc85a2664b1 in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#18 0x7fc85a26d950 in QApplication::notify(QObject*, QEvent*) () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#19 0x7fc8598515a9 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x7fc85985459b in QCoreApplicationPrivate::sendPostedEvents(QObject*,
int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#21 0x7fc8598a3233 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#22 0x7fc856fa5f2e in g_main_context_dispatch () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x7fc856fa61c8 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x7fc856fa625c in g_main_context_iteration () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x7fc8598a2863 in
QEventDispatcherGlib::processEvents(QFlags) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#26 0x7fc85985027b in
QEventLoop::exec(QFlags) () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#27 0x7fc85969fec6 in QThread::exec() () from /usr/lib/x86_64-linux-
gnu/libQt5Core.so.5
#28 0x7fc858ab7c65 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#29 0x7fc8596a9aa7 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#30 0x7fc857c43fa3 in start_thread () from /lib/x86_64-linux-
gnu/libpthread.so.0
#31 0x7fc85939b4cf in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 5 (Thread 0x7fc8435ef700 (LWP 1034)):
#0  0x7fc859390819 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fc856fa6136 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fc856fa625c in g_main_context_iteration () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fc8598a287b in
QEventDispatcherGlib::processEvents(QFlags) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7fc85985027b in
QEventLoop::exec(QFlags) () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7fc85969fec6 in QThread::exec() () from /usr/lib/x86_64-linux-
gnu/libQt5Core.so.5
#6  0x7fc858ab7c65 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#7  0x7fc8596a9aa7 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7fc857c43fa3 in start_thread () from /lib/x86_64-linux-
gnu/libpthread.so.0
#9  0x7fc85939b4cf in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 4 (Thread 0x7fc849dc6700 (LWP 1033)):
#0  0x7fff8e5a1a21 in clock_gettime ()
#1  0x7fc8593a8ff6 in clock_gettime () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x7fc8598a21a1 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#3  0x7fc8598a09d9 in QTimerInfoList::updateCurrentTime() () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7fc8598a0fd5 in QTimerInfoList::timerWait(timespec&) () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7fc8598a25fe in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7fc856fa5669 in g_main_context_prepare () from /usr/lib/x86_64-linux-
gnu/libglib-2.0.so.0
#7  0x7fc856fa606b in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x7fc856fa625c in g_main_context_iteration () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x7fc8598a287b in
QEventDispatcherGlib::processEvents(QF

Bug#913102: pulseaudio does not restore correct mic/speaker state

[Alexandre Vaissière]

Le 24/07/2019 à 22:08, Алексей Шилин a écrit :
> Hi,
>  
> Could you please test if the issue can be reproduced after building
> pulseaudio
> with the attached patch?
>  
>  
> --
> Алексей Шилин

Hi

Just tested it and volume settings do not change anymore within a few
seconds after I'm logged in, so it does seem to fix it.

Thanks!

Alexandre.

Bug#933252: apt-listbugs should use https by default, patches included

[Francesco Poli]

Control: notfound -1 1:2.5.1
Control: forcemerge 792639 -1


On Sun, 28 Jul 2019 07:21:29 +
htxo8e+1eqk0555yr...@guerrillamail.com wrote:

> Package: apt-listbugs
> Version: 1:2.5.1

This is not a version of apt-listbugs: I am dropping it from the
"found" list...

> Severity: important
> 
> apt-listbugs uses insecure http port 80 by default. It can
> easily be moved to https via port 443
[...]

Hello unidentified user,
thanks for your bug report.

There is already another open [wishlist bug] report for the same
feature, but, unfortunately, the [incompatibility] between the OpenSSL
license and the GNU GPL license prevents me from adopting the simple
straightforward solution proposed by the original bug report submitter
(and similarly by you)...   :-(

[wishlist bug]: 
[incompatibility]: 

I am merging your bug report with the other bug report.


I haven't yet found the time to investigate alternative solution
strategies, but, in the meanwhile, OpenSSL has switched to the Apache
license v2, which is GPLv3-compatible (although GPLv2-incompatible...).

This will solve the OpenSSL incompatibility with GPLv2-or-later and for
GPLv3 works, but it [only affects] OpenSSL version 3.0.0 and later (and
not the current stable version which is included in current Debian
sid/bullseye).

[only affects]: 

I am waiting for OpenSSL v3.0.0 to be released and included in Debian.
Then, I will be able to evaluate the use of https for the SOAP
connections.


Thanks for caring about apt-listbugs and its enhancement!
Bye.

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


pgpfzVN4qy2aw.pgp
Description: PGP signature

Bug#933255: gst-plugins-base1.0: FTBFS on hurd-i386: extra Linux symbol

[Pino Toscano]

Source: gst-plugins-base1.0
Version: 1.16.0-2
Severity: important
Tags: patch ftbfs

Hi,

currently, gst-plugins-base1.0 fails to compile on hurd-i386 [1].

The issue is that one symbol in marked as available for all the
architectures, while it is not available on Hurd.  This is related to
the fixes done for #918568.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=gst-plugins-base1.0&arch=hurd-i386&ver=1.16.0-2&stamp=1563899335&raw=0

Thanks,
-- 
Pino
--- a/debian/libgstreamer-gl.symbols
+++ b/debian/libgstreamer-gl.symbols
@@ -9,7 +9,7 @@ libgstgl-1.0.so.0 libgstreamer-gl1.0-0 #
  gst_egl_get_error_string@Base 1.14.0
  (arch=linux-any kfreebsd-any)gst_egl_image_export_dmabuf@Base 1.14.0
  (arch=linux-any kfreebsd-any)gst_egl_image_from_dmabuf@Base 1.14.0
- gst_egl_image_from_dmabuf_direct@Base 1.16.0
+ (arch=linux-any kfreebsd-any)gst_egl_image_from_dmabuf_direct@Base 1.16.0
  gst_egl_image_from_texture@Base 1.14.0
  gst_egl_image_get_image@Base 1.14.0
  gst_egl_image_get_type@Base 1.14.0

Bug#823037: ITP: flatbuffers -- efficient cross platform serialization library

[Bálint Réczey]

Hi Maximiliano,

Maximiliano Curia  ezt írta (időpont: 2019.
márc. 4., H, 14:30):
>
> ¡Hola Bálint!
>
> El 2019-03-04 a las 00:23 +0100, Bálint Réczey escribió:
> > With the following changes IMO the package would be ready for upload:
> > https://salsa.debian.org/debian/flatbuffers/merge_requests/1
>
> Currently the salsa ci rules test the build against reprotest, and it fails.
> The log mentions that the issue might be due to the use of __DATE__ but that
> gets set by the SOURCE_DATE_EPOCH [1] (using the time and date from the last
> debian/changelog entry).
>
> diffoscope shows the presence of the build paths in the generated binaries,
> I'm not sure how to avoid that.
>
> If you know how to fix this, or you are interested in fixing this,
> please go ahead and make flatbuffers reproducible, otherwise, please disable
> the reprotest in the salsa ci pipeline.

I have fixed the CI pipelines by skipping reprotest for now.
Could you please proceed with the upload?

Thanks,
Balint

Bug#914319: kodi: stale process on kodi crash

[Bálint Réczey]

Hi Ritesh,

Ritesh Raj Sarraf  ezt írta (időpont: 2018. nov. 22., Cs, 
6:54):
>
> Package: kodi
> Version: 2:17.6+dfsg1-4
> Severity: important
>
> Thank you for continuing to maintain Kodi. Hopefully, now that I've
> switched to the Debian one, I'll have some time to help.
>
> Meanwhile, here's something I noticed:
>
> rrs@lenovo:~$ ps aux | grep kodi
> root 25312  0.0  0.1  75284 13316 ?S10:41   0:00 
> /usr/lib/x86_64-linux-gnu/sddm/sddm-helper --socket 
> /tmp/sddm-auth7a7c9e75-6afb-4ff5-969a-0aef94e4f40d --id 1 --start 
> kodi-standalone --user rrs --autologin
> rrs  25315  0.0  0.0   2372   760 ?S10:41   0:00 /bin/sh 
> /usr/bin/kodi-standalone
> rrs  25354  0.0  0.0   5832   472 ?Ss   10:41   0:00 
> /usr/bin/ssh-agent kodi-standalone
> rrs  25358  0.0  0.0   2372   700 ?S10:41   0:00 /bin/sh 
> /usr/bin/kodi --standalone
> rrs  25360 11.3  3.9 2949992 318956 ?  SLl  10:41   3:18 
> /usr/lib/x86_64-linux-gnu/kodi/kodi.bin --standalone
> rrs  28485  0.0  0.0   4764   940 pts/0S+   11:10   0:00 grep 
> --color=auto kodi
> 11:10 ♒♒♒
>
>
>
>
> Nov 22 10:40:54 lenovo sddm[24877]: Message received from greeter: Connect
> Nov 22 10:40:54 lenovo sddm-greeter[25128]: Loading 
> file:///usr/share/sddm/themes/debian-theme/Main.qml...
> Nov 22 10:40:54 lenovo sddm-greeter[25128]: Adding view for "eDP-1" QRect(0,0 
> 1920x1080)
> Nov 22 10:40:54 lenovo sddm-greeter[25128]: Loading 
> file:///usr/share/sddm/themes/debian-theme/Main.qml...
> Nov 22 10:40:54 lenovo sddm-greeter[25128]: Adding view for "HDMI-1" 
> QRect(1920,0 1920x1080)
> Nov 22 10:40:54 lenovo sddm-greeter[25128]: Message received from daemon: 
> Capabilities
> Nov 22 10:40:54 lenovo sddm-greeter[25128]: Message received from daemon: 
> HostName
> Nov 22 10:41:04 lenovo kernel: kodi.bin[25043]: segfault at 0 ip 
>  sp 7ffd1c3fd308 error 14 in kodi.bin[557762719000+43b000]
> Nov 22 10:41:04 lenovo kernel: Code: Bad RIP value.
> Nov 22 10:41:04 lenovo systemd[1]: Started Process Core Dump (PID 25157/UID 
> 0).
> Nov 22 10:41:04 lenovo kernel: kodi.bin[24958]: segfault at 0 ip 
>  sp 7ffd2e5b0578 error 14 in kodi.bin[55aaf687+43b000]
> Nov 22 10:41:04 lenovo kernel: Code: Bad RIP value.
> Nov 22 10:41:04 lenovo systemd[1]: Started Process Core Dump (PID 25159/UID 
> 0).
> Nov 22 10:41:07 lenovo systemd-coredump[25158]: Process 25043 (kodi.bin) of 
> user 1000 dumped core.
>
> Stack trace of thread 25043:
> #0  0x n/a 
> (n/a)
> Nov 22 10:41:07 lenovo systemd-coredump[25160]: Process 24958 (kodi.bin) of 
> user 1000 dumped core.
>
> Stack trace of thread 24958:
> #0  0x n/a 
> (n/a)
> Nov 22 10:41:10 lenovo systemd-logind[24616]: Removed session 1.
> Nov 22 10:41:25 lenovo polkitd(authority=local)[11874]: Registered 
> Authentication Agent for unix-process:25280:144345 (system bus name :1.375 
> [/usr
> Nov 22 10:41:26 lenovo polkitd(authority=local)[11874]: Operator of 
> unix-process:25280:144345 successfully authenticated as unix-user:rrs to gain 
> O
> Nov 22 10:41:26 lenovo sddm[24877]: Signal received: SIGTERM
> Nov 22 10:41:26 lenovo systemd[1]: Stopping Simple Desktop Display Manager...
> Nov 22 10:41:26 lenovo sddm-greeter[25128]: The X11 connection broke (error 
> 1). Did the X11 server die?
> Nov 22 10:41:26 lenovo sddm[24877]: Greeter stopping...
> Nov 22 10:41:26 lenovo sddm[24877]: Socket server stopping...
> Nov 22 10:41:26 lenovo sddm[24877]: Socket server stopped.
> Nov 22 10:41:26 lenovo sddm[24877]: Display server stopping...
> Nov 22 10:41:26 lenovo sddm-helper[25113]: [PAM] Closing session
> Nov 22 10:41:26 lenovo sddm-helper[25113]: pam_unix(sddm-greeter:session): 
> session closed for user sddm
> Nov 22 10:41:26 lenovo sddm-helper[25113]: [PAM] Ended.
> Nov 22 10:41:26 lenovo systemd-logind[24616]: Session 7 logged out. Waiting 
> for processes to exit.
> Nov 22 10:41:26 lenovo systemd-logind[24616]: Removed session 7.
> Nov 22 10:41:26 lenovo systemd[1]: user-runtime-dir@129.service: Unit not 
> needed anymore. Stopping.
> Nov 22 10:41:26 lenovo systemd[1]: Stopping User Manager for UID 129...
>
> The recommendation been made is to not use kodi through any systemd
> service script. Instead, users are recommended to setup an autologin
> mechanism with a window manager of their choice, and then autostart
> kodi. This works fine in an ideal world.
>
> But, in cases where kodi crashes, it leaves stray processes behind. Then
> a respawn of new kodi instance ends up having conflicts because part
> process from the previous invocation is still occupying services, like
> 8080 and 9090.
>
> Why are you recommending against the systemd service approach ? IIRC,
> when I had set it up on my RPi, the sy

Bug#859047: pysolfc: Any stack of Hanafuda cards is always movable

[Juhani Numminen]

Dear Frédéric,

On Wed, 29 Mar 2017 14:49:27 -0400 Frédéric Brière  wrote:
> Package: pysolfc
> Version: 2.0-4
> Severity: normal
> Tags: patch
> 
> Any stack of Hanafuda cards is always deemed movable, even if it is out
> of sequence.  The effect can easily be seen a game such as Firecracker,
> where:
> 
>  - Any stack can be dragged as a whole (but not released)
>  - "Highlight piles" will highlight everything
>  - Asking for a hint will ignore most valid moves
> 
> This is due to Hanafuda_SequenceStack lacking a canMoveCards() method.

I forwarded your patch upstream and it was merged:
https://github.com/shlomif/PySolFC/commit/0abb801
I'm very sorry your patch was forgotten in the BTS for such a long time.

In case you haven't already, may I propose you try out version 2.6.4-2
which was recently uploaded in Debian? Bug reports are welcome :)


Regards,
Juhani Numminen

Bug#933220: siridb-server: missing source for Release/makefile

[Paul Gevers]

Hi Helmut,

On 27-07-2019 18:47, Helmut Grohne wrote:
> The Release/makefile starts with:
> 
> 
> # Automatically-generated file. Do not edit!
> 
> 
> However, I was unable to find the source for the generator. This is a
> DFSG#2 violation.

Thank you for this report. I'm sure Jeroen, upstream and co-maintainer,
will be able to clarify and fix this quickly.

I'm slight curious, you're doing QA and found this, or are you actually
interested in siridb-server?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#933256: collectd: Change icinga dependency to icinga2

[Bas Couwenberg]

Source: collectd
Version: 5.8.1-1.3
Severity: normal
User: pkg-nagios-de...@lists.alioth.debian.org
Usertags: icinga-rm

Dear Maintainer,

Please update your package to change the icinga dependency to icinga2.

Icinga 1.x is EOL and will be removed from Debian once Icinga 2.11.1 is
in unstable.

Kind Regards,

Bas

Bug#933257: sitesummary: Change icinga dependency to icinga2

[Bas Couwenberg]

Source: sitesummary
Version: 0.1.43
Severity: normal
User: pkg-nagios-de...@lists.alioth.debian.org
Usertags: icinga-rm

Dear Maintainer,

Please update your package to change the icinga dependency to icinga2.

Icinga 1.x is EOL and will be removed from Debian once Icinga 2.11.1 is
in unstable.

Kind Regards,

Bas

Bug#931245: unblock: encoding-rs/0.8.15-2

[Paul Gevers]

reopen 931245
retitle 931245 buster-pu: package rust-encoding-rs/0.8.15-2~deb10u1 ?
user release.debian@packages.debian.org
usertags 931245 - unblock
usertags 931245 pu
thanks

On Sat, 27 Jul 2019 08:44:16 +0200 Salvatore Bonaccorso
 wrote:
> > I think you just can recycle this one (and update the bug metadata to
> > match those for a buster-pu update). There will need to be a rebuild
> > for buster versioned as 0.8.15-2~deb10u1 of rust-encoding-rs which
> > should work.
> > 
> > [Disclaimer, I'm not part of the release team, so just take this as
> > some informal comment, if SRM say to fill a new bug instead just
> > follow that]
> 
> or given #931245 is closed, just fill with reportbug a new buster-pu
> update request for rust-encoding-rs/0.8.15-2~deb10u1.

I have recycled the unblock bug, so it already shows up in the SRM
overview. Please use this if/when you have more info to share.

Paul

Bug#933258: nagios-check-xmppng: Change icinga dependency to icinga2

[Bas Couwenberg]

Source: nagios-check-xmppng
Version: 0.3.0-1
Severity: normal
User: pkg-nagios-de...@lists.alioth.debian.org
Usertags: icinga-rm

Dear Maintainer,

Please update your package to change the icinga dependency to icinga2.

Icinga 1.x is EOL and will be removed from Debian once Icinga 2.11.1 is
in unstable.

Kind Regards,

Bas

Bug#933259: djagios: Useless after icinga removal

[Bas Couwenberg]

Source: djagios
Version: 0.1.3+dfsg-9
Severity: normal
User: pkg-nagios-de...@lists.alioth.debian.org
Usertags: icinga-rm

Dear Maintainer,

This package should probably be removed, as it's not compatible with
Icinga 2, it will be useless soon.

Icinga 1.x is EOL and will be removed from Debian once Icinga 2.11.1 is
in unstable.

Kind Regards,

Bas

Bug#933260: education-main-server: Change icinga dependency to icinga2

[Bas Couwenberg]

Source: debian-edu
Version: 2.10.47
Severity: normal
User: pkg-nagios-de...@lists.alioth.debian.org
Usertags: icinga-rm

Dear Maintainer,

Please update your package to change the icinga dependency to icinga2.

Icinga 1.x is EOL and will be removed from Debian once Icinga 2.11.1 is
in unstable.

Kind Regards,

Bas

Bug#933261: RM: icli -- ROM; Dead upstream, depends on icinga which EOL

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove icli from the archive. It is dead upstream and depends on
icinga which is EOL and will be removed from Debian soon.

Kind Regards,

Bas

Bug#932434: libminini: please mark internal symbol as optional

[Gianfranco Costamagna]

 Hello,removing it is fine, however marking it as optional might be the best 
solution to avoid build failures on backports or wherever gcc-8 is still the 
default...
G.

Il venerdì 19 luglio 2019, 16:04:51 CEST, Yangfl  ha 
scritto:  
 
 Gianfranco Costamagna  于2019年7月19日周五 下午6:03写道：
>
> Source: libminini
> Version: 1.2.a+ds-2
> Tags: patch
>
> hello, please apply this patch to the symbols file
>
> +libminini (1.2.a+ds-3) unstable; urgency=medium
> +
> +  * Mark an internal symbol as optional (Closes: #-1)
> +
> + -- Gianfranco Costamagna   Fri, 19 Jul 2019 
> 11:49:22 +0200
> +
>  libminini (1.2.a+ds-2) unstable; urgency=medium
>
>    * Fix FTBFS with GCC-9 (Closes: #925751)
> diff -Nru libminini-1.2.a+ds/debian/libminini1.symbols 
> libminini-1.2.a+ds/debian/libminini1.symbols
> --- libminini-1.2.a+ds/debian/libminini1.symbols        2019-07-12 
> 17:29:01.0 +0200
> +++ libminini-1.2.a+ds/debian/libminini1.symbols        2019-07-19 
> 11:49:21.0 +0200
> @@ -17,7 +17,7 @@
>  (c++)"minIni::browse(int (*)(char const*, char const*, char const*, void*), 
>void*) const@Base" 1.2.a
>  (c++)"minIni::getkey(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, int) const@Base" 1.2.a
>  (c++)"minIni::getbool(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
>std::__cxx11::basic_string, std::allocator 
>> const&, bool) const@Base" 1.2.a
> - (c++)"void std::__cxx11::basic_string, 
> std::allocator >::_M_construct(char const*, char const*, 
> std::forward_iterator_tag)@Base" 1.2.a
> + (c++|optional)"void std::__cxx11::basic_string std::char_traits, std::allocator >::_M_construct const*>(char const*, char const*, std::forward_iterator_tag)@Base" 1.2.a
>  ini_browse@Base 1.2.a
>  ini_getbool@Base 1.2.a
>  ini_getf@Base 1.2.a
>
>
> that symbol is probably not exported anymore in gcc-9, this is why you can't 
> see the issue yet in Debian
>
> cheers,
>
> Gianfranco

Hmm, I just removed it in order to fix #925751, neither does it appear
in the latest buildd log
https://buildd.debian.org/status/fetch.php?pkg=libminini&arch=amd64&ver=1.2.a%2Bds-2&stamp=1563481050&raw=0
. Is there any need to add it back?  

Bug#932915: RFS: qcoan/2.0-6

[Elmar Stellnberger]

I have now installed a plain Bullseye chroot with debootstrap, installed 
all packages in build-depends and then run dpkg-buildpackage and see it 
builds without any problem. There needs to be something messed up with 
your build environment. Please have a look!


Am 28.07.19 um 02:02 schrieb Adam Borowski:

On Sat, Jul 27, 2019 at 10:00:45AM +0200, Elmar Stellnberger wrote:

This is a strange error. I have tested the package locally on Debian 10 as
well as on Debian 8 and Debian 9 via the OpenSuSE build service.


Well, "Debian 9" is oldstable, while all new packages must go to unstable
(and at most get backported later).  That's a difference of two major
releases (ok, maybe 1.2 releases as to-be-Bullseye is very young, although
it did already see the flurry of post-Buster upload).  No wonder the package
fails to build.


For the obs it tests building the package in a previously empty chroot and
installs only the packages given via the build dependencies.  Consequently
I can exclude that there is some missing dependency.


Also, I see that that OpenSuSE build service uses some hacked up homebrewed
dependency resolution -- it likely has a different behaviour than native
Debian tools, which also may be the culprit.


I´m afraid you will have to research what causes that error message on your
computer.


The official archive requires all packages to be buildable on unstable using
sbuild; pbuilder may also work -- it has different defaults (notably,
doesn't strip alternative build-dependencies) but those don't apply to your
package.

I haven't started the real review yet -- just tried if it builds -- but I
already see that the -dbg package is obsolete; these are built automatically
since quite a while ago.


On Wed, Jul 24, 2019 at 07:02:13PM +0200, Elmar Stellnberger wrote:

   * Package name: qcoan
 Version : 2.0-6



Meow!

Bug#932678: glib2.0: tests timeout on i386 and mips

[Simon McVittie]

On Sun, 28 Jul 2019 at 00:04:01 +0200, Aurelien Jarno wrote:
> The UTM8 based buildds like mips-sil-01 are much faster than the
> mips-aql-0{1,2,4,5} buildds, and also have an FPU, although I am not
> sure it plays a role here.

The test that timed out uses g_random_double_range() in a fairly tight
loop, and that function casts random integers to doubles, so if mips-aql-*
is emulating floating point in software I'm not necessarily surprised
it's so slow.

> After giving back this package, it built successfully on mips-manda-01.
> I have therefore blacklisted glib2.0 from the slowest buildds.

In 2.60.6 I've also disabled that test on mips.

smcv

Bug#933191: borgbackup: Fails to run as normal user because of msgpack

[Gianfranco Costamagna]

 Hello,what is your msgpack version?def is_supported_msgpack():
    # DO NOT CHANGE OR REMOVE! See also requirements and comments in setup.py.
    return (0, 4, 6) <= msgpack.version <= (0, 5, 6) and \
   msgpack.version not in [(0, 5, 0), (0, 5, 2), (0, 5, 3), (0, 5, 5)]


looks like 0.5.6 is fine, I suspect your home directory has some old and custom 
pip-installed msgpack version...
please try to see if you poisoned your home directory :)
G.
Il sabato 27 luglio 2019, 14:57:12 CEST, Lanquil  
ha scritto:  
 
 Package: borgbackup
Version: 1.1.10-2
Severity: important

Dear Maintainer,

trying to run borg create as normal user gives the following output:

You do not have a supported msgpack[-python] version installed. Terminating.
This should never happen as specific, supported versions are required by our 
setup.py.
Do not contact borgbackup support about this.

This doesn't happen if I run borg as root.


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

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

Versions of packages borgbackup depends on:
ii  fuse                  2.9.9-1
ii  libacl1                2.2.53-4
ii  libb2-1                0.98.1-1
ii  libc6                  2.28-10
ii  liblz4-1              1.8.3-1
ii  libssl1.1              1.1.1c-1
ii  libzstd1              1.3.8+dfsg-3
ii  python3                3.7.3-1
ii  python3-llfuse        1.3.6+dfsg-1
ii  python3-msgpack        0.5.6-1+b1
ii  python3-pkg-resources  41.0.1-1

borgbackup recommends no packages.

Versions of packages borgbackup suggests:
pn  borgbackup-doc  

-- no debconf information

  

Bug#933262: grub2-common: misleading information in /usr/share/grub/default/grub

[Heinrich Schuchardt]

Package: grub2-common
Version: 2.04-1
Severity: minor

Dear Maintainer,

file ./usr/share/grub/default/grub has these lines;

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

The GRUB_TERMINAL variable is not specific for grub-pc. Also on
grub-efi-arm it controls the input and output device. So please, change
the lines to:

# Uncomment to disable graphical terminal
#GRUB_TERMINAL=console

Best regards

Heinrich Schuchardt

Bug#933221: openarena: suggestion to make openarena -players-mature optional

[Simon McVittie]

Control: reassign -1 openarena-085-data
Control: affects -1 openarena-081-players-mature openarena-data openarena

On Sat, 27 Jul 2019 at 17:41:33 -0400, Tom Goulet wrote:
> It says 081 in the package
> name, so I assumed I was using that version.

Yeah, it's a bit confusing. The way the Quake III Arena engine does
backwards-compatible patches is that you continue to ship the old data
as-is in identical PK3 (zip) files, or close enough, then add new data
in an additional PK3 file containing some of the same filenames. This
results in the new versions of those files "winning" and the old versions
being ignored.

In older Debian releases there was just one large openarena-data package,
but I broke it up into smaller packages according to how upstream divide
up the installed zip files when I added the missing "source code" for
some of the data, because otherwise the source package would have been
impractically large.

0.8.1 was the most recent non-backwards-compatible update containing
complete data broken up by topic (maps, textures, players and so on),
so the openarena-081-* packages are the ones that were originally shipped
in 0.8.1 and copied into later releases without modification.

The changes that were made in 0.8.5 and 0.8.8 are distributed as
additional "patch" PK3 files that are not broken up by topic. If
they had separated out the updated "mature" player models into
pak6-patch-08?-players-mature.pk3, then I would have applied the same
separation to the Debian binary packages, and you would have been able
to remove openarena-088-players-mature, openarena-085-players-mature
and openarena-081-players-mature to get the result you wanted - but
unfortunately that didn't happen.

smcv

Bug#780706: Thank You For Making a Difference! 👍 (Surprise Inside)

[The One]

**

If you don't want to receive these emails in the future,
please unsubscribe here: 
//track.mdrctr.com/track/pre-unsubscribe/category/EMAIL/empId/74112/subId/83/listId/1/conId/8326/signature/1a9ebb70e4755c93163b96e1036a810c/conEmail/780...@bugs.debian.org/conMovil/-/snapId/17992

Bug#920937: Also with 20190502-1

[Miek Gieben]

[ Quoting  in "Bug#920937: Also with 20190502-1..." ]

I'm seeing the same problem even with version 20190502-1 firmware-atheros.


I've downgraded to the version supplied with stretch, but that didn't help 
either.


I'm now running kernel 5.2.3 (ubuntu ppa) and this seems to have made some kind 
of difference.

Bug#932795: How to handle FTBFS bugs in release architectures

[Adrian Bunk]

On Fri, Jul 26, 2019 at 07:05:50PM +0200, Santiago Vila wrote:
>...
> https://people.debian.org/~sanvila/single-cpu/
>...
> The practical implications of this is that we are currently forcing
> users to spend extra money if they want *assurance* that all the
> packages (and not just "most" of them) will build, which is a pity.

Your "assurance that all the packages will build" only applies to the 
single-cpu part of your setup.

This Intel Atom instance you were using this year seems to have only
1 GB RAM and 25 GB storage, and you mention that you had to exclude
all packages that need more than 1 GB RAM.

Excluding these usually larger packages also makes your data unreliable.
Small packages with short build time don't benefit that much from 
parallel building, but for huge packages with thousands of source files 
like gcc or libreoffice where build time matters most the build time 
tends to correlate quite well with the number of CPUs. And these huge 
packages are where a large part of build time is spent when rebuilding 
the archive.

Your "forcing users to spend extra money" claim might not be true when 
giving the actual assurance that all packages should build - it omits 
the costs of having to actually pay for provisioning sufficient RAM and 
storage for a longer amount of time when building on single-core.

How much would you be paying per month for a single-core VM
with 8 GB RAM and 80 GB storage?

If you give your current single-cpu VM 2 GB of RAM plus the same amount 
of swap this would be an economical setup that can build > 99% of all 
packages on amd64.

A VM that gives the *assurance* that all the packages will build has
to be a lot larger, and will be oversized for most packages.

The economical setup will never be able to build all packages,
and the safe way to create the assurance setup will always be
to use the same specs as the buildd VMs.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#923369: asymptote: split noX package

[Hilmar Preuße]

Am 10.07.2019 um 11:00 teilte Norbert Preining mit:

Hi,


My proposal is to split /usr/bin/xasy & /usr/share/man/man1/xasy.1x.gz
into a new package (maybe /usr/share/asymptote/GUI/ too) called


Yes, that GUI part should be moved, too.


asymptote-x11. New package depends on old one, old one suggests new one;
conflict needs to be implemented.


Sounds perfectly fine to me.


https://github.com/debian-tex/asymptote/pull/1


Then we can move over the dep on python3-pyqt5, python3-pyqt5.qtsvg to
the new package.


Agreed.


Hope I got everything.

I've moved the Dep on python packages to the asymptote-x11 package too
as there does not seem to be python code in the asymptote package any
more. I'm absolutely unsure about the librsvg2-bin package and if it is
needed by the asy program.

@Dmitry: are you able to answer that question?

Hilmar
--
#206401 http://counter.li.org

Bug#931965: New Debian package squashfs-tools-ng_0.4.2

[GCS]

Dear Phillip,

On Sun, Jul 28, 2019 at 5:18 AM Phillip Lougher
 wrote:
> I notice you have produced a new package squashfs-tools-ng_0.4.2.
 I have packaged it and uploaded for review of our FTP Master team.
They are going to check if all files have a license that's acceptable
as free software according to our guidelines.

> I have not been able to find any download of that package available.
 No one can download the package until the mentioned check is over.

> Can you confirm that this package does not repeat the libel contained
> in the upstream package?
 David removed that text from his Git tree. As this is the latest
release and before that removal, it's still contains the sentences
that you thought to be inactive and the squashfs-tools development
seemed to be stalled.

> Additionally this page
>
> https://ftp-master.debian.org/new/squashfs-tools-ng_0.4.2-1.html
>
> In the "Description" contains two paragraphs lifted from my
> Squashfs-tools repository without attribution which I consider a
> copyright violation.
>
> "Squashfs is a highly compressed read-only filesystem for Linux. It uses zlib
>  compression to compress both files, inodes and directories. Inodes in the
>  system are very small and all blocks are packed to minimise data overhead.
>  Block sizes greater than 4K are supported up to a maximum of 64K.
>  .
>  Squashfs is intended for general read-only filesystem use, for archival use
>  (i.e. in cases where a .tar.gz file may be used), and in constrained block
>  device/memory systems (e.g. embedded systems) where low overhead is needed."
 If you ask about if I credited you for this paragraph in
debian/copyright then forgive me but not yet. I can ask the FTP
Masters to reject the current package and I'm going to re-upload with
that added.
@David may even write a new description for his squashfs-tools-ng project.

> Dr Phillip Lougher
> Squashfs author and maintainer
 With all the respect, I don't know you are such upset and against
this new tool. If I look around, it seemed you are a dormant
developer.
You didn't update your homepage[1], even today it still states
"Squashfs 4.2 released (28th February 2011)" and "Squashfs 4.2 This is
the latest release, for users of 2.6.29 and later kernels". No mention
of the real latest release, 4.3 [2].
I don't see any announcement either where you present the new
development on GitHub. Quickly checking the commit logs, it reveals
that you only fixed security vulnerabilities 13 days ago[3] when these
were publicly reported four years ago (on July 20th, 2015)[4].
Then David announced _twice_ squashfs-tools-ng on _your_ mailing
list[5][6] without any comment from you. Now all of a sudden you are
against him because he (me and lot of people included) thought you are
inactive[7].
Just for the record, did you contact Gentoo as well? They already
distribute squashfs-tools-ng[8] with the text you label as
"defamatory".

@FTP Masters: please reject the package if it's really a copyright
infringement using a text description from an other package without
crediting that in our copyright file.

Kind regards,
Laszlo/GCS
[1] http://squashfs.sourceforge.net/
[2] https://sourceforge.net/projects/squashfs/files/squashfs/squashfs4.3/
[3] 
https://github.com/plougher/squashfs-tools/commit/f95864afe8833fe3ad782d714b41378e860977b1
[4] https://lwn.net/Vulnerabilities/651775/
[5] https://sourceforge.net/p/squashfs/mailman/message/36689846/
[6] https://sourceforge.net/p/squashfs/mailman/message/36709722/
[7] https://github.com/AgentD/squashfs-tools-ng/issues/10
[8] 
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5ae739228d96e5857b88c0658d22456da1724ea0

Bug#933264: gradle: update SID version to new version?

[Martin Monperrus]

Package: gradle
Version: 4.4.1-7
Severity: normal

Dear Maintainers,

Thanks a lot for this useful package.

The current SID version of gradle is 4.4.1, which dates from Dec 20, 2017 (see
https://gradle.org/releases/)

What about creating a new version of the package, for example with Gradle 5.5.1
from July 10, 2019?

That would be awesome. Thanks a lot!

--Martin



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

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

Versions of packages gradle depends on:
ii  default-jre-headless [java8-runtime-headless] 2:1.11-71
ii  libgradle-core-java   4.4.1-7
ii  libgradle-plugins-java4.4.1-7
ii  openjdk-10-jre-headless [java8-runtime-headless]  10.0.2+13-2
ii  openjdk-11-jre-headless [java8-runtime-headless]  11.0.4+10-1
ii  openjdk-8-jre-headless [java8-runtime-headless]   8u222-b07-3
ii  openjdk-9-jre-headless [java8-runtime-headless]   9.0.4+12-4

gradle recommends no packages.

Versions of packages gradle suggests:
pn  gradle-doc  

-- debconf-show failed

Bug#933265: linux-image-4.19.0-5-arm64: NULL pointer dereference at nf_tables_newrule

[Reco]

Package: src:linux
Version: 4.19.37-5+deb10u1
Severity: normal

Dear Maintainer,

I've discovered recently that loading the following set of iptables rules with 
iptables-nft-restore:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp --icmp-type 0 -m comment --comment "Ping" -j ACCEPT
-A INPUT -p icmp --icmp-type 3 -m comment --comment "Ping" -j ACCEPT
-A INPUT -p icmp --icmp-type 8 -m comment --comment "Ping" -j ACCEPT
-A INPUT -p icmp --icmp-type any -m limit --limit 10/sec   -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m hashlimit 
--hashlimit-upto 1/hour --hashlimit-burst 4 --hashlimit-mode srcip 
--hashlimit-name ssh --hashlimit-htable-expire 65536 -m comment --comment "SSH 
Blocker" -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m comment 
--comment "SSH Blocker" -j DROP

-A FORWARD -m conntrack --ctstate INVALID -j DROP

-A OUTPUT -m conntrack --ctstate INVALID -j DROP
-A OUTPUT -p udp -m udp -d 224/4 -j REJECT

COMMIT


Triggers the following NULL pointer dereference:

[  181.133805] Unable to handle kernel NULL pointer dereference at virtual 
address 0028
[  181.135156] Mem abort info:
[  181.135313]   ESR = 0x9604
[  181.135484]   Exception class = DABT (current EL), IL = 32 bits
[  181.135697]   SET = 0, FnV = 0
[  181.135819]   EA = 0, S1PTW = 0
[  181.135953] Data abort info:
[  181.136075]   ISV = 0, ISS = 0x0004
[  181.136218]   CM = 0, WnR = 0
[  181.136569] user pgtable: 4k pages, 48-bit VAs, pgdp = 6b2d46d6
[  181.137242] [0028] pgd=
[  181.137752] Internal error: Oops: 9604 [#1] SMP
[  181.138038] Modules linked in: nft_limit nft_counter ipt_REJECT 
nf_reject_ipv4 xt_hashlimit xt_tcpudp xt_limit xt_comment ip_tables 
xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c nft_compat 
x_tables nf_tables nfnetlink autofs4 fuse 9p fscache nls_ascii nls_cp437 vfat 
fat evdev aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce gf128mul sha2_ce 
sha256_arm64 sha1_ce efi_pstore gpio_keys efivars 9pnet_virtio virtio_net 9pnet 
net_failover failover qemu_fw_cfg ext4 crc16 mbcache jbd2 crc32c_generic 
fscrypto ecb aes_arm64 dm_mod virtio_blk virtio_rng rng_core virtio_mmio 
virtio_pci virtio_ring virtio
[  181.140242] Process iptables-restor (pid: 1886, stack limit = 
0xeeeb9f00)
[  181.140676] CPU: 0 PID: 1886 Comm: iptables-restor Not tainted 
4.19.0-5-arm64 #1 Debian 4.19.37-5+deb10u1
[  181.140999] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
[  181.141423] pstate: 8005 (Nzcv daif -PAN -UAO)
[  181.142111] pc : nf_tables_newrule+0x4b4/0x718 [nf_tables]
[  181.142331] lr : nf_tables_newrule+0x4bc/0x718 [nf_tables]
[  181.142532] sp : 099037a0
[  181.142672] x29: 099037a0 x28: 0003
[  181.142885] x27:  x26: 294393bd8840
[  181.143084] x25: a0defcc901b0 x24: fff5
[  181.143287] x23: a0defd490b00 x22: 08a35878
[  181.143480] x21: a0defcc90120 x20: 0002
[  181.143679] x19: 294393aa9708 x18: 294393ac7220
[  181.143878] x17:  x16: 0006
[  181.144080] x15:  x14: a0defde99860
[  181.144267] x13: a0defde996d0 x12: 0028
[  181.144466] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
[  181.144674] x9 : fefeff73686c686b x8 : 294317db3b7c
[  181.144876] x7 : fefefefefefefefe x6 : 00808080
[  181.145075] x5 :  x4 : 29431f6bb968
[  181.145276] x3 : 0006 x2 : 0005
[  181.145479] x1 : 0006 x0 : 
[  181.145772] Call trace:
[  181.145966]  nf_tables_newrule+0x4b4/0x718 [nf_tables]
[  181.146178]  nfnetlink_rcv_batch+0x3ec/0x580 [nfnetlink]
[  181.146388]  nfnetlink_rcv+0x138/0x188 [nfnetlink]
[  181.146810]  netlink_unicast+0x1d0/0x260
[  181.146968]  netlink_sendmsg+0x1b0/0x358
[  181.147128]  sock_sendmsg+0x4c/0x68
[  181.147273]  ___sys_sendmsg+0x288/0x2c8
[  181.147419]  __sys_sendmsg+0x7c/0xd0
[  181.147559]  __arm64_sys_sendmsg+0x2c/0x38
[  181.147726]  el0_svc_common+0x94/0x108
[  181.147881]  el0_svc_handler+0x38/0x78
[  181.148037]  el0_svc+0x8/0xc
[  181.148314] Code: d503201f f94002a0 b480 f9402c00 (f9401400)
[  181.148838] ---[ end trace 04c9f90c72f843fa ]---

I can reproduce this problem on both QEMU and a real hardware, and as far as I 
can tell both aarch64 and armhf are affected.

Sincerely yours, Reco

-- Package-specific info:
** Version:
Linux version 4.19.0-5-arm64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-arm64 
root=/dev/mapper/stretch--arm64--vg-root ro quiet console=ttyAMA0

** Not tainted

** Ke

Bug#933254: [Pkg-javascript-devel] Bug#933254: Auto detection of components is broken when used in webpack

[Xavier]

Le 28/07/2019 à 10:01, Pirate Praveen a écrit :
> Package: pkg-js-tools
> Version: 0.8.2
> Severity: grave
> 
> Reproducible in node-webpack master.
> 
> dh_auto_configure --buildsystem=nodejs
> mkdir node_modules mkdir webpack-cli/node_modules
> ln -s ../eslint-scope node_modules/eslint-scope
> ln -s ../../eslint-scope webpack-cli/node_modules/eslint-scope ln -s
> ../webpack-cli node_modules/eslint-scope

What is the problem here ? I don't see any error using pkg-js-tools 0.8.3

Bug#933266: nettle: Please package version 3.5.1

[Andreas Metzler]

Source: nettle
Version: 3.4.1-1
Severity: wishlist

Hello,

nettle 3.5.1 was released end of June. Could you please update the
package?

Thanks, cu Andreas

Bug#928901: shutdown-qapps FTCBFS: missing Build-Depens: qt5-qmake:native

[Johannes Schauer]

Hi,

On Sun, 28 Jul 2019 15:42:29 +0900 Christian Metscher  wrote:
> Well... Not sure if this was really correct...
> 
> https://qa.debian.org/debcheck.php?dist=unstable&package=shutdown-qapps
> 
> > Malformed Build-Depends
> > 
> > Package declares a build time dependency on 'qt5-qmake:native' which is 
> > broken Syntax.
> 
> Though, I suppose the build went all good...
> Is the problem recognition tool maybe not up-to-date?

adding :native was correct. The debcheck.php tool is indeed not up-to-date.

In the past ten years, dependency handling gained a number of features, like
multi-arch, build profiles or versioned provides. Debcheck.php is not able to
understand any of these.

See also here:

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

or here:

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

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#933231: exim4-base: /etc/cron.daily/exim4-base can't detect hostname via hostname --fqdn

[Andreas Metzler]

On 2019-07-27 Christian Garbs  wrote:
> Package: exim4-base
> Version: 4.92-8+deb10u1
> Severity: normal
> Tags: ipv6

> After the update from Stretch to Buster, on one of my systems
> /etc/cron.daily/exim4-base failed on every run with just

> hostname: Name or service not known

> as an error message.

> I could trace this to the usage of "hostname --fqdn" in the script.
> On this (and so far only on this) system this call simply fails:

> $ hostname --fqdn
> hostname: Name or service not known
[...]
> I don't yet know why, but I indeed have two hostnames:

> $ hostname --all-fqdns
> het.cgarbs.de het.cgarbs.de 

> I guess one is for the IPv4 connection and the other for IPv6.
[...]

Hello Christian,

on this system, hostname --fqdn succeeds but hostname --all-fqdns fails:
--
ametzler@argenau:~$ hostname --fqdn ; echo FQDN $? ; hostname --all-fqdns ; 
echo fqdnS $?
argenau.bebt.de
FQDN 0

fqdnS 0
--

In /etc/hosts I have got 127.0.0.1 as localhost and 127.0.1.1 as my
normal FQDN, which I think is not totally broken.

> Is there another way to get a proper hostname, perhaps from Exim
> or the Exim configuration, that can be used in /etc/cron.daily/exim4-base
> instead of calling "hostname --fqdn"?

There is
/usr/sbin/exim4 -bP primary_hostname
or
/usr/sbin/exim4 -be '${primary_hostname}'

How about the attached patch?

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
--- debian/exim4-base.cron.daily	2019-07-27 17:38:42.325457369 +0200
+++ /tmp/cron.daily	2019-07-28 14:06:59.414272250 +0200
@@ -25,6 +25,13 @@ fi
 [ -f /etc/default/exim4 ] && . /etc/default/exim4
 
 SPOOLDIR="$(exim4 -bP spool_directory | sed 's/.*=[[:space:]]\(.*\)/\1/')"
+if [ -n "$E4BCD_DAILY_REPORT_TO" ] || [ "$E4BCD_WATCH_PANICLOG" != "no" ] ; then
+	# Only needed for mail subject.
+	if ! HOSTNAME=$(/usr/sbin/exim4 -be '${primary_hostname}'); then
+		HOSTNAME="$(hostname)"
+	fi
+fi
+
 
 # The log processing code used in this cron script is not very
 # sophisticated. It relies on this cron job being executed earlier than
@@ -43,11 +50,11 @@ if [ -n "$E4BCD_DAILY_REPORT_TO" ]; then
 if [ "$(< /var/log/exim4/mainlog grep -v "$E4BCD_MAINLOG_NOISE" | wc -l)" -gt "0" ]; then
   < /var/log/exim4/mainlog grep -v "$E4BCD_MAINLOG_NOISE" \
 | eximstats $E4BCD_DAILY_REPORT_OPTIONS \
-| mail -s"$(hostname --fqdn) Daily e-mail activity report" \
+| mail -s"${HOSTNAME} Daily e-mail activity report" \
 		$E4BCD_DAILY_REPORT_TO
 else
   echo "no mail activity in this interval" \
-| mail -s"$(hostname --fqdn) Daily e-mail activity report" \
+| mail -s"${HOSTNAME} Daily e-mail activity report" \
 		$E4BCD_DAILY_REPORT_TO
 fi
   else
@@ -73,7 +80,7 @@ if [ "$E4BCD_WATCH_PANICLOG" != "no" ];
 if [ -z "$E4BCD_PANICLOG_NOISE" ] || grep -vq "$E4BCD_PANICLOG_NOISE" /var/log/exim4/paniclog; then
   log_this "ALERT: exim paniclog /var/log/exim4/paniclog has non-zero size, mail system possibly broken"
   if ! printf "Subject: exim paniclog on %s has non-zero size\nTo: root\n\nexim paniclog /var/log/exim4/paniclog on %s has non-zero size, mail system might be broken. Up to ${E4BCD_PANICLOG_LINES} lines are quoted below.\n\n%s\n" \
-  "$(hostname --fqdn)" "$(hostname --fqdn)" \
+  "${HOSTNAME}" "${HOSTNAME}" \
   "$(if [ -z "$E4BCD_PANICLOG_NOISE" ] ; then tail -n "${E4BCD_PANICLOG_LINES}" /var/log/exim4/paniclog ; else grep -v "$E4BCD_PANICLOG_NOISE" /var/log/exim4/paniclog | tail -n "${E4BCD_PANICLOG_LINES}" ; fi)" \
   | exim4 root; then
 log_this "PANIC: sending out e-mail warning has failed, exim has non-zero return code"

Bug#933267: linux-image-amd64: CONFIG_TRACE_IRQFLAGS missing from config kernel file.

[Corcodel Marian]

Package: linux-image-amd64
Version: 4.9+80+deb9u7
Severity: normal

May bee on irqflags.h header file try to replace CONFIG_TRACE_IRQFLAGS with
CONFIG_TRACE_IRQFLAGS_SUPPORT on order to enable trace.



-- System Information:
Debian Release: 9.9
  APT prefers oldstable
  APT policy: (500, 'oldstable')
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 linux-image-amd64 depends on:
ii  linux-image-4.9.0-9-amd64  4.9.168-1+deb9u4

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#933252: apt-listbugs should use https by default, patches included

[hty81z+5ruj6wk24x33w]

https://lists.debian.org/debian-legal/2004/05/msg00595.html






Sent using Guerrillamail.com
Block or report abuse: 
https://www.guerrillamail.com//abuse/?a=GBInV1hSY7YAjx369HsdexXJA8WC1Q%3D%3D

Bug#933252: apt-listbugs should use https by default, patches included

[hty81z+5ruj6wk24x33w]

https://lists.debian.org/debian-legal/2004/05/msg00595.html






Sent using Guerrillamail.com
Block or report abuse: 
https://www.guerrillamail.com//abuse/?a=GBInV1hSY7YAjx369HsdexXJA8WC1Q%3D%3D

Bug#933043: Acknowledgement (nmu: petsc_3.10.5+dfsg1-1)

[Drew Parsons]

On 2019-07-26 08:57, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 933043:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933043.


I missed the name of sundials in the second set of binNMUs with slepc:

nmu petsc_3.10.5+dfsg1-1 . ANY . unstable . -m "rebuild against hypre 
2.16.0"


and after that,

nmu slepc_3.10.2+dfsg1-1 . ANY . unstable . -m "rebuild against hypre 
2.16.0"
nmu sundials_3.1.2+dfsg-3 . ANY . unstable . -m "rebuild against hypre 
2.16.0"



Drew

Bug#933254: [Pkg-javascript-devel] Bug#933254: Bug#933254: Auto detection of components is broken when used in webpack

[Pirate Praveen]

On 2019, ജൂലൈ 28 4:53:53 PM IST, Xavier  wrote:
>Le 28/07/2019 à 13:08, Xavier a écrit :
>> Le 28/07/2019 à 10:01, Pirate Praveen a écrit :
>>> Package: pkg-js-tools
>>> Version: 0.8.2
>>> Severity: grave
>>>
>>> Reproducible in node-webpack master.
>>>
>>> dh_auto_configure --buildsystem=nodejs
>>> mkdir node_modules mkdir webpack-cli/node_modules
>>> ln -s ../eslint-scope node_modules/eslint-scope
>>> ln -s ../../eslint-scope webpack-cli/node_modules/eslint-scope ln -s
>>> ../webpack-cli node_modules/eslint-scope
>> 
>> What is the problem here ? I don't see any error using pkg-js-tools
>0.8.3
>
>Your source tree is broken: webpack-cli directory contains
>"eslint-scope" module, not webpack-cli. There was a problem during
>source import

Ah, thanks for figuring out the problem.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#928901: shutdown-qapps FTCBFS: missing Build-Depens: qt5-qmake:native

[Christian Metscher]

Hi!

Thank you so much!
That was indeed very helpful.

Cheers,

Christian

On 2019年7月28日 20:41:26 JST, Johannes Schauer  wrote:
>Hi,
>
>On Sun, 28 Jul 2019 15:42:29 +0900 Christian Metscher 
>wrote:
>> Well... Not sure if this was really correct...
>> 
>>
>https://qa.debian.org/debcheck.php?dist=unstable&package=shutdown-qapps
>> 
>> > Malformed Build-Depends
>> > 
>> > Package declares a build time dependency on 'qt5-qmake:native'
>which is broken Syntax.
>> 
>> Though, I suppose the build went all good...
>> Is the problem recognition tool maybe not up-to-date?
>
>adding :native was correct. The debcheck.php tool is indeed not
>up-to-date.
>
>In the past ten years, dependency handling gained a number of features,
>like
>multi-arch, build profiles or versioned provides. Debcheck.php is not
>able to
>understand any of these.
>
>See also here:
>
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708060
>
>or here:
>
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816448
>
>Thanks!
>
>cheers, josch

Bug#933268: Failures during upgrade, rpcbind.socket fails to (re)start

[Michael Biebl]

Package: rpcbind
Version: 1.2.5-4
Severity: serious

Hi,

during an upgrade from -3 to -4, I got the following failure (sorry for
the German locale)

rpcbind (1.2.5-4) wird eingerichtet ...
Neue Version der Konfigurationsdatei /etc/init.d/rpcbind wird installiert ...
Job for rpcbind.socket failed.
See "systemctl status rpcbind.socket" and "journalctl -xe" for details.
A dependency job for rpcbind.service failed. See 'journalctl -xe' for details.

After that, I get:
# systemctl status rpcbind.socket
● rpcbind.socket - RPCbind Server Activation Socket
   Loaded: loaded (/lib/systemd/system/rpcbind.socket; enabled; vendor preset: 
enabled)
   Active: inactive (dead) since Sun 2019-07-28 14:31:17 CEST; 3min 28s ago
   Listen: /run/rpcbind.sock (Stream)
   0.0.0.0:111 (Stream)
   0.0.0.0:111 (Datagram)
   [::]:111 (Stream)
   [::]:111 (Datagram)

Jul 28 14:31:17 pluto systemd[1]: rpcbind.socket: Succeeded.
Jul 28 14:31:17 pluto systemd[1]: Closed RPCbind Server Activation Socket.
Jul 28 14:31:17 pluto systemd[1]: Stopping RPCbind Server Activation Socket.
Jul 28 14:31:17 pluto systemd[1]: rpcbind.socket: Socket service 
rpcbind.service already active, refusing.
Jul 28 14:31:17 pluto systemd[1]: Failed to listen on RPCbind Server Activation 
Socket.



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

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

Versions of packages rpcbind depends on:
ii  adduser  3.118
ii  init-system-helpers  1.57
ii  libc62.28-10
ii  libsystemd0  241-7
ii  libtirpc31.1.4-0.4
ii  libwrap0 7.6.q-28
ii  lsb-base 10.2019051400

rpcbind recommends no packages.

rpcbind suggests no packages.

-- no debconf information

Bug#933269: firmware-amd-graphics: Had to reboot system and now hanging even with the vega20 firmware removed.

[Robin Cook]

Package: firmware-amd-graphics
Version: 20190502-1
Severity: important

Dear Maintainer,

Not sure what changed but even though I have the vega20 firmware removed it
hung on boot.



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

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

-- no debconf information

Bug#932584: Please help fix pydoctor

[Ian Jackson]

Hi, Python folks.

I think help is needed regarding

  #932584  python-pydoctor: Epydoc will be removed

It seems to be languishing rather.  What I don't understand is why
pydoctor depends on epydoc given that, in the words of the
Description:

  [Pydoctor] was written primarily to replace epydoc ...

I had a quick look through the source but I don't know enough about
pydoctor to make immediate sense of the results of my grep.  Maybe
some person who knows more about pydoctor can help ?

(I'm CCing this to the gbp maintainers because this came to my
attention due to an autoremoval bug where a package of mine has a
dependency chain via gbp.)

Thanks,
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#933194: Automate build commands from package.json gradually, one build tool at a time

[Xavier]

Hello,

I'll start doing this when pkg-js-tools 0.8.* will be in unstable to be
able to do some test in experimental

Cheers,
Xavier

Bug#915050: Proposal: Repository for fast-paced package backports

[Phil Morrell]

On Tue, Jan 01, 2019 at 05:49:37PM +0530, Pirate Praveen wrote:
> I think STS (Short term support) will fit nicely with LTS. If there is
> no serious objections, I'd go with this.

As debconf is finishing, though I don't know if either of you attended
this year, has there been any progress on this idea? Is there an
evergreen/sts/fasttrack destination I can put in my dput.cf to support
normally unsuitable packages like jenkins/virtualbox/firefox/gitlab?


signature.asc
Description: PGP signature

Bug#933267: linux-image-amd64: CONFIG_TRACE_IRQFLAGS missing from config kernel file.

[Ben Hutchings]

Control: reassign -1 src:linux 4.9.168-1+deb9u4
Control: severity -1 wishlist
Control: tag -1 wontfix

On Sun, 2019-07-28 at 14:05 +0200, Corcodel Marian wrote:
> Package: linux-image-amd64
> Version: 4.9+80+deb9u7
> Severity: normal
> 
> May bee on irqflags.h header file try to replace
> CONFIG_TRACE_IRQFLAGS with
> CONFIG_TRACE_IRQFLAGS_SUPPORT on order to enable trace.

This option is not enabled directly, but through CONFIG_PROVE_LOCKING
or CONFIG_IRQSOFF_TRACER.  We don't enable those as they have make the
kernel larger and have a significant performance cost.

Ben.

-- 
Ben Hutchings
If at first you don't succeed, you're doing about average.



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

Bug#923369: asymptote: split noX package

[Norbert Preining]

On Sun, 28 Jul 2019, Hilmar Preuße wrote:
> more. I'm absolutely unsure about the librsvg2-bin package and if it is

It is only used in xasy, the rsvg-convert utility:
$ git grep rsvg-convert
ChangeLog:Improve error message when rsvg-convert is missing.
ChangeLog:Make rsvg-convert read directly from file.
GUI/requirements.txt:rsvg-convert==2.42.3
GUI/xasySvg.py:rawDataProc = 
subprocess.Popen(['rsvg-convert', '--dpi-x', str(dpi),
GUI/xasySvg.py:Qw.QMessageBox.about(None,'rsvg-convert 
missing','Please install rsvg-convert version >= 2.40 in your path.')
doc/asymptote.texi:the @code{rsvg-convert} utility, which is part of the

doc/asymptote.texi:@url{https://sourceforge.net/projects/tumagcc/files/rsvg-convert-2.40.20.7z}

Merged, test-build, test-installed, all working.

@Hilmar, if you don't have anything else, you can upload this package.

Again, probably we need a binary upload due to NEW queue processing.

Best

Norbert

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

Bug#915050: Proposal: Repository for fast-paced package backports

[Pirate Praveen]

On 2019, ജൂലൈ 28 6:36:21 PM IST, Phil Morrell  wrote:
>On Tue, Jan 01, 2019 at 05:49:37PM +0530, Pirate Praveen wrote:
>> I think STS (Short term support) will fit nicely with LTS. If there
>is
>> no serious objections, I'd go with this.
>
>As debconf is finishing, though I don't know if either of you attended
>this year, has there been any progress on this idea? Is there an
>evergreen/sts/fasttrack destination I can put in my dput.cf to support
>normally unsuitable packages like jenkins/virtualbox/firefox/gitlab?

Hi Phil,

It stalled for a long time and we restarted work on it recently. We are in the 
process of getting server space to setup dak.

Praveen
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#933220: siridb-server: missing source for Release/makefile

[Helmut Grohne]

Hi Paul,

On Sun, Jul 28, 2019 at 10:46:10AM +0200, Paul Gevers wrote:
> I'm slight curious, you're doing QA and found this, or are you actually
> interested in siridb-server?

You guessed correctly. I found that siridb-server would FTCBFS and I
figured that I'd have to change the generated files to fix that. All of
them hard code the compiler and we need to substitute that. Yes, this is
QA. I have no clue what siridb-server does and actually didn't even read
the package description. %-)

Given this, I do find missing sources for build systems every now and
then. The most visible maybe was perl's own build system which lacked
sources in Debian for years.

Helmut

Bug#933247: e2fsprogs FTCBFS: DEB_BUILD_OPTIONS=nocheck no longer works

[Theodore Y. Ts'o]

control: -1 tags +pending

On Sun, Jul 28, 2019 at 08:09:22AM +0200, Helmut Grohne wrote:
> Source: e2fsprogs
> Version: 1.45.3-3
> Severity: important
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> e2fsprogs fails to cross build from source, since the -3 upload, because
> its support for DEB_BUILD_OPTIONS=nocheck is broken. Setting severity to
> important, because e2fsprogs is required for bootstrapping. Please
> consider applying the attached patch.

Yes, I had noticed that this was breaking some of the ports build as
well, and so I have a similar patch in my tree already.  I was going
to wait a few days to see if there were any other issues, and to allow
1.45.3-3 to enter testing before I was going to do another upload.  Is
it urgent for you such that you would prefer an upload sooner?

  - Ted

commit 20a18d54746731704d2d2dfc28edd9660eb1a296
Author: Theodore Ts'o 
Date:   Sat Jul 27 12:17:06 2019 -0400

debian: skip running "make check" if DEB_BUILD_OPTIONS contains nocheck

This was done automatically by debhelper, but it got dropped when
override_dh_auto_test was added by commit 7f4c3bb120 ("debian: run
"make check" with V=1 to keep blhc happy").

Signed-off-by: Theodore Ts'o 

diff --git a/debian/rules b/debian/rules
index e957d754..2499f6a7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -170,7 +170,9 @@ override_dh_gencontrol:
dh_gencontrol --remaining-packages
 
 override_dh_auto_test:
+ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
$(MAKE) -C ${stdbuilddir} V=1 check
+endif
 
 test_printenv:
printenv | sort

Bug#932795: Ethics of FTBFS bug reporting

[Ian Jackson]

Simon McVittie writes ("Bug#932795: Ethics of FTBFS bug reporting"):
> For the specific question of whether a single CPU core is a "reasonable"
> build environment, my answer at the moment is "I don't know".

There are two issues here:

1. "Is a 1-cpu system `reasonable' or `supported'" (or whatever)

2. We don't have anywhere to write down the answer to these kind of
questions.  (That there was nowhere to write down the answer, in
particular, nowhere in policy, is I think a large underlying cause of
why Santiago is frustrated.  Because it means that the answer isn't
written down despite it being quite relevant.)

I think most people here would be happy to have (1) decided (one way
or the other) by the release team.  Solving (2) seems like a job for
the -policy list, since it's mostly wordsmithing.

The detailed questions you ask downthread seem like good questions to
be asking to help aswer (1) but maybe now would be a good time to
bring in -release ?

Ian.

Bug#933151: mariadb-10.3: FTBFS on riscv64

[Héctor Orón Martínez]

Hello,

Missatge de Hector Oron  del dia dg., 28 de jul.
2019 a les 1:45:
> The code including atomic must link using `-latomic`, that is
> apparently GCC bug, which it is not often seen in other architectures.
> I have been unable to test the assumption.

>From irc://OFTC/debian-riscv channel someone suggests to link -pthread.

Regards
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#931386: stretch-pu: package fribidi/0.19.7-1.1

[Samuel Thibault]

Jonathan Wiltshire, le sam. 27 juil. 2019 20:36:00 -0300, a ecrit:
> On Wed, Jul 03, 2019 at 07:36:55PM +0200, Samuel Thibault wrote:
> > As reported on #917909, the text-based debian installer support for
> > right-to-left languages is completely broken, only due to a path
> > mismatch. This was fixed in Buster in January with the attached change,
> > which I have uploaded to stretch as 0.19.7-1.1, could you accept it?
> 
> That's an unusual version; did you mean to +deb9u1 it instead?

Oops, sorry about this.  I have reuploaded it as 0.19.7-1+deb9u1 with
the attached changes.

Samuel
diff -Nru fribidi-0.19.7/debian/changelog fribidi-0.19.7/debian/changelog
--- fribidi-0.19.7/debian/changelog 2015-08-12 07:32:03.0 +0200
+++ fribidi-0.19.7/debian/changelog 2019-06-08 22:39:38.0 +0200
@@ -1,3 +1,12 @@
+fribidi (0.19.7-1+deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * libfribidi0-udeb: Fix right-to-left output in textual version of
+d-i by installing the shared library files into a multi-arch libdir
+(Closes: #917909).
+
+ -- Samuel Thibault   Sat, 08 Jun 2019 22:39:38 +0200
+
 fribidi (0.19.7-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru fribidi-0.19.7/debian/libfribidi0-udeb.install 
fribidi-0.19.7/debian/libfribidi0-udeb.install
--- fribidi-0.19.7/debian/libfribidi0-udeb.install  2015-08-12 
07:32:03.0 +0200
+++ fribidi-0.19.7/debian/libfribidi0-udeb.install  2019-06-08 
22:39:38.0 +0200
@@ -1 +1 @@
-usr/lib/*/libfribidi.so.* lib
+usr/lib/*/libfribidi.so.*

Bug#933270: RFS: erlang-metrics/2.5.0-1 [ITP] -- generic interface to different metrics systems in Erlang

[James Valleroy]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "erlang-metrics"

 * Package name: erlang-metrics
   Version : 2.5.0-1
   Upstream Author : Benoît Chesneau 
 * URL : https://github.com/benoitc/erlang-metrics
 * License : BSD-3-clause
   Section : devel

It builds those binary packages:

  erlang-metrics - generic interface to different metrics systems in Erlang

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

https://mentors.debian.net/package/erlang-metrics

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

  dget -x
https://mentors.debian.net/debian/pool/main/e/erlang-metrics/erlang-metrics_2.5.0-1.dsc

Regards,
James Valleroy



signature.asc
Description: OpenPGP digital signature

Bug#923369: asymptote: split noX package

[Hilmar Preuße]

Am 28.07.2019 um 15:12 teilte Norbert Preining mit:

Hi,

> @Hilmar, if you don't have anything else, you can upload this package.
> 
> Again, probably we need a binary upload due to NEW queue processing.
> 
Hmm, forgot about that (as you noticed already). Hope that I get a
reject E-mail shortly and ...


ACL dm: NEW uploads are not allowed

binary:asymptote-x11 is NEW.


Go ahead!!!

Hilmar

BTW: do we still need the experimental branch on github?
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#931974: O: festvox-ru - Russian male speaker for Festival

[Samuel Thibault]

Hello,

Sergey B Kirpichev, le sam. 13 juil. 2019 09:13:11 +0300, a ecrit:
> I am winding down my involvement in Debian to a minimum and I have
> no intentions to support this package anymore.
> 
> Maintaining a package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.

We can maintain this along the other voices under the tts-team umbrella.
I have added you to the tts-team group on salsa, I guess this is enough
for you to transfer the salsa project?

Samuel

Bug#933267: linux-image-amd64: CONFIG_TRACE_IRQFLAGS missing from config kernel file.

[Corcodel Marian]

This aniway is a bug because CONFIG_TRACE_IRQFLAGS in not found in 
config file.


On 7/28/19 3:04 PM, Ben Hutchings wrote:

Control: reassign -1 src:linux 4.9.168-1+deb9u4
Control: severity -1 wishlist
Control: tag -1 wontfix

On Sun, 2019-07-28 at 14:05 +0200, Corcodel Marian wrote:

Package: linux-image-amd64
Version: 4.9+80+deb9u7
Severity: normal

May bee on irqflags.h header file try to replace
CONFIG_TRACE_IRQFLAGS with
CONFIG_TRACE_IRQFLAGS_SUPPORT on order to enable trace.

This option is not enabled directly, but through CONFIG_PROVE_LOCKING
or CONFIG_IRQSOFF_TRACER.  We don't enable those as they have make the
kernel larger and have a significant performance cost.

Ben.

Bug#931087: fdisk/sfdisk: creates scripts that don't work

[Matthias Urlichs]

https://github.com/karelzak/util-linux/issues/830


-- 
-- Matthias Urlichs

Bug#923369: asymptote: split noX package

[Norbert Preining]

On Sun, 28 Jul 2019, Hilmar Preuße wrote:
> Go ahead!!!

Do you mean I should upload it, right?

> BTW: do we still need the experimental branch on github?

I keep it normally, then merge master in case I do exp versions prior to
release. But it can be recreated, so no strong opinion.

Best

Norbert

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

Bug#931974: O: festvox-ru - Russian male speaker for Festival

[Sergey B Kirpichev]

On Sun, Jul 28, 2019 at 04:44:25PM +0200, Samuel Thibault wrote:
> We can maintain this along the other voices under the tts-team umbrella.
> I have added you to the tts-team group on salsa, I guess this is enough
> for you to transfer the salsa project?

What exactly I should do?

Bug#932684: buster-pu: package gnupg2/2.2.12-1+deb10u1

[Daniel Kahn Gillmor]

On Sun 2019-07-21 15:55:28 -0400, Daniel Kahn Gillmor wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> Control: affects -1 src:gnupg2
>
> The version of GnuPG in debian buster (2.2.12-1) has a number of
> outstanding bugs related to OpenPGP certificate management and network
> access.  Many of these concerns are addressed in some of the patches
> in upstream's STABLE-BRANCH-2-2 series.
>
> The debdiff (attached) is basically a slew of bugfix, documentation,
> stability, and efficiency patches cherry-picked from upstream, plus
> some additional changes to reduce the exposure of debian users to
> malicious attack on the SKS keyserver network, and some improvements
> in the continuous integration test suite.

ping on this?  i'd appreciate any feedback about its prospects for
fixing problems for users of debian buster.

   --dkg


signature.asc
Description: PGP signature

Bug#923369: asymptote: split noX package

[Hilmar Preuße]

Am 28.07.2019 um 16:54 teilte Norbert Preining mit:
> On Sun, 28 Jul 2019, Hilmar Preuße wrote:

Hi,

>> Go ahead!!!
> 
> Do you mean I should upload it, right?
> 
Yes, please. I'm not permitted to do it.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#923369: asymptote: split noX package

[Norbert Preining]

On Sun, 28 Jul 2019, Hilmar Preuße wrote:
> Yes, please. I'm not permitted to do it.

I pushed two more commits and are building it now.

Norbert

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

Bug#799090: Still present in buster version (3.30.1.1-1)

[Ivan Kohler]

On Sat, Jul 27, 2019 at 05:10:31PM +0200, Jörg Frings-Fürst wrote:
> tags 799090 - upstream
> thanks
> 
> 
> Hello,
> 
> in my mail from 14-07-2019 I asked to open a new bug report if the bug
> still exists.

That makes no sense and is not now the bug tracker is used.  The bug is 
still present, I am re-opening the original bug to save all history, not 
bloat the bug tracker with new copies of the same bugs every few years.

If there is some additional information you require other than the 
verification the bug is still present on buster, please feel free ask 
for it.  It seems bog-simple straightforward to reproduce to me, but 
perhaps my multiple different systems over the years have some 
configuration that is unusual.

Again, my thanks for packaging up a great scanning program that runs 
under multiple desktop environments, and my thanks to upstream for the 
application.

-- 
_ivan

Bug#933271: libreoffice: Should recommend libreoffice-gnome

[Yvan Masson]

Source: libreoffice
Severity: normal

Dear Maintainers,

LibreOffice is not able to read/write to GVFS mounts (GIO) if 
libreoffice-gnome is not installed. If I am not wrong, libreoffice-gnome 
is installed automatically only in the following cases when installing a 
Debian computer:

- when choosing task-gnome-desktop (which recommends libreoffice-gnome)
- when choosing task-gnome-cinammon (which depends on 
cinnamon-desktop-environment, which recommends libreoffice-gnome)


This means that when installing Debian with a desktop environment, 
LibreOffice is not able to read/write files on GVFS mounts on:

- KDE (I think it uses KIO instead of GIO, so it might work in another way)
- Mate
- XFCE
- LXDE
- LXQT

I believe that installing a Debian desktop with "recommended" 
dependencies enabled should automatically install libreoffice-gnome so 
that this functionality is not broken. Especially because when 
LibreOffice fails it is very difficult to understand where it comes from 
(it could be an issue with the SMB share or with GVFS).


Could you make libreoffice (or another package like task-desktop) 
recommends libreoffice-gnome?


Thanks for your time and work,
Yvan

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#933267: linux-image-amd64: CONFIG_TRACE_IRQFLAGS missing from config kernel file.

[Corcodel Marian]

I want to see CONFIG_TRACE_IRQFLAGS on config file like 
CONFIG_TRACE_IRQFLAGS is not set but not see that please send this 
request on linux developers.


On 7/28/19 3:04 PM, Ben Hutchings wrote:

Control: reassign -1 src:linux 4.9.168-1+deb9u4
Control: severity -1 wishlist
Control: tag -1 wontfix

On Sun, 2019-07-28 at 14:05 +0200, Corcodel Marian wrote:

Package: linux-image-amd64
Version: 4.9+80+deb9u7
Severity: normal

May bee on irqflags.h header file try to replace
CONFIG_TRACE_IRQFLAGS with
CONFIG_TRACE_IRQFLAGS_SUPPORT on order to enable trace.

This option is not enabled directly, but through CONFIG_PROVE_LOCKING
or CONFIG_IRQSOFF_TRACER.  We don't enable those as they have make the
kernel larger and have a significant performance cost.

Ben.

Bug#931974: O: festvox-ru - Russian male speaker for Festival

[Samuel Thibault]

Sergey B Kirpichev, le dim. 28 juil. 2019 17:52:29 +0300, a ecrit:
> On Sun, Jul 28, 2019 at 04:44:25PM +0200, Samuel Thibault wrote:
> > We can maintain this along the other voices under the tts-team umbrella.
> > I have added you to the tts-team group on salsa, I guess this is enough
> > for you to transfer the salsa project?
> 
> What exactly I should do?

On salsa, on your festvox-ru project page, in the Settings panel, in the
General subpanel, Expand the Advanced section, and in the Transfert
Project box, you should be able to choose "Debian TTS Maintainers". If
it doesn't appear in the list, I'll increase your access to the group.

Samuel

Bug#933271: libreoffice: Should recommend libreoffice-gnome

[Rene Engelhard]

severity 933271 wishlist
thanks

Hi,

On Sun, Jul 28, 2019 at 05:16:31PM +0200, Yvan Masson wrote:
> LibreOffice is not able to read/write to GVFS mounts (GIO) if
> libreoffice-gnome is not installed. If I am not wrong, libreoffice-gnome is
> installed automatically only in the following cases when installing a Debian
> computer:
> - when choosing task-gnome-desktop (which recommends libreoffice-gnome)
> - when choosing task-gnome-cinammon (which depends on
> cinnamon-desktop-environment, which recommends libreoffice-gnome)
> 
> This means that when installing Debian with a desktop environment,
> LibreOffice is not able to read/write files on GVFS mounts on:

Wrong. GNOME is a desktop environment. In fact, it is the default
desktop environment.

$ apt-cache show task-desktop
Package: task-desktop
Source: tasksel
Version: 3.53
Installed-Size: 6
Maintainer: Debian Install System Team 
Architecture: all
Depends: tasksel (= 3.53), xorg, xserver-xorg-video-all,
xserver-xorg-input-all, desktop-base
Recommends: task-gnome-desktop | [...]
[...]

> - KDE (I think it uses KIO instead of GIO, so it might work in another way)

So why would installing -gnome help here?

> Could you make libreoffice (or another package like task-desktop) recommends
> libreoffice-gnome?

As shown above, task-desktop recommends task-gnome-desktop which already
does what you want.

Regards,

Rene

Bug#933271: libreoffice: Should recommend libreoffice-gnome

[Rene Engelhard]

Hi,

On Sun, Jul 28, 2019 at 05:34:41PM +0200, Rene Engelhard wrote:
> > Could you make libreoffice (or another package like task-desktop) recommends
> > libreoffice-gnome?
> 
> As shown above, task-desktop recommends task-gnome-desktop which already
> does what you want.

And just for the record:

$ apt-cache show libreoffice
Package: libreoffice
Version: 1:6.1.5-3+deb10u2
Installed-Size: 92
Maintainer: Debian LibreOffice Maintainers

Architecture: amd64
Depends: libreoffice-base, libreoffice-calc, libreoffice-core (=
1:6.1.5-3+deb10u2), libreoffice-draw, libreoffice-impress,
libreoffice-math, libreoffice-report-builder-bin, libreoffice-writer,
libreoffice-avmedia-backend-gstreamer | libreoffice-avmedia-backend-vlc,
python3-uno (>= 4.4.0~beta2)
Suggests: cups-bsd, firefox-esr | thunderbird | firefox, ghostscript,
gnupg, gpa, hunspell-dictionary, hyphen-hyphenation-patterns,
imagemagick | graphicsmagick-imagemagick-compat, libgl1,
libreoffice-gnome | libreoffice-kde5, [...]

So apt install libreoffice would have shown that. But yes, tasksel
wouldn't have shown it.

Regards,
 
Rene

Bug#637127: biblatex: Version 1.6-1 breaks "refsection=part" functionality

[Hilmar Preuße]

Am 08.08.2011 um 18:53 teilte Gunnar Wolf mit:

Hi Gunnar,

> Upon installing biblatex 1.6-1, my book (which includes a references
> section per part) no longer generates the partial *.blx.aux files when
> being built. My preamble includes:
> 
> \usepackage[style=authoryear, backref=true, backrefstyle=two,
> refsection=part, block=ragged]{biblatex}
> \ExecuteBibliographyOptions{ autocite=inline, sortcites=true,
> labelyear=true, uniquename=true}
> \bibliography{seco3}
> 
> So, from the seco3.bib file, four files (one per part --
> seco31.blx.aux, seco32.blx.aux, seco33.blx.aux, seco34.blx.aux) should
> be generated, and bibtex is run for each. Of course, if I run bibtex
> on the core seco3.aux file, the complete reference section is repeated
> at the end of each part.
> 
> Downgrading to 1.4c-1 fixes the problem.
> 
Quite old bug, I know. We didn't work on the issue for a while and then
it was closed b/c the package was removed from the archive. The code
however is still in the archive and could be buggy.

1. Are you still able to reproduce the issue?
2. If yes, do you have still some sample code? The git repository
   mentioned does not exist any more.

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#933247: e2fsprogs FTCBFS: DEB_BUILD_OPTIONS=nocheck no longer works

[Helmut Grohne]

Hi Ted,

On Sun, Jul 28, 2019 at 10:04:48AM -0400, Theodore Y. Ts'o wrote:
> Yes, I had noticed that this was breaking some of the ports build as
> well, and so I have a similar patch in my tree already.  I was going
> to wait a few days to see if there were any other issues, and to allow
> 1.45.3-3 to enter testing before I was going to do another upload.  Is
> it urgent for you such that you would prefer an upload sooner?

If you defer it, I'll have to add the patch to rebootstrap.git and later
revert it. That's unfortunate, but certainly possible. I'll need some
fix (either in e2fsprogs or rebootstrap), because otherwise I'm blind to
later failures. Knowing your plans is key here. I'll assume that you
defer it unless you mail back with 12h.

>  override_dh_auto_test:
> +ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
>   $(MAKE) -C ${stdbuilddir} V=1 check
> +endif
>  
>  test_printenv:
>   printenv | sort

It just occured to me that there might be a simpler implementation
(untested):

override_dh_auto_test:
dh_auto_test -- V=1

Helmut

Bug#615596: tex4ht: mk4ht dblatex file.tex fails with xtpipes error

[Hilmar Preuße]

Control: tags 615596 + patch fixed-upstream pending notforwarded

Am 27.02.2011 um 18:05 teilte Martin Dietze mit:

Hi,

> Calling mk4ht dblatex some_file.tex results in this error:
> 
> System call: java -classpath /usr/share/tex4ht/tex4ht.jar xtpipes -i
> /usr/share/texmf/tex4ht/xtpipes/ -o some_file.xml some_file.tmp
> --- xtpipes error 32 --- Missing 4xt script file name
> --- Warning --- System return: 256
> 
> This makes it impossible to create docbook files from a LaTeX
> source.
> 
The patch from upstream solved the issue for me, tagging as patch available.

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#554637: tex4ht: Leaves intermediate files

[Hilmar Preuße]

Control: tags 554637 + wontfix
Control: notforwarded 554637

Am 05.11.2009 um 21:40 teilte Andrey mit:

Hi,

I've got a reply that some intermediate files are really needed for
reprocessing input files. Therefore they refuse to change the code. If
you really need to delete them, please use a wrapper around the tex4ht
processor.

Tag as "will not fix".

Hilmar

> I've noticed that running
> 
> htlatex test.tex "xhtml,ooffice,enumerate+" "ooffice/! -cunihtf -utf8" "-coo"
> 
> pollutes current directory with the following intermediate files:
> 
> test.4ct
> test.4tc
> test.dvi
> test.idv
> test.tmp
> test.xref
> 
> As htlatex is actually trying to do some cleanup, I think these should
> be removed as well. I only expect the following files to stay:
> 
> test.lg
> test.odt
> 


-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#893574: Auto-suspend

[Andrey Skvortsov]

My use-case is slightly different, but very annoying.

1) user1 logged in GNOME session for a while. 
2) user2 wants to use its account.
3) user1 locks its session.
4) user2 selects 'switch user' and then ...
system is surprisingly suspended after switching to greeter. User2 has
to wakeup system to login.


I've made suggested changes to /etc/gdm3/greeter.dconf-defaults as a
workaround for this behavior:

[org/gnome/settings-daemon/plugins/power]
sleep-inactive-ac-timeout=0
sleep-inactive-battery-timeout=0

I understand that most likely defaults will not be changed, because
they were modify to comply with European and American power-saving
regulations.
Changes in /etc/gdm3/greeter.dconf-defaults have solved my problem,
but other users probably have the same problem.

The problem seems that activity in other seats doesn't reset
inactivity timer in greeter session. As soon as greeter session is
active again (switch user/logout) inactivity timer triggers automatic
system suspend. It would be nice if inactivity timer would be reset on
session switching.

-- 
Best regards,
Andrey Skvortsov


signature.asc
Description: PGP signature

Bug#933272: python-mode: Emacs initialisation reports python-mode problem after fresh install

[Andreas Ames]

Package: python-mode
Version: 1:6.2.3-1.1
Severity: normal

Dear Maintainer,

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

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

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

I am starting emacs daemon from a terminal.  After a full-upgrade to buster the 
output
from "emacs --daemon" started showing problems with initialising python-mode and
haskell-mode.  So, I purged all (?) emacs-related packages including the elpa-* 
ones,
especially pythn-mode and haskell-mode.  Now, the initialisation with 
haskell-mode (or
rather elpa-haskell-mode) seem to be gone, but "emacs --daemon" still shows the 
following
issue with python-mode:

Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/00debian.el (source)...done
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...done
Loading /etc/emacs/site-start.d/50cmake-data.el (source)...
Loading /etc/emacs/site-start.d/50cmake-data.el (source)...done
Loading /etc/emacs/site-start.d/50coq.el (source)...
Loading /etc/emacs/site-start.d/50coq.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
Loading debian-ispell...
Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)...
Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)...done
Loading debian-ispell...done
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done
Loading /etc/emacs/site-start.d/50global.el (source)...
Loading /etc/emacs/site-start.d/50global.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)...
Loading /usr/share/emacs/site-lisp/latex-cjk-common/cjk-enc.el (source)...
Loading /usr/share/emacs/site-lisp/latex-cjk-common/cjk-enc.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-thai.el (source)...
Loading /etc/emacs/site-start.d/50latex-cjk-thai.el (source)...done
Loading /etc/emacs/site-start.d/50ocaml-mode.el (source)...
Loading /etc/emacs/site-start.d/50ocaml-mode.el (source)...done
Loading /etc/emacs/site-start.d/50proofgeneral.el (source)...
Loading /etc/emacs/site-start.d/50proofgeneral.el (source)...done
Loading /etc/emacs/site-start.d/50pylint.el (source)...
Loading /etc/emacs/site-start.d/50pylint.el (source)...done
Loading /etc/emacs/site-start.d/50pymacs.el (source)...
Loading /etc/emacs/site-start.d/50pymacs.el (source)...done
Loading /etc/emacs/site-start.d/50python-docutils.el (source)...
Loading /etc/emacs/site-start.d/50python-docutils.el (source)...done
Loading /etc/emacs/site-start.d/50python-mode.el (source)...
Package python-mode not fully installed.  Skipping setup.
Loading /etc/emacs/site-start.d/50python-mode.el (source)...done
Loading /etc/emacs/site-start.d/50tcsh.el (source)...
Loading /etc/emacs/site-start.d/50tcsh.el (source)...done
Loading /etc/emacs/site-start.d/50texlive-lang-english.el (source)...
Loading /etc/emacs/site-start.d/50texlive-lang-english.el (source)...done
Loading /etc/emacs/site-start.d/50why3.el (source)...
Loading /etc/emacs/site-start.d/50why3.el (source)...done
Loading delsel...
Loading delsel...done
Loading paren...
Loading paren...done
Loading /home/aa/.emacs.d/emacs-lisp/cc-mode-config.el (source)...
Loading /home/aa/.emacs.d/emacs-lisp/ppindent.el (source)...
Loading /home/aa/.emacs.d/emacs-lisp/ppindent.el (source)...done
Loading /home/aa/.emacs.d/emacs-lisp/cc-mode-config.el (source)...done
Starting Emacs daemon.

Issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905305 seems to be
related, but it is closed.

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

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

Versions of packages python-mode depends on:
ii  emacsen-common  3.0.4
ii  python  2.7.16-1

Versions of packages python-mode recommends:
ii  pychecker  0.8.19-17
ii  pymacs 0.25-2

Versions of packages python-mode suggests:
ii  pylint   1.9.4-1
ii  python-ropemacs  0.8-1

-- no debconf information

Thanks in advance,

Andreas

Bug#932328: logrotate.timer "breaks" activity report of /etc/cron.daily/exim4-base

[Andreas Metzler]

On 2019-07-18 Sven Hartge  wrote:
> On 17.07.19 20:46, Sven Hartge wrote:

>> Possible solution (untested): Also create a exim4-base.timer and
>> .service and create a Before= dependency on logrotate.service.

> I've whipped up a little Proof-of-Concept to test this, available also
> at https://salsa.debian.org/hartge-guest/exim4/tree/systemd-timer

> I'm testing this right now on two of my systems to see how this behaves,
> especially the Before=logrotate.{service,timer} ordering.

Hello Sven,

I /think/ setting Before= in *both* .service and .timer is strange.

Is this supposed to work like this?
1. When systemd looks at the timers it finds that both logratoe and exim
have identical time specifications. With the Before= setting it
triggers logrotate.service after exim.service. Otherwise it might work
out the other way round, or they are started in parallel.
2. When running exim.service systemd again finds a Before= and waits
with starting log-rotation until after exim's job has finished?

Thanks for the hand holding.

(FWIW on my system I have only a single timer/service pair that uses
Before/After - apt-daily-upgrade/apt-daily and they do it exactly the
way you suggested.)

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#933252: apt-listbugs should use https by default, patches included

[Francesco Poli]

On Sun, 28 Jul 2019 12:23:22 + hty81z+5ruj6wk24x...@guerrillamail.com wrote:

> https://lists.debian.org/debian-legal/2004/05/msg00595.html

A URL without any comment is a bit laconic.

What do you mean?
That I should add an OpenSSL linking exception to the GPLv2-or-later
license of apt-listbugs?

It's not that simple: please read the [bug log] I have already cited.
Especially [message #45], which states, in part:

[...]
| apt-listbugs is GPL-licensed and loads a number of
| GPL-licensed Ruby libraries
[...]

[bug log]: 
[message #45]: 

I cannot grant a linking exception on behalf of other copyright
holders, and I am not the sole copyright holder for apt-listbugs, nor
do I hold any copyright in the other GPL-licensed libraries loaded by
apt-listbugs.
I should ask all those other people for that linking exception,
something which I am not going to pursue.
Moreover, I do not want to grant that linking exception myself.


On the other hand, if you meant something else, sorry for
misunderstanding you, but please try and be more explicit.

Bye.

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


pgpIT__QmKzVc.pgp
Description: PGP signature

Bug#581960: tex4ht: wrong charset in htlatex output

[Hilmar Preuße]

Control: forwarded 581960 https://puszcza.gnu.org.ua/bugs/index.php?432

Am 17.05.2010 um 13:54 teilte jsb...@mimuw.edu.pl mit:

> Please have a look at the attached example.
> 
> This is a regression, it work correctly several years ago...
> 
Forwarded to upstream.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#933273: nullmailer logcheck rules no longer work

[Marc SCHAEFER]

Package: nullmailer
Version: 1:2.2-3

In buster, nullmailer now seems to report as nullmailer-send in syslog:

   Jul 28 08:02:08 falken nullmailer-send[586]: Trigger pulled.
   Jul 28 08:02:08 falken nullmailer-send[586]: Rescanning queue.
   Jul 28 08:02:08 falken nullmailer-send[586]: Starting delivery, 1 message(s) 
in queue.
   Jul 28 08:02:08 falken nullmailer-send[586]: Starting delivery: [ ... ]

thus

   sed --in-place 's/nullmailer/nullmailer-send/' 
/etc/logcheck/ignore.d.server/nullmailer

is required (and maybe everywhere else).

Also some more lines needs filtering (e.g. Message-Id: <.+>) and the order in 
Starting delivery
changed.

Here is the diff that works for me (using ignore.d.server):

--- /tmp/nullmailer.ORIG2019-07-28 19:07:10.497156131 +0200
+++ /etc/logcheck/ignore.d.server/nullmailer2019-07-28 15:06:22.544887446 
+0200
@@ -1,7 +1,8 @@
-nullmailer\[[0-9]+\]: Rescanning queue\.
-nullmailer\[[0-9]+\]: Trigger pulled\.
-nullmailer\[[0-9]+\]: Starting delivery, [0-9]+ message\(s\) in queue\.
-nullmailer\[[0-9]+\]: Starting delivery: protocol: [a-z]+ host: .+ file: 
[0-9\.]+
-nullmailer\[[0-9]+\]: Sent file\.
-nullmailer\[[0-9]+\]: Delivery complete, 0 message\(s\) remain\.
-nullmailer\[[0-9]+\]: smtp: Succeeded:
+nullmailer-send\[[0-9]+\]: Rescanning queue\.
+nullmailer-send\[[0-9]+\]: Trigger pulled\.
+nullmailer-send\[[0-9]+\]: Starting delivery, [0-9]+ message\(s\) in queue\.
+nullmailer-send\[[0-9]+\]: Starting delivery: host: .+ protocol: [a-z]+ file: 
[0-9\.]+
+nullmailer-send\[[0-9]+\]: Sent file\.
+nullmailer-send\[[0-9]+\]: Delivery complete, 0 message\(s\) remain\.
+nullmailer-send\[[0-9]+\]: smtp: Succeeded:
+nullmailer-send\[[0-9]+\]: Message-Id: <.+>

Bug#932328: logrotate.timer "breaks" activity report of /etc/cron.daily/exim4-base

[Sven Hartge]

On 28.07.19 18:53, Andreas Metzler wrote:

> I /think/ setting Before= in *both* .service and .timer is strange.

I think you just need it in the Service. But I am not sure. The
documentation was a bit sparse on that matter. Other times, just as the
apt ones you mentioned have it in both places.

Please ask the systemd guys for clarification on that matter.

But in the end it shouldn't hurt to have it in both the timer and the
service.

> Is this supposed to work like this?
> 1. When systemd looks at the timers it finds that both logratoe and exim
> have identical time specifications. With the Before= setting it
> triggers logrotate.service after exim.service. Otherwise it might work
> out the other way round, or they are started in parallel.
> 2. When running exim.service systemd again finds a Before= and waits
> with starting log-rotation until after exim's job has finished?

Exactly. At least that is how it works in my systems.

My main system is fast enough so that both exim4-base.service and
logrotate.service get started in the same second, but I see from the
logreport from exim4-base that it uses the whole logfile from the last
day, whereas before my changes I got a report spanning from 00:00 to 00:26.

On another system, which is very slow and has a very very slow storage,
I can see logrotate.service being clearly startet after
exim4-base.service finishes.

Looks like this in the logs:

Jul 28 00:00:22 svenhartge systemd[1]: Starting Daily man-db regeneration...
Jul 28 00:00:22 svenhartge systemd[1]: Starting exim4-base housekeeping...
Jul 28 00:00:38 svenhartge systemd[1]: Started exim4-base housekeeping.
Jul 28 00:00:38 svenhartge systemd[1]: Starting Rotate log files...
Jul 28 00:00:44 svenhartge systemd[1]: man-db.service: Succeeded.
Jul 28 00:00:44 svenhartge systemd[1]: Started Daily man-db regeneration.

logrotate.service waits until exim4-base.service is done, which is
exactly the way you want this to be.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#931974: O: festvox-ru - Russian male speaker for Festival

[Sergey B Kirpichev]

On Sun, Jul 28, 2019 at 05:23:17PM +0200, Samuel Thibault wrote:
> Sergey B Kirpichev, le dim. 28 juil. 2019 17:52:29 +0300, a ecrit:
> > On Sun, Jul 28, 2019 at 04:44:25PM +0200, Samuel Thibault wrote:
> > > We can maintain this along the other voices under the tts-team umbrella.
> > > I have added you to the tts-team group on salsa, I guess this is enough
> > > for you to transfer the salsa project?
> > 
> > What exactly I should do?
> 
> On salsa, on your festvox-ru project page, in the Settings panel, in the
> General subpanel, Expand the Advanced section, and in the Transfert
> Project box, you should be able to choose "Debian TTS Maintainers". If
> it doesn't appear in the list, I'll increase your access to the group.

Thank you, I did.  Hopefully, everything ok.

Bug#931548: Migration to Sphinx

[Sean Whitton]

Hello,

On Sat 27 Jul 2019 at 06:31pm +09, Osamu Aoki wrote:

> Yes.  Eventually ;-)
>
> I also see the translation of Policy is building only HTML.

We can add others upon request.

> I think I am going to rewrite build script more symmetrically to make it
> easy to build all formats for all languages.
>
> Just give me some time with developers-reference get this sorted out.

Okay -- Policy's build is already quite complex so please try to keep
the patch as small as possible.

-- 
Sean Whitton

Bug#913102: Re[2]: Bug#913102: pulseaudio does not restore correct mic/speaker state

[Алексей Шилин]

This is a pulseaudio bug [1]. It is triggered by recent changes in GDM (which 
began to
terminate itself shortly after a user logs in) and seems to affect all GDM 
users.
 
Given that GDM is part of a default Debian desktop installation, is it possible 
to fix this
issue in the next stable point release?
 
(The patch that I sent previously was cherry-picked from pulseaudio git master.)
 
 [1]  https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/667
--
Алексей Шилин
 

Bug#933274: thunderbird: TB recreates .icedove profile dir if missing, will not start at next launch

[Andrea Borgia]

Package: thunderbird
Version: 1:60.8.0-1
Severity: normal

Dear Maintainer,

This system has gone through the thunderbird->icedove->thunderbird
conversions; launching thunderbird with a real .thunderbird profile
directory and no .icedove, thunderbird will recreate .icedove as a
directory, so that following attempts to run it will fail with a conversion
error.  If I remove the .icedove directory and replace it with a symlink to
.thunderbird, the program will start happily.

Thinking it might have been an incomplete conversion, I quit the program,
removed the .icedove symlink, renamed .thunderbird to .icedove and restarted
the program.  Once the conversion was done, I closed the program and
verified I had my ".icedove" (formerly .thunderbird) directory and a new
.thunderbird symlink.  I deleted this symlink and renamed .icedove to
.thunderbird: no luck, again .icedove as real dir at the first run and an
error at the next.

First I though this was #857029 again but it turned out that, for some
reason, this profile still had a "prefs.js" which referenced ".icedove":
manually editing this file fixed the issue for good.  Shouldn't this file be
migrated too?

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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6.3
ii  fontconfig2.13.1-2
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3
ii  libgcc1   1:9.1.0-10
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-3
ii  libgtk-3-03.24.5-1
ii  libgtk2.0-0   2.24.32-3
ii  libhunspell-1.7-0 1.7.0-2+b1
ii  libicu63  63.2-2
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.21-1
ii  libnss3   2:3.45-1
ii  libpango-1.0-01.42.4-6
ii  libsqlite3-0  3.29.0-1
ii  libstartup-notification0  0.12-6
ii  libstdc++69.1.0-10
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  psmisc23.2-1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1
ii  hunspell-it [hunspell-dictionary] 1:6.3.0~rc1-1
ii  lightning 1:60.8.0-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.3-3
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.17-5

-- no debconf information

Bug#931358: release.debian.org: buster-pu (pre-approval): musescore/2.3.2+dfsg2-7~deb10u1

[Thorsten Glaser]

Hi again, sorry for bothering, but…

… in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931040#10
it was indicated this should go into the first point release,
and https://lists.debian.org/debian-devel-announce/2019/07/msg2.html
indicates that that will be done in little more than a weel, so…

>On Wed, 2019-07-03 at 06:43 +0100, Adam D. Barratt wrote:
>
>> and target would indeed be "buster". Please attach a debdiff of the
>> proposed upload to this report (but do not upload it at this stage).
>
>Is it OK to upload now?

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

Bug#931965: New Debian package squashfs-tools-ng_0.4.2

[David Oberhollenzer]

Hi,

I published an early 0.5 release based on the latest "stable point" of the
git tree:

https://infraroot.at/pub/squashfs/squashfs-tools-ng-0.5.tar.xz

The stable point has been chosen to be right after fixing stuff from multiple
hours of chewing on the Debian live CD squashfs image and pushing the Coverity
defect density below 0.1, and right before starting on a new feature that isn't
quite stable yet.

It doesn't contain everything I wanted for this release but at least it
contains the important fixes and the updated README.


If there really is a dispute now over the *two sentences* from the
description in the control file, how about this:

> New set of tools for working with SquashFS images
> 
> SquashFS is a highly compressed read-only filesystem for Linux, optimized
> for small size and high packing density. It is widely used in embedded
> systems and bootable live media.
>
> SquashFS supports many different compression formats, such as zstd, xz,
> zlib or lzo for both data and metadata compression. It has many features
> expected from popular filesystems, such as extended attributes and support
> for NFS export.
>
> As the name suggests, this is not the original user space tooling for
> SquashFS. Here are some of the features that primarily distinguish this
> package from the original:
>   - reproducible, deterministic packing without any local time stamps,
>   - Linux `gen_init_cpio` like file listing for micro managing the
> file system contents, permissions, and ownership without having to
> replicate the file system (and especially permissions) locally,
>   - support for SELinux contexts file (see selabel_file(5)) to generate
> SELinux labels.
>   - support for directly turning a tarball into a SquashFS image and back


Regards,

David

Bug#933275: expects valgrind in own binary dir, fails to run tests with --valgrind option

[Simon Richter]

Package: piglit
Version: 0~git20180515-62ef6b0db-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

running piglit tests with the --valgrind option gives a results file with
all tests marked as skipped:

"result": "skip",
"command": "/usr/lib/x86_64-linux-gnu/piglit/bin/valgrind",
"out": "An internal exception that should have been handled was 
not:\nTest executable not found.\n",

   Simon

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

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

Versions of packages piglit depends on:
ii  libc62.28-10
ii  libdrm-intel12.4.97-1
ii  libdrm2  2.4.97-1
ii  libegl1  1.1.0-1
ii  libgbm1  18.3.6-2
ii  libgcc1  1:8.3.0-6
ii  libgl1   1.1.0-1
ii  libstdc++6   8.3.0-6
ii  libwaffle-1-01.5.2-4
ii  libwayland-client0   1.16.0-1
ii  libwayland-egl1  1.16.0-1
ii  libx11-6 2:1.6.7-1
ii  libxcb-dri2-01.13.1-2
ii  libxcb1  1.13.1-2
ii  libxkbcommon00.8.2-1
ii  ocl-icd-libopencl1 [libopencl1]  2.2.12-2
ii  python3  3.7.3-1
ii  python3-mako 1.0.7+ds1-1
ii  python3-six  1.12.0-1

piglit recommends no packages.

piglit suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFDBAEBCgAtFiEEtjuqOJSXmNjSiX3Tfr04e7CZCBEFAl094XsPHHNqckBkZWJp
YW4ub3JnAAoJEH69OHuwmQgRztwH/ilPtSuR38jTd/69IECI+fmnLK7gNCnA11rh
jAe/no1ANIDH+0jbX+v8eb9cxmzHOVfkkMToxu0Q15w/6y+j8iigS6DC4QAF5VjJ
7PjNOJFNtPyhBCvZgcXJjjw4EZVicKzMmxBfZxndmOq0zRgWA1OTizwmUxS0cwSf
t7JIKg2ZP5qI1Pgzt1hNI8WQAZdztqNvcwIkA515B3kOFofUmt0xGe05AdeRs6JC
JRDSd7gJ3QU3mMr668FEiw2rVe/nyvB6BtTpKJxjOAZJmvgbN1IR/Q5YP+4yRuT8
FFWR5CuC6LrcgE/S6NtbEWYdVDan0GZ1F4l/va4NHVLkWF8PM5s=
=hsb0
-END PGP SIGNATURE-

Bug#917663: vdr-plugin-dvbhddevice: FTBFS: dvbhdffdevice.c:569:33: error: 'AUDIO_GET_PTS' was not declared in this scope

[Tobias Grimm]

Version: 2.2.0-10

Bug#931974: O: festvox-ru - Russian male speaker for Festival

[Samuel Thibault]

Sergey B Kirpichev, le dim. 28 juil. 2019 20:16:12 +0300, a ecrit:
> Thank you, I did.  Hopefully, everything ok.

Yep, thanks!

Samuel

Bug#931974: O: festvox-ru - Russian male speaker for Festival

[Samuel Thibault]

control: retitle -1 ITA: festvox-ru - Russian male speaker for Festival
control: tags -1 + pending

Sergey B Kirpichev, le dim. 28 juil. 2019 20:16:12 +0300, a ecrit:
> Thank you, I did.  Hopefully, everything ok.

Yep, I could push the maintenance switch.

Samuel

Bug#933276: libboost-all-dev: Depends on libboost-context-dev which does not exist on x32, causing BD-Uninstallable

[Thorsten Glaser]

Package: libboost-all-dev
Version: 1.67.0.1
Severity: important

Dependency installability problem for performous on x32:

performous build-depends on:
- libboost-all-dev:x32 (>= 1.67.0.1)
libboost-all-dev depends on:
- libboost-context-dev:x32
libboost-context-dev depends on missing:
- libboost-context1.67-dev:x32

Apparently, libboost-all-dev depends on libboost-context-dev only
on platforms where libboost-context-dev actually exists… and x32.

Please fix, this ought to be easy.

Thanks in advance!

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

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

Versions of packages libboost-all-dev depends on:
pn  libboost-atomic-dev   
pn  libboost-chrono-dev   
pn  libboost-container-dev
pn  libboost-context-dev  
pn  libboost-coroutine-dev
pn  libboost-date-time-dev
pn  libboost-dev  
pn  libboost-exception-dev
pn  libboost-fiber-dev
pn  libboost-filesystem-dev   
pn  libboost-graph-dev
pn  libboost-graph-parallel-dev   
pn  libboost-iostreams-dev
pn  libboost-locale-dev   
pn  libboost-log-dev  
pn  libboost-math-dev 
pn  libboost-mpi-dev  
pn  libboost-mpi-python-dev   
pn  libboost-numpy-dev
pn  libboost-program-options-dev  
pn  libboost-python-dev   
pn  libboost-random-dev   
pn  libboost-regex-dev
pn  libboost-serialization-dev
pn  libboost-signals-dev  
pn  libboost-stacktrace-dev   
pn  libboost-system-dev   
pn  libboost-test-dev 
pn  libboost-thread-dev   
pn  libboost-timer-dev
pn  libboost-tools-dev
pn  libboost-type-erasure-dev 
pn  libboost-wave-dev 

libboost-all-dev recommends no packages.

libboost-all-dev suggests no packages.

Bug#933277: [agent-transfer] Depends on dummy transitional package

[Felix Lechner]

Package: agent-transfer
Severity: minor

Dear Maintainer,

The package 'agent-transfer' depends on the dummy transitional package
'gnupg-agent'. Please update the dependency to the similarly named
'gpg-agent', or offer the latter as an installation alternative.

Users of your software can then remove the transitional package, as
recommended its description, or avoid the installation altogether.

Kind regards
Felix Lechner

Bug#933278: kmail: Kmail printing Mails prints blank pages

[Michael Müller]

Package: kmail
Version: 4:18.08.3-1
Severity: normal

Dear Maintainer,

when printing mails, kmail only prints blank pages, also when printing to PDF 
or in the pre-view.

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

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

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


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

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

Versions of packages kmail depends on:
ii  akonadi-server   4:18.08.3-5
ii  kdepim-runtime   4:18.08.3-4
ii  kio  5.54.1-1
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libgpgmepp6  1.12.0-6
ii  libkf5akonadiagentbase5  4:18.08.3-5
ii  libkf5akonadicontact54:18.08.3-1
ii  libkf5akonadicore5abi2   4:18.08.3-5
ii  libkf5akonadimime5   4:18.08.3-1
ii  libkf5akonadisearch-bin  4:18.08.3-1
ii  libkf5akonadisearch-plugins  4:18.08.3-1
ii  libkf5akonadisearchdebug54:18.08.3-1
ii  libkf5akonadisearchpim5  4:18.08.3-1
ii  libkf5akonadiwidgets5abi14:18.08.3-5
ii  libkf5bookmarks5 5.54.0-1
ii  libkf5calendarcore5abi2  4:18.08.3-1
ii  libkf5calendarutils5 4:18.08.3-2
ii  libkf5codecs55.54.0-1
ii  libkf5completion55.54.0-1
ii  libkf5configcore55.54.0-1
ii  libkf5configgui5 5.54.0-1
ii  libkf5configwidgets5 5.54.0-1
ii  libkf5contacts5  4:18.08.3-1
ii  libkf5coreaddons55.54.0-1
ii  libkf5crash5 5.54.0-1
ii  libkf5dbusaddons55.54.0-1
ii  libkf5followupreminder5  4:18.08.3-2
ii  libkf5grantleetheme-plugins  18.08.3-1
ii  libkf5gravatar5abi2  4:18.08.3-1
ii  libkf5guiaddons5 5.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5iconthemes55.54.0-1
ii  libkf5identitymanagement518.08.3-2
ii  libkf5itemmodels55.54.0-1
ii  libkf5itemviews5 5.54.0-1
ii  libkf5jobwidgets55.54.0-1
ii  libkf5kcmutils5  5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5kiofilewidgets55.54.1-1
ii  libkf5kiowidgets55.54.1-1
ii  libkf5kontactinterface5  18.08.3-1
ii  libkf5ksieveui5  4:18.08.3-2
ii  libkf5libkdepim-plugins  4:18.08.3-2
ii  libkf5libkdepim5 4:18.08.3-2
ii  libkf5libkdepimakonadi5  4:18.08.3-2
ii  libkf5libkleo5   4:18.08.3-2
ii  libkf5mailcommon5abi24:18.08.3-2
ii  libkf5mailtransport5 18.08.3-2
ii  libkf5mailtransportakonadi5  18.08.3-2
ii  libkf5messagecomposer5abi1   4:18.08.3-2
ii  libkf5messagecore5abi1   4:18.08.3-2
ii  libkf5messagelist5abi1   4:18.08.3-2
ii  libkf5messageviewer5abi1 4:18.08.3-2
ii  libkf5mime5abi1  18.08.3-1
ii  libkf5mimetreeparser5abi14:18.08.3-2
ii  libkf5notifications5 5.54.0-1
ii  libkf5notifyconfig5  5.54.0-1
ii  libkf5parts5 5.54.0-1
ii  libkf5pimcommon5abi2 4:18.08.3-2
ii  libkf5pimcommonakonadi5abi1  4:18.08.3-2
ii  libkf5pimtextedit5abi2   18.08.3-1
ii  libkf5sendlater5 4:18.08.3-2
ii  libkf5service-bin5.54.0-1
ii  libkf5service5   5.54.0-1
ii  libkf5sonnetui5  5.54.0-1
ii  libkf5templateparser54:18.08.3-2
ii  libkf5textwidgets5   5.54.0-1
ii  libkf5tnef5  4:18.08.3-1
ii  libkf5wallet-bin 5.54.0-1
ii  libkf5wallet55.54.0-1
ii  libkf5webengineviewer5abi1   4:18.08.3-2
ii  libkf5widgetsaddons5 5.54.0-1
ii  libkf5windowsystem5  5.54.0-1
ii  libkf5xmlgui55.54.0-1
ii  libqgpgme7   1.12.0-6
ii  libqt5core5a 5.11.3+dfsg1-1
ii  libqt5dbus5  5.11.3+dfsg1-1
ii  libqt5gui5   5.11.3+dfsg1-1
ii  libqt5network5   5.11.3+dfsg1-1
ii  libqt5widgets5   5.11.3+dfsg1-1
ii  libqt5xml5   5.11.3+dfsg1-1
ii  libstdc++6   8.3.0-6

Versions of packages kmail recommends:
ii  accountwizard   4:18.08.3-1
ii  gnupg   2.2.12-1
ii  kdepim-addons   18.08.3-2
ii  kdepim-themeeditors 4:18.08.3-1
ii  mbox-importer   4:18.08.3-1
ii  pim-data-exporter   4:18.08.3-1
ii  pim-sieve-editor4:18.08.3-1
ii  pinentry-qt [pinentry-x11]  1.1.0-2

Versions of packages kmail suggest