Bug#923200: libpolkit-qt5-1-1 depends on libpam-systemd

[Demi]

I have to agree with Joshua -- programs like marble or kdenlive work
just fine without systemd, but this dependency keeps them from doing
so.

Since I have a couple of boxes that are pretty heavily tinkered with
(which makes them unattractive for systemd), I just tried it, apt-get
source-d libpolkit-qt5-1-1, removed the libpam-systemd dependency in
both places in debian/rules, built and installed the package, and the
(few) kde applications I've tried installed and ran without problem.

So -- it may be that some component of kde actually depends on
systemd, but given the wide-ranging consequences of this particular
dependency (essentially shutting out non-systemd boxes from KDE
applications) it'd be great if the dependency could be limited to
that particular component.

Bug#930118: libconfig-model-dpkg-perl: adds debian/compat despite debhelper-compat

[Alex Muntada]

Hi Dominique,

> Come to think of it, I've detailed the fix mechanism (sorry
> for the headache), but, in the end, the 'cme fix' command will
> cascade the fixes to end up with 'debhelper-compat (= 12)'
> (or whatever latest release). This is similar to the current
> mechanism where a cme fix for an old compat sets compat (and
> delhelper) to latest compat value.

It makes perfect sense :) Good job!

Cheers,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer 🍥 log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Bug#931776: Apparmor and workaround

[Ruben Vorderman]

Dear maintainer,

I did some fiddling around. It appears that the .destkop files that are 
created work fine in other directories that are in $XDG_DATA_DIRS.


As a workaround I use

    sudo ln -s /var/lib/snapd/desktop/applications 
/usr/share/applications/snapd


This works (sometimes logging out and in again is required).

I think the issue is caused by the apparmor configuration. The menu 
generating process may not be allowed to access /var/lib/snapd/desktop. 
I do not have enough experience with apparmor to fully debug that. I 
tried looking in the apparmor config files, but could not find the cause 
of the issue.


Best regards,

Ruben Vorderman

Bug#931898: O: hal-flash -- Compatibility library to allow playback of Flash DRM content

[Kentaro Hayashi]

Package: wnpp
Severity: normal

I'm orphaning hal-flash because Flash is already going toward EOL gradually
and there is alternatives for it, so it's time to orphan.

Here is the hal-flash repository:

  https://salsa.debian.org/debian/hal-flash

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

The package detail(debian/control) is:

  Source: hal-flash
  Priority: optional
  Maintainer: Kentaro Hayashi 
  Build-Depends:
debhelper-compat (= 11),
pkg-config,
libdbus-1-dev,
libglib2.0-dev
  Standards-Version: 4.2.1
  Section: libs
  Homepage: https://github.com/cshorler/hal-flash
  Vcs-Browser: https://salsa.debian.org/debian/hal-flash
  Vcs-Git: https://salsa.debian.org/debian/hal-flash.git

  Package: libhal1-flash
  Architecture: any
  Depends: ${shlibs:Depends}, ${misc:Depends}, udisks2
  Suggests: flashplugin-nonfree
  Description: Compatibility library to allow playback of Flash DRM content
   A libhal stub library forwarding to UDisks specifically to satisfy the
   libflashplayer.so / libadobecp requirements.
   .
   It is loosely based upon libhal.[ch] from the hal-0.5.14 package
   for the external interface presented by the shared library libhal.
   Further information on HAL can be found here:
   http://www.freedesktop.org/wiki/Software/hal
   .
   The Adobe Flash web browser plugin for Linux relies upon libhal to provide
   information required by libadobecp (which libflashplayer.so retrieves
   from the internet) for playing back drm content.
   .
   Since HAL is no longer centric to most modern Linux systems (now there
   are succeeded product such as UDev, UDisks and so on).
   This library provides thin wrapper until such time as HTML5 becomes
   standard for online TV (many sites continue to use Flash).

Regards,

Bug#931897: librust-debcargo-dev depends on old version of librust-cargo-dev

[Steve Langasek]

Package: librust-debcargo-dev
Version: 2.2.10-1
Severity: serious
Tags: sid
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan

Hi Ximin,

The librust-debcargo-dev package is uninstallable in unstable because it
depends on older ABIs of librust-cargo-dev and librust-git2-dev:

$ sudo apt install librust-debcargo-dev
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 librust-debcargo-dev : Depends: librust-cargo-0.32+default-dev but it is not 
installable
Depends: librust-git2-0.7+default-dev but it is not 
installable
E: Unable to correct problems, you have held broken packages.
$

Please update this package.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#911189: gpgme-json chromium/firefox packaging

[Daniel Kahn Gillmor]

Hi Maximilian--

On Wed 2019-07-10 10:12:37 +0200, Maximilian Krambach wrote:
> I have been tasked to prepare "debian packages" for the gpgme-json browser 
> integration, to ease installation of native messaging between gnupg and 
> browser 
> extensions.

great, thanks for working on this!  I assume you're aware of
https://bugs.debian.org/911189 (in cc as well).  That's the best place
to talk about the debian packaging for this stuff.

> I'm working on a patch for salsa.debian.org/debian/gpgme/, as I think this is 
> probably the best place for it.

Sounds reasonable to me.

> Basically, the two packages (chromium-gpgme and firefox-gpgme) just need to 
> ensure that the gpgme-json binary ships, and that a configuration file is 
> present at paths the browsers like.
>
> My question:
> Is it okay and maintainable to add "approved" extension ids (in this case, 
> mailvelope) to these configuration files?
>
> In the end, it is an authorization between the extension(s) and the browser 
> (based on ids assigned by the browser publisher).
> gpgme-json itself does not care who communicates with them (as long as it 
> stays 
> the same actor). Still, I have the feelings that some link between worlds is 
> created that may not be desired.

This is an excellent question, and one that i did not figure out the
answer to when i was briefly researching the situation.

I wonder whether it makes more sense (and whether it's possible) to ship
the gpgme-json binary and wrapper files in one package, without any
"approved" extension IDs.  And then in the extension-specific package
(e.g. the "mailvelope" package), include the approved extension IDs.
Does that even make sense?  I don't remember the exact layouts expected.

Thanks for stepping up to do this work!

 --dkg


signature.asc
Description: PGP signature

Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

[userm57]

On 7/11/19 8:15 PM, Finn Thain wrote:
> On Thu, 11 Jul 2019, user...@yahoo.com wrote:
> ...
>>
>> Shadowfb has no effect for mach64. 
> 
> I haven't seen any results that confirm this. Your results seem to show 
> that the xorg.conf change was bogus.
> 
> Moreover, the X server logs show that the shadow framebuffer was never 
> actually enabled for any mach64 test.
> 
> So it's an open question.
> ...

Please see Xorg_sid_mach64.log.

That file has this line:

[ 16529.773] (WW) MACH64(0): Cannot shadow an accelerated frame buffer.

I take that to mean that shadowing can not work for mach64, so it is
explicitly disabled regardless of whether it is specified in an
xorg.conf file (and it must be specified somewhere by default for
mach64, since I didn't use any custom xorg.conf files).  That same
message, and no other message related to shadowing, appears in the Xorg
log regardless of whether shadowfb (or shadow_fb) is set to "true" or
"false" in a custom /etc/X11/xorg.conf file:

Section "Device"
Identifier "Mach64"
Driver "mach64"
Option "shadowfb" "true"
EndSection

This was seen in an earlier Xorg.log file that I may have only reported
but did not include (it showed that /etc/X11/xorg.conf was read and no
errors were logged regarding that file, though the above warning was
included regardless of the shadowfb, or shadow_fb, setting).

Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

[Finn Thain]

On Thu, 11 Jul 2019, user...@yahoo.com wrote:

> 
> No, for all the tests today, I used 4.19.56-debian-pmac, with the same
> kernel command line (except for root=).
> 

Right. My mistake.

> > > d) It takes approximately three seconds to open an xfce4-terminal in
> > > Debian 8.11, six seconds in Debian sid.
> ...
> > 
> > If you were to patch the X server, or change the xorg.conf (e.g. shadowfb) 
> 
> Shadowfb has no effect for mach64. 

I haven't seen any results that confirm this. Your results seem to show 
that the xorg.conf change was bogus.

Moreover, the X server logs show that the shadow framebuffer was never 
actually enabled for any mach64 test.

So it's an open question.

> I didn't test it for fbdev.

Actually, all of your fbdev tests use the shadow framebuffer, according to 
the X server logs. As Michel said, that's the default for fbdev. That's 
all good. The shadowfb test is only relevant as a workaround for the 
mach64 bug.

Anyway, the point I was trying to make here was simply that Xfce issues 
aren't necessarily X server issues (though they may be).

-- 

Bug#594506: konsole crashed (signal 11)

[D.J.J. Ring, Jr.]

It must be.  Google is having problems, their email is all being archived
instead of being sent to inbox.

Sorry to bother you. No offense was meant.

Thank you for your help!

DR

On Thu, Jul 11, 2019, 19:03 Bernhard Übelacker 
wrote:

> Hello David,
> that was not the link I sent in my mail,
> I sent a plain link to bugs.debian.org.
> Maybe you are viewing my mail via google webmail client,
> and that is adding something unwanted?
>
> Kind regards,
> Bernhard
>
>

Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

[userm57]

On 7/11/19 6:57 PM, Finn Thain wrote:
> 
> On Thu, 11 Jul 2019, user...@yahoo.com wrote:
> 
>> 8) Xorg_sid_fbdev.log: Xorg log file for test (3)
>> 9) Xorg_sid_mach64.log   : Xorg log file for test (4)
> 
> Thanks for sending these results.
> 
> Unfortunately these SID test results might be skewed because the X server 
> is continually logging "dbus-core: error connecting to system bus" at 10 
> times per second. So if you're using single-user mode, you may have to 
> start up dbus first.

Yeah, I noticed those dbus errors.  Instead of just starting dbus from
single-user, it would be easier to start multiuser, then kill wdm and
restart X from the serial console using xinit.  I can run those two
tests tomorrow (repeating tests 8 and 9 above).  And I'll capture the
console log for those tests.

> 
> Anyway, if we assume that the measurements aren't skewed, we see that the 
> majority of the the x11perf measurements have regressed (for fbdev).
> 
> But note that, unlike mach64, fbdev performance depends on both the kernel 
> fbdev driver and the x server fbdev driver. These test results were taken 
> from different kernels.

No, for all the tests today, I used 4.19.56-debian-pmac, with the same
kernel command line (except for root=).

> 
> When you make fbdev measurements, you should use the same kernel binary 
> and kernel parameters for each test. In the previous fbdev test, I think 
> you used a kernel that I built from Debian's .config --
> 
> [   236.387] Current Operating System: Linux mac-server 4.19.56-debian-pmac 
> #1 Wed Jul 3 20:08:58 AEST 2019 ppc
> [   236.387] Kernel command line: root=/dev/sda11 single ignore_loglevel 
> printk.time console=ttyS0,9600n8 video=ofonly
> 
> I think this was a good choice.
> 
> Please also capture the complete console log if convenient.
> 
>>
>> c) The glxgears tests are included for reference.  Those results give a 
>> better picture of the overall slowdown in X11 graphics from Debian 8.11 
>> to Debian sid.  The slowdown is most easily seen when running in 
>> multiuser mode with Xfce (see particularly the last two tests in the 
>> file), where the glxgears FPS is about 14.1 FPS in Debian 8.11 but only 
>> 4.7 FPS in Debian sid.  So perhaps there are some interrelated issues 
>> with Xorg and Xfce and/or mesa-utils, especially since glxgears has 
>> intermittent segmentation and illegal instruction errors (only in sid).
>>
> 
> Unfortunately, glxgears doesn't reflect the "overall slowdown". 

Well, glxgears accurately represents the slowness that I perceive on the
Desktop going from Debian 7.8 to 8.11 to sid.  It's probably also
important that the startup time (first FPS) for glxgears is much lower
in sid, and of course the segmentation and illegal instruction errors
are probably important as well (but those may be an issue with
mesa-utils, or possibly related to the dbus issue).

> More data 
> is always good, however, the x11perf microbenchmarks are more tightly 
> focused.
> 
>> d) It takes approximately three seconds to open an xfce4-terminal in
>> Debian 8.11, six seconds in Debian sid.
>>
> 
> A 50% slowdown is serious. But it may not be caused by Xorg.

Right.  The 50% slowdown could just as easily be caused by Xfce, fvwm,
or even xfce-terminal.

> 
> If you were to patch the X server, or change the xorg.conf (e.g. shadowfb) 

Shadowfb has no effect for mach64.  I didn't test it for fbdev.  For
these tests, I didn't use shadowfb, or any custom xorg.conf files.

> or downgrade all of the X server packages, and if this fixed the slowdown, 
> then that would prove that the regression was in the X server.
> 
> But it seems that you already have x11perf results which demonstrate an X 
> server performance regression. Fixing this may or may not fix the Xfce 
> slowdown. It remains to be seen.
> 
>> e) Moving and resizing windows might be faster in all versions of Debian 
>> if the default setting would be to highlight only the window borders 
>> while moving or resizing, instead of including the window contents. This 
>> is probably an Xfce setting.
>>
> 
> Right. If Xfce doesn't offer this feature, there are certainly other 
> window managers that do offer this.

ok.  It appears that Gnome and KDE both require systemd now, at least in
Debian, and twm is a bit limited.  I think Xfce uses fvwm, so I could
probably use fvwm separately without Xfce (say, by starting X with
startx).  It's probably also possible to compile gnome and KDE without
systemd support, but that's beyond the scope of the current tests and
might break other things (in Debian).

> 
> If this is an Xfce bug, you'll need to file a bug report against that 
> package, in order to reach the relevant developers.
> 

Bug#931895: unzip: zip bomb false positives in Java ecosystem

[Ben Caradoc-Davies]

With the 17 affected jar files in the current working directory:

unzip 6.0-23:

$ for f in *.jar; do echo $f; unzip -tq $f; done
asm-5.0.3-sources.jar
No errors detected in compressed data of asm-5.0.3-sources.jar.
asm-analysis-5.0.3-sources.jar
No errors detected in compressed data of asm-analysis-5.0.3-sources.jar.
asm-tree-5.0.3-sources.jar
No errors detected in compressed data of asm-tree-5.0.3-sources.jar.
asm-util-5.0.3-sources.jar
No errors detected in compressed data of asm-util-5.0.3-sources.jar.
gradle-kotlin-dsl-5.4.1.jar
No errors detected in compressed data of gradle-kotlin-dsl-5.4.1.jar.
gradle-kotlin-dsl-5.5.1.jar
No errors detected in compressed data of gradle-kotlin-dsl-5.5.1.jar.
gradle-kotlin-dsl-provider-plugins-5.4.1.jar
No errors detected in compressed data of 
gradle-kotlin-dsl-provider-plugins-5.4.1.jar.

gradle-kotlin-dsl-provider-plugins-5.5.1.jar
No errors detected in compressed data of 
gradle-kotlin-dsl-provider-plugins-5.5.1.jar.

gradle-kotlin-dsl-tooling-builders-5.4.1.jar
No errors detected in compressed data of 
gradle-kotlin-dsl-tooling-builders-5.4.1.jar.

gradle-kotlin-dsl-tooling-builders-5.5.1.jar
No errors detected in compressed data of 
gradle-kotlin-dsl-tooling-builders-5.5.1.jar.

groovy-all-1.0-2.5.4.jar
No errors detected in compressed data of groovy-all-1.0-2.5.4.jar.
spring-beans-4.2.5.RELEASE-sources.jar
No errors detected in compressed data of 
spring-beans-4.2.5.RELEASE-sources.jar.

spring-beans-4.3.16.RELEASE-sources.jar
No errors detected in compressed data of 
spring-beans-4.3.16.RELEASE-sources.jar.

spring-beans-4.3.18.RELEASE-sources.jar
No errors detected in compressed data of 
spring-beans-4.3.18.RELEASE-sources.jar.

spring-beans-4.3.7.RELEASE-sources.jar
No errors detected in compressed data of 
spring-beans-4.3.7.RELEASE-sources.jar.

spring-orm-4.2.5.RELEASE-sources.jar
No errors detected in compressed data of 
spring-orm-4.2.5.RELEASE-sources.jar.

spring-orm-4.3.7.RELEASE-sources.jar
No errors detected in compressed data of 
spring-orm-4.3.7.RELEASE-sources.jar.


unzip 6.0-24:

$ for f in *.jar; do echo $f; unzip -tq $f; done
asm-5.0.3-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
asm-analysis-5.0.3-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
asm-tree-5.0.3-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
asm-util-5.0.3-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
gradle-kotlin-dsl-5.4.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
gradle-kotlin-dsl-5.5.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
gradle-kotlin-dsl-provider-plugins-5.4.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
gradle-kotlin-dsl-provider-plugins-5.5.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
gradle-kotlin-dsl-tooling-builders-5.4.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
gradle-kotlin-dsl-tooling-builders-5.5.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
groovy-all-1.0-2.5.4.jar
error: invalid zip file with overlapped components (possible zip bomb)
spring-beans-4.2.5.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
spring-beans-4.3.16.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
spring-beans-4.3.18.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
spring-beans-4.3.7.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
spring-orm-4.2.5.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
spring-orm-4.3.7.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

[Finn Thain]

On Thu, 11 Jul 2019, user...@yahoo.com wrote:

> 8) Xorg_sid_fbdev.log: Xorg log file for test (3)
> 9) Xorg_sid_mach64.log   : Xorg log file for test (4)

Thanks for sending these results.

Unfortunately these SID test results might be skewed because the X server 
is continually logging "dbus-core: error connecting to system bus" at 10 
times per second. So if you're using single-user mode, you may have to 
start up dbus first.

Anyway, if we assume that the measurements aren't skewed, we see that the 
majority of the the x11perf measurements have regressed (for fbdev).

But note that, unlike mach64, fbdev performance depends on both the kernel 
fbdev driver and the x server fbdev driver. These test results were taken 
from different kernels.

When you make fbdev measurements, you should use the same kernel binary 
and kernel parameters for each test. In the previous fbdev test, I think 
you used a kernel that I built from Debian's .config --

[   236.387] Current Operating System: Linux mac-server 4.19.56-debian-pmac #1 
Wed Jul 3 20:08:58 AEST 2019 ppc
[   236.387] Kernel command line: root=/dev/sda11 single ignore_loglevel 
printk.time console=ttyS0,9600n8 video=ofonly

I think this was a good choice.

Please also capture the complete console log if convenient.

> 
> c) The glxgears tests are included for reference.  Those results give a 
> better picture of the overall slowdown in X11 graphics from Debian 8.11 
> to Debian sid.  The slowdown is most easily seen when running in 
> multiuser mode with Xfce (see particularly the last two tests in the 
> file), where the glxgears FPS is about 14.1 FPS in Debian 8.11 but only 
> 4.7 FPS in Debian sid.  So perhaps there are some interrelated issues 
> with Xorg and Xfce and/or mesa-utils, especially since glxgears has 
> intermittent segmentation and illegal instruction errors (only in sid).
> 

Unfortunately, glxgears doesn't reflect the "overall slowdown". More data 
is always good, however, the x11perf microbenchmarks are more tightly 
focused.

> d) It takes approximately three seconds to open an xfce4-terminal in
> Debian 8.11, six seconds in Debian sid.
> 

A 50% slowdown is serious. But it may not be caused by Xorg.

If you were to patch the X server, or change the xorg.conf (e.g. shadowfb) 
or downgrade all of the X server packages, and if this fixed the slowdown, 
then that would prove that the regression was in the X server.

But it seems that you already have x11perf results which demonstrate an X 
server performance regression. Fixing this may or may not fix the Xfce 
slowdown. It remains to be seen.

> e) Moving and resizing windows might be faster in all versions of Debian 
> if the default setting would be to highlight only the window borders 
> while moving or resizing, instead of including the window contents. This 
> is probably an Xfce setting.
> 

Right. If Xfce doesn't offer this feature, there are certainly other 
window managers that do offer this.

If this is an Xfce bug, you'll need to file a bug report against that 
package, in order to reach the relevant developers.

-- 

> -Stan Johnson
>  user...@yahoo.com
> 

Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found

[Sebastian Ramacher]

Package: grub-efi-amd64
Version: 2.04-1
Severity: grave

Hi,

since the last update the grub no longer works. It fails very early with

symbol `grub_file_filters` not found

and enters the rescue shell. After downgrading it back to 2.02+dfsg1-20
everything works again as expected.

Cheers


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/neptun-vg/root / ext4 rw,relatime 0 0
/dev/sda2 /boot ext2 rw,relatime,block_validity,barrier,user_xattr,acl 0 0
/dev/sda1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  
d7aaa367-61ca-446f-b815-c2e79b8e4dfa
else
  search --no-floppy --fs-uuid --set=root d7aaa367-61ca-446f-b815-c2e79b8e4dfa
fi
font="/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  
d7aaa367-61ca-446f-b815-c2e79b8e4dfa
else
  search --no-floppy --fs-uuid --set=root d7aaa367-61ca-446f-b815-c2e79b8e4dfa
fi
insmod png
if background_image /grub/.background_cache.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-74ba39e5-850a-42b8-93da-84fc7730af1e' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  
d7aaa367-61ca-446f-b815-c2e79b8e4dfa
else
  search --no-floppy --fs-uuid --set=root 
d7aaa367-61ca-446f-b815-c2e79b8e4dfa
fi
echo'Loading Linux 4.19.0-5-amd64 ...'
linux   /vmlinuz-4.19.0-5-amd64 root=/dev/mapper/neptun--vg-root ro 
intel_iommu=off quiet
echo'Loading initial ramdisk ...'
initrd  /initrd.img-4.19.0-5-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-74ba39e5-850a-42b8-93da-84fc7730af1e' {
menuentry 'Debian GNU/Linux, with Linux 4.19.0-5-amd64' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-4.19.0-5-amd64-advanced-74ba39e5-850a-42b8-93da-84fc7730af1e' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 
fi
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint =

Bug#931895: unzip: zip bomb false positives in Java ecosystem

[Ben Caradoc-Davies]

Package: unzip
Version: 6.0-24
Severity: normal

Dear Maintainer,

zip bomb detection introduced in 6.0-24 (see #931433
 and CVE-2019-13232)
causes unzip to reject many jar files distributed in the Java ecosystem.

Workaround is to downgrade to unzip 6.0-23.

Examples:

$ find .gradle .m2 java -name "*.jar" -type f -size +0c -print -exec unzip -tq
{} \; 2>&1 | grep -B1 invalid
.gradle/wrapper/dists/gradle-5.2.1-bin/9lc4nzslqh3ep7ml2tp68fk8s/gradle-5.2.1/lib/groovy-
all-1.0-2.5.4.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.gradle/wrapper/dists/gradle-5.4.1-bin/e75iq110yv9r9wt1a6619x2xm/gradle-5.4.1/lib/gradle-
kotlin-dsl-5.4.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.gradle/wrapper/dists/gradle-5.4.1-bin/e75iq110yv9r9wt1a6619x2xm/gradle-5.4.1/lib/plugins/gradle-
kotlin-dsl-tooling-builders-5.4.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.gradle/wrapper/dists/gradle-5.4.1-bin/e75iq110yv9r9wt1a6619x2xm/gradle-5.4.1/lib/plugins/gradle-
kotlin-dsl-provider-plugins-5.4.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.gradle/wrapper/dists/gradle-5.4.1-bin/e75iq110yv9r9wt1a6619x2xm/gradle-5.4.1/lib/groovy-
all-1.0-2.5.4.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/ow2/asm/asm-tree/5.0.3/asm-tree-5.0.3-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/ow2/asm/asm-util/5.0.3/asm-util-5.0.3-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/ow2/asm/asm/5.0.3/asm-5.0.3-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/ow2/asm/asm-analysis/5.0.3/asm-analysis-5.0.3-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/springframework/spring-orm/4.2.5.RELEASE/spring-
orm-4.2.5.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/springframework/spring-orm/4.3.7.RELEASE/spring-
orm-4.3.7.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/springframework/spring-beans/4.3.16.RELEASE/spring-
beans-4.3.16.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/springframework/spring-beans/4.2.5.RELEASE/spring-
beans-4.2.5.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/springframework/spring-beans/4.3.18.RELEASE/spring-
beans-4.3.18.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
.m2/repository/org/springframework/spring-beans/4.3.7.RELEASE/spring-
beans-4.3.7.RELEASE-sources.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
java/gradle-5.5.1/lib/plugins/gradle-kotlin-dsl-tooling-builders-5.5.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
java/gradle-5.5.1/lib/plugins/gradle-kotlin-dsl-provider-plugins-5.5.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
--
java/gradle-5.5.1/lib/gradle-kotlin-dsl-5.5.1.jar
error: invalid zip file with overlapped components (possible zip bomb)
java/gradle-5.5.1/lib/groovy-all-1.0-2.5.4.jar
error: invalid zip file with overlapped components (possible zip bomb)

Kind regards,
Ben.



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

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

Versions of packages unzip depends on:
ii  libbz2-1.0  1.0.6-9.2
ii  libc6   2.28-10

unzip recommends no packages.

Versions of packages unzip suggests:
ii  zip  3.0-11+b1

-- no debconf information

Bug#931746: neomutt: /etc/neomuttrc tries to source /usr/lib/neomutt/source-neomuttrc.d which is not existing

[Norbert Preining]

On Thu, 11 Jul 2019, Julian Andres Klode wrote:
> I have NMUed to DELAYED/1, a diff was sent to the bug report, but

Thnaks!

Norbert

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

Bug#931894: Say 'no space left on device' instead of "Output error"

[積丹尼 Dan Jacobson]

Package: at
Version: 3.1.23-1
Severity: wishlist

Please just say 'no space left on device' instead of

$ echo echo test | batch
warning: commands will be executed using /bin/sh
at: Output error

Bug#931893: ITP: sphinx-autodoc-typehints -- Type hints support for the Sphinx autodoc extension

[William Grzybowski]

Package: wnpp
Severity: wishlist
Owner: William Grzybowski 

* Package name: sphinx-autodoc-typehints
  Version : 1.6.0
  Upstream Author : Alex Grönholm 
* URL : https://github.com/agronholm/sphinx-autodoc-typehints
* License : MIT
  Programming Lang: Python
  Description : Type hints support for the Sphinx autodoc extension

This extension allows you to use Python 3 annotations for documenting
acceptable argument types and return value types of functions.

This is relevant to build documentation of some python modules. Its currently a
dependency for sentry-python.
I plan to maintain it myself, or within DPMT team if they allow me.

Bug#931892: gnome: Gnome GUI Privacy settings are ignored.

[Damien]

Package: gnome
Version: 1:3.30+1
Severity: serious
Tags: security
Justification: 5

Dear Maintainer,

It became apparent that despite explicit settings of gnome desktop environment 
"Settings -> All Settings -> Privacy -> Location Services" set to "OFF", 
package 'geoclue-2.0' along with packages depending on it, such as 
'gnome-clocks' ignore settings and continue to send requests via networking 
stack to identify hosts geographical location. 

Could some one from Debian security team review this bug and hopefully provide 
a work around to stop gnome desktop environment along with packages 
'gnome-clocks' & 'geoclue-2.0' from contacting remote services over the 
network, tracing the hosts geo-location?

Any help to stop geo-location tracing/checking/calculating/guestimating - would 
be greatly appreciated.

PS: Debian Dev Team, please note, nether package 'gnome-clocks' or 
'geoclue-2.0' have NO man pages available, and therefore there is no way for a 
user of the host to find out how to disable geo-tracing functionality.

Per Debian regulations: 

https://release.debian.org/testing/rc_policy.txt

... Section 5(o) - 'Packages must have a useful extended description.' there 
should be some sort of a documentation that would informed a user of the host 
what options are available to modify unwanted, and this case, privacy related 
behavior to be changes or stopped.

At the same time, while explicit settings for privacy gui element of a GNOME 
environment exist, they appear to be meaningless in terms geo location tracing 
of the host.

Damien.

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=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 gnome depends on:
ii  avahi-daemon 0.7-4+b1
ii  cheese   3.31.90-1
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 10.0.2
ii  evolution3.30.5-1.1
ii  evolution-plugins3.30.5-1.1
ii  file-roller  3.30.1-2
ii  gedit-plugins3.30.1-3
ii  gnome-calendar   3.30.1-2
ii  gnome-clocks 3.30.1-2
ii  gnome-color-manager  3.30.0-2
ii  gnome-core   1:3.30+1
ii  gnome-documents  3.31.92-1
ii  gnome-getting-started-docs   3.30.0-1
ii  gnome-maps   3.30.3-1
ii  gnome-music  3.30.2-1
ii  gnome-screenshot 3.30.0-2
ii  gnome-sound-recorder 3.28.2-1
ii  gnome-todo   3.28.1-2
ii  gnome-tweaks 3.30.2-1
ii  gnome-weather3.26.0-5
ii  gstreamer1.0-libav   1.15.0.1+git20180723+db823502-2
ii  gstreamer1.0-plugins-ugly1.14.4-1
ii  libgsf-bin   1.14.45-1
ii  libproxy1-plugin-networkmanager  0.4.15-5
ii  libreoffice-calc 1:6.1.5-3
ii  libreoffice-gnome1:6.1.5-3
ii  libreoffice-impress  1:6.1.5-3
ii  libreoffice-writer   1:6.1.5-3
ii  nautilus-sendto  3.8.6-3
ii  network-manager-gnome1.8.20-1.1
ii  orca 3.30.1-1
ii  rhythmbox3.4.3-2
ii  rhythmbox-plugin-cdrecorder  3.4.3-2
ii  rhythmbox-plugins3.4.3-2
ii  rygel-playbin0.36.2-4
ii  rygel-tracker0.36.2-4
ii  seahorse 3.30.1.1-1
ii  shotwell 0.30.1-1
ii  simple-scan  3.30.1.1-1+b1
ii  totem-plugins3.30.0-4
ii  vinagre  3.22.0-6
ii  vino 3.22.0-5
ii  xdg-user-dirs-gtk0.10-3

Versions of packages gnome recommends:
ii  gnome-games 1:3.30+1
ii  nautilus-extension-brasero  3.12.2-5
ii  transmission-gtk2.94-2

Versions of packages gnome suggests:
pn  alacarte 
pn  empathy  
pn  firefox-esr-l10n-all | firefox-l10n-all  
pn  gnome-remote-desktop 
pn  goobox | sound-juicer
pn  polari   
pn  webext-ublock-origin 

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme3.30.1-1
ii  at-spi2-core  2.30.0-7
ii  baobab3.30.0-2
ii  caribou   0.4.21-7
ii  dconf-cli 0.30.1-2
ii  dconf-gsettings-backend   0.30.1-2
ii  eog   3.28.4-2+b1
ii  evince3.30.2-3
ii  evolution-data-server 3.30

Bug#931881: diffoscope: undeclared versioned dependency on file

[Mattia Rizzolo]

mh, no.  I think some logic needs tweaking, as file is definitely present
(it's an hard dependency of diffoscope), and that test should just be
skipped.

On Thu, Jul 11, 2019 at 11:42 PM Chris Lamb  wrote:

> Steve Langasek wrote:
>
> > At the very least, it seems this should be a versioned test dep on file
> (>=
> > 5.37), but perhaps it should also be a versioned runtime dependency. I
> > haven't looked to see what the impact is of the wrong version of 'file'
> when
> > DIFFOSCOPE_TESTS_FAIL_ON_MISSING_TOOLS is not set.
>
> I think we need to add "file" to the DIFFOSCOPE_TESTS_MISSING_TOOLS
> list in debian/tests/pytest. Mattia, can you confirm?
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
>`-
>
>

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

Bug#594506: konsole crashed (signal 11)

[Bernhard Übelacker]

Hello David,
that was not the link I sent in my mail,
I sent a plain link to bugs.debian.org.
Maybe you are viewing my mail via google webmail client,
and that is adding something unwanted?

Kind regards,
Bernhard

Bug#924516: geoclue-2.0: Privacy settings ignored by gnome and geoclue

[Damien]

Package: geoclue-2.0
Version: 2.5.2-1
Followup-For: Bug #924516

Dear Maintainer,

This issue still present in a new Debian 10 'Buster' release.

Privacy settings in gnome desktop environment ignored.
While, "Settings -> All Settings -> Privacy -> Location Services" set to "OFF", 
package 'geoclue-2.0' ignores settings and continues to send requests via 
networking stack to identify hosts geographical location. 

Could some one from Dabien security team review this bug and hopefully provide 
a work around to stop 'geoclue-2.0' from contacting remote services over the 
network, tracing the hosts geo-location?

Any help would be greatly appreciated.

Damien.


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=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 geoclue-2.0 depends on:
ii  adduser 3.118
ii  libavahi-client30.7-4+b1
ii  libavahi-common30.7-4+b1
ii  libavahi-glib1  0.7-4+b1
ii  libc6   2.28-10
ii  libglib2.0-02.58.3-2
ii  libjson-glib-1.0-0  1.4.4-2
ii  libmm-glib0 1.10.0-1
ii  libnotify4  0.7.7-4
ii  libsoup2.4-12.64.2-2

Versions of packages geoclue-2.0 recommends:
ii  avahi-daemon  0.7-4+b1
ii  iio-sensor-proxy  2.4-2
ii  modemmanager  1.10.0-1
ii  wpasupplicant 2:2.7+git20190128+0c1e29f-6

geoclue-2.0 suggests no packages.

-- no debconf information

Bug#931844: libqt5gui5: Endless loop in konsole showing midnight commander with activated orca screenreader.

[Bernhard Übelacker]

Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-77017


Dear Maintainer,
I created an upstream bug report and forward this bug to it.

Kind regards,
Bernhard

Bug#924516: geoclue-2.0: Privacy settings ignored by gnome and geoclue-2.0

[Demien]

Package: geoclue-2.0
Version: 2.4.5-1
Followup-For: Bug #924516

Dear Maintainer,

It became apparent that despite explicit settings of gnome desktop environment 
"Settings -> All Settings -> Privacy -> Location Services" set to "OFF", 
package 'geoclue-2.0' ignores settings and continues to send requests via 
networking stack to identify hosts geographical location. 

Could some one from Dabien security team review this bug and hopefully provide 
a work around to stop 'geoclue-2.0' from contacting remote services over the 
network, tracing the hosts geo-location?

Any help would be greatly appreciated.

Damien.

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

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

Versions of packages geoclue-2.0 depends on:
ii  adduser 3.115
ii  libavahi-client30.6.32-2
ii  libavahi-common30.6.32-2
ii  libavahi-glib1  0.6.32-2
ii  libc6   2.24-11+deb9u4
ii  libgeoclue-2-0  2.4.5-1
ii  libglib2.0-02.50.3-2
ii  libjson-glib-1.0-0  1.2.6-1
ii  libmm-glib0 1.6.4-1
ii  libsoup2.4-12.56.0-2+deb9u2

Versions of packages geoclue-2.0 recommends:
ii  avahi-daemon  0.6.32-2
ii  iio-sensor-proxy  2.0-4
ii  modemmanager  1.6.4-1
ii  wpasupplicant 2:2.4-1+deb9u4

geoclue-2.0 suggests no packages.

-- no debconf information

Bug#931891: dh_dwz: handle compressed debug sections?

[Matthias Klose]

Package: debhelper,lintian
Severity: wishlist

dwz currently doesn't handle compressed debug sections.  In the first place, why
should we have these, because or dbg packages are compressed anyway. otoh, these
are enabled by some upstreams like ruby.

So what dh_dwz could do, is

 - look for SHF_COMPRESSED
 - objcopy --decompress-debug-sections
 - dwz
 - objcopy --compress-debug-sections

Or lintian could just warn about compressed debug sections.

Bug#931540: transition: statsmodels 0.8 -> 0.9 or 0.10

[Rebecca N. Palmer]

0.9 in salsa is now buildable (but _not_ ready for upload).  With this 
version installed:

seaborn, tnseq-transit: build successful
pymvpa2: the same FTBFS as with 0.8 (#931888)

pandas only build-depends on statsmodels for documentation examples (run 
during build), and the others import (somewhere in their source, which 
might be in an example) but don't (build-/autopkgtest-)depend.


Python 2 can't be dropped at this point, as tnseq-transit and pymvpa2 
are Python 2 only hard (Build-)Depends.  (I suspect they will get 
removed for this, but that's not my choice to make.)

Bug#426283: prosper: 'p' as om 'page' is not translated

[Hilmar Preuße]

tags 426283 + wontfix
stop

On 27.05.07 19:08, Vincent Lönngren wrote:

Hi,

> In the lower right corner, 'p. X' is displayed where X is the number
> of the current page. 'p' isn't translated even when babel is loaded
> with a language other than English.
> 
According to [1] The current maintainer of this package is Fred­eric
Goualard. In his web page [2] I find the statement:

Since 1996, I have developed many LaTeX packages, mostly used only
locally at the labs I was employed at the time. For my PhD defense in
2000, I developed Prosper, a package to write more beautiful LaTeX
slides in a simpler way than what was available at the time. Somehow, it
filled a need and caught on. However, Prosper heavily relies on Adobe
Postscript, and cannot be used when producing Adobe PDF files directly
from the LaTeX source, as would be done by a tool such as pdflatex. With
more modern contenders around, I decided in 2009 to stop supporting it.
If you are now making the move to LaTeX slide design, please consider
packages like Powerdot (self-advertised as ``based on Prosper'') or
Beamer (my favorite, and the one I myself use now) instead.

So we won't get a bug fix for it. Tagging it wontfix for now.

H.

[1] https://ctan.org/pkg/prosper?lang=de
[2] http://frederic.goualard.net/
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#237382: prosper: Wrong handling of stated .eps file

[Hilmar Preuße]

tags 237382 + wontfix
stop

On 11.03.04 12:02, Ajay Shah wrote:

Hi,

> I have attached a file.tex that eats two .eps files. One of them is
> just to persuade me that nothing basic is broken. The other of them
> (the 1st of the two files) gets wrongly rotated when I do the steps:
> 
>  $ latex file.tex
>  $ dvips file.dvi
>  $ ps2pdf file.ps
> 
> In gv, both .eps files show up correctly.
> 
> The .pdf file that I get out of the above steps is attached, so you
> can see what is going wrong.
> 
According to [1] The current maintainer of this package is Fred­eric
Goualard. In his web page [2] I find the statement:

Since 1996, I have developed many LaTeX packages, mostly used only
locally at the labs I was employed at the time. For my PhD defense in
2000, I developed Prosper, a package to write more beautiful LaTeX
slides in a simpler way than what was available at the time. Somehow, it
filled a need and caught on. However, Prosper heavily relies on Adobe
Postscript, and cannot be used when producing Adobe PDF files directly
from the LaTeX source, as would be done by a tool such as pdflatex. With
more modern contenders around, I decided in 2009 to stop supporting it.
If you are now making the move to LaTeX slide design, please consider
packages like Powerdot (self-advertised as ``based on Prosper'') or
Beamer (my favorite, and the one I myself use now) instead.

So we won't get a bug fix for it. Tagging it wontfix for now.

H.

[1] https://ctan.org/pkg/prosper?lang=de
[2] http://frederic.goualard.net/
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#216283: prosper: \date does not work with serpaggi

[Hilmar Preuße]

tags 216283 + wontfix
stop

On 17.10.03 19:35, Ajay Shah wrote:

Hi,

> I do
> 
> \documentclass[pdf,serpaggi,slideColor,colorBG]{prosper}
> According to [1] The current maintainer of prosper is Fred­eric
Goualard. In his web page [2] I find the statement:

Since 1996, I have developed many LaTeX packages, mostly used only
locally at the labs I was employed at the time. For my PhD defense in
2000, I developed Prosper, a package to write more beautiful LaTeX
slides in a simpler way than what was available at the time. Somehow, it
filled a need and caught on. However, Prosper heavily relies on Adobe
Postscript, and cannot be used when producing Adobe PDF files directly
from the LaTeX source, as would be done by a tool such as pdflatex. With
more modern contenders around, I decided in 2009 to stop supporting it.
If you are now making the move to LaTeX slide design, please consider
packages like Powerdot (self-advertised as ``based on Prosper'') or
Beamer (my favorite, and the one I myself use now) instead.

So we won't get a bug fix for it. Tagging it wontfix for now.

H.

[1] https://ctan.org/pkg/prosper?lang=de
[2] http://frederic.goualard.net/
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#931798: anki: The "Enter" key to save the audio rather than cancel the recording.

[Julian Gilbey]

forwarded 931798 
https://anki.tenderapp.com/discussions/ankidesktop/34985-make-save-the-default-option-when-recording-audio
thanks

On Wed, Jul 10, 2019 at 05:53:23PM +0300, Jury Mazurov wrote:
> Package: anki
> Version: 2.1.8+dfsg-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> In Anki, when you save the sound, the "Cancel" key is active by default.
> When repeating 50 - 100 words per day is not convenient.
> 
> I suggest a patch.

Thanks for this patch.  I've submitted it upstream, but it turns out
that there's something stranger going on.  I've come up with a better
patch; have a look at the upstream bug report to see more.

Best wishes,

   Julian

Bug#931679: /sbin/e2scrub_all: e2scrub_all -r passes the snapshot, but e2scrub -r expects the original

[Theodore Ts'o]

Control: tag -1 +pending

On Tue, Jul 09, 2019 at 06:36:03PM +1000, Trent W. Buck wrote:
> Package: e2fsprogs
> Version: 1.45.2-1
> Severity: minor
> File: /sbin/e2scrub_all
> 
> e2scrub_all calls e2scrub with the wrong argument:

Thanks for the bug report!  This will be fixed in the next release of
e2fsprogs.

- Ted

commit 9b2c33f9daaecc593755fa6d45b6d910f8fe2f7b
Author: Theodore Ts'o 
Date:   Thu Jul 11 13:28:05 2019 -0400

e2scrub_all: fix "e2scurb_all -r"

The e2scrub_all program was broken by commit c7d6525ecaab
("e2scrub_all: refactor device probe loop") so that it would use the
path of the snapshot volume instead of the base volume.  This caused
"e2scrub_all -r" to pass the wrong pathname to e2scrub, with the
result that e2scrub would abort with an error instead of removing the
snapshot volume.

Fixes: c7d6525ecaab ("e2scrub_all: refactor device probe loop")
Addresses-Debian-Bug: #931679
Signed-off-by: Theodore Ts'o 

diff --git a/scrub/e2scrub_all.in b/scrub/e2scrub_all.in
index 24b2c681..f342faf2 100644
--- a/scrub/e2scrub_all.in
+++ b/scrub/e2scrub_all.in
@@ -115,7 +115,8 @@ ls_scan_targets() {
 
 # Find leftover scrub snapshots
 ls_reap_targets() {
-   lvs -o lv_path -S lv_role=snapshot -S lv_name=~\(e2scrub$\) --noheadings
+lvs -o lv_path -S lv_role=snapshot -S lv_name=~\(e2scrub$\) \
+   --noheadings | sed -e 's/.e2scrub$//'
 }
 
 # Figure out what we're targeting

Bug#931881: diffoscope: undeclared versioned dependency on file

[Chris Lamb]

Steve Langasek wrote:

> At the very least, it seems this should be a versioned test dep on file (>=
> 5.37), but perhaps it should also be a versioned runtime dependency. I
> haven't looked to see what the impact is of the wrong version of 'file' when
> DIFFOSCOPE_TESTS_FAIL_ON_MISSING_TOOLS is not set.

I think we need to add "file" to the DIFFOSCOPE_TESTS_MISSING_TOOLS
list in debian/tests/pytest. Mattia, can you confirm?


Regards,

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

Bug#931890:

[Klaus-J. Wolf]

I suppose some scripts broken with "newer" kernels (but which?), packages
missing, or required preparations undocumented.

Bug#931730: libfile-stripnondeterminism-perl: build dependency cycle with libsub-identify-perl

[Chris Lamb]

Hi Niko,

> > I guess in theory but if I recall the details correctly, I don't
> > /think/ this was going to be a trivial patch to Archive::Zip and my
> > Perl-fu is/was a bit weak. Would pkg-perl apply and upload a patch
> > anyway?
[…]
> Obviously features would be best developed upstream. Archive-Zip seems
> to be alive if quiet. But a bug against libarchive-zip-perl would be a
> good start (with or without a patch).

Nod. I'll work on a proper patch to libarchive-zip-perl over the next
few days.


Regards,

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

Bug#895534: closed by Debian FTP Masters

[Simon McVittie]

On Thu, 11 Jul 2019 at 18:51:18 +, Debian Bug Tracking System wrote:
> #895534: override: libgtkgl2.0-1:oldlibs/optional, 
> libgtkgl2.0-dev:oldlibs/optional, libgtkglext1:oldlibs/optional, 
> libgtkglext1-dev:oldlibs/optional, libgtkglext1-doc:oldlibs/optional, 
> libgtkglextmm-x11-1.2-dev:oldlibs/optional, 
> libgtkglextmm-x11-1.2-0v5:oldlibs/optional, python-gtkglext1:oldlibs/optional
...
> Concerning package libgtkgl2.0-1...
> Operating on the unstable suite
> Changed section from libs to oldlibs

I asked for multiple binary packages to be overridden, including but not
limited to libgtkgl2.0-1:

> libgtkgl2.0-1:oldlibs/optional
> libgtkgl2.0-dev:oldlibs/optional
> libgtkglext1-dev:oldlibs/optional
> libgtkglext1-doc:oldlibs/optional
> libgtkglext1:oldlibs/optional
> libgtkglextmm-x11-1.2-0v5:oldlibs/optional
> libgtkglextmm-x11-1.2-dev:oldlibs/optional
> python-gtkglext1:oldlibs/optional

Do the ftp team prefer to receive a separate bug report for each binary
package that is deprecated and should be overridden into oldlibs?

Or am I misinterpreting the email that closed this bug? Was the action
actually taken on multiple binary packages?

Thanks,
smcv

Bug#931888: pymvpa2 FTBFS: test_assert_objectarray_equal / test_vector_alignment_find_rotation_illegal_inputs

[Rebecca N. Palmer]

Source: pymvpa2
Version: 2.6.5-1
Severity: serious

This package FTBFS in sid (plain dpkg-buildpackage) with these test 
failures (which are different from the ones in #906399, but the same as 
the ones in reproducible-builds).


This bug was found during statsmodels 0.9 transition testing, but also 
occurs with current (0.8) statsmodels.


As this is a Python 2 only package (in Debian, I didn't check upstream), 
it may make sense to remove it rather than try to fix this.


==
ERROR: mvpa2.tests.test_testing.test_assert_objectarray_equal
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in 
runTest

self.test(*self.arg)
  File 
"/home/test1/pymvpa2-2.6.5/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/tests/test_testing.py", 
line 39, in test_assert_objectarray_equal

assert_objectarray_equal(a, a.copy(), strict=strict)
  File 
"/home/test1/pymvpa2-2.6.5/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/testing/tools.py", 
line 472, in assert_objectarray_equal

assert_array_equal(x, y)
  File 
"/usr/lib/python2.7/dist-packages/numpy/testing/_private/utils.py", line 
896, in assert_array_equal

verbose=verbose, header='Arrays are not equal')
  File 
"/usr/lib/python2.7/dist-packages/numpy/testing/_private/utils.py", line 
827, in assert_array_compare

raise ValueError(msg)
ValueError:
error during assertion:

Traceback (most recent call last):
  File 
"/usr/lib/python2.7/dist-packages/numpy/testing/_private/utils.py", line 
803, in assert_array_compare

max_abs_error = error.max()
  File "/usr/lib/python2.7/dist-packages/numpy/core/_methods.py", line 
28, in _amax

return umr_maximum(a, axis, None, out, keepdims, initial)
ValueError: The truth value of an array with more than one element is 
ambiguous. Use a.any() or a.all()



Arrays are not equal
 x: array([array([0, 1]), array(1)], dtype=object)
 y: array([array([0, 1]), array(1)], dtype=object)

==
FAIL: test_vector_alignment_find_rotation_illegal_inputs 
(mvpa2.tests.test_surfing_surface.SurfingSurfaceTests)

--
Traceback (most recent call last):
  File 
"/home/test1/pymvpa2-2.6.5/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/tests/test_surfing_surface.py", 
line 97, in test_vector_alignment_find_rotation_illegal_inputs

vector_alignment_find_rotation, *illegal_arg)
AssertionError: (, 'exceptions.IndexError'>) not raised


--
Ran 577 tests in 234.985s

FAILED (SKIP=22, errors=1, failures=1)

Bug#526746: prosper: overlays stopped working properly after upgrade to Lenny

[Hilmar Preuße]

tags 526746 + wontfix
stop

On 03.05.09 10:47, Anton Rebhan wrote:

Hi,

> After upgrading from etch/tetex to lenny/texlive, some overlay commands
> don't work as they should. For example, putting
> an \onlySlide{p}{mat} command displays "mat" but kills
> all the subsequent material on the page, as the modified Example.tex
> below shows. Likewise, \fromSlide etc. is broken.
> 
According to [1] The current maintainer of this package is Fred­eric
Goualard. In his web page [2] I find the statement:

Since 1996, I have developed many LaTeX packages, mostly used only
locally at the labs I was employed at the time. For my PhD defense in
2000, I developed Prosper, a package to write more beautiful LaTeX
slides in a simpler way than what was available at the time. Somehow, it
filled a need and caught on. However, Prosper heavily relies on Adobe
Postscript, and cannot be used when producing Adobe PDF files directly
from the LaTeX source, as would be done by a tool such as pdflatex. With
more modern contenders around, I decided in 2009 to stop supporting it.
If you are now making the move to LaTeX slide design, please consider
packages like Powerdot (self-advertised as ``based on Prosper'') or
Beamer (my favorite, and the one I myself use now) instead.

So we won't get a bug fix for it. Tagging it wontfix for now.

H.

[1] https://ctan.org/pkg/prosper?lang=de
[2] http://frederic.goualard.net/
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#931890: debian-handbook: in section 8.10.4 (Compiling the Kernel / Compiling and Building the Package)

[Klaus-J. Wolf]

Package: debian-handbook
Severity: normal

The description on how to compile the kernel packages has stopped working
with Debian 9 and kernel 4.14 and persists with Debian 10 kernel 4.19.

Command line:

$ nice -15 make -j1 deb-pkg KDEB_PKGVERSION=4.19.57-1 V=0

At the moment I get:

  AR  kernel/built-in.a
make[4]: *** No rule to make target 'debian/certs/debian-uefi-certs.pem', 
needed by 'certs/x509_certificate_list'.  Stop.
make[3]: *** [Makefile:1044: certs] Error 2
make[2]: *** [debian/rules:4: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
make[1]: *** [scripts/package/Makefile:75: deb-pkg] Error 2
make: *** [Makefile:1357: deb-pkg] Error 2

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

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

Bug#931889: package-supports-alternative-init-but-no-init.d-script way too aggressive

[Michael Biebl]

Package: lintian
Version: 2.16.0
Severity: normal

Hi,

in several of my packages I get a lintian error since a few days ago:
package-supports-alternative-init-but-no-init.d-script
All of them false positives.
There are a lot of cases where a service ships a systemd service file
but not a sysv init script:
- D-Bus activated services
- one sysv init script, multiple systemd service files
- sysv init script named differently then systemd service file (but
  shipping a Alias symlink)
- crontab vs systemd.timer/systemd.service

Given the high probability of false positives, please consider
downgrading that lintian check to informal or even pedantic.

Thanks,
Michael


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

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

Versions of packages lintian depends on:
ii  binutils   2.32.51.20190707-1
ii  bzip2  1.0.6-9.2
ii  diffstat   1.62-1
ii  dpkg   1.19.7
ii  dpkg-dev   1.19.7
ii  file   1:5.35-4
ii  gettext0.19.8.1-9
ii  gpg2.2.13-2
ii  intltool-debian0.35.0+20060710.5
ii  libapt-pkg-perl0.1.36+b1
ii  libarchive-zip-perl1.64-1
ii  libcapture-tiny-perl   0.48-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
ii  libdigest-sha-perl 6.02-1+b1
ii  libdpkg-perl   1.19.7
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libio-async-perl   0.72-1
ii  libipc-run-perl20180523.0-1
ii  liblist-compare-perl   0.53-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libmoo-perl2.003004-2
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libpath-tiny-perl  0.108-1
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  libtry-tiny-perl   0.30-1
ii  libtype-tiny-perl  1.004004-1
ii  liburi-perl1.76-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.76+repack-1
ii  man-db 2.8.5-2
ii  patchutils 0.3.4-2
ii  perl   5.28.1-6
ii  t1utils1.41-3
ii  xz-utils   5.2.4-1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.55-1

-- no debconf information

Bug#931887: ITP: q2-feature-classifier -- QIIME 2 plugin supporting taxonomic classification

[Liubov Chuprikova]

Package: wnpp
Owner: Liubov Chuprikova 
Severity: wishlist

* Package name: q2-feature-classifier
  Version : 2019.4.0
  Upstream Author : QIIME 2 development team
* URL : https://qiime2.org/
* License : BSD-3-clause
  Programming Lang: Python
  Description : QIIME 2 plugin supporting taxonomic classification
 QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
 package with a focus on data and analysis transparency. QIIME 2 enables
 researchers to start an analysis with raw DNA sequence data and finish with
 publication-quality figures and statistical results.
 Key features:
  * Integrated and automatic tracking of data provenance
  * Semantic type system
  * Plugin system for extending microbiome analysis functionality
  * Support for multiple types of user interfaces (e.g. API, command line,
 graphical)
 .
 QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome
analysis
 pipeline. QIIME 2 will address many of the limitations of QIIME 1, while
 retaining the features that makes QIIME 1 a powerful and widely-used
analysis
 pipeline.
 .
 QIIME 2 currently supports an initial end-to-end microbiome analysis
pipeline.
 New functionality will regularly become available through QIIME 2 plugins.
You
 can view a list of plugins that are currently available on the QIIME 2
plugin
 availability page. The future plugins page lists plugins that are being
 developed.

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

Bug#931869: wine64-tools and wine32-tools:i386 are mutually asking for removal of each other

[Stephen Kitt]

On Thu, 11 Jul 2019 20:37:22 +0200, Arnaldo Pirrone  wrote:
> >FTBFS means that the package you file the bug on doesn’t build; it’s not  
> appropriate if another piece of software is harder to build.
> 
> I'm sorry, didn't know that, can you please reassign the severity level?

No worries, I’ve reduced the severity to “normal” and removed the ftbfs tag.

Thanks for taking the time to file the bug!

Regards,

Stephen


pgpHpJuci8sMq.pgp
Description: OpenPGP digital signature

Bug#931886: irssi-plugin-xmpp: fails to connect to server with irssi 1.2.0-2

[Guilhem Moulin]

Package: irssi-plugin-xmpp
Version: 0.54-3
Severity: important

Hi there,

I got bit by this bug after the upgrade to Buster:

irssi-xmpp 0.54 fails to connect to jabber server with irssi-1.2.0

I upgraded irssi to 1.2.0. After the upgrade irssi-xmpp fails to
connect to jabber server. The client appears to do the STARTTLS
phase and it prompts for password. After entering the password the
connection is terminated with message like "Unable to connect server
… timeout". The host OS is FreeBSD 12.

Reported by mjsaarin on Mar 7, 2019
https://github.com/cdidier/irssi-xmpp/issues/43

The issue is reproducible and results into Buster's irssi-public-xmpp
being unusable for me.  I checked with a single server though, and it
might work fine with others.  Otherwise I guess the bug should be RC.

Applying Ailin Nemui's 3 commits from PR#40 fixes the problem.

https://github.com/cdidier/irssi-xmpp/pull/40/commits
57c62278b97aeb999f3ca2e2b8a492f364405b61
617f0f1733f912d2dd94704f1331eaaf1184bbc8
9388f41ce84382fdffce22739051ab8661448a8f

(I guess only the first one is needed, but protecting against double
free seems worth having, too.)  Do you agree that it makes sense to
include these in the next point release?

Cheers,
-- 
Guilhem.

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

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

Versions of packages irssi-plugin-xmpp depends on:
ii  irssi [irssi-abi-20]  1.2.0-2
ii  libc6 2.28-10
ii  libglib2.0-0  2.58.3-2
ii  libloudmouth1-0   1.5.3-5

irssi-plugin-xmpp recommends no packages.

irssi-plugin-xmpp suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#931885: ITP: q2-quality-filter -- QIIME2 plugin for PHRED-based filtering and trimming

[Liubov Chuprikova]

Package: wnpp
Owner: Liubov Chuprikova 
Severity: wishlist

* Package name: q2-quality-filter
  Version : 2019.4.0
  Upstream Author : QIIME 2 development team
* URL : https://qiime2.org/
* License : BSD-3-clause
  Programming Lang: Python
  Description : QIIME2 plugin for PHRED-based filtering and trimming
 QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
 package with a focus on data and analysis transparency. QIIME 2 enables
 researchers to start an analysis with raw DNA sequence data and finish with
 publication-quality figures and statistical results.
 Key features:
  * Integrated and automatic tracking of data provenance
  * Semantic type system
  * Plugin system for extending microbiome analysis functionality
  * Support for multiple types of user interfaces (e.g. API, command line,
 graphical)
 .
 QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome
analysis
 pipeline. QIIME 2 will address many of the limitations of QIIME 1, while
 retaining the features that makes QIIME 1 a powerful and widely-used
analysis
 pipeline.
 .
 QIIME 2 currently supports an initial end-to-end microbiome analysis
pipeline.
 New functionality will regularly become available through QIIME 2 plugins.
You
 can view a list of plugins that are currently available on the QIIME 2
plugin
 availability page. The future plugins page lists plugins that are being
 developed.

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

Bug#931884: pkg-kde-tools: References soon to be removed dh_gconf tool in qt-kde-team/{2,3}/commands

[Niels Thykier]

Package: qt-kde-team
Version: 0.15.29
Severity: important
Control: block 908845 by -1


Hi,

Per Jeremy Bicha request, we are expecting to remove dh_gconf during
the Bullseye release cycle.  Unfortunately, pkg-kde-tools appears to
depend on this tool via its commands files:

"""
[...]
dh_installxfonts
dh_bugfiles
dh_lintian
dh_gconf
dh_icons
dh_perl
dh_usrlocal
[...]
"""

https://sources.debian.org/src/pkg-kde-tools/0.15.29/qt-kde-team/2/commands/?hl=61#L61
https://sources.debian.org/src/pkg-kde-tools/0.15.29/qt-kde-team/3/commands/?hl=61#L61


Please remove this unconditional reference for Bullseye.

Thanks,
~Niels

Bug#931883: gnome-pkg-tools: References soon to be removed dh_gconf in gnome.pm (dh sequence add-on)

[Niels Thykier]

Package: gnome-pkg-tools
Version: 0.21.1
Severity: important
Control: block 908845 by -1

Hi,

Per Jeremy Bicha request, we are expecting to remove dh_gconf during
the Bullseye release cycle.  Unfortunately, gnome-pkg-tools appears to
depend on this tool via its gnome.pm (dh sequencer add-on).

"""
#!/usr/bin/perl

use warnings;
use strict;
use Debian::Debhelper::Dh_Lib;

insert_before("dh_gconf", "dh_gnome");
insert_before("dh_clean", "dh_gnome_clean");

1;
"""

https://sources.debian.org/src/gnome-pkg-tools/0.21.1/dh/gnome.pm/?hl=7#L7

Please replace this reference with "dh_icons" to keep the same ordering.

Thanks,
~Niels

Bug#931882: ITP: kopano-webapp-plugin-desktopnotifications -- Kopano WebApp desktopnotifications plugin

[Roel van Meer]

Package: wnpp
Severity: wishlist
Owner: Roel van Meer 

* Package name: kopano-webapp-plugin-desktopnotifications
  Version : 2.0.2
  Upstream Author : Kopano 
* URL : https://kopano.com/

https://stash.kopano.io/projects/KWA/repos/desktopnotifications/browse
* License : AGPL-3
  Programming Lang: PHP, JS
  Description : Kopano WebApp desktopnotifications plugin

 This package is a plugin for kopano-webapp, a web interface for the Kopano
 Collaboration Platform.
 .
 This plugin shows notifications of new emails and reminders on the desktop.

This package is an additional plugin for kopano-webapp. It will be maintained
by Giraffe Maintainers .

Kind regards,

Roel

Bug#931881: diffoscope: undeclared versioned dependency on file

[Steve Langasek]

Package: diffoscope
Version: 117
Severity: serious
Justification: autopkgtest failures and runtime failures
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan

Dear maintainers,

diffoscope 117 is not migratable to testing because its autopkgtests are
failing, due to runtime errors complaining about a wrong version of the
'file' command:

[...]
=== FAILURES ===
_ test_text_proper_indentation _

args2 = (), kwargs2 = {}

def inner(*args2, **kwargs2):
if args[0]:  # i.e. the condition of the skipif() is True
>   return pytest.fail(msg)
E   Failed: requires file >= 5.37 (5.35 detected) 
(DIFFOSCOPE_TESTS_FAIL_ON_MISSING_TOOLS=1)

args   = (True,)
args2  = ()
kwargs2= {}
msg= ('requires file >= 5.37 (5.35 detected) '
 '(DIFFOSCOPE_TESTS_FAIL_ON_MISSING_TOOLS=1)')

tests/utils/tools.py:77: Failed
[...]

(https://ci.debian.net/packages/d/diffoscope/testing/amd64/)

file 5.37 is only present in Debian experimental, and the diffoscope package
declares no dependency on file >= 5.37.

At the very least, it seems this should be a versioned test dep on file (>=
5.37), but perhaps it should also be a versioned runtime dependency.  I
haven't looked to see what the impact is of the wrong version of 'file' when
DIFFOSCOPE_TESTS_FAIL_ON_MISSING_TOOLS is not set.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#931880: slurm-llnl: CVE-2019-12838

[Salvatore Bonaccorso]

Source: slurm-llnl
Version: 18.08.6.2-1
Severity: grave
Tags: security upstream
Control: found -1 18.08.5.2-1 
Control: found -1 16.05.9-1+deb9u4
Control: found -1 16.05.9-1

Hi,

The following vulnerability was published for slurm-llnl. I'm filling
it with an RC severity to be on safe side, but if you have more
information available and think the RC severity is not warranted
please feel free to then downgrade.

CVE-2019-12838[0]:
| SchedMD Slurm 17.11.x, 18.08.0 through 18.08.7, and 19.05.0 allows SQL
| Injection.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-12838
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12838
[1] https://lists.schedmd.com/pipermail/slurm-announce/2019/25.html

Please adjust the affected versions in the BTS as needed. [1] say that
whilest only 19.05 and 18.08 releases are patched previous releases
were affected as well.

Regards,
Salvatore

Bug#931879: RFS: simple-scan/3.32.2.1-1

[Matt Zagrabelny]

Greetings,

Thanks for packaging software for Debian!

On Thu, Jul 11, 2019 at 2:42 PM Jörg Frings-Fürst  wrote:

> Package: sponsorship-requests
> Severity: normal
>
>
>   Dear mentors,
>
>   I am looking for a sponsor for my package "simple-scan"
>
>Package name: simple-scan
>Version : 3.32.2.1-1
>Upstream Author : Robert Ancell 
>URL : https://gitlab.gnome.org/GNOME/simple-scan
>License : GPL-3+
>Section : gnome
>
>  It builds those binary packages:
>
> simple-scan - Simple Scanning Utility
>
>
Please consider using a slightly more informative description. Three words
might be sufficient for the description, but two of those three words are
in the package name and are, unfortunately, generic in nature.

Cheers!

-m

Bug#929185: default soundfonts

[Tim Colgate]

On Thu, 11 Jul 2019 14:50:30 + (UTC) Thorsten Glaser  wrote:
> > - Patch libraries using soundfonts to fallback to the new default
> >   soundfont path and add dependencies accordingly (fluidsynth,
> >   timidity, anything else?)
> 
> gstreamer (the one that started this discussion) perhaps, maybe
> also the various phonon? I’m not well-versed in the “desktop” world.

According to Wikipedia, Phonon can use GStreamer and VLC. QT multimedia used to 
use Phonon, but now uses Gstreamer - this may be configurable somewhere, but 
the problem with Gstreamer at the top of this thread, when fixed, allowed QT to 
work. VLC uses fluidsynth for midi files (configurable?). This doesn't work for 
me by default, because the default audio driver for fluidsynth is Jack, but I'm 
using pulseaudio, and I couldn't find a way in the VLC GUI to specify that the 
fluidsynth plugin should use the pulseaudio driver, although I can set the 
soundfount for fluidsynth to use, and I can set the audio driver for VLC to use 
generally. Come to think of it, this is another problem with fluidsynth, that 
would be solved by having a defaults file under /etc that is always used by 
fluidsynth, rather than only when it is in daemon mode. Neither xine nor 
mplayer seem to know about midi files.

So, in summary, I think addressing gstreamer and fluidsynth should cover most 
cases. I don't know much about timidity.

The code changes for gstreamer and fluidsynth look pretty straightforward; 
they're included at the top of this bug and #929182 respectively, but it's just 
changing one hard-coded name for another. I don't know if upstream have any 
plans to make this configurable at run time instead? Given that Gstreamer seems 
quite widespread, I'm surprised that there doesn't seen to be more in the way 
of system level configuration files.

Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")

[Christoph Berg]

Re: David Kalnischkies 2019-07-10 <20190710100502.yoe2umfxyiuglaw2@crossbow>
> http://deb.devuan.org/devuan/dists/stable/Release
> http://deb.devuan.org/merged/dists/stable/Release
> 
> The two release pockets differ by Suite only.

Hi,

this bug is not about fixing problems that devuan and the others might
have, this is about not breaking proper Debian Buster installations.
I appreciate the efforts put into sanely handling half-broken
repositories, but I'd still like to avoid the looming shitstorm on
the stable->oldstable switch in two years.

Christoph

Bug#931879: RFS: simple-scan/3.32.2.1-1

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal


  Dear mentors,

  I am looking for a sponsor for my package "simple-scan"

   Package name: simple-scan
   Version : 3.32.2.1-1
   Upstream Author : Robert Ancell 
   URL : https://gitlab.gnome.org/GNOME/simple-scan
   License : GPL-3+
   Section : gnome

 It builds those binary packages:

simple-scan - Simple Scanning Utility

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

  https://mentors.debian.net/package/simple-scan


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/simple-scan/simple-scan_3.32.2.1-1.dsc

or

  https://jff.email/cgit/simple-scan.git/?h=release%2Fdebian%2F3.32.2.1-1

  
  Changes since the last upload:

  * New upstream release.
  * Migrate to debhelper 12:
- Change debian/compat to 12.
- Change debhelper version in debian/control to >= 12.
  * Declare compliance with Debian Policy 4.4.0 (No changes needed).


The build with sbuild and pdebuild and the tests with Lintain are ok.
Puiparts fails about "package purging left files on system" mostly from
a mime package. 


+--+
| Summary  |
+--+

Build Architecture: amd64
Build Type: full
Build-Space: 26812
Build-Time: 35
Distribution: sid
Host Architecture: amd64
Install-Time: 299
Job: /data/entwicklung/linux/debian/simple-scan/simple-scan_3.32.2.1-1.dsc
Lintian: info
Machine Architecture: amd64
Package: simple-scan
Package-Time: 345
Piuparts: fail
Source-Version: 3.32.2.1-1
Space: 26812
Status: successful
Version: 3.32.2.1-1

Finished at 2019-07-11T19:09:59Z
Build needed 00:05:45, 26812k disk space



  Regards,
   Jörg Frings-Fürst


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#931877: [Pkg-javascript-devel] Bug#931877: please update marked

[Jérémy Lal]

Le jeu. 11 juil. 2019 à 21:00, Tomas Pospisek  a
écrit :

> Package: node-marked
> Version: 0.5.1+dfsg-1
> Severity: wishlist
>
> Hello,
>
> TLDR: please update marked from 0.5.1 to current 0.7.0
>
> the version of marked currently in Debian doesn't support tables in
> lists in Github Flavored Markdown. Something like the following will not
> get the expected output:
>
> * Foo
>   | a | table |
>   | - | - |
>   | x | y |
>
> Could you please update marked?
>
> Would me NMUing marked be OK? 0.7 seems to work well with
> nodejs from buster.
>

Yes, we can update node-marked.
If you were so kind to use gbp on
https://salsa.debian.org/js-team/node-marked, instead of NMU.

Also there's a good chance it's going to break node-marked-man (which i
maintain and author),
so please keep me informed.

Jérémy

Bug#931878: libonig: CVE-2019-13224 CVE-2019-13225

[Salvatore Bonaccorso]

Source: libonig
Version: 6.9.1-1
Severity: important
Tags: security upstream

Hi,

The following vulnerabilities were published for libonig.

CVE-2019-13224[0]:
| A use-after-free in onig_new_deluxe() in regext.c in Oniguruma 6.9.2
| allows attackers to potentially cause information disclosure, denial
| of service, or possibly code execution by providing a crafted regular
| expression. The attacker provides a pair of a regex pattern and a
| string, with a multi-byte encoding that gets handled by
| onig_new_deluxe(). Oniguruma issues often affect Ruby, as well as
| common optional libraries for PHP and Rust.


CVE-2019-13225[1]:
| A NULL Pointer Dereference in match_at() in regexec.c in Oniguruma
| 6.9.2 allows attackers to potentially cause denial of service by
| providing a crafted regular expression. Oniguruma issues often affect
| Ruby, as well as common optional libraries for PHP and Rust.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-13224
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13224
[1] https://security-tracker.debian.org/tracker/CVE-2019-13225
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13225

Please adjust the affected versions in the BTS as needed, for instance
stretch version not checked.

Regards,
Salvatore

Bug#931846: lintian: False positive debian-watch-file-should-mangle-version

[Mark Hindley]

On Thu, Jul 11, 2019 at 05:48:33AM -0700, Felix Lechner wrote:
> On Thu, Jul 11, 2019 at 3:09 AM Mark Hindley  wrote:
> >
> > I think lintian should differentiate between 'debian' in the upstream 
> > version
> > (before the hyphen) and the packaging version (after the hyphen).
> 
> Thank you for reporting the issue. This MR should fix it:
> 
> https://salsa.debian.org/lintian/lintian/merge_requests/211

Felix and Chris,

Many thanks for attending to this so promptly.

Best wishes

Mark

Bug#906057: linphone: Linphone "cannot start transport on port 5060, maybe this port is already used" although it is not.

[Matthias Maisenbacher]

On Fri, 23 Nov 2018 21:42:06 +0100 "W. Martin Borgert"
 wrote:
> I use linphone on stretch as my one and only telephone.
> So far, I did not encounter this problem.
> I suggest to downgrade this issue to "important",
> because it seems to affect only few users.
>
For me it is exactly the same problem as for the other two.
This is Debian 9.9 amd64.

Could possibly look somebody into it again?
I'd willing to test everything.

Here is another interesting hint for the problem:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743494

(look at message #20)
How could I test this?

Bug#931877: please update marked

[Tomas Pospisek]

Package: node-marked
Version: 0.5.1+dfsg-1
Severity: wishlist

Hello,

TLDR: please update marked from 0.5.1 to current 0.7.0

the version of marked currently in Debian doesn't support tables in
lists in Github Flavored Markdown. Something like the following will not
get the expected output:

* Foo
  | a | table |
  | - | - |
  | x | y |

Could you please update marked?

Would me NMUing marked be OK? 0.7 seems to work well with
nodejs from buster.

Thanks,
*t

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

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

Versions of packages node-marked depends on:
ii  nodejs  10.15.2~dfsg-2

node-marked recommends no packages.

node-marked suggests no packages.

-- no debconf information

Bug#931433: unzip: CVE-2019-13232

[Santiago Vila]

> > What would be next? Is this the kind of bug for which you will prepare
> > a DSA (security), or is stable-pu and oldstable-pu enough?
> 
> Once the fix is in unstable, this can safely go via the next buster.
> and stretch point release. Can you contact the stable release managers
> for it?

Ok, will do.

I asked because this CVE is in the headlines now (I've seen it in
slashdot and reddit, for example).

Thanks.

Bug#604033: Currículo - Rodrigo M. Bitencourt

[Gábor Szőgyényi]

Hello Rodrigo!

Please visit https://www.bosch.com.br/ and click to "Carreiras" . You can
upload you CV.

Regards,
Gabor

Rodrigo Bitencourt  ezt írta (időpont: 2019. júl.
11., Cs, 20:33):

> *Prezados Senhore (as)*
>
>
>
>
> *Gostaria de apresentar meu currículo profissional em anexo neste e-mail
> em busca de uma proposta de trabalho na área de Engenharia, Administrativa
> ou Industrial. Acredito reunir os requisitos e competências necessárias
> para colaborar de maneira significativa com a empresa.Possuo mais de 09
> anos de experiências na área de engenharia na gestão de projetos voltados
> seguimentos de segurança do trabalho, obras em geral, Qualidade, Meio
> Ambiente, planejamento, orçamentos entre outras atividades.*
>
>
> *Coloco-me a sua inteira disposição para uma entrevista pessoal quando
> poderei apresentar como maiores detalhes o meu histórico e qualificações, e
> reitero meu grande interesse em integrar no quadro de funcionários desta
> conceituada empresa.*
>
>
> *Atenciosamente*
>
> *Rodrigo Bitencourt*
>

Bug#931837: lightdm: Depends =~ s/libpam-systemd/default-logind/

[Yves-Alexis Perez]

On Thu, 2019-07-11 at 10:11 +0200, Adam Borowski wrote:
> Hi!
> You've just changed Depends from
> logind | consolekit
> to
> libpam-systemd | logind
> 
> I assume that you missed the new Policy -- discussed and approved before
> Buster, released as a package a few days ago. 

Yes. To be fair, the change was proposed and integrated before the release,
but we didn't upload during the freeze. Something might have changed between
the first proposal and the final policy.

>  It standardizes the above
> dependency as:
> default-logind | logind
> which it would be nice if you could change to.

Sure, I'll add that locally and it'll be part of the next upload (not sure
when it'll happen though).

Is default-logind [linux-any] as well?

Regards,
-- 
Yves-Alexis

Bug#931433: unzip: CVE-2019-13232

[Salvatore Bonaccorso]

Hi Santiago,

On Thu, Jul 11, 2019 at 06:03:15PM +0200, Santiago Vila wrote:
> Hi.
> 
> I'm going to upload a fix for unstable in short (patches by Mark Adler,
> already applied by Markus Koschany in jessie LTS btw).

Thanks for doing the unstable upload.

> What would be next? Is this the kind of bug for which you will prepare
> a DSA (security), or is stable-pu and oldstable-pu enough?

Once the fix is in unstable, this can safely go via the next buster.
and stretch point release. Can you contact the stable release managers
for it?

Thanks!

Regards,
Salvatore

Bug#931876: RFS: dmidecode/3.2-2

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name: dmidecode
   Version : 3.2-2
   Upstream Author : dmidecode-de...@nongnu.org
   URL : https://nongnu.org/dmidecode/
   License : GPL-2+
   Section : utils

  It builds those binary packages:

 dmidecode  - SMBIOS/DMI table decoder
 dmidecode-udeb - SMBIOS/DMI table decoder (udeb) (udeb)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dmidecode/dmidecode_3.2-2.dsc

or 

  https://jff.email/cgit/dmidecode.git/?h=release%2Fdebian%2F3.2-2
  
 
  Changes since the last upload:

  * Mark dmidecode Multi-Arch: foreign (Closes: #929455).
   - Thanks to: Helmut Grohne .
  * Declare compliance with Debian Policy 4.4.0 (No changes needed).
  * debian/copyright:
- Add year 2019 to debian/*.
  * Migrate to debhelper 12:
- Change debian/compat to 12.
- Bump minimum debhelper version in debian/control to >= 12.
- debian/rules: Remove obsolete dh_install --fail-missing.


The build with sbuild and pdebuild and the tests with Lintain and
Piuparts are ok:


+--+
| Summary  |
+--+

Build Architecture: amd64
Build Type: full
Build-Space: 3552
Build-Time: 7
Distribution: sid
Host Architecture: amd64
Install-Time: 43
Job: /data/entwicklung/linux/debian/dmidecode/dmidecode_3.2-2.dsc
Lintian: info
Machine Architecture: amd64
Package: dmidecode
Package-Time: 62
Piuparts: pass
Source-Version: 3.2-2
Space: 3552
Status: successful
Version: 3.2-2

Finished at 2019-07-11T18:31:45Z
Build needed 00:01:02, 3552k disk space



  Regards,
   Jörg Frings-Fürst
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.

Bug#931875: gnome-shell-extension-dashtodock has broken dependencies

[Alf Gaida]

Package: gnome-shell-extension-dashtodock
Severity: grave

 gnome-shell-extension-dashtodock : Depends: gnome-shell (>= 3.32) but 3.30.2-9 
is to be installed



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

Kernel: Linux 5.1.17-towo.1-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-shell-extension-dashtodock depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
pn  gir1.2-clutter-1.0   
pn  gnome-shell  

gnome-shell-extension-dashtodock recommends no packages.

gnome-shell-extension-dashtodock suggests no packages.

Bug#931869: wine64-tools and wine32-tools:i386 are mutually asking for removal of each other

[Arnaldo Pirrone]

>FTBFS means that the package you file the bug on doesn’t build; it’s not
appropriate if another piece of software is harder to build.

I'm sorry, didn't know that, can you please reassign the severity level?

Thank you

Il giorno gio 11 lug 2019 alle ore 19:56 Stephen Kitt  ha
scritto:

> Control: severity -1 normal
> Control: tag -1 - ftbfs
>
> FTBFS means that the package you file the bug on doesn’t build; it’s not
> appropriate if another piece of software is harder to build.
>
> On 11 July 2019 19:37:28 CEST, Arnaldo Pirrone  wrote:
>>
>> Package: wine64-tools
>> Version: 4.0-2
>> Severity: serious
>> Tags: ftbfs
>> Justification: fails to build from source (but built successfully in the 
>> past)
>>
>> wine64-tools and wine32-tools:i386 mutually ask for removal of each other.
>>
>> This is making difficult to build Carla from source. (You have to install
>> wine32-tools:i386, make wine32, then overwrite it with wine64-tools and make
>> wine64).
>>
>> make wine32
>> make -C source/jackbridge wine32
>> make[1]: ingresso nella directory
>> "/home/arny91/.sourcebuilds/Carla/source/jackbridge"
>> Linking jackbridge-wine32.dll.so
>> ld: relocatable linking with relocations from format elf64-x86-64
>> (/usr/lib/x86_64-linux-gnu/wine/libwinecrt0.a(dll_entry.o)) to format
>> elf32-i386 (jackbridge-wine32.6H9WHw.o) is not supported
>> winebuild: ld failed with status 1
>> winegcc: /usr/lib/wine/winebuild failed
>> make[1]: *** [Makefile:165: ../../build/modules/Release/jackbridge-
>> wine32.dll.so] Error 2
>> make[1]: uscita dalla directory
>> "/home/arny91/.sourcebuilds/Carla/source/jackbridge"
>> make: *** [Makefile:342: wine32] Error 2
>>
>>
>>
>>
>> -- Package-specific info:
>> /usr/bin/wine points to /usr/bin/wine-stable.
>>
>> -- System Information:
>> Debian Release: bullseye/sid
>>   APT prefers unstable
>>   APT policy: (500, 'unstable')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>>
>> Kernel: Linux 5.1.0-16.1-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
>> Kernel taint flags: TAINT_OOT_MODULE
>> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
>> LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /usr/bin/dash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages wine64-tools depends on:
>> ii  gcc4:8.3.0-1
>> ii  libc6  2.28-10
>> ii  libgettextpo0  0.19.8.1-9
>> ii  libwine-dev4.0-2
>> ii  perl   5.28.1-6
>>
>> Versions of packages wine64-tools recommends:
>> ii  g++  4:8.3.0-1
>> ii  wine 4.0-2
>> ii  wine-development [wine]  4.3-1
>>
>> wine64-tools suggests no packages.
>>
>> Versions of packages wine64-tools is related to:
>> ii  fonts-wine   4.0-2
>> ii  wine 4.0-2
>> ii  wine-development [wine]  4.3-1
>> ii  wine32   4.0-2
>> ii  wine64   4.0-2
>>
>> -- no debconf information
>>
>>

Bug#931874: not installable, broken dependencies

[Alf Gaida]

Package: gnome-shell-extension-appindicator
Severity: grave


gnome-shell-extension-appindicator : Depends: gnome-shell (>= 3.31) but 
3.30.2-9 is to be installed



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

Kernel: Linux 5.1.17-towo.1-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-shell-extension-appindicator depends on:
pn  gnome-shell  

gnome-shell-extension-appindicator recommends no packages.

gnome-shell-extension-appindicator suggests no packages.

Bug#931869: wine64-tools and wine32-tools:i386 are mutually asking for removal of each other

[Stephen Kitt]

Control: severity -1 normal
Control: tag -1 - ftbfs

FTBFS means that the package you file the bug on doesn’t build; it’s not 
appropriate if another piece of software is harder to build.

On 11 July 2019 19:37:28 CEST, Arnaldo Pirrone  wrote:
>Package: wine64-tools
>Version: 4.0-2
>Severity: serious
>Tags: ftbfs
>Justification: fails to build from source (but built successfully in
>the past)
>
>wine64-tools and wine32-tools:i386 mutually ask for removal of each
>other.
>
>This is making difficult to build Carla from source. (You have to
>install
>wine32-tools:i386, make wine32, then overwrite it with wine64-tools and
>make
>wine64).
>
>make wine32
>make -C source/jackbridge wine32
>make[1]: ingresso nella directory
>"/home/arny91/.sourcebuilds/Carla/source/jackbridge"
>Linking jackbridge-wine32.dll.so
>ld: relocatable linking with relocations from format elf64-x86-64
>(/usr/lib/x86_64-linux-gnu/wine/libwinecrt0.a(dll_entry.o)) to format
>elf32-i386 (jackbridge-wine32.6H9WHw.o) is not supported
>winebuild: ld failed with status 1
>winegcc: /usr/lib/wine/winebuild failed
>make[1]: *** [Makefile:165: ../../build/modules/Release/jackbridge-
>wine32.dll.so] Error 2
>make[1]: uscita dalla directory
>"/home/arny91/.sourcebuilds/Carla/source/jackbridge"
>make: *** [Makefile:342: wine32] Error 2
>
>
>
>
>-- Package-specific info:
>/usr/bin/wine points to /usr/bin/wine-stable.
>
>-- System Information:
>Debian Release: bullseye/sid
>  APT prefers unstable
>  APT policy: (500, 'unstable')
>Architecture: amd64 (x86_64)
>Foreign Architectures: i386
>
>Kernel: Linux 5.1.0-16.1-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
>Kernel taint flags: TAINT_OOT_MODULE
>Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
>LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
>Shell: /bin/sh linked to /usr/bin/dash
>Init: systemd (via /run/systemd/system)
>
>Versions of packages wine64-tools depends on:
>ii  gcc4:8.3.0-1
>ii  libc6  2.28-10
>ii  libgettextpo0  0.19.8.1-9
>ii  libwine-dev4.0-2
>ii  perl   5.28.1-6
>
>Versions of packages wine64-tools recommends:
>ii  g++  4:8.3.0-1
>ii  wine 4.0-2
>ii  wine-development [wine]  4.3-1
>
>wine64-tools suggests no packages.
>
>Versions of packages wine64-tools is related to:
>ii  fonts-wine   4.0-2
>ii  wine 4.0-2
>ii  wine-development [wine]  4.3-1
>ii  wine32   4.0-2
>ii  wine64   4.0-2
>
>-- no debconf information

Bug#799355: emacs-goodies-el: apache-mode has incorrect highlighting

[Nicholas D Steeves]

Control: tags -1 +upstream +fixed-upstream

I've cherry picked the patch into the git repo for this package, and
this bug will be closed in the next upload.


signature.asc
Description: PGP signature

Bug#931873: texlive-bin: FTBFS on sparc64

[Hilmar Preusse]

Source: texlive-bin
Version: 2019.20190605.51237-2
Severity: important
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

It fails to build for a few versions now.

https://buildd.debian.org/status/fetch.php?pkg=texlive-bin&arch=sparc64&ver=2019.20190605.51237-2&stamp=1562791518&raw=0

./luatex -fmt=luaimage luaimage || exit 1
+ ./luatex -fmt=luaimage luaimage
This is LuaTeX, Version 1.10.0 (TeX Live 2019/Debian)
 restricted system commands enabled.
(../../../texk/web2c/luatexdir/tests/luaimage.tex [1<../../../texk/web2c/tests/
1-4.jpg>]Bus error
+ exit 1
FAIL luatexdir/luaimage.test (exit status: 1)

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

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

Bug#931872: RM: thuban -- ROM; Dead upstream, no Python 3 support, FTBFS with PROJ 6.

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove thuban from the archive.

It's dead upstream, doesn't support Python 3, and FTBFS with PROJ 6
because it requires projects.h which is no longer supported.

Kind Regards,

Bas

Bug#931871: kidletime FTCBFS: missing Build-Depends: qttools5-dev

[Helmut Grohne]

Source: kidletime
Version: 5.54.0-1
Tags: pending

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

Helmut

Bug#883393: ITP: jool -- Open Source SIIT and NAT64 Translator for Linux

[Alberto Leiva]

> Any progress on this? Do you need help packaging?

Hello. upstream author (and perhaps future upstream maintainer as well) here.

I've been working on this since June 17 (2019). I have Jool packages
seemingly working properly, and recently finished scanning the Debian
Policy Manual, making sure that they comply with it.

I was just about to start reading the Debian Developer's Reference. I
haven't started looking for a sponsor or whatever it is that I'll
need, yet.

Not much of a due date, I know, but maybe it should give you an idea
of where I'm standing and the speed at which I'm working.

Some help would be nice, but I don't know what I'll need in the near future yet.

Cheers,
Alberto

Bug#931870: RFS: libunistring/0.9.10-2

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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


   Package name: libunistring
   Version : 0.9.10-2
   Upstream Author : Bruno Haible 
   URL : https://www.gnu.org/software/libunistring/
   License : LGPL-3+ or GPL-2+, FreeSoftware, 
 GPL-2+ with distribution exception,
 GPL-3+ or GFDL-1.2+, GPL-3+, GPL-2+,
 MIT
   Section : libs

It builds those binary packages:

libunistring-dev - Unicode string library for C - development files
libunistring2 - Unicode string library for C

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/libu/libunistring/libunistring_0.9.10-2.dsc

or

  https://jff.email/cgit/libunistring.git/?h=release%2Fdebian%2F0.9.10-2

  Changes since the last upload:

  * New patch debian/patches/0705-gcc-9.patch:
- Fix gcc-9 issue (Closes: #925762, #920824).
  * Migrate to debhelper 12:
- Change debian/compat to 12.
- Bump minimum debhelper version in debian/control to >= 12.
  * Declare compliance with Debian Policy 4.4.0 (No changes needed).
  * debian/copyright:
- Refresh copyright years for debian/* to 2019.

The build with sbuild and pdebuild and the tests with Lintain and
Piuparts are ok:


+--+
| Summary  |
+--+

Build Architecture: amd64
Build Type: full
Build-Space: 134080
Build-Time: 211
Distribution: sid
Host Architecture: amd64
Install-Time: 39
Job: /data/entwicklung/linux/debian/libunistring/libunistring_0.9.10-2.dsc
Lintian: info
Machine Architecture: amd64
Package: libunistring
Package-Time: 262
Piuparts: pass
Source-Version: 0.9.10-2
Space: 134080
Status: successful
Version: 0.9.10-2

Finished at 2019-07-11T17:23:37Z
Build needed 00:04:22, 134080k disk space




  Regards,
   Jörg Frings-Fürst

Bug#924014: starpu-contrib: build-depends on GCC 7

[Andreas Beckmann]

Followup-For: Bug #924014
Control: tag -1 patch pending

Hi Samuel,

I'll upload a NMU with the attached patch in the next days.

Andreas
diff -Nru starpu-contrib-1.2.6+dfsg/debian/changelog 
starpu-contrib-1.2.6+dfsg/debian/changelog
--- starpu-contrib-1.2.6+dfsg/debian/changelog  2019-02-05 18:57:23.0 
+0100
+++ starpu-contrib-1.2.6+dfsg/debian/changelog  2019-07-11 18:16:30.0 
+0200
@@ -1,3 +1,10 @@
+starpu-contrib (1.2.6+dfsg-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build with CUDA 10.1 and GCC 8.  (Closes: #924014).
+
+ -- Andreas Beckmann   Thu, 11 Jul 2019 18:16:30 +0200
+
 starpu-contrib (1.2.6+dfsg-6) unstable; urgency=medium
 
   * patches/doc-nopdf: Disable building pdf version of doxygen documentation
diff -Nru starpu-contrib-1.2.6+dfsg/debian/control 
starpu-contrib-1.2.6+dfsg/debian/control
--- starpu-contrib-1.2.6+dfsg/debian/control2019-02-05 18:57:23.0 
+0100
+++ starpu-contrib-1.2.6+dfsg/debian/control2019-07-11 18:16:30.0 
+0200
@@ -20,12 +20,10 @@
 #  guile-2.2,
opencl-c-headers, ocl-icd-opencl-dev | opencl-dev,
gfortran,
-#  gcc-7, g++-7, gfortran-7, gcc-7-plugin-dev, gcc,
-   gcc-7, g++-7, gfortran-7, gcc-7-plugin-dev,
-#  clang-5.0,
+   g++-8, gfortran-8, gcc-8-plugin-dev,
+#  clang-7,
help2man, doxygen, doxygen-latex,
-   nvidia-cuda-toolkit (>= 9.2),
-#Build-Conflicts: gcc-8, g++-8
+   nvidia-cuda-toolkit (>= 10.1),
 Standards-Version: 4.2.0
 Section: contrib/libs
 Homepage: http://starpu.gforge.inria.fr/
diff -Nru starpu-contrib-1.2.6+dfsg/debian/rules 
starpu-contrib-1.2.6+dfsg/debian/rules
--- starpu-contrib-1.2.6+dfsg/debian/rules  2019-02-05 18:57:23.0 
+0100
+++ starpu-contrib-1.2.6+dfsg/debian/rules  2019-07-11 18:16:30.0 
+0200
@@ -9,11 +9,11 @@
 
 # This is the version we want to build starpu against (may have to change
 # according to plugin support)
-GCC_VERSION  := 7
+GCC_VERSION  := 8
 
 # These are the best versions that nvcc supports.
-CONTRIB_GCC_VERSION  := 7
-CONTRIB_CLANG_VERSION  := 5.0
+CONTRIB_GCC_VERSION  := 8
+CONTRIB_CLANG_VERSION  := 7
 
 ifeq ($(source),starpu)
 #CC=gcc-$(GCC_VERSION)
@@ -35,8 +35,8 @@
 V=1
 export V
 
-#export NVCC_CC = gcc-7
-#export NVCC_CC = clang-5.0
+#export NVCC_CC = gcc-8
+#export NVCC_CC = clang-7
 export NVCCFLAGS = -Xcompiler -fPIC -Xcompiler -std=c++03
 
 export QT_SELECT=5

Bug#931869: wine64-tools and wine32-tools:i386 are mutually asking for removal of each other

[Arnaldo Pirrone]

Package: wine64-tools
Version: 4.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

wine64-tools and wine32-tools:i386 mutually ask for removal of each other.

This is making difficult to build Carla from source. (You have to install
wine32-tools:i386, make wine32, then overwrite it with wine64-tools and make
wine64).

make wine32
make -C source/jackbridge wine32
make[1]: ingresso nella directory
"/home/arny91/.sourcebuilds/Carla/source/jackbridge"
Linking jackbridge-wine32.dll.so
ld: relocatable linking with relocations from format elf64-x86-64
(/usr/lib/x86_64-linux-gnu/wine/libwinecrt0.a(dll_entry.o)) to format
elf32-i386 (jackbridge-wine32.6H9WHw.o) is not supported
winebuild: ld failed with status 1
winegcc: /usr/lib/wine/winebuild failed
make[1]: *** [Makefile:165: ../../build/modules/Release/jackbridge-
wine32.dll.so] Error 2
make[1]: uscita dalla directory
"/home/arny91/.sourcebuilds/Carla/source/jackbridge"
make: *** [Makefile:342: wine32] Error 2




-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-stable.

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

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

Versions of packages wine64-tools depends on:
ii  gcc4:8.3.0-1
ii  libc6  2.28-10
ii  libgettextpo0  0.19.8.1-9
ii  libwine-dev4.0-2
ii  perl   5.28.1-6

Versions of packages wine64-tools recommends:
ii  g++  4:8.3.0-1
ii  wine 4.0-2
ii  wine-development [wine]  4.3-1

wine64-tools suggests no packages.

Versions of packages wine64-tools is related to:
ii  fonts-wine   4.0-2
ii  wine 4.0-2
ii  wine-development [wine]  4.3-1
ii  wine32   4.0-2
ii  wine64   4.0-2

-- no debconf information

Bug#931868: O: libcitadel -- Development files for libcitadel4

[Michael Meskes]

Package: wnpp
Severity: normal

I intend to orphan the libcitadel package.

The package description is:
 This library contains the commonly used routines for the citadel suite.
 .
 This package provides development files and static libraries.

I have not used the package for ages and lack the resources to keep maintaining 
i
t.

Michael

Bug#931576: RFS: blackbox-themes/0.6

[Juhani Numminen]

Dmitry Bogatov kirjoitti 10.7.2019 klo 9.40:
> 
> [2019-07-07 22:38] Juhani Numminen 
>> Alternatively, one can download the package with dget using this command:
>>   dget -x 
>> https://mentors.debian.net/debian/pool/main/b/blackbox-themes/blackbox-themes_0.6.dsc
> 
> 404.

The upload was sponsored, and as a result the package was automatically removed 
from mentors.d.n.

tracker.debian.org tells me this is the new location on official archive 
mirrors:
http://deb.debian.org/debian/pool/main/b/blackbox-themes/blackbox-themes_0.6.dsc

Regards,
Juhani

Bug#837895: Similar bug on strtetch

[Roger James]

I am seeing a similar bug on stretch. This bug also reports a problem in 
running upstart. However upstart is not installed on stretch by default as 
it is running systemd. The default for the autoconf variable 
enable_indicator_services_command is "upstart --user --startup-event 
indicator-services-start". This will always fail. The package needs to be 
built without this bring enabled to stop this happening.

Bug#931730: libfile-stripnondeterminism-perl: build dependency cycle with libsub-identify-perl

[Niko Tyni]

On Tue, Jul 09, 2019 at 04:08:18PM -0300, Chris Lamb wrote:
 
> > the recently added libmonkey-patch-perl dependency in
> > libfile-stripnondeterminism-perl has unfortunately resulted in a build
> > dependency cycle
> […]
> > I see this new dependency was introduced for normalizing zip archives
> > (#858431) by changing the Archive::Zip behaviour on the fly. Is this
> > fixable on the Archive::Zip side?
> 
> I guess in theory but if I recall the details correctly, I don't
> /think/ this was going to be a trivial patch to Archive::Zip and my
> Perl-fu is/was a bit weak. Would pkg-perl apply and upload a patch
> anyway?

I'm sorry I haven't had time to look at this properly (and still don't).

Obviously features would be best developed upstream. Archive-Zip seems
to be alive if quiet. But a bug against libarchive-zip-perl would be a
good start (with or without a patch). We can then take it upstream
if you'd prefer that.

> > Alternatively, would it be possible to weaken the cycle somehow, for
> > instance by making this dependency optional and having the packages that
> > actually need it declare an explicit build dependency ?
> 
> Would adding a  restriction be of use to you?

No, I'm afraid not. I was thinking of having
libfile-stripnondeterminism-perl recommend libmonkey-patch-perl rather
than depend on it, or something like that.

The only Build-Depends that is relevant here is libsub-identify-perl ->
debhelper. The problem is with runtime dependencies: debhelper needs to
stay installable even when libsub-identify-perl has become uninstallable
and needs a rebuild.

One more alternative might be to make a derived class like
Archive::Zip::Normalizing or Archive::Zip::DebianReproducible or whatever
and package that separately, avoiding the "monkey patching" part.
Not sure how feasible that is to implement though.

Hope this clarifies,
-- 
Niko

Bug#931867: /lib/init/init-d-script is sourcing /etc/default/* too late

[Justin Pasher]

Package: sysvinit-utils
Version: 2.93-8

I started testing the upgrade from Debian Stretch to Buster, and I've 
encountered a problem that affects the snmpd package's init.d script. It 
looks like it has been changed to utilize /lib/init/init-d-script for 
its core functionality. However, by doing so, the SNMPDOPTS value is 
ignored from the init config file at /etc/default/snmpd. This is because 
of the following lines in /etc/init.d/snmpd:


==
DEFAULT_SNMPDOPTS="-Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I 
-smux,mteTrigger,mteTriggerConf"

[ -z "$SNMPDOPTS" ] && SNMPDOPTS=$DEFAULT_SNMPDOPTS
==

Because the /lib/init/init-d-script script sources /etc/init.d/snmpd 
BEFORE it sources /etc/default/snmpd, none of the values in 
/etc/default/snmpd are visible to /etc/init.d/snmpd. This results in 
SNMPDOPTS always being set to the default arguments.


One could view this as a bug in either snmpd or sysvinit-utils, 
depending on your viewpoint. However, it seems more appropriate for a 
fix to be applied to /lib/init/init-d-script within sysvinit-utils, as 
other scripts may try (or even be trying already) to use this method 
within the init.d script to set defaults. The /etc/init.d/snmpd script 
could manually force an inclusion of /etc/defaults/snmpd, but it seems a 
little redundant when /lib/init/init-d-script is supposed to do that work.


The line in question in /lib/init/init-d-script is below:

==
# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
==

Moving it above the following block would ensure it's sourced first:

==
SCRIPTNAME="$__init_d_script_name"
scriptbasename="$(basename "$__init_d_script_name")"
if [ "$scriptbasename" != "init-d-script" ] ; then
    . "$__init_d_script_name"
else
    exit 0
fi
==

I checked the latest experimental version (2.95) and it doesn't have any 
changes like this (although it does fix the snmpd package install bug as 
referenced in #926390). Without knowing all the ins and outs of how 
/lib/init/init-d-script is used throughout Debian, I can't say if this 
change would be considered safe or not. Perhaps there are instances 
where the /etc/default/* config file tries to do more than just set some 
shell variables and it would cause some bizarre side effects.


Thanks.

--
Justin Pasher

Bug#901321: Bug#876197: Removed package(s) from unstable

[Helio Loureiro]

Hi,

Just to confirm that after Buster release, this bug stills open and the
error persists.

Best Regards,
Helio Loureiro
http://helio.loureiro.eng.br
http://br.linkedin.com/in/helioloureiro
http://twitter.com/helioloureiro



On Tue, 3 Jul 2018 at 13:20, Helio Loureiro  wrote:

> Hi,
>
> I started on Debian at Ham release.  At that time mpage was part of
> Debian.  So I've a profound relationship with mpage as great tool along all
> these years.
>
> But if my statement is correct, that package after 20 years at Debian was
> wrongly removed due a license which doesn't apply to delivered binaries, do
> you really believe the best approach is to ask a volunteer out of Debian
> developers/maintainers to join on Debian mentors to fix it?   Wouldn't be
> easier for you and Eriberto to just revert the removal?  I guess that any
> DSC from theses 20 years of Debian would work just fine.
>
> Vänliga hälsningar/Best Regards,
> Helio Loureiro
> http://helio.loureiro.eng.br
> https://se.linkedin.com/in/helioloureiro
> http://twitter.com/helioloureiro
>
> Note: if you failed to reach me, try my alternative mail "
> helio.loure...@gmail.com".
> I'm implementing DKIM on my mail server, so some disturbance is expected.
>
> On Mon, 2 Jul 2018 11:46:36 +0200 Paul Gevers  wrote:
> > Sending again to the new bug.
> >
> >  Forwarded Message 
> > Subject: Re: Bug#876197: Removed package(s) from unstable
> > Date: Mon, 11 Jun 2018 15:01:35 +0200
> > From: Paul Gevers 
> > To: Helio Loureiro 
> > CC: Eriberto Mota 
> >
> > Dear Helio,
> >
> > On 11-06-18 14:45, Helio Loureiro wrote:
> > > Is possible to keep this bug as open and revert the decision?
> >
> > As the package isn't in Debian anymore, the bug is closed. However, any
> > Debian maintainer (and via sponsoring anybody) can reintroduce the
> > package if it is considered useful. So the answers are: no and yes.
> >
> > > So is it possible to revert the package removal or at the least move it
> > > to contrib instead?
> >
> > If you want to reintroduce the package to Debian, I suggest you contact
> > Debian mentors¹². I don't have any personal interest in mpage.
> >
> > Paul
> >
> > ¹ http://mentors.debian.net/
> > ² IRC #debian-mentors on oftc
> >
> >
> >
>
>

Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

[userm57]

On 7/4/19 1:07 PM, user...@yahoo.com wrote:
> Correction: The CPU of the Wallstreet is 266 MHz, not 292 MHz.

Update:

Please see attached "all.tar.xz", which contains the following files:

"x11perf -all" tests:

1) x11perf_8_fbdev.txt: Debian 8.11, mach64 removed
2) x11perf_8_mach64.txt   : Debian 8.11, mach64 installed
3) x11perf_sid_fbdev.txt  : Debian sid, mach64 removed
4) x11perf_sid_mach64.txt : Debian sid, mach64 installed
5) x11perfcomp.txt: comparison of the above four tests

"/var/log/Xorg.0.log" files:

6) Xorg_8_fbdev.log  : Xorg log file for test (1)
7) Xorg_8_mach64.log : Xorg log file for test (2)
8) Xorg_sid_fbdev.log: Xorg log file for test (3)
9) Xorg_sid_mach64.log   : Xorg log file for test (4)

"glxgears" (from mesa-utils) tests:

10) glxgears.txt

Notes:

a) "mach64" is short for "xserver-xorg-video-mach64".

b) I was not able to install Michel's patch -- I wasn't sure what
compile or other options to use.  It looks like I could build a new
kernel with that (patched) module; would that be the best way to include
the patch?  I see that a commit was made yesterday (Jul 10) related to
the patch, so I can just wait and test it when it's available in Debian
sid, or I can build a new kernel with the patch included.  Please advise.

c) The glxgears tests are included for reference.  Those results give a
better picture of the overall slowdown in X11 graphics from Debian 8.11
to Debian sid.  The slowdown is most easily seen when running in
multiuser mode with Xfce (see particularly the last two tests in the
file), where the glxgears FPS is about 14.1 FPS in Debian 8.11 but only
4.7 FPS in Debian sid.  So perhaps there are some interrelated issues
with Xorg and Xfce and/or mesa-utils, especially since glxgears has
intermittent segmentation and illegal instruction errors (only in sid).

d) It takes approximately three seconds to open an xfce4-terminal in
Debian 8.11, six seconds in Debian sid.

e) Moving and resizing windows might be faster in all versions of Debian
if the default setting would be to highlight only the window borders
while moving or resizing, instead of including the window contents.
This is probably an Xfce setting.

-Stan Johnson
 user...@yahoo.com


all.tar.xz
Description: Binary data

Bug#931866: debirf: dpkg-divert warnings

[Matt Taggart]

Package: debirf
Version: 0.38
Severity: minor

I noticed some warnings when running debirf on buster

dpkg-divert: warning: please specify --no-rename explicitly, the default
will change to --rename in 1.20.x
Removing 'diversion of /sbin/ldconfig to /sbin/ldconfig.REAL by fakechroot'
dpkg-divert: warning: please specify --no-rename explicitly, the default
will change to --rename in 1.20.x
Removing 'diversion of /usr/bin/ldd to /usr/bin/ldd.REAL by fakechroot'

Buster released with dpkg 1.19.7, so probably this will break once dpkg
development resumes in testing.

Thanks,

-- 
Matt Taggart
tagg...@debian.org

Bug#931865: O: citadel-client -- complete and feature-rich groupware server (command line client)

[Michael Meskes]

Package: wnpp
Severity: normal

I intend to orphan the citadel-client package.

The package description is:
 This is package contains the command line client for Citadel, a complete and
 feature-rich open source groupware platform.
 .
 See the 'citadel-server' package for more information.

I have not used the package for ages and lack the resources to keep maintaining 
i
t.

Michael

Bug#931864: O: webcit

[Michael Meskes]

Package: wnpp
Severity: normal

I have not used the package for ages and lack the resources to keep maintaining 
i
t.

Michael

Bug#931540: transition: statsmodels 0.8 -> 0.9 or 0.10

[Graham Inggs]

Hi Rebecca

> Upstream have released statsmodels 0.10.0.  I am not yet sure whether
> to go straight for that or do 0.9.x first.

My feeling is 0.9 first, but whomever does the work gets to decide.

> Packages using statsmodels (to be tested):
> bcbio pandas pymvpa2 pysal python-mne seaborn tnseq-transit

That's a nice short list!  I see (using reverse-depends) most of those 
are Reverse-Recommends as opposed to Reverse-Depends.  Do you think it 
would be possible to drop the python 2 packages at the same time?


Regards
Graham

Bug#931862: O: citadel

[Michael Meskes]

Package: wnpp
Severity: normal

I have not used the package for ages and lack the resources to keep maintaining 
it.

Michael

Bug#931863: debirf: buster build fails to create initrd

[Matt Taggart]

Package: debirf
Version: 0.38

When running a debirf build on a buster machine, building a stable
(buster) rescue image, everything works up until creating the initrd

...
debirf> modules complete
debirf> creating debirf initrd ('nested')...
cp: cannot stat '/home/taggart/debirf/rescue/root/lib/klibc-*': No such
file or directory

-- 
Matt Taggart
tagg...@debian.org

Bug#866472: copyright extract script

[Xavi Drudis Ferran]

El Thu, Jul 11, 2019 at 05:28:30PM +0200, Agustin Martin deia:
> On Thu, Jul 11, 2019 at 04:17:30PM +0200, Agustin Martin wrote:
> > On Thu, Jul 11, 2019 at 04:02:13PM +0200, Xavi Drudis Ferran wrote:
> > > 
> > > I attach the script. It prints some (c) info on the *_rc.py files. 
> > > You might need to change the uniconvertor directory in the script. 
> > > And you may not really find it too enlightening...
> > 
> > Thanks a lot,
> > 
> > I was already looking at the files generated under
> > ~/.config/uc2/profiles/ where those strings can also be guessed. I will look
> > more carefully, but at least one of the color profiles seems non free (the
> > HP one).
> 
> Hi again, Xavi
> 
> I was looking at the color profiles. Here goes a summary of what I found:
>

that was the intention of this code in my debian/rules (probably misplaced) 

python src/uc2/utils/rcc2py/rcc2py.py 
/usr/share/color/icc/ghostscript/default_cmyk.icc src/uc2/cms/cmyk_profile_rc.py
python src/uc2/utils/rcc2py/rcc2py.py /usr/share/color/icc/Gray.icc 
src/uc2/cms/gray_profile_rc.py
python src/uc2/utils/rcc2py/rcc2py.py /usr/share/color/icc/sRGB.icc 
src/uc2/cms/srgb_profile_rc.py
#   python src/uc2/utils/rcc2py/rcc2py.py ? 
src/uc2/cms/display_profile_rc.py
python src/uc2/utils/rcc2py/rcc2py.py 
/usr/share/color/icc/ghostscript/lab.icc src/uc2/cms/lab_profile_rc.py
 
>   * cmyk_profile_rc.py -> built-in_CMYK.icm
> 
> (Fogra27L.icc) Fogra27L CMYK Coated Press
> (C) Richard Hughes 
> Public Domain
>

I replaced it from /usr/share/color/icc/ghostscript/default_cmyk.icc

But I think I found it had a different checksum to the original. 

The problem is despite beliving the attribution and license of the
original, can I be saying to distribute the source code if I only have
src/uc2/cms/cmyk_profile_rc.py ?  or should I add the file that file
was generated from, which I'm not sure which was?  So to avoid the
doubt, I just removed it, and regenerated from _another_ icc profile,
that I hope is good enough but I can't tell.

Maybe it would be enough to just ship the py or the rcc2py and the
.icc binary decoded from the *_rc.py so people can regenerate the
*_rc.py (but this seems backwards? is it really the binary obtained
from *_rc.py a source for *_rc.py?)
 
To know what counts as source, I should know what is the prefered
format for people modifying icc profiles ?  .icc ? *_rc.py ? something
else ? I've never used an .icc file (conciously).

>   * display_profile_rc.py -> built-in_Display.icm
> 
> Contains this string:
> No copyright. Created with dispcalGUI 1.1.2.9 and Argyll CMS 1.4.0 -M 
> P244W -A Acer Technologies
> 
> Could get no more info about this profile
> 

Yes, I'm in the dark too. 

>   * gray_profile_rc.py -> built-in_Grayscale.icm
> 
> This is the same as /usr/share/color/icc/Gray.icc, shipped in
> icc-profiles-free package
>  
> Copyright (C) 2005-2008 Kai-Uwe Behrmann 
> License: zlib/libpng License
> 

Yes, but I seem to recall the checksum did not match the base64
decoded file from the _rc.py .  I don't remember well, I should
recheck, maybe some of the files matched, my impression was that most
or all didn't.

Like the first case, I generated it from a debian file
/usr/share/color/icc/Gray.icc
and I don't know if this is a good enough substitute. 

>   * lab_profile_rc.py -> built-in_LAB.icm
> 
> Seems similar (but not exact) to /usr/share/color/icc/LCMSXYZI.ICM,
> shipped in icc-profiles-free package
> 
> Copyright (C) Marti Maria Saguer 1999
> License: zlib/libpng License
>

 Could be, I tried 
/usr/share/color/icc/ghostscript/lab.icc

>   * srgb_profile_rc.py -> built-in_RGB.icm
> 
> Copyright (c) 1998 Hewlett-Packard Company
> 
> $ md5sum built-in_RGB.icm 
> 1d3fda2edb4a89ab60a23c5f7c7d81dd  built-in_RGB.icm
>
> If you look at https://bugs.debian.org/699301 this is exactly the same
> file that was reported as non-free. It is shipped as 
> /usr/share/color/icc/sRGB.icm in non-free icc-profiles package.
>

I tried /usr/share/color/icc/sRGB.icc hoping it is free. But is it a
good enough substitute ?  I mean does it work like the original ? How
do I know ?
 
> Some Debian packages are currently shipping free color profiles, at least
> 
> icc-profiles-free
> colord-data
> libgs9-common
> 

I added to build-depends : 
 libgs9-common,
 icc-profiles-free
But I didn't use colord-data

> I wonder if some profile in those packages could help. I have no idea about
> color profiles and such.
> 

Yes. What does one do here ? Ask the maintainers from libgs9-common,
icc-profiles-free for any ideas on source ? the legal team ? ask
nobody until one has something tested that looks useful ?

Bug#931861: RM: newsbeuter -- RoM; abandoned upstream; actively maintained fork available

[Nikos Tsipinakis]

Package: ftp.debian.org
Severity: normal

Hello,

Please remove newsbeuter from the archive. It has been abandoned upstream and
there is an actively maintained fork (newsboat) already available in Debian.
It also currently fails to build with the new json-c version that'll be added in
the upcoming transition.

Best Regards,
  Nikos Tsipinakis

Bug#931433: unzip: CVE-2019-13232

[Santiago Vila]

Hi.

I'm going to upload a fix for unstable in short (patches by Mark Adler,
already applied by Markus Koschany in jessie LTS btw).

What would be next? Is this the kind of bug for which you will prepare
a DSA (security), or is stable-pu and oldstable-pu enough?

Thanks.

Bug#931860: kmail print empty page

[Denis Gottardello]

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

Dear Maintainer,
Please try to export an email to pdf or just make a print preview to obtain the 
problem.

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

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

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

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

Versions of packages kmail suggests:
pn  clamav 
ii  kaddressbook   4:18.08.3-3
ii  kleopatra  4:18.08.3-1
pn

Bug#931372: RFS: dunst/1.4.1-1 [ITA] -- dmenu-ish notification-daemon

[Nikos Tsipinakis]

On 10/07, David Kalnischkies wrote:
> As far as I looked I have only some minor nitpick comments because
> I like looking at changelogs and get the feeling of understanding what
> happened without investigating too deeply.

Nitpicks, but very valid points nonetheless.

> I think I would prefer "Adopting package" or "Set myself as maintainer"
> or something like that as "Update" can basically mean everything like
> changing your email address, joining a team or whatever.

Fixed.

> >   * Update Build-Depends
> 
> If there is a good way to summarize what was exactly updated, please say
> so. Version bump? Now build-depending on KDE, GNOME and Qt3? 😉

I have to admit I wanted to explain a bit more here but given that there were a
bunch of small changes in the same file at the same time I got a bit lazy with
splitting commits and left it as-is. I've now broken the changes for this and
the copyright file down to individual commits, should be much better.

> >   * Bump standards version
> 
> Which standard? – also there is a new one out by now.

Added the version, and updated it to 4.4.0.

> >   * Bump debhelper compat to 12
> 
> You could switch to "debhelper-compat (= 12)" in Build-Depends and
> remove the debian/compat file.

Interesting I didn't know about that, it looks handy. I've updated it to use
this format now.

> >   * Install release notes in docs
> 
> Your are installing them as NEWS: Do you have a deeper reason for doing
> that?

The policy mentions that release notes should be installed as NEWS[1]

"If an upstream release notes file is available, containing a summary of changes
between upstream releases intended for end users of the package and often called
NEWS, it should be accessible as /usr/share/doc/package/NEWS.gz."

> The file contents look like a bit similar to a NEWS.Debian file
> in content, but then upstream name and content also suggest it should
> contain notes for each (major) release – even if 1.4 is missing – which
> would usually be a bit much for NEWS… but yeah, that is really just
> personal taste and style I guess. Long story short: mention NEWS.

It would be much if it was displayed during installation indeed but from my
understanding apt-listchanges only shows NEWS.Debian by default. So in my mind
it's fine to have it there for anyone who's interested to read it.

> 
> Thanks again for adopting a package and good luck finding a sponsor now
> that unstable is open again!
> 

Thank _you_ for taking a look and reviewing.

The new (more descriptive) changelog after this is the following:

  [ Francois Marier ]
  * Use sensible-browser instead of Firefox in /etc/xdg/dunst/dunstrc
  (Closes: #929456)

  [ Nikos Tsipinakis ]
  * Adopt package (Closes: #930310)
  * New upstream version 1.4.1
  * Remove cross.patch (applied upstream)
  * Refresh patches
  * d/control:
- Drop build-dep on libxdg-basedir
- Remove glib version constraint (minimum version no longer in archive)
- Drop build-dep on gtk in favour of gdk-pixbuf
- Add build-dep on dbus daemon and librsvg (required for the test suite)
  * Bump standards to 4.4.0
  * Install release notes as NEWS in docs
  * Bump debhelper compat to 12
Also switch to using debhelper-compat rather than d/compat
  * d/copyright:
- Update Source URL
- Add myself to debian/ attributions
- Add missing license for greatest.h

[1] 
https://www.debian.org/doc/debian-policy/ch-docs.html#changelog-files-and-release-notes

Best Regards,
 Nikos Tsipinakis

Bug#931719: 40-systemd: line 11: 1: unbound variable when sourcing /lib/lsb/init-functions with $1 unset

[Mert Dirik]

On 7/11/19, Thomas Bätzler  wrote:
>
> To wit:
>
>   root@kvm1:~# /etc/init.d/rsync
>   Usage: /etc/init.d/rsync {start|stop|reload|force-reload|restart|status}
>
> vs.
>
>   root@kvm1:~# /etc/init.d/mysql
>   /lib/lsb/init-functions.d/40-systemd: line 11: 1: unbound variable
>
>

Thanks, I've been able to confirm that.

> In this case, line 16 has to be changed to 'argument="${1:-}', too (last
> line of your patch), since the call without argument falls through to
> the else branch, i.e.

Indeed. "argument=$1" line had need to be changed, not the
"argument=$2" one. Can you try this patch:

 executable="$__init_d_script_name"
 argument="$1"
 elif [ "${0##*/}" = "init-d-script" ] ||
- [ "${0##*/}" = "${1##*/}" ]; then # scripts run with old
init-d-script
+ [ "${0}" = "${1:-}" ]; then # scripts run with old  init-d-script
 executable="$1"
 argument="$2"
 else # plain old scripts
 executable="$0"
-argument="$1"
+argument="${1:-}"
 fi

Bug#866472: copyright extract script

[Agustin Martin]

On Thu, Jul 11, 2019 at 04:17:30PM +0200, Agustin Martin wrote:
> On Thu, Jul 11, 2019 at 04:02:13PM +0200, Xavi Drudis Ferran wrote:
> > 
> > I attach the script. It prints some (c) info on the *_rc.py files. 
> > You might need to change the uniconvertor directory in the script. 
> > And you may not really find it too enlightening...
> 
> Thanks a lot,
> 
> I was already looking at the files generated under
> ~/.config/uc2/profiles/ where those strings can also be guessed. I will look
> more carefully, but at least one of the color profiles seems non free (the
> HP one).

Hi again, Xavi

I was looking at the color profiles. Here goes a summary of what I found:

  * cmyk_profile_rc.py -> built-in_CMYK.icm

(Fogra27L.icc) Fogra27L CMYK Coated Press
(C) Richard Hughes 
Public Domain

  * display_profile_rc.py -> built-in_Display.icm

Contains this string:
No copyright. Created with dispcalGUI 1.1.2.9 and Argyll CMS 1.4.0 -M P244W 
-A Acer Technologies

Could get no more info about this profile

  * gray_profile_rc.py -> built-in_Grayscale.icm

This is the same as /usr/share/color/icc/Gray.icc, shipped in
icc-profiles-free package
 
Copyright (C) 2005-2008 Kai-Uwe Behrmann 
License: zlib/libpng License

  * lab_profile_rc.py -> built-in_LAB.icm

Seems similar (but not exact) to /usr/share/color/icc/LCMSXYZI.ICM,
shipped in icc-profiles-free package

Copyright (C) Marti Maria Saguer 1999
License: zlib/libpng License

  * srgb_profile_rc.py -> built-in_RGB.icm

Copyright (c) 1998 Hewlett-Packard Company

$ md5sum built-in_RGB.icm 
1d3fda2edb4a89ab60a23c5f7c7d81dd  built-in_RGB.icm

If you look at https://bugs.debian.org/699301 this is exactly the same
file that was reported as non-free. It is shipped as 
/usr/share/color/icc/sRGB.icm in non-free icc-profiles package.

Some Debian packages are currently shipping free color profiles, at least

icc-profiles-free
colord-data
libgs9-common

I wonder if some profile in those packages could help. I have no idea about
color profiles and such.

Regards,

-- 
Agustin

Bug#931805: dead keys not working

[Hubert Chathi]

forwarded 931805 https://github.com/aperezdc/revolt/issues/94
thanks

On Wed, 10 Jul 2019 17:39:30 +0200, Sébastien Villemot  
said:

> In a revolt window, I can’t input characters that involve dead keys
> (exemple: “ê” on a French keyboard, which is entered via the
> combination of the “^” dead key followed by “e”).

That sounds like the same as the issue reported upstream at
https://github.com/aperezdc/revolt/issues/94

Bug#926509: keepassxc: Please update to Version 2.4.0

[Jonathan Rubenstein]

On Sat, 6 Apr 2019 12:28:06 +0200 Julian Andres Klode wrote:
> On Sat, Apr 06, 2019 at 11:23:29AM +0200, Philipp Kolmann wrote:
> > Package: keepassxc
> > Version: 2.3.4+dfsg.1-1
> > Severity: wishlist
> >
> > Hi,
> >
> > could you please update keepassxc to the latest release 2.4.0.
> >
> > https://keepassxc.org/blog/2019-03-19-2.4.0-released/
>
> No, we're in freeze.
>
> --
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer i speak de, en
>
>


Hello, Debian Buster was released earlier this month, so the freeze is 
over. In that time the released version is now 2.4.3.



Thanks, Jonathan

Bug#931719: 40-systemd: line 11: 1: unbound variable when sourcing /lib/lsb/init-functions with $1 unset

[Thomas Bätzler]

Hi Mert,

On 10.07.2019 at 17:47, Mert Dirik wrote:

After upgrading to Debian 10 we noticed a slightly different behaviour
in  /lib/lsb/init-functions.d/40-systemd which caused one of our scripts
to break and which also causes some /etc/init.d files like
/etc/init.d/mysql
to no longer to display their help text when calling them without a
parameter.

The root cause are accesses to the $1 and $2 variables without checking
if they are defined beforehand. When running code using "set -u", this
causes the above mentioned error.


Which command did you use to make that happen? I'm asking because I
can't test it right now.


To wit:

 root@kvm1:~# /etc/init.d/rsync
 Usage: /etc/init.d/rsync {start|stop|reload|force-reload|restart|status}

vs.

 root@kvm1:~# /etc/init.d/mysql
 /lib/lsb/init-functions.d/40-systemd: line 11: 1: unbound variable


[Suggested patch]


It seems OK.

What I'd rather do is drop the "##*/" substitution, and set a default
value if $1 is unset, and let the statement continue:

  executable="$__init_d_script_name"
  argument="$1"
  elif [ "${0##*/}" = "init-d-script" ] ||
- [ "${0##*/}" = "${1##*/}" ]; then # scripts run with old
init-d-script
+ [ "${0}" = "${1:-}" ]; then # scripts run with old  init-d-script
  executable="$1"
-argument="$2"
+argument="${2:-}"
  else # plain old scripts
  executable="$0"
  argument="$1"

Dropping the "##*/" substitution isn't actually related to this change
but dropping it allows the use of ":-" syntax in the same line. I was
in fact thinking about dropping it irrelevant to this issue.


Another important issue here is the use of "set -e" and "set -u" on
the /etc/init.d/mysql script. It is ineffective right now because
later in 40-systemd file they are set back to their defaults (set +e
and set +u). I don't know the policy or best practices about this
topic but either one of the scripts should be accommodated to be in
compliance with the other.

I'm sorry I can't test any of this right now as I don't have a
suitable and up-to-date test system ready and I'm not sure when I'll
be.



In this case, line 16 has to be changed to 'argument="${1:-}', too (last 
line of your patch), since the call without argument falls through to 
the else branch, i.e.


    # diff -C1 40-systemd.orig 40-systemd
    *** 40-systemd.orig 2019-07-09 16:27:19.380695186 +0200
    --- 40-systemd  2019-07-11 16:58:33.113302048 +0200
    ***
    *** 10,17 
      elif [ "${0##*/}" = "init-d-script" ] ||
    !  [ "${0##*/}" = "${1##*/}" ]; then # scripts run with 
old  init-d-script

          executable="$1"
    ! argument="$2"
      else # plain old scripts
          executable="$0"
    ! argument="$1"
      fi
    --- 10,17 
      elif [ "${0##*/}" = "init-d-script" ] ||
    !  [ "${0}" = "${1:-}" ]; then # scripts run with old 
init-d-script

          executable="$1"
    ! argument="${2:-}"
      else # plain old scripts
          executable="$0"
    ! argument="${1:-}"
      fi


Behaviour after the change:

 # /etc/init.d/mysql
 Usage: /etc/init.d/mysql 
start|stop|restart|reload|force-reload|status|bootstrap



HTH,
Thomas

Bug#931859: sssd-common failed to install due to outdated p11_child location

[Karol Augustin]

Package: sssd-common
Version: 2.2.0-2
Severity: grave

During installation of sssd-common the following error occurs:

Setting up sssd-common (2.2.0-2) ...
chown: cannot access '/usr/lib/x86_64-linux-gnu/sssd/p11_child': No such
file or directory
dpkg: error processing package sssd-common (--configure):
 installed sssd-common package post-installation script subprocess
returned error exit status 1


This is related to the following change in the 2.2.0-1 version:

  * *.install: Updated, some files moved to /usr/libexec.

As the postinst script contains:

LIBDIR=/usr/lib/x86_64-linux-gnu/sssd
...
chown root:sssd $LIBDIR/p11_child
chmod 4754 $LIBDIR/p11_child

snippet of dpkg -L sssd-common:
/usr/libexec/sssd/p11_child


This bug also exists in other sssd- packages, I have stopped
investigating after encountering it in aaas-krb5-common.
Setting up sssd-krb5-common (2.2.0-2) ...
chown: cannot access '/usr/lib/x86_64-linux-gnu/sssd/krb5_child': No
such file or directory
chown: cannot access '/usr/lib/x86_64-linux-gnu/sssd/ldap_child': No
such file or directory


Thanks,
Karol

Bug#931858: libreswan: please remove the dependency on systemd

[Stephen Kitt]

Package: libreswan
Version: 3.27-6
Severity: normal

Dear Maintainer,

The libreswan binary package has a strict dependency on systemd; is it
necessary? It makes libreswan painful to install in containers...

Would it be possible to drop the dependency?

Thanks,

Stephen


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

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

Versions of packages libreswan depends on:
ii  bind9-host [host]1:9.11.5.P4+dfsg-5.1
ii  bsdmainutils 11.1.2+b1
ii  debconf [debconf-2.0]1.5.71
ii  dns-root-data2019031302
ii  iproute2 4.20.0-2
ii  iptables 1.8.2-4
ii  libaudit11:2.8.4-3
ii  libc62.28-10
ii  libcap-ng0   0.7.9-2
pn  libcurl3-nss 
ii  libevent-2.1-6   2.1.8-stable-4
ii  libevent-pthreads-2.1-6  2.1.8-stable-4
ii  libldap-2.4-22.4.47+dfsg-3
ii  libldns2 1.7.0-4
ii  libnspr4 2:4.20-1
ii  libnss3  2:3.42.1-1
ii  libnss3-tools2:3.42.1-1
ii  libpam0g 1.3.1-5
ii  libselinux1  2.8-1+b1
ii  libsystemd0  241-5
ii  libunbound8  1.9.0-2
ii  systemd  241-5

Versions of packages libreswan recommends:
ii  python3  3.7.3-1

libreswan suggests no packages.

Bug#931845: Cannot install solr-tomcat when building docker image

[Markus Koschany]

Hello,

this issue is caused by the command systemctl daemon-reload in
solr-tomcat's postinst file. You can try to remove it and see if it
works. However solr-tomcat is supposed to work in a systemd environment,
I doubt that anyone has tested it with another init system or without one.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#931857: ioquake3: framerate/performance under wayland is poor (FPS misleading)

[Jonathan Dowland]

Package: ioquake3
Version: 1.36+u20181222.e5da13f~dfsg-2
Severity: normal

Hi,

Game performance under Wayland is much lower than under Xorg. I have FPS
displayed within the game and in both cases it reports something around
90fps at all times. But I suspect this is misleading in the Wayland case
(possibly due to off-screen rendering or buffers or something?); it
*feels* much lower. I cannot reliably hit things with the Rail gun,
whereas playing the same level/skill/#bots under Xorg is much smoother.



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.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 ioquake3 depends on:
ii  ioquake3-server  1.36+u20181222.e5da13f~dfsg-2
ii  libc62.28-10
ii  libcurl3-gnutls  7.64.0-3
ii  libgl1   1.1.0-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libogg0  1.3.2-1+b1
ii  libopenal1   1:1.19.1-1
ii  libopus0 1.3-1
ii  libopusfile0 0.9+20170913-1
ii  libsdl2-2.0-02.0.9+dfsg1-1
ii  libvorbis0a  1.3.6-2
ii  libvorbisfile3   1.3.6-2
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages ioquake3 recommends:
ii  x11-utils  7.7+4
ii  zenity 3.30.0-2

ioquake3 suggests no packages.

Versions of packages ioquake3 is related to:
ii  libgl1-mesa-dri  18.3.4-2

-- no debconf information