Bug#890391: libjs-jquery-atwho: ReferenceError: Controller is not defined

[Pirate Praveen]

On Sun, 25 Feb 2018 14:47:19 +1100 Ben Finney  wrote:
> On 25-Feb-2018, Balasankar C wrote:
> 
> > Note: I have enabled the atwho JS file from cloudflare CDN in it.
> 
> How is that related to the upstream source?

These days most browser libraries are developed in a node.js environment
and the output of these source files are generated by tools (module
bundlers) like browserify, rollup and webpack (in this particular case I
think gulp-umd + gulp-concat and other gulp plugins).

cloudflare CDN is distributing the output of these source files
(generated using gulp). Because browsers don't implement all APIs of
Nodejs, we cannot directly use these source files, but need to use a
module bundler like webpack (we have two module bundlers in debian now -
webpack and rollup). I have been replacing many of the build scripts to
use webpack instead of rollup for some time (as rollup was accepted only
a week back).

Many times, there is also an extra step of transpiling before we can
bundle the modules. A transpiler like babel or buble (both now available
in main), convert code written in ES6 version of javascript to ES5 that
browsers understand. In this particular case, we don't have the
transpile step and we directly bundle the modules using gulp-umd and
gulp-concat.



signature.asc
Description: OpenPGP digital signature

Bug#877746: closed by Mattia Rizzolo <mat...@debian.org> (Bug#877746: fixed in hexchat 2.12.4-6)

[Mattia Rizzolo]

On Sun, Feb 25, 2018 at 11:12:43AM +0800, Paul Wise wrote:
> On Sat, 2018-02-24 at 18:09 +, Debian Bug Tracking System wrote:
> 
> >  + Replace recomendency on gvfs-bin to libglib2.0-bin.  Closes: #877746
> 
> I can't find any mention of the gio or gvfs tools in hexchat.

I didn't as well, what I saw is that:
1) it has an '#include '
2) there is a comment around the code where it handles the links with a
   commnet "gvfs likes …"
3) the original bug adding the recommends is something on the line of
   "without the tools links won't open in the right place" or something
   like that, so it feels like that the tools are somewhat used by
   gvfs/gio itself as well when they are available, and improve the ux
   when they are.

So, I haven't digged that far, but with the very little of what I saw I
figured it would be the safest option.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#890391: libjs-jquery-atwho: ReferenceError: Controller is not defined

[Balasankar C]

Hi,


On Sun, 25 Feb 2018 14:47:19 +1100 Ben Finney  wrote:
> On 25-Feb-2018, Balasankar C wrote:
> 
> > Note: I have enabled the atwho JS file from cloudflare CDN in it.
> 
> How is that related to the upstream source?

You can ignore that. I just wanted to demo a working copy first so that
we can see how switching to the packaged one broke the test. Hence made
use of the CDN. It was only meant to show "Upstream one works, packaged
one doesn't.". :)

PS: In case you were asking how the CDN is related to upstream, check
this link: https://cdnjs.com/libraries/at.js . It hosts all the versions
of the library in a central location that websites can use via 

Bug#891398: mark kf5-kdepim-apps-libs Multi-Arch: foreign

[Helmut Grohne]

Package: kf5-kdepim-apps-libs
Version: 4:17.08.3-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

kf5-kdepim-apps-libs is a data package that doesn't have any
dependencies nor maintainer scripts. Thus it is safe to mark it
Multi-Arch: foreign. In general, Architecture: all packages can never be
used for satsifying cross Build-Depends unless marked such. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru kf5-kdepim-apps-libs-17.08.3/debian/changelog 
kf5-kdepim-apps-libs-17.08.3/debian/changelog
--- kf5-kdepim-apps-libs-17.08.3/debian/changelog   2017-12-21 
17:54:25.0 +0100
+++ kf5-kdepim-apps-libs-17.08.3/debian/changelog   2018-02-25 
08:39:54.0 +0100
@@ -1,3 +1,10 @@
+kf5-kdepim-apps-libs (4:17.08.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark kf5-kdepim-apps-libs-data Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 25 Feb 2018 08:39:54 +0100
+
 kf5-kdepim-apps-libs (4:17.08.3-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru kf5-kdepim-apps-libs-17.08.3/debian/control 
kf5-kdepim-apps-libs-17.08.3/debian/control
--- kf5-kdepim-apps-libs-17.08.3/debian/control 2017-12-18 23:08:26.0 
+0100
+++ kf5-kdepim-apps-libs-17.08.3/debian/control 2018-02-25 08:39:52.0 
+0100
@@ -31,6 +31,7 @@
 
 Package: kf5-kdepim-apps-libs-data
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Breaks: libkf5composereditorng5 (<= 4:16.04), ${kde-l10n:all}
 Replaces: libkf5composereditorng5 (<= 4:16.04), ${kde-l10n:all}

Bug#891397: mark aglfn Multi-Arch: foreign

[Helmut Grohne]

Package: aglfn
Version: 1.7-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Please mark aglfn Multi-Arch: foreign. It's a font package and thus a
data package with now maintainer scripts nor dependencies. Such packages
can be safely marked Multi-Arch: foreign. They should be to allow
satisfying dependencies from foreign architectures, which is relevant
for cross building packages that use gnuplot during build. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru aglfn-1.7/debian/changelog aglfn-1.7/debian/changelog
--- aglfn-1.7/debian/changelog  2014-01-03 16:36:59.0 +0100
+++ aglfn-1.7/debian/changelog  2018-02-25 08:35:20.0 +0100
@@ -1,3 +1,10 @@
+aglfn (1.7-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark aglfn Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 25 Feb 2018 08:35:20 +0100
+
 aglfn (1.7-3) unstable; urgency=low
 
   * Team upload
diff --minimal -Nru aglfn-1.7/debian/control aglfn-1.7/debian/control
--- aglfn-1.7/debian/control2014-01-03 16:30:17.0 +0100
+++ aglfn-1.7/debian/control2018-02-25 08:35:18.0 +0100
@@ -11,6 +11,7 @@
 
 Package: aglfn
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Description: Adobe Glyph List For New Fonts
  AGL (Adobe Glyph List) maps glyph names to Unicode values for the

Bug#891395: libfabric1: improperly packaged library support files

[Helmut Grohne]

Package: libfabric1
Version: 1.5.3-1
Severity: serious
Justification: policy 8.2

libfabric1 ships /usr/bin/fi_{info,pingpong,strerror}. These files are
independent of the soname of the library. Debian policy section 8.2
prohibits such files from being shipped in the shared library package.
The typical solution is to split them out into a package named e.g.
libfabric-bin. Thus when libfabric bumps its soname, libfabric-bin would
get taken over by the newer package while libfabric1 and e.g. libfabric2
would remain coinstallable.

Helmut

Bug#890391: libjs-jquery-atwho: ReferenceError: Controller is not defined

[Pirate Praveen]

On Sun, 25 Feb 2018 15:03:45 +1100 Ben Finney  wrote:
> On 15-Feb-2018, Pirate Praveen wrote:
> 
> > wget `npm view at.js dist.tarball` will get you the dist tarball.
> > Compare dist/js/jquery.atwho.js in the tarball with the file installed
> > by the debian package.
> 
> (There is no ‘npm’ in Debian Buster yet, so I'm not easily able to get
> anything from NPM.)

You can just use wget to get the files from npm registry.

$ npm view at.js dist.tarball
https://registry.npmjs.org/at.js/-/at.js-1.5.3.tgz

(it is the same pattern for all npm modules)

$ wget https://registry.npmjs.org/at.js/-/at.js-1.5.3.tgz

> Looking at the ‘/usr/share/javascript/jquery-atwho/jquery.atwho.js’
> file installed by the Debian package, I see that the Reference Error
> is because ‘Controller’ is defined in a different scope.
> 
> As you have suggested, the custom build rules in the Debian package
> were implemented before we had Gulp in Debian. So the build process
> may be to blame for the error behaviour.
> 
> What should be done in this package to use the ‘gulpfile.js’ tasks,
> now that Gulp is available in Debian?

https://wiki.debian.org/Javascript/Nodejs#Using_build_tools_like_grunt

You can just call gulp from debian/rules. But you may need to package
some gulp plugins or embed them
https://wiki.debian.org/Javascript/Nodejs/Npm2Deb#Embedding_some_modules
some of them plugins you may be able to skip.

$ npm2deb depends  -r at.js
Module at.js has no dependencies.
Build dependencies:
NPM   Debian
gulp (^3.9.0) node-gulp (3.9.1-6)
gulp-bump (^1.0.0)None
gulp-coffee (^2.3.1)  node-gulp-coffee (2.3.4-1)
gulp-concat (^2.6.0)  node-gulp-concat (2.6.1-1)
gulp-cssmin (^0.1.7)  None
gulp-debug (^2.1.2)   None
gulp-header (^1.7.1)  None
gulp-jasmine (^2.2.1) None
gulp-jasmine-phantom (^2.0.1) None
gulp-rename (^1.2.2)  node-gulp-rename (1.2.2-1)
gulp-uglify (^1.5.1)  None
gulp-umd (^0.2.0) None
gulp-util (^3.0.7)node-gulp-util (3.0.7-1)
jasmine-ajax (^3.2.0) None
jasmine-jquery (^2.1.1)   None
phantomjs (^1.9.19)   None

We can skip phantomjs and jasmine in the first iteration and enable
tests later. For skipping some modules, you have to patch the gulpfile.js.



signature.asc
Description: OpenPGP digital signature

Bug#891396: multiarchify libpotrace0

[Helmut Grohne]

Package: libpotrace0
Version: 1.14-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libpotrace0 and libpotrace-dev already ship all of their
architecture-dependent files on architecture-dependent paths. Please
mark them as coinstallable to ease cross building where both versions
are required simultaneously. The attached patch implements that for your
convenience.

Helmut
diff --minimal -Nru potrace-1.14/debian/changelog potrace-1.14/debian/changelog
--- potrace-1.14/debian/changelog   2017-05-28 11:19:02.0 +0200
+++ potrace-1.14/debian/changelog   2018-02-25 08:26:31.0 +0100
@@ -1,3 +1,10 @@
+potrace (1.14-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark libpotrace0 and libpotrace-dev Multi-Arch: same. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 25 Feb 2018 08:26:31 +0100
+
 potrace (1.14-2) unstable; urgency=low
 
   * Stricter dependency on libpotrace (Closes: #862540)
diff --minimal -Nru potrace-1.14/debian/control potrace-1.14/debian/control
--- potrace-1.14/debian/control 2017-05-28 11:19:02.0 +0200
+++ potrace-1.14/debian/control 2018-02-25 08:26:26.0 +0100
@@ -28,6 +28,7 @@
 Package: libpotrace0
 Section: libs
 Architecture: any
+Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: library for tracing bitmaps
  potrace is a utility for tracing a bitmap, which means, transforming
@@ -39,6 +40,7 @@
 Package: libpotrace-dev
 Section: libdevel
 Architecture: any
+Multi-Arch: same
 Depends: libpotrace0 (= ${binary:Version}), ${misc:Depends}
 Description: development files for potrace library
  potrace is a utility for tracing a bitmap, which means, transforming

Bug#891393: Old Ubuntu release chroot cannot be created with debootstrap on Debian

[Hideki Yamane]

package: debootstrap
severity: minor

Hi,

 When I run debootstrap to create old Ubuntu release (until karmic(*),
 lucid is okay)  on Debian, it causes segfault.

> W: Failure trying to run: chroot /home/henrich/tmp/karmic /sbin/ldconfig
> W: See /home/henrich/tmp/karmic/debootstrap/debootstrap.log for details
> henrich@e450:~/tmp$ cat /home/henrich/tmp/karmic/debootstrap/debootstrap.log
> gpgv: Signature made 2009年10月28日 23時23分20秒 JST
> gpgv:using DSA key 40976EAF437D05B5
> gpgv: Good signature from "Ubuntu Archive Automatic Signing Key 
> "
> Segmentation fault

 But same job works on Ubuntu (at least 16.04).


 *) https://wiki.ubuntu.com/Releases

-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#891394: multiarchify libostyle1c2

[Helmut Grohne]

Package: libostyle1c2
Version: 1.4devel1-21.3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Please multiarchify libostyle1c2 to allow coinstallation with itself.
The attached patch implements that.

Helmut
diff -u openjade-1.4devel1/debian/changelog openjade-1.4devel1/debian/changelog
--- openjade-1.4devel1/debian/changelog
+++ openjade-1.4devel1/debian/changelog
@@ -1,3 +1,12 @@
+openjade (1.4devel1-21.4) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Multiarchify: (Closes: #-1)
++ Let dh_auto_configure pass --libdir to ./configure.
++ Update debian/*.install files.
+
+ -- Helmut Grohne   Sat, 24 Feb 2018 14:31:36 +0100
+
 openjade (1.4devel1-21.3) unstable; urgency=low
 
   * Non-maintainer upload.
diff -u openjade-1.4devel1/debian/libostyle-dev.install 
openjade-1.4devel1/debian/libostyle-dev.install
--- openjade-1.4devel1/debian/libostyle-dev.install
+++ openjade-1.4devel1/debian/libostyle-dev.install
@@ -2,2 +2,2 @@
-debian/tmp/usr/lib/lib*.a usr/lib
-debian/tmp/usr/lib/lib*.so usr/lib
+debian/tmp/usr/lib/*/lib*.a
+debian/tmp/usr/lib/*/lib*.so
diff -u openjade-1.4devel1/debian/libostyle1c2.install 
openjade-1.4devel1/debian/libostyle1c2.install
--- openjade-1.4devel1/debian/libostyle1c2.install
+++ openjade-1.4devel1/debian/libostyle1c2.install
@@ -1,2 +1,2 @@
-debian/tmp/usr/lib/lib*.so.[0-9].[0-9].[0-0] usr/lib
-debian/tmp/usr/lib/lib*.so.[0-9] usr/lib
+debian/tmp/usr/lib/*/lib*.so.[0-9].[0-9].[0-0]
+debian/tmp/usr/lib/*/lib*.so.[0-9]
diff -u openjade-1.4devel1/debian/rules openjade-1.4devel1/debian/rules
--- openjade-1.4devel1/debian/rules
+++ openjade-1.4devel1/debian/rules
@@ -97,7 +97,7 @@
 configure-stamp:
dh_autoreconf
dh_buildinfo generate cat
-   ./configure --prefix=/usr --enable-http --enable-shared --enable-static
+   dh_auto_configure -- --enable-http --enable-shared --enable-static
touch $@
 
 

Bug#891333: [Pkg-nagios-devel] Bug#891333: new upstream (2.8.1)

[Alexander Wirt]

On Sat, 24 Feb 2018, Daniel Baumann wrote:

> Hi Alexander,
> 
> On 02/24/2018 05:45 PM, Alexander Wirt wrote:
> > want to maintain it?
> 
> for the last 5 years I only maintain a few[0] packages in Debian. In
> general I do not want to maintain more (as I did some years ago),
> however, icinga is quite important to me, so I'd like to volunteer for this.
> 
> I'll prepare an updated package and get it uploaded through my usual
> sponsor if this is alright with you.
> 
> > it is de facto without maintainer. 
> 
> Does this also extend to icingaweb2?
I would say more or less to whole pkg-nagios. 

You can just send me a patch and I will do the upload and add it to the git. 

Alex

Bug#889471: libcairo-perl: FTBFS: t/CairoSurface.t failure

[Niko Tyni]

Control: reassign -1 libcairo2 1.15.10-1
Control: retitle -1 cairo: PNG handling regression in 1.15.10
Control: tag -1 patch fixed-upstream
Control: affects -1 libcairo-perl 

On Sat, Feb 03, 2018 at 07:55:23PM +0200, Niko Tyni wrote:
> On Sat, Feb 03, 2018 at 07:19:24PM +0200, Niko Tyni wrote:
> > Package: libcairo-perl
> > Version: 1.106-2
> > Severity: serious
> > User: debian-p...@lists.debian.org
> > Usertags: autopkgtest
> > 
> > As noticed by ci.debian.net, the test suite of this package
> > recently started failing.
> > 
> >   Test Summary Report
> >   ---
> >   t/CairoSurface.t (Wstat: 139 Tests: 41 Failed: 0)
> > Non-zero wait status: 139
> > Parse errors: Bad plan.  You planned 88 tests but ran 41.
> >   Files=9, Tests=256,  0 wallclock secs ( 0.08 usr  0.00 sys +  0.58 cusr  
> > 0.05 csys =  0.71 CPU)
> >   Result: FAIL
> >  
> > Timing suggests src:cairo (1.15.8-3 -> 1.15.10-1) as the probable cause
> > for this regression.
> 
> Confirmed by downgrading libcairo2; that makes the test suite pass again.

This seems to be similar to https://bugs.freedesktop.org/show_bug.cgi?id=104325
as my tests indicate that the corresponding fix

 
https://cgit.freedesktop.org/cairo/commit/?id=82f4028532c11152a0110f1b277e3358dfca6545

also fixes the libcairo-perl test suite crash.

Reassigning accordingly.
-- 
Niko Tyni   nt...@debian.org

Bug#891392: enlightenment: Unable to start Wayland session

[sergio]

Package: enlightenment
Version: 0.22.1-2
Severity: normal


Without exports, just from tty:

% enlightenment_start
...
ESTART: 0.06879 [0.1] - Compositor Init
 Enlightenment Error 
Enlightenment cannot initialize Ecore_X!

 Enlightenment Error 
Enlightenment cannot create a compositor.

E: Begin Shutdown Procedure!
ERR<1982>:e ../src/bin/e_msgbus.c:84 _e_msgbus_request_name_cb() Could not 
request bus name




With ELM_DISPLAY=wl

% enlightenment_start
...
ESTART: 0.06085 [0.2] - Elementary Init
ERR<2358>:elementary lib/elementary/elm_config.c:3965 _elm_config_sub_init() 
Could not connect to Wayland Display
## Copy & Paste the below (until EOF) into a terminal, then hit Enter





-- System Information:
Debian Release: sid
Architecture: amd64 (x86_64)
Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages enlightenment depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.4-1
ii  dbus-x11 [dbus-session-bus]   1.12.4-1
ii  enlightenment-data0.22.1-2
ii  libasound21.1.3-5
ii  libbluetooth3 5.47-1+b1
ii  libc6 2.26-6
ii  libecore-con1 1.20.6-3
ii  libecore-evas11.20.6-3
ii  libecore-file11.20.6-3
ii  libecore-input1   1.20.6-3
ii  libecore-ipc1 1.20.6-3
ii  libecore-x1   1.20.6-3
ii  libecore1 1.20.6-3
ii  libedje-bin   1.20.6-3
ii  libedje1  1.20.6-3
ii  libeet1   1.20.6-3
ii  libeeze1  1.20.6-3
ii  libefreet-bin 1.20.6-3
ii  libefreet1a   1.20.6-3
ii  libeina1a 1.20.6-3
ii  libeio1   1.20.6-3
ii  libelementary11.20.6-3
ii  libemile1 1.20.6-3
ii  libemotion1   1.20.6-3
ii  libevas1  1.20.6-3
ii  libevas1-engines-x1.20.6-3
ii  libpam0g  1.1.8-3.7
ii  libpulse0 11.1-4
ii  libxcb-keysyms1   0.4.0-1+b2
ii  libxcb-shape0 1.12-1
ii  libxcb1   1.12-1



-- Full Log Without exports:
% enlightenment_start
E - PID=3603, valgrind=0
ESTART: 0.1 [0.1] - Begin Startup
ESTART: 0.4 [0.4] - Signal Trap
ESTART: 0.5 [0.1] - Signal Trap Done
ESTART: 0.8 [0.3] - Eina Init
ESTART: 0.00045 [0.00037] - Eina Init Done
ESTART: 0.00046 [0.1] - Determine Prefix
ESTART: 0.00062 [0.00016] - Determine Prefix Done
ESTART: 0.00063 [0.1] - Environment Variables
ESTART: 0.00065 [0.2] - Environment Variables Done
ESTART: 0.00065 [0.1] - Parse Arguments
ESTART: 0.00066 [0.1] - Parse Arguments Done
ESTART: 0.00067 [0.1] - Eet Init
ESTART: 0.00070 [0.3] - Eet Init Done
ESTART: 0.00071 [0.1] - Ecore Init
ESTART: 0.01115 [0.01045] - Ecore Init Done
ESTART: 0.02935 [0.01820] - EFX Init
ESTART: 0.02939 [0.4] - EFX Init Done
ESTART: 0.02939 [0.1] - EIO Init
ESTART: 0.06313 [0.03373] - EIO Init Done
ESTART: 0.06316 [0.4] - Ecore Event Handlers
ESTART: 0.06317 [0.1] - Ecore Event Handlers Done
ESTART: 0.06318 [0.1] - Ecore_File Init
ESTART: 0.06319 [0.1] - Ecore_File Init Done
ESTART: 0.06320 [0.1] - Ecore_Con Init
ESTART: 0.06322 [0.2] - Ecore_Con Init Done
ESTART: 0.06323 [0.1] - Ecore_Ipc Init
ESTART: 0.06324 [0.1] - Ecore_Ipc Init Done
ESTART: 0.06329 [0.5] - Ecore_Evas Init
ESTART: 0.06412 [0.00082] - Ecore_Evas Init Done
ESTART: 0.06415 [0.3] - Elementary Init
ESTART: 0.09090 [0.02675] - Elementary Init Done
ESTART: 0.09092 [0.2] - Emotion Init
ESTART: 0.09112 [0.00019] - Emotion Init Done
ESTART: 0.09113 [0.1] - Ecore_Evas Engine Check
ESTART: 0.09114 [0.1] - Ecore_Evas Engine Check Done
ESTART: 0.09115 [0.1] - E Intl Init
ESTART: 0.09118 [0.3] - E Intl Init Done
ESTART: 0.09118 [0.1] - E_Alert Init
ESTART: 0.09119 [0.1] - E_Alert Init Done
ESTART: 0.09120 [0.1] - E Directories Init
ESTART: 0.09127 [0.7] - E Directories Init Done
ESTART: 0.09128 [0.1] - E_Filereg Init
ESTART: 0.09132 [0.4] - E_Filereg Init Done
ESTART: 0.09133 [0.1] - E_Config Init
ESTART: 0.10602 [0.01470] - E_Config Init Done
ESTART: 0.10605 [0.3] - E_Env Init
ESTART: 0.10607 [0.2] - E_Env Init Done
ESTART: 0.10608 

Bug#891306: gnome-shell-pomodoro: uninstallable with gnome-shell 3.27

[Joseph Herlant]

Hi Jeremy,

Thanks for your report.

> Since GNOME 3.22, GNOME Shell allows loading extensions even if they
> have not been specifically marked as compatible in their
> metadata.json.

I think that last time I checked that the issue was that
gnome-tweak-tool didn't allow the extension to be enabled.

I'll check and get back to you asap.

Joseph

Bug#890608: [921fc67] Fix for Bug#890608 committed to git

[Manoj Srivastava]

tags 890608 + pending
thanks
Hi,

 The following change has been committed for this bug by
 Manoj Srivastava  on the branch 
 dgit/sid at Sat, 24 Feb 2018 21:53:20 -0800.

 The fix will be in the next upload. 
=
[master]: A bug fixing release

Rolled backt he POSIX_X_SOURCE feature  check changes.

Closes: #890608
Closes: #890714
Closes: #890743
Closes: #890703

Signed-off-by: Manoj Srivastava 
=

Bug#873240: redshift-gtk: redshift doesn't launch either when launching in the console or at start of computer

[Ritesh Raj Sarraf]

I just tried out redshift on my GNOME box and it is working fine.
Lately, the way redshift works has changed slightly.

What is the output of:

systemctl --user status redshift


rrs@chutzpah:~$ systemctl --user status redshift
● redshift.service - Redshift display colour temperature adjustment
   Loaded: loaded (/usr/lib/systemd/user/redshift.service; enabled; vendor 
preset: enab
   Active: active (running) since Sun 2018-02-25 10:49:56 IST; 3min 47s ago
 Docs: http://jonls.dk/redshift/
 Main PID: 18964 (redshift)
   CGroup: /user.slice/user-1000.slice/user@1000.service/redshift.service
   └─18964 /usr/bin/redshift

Feb 25 10:49:56 chutzpah systemd[13641]: Started Redshift display colour 
temperature ad
Feb 25 10:49:56 chutzpah redshift[18964]: Trying location provider `geoclue2'...
Feb 25 10:49:56 chutzpah redshift[18964]: Using provider `geoclue2'.
Feb 25 10:50:02 chutzpah redshift[18964]: Using method `randr'.


The gtk icon doesn't show up in GNOME but that is a different issue
altogether. You should be able to see the icon on other desktops that
use LibAppIndicator.


Please keep in mind that redshift needs geoclue2 support. Without it,
it wouldn't function properly unless you explicitly provide the
location details to it.


rrs@chutzpah:/usr/share/doc/redshift$ redshift -l list
Available location providers:
  geoclue2
  manual

Specify colon-separated options with`-l PROVIDER:OPTIONS'.
Try `-l PROVIDER:help' for help.
10:57 ♒♒♒   ☺



On Sat, 2018-02-24 at 10:06 -0500, John Scott wrote:
> Package: redshift-gtk
> Version: 1.11-1
> Followup-For: Bug #873240
> 
> I felt that it was justified since redshift-gtk is unusable, though I
> respect
> your decision going forward. I don't think this is specific to any
> particular desktop environment. I am having the same issue on MATE,
> and the
> submitter of the bug I merged into this one said that this bug also
> applied to
> Xfce. I concede that I don't know a lot about Python packaging, but I
> had
> thought that the Python errors could have explained the issue. This
> is
> displayed when it tries to import some modules from python3-xdg:
> 
> import 'xdg.BaseDirectory' #
> <_frozen_importlib_external.SourceFileLoader object at
> 0x7f697d5abda0>
> # code object from /usr/lib/python3/dist-packages/xdg/DesktopEntry.py
> # could not create '/usr/lib/python3/dist-packages/xdg/__pycache__':
> PermissionError(13, 'Permission denied')
> 
> I attempted to run redshift-gtk as root (I know it's not a good
> idea), and
> running it as root in MATE does work and show in the tray. That is
> why I thought
> escalating this issue was justified, since I thought this seemed like
> an
> issue not specific to a desktop environment, but to Python or
> Redshift, like above.
> 
> For me, most packages in /usr/lib/python3/dist-packages/ do have a
> __pycache__
> directory, but xdg seems to be an exception. pyxdg hasn't been built
> since 2014, so
> could it be that it just needs to be rebuilt?
> 
> I tried to rebuild it to investigate it further, but one of the tests
> in pyxdg,
> test_validate_icon_theme, fails, with "Invalid key: Scale", which
> keeps me from
> building the package.
> 
> Sorry for the trouble and confusion I caused earlier.
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing-debug
>   APT policy: (500, 'testing-debug'), (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages redshift-gtk depends on:
> ii  gir1.2-appindicator3-0.1  0.4.92-5
> ii  python3   3.6.4-1
> ii  python3-gi3.26.1-2
> ii  python3-xdg   0.25-4
> ii  redshift  1.11-1
> 
> Versions of packages redshift-gtk recommends:
> ii  at-spi2-core  2.26.2-2
> 
> redshift-gtk suggests no packages.
> 
> -- no debconf information
> 
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

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

Bug#806464: ITP: trufont -- cross-platform ufo3 font editor

[魏銘廷]

Package: wnpp
Followup-For: Bug #806464
Owner: Yao Wei (魏銘廷) 
Control: retitle -1 ITP: trufont -- cross-platform ufo3 font editor

Some of the dependencies has been resolved (thanks to fontmake!) , so I
am going to revisit this.

Yao Wei


signature.asc
Description: PGP signature

Bug#891391: ITP: python-hsluv -- Python implementation of HSLuv (Human-friendly HSL)

[魏銘廷]

Package: wnpp
Severity: wishlist
Owner: Yao Wei (魏銘廷) 
Control: block 806464 by -1

* Package name: python-hsluv
  Version : 4.0.2
  Upstream Author : Alexei Boronine 
* URL : https://github.com/hsluv/hsluv-python
* License : Expat
  Programming Lang: Python
  Description : Python implementation of HSLuv (Human-friendly HSL)

This is the dependency of trufont


signature.asc
Description: PGP signature

Bug#891389: ITP: python3-defconqt -- A set of Qt objects for use in defcon applications

[Yao Wei]

On Sun, Feb 25, 2018 at 12:54:51PM +0800, Yao Wei wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Yao Wei (魏銘廷) 
> Control: block 806464 by -1
> 
> * Package name: python3-defconqt
>   Version : x.y.z
>   Upstream Author : Name 
> * URL : http://www.example.org/
> * License : GPL-3 or LGPL-3
>   Programming Lang: Python3
>   Description : A set of Qt objects for use in defcon applications
> 
> This is the dependency used by trufont (#806464)

Sorry, sending things too quick without checking:

* Package name : python3-defconqt
  Version : 0.5.3
  Upstream Author : Adrien Tétar
* URL : https://github.com/trufont/defconQt
* License : GPL-3 or LGPL-3
  Programming Lang: Python3

Description : A set of Qt objects for use in defcon applications




signature.asc
Description: PGP signature

Bug#891390: ITP: ufo-extractor -- Tools for extracting data from font binaries into UFO objects.

[魏銘廷]

Package: wnpp
Severity: wishlist
Owner: Yao Wei (魏銘廷) 

* Package name: ufo-extractor
  Version : 0.2.0
  Upstream Author : Cosimo Lupo 
* URL : https://github.com/typesupply/extractor
* License : Expat
  Programming Lang: Python
  Description : Tools for extracting data from font binaries into UFO 
objects.

This is one of the dependencies of trufont


signature.asc
Description: PGP signature

Bug#891389: ITP: python3-defconqt -- A set of Qt objects for use in defcon applications

[魏銘廷]

Package: wnpp
Severity: wishlist
Owner: Yao Wei (魏銘廷) 
Control: block 806464 by -1

* Package name: python3-defconqt
  Version : x.y.z
  Upstream Author : Name 
* URL : http://www.example.org/
* License : GPL-3 or LGPL-3
  Programming Lang: Python3
  Description : A set of Qt objects for use in defcon applications

This is the dependency used by trufont (#806464)


signature.asc
Description: PGP signature

Bug#592834: File descriptor leaked

[Dean]

System

Linux kali 4.13.0-kali1-amd64 #1 SMP Debian 4.13.13-1kali1 (2017-11-17) 
x86_64 GNU/Linux


Disks

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda  8:00 238.5G  0 disk
├─sda1   8:10  1000M  0 part
├─sda2   8:20   260M  0 part /boot/efi
├─sda3   8:30  1000M  0 part
├─sda4   8:40   128M  0 part
└─sda5   8:50 236.1G  0 part
  ├─vg5-Kali   254:0036G  0 lvm  /
  ├─vg5-Bunsen 254:10 8G  0 lvm
  ├─vg5-Work   254:2025G  0 lvm /home/bu5hman/Documents/work
  └─vg5-Home   254:30   150G  0 lvm  /home


os-prober version 1.76

Update log (partial)


Preparing to unpack .../15-broadcom-sta-dkms_6.30.223.271-8_all.deb ...

 Uninstall Beginning 
Module:  broadcom-sta
Version: 6.30.223.271
Kernel:  4.13.0-kali1-amd64 (x86_64)
-

Status: Before uninstall, this module version was ACTIVE on this kernel.

wl.ko:
 - Uninstallation
   - Deleting from: /lib/modules/4.13.0-kali1-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

depmod...

Backing up initrd.img-4.13.0-kali1-amd64 to 
/boot/initrd.img-4.13.0-kali1-amd64.old-dkms

Making new initrd.img-4.13.0-kali1-amd64
(If next boot fails, revert to initrd.img-4.13.0-kali1-amd64.old-dkms image)
update-initramfs..

DKMS: uninstall completed.

 Uninstall Beginning 
Module:  broadcom-sta
Version: 6.30.223.271
Kernel:  4.14.0-kali1-amd64 (x86_64)
-

Status: Before uninstall, this module version was ACTIVE on this kernel.

wl.ko:
 - Uninstallation
   - Deleting from: /lib/modules/4.14.0-kali1-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

depmod...

Backing up initrd.img-4.14.0-kali1-amd64 to 
/boot/initrd.img-4.14.0-kali1-amd64.old-dkms

Making new initrd.img-4.14.0-kali1-amd64
(If next boot fails, revert to initrd.img-4.14.0-kali1-amd64.old-dkms image)
update-initramfs..

DKMS: uninstall completed.

 Uninstall Beginning 
Module:  broadcom-sta
Version: 6.30.223.271
Kernel:  4.14.0-kali3-amd64 (x86_64)
-

Status: Before uninstall, this module version was ACTIVE on this kernel.

wl.ko:
 - Uninstallation
   - Deleting from: /lib/modules/4.14.0-kali3-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

depmod...

Backing up initrd.img-4.14.0-kali3-amd64 to 
/boot/initrd.img-4.14.0-kali3-amd64.old-dkms

Making new initrd.img-4.14.0-kali3-amd64
(If next boot fails, revert to initrd.img-4.14.0-kali3-amd64.old-dkms image)
update-initramfs..

DKMS: uninstall completed.

--
Deleting module version: 6.30.223.271
completely from the DKMS tree.
--
Done.
Unpacking broadcom-sta-dkms (6.30.223.271-8) over (6.30.223.271-7) ...

Setting up broadcom-sta-dkms (6.30.223.271-8) ...
Loading new broadcom-sta-6.30.223.271 DKMS files...
Building for 4.13.0-kali1-amd64 4.14.0-kali3-amd64
Building initial module for 4.13.0-kali1-amd64
Done.

wl:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/4.13.0-kali1-amd64/updates/dkms/

depmod...

Backing up initrd.img-4.13.0-kali1-amd64 to 
/boot/initrd.img-4.13.0-kali1-amd64.old-dkms

Making new initrd.img-4.13.0-kali1-amd64
(If next boot fails, revert to initrd.img-4.13.0-kali1-amd64.old-dkms image)
update-initramfs.

DKMS: install completed.
Building initial module for 4.14.0-kali3-amd64
Done.

wl:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/4.14.0-kali3-amd64/updates/dkms/

depmod...

Backing up initrd.img-4.14.0-kali3-amd64 to 
/boot/initrd.img-4.14.0-kali3-amd64.old-dkms

Making new initrd.img-4.14.0-kali3-amd64
(If next boot fails, revert to initrd.img-4.14.0-kali3-amd64.old-dkms image)
update-initramfs..

DKMS: install completed.

Setting up grub-efi-amd64 (2.02+dfsg1-1) ...
Installing for x86_64-efi platform.
File descriptor 3 (pipe:[54303]) leaked on vgs invocation. Parent PID 
4426: grub-install
File descriptor 5 (/dev/sda2) leaked on vgs invocation. Parent PID 4426: 
grub-install
File descriptor 3 (pipe:[54303]) leaked on vgs invocation. Parent PID 
4426: grub-install
File descriptor 5 (/dev/sda2) leaked on vgs invocation. Parent PID 4426: 
grub-install

Installation finished. No error reported.
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found 

Bug#891388: debtags.debian.org: link from facet/tag names to facet/tag pages

[Paul Wise]

Package: debtags
Severity: wishlist

For each of the pages where facet/tag names are printed, it would be
useful for those to link to the corresponding facet/tag pages.

For example:

  admin::configuring

Replaces:
  
  admin::configuring

On these pages:

  https://debtags.debian.org/reports/todo/maint/p...@debian.org
  https://debtags.debian.org/reports/todo/
  https://debtags.debian.org/reports/checks/
  https://debtags.debian.org/reports/checks/1

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#890391: libjs-jquery-atwho: ReferenceError: Controller is not defined

[Ben Finney]

On 15-Feb-2018, Pirate Praveen wrote:

> wget `npm view at.js dist.tarball` will get you the dist tarball.
> Compare dist/js/jquery.atwho.js in the tarball with the file installed
> by the debian package.

(There is no ‘npm’ in Debian Buster yet, so I'm not easily able to get
anything from NPM.)

Looking at the ‘/usr/share/javascript/jquery-atwho/jquery.atwho.js’
file installed by the Debian package, I see that the Reference Error
is because ‘Controller’ is defined in a different scope.

As you have suggested, the custom build rules in the Debian package
were implemented before we had Gulp in Debian. So the build process
may be to blame for the error behaviour.

What should be done in this package to use the ‘gulpfile.js’ tasks,
now that Gulp is available in Debian?

-- 
 \“Science doesn't work by vote and it doesn't work by |
  `\authority.” —Richard Dawkins, _Big Mistake_ (The Guardian, |
_o__)  2006-12-27) |
Ben Finney 


signature.asc
Description: PGP signature

Bug#890391: libjs-jquery-atwho: ReferenceError: Controller is not defined

[Ben Finney]

Control: tags -1 - unreproducible + confirmed
Control: found -1 libjs-jquery-atwho/1.5.4+dfsg.1-1

On 25-Feb-2018, Balasankar C wrote:

> Attaching an html test file. It uses the libjs-jquery-caret.js
> package you have in experimental along with the libjs-query-atwho
> package in question.

Thank you. I have modified that so that it simply uses the
Debian-installed package, to show the error (and to use the same file
unchanged to test for whatever fix is implemented). The test file is
attached to this message.


The steps I am using to reproduce the behaviour:

* Install ‘libjs-jquery-caret.js’ version “0.3.1+dfsg.1-2” or later
  (now available in Debian “unstable”).

* Install ‘libjs-jquery-atwho’.

* Open a web browser with a debugger. (I am using Firefox.)

* Load the test page ‘atwho-bug890391-test.html’ with the debugger
  enabled.

  The JavaScript engine will report a “ReferenceError”, shown in the
  console.

This allows us to verify the reported behaviour.


This behaviour is present in version “1.5.3+dfsg.1-1”:

ReferenceError: Controller is not defined
jquery.atwho.min.js:1:10662

and, using the same test case, also in version “1.5.4+dfsg.1-1”:

ReferenceError: Controller is not defined
jquery.atwho.min.js:1:10634

Version “1.5.4” is the latest available from upstream. There are
(apparently?) no relevant upstream changes since that version that
would address this bug.

So unless I have misunderstood the bug, or there are changes in the
upstream source that address this bug, we need some fix that upstream
has not yet implemented.

-- 
 \“Are you pondering what I'm pondering, Pinky?” “Sure, Brain, |
  `\ but how are we going to find chaps our size?” —_Pinky and The |
_o__)   Brain_ |
Ben Finney 

	
	
		
		
	



signature.asc
Description: PGP signature

Bug#890391: libjs-jquery-atwho: ReferenceError: Controller is not defined

[Ben Finney]

On 25-Feb-2018, Balasankar C wrote:

> Note: I have enabled the atwho JS file from cloudflare CDN in it.

How is that related to the upstream source?

-- 
 \   “We have clumsy, sputtering, inefficient brains…. It is a |
  `\ *struggle* to be rational and objective, and failures are not |
_o__) evidence for an alternative reality.” —Paul Z. Myers, 2010-10-14 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#890661: debtags.debian.org: edit page for harmony returns "Package harmony was not found"

[Paul Wise]

On Sat, 2018-02-24 at 10:32 +0100, Enrico Rossi wrote:

> Meanwhile can you send me or attach the tags you want for the harmony
> package so I can add it to the db?

python3-harmony: implemented-in::python interface::shell network::client 
role::program role::shared-lib scope::utility

A couple more symptoms:

The harmony package does not appear in my TODO list:

https://debtags.debian.org/reports/todo/maint/p...@debian.org

The patch API doesn't return python3-harmony when I submit:

https://debtags.debian.org/api/patch
{"pkgs": {}, "notes": []}

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#877746: closed by Mattia Rizzolo <mat...@debian.org> (Bug#877746: fixed in hexchat 2.12.4-6)

[Paul Wise]

On Sat, 2018-02-24 at 18:09 +, Debian Bug Tracking System wrote:

>  + Replace recomendency on gvfs-bin to libglib2.0-bin.  Closes: #877746

I can't find any mention of the gio or gvfs tools in hexchat.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#878122: [pkg-opensc-maint] Bug#878122: opensc: please enable npa-tool

[Eric Dorland]

Control: block -1 by 891386

It looks like this requires OpenPACE to be packaged first.

* Andrew Shadura (andre...@debian.org) wrote:
> Package: opensc
> Version: 0.17.0-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Please enable npa-tool recently added to OpenSC:
> 
> https://github.com/OpenSC/OpenSC/pull/831/commits/089c472d8f87145ee0e2f66df087615fc4af1e3d#diff-67e997bcfdac55191033d57a16d1408aR869
> 
> Thanks!
> 

-- 
Eric Dorland 
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93


signature.asc
Description: PGP signature

Bug#891387: lintian: complains about mentions of riscv64

[Adam Borowski]

Package: lintian
Version: 2.5.76
Severity: normal

Hi!
I get the following error:
E: arch-test source: invalid-arch-string-in-source-relation riscv64 
[build-depends: binutils-riscv64-linux-gnu [!riscv64]]

The riscv64 architecture is supported by dpkg and binutils already, and
folks are working on making it an official Debian port.

You have uploaded lintian after riscv64 has been added to the arch table,
but it apparently takes a manual action to update lintian's database.  I see
it is generated from "dpkg-architecture -L" by private/refresh-archs; thus
triggering that should do the trick.

Note that the other two architectures of this family, riscv32 and riscv128,
are not in dpkg's arch table, and porters do not plan to work on them
anytime soon.


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

Kernel: Linux 4.16.0-rc2-debug-00027-g42a5c5c629e3 (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils  2.30-5
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.5
ii  file  1:5.32-2
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.60-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdpkg-perl  1.19.0.5
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-5
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.73-1
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.69+repack-1
ii  man-db2.8.1-1
ii  patchutils0.3.4-2
ii  perl  5.26.1-5
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

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

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
pn  libtext-template-perl  

-- no debconf information

Bug#888637: gozer: Update URL

[Eric Dorland]

Do you have a new URL to suggest?

* Ricardo Fabian Peliquero (zh...@lasampa.com.ar) wrote:
> Package: gozer
> Version: 0.7.nofont.1-6+b1
> Severity: minor
> 
> Dear Maintainer,
> 
> Please consider updating URL in package information.
> Current URL (http://linuxbrit.co.uk/gozer/) is not reachable.
> 
> Thank you!
> 
> Ricardo
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.15.0-rc8-amd64 (SMP w/2 CPU cores)
> Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
> LANGUAGE=es_AR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages gozer depends on:
> ii  giblib11.2.4-11
> ii  libc6  2.26-6
> ii  libimlib2  1.4.10-1
> 
> gozer recommends no packages.
> 
> gozer suggests no packages.
> 
> -- no debconf information

-- 
Eric Dorland 
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93


signature.asc
Description: PGP signature

Bug#891386: RFP: openpace -- OpenPACE implements Extended Access Control (EAC) version 2

[Eric Dorland]

Package: wnpp
Severity: wishlist

* Package name: openpace
  Version : 1.0.2
  Upstream Author : Frank Morgner 
* URL : https://frankmorgner.github.io/openpace/
* License : GPL3
  Programming Lang: C
  Description : OpenPACE implements Extended Access Control (EAC) version 2

OpenPACE implements Extended Access Control (EAC) version 2 as specified in
BSI TR-03110. OpenPACE comprises support for the following protocols:

* Password Authenticated Connection Establishment (PACE) Establish a secure
  channel with a strong key between two parties that only share a weak secret.
* Terminal Authentication (TA) Verify/prove the terminal's certificate (or
  rather certificate chain) and secret key.
* Chip Authentication (CA) Establish a secure channel based on the chip's
  static key pair proving its authenticy.

Furthermore, OpenPACE also supports Card Verifiable Certificates (CV
Certificates) as well as easy to use wrappers for using the established
secure channels.

Bug#890875: Simple test for ‘libjs-jquery-caret.js’ Debian package

[Ben Finney]

On 11-Dec-2016, Ben Finney wrote:

> I am still not clear about how this is meant to be used, so after it
> clears the NEW queue please experiment and report bugs if it is not
> working.


On 25-Feb-2018, Balasankar C wrote:
> On Thu, 22 Feb 2018 10:40:05 +1100 Ben Finney  wrote:
> > Does the package currently in ‘experimental’ work? It should not
> > be uploaded to ‘unstable’ unless it serves the need of a dependent
> > package like Pagure or GitLab.
> > 
> > […] I have not seen any confirmation that the package works as-is.
> 
> I imitated the upstream test page (http://ichord.github.io/Caret.js/),
> with the packaged JS file and it seems to be working similarly.

Thank you, that's what I needed: a verifiable test of the Debian
package when installed.

I am attaching a modified test page that uses only the Debian packages
(no network requests) for JavaScript libraries.

When I view that page, the Debian ‘libjs-jquery-caret.js’ package
allows the page's code to work.

I am satisfied this proves the package is ready for entry into Debian;
I'll prepare a new release to upload into “unstable”. Thank you!

-- 
 \  “I don't know half of you half as well as I should like, and I |
  `\   like less than half of you half as well as you deserve.” —Bilbo |
_o__)  Baggins |
Ben Finney 
Title: Caret.js









Caret.js



Textarea




Type something here for fun!!



ContentEditable

Hello, some bold and italic and bold text


iframe body












-> Fork me on GitHub!









signature.asc
Description: PGP signature

Bug#891385: bumblebeed fails to unload nvidia kernel module

[Pavel Kreuzt]

Package: bumblebee
Version: 3.2.1-17
Severity: important

When I launch some program with primusrun or optirun and close it, nvidia 
kernel module keeps loaded in kernel. Bumblebeed shows this error on syslog:

Feb 25 12:53:52 Harken bumblebeed[18893]: [ 3106.839895] [ERROR]Failed to 
unload module 'nvidia' (ref count: 1).

Keeping the kernel module loaded seems to affect battery performance and 
temperature of laptop.

-- System Information:
Distributor ID: Kali
Description:Kali GNU/Linux Rolling
Release:kali-rolling (Debian Buster)
Architecture:   x86_64

Kernel: Linux 4.14.0-kali3-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 bumblebee depends on:
ii  bbswitch-dkms  0.8-5
ii  dpkg   1.19.0.5kali1
ii  libbsd00.8.7-1
ii  libc6  2.26-6
ii  libglib2.0-0   2.54.3-2
ii  libkmod2   25-1
ii  libx11-6   2:1.6.4-3
ii  lsb-base   9.20170808
ii  xserver-xorg-core  2:1.19.6-1

Versions of packages bumblebee recommends:
ii  primus  0~20150328-6

Versions of packages bumblebee suggests:
ii  bumblebee-nvidia  3.2.1-17

-- no debconf information

Bug#878088: [Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Sandro Tosi]

thanks a lot guys! and apologies for the time it took to get it
addressed; i made a few minor changes (mostly what Nis said) and
commited as 
https://salsa.debian.org/reportbug-team/reportbug/commit/e6b24a88431e7ed3e71a16d231d693c547586c78
will upload soon


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

Bug#891384: override: gnome-themes-standard/oldlibs

[Jeremy Bicha]

Package: ftp.debian.org

Please move the transitional package gnome-themes-standard to oldlibs.
debian/control has already been updated.

Thanks,
Jeremy Bicha

Bug#891381: vt100 line-drawing is a bad idea here

[Adam Borowski]

> undertime prints terminal escape sequences to pipes and files.

There are two types of escape sequences here:

• SGR.  These make sense, as undertime uses color to convey its output.
A plain text interface would be a reasonable request but is probably a feature
(anarcat: you can detect non-terminals by !isatty(1) ).

• VT100 line drawing.  These codes shouldn't be used these days: there's a
debate whether they're allowed within an UTF-8 locale, as the relevant
standard seems to say no.  I for one consider this interpretation bogus,
especially as it forces programs to know about locales even if they don't
have a reason to care, and _most_ terminal authors think so as well -- but
"most" doesn't mean all.  Here's some information:
https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/utf8-plus-vt100.html
and putty is one of terminals that does otherwise.

Also, tools like "less -R", which support colors well, don't handle such
line drawing.  This includes my ansi2txt and ansi2html -- understanding
these codes would be a reasonable feature, but, like less' author, I haven't
either thought nor bothered to implement that yet.  Thus, let's assume those
who claim supporting them with UTF-8 is wrong are right :þ .

This leaves two options for you: either you can detect if the locale is
UTF-8 and switch codes you output accordingly, or you can consider this a
waste of your time and just output Unicode unconditionally.  As the latter
works cleanly with redirection and other non-terminal receivers, this is
what I'd suggest.  It's overdue to declare ancient locales unsupported.


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

Bug#891383: RM: gnome-themes-standard [all] -- NBS; replaced by gnome-themes-extra

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-CC: gnome-themes-stand...@packages.qa.debian.org

The gnome-themes-extra source package has now replaced
gnome-themes-standard. It wasn't picked up by auto-cruft because of an
arch:all issue.

Please remove the 3.22.3-4 version of the gnome-themes-standard source
and binaries.

gnome-themes-extra still provides gnome-accessibility-themes and
gnome-themes-standard (as a transitional package).

Thanks,
Jeremy Bicha

Bug#840014: webcheckout: missing URL sanitization

[Paul Wise]

On Sat, 2018-02-24 at 18:46 +0100, Jakub Wilk wrote:

> ">=" compares numerically even when arguments are strings, so the int() 
> calls aren't needed here.
> 
> More importantly, this will break when Git 3.0 is released, because 
> int($minor) >= 12 will be no longer true.

Fixed in git:

http://source.myrepos.branchable.com/?p=source.git;a=commitdiff;h=6808ec71ba7ae13f3cf755561aa4165e4f623f0d

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#891129: neovim-qt: Microscopic window when .vimrc is corrupted

[James McCoy]

Control: tag -1 confirmed upstream
Control: forwarded -1 https://github.com/equalsraf/neovim-qt/issues/251

On Thu, Feb 22, 2018 at 03:23:31PM +0100, Luffah wrote:
>   when i put (incidentally) a corrupted configuration in  init.vim
>   (=.vimrc).
>   NeoVim does open with these properties :
>   Width: 200
>   Height: 100
> This size is not readable, so the user have to resize the window to
>   understand what does happens.
> 
>   I think a size of 640x480  is a more appropriate as default size.

It's a known issue upstream, but a fix hasn't been determined yet.

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

Bug#891382: libgc: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)

[Manuel A. Fernandez Montecelo]

Source: libgc
Version: 1:7.4.2-8.1
Severity: normal
Tags: patch upstream fixed-upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64
Forwarded: 
https://github.com/ivmai/bdwgc/commit/4f7f0eebd24dcde9f2b3ec2cb98913fc39bbdda3

Hello,

We need support in this package for RISC-V, to bootstrap the riscv64
architecture.

A patch has been submitted upstream a few days ago, so it would be great if you
could include it as a patch and release a new version for unstable.

If we can help by NMUing the package or anything else, please let me/us know.

Since the package maintenance doesn't seem to be very active lately and this
package is quite critical for the (any) port, I plan to NMU if no reply is
received in a few days/weeks.


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 

Bug#888566: vim FTBFS on alpha: vim segfaults in the build

[James McCoy]

On Sat, Feb 24, 2018 at 07:13:02PM +0100, Aurelien Jarno wrote:
> On 2018-01-28 21:05, James McCoy wrote:
> > Control: reassign -1 src:glibc 2.24-2
> > Control: affects -1 src:vim
> > 
> > On Sat, Jan 27, 2018 at 02:37:21PM -0500, James McCoy wrote:
> > > On Sat, Jan 27, 2018 at 05:50:16PM +1300, Michael Cree wrote:
> > > > [snip useful details]
> > > > 
> > > > Four of those bytes difference are due to the field b_ino in the
> > > > struct (of type ino_t).  And indeed examining the build log [1]
> > > > one sees option.c is compiled with -DFILE_OFFSET_BITS=64 but
> > > > misc1.c is NOT compiled with that option, hence the difference
> > > > in offsets to fields in the buf_T struct.
> > > 
> > > It looks like you came to the same conclusion as we did in #827319.  Vim
> > > uses autoconf's AC_SYS_LARGEFILE to determine whether _FILE_OFFSET_BITS
> > > needs to be set (and decides it doesn't), however the Perl bindings
> > > always force _FILE_OFFSET_BITS=64[0].
> > 
> > Note that Vim handles this via config.h, so it's not actually evident
> > from the compile commands whether an individual module is being built
> > with -D_FILE_OFFSET_BITS=64.  Having looked through Vim's source, I can
> > confirm that Vim does properly ensure config.h is loaded before any
> > system headers, though.
> > 
> > After some discussion on IRC, bunk pointed out this is an issue with
> > glibc on alpha and kfreebsd-*.
> > 
> > Alpha
> > -
> > 
> > AC_SYS_LARGEFILE determines whether -D_FILE_OFFSET_BITS=64 is needed by
> > checking whether off_t is 64-bit on its own.  For alpha, this is true
> > because
> > 
> > usr/include/alpha-linux-gnu/bits/typesizes.h
> > 36:#define __OFF_T_TYPE __SLONGWORD_TYPE
> > 67:#define __OFF_T_MATCHES_OFF64_T  1
> >
> > On the other hand, ino_t is always defined to be 32-bits
> > 
> > usr/include/alpha-linux-gnu/bits/typesizes.h
> > 32:#define __INO_T_TYPE __U32_TYPE
> > 
> > and struct stat's st_ino varies type based on whether
> > __USE_FILE_OFFSET64 is defined
> > 
> > usr/include/alpha-linux-gnu/bits/stat.h
> > 69:struct stat
> > 70-  {
> > 71-__dev_t st_dev;  /* Device.  */
> > 72-#ifdef __USE_FILE_OFFSET64
> > 73-__ino64_t st_ino;/* File serial number.  */
> > 74-#else
> > 75-__ino_t st_ino;  /* File serial number.  */
> > 76-int __pad0;  /* 64-bit st_ino.  */
> > 
> > So, st_ino is only 64-bit when __USE_FILE_OFFSET64 is set, but that won't
> > typically be the case because off_t is _always_ 64-bit.
> 
> -D_FILE_OFFSET_BITS=64 changes a lot of types, and not only struct stat.
> It also causes for example struct statfs or struct dirent to change. It
> looks to me that the issue is to decide to pass -D_FILE_OFFSET_BITS=64
> depending on the size of off_t,

Which has been the mechanism behind autoconf's AC_SYS_LARGEFILE for
quite a while.

> while many more things are affected. It
> should not hurt to always pass -D_FILE_OFFSET_BITS=64.

Many projects rely on AC_SYS_LARGEFILE to determine whether and which
flags need to be set.  If AC_SYS_LARGEFILE determines the flag isn't
necessary, but some dependency advertises it, then it's easy to have
modules compiled with different settings, causing subtle breakage.

> In any case it's an existing interface, that probably wasn't done
> the best way on alpha as it's one of the first 64-bit platforms in
> glibc. The structures can't be easily changed without breaking the
> world. It should however be possible to use symbol versioning to
> provide a new version of all the functions affected by this change.
> If some alpha porters have the motivation to do so, it should be
> coordinated upstream.

Hopefully alpha (and kfreebsd-*) are the only platforms affected.

> Otherwise vim should have to be fixed.

Vim now includes -D_FILE_OFFSET_BITS=64 if AC_SYS_LARGEFILE determines
it is needed or any libraries it links against include that in their
exported CFLAGS, so it handles this.  I was just hoping there was
something broader that could be done, since it was troublesome to track
down.

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

Bug#891379: undertime: useless without manpage

[Adam Borowski]

Package: undertime
Version: 1.1.0
Severity: normal

Hi!
As "undertime" is a command-line program that requires arguments to do
anything useful, some description of how to use it would be required.

Shipping such documentation as a man page would be greatly preferred
-- and there's no other docs in the package anyway.


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

Kernel: Linux 4.16.0-rc2-debug-00027-g42a5c5c629e3 (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages undertime depends on:
ii  python3 3.6.4-1
ii  python3-parsedatetime   2.4-2
ii  python3-termcolor   1.1.0-1
ii  python3-terminaltables  3.1.0-2
ii  python3-tz  2018.3-2

undertime recommends no packages.

undertime suggests no packages.

-- no debconf information

Bug#891380: ncurses: Please add Breaks for libunibilium0

[James McCoy]

Source: ncurses
Version: 6.1-1
Severity: normal

unibilium is a library which parses terminfo files.  The wide terminfo
format introduced in ncurses 6.1 wasn't supported by unibilium until
2.0.0 (which required an SONAME bump to libunibilium4).  When
libunibilium0 is in use, it can cause anything from visual glitches to
crashes of the application.

In order to help partial upgrades, please add "Breaks: libunibilium0" to
ncurses-term and ncurses-base.

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

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

Bug#891381: undertime: prints terminal escape sequences to pipes/files

[Paul Wise]

Package: undertime
Version: 1.1.0
Severity: normal

undertime prints terminal escape sequences to pipes and files.
It should drop the highlighting when stdout is not a terminal.
It looks like it maybe should use different characters for the
table cell borders as well because the ansi2txt output is ugly.

$ undertime | less
ESC(0lqqqkESC(B
ESC(0xESC(B  AWST ESC(0xESC(B
ESC(0tqqquESC(B
ESC(0xESC(B 00:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 01:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 02:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 03:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 04:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 05:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 06:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 07:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 08:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[1m08:30ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m09:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m10:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m11:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m12:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m13:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m14:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m15:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m16:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m17:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 18:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 19:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 20:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 21:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 22:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 23:00ESC[0m ESC(0xESC(B
ESC(0mqqqjESC(B
(END)
$ undertime > foo
$ less foo
ESC(0lqqqkESC(B
ESC(0xESC(B  AWST ESC(0xESC(B
ESC(0tqqquESC(B
ESC(0xESC(B 00:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 01:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 02:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 03:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 04:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 05:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 06:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 07:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 08:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[1m08:31ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m09:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m10:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m11:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m12:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m13:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m14:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m15:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m16:00ESC[0m ESC(0xESC(B
ESC(0xESC(B ESC[33m17:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 18:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 19:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 20:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 21:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 22:00ESC[0m ESC(0xESC(B
ESC(0xESC(B 23:00ESC[0m ESC(0xESC(B
ESC(0mqqqjESC(B
foo (END)
$ undertime | ansi2txt
0lqqqkB
0xB  AWST 0xB
0tqqquB
0xB 00:00 0xB
0xB 01:00 0xB
0xB 02:00 0xB
0xB 03:00 0xB
0xB 04:00 0xB
0xB 05:00 0xB
0xB 06:00 0xB
0xB 07:00 0xB
0xB 08:00 0xB
0xB 08:33 0xB
0xB 09:00 0xB
0xB 10:00 0xB
0xB 11:00 0xB
0xB 12:00 0xB
0xB 13:00 0xB
0xB 14:00 0xB
0xB 15:00 0xB
0xB 16:00 0xB
0xB 17:00 0xB
0xB 18:00 0xB
0xB 19:00 0xB
0xB 20:00 0xB
0xB 21:00 0xB
0xB 22:00 0xB
0xB 23:00 0xB
0mqqqjB

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages undertime depends on:
ii  python3 3.6.4-1
ii  python3-parsedatetime   2.4-2
ii  python3-termcolor   1.1.0-1
ii  python3-terminaltables  3.1.0-2
ii  python3-tz  2018.3-2

undertime recommends no packages.

undertime suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#891378: undertime: indentation of highlighted times with some timezones

[Paul Wise]

Package: undertime
Version: 1.1.0
Severity: minor

There is some indentation of highlighted times but only with some
timezones. It seems to happen only when printing a long timezone name
in the header.

$ undertime --no-default-zone Europe/Amsterdam 
┌──┐
│ Europe/Amsterdam │
├──┤
│   17:00  │
│  18:00   │
│  19:00   │
│  20:00   │
│  21:00   │
│  22:00   │
│  23:00   │
│  00:00   │
│  01:00   │
│  01:17   │
│  02:00   │
│  03:00   │
│  04:00   │
│  05:00   │
│  06:00   │
│  07:00   │
│  08:00   │
│   09:00  │
│   10:00  │
│   11:00  │
│   12:00  │
│   13:00  │
│   14:00  │
│   15:00  │
│   16:00  │
└──┘
$ TZ=Europe/Amsterdam undertime
┌───┐
│  CET  │
├───┤
│ 00:00 │
│ 01:00 │
│ 01:19 │
│ 02:00 │
│ 03:00 │
│ 04:00 │
│ 05:00 │
│ 06:00 │
│ 07:00 │
│ 08:00 │
│ 09:00 │
│ 10:00 │
│ 11:00 │
│ 12:00 │
│ 13:00 │
│ 14:00 │
│ 15:00 │
│ 16:00 │
│ 17:00 │
│ 18:00 │
│ 19:00 │
│ 20:00 │
│ 21:00 │
│ 22:00 │
│ 23:00 │
└───┘
$ undertime --no-default-zone CET
┌───┐
│  CET  │
├───┤
│ 17:00 │
│ 18:00 │
│ 19:00 │
│ 20:00 │
│ 21:00 │
│ 22:00 │
│ 23:00 │
│ 00:00 │
│ 01:00 │
│ 01:21 │
│ 02:00 │
│ 03:00 │
│ 04:00 │
│ 05:00 │
│ 06:00 │
│ 07:00 │
│ 08:00 │
│ 09:00 │
│ 10:00 │
│ 11:00 │
│ 12:00 │
│ 13:00 │
│ 14:00 │
│ 15:00 │
│ 16:00 │
└───┘
$ undertime --no-default-zone Australia/Perth
┌─┐
│ Australia/Perth │
├─┤
│  00:00  │
│  01:00  │
│  02:00  │
│  03:00  │
│  04:00  │
│  05:00  │
│  06:00  │
│  07:00  │
│  08:00  │
│  08:17  │
│  09:00  │
│  10:00  │
│  11:00  │
│  12:00  │
│  13:00  │
│  14:00  │
│  15:00  │
│  16:00  │
│  17:00  │
│  18:00  │
│  19:00  │
│  20:00  │
│  21:00  │
│  22:00  │
│  23:00  │
└─┘
$ TZ=Australia/Perth undertime
┌───┐
│  AWST │
├───┤
│ 00:00 │
│ 01:00 │
│ 02:00 │
│ 03:00 │
│ 04:00 │
│ 05:00 │
│ 06:00 │
│ 07:00 │
│ 08:00 │
│ 08:20 │
│ 09:00 │
│ 10:00 │
│ 11:00 │
│ 12:00 │
│ 13:00 │
│ 14:00 │
│ 15:00 │
│ 16:00 │
│ 17:00 │
│ 18:00 │
│ 19:00 │
│ 20:00 │
│ 21:00 │
│ 22:00 │
│ 23:00 │
└───┘
$ count=0 ; for TZ in ** ; do set -- "$@" "$TZ" ; count=$((count+1)) ; if [ 
$count -eq 5 ] ; then undertime "$@" ; count=0 ; set -- ; fi ; done


-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages undertime depends on:
ii  python3 3.6.4-1
ii  python3-parsedatetime   2.4-2
ii  python3-termcolor   1.1.0-1
ii  python3-terminaltables  3.1.0-2
ii  python3-tz  2018.3-2

undertime recommends no packages.

undertime suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#891377: binutils: wrong description of per-arch binary packages

[Adam Borowski]

Source: binutils
Version: 2.30-5
Severity: minor

Hi!
The description of binutils-$TRIPLET packages is wrong and misleading:

 This package provides GNU assembler, linker and binary utilities
 for the aarch64-linux-gnu target, for use in a cross-compilation
 environment.
 .
 You don't need this package unless you plan to cross-compile programs
 for aarch64-linux-gnu.

Except, these packages are required for regular native builds as well,
"binutils" merely ships default symlinks these days.



Meow!
-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 4.15.0-00183-ga494935d9d25 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- no debconf information

Bug#891376: libgdbm-dev: headers (and other) files missing

[Mathias Millet]

Package: libgdbm-dev
Version: 1.14.1-3
Severity: important

Dear Maintainer,



   * What led up to the situation?

Trying to install third party programs ( https://github.com/ocaml/dbm )
that need the header file ndbm.h to compile.

* What exactly did you do (or not do) that was effective (or
 ineffective)?

It seems that libgdbm-dev should provide this file (or a similar one, 
gdbm-ndbm.h I guess),
as stated in the package files listing at 
https://packages.debian.org/buster/amd64/libgdbm-dev/filelist


It appears many files are missing when comparing the package content to 
this list.


   * What was the outcome of this action?

No further outcome.

   * What outcome did you expect instead?




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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgdbm-dev depends on:
ii  libc6-dev [libc-dev]  2.26-4
ii  libgdbm5  1.14.1-3

libgdbm-dev recommends no packages.

libgdbm-dev suggests no packages.

-- no debconf information

Bug#837081: netbeans: Crashes due to assertion failure in GLib

[Samuel Thibault]

Mark Cave-Ayland, on sam. 24 févr. 2018 12:53:58 +, wrote:
> Not that this was more than a casual observation but I was pondering the
> possibility of a memory leak somewhere in the C code?

I have investigated, and yes there are leaks there.  It'll be quite
invasive to fix, so I won't be able to push that to stretch.  But I
believe if you can confirm that at least the crashes are gone, we can
push the fix to stretch.

Samuel

Bug#891020: ppp: with SSTP: "CHAP authentication failed" since 2.4.7-2+1

[Chris Boot]

Control: severity -1 normal
Control: tags -1 moreinfo

On 21/02/18 15:02, Alexander Elbs wrote:
[snip]
> I am using SSTP (see http://sstp-client.sourceforge.net ) with ppp to
> establish a VPN connection. So far this worked fine.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Upgrading to 2.4.7-2+1 led to these messages in log file:
>   MS-CHAP authentication failed: E=691 Authentication failure
>   CHAP authentication failed
> And a VPN connection could no longer be established.
> 
> Downgrading to 2.4.7-1+4 helps. I also tried to unapply new patches.
> It seems the patch "replace-vendored-hash-functions.patch" introduced the 
> breakage:
> When I build ppp 2.4.7-2+1 without that patch a VPN connection can be 
> established.
[snip]

sstp-client isn't in Debian so there's a limit to how much I can help,
but did you try rebuilding the sstp-client packages against the latest
ppp-dev?

The new version deliberately breaks ABI for plugins, but there are
mechanisms for dealing with that in Debian. Any compiled ppp plugins
will need to be rebuilt against the new version.

Regards,
Chris

-- 
Chris Boot
bo...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#891375: qemu: FTBFS with glibc 2.27: error: static declaration of 'memfd_create' follows non-static declaration

[Aurelien Jarno]

Source: qemu
Version: 1:2.11+dfsg-1
Severity: important
Tags: patch
User: debian-gl...@lists.debian.org
Usertags: 2.27

qemu 1:2.11+dfsg-1 fails to build with glibc 2.27 (2.27-0experimental0
from experimental):

| cc -I/<>/qemu-2.11+dfsg/qemu-build/util -Iutil 
-I/<>/qemu-2.11+dfsg/tcg -I/<>/qemu-2.11+dfsg/tcg/i386 
-I/<>/qemu-2.11+dfsg/linux-headers 
-I/<>/qemu-2.11+dfsg/qemu-build/linux-headers -I. 
-I/<>/qemu-2.11+dfsg -I/<>/qemu-2.11+dfsg/accel/tcg 
-I/<>/qemu-2.11+dfsg/include -I/usr/include/pixman-1  
-DHAS_LIBSSH2_SFTP_FSYNC -pthread -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -DNCURSES_WIDECHAR -D_GNU_SOURCE 
-D_DEFAULT_SOURCE -I/usr/include/ncursesw -fPIE -DPIE -m64 -mcx16 -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv  -g -O2 
-fdebug-prefix-map=/<>/qemu-2.11+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
-DCONFIG_QEMU_DATAPATH='"/usr/share/qemu:/usr/share/seabios:/usr/lib/ipxe/qemu"'
 -DVENDOR_DEBIAN -Wexpansion-to-defined -Wendif-labels 
-Wno-shift-negative-value -Wno-missing-include-dirs -Wempty-body 
-Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition 
-Wtype-limits -fstack-protector-strong -I/usr/include/p11-kit-1
-I/usr/include/libpng16 -I/usr/include/spice-server -I/usr/include/spice-1 
-I/<>/qemu-2.11+dfsg/tests -I qga/qapi-generated -MMD -MP -MT 
util/memfd.o -MF util/memfd.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g   -c 
-o util/memfd.o /<>/qemu-2.11+dfsg/util/memfd.c

[...]

| /<>/qemu-2.11+dfsg/util/memfd.c:40:12: error: static declaration of 
'memfd_create' follows non-static declaration
|  static int memfd_create(const char *name, unsigned int flags)
 
[...]
 
| In file included from /usr/include/x86_64-linux-gnu/bits/mman-linux.h:115:0,
|  from /usr/include/x86_64-linux-gnu/bits/mman.h:45,
|  from /usr/include/x86_64-linux-gnu/sys/mman.h:41,
|  from 
/<>/qemu-2.11+dfsg/include/sysemu/os-posix.h:29,
|  from /<>/qemu-2.11+dfsg/include/qemu/osdep.h:104,
|  from /<>/qemu-2.11+dfsg/util/memfd.c:28:
| /usr/include/x86_64-linux-gnu/bits/mman-shared.h:46:5: note: previous 
declaration of 'memfd_create' was here
|  int memfd_create (const char *__name, unsigned int __flags) __THROW;
|  ^~~~
| /<>/qemu-2.11+dfsg/rules.mak:66: recipe for target 'util/memfd.o' 
failed
| make[1]: *** [util/memfd.o] Error 1
| make[1]: *** Waiting for unfinished jobs
| make[1]: Leaving directory '/<>/qemu-2.11+dfsg/qemu-build'
| debian/rules:119: recipe for target 'build-stamp' failed
| make: *** [build-stamp] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2
| 
| A full build log is available there:
| 
http://aws-logs.debian.net/2018/02/07/glibc-exp/qemu_2.11+dfsg-1_unstable_glibc-exp.log

glibc 2.27 added support for memfd_create. Unfortunately qemu also has
such a function to wrap the corresponding syscall. The configure script
tries to detect that, but fail to do so due to a wrong test.

This is fixed by the following upstream commit:
https://git.qemu.org/?p=qemu.git;a=commit;h=75e5b70e6b5dcc4f2219992d7cffa462aa406af0

Bug#891374: python-django-postorius: broken symlinks: /usr/share/doc/python-django-postorius/html/_static/*

[Andreas Beckmann]

Package: python-django-postorius
Version: 1.1.2-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

1m4.0s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/python-django-postorius/html/_static/js/theme.js -> 
../../../../../sphinx_rtd_theme/static/js/theme.js
  /usr/share/doc/python-django-postorius/html/_static/js/modernizr.min.js -> 
../../../../../sphinx_rtd_theme/static/js/modernizr.min.js
  
/usr/share/doc/python-django-postorius/html/_static/fonts/fontawesome-webfont.woff
 -> ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff
  
/usr/share/doc/python-django-postorius/html/_static/fonts/fontawesome-webfont.ttf
 -> ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.ttf
  
/usr/share/doc/python-django-postorius/html/_static/fonts/fontawesome-webfont.svg
 -> ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.svg
  
/usr/share/doc/python-django-postorius/html/_static/fonts/fontawesome-webfont.eot
 -> ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.eot
  
/usr/share/doc/python-django-postorius/html/_static/fonts/RobotoSlab-Regular.ttf
 -> ../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Regular.ttf
  /usr/share/doc/python-django-postorius/html/_static/fonts/RobotoSlab-Bold.ttf 
-> ../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Bold.ttf
  /usr/share/doc/python-django-postorius/html/_static/fonts/Lato-Regular.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.ttf
  /usr/share/doc/python-django-postorius/html/_static/fonts/Lato-Bold.ttf -> 
../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.ttf
  
/usr/share/doc/python-django-postorius/html/_static/fonts/Inconsolata-Regular.ttf
 -> ../../../../../sphinx_rtd_theme/static/fonts/Inconsolata-Regular.ttf
  
/usr/share/doc/python-django-postorius/html/_static/fonts/Inconsolata-Bold.ttf 
-> ../../../../../sphinx_rtd_theme/static/fonts/Inconsolata-Bold.ttf
  /usr/share/doc/python-django-postorius/html/_static/css/theme.css -> 
../../../../../sphinx_rtd_theme/static/css/theme.css
  /usr/share/doc/python-django-postorius/html/_static/css/badge_only.css -> 
../../../../../sphinx_rtd_theme/static/css/badge_only.css

Is python-django-postorius missing a
Depends/Recommends/Suggests: sphinx-rtd-theme-common?


cheers,

Andreas


python-django-postorius_1.1.2-1.log.gz
Description: application/gzip

Bug#891373: gridengine: FTBFS with glibc 2.27: undefined reference to `__alloca'

[Aurelien Jarno]

Source: gridengine
Version: 8.1.9+dfsg-7
Severity: important
User: debian-gl...@lists.debian.org
Usertags: 2.27

gridengine 8.1.9+dfsg-7 fails to build with glibc 2.27
(2.27-0experimental0 from experimental):

| make[4]: Entering directory 
'/<>/gridengine-8.1.9+dfsg/source/3rdparty/qmake/LINUXAMD64/glob'
| cc -DHAVE_CONFIG_H -I. -I../../glob -I..   -Wdate-time -D_FORTIFY_SOURCE=2  
-O2 -Wstrict-prototypes -DLINUX -DLINUXAMD64 -DLINUXAMD64 -D_GNU_SOURCE 
-DGETHOSTBYNAME_R6 -DGETHOSTBYADDR_R8 -DTARGET_64BIT -Wdate-time 
-D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>/gridengine-8.1.9+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -DSGE_PQS_API 
-DSPOOLING_dynamic -DSECURE -DHAVE_HWLOC=1 -DCOMPILE_DC 
-D__SGE_COMPILE_WITH_GETTEXT__ -D__SGE_NO_USERMAPPING__ -Wno-error 
-Wno-strict-prototypes -MT glob.o -MD -MP -MF .deps/glob.Tpo -c -o glob.o 
../../glob/glob.c
| cc -DHAVE_CONFIG_H -I. -I../../glob -I..   -Wdate-time -D_FORTIFY_SOURCE=2  
-O2 -Wstrict-prototypes -DLINUX -DLINUXAMD64 -DLINUXAMD64 -D_GNU_SOURCE 
-DGETHOSTBYNAME_R6 -DGETHOSTBYADDR_R8 -DTARGET_64BIT -Wdate-time 
-D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>/gridengine-8.1.9+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -DSGE_PQS_API 
-DSPOOLING_dynamic -DSECURE -DHAVE_HWLOC=1 -DCOMPILE_DC 
-D__SGE_COMPILE_WITH_GETTEXT__ -D__SGE_NO_USERMAPPING__ -Wno-error 
-Wno-strict-prototypes -MT fnmatch.o -MD -MP -MF .deps/fnmatch.Tpo -c -o 
fnmatch.o ../../glob/fnmatch.c
| mv -f .deps/fnmatch.Tpo .deps/fnmatch.Po
| ../../glob/glob.c: In function ‘glob’:
| ../../glob/glob.c:576:23: warning: implicit declaration of function 
‘__alloca’; did you mean ‘alloca’? [-Wimplicit-function-declaration]
|newp = (char *) __alloca (dirlen + 1);
|^~~~
|alloca
| ../../glob/glob.c:576:14: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
|newp = (char *) __alloca (dirlen + 1);
|   ^
| ../../glob/glob.c:704:15: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
| newp = (char *) __alloca (home_len + dirlen);
|^
| ../../glob/glob.c:727:15: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
| newp = (char *) __alloca (end_name - dirname);
|^
| ../../glob/glob.c:778:15: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
| newp = (char *) __alloca (home_len + rest_len + 1);
|^
| ../../glob/glob.c:809:11: warning: implicit declaration of function ‘__stat’; 
did you mean ‘__xstat’? [-Wimplicit-function-declaration]
|  : __stat (dirname, )) == 0
|^~
|__xstat
| ../../glob/glob.c: In function ‘glob_in_dir’:
| ../../glob/glob.c:1251:21: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
| char *fullname = (char *) __alloca (dirlen + 1 + patlen + 1);
|  ^
| ../../glob/glob.c:1278:12: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
| names = (struct globlink *) __alloca (sizeof (struct globlink));
| ^
| ../../glob/glob.c:1336:32: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
|  struct globlink *new = (struct globlink *)
| ^
| ../../glob/glob.c:1362:15: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
|names = (struct globlink *) __alloca (sizeof (struct globlink));
|^
| mv -f .deps/glob.Tpo .deps/glob.Po
| rm -f libglob.a
| ar cru libglob.a glob.o fnmatch.o 
| ar: `u' modifier ignored since `D' is the default (see `U')
| ranlib libglob.a
| make[4]: Leaving directory 
'/<>/gridengine-8.1.9+dfsg/source/3rdparty/qmake/LINUXAMD64/glob'
| Making all in config
 
[...]
 
| cc  -O2 -Wstrict-prototypes -DLINUX -DLINUXAMD64 -DLINUXAMD64 -D_GNU_SOURCE 
-DGETHOSTBYNAME_R6 -DGETHOSTBYADDR_R8 -DTARGET_64BIT -Wdate-time 
-D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>/gridengine-8.1.9+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -DSGE_PQS_API 
-DSPOOLING_dynamic -DSECURE -DHAVE_HWLOC=1 -DCOMPILE_DC 
-D__SGE_COMPILE_WITH_GETTEXT__ -D__SGE_NO_USERMAPPING__ -Wno-error 
-Wno-strict-prototypes  -L. -Wl,-z,relro -rdynamic 
-Wl,-rpath,\$ORIGIN/../../lib/lx-amd64 -o make ar.o arscan.o commands.o 
default.o dir.o expand.o file.o function.o getopt.o getopt1.o implicit.o job.o 
main.o misc.o read.o remake.o remote-sge.o rule.o signame.o strcache.o 
variable.o version.o vpath.o hash.o glob/libglob.a  -lm -lpthread
| glob/libglob.a(glob.o): In function `glob_in_dir':
| ./source/3rdparty/qmake/LINUXAMD64/glob/../../glob/glob.c:1362: undefined 
reference to `__alloca'
| ./source/3rdparty/qmake/LINUXAMD64/glob/../../glob/glob.c:1337: undefined 
reference to `__alloca'
| 

Bug#891161: cwidget: FTBFS with libncursesw6

[Manuel A. Fernandez Montecelo]

2018-02-24 8:54 GMT+01:00 Sven Joachim :
> On 2018-02-23 22:12 +0100, Sven Joachim wrote:
>
>> So I have good and bad news.  The good one is that this error was easy
>> to fix by casting the 0 to size_t, so that both parameters passed to
>> std::max have the same type.  See the attached patch.
>>
>> The bad news is that after rebuilding libcwidget3v5 against libncursesw6
>> aptitude no longer starts:
>>
>> ,
>> | $ aptitude
>> | aptitude: symbol lookup error: aptitude: undefined symbol: 
>> _ZN7cwidget7widgets6widget14dispatch_mouseEsiiim
>> | $ objdump -T /usr/lib/i386-linux-gnu/libcwidget.so.3.0.0 | grep 
>> widget14dispatch_mouse
>> | 000dde10 gDF .text  0002  Base
>> _ZN7cwidget7widgets6widget14dispatch_mouseEsiiij
>> `
>>
>> This is because mmask_t is of a different type in libncursesw6.  Looks
>> like I may have to go back to the drawing board in ncurses and re-enable
>> the "--with-mmask-t='long'" configure option there.  Oh well. :-(
>
> Grepping for mmask_t on codesearch.debian.net revealed 48 packages which
> might be using this datatype.  I will examine them more closely next
> week, but from a first look it seems that cwidget might very well be the
> only affected library.  If this turns out to be true, I would prefer to
> deal with the incompatibility in cwidget/aptitude rather than deviate
> from upstream's default in ncurses.
>
> So here is a possible plan:
>
> - Do *not* fix this bug in unstable now, to exclude the possibility of
>   the above symbol lookup error after a cwidget rebuild when the ncurses
>   transition starts.
>
> - After ncurses has been accepted in experimental, upload cwidget there
>   too.  Rename the library package again, say to libcwidget3v6, and
>   build-depend on libncurses-dev (>= 6.0+20180210) to ensure that it gets
>   linked against libncursesw6 rather than libncursesw5.
>
> - When the ncurses transition starts in unstable, both aptitude and
>   cwidget still FTBFS.  Upload the new cwidget package to unstable, get
>   aptitude binNMU'ed, and everyone is happy.
>
> Does this sound reasonable?

Yes, with the following comments/caveats (mostly reminders for myself,
or somebody else if ends up doing this):

- the "v5" suffix was for the GCC5 transition (changes due to C++11
ABI), the name should be "libcwidget4" or something.  I wanted to
change a couple of minor things and bump the soversion anyway, just
never find the time to sort out all of the details, so let's see :)

- I am the maintainer of both aptitude and cwidget, so no need to
sweat over problems, I can upload them in lockstep


Thanks for the detailed follow-up and taking care of these details :)


-- 
Manuel A. Fernandez Montecelo 

Bug#891372: kbuild: FTBFS with glibc 2.27: undefined reference to `__alloca'

[Aurelien Jarno]

Package: kbuild
Version: 1:0.1.9998svn3127+dfsg-1
Severity: important
User: debian-gl...@lists.debian.org
Usertags: 2.27

kbuild 1:0.1.9998svn3127+dfsg-1 fails to build with glibc 2.27
(2.27-0experimental0 from experimental):

| gcc -DHAVE_CONFIG_H -I. 
-I/<>/kbuild-0.1.9998svn3127+dfsg/src/kmk/glob -I..   -Wdate-time 
-D_FORTIFY_SOURCE=2  -g -O2 
-fdebug-prefix-map=/<>/kbuild-0.1.9998svn3127+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -MT glob.o -MD -MP 
-MF .deps/glob.Tpo -c -o glob.o 
/<>/kbuild-0.1.9998svn3127+dfsg/src/kmk/glob/glob.c
| /<>/kbuild-0.1.9998svn3127+dfsg/src/kmk/glob/glob.c: In function 
'glob':
| /<>/kbuild-0.1.9998svn3127+dfsg/src/kmk/glob/glob.c:577:23: 
warning: implicit declaration of function '__alloca'; did you mean 'alloca'? 
[-Wimplicit-function-declaration]
|newp = (char *) __alloca (dirlen + 1);
|^~~~
|alloca
| /<>/kbuild-0.1.9998svn3127+dfsg/src/kmk/glob/glob.c:577:14: 
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
|newp = (char *) __alloca (dirlen + 1);
|   ^
| /<>/kbuild-0.1.9998svn3127+dfsg/src/kmk/glob/glob.c:705:15: 
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
| newp = (char *) __alloca (home_len + dirlen);
|^
| /<>/kbuild-0.1.9998svn3127+dfsg/src/kmk/glob/glob.c:728:15: 
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
| newp = (char *) __alloca (end_name - dirname);
|^
| /<>/kbuild-0.1.9998svn3127+dfsg/src/kmk/glob/glob.c:779:15: 
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
| newp = (char *) __alloca (home_len + rest_len + 1);
|^
| /<>/kbuild-0.1.9998svn3127+dfsg/src/kmk/glob/glob.c:815:11: 
warning: implicit declaration of function '__stat'; did you mean '__xstat'? 
[-Wimplicit-function-declaration]
|  : __stat (dirname, )) == 0
|^~
|__xstat
| /<>/kbuild-0.1.9998svn3127+dfsg/src/kmk/glob/glob.c: In function 
'glob_in_dir':
| /<>/kbuild-0.1.9998svn3127+dfsg/src/kmk/glob/glob.c:1271:21: 
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
| char *fullname = (char *) __alloca (dirlen + 1 + patlen + 1);
|  ^
| /<>/kbuild-0.1.9998svn3127+dfsg/src/kmk/glob/glob.c:1302:12: 
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
| names = (struct globlink *) __alloca (sizeof (struct globlink));
| ^
| /<>/kbuild-0.1.9998svn3127+dfsg/src/kmk/glob/glob.c:1360:32: 
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
|  struct globlink *new = (struct globlink *)
| ^
| /<>/kbuild-0.1.9998svn3127+dfsg/src/kmk/glob/glob.c:1386:15: 
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
|names = (struct globlink *) __alloca (sizeof (struct globlink));
|^
| mv -f .deps/glob.Tpo .deps/glob.Po
| gcc -DHAVE_CONFIG_H -I. 
-I/<>/kbuild-0.1.9998svn3127+dfsg/src/kmk/glob -I..   -Wdate-time 
-D_FORTIFY_SOURCE=2  -g -O2 
-fdebug-prefix-map=/<>/kbuild-0.1.9998svn3127+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -MT fnmatch.o -MD -MP 
-MF .deps/fnmatch.Tpo -c -o fnmatch.o 
/<>/kbuild-0.1.9998svn3127+dfsg/src/kmk/glob/fnmatch.c
| mv -f .deps/fnmatch.Tpo .deps/fnmatch.Po
| rm -f libglob.a
| ar cru libglob.a glob.o fnmatch.o 
| ar: `u' modifier ignored since `D' is the default (see `U')
| ranlib libglob.a
| make[5]: Leaving directory 
'/<>/kbuild-0.1.9998svn3127+dfsg/out/linux.amd64/release/bootstrap/kmk/glob'

[...]

| gcc -Wall -Wextra -Wdeclaration-after-statement -Wshadow -Wpointer-arith 
-Wbad-function-cast -g -O2 
-fdebug-prefix-map=/<>/kbuild-0.1.9998svn3127+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security  -Wl,-z,relro 
-Wl,--as-needed -o kmk ar.o arscan.o commands.o default.o dir.o expand.o file.o 
function.o getopt.o getopt1.o implicit.o job.o main.o misc.o read.o remake.o 
remote-stub.o rule.o signame.o strcache.o variable.o version.o vpath.o hash.o 
expreval.o incdep.o strcache2.o alloccache.o kbuild.o kbuild-object.o 
electric.o md5.o kDep.o kbuild_version.o dos2unix.o maybe_con_fwrite.o 
kmkbuiltin.o append.o cat.o chmod.o cmp.o cmp_util.o cp.o cp_utils.o echo.o 
expr.o install.o kDepIDB.o kDepObj.o ln.o md5sum.o mkdir.o mv.o printf.o 
redirect.o rm.o rmdir.o sleep.o test.o touch.o err.o fts.o setmode.o strmode.o 
strlcpy.o osdep.o kbuild_protection.o common-env-and-cwd-opt.o glob/libglob.a  
| chmod.o: In function `kmk_builtin_chmod':
| ./out/linux.amd64/release/bootstrap/kmk/./src/kmk/kmkbuiltin/chmod.c:184: 
warning: lchmod is not implemented and will always fail
| glob/libglob.a(glob.o): In function `glob_in_dir':
| ./out/linux.amd64/release/bootstrap/kmk/glob/./src/kmk/glob/glob.c:1386: 
undefined 

Bug#891371: goobook: Missing dependency: python-setuptools

[debian]

Package: goobook
Version: 1.9-2
Severity: serious
Justification: Policy 7.2

Dear Maintainer,

the package is missing an dependency: python-setuptools


Without it just crashes when running:

Traceback (most recent call last):
  File "/usr/bin/goobook", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3147, 
in 
@_call_aside
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3131, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3160, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 666, 
in _build_master
ws.require(__requires__)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 984, 
in require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 870, 
in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'setuptools>=0.7' distribution was not 
found and is required by goobook


After installing it everything is fine.

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

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

Versions of packages goobook depends on:
ii  python2.7.14-4
ii  python-gdata  2.0.18+dfsg1-2
ii  python-httplib2   0.9.2+dfsg-1
ii  python-oauth2client   4.1.2-2
ii  python-pkg-resources  38.4.0-1
ii  python-simplejson 3.13.2-1

goobook recommends no packages.

Versions of packages goobook suggests:
pn  python-keyring  

-- no debconf information

Bug#891363: Acknowledgement (Diffoscope crashes when cleaning non-writeable temporary files/dirs)

[michal marzuchowski]

The issue can be reproduced by comparing two different official images 
from https://nixos.org/nixos/download.html, e.g. x86_64 and i686.
https://d3g5gsiof5omrk.cloudfront.net/nixos/17.09/nixos-17.09.3047.8bce347f02f/nixos-minimal-17.09.3047.8bce347f02f-x86_64-linux.iso
https://d3g5gsiof5omrk.cloudfront.net/nixos/17.09/nixos-17.09.3047.8bce347f02f/nixos-minimal-17.09.3047.8bce347f02f-i686-linux.iso

It takes over 1h to compare those 337M ISOs. I guess that minimal case 
would be non-writeable file in non-writeable directory in squashfs in 
ISO image. Neither tar nor squashfs alone triggered the issue (i.e. 
without ISO image).

Bug#891370: pki-base-java: broken symlink: /usr/share/pki/lib/pki-tools.jar -> ../../java/pki/pki-tools.jar

[Andreas Beckmann]

Package: pki-base-java
Version: 10.5.5-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m43.5s ERROR: FAIL: Broken symlinks:
  /usr/share/pki/lib/pki-tools.jar -> ../../java/pki/pki-tools.jar


Is pki-base-java missing a Depends/Recommends/Suggests: pki-tools?


cheers,

Andreas


pki-base-java_10.5.5-1.log.gz
Description: application/gzip

Bug#887640: SIGSEGVs in libcdio: double free or corruption

[Jack Underwood]

Hey,
I have been lurking following the progress on this since I discovered this bug 
reported on
gvfs-backends https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886278 which I 
traced back to libcdio.


And yes, as I commented there, the solution seems to get 2.0.0 out.

> As I look at  Debian packages for libcdio, I think it is early enough in
> the packaging of the 1.x that changing to 2.0 rather than 1.x wouldn't be a
> big deal. Right?


1.0.0 has already been packaged, and from what I can see from the NEWS file, 
the ABI changed twice
between 1.0.0 and 2.0 (once to 1.1 and then again to 2.0), which AFAIK means it 
needs a transition
to recompile dependent programmes on the new version.
http://git.savannah.gnu.org/cgit/libcdio.git/tree/NEWS?id=908ec296cdffbee8bfe9ff9196caa13a49262b91

Matthias Klose, whom I have CC'ed here, uploaded 2.0.0 to experimental on the 
30th January,
which auto-generated the transition tracker for this:

https://release.debian.org/transitions/html/auto-libcdio.html

I don't know the current state of play, Matthias Klose stated back in November 
2017 that they were

orphaning libcdio but still doing the then current transition, i.e. from 0.83 
(libcdio13) to 0.94 (libcdio16),
and they did the Ubuntu transition as well which they did before getting the 
all clear to begin the transition
from experimental to unstable.  No transition was needed from 0.94 to 1.0.0 as 
there was no ABI change.


I would offer to take take over the orphaned package, but I don't know how much 
time it would take (I have very little time at the moment), and I know almost 
nothing about packaging, so far only working on upstream projects in python.

The current Ubuntu transition exists here, but the Ubuntu transitioning process 
seems even more unclear than
the Debian one:
http://people.canonical.com/~ubuntu-archive/transitions/html/html/libcdio.html

Okay, that documents everything I know so far about the status of this.

Best,
Jack

Bug#891368: remake: FTBFS with glibc 2.27: undefined reference to `__alloca'

[Aurelien Jarno]

Package: remake
Version: 4.1+dbg1.3~dfsg.1-1
Severity: important
Tags: patch
User: debian-gl...@lists.debian.org
Usertags: 2.27

remake 4.1+dbg1.3~dfsg.1-1 fails to build with glibc 2.27
(2.27-0experimental0 from experimental):

| cc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-fdebug-prefix-map=/<>/remake-4.1+dbg1.3~dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o glob.o glob.c
| glob.c: In function 'glob':
| glob.c:581:23: warning: implicit declaration of function '__alloca'; did you 
mean 'alloca'? [-Wimplicit-function-declaration]
|newp = (char *) __alloca (dirlen + 1);
|^~~~
|alloca
| glob.c:581:14: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
|newp = (char *) __alloca (dirlen + 1);
|   ^
| glob.c:709:15: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
| newp = (char *) __alloca (home_len + dirlen);
|^
| glob.c:732:15: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
| newp = (char *) __alloca (end_name - dirname);
|^
| glob.c:783:15: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
| newp = (char *) __alloca (home_len + rest_len + 1);
|^
| glob.c:814:11: warning: implicit declaration of function '__stat'; did you 
mean '__xstat'? [-Wimplicit-function-declaration]
|  : __stat (dirname, )) == 0
|^~
|__xstat
| glob.c: In function 'glob_in_dir':
| glob.c:1256:21: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
| char *fullname = (char *) __alloca (dirlen + 1 + patlen + 1);
|  ^
| glob.c:1283:12: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
| names = (struct globlink *) __alloca (sizeof (struct globlink));
| ^
| glob.c:1341:32: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
|  struct globlink *new = (struct globlink *)
| ^
| glob.c:1367:15: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
|names = (struct globlink *) __alloca (sizeof (struct globlink));
|^

[...]

| gcc -pthread -I/usr/include/guile/2.0 -Wall -Wextra 
-Wdeclaration-after-statement -Wshadow -Wpointer-arith -Wbad-function-cast -g 
-O2 -fdebug-prefix-map=/<>/remake-4.1+dbg1.3~dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,--export-dynamic 
-Wl,-z,relro -o make alloc.o ar.o arscan.o buildargv.o commands.o default.o 
debug.o dir.o expand.o file_basic.o file.o function.o getopt.o getopt1.o 
globals.o guile.o hash.o implicit.o job.o load.o loadapi.o main.o misc.o 
output.o profile.o print.o read.o remake.o rule.o signame.o strcache.o trace.o 
variable.o version.o vpath.o remote-stub.o debugger/break.o debugger/cmd.o 
debugger/fns.o debugger/file2line.o debugger/msg.o debugger/stack.o 
glob/libglob.a -lguile-2.0 -lgc  -ldl -lreadline  -lreadline
| glob/libglob.a(glob.o): In function `glob_in_dir':
| ./glob/glob.c:1367: undefined reference to `__alloca'
| ./glob/glob.c:1342: undefined reference to `__alloca'
| ./glob/glob.c:1283: undefined reference to `__alloca'
| ./glob/glob.c:1256: undefined reference to `__alloca'
| glob/libglob.a(glob.o): In function `glob':
| ./glob/glob.c:581: undefined reference to `__alloca'
| glob/libglob.a(glob.o):./glob/glob.c:732: more undefined references to 
`__alloca' follow
| collect2: error: ld returned 1 exit status
| Makefile:1354: recipe for target 'make' failed
| make[3]: *** [make] Error 1
| make[3]: Leaving directory '/<>/remake-4.1+dbg1.3~dfsg.1'
| Makefile:906: recipe for target 'all-recursive' failed
| make[2]: *** [all-recursive] Error 1
| make[2]: Leaving directory '/<>/remake-4.1+dbg1.3~dfsg.1'
| Makefile:612: recipe for target 'all' failed
| make[1]: *** [all] Error 2
| make[1]: Leaving directory '/<>/remake-4.1+dbg1.3~dfsg.1'
| dh_auto_build: make -j1 returned exit code 2
| debian/rules:9: recipe for target 'build-arch' failed
| make: *** [build-arch] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

A full build log is available there:
http://aws-logs.debian.net/2018/02/07/glibc-exp/remake_4.1+dbg1.3~dfsg.1-1_unstable_glibc-exp.log

The problem is that the glibc 2.27 slightly changed its internal glob
implementation. make detects that it doesn't support the new
interface and switch to its internal implementation which is slightly
broken.

The attached patch fixes that by backporting two upstream commits from
the original make, which add support for the new interface.
diff -Nru remake-4.1+dbg1.3~dfsg.1/debian/patches/glob-glibc227.diff 
remake-4.1+dbg1.3~dfsg.1/debian/patches/glob-glibc227.diff
--- 

Bug#891369: gtk2-engines-pixbuf: broken symlinks: /usr/share/doc/gtk2-engines-pixbuf/{{README,NEWS}.gz,AUTHORS}

[Andreas Beckmann]

Package: gtk2-engines-pixbuf
Version: 2.24.32-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m29.3s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/gtk2-engines-pixbuf/README.gz -> ../libgtk2.0-common/README.gz
  /usr/share/doc/gtk2-engines-pixbuf/NEWS.gz -> ../libgtk2.0-common/NEWS.gz
  /usr/share/doc/gtk2-engines-pixbuf/AUTHORS -> ../libgtk2.0-common/AUTHORS


There is no (indirect) dependency from gtk2-engines-pixbuf to libgtk2.0-common.


cheers,

Andreas


gtk2-engines-pixbuf_2.24.32-1.log.gz
Description: application/gzip

Bug#891367: libsimbody-dev: broken symlink: /usr/share/doc/simbody/examples/bin -> ../../../../lib/x86_64-linux-gnu/simbody/examples

[Andreas Beckmann]

Package: libsimbody-dev
Version: 3.5.4+dfsg2-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m30.1s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/simbody/examples/bin -> 
../../../../lib/x86_64-linux-gnu/simbody/examples


cheers,

Andreas


libsimbody-dev_3.5.4+dfsg2-1.log.gz
Description: application/gzip

Bug#891247: sbuild: does not pass appropriate options to dpkg-genchanges for source-only .changes

[Guillem Jover]

Control: reassign -1 sbuild
Control: retitle -1 sbuild: does not pass appropriate options to 
dpkg-genchanges for source-only .changes

Hi!

On Fri, 2018-02-23 at 19:39:48 +0100, Arturo Borrero Gonzalez wrote:
> Package: dpkg-dev
> Version: 1.19.0.5
> Severity: normal

> when building stretch-backports package I used:
> 
>  % sbuild --build-dep-resolver=aptitude --debbuildopts="-v"
> 
> as recommended at https://wiki.debian.org/BuildingFormalBackports
> 
> However, when generating the source.changes file, the -v switch is ignored.
> It just generates the long changelog for the binary .changes file.

I'm not entirely sure what you mean by the long changelog entry for
the binary .changes file. But ISTR that sbuild builds a different
.changes for the source, and a quick check seems to confirm that one
does not get the stock dpkg-buildpackage options that can be accepted
by dpkg-genchanges passed through.

> It would be great to address that in order to properly support source-only 
> upload workflows.
> In fact, I don't even know were the source.changes file is being generated, 
> since is not reported
> by sbuild.

I guess, something for sbuild to fix, then. :)

Thanks,
Guillem

Bug#891366: libdwarf1: broken symlink: /usr/share/doc/libdwarf1/changelog.gz -> ChangeLog.gz

[Andreas Beckmann]

Package: libdwarf1
Version: 20180129-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m25.0s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/libdwarf1/changelog.gz -> ChangeLog.gz


cheers,

Andreas


libdwarf1_20180129-1.log.gz
Description: application/gzip

Bug#891365: make-dfsg: FTBFS with glibc 2.27: undefined reference to `__alloca'

[Aurelien Jarno]

Source: make-dfsg
Version: 4.2.1-1
Severity: important
Tags: patch
User: debian-gl...@lists.debian.org
Usertags: 2.27

make-dfsg 4.2.1-1 fails to build with glibc 2.27 (2.27-0experimental0 from
experimental):

| gcc -DHAVE_CONFIG_H -I. -I../../../glob -I..   -Wdate-time 
-D_FORTIFY_SOURCE=2  -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o glob.o 
../../../glob/glob.c
| gcc -DHAVE_CONFIG_H -I. -I../../../glob -I..   -Wdate-time 
-D_FORTIFY_SOURCE=2  -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o fnmatch.o 
../../../glob/fnmatch.c
| ../../../glob/glob.c:581:23: warning: implicit declaration of function 
'__alloca'; did you mean 'alloca'? [-Wimplicit-function-declaration]
|newp = (char *) __alloca (dirlen + 1);
|^~~~
|alloca
| ../../../glob/glob.c:581:14: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
|newp = (char *) __alloca (dirlen + 1);
|   ^
| ../../../glob/glob.c:709:15: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
| newp = (char *) __alloca (home_len + dirlen);
|^
| ../../../glob/glob.c:732:15: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
| newp = (char *) __alloca (end_name - dirname);
|^
| ../../../glob/glob.c:783:15: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
| newp = (char *) __alloca (home_len + rest_len + 1);
|^
| ../../../glob/glob.c:814:11: warning: implicit declaration of function 
'__stat'; did you mean '__xstat'? [-Wimplicit-function-declaration]
|  : __stat (dirname, )) == 0
|^~
|__xstat
| ../../../glob/glob.c: In function 'glob_in_dir':
| ../../../glob/glob.c:1256:21: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
| char *fullname = (char *) __alloca (dirlen + 1 + patlen + 1);
|  ^
| ../../../glob/glob.c:1283:12: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
| names = (struct globlink *) __alloca (sizeof (struct globlink));
| ^
| ../../../glob/glob.c:1341:32: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
|  struct globlink *new = (struct globlink *)
| ^
| ../../../glob/glob.c:1367:15: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
|names = (struct globlink *) __alloca (sizeof (struct globlink));
|^
| rm -f libglob.a
| ar cru libglob.a glob.o fnmatch.o 
| ar: `u' modifier ignored since `D' is the default (see `U')
| ranlib libglob.a

[...]

| gcc -pthread -I/usr/include/guile/2.0 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wl,--export-dynamic -Wl,-z,relro -o make ar.o arscan.o 
commands.o default.o dir.o expand.o file.o function.o getopt.o getopt1.o 
guile.o implicit.o job.o load.o loadapi.o main.o misc.o output.o read.o 
remake.o rule.o signame.o strcache.o variable.o version.o vpath.o hash.o 
remote-stub.o glob/libglob.a -lguile-2.0 -lgc  -ldl 
| glob/libglob.a(glob.o): In function `glob_in_dir':
| ./debian/build-make-guile/glob/../../../glob/glob.c:1367: undefined reference 
to `__alloca'
| ./debian/build-make-guile/glob/../../../glob/glob.c:1342: undefined reference 
to `__alloca'
| ./debian/build-make-guile/glob/../../../glob/glob.c:1283: undefined reference 
to `__alloca'
| ./debian/build-make-guile/glob/../../../glob/glob.c:1256: undefined reference 
to `__alloca'
| glob/libglob.a(glob.o): In function `glob':
| ./debian/build-make-guile/glob/../../../glob/glob.c:581: undefined reference 
to `__alloca'
| 
glob/libglob.a(glob.o):./debian/build-make-guile/glob/../../../glob/glob.c:732: 
more undefined references to `__alloca' follow
| collect2: error: ld returned 1 exit status
| Makefile:631: recipe for target 'make' failed
| make[4]: *** [make] Error 1
| make[4]: Leaving directory '/<>/debian/build-make-guile'
| Makefile:773: recipe for target 'all-recursive' failed
| make[3]: *** [all-recursive] Error 1
| make[3]: Leaving directory '/<>/debian/build-make-guile'
| Makefile:526: recipe for target 'all' failed
| make[2]: *** [all] Error 2
| make[2]: Leaving directory '/<>/debian/build-make-guile'
| dh_auto_build: cd debian/build-make-guile && make -j16 returned exit code 2
| debian/rules:40: recipe for target 'override_dh_auto_build' failed
| make[1]: *** [override_dh_auto_build] Error 2
| make[1]: Leaving directory '/<>'
| debian/rules:22: recipe for target 'build-arch' failed
| make: *** [build-arch] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

A full build log is available there (from a slightly older version):

Bug#891333: [Pkg-nagios-devel] Bug#891333: new upstream (2.8.1)

[Daniel Baumann]

Hi Alexander,

On 02/24/2018 05:45 PM, Alexander Wirt wrote:
> want to maintain it?

for the last 5 years I only maintain a few[0] packages in Debian. In
general I do not want to maintain more (as I did some years ago),
however, icinga is quite important to me, so I'd like to volunteer for this.

I'll prepare an updated package and get it uploaded through my usual
sponsor if this is alright with you.

> it is de facto without maintainer. 

Does this also extend to icingaweb2?

Regards,
Daniel

[0]
https://qa.debian.org/developer.php?email=daniel.baum...@progress-linux.org

Bug#891364: firmware-amd-graphics: please update amdgpu firmware for polaris10

[Wil van Lierop]

Package: firmware-amd-graphics
Version: 20170823-1
Severity: wishlist

Dear Maintainer,

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

   * What led up to the situation?
 dmesg repeatedly could not load firmware.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Manually installed latest polaris10 firmware.
   * What was the outcome of this action?
 It solved my problem.
   * What outcome did you expect instead?
 -

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



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

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

firmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
ii  initramfs-tools  0.130

-- no debconf information

-- debsums errors found:
debsums: changed file /lib/firmware/amdgpu/polaris10_uvd.bin (from 
firmware-amd-graphics package)

Bug#891363: Diffoscope crashes when cleaning non-writeable temporary files/dirs

[michal marzuchowski]

Package: diffoscope
Version: 90

When comparing two NixOS iso images (one pulled from website and one I 
built myself), diffoscope fails after or during printing results with 
(full error included at the bottom):
> PermissionError: [Errno 13] Permission denied: 'curl'
> Unable to delete 
> Traceback (most recent call last):
>   File 
> "/nix/store/1ipliryvqaxixffryxw1w7ckqly0sw35-diffoscope-90/lib/python3.6/site-packages/diffoscope/main.py",
>  
> line 412, in main
>     sys.exit(run_diffoscope(parsed_args))
> SystemExit: 1

It seems that diffoscope is not able to remove r-xr-xr-x temporary file:
> ~> find /tmp/tmpun51yx54_diffoscope -name curl -exec ls -gGd {} +
> dr-xr-xr-x 2   4096 Jan  1  1970 
> /tmp/tmpun51yx54_diffoscope/d1yxmlqavkg9pp02h3b20sn6wbw1ngmd-nixos-17.09.3047.8bce347f02f/nixos/pkgs/tools/networking/curl
> -r-xr-xr-x 1 151168 Jan  1  1970 
> /tmp/tmpun51yx54_diffoscope/dmchxbmdbk9616xl98f0a69wb55anmq6-curl-7.58.0-bin/bin/curl
> lrwxrwxrwx 1 68 Feb 24 22:10 
> /tmp/tmpun51yx54_diffoscope/plr0a7lnqmz4v453drw7q1ivrdrcamvj-system-path/bin/curl
>  
> -> /nix/store/dmchxbmdbk9616xl98f0a69wb55anmq6-curl-7.58.0-bin/bin/curl

The 'curl' seems to be first to be removed:
> ~> rm -r /tmp/tmpun51yx54_diffoscope
> rm: descend into write-protected directory 
> '/tmp/tmpun51yx54_diffoscope/dmchxbmdbk9616xl98f0a69wb55anmq6-curl-7.58.0-bin'?
>  
> y
> rm: descend into write-protected directory 
> '/tmp/tmpun51yx54_diffoscope/dmchxbmdbk9616xl98f0a69wb55anmq6-curl-7.58.0-bin/bin'?
>  
> y
> rm: remove write-protected regular file 
> '/tmp/tmpun51yx54_diffoscope/dmchxbmdbk9616xl98f0a69wb55anmq6-curl-7.58.0-bin/bin/curl'?
>  
> y
> rm: cannot remove 
> '/tmp/tmpun51yx54_diffoscope/dmchxbmdbk9616xl98f0a69wb55anmq6-curl-7.58.0-bin/bin/curl':
>  
> Permission denied
> rm: descend into write-protected directory 
> '/tmp/tmpun51yx54_diffoscope/a18nnq9b1vyh9f7f71w5lmip91cqr1px-gdbm-1.13'? 
> ^C

Non-writeable files and dirs are quite common for NixOS isos:
> ~> rm -r /tmp/tmpun51yx54_diffoscope
> rm: descend into write-protected directory 
> '/tmp/tmpun51yx54_diffoscope/dmchxbmdbk9616xl98f0a69wb55anmq6-curl-7.58.0-bin'?
>  
> y
> rm: descend into write-protected directory 
> '/tmp/tmpun51yx54_diffoscope/dmchxbmdbk9616xl98f0a69wb55anmq6-curl-7.58.0-bin/bin'?
>  
> y
> rm: remove write-protected regular file 
> '/tmp/tmpun51yx54_diffoscope/dmchxbmdbk9616xl98f0a69wb55anmq6-curl-7.58.0-bin/bin/curl'?
>  
> y
> rm: cannot remove 
> '/tmp/tmpun51yx54_diffoscope/dmchxbmdbk9616xl98f0a69wb55anmq6-curl-7.58.0-bin/bin/curl':
>  
> Permission denied
> rm: descend into write-protected directory 
> '/tmp/tmpun51yx54_diffoscope/a18nnq9b1vyh9f7f71w5lmip91cqr1px-gdbm-1.13'? 
> ^C

Full stacktrace:
> Unable to delete 
> Traceback (most recent call last):
>   File 
> "/nix/store/1ipliryvqaxixffryxw1w7ckqly0sw35-diffoscope-90/lib/python3.6/site-packages/diffoscope/main.py",
>  
> line 412, in main
>     sys.exit(run_diffoscope(parsed_args))
> SystemExit: 1
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File 
> "/nix/store/1ipliryvqaxixffryxw1w7ckqly0sw35-diffoscope-90/lib/python3.6/site-packages/diffoscope/tempfiles.py",
>  
> line 62, in clean_all_temp_files
>     x.cleanup()
>   File 
> "/nix/store/53dyjh7xjhnbibqllr7j27lk2h98n7j7-python3-3.6.4/lib/python3.6/tempfile.py",
>  
> line 811, in cleanup
>     _shutil.rmtree(self.name)
>   File 
> "/nix/store/53dyjh7xjhnbibqllr7j27lk2h98n7j7-python3-3.6.4/lib/python3.6/shutil.py",
>  
> line 480, in rmtree
>     _rmtree_safe_fd(fd, path, onerror)
>   File 
> "/nix/store/53dyjh7xjhnbibqllr7j27lk2h98n7j7-python3-3.6.4/lib/python3.6/shutil.py",
>  
> line 418, in _rmtree_safe_fd
>     _rmtree_safe_fd(dirfd, fullname, onerror)
>   File 
> "/nix/store/53dyjh7xjhnbibqllr7j27lk2h98n7j7-python3-3.6.4/lib/python3.6/shutil.py",
>  
> line 418, in _rmtree_safe_fd
>     _rmtree_safe_fd(dirfd, fullname, onerror)
>   File 
> "/nix/store/53dyjh7xjhnbibqllr7j27lk2h98n7j7-python3-3.6.4/lib/python3.6/shutil.py",
>  
> line 438, in _rmtree_safe_fd
>     onerror(os.unlink, fullname, sys.exc_info())
>   File 
> "/nix/store/53dyjh7xjhnbibqllr7j27lk2h98n7j7-python3-3.6.4/lib/python3.6/shutil.py",
>  
> line 436, in _rmtree_safe_fd
>     os.unlink(name, dir_fd=topfd)
> PermissionError: [Errno 13] Permission denied: 'curl'
> Unable to delete 
> Traceback (most recent call last):
>   File 
> "/nix/store/1ipliryvqaxixffryxw1w7ckqly0sw35-diffoscope-90/lib/python3.6/site-packages/diffoscope/main.py",
>  
> line 412, in main
>     sys.exit(run_diffoscope(parsed_args))
> SystemExit: 1
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File 
> "/nix/store/1ipliryvqaxixffryxw1w7ckqly0sw35-diffoscope-90/lib/python3.6/site-packages/diffoscope/tempfiles.py",
>  
> line 62, in clean_all_temp_files
>     x.cleanup()
>   File 
> 

Bug#890506: stretch-pu: package ntp/1:4.2.8p10+dfsg-3+deb9u2

[Bernhard Schmidt]

On 23.02.2018 18:44, Adam D. Barratt wrote:

Hi Adam,

> On Thu, 2018-02-15 at 12:55 +0100, Bernhard Schmidt wrote:
>> I'd like to update ntp in Stretch to fix Bug#887385. There have been
>> numerous
>> reports about ntpd segfaulting with the libc6 update from
>> stretch-proposed-updates or in sid. It does not happen on all
>> machines (I for
>> one did not see it once).
>>
>> There has been an upstream bug and an upstream patch to increase the
>> stack size. This patch has been part of sid/buster for some weeks now
>> and
>> one of the reporters on the bug confirmed it being fixed.
>>
> 
> Please go ahead.

Uploaded and ACCEPTed.

Bernhard

Bug#888353: moc: FTBFS with FFmpeg 3.5

[Elimar Riesebieter]

* James Cowgill  [2018-02-24 21:03 +]:

> Hi,
> 
> On 24/02/18 20:54, Elimar Riesebieter wrote:
> > Hi James,
> > 
> > * jcowg...@debian.org  [2018-01-24 22:26 +]:
> > 
> >> Source: moc
> >> Version: 1:2.6.0~svn-r2949-2
> >> Severity: important
> >> User: debian-multime...@lists.debian.org
> >> Usertags: ffmpeg-3.5-transition
> >>
> >> Hi,
> >>
> >> Your package FTBFS with the upcoming version 3.5 of FFmpeg.
> > 
> > Is there a ffmpeg version available to test our package build with?
> > I can't see version 4 flowing around at least at rmadison...
> 
> You can use "3.5" from experimental for the time being. When I uploaded
> it I thought they would call it 3.5, but instead they are going to call
> it 4.0. It's still the same thing though.

Thanks for the information.

Elimar
-- 
  Learned men are the cisterns of knowledge,
  not the fountainheads ;-)


signature.asc
Description: PGP signature

Bug#891362: mate-utils: mate-screenshot hangs when storage-folder is not accessible

[Michael Abel]

Package: mate-utils
Version: 1.16.0-1
Severity: normal

Dear Maintainer,

mate-screenshot hangs when the folder where the last screenshot was stored is
not accessible or not mounted.

To reproduce, take screenshot:
$ mate-screenshot
Store the screenshot to a test folder.
-> The the new location is stored.

Make it inaccessible:
$ chmod 000 
(Or unmount the place where the folder is)
(Deleting the folder will not reproduce the issue)

Make a new screenshot:
$ mate-screenshot
-> Busy loop with 100% CPU
-> Needs to be killed

Installed Versions:
$ mate-screenshot --version
mate-screenshot 1.16.0
Linux proteus 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64
GNU/Linux
$ apt show libc6 | grep ^Version
Version: 2.24-11+deb9u1
$ apt show mate-utils | grep ^Version
Version: 1.16.0-1



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

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

Versions of packages mate-utils depends on:
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-11+deb9u1
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libcanberra-gtk3-00.30-3
ii  libcanberra0  0.30-3
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2
ii  libgtk-3-03.22.11-1
ii  libgtop-2.0-102.34.2-1
ii  libice6   2:1.0.9-2
ii  libmate-panel-applet-4-1  1.16.2-1
ii  libmatedict6  1.16.0-1
ii  libpango-1.0-01.40.5-1
ii  libpangocairo-1.0-0   1.40.5-1
ii  libsm62:1.2.2-1+b3
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  mate-desktop-common   1.16.2-2
ii  mate-utils-common 1.16.0-1
ii  zlib1g1:1.2.8.dfsg-5

mate-utils recommends no packages.

mate-utils suggests no packages.

-- no debconf information

Bug#888353: moc: FTBFS with FFmpeg 3.5

[James Cowgill]

Hi,

On 24/02/18 20:54, Elimar Riesebieter wrote:
> Hi James,
> 
> * jcowg...@debian.org  [2018-01-24 22:26 +]:
> 
>> Source: moc
>> Version: 1:2.6.0~svn-r2949-2
>> Severity: important
>> User: debian-multime...@lists.debian.org
>> Usertags: ffmpeg-3.5-transition
>>
>> Hi,
>>
>> Your package FTBFS with the upcoming version 3.5 of FFmpeg.
> 
> Is there a ffmpeg version available to test our package build with?
> I can't see version 4 flowing around at least at rmadison...

You can use "3.5" from experimental for the time being. When I uploaded
it I thought they would call it 3.5, but instead they are going to call
it 4.0. It's still the same thing though.

James



signature.asc
Description: OpenPGP digital signature

Bug#891361: ITP: golang-github-armon-go-socks5 -- SOCKS5 server in Golang

[Christopher Hoskin]

Package: wnpp
Severity: wishlist
Owner: Christopher Hoskin 

* Package name: golang-github-armon-go-socks5
  Version : 0.0~git20160902.e753329-1
  Upstream Author : Armon Dadgar
* URL : https://github.com/armon/go-socks5
* License : Expat
  Programming Lang: Go
  Description : SOCKS5 server in Golang

 Provides the socks5 package that implements a SOCKS5 server
 (http://en.wikipedia.org/wiki/SOCKS).  SOCKS (Secure Sockets) is used
 to route traffic between a client and server through an intermediate
 proxy layer. This can be used to bypass firewalls or NATs.  Feature The
 package has the following features:
  * "No Auth" mode
  * User/Password authentication
  * Support for the CONNECT command
  * Rules to do granular filtering of commands
  * Custom DNS resolution
  * Unit tests
 The package lacks the following:
  * Support for the BIND command 
  * Support for the ASSOCIATE command

Bug#890590: libcomerr2:i386: no available i386 variant of transitional package

[Adam Conrad]

On Thu, Feb 22, 2018 at 04:06:06PM -0500, Theodore Ts'o wrote:
> 
> Thanks for the patch and the explatnation.  Hmmm... so that memans
> that if a package is every Arch:all, it's impossible to ever
> transition to Arch:any without running afoul of the potential for the
> package to be installed for multiple architectures.  Grump.

The inverse, surely.  If it's :any (and m-a:same), changing it to :all
won't work *if it has deps*.

If there weren't deps involved here, it would be fine, since replacing
two installations of old-package with one installation of new-package
would be exactly what you wanted.

But, due to there being deps, you end up with a situation where:

1) We upgrade any->all on the primary arch (say, amd64).
2) libold:amd64 brings in libnew:amd64, but nothing pulls in libnew:i386.
3) libold:i386 and libold:amd64 are now different versions.
4) The situation in (3) isn't allowed, so we remove i386.
5) Anything that depended on libold:i386 now needs to be removed.

Anyhow, with the exception of transitionals, it seems generally weird
that one would want to go from any+same to all, as those tend to cater
to very different types of packages, so meh.

... Adam

Bug#891360: python-magnumclient FTBFS: test failures

[Adrian Bunk]

Source: python-magnumclient
Version: 2.7.0-4
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-magnumclient.html

...
==
FAIL: magnumclient.tests.test_shell.ShellTest.test_main_endpoint_internal
magnumclient.tests.test_shell.ShellTest.test_main_endpoint_internal
--
_StringException: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in patched
return func(*args, **keywargs)
  File "magnumclient/tests/test_shell.py", line 296, in 
test_main_endpoint_internal
mock_client.assert_called_once_with(**expected_args)
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 948, in 
assert_called_once_with
return self.assert_called_with(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 937, in 
assert_called_with
six.raise_from(AssertionError(_error_message(cause)), cause)
  File "/usr/lib/python2.7/dist-packages/six.py", line 737, in raise_from
raise value
AssertionError: Expected call: Client(api_version='latest', auth_token=None, 
auth_url='http://no.where/v2.0', cloud=None, insecure=False, 
interface='internal', magnum_url=None, password='password', profile=None, 
project_domain_id=None, project_domain_name=None, project_id=None, 
project_name='project_name', region_name=None, service_type='container-infra', 
user_domain_id=None, user_domain_name=None, user_id=None, username='username')
Actual call: Client(api_version='latest', auth_token=None, 
auth_url='http://no.where/v2.0', cloud=None, insecure=False, 
interface='internal', magnum_url=None, password='password', 
project_domain_id=None, project_domain_name=None, project_id=None, 
project_name='project_name', region_name=None, service_type='container-infra', 
user_domain_id=None, user_domain_name=None, user_id=None, username='username')


==
FAIL: magnumclient.tests.test_shell.ShellTestKeystoneV3.test_main_no_region
magnumclient.tests.test_shell.ShellTestKeystoneV3.test_main_no_region
--
_StringException: Traceback (most recent call last):
  File "magnumclient/tests/test_shell.py", line 280, in test_main_no_region
self._test_main_region('bay-list', None)
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in patched
return func(*args, **keywargs)
  File "magnumclient/tests/test_shell.py", line 266, in _test_main_region
mock_client.assert_called_once_with(**expected_args)
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 948, in 
assert_called_once_with
return self.assert_called_with(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 937, in 
assert_called_with
six.raise_from(AssertionError(_error_message(cause)), cause)
  File "/usr/lib/python2.7/dist-packages/six.py", line 737, in raise_from
raise value
AssertionError: Expected call: Client(api_version='latest', auth_token=None, 
auth_url='http://no.where/v3', cloud=None, insecure=False, interface='public', 
magnum_url=None, password='password', profile=None, project_domain_id=None, 
project_domain_name=None, project_id=None, project_name='project_name', 
region_name=None, service_type='container-infra', user_domain_id=None, 
user_domain_name=None, user_id=None, username='username')
Actual call: Client(api_version='latest', auth_token=None, 
auth_url='http://no.where/v3', cloud=None, insecure=False, interface='public', 
magnum_url=None, password='password', project_domain_id=None, 
project_domain_name=None, project_id=None, project_name='project_name', 
region_name=None, service_type='container-infra', user_domain_id=None, 
user_domain_name=None, user_id=None, username='username')


==
FAIL: magnumclient.tests.test_shell.ShellTest.test_main_os_cloud
magnumclient.tests.test_shell.ShellTest.test_main_os_cloud
--
_StringException: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in patched
return func(*args, **keywargs)
  File "magnumclient/tests/test_shell.py", line 308, in test_main_os_cloud
mock_client.assert_called_once_with(**expected_args)
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 948, in 
assert_called_once_with
return self.assert_called_with(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 937, in 
assert_called_with
six.raise_from(AssertionError(_error_message(cause)), cause)
  File "/usr/lib/python2.7/dist-packages/six.py", line 737, in raise_from
raise value
AssertionError: Expected call: Client(api_version='latest', auth_token=None, 
auth_url=None, 

Bug#890922: sane: Agfa SnapScan 1212U does not work after upgrade to stretch.

[Jörg Frings-Fürst]

severity 890922 normal
tags 890922 +moreinfo
reassign 890922 sane-backends 1.0.25-4.1
thanks



Hello Michael,

thank you for spending your time helping to make Debian better with
this bug report.


Please can you attach your /etc/sand.d/snapscan.conf and the 
Directory listing ls -l /usr/share/sane/snapscan.

CU
Jörg 



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

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

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

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

IRC: j_...@freenode.net
 j_...@oftc.net

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

Bug#890866: mesa: regression vs mesa 17.3.3-1: crash on i915 triggered by running emacs

[Theodore Ts'o]

On Tue, Feb 20, 2018 at 11:37:12AM +0100, Andreas Boll wrote:
> 
> Thanks for reporting to upstream!
> Could you test Mesa 18.0.0~rc4-1 from experimental? According to [1]
> some GPU hangs are supposed to be fixed.

Per [1], I've tried 18.0.0~rc4-1, and it appears to fix the issue.
Also, I've since noticed there are similar GPU hangs happening with
17.3.3-1 --- it's just that they are much more easy to reproduce with
17.3.4-1.

Cheers,

- Ted

[1] https://bugs.freedesktop.org/show_bug.cgi?id=105169#c2

Bug#891359: pk4 FTBFS with golang-1.10-go

[Adrian Bunk]

Source: pk4
Version: 5
Severity: serious

https://buildd.debian.org/status/package.php?p=pk4=sid

...
   dh_auto_configure -a -O--buildsystem=golang
dh_auto_configure: Could not symlink 
obj-x86_64-linux-gnu/src/github.com/Debian/pk4/cmd/pk4/testdata/FileImplicit: 
No such file or directory
make: *** [debian/rules:19: build-arch] Error 2

Bug#891358: rawdns FTBFS with golang-1.10-go

[Adrian Bunk]

Source: rawdns
Version: 1.6~ds1-1
Severity: serious
Tags: buster sid

https://buildd.debian.org/status/package.php?p=rawdns=sid

...
dh build-arch --buildsystem=golang --with=golang
   dh_update_autotools_config -a -O--buildsystem=golang
   dh_auto_configure -a -O--buildsystem=golang
dh_auto_configure: Could not symlink 
obj-x86_64-linux-gnu/src/github.com/tianon/rawdns/version.go: No such file or 
directory
make: *** [debian/rules:6: build-arch] Error 2

Bug#891357: hexchat: Hexchat suddenly crash if cannot connect

[Genomian]

Package: hexchat
Version: 2.12.4-3
Severity: important

Dear Maintainer, if hexchat cannot connect to a irc server sometimes suddenly
crash if the window is clicked, please find the issue and fix it



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

Kernel: Linux 4.9.0-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages hexchat depends on:
ii  hexchat-common   2.12.4-3
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u1
ii  libcairo21.14.8-1
ii  libcanberra0 0.30-3
ii  libdbus-1-3  1.10.24-0+deb9u1
ii  libdbus-glib-1-2 0.108-2
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgtk2.0-0  2.24.31-2
ii  libnotify4   0.7.7-2
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpangoft2-1.0-01.40.5-1
ii  libproxy1v5  0.4.14-2
ii  libssl1.11.1.0f-3+deb9u1

Versions of packages hexchat recommends:
ii  gvfs-bin 1.30.4-1
ii  hexchat-perl 2.12.4-3
ii  hexchat-plugins  2.12.4-3
ii  hexchat-python3  2.12.4-3

Versions of packages hexchat suggests:
pn  hexchat-otr  
pn  unifont  

-- debconf-show failed

Bug#798564: debootstrap: Add scripts for kali releases

[Raphael Hertzog]

On Sat, 24 Feb 2018, Hideki Yamane wrote:
> On Thu, 10 Sep 2015 16:45:20 +0200 =?utf-8?q?Rapha=C3=ABl_Hertzog?= 
>  wrote:
> > I'd like debootstrap to have native support of the various kali releases.
> 
>  Patch attached, based on Bug#798562.

Thanks, but in the mean time our set of releases has evolved:
http://git.kali.org/gitweb/?p=packages/debootstrap.git;a=tree;f=scripts;h=efa42caf1253542f3b3af4731f0923fd3e420fa9;hb=refs/heads/kali/master

>  scripts/kali/kali | 9 +
>  scripts/kali/kali-current | 1 +
>  scripts/kali/kali-dev | 1 +
>  scripts/kali/kali-next| 1 +
>  scripts/kali/kali-rolling | 1 +
>  scripts/kali/moto | 1 +
>  scripts/kali/sana | 1 +

We only need kali-rolling, kali-dev and kali-last-snapshot.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#891356: golang-google-cloud FTBFS: FAIL google.golang.org/cloud/spanner

[Adrian Bunk]

Source: golang-google-cloud
Version: 0.9.0-4
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=golang-google-cloud=all=0.9.0-4=1519472771=0

...
=== RUN   TestRsdNonblockingStates
FATAL: 2018/02/24 11:45:48 grpc: Server.RegisterService after Server.Serve for 
"google.spanner.v1.Spanner"
FAILgoogle.golang.org/cloud/spanner 0.039s

Bug#798562: debootstrap: Support "scripts" sharing code with Debian but with different default_mirror and keyring

[Raphael Hertzog]

Hi,

On Sat, 24 Feb 2018, Hideki Yamane wrote:
> On Thu, 10 Sep 2015 16:22:25 +0200 =?utf-8?q?Rapha=C3=ABl_Hertzog?= 
>  wrote:
> > It might be possible to just move the code out in some separate
> > files that can be sourced from all the "script" files?
> 
>  I've made a PoC patch for this issue
>  - relocate scripts files to each distro directroy

I think this is not a good idea. The location of the scripts file is part
of the public interface since debootstrap takes a script file
as 4th parameter.

Or maybe it's a good idea because we are going to have collisions one day
between codenames of the various distributions but then you have to keep
the current files for a little longer and you probably should consider
further changes so that we can pass "debian/sid" or "kali/kali-rolling"
as 1st parameter (suite).

But this is also not required to implement this:

>  - split code from scripts/debian/sid

This part looks fine from a cursory review.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#891082: Fwd: Bug#891082: xvkbd: Regression in using some definition for mouse "back" a nd "forward" buttons

[Jean-Luc Coulon]

Hi Paul,

Le 24/02/2018 à 19:41, Paul Gevers a écrit :

Control: tags -1 patch confirmed

Hi Jean-Luc,

Are you in the position to test a patch?


Done...
And it works for me [tm]!

Whaou... very reactive!

Thanks and regards

Jezn-Luc



Paul


--- ../xvkbd-3.8/xvkbd.c2017-06-06 19:24:16.897060353 +0900
+++ xvkbd.c 2018-02-24 16:27:45.559394153 +0900
@@ -1513,6 +1513,11 @@
unsigned junk_u;
int cur_x, cur_y;
  
+  if (need_read_keymap) {

+need_read_keymap = FALSE;
+ReadKeymap();
+  }
+
shift_state = 0;
for (cp = str; *cp != '\0'; cp++) {
  if (0 < appres.text_delay) usleep(appres.text_delay * 1000);

Bug#888591: ck: diff for NMU version 0.6.0-1.1

[Adrian Bunk]

Control: tags 888591 + pending

Dear maintainer,

I've prepared an NMU for ck (versioned as 0.6.0-1.1) and uploaded
it to DELAYED/5. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

diff -Nru ck-0.6.0/debian/changelog ck-0.6.0/debian/changelog
--- ck-0.6.0/debian/changelog	2017-03-11 01:38:50.0 +0200
+++ ck-0.6.0/debian/changelog	2018-02-24 21:32:28.0 +0200
@@ -1,3 +1,11 @@
+ck (0.6.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch from Niels Thykier to fix FTBFS with
+debhelper >= 11.1. (Closes: #888591)
+
+ -- Adrian Bunk   Sat, 24 Feb 2018 21:32:28 +0200
+
 ck (0.6.0-1) unstable; urgency=medium
 
   * New upstream version 0.6.0
diff -Nru ck-0.6.0/debian/rules ck-0.6.0/debian/rules
--- ck-0.6.0/debian/rules	2017-03-11 01:38:50.0 +0200
+++ ck-0.6.0/debian/rules	2018-02-24 21:32:24.0 +0200
@@ -14,5 +14,10 @@
 %:
 	dh $@
 
+# The build target must not be empty.  Sadly because of how make
+# works, we have do duplicate the target in this case.
+build:
+	dh $@
+
 .PHONY: build
 

Bug#890485: xserver-xorg-core 1.19.6 crash

[Marek Vasut]

On 02/16/2018 02:55 PM, Andreas Boll wrote:
> On Fri, Feb 16, 2018 at 01:11:20PM +0100, Marek Vasut wrote:
>> On 02/16/2018 11:47 AM, Andreas Boll wrote:
>>> On Thu, Feb 15, 2018 at 09:54:43AM +0100, Marek Vasut wrote:
 Package: xserver-xorg-core
 Version: 2:1.19.6-1

 After update from 2:1.19.5-1 crashes with

 (EE) Backtrace:
 (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4d) [0x555939ea4e3d]
 (EE) 1: /usr/lib/xorg/Xorg (0x555939ced000+0x1bbbd9) [0x555939ea8bd9]
 (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f3fc30fa000+0x12180)
 [0x7f3fc310c180]
 (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x110) [0x7f3fc2d786a0]
 (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x1c7) [0x7f3fc2d79cf7]
 (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (0x7f3fc2d44000+0x76f87)
 [0x7f3fc2dbaf87]
 (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (0x7f3fc2d44000+0x7d27a)
 [0x7f3fc2dc127a]
 (EE) 7: /lib/x86_64-linux-gnu/libc.so.6 (0x7f3fc2d44000+0x7efdc)
 [0x7f3fc2dc2fdc]
 (EE) 8: /usr/lib/xorg/Xorg (PanoramiXCreateConnectionBlock+0x22d)
 [0x555939deaeed]
 (EE) 9: /usr/lib/xorg/Xorg (0x555939ced000+0x56d79) [0x555939d43d79]
 (EE) 10: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xea)
 [0x7f3fc2d64f2a]
 (EE) 11: /usr/lib/xorg/Xorg (_start+0x2a) [0x555939d2da3a]
 (EE)
 (EE)
 error:
 (EE) Caught signal 6 (Aborted). Server aborting

 Note that this did not crash in 1.19.5-1 and compiling this tag from
 debian xorg git makes the X11 work again, so something changed between
 those two revisions -- 1.19.5-1 and 1.19.6-1 .
> 
> The biggest change between those revisions is the new upstream
> xorg-server release 1.19.6. [1]
> 

>>> Please report this upstream at
>>> https://bugs.freedesktop.org/enter_bug.cgi?product=xorg=Server%2FExt%2FXinerama
>>> and let us know the bug number for tracking.
>>
>> 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.

-- 
Best regards,
Marek Vasut

Bug#890485: xserver-xorg-core 1.19.6 crash

[Marek Vasut]

[...]
>>> 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 .

-- 
Best regards,
Marek Vasut

Bug#883223: pcre2: Please switch to 3.0 (quilt)

[Sean Whitton]

Hello,

On Sat, Feb 24 2018, Jeremy Bicha wrote:

> After several months, I think we're repeating the same arguments and
> not really making any progress. So if you're unwilling to change, I
> suppose it's fine for this bug to be closed or wontfixed.

The next release of dgit will contain a tool called git-debrebase and a
workflow dgit-maint-rebase(7) which /might/ satisfy both of you.  So
perhaps hold off closing the bug until Matthew has an opportunity to
evaluate that tool.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#891355: network-manager-fortisslvpn: The /var/lib/NetworkManager-fortisslvpn\ folder doesn't exist

[gianogli]

Package: network-manager-fortisslvpn
Version: 1.2.8-1+b1
Severity: important

Dear Maintainer,

I tried to configure a SSL-VPN with a FortiNet appliance but it didn't work.
Into the /var/log/syslog file I saw an error regarding a non existing folder:

Feb 24 18:20:12 soprano NetworkManager[1107]:   [1519492812.3343] 
vpn-connection[0x55d68e8486e0,25910a3b-42eb-4126-aeec-542526cf5452,"SSLVPN 
Fortinet",0]: VPN connection: failed to connect: 'Creazione del file 
«/var/lib/NetworkManager-fortisslvpn/25910a3b-42eb-4126-aeec-542526cf5452.config.YYG2EZ»
 non riuscita: File o directory non esistente'

So I manually created the /var/lib/NetworkManager-fortisslvpn/ folder and all 
started working right.

Could you investigate about this issue?

Thanks,

   gian


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

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

Versions of packages network-manager-fortisslvpn depends on:
ii  libc62.26-6
ii  libglib2.0-0 2.54.3-2
ii  libnm0   1.10.4-1+b1
ii  network-manager  1.10.4-1+b1
ii  openfortivpn 1.6.0-1
ii  ppp  2.4.7-2+1

network-manager-fortisslvpn recommends no packages.

network-manager-fortisslvpn suggests no packages.

-- no debconf information

Bug#891354: O: trac-spamfilter -- Spam-prevention plugin for Trac

[W. Martin Borgert]

Package: wnpp
Severity: normal

Orphaning trac-spamfilter.

I never used this Trac plugin myself.

The package description is:
 This plugin attempts to reject contributions to Trac environments that contain
 spam. It can use the following techniques:
 .
  * Regular expressions
  * Akismet web service
  * IP throttling
  * IP blacklisting (requires python-dnspython package)
  * Bayesian filtering (requires spambayes package)

Bug#891331: Beta from SQLA are *not* to upload, and full of bugs

[Piotr Ożarowski]

[Thomas Goirand, 2018-02-24]
> Please upload a working version of SQLA in Experimental, for example 1.2.1,
> which is accepted by OpenStack, as per this document:

if 1.2.4 works in OpenStack, I will upload it directly into unstable. Is
that OK?

Bug#822766: Python3 binary for pyglet

[Yaroslav Halchenko]

On Sat, 24 Feb 2018, Rock Storm wrote:

> What's the status of this issue? 

it is stable. contributions would be welcome(d)

> Will it ever be a python3 binary package?

yes

> I fail to use the package 'python-pyglet' for a python3 application, I
> keep getting the following error even though the package is installed.

> ModuleNotFoundError: No module named 'pyglet'

expected since there is no python3 package

note that "native" python3 support came only with this 1.3.0 version

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#891353: O: email2trac

[W. Martin Borgert]

Package: wnpp
Severity: normal

I'm not using email2trac anymore and can't test it properly.
Note, that there is newer source code in GitLab:
https://gitlab.com/surfsara/email2trac

Bug#891033: dgit: Please integrate with pristine-tar

[Sean Whitton]

Hello Ian, Felipe,

Before I get into details, let me mention origtargz(1) from devscripts.
It will extract origs from pristine-tar branches if those exist, or pull
from the archive.

Whenever I get an error about a missing orig and it's not a new upstream
version, I just type `origtargz` and I don't recall it ever failing to
fix the problem :)

On Wed, Feb 21 2018, Ian Jackson wrote:

> I think there is probably a gbp rune that will just provide the
> upstream source tarball from the pristine tar branch.  I'm afraid I
> don't know how it's spelled, but you can probably use that as a
> workaround in the meantime.
>
> If you let me know what it is, that will be a small step towards
> implementing this feature :-).

It's --git-pristine-tar.  Look for that in gbp-buildpackage(1).

> Sean may disagree, but I don't think automatically generating missing
> origs from pristine tar branches is something that dgit should to by
> default.

I do not disagree.  I would like to see dgit's defaults remain suitable
for the subset of pure dgit workflows to which pristine-tar is
orthogonal.

(By a pure dgit workflow I just mean one that may involve simple scripts
like git-deborig but not a big tool like gbp or git-dpm.  pristine-tar
is orthogonal to a subset of the pure dgit workflows, which I consider
to be the best pure dgit workflows.  I'll avoid explaining that
orthogonality here, unless asked.)

> But it's certainly something we could have as an option, and maybe it
> should even be implied by --gbp.  And dgit could prompt the user to
> specify the relevant options, if it detected an pristine-tar or
> upstream branch.

Right.  We certainly want to make dgit+gbp convenient.

I wonder if we might just have an option that causes dgit to call
`origtargz` whenever it would error out due to a missing orig, and then
try again?  Or suggest to the user running that command?  I think I'd
prefer the latter, if the hint is not buried in other output.

That would do what's needed for this bug, and it centralises logic about
finding missing orig scripts to that script, rather than adding more
code to dgit.

> Related to this is #865905 "want better msg for missing .orig (eg due
> to accidental upstream version bump)".  #865905 mentions git-deborig
> which is also a thing that dgit should maybe be willing to use for
> this, when requested/configured.

git-deborig has the potential to generate an orig with a different hash
to the one in the archive and/or the pristine-tar branch (though
git-deborig's tarball would be identical to an orig downloaded from an
upstream's github releases page).  So I'm not sure it should happen
automatically.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#891347: Stop xgettext() from crashing when run with --its=FILE option

[Gunnar Hjalmarsson]

Sorry, the package version should be 0.19.8.1-4.

Attached please find a debdiff with the fix.

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj
diff -Nru gettext-0.19.8.1.orig/debian/changelog 
gettext-0.19.8.1/debian/changelog
--- gettext-0.19.8.1.orig/debian/changelog  2017-08-22 03:20:24.0 
+0200
+++ gettext-0.19.8.1/debian/changelog   2018-02-24 19:24:42.452655811 +0100
@@ -1,3 +1,11 @@
+gettext (0.19.8.1-5) unstable; urgency=medium
+
+  * debian/patches/04-fix-crash-xgettext-with-its.patch:
+- Stop xgettext() from crashing when run with --its=FILE option
+  Closes: #891347, LP: #1751261
+
+ -- Gunnar Hjalmarsson   Sat, 24 Feb 2018 19:24:00 +0100
+
 gettext (0.19.8.1-4) unstable; urgency=medium
 
   * Avoid extraneous NUL bytes in .mo files. Closes: #872869.
diff -Nru 
gettext-0.19.8.1.orig/debian/patches/04-fix-crash-xgettext-with-its.patch 
gettext-0.19.8.1/debian/patches/04-fix-crash-xgettext-with-its.patch
--- gettext-0.19.8.1.orig/debian/patches/04-fix-crash-xgettext-with-its.patch   
1970-01-01 01:00:00.0 +0100
+++ gettext-0.19.8.1/debian/patches/04-fix-crash-xgettext-with-its.patch
2018-02-23 21:40:12.801136733 +0100
@@ -0,0 +1,40 @@
+From: Bruno Haible 
+Date: Fri, 9 Dec 2016 20:04:31 + (+0100)
+Subject: Fix crash of xgettext with --its option.
+X-Git-Url: 
http://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff_plain;h=a0cab23332a254e3500cac2a3a984472d02180e5
+
+Fix crash of xgettext with --its option.
+
+* gettext-tools/src/xgettext.c (main): Free contents of its_dirs only when it
+was initialized. Fixes bug introduced on 2016-05-16.
+---
+
+diff --git a/gettext-tools/src/xgettext.c b/gettext-tools/src/xgettext.c
+index f848d76..a80ee51 100644
+--- a/gettext-tools/src/xgettext.c
 b/gettext-tools/src/xgettext.c
+@@ -330,7 +330,7 @@ main (int argc, char *argv[])
+   bool sort_by_msgid = false;
+   bool sort_by_filepos = false;
+   char **dirs;
+-  char **its_dirs;
++  char **its_dirs = NULL;
+   char *explicit_its_filename = NULL;
+   const char *file_name;
+   const char *files_from = NULL;
+@@ -1016,9 +1016,12 @@ warning: file '%s' extension '%s' is unknown; will try 
C"), filename, extension)
+   if (its_locating_rules)
+ locating_rule_list_free (its_locating_rules);
+ 
+-  for (i = 0; its_dirs[i] != NULL; i++)
+-free (its_dirs[i]);
+-  free (its_dirs);
++  if (its_dirs != NULL)
++{
++  for (i = 0; its_dirs[i] != NULL; i++)
++free (its_dirs[i]);
++  free (its_dirs);
++}
+ 
+   exit (EXIT_SUCCESS);
+ }
diff -Nru gettext-0.19.8.1.orig/debian/patches/series 
gettext-0.19.8.1/debian/patches/series
--- gettext-0.19.8.1.orig/debian/patches/series 2017-08-22 02:00:00.0 
+0200
+++ gettext-0.19.8.1/debian/patches/series  2018-02-23 21:41:51.725794456 
+0100
@@ -1,3 +1,4 @@
 01-do-not-use-java-in-urlget.patch
 02-msgfmt-remove-pot-creation-date.patch
 03-avoid-extraneous-nul-bytes.patch
+04-fix-crash-xgettext-with-its.patch

Bug#890875: Upload jquery-caret.js to unstable

[Balasankar C]

Heya,


On Thu, 22 Feb 2018 10:40:05 +1100 Ben Finney  wrote:
> Control: severity -1 wishlist
> Control: tags -1 + moreinfo
> 
> On 20-Feb-2018, Pirate Praveen wrote:
> 
> > I'd like to upload gitlab 9.5 currently in experimental to unstable.
> 
> (This request is no more severe than “wishlist”, by the definitions of
> the severity levels.)
> 
> Does the package currently in ‘experimental’ work? It should not be
> uploaded to ‘unstable’ unless it serves the need of a dependent
> package like Pagure or GitLab.
> 
> Please see bug#836408 for a request for testing, I have not seen any
> confirmation that the package works as-is.


I imitated the upstream test page (http://ichord.github.io/Caret.js/),
with the packaged JS file and it seems to be working similarly. I think
it is safe to assume the package is fit for unstable (and eventually
testing), where it may undergo more extensive tests and actual usage as
part of GitLab/Pagure packages.

Attaching my test file, in case someone else want to try. It is merely
the source of the upstream test page with the script tag pointing to the
packaged JS.

Regards
Balasankar C
Debian Developer
Title: Caret.js









Caret.js



Textarea




Type something here for fun!!



ContentEditable

Hello, some bold and italic and bold text


iframe body












-> Fork me on GitHub!









signature.asc
Description: OpenPGP digital signature

Bug#889616: nm.debian.org: please block DM applications until the key requirements are satisfied

[Enrico Zini]

On Fri, Feb 16, 2018 at 07:00:41PM +0100, Mattia Rizzolo wrote:

> > Let's be clear, the only rejected UID I recall
> > recently was someone applying for DM status who had added an @debian.org
> > email address to their key which they had no entitlement to. > keyring-maint hat>
> 
> There also was one with an UID with a completely different name from the
> others (I don't remember if that one was rejected by you or just frowned
> upon but later approved).

For the record, I have no problems with pseudonyms.

> > At the moment there is no requirement on Front Desk to get involved in a
> > process before it's been confirmed that an applicant has an advocate and
> > is ready to progress in their application. Your proposal would instead
> > require that Front Desk get involved at the start of any process and
> > prevent any action until they had done so. That pushes the up front work
> > from a large pool of potentials (the advocates) to a small, overworked
> > team (Front Desk).
> 
> Well, they already have to, to approve the key.
> Yes, this would block the processes until that (quite critical) part of
> the process is not cleared.

I like the idea that a process collects advocacies and statements of
intent before key requirements are satisfied. When a process shows up in
the AM dashboard with all requirements satisfied except key signatures,
ideally someone from Front Desk can realise that there are indeed people
who'd like to have that person become DM, and then try and help getting
signatures, like by asking where one lives, if one can move, mailing
-private asking for help, and so on.

That's the ideal thing. There's the problem that currently there seem to
be not enough people in Front Desk to do that. If the latter can be
solved, that'd be wonderful. If Front Desk cannot easily be restaffed,
I'd reevaluate the big picture of how to enter Debian in view of that.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Bug#891352: RM: gtetrinet -- RoM; unmaintained, depends on GNOME 2 libraries

[Jeremy Bicha]

Package: ftp.debian.org
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-Cc: gtetri...@packages.debian.org

gtetrinet has not had an upstream release since 2006. It depends on
several unmaintained GNOME 2 libraries: libgnome, libgnomeui, and
gconf, which we are trying to remove from Debian.

Please remove gtetrinet from Debian.

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#891351: scilab segfaults at startup

[Michel Briand]

Package: scilab
Version: 5.5.2-4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

scilab crashes at startup:

$ scilab
Segmentation fault

Packages installed are:

scilab 5.5.2-4
scilab-ann 0.4.2.4-1
scilab-celestlab 3.0.0-1-2
scilab-cli 5.5.2-4
scilab-data 5.5.2-4
scilab-doc 5.5.2-4
scilab-full-bin 5.5.2-4+b1
scilab-include 5.5.2-4+b1
scilab-minimal-bin 5.5.2-4+b1
scilab-plotlib 0.42-1
scilab-test 5.5.2-4

Best regards,
Michel

Debug:

$ scilab -debug
unning debug of Scilab [gdb]  :  gdb --args /usr/bin/scilab-bin -debug
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/scilab-bin...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/scilab-bin -debug
Installing openjdk unwinder
Traceback (most recent call last):
  File 
"/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so-gdb.py",
 line 52, in 
class Types(object):
  File 
"/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so-gdb.py",
 line 66, in Types
nmethodp_t = gdb.lookup_type('nmethod').pointer()
gdb.error: No type named nmethod.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffd35df700 (LWP 6521)]
[New Thread 0x7fffd34de700 (LWP 6522)]
[New Thread 0x7fffd33dd700 (LWP 6523)]
[New Thread 0x7fffd32dc700 (LWP 6524)]

Thread 1 "scilab-bin" received signal SIGSEGV, Segmentation fault.
0x77de30c9 in _dl_lookup_symbol_x (undef_name=0x7fffeee89102 "strlen", 
undef_map=0x77f86f18, ref=ref@entry=0x7fff8138, 
symbol_scope=0x77f87270, version=0x77f6a5a0, 
type_class=type_class@entry=1, flags=5, skip_map=0x0) at dl-lookup.c:833
833 dl-lookup.c: Aucun fichier ou dossier de ce type.
(gdb) bt
#0  0x77de30c9 in _dl_lookup_symbol_x (
undef_name=0x7fffeee89102 "strlen", undef_map=0x77f86f18, 
ref=ref@entry=0x7fff8138, symbol_scope=0x77f87270, 
version=0x77f6a5a0, type_class=type_class@entry=1, flags=5, 
skip_map=0x0) at dl-lookup.c:833
#1  0x77de7ca4 in _dl_fixup (l=, 
reloc_arg=) at ../elf/dl-runtime.c:111
#2  0x77def37f in _dl_runtime_resolve_sse ()
at ../sysdeps/x86_64/dl-trampoline.h:212
#3  0x7fffec88bd90 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x7fffec899038 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x77de2bc3 in do_lookup_x (
undef_name=undef_name@entry=0x7fffedd38e7e "__stpcpy_chk", 
new_hash=new_hash@entry=3373522011, 
old_hash=old_hash@entry=0x7fff84f0, ref=0x7fffedd34778, 
result=result@entry=0x7fff8500, scope=, 
i=, version=0x77f6a7c8, flags=1, skip=, 
type_class=1, undef_map=0x77f87960) at dl-lookup.c:423
#6  0x77de30d1 in _dl_lookup_symbol_x (
undef_name=0x7fffedd38e7e "__stpcpy_chk", undef_map=0x77f87960, 
ref=ref@entry=0x7fff85b8, symbol_scope=0x77f87cb8, 
version=0x77f6a7c8, type_class=type_class@entry=1, flags=1, 
skip_map=0x0) at dl-lookup.c:833
---Type  to continue, or q  to quit---
#7  0x77de7ca4 in _dl_fixup (l=, 
reloc_arg=) at ../elf/dl-runtime.c:111
#8  0x77def37f in _dl_runtime_resolve_sse ()
at ../sysdeps/x86_64/dl-trampoline.h:212
#9  0x77de9984 in _dl_name_match_p (
name=0x7fffa7b0 "\340\247\377\377\377\177", 
name@entry=0x7fffec89e906 "ld-linux-x86-64.so.2", 
map=map@entry=0x7fffad50) at dl-misc.c:295
#10 0x77de1699 in _dl_map_object (loader=0x7fff9780, 
name=0x7fffec89e906 "ld-linux-x86-64.so.2", type=1, trace_mode=0, 
mode=-30992, nsid=0) at dl-load.c:2186
#11 0x7fff9008 in ?? ()
#12 0x7fff9008 in ?? ()
#13 0x7fff9000 in ?? ()
#14 0x7fff8fff in ?? ()
#15 0x7fff8c0c in ?? ()
#16 0x7fff9170 in ?? ()
#17 0x812daafc8086f371 in ?? ()
#18 0x in ?? ()



-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (50, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr 

Bug#891349: with caja-dropbox from sid problem persists

[Nrbrtx]

I installed caja-dropbox 1.20.0-1 from sid, problem persists.

But `caja-dropbox autostart y` helps as before.