Bug#894278: src:libdatrie: Please add trie_state_get_terminal_data() which is needed in python-datrie
On Thu, Mar 29, 2018 at 11:31 AM, Theppitak Karoonboonyanan wrote: > 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. Update: After reading the patch again, I think I got another point: trie_state_get_data() fails when s->is_suffix is FALSE, which the proposed trie_state_get_terminal_data() tries to address. So, I've fixed the issue in trie_state_get_data() instead: https://github.com/tlwg/libdatrie/commit/d1dfdb831093892541cae46eba82c46aec94f726 I'll also inform Filip to check this out before releasing a new upstream version. Best regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/
Bug#894324: gnudatalanguage ftbfs on ppc64el, mips and mipsel
Package: src:gnudatalanguage Version: 0.9.8-1 Severity: serious Tags: sid buster see https://buildd.debian.org/status/package.php?p=gnudatalanguage [ 11%] Building CXX object src/CMakeFiles/gnudatalanguage.dir/basic_fun.cpp.o cd /<>/obj-powerpc64le-linux-gnu/src && /usr/bin/c++ -DHAVE_CONFIG_H -DWXUSINGDLL -D_FILE_OFFSET_BITS=64 -D__WXGTK__ -Dgnudatalanguage_EXPORTS -I/usr/include/GraphicsMagick -I/usr/lib/powerpc64le-linux-gnu/wx/include/gtk2-unicode-3.0 -I/usr/include/wx-3.0 -I/usr/include/hdf5/serial -I/usr/include/hdf -I/usr/include/python2.7 -I/usr/lib/python2.7/dist-packages/numpy/core/include -I/usr/include/eigen3 -I/<> -I/<>/obj-powerpc64le-linux-gnu -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -DBUILD_DATE="\"Mar 27 2018\"" -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fopenmp -o CMakeFiles/gnudatalanguage.dir/basic_fun.cpp.o -c /<>/src/basic_fun.cpp In file included from /<>/src/basic_fun.cpp:3936:0: /<>/src/medianfilter.cpp: In function 'void lib::fastmedian::histogram_add(const uint16_t*, uint16_t*)': /<>/src/medianfilter.cpp:676:14: error: missing template arguments before 'unsigned' *(vector unsigned short*) &y[0] = vec_add( *(vector unsigned short*) &y[0], *(vector unsigned short*) &x[0] ); ^~~~ /<>/src/medianfilter.cpp:676:14: error: expected ')' before 'unsigned' /<>/src/medianfilter.cpp:677:14: error: missing template arguments before 'unsigned' *(vector unsigned short*) &y[8] = vec_add( *(vector unsigned short*) &y[8], *(vector unsigned short*) &x[8] ); ^~~~ /<>/src/medianfilter.cpp:677:14: error: expected ')' before 'unsigned' /<>/src/medianfilter.cpp: In function 'void lib::fastmedian::histogram_sub(const uint16_t*, uint16_t*)': /<>/src/medianfilter.cpp:710:14: error: missing template arguments before 'unsigned' *(vector unsigned short*) &y[0] = vec_sub( *(vector unsigned short*) &y[0], *(vector unsigned short*) &x[0] ); ^~~~ /<>/src/medianfilter.cpp:710:14: error: expected ')' before 'unsigned' /<>/src/medianfilter.cpp:711:14: error: missing template arguments before 'unsigned' *(vector unsigned short*) &y[8] = vec_sub( *(vector unsigned short*) &y[8], *(vector unsigned short*) &x[8] ); ^~~~ /<>/src/medianfilter.cpp:711:14: error: expected ')' before 'unsigned' make[3]: *** [src/CMakeFiles/gnudatalanguage.dir/build.make:426: src/CMakeFiles/gnudatalanguage.dir/basic_fun.cpp.o] Error 1 make[3]: Leaving directory '/<>/obj-powerpc64le-linux-gnu'
Bug#642072: python3-gobject: python3 crashes randomly when invoking Gtk.Menu.popup with Gtk.StatusIcon.position_menu
On Mon, 19 Sep 2011 16:17:49 +0800 Guanhao Yin wrote: > While test.py works with python 2, it crashes randomly with python > 3. Thus there is very likely to be a bug in python3-gobject. I can't reproduce with the current version. Is this still a problem?
Bug#890485: xserver-xorg-core 1.19.6 crash
There were a number of questions asked in my previous post that can help debug this. I can't see any of them answered. Since I can't reproduce it with my setup these are crucial for resolving this. /Thomas > > > > +CC Thomas . > > This is still broken, any news ? > > -- > Best regards, > Marek Vasut > >
Bug#894323: [Pkg-deepin-devel] Bug#894323: deepin terminal lacks wayland support
On Thu 03/29 05:04, Lumin wrote: > 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, > > ___ > Pkg-deepin-devel mailing list > pkg-deepin-de...@lists.alioth.debian.org > https://lists.alioth.debian.org/mailman/listinfo/pkg-deepin-devel we currently have no plan to add support for wayland, sorry. -- Yanhao Mo signature.asc Description: PGP signature
Bug#893030: closed by Bastien Roucariès (Bug#893030: fixed in imagemagick 8:6.9.9.39+dfsg-1)
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#894323: deepin terminal lacks wayland support
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#893759: variety: launching variety gives quite a few python 2.7 warnings
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#894322: cifs-utils: Please remove myself from Uploaders
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-- 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 a/glm/detail/type_mat2x3.hpp b/glm/detail/type_mat2x3.hpp index 657f5fd8..0f4b43ad 100644 --- a/glm/detail/t
Bug#894163: RFS: streamlink/0.11.0+dfsg-1~bpo9+1
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
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)
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
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
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
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
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
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
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
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
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
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
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 now
Bug#893561: libtablelayout-java: license does not seem to meet the DFSG
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 lic
Bug#827065: [uscan] add signed git tag support (pgpmode)'
(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)
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
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)
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)
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
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)
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
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
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 (Re: osgi-foundation-ee FTBFS with openjdk-9)
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&arch=all&ver=4.2.0-3&stamp=1522242580&raw=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
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
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
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
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)
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
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]
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
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
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
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?
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
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
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
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
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]
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
Ah I see... :-) Thanks for the prompt reply :-) Cheers, Chris.
Bug#893658: [pkg-cinnamon] Bug#893658: cinnamon: recommend smart-notifier
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
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
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
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
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
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
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
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&arch=riscv64&ver=1.0.2o-1&stamp=1522207078&raw=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
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
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.
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
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
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
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
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
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
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
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
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.
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)
Are there any news about this?
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
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
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)
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
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
Package: ftp.debian.org Severity: normal Thanks!
Bug#894297: [PATCH] cyrus-sasl2: please add build-profile support
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 Cyru
Bug#894298: RM: python-gffutils -- ROM; No longer needed, no reverse-dependencies
Package: ftp.debian.org Severity: normal Thanks!
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
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: Droppi
Bug#880133: firefox-esr: double-sided print-out is no longer working
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
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