date:20181231

On Tue, 01 Jan 2019 01:40:09 +0100, gregor herrmann wrote:

> (And with 240-2 and 2.03.02-1 there are still interaction problems

*cough*

… with udev 240-2 and lvm2 2.03.02-1 …


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Little Walter: Ah'w Baby


signature.asc
Description: Digital Signature

Bug#917622: Keyboard shortcuts ignored in text fields

2018-12-31 Thread Minh Duc Vo



On Jan 1 2019, at 7:57 am, Michael Gilbert  wrote:
> control: tag -1 moreinfo
>
> On Sat, Dec 29, 2018 at 7:27 AM Minh Duc Vo wrote:
> > Inputting a shortcut key combination while a text field is being focused 
> > will
> > not trigger the desired action for that combination.
> > For example, A Ctrl+T combination inputted while the cursor is placed in the
> > Omnibox will simply be ignored without any further effect.
>
>
> I am not able to reproduce this with the version you mention. Are you
> sure that there isn't something else interpreting key presses, perhaps
> your desktop environment or window manager?
>
> Best wishes,
> Mike
>

Okay, so, in Cinnamon, I can confirm that stopping IBus with ibus exit makes 
things turn back to normal. That also applies in Xfce4.
It looks like the problem itself doesn't come from Chromium. Sorry for 
disturbance.

Bug#917622: Keyboard shortcuts ignored in text fields

2018-12-31 Thread Michael Gilbert

control: tag -1 moreinfo

On Sat, Dec 29, 2018 at 7:27 AM Minh Duc Vo wrote:
> Inputting a shortcut key combination while a text field is being focused will
> not trigger the desired action for that combination.
> For example, A Ctrl+T combination inputted while the cursor is placed in the
> Omnibox will simply be ignored without any further effect.

I am not able to reproduce this with the version you mention.  Are you
sure that there isn't something else interpreting key presses, perhaps
your desktop environment or window manager?

Best wishes,
Mike

Bug#717563:

2018-12-31 Thread Sandro Tosi

Hey Kay,
the patch against python-debianbts has been applied and the package
uploaded: do you mind update your patch against reportbug to include
it?

thanks!

On Wed, Dec 26, 2018 at 4:16 PM Sandro Tosi  wrote:
>
> control: block -1 by 914057
>
> On Fri, Nov 30, 2018 at 9:09 PM Kay Mccormick  wrote:
> >
> > I managed to fix this (at least for the get_bugs case) but it required 
> > changes
> > to python-debianbts package.
> >
> > I have included two patches for feedback. There are some caveats:
> >
> > * Other method calls need to be patched in reportbug/debbugs.py.
> > * pysimplesoap will use alternatve http transport libraries if httplib2 is 
> > unavailable, and proxy support is unavailable for some of the other 
> > transports such as urllib2.
> > * reportbug uses urllib2 over httplib2, and pysimplesoap uses httplib2 over 
> > urllib2, but i don't think httplib2 is a dependency of reportbug - 
> > therefore, that must changed also or pysimplesoap wont pick it up.
>
> i see you opened 914057 - let's first see how the python-debianbts
> maintainer reacts (we need low-level support first anyway).
>
> Thanks,
>
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> G+: https://plus.google.com/u/0/+SandroTosi



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

Bug#917247: udev: Many modules are no longer automatically loaded at boot

On Fri, 28 Dec 2018 20:39:46 +0100, Michael Biebl wrote:

> Am 28.12.18 um 20:19 schrieb Jamie Heilman:
> >> Please test if this problem is still reproducible with 240-2
> > still very much a problem with 240-2
> Are you using sysvinit as well?

I got the same today with 240-2 and sysvinit.

(And with 240-2 and 2.03.02-1 there are still interaction problems
[0]; not sure which of the many bugs in this area this is exactly and
which package is reponsible here)


Cheers,
gregor

[0] The initialization problems, with loads of:
WARNING: Device /dev/xxx not initialized in udev database even after waiting 
1000 microseconds.

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Aimee Mann: Fifty Years After The Fair


signature.asc
Description: Digital Signature

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

2018-12-31 Thread Rich

-- Forwarded message -
From: Rich 
Date: Mon, Dec 31, 2018 at 8:16 AM
Subject: Re: zfsutils-linux: Upgrading to 0.7.12 breaks during dpkg --configure
To: Mo Zhou 

Heh. It being installed was not, AFAIK, a deliberate choice.

Attempting to remove it, though, looks...frought.

$ sudo apt remove -V insserv
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
   init (1.48)
   initscripts (2.88dsf-59.9)
   insserv (1.14.0-5.4+b1)
   systemd-sysv (232-25+deb9u6)
   sysv-rc (2.88dsf-59.9)
   sysvinit (2.88dsf-59)
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
   init
   systemd-sysv (due to init)
0 upgraded, 0 newly installed, 6 to remove and 39 not upgraded.
After this operation, 735 kB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?]

I'm reasonably confident doing this will break any sort of sysvinit
script usage on the whole system, which (presumably) would defeat the
purpose of ever shipping the sysvinit scripts?

It seems like what we might want is an OR dependency on two child
zfs-{systemd,sysvinit} packages - and for those two packages to
conflict with each other (and require the appropriate respective init
packages)? I think that's the right dependency interlock - exactly one
of {zfs-sysvinit,zfs-systemd} installed with the zfsutils-linux
package, probably with Breaks (zfsutils-linux < $NEW_SHINY_VERSION) in
the new children so that zfsutils-linux's new version shows up first,
and we don't have the two new packages trying to step on the old one's
files?

I don't actually know what a "reasonable" Debian system still using
sysvinit and not transitional bits looks like, so I don't know ATM how
to express the appropriate kind of conflict, but since I think(?) it's
still reasonable to have sysvinit compat hooks installed on stretch,
and I think it's also reasonable to not force people to remove all
sysvinit compat packages to install zfsutils-linux, it seems like
breaking the mutually exclusive bits out might be the best option?

(I think there's also a way to just do this with one new sysvinit
child package, that diverts all the systemd service scripts to
/dev/null or similar when it's installed and reverts it when not, but
since it's not clear to me that it'd be simpler to do that,
particularly if you're still having to include enumeration of the
systemd service files you're overriding in the sysvinit package, I
started with breaking them both out.)

Does that all make sense and/or seem correct? I don't think I made any
unreasonable assumptions about what a "correct" transition path to
having sysvinit and/or systemd files around given the prior states and
that having both enabled is probably impractical, but please tell me
if my pants are on my head. :)

(Also, thanks a lot for spending the time digging into this, I had
been hoping to doso over my short winter vacation, but other things
topped the priority queue.)

- Rich

On Mon, Dec 31, 2018 at 5:28 AM Mo Zhou  wrote:
>
> 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.

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

On Mon, 31 Dec 2018 13:04:59 +0100, Jakub Wilk wrote:

> 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

That's what I got as well today after a reboot. Makes apparmor pretty
unusable …
 

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#547608: better URLs for policy doc

2018-12-31 Thread 積丹尼 Dan Jacobson

OK looking at the bug, that was nine years ago.
I am sure you have a better grasp of the current situation so
closing the bug is fine.

Bug#914886: chromium: SafeBrowsing is not working at all (sample included)

2018-12-31 Thread Michael Gilbert

control: tag -1 moreinfo

On Wed, Nov 28, 2018 at 4:09 AM Peter Gervai wrote:
> Anyway, Chromium SafeBrowsing seems not to work at all, despite that both
> "SafeBrowsing" and "Help improve SB" is on.
>
> Just go to this URL and see no warnings: 
> https://www[.]xn--bbox-vw5a[.]com/login
> (It is a phishing site for bibox.com with TLS domain padlock.)
> The URL is detected by both FireFox and Google SafeBrowsing website.

I tried this both with and without safe browsing enabled in chromium
72.  It always detected the site as insecure, the red Not Secure
triangle, regardless of the safebrowsing setting.  Maybe this was a
temporary bug in version 70?  Could you retest with a newer version?

Best wishes,
Mike

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

2018-12-31 Thread Anton Gladky

Hello Adrian,

thank you for the patch! Feel free to put the NMU-upload
into the DELAYED/0.

Regards

Anton

Am Mo., 31. Dez. 2018 um 16:39 Uhr schrieb 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
>
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#917930: file: missing dependency: libseccomp-dev

2018-12-31 Thread testuser524

Package: file
Version: 1:5.34-2
Severity: normal

Dear Maintainer,

the current package for the program file as shipped with debian testing and 
newer 
includes a statement in the manpage about file being sandboxed by default using 
libseccomp.

However since libseccomp-dev is not included in the build dependencies, this 
feature is not included.

This can be tested by running "ldd /usr/bin/file" which will not list 
libseccomp-dev as a linked library.
Building file on a system with libseccomp-dev available solves this issue.

Since this sandbox feature might cause issues with other applications running 
file with the decompression
option -z but without the new -S option to disable seccomp, having this feature 
enabled like upstream indended
might cause issues.

The correct way to handle those issues would be to fix third party applications 
that use file incorrectly 
(without -S for decompression), however other distributions like arch have 
instead disabled seccomp support in file.

In case you decide to do the same please remove the statement in the manpage 
that file runs with seccomp by default.



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

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

Versions of packages file depends on:
ii  libc6  2.28-2
ii  libmagic1  1:5.34-2
ii  zlib1g 1:1.2.11.dfsg-1

file recommends no packages.

file suggests no packages.

-- no debconf information

Bug#916725: chromium: Extensions which access Google Bookmarks fail

2018-12-31 Thread Michael Gilbert

control: severity -1 normal

On Mon, Dec 17, 2018 at 4:15 PM Sean Shapira wrote:
> Extensions which attempt to access Google (not chrome) bookmarks no longer
> function. This is a regression introducted since 69.0.3497.92-1~deb9u1.

enable_one_click_signin is set to false starting with version 70 to
prevent background interfacing with google services.  It is the most
likely cause here.  Other users expect chromium to not interface with
google's services, so you would need to debate them about whether or
not this should be enabled.  I am inclined to leave it disabled.

Best wishes,
Mike

Bug#917928: libsensors5-dev seems to be missing, only libsensors4-dev is there in buster

2018-12-31 Thread Nerdopolis Turfwalker

Package: libsensors5
Severity: normal

Dear Maintainer,

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

I am trying to install libsensors5-dev but all that is there is libsensors4-dev
It also seems that there is a conflict between libsensors4 and 5, and one of 
the 
packages depends on the other as well

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


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

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

Versions of packages libsensors5 depends on:
ii  libc6  2.28-2
pn  libsensors-config  

libsensors5 recommends no packages.

Versions of packages libsensors5 suggests:
pn  lm-sensors

Bug#917929: lightdm: multiseat causes ghost-logins

2018-12-31 Thread westlake


Package: lightdm
Version: 1.18.3-1
Severity: important

Multi-seat works perfectly up to the point which I decribe below.

There are existing users who do not login who automatically appear to 
login onto the workstation.

(no remote services -- it's not a compromised system)

loginctl
SESSION  UID USERSEAT   TTY
  145180 root
   8901 1000 userA   seat0
c14  131 lightdm seat0
c33  131 lightdm seat-1


Even after clearing the logged-in users (there's only about 2 or 3 users 
on this system.. ) , with loginctl terminate-user ...  a user or two 
then re-appear again...


ps shows gvfs things.

I looked at timers with systemctl list-timers and disabled/stopped any 
of them.


I also tried to look at timers with user accounts using, "systemctl 
--user" list-timers and couldn't find anything under there.


I wonder what is "triggering" these processes...

it must be a bug lightdm.

/etc/lightdm/lightdm.conf

[Seat:seat0]
logind-check-graphical=true
type=xlocal

#xserver-config=/etc/X11/xorg.conf.intel_seat0
#note: debian's current Xorg (in this system), manpage does not indicate 
-seat seat_id but Xorg --help shows it is available


xserver-config=/etc/X11/xorg.conf.seat0
xserver-command=/usr/bin/Xorg -nolisten tcp -layout layout_seat0 -seat 
seat0 -novtswitch



[Seat:seat-1]
logind-check-graphical=true
type=xlocal

xserver-config=/etc/X11/xorg.conf.seat-1
xserver-command=/usr/bin/Xorg -nolisten tcp -layout layout_seat-1 -seat 
seat-1 -novtswitch


-

I provided xserver-config for the two seats, there's nothing special I 
can find which can be triggering this...


Despite the multiple ghost-logins, I am able to login via lightdm with 
the already listed users shown with loginctl list-users.



-Scott

Section "ServerLayout"
Identifier "layout_seat-1"
MatchSeat "seat-1"

Screen  0  "Screen0" 
InputDevice"Mouse0" 
InputDevice"Keyboard0" 

Option "SingleCard" "on"

EndSection

Section "ServerFlags"
 Option "DefaultServerLayout" "layout_seat-1"
 Option "AllowMouseOpenFail" "true"
 Option "AutoAddDevices" "false"
 Option "Xinerama" "false"

EndSection

Section "InputDevice"
   Identifier  "Keyboard0"
   # Driver  "kbd"
  Driver  "evdev"
  Option "GrabDevice" "on"
   Option "Device" "/dev/input/by-id/usb-Darfon_USB_Combo_Keyboard-event-kbd"

   Option "XkbRules" "base"
   Option "XkbModel" "pc105"
   Option "XkbLayout" "us"

   Option "CoreKeyboard" "on"

EndSection

Section "InputDevice"
Identifier  "Mouse0"
   # Driver  "mouse"
Driver "evdev"
Option "GrabDevice" "on"
Option  "Protocol" "auto"

Option "Device" 
"/dev/input/by-id/usb-Logitech_G400s_Optical_Gaming_Mouse-event-mouse"
Option "CorePointer" "on"

EndSection

Section "Monitor"
Identifier   "Monitor_BL"
VendorName   "Acer"
ModelName"1201(BL)"
EndSection


Section "Device"
Identifier  "Card0"
Driver  "nouveau"
BusID   "PCI:1:0:0"

  Option "Monitor-HDMI-A-2" "Monitor_BL"

EndSection


Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor"Monitor_BL"
SubSection "Display"
Viewport   0 0
Depth 1
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 4
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 8
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 15
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 24
EndSubSection
EndSection


Section "ServerLayout"
Identifier "layout_seat0"
MatchSeat "seat0"

Screen  0  "Screen0" 

InputDevice"Keyboard0" 
InputDevice"Mouse0" 


Option "SingleCard" "on"

EndSection

Section "ServerFlags"
 Option "DefaultServerLayout" "layout_seat0"
 Option "AllowMouseOpenFail" "true"
 Option "AutoAddDevices" "false"
 Option "Xinerama" "false"

EndSection

Section "InputDevice"
   Identifier  "Keyboard0"
   # Driver  "kbd"
Driver  "evdev"
Option "GrabDevice" "on"
# prevent send event to other X-servers

   Option "Device" "/dev/input/by-id/usb-Microsoft_Wired_Keyboard_600-event-kbd"

   Option "XkbRules" "base"
   Option "XkbModel" "pc105"
   Option "XkbLayout" "us"

   Option "CoreKeyboard" "on"

EndSection

Section "InputDevice"
Identifier  "Mouse0"
   # Driver  "mouse"
Driver "evdev"
Option "GrabDevice" "on"
Option  "Protocol" "auto"

 Option "Device" 
"/dev/input/by-id/usb-Logitech_USB-PS_2_Optical_Mouse-event-mouse"

Bug#913978: is not accessible with Orca screenreader

2018-12-31 Thread Jeremy Bicha

Control: forwarded -1
https://gitlab.gnome.org/GNOME/gnome-control-center/issues/327

On Sat, Nov 17, 2018 at 4:03 PM Mika Hanhijärvi  wrote:
> This is wery severe unacceptable problem. This bug makes Gnome 3.30 unusable
> for the visually impaired users because you can not access or change the
> desktop settings.

Thank you for taking the time to report this bug.

I agree that the GNOME Settings app has many accessible problems for
navigating with only a keyboard and screen reader.

I opened a bug now for the most critical issue. When that's fixed, you
should be able to navigate most of the Settings app, although there
are some elements that are not read and the context may be unclear.

Thanks,
Jeremy Bicha

Bug#916846: [libreoffice-ogltrans] Blank screen with OpenGL transitions

2018-12-31 Thread Rene Engelhard

clone 916846 -1
fixed 916846 1:6.1.4-2
reassign -1 libreoffice-impress
severity -1 important
retitle -1 [libreoffice-impress] Blank screen with OpenGL transitions
found -1 1:6.1.4-2
thanks

Hi,

On Wed, Dec 19, 2018 at 07:08:13PM +0100, Rene Engelhard wrote:
> Maybe we should just stop shipping them, no one needs it.

OK, so I merged -ogltrans back into -impress. That makes this bug
a) "fixed" in 1:6.4.1-2 of libreoffice-ogltrans (as it's now
   a transitional package and doesn't contain anything)
b) only "important", since it definitely doesn't make the whole
   of Impress unusable but just affects the OpenGL transitions thingy.


Yes, this is an "evil" trick to make this bug not RC anymore...


If someone finds the cause of this it can and will be fixed, though.

Regards,
 
Rene

Bug#917875: RFS: fathom/1.0-1 [ITP]

2018-12-31 Thread Pierre-Elliott Bécue

Le lundi 31 décembre 2018 à 10:46:20+0100, Jose G. López a écrit :
> On Mon, 31 Dec 2018 10:35:55 +0100
> "Jose G. López"  wrote:
> 
> > P.D: It's a requirement for ethereal-chess (ITP #914595) and surely for 
> > other
> > chess engines that are embedding this probe tool.
> > 
> 
> Sorry ITP actually is 914598.

Hi,

I suggest you rename your branch "master" to "upstream".

Regardless:

 * d/patches: why changing the .c file instead of adding -I to gcc calls?

Otherwise, LGTM, I'll upload as soon as you answer. :)

Thanks,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#917925: Module fails to load on Linux 4.3 or later

2018-12-31 Thread Guillem Jover

Hi!

On Mon, 2018-12-31 at 19:51:39 +, Ben Hutchings wrote:
> Package: device3dfx-source
> Version: 2013.08.08-6
> Severity: grave
> 
> devie3dfx-source can now build a module, but with these build-time
> warnings:
> 
>   MODPOST 1 modules
> WARNING: "mtrr_del" [/usr/src/modules/device3dfx/kbuild/3dfx.ko] undefined!
> WARNING: "mtrr_add" [/usr/src/modules/device3dfx/kbuild/3dfx.ko] undefined!
> 
> The mtrr_{add,del}() functions are no longer exported since Linux 4.3,
> which means it won't be possible to load the module.  Drivers should
> use the higher-level functions arch_phys_wc_{add,del}() to mark memory
> as write-combining.

Ah, thanks, I had completely forgotten about this, which looks like I
had fixed locally back in August! I think I got more concerned on
whether the upload would get through at all, due to the new dpkg-dev
code I used which omits the Binary and Description fields on the
.changes file, than on the build output here. :)

Will roll out a new upstream release and upload a new version.

Thanks,
Guillem

Bug#893814: keyboard-configuration: Set the default XKB model to nokiarx51 for Nokia N900 devices

2018-12-31 Thread David Derby


Dear maintainer,

Is there any chance of getting this patch merged before the buster 
transition freeze on 2019-01-12?  It would be a shame to miss the 
release and have to wait an additional 2 years for this to be included 
in Debian stable (bullseye).  Is there anything I can do to help with 
this?


I look forward to hearing from you.

Kind regards,

David

Bug#917926: RFS: openbox/3.6.1-8

2018-12-31 Thread Mateusz Łukasik


Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: openbox
   Version : 3.6.1-8
   Upstream Author : Dana Jansens 
 * URL : openbox.org
 * License : GPL-2+
   Section : x11

  It builds those binary packages:

gnome-panel-control - command line utility to invoke GNOME panel run 
dialog/menu
 libobrender32v5 - rendering library for openbox themes
 libobt2v5  - parsing library for openbox
 openbox- standards-compliant, fast, light-weight and extensible window man
 openbox-dev - development files for the openbox window manager
 openbox-gnome-session - command line utility to run Openbox as GNOME session
 openbox-kde-session - command line utility to run Openbox as KDE SC session

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/o/openbox/openbox_3.6.1-8.dsc


  Changes since the last upload:

  * Fix applications menu when there are no entries.
(Closes: #888254 #887122 #886716) (LP: #1771696).
  * debian/control:
+ Add obconf-qt as alternative for obconf. (Closes: #914960)
+ Bump Standards-Version to 4.3.0.
+ Remove openbox-menu from Recommends. (Closes: #876017)
  * debian/docs/build.html drop suggests using non-existent kdetrayproxy.
(Closes: #916086)
  * debian/patches:
+ Add 917204_undecorated_maximized_no_border.patch for removed top
border on undecorated maximized windows. (Closes: #917204)

  Regards,
   Mateusz Łukasik

Bug#913663: Bug#917592: libterm-termkey-perl: FTBFS (failing tests)

Control: retitle 917592 libterm-termkey-perl: FTBFS with STDIN as a readable 
non-tty
Control: severity 917592 important
Control: retitle 917497 libanyevent-termkey-perl: FTBFS with STDIN as a 
readable non-tty
Control: severity 917497 important

On Sun, 30 Dec 2018 20:22:00 +, Niels Thykier wrote:

> gregor herrmann:
> > Results for the various option in override_dh_auto_test:
> 
> Basically, the test (t/05flags.t) seg. faults if stdin is a *readable*
> non-tty (but succeeds in all other cases).

Ah ok, thanks.
 
> My recommendation is to use a short term work around by replacing the
> dh_auto_test call with the upstream test runner.  This will take the
> "edge" off this bug and enable us to debug this issue without the same
> pressure with the upcoming freeze.

Agreed. I've uploaded libterm-termkey-perl and
libanyevent-termkey-perl earlier today with a workaround.
 
> Anyhow, on to the details I have found:

Thanks for your debugging, and also to James for his help.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: B.B. King and Eric Clapton


signature.asc
Description: Digital Signature

Bug#917607: udev 240 Makes System Unbootable; rootfs Not Found

2018-12-31 Thread Leo L. Schwab

On Sun, Dec 30, 2018 at 10:36:02PM +0100, Michael Biebl wrote:
> Can you share more details about your storage configuration, like mdadm
> configs, /etc/fstab etc.
> 
Oh, sorry, left out partition info.

/etc/fstab by itself won't make much sense, as it's all UUIDs.
Further, the system dual-boots Win7 and Linux, spending most of its time in
the latter.

This will probably be more useful to you:

$ sudo lsblk -f
NAME   FSTYPE LABEL UUID FSAVAIL FSUSE% 
MOUNTPOINT
sda 
├─sda1 vfat ECB5-32D4  77.8M19% 
/boot/efi
├─sda2  
├─sda3 ntfs 143EEC7D3EEC58EE
├─sda4 ext4   debian-rootfs eb6ceb17-4ec4-4388-a902-ff2699840d62 40G31% 
/
├─sda5 ntfs   Swap  869E24439E242E5D
├─sda6 swap 8af77582-3df1-4960-a966-99388cd57906
[SWAP]
└─sda7 ext4 ce37c7e7-ba53-4151-9be2-bd9d7adb4626   65.7G 0% 
/extra
sdb 
├─sdb1  
├─sdb2 ntfs   Neptune   6018A6CC18A6A090
└─sdb3 ext4   mnt.home  5f8a63b0-12f0-4041-84b3-8235ded4b51a  857.2G 6% 
/home
sdc 
├─sdc1 ext4   vidwork   38fde8c7-11ed-48df-996e-08ffdef5434b  173.7G49% 
/vidwork
├─sdc2  
└─sdc5 ntfs   Re-lantic A6B87CCFB87C9F8B
sr0 

Mapped as follows:

/dev/sda3 -- Windows C:\ volume
/dev/sda4 -- Linux rootfs.
/dev/sda5 -- Windows swap (swapfile.sys is forced here).
/dev/sda6 -- Linux swap.
/dev/sda7 -- ext4 filesystem.

/home lives on /dev/sdb3.

Schwab

Bug#917911: libdatetime-timezone-perl 2.09-1+2018i flagged for acceptance

2018-12-31 Thread Adam D Barratt

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian .

Thanks for your contribution!

Upload details
==

Package: libdatetime-timezone-perl
Version: 2.09-1+2018i

Explanation: update included data

Bug#917377: tar: diff for NMU version 1.30+dfsg-3.1

2018-12-31 Thread Salvatore Bonaccorso

Control: tags 917377 + patch
Control: tags 917377 + pending


Hi Bdale,

I've prepared an NMU for tar (versioned as 1.30+dfsg-3.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

What do you think on the update? Are you fine with the NMU or would
you like rather to do a maintainer update as you know best if you want
to include more for buster? I have seen there is one further RC
severity bug for tar which is affecting the upcoming stable release so
far. But I adressed only specifically #917377 here.

Regards,
Salvatore
diff -Nru tar-1.30+dfsg/debian/changelog tar-1.30+dfsg/debian/changelog
--- tar-1.30+dfsg/debian/changelog	2018-11-17 08:33:47.0 +0100
+++ tar-1.30+dfsg/debian/changelog	2018-12-31 21:08:52.0 +0100
@@ -1,3 +1,11 @@
+tar (1.30+dfsg-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Infinite read loop in sparse_dump_region function (CVE-2018-20482)
+(Closes: #917377)
+
+ -- Salvatore Bonaccorso   Mon, 31 Dec 2018 21:08:52 +0100
+
 tar (1.30+dfsg-3) unstable; urgency=medium
 
   * elide reference to non-existent section 5 page from section 1 tar manpage,
diff -Nru tar-1.30+dfsg/debian/patches/Fix-CVE-2018-20482.patch tar-1.30+dfsg/debian/patches/Fix-CVE-2018-20482.patch
--- tar-1.30+dfsg/debian/patches/Fix-CVE-2018-20482.patch	1970-01-01 01:00:00.0 +0100
+++ tar-1.30+dfsg/debian/patches/Fix-CVE-2018-20482.patch	2018-12-31 21:08:52.0 +0100
@@ -0,0 +1,377 @@
+From: Sergey Poznyakoff 
+Date: Thu, 27 Dec 2018 17:48:57 +0200
+Subject: Fix CVE-2018-20482
+Origin: https://git.savannah.gnu.org/cgit/tar.git/commit/?id=c15c42ccd1e2377945fd0414eca1a49294bff454
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2018-20482
+Bug: https://lists.gnu.org/archive/html/bug-tar/2018-12/msg00023.html
+Bug-Debian: https://bugs.debian.org/917377
+
+* NEWS: Update.
+* src/sparse.c (sparse_dump_region): Handle short read condition.
+(sparse_extract_region,check_data_region): Fix dumped_size calculation.
+Handle short read condition.
+(pax_decode_header): Fix dumped_size calculation.
+* tests/Makefile.am: Add new testcases.
+* tests/testsuite.at: Likewise.
+
+* tests/sptrcreat.at: New file.
+* tests/sptrdiff00.at: New file.
+* tests/sptrdiff01.at: New file.
+---
+ NEWS|  8 +-
+ src/sparse.c| 50 +++-
+ tests/Makefile.am   |  5 +++-
+ tests/sptrcreat.at  | 62 +
+ tests/sptrdiff00.at | 55 
+ tests/sptrdiff01.at | 55 
+ tests/testsuite.at  |  5 +++-
+ 7 files changed, 231 insertions(+), 9 deletions(-)
+ create mode 100644 tests/sptrcreat.at
+ create mode 100644 tests/sptrdiff00.at
+ create mode 100644 tests/sptrdiff01.at
+
+diff --git a/src/sparse.c b/src/sparse.c
+index d41c0eacd1f3..f611200a2fc5 100644
+--- a/src/sparse.c
 b/src/sparse.c
+@@ -427,6 +427,30 @@ sparse_dump_region (struct tar_sparse_file *file, size_t i)
+ 			 bufsize);
+ 	  return false;
+ 	}
++  else if (bytes_read == 0)
++	{
++	  char buf[UINTMAX_STRSIZE_BOUND];
++	  struct stat st;
++	  size_t n;
++	  if (fstat (file->fd, ) == 0)
++	n = file->stat_info->stat.st_size - st.st_size;
++	  else
++	n = file->stat_info->stat.st_size
++	  - (file->stat_info->sparse_map[i].offset
++		 + file->stat_info->sparse_map[i].numbytes
++		 - bytes_left);
++	  
++	  WARNOPT (WARN_FILE_SHRANK,
++		   (0, 0,
++		ngettext ("%s: File shrank by %s byte; padding with zeros",
++			  "%s: File shrank by %s bytes; padding with zeros",
++			  n),
++		quotearg_colon (file->stat_info->orig_file_name),
++		STRINGIFY_BIGINT (n, buf)));
++	  if (! ignore_failed_read_option)
++	set_exit_status (TAREXIT_DIFFERS);
++	  return false;
++	}
+ 
+   memset (blk->buffer + bytes_read, 0, BLOCKSIZE - bytes_read);
+   bytes_left -= bytes_read;
+@@ -464,9 +488,9 @@ sparse_extract_region (struct tar_sparse_file *file, size_t i)
+ 	  return false;
+ 	}
+   set_next_block_after (blk);
++  file->dumped_size += BLOCKSIZE;
+   count = blocking_write (file->fd, blk->buffer, wrbytes);
+   write_size -= count;
+-  file->dumped_size += count;
+   mv_size_left (file->stat_info->archive_file_size - file->dumped_size);
+   file->offset += count;
+   if (count != wrbytes)
+@@ -598,6 +622,12 @@ check_sparse_region (struct tar_sparse_file *file, off_t beg, off_t end)
+ 			 rdsize);
+ 	  return false;
+ 	}
++  else if (bytes_read == 0)
++	{
++	  report_difference (file->stat_info, _("Size differs"));
++	  return false;
++	}
++  
+   if (!zero_block_p (diff_buffer, bytes_read))
+ 	{
+ 	  char begbuf[INT_BUFSIZE_BOUND (off_t)];
+@@ -609,6 +639,7 @@ check_sparse_region (struct tar_sparse_file *file, off_t beg, off_t end)
+ 
+   beg += bytes_read;
+ }
++
+   return true;
+ }
+ 
+@@ -635,6 +666,7 @@ check_data_region

Bug#914694: [Pkg-utopia-maintainers] Bug#914694: firewall-cmd --reload fails: RULE_REPLACE failed (No such file or directory): rule in chain {INPUT, OUTPUT}

2018-12-31 Thread Sunil Mohan Adapa

On Tue, 27 Nov 2018 14:29:40 -0500 Eric Garver  wrote:
[...]
> That makes it smell like an iptables-restore issue in the nftables
> backed version of iptables. It would be great if we could reproduce
> without firewalld using iptables-restore.

A much simpler way I reproduced the problem with iptables-restore:

# iptables-restore <

signature.asc
Description: OpenPGP digital signature

Bug#895061: status update

2018-12-31 Thread Nicolas Boulenguez

The suggested patch for #895659 has been applied,
and you have fixed lintian.
The only blocker is now #877267 in ocaml.
While waiting for an answer, I suggest the attached change to the
manual page.
diff --git a/debhelper.pod b/debhelper.pod
index acee4e20..ddc60878 100644
--- a/debhelper.pod
+++ b/debhelper.pod
@@ -185,13 +185,10 @@ process the rest of packages with default settings.
 
 =item B<--ignore=>I
 
-Ignore the specified file. This can be used if F contains a debhelper
-config file that a debhelper command should not act on. Note that
-F, F, and F can't be ignored, but
-then, there should never be a reason to ignore those files.
-
-For example, if upstream ships a F that you don't want
-B to install, use B<--ignore=debian/init>
+The removal of this option is planned.  If you cannot acheive your
+goal with L or executable debhelper configuration files,
+please describe your needs at
+L.
 
 =item B<-P>I, B<--tmpdir=>I

Bug#917479: Removed package(s) from unstable

2018-12-31 Thread Scott Kitterman

You can find information on the Debian maintainer/uploaders at 
https://tracker.debian.org/pkg/foxyproxy .  I would get in touch with them.

Scott K

Bug#917925: Module fails to load on Linux 4.3 or later

Package: device3dfx-source
Version: 2013.08.08-6
Severity: grave

devie3dfx-source can now build a module, but with these build-time
warnings:

  MODPOST 1 modules
WARNING: "mtrr_del" [/usr/src/modules/device3dfx/kbuild/3dfx.ko] undefined!
WARNING: "mtrr_add" [/usr/src/modules/device3dfx/kbuild/3dfx.ko] undefined!

The mtrr_{add,del}() functions are no longer exported since Linux 4.3,
which means it won't be possible to load the module.  Drivers should
use the higher-level functions arch_phys_wc_{add,del}() to mark memory
as write-combining.

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.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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages device3dfx-source depends on:
ii  debhelper 12
ii  make  4.2.1-1.2
ii  module-assistant  0.11.10

Versions of packages device3dfx-source recommends:
ii  kernel-package  13.018+nmu1

device3dfx-source suggests no packages.

Bug#833116: fgetty: Incorrect keystroke interpretation

2018-12-31 Thread Ricardo Peliquero

Dmitry Bogatov  Sat, 29 Dec 2018 18:33:11 +:

> Could you try replace calls to `setlocale(LC_ALL, "")` in previous
> patch with (different variants)

>  * setlocale(LC_ALL, "C.UTF-8")

Does not work (patch applies ok but won't be able to type 'ñandú').


>  * setenv("LANG", "C.UTF-8", 1)

It works as a breeze.
Able to type 'ñandú' and other stuff with LANG=C.UTF-8.
I can always put LANG=es_AR.UTF-8 and LANGUAGE=es_AR:es into .rcrc in
order to fit my local needs, and it still works perfectly well.


>  * setenv("LC_ALL", "C.UTF-8", 1)

It works, but LC_ALL variable might not be neccessary here. I'll of
course respect your choice.

 
> Also, could you please use unified diffs (diff -U) -- they are easier
> to read? Thank you.

Certainly; suggestion appreciated.


Thank you very much, and happy new year!

Bug#917479: Removed package(s) from unstable

2018-12-31 Thread brent s.

Hey all -

Recent versions of FoxyProxy are indeed compatible with Firefox >= 57.
The source has moved to https://code.getfoxyproxy.org/ (specifically, to
https://code.getfoxyproxy.org/Foxyproxy_Firefox_Webextensions/).

Who was previously maintaining this package? Is there anyone we
can/should get in contact with to bring this up to speed?

-- 
brent s.
Linux System Administrator/Engineer
FoxyProxy (https://getfoxyproxy.org)



signature.asc
Description: OpenPGP digital signature

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

2018-12-31 Thread Thomas Dickey

On Mon, Dec 31, 2018 at 06:11:23PM +0100, Alexander Meyer wrote:
> * Thomas Dickey  [2018-12-31 00:51]:
> 
> > On Sun, Dec 30, 2018 at 06:26:44PM +0100, Alexander Meyer wrote:
> > ...
> >> This is the behaviour I get across xterm versions:
> >> (everything with libfontconfig1 2.13.1-2)
> >> 
> >> fonts.conf enabled:
> >> 337: works
> >> 338: segfault
> >> 340: segfault
> >> 341: segfault
> > 
> > Can you make a backtrace for #341, please?
> 
> Here it is:

thanks.  I added some notes, but have not been able to reproduce the problem.
 
> Reading symbols from /usr/bin/xterm...Reading symbols from 
> /usr/lib/debug/.build-id/b8/d462fb6f4969a6a228262ceff981af02a1a4d5.debug...done.
> done.
> (gdb) run -fa 'Noto Mono'

fwiw, my Debian/testing machine has these fonts (with "noto" in their names):

ii  fonts-noto20181130-1
all  metapackage to pull in all Noto fonts
ii  fonts-noto-cjk1:20170601+repack1-3  
all  "No Tofu" font families with large Unicode coverage (CJK 
regular and bold)
ii  fonts-noto-color-emoji0~20180810-1  
all  color emoji font from Google
ii  fonts-noto-hinted 20181130-1
all  "No Tofu" font families with large Unicode coverage 
(hinted)
ii  fonts-noto-mono   20181130-1
all  "No Tofu" monospaced font family with large Unicode 
coverage
ii  fonts-noto-unhinted   20181130-1
all  "No Tofu" font families with large Unicode coverage 
(unhinted)

> Starting program: /usr/bin/xterm -fa 'Noto Mono'
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x77d662d1 in FcConfigEvaluate (p=0x556f2430, 
> p_pat=0x559dea90, kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
> (gdb) bt full
> #0  0x77d662d1 in FcConfigEvaluate (p=0x556f2430, 
> p_pat=0x559dea90, kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
> v = {type = FcTypeVoid, u = {s = 0x556f1ad0 " \033oUUU", i = 
> 1433344720, b = 1433344720, d = 4.6355706220021174e-310, m = 0x556f1ad0, 
> c = 0x556f1ad0, f = 0x556f1ad0, 
> l = 0x556f1ad0, r = 0x556f1ad0}}
> vl = {type = 1433014944, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, 
> c = 0x0, f = 0x0, l = 0x0, r = 0x0}}
> vr = {type = 1436412560, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, 
> c = 0x0, f = 0x0, l = 0x0, r = 0x0}}
> vle = 
> vre = 
> m = 
> str = 
> op = 

If "op" weren't optimized, we could see which case is breaking :-)
But since "e" is null, that says op is garbage anyway.

> buf1 = {u = {d = 0, i = 0, l = 0, 
> c = 
> "\000\000\000\000\000\000\000\000\200\032oUUU\000\000\270\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
>  '\000' , 
> "\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\060\032oUUU\000\000\320\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
>  '\000' , 
> "\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\340\031oUUU\000\000\350\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
>  '\000' , 
> "\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000"...}}
> buf2 = {u = {d = 0, i = 0, l = 0, 
> c = 
> "\000\000\000\000\000\000\000\000@\031oUUU\000\000\030\023jUUU\000\000\000\000\000\000\000\000\000\000\025",
>  '\000' , "\a\000\000\000\000\000\000\000 
> \000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\020\300aUUU\000\000\017\000\000\000\000\000\000\000@\000\000\000\000\000\000\000\260\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\060",
>  '\000' , "[\000\000\000w", '\000' , 
> "n\000\000\000|\000\000\000\t\000\000\000\000\000\000\000\017\000\000\000\000\000\000\000\025",
>  '\000' , "\260\377\377\377\377\377\377\377"...}}
> #1  0x77d66418 in FcConfigEvaluate (p=p@entry=0x556f2430, 
> p_pat=p_pat@entry=0x559dea90, kind=kind@entry=FcMatchFont, 
> e=e@entry=0x55681218) at fccfg.c:1003
> m = {xx = 1.4821969375237396e-323, xy = 6.9533490418283141e-310, yx = 
> 1.4821969375237396e-323, yy = 1}
> xx = 
> yy = 
> xy = 
> yx = 
> v = {type = FcTypeMatrix, u = {s = 0x3  at address 0x3>, i = 3, b = 3, d = 1.4821969375237396e-323, m = 0x3, c = 0x3, 
> f = 0x3, l = 0x3, r = 0x3}}
> vl = {type = FcTypeVoid, u = {s = 0x556f24b0 "Noto Color Emoji", 
> i = 1433347248, b = 1433347248, d = 4.6355706221270172e-310, m = 
> 0x556f24b0, c = 0x556f24b0, f = 0x556f24b0,

Bug#878890: fails to detect disks/partitions correctly

2018-12-31 Thread Daniel Baumann

close 878890 1.11.1+dfsg-1~exp1
thanks

Hi,

I tried to reproduce this with 1.11.1 and see, that on different systems
I see all the same filesystems information/graphs listet, with or
without the systemd unit changes.

I conclude that the bug has been fixed upstream and therefore close the bug.

Regards,
Daniel

Bug#916654: Acknowledgement (vdr-plugin-epgsearch 2.2.0+git20170817-2)

2018-12-31 Thread klak

Am Sun, 23 Dec 2018 22:55:09 +0100
schrieb klak :

> Hallo Maintainer,
> 
> after two days (of updates) the bug was gone.
> 
> Please close bug#916654.
> 
> Greets klak


Hello Maintainer,

please reopen the bug, the error occurs again.

Greets klak

Bug#810548: xserver-xorg-video-radeon: gpu lockup and black screen

2018-12-31 Thread Alexandros Prekates

Package: xserver-xorg-video-radeon
Version: 1:7.8.0-1+b1
Followup-For: Bug #810548

Dear Maintainer,

I have an radeon HD 5750

In phenomenicaly random moment ,  in frequency of one per day , and usually
while i play in the same time Stellaris (starting it from withing the steam
client)
linux will freeze and screen will become blank .Fans are still operational ,
also i tested another screen but still blank.

/var/log/syslog display hundred times :

ec 31 17:56:28 enous kernel: [20887.723072] radeon :01:00.0: GPU lockup
(current fence id 0x007c89d8 last fence id 0x007c89e0 on ring
0)
Dec 31 17:56:29 enous kernel: [20888.234984] radeon :01:00.0: ring 0
stalled for more than 216576msec
Dec 31 17:56:29 enous kernel: [20888.234987] radeon :01:00.0: GPU lockup
(current fence id 0x007c89d8 last fence id 0x007c89e0 on ring
0)
Dec 31 17:56:29 enous kernel: [20888.746986] radeon :01:00.0: ring 0
stalled for more than 217088msec


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

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

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



-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Juniper PRO [Radeon HD 5750] [1002:68be]

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.9.0-7-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.110-3+deb9u2 (2018-08-13)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 45343 Nov  2 13:41 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 46137 Dec 31 18:19 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[ 2.931] (--) Log file renamed from "/var/log/Xorg.pid-653.log" to 
"/var/log/Xorg.0.log"
[ 2.933] 
X.Org X Server 1.19.2
Release Date: 2017-03-02
[ 2.933] X Protocol Version 11, Revision 0
[ 2.933] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[ 2.933] Current Operating System: Linux enous 4.9.0-7-amd64 #1 SMP Debian 
4.9.110-3+deb9u2 (2018-08-13) x86_64
[ 2.933] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-7-amd64 
root=UUID=f92aef31-d231-4b0f-8d17-f120b6ec98f5 ro quiet
[ 2.933] Build Date: 03 November 2018  03:09:11AM
[ 2.933] xorg-server 2:1.19.2-1+deb9u5 (https://www.debian.org/support) 
[ 2.933] Current version of pixman: 0.34.0
[ 2.933]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 2.933] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 2.933] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Dec 31 18:19:28 
2018
[ 2.937] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 2.938] (==) No Layout section.  Using the first Screen section.
[ 2.938] (==) No screen section available. Using defaults.
[ 2.938] (**) |-->Screen "Default Screen Section" (0)
[ 2.938] (**) |   |-->Monitor ""
[ 2.939] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 2.939] (==) Automatically adding devices
[ 2.939] (==) Automatically enabling devices
[ 2.939] (==) Automatically adding GPU devices
[ 2.939] (==) Max clients allowed: 256, resource mask: 0x1f
[ 2.942] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 2.942]Entry deleted from font path.
[ 2.946] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[ 2.946] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 2.946] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[ 2.946] (II) Loader magic: 0x5642f9cdbe00
[ 2.946] (II) Module ABI versions:
[ 2.946]X.Org ANSI C Emulation: 0.4
[ 2.946]X.Org Video Driver: 23.0
[ 2.946]X.Org XInput driver : 24.1
[ 2.946]X.Org Server Extension : 10.0
[

Bug#917924: nm-tray: does not appear in SNI tray

2018-12-31 Thread Clint Adams

Package: nm-tray
Version: 0.4.2-1

I ran nm-tray, expecting something to appear in taffybar's SNI tray
area.  It did not.

% nm-tray
QSystemTrayIcon::setVisible: No Icon set


strace shows that it is trying to access various non-existent images
in /usr/share/pixmaps .

Bug#904459: modifies conffiles (health_alarm_notify.conf)

2018-12-31 Thread Daniel Baumann

Hi,

quick update on this.. it took longer than expected because I also
realized that what goes for health_alarm_notify.conf also applies to
netdata.conf (that is currently not modified/handled by debconf, but for
which I would like to add some debconf questions for the tree basic/most
common things too).

Doing this properly and in a non-crappy way (especially because
health*.conf is shell, netdata.conf is ini format) requires a bit more
work (in the long run, I hope upstream will fix it by implementing
proper conf.d support for all configuration files).

Therefore.. to get netdata into testing as soon as possible.. I'll drop
the debconf handling for now, get that into testing, and introduce it in
some time after careful testing when everything works.

Regards,
Daniel

Bug#917923: ITP: python-pytest-random-order -- pytest plugin to randomise the order of tests (Python 3)

2018-12-31 Thread Nick Morrott

Package: wnpp
Owner: Nick Morrott ,
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-pytest-random-order
  Version : 1.0.4
  Upstream Author : Jazeps Basko 
* URL : https://github.com/jbasko/pytest-random-order
* License : Expat
  Programming Lang: Python
  Description : pytest plugin to randomise the order of tests (Python 3)

pytest-random-order is a pytest plugin that randomises the order of tests.
This can be useful to detect a test that passes just because it happens to
run after an unrelated test that leaves the system in a favourable state.

The plugin allows the user to control the level of randomness they want to
introduce and to disable reordering on subsets of tests. Tests can be rerun
in a specific order by passing a seed value reported in a previous test run.

This package installs the pytest plugin for Python 3.

I plan to maintain this package in the Debian Python Modules Team.

Bug#552275: network-manager-gnome: Wifi icons not scalable for larger panel sizes

2018-12-31 Thread Josh Triplett

On Mon, Dec 31, 2018 at 09:55:53AM +0100, Eugen Dedu wrote:
> On Sat, 24 Oct 2009 17:09:07 -0700 Josh Triplett 
> wrote:
> > Package: network-manager-gnome
> > Version: 0.7.1-1
> > Severity: normal
> > 
> > I use a 48-pixel bottom panel and no top panel.  Most tray icons scale
> > to the appropriate size, but nm-applet's wifi icons remain small.  (Some
> > of nm-applet's other icons scale appropriately, making the icon change
> > size depending on the networking state.)
> 
> Hi,
> 
> Is this bug still actual?
> 
> I am not sure if this was the same bug like me, but I use awesome with a
> larger panel, and the wi-fi icon, but also Ethernet one, contained visual
> artifacts.  Since a few days (I use Debian unstable), everything is normal,
> I have not found the reason (perhaps a recent update of libpng?)

I haven't personally observed this bug in a long time, but it was a bug
with non-GNOME-3 environments, so someone with another environment would
need to check.

Bug#917922: RM: cpufrequtils [ppc64el] -- ROP; Does not work on powerpc

2018-12-31 Thread Niels Thykier

Package: ftp.debian.org
Severity: normal

In #889895, the PowerPC powers requested that cpufrequtils was no
longer built on powerpc architectures as it does not work on those
architectures.

I have uploaded a new version of cpufrequtils that no longer builds
cpufrequtils on ppc64el and kindly ask that you remove the old binaries
left in unstable on said architectures.

Thanks,
~Niels

Bug#917921: rainloop: cannot launch admin panel

2018-12-31 Thread Joseph Nahmias

Package: rainloop
Version: 1.11.1-1
Severity: important

Dear Maintainer,

I tried to follow the instructions in the README.Debian for activating
the admin panel (I changed admin_password and set allow_admin_panel =
On) but I kept getting "Authentication failed".  Only when I changed the
password back to 12345 did it work.

Help!
--Joe


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

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

Versions of packages rainloop depends on:
ii  ckeditor4.5.7+dfsg-2
ii  libphp-predis   0.8.3-1
ii  lighttpd [httpd]1.4.45-1
ii  php-curl1:7.0+49
ii  php-fpm 1:7.0+49
ii  php-json1:7.0+49
ii  php-pclzip  2.8.2-4
ii  php-seclib  1.0.5-1
ii  php-xml 1:7.0+49
ii  php7.0-curl [php-curl]  7.0.33-0+deb9u1
ii  php7.0-fpm [php-fpm]7.0.33-0+deb9u1
ii  php7.0-json [php-json]  7.0.33-0+deb9u1
ii  php7.0-xml [php-xml]7.0.33-0+deb9u1

rainloop recommends no packages.

Versions of packages rainloop suggests:
pn  php5-sqlite | php5-mysql | php5-pgsql  

-- Configuration Files:
/etc/rainloop/application.ini changed [not included]

-- no debconf information

Bug#917752: lintian: FTBFS: tests failed

2018-12-31 Thread Felix Lechner

This bug is fixed. It can be marked as pending when the merge requests
for the two blocking bugs are accepted.

Bug#913717: quaternion: please package new upstream release 0.0.9.3

2018-12-31 Thread Jonas Smedegaard

Quoting Hubert Chathi (2018-12-31 18:15:08)
> On Wed, 14 Nov 2018 11:05:00 -0500, Hubert Chathi  said:
> 
> > In this case, I'm planning on splitting out libqmatrixclient into its
> > own package, rather than bundling it with quaternion, as it is now
> > being used by at least one other Matrix client (Spectral), which we
> > may want to package as well.
> 
> I've uploaded libqmatrixclient.  Once it clears NEW, I'll upload the new
> quaternion.

Great!

As you no doubt noticed, I didn't find time to do that myself.  But I am 
still interested in helping out here, so feel free to make me aware if 
something specific is pending.

NB! An expertise of mine is copyright and licensing examinations... :-)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#913930: Confirmed for sbuild only

2018-12-31 Thread Felix Lechner

Hi Harlan!

On Thu, Dec 27, 2018 at 9:09 PM Harlan Lieberman-Berg
 wrote:
>
> Just as one more datapoint for you, I see the same thing with
> certbot-dns-ovh with lintian 2.5.118 and sbuild 0.77.1-2.

Thank you for writing! Your package builds much faster than lxc. The
problem was fixed in

https://salsa.debian.org/lintian/lintian/merge_requests/114

Kind regards
Felix Lechner

Bug#917592: libterm-termkey-perl: FTBFS (failing tests)

2018-12-31 Thread James McCoy

On Sun, Dec 30, 2018 at 09:30:34PM -0500, James McCoy wrote:
> Dropping debhelper and related bug, since this is just about libtermkey.
> 
> On Sun, Dec 30, 2018 at 08:22:00PM +, Niels Thykier wrote:
> > Anyhow, on to the details I have found:
> > 
> >  * Only test case 05flags.t fails and only if stdin is a *readable*
> >non-tty (e.g. /dev/null, an empty file or a non-empty file)
> > 
> >  […]
> > 
> >  * If the TERM is set to "dump", the test hangs.
> 
> Both of these issues have come up before in #809162.

Sorry, that should be #809192.

> At the time, I
> sent a patch to libtermkey's upstream to avoid the crash and then forgot
> to follow up on it.
> 
> I've sent a prod and will try to keep on top of it better this time. :)

He's looking into both issues (libtermkey NULL pointer crash and
libterm-termkey-perl's 05flags.t hang) now.  They're primarily test
issues, since it should be expected that normal use of these libraries
would have a valid TERM in the environment.

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

Bug#916392: please provide a column marker mechanism

2018-12-31 Thread Benno Schulenberg


Please try the attached patch.

Use --edge= to show a colored bar at the desired column.

Benno
From 119491bbdedf2c727135e5e331f0714d94644351 Mon Sep 17 00:00:00 2001
From: Benno Schulenberg 
Date: Mon, 17 Dec 2018 19:57:30 +0100
Subject: [PATCH] new feature: add option --edgecolumn that shows a vertical
 guiding bar
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Option -e (--edgecolumn) takes a column number as argument and then
shows a vertical, colored bar over the entire height of the buffer,
to help the user control the width of the text when the terminal is
wider than this desired width.

[The color needs to become configurable, and would by default just
change the background color, not the foreground color.  But that is
something for a later patch.  It also needs to add an rcfile option
and documentation, of course.  Suggestions for a better name for the
option are welcome.]

This fulfills https://bugs.debian.org/916392.
Requested-by: Arturo Borrero GonzÃ¡lez 
And fulfills https://savannah.gnu.org/bugs/?55315.
Requested-by: Bryan Christ 
---
 src/global.c |  2 ++
 src/nano.c   | 16 ++--
 src/proto.h  |  1 +
 src/winio.c  |  9 +
 4 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/src/global.c b/src/global.c
index 0368132f..baef8fa9 100644
--- a/src/global.c
+++ b/src/global.c
@@ -111,6 +111,8 @@ int editwincols = -1;
 		/* The number of usable columns in the edit window: COLS - margin. */
 int margin = 0;
 		/* The amount of space reserved at the left for line numbers. */
+ssize_t edge_col = 0;
+		/* The column at which a vertical bar of color will be drawn. */
 
 filestruct *cutbuffer = NULL;
 		/* The buffer where we store cut text. */
diff --git a/src/nano.c b/src/nano.c
index 263045bc..db3371b6 100644
--- a/src/nano.c
+++ b/src/nano.c
@@ -851,6 +851,10 @@ void usage(void)
 	print_opt("-c", "--constantshow", N_("Constantly show cursor position"));
 	print_opt("-d", "--rebinddelete",
 	N_("Fix Backspace/Delete confusion problem"));
+#ifndef NANO_TINY
+	print_opt("-e ", "--edgecolumn=",
+	N_("Show a guiding bar at this column"));
+#endif
 #ifdef ENABLE_BROWSER
 	if (!ISSET(RESTRICTED))
 		print_opt("-g", "--showcursor", N_("Show cursor in file browser & help text"));
@@ -2022,6 +2026,7 @@ int main(int argc, char **argv)
 		{"wordchars", 1, NULL, 'X'},
 		{"zap", 0, NULL, 'Z'},
 		{"atblanks", 0, NULL, 'a'},
+		{"edgecolumn", 0, NULL, 'e'},
 		{"autoindent", 0, NULL, 'i'},
 		{"cutfromcursor", 0, NULL, 'k'},
 		{"unix", 0, NULL, 'u'},
@@ -2084,7 +2089,7 @@ int main(int argc, char **argv)
 
 	while ((optchr =
 		getopt_long(argc, argv,
-"ABC:DEFGHIKLMNOPQ:RST:UVWX:Y:Zabcdefghijklmno:pqr:s:tuvwxyz$",
+"ABC:DEFGHIKLMNOPQ:RST:UVWX:Y:Zabcde:fghijklmno:pqr:s:tuvwxyz$",
 long_options, NULL)) != -1) {
 		switch (optchr) {
 #ifndef NANO_TINY
@@ -2203,6 +2208,14 @@ int main(int argc, char **argv)
 			case 'd':
 SET(REBIND_DELETE);
 break;
+			case 'e':
+if (!parse_num(optarg, _col) || edge_col <= 0) {
+die("here");
+	fprintf(stderr, _("Requested edge column \"%s\" is invalid"), optarg);
+	fprintf(stderr, "\n");
+	exit(1);
+}
+break;
 			case 'g':
 SET(SHOW_CURSOR);
 break;
@@ -2294,7 +2307,6 @@ int main(int argc, char **argv)
 break;
 #endif
 			case 'b':  /* Pico compatibility flags. */
-			case 'e':
 			case 'f':
 			case 'j':
 			case 'q':
diff --git a/src/proto.h b/src/proto.h
index 65890134..09e7464a 100644
--- a/src/proto.h
+++ b/src/proto.h
@@ -88,6 +88,7 @@ extern WINDOW *bottomwin;
 extern int editwinrows;
 extern int editwincols;
 extern int margin;
+extern ssize_t edge_col;
 
 extern filestruct *cutbuffer;
 extern filestruct *cutbottom;
diff --git a/src/winio.c b/src/winio.c
index e2042d9e..18f91254 100644
--- a/src/winio.c
+++ b/src/winio.c
@@ -2677,6 +2677,15 @@ void edit_draw(filestruct *fileptr, const char *converted,
 	}
 #endif /* ENABLE_COLOR */
 
+	if (edge_col > 0) {
+		const char *text = converted +  actual_x(converted, edge_col);;
+		const char *edge_char = (*text == '\0') ? " " : text;
+
+		wattron(edit, interface_color_pair[ERROR_MESSAGE]);
+		mvwaddnstr(edit, row, margin + edge_col, edge_char, 1);
+		wattroff(edit, interface_color_pair[ERROR_MESSAGE]);
+	}
+
 #ifndef NANO_TINY
 	/* If the mark is on, and fileptr is at least partially selected, we
 	 * need to paint it. */
-- 
2.19.2

Bug#913717: quaternion: please package new upstream release 0.0.9.3

2018-12-31 Thread Hubert Chathi

On Wed, 14 Nov 2018 11:05:00 -0500, Hubert Chathi  said:

> In this case, I'm planning on splitting out libqmatrixclient into its
> own package, rather than bundling it with quaternion, as it is now
> being used by at least one other Matrix client (Spectral), which we
> may want to package as well.

I've uploaded libqmatrixclient.  Once it clears NEW, I'll upload the new
quaternion.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

2018-12-31 Thread Alexander Meyer

* Thomas Dickey  [2018-12-31 00:51]:

> On Sun, Dec 30, 2018 at 06:26:44PM +0100, Alexander Meyer wrote:
> ...
>> This is the behaviour I get across xterm versions:
>> (everything with libfontconfig1 2.13.1-2)
>> 
>> fonts.conf enabled:
>> 337: works
>> 338: segfault
>> 340: segfault
>> 341: segfault
> 
> Can you make a backtrace for #341, please?

Here it is:


Reading symbols from /usr/bin/xterm...Reading symbols from 
/usr/lib/debug/.build-id/b8/d462fb6f4969a6a228262ceff981af02a1a4d5.debug...done.
done.
(gdb) run -fa 'Noto Mono'
Starting program: /usr/bin/xterm -fa 'Noto Mono'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x77d662d1 in FcConfigEvaluate (p=0x556f2430, p_pat=0x559dea90, 
kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
(gdb) bt full
#0  0x77d662d1 in FcConfigEvaluate (p=0x556f2430, 
p_pat=0x559dea90, kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
v = {type = FcTypeVoid, u = {s = 0x556f1ad0 " \033oUUU", i = 
1433344720, b = 1433344720, d = 4.6355706220021174e-310, m = 0x556f1ad0, c 
= 0x556f1ad0, f = 0x556f1ad0, 
l = 0x556f1ad0, r = 0x556f1ad0}}
vl = {type = 1433014944, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, c 
= 0x0, f = 0x0, l = 0x0, r = 0x0}}
vr = {type = 1436412560, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, c 
= 0x0, f = 0x0, l = 0x0, r = 0x0}}
vle = 
vre = 
m = 
str = 
op = 
buf1 = {u = {d = 0, i = 0, l = 0, 
c = 
"\000\000\000\000\000\000\000\000\200\032oUUU\000\000\270\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
 '\000' , 
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\060\032oUUU\000\000\320\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
 '\000' , 
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\340\031oUUU\000\000\350\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
 '\000' , 
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000"...}}
buf2 = {u = {d = 0, i = 0, l = 0, 
c = 
"\000\000\000\000\000\000\000\000@\031oUUU\000\000\030\023jUUU\000\000\000\000\000\000\000\000\000\000\025",
 '\000' , "\a\000\000\000\000\000\000\000 
\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\020\300aUUU\000\000\017\000\000\000\000\000\000\000@\000\000\000\000\000\000\000\260\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\060",
 '\000' , "[\000\000\000w", '\000' , 
"n\000\000\000|\000\000\000\t\000\000\000\000\000\000\000\017\000\000\000\000\000\000\000\025",
 '\000' , "\260\377\377\377\377\377\377\377"...}}
#1  0x77d66418 in FcConfigEvaluate (p=p@entry=0x556f2430, 
p_pat=p_pat@entry=0x559dea90, kind=kind@entry=FcMatchFont, 
e=e@entry=0x55681218) at fccfg.c:1003
m = {xx = 1.4821969375237396e-323, xy = 6.9533490418283141e-310, yx = 
1.4821969375237396e-323, yy = 1}
xx = 
yy = 
xy = 
yx = 
v = {type = FcTypeMatrix, u = {s = 0x3 , i = 3, b = 3, d = 1.4821969375237396e-323, m = 0x3, c = 0x3, f = 
0x3, l = 0x3, r = 0x3}}
vl = {type = FcTypeVoid, u = {s = 0x556f24b0 "Noto Color Emoji", i 
= 1433347248, b = 1433347248, d = 4.6355706221270172e-310, m = 0x556f24b0, 
c = 0x556f24b0, f = 0x556f24b0, 
l = 0x556f24b0, r = 0x556f24b0}}
vr = {type = FcTypeString, u = {s = 0x77d660a4 
 
"\205\300\017\224\300\017\266\300\351\267\375\377\377L\211\346H\211\327\350\364=",
 i = -136945500, b = -136945500, 
d = 6.9533490418283141e-310, m = 0x77d660a4 
, c = 0x77d660a4 , f = 
0x77d660a4 , 
l = 0x77d660a4 , r = 0x77d660a4 
}}
vle = 
vre = 
m = 
str = 
op = FcOpMatrix
buf1 = {u = {d = 4.6355706048940074e-310, i = 1432998448, l = 
93824993579568, 
c = 
"0\322iUUU\000\000\002\000\000\000\000\000\000\000\060\026jUUU\000\000\354c\326\367\377\177\000\000\000\000\000\000\000\000\000\000\003\000\000\000\000\000\000\000\003",
 '\000' , "\a\000\000\000\000\000\000\000 
\000\000\000\000\000\000\000\002\000\000\000UU\000\000\020\300aUUU\000\000\017\000\000\000\000\000\000\000@\000\000\000\000\000\000\000\260\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\060",
 '\000' , 
"\f\341\327\367\377\177\000\000\000\000\000\000\257\060\000\000\000\240\316\365\301\035?\376\003\000\000\000\000\000\000\000\256\340\327\367\377\177\000\000\200\326\377\377\264\060\000\000\000"...}}
buf2 = {u = {d = 4.6355706320533889e-310, i = 1433548160, l = 
93824994129280, 
c = 
"\200\065rUUU\000\000\270\220B\365\377\177\000\000\000\000\000\000\000\000\000\000\362H\327\367\377\177\000\000
 ", '\000' ,

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

2018-12-31 Thread Alexander Meyer

* Thomas Dickey  [2018-12-30 23:14]:

> On Sun, Dec 30, 2018 at 10:15:53PM +0100, Sven Joachim wrote:
>> On 2018-12-30 18:26 +0100, Alexander Meyer wrote:
>>> So the segfault only happens with that fonts.conf.
>> 
>> Thanks, that explains why others did not see it - and possibly also why
>> I could still reproduce #916349 in xterm 340, as I have my own
>> fonts.conf, albeit a much shorter and simpler one than yours.
>> 
>> Alas, with your file (saved as /tmp/fonts.conf) xterm does not even start
>> here, although I have fonts-noto-mono and fonts-noto-color-emoji
>> installed:
> 
> If xterm sees the latter, it will not start.  That's a problem that can
> only be solved by modifying Xft.  Not xterm.
> 
> But the short term goal is to get xterm working as well as feasible with
> Xft before moving on to see what can be done to make Xft handle the
> color bitmap fonts.
> 
> I'm looking for details on how to reproduce the segmentation violation
> which was reported.
>  
>> ,
>> | $ FONTCONFIG_FILE=/tmp/foo/fonts.conf xterm -fa 'Noto Mono'  
> 
> Back up a step: with that fonts.conf, I get no result for
>   fc-match 'Noto Mono'
> 
> while without it, I do get a match.  A quick look at strace tells me
> that setting FONTCONFIG_FILE eliminates a lot of the normal configuration
> information, and probably isn't what you want to do in reproducing the
> problem.

For the record: I disabled/enabled my fonts.conf by moving it out of
~/.config/fontconfig/ and then back inside. I did not set FONTCONFIG_FILE.

Also, as described in my original report, the segfault is not limited to
"Noto Mono" but seems to happen with any other font, too. (I've randomly
tried a few from my fc-list.)

>> | xterm: cannot match normal font "Noto Mono"
>> | xterm: Selected font has no non-zero height for ISO-8859-1 encoding
> 
> ...and because there's no match, for _this_ case I get the same failure.
> 
> However, that's not a bug (in xterm), but a problem with configuration.
> 
>> So I am a bit at a loss here.  And I am definitely not a an expert on
>> fontconfig (or fonts in general) either.
> 
> I'd like to see the XFT_DEBUG information from the known broken scenario.
> If it tells me that Xft is still loading the color-noto font, there's
> probably nothing that I can do to address that in xterm.

Please find attached the gzipped output of

$ XFT_DEBUG=1023 xterm -fa 'Noto Mono'

with xterm 341. All output happens directly after startup, there's no
output after issuing the command that displays the character that causes
the segfault.

Best
Alex


xterm-341-XFT_DEBUG_1023.log.gz
Description: application/gzip

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, 13:04:59 CET schrieb 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).

Indeed, that could explain it - openSUSE defaults to bash for /bin/sh,
so it fails silently (and $? gets ignored).

> >-   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?

Right :-(

(As a sidenote - I wonder why I don't see this failure on openSUSE + 
latest rc.apparmor.functions.  Intrigeri, do you have an idea what 
Debian is doing differently? If in doubt, a   sh -x   trace might be
interesting to see. A wild guess is that the
if [ -f "${SECURITYFS}/${MODULE}/profiles" ]; then
test in is_apparmor_loaded() might fail for whatever reason so the 
"return" shortcut that avoids calling is_apparmor_present() doesn't get
taken.)


Back to the bug - the failure is caused by this test:

[ $? -ne 0 -a -d /sys/module/apparmor ]

Note that the check uses   -ne   so it expects that $? != 0.
However, the while loop always ends with $? = 0, so the test always 
fails.


I'll have to do a little history lesson to explain what happened ;-)

The old version of the function was:

# Test if the apparmor "module" is present.
is_apparmor_present() {
local modules=$1
shift

while [ $# -gt 0 ] ; do
modules="$modules|$1"
shift
done

# check for subdomainfs version of module
grep -qE "^($modules)[[:space:]]" /proc/modules

[ $? -ne 0 -a -d /sys/module/apparmor ]

return $?
}

The function was called in two ways:
is_apparmor_present apparmor
is_apparmor_present apparmor subdomain
so basically /proc/modules was grepped for "apparmor" and "subdomain".
Since AppArmor gets built into the kernel (not as a module) since many 
years, that grep never found anything in /proc/modules and returned 
with $? = 1. (We could also have called "false" instead of grep - same 
result with less CPU cycles ;-)

The cleanup ("because AppArmor wasn't a kernel module since many years") 
removed that seemingly superfluous and pointless grep.

However, removing the grep means that $? no longer gets set to 1 (the 
while loop ends up with $? = 0), and that means that the function always 
fails.


That all said - can you please test with this patch?

--- a/parser/rc.apparmor.functions
+++ b/parser/rc.apparmor.functions
@@ -61,15 +62,9 @@ STATUS=0
 
 # Test if the apparmor "module" is present.
 is_apparmor_present() {
-   local modules=$1
-   shift
+   # TODO: change callers - handing over a parameter is no longer needed
 
-   while [ $# -gt 0 ] ; do
-   modules="$modules|$1"
-   shift
-   done
-
-   [ $? -ne 0 -a -d /sys/module/apparmor ]
+   [ -d /sys/module/apparmor ]
 
return $?
 }


The function should now look like this:

is_apparmor_present() {
# TODO: change callers - handing over a parameter is no longer needed

[ -d /sys/module/apparmor ]

return $?
}

> >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

That could be a Debian-specific issue - I'll let intrigeri handle this 
part ;-)  (a quick look indicates that these messages are "only" 
annoying, but shouldn't break anything)


Regards,

Christian Boltz
-- 
Honestly - I ignore every thread Basil or Linda take part in. I wonder
if we can somehow automate that. Perhaps a opensuse-factory-sane list
that is feed by opensuse-factory posts but automatically filters such
threads and posts? [Stephan Kulow in opensuse-factory]


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

Bug#917920: fakechroot: fails to find libsystemd-shared-240.so when installin systemd

2018-12-31 Thread Johannes 'josch' Schauer

Package: fakechroot
Version: 2.19-3
Severity: normal

Hi,

when installing systemd under fakechroot one currently gets the
following error during package configuration.

Setting up systemd (240-2) ...
Created symlink /etc/systemd/system/getty.target.wants/getty@tty1.service → 
/lib/systemd/system/getty@.service.
Created symlink /etc/systemd/system/multi-user.target.wants/remote-fs.target → 
/lib/systemd/system/remote-fs.target.
Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → 
/lib/systemd/system/systemd-timesyncd.service.
Created symlink 
/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → 
/lib/systemd/system/systemd-timesyncd.service.
systemd-machine-id-setup: error while loading shared libraries: 
libsystemd-shared-240.so: cannot open shared object file: No such file or 
directory
dpkg: error processing package systemd (--configure):
 installed systemd package post-installation script subprocess returned error 
exit status 127
Setting up dmsetup (2:1.02.155-1) ...
Errors were encountered while processing:
 systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)

A workaround is to add "/lib/systemd" to LD_LIBRARY_PATH. But maybe
there is a better solution. Anyways, this should work out-of-the-box.

Thanks!

cheers, josch

Bug#917919: RM: pyorbit -- ROM, RoQA; unmaintained library

2018-12-31 Thread Jeremy Bicha

Package: ftp.debian.org
X-Debbugs-Cc: pyor...@packages.debian.org
Affects: src:pyorbit
Tags: moreinfo
Control: block -1 by 917918

pyorbit has been unmaintained for years. Now that gnome-python is
being removed, it should be removed too.

pyorbit was removed from Testing a year ago:
https://bugs.debian.org/884988

On behalf of the Debian GNOME team,
Jeremy Bicha

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

2018-12-31 Thread Samuel Thibault

Control: reassign -1 fribidi
Control: tags -1 + patch

Samuel Thibault, le lun. 31 déc. 2018 17:20:42 +0100, a ecrit:
> Holger Wansing, le lun. 31 déc. 2018 16:15:12 +0100, a ecrit:
> > 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!
> 
> Indeed, I can confirm this.  I tried to copy the Jessie libnewt.so.0.52
> into a Stretch image, and it fixes the issue, so I believe the
> regression is within the newt package, thus somewhere between newt
> 0.52.17-1 and 0.52.19-1.

Ah, it's 98fa157c758d ('bidi.patch: Look for libfribidi in multi-arch
directory.'). In fribidi's udeb libfribidi.so.0 is in /lib, not
/usr/lib/$MACH, is there really a reason for doing so?  I'd say we
should move it there, i.e. the attached patch? (which I could check
as fixing the issue in the textual installer, without breaking the
graphical installer). And we can probably backport it to Stretch.

Samuel
diff --git a/debian/libfribidi0-udeb.install b/debian/libfribidi0-udeb.install
index 6b97e71..c3f6cb1 100644
--- a/debian/libfribidi0-udeb.install
+++ b/debian/libfribidi0-udeb.install
@@ -1 +1 @@
-usr/lib/*/libfribidi.so.* lib
+usr/lib/*/libfribidi.so.*

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

2018-12-31 Thread Jeremy Bicha

Package: ftp.debian.org
X-Debbugs-Cc: gnome-pyt...@packages.debian.org
Affects: src:gnome-python
Tags: moreinfo
Control: block -1 by 790584 917210

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

gnome-pythonwas removed from Testing a year ago:
https://bugs.debian.org/884986

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#917863: webext-privacy-badger: Loaded but inoperable

2018-12-31 Thread Markus Koschany

Hi Bruno,

Am 31.12.18 um 06:54 schrieb Bruno Kleinert:
> Package: webext-privacy-badger
> Version: 2018.12.17-1
> Severity: important
> 
> Hi,
> 
> in Firefox ESR (currently 60.4.0esr-1) the pluget appears as if it is
> successfully loaded, but when browsing the web it seems to do nothing.
> I.e., it doesn't show any trackers on any website where I know it will
> find some, nor does it show its own version information when clicked on
> the badger symbol in the button bar.

I have just tested privacybadger with firefox-esr in Buster but I can't
reproduce this behavior. When I go to youtube.com two trackers are
detected and successfully blocked.


> When I build and install version 2018.12.5-2 from 
> https://salsa.debian.org/webext-team/privacybadger.git, it works as
> expected: It shows trackers it detects and displays its version
> information.
> 
> However, in Firefox (non-ESR, currently 64.0-1) privacy badger works as
> expected, so it seems related only to Firefox ESR.
> 
> Cheers - Bruno

That is weird. Could you try again with 2018.12.17 after you have
cleared your Firefox cache in ~/.cache/mozilla. Is this also
reproducible when you create a complete new Firefox profile?

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#915353: vdr-plugin-skinenigmang: diff for NMU version 0.1.2+git20180128-2.1

2018-12-31 Thread Adrian Bunk

Control: tags 915353 + pending

Dear maintainer,

I've prepared an NMU for vdr-plugin-skinenigmang (versioned as 
0.1.2+git20180128-2.1)
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 vdr-plugin-skinenigmang-0.1.2+git20180128/debian/changelog vdr-plugin-skinenigmang-0.1.2+git20180128/debian/changelog
--- vdr-plugin-skinenigmang-0.1.2+git20180128/debian/changelog	2018-04-15 20:43:46.0 +0300
+++ vdr-plugin-skinenigmang-0.1.2+git20180128/debian/changelog	2018-12-31 18:17:16.0 +0200
@@ -1,3 +1,10 @@
+vdr-plugin-skinenigmang (0.1.2+git20180128-2.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix FTBFS without freetype-config. (Closes: #915353)
+
+ -- Adrian Bunk   Mon, 31 Dec 2018 18:17:16 +0200
+
 vdr-plugin-skinenigmang (0.1.2+git20180128-2) unstable; urgency=medium
 
   * VCS moved to salsa.debian.org
diff -Nru vdr-plugin-skinenigmang-0.1.2+git20180128/debian/patches/no-freetype-config vdr-plugin-skinenigmang-0.1.2+git20180128/debian/patches/no-freetype-config
--- vdr-plugin-skinenigmang-0.1.2+git20180128/debian/patches/no-freetype-config	1970-01-01 02:00:00.0 +0200
+++ vdr-plugin-skinenigmang-0.1.2+git20180128/debian/patches/no-freetype-config	2018-12-31 18:17:16.0 +0200
@@ -0,0 +1,18 @@
+Description: freetype-config was removed in Debian, switch to pkg-config
+Author: Adrian Bunk 
+
+--- vdr-plugin-skinenigmang-0.1.2+git20180128.orig/Makefile
 vdr-plugin-skinenigmang-0.1.2+git20180128/Makefile
+@@ -138,9 +138,9 @@ INCLUDES += $(shell pkg-config --cflags
+ endif
+ endif
+ 
+-ifneq ($(shell which freetype-config),)
+-	INCLUDES += $(shell freetype-config --cflags)
+-	LIBS += $(shell freetype-config --libs)
++ifneq ($(shell which pkg-config),)
++	INCLUDES += $(shell pkg-config --cflags freetype2)
++	LIBS += $(shell pkg-config --libs freetype2)
+ else
+ 	INCLUDES += -I/usr/include/freetype -I/usr/local/include/freetype
+ 	LIBS += -lfreetype
diff -Nru vdr-plugin-skinenigmang-0.1.2+git20180128/debian/patches/series vdr-plugin-skinenigmang-0.1.2+git20180128/debian/patches/series
--- vdr-plugin-skinenigmang-0.1.2+git20180128/debian/patches/series	2018-04-15 20:43:46.0 +0300
+++ vdr-plugin-skinenigmang-0.1.2+git20180128/debian/patches/series	2018-12-31 18:17:16.0 +0200
@@ -1,2 +1,3 @@
 fix-imagemagick-path.patch
 vdr-plugin-skinenigma_min_max_from_stl.patch
+no-freetype-config

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

2018-12-31 Thread Samuel Thibault

Control: reassign -1 newt
Control: fixed -1 0.52.17-1
Control: found -1 0.52.19-1

Hello,

Holger Wansing, le lun. 31 déc. 2018 16:15:12 +0100, a ecrit:
> 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!

Indeed, I can confirm this.  I tried to copy the Jessie libnewt.so.0.52
into a Stretch image, and it fixes the issue, so I believe the
regression is within the newt package, thus somewhere between newt
0.52.17-1 and 0.52.19-1.

Samuel

Bug#917915: Updating the phpunit Uploaders list

Source: phpunit
Version: 7.5.1-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Olivier Berger  has retired, so can't work on
the phpunit package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
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#917910: plasma-desktop: separate binary package for xembedsniproxy

2018-12-31 Thread Clint Adams

On Mon, Dec 31, 2018 at 04:51:21PM +0100, Pino Toscano wrote:
> > 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?

taffybar dropped gtk-traymanager support in favor of SNI.  I want
nm-applet to appear in my taffybar tray so I need to use
xembedsniproxy.  This doesn't work very well, so if there is a better
way of accomplishing this, I'm all ears.

Bug#917916: Updating the nusoap Uploaders list

Source: nusoap
Version: 0.9.5-3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Olivier Berger  has retired, so can't work on
the nusoap package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
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#917913: Updating the rdflib Uploaders list

Source: rdflib
Version: 4.2.2-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Olivier Berger  has retired, so can't work on
the rdflib package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
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#917914: Updating the planet-venus Uploaders list

Source: planet-venus
Version: 0~git9de2109-4.2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Olivier Berger  has retired, so can't work on
the planet-venus package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
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#917912: Updating the sparql-wrapper-python Uploaders list

Source: sparql-wrapper-python
Version: 1.7.6-2.1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Olivier Berger  has retired, so can't work on
the sparql-wrapper-python package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
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#914109: xscreensaver-data: looks for image files to display even though it is told not to

2018-12-31 Thread Tormod Volden

Hi,
Thanks for your bug report. I can confirm this issue, for instance by
running glitchpeg standalone:

usage: xscreensaver-getimage-file [--verbose] directory-or-feed-url

   Prints the name of a randomly-selected image file.  The directory
   is searched recursively.  Images smaller than 255x255 are excluded.

   The directory may also be the URL of an RSS/Atom feed.  Enclosed
   images will be downloaded and cached locally.

glitchpeg: unable to read

Best regards,
Tormod

On Mon, Nov 19, 2018 at 3:45 PM Francesco Potortì wrote:
>
> Even though I have this in my ~/.xscreensaver:
>
> grabDesktopImages:  True
> grabVideoFrames:False
> chooseRandomImages: False
> imageDirectory:
>
> xscreensaver gives an error saying that xscreensaver-getimage-file
> cannot find the image directory.
>
> P.S. is this package still maintained?  I see lots of very old bugs, one
> from 2001...
>

Bug#917532: RFP: fava -- web interface for the Beancount accounting tool

2018-12-31 Thread Stefano Zacchiroli

tag 917532 + pending
thanks

Fava is now in NEW.

Cheers.
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

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

2018-12-31 Thread Holger Wansing

Forwarding this to translators of relevant languages:


Hi all,

I would like to get your attention on this bugreport for the debian-installer.
It looks to me, as if RTL writing direction is no longer correct in the 
text-based installer.

But as I am not a mother-tongue speaker of the affected languages, I would like
to have some opinion/acknoledgement from you regarding this.

The bugreport contains some screenshots, where you can see the text-based an
the graphical installer - side-by-side - for all those languages.
IMO the graphical installer looks good, while the text-based one - with the
blue background - is not correct.


Note: the screenshot were created with the buster-alpha4 netinst ISO image.



Many thanks
Holger







Date: Mon, 31 Dec 2018 16:15:12 +0100
From: Holger Wansing 
To: Debian Bug Tracking System 
Subject: 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 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#917911: stretch-pu: package libdatetime-timezone-perl/1:2.09-1+2018i

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#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#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
+++

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#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#833268: task-lxde-desktop: LXDE desktop does not include a web browser

2018-12-31 Thread Holger Wansing

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#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#917909: [text-based installer] right-to-left writing direction broken

2018-12-31 Thread Holger Wansing

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#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#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#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#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#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#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