Bug#893030: closed by Bastien Roucariès <ro...@debian.org> (Bug#893030: fixed in imagemagick 8:6.9.9.39+dfsg-1)

[Helmut Grohne]

Control: reopen -1

On Tue, Mar 20, 2018 at 11:09:12AM +, Debian Bug Tracking System wrote:
>* Provide transitional packages from arch:any packages.
>  (Closes: #893030)

As discussed, I think this solution is a good one. Unfortunately, it
wasn't implemented properly. Now, libmagickwand-6.q16-dev Provides
libmagickcore-dev, but I think it should provide libmagickwand-dev.
Nothing presently provides libmagickwand-dev.

Having it provide libmagickcore-6.defaultquantum-dev also looks fishy to
me.

Helmut

Bug#893759: variety: launching variety gives quite a few python 2.7 warnings

[shirish शिरीष]

Reply in-line :-

On 27/03/2018, James Lu  wrote:
> Hello,
>
> This actually looks like three different bugs.
>
> The first traceback (relating to
> /usr/share/images/desktop-base/desktop-background) seems to involve
> misdetecting image file formats somewhere. To help debug this further,
> could you reply with the output of:
>
> ls /etc/alternatives/desktop-background -lah
>

Dear James,

Sorry didn't see your reply earlier.

That shows  -

$  ls /etc/alternatives/desktop-background -lah
lrwxrwxrwx 1 root root 76 Mar 10 17:11
/etc/alternatives/desktop-background ->
/usr/share/desktop-base/active-theme/wallpaper/contents/images/1920x1080.svg

 I am running mate 1.20.0 if that makes any difference although eog
and eom are able to load that file fine, there is no corruption in
/usr/share/desktop-base/active-theme/wallpaper/contents/images/1920x1080.svg

> For the second error (cannot identify image file), I suspect a corrupt
> image file. Does the file it mentions
> (/home/shirish/.config/variety/Downloaded/flickr_user_www_flickr_com_photos_peter_levi__user_id_93647178_N00_/7527884976_7d72041417_o.jpg)
> seem like a working JPEG? If not, try deleting it and see if the issue
> disappears.
>

I don't see that image anymore.

> The "unary operator expected" issue is a mistake on my part and will be
> fixed in the next upstream release (0.6.7)
>
> Hope this helps,
> James
>

Cool. Look forward to see the changes. I would try out the changes
whenever you put the fixed packages . I would need to remove variety
from System >  Preferences >
Startup applications > Variety Wallpaper changer  although would have
liked an easier way to do that.



-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#894323: deepin terminal lacks wayland support

[Lumin]

Package: deepin-terminal
Version: 2.9.2-1
Severity: normal

~ ❯❯❯ deepin-terminal

(deepin-terminal:21073): Wnck-WARNING **: 05:01:48.691: libwnck is
designed to work in X11 only, no valid display found

(deepin-terminal:21073): Wnck-CRITICAL **: 05:01:48.691:
wnck_screen_force_update: assertion 'WNCK_IS_SCREEN (screen)' failed

(deepin-terminal:21073): Wnck-CRITICAL **: 05:01:48.691:
wnck_screen_get_active_workspace: assertion 'WNCK_IS_SCREEN (screen)'
failed

(deepin-terminal:21073): Wnck-CRITICAL **: 05:01:48.691:
wnck_screen_get_windows: assertion 'WNCK_IS_SCREEN (screen)' failed

(deepin-terminal:21073): Gdk-CRITICAL **: 05:01:48.720:
gdk_x11_display_get_xdisplay: assertion 'GDK_IS_DISPLAY (display)'
failed

(deepin-terminal:21073): GLib-GObject-WARNING **: 05:01:48.720:
invalid cast from 'GdkWaylandWindow' to 'GdkX11Window'

(deepin-terminal:21073): Gdk-WARNING **: 05:01:48.720:
../../../../../gdk/x11/gdkwindow-x11.c:5579 drawable is not a native
X11 window
fish: “deepin-terminal” terminated by signal SIGSEGV (Address boundary error)
~ ❯❯❯ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
XWAYLAND0 connected 1920x1080+0+0 (normal left inverted right x axis y
axis) 310mm x 170mm
   1920x1080 59.96*+


-- 
Best,

Bug#894322: cifs-utils: Please remove myself from Uploaders

[Christian Perrier]

Package: cifs-utils
Version: 2:6.7-1
Severity: minor

I am no longer active in the Samba Packaging team for quite a while
now. Please remove me from the Uploaders field from the cifs-utils
package.

Thanks in advance.


-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages cifs-utils depends on:
ii  libc6 2.27-2
ii  libcap-ng00.7.7-3.1+b1
ii  libkeyutils1  1.5.9-9.2
ii  libkrb5-3 1.16-2
ii  libpam0g  1.1.8-3.7
ii  libtalloc22.1.10-2
ii  libwbclient0  2:4.7.4+dfsg-2
ii  samba-common  2:4.7.4+dfsg-2

cifs-utils recommends no packages.

Versions of packages cifs-utils suggests:
ii  keyutils   1.5.9-9.2
ii  smbclient  2:4.7.4+dfsg-2
ii  winbind2:4.7.4+dfsg-2

-- no debconf information

Bug#888712: netgen: Please update to newest package version 6.2.x

[Kurt Kremitzki]

Upstream has tagged 6.2.1802. I have a package for this ready, but it 
depends on my OCCT 7.2 package. Also, the Python bindings for 6.2.1802 
depend on pybind11 >= 2.2 which is only in experimental currently.

Bug#894278: src:libdatrie: Please add trie_state_get_terminal_data() which is needed in python-datrie

[Theppitak Karoonboonyanan]

Hi Andreas,

On Wed, Mar 28, 2018 at 3:56 PM, Andreas Tille  wrote:

> there is an ITP for pyton-datrie (#828741) which needs an additional
> function in libdatrie.  Upstream has created a patch[1] which provides
> this missing function.  I took the freedom to create a new branch in
> libdatrie Git[2] which incorporates the said patch + fixes.  I also
> adapted the symbols file even if I'm aware that its bad style to inject
> a new symbol in a random Debian revision.

Thanks for the effort to make it available in Debian!

I have communicated with Filip Pytloun, the patch author,
in a personal mail for some time. And here's my comment
excerpt:

---8<---
  I wonder what's wrong with trie_state_get_data()?
  Why don't you just use it?

  And, from your patch, it looks like what the new function
  tries to do is to get the TAIL-associated data  *without*
  verifying the entire key. Only prefix mathing up to the single-path
  separation point is enough, and 's' does not have to be
  a real terminal state, which contradicts the function
  name and the documentation.

  I think trie_state_get_data() could be used instead.
---8<---

And I haven't got further explanation yet.

What I can guess from the patch is that it looks like an attempt
to speed up trie enumeration by bypassing the check of
the rest of the key. But unfortunately, in general users' viewpoint,
it could be confusing when a non-terminal state (which appears
to be in a separate path, but has not reached the end yet) gets
the data from a *_get_terminal_data() function, whose
documentation states that its argument is a *terminal* state.

Meanwhile, the existing trie_state_get_data() does exactly
the same to a *terminal* state, but not to a non-terminal one.
If something is still missing, we had better fix it there,
rather than introducing a new similar API.

That's why I haven't accepted the patch upstream so far.

Kind regards,
-- 
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/

Bug#894321: new upstream (1.9.0)

[Daniel Baumann]

Package: pgcli
Severity: wishlist

Hi,

thank you for maintaining pgcli in debian. However, it would be nice if
you could upgrade pgcli to the current usptream version (1.9.0).

Regards,
Daniel

Bug#864719: [Pkg-openldap-devel] Bug#864719: slapd: also when upgrading from wheezy to jessie, fails to configure when olcSuffix contains a backslash-escaped umlaut

[Ryan Tandy]

On Wed, Feb 21, 2018 at 08:33:02PM +0100, Thorsten Glaser wrote:

I’ve just got hit *again* by this… this time on a
long due wheezy to jessie upgrade.


Multiple issues, I'm afraid.

* I haven't gotten to a jessie update yet - only sid and stretch so far.

* My patch missed several occurrences of "| while read suffix". I think 
 the one you attached has all of them. I don't know what I was thinking 
 but I must have failed to test a case involving a dump/reload (as with 
 wheezy->jessie).


* The grep change I applied doesn't work anyway for jessie and later, 
 because the patterns gained an anchor in #723957. The command:


 grep -Fl "^olcSuffix: $1"

 obviously doesn't work. What I actually wanted is probably more like:

 grep -Flx "olcSuffix: $1"

 Not only does this imply I failed to test a dump/reload upgrade, but 
 it looks like I _also_ broke update_permissions() for affected 
 suffixes. Shame on me!


Now wheezy->jessie was the last upgrade where dump/reload was mandatory, 
so most users of newer systems wouldn't hit this, but it can be 
reproduced by setting slapd/dump_databases: always.


Reopened for fixing properly...

Bug#894238: RM: mozjs -- RoQA; unmaintained, superseded by mozjs52

[Jeremy Bicha]

Control: tags -1 -moreinfo

Ok, this should be good to go now.

Thanks,
Jeremy Bicha

Bug#893547: ant: please do not emit --ignore-source-errors on Java 9

[tony mancill]

On Wed, Mar 28, 2018 at 09:21:45AM +0200, Emmanuel Bourg wrote:
> Le 20/03/2018 à 05:20, tony mancill a écrit :
> 
> > I'm in the midst of preparing an update for ant.  Is there any context
> > in which we want to add "--ignore-source-errors" to the ant javadoc
> > task, or should this patch [1] be removed entirely?
> 
> It looks like the --ignore-source-errors only works with the default
> doclet. The patch should be refined such that --ignore-source-errors is
> only added if the doclet attribute is null.
> 
> Tony I prepared an upgrade of Ant to the version 1.10.3 before noticing
> you were also working on the package. May I proceed with the upload or
> do you want to upload your changes first?
> 
> Here is my changelog so far:
> 
>   * New upstream release
> - Refreshed the patches
> - Changed the source/target level to 1.8 when building Ant
> - Build the new optional ant-xz module
> - Require Java 8 or higher to run Ant
>   * Adjust the source/target level to 1.7 in anticipation
> of the 1.6 removal in Java 11
>   * Added activation.jar to the build classpath to fix
> the empty ant-javamail jar with Java 9
> 
> Emmanuel Bourg

Hi Emmanuel,

That's great!  Please go ahead with your upload.

Thank you,
tony


signature.asc
Description: PGP signature

Bug#894319: ibus-chewing: Please drop Build-Depends on libgconf2-dev

[Jeremy Bicha]

Source: ibus-chewing
Version: 1.5.1-1
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: patch buster sid

Your package build-depends on libgconf2-dev, but gconf will be removed from 
Debian soon.

The dependency appears to be unused so please remove it.
(No patch attached but this issue should be easy to fix.)

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html
https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#894318: tomcat8 fail to find oracle jvm built with make-jpkg

[Daniele Palumbo]

Package: tomcat8
Version: 8.5.14-1+deb9u2
Severity: normal

Dear Maintainer,

tomcat8 has, in its init script, a lookup over the available jvm.
"""
 for jvmdir in /usr/lib/jvm/java-${java_version}-openjdk-* \
  /usr/lib/jvm/jdk-${java_version}-oracle-* \
  /usr/lib/jvm/jre-${java_version}-oracle-*
"""

the new make-jpkg has a different syntax, likely from version 0.61
>From 
>http://metadata.ftp-master.debian.org/changelogs/contrib/j/java-package/java-package_0.62_changelog
"""
 * Use package name plus architecture as directory in /usr/lib/jvm
"""

to better understand the difference, see the following path of installation

old package path (jessie)
/usr/lib/jvm/jdk-8-oracle-x64/

new package path (stretch)
/usr/lib/jvm/oracle-java8-jdk-amd64/

The workaround as suggested also by the init script is to set JAVA_HOME 
variable indefault file.

A patch should be considered to properly lookup the new java package built.

Nevertheless, i would suggest to lookup the alternative jdk selected, in place 
of JAVA_HOME.

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

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

Versions of packages tomcat8 depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  lsb-base   9.20161125
ii  tomcat8-common 8.5.14-1+deb9u2
ii  ucf3.0036

Versions of packages tomcat8 recommends:
ii  authbind   2.1.2
ii  libtcnative-1  1.2.12-2+deb9u1

Versions of packages tomcat8 suggests:
ii  tomcat8-admin 8.5.14-1+deb9u2
pn  tomcat8-docs  
pn  tomcat8-examples  
pn  tomcat8-user  

-- debconf information:
  tomcat8/username: tomcat8
  tomcat8/groupname: tomcat8
  tomcat8/javaopts: -Djava.awt.headless=true -XX:+UseConcMarkSweepGC

Bug#893427: tunnelx FTBFS with openjdk-9

[Wookey]

On 2018-03-28 22:33 +0200, Emmanuel Bourg wrote:
> Control: tags -1 + patch
> 
> Here is a patch fixing this issue.

> --- a/src/SelectedSubsetsStructure.java
> +++ b/src/SelectedSubsetsStructure.java
> @@ -257,7 +257,7 @@
>   OneLeg ol = (OneLeg)tn.getUserObject(); 
>  if (btransitivesubset)
>   {
> - Enumeration 
> tnenum = tn.depthFirstEnumeration(); 
> + Enumeration 
> tnenum = (Enumeration) tn.depthFirstEnumeration(); 
>   while (tnenum.hasMoreElements())
>   
> vsselectedsubsets.add(((OneLeg)tnenum.nextElement().getUserObject()).stto);  
> // the actual subset name, not the thing that appears in the treeview
>   }

Aha. Cheers very much for that. Upstream hadn't provided one yet, so I was
thinking I was going to have to try and work it out myself.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#894317: goobox: Drop Build-Depends on gconf

[Jeremy Bicha]

Source: goobox
Version: 3.4.2-7
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: patch

Your package build-depends on libgconf2-dev, but gconf will be removed from 
Debian soon.

The good news is that it looks like the dependency is unnecessary. Please 
remove it. You can also remove the dh_gconf call from your debian/rules. (No 
patch attached but this should be fairly easy.)

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html
https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#892057: Fwd: Re: TS-x09 fails to boot when obtaining MAC

[Martin Michlmayr]

The fix is in Linus' tree since v.16-rc5:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=13a55372b64e00e564a08d785ca87bd9d454ba30

I don't see it in 4.9 stable or the stable queue.  Will Greg pick it
up automatically because of the Fixes: info or do we have to let him
know?

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#894316: iw dev interface scan ssid returns all SSIDs

[Chiraag Nataraj]

Package: iw
Version: 4.14-0.1
Severity: normal

Dear Maintainer,

I have started using systemd-networkd/resolved and wpa_supplicant to configure 
my wireless card automatically, and it works pretty well. However, given that 
they don't present much of an interactive interface (wpa_cli doesn't really 
count ;)), I thought I could use iw to figure out the details of a particular 
SSID (so I would know how to configure it in wpa_supplicant). Assuming I know 
the SSID, I expected that `iw dev wlp60s0 scan ssid Chiraag-VPN` would result 
in just the details for Chiraag-VPN. However, it turns out that iw returns the 
results for _all_ discovered networks, completely ignoring the `ssid` option. 
This seems to conflict with the behavior documented in `iw dev wlp60s0 scan 
help` and thus seems to be a bug. It also seems that this has been reported in 
Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1300205) with no 
resolution. I'd be happy to help get to the bottom of this once and for all. 
With the introduction of systemd-networkd, it seems that 
systemd-networkd/resolved + wpa_supplicant + iw could make a great lightweight 
network management solution, and solving this bug could really help make iw 
actually useful for many of us.

Sincerely,

Chiraag

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

Kernel: Linux 4.15.11-chiraag (SMP w/8 CPU cores; PREEMPT)
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)

Versions of packages iw depends on:
ii  libc6 2.27-2
ii  libnl-3-200   3.2.27-2
ii  libnl-genl-3-200  3.2.27-2

Versions of packages iw recommends:
ii  crda  3.18-1

iw suggests no packages.

-- no debconf information

Bug#856179: ITP: polybar -- fast and easy-to-use status bar

[Jason Pleau]

Hi (again..!)

Didn't expect to get something to work so soon regarding the splitting
of the packages.

On salsa:

https://salsa.debian.org/jpleau-guest/polybar (BRANCH: split_pkg)
https://salsa.debian.org/jpleau-guest/libxpp
https://salsa.debian.org/jpleau-guest/i3ipcpp

In my sid chroot, all 3 now build fine, and the installed package works
on my machine (you'll probably find the same issues you did before with
the config and fonts though, haven't worked those yet)

I have a patch that I will have to carry for polybar, which includes
bits of xpp's CMake file to include the necessary XCB include /
libraries (for linking). I think that's a bit less ugly than carrying
the whole thing together :)

Cheers

-- 
Jason Pleau

Bug#893332: ghostscript: Ghostscript cannot find Resource directory

[James Cloos]

It makes little sense that a symlink fails.

Except that deb's /usr/share/ghostscript/9.22/ has a relative symlink:

iccprofiles -> ../../color/icc/ghostscript/

so you'd need also to fix that symlink to be absolute:

iccprofiles -> /usr/share/color/icc/ghostscript/

The other symlink in the /usr/share/ghostscript tree is absolute.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Bug#894125: amanda-server: error=write error to: Broken pipe

[Jose M Calhariz]

Hi,

This error was one shot or happen every day?

Have you look into the amanda logs files on server?

Have you look into the amanda logs files of the failing clients?

Kind regards
Jose M Calhariz

Bug#893145: Pending fixes for bugs in the excalibur-logkit package

[pkg-java-maintainers]

tag 893145 + pending
thanks

Some bugs in the excalibur-logkit package are closed in revision
6a805a6ce2cd4155e6f9a3d5748376f6679890f9 in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/excalibur-logkit.git/commit/?id=6a805a6

Commit message:

Fixed the build failure with Java 9 (Closes: #893145)

Bug#881431: proposed wording

[Adam Borowski]

On Wed, Mar 28, 2018 at 03:32:02PM -0700, Sean Whitton wrote:
> Suggested replacement:
> 
> The part of the version number after the epoch must not be reused for a
> version of the package with different contents, even if the version
> of the package previously using that part of the version number is
> no longer present in any archive suites.
> 
> Epochs are not included in the names of the files that compose
> source packages, or in the filenames of binary packages, so reusing
> a version number, even if the epoch differs, results in identically
> named files with different contents.  This causes various problems.

Sounds better than mine.  I'd re-add "once that package has been accepted
into the archive", to make it obvious that resubmissions to NEW and/or
mentors are expected to reuse version numbers of what they amend.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ When I visited the US a couple decades ago, Hillary molested and
⣾⠁⢰⠒⠀⣿⡁ groped me.  You don't believe?  Well, the burden of proof is on you!
⢿⡄⠘⠷⠚⠋⠀ Flooding a douche with obviously false accusations makes your other
⠈⠳⣄ words dubious even when they happen to be true.

Bug#894315: konsole: boxes in programs such as dialog or aptitude using ncurses>6.0 are garbled

[Jiri Palecek]

Package: konsole
Version: 4:17.08.3-1
Severity: normal

Dear Maintainer,

after upgrading libncurses, some text mode programs started to display
boxes wrong. See bug 892923 for a screenshot. This was reproted upstream
as https://bugs.kde.org/show_bug.cgi?id=384620 and fixed
recently. There's also a patch that could be backported.

Regards
Jiri Palecek

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

Kernel: Linux 4.14.0-rc3-bughunt+ (SMP w/2 CPU cores)
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ 
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages konsole depends on:
ii  kio   5.42.0-3
ii  konsole-kpart 4:17.08.3-1
ii  libc6 2.27-2
ii  libkf5completion5 5.42.0-4
ii  libkf5configcore5 5.42.0-2
ii  libkf5configgui5  5.42.0-2
ii  libkf5configwidgets5  5.42.0-2
ii  libkf5coreaddons5 5.42.0-2
ii  libkf5crash5  5.42.0-2
ii  libkf5dbusaddons5 5.42.0-2
ii  libkf5i18n5   5.42.0-3
ii  libkf5iconthemes5 5.42.0-2
ii  libkf5kiowidgets5 5.42.0-3
ii  libkf5notifyconfig5   5.42.0-2
ii  libkf5widgetsaddons5  5.42.1-2
ii  libkf5windowsystem5   5.42.0-2
ii  libkf5xmlgui5 5.42.0-2
ii  libqt5core5a  5.9.2+dfsg-12
ii  libqt5gui55.9.2+dfsg-12
ii  libqt5widgets55.9.2+dfsg-12
ii  libstdc++68-20180321-1

konsole recommends no packages.

konsole suggests no packages.

-- no debconf information

Bug#892861: Fwd: Bug#892861: libglm-dev: removal of default type initialization breaking packages

[Andrew Caudwell]

-- Forwarded message --
From: Andrew Caudwell 
Date: Thu, Mar 29, 2018 at 11:55 AM
Subject: Re: Bug#892861: libglm-dev: removal of default type initialization
breaking packages
To: Guus Sliepen 



On Thu, Mar 29, 2018 at 9:12 AM, Guus Sliepen  wrote:

> tags 892861 - wontfix
> thanks
>
> On Wed, Mar 28, 2018 at 01:19:44PM +1300, Andrew Caudwell wrote:
>
> > Upstream has implemented my suggestion to re-add default initialization
> as
> > opt-in via a new define:
> >
> > https://github.com/g-truc/glm/issues/735
> > https://github.com/g-truc/glm/commit/8390a77b3a278b15259e5ca
> 6e67f7e41badc457b
> >
> > Could you apply the commit as a patch so maintainers can then define
> > GLM_FORCE_CTOR_INIT and avoid having to modifying code?
>
> Sure. However, I'm running into problems trying to apply the patch: it
> doesn't apply cleanly on 0.9.9~a2, and if I just package the latest
> revision from git, then I am getting internal compiler errors from GCC.
> I can still compile 0.9.9~a2 without problems, so I will try to see if I
> can just adapt the commit which adds GLM_FORCE_CTOR_INIT to 0.9.9~a2.
>
> Here's a patch I created. The main issue is they added a few macros before
the constructors that we need to remove:

git format-patch -1 8390a77b3a278b15259e5ca6e67f7e41badc457b
perl -npe "s/GLM_CONSTEXPR_(CTOR_)?CXX14 //g"
0001-Added-GLM_FORCE_CTOR_INIT-735-740.patch
> 0001-Added-GLM_FORCE_CTOR_INIT-735-740-fixed.patch

I also had to remove some expected white space from type_mat3x2.inl and
type_mat4x2.inl.

Tested it against the 0.9.9-a2 tag with GLM_FORCE_CTOR_INIT defined and it
fixes my issue.



> > Let me know as then I can then avoid having to embed the current release
> in
> > my software.
>
> Yeah, that would be less than optimal.
>
> --
> Met vriendelijke groet / with kind regards,
>   Guus Sliepen 
>
From 8390a77b3a278b15259e5ca6e67f7e41badc457b Mon Sep 17 00:00:00 2001
From: Christophe Riccio 
Date: Tue, 27 Mar 2018 18:23:37 +0200
Subject: [PATCH] Added GLM_FORCE_CTOR_INIT #735 #740

---
 glm/detail/setup.hpp| 11 +++
 glm/detail/type_mat2x2.hpp  |  2 +-
 glm/detail/type_mat2x2.inl  |  9 +++--
 glm/detail/type_mat2x3.hpp  |  2 +-
 glm/detail/type_mat2x3.inl  |  9 +++--
 glm/detail/type_mat2x4.hpp  |  2 +-
 glm/detail/type_mat2x4.inl  |  9 +++--
 glm/detail/type_mat3x2.hpp  |  2 +-
 glm/detail/type_mat3x2.inl  | 10 --
 glm/detail/type_mat3x3.hpp  |  2 +-
 glm/detail/type_mat3x3.inl  | 10 --
 glm/detail/type_mat3x4.hpp  |  2 +-
 glm/detail/type_mat3x4.inl  | 10 --
 glm/detail/type_mat4x2.hpp  |  2 +-
 glm/detail/type_mat4x2.inl  | 11 +--
 glm/detail/type_mat4x3.hpp  |  2 +-
 glm/detail/type_mat4x3.inl  | 11 +--
 glm/detail/type_mat4x4.hpp  |  2 +-
 glm/detail/type_mat4x4.inl  | 11 +--
 glm/detail/type_vec1.inl|  7 +--
 glm/detail/type_vec2.hpp|  2 +-
 glm/detail/type_vec2.inl|  7 +--
 glm/detail/type_vec3.hpp|  2 +-
 glm/detail/type_vec3.inl|  7 +--
 glm/detail/type_vec4.hpp|  2 +-
 glm/detail/type_vec4.inl|  7 +--
 glm/ext/vec1.hpp|  2 +-
 glm/gtc/quaternion.hpp  |  2 +-
 glm/gtc/quaternion.inl  |  5 -
 glm/gtx/dual_quaternion.hpp |  2 +-
 glm/gtx/dual_quaternion.inl |  6 +-
 31 files changed, 127 insertions(+), 43 deletions(-)

diff --git a/glm/detail/setup.hpp b/glm/detail/setup.hpp
index 050978c6..d6e7ba1a 100644
--- a/glm/detail/setup.hpp
+++ b/glm/detail/setup.hpp
@@ -720,8 +720,19 @@
 
 #if GLM_HAS_DEFAULTED_FUNCTIONS
 #	define GLM_DEFAULT = default
+
+#	ifdef GLM_FORCE_NO_CTOR_INIT
+#		undef GLM_FORCE_CTOR_INIT
+#	endif
+
+#	ifdef GLM_FORCE_CTOR_INIT
+#		define GLM_DEFAULT_CTOR
+#	else
+#		define GLM_DEFAULT_CTOR = default
+#	endif
 #else
 #	define GLM_DEFAULT
+#	define GLM_DEFAULT_CTOR
 #endif
 
 #if GLM_HAS_CONSTEXPR || GLM_HAS_CONSTEXPR_PARTIAL
diff --git a/glm/detail/type_mat2x2.hpp b/glm/detail/type_mat2x2.hpp
index ed9b782f..47e28cba 100644
--- a/glm/detail/type_mat2x2.hpp
+++ b/glm/detail/type_mat2x2.hpp
@@ -34,7 +34,7 @@ namespace glm
 
 		// -- Constructors --
 
-		GLM_FUNC_DECL mat() GLM_DEFAULT;
+		GLM_FUNC_DECL mat() GLM_DEFAULT_CTOR;
 		GLM_FUNC_DECL mat(mat<2, 2, T, Q> const& m) GLM_DEFAULT;
 		template
 		GLM_FUNC_DECL mat(mat<2, 2, T, P> const& m);
diff --git a/glm/detail/type_mat2x2.inl b/glm/detail/type_mat2x2.inl
index 3c7fae56..72971d8c 100644
--- a/glm/detail/type_mat2x2.inl
+++ b/glm/detail/type_mat2x2.inl
@@ -7,10 +7,15 @@ namespace glm
 {
 	// -- Constructors --
 
-#	if !GLM_HAS_DEFAULTED_FUNCTIONS
+#	if !GLM_HAS_DEFAULTED_FUNCTIONS || defined(GLM_FORCE_CTOR_INIT)
 		template
 		GLM_FUNC_QUALIFIER mat<2, 2, T, Q>::mat()
-		{}
+		{
+#			ifdef GLM_FORCE_CTOR_INIT
+this->value[0] = col_type(1, 0);
+this->value[1] = col_type(0, 1);
+#			endif
+		}
 #	endif
 
 #	if !GLM_HAS_DEFAULTED_FUNCTIONS
diff --git 

Bug#894163: RFS: streamlink/0.11.0+dfsg-1~bpo9+1

[Alexis Murzeau]

Le 28/03/2018 à 03:46, Paul Wise a écrit :
> On Tue, 2018-03-27 at 22:49 +0200, Alexis Murzeau wrote:
> 
>> Can you post your logs ?
> 
> Attached.
> 
>> I cannot reproduce this error either with sbuild or pbuilder.
> 
> I guess the LANG/LC_ALL in your chroots has UTF-8 in the name,
> for some reason mine only has LANG=C LC_ALL=C.
> 
> Strangely, the RB infra builds fine with LANG=C LC_ALL=C:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/streamlink.html
> 
>> I previously encountered this encoding error and it should have been fixed
>> by debian/patches/0006-Avoid-use-of-non-ASCII-in-plugins.patch.
> 
> You only patched one of the UTF-8 files, not all of them:
> 
> $ file src/streamlink/plugins/* | grep -v ASCII
> src/streamlink/plugins/showroom.py:   Python script, UTF-8 
> Unicode text executable
> 
> This file includes some Chinese characters in the keys of a dict,
> so I don't think you will be able to patch them out.
> 
> $ grep -C3 --color='auto' -P -n "[^\x00-\x7F]" 
> src/streamlink/plugins/showroom.py
> 42-
> 43-# the "low latency" streams are rtmp, the others are hls
> 44-_rtmp_quality_lookup = {
> 45:"オリジナル画質": "high",
> 46:"オリジナル画質(低遅延)": "high",
> 47-"original spec(low latency)": "high",
> 48-"original spec": "high",
> 49:"低画質": "low",
> 50:"低画質(低遅延)": "low",
> 51-"low spec(low latency)": "low",
> 52-"low spec": "low"
> 53-}
> 
> So upstream needs to load the plugin files using the UTF-8 encoding.
> 

I think I have found the cause.
I found that the failing test was loading python modules using
imp.load_module with possibly closed file descriptor.
In that case, python reopen the file descriptor using open() which use
the system encoding by default (here, ASCII).

This does not always happen reliably and I'm not sure why, but I think
this the reason we have not the same test behavior.

I've replaced the patch 0006-Avoid-use-of-non-ASCII-in-plugins.patch
with another patch ensuring load_module is given an open file descriptor.

I've uploaded the resulting package on mentors.debian.net.
Does it work for you ? Thanks :)

dget
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_0.11.0+dfsg-1~bpo9+1.dsc


PS: Note that this uploaded package does not contain the build twice in
a row fix.

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#890485: xserver-xorg-core 1.19.6 crash

[Marek Vasut]

On 02/24/2018 08:48 PM, Marek Vasut wrote:
> [...]
 But this is a bug in the debian-patched X11 packages ?
>>>
>>> It's most likely a bug introduced with the new upstream release.
>>> There's only one newly added Debian-only patch
>>> (07-glx-do-not-pick-srgb-config-for-32bit-rgba-visual.diff). All the
>>> other changes documented in debian/changelog are packaging related
>>> changes. You could try to disable this patch by commenting the patch
>>> in the debian/patches/series file and rebuilding xorg-server. Though I
>>> don't think your issue is caused by this patch.
>>
>> I bisected it to be057d8cc7dfbc0b56cf2434ccfeeb8e30208e35
>> "glx: Duplicate relevant fbconfigs for compositing visuals"
>>
>> If I revert that on top of xorg-server-2_1.19.6-1 , the X doesn't crash
>> anymore.
> 
> +CC Thomas .

This is still broken, any news ?

-- 
Best regards,
Marek Vasut

Bug#889072: chromium: Crash when opening print dialog (regression from v 63 in stable)

[Tony Thedford]

I am having the same issue. Chromium version 64.0.3282.119-1~deb9u1
exhibits the problem while version 63.0.3239.84-1~deb9u1 does not.

I also am running with strict isolation enabled.

I also agree that this is not a minor problem. It is actually kind of a
big problem since there is now no way to safely print a page from
Chromium. Turning off strict isolation is not a safe work around as far
as I know.

-- 
Tony Thedford

Bug#893561: libtablelayout-java: license does not seem to meet the DFSG

[Markus Koschany]

Am 28.03.2018 um 23:34 schrieb Francesco Poli:
> On Sat, 24 Mar 2018 15:22:12 +0100 Markus Koschany wrote:
> 
>> Am 24.03.2018 um 00:17 schrieb Francesco Poli:
> [...]
>>> Was the debian-legal discussion pointed out to the FTP Masters?
>>> Did they explain the rationale behind their decision? 
>>
>> FYI, debian-legal is a mailing list and not a Debian body that can exert
>> any power over the FTP masters.
> 
> I am well aware of this, as I have participated in debian-legal
> discussions for more than 13 years.

I intend to make this my last reply to Debian bug #893561. However if my
following answer does not satisfy you, there is the last resort of
asking Debian's technical committee (CTTE) for a definite ruling.


> debian-legal is more like a sort of advisory board, where licensing
> issues are discussed and analyzed. The FTP Masters are not bound to
> follow the advice, of course.
> But, whenever an issue was actually discussed on debian-legal, it is
> useful for the FTP Masters to be informed about the discussion, so that
> they can see what was said and pointed out, before making their
> decision.
> Otherwise, what's the point in having a discussion on debian-legal, if
> the FTP Masters are left unaware of it and must analyze the license
> from scratch?

I know your involvement in debian-legal from previous discussions. Like
I said before debian-legal is a mailing list and not an authoritative
body of Debian. Of course everyone is entitled to his/her own opinion
but nevertheless in the end only the FTP masters decide whether a
license is compatible to Debian's Free Software Guidelines. It is at
least questionable why you act now, _nine_ years later.

>> They may or may not have been aware of
>> the discussion but by accepting libtablelayout-java into Debian they
>> clearly made a decision in favor of the license.
> The FTP Masters are humans and may make mistakes, like all of us.
> They could have overlooked some troublesome clause in the license, if
> not informed about the potential issue...

Please note that this package was introduced to Debian by Torsten Werner
who was once a FTP master himself. I know that Torsten was highly
critical of some game licenses that were accepted into Debian and I'm
pretty sure he didn't introduce libtablelayout-java purely on a whim.

> [...]
>>> The issue is not the requirement to modify the package through patch
>>> files. Patch-only clauses are explicitly allowed by DFSG#4, as you
>>> correctly point out.
>>> As I have previously said, the issue is that the license forbids to
>>> create a derived work that uses the info.clearthought namespace/package.
>>>
>>> This goes beyond what is allowed by DFSG#4, which only talks about
>>> patch files and requirements to change the *name* or the *version
>>> number*.
>>
>> No, this is precisely why DFSG 4 mentions patch files explicitly and why
>> DFSG 4 is named "Integrity of The Author's Source Code".
> 
> Once again, patch files are not the freeness issue I am talking about.
> The troublesome clause is the namespace-change restriction.

As I pointed out before the namespace-change is not an issue for Debian.
We are acting according to the license and there is certainly no need to
revert to the original namespace once you have created a derived work?

>> We respect the
>> authors source code and his wish to preserve the info.clearthough
>> namespace. Nevertheless we are allowed to change it for derived works
>> and can rename it to any name we want. This is sufficiently DFSG-free.
>> The name is "info.clearthought" which is the official upstream URL. It
>> is common practice in Java to use a namespace that corresponds to some
>> URL. It is completely fair to reserve info.clearthought because Debian
>> also reserves the rights for debian.org or the name Debian in general.
> 
> Please let me understand, as I am not too familiar with Java.
> Isn't the namespace concept in Java similar to the corresponding
> concept in C++?
> 
> Suppose someone has several Java programs that link with
> libtablelayout-java and use classes from the info.clearthought
> namespace.
> Suppose he/she wants to use a modified version of libtablelayout-java
> (maybe with some bugs fixed, or something like that) where the
> namespace has been changed to a different one.
> Can he/she use the programs with the modified libtablelayout-java,
> without having to modify each one of them?
> 
> In other words, can someone develop a fork of libtablelayout-java (with
> the namespace changed to a different one) which works as a drop-in
> replacement for the original libtablelayout-java?

We have already created a derived work of libtablelayout-java. We don't
need to change the namespace ever again. This is similar to license
clauses that say: If you make changes to this program, don't claim it is
the original program, mark them as separate changes. We have accepted
such licenses into Debian and it makes a lot of sense to do so.

> [...]
>>> The thread is the very

Bug#881431: proposed wording

[Sean Whitton]

Hello Adam,

On Wed, Mar 28 2018, Adam Borowski wrote:

> Here's my proposed wording:

Thank you for working on this.

> .
> §3.2.2. Versions must be unique

"Uniqueness of version numbers" would be more fitting with Policy's
tone.

And versions are unique by definition :)  It's version numbers that are
the problem here.

> Because of a quirk of file naming, version numbers that are identical
> save for epoch cause problems, and thus must not be used.

This sentence is quite confusing.  It seems to suggest that the whole
reason version numbers should not be reused is because of a quirk in
file naming, which is false.

Further, if we're going to mention the quirk in file naming, we should
say what that quirk is, or people reading won't understand what's going
on.

Finally, you haven't given a sense to the verb phrase "use version
numbers that are identical" -- use them for what?

Suggested replacement:

The part of the version number after the epoch must not be reused for a
version of the package with different contents, even if the version
of the package previously using that part of the version number is
no longer present in any archive suites.

Epochs are not included in the names of the files that compose
source packages, or in the filenames of binary packages, so reusing
a version number, even if the epoch differs, results in identically
named files with different contents.  This causes various problems.

> In such case

I think we should say what the case is.

> you may bump the Debian revision (it doesn't need to
> start at 1 or be consecutive) or append a tag.

Policy doesn't define "tags" in version numbers so might be good to give
an example (possibly using the +really convention?).

> In these three namespaces: source, upstream (.orig), and binary, a
> combination of package name:version-without-epoch must never be reused
> once a package has been accepted into the archive, even after a
> release the package belonged to has been obsoleted.

I think the quoted sentence is obsoleted by what I wrote above, so can
be deleted.  But let me know what you think.

> WRT doing policy first before DAK/etc implementation: a maintainer in
> #887740 refused to make a version before such a requirement has been agreed
> upon -- thus, it'd be good to provide guidelines even before they're
> enforced with code.

Just to note that since Policy is about the contents of source and
binary packages, not about the behaviour of dak, this is a case where
our convention of changing the archive before changing Policy does not
apply, and so existing convention does not determine which should happen
first.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#894314: [PATCH] audit: Please add support for a pkg.audit.noldap build-profile

[Karsten Merker]

Package: audit
Version: 1:2.8.2-1
Severity: wishlist
X-Debbugs-CC: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

we are in the process of bootstrapping a Debian port for the
riscv64 architecture (https://wiki.debian.org/RISC-V). The
audit package is part of the build-dependency chain for the
essential package set, so we need to build it to be able to
complete the bootstrap process.

Unfortunately audit is involved in a circular set of
build-dependencies: audit build-depends on openldap, openldap
build-depends on cyrus-sasl, cyrus-sasl build-depends on pam and
pam build-depends on audit, which is where the cat chases its
tail :-).

To break this circular dependency in a proper way, it is necessary
to add a build-profile (https://wiki.debian.org/BuildProfileSpec)
to audit which allows building the package without support for
openldap.  AIUI, the only binary package built from the audit
source that actually needs openldap is audispd-plugins, in
particular the zos-remote plugin.  Attached is a patch that adds
support for a pkg.audit.noldap build-profile that does two things
when enabled:

  - disable the build-dependency on libldap2-dev
  - disable building the audispd-plugins binary package

It would be great if you could upload a version of audit with
this patch included to unstable soon as we depend on it for
continuing with our bootstrapping efforts.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
diff -Nur audit-2.8.2.orig/debian/control audit-2.8.2.new/debian/control
--- audit-2.8.2.orig/debian/control
+++ audit-2.8.2.new/debian/control
@@ -10,7 +10,7 @@
 # audit sources embed their own patched version of libev
 #   libev-dev,
libkrb5-dev,
-   libldap2-dev,
+   libldap2-dev ,
libprelude-dev,
libwrap0-dev,
python-all-dev:any (>= 2.6.6-3~) ,
@@ -138,6 +138,7 @@
 Section: admin
 Architecture: linux-any
 Depends: auditd, ${misc:Depends}, ${shlibs:Depends}
+Build-Profiles: 
 Description: Plugins for the audit event dispatcher
  The audispd-plugins package provides plugins for the real-time
  interface to the audit system, audispd. These plugins can do things
diff -Nur audit-2.8.2.orig/debian/rules audit-2.8.2.new/debian/rules
--- audit-2.8.2.orig/debian/rules	2017-12-18 08:13:02.0 +
+++ audit-2.8.2.new/debian/rules	2018-03-28 17:38:29.354936110 +
@@ -30,6 +30,10 @@
   EXTRA_ARCH_TABLE := --with-hppa
 endif
 
+ifneq ($(filter pkg.audit.noldap,$(DEB_BUILD_PROFILES)),)
+  CONFIGURE_FLAGS += --disable-zos-remote
+endif
+
 %:
 	dh $@ --builddirectory=debian/build --buildsystem=autoconf $(DH_ADDONS)
 

Bug#893221: knopflerfish-osgi FTBFS with openjdk-9

[Emmanuel Bourg]

Le 28/03/2018 à 21:40, Felix Natter a écrit :

> I tried several variations of javadoc's -exclude parameter:
> 
> -exclude "org.knopflerfish.framework.bundlestorage.dex"
> -exclude "org.knopflerfish.framework.bundlestorage.dex.DexArchive"
> -exclude "org.knopflerfish.framework.bundlestorage.dex.*"
> -exclude "org/knopflerfish/framework/bundlestorage/dex"
> -exclude dalvik.system
> [...]
> 
> Do you have an idea what I'm doing wrong? To me it looks like -exclude
> is broken/ignored. If we can't fix the javadoc invocation, I suggest
> to patch out DexArchive.java.
> What do you think?

I gave it a try and I haven't been able to get the -exclude option to
work as documented either. I managed to build the javadoc with the
"--ignore-source-errors -Xdoclint:none" options, but this may break
again in the future.

I suggest simply removing the -java-doc package, it has a low popcon and
no reverse dependencies.

Emmanuel Bourg

Bug#893561: libtablelayout-java: license does not seem to meet the DFSG

[Emmanuel Bourg]

Le 28/03/2018 à 23:34, Francesco Poli a écrit :

> In other words, can someone develop a fork of libtablelayout-java (with
> the namespace changed to a different one) which works as a drop-in
> replacement for the original libtablelayout-java?

If you change the namespace it can't be used as a drop-in replacement.

But since the Debian libtablelayout-java package is already a fork of
the upstream TableLayout project using a different namespace (as
required by the license for derivative works), there is no need to
change again the namespace for anyone modifying the libtablelayout-java
package.

Emmanuel Bourg

Bug#894313: etherape: Crashes on startup

[Pelle Hjek]

Package: etherape
Version: 0.9.16-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I'm trying to start etherape, but it crashes with this error:

% etherape

(etherape:32196): libglade-WARNING **: Could not load support for `gnome': 
libgnome.so: cannot open shared object file: No such file or directory

(etherape:32196): libglade-WARNING **: unknown widget class 'GnomeCanvas'

(etherape:32196): Gtk-WARNING **: gtk_scrolled_window_add(): cannot add non 
scrollable widget use gtk_scrolled_window_add_with_viewport() instead
EtherApe-INFO: sctp protocol not supported
EtherApe-INFO: ddp protocol not supported
EtherApe-INFO: ddp protocol not supported
EtherApe-INFO: ddp protocol not supported
EtherApe-INFO: ddp protocol not supported

(etherape:32196): GLib-GObject-WARNING **: invalid cast from 'GtkLabel' to 
'GnomeCanvas'

(etherape:32196): GnomeCanvas-CRITICAL **: gnome_canvas_root: assertion 
'GNOME_IS_CANVAS (canvas)' failed

(etherape:32196): GnomeCanvas-CRITICAL **: gnome_canvas_item_new: assertion 
'GNOME_IS_CANVAS_GROUP (parent)' failed
**
ERROR:diagram.c:250:addref_canvas_obj: assertion failed: (obj)
zsh: abort  etherape
% unexpected EOF in read_all()
critical: read_all() failed on control socket

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

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

Versions of packages etherape depends on:
ii  etherape-data0.9.16-1
ii  libart-2.0-2 2.3.21-3
ii  libatk1.0-0  2.26.1-3
ii  libc-ares2   1.14.0-1
ii  libc62.27-1
ii  libcairo21.15.10-2
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-2
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglade2-0  1:2.6.4-2+b1
ii  libglib2.0-0 2.54.3-2
ii  libgnomecanvas2-02.30.3-3
ii  libgtk2.0-0  2.24.32-1
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libpangoft2-1.0-01.40.14-1
ii  libpcap0.8   1.8.1-6
ii  libpopt0 1.16-10+b2
ii  libxml2  2.9.4+dfsg1-6.1

etherape recommends no packages.

etherape suggests no packages.

-- no debconf information

Bug#892923: aptitude: After upgrading ncurses, aptitude fails to correctly display dialog windows and align columns

[Jiri Palecek]

On 3/16/18 1:24 PM, Manuel A. Fernandez Montecelo wrote:

Control: tags -1 + moreinfo


Hi Jiri,

2018-03-14 15:34 Jiri Palecek:

Package: aptitude
Version: 0.8.10-6
Severity: normal

Dear Maintainer,

after upgrading libncurses5 to version 6.1-1, aptitude no longer
displays its GUI correctly. The columns are not aligned, and the dialog
boxes fail to use the width of the screen. See this screenshot with what
should be a search dialog:

Other console applications (mc, emacs) don't exhibit this behaviour, so
I'm filing this to aptitude. Please have a look at it.


Thanks for the report.

I have the same versions installed and for me it works perfectly.

 $ aptitude search -F '%p %v' --disable-columns 
'~i~n^(aptitude|libncursesw5)$'

 aptitude 0.8.10-6
 aptitude-common 0.8.10-6
 aptitude-dbgsym 0.8.10-6
 libncursesw5 6.1-1
 libncursesw5-dev 6.1-1

This will require more investigation.

Maybe the locale/encoding?

 Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE= 
(charmap=ISO-8859-2)



No, it isn't this (checked that).

In fact, after finding that dialog is also affected by this problem and 
dissecting the escape codes sent to the terminal, I can conclude that 
the true culprit is Konsole. xterm and text console all work well.


The problem seems to be the escape sequence ESC [ 7 b. Problem is, I 
can't find anywhere documented what it does, but it should be something 
like repeat last char 7 times.


Regards

    Jiri Palecek

Bug#881431: proposed wording

[Adam Borowski]

Control: tags -1 +patch


Here's my proposed wording:

.
§3.2.2. Versions must be unique

Because of a quirk of file naming, version numbers that are identical save
for epoch cause problems, and thus must not be used.  In such case you may
bump the Debian revision (it doesn't need to start at 1 or be consecutive)
or append a tag.  In these three namespaces: source, upstream (.orig), and
binary, a combination of package name:version-without-epoch must never be
reused once a package has been accepted into the archive, even after a
release the package belonged to has been obsoleted.
`

This should address all issues mentioned in this bug, plus a not entirely
obvious case of a new source package producing a binary with a name that
used to belong to another package.

It also forbids the secret tech of uploading 1.2.3.orig.tar.gz then
1.2.3.orig.tar.xz; this is sometimes useful but the confusion is not
worth it compared to adding a tag.

WRT doing policy first before DAK/etc implementation: a maintainer in
#887740 refused to make a version before such a requirement has been agreed
upon -- thus, it'd be good to provide guidelines even before they're
enforced with code.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Bug#809069: logind sometimes blocks input to X after VT switch

[Ben Hutchings]

On Wed, 2018-03-28 at 12:47 +0200, Michael Biebl wrote:
> Control: tags -1 + moreinfo
> 
> Am 09.03.2017 um 06:40 schrieb Michael Biebl:
> > Hi Ben
> > 
> > On Sat, 26 Dec 2015 22:44:45 + Ben Hutchings 
> > wrote:
> > > Package: systemd
> > > Version: 228-2
> > > Severity: important
> > > 
> > > After switching between a text console (VT 1) and X (VT 7) a few
> > > times, I found that keyboard and mouse input no longer worked in X.
> > > The system log showed this:
[...]
> > Sorry for not replying earlier. This bug is rather old, do you still
> > experience on an up-to-date stretch system?
> 
> This went unanswered, so probably fell through the cracks.
> Ben, do you still run into this issue with stretch and/or buster?

I don't remember seeing this again.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.



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

Bug#856179: ITP: polybar -- fast and easy-to-use status bar

[Jason Pleau]

Hi,

I'll try to answer your questions :)

On 03/28/2018 10:51 AM, Antoine Beaupré wrote:
> On 2018-03-27 21:15:35, Jason Pleau wrote:
>> Hi.
>>
>> I took a few hours last weekend to work on this.
> 
> Awesome, thanks for the work!
> 
>> While I was able to have "working" packages for both xpp and i3ipcpp,
>> I could not get polybar to use them (the whole thing is glued together
>> nicely it seems and trying to split them caused me headaches). So I
>> went ahead and worked on packaging the whole repo (and submodules)
>> together.
> 
> Can you expand on the problems you've encountered?

Sure. Basically, by itself xpp, it's a header-only library. To build a
project using it you have to include xpp's CMakeLists.txt from cmake,
which then includes other cmake modules to find the different XCB modules.

xpp's CMake file then generates the appropriate XCB_* libraries for your
own project (in this case, polybar) to link against.

So, if I was to take "xpp" into it's own package, polybar currently
would have no way to know which XCB libraries to link against, since it
uses xpp's own CMakeFile to find those. That's where I was stuck (I
don't really use CMake so this stuff is out of my reach for the time being)

> 
>> Repo: https://salsa.debian.org/jpleau-guest/polybar
>>
>> Current status: it builds in a chroot and works on my sid install.
> 
> I have tried to build this in stretch and failed:
> 
> $ sbuild -c stretch
> dh clean --buildsystem=cmake --builddirectory=build
>dh_auto_clean -O--buildsystem=cmake -O--builddirectory=build
>dh_autoreconf_clean -O--buildsystem=cmake -O--builddirectory=build
>dh_clean -O--buildsystem=cmake -O--builddirectory=build
> dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream 
> tarball found at ../polybar_3.1.0.orig.tar.{bz2,gz,lzma,xz}
> E: Failed to package source directory /home/anarcat/dist/polybar
> 1$ uscan
> uscan warn: No watch file found
> 1$ gbp buildpackage -c stretch
> dh clean --buildsystem=cmake --builddirectory=build
>dh_auto_clean -O--buildsystem=cmake -O--builddirectory=build
>dh_autoreconf_clean -O--buildsystem=cmake -O--builddirectory=build
>dh_clean -O--buildsystem=cmake -O--builddirectory=build
> gbp:error: upstream/3.1.0 is not a valid treeish
> 
> So a few things here:
> 
>  * a debian/watch file would be useful, even if just to find out new
>versions are coming out...
>  * the upstream tree should be tagged
>  
> When those are fixed, I get this:
> 
>  sbuild-build-depends-polybar-dummy : Depends: debhelper (>= 11) but it is 
> not going to be installed
> 
> So it might also be useful to make the DH dependency >= 11~ to allow for
> easier backporting. I can send a merge request for that on Salsa (or a
> patch here) if you want.
> 

1) watch file: I can add the watch file, if only to check for new versions.

2) debhelper version: sure, I didn't really test building for stretch
but I see no harm in changing the version for debhelper if it means
polybar can be backported (no need to do a MR I'll take care of it)

>> TODO:
>>
>> - There's a few copyright info missing (ie: lib/concurrentqueue)-
> 
> Seems to be 2-clause BSD.

Yep, I saw it but I didn't add the changes yet to debian/copyright
(hence the TODO title!)

> 
>> - After installing the package, it won't do anything because the config
>> file is not found (it should be in $HOME/.config/polybar). There is one
>> shipped in /usr/share/doc/polybar/config.gz, but surely there's a way to
>> tell the users that when they install the package?
> 
> /usr/share/doc/polybar/README.Debian is usually where I would expect
> that kind of information to be, or in the manpage, or in the error
> message directly.. Also, I would expect to find the config.gz file in an
> examples/ subdirectory there.
> 
> Maybe a more long-term solution would be to ship the sample config file
> in /etc/polybar/config and patch the package to look for there on top of
> $XDG_CONFIG_HOME. The proper place to look for those is XDG_CONFIG_DIRS,
> which defaults to /etc/xdg, which I've always found weird. See this spec
> for details:
> 
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Yes I think upstream would be in favor of having a "system-wide" config
file to use as fallback. /etc/polybar or /etc/polybar/config, I'll have
to see what other programs do.
> 
>> Note that I made a custom get-orig-source rule. The tarball didn't
>> contain xpp and i3ipcpp (github generated tarballs don't include
>> submodules). It seems to work fine, feedback welcome on this one..
> 
> hmm... that does look kind of nasty. :p Why is the version number
> hardcoded in $GIT_VER? Why not just use DEB_VERSION_UPSTREAM there?

Initially I was using DEB_VERSION_UPSTREAM, but then I thought what if I
needed to package a version that has no release (ie: a git revision).

Doing it this way lets me use either DEB_VERSION_UPSTREAM, a git tag, or
a specific commit.

> 
> It's fine for testing 

Bug#893561: libtablelayout-java: license does not seem to meet the DFSG

[Francesco Poli]

On Sat, 24 Mar 2018 15:22:12 +0100 Markus Koschany wrote:

> Am 24.03.2018 um 00:17 schrieb Francesco Poli:
[...]
> > Was the debian-legal discussion pointed out to the FTP Masters?
> > Did they explain the rationale behind their decision? 
> 
> FYI, debian-legal is a mailing list and not a Debian body that can exert
> any power over the FTP masters.

I am well aware of this, as I have participated in debian-legal
discussions for more than 13 years.

debian-legal is more like a sort of advisory board, where licensing
issues are discussed and analyzed. The FTP Masters are not bound to
follow the advice, of course.
But, whenever an issue was actually discussed on debian-legal, it is
useful for the FTP Masters to be informed about the discussion, so that
they can see what was said and pointed out, before making their
decision.
Otherwise, what's the point in having a discussion on debian-legal, if
the FTP Masters are left unaware of it and must analyze the license
from scratch?

> They may or may not have been aware of
> the discussion but by accepting libtablelayout-java into Debian they
> clearly made a decision in favor of the license.

The FTP Masters are humans and may make mistakes, like all of us.
They could have overlooked some troublesome clause in the license, if
not informed about the potential issue...

[...]
> > The issue is not the requirement to modify the package through patch
> > files. Patch-only clauses are explicitly allowed by DFSG#4, as you
> > correctly point out.
> > As I have previously said, the issue is that the license forbids to
> > create a derived work that uses the info.clearthought namespace/package.
> > 
> > This goes beyond what is allowed by DFSG#4, which only talks about
> > patch files and requirements to change the *name* or the *version
> > number*.
> 
> No, this is precisely why DFSG 4 mentions patch files explicitly and why
> DFSG 4 is named "Integrity of The Author's Source Code".

Once again, patch files are not the freeness issue I am talking about.
The troublesome clause is the namespace-change restriction.

> We respect the
> authors source code and his wish to preserve the info.clearthough
> namespace. Nevertheless we are allowed to change it for derived works
> and can rename it to any name we want. This is sufficiently DFSG-free.
> The name is "info.clearthought" which is the official upstream URL. It
> is common practice in Java to use a namespace that corresponds to some
> URL. It is completely fair to reserve info.clearthought because Debian
> also reserves the rights for debian.org or the name Debian in general.

Please let me understand, as I am not too familiar with Java.
Isn't the namespace concept in Java similar to the corresponding
concept in C++?

Suppose someone has several Java programs that link with
libtablelayout-java and use classes from the info.clearthought
namespace.
Suppose he/she wants to use a modified version of libtablelayout-java
(maybe with some bugs fixed, or something like that) where the
namespace has been changed to a different one.
Can he/she use the programs with the modified libtablelayout-java,
without having to modify each one of them?

In other words, can someone develop a fork of libtablelayout-java (with
the namespace changed to a different one) which works as a drop-in
replacement for the original libtablelayout-java?

[...]
> > The thread is the very
> > [one](https://lists.debian.org/debian-legal/2009/06/msg00050.html)
> > I cited in my bug report.
> > 
> > There were two replies, one by Joe Smith and one by me.
> > Joe said that the license is acceptable and within the spirit of the
> > DFSG.
> > On the other hand, I said that two clauses fail to meet the DFSG.
> > 
> > Now, I respect Joe's opinion, but it's not clear to me why you claim
> > that *his* reply represents the outcome of the debian-legal discussion,
> > while *my* reply is just my personal opinion...
> 
> I have never said that and it is also not relevant.

Well, you said:

"This is your personal opinion. It was already discussed on debian-legal
back in 2009 that the license is still acceptable and in the spirit of
the DFSG."

as if the only reply on debian-legal had been the one from Joe...

[...]
> > The license of libtablelayout-java is *clearly* GPL-incompatible, no
> > doubt about it.
> > 
> > It is a patch-only license and has restrictions on namespace change for
> > derived works.
> > These restrictions (and possibly other ones) are not included in the
> > GNU GPL v2 or v3, nor allowed by them.
> 
> Again, this is _your_ opinion. If it was that easy we wouldn't need any
> lawyers in the world.

Sorry, but that is not just _my_ opinion.
It's a well known fact: patch-only licenses are GPL-incompatible.
Anyone who knows enough about the GNU GPL will tell you so.

We may need lawyers for difficult licensing issues, but not for every
single step during software development!

[...]
> Feel free to contact all
> upstreams yourself though and discuss any 

Bug#827065: [uscan] add signed git tag support (pgpmode)'

[Georg Faerber]

(Sorry for missing References: and In-Reply-To:)

Hi all,

I became a DM recently and maintain some packages by now, mostly within
the Ruby team. I would *love* to see this implemented, and I'm offering
help, hereby.

I've got no clue about Perl, but I know quite a bit of Python. ;)

@Osamu: Is there any update on this? What's the current state?

@Debian Perl group: Would someone of you willing to mentor me with this?

Looking forward,
cheers,
Georg


[1] https://qa.debian.org/developer.php?login=georg%40riseup.net


signature.asc
Description: Digital signature

Bug#893359: marked as done (jboss-xnio FTBFS with openjdk-9)

[Emmanuel Bourg]

Le 28/03/2018 à 22:39, Markus Koschany a écrit :

> Ah, I see. Forgive my ignorance but wasn't --ignore-source-errors some
> kind of internal developer hack which can be removed at anytime?

You are right, I'm just crossing my fingers that it will happen after
Java 11 (so far our openjdk-11 package still support it).

> I faintly remember that we reverted this change for Ant already because it
> broke some reverse-dependencies. Oh well, you can tell me later.

This is the ongoing discussion in #893547. The --ignore-source-errors
option works only with the default doclet. Packages using a custom
doclet fail to build with this option. In maven-javadoc-plugin/3.0.0-3
the --ignore-source-errors option is added only if no doclet is
specified. I plan to do the same with Ant (and Gradle will probably need
the same treatment).

Bug#890266: php5-common: 0050-Detect-invalid-port-in-xp_socket-parse-ip-address.patch incomplete

[jack]

Source: php5
Version: 5.6.33+dfsg-0+deb8u1
Followup-For: Bug #890266

Dear Maintainer,

I confirm the existence of this bug

The following snippet triggers the issue:
stream_socket_client('tcp://localhost:6379/');

On php 5.6.30+dfsg-0+deb8u1, the call is a success
On php 5.6.33+dfsg-0+deb8u1:
PHP Warning:  stream_socket_client(): unable to connect to 
tcp://localhost:6379/ (Failed to parse address "localhost:6379/") in 
/tmp/test.php on line 3

The '/' behavior seems to be a long known trick, used by many libs etc (which 
are broken with the 5.6.33 release), despite the absence of official 
documentation:
https://stackoverflow.com/a/30391981/4091648
https://secure.php.net/manual/en/function.stream-socket-client.php#105393

Thanks for maintaining,

-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.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 /bin/das

Bug#893359: marked as done (jboss-xnio FTBFS with openjdk-9)

[Markus Koschany]

Am 28.03.2018 um 22:35 schrieb Emmanuel Bourg:
> Le 28/03/2018 à 22:29, Markus Koschany a écrit :
> 
>> I'm just wondering, we never had 3.0.0-3 of maven-bundle-plugin in
>> Debian. How did it get fixed and what does maven-bundle-plugin do now to
>> make those Java modules accessible? I thought this was an issue of the
>> application build system and not a general tool chain problem. Just
>> asking because that could probably speed some things up. :)
> 
> Err I meant maven-javadoc-plugin/3.0.0-3. Sorry, I need some sleep ;)
> 
> Emmanuel
> 

Ah, I see. Forgive my ignorance but wasn't --ignore-source-errors some
kind of internal developer hack which can be removed at anytime? I
faintly remember that we reverted this change for Ant already because it
broke some reverse-dependencies. Oh well, you can tell me later.



signature.asc
Description: OpenPGP digital signature

Bug#893359: marked as done (jboss-xnio FTBFS with openjdk-9)

[Emmanuel Bourg]

Le 28/03/2018 à 22:29, Markus Koschany a écrit :

> I'm just wondering, we never had 3.0.0-3 of maven-bundle-plugin in
> Debian. How did it get fixed and what does maven-bundle-plugin do now to
> make those Java modules accessible? I thought this was an issue of the
> application build system and not a general tool chain problem. Just
> asking because that could probably speed some things up. :)

Err I meant maven-javadoc-plugin/3.0.0-3. Sorry, I need some sleep ;)

Emmanuel

Bug#893427: tunnelx FTBFS with openjdk-9

[Emmanuel Bourg]

Control: tags -1 + patch

Here is a patch fixing this issue.
--- a/src/SelectedSubsetsStructure.java
+++ b/src/SelectedSubsetsStructure.java
@@ -257,7 +257,7 @@
OneLeg ol = (OneLeg)tn.getUserObject(); 
 if (btransitivesubset)
{
-   Enumeration 
tnenum = tn.depthFirstEnumeration(); 
+   Enumeration 
tnenum = (Enumeration) tn.depthFirstEnumeration(); 
while (tnenum.hasMoreElements())

vsselectedsubsets.add(((OneLeg)tnenum.nextElement().getUserObject()).stto);  // 
the actual subset name, not the thing that appears in the treeview
}

Bug#893359: marked as done (jboss-xnio FTBFS with openjdk-9)

[Markus Koschany]

Hi,

I'm just wondering, we never had 3.0.0-3 of maven-bundle-plugin in
Debian. How did it get fixed and what does maven-bundle-plugin do now to
make those Java modules accessible? I thought this was an issue of the
application build system and not a general tool chain problem. Just
asking because that could probably speed some things up. :)



signature.asc
Description: OpenPGP digital signature

Bug#894312: rrootage: New upstream version 0.24

[Peter De Wachter]

Source: rrootage
Version: 0.23a-12+b1
Severity: normal

A new upstream version, rRootage 0.24, has been released:

http://www.asahi-net.or.jp/~cs8k-cyu/windows/rr_e.html
https://github.com/abagames/rrootage

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

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

Bug#894311: php-imagick: Install script should restart apache

[Mark Roberts]

Package: php-imagick
Version: 3.4.3~rc2-2
Severity: minor

Dear Maintainer,

after installing php-imagick the php class Imagick was still not found
by php scripts launched by apache2. Restarting apache2 solved the
problem.

It seems to me that the installation script should have restarted
apache2, since a novice user might not expect to have to do it
herself. In fact, it would probably have been enough to reload
apache2's config files.

Surely a five minute fix for someone who knows what they're doing.

Thanks,
Mark Roberts


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

Kernel: Linux 4.9.0-6-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)

Versions of packages php-imagick depends on:
ii  libapache2-mod-php7.0 [phpapi-20151012]  7.0.27-0+deb9u1
ii  libc62.24-11+deb9u3
ii  libmagickcore-6.q16-38:6.9.7.4+dfsg-11+deb9u4
ii  libmagickwand-6.q16-38:6.9.7.4+dfsg-11+deb9u4
ii  php-common   1:49
ii  php7.0-cli [phpapi-20151012] 7.0.27-0+deb9u1

Versions of packages php-imagick recommends:
ii  ghostscript  9.20~dfsg-3.2+deb9u1
ii  ttf-dejavu-core  2.37-1

php-imagick suggests no packages.

-- no debconf information

Bug#893382: closed by Markus Koschany <a...@debian.org> (Re: osgi-foundation-ee FTBFS with openjdk-9)

[Markus Koschany]

Am 28.03.2018 um 15:13 schrieb Adrian Bunk:
> Control: reopen -1
> 
>> Date: Wed, 28 Mar 2018 14:19:30 +0200
>> From: Markus Koschany 
>> To: 893382-d...@bugs.debian.org
>> Subject: Re: osgi-foundation-ee FTBFS with openjdk-9
>>
>> Building the package works for me. I'm going to upload a new revision
>> but I think this bug is already resolved.
> 
> Still happens for me, and also on the buildd:
> https://buildd.debian.org/status/fetch.php?pkg=osgi-foundation-ee=all=4.2.0-3=1522242580=0

Right. Apparently one of my chroots was not properly updated. This issue
is related to openjdk-9 bug

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8186841

However they only consider the error handling of javadoc a bug (not
exiting gracefully), the "bad class file" is another story.

AFAICS osgi-foundation-ee uses identical class names and the same
namespace as several classes in the java.base module (src/java/util) and
OpenJDK 9 does not like that. Maybe --add-modules java.base might work
in this case?

We could also do the following. The only reverse-dependency of this
package is osgi-compendium. It appears it requires only some specific
class files to build correctly (namely javax.microedition.io.*" If this
is true we could move those classes into osgi-compendium and remove
osgi-foundation-ee from Debian. One package less to support.



signature.asc
Description: OpenPGP digital signature

Bug#892861: libglm-dev: removal of default type initialization breaking packages

[Guus Sliepen]

tags 892861 - wontfix
thanks

On Wed, Mar 28, 2018 at 01:19:44PM +1300, Andrew Caudwell wrote:

> Upstream has implemented my suggestion to re-add default initialization as
> opt-in via a new define:
> 
> https://github.com/g-truc/glm/issues/735
> https://github.com/g-truc/glm/commit/8390a77b3a278b15259e5ca6e67f7e41badc457b
> 
> Could you apply the commit as a patch so maintainers can then define
> GLM_FORCE_CTOR_INIT and avoid having to modifying code?

Sure. However, I'm running into problems trying to apply the patch: it
doesn't apply cleanly on 0.9.9~a2, and if I just package the latest
revision from git, then I am getting internal compiler errors from GCC.
I can still compile 0.9.9~a2 without problems, so I will try to see if I
can just adapt the commit which adds GLM_FORCE_CTOR_INIT to 0.9.9~a2.

> Let me know as then I can then avoid having to embed the current release in
> my software.

Yeah, that would be less than optimal.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#894212: please add dragonboard 820c support

[Ricardo Salveti]

On Wed, Mar 28, 2018 at 10:32 AM, Riku Voipio  wrote:
> On Tue, Mar 27, 2018 at 01:52:46PM -0700, Vagrant Cascadian wrote:
>> On 2018-03-27, Riku Voipio wrote:
>> > I've created a merge request to add Dragonboard 820c support
>> > in debian u-boot build:
>> >
>> > https://salsa.debian.org/debian/u-boot/merge_requests/1
>>
>> Thanks!
>>
>> Have you read up on the rests for testers:
>>
>>   https://wiki.debian.org/U-boot
>
>> The only thing I'm unsure of about the pull request is why you removed
>> Ricardo Salveti as a tester for dragonboard410c?
>
> Ricardo, do you want to keep testing DB410c? I notice from IRC you are testing
> u-boot on DB820c as well ;)

Fine to replace me as tester.

I'm using u-boot on both, but not having too much time lately to test
with latest debian.

Cheers,
-- 
Ricardo Salveti de Araujo

Bug#894310: Please build the thunderbolt-net module

[Richard B. Kreckel]

Package: linux
Severity: wishlist
File: /boot/config-4.15.0-2-amd64
X-Debbugs-CC: sin...@nefkom.net

I'ld like to play-test the thunderbolt-net module.

Please consider enabling CONFIG_THUNDERBOLT_NET.

Thanks
   -richy.

Bug#887740: moon-buggy: Please bump the Debian part of the version number

[Christian T. Steigies]

Hi,
On Tue, Mar 27, 2018 at 09:06:56PM -0400, Jeremy Bicha wrote:
> On Tue, Feb 6, 2018 at 3:50 AM, Raphael Hertzog  wrote:
> > So I would also suggest to bump version to 1:1.0.51-12. Not for launchpad,
> > but for end users.
> 
> Christian, may I do an NMU now to bump the Debian revision number?

Has the debian policy been updated to document that skipping version numbers
is now required? Then I would do the upload myself.

But I can not stop you from doing a NMU for launchpad, I guess.

Christian

Bug#894309: update to version 1.0.1 (released Nov '17 on github)

[Sylwester Arabas]

Package: blitz++

Hello,

Blitz++ development has moved two years ago to github:
https://github.com/blitzpp/blitz

There have since been two releases:
- 1.0.0 on 29 Feb 2016,
- 1.0.1 on 2 Oct 2017

HTH,
Sylwester

Bug#893221: knopflerfish-osgi FTBFS with openjdk-9

[Felix Natter]

Adrian Bunk  writes:

> On Sat, Mar 24, 2018 at 11:35:48AM +0100, Felix Natter wrote:
>> hello Adrian,
>
> Hi Felix,

hello Adrian,

>> thank you very much for the report.
>> 
>> I am not sure that this is a Java9 issue, lookls more like some classes
>> (org.osgi.annotation.versioning.*) were dropped from a package I depend
>> on.
>
> the relevant change is that javadoc now gives errors instead of warnings 
> for some problems (often caused by incorrect/incomplete classpath).
>
> Fails with Java 9:
> /usr/lib/jvm/java-9-openjdk-amd64/bin/javadoc -locale en -encoding "UTF-8" 
> -sourcepath osgi/framework/src -d api -subpackages org.knopflerfish:org.osgi
>
> Works with Java 8:
> /usr/lib/jvm/java-8-openjdk-amd64/bin/javadoc -locale en -encoding "UTF-8" 
> -sourcepath osgi/framework/src -d api -subpackages org.knopflerfish:org.osgi

Many thanks for the explanation. Most errors are fixed by adding "-cp
/usr/share/java/osgi.annotation.jar".

The remaining problem is the Android (Dalvik) dependency (we build
without Android support):

Loading source files for package org.knopflerfish...
Loading source files for package org.osgi...
Constructing Javadoc information...
osgi/framework/src/org/knopflerfish/framework/bundlestorage/dex/DexArchive.java:47:
 error: package dalvik.system does not exist
import dalvik.system.DexFile;
^
osgi/framework/src/org/knopflerfish/framework/bundlestorage/dex/DexArchive.java:57:
 error: cannot find symbol
  private DexFile dexFile = null;
  ^
  symbol:   class DexFile
  location: class DexArchive
2 errors

I tried several variations of javadoc's -exclude parameter:

-exclude "org.knopflerfish.framework.bundlestorage.dex"
-exclude "org.knopflerfish.framework.bundlestorage.dex.DexArchive"
-exclude "org.knopflerfish.framework.bundlestorage.dex.*"
-exclude "org/knopflerfish/framework/bundlestorage/dex"
-exclude dalvik.system
[...]

Do you have an idea what I'm doing wrong? To me it looks like -exclude
is broken/ignored. If we can't fix the javadoc invocation, I suggest
to patch out DexArchive.java.
What do you think?

Many Thanks and Best Regards,
-- 
Felix Natter
debian/rules!

Bug#859130: [alb...@spenarnc.xs4all.nl: Re: Preferred source: a fundamental question was Re: - #859130 ITP: lina]

[Geert Stappers]

for the BTS
- Forwarded message from Albert van der Horst  
-

Date: Wed, 28 Mar 2018 13:24:03 +0200
From: Albert van der Horst 
To: Walter Landry , Geert Stappers 
Cc: debian-ment...@lists.debian.org
Subject: Re: Preferred source: a fundamental question was Re: - #859130 ITP: 
lina
User-Agent: XS4ALL Webmail

Walter Landry schreef op 2017-07-03 20:59:
> Albert van der Horst  wrote:
>> For those not versant with assembler. The binary that is generated is
>> supposed to be byte for byte the same with both assemblers. If not it
>> is a bug. The sources are equivalent, the binaries are the same, it
>> really is the same program.
>> 
>> Note, that I could not have told that I use an internal representation
>> and nobody could have guessed (nor benefited.)
>> 
>> So is the .s accepted as source conform Debian policies?
> 
> Unpopular or obscure source formats can still be the preferred source.
> Presumably you use this internal representation for a good reason.  If
> it helps you, it can help others.

As you may see in a separate post i've made an essentially larger upload
of lina, mainly to preempt legalistic reasons that would prevent
acceptance.

It contains the "obscure source format".

The basic idea is that in the main directory building is from the
assembler file, but it is a target build from an extract directory.
So there is still a clear separation between meta building and
final building where the final build is very simple.

More about the basic idea in
https://github.com/albertvanderhorst/ciforth/wiki/Philosophy-behind-ciforth

Note that the extract directory (even containing a small fraction of the
files in the generic system) can generate 2 source files in 4 assembler
formats. 6 of those 8 I've tested. Tinkering with configuration files
multiplies the number of possible generated files by 512.
Most of those assembler source program's won't work.

I invite mentors interested in the "preferred source" matter to check
whether they can agree that the package now complies with debian guide
lines.


> 
> Cheers,
> Walter Landry

-- 
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst

- End forwarded message -

-- 
Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#894221: nvme-cli: Got SIGSEGV when using --output-format=json with nvme list

[Breno Leitao]

Hi David,

On Tue, 27 Mar 2018 15:30:07 +0200 David Guyot
 wrote:

> While conducting trials using the nvme command, I noticed that the list
> argument produces SIGSEGV when used with --output-format=json, but not
> with --output-format=normal nor if this option is not specified: 
> 
> root@Alioth ~ {⌗0/⬓54}[0]꩜# nvme list --output-format=json
>   
> fish: 'nvme list --output-format=json' terminated by signal SIGSEGV
> (Erreur de frontière d'adresse)

Thanks. I found that this is already fixed on unstable branch, but it is
broken on older version.

I will find the commit that fixed it and cherry pick it back to version 1.0

Bug#888583: ltsp: ltsp-client-builder should use console-setup-udeb instead of kbd-chooser

[Holger Levsen]

On Wed, Mar 28, 2018 at 09:34:34AM -0700, Vagrant Cascadian wrote:
> On 2018-03-27, Holger Levsen wrote:
> > ping on this bug. If you'd agree, I'd also NMU ltsp with this change
> > only.
> I don't disagree, per se, but there are a few other issues that should
> also get resolved...
 
well, yes, always.

so I'll try to NMU this over the coming easterweekend, thanks.

> Honestly, LTSP development and maintenance in general could really use
> some extra hands. I don't currently maintain any real-world deployments
> of LTSP, so help from someone who actually does would be very
> appreciated.

file a RFH bug against ltsp? Unfortunatly I also dont have time for more
Debian commitments…


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#886049: The problem with the splice() depends on the used SMB-Version

[Reiny]

Since this Bug only appears if the file is copied from a CIFS-Share it 
now was seen that the error depends on the used SMB-Version. If the 
share is mounted with the option vers=2.0, small files can be copied 
without blocking. If a higher SMB-Version than 2.0 is used to mount the 
share, e.g. vers=2.1 or vers=3.0, the copy fails as described above. 
Capturing the network traffic with wireshark shows that the file is 
copied completely in both cases, but when the share is mounted in 
SMB-Version 2.1 the last 'Read Response' which contains all the data of 
the small file never stopps. The 'Close Request' and the 'Close 
Response' for the file do not come up until the hanging process is 
interrupted. Another difference betweent the Versions is that the 'Read 
Request' has 'Len:65536' in SMB-Version 2.1 and 'Len:4096' in 
SMB-Version 2.0. The 'Read Response' containing the data in both cases 
has the same size.

Bug#887846: libffado: may I upload a fix to #887846?

[Nicolas Boulenguez]

Hello.

A patch packaging last upstream release, updating the packaging,
removing the dependency on an orphaned package, fixing #834140,
#887846, and most probably #864717, has been availble for a while.

Who should I contact to review it, and/or allow an NMU?
Thanks.

Bug#894308: tftpd-hpa: Init script kills daemons in lxc containers too

[Matthew Gabeler-Lee]

Package: tftpd-hpa
Version: 5.2+20150808-1+b1
Severity: normal

The init script for tftpd-hpa kills any instances running in lxc containers
when stopping the service on the host machine.

Example:
Host: sudo service tftpd-hpa start
Guest: sudo service tftpd-hpa start
## all running now
Host: sudo service tftpd-hpa stop
Guest: sudo service tftpd-hpa status
## no longer running in the guest, host init script killed it!

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

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

Versions of packages tftpd-hpa depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u3
ii  libwrap0   7.6.q-26

tftpd-hpa recommends no packages.

Versions of packages tftpd-hpa suggests:
ii  pxelinux  3:6.03+dfsg-14.1+deb9u1

-- debconf information excluded

Bug#872894: [Pkg-javascript-devel] Bug#872894: node-policyfile: autopkgtests fail with nodejs 6

[Graham Inggs]

Control: severity -1 serious

Since the upload of nodejs 8.9.3, this warning has turned into a failure.
As far a I can tell, this package has no reverse-dependencies, should
it be considered for removal?

Bug#893923: nmu: libalien-wxwidgets-perl_0.69+dfsg-1 libwx-perl_1:0.9932-2

[Niko Tyni]

On Wed, Mar 28, 2018 at 08:29:38PM +0300, Niko Tyni wrote:

> So the rebuilt libalien-wxwidgets-perl has picked up wxwidgets 3.0.4
> and embedded that in the virtual package name that libwx-perl depends on.

And just in case somebody wonders why: the whole story is in #757855.
-- 
Niko

Bug#894272: Another test

[Er_Maqui]

Hi,

After another reinstall (uninstall & purge), with a clean database and
repository, same error trying to login.

All binaries from /usr/local/bin are deleted.

I've tried to uninstall 10.5.6 and installing clean 10.5.5+dfsg-3. Same
error.
 I don't know if this information can help you on this error.


Thanks,

https://maqui.darkbolt.net/
Linux registered user ~#363219
PGP keys avaiables at KeyServ. ID: 0x4233E9F2
Los hombres somos esclavos de la historia

Bug#894307: RFS: pgn2web/0.4-2 [ITA]

[Jose G. López]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "pgn2web":

* Package name: pgn2web
  Version : 0.4-2
  Upstream Author : William Hoggarth 
* URL : http://pgn2web.sourceforge.net/
* License : GPL-3+
  Section : web

It builds those binary packages:

  pgn2web - convert PGN chess game files into webpages

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pgn2web/pgn2web_0.4-2.dsc

Package development is on the following repo:

https://salsa.debian.org/josgalo-guest/pgn2web

Changes since the last upload:

pgn2web (0.4-2) unstable; urgency=medium

  * Set myself as Maintainer (Closes: #835308)
  * debian/compat: Upgrade to version 11.
  * debian/control:
- Bump to Standards-Version 4.1.3. No changes required.
- Use optional priority.
- Add Vcs-* fields pointing to Salsa.
  * debian/copyright: Convert to Machine-readable format.
  * debian/patches:
- compilation.patch: Add to fix compilation errors.
- makefile.patch: Add to enable hardening flags.
- install-location.patch: Move install location fix to makefile.patch.
  * debian/rules: Enable hardening flags and use verbose mode.
  * debian/watch: Add to track upstream releases.
  * Add and install a desktop file.

 -- Jose G. López   Wed, 28 Mar 2018 19:08:10 +0200

Thanks and regards,


pgpizXBK531FN.pgp
Description: PGP signature

Bug#894303: cinnamon-control-center: broken since 3.6

[Christoph Anton Mitterer]

Ah I see... :-)

Thanks for the prompt reply :-)


Cheers,
Chris.

Bug#893658: [pkg-cinnamon] Bug#893658: cinnamon: recommend smart-notifier

[Christoph Anton Mitterer]

On Wed, 2018-03-28 at 19:25 +0200, Fabio Fantoni wrote:
> I added gnome-disk-utility half year ago (in git) mainly for do
> operation on disk, see informations about ecc...
> About notification of disk failures I'll do some tests with broken
> hard disk to see how smart-notifier works but probably not in few
> days, if it works very well and without problems too I also think it
> could be very useful and I will ask maxy if possible to add it.

Thanks :)

The nice thing of smartd+some-notifyer over g-d-u would be that it's
probably much more flexible than the (presumably in the end
libatasmart-based) gnome-disk-utility.

Also, for smartmontools I'd know that it's pretty much kept up to date
with current disk models and quirks for them... not idea whether or not
libatasmart is as properly maintained as well.


Cheers,
Chris.

Bug#893923: nmu: libalien-wxwidgets-perl_0.69+dfsg-1 libwx-perl_1:0.9932-2

[Niko Tyni]

Control: reopen -1

On Wed, Mar 28, 2018 at 12:08:26AM +0200, Emilio Pozuelo Monfort wrote:
> On 23/03/18 20:26, Niko Tyni wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: binnmu
> > 
> > These are uninstallable in sid since the latest wxwidgets3.0 upload.
> > Could you please binNMU them?
> > 
> > nmu libalien-wxwidgets-perl_0.69+dfsg-1 . ANY . unstable . -m "Rebuild for 
> > wxwidgets3.0 3.0.4"
> 
> Scheduled.

Thanks!
 
> > nmu libwx-perl_1:0.9932-2 . ANY . unstable . -m "Rebuild for wxwidgets3.0 
> > 3.0.4"
> 
> I don't see libwx-perl having a strict dependency on wxwidgets. I suspect this
> will be fixed once libalien-wxwidgets-perl is rebuilt, please reopen and shout
> if not.

It's a chain via libalien-wxwidgets-perl.

Package: libwx-perl
Version: 1:0.9932-2
Depends: [...], wxperl-gtk2-3-0-3-uni-gcc-3-4

Package: libalien-wxwidgets-perl
Version: 0.69+dfsg-1
Provides: wxperl-gtk2-3-0-3-uni-gcc-3-4

Package: libalien-wxwidgets-perl
Version: 0.69+dfsg-1+b1
Provides: wxperl-gtk2-3-0-4-uni-gcc-3-4

So the rebuilt libalien-wxwidgets-perl has picked up wxwidgets 3.0.4
and embedded that in the virtual package name that libwx-perl depends on.

Sorry for not being explicit about this in my original request. Reopening.
-- 
Niko

Bug#894306: gnome-control-center: gnome display external monitor resolution higher than full hd freezes the system: only in 3.28

[geodeb]

Package: gnome-control-center
Version: 1:3.28.0-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation? connection of a 4k external monitor
   * What exactly did you do (or not do) that was effective (or
 ineffective)? until gnome 3.26 it was correctly detected. now it works
only on full hd resolution. higher resolutions cause the blackout of both the
displays and the only way out is to power off.
   * What was the outcome of this action? the system is unusable
   * What outcome did you expect instead?the correct resolution on both
displays

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



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

Kernel: Linux 4.15.0-2-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)
LSM: AppArmor: enabled

Versions of packages gnome-control-center depends on:
ii  accountsservice0.6.45-1
ii  apg2.2.3.dfsg.1-5
ii  colord 1.3.3-2
ii  desktop-file-utils 0.23-2
ii  gnome-control-center-data  1:3.28.0-1
ii  gnome-desktop3-data3.28.0-1
ii  gnome-settings-daemon  3.28.0-1
ii  gsettings-desktop-schemas  3.28.0-1
ii  libaccountsservice00.6.45-1
ii  libatk1.0-02.28.1-1
ii  libc6  2.27-2
ii  libcairo-gobject2  1.15.10-1
ii  libcairo2  1.15.10-1
ii  libcanberra-gtk3-0 0.30-6
ii  libcanberra0   0.30-6
ii  libcheese-gtk253.28.0-1
ii  libcheese8 3.28.0-1
ii  libclutter-1.0-0   1.26.2+dfsg-4
ii  libclutter-gtk-1.0-0   1.8.4-3
ii  libcolord-gtk1 0.1.26-2
ii  libcolord2 1.3.3-2
ii  libcups2   2.2.6-5
ii  libfontconfig1 2.12.6-0.1
ii  libgdk-pixbuf2.0-0 2.36.11-2
ii  libglib2.0-0   2.56.0-4
ii  libgnome-bluetooth13   3.28.0-2
ii  libgnome-desktop-3-17  3.28.0-1
ii  libgoa-1.0-0b  3.28.0-1
ii  libgoa-backend-1.0-1   3.28.0-1
ii  libgrilo-0.3-0 0.3.4-1
ii  libgtk-3-0 3.22.29-1
ii  libgtop-2.0-11 2.38.0-2
ii  libgudev-1.0-0 232-2
ii  libibus-1.0-5  1.5.17-3
ii  libkrb5-3  1.16-2
ii  libmm-glib01.7.990-1
ii  libnm0 1.10.6-2
ii  libnma01.8.10-2
ii  libpango-1.0-0 1.40.14-1
ii  libpangocairo-1.0-01.40.14-1
ii  libpolkit-gobject-1-0  0.105-18
ii  libpulse-mainloop-glib011.1-4
ii  libpulse0  11.1-4
ii  libpwquality1  1.4.0-2
ii  libsmbclient   2:4.7.4+dfsg-2
ii  libsoup2.4-1   2.62.0-1
ii  libupower-glib30.99.7-2
ii  libwacom2  0.29-1
ii  libwayland-server0 1.14.0-2
ii  libx11-6   2:1.6.5-1
ii  libxi6 2:1.7.9-1
ii  libxml22.9.4+dfsg1-6.1

Versions of packages gnome-control-center recommends:
ii  cracklib-runtime  2.9.2-5.1
ii  cups-pk-helper0.2.6-1+b1
ii  gkbd-capplet  3.26.0-3
ii  gnome-online-accounts 3.28.0-1
ii  gnome-user-docs   3.28.0-1
ii  gnome-user-share  3.18.3-3
ii  iso-codes 3.79-1
ii  libcanberra-pulse 0.30-6
ii  libnss-myhostname 238-3
ii  mousetweaks   3.12.0-4
ii  network-manager-gnome 1.8.10-2
ii  policykit-1   0.105-18
ii  pulseaudio-module-bluetooth   11.1-4
ii  realmd0.16.3-1
ii  rygel 0.36.1-1
ii  rygel-tracker 0.36.1-1
ii  system-config-printer-common  1.5.11-2

Versions of packages gnome-control-center suggests:
ii  gnome-packagekit 3.28.0-2
ii  gnome-software   3.28.0-1
ii  gstreamer1.0-pulseaudio  1.12.4-1+b1
pn  libcanberra-gtk-module   
ii  libcanberra-gtk3-module  0.30-6
ii  x11-xserver-utils7.7+8

-- no debconf information

Bug#893658: [pkg-cinnamon] Bug#893658: cinnamon: recommend smart-notifier

[Fabio Fantoni]

Il 28/03/2018 17:51, Christoph Anton Mitterer ha scritto:
> Hi.
>
> I've just noted that gnome-disk-utility, which cinnamon now recommends
> somewhere, claims (in it's README):
>> gsd-disk-utility-notify:
>> gnome-disk-utility notification plugin for GNOME Settings Daemon
>> Disk health failure notification (SMART status)
> Not sure if it really does that,... and I'd say smartd is way more
> powerful + handling low-level block device stuff is not really an areay
> where I'd consider GNOME to be highly qualified...
>
> Nevertheless,... you may consider it as a fix for this bug.
> smartmontools anyway suggest smart-notifier so everyone should be
> happy.
>
>
> However, I personally would feel better if the gsd-disk-utility package
> could be split up so that there's a package which does only the SMART
> notifying... it seems a bit scary, that the gnome-disks utility shows a
> GUI which seemingly allows to format partitions, edit fstab options and
> the like.
>
>
> Cheers,
> Chris.
>
I added gnome-disk-utility half year ago (in git) mainly for do
operation on disk, see informations about ecc...

About notification of disk failures I'll do some tests with broken hard
disk to see how smart-notifier works but probably not in few days, if it
works very well and without problems too I also think it could be very
useful and I will ask maxy if possible to add it.

Bug#878101: nemo: Nemo segfault on thumbnailing of a moved file over smb

[Zeljko Culek]

Hello,

@Fabio - I upgraded nemo with the patched version from you repo and 
haven't experienced the bug since then (been a week since the upgrade).

Bug#894305: package build-depends on legacy ruby2.3-dev

[Matthias Klose]

Package: src:ruby-debugger-ruby-core-source
Version: 1.3.8+ds-1
Severity: serious
Tags: sid buster patch

the package build-depends on legacy ruby2.3-dev which is going to be removed. Is
there are reason not to use the unversioned b-d?

patch at
http://launchpadlibrarian.net/362398716/ruby-debugger-ruby-core-source_1.3.8+ds-1_1.3.8+ds-1ubuntu1.diff.gz

Bug#826994: Updated Patch for 0.7.6-1

[Chris Zubrzycki]

Please, lets get this fixed and merged. sysvinit is still officially supported 
in debian, although it’s not required. Some of us still like our init systems 
to be just that, and of course zfs fully supports it as well. It’s a bit insane 
that we have to manually install the init files on every system ourselves, they 
could have at least been hidden in docs/ or something


-chris zubrzycki
- --
PGP ID: 0xA2ABC070
Fingerprint: 26B0 BA6B A409 FA83 42B3  1688 FBF9 8232 A2AB C070


"Sadly, text alone cannot convey the depths of my sarcasm."

Bug#891799: fixed in openssl1.0 1.0.2o-1

[Aurelien Jarno]

control: reopen 891799
thanks

On 2018-03-27 22:24, Sebastian Andrzej Siewior wrote:
> Source: openssl1.0
> Source-Version: 1.0.2o-1
> 
> We believe that the bug you reported is fixed in the latest version of
> openssl1.0, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 891...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Sebastian Andrzej Siewior  (supplier of updated 
> openssl1.0 package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> Format: 1.8
> Date: Tue, 27 Mar 2018 21:10:52 +0200
> Source: openssl1.0
> Binary: libssl1.0.2 libssl1.0-dev libcrypto1.0.2-udeb libssl1.0.2-udeb
> Architecture: source
> Version: 1.0.2o-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian OpenSSL Team 
> Changed-By: Sebastian Andrzej Siewior 
> Description:
>  libcrypto1.0.2-udeb - Secure Sockets Layer toolkit - libcrypto udeb (udeb)
>  libssl1.0-dev - Secure Sockets Layer toolkit - development files
>  libssl1.0.2 - Secure Sockets Layer toolkit - shared libraries
>  libssl1.0.2-udeb - ssl shared library - udeb (udeb)
> Closes: 891799
> Changes:
>  openssl1.0 (1.0.2o-1) unstable; urgency=medium
>  .
>* Add riscv64 (Closes: #891799).
>* New upstream version 1.0.2o:
>  - Fixes CVE-2018-0739 (Constructed ASN.1 types with a recursive 
> definition
>  could exceed the stack)

Thanks for merging the patch. Unfortunately it doesn't work as there is
a small typo in debian-targets.patch, causing the package to FTBFS [1].
The patch below should fix that. Note the extra space between
"$(SHLIB_MAJOR)" and ".\$(SHLIB_MINOR)".

Could you please apply this patch in the next upload?

Thanks,
Aurelien

[1] 
https://buildd.debian.org/status/fetch.php?pkg=openssl1.0=riscv64=1.0.2o-1=1522207078=0


diff -Nru openssl1.0-1.0.2o/debian/patches/debian-targets.patch 
openssl1.0-1.0.2o/debian/patches/debian-targets.patch
--- openssl1.0-1.0.2o/debian/patches/debian-targets.patch   2018-03-27 
21:08:35.0 +0200
+++ openssl1.0-1.0.2o/debian/patches/debian-targets.patch   2018-03-28 
18:06:52.0 +0200
@@ -63,7 +63,7 @@
 +"debian-powerpcspe","gcc:-DB_ENDIAN 
${debian_cflags}::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_RISC1 
DES_UNROLL:${ppc32_asm}:linux32:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
 +"debian-ppc64","gcc:-m64 -DB_ENDIAN 
${debian_cflags}::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK 
DES_RISC1 
DES_UNROLL:${ppc64_asm}:linux64:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
 +"debian-ppc64el","gcc:-m64 -DL_ENDIAN 
${debian_cflags}::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK 
DES_RISC1 
DES_UNROLL:${ppc64_asm}:linux64le:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
-+"debian-riscv64","gcc:-DL_ENDIAN 
${debian_cflags}::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK 
DES_RISC2 DES_UNROLL:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR) 
.\$(SHLIB_MINOR)",
++"debian-riscv64","gcc:-DL_ENDIAN 
${debian_cflags}::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK 
DES_RISC2 
DES_UNROLL:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
 +"debian-s390","gcc:-DB_ENDIAN ${debian_cflags}::-D_REENTRANT::-ldl:RC4_CHAR 
RC4_CHUNK DES_INT 
DES_UNROLL:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
 
 +"debian-s390x","gcc:-DB_ENDIAN 
${debian_cflags}::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK 
DES_INT 
DES_UNROLL:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
 +"debian-sh3",   "gcc:-DL_ENDIAN 
${debian_cflags}::-D_REENTRANT::-ldl:BN_LLONG:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",

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


signature.asc
Description: PGP signature

Bug#888583: ltsp: ltsp-client-builder should use console-setup-udeb instead of kbd-chooser

[Vagrant Cascadian]

On 2018-03-27, Holger Levsen wrote:
> ping on this bug. If you'd agree, I'd also NMU ltsp with this change
> only.

I don't disagree, per se, but there are a few other issues that should
also get resolved...

Honestly, LTSP development and maintenance in general could really use
some extra hands. I don't currently maintain any real-world deployments
of LTSP, so help from someone who actually does would be very
appreciated.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#894206: dxf2gcode: Traceback related to empty self.geo in polyline and lwpolyline

[Sebastian Reichel]

Hi,

On Tue, Mar 27, 2018 at 09:57:04AM -0600, Sebastian Kuzminsky wrote:
> Hi Sebastian, thanks for the bug report and the patches!  They look good to
> me at first glance, I will forward them upstream and if they agree I'll
> incorporate them into an updated debian package.
> 
> Do you have an example of a DXF file that fails before these patches and
> works after them?

One more note - I just checked upstream's ticket system and the
LwPolyline patch fixes the same issue, that is fixed by this
ticket/patch, but is a bit cleaner and shorter:

https://sourceforge.net/p/dxf2gcode/tickets/97/
https://sourceforge.net/p/dxf2gcode/sourcecode/ci/2bab0a200cd1643c54b6fdf5b54c3e84aee59946/

Thanks for taking care of this!

-- Sebastian


signature.asc
Description: PGP signature

Bug#893964: gdm3: System goes into suspend mode unless a user is logged in on the console.

[Simon McVittie]

On Sat, 24 Mar 2018 at 15:23:28 +, Russel Winder wrote:
> With the update to 3.28 a newly rebooted machine that starts GDM will suspend 
> after about 15 mins unless a
> user logs in to the console.

It's 20 minutes, and is a result of the defaults in gnome-settings-daemon
3.28 changing to comply with European and American power-saving
regulations.

> there appears to be no way of switching the GDM suspend behaviour off

There's currently no UI for it, but if you append this to
/etc/gdm3/greeter.dconf-defaults:

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

then reboot (or run "service gdm3 reload" as root), that should put the
GDM session back to the pre-3.28 behaviour. The values are in seconds,
with 0 meaning never; please adjust as needed.

smcv

Bug#893037: Add support for diffing docker-format containers

[Chris Lamb]

Juliana wrote:

> AFAIK, docker /images/ can be exported to tarballs. Not sure how human
> readable they are, but diffoscope can definitely work. (:> 

Indeed that would definitely work. However, the "REPL" for someone
doing this would inevitably involve someone scripting the export of
two images and then runnning diffoscope against them, instead of
simply knowing how to carve them out of, say, Docker to begin with.

This seems a little at odds with diffoscope's idea of making the
whole process of diffing two things much more usable.

Whilst my gut was initially against it, perhaps some kind of "magic"
paths (or URI scheme) would work here.

(Inspired by IRC conversation with Jon right now)


Best wishes,

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

Bug#894206: dxf2gcode: Traceback related to empty self.geo in polyline and lwpolyline

[Sebastian Reichel]

Hi,

On Tue, Mar 27, 2018 at 09:57:04AM -0600, Sebastian Kuzminsky wrote:
> Hi Sebastian, thanks for the bug report and the patches!  They look good to
> me at first glance, I will forward them upstream and if they agree I'll
> incorporate them into an updated debian package.
> 
> Do you have an example of a DXF file that fails before these patches and
> works after them?

I attached a file, that fails in lwpolyline. I got the polyline
traceback after slightly modifying it with librecad / playing
with DXF version and currently don't have it at hand anymore.

-- Sebastian
999
dxfrw 0.6.3
  0
SECTION
  2
HEADER
  9
$ACADVER
  1
AC1021
  9
$DWGCODEPAGE
  3
ANSI_1252
  9
$INSBASE
 10
0
 20
0
 30
0
  9
$EXTMIN
 10
-2.296212748401287e-16
 20
-21.25
 30
0
  9
$EXTMAX
 10
240
 20
108.353971
 30
0
  9
$LIMMIN
 10
0
 20
0
  9
$LIMMAX
 10
420
 20
297
  9
$ORTHOMODE
 70
0
  9
$REGENMODE
 70
1
  9
$FILLMODE
 70
1
  9
$QTEXTMODE
 70
0
  9
$MIRRTEXT
 70
0
  9
$LTSCALE
 40
1
  9
$ATTMODE
 70
0
  9
$TEXTSIZE
 40
2.5
  9
$TRACEWID
 40
15.68
  9
$TEXTSTYLE
  7
STANDARD
  9
$CLAYER
  8
0
  9
$CELTYPE
  6
BYLAYER
  9
$CECOLOR
 62
  256
  9
$CELTSCALE
 40
1
  9
$DISPSILH
 70
0
  9
$DIMSCALE
 40
1
  9
$DIMASZ
 40
2.5
  9
$DIMEXO
 40
0.625
  9
$DIMDLI
 40
3.75
  9
$DIMRND
 40
0
  9
$DIMDLE
 40
0
  9
$DIMEXE
 40
1.25
  9
$DIMTP
 40
0
  9
$DIMTM
 40
0
  9
$DIMTXT
 40
2.5
  9
$DIMCEN
 40
2.5
  9
$DIMTSZ
 40
0
  9
$DIMTOL
 70
0
  9
$DIMLIM
 70
0
  9
$DIMTIH
 70
0
  9
$DIMTOH
 70
0
  9
$DIMSE1
 70
0
  9
$DIMSE2
 70
0
  9
$DIMTAD
 70
1
  9
$DIMZIN
 70
8
  9
$DIMBLK
  1

  9
$DIMASO
 70
1
  9
$DIMSHO
 70
1
  9
$DIMPOST
  1

  9
$DIMAPOST
  1

  9
$DIMALT
 70
0
  9
$DIMALTD
 70
3
  9
$DIMALTF
 40
0.03937
  9
$DIMLFAC
 40
1
  9
$DIMTOFL
 70
1
  9
$DIMTVP
 40
0
  9
$DIMTIX
 70
0
  9
$DIMSOXD
 70
0
  9
$DIMSAH
 70
0
  9
$DIMBLK1
  1

  9
$DIMBLK2
  1

  9
$DIMSTYLE
  2
Standard
  9
$DIMCLRD
 70
0
  9
$DIMCLRE
 70
0
  9
$DIMCLRT
 70
0
  9
$DIMTFAC
 40
1
  9
$DIMGAP
 40
0.625
  9
$DIMJUST
 70
0
  9
$DIMSD1
 70
0
  9
$DIMSD2
 70
0
  9
$DIMTOLJ
 70
0
  9
$DIMTZIN
 70
8
  9
$DIMALTZ
 70
0
  9
$DIMALTTZ
 70
0
  9
$DIMUPT
 70
0
  9
$DIMDEC
 70
2
  9
$DIMTDEC
 70
2
  9
$DIMALTU
 70
2
  9
$DIMALTTD
 70
3
  9
$DIMTXSTY
  7
STANDARD
  9
$DIMAUNIT
 70
0
  9
$DIMADEC
 70
0
  9
$DIMALTRND
 40
0
  9
$DIMAZIN
 70
0
  9
$DIMDSEP
 70
   44
  9
$DIMATFIT
 70
3
  9
$DIMFRAC
 70
0
  9
$DIMLDRBLK
  1
STANDARD
  9
$DIMLUNIT
 70
2
  9
$DIMLWD
 70
   -2
  9
$DIMLWE
 70
   -2
  9
$DIMTMOVE
 70
0
  9
$DIMFXL
 40
1
  9
$DIMFXLON
 70
0
  9
$DIMJOGANG
 40
0.7854
  9
$DIMTFILL
 70
0
  9
$DIMTFILLCLR
 70
0
  9
$DIMARCSYM
 70
0
  9
$DIMLTYPE
  6

  9
$DIMLTEX1
  6

  9
$DIMLTEX2
  6

  9
$LUNITS
 70
2
  9
$LUPREC
 70
4
  9
$SKETCHINC
 40
1
  9
$FILLETRAD
 40
0
  9
$AUNITS
 70
0
  9
$AUPREC
 70
2
  9
$MENU
  1
.
  9
$ELEVATION
 40
0
  9
$PELEVATION
 40
0
  9
$THICKNESS
 40
0
  9
$LIMCHECK
 70
0
  9
$CHAMFERA
 40
0
  9
$CHAMFERB
 40
0
  9
$CHAMFERC
 40
0
  9
$CHAMFERD
 40
0
  9
$SKPOLY
 70
0
  9
$USRTIMER
 70
1
  9
$ANGBASE
 50
0
  9
$ANGDIR
 70
0
  9
$PDMODE
 70
   34
  9
$PDSIZE
 40
0
  9
$PLINEWID
 40
0
  9
$SPLFRAME
 70
0
  9
$SPLINETYPE
 70
2
  9
$SPLINESEGS
 70
8
  9
$HANDSEED
  5
2
  9
$SURFTAB1
 70
6
  9
$SURFTAB2
 70
6
  9
$SURFTYPE
 70
6
  9
$SURFU
 70
6
  9
$SURFV
 70
6
  9
$UCSBASE
  2

  9
$UCSNAME
  2

  9
$UCSORG
 10
0
 20
0
 30
0
  9
$UCSXDIR
 10
1
 20
0
 30
0
  9
$UCSYDIR
 10
0
 20
1
 30
0
  9
$UCSORTHOREF
  2

  9
$UCSORTHOVIEW
 70
0
  9
$UCSORGTOP
 10
0
 20
0
 30
0
  9
$UCSORGBOTTOM
 10
0
 20
0
 30
0
  9
$UCSORGLEFT
 10
0
 20
0
 30
0
  9
$UCSORGRIGHT
 10
0
 20
0
 30
0
  9
$UCSORGFRONT
 10
0
 20
0
 30
0
  9
$UCSORGBACK
 10
0
 20
0
 30
0
  9
$PUCSBASE
  2

  9
$PUCSNAME
  2

  9
$PUCSORG
 10
0
 20
0
 30
0
  9
$PUCSXDIR
 10
1
 20
0
 30
0
  9
$PUCSYDIR
 10
0
 20
1
 30
0
  9
$PUCSORTHOREF
  2

  9
$PUCSORTHOVIEW
 70
0
  9
$PUCSORGTOP
 10
0
 20
0
 30
0
  9
$PUCSORGBOTTOM
 10
0
 20
0
 30
0
  9
$PUCSORGLEFT
 10
0
 20
0
 30
0
  9
$PUCSORGRIGHT
 10
0
 20
0
 30
0
  9
$PUCSORGFRONT
 10
0
 20
0
 30
0
  9
$PUCSORGBACK
 10
0
 20
0
 30
0
  9
$USERI1
 70
0
  9
$USERI2
 70
0
  9
$USERI3
 70
0
  9
$USERI4
 70
0
  9
$USERI5
 70
0
  9
$USERR1
 40
0
  9
$USERR2
 40
0
  9
$USERR3
 40
0
  9
$USERR4
 40
0
  9
$USERR5
 40
0
  9
$WORLDVIEW
 70
1
  9
$SHADEDGE
 70
3
  9
$SHADEDIF
 70
   70
  9
$TILEMODE
 70
1
  9
$MAXACTVP
 70
   64
  9
$PINSBASE
 10
0
 20
0
 30
0
  9
$PLIMCHECK
 70
0
  9
$PEXTMIN
 10
0
 20
0
 30
0
  9
$PEXTMAX
 10
0
 20
0
 30
0
  9
$GRIDMODE
 70
0
  9
$SNAPSTYLE
 70
0
  9
$PLIMMIN
 10
0
 20
0
  9
$PLIMMAX
 10
297
 20
210
  9
$UNITMODE
 70
0
  9
$VISRETAIN
 70
1
  9
$PLINEGEN
 70
0
  9
$PSLTSCALE
 70
1
  9
$TREEDEPTH
 70
 3020
  9
$CMLSTYLE

Bug#894304: ITP: r-cran-manipulatewidgets -- GNU R package for more interactivity in interactive charts

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-manipulatewidgets
  Version : 0.9.0
  Upstream Author : Jalal-Edine Zawam, Francois Guillem, JJ Allaire, Marion 
Praz, Benoit Thieurmel, Titouan Robert and Duncan Murdoch
* URL or Web page : https://github.com/rte-antares-rpackage/manipulateWidget
* License : GPL-2+
  Description : GNU R package for more interactivity in interactive charts

This is a newly added Build-Depends of the package r-cran-rgl which has been
in Debian for fifteen year.

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#894303: cinnamon-control-center: broken since 3.6

[Christoph Anton Mitterer]

Package: cinnamon-control-center
Version: 3.6.5-1
Severity: grave
Justification: renders package unusable


Hi.

Since 3.6, when clicking on the control centre icon in the
"Start menu" the control centre doesn't start anymore.

When starting it manually via terminal:
$ cinnamon-control-center

All the usual submenus are missing and only the hardware
section with:
Color, Display, Graphics Tablet and Network
is shown.


Cheers,
Chris.

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

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

Versions of packages cinnamon-control-center depends on:
ii  accountsservice   0.6.45-1
ii  apg   2.2.3.dfsg.1-5
ii  cinnamon-control-center-data  3.6.5-1
ii  cinnamon-desktop-data 3.6.2-2
ii  cinnamon-settings-daemon  3.6.2-1
ii  desktop-file-utils0.23-2
ii  gettext   0.19.8.1-6
ii  gnome-online-accounts 3.28.0-1
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-2
ii  libcairo2 1.15.10-2
ii  libcinnamon-control-center1   3.6.5-1
ii  libcinnamon-desktop4  3.6.2-2
ii  libcinnamon-menu-3-0  3.6.0-1
ii  libcolord21.3.3-2
ii  libfontconfig12.12.6-0.1
ii  libgdk-pixbuf2.0-02.36.11-2
ii  libglib2.0-0  2.56.0-4
ii  libgnomekbd8  3.26.0-3
ii  libgoa-1.0-0b 3.28.0-1
ii  libgoa-backend-1.0-1  3.28.0-1
ii  libgtk-3-03.22.29-2
ii  libmm-glib0   1.7.990-1
ii  libnm01.10.6-2
ii  libnma0   1.8.10-2
ii  libnotify40.7.7-3
ii  libpango-1.0-01.42.0-1
ii  libpangocairo-1.0-0   1.42.0-1
ii  libpolkit-gobject-1-0 0.105-20
ii  libwacom2 0.29-1
ii  libx11-6  2:1.6.5-1
ii  libxi62:1.7.9-1
ii  libxklavier16 5.4-3
ii  xdg-utils 1.1.2-2

Versions of packages cinnamon-control-center recommends:
ii  cinnamon-l10n  3.6.4-1
ii  iso-codes  3.79-1
ii  mesa-utils 8.4.0-1
ii  mousetweaks3.12.0-4
ii  policykit-1-gnome  0.105-6

Versions of packages cinnamon-control-center suggests:
ii  x11-xserver-utils  7.7+8

-- no debconf information

Bug#893658: [pkg-cinnamon] Bug#893658: cinnamon: recommend smart-notifier

[Christoph Anton Mitterer]

Hi.

I've just noted that gnome-disk-utility, which cinnamon now recommends
somewhere, claims (in it's README):
>gsd-disk-utility-notify:
>gnome-disk-utility notification plugin for GNOME Settings Daemon
>Disk health failure notification (SMART status)

Not sure if it really does that,... and I'd say smartd is way more
powerful + handling low-level block device stuff is not really an areay
where I'd consider GNOME to be highly qualified...

Nevertheless,... you may consider it as a fix for this bug.
smartmontools anyway suggest smart-notifier so everyone should be
happy.


However, I personally would feel better if the gsd-disk-utility package
could be split up so that there's a package which does only the SMART
notifying... it seems a bit scary, that the gnome-disks utility shows a
GUI which seemingly allows to format partitions, edit fstab options and
the like.


Cheers,
Chris.

Bug#894211: xserver-xorg-video-nouveau: Screen frozen every few seconds for less than a second

[Sven Joachim]

On 2018-03-28 09:22 +0300, Stanimir Stoyanov wrote:

> The fact that I see the nouveau lnkctl speed error in the dmesg output
> makes me think it could be related. I've tried setting nomodeset in
> grub - the system boots, but after entering my credentials its showing
> only the gnome background image.
>
> I'm sorry if the cause is not in the driver, and will be grateful for
> any suggestions or directions where to look for the issue.

I'd start with the kernel.  Which was the last version that worked
correctly, and does the current version in testing (4.15.11) improve
things over the 4.14 kernel?

Cheers,
   Sven

Bug#894302: g++-7: Compiler generates wrong code with warning options

[Vadim Zeitlin]

Package: g++-7
Version: 7.3.0-12
Severity: important

This is an apparently impossible bug which nevertheless can be reliably
observed when using Debian versions of g++-7 and also i686-w64-mingw32-g++.
It consists in compiler generating different, and broken, code when
compiling the same input with only warning options -- which are, of course,
not supposed to affect the code generation at all -- added.

The upstream bug at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
contains several test cases. Using the one from
https://gcc.gnu.org/bugzilla/attachment.cgi?id=43774 it can be seen that
running

g++-7 -S -std=c++17 -O2 gcc-7.3-x86_64-linux.cpp -o nowarn.s

and

g++-7 -S -std=c++17 -O2 gcc-7.3-x86_64-linux.cpp -Wnonnull 
-Woverloaded-virtual -o warn.s

commands produces different assembly. Subsequently, Martin Liška has
created a further reduced test case which allows to reproduce the problem
using just "-O1 -Woverloaded-virtual", please see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091#c31

The bug is really mysterious but quite worrisome, as it results in broken
code being silently generated in practice and, worse, the generated code
oscillates between correct and broken versions when any, even apparently
completely unrelated, changes are made. Another interesting detail is that
using -fchecking=2 makes the bug disappear (but -fchecking does not).

Finally, please note that the bug doesn't seem to happen with the upstream
versions nor with g++ 7.2 from Fedora, so it's highly likely that it's due
to one of the Debian-specific patches, even if I really can't see anything
that could explain it in any of them.

Thanks in advance for any help with this!

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

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages g++-7 depends on:
ii  gcc-77.3.0-12
ii  gcc-7-base   7.3.0-12
ii  libc62.27-2
ii  libgmp10 2:6.1.2+dfsg-3
ii  libisl19 0.19-1
ii  libmpc3  1.1.0-1
ii  libmpfr6 4.0.1-1
ii  libstdc++-7-dev  7.3.0-12
ii  zlib1g   1:1.2.8.dfsg-5

g++-7 recommends no packages.

Versions of packages g++-7 suggests:
pn  g++-7-multilib
pn  gcc-7-doc 
pn  libstdc++6-7-dbg  

-- no debconf information


pgpvILPPlKYm4.pgp
Description: PGP signature

Bug#894061: guake refuses to work with sway/wayland

[Daniel Echeverry]

tags forwarded 894061 https://github.com/Guake/guake/issues/1219
thanks

-- 
Daniel Echeverry
http://wiki.debian.org/DanielEcheverry
http://rinconinformatico.net
Linux user: #477840
Debian user

Bug#894301: aptitude doesn't really work with '$sudo aptitude forget-new' the way I expect it to work.

[shirish शिरीष]

Package: aptitude
Version: 0.8.10-6
Severity: normal

Dear Maintainer,

Thank you for maintaining aptitude and would be eternally grateful for
the tool.

My query/bug maybe same/similar to perhaps #833310

I remember how aptitude used to work before.

a. Before updating the package lists I used to run

$ sudo aptitude forget-new

This used to forget all the new packages be a blank slate.

b. Then I used to run ' $ sudo apt update'

c. Then run '$ sudo aptitude search '~n'

and it used to only show the new packages which have come in because
of the update.

This behavior doesn't seem possible.


-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.10
Compiler: g++ 7.2.0
Compiled against:
  apt version 5.0.2
  NCurses version 6.0
  libsigc++ version: 2.10.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.1.20180127
  cwidget version: 0.5.17
  Apt version: 5.0.2

aptitude linkage:
linux-vdso.so.1 (0x7ffe25b2d000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
(0x7f8b73181000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7f8b72f51000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f8b72d27000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0
(0x7f8b72b2)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3
(0x7f8b72828000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
(0x7f8b7251d000)
libboost_iostreams.so.1.62.0 =>
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.62.0
(0x7f8b72305000)
libboost_filesystem.so.1.62.0 =>
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0
(0x7f8b720ec000)
libboost_system.so.1.62.0 =>
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0
(0x7f8b71ee8000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30
(0x7f8b71add000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f8b718bf000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f8b7153a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f8b711a7000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f8b70f8f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8b70bd5000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f8b709be000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f8b707a4000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f8b70594000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f8b7036e000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f8b7015c000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f8b6ff3e000)
/lib64/ld-linux-x86-64.so.2 (0x7f8b73b5)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f8b6fd3a000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f8b6fb32000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f8b6f92b000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common0.8.10-6
ii  libapt-pkg5.0  1.6~beta1
ii  libboost-filesystem1.62.0  1.62.0+dfsg-5
ii  libboost-iostreams1.62.0   1.62.0+dfsg-5
ii  libboost-system1.62.0  1.62.0+dfsg-5
ii  libc6  2.27-2
ii  libcwidget3v5  0.5.17-7
ii  libgcc11:8-20180321-1
ii  libncursesw5   6.1-1
ii  libsigc++-2.0-0v5  2.10.0-2
ii  libsqlite3-0   3.22.0-2
ii  libstdc++6 8-20180321-1
ii  libtinfo5  6.1-1
ii  libxapian301.4.5-1

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-12
ii  sensible-utils 0.0.12

Versions of packages aptitude suggests:
ii  apt-xapian-index0.49
pn  aptitude-doc-en | aptitude-doc  
ii  debtags 2.1.5
ii  tasksel 3.43

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#890266: (no subject)

[jfot]

Are there any news about this?

Bug#856179: ITP: polybar -- fast and easy-to-use status bar

[Antoine Beaupré]

On 2018-03-28 10:51:23, Antoine Beaupré wrote:
> Anyways, I guess that's an upstream problem as well, but it does seem
> like the default font provided in the example config file (Siji) is not
> in Debian, so that might be a nice addition. :)

For what it's worth, I managed to make polybar load the Siji font, but
only after installing a TrueType version of the font:

https://github.com/stark/siji/issues/8

But even then, the status bar is basically blank... Not sure what's
going on there, but I reverted back to i3bar for now, unfortunately.

-- 
The university must paint itself black, mulatto, worker anddd
peasant. If not, people will break down their doors and paint the
university the color they like.
- Ernesto "Che" Guevara

Bug#875821: [vagr...@debian.org] Re: [Ltsp-discuss] NFS stale filehandle in Debian 9

[Vagrant Cascadian]

On 2017-09-18, Matthew Wyneken wrote:
> I have now set up a new LTSP server running Debian 9 with a Debian 9
> client. The LTSP version is 5.5.9. I've been surprised at how easy the
> process has been, but now I've run into a problem that might be more
> difficult to solve.
...
> That no longer seems to be possible with 5.5.9. I've been getting NFS
> stale file handle messages basically every time I update the chroot,
> and the only way to fix this is to reboot the client. This is not an
> option for my installation.

It sounds like you've got a better working NFS setup than I managed to
get working...

In /usr/share/doc/ltsp-server/NEWS.Debian:

  LTSP defaults to using NBD in both ltsp-build-client and in
  ltsp-client-core, due to incompatibilities using overlay fs from linux
  4.x with NFS as a backend.


Another person reported similar issues:

  https://sourceforge.net/p/ltsp/mailman/message/36038589/
  https://bugs.debian.org/875821

It may be possible to switch to aufs by using the aufs-dkms package, as
aufs is what was used before stretch.

Another option would be fixing the way LTSP mounts using "overlay" fs,
as NFS + overlay fs is used by FAI apparently without issue. FAI uses
dracut instead of initramfs-tools, so that could be a path of further
investigation.


live well,
  vagrant

Bug#894300: Missing dependency: libmpfr-dev (included by libqalculate/Number.h)

[Maximiliano Curia]

Package: libqalculate-dev
Version: 2.2.1-1
Severity: important

Building plasma-workspace against the experimental version of qalculate causes 
plasma-workspace to FTBFS, due to the a missing dependency of libmpfr-dev in 
qalculate's -dev package.


Happy hacking,
--
"A computer program does what you tell it to do, not what you want it to do."
-- Greer's Law
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#893929: libqt4-dev-bin: kopete FTBFS

[Lisandro Damián Nicanor Pérez Meyer]

On 28 March 2018 at 11:42, Jiri Palecek  wrote:
> Hello,
>
>
> On 3/25/18 8:19 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
>>
>> Hi Jiri!
>>
>> El viernes, 23 de marzo de 2018 18:25:29 -03 Jiri Palecek escribió:
>>>
>>> Package: libqt4-dev-bin
>>> Version: 4:4.8.7+dfsg-13
>>> Severity: normal
>>> Tags: patch
>>> File: /usr/bin/moc-qt4
>>>
>>> Dear Maintainer,
>>>
>>> I tried to rebuild kopete from source and got errors such as these:
>>>
>>> Generating s5b.moc
>>>
>>> /mnt/extras/src/kopete-17.08.3/protocols/jabber/libiris/src/irisnet/noncore/
>>> cutestuff/bytestream.h:52: Parse error at "defined"
>>>
>>> Apparently this is caused by a nonconformity of moc's preprocessor which
>>> manifests itself when macro
>>>
>>> major(arg)
>>
>> I reember this was an issue some time ago. I went ahead and rebuilt
>> unstable's
>> kopete and did it without issues. So I wonder why unstable kopete builds
>> and
>> your build doesnt :-/
>
> I don't know, maybe it's the libc version ? (2.27-2)

I don't know.

>> For what it's worth, the next kopete version should be qt5 based.
>
>
> Yes, but that's assuming there won't be any need for rebuilds.

Maybe I was not clear enough in my last mail: I've rebuilt kopete with
an up-to-date unstable chroot without any issues.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#894299: RM: python-pybedtools -- ROM; No longer needed, only reverse build-dep has also been ROM'd

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal

Thanks!

Bug#894297: [PATCH] cyrus-sasl2: please add build-profile support

[Karsten Merker]

Package: cyrus-sasl2
Version: 2.1.27~101-g0780600+dfsg-3
Severity: wishlist
Tags: patch
X-Debbugs-CC: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

we are in the process of bootstrapping a Debian port for the
riscv64 architecture (https://wiki.debian.org/RISC-V). The
cyrus-sasl2 package is part of the build-dependency chain for the
essential package set, so we need to build it to be able to
complete the bootstrap process.

Cyrus-sasl2 is involved in a circular dependency chain whose
untangling requires building the package in multiple steps with
reduced functionality and reduced build-dependencies.  To achieve
that, debian/rules currently supports passing a number of options
(no-sql, no-ldap and no-gssapi) in $(DEB_BUILD_OPTIONS).  This
mechanism has the limitation that it requires manually adjusting the
build-dependency list based on the options set and makes it hard to
autobuild the package in a bootstrapping context.  The use of
build-profiles (https://wiki.debian.org/BuildProfileSpec) would make
this process quite a bit easier.  Attached is a patch that adds
build-profile support to the packge while keeping the original
$(DEB_BUILD_OPTIONS)-based mechanism in place.

The build profile names follow the "extension namespace" conventions
from the build profile specification:

DEB_BUILD_OPTIONS -> build-profile name
-
no-sql-> pkg.cyrus-sasl2.nosql
no-ldap   -> pkg.cyrus-sasl2.noldap
no-gssapi -> pkg.cyrus-sasl2.nogssapi

It would be very helpful for our bootstrapping efforts if you could
upload a version of the cyrus-sasl2 package with this patch applied to
unstable in the near future.  For a standard build the patch changes
nothing, so there should be no significant risk in applying it.

JFTR one thing that I have found while testing the patch: the three
options/profiles are in practice not completely independent from each
other.  The main purpose of the no-gssapi option is to remove the
dependency on kerberos, but if the package is built with SQL support
(i.e. pkg.cyrus-sasl2.nogssapi is set but pkg.cyrus-sasl2.nosql is
not), libpq5 by default pulls in krb5 nonetheless.  The same limitation
applies to the existing mechanism, so this isn't a regression compared
to what we have now.  It definitely makes sense to have separate
options/profiles for no-gssapi and no-sql though, as postgresql
supports a stage1 build without krb5 for bootstrapping purposes and in
this case they are really independent from each other.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
diff -Nur cyrus-sasl2-2.1.27~101-g0780600+dfsg.orig/debian/control cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/control
--- cyrus-sasl2-2.1.27~101-g0780600+dfsg.orig/debian/control
+++ cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/control
@@ -11,17 +11,17 @@
autotools-dev,
chrpath,
debhelper (>= 9),
-   default-libmysqlclient-dev | libmysqlclient-dev,
+   default-libmysqlclient-dev  | libmysqlclient-dev ,
dh-autoreconf,
docbook-to-man,
groff-base,
-   heimdal-multidev,
-   krb5-multidev,
+   heimdal-multidev ,
+   krb5-multidev ,
libdb-dev,
-   libkrb5-dev,
-   libldap2-dev,
+   libkrb5-dev ,
+   libldap2-dev ,
libpam0g-dev,
-   libpq-dev,
+   libpq-dev ,
libsqlite3-dev,
libssl-dev,
po-debconf,
@@ -119,6 +119,7 @@
 Depends: libsasl2-modules (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
+Build-Profiles: 
 Description: Cyrus SASL - pluggable authentication modules (LDAP)
  This is the Cyrus SASL API implementation, version 2.1. See package
  libsasl2-2 and RFC  for more information.
@@ -145,6 +146,7 @@
 Depends: libsasl2-modules (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
+Build-Profiles: 
 Description: Cyrus SASL - pluggable authentication modules (SQL)
  This is the Cyrus SASL API implementation, version 2.1. See package
  libsasl2-2 and RFC  for more information.
@@ -160,6 +162,7 @@
  ${misc:Depends},
  ${shlibs:Depends}
 Conflicts: libsasl2-modules-gssapi-heimdal
+Build-Profiles: 
 Description: Cyrus SASL - pluggable authentication modules (GSSAPI)
  This is the Cyrus SASL API implementation, version 2.1. See package
  libsasl2-2 and RFC  for more information.
@@ -189,6 +192,7 @@
  ${misc:Depends},
  ${shlibs:Depends}
 Conflicts: libsasl2-modules-gssapi-mit
+Build-Profiles: 
 Description: Pluggable Authentication Modules for SASL (GSSAPI)
  This is the 

Bug#894298: RM: python-gffutils -- ROM; No longer needed, no reverse-dependencies

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal

Thanks!

Bug#856179: ITP: polybar -- fast and easy-to-use status bar

[Antoine Beaupré]

On 2018-03-27 21:15:35, Jason Pleau wrote:
> Hi.
>
> I took a few hours last weekend to work on this.

Awesome, thanks for the work!

> While I was able to have "working" packages for both xpp and i3ipcpp,
> I could not get polybar to use them (the whole thing is glued together
> nicely it seems and trying to split them caused me headaches). So I
> went ahead and worked on packaging the whole repo (and submodules)
> together.

Can you expand on the problems you've encountered?

> Repo: https://salsa.debian.org/jpleau-guest/polybar
>
> Current status: it builds in a chroot and works on my sid install.

I have tried to build this in stretch and failed:

$ sbuild -c stretch
dh clean --buildsystem=cmake --builddirectory=build
   dh_auto_clean -O--buildsystem=cmake -O--builddirectory=build
   dh_autoreconf_clean -O--buildsystem=cmake -O--builddirectory=build
   dh_clean -O--buildsystem=cmake -O--builddirectory=build
dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream 
tarball found at ../polybar_3.1.0.orig.tar.{bz2,gz,lzma,xz}
E: Failed to package source directory /home/anarcat/dist/polybar
1$ uscan
uscan warn: No watch file found
1$ gbp buildpackage -c stretch
dh clean --buildsystem=cmake --builddirectory=build
   dh_auto_clean -O--buildsystem=cmake -O--builddirectory=build
   dh_autoreconf_clean -O--buildsystem=cmake -O--builddirectory=build
   dh_clean -O--buildsystem=cmake -O--builddirectory=build
gbp:error: upstream/3.1.0 is not a valid treeish

So a few things here:

 * a debian/watch file would be useful, even if just to find out new
   versions are coming out...
 * the upstream tree should be tagged
 
When those are fixed, I get this:

 sbuild-build-depends-polybar-dummy : Depends: debhelper (>= 11) but it is not 
going to be installed

So it might also be useful to make the DH dependency >= 11~ to allow for
easier backporting. I can send a merge request for that on Salsa (or a
patch here) if you want.

> TODO:
>
> - There's a few copyright info missing (ie: lib/concurrentqueue)-

Seems to be 2-clause BSD.

> - After installing the package, it won't do anything because the config
> file is not found (it should be in $HOME/.config/polybar). There is one
> shipped in /usr/share/doc/polybar/config.gz, but surely there's a way to
> tell the users that when they install the package?

/usr/share/doc/polybar/README.Debian is usually where I would expect
that kind of information to be, or in the manpage, or in the error
message directly.. Also, I would expect to find the config.gz file in an
examples/ subdirectory there.

Maybe a more long-term solution would be to ship the sample config file
in /etc/polybar/config and patch the package to look for there on top of
$XDG_CONFIG_HOME. The proper place to look for those is XDG_CONFIG_DIRS,
which defaults to /etc/xdg, which I've always found weird. See this spec
for details:

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

> Note that I made a custom get-orig-source rule. The tarball didn't
> contain xpp and i3ipcpp (github generated tarballs don't include
> submodules). It seems to work fine, feedback welcome on this one..

hmm... that does look kind of nasty. :p Why is the version number
hardcoded in $GIT_VER? Why not just use DEB_VERSION_UPSTREAM there?

It's fine for testing now, but I doubt this tarball would pass NEW: we'd
need to split it into those three packages, probably...?

Also: when we mess around with the tarballs like this, we usually tag
the upstream version number accordingly, say with "+dfsg1" or
something. In this case, it's not because of the DFSG, but still - we
shouldn't make this package look like upstream, otherwise it brings
confusion to the ecosystem, because the checksums don't match
upstream.

At the very least, this stuff should be documented in debian/README.source.

Final nitpicks on the package:

 * the changelog should close this ITP
 * please follow DEP3 patch tagging guidelines to explain if patches
   were sent back upstream, if so where, and if not why. :)

   http://dep.debian.net/deps/dep3/

Also, I am having trouble making the thing work meaningfully. It seems
it requires quite a bit of configuration... Here's what the default
config gives me by default:

warn: No monitor specified, using "DP1"
error: Disabling module "bspwm" (reason: Could not find socket: 
/tmp/bspwm_0_0-socket)
error: module/xbacklight: Could not get data (err: XCB_NAME (15))
error: Disabling module "xbacklight" (reason: Not supported for "DP1")
error: Disabling module "wlan" (reason: Invalid network interface "net1")
error: Disabling module "battery" (reason: No suitable way to get current 
charge state)
warn: Systray selection already managed (window=0x30c)
warn: Dropping unmatched character  (U+e096)
warn: Dropping unmatched character  (U+e099)
warn: Dropping unmatched character  (U+e09a)
warn: Dropping unmatched character  (U+e09c)
warn: Dropping unmatched character  (U+e26f)
warn: 

Bug#880133: firefox-esr: double-sided print-out is no longer working

[Dominik Mies]

Dear Maintainer,

We have the same problem, aand investigated a bit:

Running Firefox or Thunderbird as en_US.UTF-8 allows us to print double 
sideded, however, this changes the paper format to Letter.

Duplex printing fails with other locales, e.g. de_DE, fr_FR or en_GB.

Yours,

Dominik Mies
IT, Mathematical Institute of the University of Bonn

Bug#893929: libqt4-dev-bin: kopete FTBFS

[Jiri Palecek]

Hello,


On 3/25/18 8:19 PM, Lisandro Damián Nicanor Pérez Meyer wrote:

Hi Jiri!

El viernes, 23 de marzo de 2018 18:25:29 -03 Jiri Palecek escribió:

Package: libqt4-dev-bin
Version: 4:4.8.7+dfsg-13
Severity: normal
Tags: patch
File: /usr/bin/moc-qt4

Dear Maintainer,

I tried to rebuild kopete from source and got errors such as these:

Generating s5b.moc
/mnt/extras/src/kopete-17.08.3/protocols/jabber/libiris/src/irisnet/noncore/
cutestuff/bytestream.h:52: Parse error at "defined"

Apparently this is caused by a nonconformity of moc's preprocessor which
manifests itself when macro

major(arg)

I reember this was an issue some time ago. I went ahead and rebuilt unstable's
kopete and did it without issues. So I wonder why unstable kopete builds and
your build doesnt :-/

I don't know, maybe it's the libc version ? (2.27-2)

For what it's worth, the next kopete version should be qt5 based.


Yes, but that's assuming there won't be any need for rebuilds.

Regards

    Jiri Palecek

Bug#893332: ghostscript: Ghostscript cannot find Resource directory

[Brian Potkin]

On Wed 28 Mar 2018 at 07:45:15 +0200, Jean-Philippe MENGUAL wrote:

> It was my dame: for space save, I copied /usr/share/ghostscript on
> another partition and created a symlink from /usr/share/ghostscript to
> the new location. And it does not work, that is gs command requires the
> folder exists in /usr/share, and not a symlink.

Great work, Jean-Philippe. Many thanks for your investigations and
persistence. I think upstream Ghostscript support was exemplary.

Happy Printing,

Brian.

Bug#894296: lasso: Add symbols file for liblasso3 shared library

[Corey Bryant]

Package: lasso
Version: 2.5.0-5
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/liblasso3.symbols. Add symbols file for liblasso3 shared library.


In the future the symbols file can be updated by following the steps at:
https://wiki.debian.org/UsingSymbolsFiles.

Thanks for considering the patch.


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

Kernel: Linux 4.15.0-12-generic (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)
LSM: AppArmor: enabled
diff -Nru lasso-2.5.0/debian/liblasso3.symbols 
lasso-2.5.0/debian/liblasso3.symbols
--- lasso-2.5.0/debian/liblasso3.symbols1969-12-31 19:00:00.0 
-0500
+++ lasso-2.5.0/debian/liblasso3.symbols2018-03-28 10:18:14.0 
-0400
@@ -0,0 +1,560 @@
+liblasso.so.3 liblasso3 #MINVER#
+ lasso_assertion_query_add_attribute_request@Base 2.3.5
+ lasso_assertion_query_build_request_msg@Base 2.3.5
+ lasso_assertion_query_build_response_msg@Base 2.3.5
+ lasso_assertion_query_destroy@Base 2.3.5
+ lasso_assertion_query_get_request_type@Base 2.3.5
+ lasso_assertion_query_get_type@Base 2.3.5
+ lasso_assertion_query_init_request@Base 2.3.5
+ lasso_assertion_query_new@Base 2.3.5
+ lasso_assertion_query_process_request_msg@Base 2.3.5
+ lasso_assertion_query_process_response_msg@Base 2.3.5
+ lasso_assertion_query_validate_request@Base 2.3.5
+ lasso_build_unique_id@Base 2.3.5
+ lasso_check_version@Base 2.3.5
+ lasso_defederation_build_notification_msg@Base 2.3.5
+ lasso_defederation_destroy@Base 2.3.5
+ lasso_defederation_get_type@Base 2.3.5
+ lasso_defederation_init_notification@Base 2.3.5
+ lasso_defederation_new@Base 2.3.5
+ lasso_defederation_process_notification_msg@Base 2.3.5
+ lasso_defederation_validate_notification@Base 2.3.5
+ lasso_ds_key_info_get_type@Base 2.3.5
+ lasso_ds_key_info_new@Base 2.3.5
+ lasso_ds_key_value_get_type@Base 2.3.5
+ lasso_ds_key_value_get_x509_data@Base 2.5.0
+ lasso_ds_key_value_new@Base 2.3.5
+ lasso_ds_key_value_set_x509_data@Base 2.5.0
+ lasso_ds_rsa_key_value_get_type@Base 2.3.5
+ lasso_ds_rsa_key_value_new@Base 2.3.5
+ lasso_ds_x509_data_get_certificate@Base 2.5.0
+ lasso_ds_x509_data_get_crl@Base 2.5.0
+ lasso_ds_x509_data_get_subject_name@Base 2.5.0
+ lasso_ds_x509_data_get_type@Base 2.5.0
+ lasso_ds_x509_data_new@Base 2.5.0
+ lasso_ds_x509_data_set_certificate@Base 2.5.0
+ lasso_ds_x509_data_set_crl@Base 2.5.0
+ lasso_ds_x509_data_set_subject_name@Base 2.5.0
+ lasso_ecp_destroy@Base 2.3.5
+ lasso_ecp_get_endpoint_url_by_entity_id@Base 2.5.0
+ lasso_ecp_get_type@Base 2.3.5
+ lasso_ecp_has_sp_idplist@Base 2.5.0
+ lasso_ecp_is_idp_entry_known_idp_supporting_ecp@Base 2.5.0
+ lasso_ecp_is_provider_in_sp_idplist@Base 2.5.0
+ lasso_ecp_new@Base 2.3.5
+ lasso_ecp_process_authn_request_msg@Base 2.5.0
+ lasso_ecp_process_response_msg@Base 2.5.0
+ lasso_ecp_process_sp_idp_list@Base 2.5.0
+ lasso_ecp_relay_state_get_type@Base 2.5.0
+ lasso_ecp_relay_state_new@Base 2.5.0
+ lasso_ecp_relay_state_validate@Base 2.5.0
+ lasso_ecp_request_get_type@Base 2.5.0
+ lasso_ecp_request_new@Base 2.5.0
+ lasso_ecp_request_validate@Base 2.5.0
+ lasso_ecp_response_get_type@Base 2.5.0
+ lasso_ecp_response_new@Base 2.5.0
+ lasso_ecp_response_validate@Base 2.5.0
+ lasso_ecp_set_known_sp_provided_idp_entries_supporting_ecp@Base 2.5.0
+ lasso_federation_build_local_name_identifier@Base 2.3.5
+ lasso_federation_destroy@Base 2.3.5
+ lasso_federation_get_type@Base 2.3.5
+ lasso_federation_new@Base 2.3.5
+ lasso_federation_verify_name_identifier@Base 2.3.5
+ lasso_flag_add_signature@Base 2.3.5
+ lasso_flag_memory_debug@Base 2.3.5
+ lasso_flag_sign_messages@Base 2.3.5
+ lasso_flag_strict_checking@Base 2.3.5
+ lasso_flag_thin_sessions@Base 2.5.0
+ lasso_flag_verify_signature@Base 2.3.5
+ lasso_get_prefix_for_dst_service_href@Base 2.3.5
+ lasso_get_prefix_for_idwsf2_dst_service_href@Base 2.3.5
+ lasso_identity_destroy@Base 2.3.5
+ lasso_identity_dump@Base 2.3.5
+ lasso_identity_get_federation@Base 2.3.5
+ lasso_identity_get_type@Base 2.3.5
+ lasso_identity_new@Base 2.3.5
+ lasso_identity_new_from_dump@Base 2.3.5
+ lasso_init@Base 2.3.5
+ lasso_key_get_type@Base 2.5.0
+ lasso_key_new_for_signature_from_base64_string@Base 2.5.0
+ lasso_key_new_for_signature_from_file@Base 2.5.0
+ lasso_key_new_for_signature_from_memory@Base 2.5.0
+ lasso_key_query_sign@Base 2.5.0
+ lasso_key_query_verify@Base 2.5.0
+ lasso_key_saml2_xml_sign@Base 2.5.0
+ lasso_key_saml2_xml_verify@Base 2.5.0
+ lasso_lecp_build_authn_request_envelope_msg@Base 2.3.5
+ lasso_lecp_build_authn_request_msg@Base 2.3.5
+ 

Bug#894295: ca-certificates fails to install: Execution of /usr/bin/c_rehash aborted due to compilation errors

[Michael Shuler]

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

This appears to be a bug in openssl with a new version to address the
regression.

-- 
Kind regards,
Michael

On 03/28/2018 09:07 AM, Helmut Grohne wrote:
> Package: ca-certificates
> Version: 20170717
> Severity: grave
> Justification: fails to install
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> In a fresh sid amd64 chroot:
> 
> # apt-get install ca-certificates
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following additional packages will be installed:
>   libssl1.1 openssl
> The following NEW packages will be installed:
>   ca-certificates libssl1.1 openssl
> 0 upgraded, 3 newly installed, 0 to remove and 22 not upgraded.
> Need to get 2274 kB of archives.
> After this operation, 5394 kB of additional disk space will be used.
> Do you want to continue? [Y/n]
> Get:1 http://ftp.stw-bonn.de/debian sid/main amd64 libssl1.1 amd64 1.1.0h-1 
> [1352 kB]
> Get:2 http://ftp.stw-bonn.de/debian sid/main amd64 openssl amd64 1.1.0h-1 
> [744 kB]
> Get:3 http://ftp.stw-bonn.de/debian sid/main amd64 ca-certificates all 
> 20170717 [178 kB]
> Fetched 2274 kB in 2s (1181 kB/s)
> debconf: delaying package configuration, since apt-utils is not installed
> Selecting previously unselected package libssl1.1:amd64.
> (Reading database ... 10089 files and directories currently installed.)
> Preparing to unpack .../libssl1.1_1.1.0h-1_amd64.deb ...
> Unpacking libssl1.1:amd64 (1.1.0h-1) ...
> Selecting previously unselected package openssl.
> Preparing to unpack .../openssl_1.1.0h-1_amd64.deb ...
> Unpacking openssl (1.1.0h-1) ...
> Selecting previously unselected package ca-certificates.
> Preparing to unpack .../ca-certificates_20170717_all.deb ...
> Unpacking ca-certificates (20170717) ...
> Processing triggers for libc-bin (2.27-2) ...
> Setting up libssl1.1:amd64 (1.1.0h-1) ...
> Setting up openssl (1.1.0h-1) ...
> Setting up ca-certificates (20170717) ...
> Updating certificates in /etc/ssl/certs...
> Unknown regexp modifier "/b" at /usr/bin/c_rehash line 15, at end of line
> Unknown regexp modifier "/W" at /usr/bin/c_rehash line 26, at end of line
> Unknown regexp modifier "/3" at /usr/bin/c_rehash line 26, at end of line
> Unknown regexp modifier "/2" at /usr/bin/c_rehash line 26, at end of line
> No such class installdir at /usr/bin/c_rehash line 58, near "Prefix our 
> installdir"
>   (Might be a runaway multi-line // string starting on line 26)
> syntax error at /usr/bin/c_rehash line 58, near "Prefix our installdir"
> Can't redeclare "my" in "my" at /usr/bin/c_rehash line 63, near "my"
> Execution of /usr/bin/c_rehash aborted due to compilation errors.
> dpkg: error processing package ca-certificates (--configure):
>  installed ca-certificates package post-installation script subprocess 
> returned error exit status 255
> Processing triggers for libc-bin (2.27-2) ...
> Errors were encountered while processing:
>  ca-certificates
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> #
> 
> Helmut
> 

Bug#894295: ca-certificates fails to install: Execution of /usr/bin/c_rehash aborted due to compilation errors

[Helmut Grohne]

Package: ca-certificates
Version: 20170717
Severity: grave
Justification: fails to install
User: helm...@debian.org
Usertags: rebootstrap

In a fresh sid amd64 chroot:

# apt-get install ca-certificates
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libssl1.1 openssl
The following NEW packages will be installed:
  ca-certificates libssl1.1 openssl
0 upgraded, 3 newly installed, 0 to remove and 22 not upgraded.
Need to get 2274 kB of archives.
After this operation, 5394 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ftp.stw-bonn.de/debian sid/main amd64 libssl1.1 amd64 1.1.0h-1 
[1352 kB]
Get:2 http://ftp.stw-bonn.de/debian sid/main amd64 openssl amd64 1.1.0h-1 [744 
kB]
Get:3 http://ftp.stw-bonn.de/debian sid/main amd64 ca-certificates all 20170717 
[178 kB]
Fetched 2274 kB in 2s (1181 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package libssl1.1:amd64.
(Reading database ... 10089 files and directories currently installed.)
Preparing to unpack .../libssl1.1_1.1.0h-1_amd64.deb ...
Unpacking libssl1.1:amd64 (1.1.0h-1) ...
Selecting previously unselected package openssl.
Preparing to unpack .../openssl_1.1.0h-1_amd64.deb ...
Unpacking openssl (1.1.0h-1) ...
Selecting previously unselected package ca-certificates.
Preparing to unpack .../ca-certificates_20170717_all.deb ...
Unpacking ca-certificates (20170717) ...
Processing triggers for libc-bin (2.27-2) ...
Setting up libssl1.1:amd64 (1.1.0h-1) ...
Setting up openssl (1.1.0h-1) ...
Setting up ca-certificates (20170717) ...
Updating certificates in /etc/ssl/certs...
Unknown regexp modifier "/b" at /usr/bin/c_rehash line 15, at end of line
Unknown regexp modifier "/W" at /usr/bin/c_rehash line 26, at end of line
Unknown regexp modifier "/3" at /usr/bin/c_rehash line 26, at end of line
Unknown regexp modifier "/2" at /usr/bin/c_rehash line 26, at end of line
No such class installdir at /usr/bin/c_rehash line 58, near "Prefix our 
installdir"
  (Might be a runaway multi-line // string starting on line 26)
syntax error at /usr/bin/c_rehash line 58, near "Prefix our installdir"
Can't redeclare "my" in "my" at /usr/bin/c_rehash line 63, near "my"
Execution of /usr/bin/c_rehash aborted due to compilation errors.
dpkg: error processing package ca-certificates (--configure):
 installed ca-certificates package post-installation script subprocess returned 
error exit status 255
Processing triggers for libc-bin (2.27-2) ...
Errors were encountered while processing:
 ca-certificates
E: Sub-process /usr/bin/dpkg returned an error code (1)
#

Helmut

Bug#894111: liferea: quits on startup with "Trace trap"

[Andreas Ronnquist]

Control: severity normal
thanks 

I found that it simply was my system that was wrong - For some reason I
had an empty GSETTINGS_SCHEMA_DIR, and doing

export GSETTINGS_SCHEMA_DIR=/usr/share/glib-2.0/schemas/

before running again removes the error completely. However, one could
think that the program shouldn't break like this. Lowering the
severity, I don't really see a reason to keep the package out of testing
because of this any longer.

-- Andreas Rönnquist
gus...@debian.org