date:20181231

control: reassign -1 python-debianbts
control: notforwarded -1
control: retitle -1 python-debianbts: incompatible with new pysimplesoap

>   File "/usr/lib/python3/dist-packages/reportbug/debbugs.py", line 1154, in 
> get_report
> log = debianbts.get_bug_log(number)
>   File "/usr/lib/python3/dist-packages/debianbts/debianbts.py", line 316, in 
> get_bug_log
> reply = _soap_client_call('get_bug_log', nr)
>   File "/usr/lib/python3/dist-packages/debianbts/debianbts.py", line 488, in 
> _soap_client_call
> return getattr(soap_client, method_name)(soap_client, *soap_args)
>   File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line 175, in 
> 
> return lambda *args, **kwargs: self.call(attr, *args, **kwargs)
>   File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line 213, in 
> call
> for k, v in parameters:  # dict: tag=valor
> TypeError: cannot unpack non-iterable SoapClient object


python-debianbts currently still carries a workaround for an old
pysimplesoap bug. The workaround is broken in that it does not work with
latest pysimplesoap, where the original bug is fixed..

Explanation and fix by Gaetano Guerriero:
https://github.com/venthur/python-debianbts/pull/45

Bug#917881: gforth: Cannot upgrade 0.7.3.+dfsg-7 on Sid, gforth-common unavailable.

2018-12-31 Thread Oliver Schode

Package: gforth
Version: 0.7.3+dfsg-7
Severity: normal

Hi!

Very likely only temporary, yet just in case of an oversight: Gforth is
currently stuck in unstable as gforth-common lags behind. Nothing
serious, nothing's broken, we're around the holidays, but it's a couple
of days now and the changelog doesn't look like trouble so I'll just
post a tip-off.

Greetings,
Oliver


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

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

Versions of packages gforth depends on:
ii  emacsen-common  3.0.4
ii  gforth-common   0.7.3+dfsg-7
ii  gforth-lib  0.7.3+dfsg-7
ii  libc6   2.28-4
ii  libffi6 3.2.1-9
ii  libltdl72.4.6-6

gforth recommends no packages.

gforth suggests no packages.

Bug#917622: Keyboard shortcuts ignored in text fields

2018-12-31 Thread Minh Duc Vo

Further information : only shortcuts containing a keyboard letter are affected, 
like Ctrl+N, Ctrl+Shift+M, etc. Ctrl+Tab, Ctrl+PageDown/PageUp, 
Ctrl+Shift+PageDown/PageUp, etc. works normally.

Bug#915831: Fwd:Re: zfsutils-linux: Upgrading to 0.7.12 breaks during dpkg --configure]

2018-12-31 Thread Mo Zhou

- Forwarded message -

Hi Rich,

I investigated into this issue a bit and it looks like a result of
messy system where systemd-sysv and insserv are co-installed.
In insserv/sid, the postinst process will nolonger fail even if the
same error occurs. The error will disappear if you remove insserv.
And in your initial bug report, meta infomation told me that you
use systemd. So please don't co-install systemd-sysv and insserv.

>From zfs's side we can do mostly nothing to prevent user from
co-installing systemd-sysv and insserv, except for a simple
suggestion.

Does the issue you reported persist even after removing insserv?



I tried to install zfs tens of times in different virtual machines
setup in differrent settings. And my conclusion is simply don't
co-install them.

- End forwarded message -

Bug#917569: linux-image-4.19.0-1-686: fails to boot on i386 (Soekris net5501) BUG at arch/x86/mm/pat.c:549

2018-12-31 Thread Salvatore Bonaccorso

Hi Francesco,

On Mon, Dec 31, 2018 at 11:04:28AM +0100, Francesco Poli wrote:
> On Sun, 30 Dec 2018 09:31:52 +0100 Francesco Poli wrote:
> 
> > On Sat, 29 Dec 2018 14:28:12 +0100 Salvatore Bonaccorso wrote:
> [...]
> > > 4.19.13 upstream was
> > > just released. So we will import that one directly and preapre towards
> > > a furthre sid update.
> > 
> > Sounds great: thank you so much!
> 
> I've just installed linux-image-4.19.0-1-686/4.19.13-1 from unstable
> and tried to reboot.
> It works like a charm!
> 
> Thanks a lot for your really prompt and helpful reaction to my bug
> report.
> Bye!

Thanks a lot for your feedback!

Regards,
Salvatore

Bug#917821: intel-media-driver: better package description

2018-12-31 Thread Sebastian Ramacher

Control: reassign -1 intel-media-va-driver 18.3.0+dfsg1-1
Control: severity -1 normal
Control: merge -1 915409

On 2018-12-30 18:56:42, Christoph Anton Mitterer wrote:
> Source: intel-media-driver
> Version: 18.3.0+dfsg1-2+b1
> Severity: wishlist
> 
> 
> Hi.
> 
> As #915409 it would be nice if the package could more thoroughly describe
> the differences between the main and non-free version.

One bug for improving the package description is enough.

Cheers

> 
> 
> But apart from this:
> What are the differences between intel-media-driver and i965-va-driver?
> 
> Both seem to have some overlap in supported platforms and both provide
> va-driver.
> 
> Also, which one is taken if both are installed?
> 
> 
> Thanks,
> Chris.
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#917397: reportbug: cannot find/fetch bug reports after initial listing

> I tried selecting a specific bug from the list reportbug presented, though 
> reportbug reports it can't find said bug:

Thanks for the report. The actual bug is in python-debianbts (tracked in
#917165), one of the libraries reportbug depends on.

I'm not reassigning or closing this bug, in order to keep it visible to
reportbug users and help avoid further duplicates. This bug will be
closed once it is fixed in the proper package.

Bug#917846: /usr/bin/querybts: querybts doesn't find bug that exists

On 31 Dec 2018 Manuel Bilderbeek wrote:
> $ querybts 917782
> Retrieving report #917782 from Debian bug tracking system...
> No report available: #917782
> No bug reports found.
> 
> But that doesn't make sense, as this bug really exists!

Thanks for the report. The actual bug is in python-debianbts (tracked in
#917165), one of the libraries reportbug depends on.

I'm not reassigning or closing this bug, in order to keep it visible to
reportbug users and help avoid further duplicates. This bug will be
closed once it is fixed in the proper package.

Bug#917871: Wrong translation in the German glibc translation

2018-12-31 Thread Aurelien Jarno

Dear German translation team,

Alexander Barton has reported through the Debian BTS an issue in the
German translation of the GNU libc, most precisely on the nscd program.
Both "positive" and "negative" are translated by "positiven". You can
find the details here:

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

Regards,
Aurelien

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


signature.asc
Description: PGP signature

Bug#917457: libilmbase23: 2.3.0-3 bumped so name without transition (breaks digikam, gimp, ...)

2018-12-31 Thread Eric Valette


On 29/12/2018 08:11, Matteo F. Vescovi wrote:

Andreas,

I'll open a specific transition bug report for that, once I've tested 
all r-deps but not earlier.



Its amazing how people think they can put garbarge in experimental and 
still expecting code to be tested and surprised to discover breakage 
only once they reach unstable.


Breaking gimp,digikam is a major failure...

I do not see the problem with letting the bug and say will not will 
before transition.

Bug#917617: reportbug-gtk: "Exception in Thread-n" when retrieving more information from BTS

On 29 Dec 2018 Bruno Kleinert wrote:
>   File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line
> 175, in
> 
> return lambda *args, **kwargs: self.call(attr, *args, **kwargs)
>   File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line
> 213, in
> call
> for k, v in parameters:  # dict: tag=valor
> TypeError: cannot unpack non-iterable SoapClient object

Thanks for the report. The actual bug is in python-debianbts (tracked in
#917165), one of the libraries reportbug depends on.

I'm not reassigning or closing this bug, in order to keep it visible to
reportbug users and help avoid further duplicates. This bug will be
closed once it is fixed in the proper package.

Bug#848631: Can I take over the xpdf package?

2018-12-31 Thread Masanori Goto

Svante,

Thanks for your reply!  I was sorry for the delayed response due to
the holiday seasons.
Yes, it seems poppler backend has been taken care of by Debian
maintenairs, so I guess it's good to go.

Enjoy your holidays, too!

2018年12月21日(金) 20:03 Svante Signell :
>
> Hi Manasori,
>
> I was never allowed to maintain that package since I wanted to use the
> upstream backend. Debian requested that I should continue to support
> the from xpdf upstream diverging poppler backend.
>
> As I see xpdf with the poppler backend is already maintained by the
> Debian QA Group . Latest version is 3.04-12
> released 17 Dec 2018. From the changelog file  names as Gianfranco
> Costamagna, Iain Lane and others show up. And the latest version
> carries your name!
>
> HTH!
>
> On Fri, 2018-12-21 at 18:51 +0900, Masanori Goto wrote:
> > owner 848631 !
> > thanks
> >
> > Hi, I intend to adopt this package.  Please let me know what you
> > think.
> >
> > 2018年12月17日(月) 20:16 Masanori Goto :
> > >
> > > Hi Svante,
> > >
> > > It seems the package "xpdf" has been orphaned for 728 days, and I'm
> > > happy to take the package maintenance. I continuously use this
> > > package
> > > so I don't want to lose this package from the support.
> > > Can I take over the package maintener?
> > >
> > > Thanks,
> > > -- gotom

Bug#914160: Bug#912376: fixed in qcontrol 0.5.6-2

2018-12-31 Thread Bernhard Übelacker

Hello Ian, hello Ted,
yesterday I tried to reinstall that device with the latest
buster installer - but unfortunately I was already too late,
the archive moved already too far away:
No kernel modules were found.

Therefore I did the reinstall with the stretch installer
and upgraded to buster, like in my last attempt from november.

There I can confirm the installation of the qcontrol package
failed while running the stretch kernel:
(linux-image-4.9.0-8-marvell:armel 4.9.130-2)

apt dist-upgrade
...
Setting up qcontrol (0.5.6-2) ...
Installing new version of config file /etc/qcontrol/ts209.lua ...
Installing new version of config file /etc/qcontrol/ts219.lua ...
Installing new version of config file /etc/qcontrol/ts41x.lua ...
update-initramfs: deferring update (trigger activated)
Created symlink 
/etc/systemd/system/multi-user.target.wants/qcontrol.service → 
/lib/systemd/system/qcontrol.service.
Created symlink 
/etc/systemd/system/multi-user.target.wants/qcontrold.service → 
/lib/systemd/system/qcontrold.service.
Created symlink /etc/systemd/system/sockets.target.wants/qcontrold.socket → 
/lib/systemd/system/qcontrold.socket.
A dependency job for qcontrold.service failed. See 'journalctl -xe' for 
details.
invoke-rc.d: initscript qcontrold, action "start" failed.
● qcontrold.service - qcontrold
Loaded: loaded (/lib/systemd/system/qcontrold.service; enabled; vendor 
preset: enabled)
Active: inactive (dead)

Dez 31 02:20:17 qnap-119p-ii systemd[1]: Dependency failed for qcontrold.
Dez 31 02:20:17 qnap-119p-ii systemd[1]: qcontrold.service: Job 
qcontrold.service/start failed with result 'dependency'.
dpkg: error processing package qcontrol (--configure):
installed qcontrol package post-installation script subprocess returned 
error exit status 1
Setting up libunbound8:armel (1.8.1-1+b1)
...


journalctl
Dez 31 02:20:17 qnap-119p-ii systemd[1]: 
dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device: Job 
dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device/start timed out.
Dez 31 02:20:17 qnap-119p-ii systemd[1]: Timed out waiting for device 
dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device.
Dez 31 02:20:17 qnap-119p-ii systemd[1]: Dependency failed for qcontrold.
Dez 31 02:20:17 qnap-119p-ii systemd[1]: qcontrold.service: Job 
qcontrold.service/start failed with result 'dependency'.
Dez 31 02:20:17 qnap-119p-ii systemd[1]: 
dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device: Job 
dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device/start failed with 
result 


But after booting the buster kernel qcontrol could setup successfully:

root@qnap-119p-ii:~# apt install -f
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr 
benötigt:
dh-python libbind9-140 libdns162 libicu57 libisc160 libisccc140 
libisccfg140 liblwres141 libperl5.24 libpython3.5-minimal libpython3.5-stdlib 
python3-distutils python3-lib2to3 python3.5
python3.5-minimal rename sgml-base xml-core
Verwenden Sie »apt autoremove«, um sie zu entfernen.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
qcontrol (0.5.6-2) wird eingerichtet ...
update-initramfs: deferring update (trigger activated)
Trigger für initramfs-tools (0.132) werden verarbeitet ...
update-initramfs: Generating /boot/initrd.img-4.19.0-1-marvell
kirkwood-qnap: machine: QNAP TS219 family
Using DTB: kirkwood-ts219-6282.dtb
Installing /usr/lib/linux-image-4.19.0-1-marvell/kirkwood-ts219-6282.dtb 
into /boot/dtbs/4.19.0-1-marvell/./kirkwood-ts219-6282.dtb
Taking backup of kirkwood-ts219-6282.dtb.
Installing new kirkwood-ts219-6282.dtb.
Installing /usr/lib/linux-image-4.19.0-1-marvell/kirkwood-ts219-6282.dtb 
into /boot/dtbs/4.19.0-1-marvell/./kirkwood-ts219-6282.dtb
Taking backup of kirkwood-ts219-6282.dtb.
Installing new kirkwood-ts219-6282.dtb.
flash-kernel: installing version 4.19.0-1-marvell
flash-kernel: appending 
/usr/lib/linux-image-4.19.0-1-marvell/kirkwood-ts219-6282.dtb to kernel
Generating kernel u-boot image... done.
Flashing kernel (using 2047906/2097152 bytes)... done.
Flashing initramfs (using 4477212/9437184 bytes)... done.

Kind regards,
Bernhard

Bug#917882: petsc4py: patch to fix underlinking issue in testsuite

2018-12-31 Thread Gianfranco Costamagna

Source: petsc4py
Version 3.10.0-4
tags: patch

Hello,
https://bitbucket.org/petsc/petsc4py/pull-requests/112/demo-perftest-poisson3d-fixup-linking/diff

Please apply this diff to fix build failures (test failures) when wl,asneeded 
is exported as gcc build flag.

thanks!

G.

Bug#917839: cpufrequtils: diff for NMU version 008-1.1

2018-12-31 Thread Niels Thykier

Mattia Dongili:
> On Sun, Dec 30, 2018 at 10:30:36PM +, Niels Thykier wrote:
>> Package: cpufrequtils
>> Version: 008-1
>> Severity: normal
>> Tags: patch  pending
>> Control: tags 793913 pending
>> Control: tags 889895 pending
>>
>> Dear maintainer,
>>
>> I've prepared an NMU for cpufrequtils (versioned as 008-1.1) and
>> uploaded it to DELAYED/15. Please feel free to tell me if I
>> should delay it longer.
> 
> Thanks. No need to delay at all for that matter.
> 

Thanks for reviewing; I have uploaded the changes directly without delay.

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Bug#910923: $PLATFORM is no longer expanded.

2018-12-31 Thread Aurelien Jarno

On 2018-10-15 00:49, Roman Lebedev wrote:
> On Sun, Oct 14, 2018 at 10:51 PM Aurelien Jarno  wrote:
> >
> > control: severity -1 normal
> > control: retitle -1 libc6: broken support for curly braces DST
> >
> > On 2018-10-13 16:13, Roman Lebedev wrote:
> > > Source: glibc
> > > Version: 2.27-6
> > > Severity: important
> > >
> > > Reproduction:
> > > $ strace -ELD_PRELOAD='/sss/${PLATFORM}/'  -s300  /bin/cat
> > > execve("/bin/cat", ["/bin/cat"], 0x55ddc6b820f0 /* 64 vars */) = 0
> > > brk(NULL)   = 0x56046d9c1000
> > > access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
> > > directory)
> > > readlink("/proc/self/exe", "/bin/cat", 4096) = 8
> > > openat(AT_FDCWD, "/sss/x86_64/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No 
> > > such file or directory)
> Hm actually wait, i think i'm confused here.
> Both the ${PLATFORM} and $PLATFORM seem to expand just fine.
> 
> $ strace -ELD_PRELOAD='/sss/${PLATFORM}/'  -s300  /bin/cat | grep PLATFORM
> ...
> openat(AT_FDCWD, "/sss/x86_64/", O_RDONLY|O_CLOEXEC) = -1 ENOENT
> (No such file or directory)
> writev(2, [{iov_base="ERROR: ld.so: object '", iov_len=22},
> {iov_base="/sss/${PLATFORM}/", iov_len=21}, {iov_base="' from ",
> iov_len=7}, {iov_base="LD_PRELOAD", iov_len=10}, {iov_base=" cannot be
> preloaded (", iov_len=22}, {iov_base="cannot open shared object file",
> iov_len=30}, {iov_base="): ignored.\n", iov_len=12}], 7ERROR: ld.so:
> object '/sss/${PLATFORM}/' from LD_PRELOAD cannot be preloaded
> (cannot open shared object file): ignored.
> ) = 124
> 
> $ strace -ELD_PRELOAD='/sss/$PLATFORM/'  -s300  /bin/cat | grep PLATFORM
> ...
> openat(AT_FDCWD, "/sss/x86_64/", O_RDONLY|O_CLOEXEC) = -1 ENOENT
> (No such file or directory)
> writev(2, [{iov_base="ERROR: ld.so: object '", iov_len=22},
> {iov_base="/sss/$PLATFORM/", iov_len=19}, {iov_base="' from ",
> iov_len=7}, {iov_base="LD_PRELOAD", iov_len=10}, {iov_base=" cannot be
> preloaded (", iov_len=22}, {iov_base="cannot open shared object file",
> io
> v_len=30}, {iov_base="): ignored.\n", iov_len=12}], 7ERROR: ld.so:
> object '/sss/$PLATFORM/' from LD_PRELOAD cannot be preloaded
> (cannot open shared object file): ignored.
> ) = 122
> 
> It clearly expanded PLATFORM to x86_64 in both cases, do you agree?
> 
> So whatever i'm seeing is something else, might be caused by docker.
> 

I agree that both are correctly expanded. I also looked again calmly on
my system, and I confirm that both are expanded. So it looks like there
is no bug there.

Aurelien

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

Bug#917874: [pkg-apparmor] Bug#917874: /etc/init.d/apparmor: 60: shift: can't shift that many

2018-12-31 Thread Christian Boltz

Hello,

Am Montag, 31. Dezember 2018, 10:35:58 CET schrieb Jakub Wilk:
> Package: apparmor
> Version: 2.13.2-2
> 
> The init script is broken. The start action fails with:
> 
>/etc/init.d/apparmor: 60: shift: can't shift that many

This looks like a regression from upstream commit
0d5ab43d592245d011b2614e6e20fc7cb851c53c
which got backported into the Debian package.


The fix is most likely (untested, because I don't see this error on 
openSUSE):

--- a/parser/rc.apparmor.functions
+++ b/parser/rc.apparmor.functions
@@ -252,7 +253,7 @@ mount_securityfs() {
 
 apparmor_start() {
aa_log_daemon_msg "Starting AppArmor"
-   if ! is_apparmor_present ; then
+   if ! is_apparmor_present apparmor ; then
aa_log_failure_msg "Starting AppArmor - failed, To enable 
AppArmor, ensure your kernel is configured with CONFIG_SECURITY_APPARMOR=y then 
add 'security=apparmor apparmor=1' to the kernel command line"
aa_log_end_msg 1
return 1

Jakub, can you please test if the patch fixes the problem?


@intrigeri: do you want to include this as another fix into
https://gitlab.com/apparmor/apparmor/merge_requests/252 ?
If not, I'll submit the above patch as separate merge request.

is_apparmor_present() might also need a round of cleanup, because since
upstream 94ff870f78ad32053392b19b4600b4b5584e3bfb (which removed 
grepping /proc/modules for $modules) the only code that still actually 
does something there is
[ -d /sys/module/apparmor ]
return $?
but that's another topic ;-)


Regards,

Christian Boltz
-- 
Foot:
A device for finding furniture in the dark


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

Bug#917883: ldtp: Depends on python-gnome2 which is being removed from Debian

Source: ldtp
Version: 3.5.0-1
Severity: serious

Your recent ldtp upload added dependencies on  python-gnome2 and
python-gobject-2.

I noticed this because python-gnome2 has been removed from Testing and
will be removed from Unstable soon.

As far as I can tell, ldtp already uses GTK3. Therefore, the correct
fix for https://bugs.debian.org/890154 would be to add a dependency on
python-gi and remove the dependencies on python-gnome2 and
python-gobject-2. You will need to do this before your updated package
can migrate to Testing.

Thanks,
Jeremy Bicha

Bug#870448: hw-detect - stop using modprobe -l

Hi,

has this been forgotten to apply?
Sounds clean to me ...

Holger




On Wed, Aug 02, 2017 at 07:58:05PM +0100, Ben Hutchings wrote:
> On Wed, 2017-08-02 at 12:26 +1000, Vincent McIntyre wrote:
> > Package: hw-detect
> > Version: 1.124
> > Severity: normal
> > Tags: patch
> > 
> > I keep seeing this in installer logs, back to jessie.
> > 
> > Aug  2 01:52:11 main-menu[193]: (process:224): modprobe: invalid option -- 
> > 'l'
> > 
> > 
> > I rated this normal rather than minor because the way it is working
> > now the is_available() function always returns 1 (failure)
> > 
> > My suggestion is to use modinfo instead.
> > This will return multiline output inside the quotes but
> > a couple of tests suggests that is ok.
> > It does fail with some modules (nvidia), not sure if we care.
> >
> > diff --git a/hw-detect.sh b/hw-detect.sh
> > index 7977814..d8196c1 100755
> > --- a/hw-detect.sh
> > +++ b/hw-detect.sh
> > @@ -43,7 +43,7 @@ is_not_loaded() {
> >  }
> >  
> >  is_available () {
> > -   [ "$(modprobe -l $1)" ] || return 1
> > +   [ "$(modinfo $1)" ] || return 1
> >  }
> 
> But this still prints error messages for missing modules.  I think the
> function should be implemented as:
> 
> is_available () {
>   modprobe -qn "$1"
> }
> 
> Ben.
> 
> >  # Module as first parameter, description of device the second.
> > 
> > Kind regards
> > Vince
> > 



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

Bug#917884: mate-dock-applet: Adding a new dock does nothing

2018-12-31 Thread Rock Storm

Package: mate-dock-applet
Version: 0.87-1
Severity: grave

Dear Maintainer,

After a recent system upgrade, I've lost the dock applet. It is no
longer shown on the panel. As said in the subject, adding a new one does
nothing. No new dock is shown on the panel either. 

This upgrade I did, did not affect the mate-dock-applet package itself,
so it might be a problem with one of its dependencies instead. I've
tried downgrading to version 0.75-1 but it didn't work. I also tried
downgrading the following dependencies with no luck:

 gir1.2-freedesktop:amd64 (1.58.3-1 > 1.58.2-2)
 gir1.2-glib-2.0:amd64 (1.58.3-1 > 1.58.2-2)
 gir1.2-notify-0.7:amd64 (0.7.7-4 > 0.7.7-2)

I'm sorry I couldn't help further, my knowledge here is limited.

Please let me know if there's anything else I could try to debug this.

Thanks a lot,

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

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

Versions of packages mate-dock-applet depends on:
ii  bamfdaemon   0.5.4-1
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gir1.2-bamf-30.5.4-1
ii  gir1.2-gdkpixbuf-2.0 2.38.0+dfsg-7
ii  gir1.2-glib-2.0  1.58.3-1
ii  gir1.2-gtk-3.0   3.24.2-3
ii  gir1.2-mate-panel1.20.3-1
ii  gir1.2-notify-0.70.7.7-4
ii  gir1.2-wnck-3.0  3.30.0-2
ii  libglib2.0-bin   2.58.1-2
ii  mate-panel   1.20.3-1
ii  python3  3.7.1-3
ii  python3-gi-cairo 3.30.4-1
ii  python3-pil  5.3.0-1
ii  python3-xdg  0.25-4
ii  python3-xlib 0.23-2

mate-dock-applet recommends no packages.

mate-dock-applet suggests no packages.

-- no debconf information


-- 
Rock Storm
GPG KeyID: 4096R/C96832FD
GPG Fingerprint:
 C304 34B3 632C 464C 2FAF  C741 0439 CF52 C968 32FD

Bug#879765: fails to run on CPUs without SSE2 instruction set

2018-12-31 Thread Daniel Baumann

Hi,

sorry for the long delay.. my suggestion is to:

a) temporarily build without sse2, get netdata 1.11.1 into testing as
   soon as possible.

   I'm doing that now.. uploading after confirming it works on one of
   our Geode systems here.

b) re-order netdata to make it work better on small systems by
   reshuffling the binary packages arround, e.g. something like:

  * netdata:   meta package, depending on netdata-daemon,
   netdata-web
  * netdata-daemon:just the daemon and systemd/init integration,
   compiled with -O3 and sse2
  * netdata-daemon-legacy: daemon compiled with -O2 and without sse2
  * netdata-web:   webfrontend, not needed on small/IoT devices
  * netdata-common:plugins, checks, etc (everything arch all).

  * netdata-doc:   htmldoc that can be used via apache2
  * netdata-apache2:   apache2 conf snipped to enable netdata
   via reverse proxy

  This however needs a bit more thinking, discussing, fiddling, and
  eventually going through NEW.. so this will take a few days more.

Regards,
Daniel

Bug#825501: CVE-2016-4434

2018-12-31 Thread Moritz Mühlenhoff

On Mon, Dec 31, 2018 at 08:04:18AM +0100, Salvatore Bonaccorso wrote:
> Hi Cyril,
> 
> 
> https://security-tracker.debian.org/tracker/source-package/tika
> 
> Furthermore if we only update to 1.13 there are likely some of the
> currently  CVEs which will make tika affected, because
> the issue was introduced post 1.5. One example of this is for instance
> CVE-2016-6809, where the Matlab file parser was only introduced in 1.6
> and the issue fixed in 1.14. Or CVE-2018-17197 which affects 1.8 to
> 1.19.1. CVE-2018-1338, which was introduced in 1.7. CVE-2018-1335,
> present from 1.7 to 1.17.
> 
> There might be others, so I think the new upstream version fixing all
> known current CVE is actually needed.

Agreed. Also 1.13 was released in May 2016, so by the time buster gets
released it would be ~ 5 years old.

Cheers,
Moritz

Bug#913159: task-kannada-desktop: uninstallable on mips and mipsel

Hi,

Ivo De Decker  wrote:
> Control: found -1 3.39
> 
> Hi
> 
> On Wed, Nov 07, 2018 at 07:19:21PM +0100, Ivo De Decker wrote:
> > version: 3.47
> 
> As kibi noted on IRC, this also affects the version in stretch.
> 
> Ivo


"task-kannada-desktop depends on 'firefox-esr-l10n-kn | firefox-l10n-kn', which
is not installable on mips and mipsel, because the latest firefox doesn't
build there (yet)."

I committed that for Buster now.
Does this deserve a stable upload for Stretch?


Holger



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

Bug#917885: apt: HideAutoRemove "false" isn't honored

2018-12-31 Thread Olaf van der Spek

Package: apt
Version: 1.8.0~alpha3
Severity: normal

Hi,

# cat /etc/apt/apt.conf.d/90-local 

APT::Get::HideAutoRemove "false";
APT::Install-Recommends "0";

# apt-get upgrade

Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following package was automatically installed and is no longer required:
  libboost-random1.67.0
Use 'apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

# 

Greetings,

Olaf

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "0";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-1-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-modules";
APT::VersionedKernelPackages:: "linux-modules-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::VersionedKernelPackages:: "linux-cloud-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Get "";
APT::Get::HideAutoRemove "false";
APT::Architectures "";
APT::Architectures:: "amd

Bug#917886: rst2pdf: /usr/bin/pygmntize binary moved to python3-pygments package

Package: src:rst2pdf
Version: 0.93-6
Severity: normal

Dear Maintainer,

I moved /usr/bin/pygmntize script to python3-pygments binary package.
Please update your dependency.

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

Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#917887: editra: please use packaged version of pygments

Package: editra
Version: 0.7.20+dfsg.1-3
Severity: normal

Dear Maintainer,

Editra ships a copy of Pygments, please use the one from python-pygments
(or python3-pygments once it uses Python 3) instead of shipping local
copy of /usr/lib/python2.7/dist-packages/Editra/src/extern/pygments
or notify security team that you need this copy.

While we're at it, please also consider moving Editra into private
namespace (/usr/share/editra/) - let me know if you don't know how to do
this and I'll provide a patch.

Bug#917874: /etc/init.d/apparmor: 60: shift: can't shift that many

2018-12-31 Thread Jakub Wilk


* Christian Boltz , 2018-12-31, 12:22:

The init script is broken. The start action fails with:

  /etc/init.d/apparmor: 60: shift: can't shift that many


This looks like a regression from upstream commit 
0d5ab43d592245d011b2614e6e20fc7cb851c53c which got backported into the 
Debian package.



The fix is most likely (untested, because I don't see this error on 
openSUSE):


I guess it's a bash vs dash thing:

  $ bash -c 'shift; echo $?'
  1

  $ dash -c 'shift; echo $?'
  dash: 1: shift: can't shift that many

I have /bin/sh pointing to dash (which is the Debian default).


-   if ! is_apparmor_present ; then
+   if ! is_apparmor_present apparmor ; then


Now I get:

  Starting AppArmor - failed, To enable AppArmor, ensure your kernel is 
configured with CONFIG_SECURITY_APPARMOR=y then add 'security=apparmor 
apparmor=1' to the kernel command line

It looks like is_apparmor_present() always fails?


the only code that still actually does something there is
   [ -d /sys/module/apparmor ]


With this one-line implementation of is_apparmor_present(), the script 
seems to work, but I get warnings about missing functions:


  /etc/init.d/apparmor: 209: /etc/init.d/apparmor: aa_log_action_start: not 
found
  /etc/init.d/apparmor: 221: /etc/init.d/apparmor: aa_log_action_end: not found

--
Jakub Wilk

Bug#917889: ITP: fuser-overlayfs -- An implementation of overlay+shiftfs in FUSE for rootless containers.

2018-12-31 Thread Reinhard Tartler

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: fuser-overlayfs
  Version : 0.2
  Upstream Author : Giuseppe Scrivano 
2001-2007  Miklos Szeredi 
* URL : https://github.com/containers/fuse-overlayfs
* License : GPLv3
  Programming Lang: C
  Description : An implementation of overlay+shiftfs in FUSE for rootless 
containers.

fuse-overlayfs provides an overlayfs FUSE implementation so that it
can be used since Linux 4.18 by unprivileged users in an user
namespace.

Bug#917888: nmu: mustache-d_0.1.3-3 [armel]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-CC: m...@debian.org

Please rebuild mustache-d on armel and x32 (as was done on other
architectures). This might allow the latest glib-d to migrate to
Testing.

https://buildd.debian.org/status/package.php?p=mustache-d

Here's my guess at the syntax:

nmu mustache-d_0.1.3-3 . armel x32 . -m 'Rebuild against
libphobos2-ldc-shared82.'

Thanks,
Jeremy Bicha

Bug#917890: nanoc: /usr/bin/pygmentize moved to python3-pygments

Source: nanoc
Version: 4.11.0-1
Severity: normal

Dear Maintainer,

I moved /usr/bin/pygmentize script to python3-pygments package
and it looks like you used it in
nanoc/lib/nanoc/filters/colorize_syntax/colorizers.rb

Please update Depends so that this lib can find the right executable

Bug#917892: ptex2tex: /usr/bin/pygmentize moved to python3-pygments package

Package: ptex2tex
Version: 0.4-1
Severity: normal

Dear Maintainer,

if the dependency on python-pygments is due to pygmentize script
(and latex/styles/minted.sty suggests that)
then please replace it with python3-pygments as that the package
that provides this script now. TIA

Bug#917891: RM: gnome-python-desktop -- ROM, RoQA; unmaintained, depends on libgnome

Package: ftp.debian.org
X-Debbugs-Cc: gnome-python-desk...@packages.debian.org
Affects: src:gnome-python-desktop

gnome-python-desktop has no remaining reverse dependencies in Debian.

It has been unmaintained for years and is one of the blockers for
removing the other unmaintained libgnome libraries.

gnome-python-desktop was removed from Testing a year ago:
https://bugs.debian.org/790591

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#917893: Please add /dev/ttyGS0 to securetty

2018-12-31 Thread Guido Günther

Package: login
Version: 1:4.5-1
Severity: wishlist
Tags: patch

Hi,
ttyGS0 is the device used by the USB gadget serial driver:

   https://www.kernel.org/doc/Documentation/usb/gadget_serial.txt

It's useful when one wants to login a USB gadget. MR is here:

   https://salsa.debian.org/debian/shadow/merge_requests/4

I'll update the bugnumber in the MR once I got it back from the BTS.
Cheers,
 -- Guido


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

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

Versions of packages login depends on:
ii  libaudit1   1:2.8.4-2
ii  libc6   2.28-2
ii  libpam-modules  1.1.8-3.8
ii  libpam-runtime  1.1.8-3.8
ii  libpam0g1.1.8-3.8

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#916072: mark python-chardet Multi-Arch: foreign

> > python-chardet cannot be used to satisfy cross build dependencies (e.g.
> > for nagios-plugins-contrib via python-debian).
> 
> Thanks for the detailed explanation and the attached patch! It's fine
> for me, but I'm only an uploader of chardet so I will ping Piotr before
> applying it.

go ahead, I will not pretend I'm a multiarch expert ;)

Bug#917889: ITP: fuser-overlayfs -- An implementation of overlay+shiftfs in FUSE for rootless containers.

2018-12-31 Thread Reinhard Tartler

Packaging available at https://salsa.debian.org/debian/fuse-overlayfs

This program is going to use fuse3, which is not co-installable with fuse2.

cf.
-
http://lists.debian.org/ca+fnjvb3j4h81k+bcxm3d2zjgheenjxhws06c5avicr51jg...@mail.gmail.com
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912526

Advise, suggestions and co-maintainers more than welcome!
-rt

Bug#917626: closed by Alastair McKinstry (Bug#917626: fixed in cctools 7.0.9-1)

2018-12-31 Thread Mattia Rizzolo

Control: reopen -1

On Mon, Dec 31, 2018 at 09:39:18AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:cctools package:
> 
> #917626: cctools: FTBFS on i386: error: 'major' was not declared in this scope
> 
> It has been closed by Alastair McKinstry .

>* New upstream release, closes: #917626

This was not enough, it still fails with the very same error.

https://buildd.debian.org/status/fetch.php?pkg=cctools&arch=i386&ver=7.0.9-1&stamp=1546250165&raw=0

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#917894: x2godesktopsharing FTCBFS: multiple reasons

2018-12-31 Thread Helmut Grohne

Source: x2godesktopsharing
Version: 3.2.0.0-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

x2godesktopsharing fails to cross build from source for multiple
reasons. For running lrelease, you must list qt5-qmake:native in
Build-Depends. The the packaging runs qmake twice: Once via
dh_auto_configure and a second time in override_dh_auto_build. While the
former picks up the host qmake, the latter uses the build qmake and thus
fails finding dependencies. Merging the calls makes x2godesktopsharing
cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru x2godesktopsharing-3.2.0.0/debian/changelog 
x2godesktopsharing-3.2.0.0/debian/changelog
--- x2godesktopsharing-3.2.0.0/debian/changelog 2018-11-28 12:09:27.0 
+0100
+++ x2godesktopsharing-3.2.0.0/debian/changelog 2018-12-31 13:07:24.0 
+0100
@@ -1,3 +1,10 @@
+x2godesktopsharing (3.2.0.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Add missing Build-Depends: qt5-qmake:native for lrelease.
++ Run the right qmake through dh_auto_configure. Run it once only.
+
+ -- Helmut Grohne   Mon, 31 Dec 2018 13:07:24 +0100
+
 x2godesktopsharing (3.2.0.0-1) unstable; urgency=medium
 
   * Initial release to Debian. (Closes: #913489).
diff --minimal -Nru x2godesktopsharing-3.2.0.0/debian/control 
x2godesktopsharing-3.2.0.0/debian/control
--- x2godesktopsharing-3.2.0.0/debian/control   2018-11-28 12:09:27.0 
+0100
+++ x2godesktopsharing-3.2.0.0/debian/control   2018-12-31 13:07:23.0 
+0100
@@ -6,6 +6,7 @@
  Mike Gabriel ,
 Build-Depends:
  debhelper-compat (= 11),
+ qt5-qmake:native,
  qtbase5-dev,
  qttools5-dev-tools,
  libqt5svg5-dev,
diff --minimal -Nru x2godesktopsharing-3.2.0.0/debian/rules 
x2godesktopsharing-3.2.0.0/debian/rules
--- x2godesktopsharing-3.2.0.0/debian/rules 2018-11-28 11:53:32.0 
+0100
+++ x2godesktopsharing-3.2.0.0/debian/rules 2018-12-31 13:07:24.0 
+0100
@@ -20,10 +20,7 @@
 
 override_dh_auto_configure:
lrelease x2godesktopsharing.pro
-   dh_auto_configure
-
-override_dh_auto_build:
-   qmake QMAKE_CFLAGS="${CPPFLAGS} ${CFLAGS}" QMAKE_CXXFLAGS="${CPPFLAGS} 
${CXXFLAGS}" QMAKE_LFLAGS="${LDFLAGS}" x2godesktopsharing.pro
+   dh_auto_configure -- QMAKE_CFLAGS="${CPPFLAGS} ${CFLAGS}" 
QMAKE_CXXFLAGS="${CPPFLAGS} ${CXXFLAGS}" QMAKE_LFLAGS="${LDFLAGS}" 
x2godesktopsharing.pro
 
 override_dh_install:
install -m 644 x2godesktopsharing 
$(CURDIR)/debian/x2godesktopsharing/usr/bin/

Bug#914154: CVE-2018-19358

Control: severity -1 normal
Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-keyring/issues/5

I am downgrading the severity but keeping the bug open in accordance
with how this reported issue is being handled so far in GNOME and
Ubuntu.

https://launchpad.net/bugs/1780365

Thanks,
Jeremy Bicha

Bug#917196: transition: qtbase-opensource-src

2018-12-31 Thread Mattia Rizzolo

On Sun, Dec 30, 2018 at 11:08:52PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> - Somehow make ci.debian.net understand that the latest kdeconnect upload 
> fixed a buggy test (so not really a qt issue, just a race condition in the 
> test)

Instead of messing with this, please just wait 2 days for kdeconnect to
migrate to testing, then plain retry the kdeconnect test.  That's the
correct course of action to take to prevent any kind of breakage (even
if it's just a faulty test) to enter testing.

-- 
regards,
Mattia Rizzolo

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

signature.asc
Description: PGP signature

Bug#917895: RFS: rmlint/2.8.0-1

2018-12-31 Thread Carlos Maddela

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "rmlint"

 * Package name: rmlint
   Version : 2.8.0-1
   Upstream Author : Christopher Pahl 
 * URL : https://rmlint.readthedocs.io/
 * License : GPL-3+
   Section : utils

  It builds these binary packages:

rmlint - Extremely fast tool to remove filesystem lint
 rmlint-doc - HTML documentation for rmlint
 rmlint-gui - GTK+ frontend to rmlint

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

  https://mentors.debian.net/package/rmlint


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

dget -ux 
https://mentors.debian.net/debian/pool/main/r/rmlint/rmlint_2.8.0-1.dsc

  Changes since the last upload:

  * New upstream release [2.8.0].
  * debian/patches/*:
- Rebase patches.
- Drop manpage-typos.patch already applied upstream.
- Add doco-typos.patch to fix typos in documentation.
- Drop parameterized-workaround.patch, which is no longer
  necessary.
  * Add dependency on packaged version of Vollkorn desktop font,
so that its use in HTML docs may be restored.  Thanks to
Adam Borowski for suggestion.
  * Add debian/gbp.conf.
  * debian/control:
- Update Vcs-* to salsa.debian.org.
- Remove unnecessary Testsuite field.
- Set "Rules-Requires-Root: no".
- Indicate compliance with Debian Policy 4.3.0.
- Update build dependencies.
  * Update lintian override to debian-watch-does-not-check-gpg-signature.
  * Add machine-readable upstream metadata.
  * debian/rules:
- Simplify LFS build rules.
  * Update debian/copyright.
  * Build with Debhelper compat level 11.
  * Link instances of jquery to packaged version.
  * Add maintainer scripts for upgrading to and downgrading from
this version of rmlint-doc, since it has some symlink changes.


  Regards,
   Carlos Maddela

Bug#917713: [Debian-med-packaging] Bug#917713: pyscanfcs: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 3.7 returned exit code 13

2018-12-31 Thread Alex Mestiashvili

On 12/30/18 3:58 PM, Andreas Tille wrote:
> Hi,
> 
> only time for a short notice but that's actually a consequence of
> #917353.
> 
> Kind regards
> 
>   Andreas.
> 

Hi Andreas,

thank you for the update, do you think it will make sense to re-upload
pyscanfcs to trigger rebuild?

Best,
Alex

Bug#892871: tome: Segfaults when started

2018-12-31 Thread Bernhard Übelacker

Control: reassign 892871 libasan4 7.3.0-5
Control: found 892871 7.3.0-12
Control: fixed 892871 7.3.0-13

Dear Maintainer,
did some tests with snapshot.debian.org and found
that crash does not happen anymore since libasan4:i386 (7.3.0-13).

Kind regards,
Bernhard

Bug#917896: Method of setting WheelEmulation button, or ScrollButton by user not documented or does not exist.

2018-12-31 Thread Roger Gammans

Source: libinput
Severity: important
Tags: a11y

(I've tagged this as a11y as it's part of my RSI mitigation - using
an actuall scroll wheel is physically painful, so tagged as important as 
this bug makes using the machine painful)

In stretch I used to run these two commands at login to set the up
a trackball so that I could avoid needing to use the scroll wheel this
worked very well for me.

xinput set-prop "Logitech M570" "Evdev Wheel Emulation" 1
xinput set-prop "Logitech M570" "Evdev Wheel Emulation Button" 8

In buster the wayland compositor sits between X and evdev/libinput and
mask the actuall device from xinput. So it can't be used to make these
settings.

The existance of these settings is still documented in 'man 4 libinput'
and 'man 4 evdev', but no command line or other mechanism to actually
set these values is documented (except Xorg.conf).

I really like to be able to do it on the commandline as an ordinary user,
so I can swtich it on or off in pair programming situations.

I'm using the gnome destktop environment, so it possible the setting
should be part of one of the Gnome packages (and in other DEs as well
presumably)  in the new scheme things, in which case I'm sorry if
I've raised the bug against the wrong package.

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

Kernel: Linux 4.18.0-3-amd64 (SMP w/6 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF8), 
LANGUAGE=en_GB:en (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#917897: O: mcrypt -- Replacement for old unix crypt(1)

2018-12-31 Thread Mattia Rizzolo

Package: wnpp

The package mcrypt has been orphaned in version 2.6.8-2.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: mcrypt
Binary: mcrypt
Version: 2.6.8-4
Maintainer: Debian QA Group 
Uploaders: RISKO Gergely 
Build-Depends: libmcrypt-dev (>= 2.5.8), libmhash-dev (>= 0.8.16), debhelper 
(>= 7.0.50), zlib1g-dev, bzip2, gettext
Architecture: any
Standards-Version: 3.8.1
Format: 1.0
Files:
 e6f7e719df21a29424e748ecf6895eb9 1952 mcrypt_2.6.8-4.dsc
 97639f8821b10f80943fa17da302607e 471915 mcrypt_2.6.8.orig.tar.gz
 7ea7440c0a574415236b5fa4c7c1e73a 348145 mcrypt_2.6.8-4.diff.gz
Vcs-Browser: http://git.debian.org/?p=collab-maint/mcrypt.git;a=summary
Vcs-Git: git://git.debian.org/collab-maint/mcrypt.git
Checksums-Sha256:
 082eb363f08ef0a5a1a1f849ff86fd5f838b9a554190c2d22d906c241c4fe684 1952 
mcrypt_2.6.8-4.dsc
 5145aa844e54cca89ddab6fb7dd9e5952811d8d787c4f4bf27eb261e6c182098 471915 
mcrypt_2.6.8.orig.tar.gz
 57e1c205ab7d1413f74f140dc832ba0247428f83eb19fc383d62e5fd991af413 348145 
mcrypt_2.6.8-4.diff.gz
Homepage: http://mcrypt.sourceforge.net/
Package-List: 
 mcrypt deb utils optional arch=any
Directory: pool/main/m/mcrypt
Priority: source
Section: utils

Package: mcrypt
Version: 2.6.8-4
Installed-Size: 204
Maintainer: Debian QA Group 
Architecture: amd64
Depends: libc6 (>= 2.14), libmcrypt4 (>= 2.5.8-1), libmhash2 (>= 0.8.16-1), 
zlib1g (>= 1:1.1.4), bzip2
Description: Replacement for old unix crypt(1)
Description-md5: 3cca2251ad50c3dbe94701b6d6a36972
Homepage: http://mcrypt.sourceforge.net/
Tag: interface::commandline, role::program, scope::utility,
 security::cryptography
Section: utils
Priority: optional
Filename: pool/main/m/mcrypt/mcrypt_2.6.8-4_amd64.deb
Size: 63432
MD5sum: 755b784ded160ef3b008c6db34963924
SHA256: dd7b742019ee2d34f3dff370fc935c04f1c2c3d6c01534b640fd5a671e35af08


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#917898: libvisual-0.4-dev: Broken include path in pkg-config file

2018-12-31 Thread Tim Müller

Package: libvisual-0.4-dev
Version: 0.4.0-14
Severity: grave
Justification: renders package unusable

Hello,

$ pkg-config --cflags libvisual-0.4
-I/usr/include/libvisual-0.4

$ ls /usr/include/libvisual-0.4
ls: cannot access '/usr/include/libvisual-0.4': No such file or directory

Only /usr/include/libvisual exists. It's not clear to me why it was renamed, 
having the major/API version in the subdirectory name is good practice, so that 
in case a new version with a different API/ABI is made it can be installed in 
parallel.

In any case, this will cause everyone who uses this package via pkg-config 
(e.g. gst-plugins-base) to FTBFS.

Cheers
 Tim

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

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

Versions of packages libvisual-0.4-dev depends on:
ii  libc6-dev [libc-dev]  2.27-5
ii  libvisual-0.4-0   0.4.0-14
ii  pkg-config0.29-4+b1

libvisual-0.4-dev recommends no packages.

libvisual-0.4-dev suggests no packages.

-- no debconf information

Bug#917196: transition: qtbase-opensource-src

2018-12-31 Thread Lisandro Damián Nicanor Pérez Meyer

El lun., 31 dic. 2018 10:20, Mattia Rizzolo  escribió:

> On Sun, Dec 30, 2018 at 11:08:52PM -0300, Lisandro Damián Nicanor Pérez
> Meyer wrote:
> > - Somehow make ci.debian.net understand that the latest kdeconnect
> upload
> > fixed a buggy test (so not really a qt issue, just a race condition in
> the
> > test)
>
> Instead of messing with this, please just wait 2 days for kdeconnect to
> migrate to testing, then plain retry the kdeconnect test.  That's the
> correct course of action to take to prevent any kind of breakage (even
> if it's just a faulty test) to enter testing.


Sorry, but that sounds like CI for the sake of CI. The test is buggy and it
shouldn't waste other people's time. I already had enough having to fix
other people's packages.

Bug#917899: gst-plugins-ugly1.0 FTCBFS: fails finding libsidplay

2018-12-31 Thread Helmut Grohne

Source: gst-plugins-ugly1.0
Version: 1.14.4-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

gst-plugins-ugly1.0 fails to cross build from source, because its check
for -lsidplay concludes that you can never cross build the sid plugin.
dh_install subsequently fails to find the plugin. The attached patch
fixes the check, but it doesn't make gst-plugins-ugly1.0 cross
buildable. It still fails in dh_gstscancodecs and I have no idea how to
fix that. Please consider applying the attached patch anyway and close
this bug when doing so.

Helmut
--- gst-plugins-ugly1.0-1.14.4.orig/m4/gst-sid.m4
+++ gst-plugins-ugly1.0-1.14.4/m4/gst-sid.m4
@@ -16,13 +16,9 @@
 
   LIBS="-lsidplay"
 
-  AC_TRY_RUN([
-#include 
-int main()
-{ sidTune tune = sidTune(0);  }
-],
+  AC_TRY_LINK([#include ],
+[sidTune tune = sidTune(0);],
 HAVE_SIDPLAY="yes",
-HAVE_SIDPLAY="no",
 HAVE_SIDPLAY="no")
 
   LIBS="$ac_libs_safe"

Bug#917901: O: groovebasin -- music player server with a web-based user interface

2018-12-31 Thread Felipe Sateler

Package: wnpp
Severity: normal

The package groovebasin has been orphaned in version 1.4.0-2.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:


 Groove Basin runs on a server optionally connected to speakers. Guests can
 control the music player by connecting with a laptop, tablet, or smart phone.
 Further, users can stream their music libraries remotely.
 .
 Groove Basin comes with a fast, responsive web interface that supports keyboard
 shortcuts and drag drop. It also provides the ability to upload songs,
 download songs, and import songs by URL, including YouTube URLs.
 .
 Groove Basin supports Dynamic Mode which automatically queues random songs,
 favoring songs that have not been queued recently.
 .
 Groove Basin automatically performs ReplayGain scanning on every song using
 the EBU R128 loudness standard, and automatically switches between track
 and album mode.
 .
 Groove Basin supports the MPD protocol, which means it is compatible with MPD
 clients. There is also a more powerful Groove Basin protocol which you can
 use if the MPD protocol does not meet your needs.
 .
 Groove Basin supports Last.fm scrobbling.

Bug#917900: stretch-pu: package libssh/0.7.3-2+deb9u2

2018-12-31 Thread Salvatore Bonaccorso

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

Hi,

The update for libssh in DSA-4322-1 introduced a regression which
breaks server-side keyboard-interactive authentication. The issue was
reported by Martin Pitt in #913870.

As this is more a special case we want to avoid to issue another DSA
(regression update) for this specific issue, but as it was introduced
in a security update we should have a fix for it in an upcoming point
release.

For that I have cherry-picked the two needed patches and i have tested
the resulting packages with the reproducer case as provided by Martin
in the upstream issue https://bugs.libssh.org/T117 .

Following the new allowed procedure, and as the changes were minimal
enough I have already uploaded the package, and attached is the
corresponding debdiff for further review.

Could you accept the changes for an upcoming point release?

Regards,
Salvatore
diff -Nru libssh-0.7.3/debian/changelog libssh-0.7.3/debian/changelog
--- libssh-0.7.3/debian/changelog   2018-10-16 21:18:05.0 +0200
+++ libssh-0.7.3/debian/changelog   2018-12-31 14:47:15.0 +0100
@@ -1,3 +1,11 @@
+libssh (0.7.3-2+deb9u2) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix broken server-side keyboard-interactive authentication.
+Thanks to Martin Pitt (Closes: #913870)
+
+ -- Salvatore Bonaccorso   Mon, 31 Dec 2018 14:47:15 +0100
+
 libssh (0.7.3-2+deb9u1) stretch-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru 
libssh-0.7.3/debian/patches/0009-server-Set-correct-state-after-sending-INFO_REQUEST-.patch
 
libssh-0.7.3/debian/patches/0009-server-Set-correct-state-after-sending-INFO_REQUEST-.patch
--- 
libssh-0.7.3/debian/patches/0009-server-Set-correct-state-after-sending-INFO_REQUEST-.patch
 1970-01-01 01:00:00.0 +0100
+++ 
libssh-0.7.3/debian/patches/0009-server-Set-correct-state-after-sending-INFO_REQUEST-.patch
 2018-12-31 14:47:15.0 +0100
@@ -0,0 +1,30 @@
+From: Meng Tan 
+Date: Wed, 17 Oct 2018 14:50:08 +0200
+Subject: server: Set correct state after sending INFO_REQUEST (Kbd
+ Interactive)
+Origin: 
https://git.libssh.org/projects/libssh.git/commit/?id=734e3ce6747a5ed120b93a1ff253b3fde5f20024
+Bug: https://bugs.libssh.org/T117
+Bug-Debian: https://bugs.debian.org/913870
+
+Signed-off-by: Meng Tan 
+Reviewed-by: Andreas Schneider 
+(cherry picked from commit 4ea46eecce9f4e676150fe27fec34e1570b70ace)
+---
+ src/server.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/server.c b/src/server.c
+index a078e7afc7f1..b1f01a86842c 100644
+--- a/src/server.c
 b/src/server.c
+@@ -976,6 +976,7 @@ int ssh_message_auth_interactive_request(ssh_message msg, 
const char *name,
+ msg->session->kbdint->prompts = NULL;
+ msg->session->kbdint->echo = NULL;
+   }
++  msg->session->auth.state = SSH_AUTH_STATE_INFO;
+ 
+   return rc;
+ }
+-- 
+2.11.0
+
diff -Nru libssh-0.7.3/debian/patches/0010-server-Fix-compile-error.patch 
libssh-0.7.3/debian/patches/0010-server-Fix-compile-error.patch
--- libssh-0.7.3/debian/patches/0010-server-Fix-compile-error.patch 
1970-01-01 01:00:00.0 +0100
+++ libssh-0.7.3/debian/patches/0010-server-Fix-compile-error.patch 
2018-12-31 14:47:15.0 +0100
@@ -0,0 +1,26 @@
+From: Andreas Schneider 
+Date: Wed, 24 Oct 2018 19:57:17 +0200
+Subject: server: Fix compile error
+Origin: 
https://git.libssh.org/projects/libssh.git/commit/?id=7ad80ba1cc48f7af1f192692d100a6255d97b843
+
+Signed-off-by: Andreas Schneider 
+---
+ src/server.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/server.c b/src/server.c
+index b1f01a86842c..400b04a7e61b 100644
+--- a/src/server.c
 b/src/server.c
+@@ -976,7 +976,7 @@ int ssh_message_auth_interactive_request(ssh_message msg, 
const char *name,
+ msg->session->kbdint->prompts = NULL;
+ msg->session->kbdint->echo = NULL;
+   }
+-  msg->session->auth.state = SSH_AUTH_STATE_INFO;
++  msg->session->auth_state = SSH_AUTH_STATE_INFO;
+ 
+   return rc;
+ }
+-- 
+2.11.0
+
diff -Nru libssh-0.7.3/debian/patches/series libssh-0.7.3/debian/patches/series
--- libssh-0.7.3/debian/patches/series  2018-10-16 21:18:05.0 +0200
+++ libssh-0.7.3/debian/patches/series  2018-12-31 14:47:15.0 +0100
@@ -6,6 +6,8 @@
 0006-CVE-2018-10933-Check-channel-state-when-OPEN_FAILURE.patch
 0007-CVE-2018-10933-Introduced-packet-filtering.patch
 0008-CVE-2018-10933-Add-tests-for-packet-filtering.patch
+0009-server-Set-correct-state-after-sending-INFO_REQUEST-.patch
+0010-server-Fix-compile-error.patch
 1001_error-msg-typo-fix.patch
 1003-custom-lib-names.patch
 2003-disable-expand_tilde_unix-test.patch

Bug#917457: libilmbase23: 2.3.0-3 bumped so name without transition (breaks digikam, gimp, ...)

2018-12-31 Thread Matteo F. Vescovi

Control: reopen -1

On 2018-12-31 at 11:45 (+01), Eric Valette wrote:

[...]

> Its amazing how people think they can put garbarge in experimental and
> still expecting code to be tested and surprised to discover breakage
> only once they reach unstable.
>
> Breaking gimp,digikam is a major failure...
>
> I do not see the problem with letting the bug and say will not will
> before transition.

So, let's reopen this bug report so that:

 - I can concentrate on its transition
 - you can slumber all night long ;-)

Cheers.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#917902: linux-image-4.19.0-1-amd64: Strange X11/Firefox slowdowns/hangs with kernel 4.19

2018-12-31 Thread Uwe Hermann

Package: src:linux
Version: 4.19.13-1
Severity: normal

Hi,

I'm experiencing weird slowdowns/hangs in X11 with
linux-image-4.19.0-1-amd64, reproducible for me with 4.19.13+1 and also
with 4.19.12-1 before that. I didn't test any 4.19.x older than that.

There are no problems when booting the system and there are no problems
when logging into a text console as far as I can tell. When starting
X11 via startx from a text-console there are no problems yet, either.

I can start two xterms, a Gimp, or other programs fine, and I can switch
from one to the other just fine.

The problems start as soon as I start Firefox (64.0-1 currently). When clicking
on e.g. "new tab" it takes ages to make a new tab, or switch from one tab to 
another
or load a website (easily 40 seconds or more). It also takes ages to switch 
from Firefox
to an xterm or Gimp that's already running. Even if the focus is on an xterm 
currently
and I click into another xterm to give it focus, that also takes 40 seconds or 
so.

The mouse cursor itself behaves normal (not slowed down or laggy or anything).

I tried wiping ~/.mozilla to get a default profile, that has the same
problems, though.

After starting X11 only one dmesg item gets logged as far as I can see:

[ 1196.886257] [drm] DM: FBC alloc 5094400

When I "killall -9 firefox" from a text console I get this:

[ 3136.433738] show_signal_msg: 18 callbacks suppressed
[ 3136.433744] Chrome_~dThread[4160]: segfault at 0 ip 7f5610585d01 sp 
7f560a828ab0 error 6
[ 3136.434676] Chrome_~dThread[4141]: segfault at 0 ip 7fe14caedd01 sp 
7fe146da0ab0 error 6
[ 3136.435053]  in libxul.so[7f561056f000+3e8f000]
[ 3136.437242]  in libxul.so[7fe14cad7000+3e8f000]
[ 3136.441992] Code: 15 d4 dd ae 04 48 89 10 c7 04 25 00 00 00 00 e7 09 00 00 
e8 61 53 ff ff 90 48 8b 05 21 7f f9 05 48 8d 0d 1a de ae 04 48 89 08  04 25 
00 00 00 00
6d 0a 00 00 e8 3f 53 ff ff e8 2a f3 ff ff 48
[ 3136.447029] Code: 15 d4 dd ae 04 48 89 10 c7 04 25 00 00 00 00 e7 09 00 00 
e8 61 53 ff ff 90 48 8b 05 21 7f f9 05 48 8d 0d 1a de ae 04 48 89 08  04 25 
00 00 00 00
6d 0a 00 00 e8 3f 53 ff ff e8 2a f3 ff ff 48
[ 3136.453812] Chrome_~dThread[4268]: segfault at 0 ip 7fd87c4ddd01 sp 
7fd876790ab0 error 6
[ 3136.453815] Chrome_~dThread[4217]: segfault at 0 ip 7f3e87c5dd01 sp 
7f3e81f00ab0 error 6 in libxul.so[7f3e87c47000+3e8f000]
[ 3136.455530]  in libxul.so[7fd87c4c7000+3e8f000]
[ 3136.457170] Code: 15 d4 dd ae 04 48 89 10 c7 04 25 00 00 00 00 e7 09 00 00 
e8 61 53 ff ff 90 48 8b 05 21 7f f9 05 48 8d 0d 1a de ae 04 48 89 08  04 25 
00 00 00 00
6d 0a 00 00 e8 3f 53 ff ff e8 2a f3 ff ff 48
[ 3136.458867] Code: 15 d4 dd ae 04 48 89 10 c7 04 25 00 00 00 00 e7 09 00 00 
e8 61 53 ff ff 90 48 8b 05 21 7f f9 05 48 8d 0d 1a de ae 04 48 89 08  04 25 
00 00 00 00
6d 0a 00 00 e8 3f 53 ff ff e8 2a f3 ff ff 48

Even after killing Firefox all other X11 stuff is still horribly slow or
hangs, though. I have to "killall -9 Xorg" and re-run "startx" to get a
working X11 without hangs again.

My current workaround is to boot into an older linux-image-4.18.0-3-amd64
(4.18.20-2) that I've luckily kept around after the dist-upgrade that
installed the current 4.19.x kernel image.

Even though this initially kinda looked like it might be a Firefox bug, the
fact that I can reproducibly boot into 4.18 and everything works fine,
but when booting into 4.19 the issues are reproducible every time,
suggests that it might be kernel or graphics driver related (?)

Cheers, Uwe.

-- Package-specific info:
** Version:
Linux version 4.19.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.2.0 (Debian 8.2.0-13)) #1 SMP Debian 4.19.13-1 (2018-12-30)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-1-amd64 root=/dev/mapper/e565--vg-root ro apparmor=1 
security=apparmor vsyscall=emulate

** Not tainted

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

** Model information
sys_vendor: LENOVO
product_name: 20EY000TGE
product_version: ThinkPad E565
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: R01ET27W (1.07 )
board_vendor: LENOVO
board_name: 20EY000TGE
board_version: Not Defined

** Loaded modules:
r8169
libphy
nf_log_ipv6
nf_log_ipv4
nf_log_common
nft_log
nft_counter
nft_ct
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
libcrc32c
cpufreq_conservative
cpufreq_userspace
cpufreq_powersave
nf_tables_set
nf_tables
nfnetlink
binfmt_misc
amdkfd
amdgpu
wmi_bmof
edac_mce_amd
kvm_amd
ccp
chash
gpu_sched
snd_hda_codec_conexant
rng_core
ttm
snd_hda_codec_generic
snd_hda_codec_hdmi
kvm
drm_kms_helper
irqbypass
joydev
evdev
serio_raw
pcspkr
drm
snd_hda_intel
fam15h_power
snd_hda_codec
k10temp
snd_hda_core
snd_hwdep
i2c_algo_bit
sp5100_tco
snd_pcm
sg
snd_timer
thinkpad_acpi
nvram
snd
wmi
soundcore
rfkill
ac
battery
video
pcc_cpufreq
button
acpi_cpufreq
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
algif_skcipher
af_alg
dm_crypt
dm_mod
hid_generic
sr_mod

Bug#917903: init-premount/dropbear reads /etc/dropbear/config instead of /etc/dropbear-initramfs/config

2018-12-31 Thread Arkay Haitsch

Package: dropbear-initramfs
Version: 2016.74-5+deb9u1

the dropbear initramfs-tools init-premount script does include the
config file of the post-initramfs dropbear.

This is likely not desired because when you run dropbear in initramfs
you will usually use a different config (like different port). Of
course there are different options to work around this, e.g.
/etc/initramfs-tools/initramfs.conf, but in my opinion
dropbear-initramfs should use its own config from
/etc/dropbear-initramfs/ instead of relying on the system one from
/etc/dropbear/.

# dpkg -S /usr/share/initramfs-tools/scripts/init-premount/dropbear
dropbear-initramfs: /usr/share/initramfs-tools/scripts/init-premount/dropbear

# dpkg -l dropbear-initramfs
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name
Version Architecture
 Description
+++--===-===-==
ii  dropbear-initramfs
2016.74-5+deb9u1all
 lightweight SSH2 server and client - initramfs integration

# cat /etc/debian_version; uname -a
9.6
Linux debian 4.9.0-8-marvell #1 Debian 4.9.130-2 (2018-10-27) armv5tel GNU/Linux



*** dropbear2018-08-24 02:08:38.0 +0200
--- dropbear.fixed  2018-12-31 15:17:05.569984908 +0100
***
*** 38,44 
  DROPBEAR_OPTIONS="$PKGOPTION_dropbear_OPTION"
  fi
  if [ -e /etc/dropbear/config ]; then
! . /etc/dropbear/config
  fi
  . /scripts/functions

--- 38,44 
  DROPBEAR_OPTIONS="$PKGOPTION_dropbear_OPTION"
  fi
  if [ -e /etc/dropbear/config ]; then
! . /etc/dropbear-initramfs/config
  fi
  . /scripts/functions

Bug#915337: rr: baseline violation on i386

2018-12-31 Thread Adrian Bunk

On Sun, Dec 02, 2018 at 11:03:17PM +0100, Stephen Kitt wrote:
> Hi Adrian,

Hi Stephen,

> On Sun, 02 Dec 2018 23:01:23 +0200, Adrian Bunk  wrote:
> > MMX and SSE are not part of the i386 baseline.
> 
> From the package description:
> 
>  rr is incompatible with ptrace hardening, and currently only supports
>  Intel CPUs with Nehalem or later microarchitectures.
> 
> All supported CPUs support MMX and SSE. The package is useful on i386, but I
> can drop it if you think I shouldn’t ship it there.

the cleanest solution would be dropping on i386.

Are there any restriction regarding using amd64 rr with i386 binaries?
During some basic testing this seemed to work for me.

> Regards,
> 
> Stephen

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#917904: tightvncserver does not ask for password set by vncpasswd

2018-12-31 Thread Jan Christoph Terasa

Package: tightvncserver
Version: 1:1.3.9-9
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

I installed tightvncserver on my VPS machine via apt. This did set up 
tightvncserver as an alternative for vncserver. Using a normal user account and
starting vncserver for the first time asks for a 8-letter password. My 
assumption
is this password will be used to authenticate users when connecting to the vnc
server.

After starting the vnc server via vncserver script, it is served on port 5901. 
On the client machine I use vinagre to connect to the server on port 5901. When
connecting, I am not asked for a password, but rather directly taken to the X
session. I would have expected the server to ask for the password I specified
earlier.

As a workaround, to ensure the integrity of the system, I set up iptable rules 
to
not allow direct WAN connections to this port, but only allow local connections
and use an SSH tunnel for connecting to the vnc server.


kind regards,
Christoph


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

Kernel: Linux 4.14.17--std-ipv6-64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages tightvncserver depends on:
ii  libc62.27-8
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  perl 5.28.0-3
ii  x11-common   1:7.7+19
ii  x11-utils7.7+4
ii  xauth1:1.0.10-1
ii  xserver-common   2:1.20.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages tightvncserver recommends:
ii  x11-xserver-utils  7.7+8
ii  xfonts-base1:1.0.4+nmu1

Versions of packages tightvncserver suggests:
pn  tightvnc-java  

-- no debconf information

Bug#847613: ITP: nextcloud-client -- desktop client for nextcloud

2018-12-31 Thread Sandro Knauß

Hey,

> With todays upload of owncloud-client, I got a big fat warning that
> connecting to nextcloud is no longer supported

Argh they now really start fighting against each other - WTF?  If nextcloud-
dektop won't make it to Debian, I'll patch this out.

hefee





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

Bug#917713: [Debian-med-packaging] Bug#917713: pyscanfcs: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 3.7 returned exit code 13

2018-12-31 Thread Andreas Tille

On Mon, Dec 31, 2018 at 02:15:21PM +0100, Alex Mestiashvili wrote:
> 
> thank you for the update, do you think it will make sense to re-upload
> pyscanfcs to trigger rebuild?

There is no need to rebuild since the FTBFS was just on some third
party machine.  Just do a local rebuild and if you can confirm that
the package builds again send an e-mail to
917713-d...@bugs.debian.org
to close the bug.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#917896: Acknowledgement (Method of setting WheelEmulation button, or ScrollButton by user not documented or does not exist.)

2018-12-31 Thread Roger Gammans

Having spend three days without luck looking for settings, I have
another look in dconf after sending the report  and find :

 org/gnome/desktop/peripherals/scroll-wheel-emulation-button

So It a documentation issue at worst..

-- 
Roger Gammans 
Gamma Science Ltd. (GB Nr. 07356014 )

Bug#874751: [Pkg-xen-devel] Bug#874751: Processed: severity of 874751 is grave

2018-12-31 Thread Hans van Kranenburg

Hi,

So, this is about:
  https://packages.debian.org/source/sid/blktap-dkms

Related (also with a long living ftbfs bug):
  https://packages.debian.org/source/sid/blktap

I can already tell that while the Debian Xen team is listed as
maintainer, the packages are not anywhere on the radar of the current team.

It seems the packages were added as part of packaging "The Xen Cloud
Platform (XCP)".

According to...
  https://www.xenproject.org/developers/teams/xapi.html
... "Before June 2013, XenServer was not fully open sourced and a subset
of XenServer called XCP was made available [...]"

...and...

  https://wiki.xen.org/wiki/Blktap2
"Xen blktap2 is a successor to the old blktap1 disk backend driver.
[...] Xen blktap2 support is included in the Xen version 4.0 released in
Apr 2010."

...the XCP project was stopped in 2013 and this v1 of blktap has been
obsoleted upstream.

So, since this dkms was already not usable since Wheezy... What about
solving this by getting both of them removed from Debian?

The blktap source package also builds a library to access vhd files...
  https://packages.debian.org/sid/libvhd0
...but there seems to be an alternative for that, if anyone was using it...
  https://packages.debian.org/sid/libvhdi1

Hans

Bug#917905: Fails to build for non-current kernel version

Package: xtables-addons-source
Version: 3.2-1
Severity: important

When running kernel version 4.18.0-3-amd64 and building for
4.19.0-1-amd64, the build fails:

/usr/bin/make -C /lib/modules/4.19.0-1-amd64/build M=/usr/src/modules/xtables-ad
dons/extensions XA_ABSTOPSRCDIR=/usr/src/modules/xtables-addons XA_TOPSRCDIR=/us
r/src/modules/xtables-addons DEPMOD=/bin/true clean
make[2]: Entering directory '/usr/src/linux-headers-4.19.0-1-amd64'
make[2]: Leaving directory '/usr/src/linux-headers-4.19.0-1-amd64'
dh_prep
dh_clean
for templ in ; do \
cp $templ `echo $templ | sed -e 's/_KVERS_/4.19.0-1-amd64/g'` ; \
  done
for templ in `ls debian/*.modules.in` ; do \
test -e ${templ%.modules.in}.backup || cp ${templ%.modules.in} ${templ%.modu
les.in}.backup 2>/dev/null || true; \
sed -e 's/##KVERS##/4.19.0-1-amd64/g ;s/#KVERS#/4.19.0-1-amd64/g ; s/_KVERS_
/4.19.0-1-amd64/g ; s/##KDREV##/4.19.13-1/g ; s/#KDREV#/4.19.13-1/g ; s/_KDREV_/
4.19.13-1/g  ' < $templ > ${templ%.modules.in}; \
  done
dh binary-arch
...
checking kernel version that we will build against... make[2]: *** 
/lib/modules/4.18.0-3-amd64/build: No such file or directory.  Stop.
0.0.0.0 in /lib/modules/4.18.0-3-amd64/build
WARNING: That kernel version is not officially supported.
...
dh_auto_build -- -C /lib/modules/4.19.0-1-amd64/build M=/usr/src/modules/xtables
-addons/extensions XA_ABSTOPSRCDIR=/usr/src/modules/xtables-addons XA_TOPSRCDIR=
/usr/src/modules/xtables-addons DEPMOD=/bin/true
make[3]: Entering directory '/usr/src/linux-headers-4.19.0-1-amd64'
...
make[3]: Leaving directory '/usr/src/linux-headers-4.19.0-1-amd64'
make[2]: Leaving directory '/usr/src/modules/xtables-addons'
make[2]: Entering directory '/usr/src/modules/xtables-addons'
Making check in extensions
make[3]: Entering directory '/usr/src/modules/xtables-addons/extensions'
make -f ../Makefile.iptrules all;
Xtables-addons 3.2 - Linux make[4]: Entering directory 
'/usr/src/modules/xtables-addons/extensions'
make[4]: *** /lib/modules/4.18.0-3-amd64/build: No such file or directory.  
Stop.
make[4]: Leaving directory '/usr/src/modules/xtables-addons/extensions'
make[3]: *** [Makefile:465: modules] Error 2
...

So building the modules is actually successful, but the following
"make check" step fails and ./configure goes wrong because they are
defaulting to the currently running kernel version.

I think you need to add override_dh_auto_configure and
override_dh_auto_test targets to debian/rules that will pass the
target kernel version to the upstream build system.

Ben.

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

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

Versions of packages xtables-addons-source depends on:
ii  bzip2 1.0.6-9
ii  debhelper 12
pn  iptables-dev  
ii  make  4.2.1-1.2
ii  pkg-config0.29-4+b1

Versions of packages xtables-addons-source recommends:
ii  module-assistant  0.11.10

xtables-addons-source suggests no packages.

Bug#917906: linux-image-4.17.0-1-amd64 (and onward): CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1 might cause long hangs for user

2018-12-31 Thread Arnaud Rebillout

Package: src:linux
Version: 4.17.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear kernel maintainers,

starting from `linux-image-4.17.0-1-amd64`, the debian kernel comes
with `CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1` (it was set to `0` before).

I wonder if this change was intended, for two reasons.

1. According to the documentation at [1]:

``CONFIG_SND_HDA_POWER_SAVE_DEFAULT`` Kconfig options. Setting this
to 1 (the minimum value) isn't recommended because many applications
try to reopen the device frequently. 10 would be a good choice for
normal operations.

2. Moreover, grepping through the config shows that this change was
only applied to `CONFIG_SND_HDA`, not to `CONFIG_SND_AC97`.

$ grep POWER_SAVE_DEFAULT config-4.18.0-3-amd64
CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1

In any case, this breaks things on my laptop. In short, the function
call `snd_pcm_open()` (to open an audio device), which used to take
around 1 ms, now takes an average of 40 ms, with maximum peaks measured
to 3 seconds.

What's unfortunate is that this function might be called from within
the GTK+ main loop, synchronously, causing apps like the terminal or
a text editor to hang until the call returns. And this function is
called A LOT, due to event sounds.

I described this a bit more in details on the ALSA mailing list at [2].

The kernel documentation at [1] mentions:

Also, it often takes certain time to wake up from the
power-down to the active state. These are often hardly to fix, so
don't report extra bug reports unless you have a fix patch ;-)

Reading that, and after discovering that event sounds are implemented
synchronously (well, at least using GNOME/Wayland), I wonder if
`CONFIG_SND_HDA_POWER_SAVE_DEFAULT` shouldn't be reverted to 0.

Thanks,

Arnaud

[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sound/designs/powersave.rst
[2]:
http://mailman.alsa-project.org/pipermail/alsa-devel/2018-December/143167.html

-BEGIN PGP SIGNATURE-

iQJTBAEBCgA9FiEE0Kl7ndbut+9n4bYs5yXoeRRgAhYFAlwqLR8fHGFybmF1ZC5y
ZWJpbGxvdXRAY29sbGFib3JhLmNvbQAKCRDnJeh5FGACFuSTD/9dmrbRgG3FfSue
0NPIwSNhV7++OqFZKt9mn3tX9XXrIJnx9SdJLAZ+Tt3R7/uwocdutGUZTT23e2kc
BUoeEPflIevoOOE6ZetdLuUotqa3FvmJMfx/odlGu2zehGkwPzjIJJ3mZ8glYTj2
+/aUi6N4GMgesqhstAAeKgz3/pfz6gWr1uf6fy+OjPSzk+xBU2mOUBvh+Rs34tch
KHUO2ysZ5RwJ73cnqsJcfv4krnF4Rojl5ooijNc5cldxfBdZsN6mfljOnCOFzkgZ
TqG+g0zlY8aGxriDxJwfM1gR9RGXbrVAD++N/KnulSzVK/r4osdtawrnVnbZ38rq
zBQ1O+WvXdWGsERj0Hn7PWHxO6eMo9RBYIFAanwbJceIyiJYxm+Zr3xBtVefEA7D
e5aWUL0AvZpA2ma1bs3xW1IhaGst8mhACu/ef+qbZBqenUfUdfOQ3SNf7wqJQvEe
u1u1O/3JC7qs+By8Kz9hBaIkblZF4IgJ9kCllg9EckTLkg2vU9rR0vyr+2BIidDj
LjmkeFcul52bE1K/azGk+Xjj1L8iGPVFiLrzPjgZOJAI7bkFIFSLYAl8Ucw3p4x5
QGq7yAFLbUgcUJ7MyvRFOEYrRjb/xExtdyG7an8U3IS/1P85FdxuHTQTGtWIPUf7
zZx7p3/ABpZzkT2cM+xRJOMoOzwNeg==
=aX+w
-END PGP SIGNATURE-

Bug#917907: RM: blktap -- RoQA; obsolete, FTBFS

Package: ftp.debian.org
Severity: normal

blktap was replaced by blktap2  in
current versions of Xen.  This package FTBFS for a year (#883212).
The related kernel module (blktap-dkms package) was also broken by
kernel API changes around the same time.

Ben.

Bug#874751: [Pkg-xen-devel] Bug#874751: Processed: severity of 874751 is grave

On Mon, 2018-12-31 at 15:49 +0100, Hans van Kranenburg wrote:
[...]
>   https://wiki.xen.org/wiki/Blktap2
> "Xen blktap2 is a successor to the old blktap1 disk backend driver.
> [...] Xen blktap2 support is included in the Xen version 4.0 released in
> Apr 2010."
> 
> ...the XCP project was stopped in 2013 and this v1 of blktap has been
> obsoleted upstream.
> 
> So, since this dkms was already not usable since Wheezy... What about
> solving this by getting both of them removed from Debian?
[...]

OK, I've opened RM bugs for these two.

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat. - John Lehman




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

Bug#917908: RM: blktap-dkms -- RoQA; obsolete, FTBFS

Package: ftp.debian.org
Severity: normal

blktap was replaced by blktap2  in
current versions of Xen.  It hasn't been possible to build a kernel
module with this package since Linux 4.12 (#874751), over a year ago.
The related userspace code (blktap package) was also broken by
glibc changes around the same time.

Ben.

Bug#838344: Acknowledgement (linux-image-4.6.0-1-amd64: allow a patch that makes elder radeon cards UltraHD ready)

2018-12-31 Thread Elmar Stellnberger

  It is now about two years ago that I have developed a patch to set 
the TMDS frequency for Radeon cards. A similar patch for Nouveau and for 
the Windows ATI driver does already exist. The patch has been proven to 
work well in the long term at least with the Radeon R5 230 and the 
Radeon HD 6570. Other people have given positive reports as well (Radeon 
HD 6970, Radeon HD 6770, see: 
https://bugs.freedesktop.org/show_bug.cgi?id=93885#c24) though not as 
extensively as John Reinhard with the HD 6570.
  Many cards do not show heat issues at all when overclocking the TMDS. 
- and even if a card did Nouveau developers have told me that it would 
hardly be possible to damage a card with this. The reason why Radeon 
developers did not want to assimilate it seems to be business interest 
as they have told me frankly. The patch is safe and has been proven 
useful (since then many people with positive experience have linked to 
my site) - so why do we not include it for Debian?

Bug#917909: [text-based installer] right-to-left writing direction broken

Package: debian-installer
Severity: important


While investigating an old bugreport regarding Hebrew, I found that RTL writing
direction is completely broken in the text-based installer
(writing direction seems left-to-right and text is aligned to the left).

That's also the case in Stretch, while it was ok in Jessie installer!

I will sent some screenshots to the bug later, to document it.


As we are near the freeze for Buster, it would probably be the best way to 
work around this, if we disable the RTL langugages completely in the text-based 
installer (since they are also supported there and it seems ok in the 
graphical installer) ?

This affects:   Arabic
Hebrew
Persian
Uyghur



I will point relevant people to this bug, to get opinions from mother-tongue 
speakers | readers ...



Holger



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

Bug#917910: plasma-desktop: separate binary package for xembedsniproxy

2018-12-31 Thread Clint Adams

Source: plasma-desktop
Version: 4:5.14.3-1

Please split xembedsniproxy out into its own binary package.  I
don't want the entirety of plasma-desktop and all its dependencies
just for this single utility.

Bug#833268: task-lxde-desktop: LXDE desktop does not include a web browser

Control: reassign -1 lxde


Jonathan Dowland  wrote:
> If I were to try and
> summarize it as succinctly as possible, it would be
> 
>   "LXDE desktop include an icon to launch a graphical web browser,
>   but does not depend upon one."
> 
> And that's still the situation since the virtual package www-browser ≠ a
> graphical one, since it can be satisfied by w3m or links and others.

Therefore forwarding to LXDE people.

@lxde: if you want to get that solved by a change in the xlde task, let me 
know.


Regards
Holger

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

Bug#909612: fakechroot: does not support renameat2

2018-12-31 Thread Johannes Schauer

Hi,

On Tue, 25 Sep 2018 23:05:45 +0200 Johannes 'josch' Schauer  
wrote:
> fakechroot currently doesn't support the renameat2 system call. This means
> that the 'mv' from coreutils in current Debian unstable and testing will not
> work. This in turn doesn't make fakechroot very useful for using it with
> Debian unstable and testing. Older Debian releases still work though.
> 
> I will leave the decision whether you consider the lack of 'mv' inside
> fakechroot an RC bug or not up to you.

attached patch fixes the problem.

I could NMU fakechroot with the patch. Would that be okay for you?

Thanks!

cheers, josch
--- a/config.h.in
+++ b/config.h.in
@@ -526,6 +526,9 @@
 /* Define to 1 if you have the `renameat' function. */
 #undef HAVE_RENAMEAT
 
+/* Define to 1 if you have the `renameat2' function. */
+#undef HAVE_RENAMEAT2
+
 /* Define to 1 if you have the `revoke' function. */
 #undef HAVE_REVOKE
 
--- a/configure.ac
+++ b/configure.ac
@@ -252,6 +252,7 @@ AC_CHECK_FUNCS(m4_normalize([
 removexattr
 rename
 renameat
+renameat2
 revoke
 rmdir
 scandir
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -135,6 +135,7 @@ libfakechroot_la_SOURCES = \
 removexattr.c \
 rename.c \
 renameat.c \
+renameat2.c \
 revoke.c \
 rmdir.c \
 rpl_lstat.c \
--- /dev/null
+++ b/src/renameat2.c
@@ -0,0 +1,42 @@
+/*
+libfakechroot -- fake chroot environment
+Copyright (c) 2010, 2013 Piotr Roszatycki 
+
+This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.
+
+This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Lesser General Public License for more details.
+
+You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307  USA
+*/
+
+
+#include 
+
+#ifdef HAVE_RENAMEAT2
+
+#define _ATFILE_SOURCE
+#include "libfakechroot.h"
+
+
+wrapper(renameat2, int, (int olddirfd, const char * oldpath, int newdirfd, const char * newpath, unsigned int flags))
+{
+char tmp[FAKECHROOT_PATH_MAX];
+debug("renameat2(%d, \"%s\", %d, \"%s\", %d)", olddirfd, oldpath, newdirfd, newpath, flags);
+expand_chroot_path_at(olddirfd, oldpath);
+strcpy(tmp, oldpath);
+oldpath = tmp;
+expand_chroot_path_at(newdirfd, newpath);
+return nextcall(renameat2)(olddirfd, oldpath, newdirfd, newpath, flags);
+}
+
+#else
+typedef int empty_translation_unit;
+#endif


signature.asc
Description: signature

Bug#915344: openfoam: diff for NMU version 4.1+dfsg1-2.3

2018-12-31 Thread Adrian Bunk

Control: tags 915344 + patch
Control: tags 915344 + pending

Dear maintainer,

I've prepared an NMU for openfoam (versioned as 4.1+dfsg1-2.3) and 
uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

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

diff -Nru openfoam-4.1+dfsg1/debian/changelog openfoam-4.1+dfsg1/debian/changelog
--- openfoam-4.1+dfsg1/debian/changelog	2018-08-12 13:41:17.0 +0300
+++ openfoam-4.1+dfsg1/debian/changelog	2018-12-31 10:22:02.0 +0200
@@ -1,3 +1,11 @@
+openfoam (4.1+dfsg1-2.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for FTBFS with glibc 2.28,
+thanks to Juhani Numminen. (Closes: #915344)
+
+ -- Adrian Bunk   Mon, 31 Dec 2018 10:22:02 +0200
+
 openfoam (4.1+dfsg1-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru openfoam-4.1+dfsg1/debian/patches/90_glibc.patch openfoam-4.1+dfsg1/debian/patches/90_glibc.patch
--- openfoam-4.1+dfsg1/debian/patches/90_glibc.patch	1970-01-01 02:00:00.0 +0200
+++ openfoam-4.1+dfsg1/debian/patches/90_glibc.patch	2018-12-31 10:22:02.0 +0200
@@ -0,0 +1,24 @@
+From 3fba921563fdb4436f73ace89fe9762474907953 Mon Sep 17 00:00:00 2001
+From: Henry Weller 
+Date: Tue, 25 Jul 2017 00:03:09 +0100
+Subject: POSIX::fileStat: Avoid warning from gcc
+
+---
+ src/OSspecific/POSIX/fileStat.C | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/OSspecific/POSIX/fileStat.C b/src/OSspecific/POSIX/fileStat.C
+index 37994508c..9139a3469 100644
+--- a/src/OSspecific/POSIX/fileStat.C
 b/src/OSspecific/POSIX/fileStat.C
+@@ -29,6 +29,7 @@ License
+ 
+ #include 
+ #include 
++#include 
+ 
+ // * * * * * * * * * * * * * * * * Constructors  * * * * * * * * * * * * * * //
+ 
+-- 
+2.11.0
+
diff -Nru openfoam-4.1+dfsg1/debian/patches/series openfoam-4.1+dfsg1/debian/patches/series
--- openfoam-4.1+dfsg1/debian/patches/series	2018-08-03 23:38:10.0 +0300
+++ openfoam-4.1+dfsg1/debian/patches/series	2018-12-31 10:22:02.0 +0200
@@ -6,3 +6,4 @@
 60_disable_dummy_packages.patch
 70_remove_IRIX_includes.patch
 80_gcc8.patch
+90_glibc.patch

Bug#915559: coreutils: Use renameat2 from glibc instead of syscall

2018-12-31 Thread Johannes Schauer

Hello again,

Quoting Johannes Schauer (2018-12-31 10:58:18)
> I'm sorry, but my attached patch was apparently not properly tested by me. :(
> 
> More work is needed to backport the patch from upstream to version 8.30 
> because
> just calling renameat2 as proposed in the patch I attached in my first message
> will just result in an infinite recursion loop. I guess I only didn't notice
> because the initial patch never worked because HAVE_RENAMEAT2 never got 
> defined
> as the following hunk was missing from it:
> 
> --- coreutils-8.30.orig/lib/config.hin
> +++ coreutils-8.30/lib/config.hin
> @@ -2069,6 +2069,9 @@
>  /* Define to 1 if you have the `renameat' function. */
>  #undef HAVE_RENAMEAT
>  
> +/* Define to 1 if you have the `renameat2' function. */
> +#undef HAVE_RENAMEAT2
> +
>  /* Define to 1 if you have the `rewinddir' function. */
>  #undef HAVE_REWINDDIR
> 
> 
> I only now started to understand how the Debian package includes the gnulib
> submodule and ends up shipping a number of autogenerated files as well.
> 
> Upstream doesn't have the problem of infinite recursion because they renamed
> renameat2 to renameatu. So one way of solving this would be to also backport
> that change.
> 
> Would you be okay with that or would you like to see another solution?
> 
> How much time do I have to present a working patch?

I think I've got it this time. Please find attached two patches. One renames
the renameat2 function to renameatu (as it was done upstream) and the other
adds support for using glibc renameat2 instead of the systemcall (and also
includes the missing hunk from lib/config.hin).

The renameatu patch is very small because the Debian package does not seem to
run the testsuite? At least it compiles fine and seems to work fine together
with my patch to fakechroot in #909612.

Sorry to not have gotten it right when I reported the bug.

Is there anything else you'd like me to do for this bug?

Thanks!

cheers, josch
From: Johannes 'josch' Schauer 
Date: Tue, 4 Dec 2018 20:57:48 +0100
X-Dgit-Generated: 8.30-1.1 2474a66055eceaf668b315d83ae7b0ae7bf9a4d5
Subject: Prefer renameat2 from glibc over syscall if available

This is necessary for fakechroot to be able to overwrite renameat2 which
is used by mv(1) from coreutils. See #909612

This patch is based on a patch by Andreas Henriksson 
which was accepted in gnulib git:

https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=c50cf67bd7ff70525f3cb4074f0d9cc1f5c6cf9c

---

--- coreutils-8.30.orig/lib/config.hin
+++ coreutils-8.30/lib/config.hin
@@ -2069,6 +2069,9 @@
 /* Define to 1 if you have the `renameat' function. */
 #undef HAVE_RENAMEAT
 
+/* Define to 1 if you have the `renameat2' function. */
+#undef HAVE_RENAMEAT2
+
 /* Define to 1 if you have the `rewinddir' function. */
 #undef HAVE_REWINDDIR
 
--- coreutils-8.30.orig/lib/renameat2.c
+++ coreutils-8.30/lib/renameat2.c
@@ -77,7 +77,10 @@ renameat2 (int fd1, char const *src, int
   int ret_val = -1;
   int err = EINVAL;
 
-#ifdef SYS_renameat2
+#if HAVE_RENAMEAT2
+  ret_val = renameat2 (fd1, src, fd2, dst, flags);
+  err = errno;
+#elif defined SYS_renameat2
   ret_val = syscall (SYS_renameat2, fd1, src, fd2, dst, flags);
   err = errno;
 #elif defined RENAME_EXCL
--- coreutils-8.30.orig/m4/renameat.m4
+++ coreutils-8.30/m4/renameat.m4
@@ -15,7 +15,7 @@ AC_DEFUN([gl_FUNC_RENAMEAT],
   AC_REQUIRE([gl_STDIO_H_DEFAULTS])
   AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
   AC_CHECK_HEADERS([linux/fs.h])
-  AC_CHECK_FUNCS_ONCE([renameat])
+  AC_CHECK_FUNCS_ONCE([renameat renameat2])
   if test $ac_cv_func_renameat = no; then
 HAVE_RENAMEAT=0
   elif test $REPLACE_RENAME = 1; then
From: Johannes 'josch' Schauer 
Date: Mon, 31 Dec 2018 11:03:58 +0100
X-Dgit-Generated: 8.30-1.1 8209088c5a946519942aba2b13200c8d09b14c91
Subject: renameatu


---

--- coreutils-8.30.orig/lib/backupfile.c
+++ coreutils-8.30/lib/backupfile.c
@@ -353,7 +353,7 @@ backupfile_internal (char const *file, e
   base_offset = 0;
 }
   unsigned flags = backup_type == simple_backups ? 0 : RENAME_NOREPLACE;
-  if (renameat2 (AT_FDCWD, file, sdir, s + base_offset, flags) == 0)
+  if (renameatu (AT_FDCWD, file, sdir, s + base_offset, flags) == 0)
 break;
   int e = errno;
   if (e != EEXIST)
--- coreutils-8.30.orig/lib/renameat.c
+++ coreutils-8.30/lib/renameat.c
@@ -21,5 +21,5 @@
 int
 renameat (int fd1, char const *src, int fd2, char const *dst)
 {
-  return renameat2 (fd1, src, fd2, dst, 0);
+  return renameatu (fd1, src, fd2, dst, 0);
 }
--- coreutils-8.30.orig/lib/renameat2.c
+++ coreutils-8.30/lib/renameat2.c
@@ -71,7 +71,7 @@ rename_noreplace (char const *src, char
function is equivalent to renameat (FD1, SRC, FD2, DST).  */
 
 int
-renameat2 (int fd1, char const *src, int fd2, char const *dst,
+renameatu (int fd1, char const *src, int fd2, char const *dst,
unsigned int flags)
 {
   int ret_val = -1;
--- coreutils-8.30.orig/lib/renameat2.h
+++ coreutils-8.30/lib/renamea

Bug#917859: vim FTBFS building for armel,armhf on arm64

2018-12-31 Thread James McCoy

On Mon, Dec 31, 2018 at 04:38:10AM +, Steve McIntyre wrote:
> I've been doing a full rebuild of the Debian archive, building all
> source packages targeting armel and armhf using arm64 hardware. We are
> planning in future to move all of our 32-bit armel/armhf builds to
> using arm64 machines, so this rebuild is to identify packages that
> might have problems with this configuration.

Thanks for doing this work!

> Test results:
> 
> 
> From test_search.vim:
> Found errors in Test_incsearch_substitute_dump():
> Run 1:
> function RunTheTest[40]..Test_incsearch_substitute_dump[40]..VerifyScreenDump 
> line 18: See dump file difference: call 
> term_dumpdiff("Test_incsearch_substitute_03.dump.failed", 
> "dumps/Test_incsearch_substitute_03.dump")
> Run 2:
> function RunTheTest[40]..Test_incsearch_substitute_dump[40]..VerifyScreenDump 
> line 18: See dump file difference: call 
> term_dumpdiff("Test_incsearch_substitute_03.dump.failed", 
> "dumps/Test_incsearch_substitute_03.dump")
> Flaky test failed too often, giving up
> 
> From test_alot.vim:
> Found errors in Test_compiler():
> function RunTheTest[40]..Test_compiler line 18: command did not fail: clist
> function RunTheTest[40]..Test_compiler line 24: Pattern '\n 1 Xfoo.pl:3: 
> Global symbol "$foo" requires explicit package name' does not match '\n11 
> Xfoo.pl:3: Global symbol "$foo" requires explicit package name (did you 
> forget to declare "my $foo"?)'
> TEST FAILURE
> make[2]: *** [Makefile:48: report] Error 1
> make[2]: Leaving directory '/<>/src/vim-basic/testdir'
> make[1]: *** [Makefile:2121: scripttests] Error 2
> make[1]: Leaving directory '/<>/src/vim-basic'
> make: *** [debian/rules:261: build-stamp-vim-basic] Error 2
> rm configure-stamp-vim-basic
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
> 2
> ...
> 
> I've no idea why this one particular test is failing :-(

The VerifyScreenDump ones are known to be flaky, but it would still help
if they actually showed the problem when they were marked as failed. :(
I should talk to upstream about that.

The "Test_compiler line 24" one is odd.  All that test does is create a
file foo.pl

#!/usr/bin/perl -w
use strict;
$foo=1;

and then run "perl -c foo.pl".  It expects there to be 1 line of output,
stating that "$foo" isn't declared.  However, there appears to be 11
lines of output.  That should be easy to verify independently.

Is there a way for me to replicate this new environment on the
porterboxes so I can debug further?

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#917911: stretch-pu: package libdatetime-timezone-perl/1:2.09-1+2018i

2018-12-31 Thread gregor herrmann

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libdatetime-timezone-perl/1:2.09-1+2018i to s-p-u. It
includes yesterday's Olson DB release 2018i as a quilt patch, which
has the following change:

São Tomé and Príncipe switches from +01 to +00 on 2019-01-01.

I'm attaching a stripped down debdiff.


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlwqOexfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbluA/+MvbKGkKbTmd60KT2cAGF4ZO+Gm/c/wTvZUcQspCFHleLIoapHbJcnohq
3sGE5YXk63cDnAQIGwAsrbT0ijN2rOv8OcZsEsbpp/3SK4X3AUxkd8eufkY4fe9e
nnilU5J1z1Dow4M9jHduU/P+YKdU8/5DcscNJmsR/8jJ85hYCADqT9wUKLgSog2b
qMDOd0ky0b5Sq0hwicrO2xpBeoECQqEdHiInfuJHdY/O3FI3xwisOZbEot/r+cxt
ZrVLnhdJIVxw5KQ0HD8DMWZzD3O0oak8C5eVJzk6qMv81hkV168P8vWTfvEKOTc1
KWOXgRVZ9Ylk0oocVO58IuEnRErMck77w+H1K8lCR2EGhtS1KHYyQWoRaSLNcdKp
54/B+ioYHKPtGhFsMC2eFh4VnY2T9KMjetuFkGaJMXWxE2k7hVQRqejOpK1TwnpH
qW0Dob7r87XAEX0srqvlm028tO7sPyLO2Xr9OvjWS3jOkLKXY6jP/tyOLGQN4fMc
hF8oJ6okMS1HeRTuKxDsaTs0uwyDbd/wSHTyUpiXJXGhUOvrGHptUitFEtyL3pPm
sCmft60HiuNW2saiWG+K+ITX+ipp3ZsChG0iPUa1lFh7/XPd3sFg21iiRXpNnjX/
L1V6bvq2GfAsArMb9V3Y0uOjWGn2LXd+yozmiafIeQMhGyAKNSo=
=wu+T
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.09/debian/changelog 
libdatetime-timezone-perl-2.09/debian/changelog
--- libdatetime-timezone-perl-2.09/debian/changelog 2018-12-30 
17:40:45.0 +0100
+++ libdatetime-timezone-perl-2.09/debian/changelog 2018-12-31 
16:38:55.0 +0100
@@ -1,3 +1,10 @@
+libdatetime-timezone-perl (1:2.09-1+2018i) stretch; urgency=medium
+
+  * Update to Olson database version 2018i.
+This update contains contemporary changes for São Tomé and Príncipe.
+
+ -- gregor herrmann   Mon, 31 Dec 2018 16:38:55 +0100
+
 libdatetime-timezone-perl (1:2.09-1+2018h) stretch; urgency=medium
 
   * Update to Olson database version 2018h.
diff -Nru libdatetime-timezone-perl-2.09/debian/patches/olson-2018i 
libdatetime-timezone-perl-2.09/debian/patches/olson-2018i
--- libdatetime-timezone-perl-2.09/debian/patches/olson-2018i   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.09/debian/patches/olson-2018i   2018-12-31 
16:38:55.0 +0100
@@ -0,0 +1,9712 @@
+Description: update to olson db 2018i
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2018-12-31
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2018h
++# Generated from debian/tzdata/africa.  Olson data version 2018i
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,7 +43,7 @@
+ ],
+ ];
+ 
+-sub olson_version {'2018h'}
++sub olson_version {'2018i'}
+ 
+ sub has_dst_changes {0}
+ 
+--- a/lib/DateTime/TimeZone/Africa/Sao_Tome.pm
 b/lib/DateTime/TimeZone/Africa/Sao_Tome.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2018h
++# Generated from debian/tzdata/africa.  Olson data version 2018i
+ #
+ # Do not edit this file directly.
+ #
+@@ -52,16 +52,25 @@
+ ],
+ [
+ 63650451600, #utc_start 2018-01-01 01:00:00 (Mon)
+-DateTime::TimeZone::INFINITY, #  utc_end
++63681987600, #  utc_end 2019-01-01 01:00:00 (Tue)
+ 63650455200, #  local_start 2018-01-01 02:00:00 (Mon)
+-DateTime::TimeZone::INFINITY, #local_end
++63681991200, #local_end 2019-01-01 02:00:00 (Tue)
+ 3600,
+ 0,
+ 'WAT',
+ ],
++[
++63681987600, #utc_start 2019-01-01 01:00:00 (Tue)
++DateTime::TimeZone::INFINITY, #  utc_end
++63681987600, #  local_start 2019-01-01 01:00:00 (Tue)
++DateTime::TimeZone::INFINITY, #local_end
++0,
++0,
++'GMT',
++],
+ ];
+ 
+-sub olson_version {'2018h'}
++sub olson_version {'2018i'}
+ 
+ sub has_dst_changes {0}
+ 
diff -Nru libdatetime-timezone-perl-2.09/debian/patches/series 
libdatetime-timezone-perl-2.09/debian/patches/series
--- libdatetime-timezone-perl-2.09/debian/patches/series2018-12-30 
17:40:45.0 +0100
+++ libdatetime-timezone-perl-2.09/debian/patches/series2018-12-31 
16:38:55.0 +0100
@@ -7,3 +7,4 @@
 olson-2018f
 olson-2018g
 olson-2018h
+olson-2018i

Bug#917910: plasma-desktop: separate binary package for xembedsniproxy

2018-12-31 Thread Pino Toscano

severity 917910 wishlist
thanks

Hi,

In data lunedì 31 dicembre 2018 16:19:34 CET, Clint Adams ha scritto:
> Source: plasma-desktop
> Version: 4:5.14.3-1
> 
> Please split xembedsniproxy out into its own binary package.  I
> don't want the entirety of plasma-desktop and all its dependencies
> just for this single utility.

What is the use case for it?

-- 
Pino Toscano

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

Bug#917909: Fw: Bug#917909: [text-based installer] right-to-left writing direction broken