Bug#916879: qtox: missing library libsodium.so.18

[Adrian Bunk]

On Wed, Dec 19, 2018 at 09:43:05PM +0100, Christian Weinz wrote:
> Package: qtox
> Version: 1.16.3-1
> Severity: serious
> Justification: Policy 3.5
> 
> Dear Maintainer,
> 
> when trying to start qtox it fails with a missing shared library:
> 
> qtox: error while loading shared libraries: libsodium.so.18: cannot open 
> shared object file: No such file or directory
>...

What is the output of
  which qtox
?

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

Bug#874487: Debian mirror mirrors.gigenet.com: missing-tracefile, syncscript

[Peter Palfrader]

On Tue, 18 Dec 2018, Julien Cristau wrote:

> On 12/18/18 2:26 PM, Scott Ehas wrote:
> > Hello Peter,
> > 
> > We have updated the ftpsync.conf, and have reconfigured the cronjob. 
> > I'll check in a few hours to see if the sync has finished.
> > 
> > 00 03 * * * /opt/debiansync/bin/ftpsync sync:all
> > 00 06 * * * /opt/debiansync/bin/ftpsync sync:all
> > 00 12 * * * /opt/debiansync/bin/ftpsync sync:all
> > 00 21 * * * /opt/debiansync/bin/ftpsync sync:all
> > 
> Are you sure about that schedule?  That has a 3 hour interval and a 9
> hour one, instead of all 6.

Also, it appears to not work.

https://mirror-master.debian.org/status/mirror-info/mirrors.gigenet.com.html

It runs some syncing, but it never finishes successfully.

Please do investigate.
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#761880: [Pkg-sysvinit-devel] Bug#761880: sysv-rc: support init scripts in /lib/init.d (or similar)

[Ansgar Burchardt]

Control: reopen -1

Dmitry Bogatov  writes:

> control: tags -1 wontfix
>
> [2014-09-16 18:00] Ansgar Burchardt 
>> The symlinks in /etc/rc?.d/* and /etc/default/* are configuration files,
>> but init script themselves are not (and if admins are supposed to modify
>> them, I would call them buggy).
>
> Your proposal contradicts Debian Policy (9.3.2):

No, all scripts in /etc/init.d would still be treated as configuration
files.  Just packages could choose to *not* do that (as is the sane
way) by shipping init scripts in a different location.

Policy also seems to lag a decade behind reality:

>  The /etc/init.d scripts must be treated as configuration files, either
>  (if they are present in the package, that is, in the .deb file) by
>  marking them as conffiles, or, (if they do not exist in the .deb) by
>  managing them correctly in the maintainer scripts (see Configuration
>  files). This is important since we want to give the local system
>  administrator the chance to adapt the scripts to the local system,
>  e.g., to disable a service without de-installing the package, or to

It's possible to disable services without editing /etc/init.d/*.

>  specify some special command line options when starting a service,

It's possible to do that without editing /etc/init.d/*. (/etc/default/*)

Allowing packages to not have init scripts as configuration files would
help dealing with outdated init scripts (from removed, but not purged
packages) which cause problems (for example when they lack LSB headers,
have outdated dependencies which cause cirular dependencies, ...).

Ansgar

Bug#916818: rustc: Compiler regression results in generated code with unaligned access

[John Paul Adrian Glaubitz]

Control: tags -1 patch

Hello!

The attached patch reverts the problematic upstream commit and fixes
the problem for me.

Would it be possible to include it in the rustc source package and apply
it per platform, i.e. something like this in debian/rules:

ifeq ($(DEB_HOST_ARCH), sparc64)
patch -p1 < patches/sparc64-fix-bus-error.patch
endif

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Revert "Rely only on base alignment and offset for computing field alignment #54547"
Author: John Paul Adrian Glaubitz 
Bug: https://github.com/rust-lang/rust/issues/56927
Last-Update: 2018-12-19

--- rustc-1.31.0+dfsg1.orig/src/librustc_codegen_llvm/mir/place.rs
+++ rustc-1.31.0+dfsg1/src/librustc_codegen_llvm/mir/place.rs
@@ -177,7 +177,10 @@ impl PlaceRef<'ll, 'tcx> {
 let cx = bx.cx;
 let field = self.layout.field(cx, ix);
 let offset = self.layout.fields.offset(ix);
-let effective_field_align = self.align.restrict_for_offset(offset);
+let effective_field_align = self.align
+.min(self.layout.align)
+.min(field.align)
+.restrict_for_offset(offset);
 
 let simple = || {
 // Unions and newtypes only use an offset of 0.
--- rustc-1.31.0+dfsg1.orig/src/test/codegen/align-struct.rs
+++ rustc-1.31.0+dfsg1/src/test/codegen/align-struct.rs
@@ -48,16 +48,6 @@ pub fn align64(i : i32) -> Align64 {
 a64
 }
 
-// For issue 54028: make sure that we are specifying the correct alignment for fields of aligned
-// structs
-// CHECK-LABEL: @align64_load
-#[no_mangle]
-pub fn align64_load(a: Align64) -> i32 {
-// CHECK: [[FIELD:%.*]] = bitcast %Align64* %{{.*}} to i32*
-// CHECK: {{%.*}} = load i32, i32* [[FIELD]], align 64
-a.0
-}
-
 // CHECK-LABEL: @nested64
 #[no_mangle]
 pub fn nested64(a: Align64, b: i32, c: i32, d: i8) -> Nested64 {

Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile

[Roger Leigh]

On 19/12/2018 23:40, Dmitry Bogatov wrote:


control: tags -1 +moreinfo

[2015-12-01 23:07] Petter Reinholdtsen 

In my view, /etc/init.d/rc and /etc/init.d/rcS should not be
conffiles.  They should be moved to /lib/init/ instead.


Dear co-maintainers, what about actually moving /etc/init.d/{rc,rcS}
into /lib/init and adding symbolic links?

Any objections to this approach?


Not from me.  They aren't conffiles, and /lib/init is as good a place as 
any, unless you wanted to put them into /bin.  Ideally they would be 
best placed in /libexec, but this is banned in Debian for some dubious 
historical reasons.



Regards,
Roger

Bug#916069: transition: rocksdb

[GCS]

Hi Emilio,

On Wed, Dec 19, 2018 at 11:24 AM Emilio Pozuelo Monfort
 wrote:
> Control: tags -1 confirmed
>
> On 09/12/2018 20:03, László Böszörményi (GCS) wrote:
> > Minor transition of RocksDB 5.15.10 (Sid) -> 5.17.2 (experimental).
> > The only affected package is balboa which builds correctly with the
> > new version as well.
>
> Only one rdep, which builds fine, and with no conflicts with other transitions
> (per the transition tracker). You shouldn't need to ask in cases like this :)
 Agree, even if the binNMU still need from the RM side. As I often
traveling these days I can't follow transitions as close as I would
like to. Close to a release I better play safe than sorry.

> Anyway go ahead.
 Thanks, uploaded and built on most architectures (expect mips{,64}el
that can't keep up with the builds).

Cheers,
Laszlo/GCS

Bug#901246: closed by Bernhard Schmidt (Re: linphone-nogtk depends on X and OpenGL)

[Pali Rohár]

> This was indeed quite bad in 3.6.1 which was present in stretch.
> 
> In 3.12 the situation has improved a lot. It is not perfect yet, since
> linphone depends on libmediastreamer-voip10, which in turn depends on a
> lot of media libraries that sometimes do have a dependency on GL or X
> (i.e. libmediastreamer-voip10 -> libavcodec-extra58 -> libcairo2 or
> libmediastreamer-voip10 -> libavcodec-extra58 -> librsvg2-2 -> libpango).
> 
> I don't think these can be fixed in linphone.

Could you at least provide 3.12 for stretch-backports?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#916107: mongodb: MongoDB should not be part of a stable release

[Ivo De Decker]

Hi,

On Mon, Dec 10, 2018 at 11:01:11AM +0200, Apollon Oikonomopoulos wrote:
> MongoDB should not be part of (at least) Buster for the following 
> reasons:
> 
>  - MongoDB 3.4 will be EOL by June 2019[1], which is way too soon for it 
>to be included in Buster.
> 
>  - MongoDB 3.6 and 4.0 will be supported longer, but upstream's switch 
>to SSPLv1 complicates matters. As discussed in #915537, we will not 
>be distributing any SSPL-licensed software, and keeping the last 
>AGPL-licensed version (3.6.8 or 4.0.3) without the ability to 
>cherry-pick upstream fixes is not a viable option. (I am currently 
>not considering distributing mongodb in non-free.)
> 
> I will not request removal immediately, to allow other packages time to 
> adjust their dependencies, but eventually auto-removal will kick in.  

The auto-removals (from testing) will not kick in, because mongodb is a key
package. You'll need to file RC bugs against the rdeps. It's probably best to
make those bugs block this bug, to allow easy tracking.

For reference, the current output for dak rm -Rn -s testing mongodb is

Checking reverse dependencies...
# Broken Depends:
golang-github-juju-testing: golang-github-juju-testing-dev
loofah: python-loofah
nextepc: nextepc-hss [amd64 arm64 ppc64el s390x]
 nextepc-pcrf [amd64 arm64 ppc64el s390x]

# Broken Build-Depends:
aodh: mongodb
ceilometer: mongodb
golang-github-juju-testing: mongodb-server
libmongodb-perl: mongodb-server
mongo-java-driver: mongodb-server
zaqar: mongodb


Please note that some of these are also key packages with rdeps that might
need to be updated.

Thanks,

Ivo

Bug#916745: web2py2po and po2web2py fail to work ("convertpy() got an unexpected keyword argument 'duplicatestyle'" and "'ascii' codec can't encode character")

[Petter Reinholdtsen]

Control: tags -1 + patch

A patch fixing this issue is now available as a pull request upstream.
https://github.com/translate/translate/pull/3838 >.  It include
unit tests to verify the web2py support keep working in the future. :)

Would you be willing to include this patch in Debian before it is
included upstream?

-- 
Happy hacking
Petter Reinholdtsen

Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile

[KatolaZ]

On Wed, Dec 19, 2018 at 11:40:48PM +, Dmitry Bogatov wrote:
> 
> control: tags -1 +moreinfo
> 
> [2015-12-01 23:07] Petter Reinholdtsen 
> > In my view, /etc/init.d/rc and /etc/init.d/rcS should not be
> > conffiles.  They should be moved to /lib/init/ instead.
> 
> Dear co-maintainers, what about actually moving /etc/init.d/{rc,rcS}
> into /lib/init and adding symbolic links?
> 
> Any objections to this approach?

Why shall we move it at all?

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: PGP signature

Bug#916818: rustc: Compiler regression results in generated code with unaligned access

[John Paul Adrian Glaubitz]

Hi!

On 12/20/18 9:25 AM, John Paul Adrian Glaubitz wrote:
> The attached patch reverts the problematic upstream commit and fixes
> the problem for me.
> 
> Would it be possible to include it in the rustc source package and apply
> it per platform, i.e. something like this in debian/rules:

If that's not feasible, I can also create a patch which changes the alignment
behavior specific to sparc64 in the code, so the patch can be applied to all
platforms.

I'm still waiting for an opinion from upstream how this issue is going to
be fixed. They do consider it a bug as the alignment should always be correct.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#746678: [Pkg-sysvinit-devel] Bug#746678: Missing or inconsistent absolute location of /sbin/insserv

[Chris Lamb]

Dmitry,

> Absolute path to command is bad thing, codified in Lintian:

For a variety of reasons, please use debian-lint-
ma...@lists.debian.org for Lintian matters, not my personal email
address.


Regards,

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

Bug#916906: RM: python-treetime -- ROM; python-treetime switched to Python3 (in version 0.5.0) - please remove Python2 binary of version 0.2.4

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi,

upstream of python-treetime switched to Python3 and the binary
package python-treetime version 0.2.4 should be removed from
Debian.

Kind regards and thanks for your work as ftpmaster

  Andreas.

Bug#916907: pyscanfcs: fails to install (found by autopkgtest)

[Paul Gevers]

Source: pyscanfcs
Version: 0.3.2+ds-1
User: debian...@lists.debian.org
Usertags: needs-update
Severity: serious
Control: affects -1 src:python3-defaults

[X-Debbugs-CC: debian...@lists.debian.org,
python3-defau...@packages.debian.org]

Dear maintainers,

With a recent upload of python3-defaults the autopkgtest of pyscanfcs
fails in testing when that autopkgtest is run with the binary packages
of python3-defaults from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
python3-defaults   from testing3.7.1-3
pyscanfcs  from testing0.3.2+ds-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems your
package embedded the python3 supported versions in the file
/usr/share/python3/runtime.d/pyscanfcs.rtupdate while it doesn't
guarantee that the required packages are installed. I may be wrong, but
I think that file could  $(py3versions -vi) or something along those
lines. I have the feeling that the error message may be confusing, as I
see python3.6 installed so maybe (just maybe) the error should read
"unsupported version".

Currently this regression is contributing to the delay of the migration
of python3-defaults to testing [1]. Of course, python3-defaults
shouldn't just break your autopkgtest (or even worse, your package), but
that the change in python3-defaults was intended and your package needs
to update to the new situation.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pyscanfcs/1549682/log.gz

Setting up python3.6 (3.6.8~rc1-1) ...
Setting up gsettings-desktop-schemas (3.28.1-1) ...
Setting up python3 (3.7.1-3) ...
E: py3compile:243: Requested versions are not installed
error running python rtupdate hook pyscanfcs



signature.asc
Description: OpenPGP digital signature

Bug#907640: compiz: Migrating to compiz-reloaded?

[Samuel Thibault]

Hello,

Samuel Thibault, le jeu. 22 nov. 2018 19:08:37 +0100, a ecrit:
> Samuel Thibault, le jeu. 30 août 2018 17:26:27 +0200, a ecrit:
> > The launchpad upstream for compiz has switched to light maintenance mode
> > and will not make further development since Ubuntu has stopped using it.
> > 
> > How do people feel about switching to compiz-reloaded?
> > 
> > https://gitlab.com/compiz
> 
> No reaction, so we moved on :)
> 
> Compiz-reloaded 0.8.14 is currently in sid, and 0.8.16 is currently in
> experimental, up for your testing :)

0.8.16 just migrated to testing, with the ability of ezoom to track
focus events, implemented by Hypra, making it a very effective screen
magnifier.

Samuel

Bug#916908: ITP: ruby-idn -- LibIDN Ruby Bindings

[Youhei SASAKI]

Package: wnpp
Owner: Youhei SASAKI 
Severity: wishlist

* Package name: ruby-idn
  Version : 0.1.0
  Upstream Author : Erik Abele, Bharanee Rathna
* URL or Web page : https://github.com/deepfryed/idn-ruby
* License : Apache-2.0
  Description : LibIDN Ruby Bindings

Ruby Bindings for the GNU LibIDN library, an implementation of the
Stringprep, Punycode and IDNA specifications defined by the IETF
Internationalized Domain Names (IDN) working group.
.
Included are the most important parts of the Stringprep, Punycode
and IDNA APIs like performing Stringprep processings, encoding to
and decoding from Punycode strings and converting entire domain names
to and from the ACE encoded form.

--
Youhei SASAKI 
  
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07

Bug#915769: daisy-player: Buffer overflow loading a most probably valid DAISY book

[Colomban Wendling]

Package: daisy-player
Followup-For: Bug #915769

Indeed, it works in 11.6.2.1-1, thanks!

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

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

Versions of packages daisy-player depends on:
ii  libc6  2.27-6
ii  libcdio-cdda2  10.2+0.94+2-4
ii  libcdio-paranoia2  10.2+0.94+2-4
ii  libcdio18  2.0.0-2
ii  libmad00.15.1b-9
ii  libmagic1  1:5.34-2
ii  libncursesw6   6.1+20181013-1
ii  libpulse0  12.0-1
ii  libsox-fmt-mp3 14.4.2-3
ii  libsox-fmt-pulse   14.4.2-3
ii  libsox314.4.2-3
ii  libtinfo6  6.1+20181013-1
ii  libxml22.9.4+dfsg1-7+b1
ii  udisks22.8.1-1
ii  unar   1.10.1-2+b2

Versions of packages daisy-player recommends:
ii  libcddb-get-perl  2.28-2

daisy-player suggests no packages.

-- debconf-show failed

Bug#907640: compiz: Migrating to compiz-reloaded?

[Didier Spaier]

Hello,

On 20/12/2018 10:01, Samuel Thibault wrote:
> 0.8.16 just migrated to testing, with the ability of ezoom to track
> focus events, implemented by Hypra, making it a very effective screen
> magnifier.

Thanks for this!

FYT, I attach the shortcuts that will be set by  default in Slint.

Best,

Didier
This document lists the default key and mouse bindings or shortcuts
in Compiz as shipped in Slint64-14.2.1 since upgrade 2, i.e.
Slint64-14.2.1.2, for the plugins enabled by default.

The plugins enabled by default are, sorted by category as in the CCSM
or Compiz Config Settings Manager that can be started with the ccsm
command (typed with lower case letters):

Category General:
  core
  matecompat
Category Accessibility:
  addhelper
  colorfilter
  ezoom
  neg
  obs
  showmouse
Category Window Management:
  move
  resize
  switcher
Category Effects
  decoration
Category Utility
  focuspoll (no key or button bindings)
  glib (no key or mouse bindings)
  mousepoll (no key or button bindings)

In the default settings indicated below the key or mouse buttons are
named like this:

Alt: Alt Key
Control: Ctrl key
Super: Windows key on most keyboards
Shift: Shift key
Button1: Left Mouse Button (if used with the right hand)
Button2: Centre Mouse Button, or click with the scroll wheel)
Button3: Right Mouse Button (if used with the right hand)
Button4: Scroll Wheel Up
Button5: Scroll Wheel Down
Button6: (I don't know, I thought that was on mouses for gamers)

IMPORTANT: when a key is written between minus than and greater than
sign, like , this key should be held while performing
the action. For instance, Tab means "Keep the Control and
Alt keys pressed while pressing Tab".

The default settings listed below by category can be changed from the
CCSM. We indicate the short name of the plugin between square brackets.

1. Category General

[core] General options, tab "key bindings":
close_window_key = F4
raise_window_button = Button6
lower_window_button = Button6
minimize_window_key = F9
maximize_window_key = F10
unmaximize_window_key = F5
window_menu_key = space
window_menu_button = Button3
show_desktop_key = d
toggle_window_shaded_key = s

[matecompat] Mate Compatibility
main_menu_key = F1
run_key = F2

2. Category Accessibility 

[addhelper] Dim inactive (less light on non focused windows)
toggle_key = p

[colorfilter] (Filter color for accessibility purposes)
toggle_window_key = f
toggle_screen_key = d
switch_filter_key = s

[ezoom] Enhanced Zoom Desktop
zoom_in_button = Button4
zoom_out_button = Button5
zoom_box_button = Button2 (zoom out to go back to normal)

[neg] Negative (toggle inverse colors of the window or screen)
window_toggle_key = n
screen_toggle_key = m

[obs] Opacity, Brightness and Saturation adjustments
opacity_increase_button = Button4
opacity_decrease_button = Button5

[showmouse] (Increase visibilty of the mouse pointer)
initiate = k

5.Category Window Management

[move] Move window
initiate_button = Button1 (hold Button1 while moving the mouse)
initiate_key = F7 (Esc to stop moving)

[resize] Resize window
initiate_button = Button 2 hold Button2 while moving the mouse)
initiate_key = F8 (Esc to stop moving)

[switcher] Application switcher (switch between windows or panels and
 the desktop)
next_window_key = Tab (cycle between windows)
prev_window_key = Tab
next_panel_key = Tab (cycle between panels and desktop)
prev_panel_key = Tab

Didier Spaier


Last modified Tuesday 13 December 2018

Bug#916416: kazam unable to start: ValueError: Invalid section name: 'DEFAULT'

[Mostafa Moradian]

Hi Jajo,

This issue has been resolved by this PR:
https://github.com/hzbd/kazam/pull/21. I hope the maintainer of the GitHub
repo and the debian package merge it soon.

Regards,
Mostafa.

Bug#914392: marked as done (transition: coin3)

[Emilio Pozuelo Monfort]

Control: reopen -1

On 19/12/2018 23:51, Debian Bug Tracking System wrote:
>  coin3 (4.0.0~CMake~6f54f1602475+ds1-1) unstable; urgency=medium
>  .
>* Transition from experimental to unstable. Closes: #914392

The upload to sid doesn't end the transition. It only starts it. Now we'll
schedule the binNMUs once coin3 builds, and you can monitor the status on the
transition tracker and buildd pages and fix or file any bugs that pop up.

Cheers,
Emilio

Bug#916891: marked as done (mirror submission for debian.mirrors.theom.nz)

[Peter Palfrader]

Control: reopen 916891
thanks

Ok, I've removed the mirror again, for now.

The nameservers for the mirrors.theom.nz provide me with different
anders for the IP address of that mirror, and there is not a consistent
view across the different addresses.

Please fix and/or let us know what's going on.

Also, the TTL for debian.mirrors seems low.

> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: debian.mirrors.theom.nz
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: Theo M. 
> Country: NZ New Zealand
> Location: Auckland, Christchurch
> Sponsor: TheoM's Mirror Service https://theom.co.nz

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#916292: Kahan summation not working on i386

[Jerome Kieffer]

Hi,

This FBFS bug comes down to the POCL on i386 which is not able to
perform calculation as described by the OpenCL spec.

It is likely a numerical optimization at the wrong place as those tests
ensures the calculation are performed as expected.
This is described in:
https://en.wikipedia.org/wiki/Kahan_summation_algorithm#Possible_invalidation_by_compiler_optimization

If I find some time I could have a look at it, but on the other hand, pyFAI does
not support 32bits architecture as it requires often more than 2GB of memory
for real scientific application.

-- 
Jérôme Kieffer: core dev of pyFAI.

Bug#907624: What ffindex do we want to package

[Andreas Tille]

Ping?
Steffen, if you did not had a specific reason I assume it was by
mistake and will replace the Segfaulting code by the original one.
If I do not hear from you I assume you will agree.
Kind regards, Andreas.

On Wed, Dec 19, 2018 at 09:53:38AM +0100, Andreas Tille wrote:
> Hi,
> 
> after reading https://github.com/soedinglab/ffindex_soedinglab/issues/4
> I came to the conclusion that we somehow picked the wrong fork of
> ffindex.  For me it seems very probable that if we pick the old codebase
> bug #907624 which was introduced when choosing this will vanish if we
> revert to the previously packaged code base.  I have a local commit
> which is doing this:
> 
> 
> diff --git a/debian/changelog b/debian/changelog
> index 6a26115..c409f4f 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,12 @@
> +ffindex (0.9.9.7+sog+git20160415.14274c9-1) UNRELEASED; urgency=medium
> +
> +  * The previous location on Github was an improperly choosen fork
> +(see https://github.com/soedinglab/ffindex_soedinglab/issues/4)
> +Here the version is now named "0.9.9.7+sog" (Saved On Github)
> +to make it alphabethically later than the previous one.
> +
> + -- Andreas Tille   Wed, 19 Dec 2018 09:16:09 +0100
> +
>  ffindex (0.9.9.7+soedinglab+git20180802.74550c8-1) unstable; urgency=medium
>  
>* Fix watch file (version should actually be +git20171201.74550c8 but
> diff --git a/debian/watch b/debian/watch
> index 91b4f38..b47f123 100644
> --- a/debian/watch
> +++ b/debian/watch
> @@ -1,4 +1,4 @@
>  version=4
>  
> -opts="mode=git,pretty=0.9.9.7+soedinglab+git%cd.%h" \
> -https://github.com/soedinglab/ffindex_soedinglab.git HEAD
> +opts="mode=git,pretty=0.9.9.7+sog+git%cd.%h" \
> +https://github.com/ahcm/ffindex.git HEAD
> 
> 
> 
> Upstream at github.com/ahcm/ffindex was extremely quick to tag a
> release and so it is at least active.
> 
> Steffen, was your pick intentional or did you just stumbled by chance
> over the other fork?  Are you OK with reverting to the old code?
> 
> Kind regards
> 
>   Andreas.
> 
> PS: I reported the segfault issue to the according fork anyway
> https://github.com/soedinglab/ffindex_soedinglab/issues/7
> 
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Bug#916831: redis ftbfs with ld --as-needed as the default

[Chris Lamb]

Hi Matthias,

> But are the really loaded at runtime? scripting.o seems to have a hard-coded
> reference, which is needed for linking?

Hah, good point. Okay, as I understand it, the fix is just:

  commit e2e25f4fcd37030c06765c6c36441a01e1167ed9
  Author: Chris Lamb 
  Date:   Thu Dec 20 10:04:31 2018 +
  
  Pass --no-as-needed to ensure linking to the Lua libraries. (Closes: 
#916831)
  
  diff --git a/debian/rules b/debian/rules
  index 9bf4a6ac..9b9e897a 100755
  --- a/debian/rules
  +++ b/debian/rules
  @@ -16,7 +16,7 @@ LUA_LDFLAGS = $(addprefix -llua5.1-,$(LUA_LIBS_DEBIAN)) 
$(addprefix ../deps/lua/
   
   export CFLAGS CPPFLAGS LDFLAGS
   export DEB_BUILD_MAINT_OPTIONS = hardening=+all
  -export DEB_LDFLAGS_MAINT_APPEND = -ldl -latomic $(LUA_LDFLAGS)
  +export DEB_LDFLAGS_MAINT_APPEND = -Wl,-no-as-needed -ldl -latomic 
$(LUA_LDFLAGS)
   
   ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
NUMJOBS = $(patsubst parallel=%,%,$(filter 
parallel=%,$(DEB_BUILD_OPTIONS)))

I should really brush up on my linker knowledge one day...


Regards,

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

Bug#916903: RM: theme-d [armel] -- ROM; guile-2.2 is not available on armel

[Scott Kitterman]

On Thu, 20 Dec 2018 09:02:21 +0200 =?UTF-8?B?VG9tbWkgSMO2eW7DpGzDpG5tYWE=?= 
 wrote:
> Package: ftp.debian.org
> X-Debbugs-Cc: them...@packages.debian.org
> X-Debbugs-Cc: tommi.hoynalan...@iki.fi
> Affects: src:theme-d, src:theme-d-gnome
> 
> guile-2.2 doesn't build on armel currently. Therefore, please remove
> theme-d and theme-d-gnome from armel.
> 
> Only reverse dependency of theme-d in Debian is theme-d-gnome.
> Package theme-d-gnome has no reverse dependencies in Debian.
> 
> Seehttps://bugs.debian.org/883778  for more details about the guile armel 
issue.

Note that theme-d-gnome is arch all, so it doesn't exist in arch armel, it 
just becomes uninstallable.

Scott K

Bug#866323: Intent to NMU clutter-gtk to fix a longstanding l10n bug

[Helge Kreutzmann]

Dear Maintainers,
I propose to NMU clutter-gtk to solve the long standing translation bug
866323. I further would include fixes for the lintian
warning vcs-obsolete-in-debian-infrastructure (have you moved to salsa?).

I would prefer if you could add this to your next MU (before the
freeze), but if I don't hear from you I would upload this NMU
mid January.

If you have any questions do not hesitate to ask.

Greetings

   Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#916843: installed system not usable

[andrew glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> root@detst:/home/user# init 0
> bash: init: command not found
> root@detst:/home/user# shutdown -h now
> bash: shutdown: command not found
> root@detst:/home/user# ls
> reportbug-installation-report-20181219-847-hn9d0g_o
> root@detst:/home/user# aptitude update && aptitude upgrade
> Get: 1 http://security.debian.org/debian-security buster/updates InRelease
> [38.3 kB] Get: 2 http://ftp2.de.debian.org/debian buster InRelease [154
> kB] Get: 3 http://ftp2.de.debian.org/debian buster/main amd64
> Packages.diff/Index [27.9 kB] Get: 4 http://ftp2.de.debian.org/debian
> buster/main Translation-en.diff/Index [27.9 kB] Get: 5
> http://ftp2.de.debian.org/debian buster/contrib amd64 Packages.diff/Index
> [27.8 kB] Get: 6 http://ftp2.de.debian.org/debian buster/contrib
> Translation-en.diff/Index [27.8 kB] Get: 7 http://ftp2.de.debian.org/debian
> buster/main amd64 Packages 2018-12-19-1410.32.pdiff [1,102 B] Get: 8
> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> 2018-12-19-2010.27.pdiff [4,334 B] Get: 9 http://ftp2.de.debian.org/debian
> buster/main amd64 Packages 2018-12-20-0210.19.pdiff [33.2 kB] Get: 10
> http://ftp2.de.debian.org/debian buster/main Translation-en
> 2018-12-19-1410.32.pdiff [824 B] Get: 11 http://ftp2.de.debian.org/debian
> buster/main amd64 Packages 2018-12-20-0210.19.pdiff [33.2 kB] Get: 12
> http://ftp2.de.debian.org/debian buster/main Translation-en
> 2018-12-20-0210.19.pdiff [5,705 B] Get: 13 http://ftp2.de.debian.org/debian
> buster/contrib amd64 Packages 2018-12-20-0210.19.pdiff [2,765 B] Get: 14
> http://ftp2.de.debian.org/debian buster/main Translation-en
> 2018-12-20-0210.19.pdiff [5,705 B] Get: 15 http://ftp2.de.debian.org/debian
> buster/contrib Translation-en 2018-12-20-0210.19.pdiff [31 B] Get: 16
> http://ftp2.de.debian.org/debian buster/contrib amd64 Packages
> 2018-12-20-0210.19.pdiff [2,765 B] Get: 17 http://ftp2.de.debian.org/debian
> buster/contrib Translation-en 2018-12-20-0210.19.pdiff [31 B] Fetched 351
> kB in 8s (45.5 kB/s) Current status: 5 (+5) upgradable, 916 (+29) new.
> Resolving dependencies... The following NEW packages will be installed:
> libhunspell-1.7-0{a} The following packages will be REMOVED:
> libhunspell-1.6-0{u} The following packages will be upgraded:
> adwaita-icon-theme enchant gpgv libenchant1c2a libgpg-error0 The following
> packages are RECOMMENDED but will NOT be installed: libgpg-error-l10n 5
> packages upgraded, 1 newly installed, 1 to remove and 0 not upgraded. Need
> to get 12.5 MB/12.7 MB of archives. After unpacking 52.2 kB will be used.
> Do you want to continue? [Y/n/?] Get: 1 http://ftp2.de.debian.org/debian
> buster/main amd64 enchant amd64 1.6.0-11.1+b1 [18.7 kB] Get: 2
> http://ftp2.de.debian.org/debian buster/main amd64 libenchant1c2a amd64
> 1.6.0-11.1+b1 [69.8 kB] Get: 3 http://ftp2.de.debian.org/debian buster/main
> amd64 libgpg-error0 amd64 1.33-3 [70.6 kB] Get: 4
> http://ftp2.de.debian.org/debian buster/main amd64 gpgv amd64 2.2.12-1 [583
> kB] Get: 5 http://ftp2.de.debian.org/debian buster/main amd64
> adwaita-icon-theme all 3.30.1-1 [11.7 MB] Fetched 12.5 MB in 1s (10.2 MB/s)
> Reading changelogs... Done dpkg: warning: 'ldconfig' not found in PATH or
> not executable dpkg: warning: 'start-stop-daemon' not found in PATH or not
> executable dpkg: error: 2 expected programs not found in PATH or not
> executable Note: root's PATH should usually
> contain /usr/local/sbin, /usr/sbin and /sbin E: Sub-process /usr/bin/dpkg
> returned an error code (2) dpkg: warning: 'ldconfig' not found in PATH or
> not executable dpkg: warning: 'start-stop-daemon' not found in PATH or not
> executable dpkg: error: 2 expected programs not found in PATH or not
> executable Note: root's PATH should usually
> contain /usr/local/sbin, /usr/sbin and /sbin root@detst:/home/user# 
-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQTF9uNaslvnJpWt8kXn6sEfJS3nCwUCXBttuwAKCRDn6sEfJS3n
C643AKC4n31erd/V+z6uhPJAm5KuNFY4swCdHdgMxKHZNEt2gSpNtquVdqrdCCM=
=5GnU
-END PGP SIGNATURE-

Bug#916843: desktop-task not installable

[andrew glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


> root@detst:/home/user# tasksel
> tasksel: apt-get failed (100)
> root@detst:/home/user# ping www.debian.org
> PING www.debian.org (5.153.231.4) 56(84) bytes of data.
> 64 bytes from senfter.debian.org (5.153.231.4): icmp_seq=1 ttl=47 time=40.8
> ms 64 bytes from senfter.debian.org (5.153.231.4): icmp_seq=2 ttl=47
> time=39.1 ms ^C
> --- www.debian.org ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 2ms
> rtt min/avg/max/mdev = 39.080/39.935/40.791/0.878 ms
> root@detst:/home/user# aptitude search task
> p   ant-contrib-cpptasks- C/C++ compilation tasks for
> Ant. p   astro-tasks - Debian Astronomy Pure Blend
> (tasksel tasks) p   blends-tasks- Debian Pure
> Blends tasks for new installation p   debichem-tasks  -
> DebiChem tasks for tasksel p   education-tasks - Debian
> Edu tasks for tasksel p   electronics-tasks   - Debian
> Electronics tasks for tasksel p   fusioninventory-agent-task-collect  -
> collect task support for FusionInventory p
> fusioninventory-agent-task-deploy   - software deployment support for
> FusionInvento p   fusioninventory-agent-task-esx  - ESX and ESXi
> inventory for FusionInventory Ag p   fusioninventory-agent-task-network  -
> network device discovery for FusionInventory p
> games-tasks - Debian Games tasks for tasksel p
> gis-tasks   - Debian GIS tasks for tasksel v
> google-tasks-sync   - p
> hamradio-tasks  - Debian Hamradio Tasks v
> icedove-google-tasks-sync   - p
> junior-tasks- Debian Jr. tasks for tasksel p
> libaether-ant-tasks-java- Aether Ant Tasks p
> libcastor-anttasks-java - Data binding framework for Java (XML,
> Objects p   libfusioninventory-agent-task-deplo - transitional dummy
> package p   libfusioninventory-agent-task-esx-p - transitional dummy
> package p   libfusioninventory-agent-task-netin - transitional dummy
> package p   libfusioninventory-agent-task-netwo - transitional dummy
> package p   libfusioninventory-agent-task-snmpq - transitional dummy
> package p   libgettext-ant-tasks-java   - Java classes for
> internationalization (i18n) p   libkpimgapitasks5   -
> library to integrate with Google Tasks servic p
> libmono-microsoft-build-tasks-v4.0- - Mono Microsoft.Build.Tasks.v4.0
> library (for p   libmono-system-threading-tasks-data - Mono
> System.Threading.Tasks.Dataflow library p
> libmono-tasklets4.0-cil - Mono Tasklets library (for CLI 4.0)
> p   libmono-xbuild-tasks4.0-cil - Mono Mono.XBuild.Tasks library
> (for CLI 4.0) p   libtask-kensho-all-perl - provides all
> Task::Kensho tasks (metapackage) p   libtask-kensho-async-perl   -
> provides modules recommended for Task::Kensho p
> libtask-kensho-cli-perl - provides modules recommended for
> Task::Kensho p   libtask-kensho-config-perl  - provides modules
> recommended for Task::Kensho p   libtask-kensho-dates-perl   -
> provides modules recommended for Task::Kensho p
> libtask-kensho-dbdev-perl   - provides modules recommended for
> Task::Kensho p   libtask-kensho-email-perl   - provides modules
> recommended for Task::Kensho p   libtask-kensho-excelcsv-perl-
> provides modules recommended for Task::Kensho p
> libtask-kensho-exceptions-perl  - provides modules recommended for
> Task::Kensho p   libtask-kensho-hackery-perl - provides modules
> recommended for Task::Kensho p   libtask-kensho-logging-perl -
> provides modules recommended for Task::Kensho p
> libtask-kensho-moduledev-perl   - provides modules recommended for
> Task::Kensho p   libtask-kensho-oop-perl - provides modules
> recommended for Task::Kensho p   libtask-kensho-perl -
> recommended modules for Enlightened Perl deve p
> libtask-kensho-scalability-perl - provides modules recommended for
> Task::Kensho p   libtask-kensho-testing-perl - provides modules
> recommended for Task::Kensho p   libtask-kensho-toolchain-perl   -
> provides modules recommended for Task::Kensho p
> libtask-kensho-webcrawling-perl - provides modules recommended for
> Task::Kensho p   libtask-kensho-webdev-perl  - provides modules
> recommended for Task::Kensho p   libtask-kensho-xml-perl -
> provides modules recommended for Task::Kensho p
> libtask-weaken-perl - module for ensuring that a platform
> has weake p   libtaskmanager6 - Plasma Workspace for
> KF5 library p   live-task-base  - Live base environment
> support p   live-task-cinnamon  - Live environment support
> for Cinnamon p   live-task-extra - Live extra
> envir

Bug#916595: vlc: program doesn't close its process in some cases

[bitfreak25]

Hello Bernhard,

here is the output with your mentioned debug symbols and the new command.

Kind regards,
bitfreak25
Attaching to process 10449
[New LWP 10450]
[New LWP 10451]
[New LWP 10452]
[New LWP 10455]
[New LWP 10456]
[New LWP 10457]
[New LWP 10458]
[New LWP 10461]
[New LWP 10462]
[New LWP 10463]
[New LWP 10464]
[New LWP 10465]
[New LWP 10466]
[New LWP 10467]
[New LWP 10468]
[New LWP 10469]
[New LWP 10470]
[New LWP 10471]
[New LWP 10472]
[New LWP 10473]
[New LWP 10474]
[New LWP 10475]
[New LWP 10476]
[New LWP 10477]
[New LWP 10478]
[New LWP 10479]
[New LWP 10480]
[New LWP 10481]
[New LWP 10494]
[New LWP 10495]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f5fa8f08485 in __GI___pthread_timedjoin_ex (threadid=140048757475072, 
thread_return=thread_return@entry=0x0, abstime=abstime@entry=0x0, 
block=block@entry=true) at pthread_join_common.c:89
89  pthread_join_common.c: Datei oder Verzeichnis nicht gefunden.
  Id   Target Id   Frame 
* 1Thread 0x7f5fa8200100 (LWP 10449) "vlc" 0x7f5fa8f08485 
in __GI___pthread_timedjoin_ex (threadid=140048757475072, 
thread_return=thread_return@entry=0x0, abstime=abstime@entry=0x0, 
block=block@entry=true) at pthread_join_common.c:89
  2Thread 0x7f5fa2250700 (LWP 10450) "threaded-ml" 0x7f5fa8e27bd9 
in __GI___poll (fds=fds@entry=0x7f5f98007030, nfds=nfds@entry=3, 
timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  3Thread 0x7f5fa470c700 (LWP 10451) "vlc" 0x7f5fa8f08485 
in __GI___pthread_timedjoin_ex (threadid=140045812623104, 
thread_return=thread_return@entry=0x0, abstime=abstime@entry=0x0, 
block=block@entry=true) at pthread_join_common.c:89
  4Thread 0x7f5f9da4f700 (LWP 10452) "vlc" 0x7f5fa8e27bd9 
in __GI___poll (fds=fds@entry=0x7f5f9da4ed60, nfds=nfds@entry=2, 
timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  5Thread 0x7f5f83bf2700 (LWP 10455) "vlc" 0x7f5fa8e27bd9 
in __GI___poll (fds=0x7f5f78aae340, nfds=4, timeout=1557) at 
../sysdeps/unix/sysv/linux/poll.c:29
  6Thread 0x7f5f8301d700 (LWP 10456) "QXcbEventReader" 0x7f5fa8e27bd9 
in __GI___poll (fds=fds@entry=0x7f5f8301ccf8, nfds=nfds@entry=1, 
timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  7Thread 0x7f5f80aa1700 (LWP 10457) "gmain"   0x7f5fa8e27bd9 
in __GI___poll (fds=0x7f5f7811dcf0, nfds=1, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  8Thread 0x7f5f6700 (LWP 10458) "gdbus"   0x7f5fa8e27bd9 
in __GI___poll (fds=0x7f5f7812f040, nfds=2, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  9Thread 0x7f5f6ec85700 (LWP 10461) "QDBusConnection" 0x7f5fa8e27bd9 
in __GI___poll (fds=0x7f5f6000e410, nfds=3, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  10   Thread 0x7f5f802a0700 (LWP 10462) "vlc" 
futex_wait_cancelable (private=0, expected=0, futex_word=0x7f5f78381f40) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
  11   Thread 0x7f5f6cb89700 (LWP 10463) "vlc:cs0" 
futex_wait_cancelable (private=0, expected=0, futex_word=0x7f5f783f6fcc) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
  12   Thread 0x7f5f5bfff700 (LWP 10464) "vlc:disk$0"  
futex_wait_cancelable (private=0, expected=0, futex_word=0x7f5f7811f8c8) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
  13   Thread 0x7f5f5b7fe700 (LWP 10465) "vlc:sh0" 
futex_wait_cancelable (private=0, expected=0, futex_word=0x7f5f7847d6cc) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
  14   Thread 0x7f5f53fff700 (LWP 10466) "vlc:sh1" 
futex_wait_cancelable (private=0, expected=0, futex_word=0x7f5f7847d6cc) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
  15   Thread 0x7f5f5affd700 (LWP 10467) "vlc:sh2" 
futex_wait_cancelable (private=0, expected=0, futex_word=0x7f5f7847d6cc) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
  16   Thread 0x7f5f5a7fc700 (LWP 10468) "vlc:sh3" 
futex_wait_cancelable (private=0, expected=0, futex_word=0x7f5f7847d6cc) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
  17   Thread 0x7f5f59ffb700 (LWP 10469) "vlc:sh4" 
futex_wait_cancelable (private=0, expected=0, futex_word=0x7f5f7847d6cc) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
  18   Thread 0x7f5f597fa700 (LWP 10470) "vlc:sh5" 
futex_wait_cancelable (private=0, expected=0, futex_word=0x7f5f7847d6cc) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
  19   Thread 0x7f5f58ff9700 (LWP 10471) "vlc:sh6" 
futex_wait_cancelable (private=0, expected=0, futex_word=0x7f5f7847d6cc) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
  20   Thread 0x7f5f537fe700 (LWP 10472) "vlc:sh7" 
futex_wait_cancelable (private=0, expected=0, futex_word=0x7f5f7847d6cc) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
  21   Thread 0x7f5f52ffd700 (LWP 10

Bug#916753: Stop recommending s6

[Laurent Bigonville]

Le 19/12/18 à 00:28, Francesco Poli a écrit :

On Tue, 18 Dec 2018 10:18:56 +0100 Laurent Bigonville wrote:

[...]

Hi,

Hello Laurent,
thanks for asking the question and suggesting an alternative to s6.


I'm not too sure why you want to use s6-setuidgid (that requires an
extra package to be installed) when you have runuser tool that exists
precisely for this reason. runuser is available in the util-linux
package for quite some times already.

The fact is that, AFAIK, runuser seems to be equivalent to su, which is
not fit to *drop* root privileges (see the [web page] cited in
the commit).

[web page]:


I can agree that su might not the correct way of doing this mainly 
because the su pam service file is doing historically a lot of things.


Otoh, runuser pam service is doing the strict minimum on purpose (ie 
setting the limits based on the configuration and cleaning the kernel 
keyring).


And even if you think that runuser shouldn't be used, I still think that 
apt-listbugs shouldn't pull s6 and what you are trying to do here can 
perfectly be done in pure ruby without the call to an external program

Bug#717358: Incorrect comments in rc script

[Алексей Шилин]

В письме от среда, 19 декабря 2018 г. 23:40:53 MSK пользователь Dmitry Bogatov 
написал:
> I can confirm issue, but I am not that familiar with code to fix these
> misleading commends. What about just removing them for now?

That will do, I guess. If fixing them means explicitly stating that the 
following code does *not* run init scripts in parallel, then removing these 
comments altogether seems like a little more sensible solution. :)

A trivial (and most probably excessive) patch is attached.>From 232250d642439092942aaf3d4ea244cc74e260ba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B5=D0=B9=20=D0=A8=D0=B8?=
 =?UTF-8?q?=D0=BB=D0=B8=D0=BD?= 
Date: Thu, 20 Dec 2018 12:53:56 +0300
Subject: [PATCH] Remove incorrect comments from the 'rc' script

A couple of comments in the 'rc' script say that init scipts are being
run in parallel. However, the code flow suggests exactly the opposite:
they both occur in sections which are executed only if $CONCURRENCY
value is *not* "makefile", and therefor the non-parallel startup()
function variant is used.
---
 debian/src/sysv-rc/etc/init.d/rc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/debian/src/sysv-rc/etc/init.d/rc b/debian/src/sysv-rc/etc/init.d/rc
index 3f8841a3..1c0e3943 100644
--- a/debian/src/sysv-rc/etc/init.d/rc
+++ b/debian/src/sysv-rc/etc/init.d/rc
@@ -155,7 +155,6 @@ then
 		fi
 	elif [ "$previous" != N ]
 	then
-		# Run all scripts with the same level in parallel
 		CURLEVEL=""
 		for s in /etc/rc$runlevel.d/K*
 		do
@@ -204,7 +203,6 @@ then
 		fi
 	else
 		# Now run the START scripts for this runlevel.
-		# Run all scripts with the same level in parallel
 		CURLEVEL=""
 		for s in /etc/rc$runlevel.d/S*
 		do
-- 
2.11.0

Bug#916441: [Pkg-libvirt-maintainers] Bug#916441: Failed to create /var/lib/libvirt/.cache for shader cache (Permission denied)

[Laurent Bigonville]

Le 14/12/18 à 15:25, Guido Günther a écrit :

Hi,
On Fri, Dec 14, 2018 at 02:54:35PM +0100, Laurent Bigonville wrote:

Package: libvirt-daemon
Version: 4.10.0-1
Severity: normal
Tags: upstream

Hi,

When starting a domain with virgl support enabled, qemu complains that
/var/lib/libvirt/.cache doesn't exits.

AFAICS, mesa is using this directory to cache the generated shaders.

Mesa tries this location because it the XDG location for the cache
files. IMVHO, this should be moved to /var/cache/libvirt/ when running a
system domain by setting XDG_CACHE_HOME to that value.

That should maybe be coordinated with upstream first?

I guess it should. Any chance you can do this?

I opened https://bugzilla.redhat.com/show_bug.cgi?id=1659484

Bug#914530: fixed in lua-ldap 1.2.3-1

[Victor Seva]

Hi Daniel,

can you please test this patch.

Cheers,
Victor
From: Victor Seva 
Date: Thu, 20 Dec 2018 11:08:55 +0100
Subject: don't set global lualdap on lua > 5.1

---
 src/lualdap.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/lualdap.c b/src/lualdap.c
index f2404b8..5dd5971 100644
--- a/src/lualdap.c
+++ b/src/lualdap.c
@@ -1093,7 +1093,9 @@ int luaopen_lualdap (lua_State *L) {
 	lualdap_createmeta (L);
 	luaL_newlib(L, lualdap);
 	lua_pushvalue(L, -1);
+#if LUA_VERSION_NUM < 502
 	lua_setglobal(L, LUALDAP_TABLENAME);
+#endif
 	set_info (L);
 
 	return 1;

Bug#916884: [britney2] Does not consider B-D for migration to testing

[Adrian Bunk]

Control: forcemerge 145257 -1

On Wed, Dec 19, 2018 at 11:02:31PM +0100, Sebastian Andrzej Siewior wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: britney
> Severity: normal
> 
> Britney does not look at build dependencies before migrating a package.
> Therefore it can migrate a package to testing which build-depends did
> not yet migrate. As a result this package can be built in testing.

That's a duplicate of #145257.

> As an example: pass-tomb 1.1-2 migrated to testing while kcov was not in
> testing.

It used to be a lot worse, but has recently been fixed for binary-any
so only build dependencies for binary-all packages are left affected
by this bug.

> It has been pointed out on #d-release that there are checks this
> |< h01ger> https://qa.debian.org/dose/debcheck.html has links

I have an eye on the relevant pages for testing and unstable and file 
bugs on a nearly daily basis, but for testing-only issues there is 
usually no point in filing bugs far outside a freeze.

I'll start the bug filing for buster from early next year,
just like I did for stretch.

> Sebastian

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

Bug#916765: cups-browsed: Aborts when restarted with "BrowseFilter pdl postscript"

[Brian Potkin]

On Tue 18 Dec 2018 at 19:15:27 +0100, Bernhard Übelacker wrote:

> Hello Brian Potkin,
> you might want to install a core dump collector like systemd-coredump.
> 
> With that in place you might get a more verbose message in journalctl.

It is more verbose:

Dec 20 11:15:14 test systemd[1]: Reloading.
Dec 20 11:15:15 test systemd[1]: Listening on Process Core Dump Socket.
Dec 20 11:15:45 test systemd[1]: Started Make remote CUPS printers available 
locally.
Dec 20 11:15:45 test cups-browsed[13344]: free(): double free detected in 
tcache 2
Dec 20 11:15:45 test systemd[1]: Created slice system-systemd\x2dcoredump.slice.
Dec 20 11:15:45 test systemd[1]: Started Process Core Dump (PID 13347/UID 0).
Dec 20 11:15:45 test systemd[1]: cups-browsed.service: Main process exited, 
code=dumped, status=6/ABRT
Dec 20 11:15:45 test systemd[1]: cups-browsed.service: Failed with result 
'core-dump'.
Dec 20 11:15:45 test systemd-coredump[13348]: Process 13344 (cups-browsed) of 
user 0 dumped core.

  Stack trace of thread 13344:
  #0  0xb7f22d51 
__kernel_vsyscall (linux-gate.so.1)
  #1  0xb78492d2 raise 
(libc.so.6)
  #2  0xb78332b6 abort 
(libc.so.6)
  #3  0xb788ac0c n/a 
(libc.so.6)
  #4  0xb7891a1d n/a 
(libc.so.6)
  #5  0xb7893379 n/a 
(libc.so.6)
  #6  0xb7e608f9 avahi_free 
(libavahi-common.so.3)
  #7  0x004c2353 n/a 
(cups-browsed)
  #8  0x004c41fb n/a 
(cups-browsed)
  #9  0xb7e50d12 
avahi_service_resolver_event (libavahi-client.s 
 #10 0xb7e4c1c1 n/a (libavahi-client.so.3)
  #11 0xb747e1d7 
dbus_connection_dispatch (libdbus-1.so.3)
  #12 0xb7e52fe9 n/a 
(libavahi-client.so.3)
  #13 0xb7e42a23 n/a 
(libavahi-glib.so.1)
  #14 0xb7b03b2d 
g_main_context_dispatch (libglib-2.0.so.0)
  #15 0xb7b03de9 n/a 
(libglib-2.0.so.0)
  #16 0xb7b04189 
g_main_loop_run (libglib-2.0.so.0)
  #17 0x004b8b64 n/a 
(cups-browsed)
  #18 0xb7834b41 
__libc_start_main (libc.so.6)
  #19 0x004b98a1 n/a 
(cups-browsed)

  Stack trace of thread 13345:
  #0  0xb7f22d51 
__kernel_vsyscall (linux-gate.so.1)
  #1  0xb790964b __poll 
(libc.so.6)
  #2  0xb7b131b0 g_poll 
(libglib-2.0.so.0)
  #3  0xb7b03d53 n/a 
(libglib-2.0.so.0)
  #4  0xb7b03e94 
g_main_context_iteration (libglib-2.0.so.0)
  #5  0xb7b03ef0 n/a 
(libglib-2.0.so.0)
  #6  0xb7b2c8da n/a 
(libglib-2.0.so.0)
  #7  0xb7a00fd2 
start_thread (libpthread.so.0)
  #8  0xb79141b6 __clone 
(libc.so.6)

-- 
Brian.

Bug#916859: closed by Andrey Rahmatullin (Re: Bug#916859: RFS: PDF Studio Viewer/2018 [ITP] -- pdf viewer)

[Sven Hoexter]

On Wed, Dec 19, 2018 at 05:12:39PM -0500, Studio Support wrote:
> Hello Andrey,
> 
> Regarding the solution on Bug#916859 about our package "pdfstudioviewer"
> 
> It's free in the real sense of the term, meaning that users don't pay for it. 
> But it is not open source. Our end-user license is displayed to users upon 
> running our application the first time. 
> 
> We don't care if our application is listed under the Free or the Commercial 
> products. 
> 
> We have a Debian installer so I hope you can use that.

Hi,
I, and propably many more Debian developers, appreciate that you try to engange
with the Debian project, but really we're focused on open source software. You 
might
want to read https://www.debian.org/social_contract.html

So yes it's true that we have this sad part called "non-free" on our mirrors 
but formally
it's not really part of the distribution, and still everything shipped in 
non-free requires
to have a source package as well. 
https://wiki.debian.org/Packaging/SourcePackage

In the end I can only encourage you to open source your software, otherwise 
you've to move
on and distribute it via your own self hosted repository.

Sven

Bug#916909: 0ad game fails to start

[scdesign]

Package: 0ad
Version: 0.0.23-1+b2, 0.0.23-1-bpo9+1

After big upgrade of system libs via aptitude (also 0ad was updated from 
0.0.23-1 to 0.0.23-1+b2) the game fails to start with following error:

$ 0ad
/usr/games/pyrogenesis: symbol lookup error: /usr/games/pyrogenesis: undefined 
symbol: _ZN4nvtt12InputOptions16setTextureLayoutENS_11TextureTypeEiii

I propose it could be connected with some old lib that does not present in the 
dependencies.
Versions 0.0.22 and above from Ubuntu repos fail similarly.

Debian's build 0.0.21-2 starts well, probably it doesn't call for that function 
or use different version of the library.

Bug#916843: installed system not usable

[Steve McIntyre]

Hi Andrew,

On Thu, Dec 20, 2018 at 11:23:55AM +0100, andrew glaeser wrote:
>>
>> root@detst:/home/user# init 0
>> bash: init: command not found
>> root@detst:/home/user# shutdown -h now
>> bash: shutdown: command not found
>> root@detst:/home/user# ls
>> reportbug-installation-report-20181219-847-hn9d0g_o
>> root@detst:/home/user# aptitude update && aptitude upgrade
>> Get: 1 http://security.debian.org/debian-security buster/updates InRelease
>> [38.3 kB] Get: 2 http://ftp2.de.debian.org/debian buster InRelease [154
>> kB] Get: 3 http://ftp2.de.debian.org/debian buster/main amd64
>> Packages.diff/Index [27.9 kB] Get: 4 http://ftp2.de.debian.org/debian
>> buster/main Translation-en.diff/Index [27.9 kB] Get: 5
>> http://ftp2.de.debian.org/debian buster/contrib amd64 Packages.diff/Index
>> [27.8 kB] Get: 6 http://ftp2.de.debian.org/debian buster/contrib
>> Translation-en.diff/Index [27.8 kB] Get: 7 http://ftp2.de.debian.org/debian
>> buster/main amd64 Packages 2018-12-19-1410.32.pdiff [1,102 B] Get: 8
>> http://ftp2.de.debian.org/debian buster/main amd64 Packages
>> 2018-12-19-2010.27.pdiff [4,334 B] Get: 9 http://ftp2.de.debian.org/debian
>> buster/main amd64 Packages 2018-12-20-0210.19.pdiff [33.2 kB] Get: 10
>> http://ftp2.de.debian.org/debian buster/main Translation-en
>> 2018-12-19-1410.32.pdiff [824 B] Get: 11 http://ftp2.de.debian.org/debian
>> buster/main amd64 Packages 2018-12-20-0210.19.pdiff [33.2 kB] Get: 12
>> http://ftp2.de.debian.org/debian buster/main Translation-en
>> 2018-12-20-0210.19.pdiff [5,705 B] Get: 13 http://ftp2.de.debian.org/debian
>> buster/contrib amd64 Packages 2018-12-20-0210.19.pdiff [2,765 B] Get: 14
>> http://ftp2.de.debian.org/debian buster/main Translation-en
>> 2018-12-20-0210.19.pdiff [5,705 B] Get: 15 http://ftp2.de.debian.org/debian
>> buster/contrib Translation-en 2018-12-20-0210.19.pdiff [31 B] Get: 16
>> http://ftp2.de.debian.org/debian buster/contrib amd64 Packages
>> 2018-12-20-0210.19.pdiff [2,765 B] Get: 17 http://ftp2.de.debian.org/debian
>> buster/contrib Translation-en 2018-12-20-0210.19.pdiff [31 B] Fetched 351
>> kB in 8s (45.5 kB/s) Current status: 5 (+5) upgradable, 916 (+29) new.
>> Resolving dependencies... The following NEW packages will be installed:
>> libhunspell-1.7-0{a} The following packages will be REMOVED:
>> libhunspell-1.6-0{u} The following packages will be upgraded:
>> adwaita-icon-theme enchant gpgv libenchant1c2a libgpg-error0 The following
>> packages are RECOMMENDED but will NOT be installed: libgpg-error-l10n 5
>> packages upgraded, 1 newly installed, 1 to remove and 0 not upgraded. Need
>> to get 12.5 MB/12.7 MB of archives. After unpacking 52.2 kB will be used.
>> Do you want to continue? [Y/n/?] Get: 1 http://ftp2.de.debian.org/debian
>> buster/main amd64 enchant amd64 1.6.0-11.1+b1 [18.7 kB] Get: 2
>> http://ftp2.de.debian.org/debian buster/main amd64 libenchant1c2a amd64
>> 1.6.0-11.1+b1 [69.8 kB] Get: 3 http://ftp2.de.debian.org/debian buster/main
>> amd64 libgpg-error0 amd64 1.33-3 [70.6 kB] Get: 4
>> http://ftp2.de.debian.org/debian buster/main amd64 gpgv amd64 2.2.12-1 [583
>> kB] Get: 5 http://ftp2.de.debian.org/debian buster/main amd64
>> adwaita-icon-theme all 3.30.1-1 [11.7 MB] Fetched 12.5 MB in 1s (10.2 MB/s)
>> Reading changelogs... Done dpkg: warning: 'ldconfig' not found in PATH or
>> not executable dpkg: warning: 'start-stop-daemon' not found in PATH or not
>> executable dpkg: error: 2 expected programs not found in PATH or not
>> executable Note: root's PATH should usually
>> contain /usr/local/sbin, /usr/sbin and /sbin E: Sub-process /usr/bin/dpkg
>> returned an error code (2) dpkg: warning: 'ldconfig' not found in PATH or
>> not executable dpkg: warning: 'start-stop-daemon' not found in PATH or not
>> executable dpkg: error: 2 expected programs not found in PATH or not
>> executable Note: root's PATH should usually
>> contain /usr/local/sbin, /usr/sbin and /sbin root@detst:/home/user# 

I've been bitten by this myself, so I recognise the symptoms.

You've logged in and used "su" to switch to root. We've recently
switched to using the "su" provided by the util-linux source package
instead of the older one from shadow, and this is a consequence of
that change. To change environment properly, you need to use "su -"
instead.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I've only once written 'SQL is my bitch' in a comment. But that code 
 is in use on a military site..." -- Simon Booth

Bug#866323: Intent to NMU clutter-gtk to fix a longstanding l10n bug

[Simon McVittie]

On Thu, 20 Dec 2018 at 11:15:11 +0100, Helge Kreutzmann wrote:
> I propose to NMU clutter-gtk to solve the long standing translation bug
> 866323.

There is only a single translatable string, which should never be seen
under normal circumstances (it's an internal error, and the original
string is in "programmer English" rather than user-comprehensible
English), so I don't think this is at all urgent. I'm not entirely
sure why upstream marked that string for translation: translating
the jargon term "stock ID" hides the connection to GTK+ 2 APIs like
GTK_STOCK_FIND_AND_REPLACE and gtk_stock_add(). On the other hand,
upstream does have translations for it into non-German languages
already...

Has this proposed translation gone upstream to
?

Please could you propose it as a merge request into
 and/or upstream?
(Sorry, I don't know what supporting changes in the build system
are needed to go from a bare .po file to a fully-working translation.)

> I further would include fixes for the lintian
> warning vcs-obsolete-in-debian-infrastructure (have you moved to salsa?).

Yes, https://salsa.debian.org/gnome-team/clutter-gtk has some pending
commits, including the Vcs-Git update. All GNOME team packages have
undergone a similar move.

smcv

Bug#916768: closed by Mark Hindley (Re: Bug#916768: libelogind-dev-doc: missing Breaks+Replaces: libelogind-dev (<< 239.1+20181115-1))

[Mark Hindley]

On Thu, Dec 20, 2018 at 08:10:09AM +0100, Helmut Grohne wrote:
> Control: reopen 916750
> 
> Hi Mark,
> 
> On Wed, Dec 19, 2018 at 06:39:04PM +, Debian Bug Tracking System wrote:
> > Package: libelogind-dev-doc
> > Version: 239.3-4+debian1
> > 
> > Closing manually as upload had typo in bug number.
> > 
> > Sorry.
> 
> If you noticed your mistake and closed the right bug now, why didn't you
> reopen the bug you erroneously closed? Doing so now.

Helmut,

Apologies. I was going to but I have limited connectivity and wanted to 
make sure I did it right first: I wasn't clear if a reopen was 
sufficient.

Sorry for messing with your report.

Mark

Bug#916911: nitrokey-app: Please announce supported hardware via appstream

[Petter Reinholdtsen]

Package: nitrokey-app
Version: 1.3.1-1
Tags: patch

It would be nice if the package provided information about what hardware
it support to appstream, to allow the isenkram tool and other users of
appstream data to propose the package when the appropriate USB dongle is
inserted into a machine.

Here is a proposed patch to do so, based on the udev file included in
libnitrokey:

--- data/com.nitrokey.nitrokey-app.appdata.xml.~1~  2018-05-13 
08:58:17.0 +
+++ data/com.nitrokey.nitrokey-app.appdata.xml  2018-12-20 11:57:44.572350004 
+
@@ -21,6 +21,11 @@
   
   
  nitrokey-app
+ usb:v20A0p4107d*
+ usb:v20A0p4108d*
+ usb:v20A0p4109d*
+ usb:v20A0p4211d*
+ usb:v20A0p4230d*
   
   nitrokey-app.desktop
   https://www.nitrokey.com/

-- 
Happy hacking
Petter Reinholdtsen

Bug#916910: gdb: Hardware watchpoints do not trigger on i.MX6 (armhf)

[Bob Ham]

Package: gdb
Version: 8.2-1
Severity: normal

Dear Maintainer,

I'm trying to debug a complex program and came across this
reproducible behaviour.  On an i.MX6 QuadPlus CPU (Boundary Devices
Nitrogen6_Max board) hardware watchpoints are not triggered in my
complex case and in a trivial test case:

= t.c =
#include 

int main ()
{
  int a = 1;

  a = 2;

  printf("a: %i\n", a);

  return 0;
}
===


Compiled with `cc -g -O0 t.c -o t' using GCC (version (Debian
6.3.0-18+deb9u1) 6.3.0 20170516) on an amd64 box gives the following
successful triggers:

===
(gdb) l
1   #include 
2
3   int main ()
4   {
5 int a = 1;
6
7 a = 2;
8
9 printf("a: %i\n", a);
10
(gdb) 
11return 0;
12  }
(gdb) break 5
Breakpoint 1 at 0x6b8: file t.c, line 5.
(gdb) run
Starting program: /store-f/rah/proj/gdb-watchpoint/t 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, main () at t.c:5
5 int a = 1;
(gdb) p &a
$1 = (int *) 0x7fffe08c
(gdb) watch *0x7fffe08c
Hardware watchpoint 2: *0x7fffe08c
(gdb) c
Continuing.

Hardware watchpoint 2: *0x7fffe08c

Old value = 0
New value = 1
main () at t.c:7
7 a = 2;
(gdb) c
Continuing.

Hardware watchpoint 2: *0x7fffe08c

Old value = 1
New value = 2
main () at t.c:9
9 printf("a: %i\n", a);
(gdb) c
Continuing.
a: 2
===


However, compiling with GCC (version (Debian 8.2.0-12) 8.2.0) on the
i.MX6 board results in no trigger:

===
(gdb) break 5
Breakpoint 1 at 0x512: file t.c, line 5.
(gdb) run
Starting program: /srv/proj/chive/gdb-watchpoint/t 

Breakpoint 1, main () at t.c:5
5 int a = 1;
(gdb) p &a
$1 = (int *) 0xbefff46c
(gdb) watch *0xbefff46c
Hardware watchpoint 2: *0xbefff46c
(gdb) c
Continuing.
a: 2
[Inferior 1 (process 1435) exited normally]
===


The program contains writes to the `a' variable, as shown in the
following assembler extract:

===
 516:   2302movsr3, #2
 518:   607bstr r3, [r7, #4]
===

from the disassembled main function:

===
050c :
 50c:   b580push{r7, lr}
 50e:   b082sub sp, #8
 510:   af00add r7, sp, #0
 512:   2301movsr3, #1
 514:   607bstr r3, [r7, #4]
 516:   2302movsr3, #2
 518:   607bstr r3, [r7, #4]
 51a:   6879ldr r1, [r7, #4]
 51c:   4b04ldr r3, [pc, #16]   ; (530 )
 51e:   447badd r3, pc
 520:   4618mov r0, r3
 522:   f7ff ef54   blx 3cc 
 526:   2300movsr3, #0
 528:   4618mov r0, r3
 52a:   3708addsr7, #8
 52c:   46bdmov sp, r7
 52e:   bd80pop {r7, pc}
 530:   0062.word   0x0062
===


and as demonstrated in the following transcript:

===
(gdb) break 5
Breakpoint 1 at 0x512: file t.c, line 5.
(gdb) run
Starting program: /srv/proj/chive/gdb-watchpoint/t 

Breakpoint 1, main () at t.c:5
5 int a = 1;
(gdb) p &a
$1 = (int *) 0xbefff46c
(gdb) watch *0xbefff46c
Hardware watchpoint 2: *0xbefff46c
(gdb) display /x *((int *) 0xbefff46c)
1: /x *((int *) 0xbefff46c) = 0x0
(gdb) n
7 a = 2;
1: /x *((int *) 0xbefff46c) = 0x1
(gdb) n
9 printf("a: %i\n", a);
1: /x *((int *) 0xbefff46c) = 0x2
(gdb) c
Continuing.
a: 2
[Inferior 1 (process 1484) exited normally]
===


Regards,

Bob Ham


-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: armhf (armv7l)

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

Versions of packages gdb depends on:
ii  libbabeltrace1  1.5.6-2
ii  libc6   2.28-2
ii  libexpat1   2.2.6-1
ii  liblzma55.2.2-1.3
ii  libncursesw66.1+20181013-1
ii  libpython3.73.7.2~rc1-1
ii  libreadline77.0-5
ii  libtinfo6   6.1+20181013-1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages gdb recommends:
pn  libc-dbg  

Versions of packages gdb suggests:
pn  gdb-doc
ii  gdbserver  8.2-1

-- no debconf information

Bug#916909: 0ad game fails to start

[Simon McVittie]

On Thu, 20 Dec 2018 at 13:53:15 +0300, scdes...@yandex.ru wrote:
> After big upgrade of system libs via aptitude (also 0ad was updated from 
> 0.0.23-1 to 0.0.23-1+b2)

What packages were upgraded during that transaction? You can find out
from /var/log/apt/history.log.

> the game fails to start with following error:
> 
> $ 0ad
> /usr/games/pyrogenesis: symbol lookup error: /usr/games/pyrogenesis: 
> undefined symbol: 
> _ZN4nvtt12InputOptions16setTextureLayoutENS_11TextureTypeEiii

This is a serious bug in *something*, but I'm not sure what.

Please send the version numbers of the packages that your 0ad package
depends on. You can get this information with "reportbug --template
0ad"; it would be helpful to use reportbug to report bugs in future,
so that they already have this information.

The missing symbol demangles to

nvtt::InputOptions::setTextureLayout(nvtt::TextureType, int, int, int)

which looks like it should come from nvidia-texture-tools, but that
package hasn't been updated since 2016, and was most recently rebuilt
several months ago.

smcv

Bug#916912: [pre-approval] stretch-pu: package freerdp/1.1.0~git20140921.1.440916e+dfsg1-13+deb9u3

[Mike Gabriel]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu


Dear Debian stretch Release Team,

in Debian LTS, we are currently discussing a complex update of the
freerdp (v1.1) package. The current status is this:

  * since March 2018 freerdp in stretch (and jessie) (Git
snapshot of never released v1.1) is unusable against
latest Windows servers.
All Windows OS versions switched to RDP proto version 6
plus CredSSP version 3) and the freerdp versions in Debian
jessie/stretch do not support that.
  * for people using Debian stretch, the only viable work-around
is using freerdp2 from stretch-backports.
  * people using Debian jessie LTS don't have any options (except
from upgrading to stretch and using freerdp2 from stretch-bpo).
  * currently, we know of four unfixed CVE issues in freerdp (v1.1)
(that are fixed in buster's freerdp2.

With my Debian LTS contributor hat on, I have started working on the open
freerdp CVE issues (which luckily appeared in a Ubuntu security update,
so not much work on this side) _and_ ...

... I have started backporting the required patches (at least these:
[1,2,3]) to get RDP proto version 6 working in Debian jessie's freerdp
v1.1 version.

This complete endeavour for LTS only makes sense if the stable release
team is open to accepting such a complex change to Debian stretch, too.

While working on these patches, I regularly get feedback from FreeRDP
upstream developer Bernhard Miklautz.

The Git version [4] of the proposed upload is not yet ready. After
feedback from Bernhard, I will have to backport various WinPR API calls
that are used around the RDP proto v6 implementation. So this whole thing
is still work in progress.

The reason for this mail is: if the stable release team declines this
update, then we neither will bring it to Debian jessie LTS.

Please give me a beacon single (mainly a "yes, go ahead", or a "no, no
way!").

Please let me know, if you need more info to consider. 

Cheers,
Mike

[1] 
https://salsa.debian.org/debian-remote-team/freerdp-1.1-legacy/blob/debian/stretch/updates/debian/patches/0010_add-support-for-credssp-version-3.patch
[2] 
https://salsa.debian.org/debian-remote-team/freerdp-1.1-legacy/blob/debian/stretch/updates/debian/patches/0011_add-support-for-proto-version-6.patch
[3] 
https://salsa.debian.org/debian-remote-team/freerdp-1.1-legacy/blob/debian/stretch/updates/debian/patches/0012-fix-nla-don-t-use-server-version.patch
[4] 
https://salsa.debian.org/debian-remote-team/freerdp-1.1-legacy/tree/debian/stretch/updates

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

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

Bug#911372: fai-setup-storage: setup-storage shouldn't use aes-cbc as default for LUKS containers

[Thomas Lange]

I was also thinking about the choice of removing this option and using
the default of crytpsetup.

@Andrew: What's you oppinion on this, since you've added the code for 
lukscreateopts?

> On Thu, 20 Dec 2018 12:53:03 +0100, Michael Schaller  
> said:

> Thanks. Is there a particular reason why you've switched to
> aes-xts-plain64 instead of removing -c and -s entirely (to use the
> cryptsetup defaults)?
> Note that I'm not questioning your decision. I merely think that if
> there was a decision behind this choice then this decision should also
> be documented in this bug. ;-)

-- 
regards Thomas

Bug#916735: lintian: appstream-metadata-missing-modalias-provide should be info, not warn

[Petter Reinholdtsen]

[Paul Wise]
> I don't think I have the requisite time and understanding to do this,
> hopefully Petter will be interested to work on this but in general I
> think it will be best for individual upstreams to work on this since
> they know their software best and how to best expose which info.

I registered a bts report against nitrokey-app with a proposed patch to
announce hardware support using appstream.  See
https://bugs.debian.org/916911 >.

I guess the documentation should be updated to make it more clear how to
do it, but I am a bit blind to exactly what is hard to comprehend about
the task, so I will need help with that.

I do not have much spare time either, but did file quite a few bug
reports with patches for providing metadata on supported hardware to
several packages.  Unfortunately most of these patches are just
lingering in BTS, so I ran out of steem and motivation for that
approach.  Perhaps adding appstream information into policy is a better
approach.  I kind of doubt it, as policy should should not be a stick to
force people to do work they do not want to do.  How can me make people
want to provide hardware metadata for their packages?  A lintian warning
help a bit, but it obviously not convincing the remaining package
maintainers.

-- 
Happy hacking
Petter Reinholdtsen

Bug#916906: Removed package(s) from unstable

[Andreas Tille]

Hi ftpmasters,

On Thu, Dec 20, 2018 at 10:12:09AM +, Debian FTP Masters wrote:
> We believe that the bug you reported is now fixed; the following
> package(s) have been removed from unstable:
> 
> python-treetime |0.2.4-1 | source, all
> python-treetime |0.5.2-1 | source
> python-treetime-examples |0.2.4-1 | all
> python3-treetime |0.5.2-1 | all

Hmmm,

  python-treetime |0.5.2-1 | source
  python3-treetime |0.5.2-1 | all

should have remained.  Should I re-upload the package as it was?

Thanks for your work anyway

   Andreas.
 
> --- Reason ---
> ROM; python-treetime switched to Python3 (in version 0.5.0) - please remove 
> Python2 binary of version 0.2.4
> --
> 
> Note that the package(s) have simply been removed from the tag
> database and may (or may not) still be in the pool; this is not a bug.
> The package(s) will be physically removed automatically when no suite
> references them (and in the case of source, when no binary references
> it).  Please also remember that the changes have been done on the
> master archive and will not propagate to any mirrors until the next
> dinstall run at the earliest.
> 
> Packages are usually not removed from testing by hand. Testing tracks
> unstable and will automatically remove packages which were removed
> from unstable when removing them from testing causes no dependency
> problems. The release team can force a removal from testing if it is
> really needed, please contact them if this should be the case.
> 
> We try to close bugs which have been reported against this package
> automatically. But please check all old bugs, if they were closed
> correctly or should have been re-assigned to another package.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 916...@bugs.debian.org.
> 
> The full log for this bug can be viewed at https://bugs.debian.org/916906
> 
> This message was generated automatically; if you believe that there is
> a problem with it please contact the archive administrators by mailing
> ftpmas...@ftp-master.debian.org.
> 
> Debian distribution maintenance software
> pp.
> Scott Kitterman (the ftpmaster behind the curtain)
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#916907: pyscanfcs: fails to install (found by autopkgtest)

[Mattia Rizzolo]

Control: reassign -1 python3-minimal
Control: severity -1 important

On Thu, Dec 20, 2018 at 10:01:37AM +0100, Paul Gevers wrote:
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/pyscanfcs/1549682/log.gz
> 
> Setting up python3.6 (3.6.8~rc1-1) ...
> Setting up gsettings-desktop-schemas (3.28.1-1) ...
> Setting up python3 (3.7.1-3) ...
> E: py3compile:243: Requested versions are not installed
> error running python rtupdate hook pyscanfcs

More details:

root@warren:/# py3compile -p pyscanfcs /usr/lib/pyscanfcs -V 3.7 -v
D: py3compile:224: argv: ['/usr/bin/py3compile', '-p', 'pyscanfcs', 
'/usr/lib/pyscanfcs', '-V', '3.7', '-v']
D: py3compile:225: options: {'verbose': True, 'force': False, 'optimize': 
False, 'package': 'pyscanfcs', 'vrange': ((3, 7), (3, 7)), 'regexpr': None}
D: py3compile:226: args: ['/usr/lib/pyscanfcs']
D: py3compile:249: compile versions: {(3, 7)}
D: py3compile:259: byte compiling /usr/lib/pyscanfcs using Python [(3, 7)]
root@warren:/# py3compile -p pyscanfcs /usr/lib/pyscanfcs -V 3.6 -v
D: py3compile:224: argv: ['/usr/bin/py3compile', '-p', 'pyscanfcs', 
'/usr/lib/pyscanfcs', '-V', '3.6', '-v']
D: py3compile:225: options: {'verbose': True, 'force': False, 'optimize': 
False, 'package': 'pyscanfcs', 'vrange': ((3, 6), (3, 6)), 'regexpr': None}
D: py3compile:226: args: ['/usr/lib/pyscanfcs']
D: py3compile:249: compile versions: {(3, 6)}
D: py3compile:259: byte compiling /usr/lib/pyscanfcs using Python [(3, 6)]
root@warren:/# py3compile -p pyscanfcs /usr/lib/pyscanfcs -V 3.6-3.7 -v
D: py3compile:224: argv: ['/usr/bin/py3compile', '-p', 'pyscanfcs', 
'/usr/lib/pyscanfcs', '-V', '3.6-3.7', '-v']
D: py3compile:225: options: {'verbose': True, 'force': False, 'optimize': 
False, 'package': 'pyscanfcs', 'vrange': ((3, 6), (3, 7)), 'regexpr': None}
D: py3compile:226: args: ['/usr/lib/pyscanfcs']
E: py3compile:243: Requested versions are not installed
root@warren:/#

I.e. I believe this to be a issue with py3compile or whatever lies
beneath it.


I'm going to workaround this bug with a no-change rebuild, which removes
the version range and uses `-V 3.7` only.

-- 
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#916913: libpcl-dev: PCLConfig.cmake fails to find eigen

[Johannes 'josch' Schauer]

Package: libpcl-dev
Version: 1.9.1+dfsg1-2
Severity: grave
Justification: renders package unusable

Hi,

a CMakeLists.txt with "find_package(PCL REQUIRED)" will currently result in:

CMake Warning at /usr/lib/x86_64-linux-gnu/cmake/pcl/PCLConfig.cmake:159 
(find_package):
  By not providing "FindEigen.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Eigen", but
  CMake did not find one.

  Could not find a package configuration file provided by "Eigen" with any of
  the following names:

EigenConfig.cmake
eigen-config.cmake

  Add the installation prefix of "Eigen" to CMAKE_PREFIX_PATH or set
  "Eigen_DIR" to a directory containing one of the above files.  If "Eigen"
  provides a separate development package or SDK, be sure it has been
  installed.
Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/pcl/PCLConfig.cmake:313 (find_eigen)
  /usr/lib/x86_64-linux-gnu/cmake/pcl/PCLConfig.cmake:544 
(find_external_library)
  src/ros/CMakeLists.txt:22 (find_package)


CMake Error at /usr/lib/x86_64-linux-gnu/cmake/pcl/PCLConfig.cmake:59 (message):
  common is required but eigen was not found
Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/pcl/PCLConfig.cmake:362 (pcl_report_not_found)
  /usr/lib/x86_64-linux-gnu/cmake/pcl/PCLConfig.cmake:544 
(find_external_library)
  src/ros/CMakeLists.txt:22 (find_package)


-- Configuring incomplete, errors occurred!



But libeigen3-dev is installed. For a full failing build log see:

https://api.travis-ci.org/v3/job/470351936/log.txt

Thanks!

cheers, josch

Bug#916914: python3.7: please add breaks agianst xapers (<< 0.8.2-1.1)

[Mattia Rizzolo]

Package: python3.7
Version:  3.7.2~rc1-1

See #912931

-- 
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#911372: fai-setup-storage: setup-storage shouldn't use aes-cbc as default for LUKS containers

[Thomas Lange]

> On Fri, 21 Dec 2018 01:27:09 +1300, Andrew Ruthven  
> said:

> Using the default of cryptsetup sounds sane, however I'd still like the
> option of over riding this.
OK, then I can just remove this code, and it's still possible to set
your own parameters. Here's the diff

diff --git a/lib/setup-storage/Commands.pm b/lib/setup-storage/Commands.pm
index 22efe113..3844bf84 100755
--- a/lib/setup-storage/Commands.pm
+++ b/lib/setup-storage/Commands.pm
@@ -253,12 +253,7 @@ sub build_cryptsetup_commands {
   "", "keyfile_$real_dev" );
 
 my $lukscreateopts = $vol->{lukscreateopts} // "";
-if ($lukscreateopts !~ /(^|\s)-c\s+\S+/) {
-  $lukscreateopts .= " -c aes-xts-plain64";
-}
-if ($lukscreateopts !~ /(^|\s)-s\s+\d+/) {
-  $lukscreateopts .= " -s 256";
-}
+
 # encrypt
 &FAI::push_command(
   "yes YES | cryptsetup luksFormat $real_dev $keyfile $lukscreateopts",

-- 
regards Thomas

Bug#911372: fai-setup-storage: setup-storage shouldn't use aes-cbc as default for LUKS containers

[Andrew Ruthven]

On Thu, 2018-12-20 at 13:06 +0100, Thomas Lange wrote:
> I was also thinking about the choice of removing this option and
> using
> the default of crytpsetup.
> 
> @Andrew: What's you oppinion on this, since you've added the code for
> lukscreateopts?

Hey,

Using the default of cryptsetup sounds sane, however I'd still like the
option of over riding this.

The reason I added the options was so that we could use the correct
settings to make use of the crypto features in the CPUs we use. Newer
CPUs might require different settings, so it'd be good to allow
flexibility.

Cheers,
Andrew

-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz  | linux.conf.au 2019, Christchurch, NZ
Catalyst Cloud:    |    https://lca2019.linux.org.au/
   https://catalystcloud.nz|

Bug#912929: xapers: diff for NMU version 0.8.2-1.1

[Mattia Rizzolo]

Control: tags 912929 + patch
Control: tags 912929 + pending
Control: tags 912931 + pending


Dear maintainer,

I've prepared an NMU for xapers (versioned as 0.8.2-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
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  `-
diffstat for xapers-0.8.2 xapers-0.8.2

 changelog|9 +
 control  |1 -
 patches/fail-tests.patch |   28 
 patches/python3.7.patch  |   32 
 patches/series   |2 ++
 5 files changed, 71 insertions(+), 1 deletion(-)

diff -Nru xapers-0.8.2/debian/changelog xapers-0.8.2/debian/changelog
--- xapers-0.8.2/debian/changelog	2017-08-08 17:36:24.0 +0200
+++ xapers-0.8.2/debian/changelog	2018-12-20 13:37:27.0 +0100
@@ -1,3 +1,12 @@
+xapers (0.8.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unnecessary Testsuite field from debian/control.
+  * Add patch to make the testsuite fatal during build.  Closes: #912929
+  * Add patch to fix compatibility with Python 3.7.  Closes: #912931
+
+ -- Mattia Rizzolo   Thu, 20 Dec 2018 13:37:27 +0100
+
 xapers (0.8.2-1) unstable; urgency=medium
 
   * New minor release (Closes: #779601, #823964, #870289)
diff -Nru xapers-0.8.2/debian/control xapers-0.8.2/debian/control
--- xapers-0.8.2/debian/control	2017-08-08 17:36:24.0 +0200
+++ xapers-0.8.2/debian/control	2018-12-20 13:36:18.0 +0100
@@ -15,7 +15,6 @@
 Standards-Version: 4.0.0
 Homepage: https://finestructure.net/xapers
 Vcs-Git: https://finestructure.net/git/xapers
-Testsuite: autopkgtest
 
 Package: xapers
 Architecture: all
diff -Nru xapers-0.8.2/debian/patches/fail-tests.patch xapers-0.8.2/debian/patches/fail-tests.patch
--- xapers-0.8.2/debian/patches/fail-tests.patch	1970-01-01 01:00:00.0 +0100
+++ xapers-0.8.2/debian/patches/fail-tests.patch	2018-12-20 13:34:25.0 +0100
@@ -0,0 +1,28 @@
+Description: make the testsuite fail when a test fails
+Author: Mattia Rizzolo 
+Bug-Debian: https://bugs.debian.org/912929
+Forwarded: no
+Last-Update: 2018-12-20
+
+--- a/test/test-aggregate-results
 b/test/test-aggregate-results
+@@ -79,3 +79,8 @@
+ tests=$(pluralize "test" $skipped)
+ echo "$skipped $tests skipped."
+ fi
++
++if [ $failed -gt 0 ]; then
++echo "Testsuite failed!"
++exit 1
++fi
+--- a/test/xapers-test
 b/test/xapers-test
+@@ -46,7 +46,7 @@
+ trap - HUP INT TERM
+ 
+ # Report results
+-./test-aggregate-results test-results/*
++./test-aggregate-results test-results/* || exit 1
+ 
+ # Clean up
+ rm -rf test-result
diff -Nru xapers-0.8.2/debian/patches/python3.7.patch xapers-0.8.2/debian/patches/python3.7.patch
--- xapers-0.8.2/debian/patches/python3.7.patch	1970-01-01 01:00:00.0 +0100
+++ xapers-0.8.2/debian/patches/python3.7.patch	2018-12-20 13:33:14.0 +0100
@@ -0,0 +1,32 @@
+Description: Fixes for Python 3.7
+ PEP 472 changes how StopIteration is handled inside generators -- it no
+ longer bubbles out but instead causes an error.
+Author: Michael Hudson-Doyle 
+Acked-By: Mattia Rizzolo 
+Bug-Debian: https://bugs.debian.org/912931
+Last-Update: 2018-12-20
+
+--- a/lib/xapers/util.py
 b/lib/xapers/util.py
+@@ -9,12 +9,18 @@
+ term_iter = iter(xapian_object)
+ if prefix:
+ plen = len(prefix)
+-term = term_iter.skip_to(prefix).term.decode()
++try:
++term = term_iter.skip_to(prefix).term.decode()
++except StopIteration:
++return
+ if not term.startswith(prefix):
+ return
+ yield term[plen:]
+ for tli in term_iter:
+-term = tli.term.decode()
++try:
++term = tli.term.decode()
++except StopIteration:
++return
+ if prefix:
+ if not term.startswith(prefix):
+ break
+
diff -Nru xapers-0.8.2/debian/patches/series xapers-0.8.2/debian/patches/series
--- xapers-0.8.2/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ xapers-0.8.2/debian/patches/series	2018-12-20 13:31:52.0 +0100
@@ -0,0 +1,2 @@
+fail-tests.patch
+python3.7.patch


signature.asc
Description: PGP signature

Bug#916915: RM: python-django-postorius -- NBS

[Mattia Rizzolo]

Package: ftp.debian.org
X-Debbugs-Cc: postor...@packages.debian.org

python-django-postorius is not built anymore since version 1.2.2-1, but
apparently it needs a manual decruft.

-- 
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#916859: closed by Andrey Rahmatullin (Re: Bug#916859: RFS: PDF Studio Viewer/2018 [ITP] -- pdf viewer)

[Ghislain Vaillant]

Le jeu. 20 déc. 2018 à 12:33, Sven Hoexter  a écrit :

> On Wed, Dec 19, 2018 at 05:12:39PM -0500, Studio Support wrote:
> > Hello Andrey,
> >
> > Regarding the solution on Bug#916859 about our package "pdfstudioviewer"
> >
> > It's free in the real sense of the term, meaning that users don't pay
> for it. But it is not open source. Our end-user license is displayed to
> users upon running our application the first time.
> >
> > We don't care if our application is listed under the Free or the
> Commercial products.
> >
> > We have a Debian installer so I hope you can use that.
>
> Hi,
> I, and propably many more Debian developers, appreciate that you try to
> engange
> with the Debian project, but really we're focused on open source software.
> You might
> want to read https://www.debian.org/social_contract.html
>
> So yes it's true that we have this sad part called "non-free" on our
> mirrors but formally
> it's not really part of the distribution, and still everything shipped in
> non-free requires
> to have a source package as well.
> https://wiki.debian.org/Packaging/SourcePackage
>
> In the end I can only encourage you to open source your software,
> otherwise you've to move
> on and distribute it via your own self hosted repository.
>
> Sven
>

Another solution would be to distribute your software via Flatpak or Snap
which most distributions, including Debian, support very well.

Ghis

>

Bug#916916: RM: python-django-hyperkitty -- NBS

[Mattia Rizzolo]

Package: ftp.debian.org
X-Debbugs-cc: hyperki...@packages.debian.org

python-django-hyperkitty is not built anymore since a few version, but
apparently it needs a manual decruft.

-- 
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#916917: RM: python-django-mailman3 -- NBS

[Mattia Rizzolo]

Package: ftp.debian.org
X-Debbugs-Cc: django-mailm...@packages.debian.org
Control: block -1 by 916915 916916

python-django-mailman3 is not built anymore since a few versions, but it
apparently needs a manual decruft.

-- 
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#916843: installed system not usable

[andrew glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 20 Dec 2018 11:29:28 +
Steve McIntyre  wrote:

> Hi Andrew,
> 
> On Thu, Dec 20, 2018 at 11:23:55AM +0100, andrew glaeser wrote:
> >>
> >> root@detst:/home/user# init 0
> >> bash: init: command not found
> >> root@detst:/home/user# shutdown -h now
> >> bash: shutdown: command not found
> >> root@detst:/home/user# ls
> >> reportbug-installation-report-20181219-847-hn9d0g_o
> >> root@detst:/home/user# aptitude update && aptitude upgrade
> >> Get: 1 http://security.debian.org/debian-security buster/updates
> >> InRelease [38.3 kB] Get: 2 http://ftp2.de.debian.org/debian buster
> >> InRelease [154 kB] Get: 3 http://ftp2.de.debian.org/debian buster/main
> >> amd64 Packages.diff/Index [27.9 kB] Get: 4
> >> http://ftp2.de.debian.org/debian buster/main Translation-en.diff/Index
> >> [27.9 kB] Get: 5 http://ftp2.de.debian.org/debian buster/contrib amd64
> >> Packages.diff/Index [27.8 kB] Get: 6 http://ftp2.de.debian.org/debian
> >> buster/contrib Translation-en.diff/Index [27.8 kB] Get: 7
> >> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> >> 2018-12-19-1410.32.pdiff [1,102 B] Get: 8
> >> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> >> 2018-12-19-2010.27.pdiff [4,334 B] Get: 9
> >> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> >> 2018-12-20-0210.19.pdiff [33.2 kB] Get: 10
> >> http://ftp2.de.debian.org/debian buster/main Translation-en
> >> 2018-12-19-1410.32.pdiff [824 B] Get: 11
> >> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> >> 2018-12-20-0210.19.pdiff [33.2 kB] Get: 12
> >> http://ftp2.de.debian.org/debian buster/main Translation-en
> >> 2018-12-20-0210.19.pdiff [5,705 B] Get: 13
> >> http://ftp2.de.debian.org/debian buster/contrib amd64 Packages
> >> 2018-12-20-0210.19.pdiff [2,765 B] Get: 14
> >> http://ftp2.de.debian.org/debian buster/main Translation-en
> >> 2018-12-20-0210.19.pdiff [5,705 B] Get: 15
> >> http://ftp2.de.debian.org/debian buster/contrib Translation-en
> >> 2018-12-20-0210.19.pdiff [31 B] Get: 16 http://ftp2.de.debian.org/debian
> >> buster/contrib amd64 Packages 2018-12-20-0210.19.pdiff [2,765 B] Get: 17
> >> http://ftp2.de.debian.org/debian buster/contrib Translation-en
> >> 2018-12-20-0210.19.pdiff [31 B] Fetched 351 kB in 8s (45.5 kB/s) Current
> >> status: 5 (+5) upgradable, 916 (+29) new. Resolving dependencies... The
> >> following NEW packages will be installed: libhunspell-1.7-0{a} The
> >> following packages will be REMOVED: libhunspell-1.6-0{u} The following
> >> packages will be upgraded: adwaita-icon-theme enchant gpgv
> >> libenchant1c2a libgpg-error0 The following packages are RECOMMENDED but
> >> will NOT be installed: libgpg-error-l10n 5 packages upgraded, 1 newly
> >> installed, 1 to remove and 0 not upgraded. Need to get 12.5 MB/12.7 MB
> >> of archives. After unpacking 52.2 kB will be used. Do you want to
> >> continue? [Y/n/?] Get: 1 http://ftp2.de.debian.org/debian buster/main
> >> amd64 enchant amd64 1.6.0-11.1+b1 [18.7 kB] Get: 2
> >> http://ftp2.de.debian.org/debian buster/main amd64 libenchant1c2a amd64
> >> 1.6.0-11.1+b1 [69.8 kB] Get: 3 http://ftp2.de.debian.org/debian
> >> buster/main amd64 libgpg-error0 amd64 1.33-3 [70.6 kB] Get: 4
> >> http://ftp2.de.debian.org/debian buster/main amd64 gpgv amd64 2.2.12-1
> >> [583 kB] Get: 5 http://ftp2.de.debian.org/debian buster/main amd64
> >> adwaita-icon-theme all 3.30.1-1 [11.7 MB] Fetched 12.5 MB in 1s (10.2
> >> MB/s) Reading changelogs... Done dpkg: warning: 'ldconfig' not found in
> >> PATH or not executable dpkg: warning: 'start-stop-daemon' not found in
> >> PATH or not executable dpkg: error: 2 expected programs not found in
> >> PATH or not executable Note: root's PATH should usually
> >> contain /usr/local/sbin, /usr/sbin and /sbin E:
> >> Sub-process /usr/bin/dpkg returned an error code (2) dpkg: warning:
> >> 'ldconfig' not found in PATH or not executable dpkg: warning:
> >> 'start-stop-daemon' not found in PATH or not executable dpkg: error: 2
> >> expected programs not found in PATH or not executable Note: root's PATH
> >> should usually contain /usr/local/sbin, /usr/sbin and /sbin
> >> root@detst:/home/user#   
> 
> I've been bitten by this myself, so I recognise the symptoms.
> 
> You've logged in and used "su" to switch to root. We've recently
> switched to using the "su" provided by the util-linux source package
> instead of the older one from shadow, and this is a consequence of
> that change. To change environment properly, you need to use "su -"
> instead.
> 

Well, I guess then it really is a minor issue only, I would have tried to fix
the path-variable next, bit if you have another solution it is fine for me,
even better, if you want.
Does this have to go into the release-notes anyway?
Other thing, that caught my attention was, that you obviously have to wait a
few minutes upon reboot, until you can log in with SSH. Is this actually
intended to be this way:

> andrew@a68n:~$ 

Bug#916906: Removed package(s) from unstable

[Andreas Tille]

Hi,

after a short discussion on IRC, I'll upload python3-treetime 0.5.2-2
without source tarball since it should be available on the mirrors since
the package should remain in testing.

Kind regards

   Andreas.

On Thu, Dec 20, 2018 at 01:10:27PM +0100, Andreas Tille wrote:
> Hi ftpmasters,
> 
> On Thu, Dec 20, 2018 at 10:12:09AM +, Debian FTP Masters wrote:
> > We believe that the bug you reported is now fixed; the following
> > package(s) have been removed from unstable:
> > 
> > python-treetime |0.2.4-1 | source, all
> > python-treetime |0.5.2-1 | source
> > python-treetime-examples |0.2.4-1 | all
> > python3-treetime |0.5.2-1 | all
> 
> Hmmm,
> 
>   python-treetime |0.5.2-1 | source
>   python3-treetime |0.5.2-1 | all
> 
> should have remained.  Should I re-upload the package as it was?
> 
> Thanks for your work anyway
> 
>Andreas.
>  
> > --- Reason ---
> > ROM; python-treetime switched to Python3 (in version 0.5.0) - please remove 
> > Python2 binary of version 0.2.4
> > --
> > 
> > Note that the package(s) have simply been removed from the tag
> > database and may (or may not) still be in the pool; this is not a bug.
> > The package(s) will be physically removed automatically when no suite
> > references them (and in the case of source, when no binary references
> > it).  Please also remember that the changes have been done on the
> > master archive and will not propagate to any mirrors until the next
> > dinstall run at the earliest.
> > 
> > Packages are usually not removed from testing by hand. Testing tracks
> > unstable and will automatically remove packages which were removed
> > from unstable when removing them from testing causes no dependency
> > problems. The release team can force a removal from testing if it is
> > really needed, please contact them if this should be the case.
> > 
> > We try to close bugs which have been reported against this package
> > automatically. But please check all old bugs, if they were closed
> > correctly or should have been re-assigned to another package.
> > 
> > Thank you for reporting the bug, which will now be closed.  If you
> > have further comments please address them to 916...@bugs.debian.org.
> > 
> > The full log for this bug can be viewed at https://bugs.debian.org/916906
> > 
> > This message was generated automatically; if you believe that there is
> > a problem with it please contact the archive administrators by mailing
> > ftpmas...@ftp-master.debian.org.
> > 
> > Debian distribution maintenance software
> > pp.
> > Scott Kitterman (the ftpmaster behind the curtain)
> > 
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> 
> -- 
> http://fam-tille.de

-- 
http://fam-tille.de

Bug#916843: installed system not usable

[Steve McIntyre]

On Thu, Dec 20, 2018 at 01:56:39PM +0100, andrew glaeser wrote:
>Steve McIntyre  wrote:
>> 
>> I've been bitten by this myself, so I recognise the symptoms.
>> 
>> You've logged in and used "su" to switch to root. We've recently
>> switched to using the "su" provided by the util-linux source package
>> instead of the older one from shadow, and this is a consequence of
>> that change. To change environment properly, you need to use "su -"
>> instead.
>
>Well, I guess then it really is a minor issue only, I would have tried to fix
>the path-variable next, bit if you have another solution it is fine for me,
>even better, if you want.
>Does this have to go into the release-notes anyway?

Yes, it probably should. I'm not sure if it's there already, I need to
check.

>Other thing, that caught my attention was, that you obviously have to wait a
>few minutes upon reboot, until you can log in with SSH. Is this actually
>intended to be this way:
>
>> andrew@a68n:~$ ssh user@detst
>> ssh: connect to host detst port 22: Connection refused
>> andrew@a68n:~$ ssh user@detst
>> ssh: connect to host detst port 22: Connection refused
>> andrew@a68n:~$ ssh user@detst
>> ssh: connect to host detst port 22: Connection refused
>> andrew@a68n:~$ ssh user@detst
>> ssh: connect to host detst port 22: Connection refused
>> andrew@a68n:~$ ssh user@detst
>> ssh: connect to host detst port 22: Connection refused
>> andrew@a68n:~$ ssh user@detst
>> Linux detst 4.18.0-3-amd64 #1 SMP Debian 4.18.20-2 (2018-11-23) x86_64

That's a separate issue. *Maybe* a lack of entropy (see [1]), but it
could be other things too. Check your logs for related messages maybe?

[1] 
https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver." -- Daniel Pead

Bug#913976: ITP: python-hgapi -- module providing a pure-Python API to Mercurial

[Julien Cristau]

On 11/17/18 9:23 PM, Nick Morrott wrote:
> Package: wnpp
> Owner: Nick Morrott 
> Severity: wishlist
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> * Package name: python-hgapi
>   Version : 1.7.3
>   Upstream Author : Fredrik Håård 
> * URL : https://github.com/haard/hgapi
> * License : Expat
>   Programming Lang: Python
>   Description : module providing a pure-Python API to Mercurial
> 
> hgapi is a pure-Python API to the Mercurial command-line, instead of the 
> internal Mercurial API.
> 
> hgapi works for all versions of Mercurial, and will instantly reflect any 
> changes to the repository (including hgrc).
> 
> hgapi is a dependency of yotta [1]
> 
>   [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908781
> 
Is there a particular reason yotta needs to use this instead of hglib,
which:
- is already in debian
- is maintained by mercurial upstream
- has pretty much the exact same package description as the above
?

This seems like useless duplication.

Thanks,
Julien

Bug#916784: [20181218] debian.gnu.gen.tr: broken DNS

[Yavuz Selim Komur]

i deploy new dns server on softlayer.

Bug#916918: iptables translation issues

[debian-reportbug-2018]

Package: nftables
Version: 0.9.0-2
Severity: normal

The following examples used to work with native iptables, but either 
fail or produce the wrong functionality with nftables:


bash# iptables-translate -4 -A bogoncheck -m set --match-set bogons4 src 
-j DROP

nft # -4 -A bogoncheck -m set --match-set bogons4 src -j DROP
bash#

(i.e. fails to translate rule)

bash# iptables-translate -A INPUT -s 0.0.0.0/8 -j DROP
nft add rule ip filter INPUT counter drop
bash#

(ignores source address match to yield a rule that drops everything)
(0.0.0.0/8 != 0.0.0.0/0)

bash# iptables-translate -6 -A protect-re -s 2001:db8:19::/64 -p tcp 
--sport 80 -j ACCEPT
nft add rule ip filter protect-re ip6 saddr 2001:db8::::0:0/0 
tcp sport 80 counter accept

bash#

(borks the source address match completely)

The last example is converted correctly by ip6tables-translate. But as I 
used to have ipv4 and ipv6 rules in the same file, I'm baffled by why 
iptables-restore-translate even tries to convert the ipv6 rules. Surely 
it should just skip them?


I also ran into a baffling error message for a rule that uses the 
multiport module, and couldn't find a workaround or even what the real 
problem was:


iptables-translate-restore v1.8.2 (nf_tables): multiport needs `-p tcp', 
`-p udp', `-p udplite', `-p sctp' or `-p dccp'


Here's an attempt to manually translate the line in question:

bash# iptables-translate -4 -A protect-re  -m multiport -p udp -s 
10.0.0.0/24 --ports 161,514  -j ACCEPT
nft # -4 -A protect-re -m multiport -p udp -s 10.0.0.0/24 --ports 
161,514 -j ACCEPT

bash#

Best Regards,

--
Aleksi Suhonen

Bug#916919: coturn 4.5.0.7-1: FTBFS, alignment problem

[Steve McIntyre]

Source: coturn
Version: 4.5.0.7-1
Severity: important
User: debian-...@lists.debian.org
Usertags: alignment

Hi!

I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so this rebuild is to identify packages that
might have problems with this configuration.

A feature of the arm64 kernel is that it does *not* support fixing up
code with broken alignment, so code that might have built and run OK
on our older armel/armhf build machines due to kernel fixups will now
fail.

When building your package, I've found a bus error (aka alignment
fault). The full log is online at

  
https://www.einval.com/debian/arm/rebuild-logs/armel/FAIL/coturn_4.5.0.7-1_armel.log

for reference

I've done a quick bit of debugging to find the source of the
bug. Here's a gdb stacktrace and variable printout to demonstrate the
problem.

(sid-armel)steve@mjolnir:~/build/coturn-4.5.0.8$ gdb bin/turnutils_rfc5769check 
core
GNU gdb (Debian 8.2-1) 8.2
Copyright (C) 2018 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 "arm-linux-gnueabi".
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 bin/turnutils_rfc5769check...done.

warning: core file may not match specified executable file.
[New LWP 2415]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".
Core was generated by `bin/turnutils_rfc5769check'.
Program terminated with signal SIGBUS, Bus error.
#0  decode_oauth_token_gcm (server_name=0xf797d968 <__stack_chk_guard> "", 
etoken=0xffa9ac60, key=, 
dtoken=0xffa9a550) at src/client/ns_turn_msg.c:2611
2611dtoken->enc_block.timestamp = 
nswap64(*((uint64_t*)(decoded_field+len)));
(gdb) bt
#0  decode_oauth_token_gcm (server_name=0xf797d968 <__stack_chk_guard> "", 
etoken=0xffa9ac60, key=, 
dtoken=0xffa9a550) at src/client/ns_turn_msg.c:2611
#1  0x00a7ca74 in check_oauth () at src/apps/rfc5769/rfc5769check.c:157
#2  main (argc=, argv=) at 
src/apps/rfc5769/rfc5769check.c:568
(gdb) p dtoken
$1 = (oauth_token *) 0xffa9a550
(gdb) p decoded_field
$2 = 
"\000\024ZksjpweoixXmvn67534m\000\000T\031\353m\000\000\000\000\016\020\064m\000\000T\031\353m\000\000\000\000\016\020",
 '\000' 
(gdb) p len
$3 = 22

Simply casting things like nswap64(*((uint64_t*)(decoded_field+len)))
is not safe unless you know it's guaranteed to be aligned. In this
case, it's not.

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

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

Bug#916765: cups-browsed: Aborts when restarted with "BrowseFilter pdl postscript"

[Bernhard Übelacker]

Hello Brian Potkin,
I tried to have a look in a unstable VM, but unfortunately
I get different offsets ...

You might add the output of this command:
  dpkg -l | grep -E "cups-browsed|libc6|libglib|libavahi|libdbus" | sort

And what output did you receive from this command
  coredumpctl list

and following this command, with PID from the above output:
  coredumpctl gdb PID
bt
quit

Kind regards,
Bernhard






signature.asc
Description: OpenPGP digital signature

Bug#916920: firejail: Firejail allows regular users to bypass root system settings

[Alain Ducharme]

Package: firejail
Version: 0.9.56-2
Severity: normal

Dear Maintainer,

Firejail being a setuid executable provides regular users root powers to bypass
system settings.
I think it's a problem for an official Debian package to automatically
grant regular users that much power without root having actively granted it
(root might not fully appreciate the powers granted to regular users simply
by installing this enhanced security package).
Perhaps Firejail could be installed by default without the SUID bit set, and
leave it up to root to actively decide if they want to turn it on.
Or, perhaps default /etc/firejail/firejail.config should be set much more
conservatively initially, things like: restricted-network yes

Example:
root sets up system firewall (simple example here, block all outbound):
# nft add table ip filter
# nft add chain ip filter OUTPUT "{ type filter hook output priority 0; policy 
drop; }"
regular user tries:
$ wget http://www.google.com # fails, as expected due to firewall rules
$ firejail --net=enp6s0 --noprofile wget http://www.google.com # works!
regular user is able to bypass all system firewall rules

Thank you

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

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

Versions of packages firejail depends on:
ii  libapparmor1  2.13.1-3+b1
ii  libc6 2.28-2

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.56-2
ii  iproute2   4.18.0-2
ii  iptables   1.8.2-2+b1
ii  xauth  1:1.0.10-1
ii  xserver-xephyr 2:1.20.3-1

firejail suggests no packages.

-- no debconf information

Bug#916649: [pkg-cryptsetup-devel] Bug#916649: crytpsetup:

[rsev]

On 2018-12-19 22:14, Guilhem Moulin wrote:
> On Wed, 19 Dec 2018 at 12:13:25 -0800, r...@riseup.net wrote:
>> I see. What would you suggest as a proper solution to this situation?
> 
> How about what's now the title of this bug? :-)

I'm sorry. I don't follow. How would I do it exactly?


Regards,

Rodrigo

Bug#833603: cross-distro

[Mattia Rizzolo]

On Wed, Dec 19, 2018 at 05:30:21PM +0100, Bernhard M. Wiedemann wrote:
> One aspect to consider:
> even if you found that all Debian packages do not need a handler
> anymore, there may be other distributions that still needed it.
> 
> So please be conservative in what you drop.

I'd propose introducing something to configure at "built time" what
normalizers to disable/enable, coupled with a revert of the change you
mentioned.

-- 
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#916649: [pkg-cryptsetup-devel] Bug#916649: crytpsetup:

[Guilhem Moulin]

On Thu, 20 Dec 2018 at 05:38:50 -0800, r...@riseup.net wrote:
> On 2018-12-19 22:14, Guilhem Moulin wrote:
>> On Wed, 19 Dec 2018 at 12:13:25 -0800, r...@riseup.net wrote:
>>> I see. What would you suggest as a proper solution to this situation?
>> 
>> How about what's now the title of this bug? :-)
> 
> I'm sorry. I don't follow. How would I do it exactly?

Our initramfs hook has code to determine which dm-crypt device(s) are
holding a given mountpoint, which could be factored in and used in
do_stop().


https://salsa.debian.org/cryptsetup-team/cryptsetup/blob/master/debian/initramfs/hooks/cryptroot#L60

I'm afraid I don't have time for further mentoring here.  That said,
it's not because you filed this bug that you need to fix it.  We package
maintainers will probably implement the fix ourselves, unless another
affected user chimes in before.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#916921: radicale: upgrade to 2.x breaks compatibility with 1.x without any prior warning

[Bernard Massot]

Package: radicale
Version: 2.1.11-2
Severity: important

On Debian unstable, Radicale was just upgraded from 1.x to 2.x. Only after
upgrading did I realize that my calendars were not available any more.

As stated on https://radicale.org/1to2/, upgrade to 2.x forces you to use
Python 3, and thus to upgrade mod_wsgi as well. I was using Python 2 version of
mod_wsgi only because it was the default version and it wasn't causing any
problem (Radicale was my only WSGI application).
Moreover, Radicale 2.x can't even use 1.x data files. You must export your
files *before* upgrading.

The Debian package silently ignores all these issues. I think there should be
warning messages and a ad hoc prerm kind of script.

By the way, installing Radicale 1.x and using --export-storage didn't even work
for me. It probably had something to do with my using single iCalendar file
calendars and my /etc/radicale/config was not configured to support this
anymore.

Just in case someone with the same problem as me read this message, here is how
I fixed all this mess.
For each calendar, I unsubscribed in Lightning, created a new calendar through
the web interface, renamed the created directory in
/var/lib/radicale/collections/collection-root// (for some reason,
Radicale uses random hexadecimal strings instead of calendar title, whereas it
is the actual string you have to type in your CalDAV client), subscribed
the newly created calendar in Lightning, and imported the old iCalendar file
from /var/lib/radicale/collections// using the "Events and
Tasks->Import" Lightning menu.
It actually was more straightforward than using the whole export storage thing.
After doing that my other CalDAV clients worked without needing to be
reconfigured.

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

Kernel: Linux 4.18.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages radicale depends on:
ii  adduser  3.118
ii  init-system-helpers  1.56+nmu1
ii  lsb-base 10.2018112800
ii  python3  3.7.1-3
ii  python3-radicale 2.1.11-2

Versions of packages radicale recommends:
ii  ssl-cert  1.0.39

Versions of packages radicale suggests:
ii  apache2 2.4.37-1
ii  apache2-utils   2.4.37-1
pn  libapache2-mod-proxy-uwsgi  
pn  python3-bcrypt  
pn  python3-passlib 
pn  uwsgi   

-- Configuration Files:
/etc/radicale/config changed [not included]

-- debconf-show failed

Bug#916922: buildbot: FTBFS: test failures

[Mattia Rizzolo]

Source: buildbot
Version: 1.4.0-1
Severity: serious

|Ran 5569 tests in 883.126s
|
|FAILED (skips=303, errors=16, successes=5258)

All of them seems to always boil down to:
builtins.NameError: name 'sqlite3' is not defined

-- 
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#916923: s-el: re-enable the test suite at package build, and the autopkgtest

[Sean Whitton]

Source: s-el
Version: 1.12.0-2
Severity: normal
Tags: help

The 1.12.0-2 upload disabled the test suite -- see comment in
d/elpa-test.  The problem should be fixed and the test suite re-enabled.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#916924: sbuild: doesn't run autodep8 autopkgtests

[Sean Whitton]

Package: sbuild
Version: 0.77.1-2
Severity: important
Control: fixed -1 0.73.0-4

Dear maintainer,

sbuild in stretch unconditionally invokes autopkgtest even if the file
debian/tests/control is not present in the source package.  Newer sbuild
does not invoke autopkgtest unless that file is present.

Many packages do not have debian/tests/control, and simply have a
Testsuite: field, which causes autopkgtest to invoke autodep8 to
generate an appropriate debian/tests/control.  Under stretch, such
packages test suites would be run by sbuild, but now they are not.

This seems like a regression since stretch.  Perhaps, at least, there
could be an option to revert to always invoking autopkgtest when
--run-autopkgtest is passed?  --definitely-run-autopkgtest?

Thank you.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#916925: Use after free on pthread_create (glibc)

[Marios Hadjieleftheriou]

Package: glibc-source
Version: 2.24-11+deb9u3

We are using slurm, which uses a lot of pthreads, and it keeps exercising this 
bug that has already
been reported upstream 
(https://sourceware.org/bugzilla/show_bug.cgi?id=20116#c5), which was introduced
after glibc 2.19 and has been fixed in glibc 2.25. Can this patch be merged in 
Debian while we wait for buster?

I am using Debian GNU/Linux 9.3, kernel 4.9.0-5-amd64, libc6 2.24-11+deb9u3

Bug#882255: libc6-dev: #define _SC_PAGESIZE _SC_PAGESIZE in /usr/include/x86_64-linux-gnu/bits/confname.h

[Florin Iucha]

Package: libc6-dev
Version: 2.28-2
Followup-For: Bug #882255

Dear Maintainer,

Trying to compile a personal project using Clang7 and maximum warning
settings, it produced the following warning:

error: disabled expansion of recursive macro
[-Werror,-Wdisabled-macro-expansion]

/usr/include/x86_64-linux-gnu/bits/confname.h:134:24: note: expanded
from macro '_SC_PAGESIZE'   
 
#define _SC_PAGESIZE_SC_PAGESIZE

I think the confname.h has that line as a result of a mis-merge. There's
no point in defining X as X.

florin

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

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

Versions of packages libc6-dev depends on:
ii  libc-dev-bin2.28-2
ii  libc6   2.28-2
ii  linux-libc-dev  4.18.20-2

libc6-dev recommends no packages.

Versions of packages libc6-dev suggests:
pn  glibc-doc 
ii  manpages-dev  4.16-1

-- no debconf information

Bug#911374: workaround?

[Thomas Lange]

> On Thu, 20 Dec 2018 13:15:01 +0100, Michael Schaller  
> said:

> I think this is a bit overkill. I would just duplicated the code that
> you currently have for /boot:
> 
https://github.com/faiproject/fai/blob/fe481ba1a3fea31c3748fc4becc625655e04b039/lib/setup-storage/Fstab.pm#L248

> If the ESP is mounted on /boot then I think you could just set both
> BOOT and ESP variables to the same values.

It's easy to write the ESP variables if setup-storage finds a
/boot/efi partition. But how should it decide if /boot is used as ESP
or if no UEFI is used at all? How can we detect this?

I would set the ESP variables if I find /boot/efi, and otherwise let
it undefined. But then the case that /boot is used as ESP is not
covered.

-- 
regards Thomas

Bug#916926: dgit: quit fixup fails with secondary orig tarballs and mode 755 files.

[peter green]

Package: dgit
Version: 8.1~bpo9+1
Severity: important

While trying to use autoforwardportergit on firefox-esr I ran into the following errors 
from "dgit -wgf --quilt=auto quilt-fixup"

dgit:  cannot represent change: creation with non-default mode 
(00->100755): l10n-bn-IN/mail/all-l10n.js
dgit:  cannot represent change: creation with non-default mode 
(00->100755): l10n-bn-IN/mail/chrome/messenger/messengercompose/mailCompose
dgit:  cannot represent change: creation with non-default mode 
(00->100755): l10n-bn-IN/mail/chrome/messenger/newTagDialog.dtd
dgit:  cannot represent change: creation with non-default mode 
(00->100755): l10n-bn-IN/mail/defines.inc
dgit:  cannot represent change: creation with non-default mode 
(00->100755): l10n-bn-IN/mail/installer/custom.properties
dgit:  cannot represent change: creation with non-default mode 
(00->100755): l10n-bn-IN/mail/installer/mui.properties
dgit:  cannot represent change: creation with non-default mode 
(00->100755): l10n-bn-IN/mail/installer/override.properties

Investigating it seems that the files in question are located in secondary orig 
tarballs. Not sure why dgit is not finding them.

Steps to reproduce:

dget 
http://deb.debian.org/debian/pool/main/f/firefox-esr/firefox-esr_60.4.0esr-1.dsc
mkdir tempgit
cd tempgit
git init
dgit import-dsc ../firefox-esr_60.4.0esr-1.dsc workingbranch
git checkout workingbranch
dgit -wgf --quilt=auto quilt-fixup

Bug#916927: aptitude: should consistently choose between signed and unsigned kernels

[Vincent Lefevre]

Package: aptitude
Version: 0.8.11-6
Severity: normal

After an upgrade of linux-image-amd64, which now depends on
linux-image-4.19.0-1-amd64, on one machine I got:

  linux-image-4.19.0-1-amd64 4.19.9-1

but on another machine I got:

  linux-image-4.19.0-1-amd64-unsigned 4.19.9-1

while only signed kernels were installed until now (on both machines).
This is not consistent.

But the issue may also be with linux-latest, which doesn't provide
different meta-packages for signed and unsigned kernels.

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

aptitude version information:
aptitude 0.8.11
Compiler: g++ 8.2.0
Compiled against:
  apt version 5.0.2
  NCurses version 6.1
  libsigc++ version: 2.10.1
  Gtk+ support disabled.
  Qt support disabled.

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

aptitude linkage:
linux-vdso.so.1 (0x7fff69d74000)
libgtk3-nocsd.so.0 => /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 
(0x7fd5d5898000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7fd5d56c5000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7fd5d568b000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7fd5d565d000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fd5d5654000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7fd5d554e000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fd5d542b000)
libboost_iostreams.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7fd5d540d000)
libboost_system.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7fd5d5406000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7fd5d51db000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fd5d51ba000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fd5d5037000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fd5d4eb2000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fd5d4e98000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fd5d4cd7000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd5d4cd2000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7fd5d4cb8000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fd5d4a9a000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fd5d4a85000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fd5d485f000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7fd5d4642000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 
(0x7fd5d45a7000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7fd5d4587000)
/lib64/ld-linux-x86-64.so.2 (0x7fd5d5f0)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fd5d457b000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fd5d4572000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.11-6
ii  libapt-pkg5.0 1.8.0~alpha3
ii  libboost-iostreams1.67.0  1.67.0-11
ii  libboost-system1.67.0 1.67.0-11
ii  libc6 2.28-3
ii  libcwidget3v5 0.5.17-11
ii  libgcc1   1:8.2.0-13
ii  libncursesw6  6.1+20181013-1
ii  libsigc++-2.0-0v5 2.10.1-1
ii  libsqlite3-0  3.26.0-3
ii  libstdc++68.2.0-13
ii  libtinfo6 6.1+20181013-1
ii  libxapian30   1.4.9-1

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

Versions of packages aptitude suggests:
pn  apt-xapian-index
ii  aptitude-doc-en [aptitude-doc]  0.8.11-6
pn  debtags 
ii  tasksel 3.48

-- no debconf information

Bug#916928: i18nspector: Emits FutureWarning at every call

[Helge Kreutzmann]

Package: i18nspector
Version: 0.25.6-1
Severity: minor

At every call i18nspector emits the follwoing strings on stderr:
/usr/share/i18nspector/lib/strformat/pybrace.py:39: FutureWarning: Possible 
nested set at position 77
  _simple_field_re = re.compile(_simple_field_pattern, re.VERBOSE)
/usr/share/i18nspector/lib/strformat/pybrace.py:57: FutureWarning: Possible 
nested set at position 182
  ''', re.VERBOSE)
/usr/share/i18nspector/lib/strformat/pybrace.py:57: FutureWarning: Possible 
nested set at position 436
  ''', re.VERBOSE)

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

Kernel: Linux 4.18.16samd.01 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages i18nspector depends on:
ii  python33.7.1-2
ii  python3-polib  1.1.0-3
ii  python3-rply   0.7.4-3

i18nspector recommends no packages.

i18nspector suggests no packages.

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#916765: cups-browsed: Aborts when restarted with "BrowseFilter pdl postscript"

[Brian Potkin]

On Thu 20 Dec 2018 at 14:36:03 +0100, Bernhard Übelacker wrote:

> Hello Brian Potkin,
> I tried to have a look in a unstable VM, but unfortunately
> I get different offsets ...
> 
> You might add the output of this command:
>   dpkg -l | grep -E "cups-browsed|libc6|libglib|libavahi|libdbus" | sort

Attached as list.
 
> And what output did you receive from this command
>   coredumpctl list

Thanks. All this is very new to me. I hope it is what is needed and 
   
someone can interpret it!

root@test:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Thu 2018-12-20 15:06:03 GMT 966 0 0   6 present   
/usr/sbin/cups-browsed

> and following this command, with PID from the above output:
>   coredumpctl gdb PID
> bt
> quit

Two attachments, one without cups-browsed-dbgsym installed (cdc-pid966).
The second contains only what is different from the first.

Regards,

Brian.
ii  cups-browsed 1.21.6-2 
i386 OpenPrinting CUPS Filters - cups-browsed
ii  cups-browsed-dbgsym  1.21.6-2 
i386 debug symbols for cups-browsed
ii  libavahi-client3:i3860.7-4+b1 
i386 Avahi client library
ii  libavahi-client-dev:i386 0.7-4+b1 
i386 Development files for the Avahi client library
ii  libavahi-common3:i3860.7-4+b1 
i386 Avahi common library
ii  libavahi-common-data:i3860.7-4+b1 
i386 Avahi common data files
ii  libavahi-common-dev:i386 0.7-4+b1 
i386 Development files for the Avahi common library
ii  libavahi-core7:i386  0.7-4+b1 
i386 Avahi's embeddable mDNS/DNS-SD library
ii  libavahi-glib1:i386  0.7-4+b1 
i386 Avahi GLib integration library
ii  libavahi-glib-dev:i386   0.7-4+b1 
i386 Development headers for the Avahi GLib integration library
ii  libc6-dbg:i386   2.28-3   
i386 GNU C Library: detached debugging symbols
ii  libc6-dev:i386   2.28-3   
i386 GNU C Library: Development Libraries and Header Files
ii  libc6:i386   2.28-3   
i386 GNU C Library: Shared libraries
ii  libdbus-1-3:i386 1.12.12-1
i386 simple interprocess messaging system (library)
ii  libdbus-1-dev:i386   1.12.12-1
i386 simple interprocess messaging system (development headers)
ii  libdbus-glib-1-2:i3860.110-3  
i386 deprecated library for D-Bus IPC
ii  libdbusmenu-qt2:i386 0.9.3+16.04.20160218-1   
i386 Qt implementation of the DBusMenu protocol
ii  libdbusmenu-qt5-2:i386   0.9.3+16.04.20160218-1   
i386 Qt implementation of the DBusMenu protocol
ii  libglib2.0-0:i3862.58.1-2 
i386 GLib library of C routines
ii  libglib2.0-bin   2.58.1-2 
i386 Programs for the GLib library
ii  libglib2.0-data  2.58.1-2 
all  Common files for GLib library
ii  libglib2.0-dev-bin   2.58.1-2 
i386 Development utilities for the GLib library
ii  libglib2.0-dev:i386  2.58.1-2 
i386 Development files for the GLib library
root@test:~# coredumpctl gdb 966
   PID: 966 (cups-browsed)
   UID: 0 (root)
   GID: 0 (root)
Signal: 6 (ABRT)
 Timestamp: Thu 2018-12-20 15:06:02 GMT (4min 8s ago)
  Command Line: /usr/sbin/cups-browsed
Executable: /usr/sbin/cups-browsed
 Control Group: /system.slice/cups-browsed.service
  Unit: cups-browsed.service
 Slice: system.slice
   Boot ID: c07e532b4b1843218ade4f24c21110a5
Machine ID: b624baf6f24f4633a7a45d1833e04b63
  Hostname: test
   Storage: 
/var/lib/systemd/coredump/core.cups-browsed.0.c07e532b4b1843218ade4f24c21110a5.966.154531836200.lz4
   Message: Process 966 (cups-browsed) of user 0 dumped core.

Stack trace of thread 966:
#0  0xb7fa3d51 __kernel_vsyscall (linux-gate.so.1)
#1  0xb78ca2d2 __libc_signal_restore_set (libc.so.6)
#2  0xb78b42b6 __GI_abort (libc.so.6)
#3  0xb790bc0c __libc_message (li

Bug#871215: Does it make sense to keep frobtads?

[Juhani Numminen]

Hi,

Sebastian Andrzej Siewior kirjoitti 20.12.2018 klo 1.06:
> Hi,
> 
> frobtads wasn't part of Stretch and has two RC bugs open with no action
> in over a year.
> Can it be removed or is somehow important?

I'll just clarify that I have no special interest in frobtads.
In this case, I was trying to find solutions to any RC bugs in general.

--
Juhani

Bug#916927: aptitude: should consistently choose between signed and unsigned kernels

[Ansgar Burchardt]

Control: reassign -1 src:linux 4.19.9-1

On Thu, 20 Dec 2018 16:26:55 +0100 Vincent Lefevre wrote:
> After an upgrade of linux-image-amd64, which now depends on
> linux-image-4.19.0-1-amd64, on one machine I got:
> 
>   linux-image-4.19.0-1-amd64 4.19.9-1
> 
> but on another machine I got:
> 
>   linux-image-4.19.0-1-amd64-unsigned 4.19.9-1

The issue is that linux-image-4.19.0-1-amd64-unsigned has
  Provides: linux-image-4.19.0-1-amd64

So if linux-image-amd64 starts depending on linux-image-4.19.0-1-amd64
before the signed version is present, apt will install the unsigned
version.  This doesn't look like a bug in apt to me.

The easiest way to avoid this would be to drop the Provides from the
unsigned image.  Is there any downside for doing so?

Ansgar

Bug#916909: 0ad game fails to start

[scdesign]

Thank you Simon! There were 600+ packages updated, so no need to post them all.
Downgrade of libnvtt2 from 2.1 to 2.08 solves the problem. So the key is in 
this library.

Versions of packages 0ad depends on:
ii  0ad-data   0.0.23-1
ii  0ad-data-common0.0.23-1
ii  dpkg   1.19.2
ii  libboost-filesystem1.67.0  1.67.0-11
ii  libboost-system1.67.0  1.67.0-11
ii  libc6  2.28-3
ii  libcurl3-gnutls7.62.0-1
ii  libenet7   1.3.13+ds-1
ii  libgcc11:8.2.0-13
ii  libgl1-mesa-glx [libgl1]   13.0.6-1~bpo8+1
ii  libgloox17 1.0.20-2
ii  libicu63   63.1-5
ii  libminiupnpc17 2.1-1+b1
ii  libnspr4   2:4.20-1
ii  libnvtt2   2.1.0-git20160229+dfsg-2~exp1+b3
ii  libopenal1 1:1.19.1-1
ii  libpng16-161.6.34-2
ii  libsdl2-2.0-0  2.0.8+dfsg1-6
ii  libsodium231.0.16-2
ii  libstdc++6 8.2.0-13
ii  libvorbisfile3 1.3.6-1
ii  libwxbase3.0-0v5   3.0.4+dfsg-7
ii  libwxgtk3.0-0v53.0.4+dfsg-7
ii  libx11-6   2:1.6.7-1
ii  libxcursor11:1.1.15-2
ii  libxml22.9.8+dfsg-1
ii  zlib1g 1:1.2.11.dfsg-1

Best regards,
Andrei.



20.12.2018, 15:03, "Simon McVittie" :
> On Thu, 20 Dec 2018 at 13:53:15 +0300, scdes...@yandex.ru wrote:
>>  After big upgrade of system libs via aptitude (also 0ad was updated from 
>> 0.0.23-1 to 0.0.23-1+b2)
>
> What packages were upgraded during that transaction? You can find out
> from /var/log/apt/history.log.
>
>>  the game fails to start with following error:
>>
>>  $ 0ad
>>  /usr/games/pyrogenesis: symbol lookup error: /usr/games/pyrogenesis: 
>> undefined symbol: 
>> _ZN4nvtt12InputOptions16setTextureLayoutENS_11TextureTypeEiii
>
> This is a serious bug in *something*, but I'm not sure what.
>
> Please send the version numbers of the packages that your 0ad package
> depends on. You can get this information with "reportbug --template
> 0ad"; it would be helpful to use reportbug to report bugs in future,
> so that they already have this information.
>
> The missing symbol demangles to
>
> nvtt::InputOptions::setTextureLayout(nvtt::TextureType, int, int, int)
>
> which looks like it should come from nvidia-texture-tools, but that
> package hasn't been updated since 2016, and was most recently rebuilt
> several months ago.
>
> smcv

Bug#911374: workaround?

[Thomas Lange]

This is now the fix, which I tested using a loop device.
Also works with a /boot/efi partition.

https://github.com/faiproject/fai/commit/d120c26c788b13b83f60f3bd1f3f5feb65cc7a55

Example:

disk_config disk1  disklabel:gpt  fstabkey:uuid  align-at:1M

primary   /boot 64M vfat   rw
primary   / 40-ext4   defaults
primary   swap  10  swap   sw


---
# disk_var.sh as YAML
ESP_DEVICE: /dev/loop0p1
SWAPLIST: /dev/loop0p3
ROOT_PARTITION: UUID=cd6aa710-56d4-439a-bf4d-0baa29cc15d8
BOOT_PARTITION: /dev/loop0p1
BOOT_DEVICE: /dev/loop0

-- 
regards Thomas

Bug#916921: radicale: upgrade to 2.x breaks compatibility with 1.x without any prior warning

[Jonas Smedegaard]

Control: severity -1 serious

Quoting Bernard Massot (2018-12-20 15:02:12)
> On Debian unstable, Radicale was just upgraded from 1.x to 2.x. Only 
> after upgrading did I realize that my calendars were not available any 
> more.
> 
> As stated on https://radicale.org/1to2/, upgrade to 2.x forces you to 
> use Python 3, and thus to upgrade mod_wsgi as well. I was using Python 
> 2 version of mod_wsgi only because it was the default version and it 
> wasn't causing any problem (Radicale was my only WSGI application).
> Moreover, Radicale 2.x can't even use 1.x data files. You must export 
> your files *before* upgrading.
> 
> The Debian package silently ignores all these issues. I think there 
> should be warning messages and a ad hoc prerm kind of script.

A NEWS entry was intended to be in place, but evidently was missed.

Raising severity to not enter testing without that in place.  Thanks!


> By the way, installing Radicale 1.x and using --export-storage didn't 
> even work for me. It probably had something to do with my using single 
> iCalendar file calendars and my /etc/radicale/config was not 
> configured to support this anymore.

which version did you upgrade from?

Upgrading from 1.1.6-4 (currently in testing) should attempt(!) to do an 
export to /var/backup before code and configfile is changed.

Upgrading from older releases (i.e. stable) is known broken: 
https://bugs.debian.org/864746


> (for some reason, Radicale uses random hexadecimal strings instead of 
> calendar title, whereas it is the actual string you have to type in 
> your CalDAV client),

This is part of the CalDAV and CardDAV specifications, to not be limited 
by filesystem constraints - e.g. calendars with same name do not clash.


> [importing via Thunderbird addon Lightning to new calendars] actually 
> was more straightforward than using the whole export storage thing.

Depending on how exactly your old data was stored (there were multiple 
formats, and they were more permissive) you might indeed have better 
luck with other migration approaches than https://radicale.org/1to2/ - 
for some cases consulting https://radicale.org/storage/ may be relevant.


 - Jonas

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

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


signature.asc
Description: signature

Bug#916929: RFS: extsmail/2.2-2 -- enables the robust sending of e-mail to external commands

[Olivier Girondel]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: extsmail
   Version : 2.2-2
   Upstream Author : Laurence Tratt 
 * URL : https://tratt.net/laurie/src/extsmail/
 * License : BSD/MIT
   Section : mail

  It builds this binary package:

extsmail   - enables the robust sending of e-mail to external commands

  The package appears to be lintian-clean

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

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


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

dget -x
https://mentors.debian.net/debian/pool/main/e/extsmail/extsmail_2.2-2.dsc

  Changes since the last upload:

  * debian/control: Remove Vcs-Git.
  * debian/patches/*: Fix FTBFS.

  Changes in 2.2-1:

  * New upstream release 2.2. (Closes: #748739)
  * debian/compat: Upgrade to 11.
  * debian/control: Priority: optional.
  * debian/control: Vcs-Browser: https://github.com/ltratt/extsmail.
  * debian/control: Vcs-Git: https://github.com/ltratt/extsmail.git.
  * debian/control: Build-Depends: Remove dh-autoreconf.
  * debian/control: Build-Depends: Update debhelper (>= 11).
  * debian/control: Update Homepage.
  * debian/control: Standards-Version: 4.2.1.
  * debian/copyright: Update copyright years.
  * debian/copyright: Update Source URL.
  * debian/copyright: Use secure copyright format URI.
  * debian/rules: Remove --with autoreconf.
  * debian/tests/control: Added.
  * debian/watch: version=4.
  * debian/watch: Use secure URI.

  Regards,

--
Olivier

Bug#916930: netatalk: CVE-2018-1160: Unauthenticated remote code execution in Netatalk

[Salvatore Bonaccorso]

Source: netatalk
Version: 2.2.5-2
Severity: grave
Tags: patch security upstream
Justification: user security hole
Control: found -1 2.2.6-1.1
Control: fixed -1 2.2.5-2+deb9u1

Hi,

The following vulnerability was published for netatalk.

CVE-2018-1160[0]:
Unauthenticated remote code execution in Netatalk

More information and patches for 2.2 branch can be found in [1].

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-1160
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1160
[1] https://bugzilla.samba.org/show_bug.cgi?id=13711
[2] http://netatalk.sourceforge.net/3.1/ReleaseNotes3.1.12.html

Regards,
Salvatore

Bug#916879: qtox: missing library libsodium.so.18

[Christian Weinz]

$ ls -l /usr/lib/x86_64-linux-gnu/libsodium.*
-rw-r--r-- 1 root root 569012 Dez 26  2017 /usr/lib/x86_64-linux-
gnu/libsodium.a
lrwxrwxrwx 1 root root 19 Dez 26  2017 /usr/lib/x86_64-linux-
gnu/libsodium.so -> libsodium.so.23.1.0
lrwxrwxrwx 1 root root 19 Dez 26  2017 /usr/lib/x86_64-linux-
gnu/libsodium.so.23 -> libsodium.so.23.1.0
-rw-r--r-- 1 root root 338632 Dez 26  2017 /usr/lib/x86_64-linux-
gnu/libsodium.so.23.1.0

Bug#916879: Acknowledgement (qtox: missing library libsodium.so.18)

[Christian Weinz]

$ date
Do 20. Dez 16:57:51 CET 2018
$ sudo apt update
OK:1 http://ftp.de.debian.org/debian sid InRelease
OK:2 http://ftp.de.debian.org/debian buster InRelease
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
Aktualisierung für 27 Pakete verfügbar. Führen Sie »apt list --
upgradable« aus, um sie anzuzeigen.
$ sudo apt install --reinstall qtox
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen
und 27 nicht aktualisiert.
Es müssen noch 0 B von 4.939 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
(Lese Datenbank ... 755019 Dateien und Verzeichnisse sind derzeit
installiert.)
Vorbereitung zum Entpacken von .../qtox_1.16.3-1_amd64.deb ...
Entpacken von qtox (1.16.3-1) über (1.16.3-1) ...
Trigger für mime-support (3.61) werden verarbeitet ...
Trigger für desktop-file-utils (0.23-4) werden verarbeitet ...
qtox (1.16.3-1) wird eingerichtet ...
Trigger für man-db (2.8.4-3) werden verarbeitet ...
Trigger für gnome-menus (3.13.3-11) werden verarbeitet ...
Trigger für hicolor-icon-theme (0.17-2) werden verarbeitet ...
$ qtox
qtox: error while loading shared libraries: libsodium.so.18: cannot
open shared object file: No such file or directory
$ ldd /usr/bin/qtox | grep sod
libsodium.so.23 => /usr/lib/x86_64-linux-gnu/libsodium.so.23
(0x7fe0c3c15000)
libsodium.so.18 => not found
$ which qtox
/usr/bin/qtox

Bug#916931: [gajim] Has package relations to unavailable packages

[Bruno Kleinert]

Package: gajim
Version: 1.1.0-1
Severity: normal

--- Please enter the report below this line. ---
Hi,

gajim recommends gstreamer0.10-plugins-ugly which is no longer
available. The package relation should either be removed or updated to
gstreamer1.0-plugins-ugly instead. Of course, the latter only makes
sense if gajim still makes any use of that package.

It suggests python3-gconf and python3-gnome2 which are unavailable. I'm
sure they can be simply dropped, since there seem to be no successors
available.

Cheers - Bruno

--- System information. ---
Architecture: 
Kernel:   Linux 4.19.0-1-amd64

Debian Release: buster/sid
  500 unstable-debug  deb.debian.org 
  500 unstabledeb.debian.org 
1 experimental-debug deb.debian.org 
1 experimentaldeb.debian.org 

--- Package information. ---
Depends  (Version) | Installed
==-+-===
python3-cssutils(>= 1.0.2) | 1.0.2-1
python3-keyring| 16.1.1-1
python3-nbxmpp  (>= 0.6.7) | 0.6.8-1
python3-openssl  (>= 0.12) | 18.0.0-1
python3-precis-i18n| 1.0.0-1
python3:any| 
gir1.2-gtk-3.0   (>= 3.22) | 3.24.2-3
python3   (>= 3.5) | 3.7.1-3
python3-gi | 3.30.4-1
python3-gi-cairo   | 3.30.4-1
python3-idna   | 2.6-1


Recommends   (Version) | Installed
==-+-===
aspell-en  | 2018.04.16-0-1
 OR aspell-dictionary  | 
ca-certificates| 20180409
dbus   | 1.12.12-1
fonts-noto-color-emoji | 0~20180810-1
gajim-omemo (>= 2.5.1) | 2.6.24-1
gajim-pgp  | 1.2.24-1
gir1.2-farstream-0.2   | 0.2.8-4
gir1.2-geoclue-2.0 | 2.5.1-1
gir1.2-gspell-1| 1.6.1-1
gir1.2-gst-plugins-base-1.0| 1.14.4-1
gir1.2-gstreamer-1.0   | 1.14.4-1
gir1.2-gupnpigd-1.0| 0.2.5-2
gir1.2-secret-1| 0.18.6-3
gstreamer0.10-plugins-ugly | 
notification-daemon| 3.20.0-3
pulseaudio-utils   | 12.2-2
 OR alsa-utils | 
 OR sox| 14.4.2-3
 OR oss4-base  | 
python3-crypto | 2.6.1-9+b1
python3-dbus (>= 0.81) | 1.2.8-2+b2
python3-gnupg   (>= 0.4.1) | 0.4.3-2
python3-pil| 5.3.0-1


Suggests  (Version) | Installed
===-+-===
avahi-daemon| 0.7-4+b1
libxss1 | 1:1.2.3-1
nautilus-sendto | 3.8.6-2
python3-gconf   | 
python3-gnome2  | 
python3-kerberos   (>= 1.1) | 
python3-pycurl  | 7.43.0.1-0.2+b1






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

Bug#916932: yara: CVE-2018-19974, CVE-2018-19975, CVE-2018-19976

[Markus Koschany]

Package: yara
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for yara.

CVE-2018-19974[0]:
| In YARA 3.8.1, bytecode in a specially crafted compiled rule can read
| uninitialized data from VM scratch memory in libyara/exec.c. This can
| allow attackers to discover addresses in the real stack (not the YARA
| virtual stack).

CVE-2018-19975[1]:
| In YARA 3.8.1, bytecode in a specially crafted compiled rule can read
| data from any arbitrary address in memory, in libyara/exec.c.
| Specifically, OP_COUNT can read a DWORD.

CVE-2018-19976[2]:
| In YARA 3.8.1, bytecode in a specially crafted compiled rule is
| exposed to information about its environment, in libyara/exec.c. This
| is a consequence of the design of the YARA virtual machine.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-19974
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19974
[1] https://security-tracker.debian.org/tracker/CVE-2018-19975
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19975
[2] https://security-tracker.debian.org/tracker/CVE-2018-19976
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19976

Please adjust the affected versions in the BTS as needed.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#916879: qtox: missing library libsodium.so.18

[Yangfl]

Christian Weinz  于2018年12月20日周四 下午11:59写道：
>
> Am Donnerstag, den 20.12.2018, 11:36 +0800 schrieb Yangfl:
> > $ sudo apt install --reinstall qtox
> > [...]
> > $ ldd /usr/bin/qtox | grep sod
> > libsodium.so.23 => /usr/lib/x86_64-linux-gnu/libsodium.so.23
> > (0x7f8415cc9000)
> > $ ll /usr/lib/x86_64-linux-gnu/libsodium.so*
> > lrwxrwxrwx 1 root root   19 12月 26  2017
> > /usr/lib/x86_64-linux-gnu/libsodium.so.23 -> libsodium.so.23.1.0
> > -rw-r--r-- 1 root root 331K 12月 26  2017
> > /usr/lib/x86_64-linux-gnu/libsodium.so.23.1.0
>
> $ date
> Do 20. Dez 16:57:51 CET 2018
> $ sudo apt update
> OK:1 http://ftp.de.debian.org/debian sid InRelease
> OK:2 http://ftp.de.debian.org/debian buster InRelease
> Paketlisten werden gelesen... Fertig
> Abhängigkeitsbaum wird aufgebaut.
> Statusinformationen werden eingelesen Fertig
> Aktualisierung für 27 Pakete verfügbar. Führen Sie »apt list --
> upgradable« aus, um sie anzuzeigen.
> $ sudo apt install --reinstall qtox
> Paketlisten werden gelesen... Fertig
> Abhängigkeitsbaum wird aufgebaut.
> Statusinformationen werden eingelesen Fertig
> 0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen
> und 27 nicht aktualisiert.
> Es müssen noch 0 B von 4.939 kB an Archiven heruntergeladen werden.
> Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
> (Lese Datenbank ... 755019 Dateien und Verzeichnisse sind derzeit
> installiert.)
> Vorbereitung zum Entpacken von .../qtox_1.16.3-1_amd64.deb ...
> Entpacken von qtox (1.16.3-1) über (1.16.3-1) ...
> Trigger für mime-support (3.61) werden verarbeitet ...
> Trigger für desktop-file-utils (0.23-4) werden verarbeitet ...
> qtox (1.16.3-1) wird eingerichtet ...
> Trigger für man-db (2.8.4-3) werden verarbeitet ...
> Trigger für gnome-menus (3.13.3-11) werden verarbeitet ...
> Trigger für hicolor-icon-theme (0.17-2) werden verarbeitet ...
> $ qtox
> qtox: error while loading shared libraries: libsodium.so.18: cannot
> open shared object file: No such file or directory
> $ ldd /usr/bin/qtox | grep sod
> libsodium.so.23 => /usr/lib/x86_64-linux-gnu/libsodium.so.23
> (0x7fe0c3c15000)
> libsodium.so.18 => not found
>

> und 27 nicht aktualisiert.

Please do an upgrade. I just tried qtox on the latest sid, the latest
testing, and debs from ftp.de, everything looks fine and works well.

If problem still exists, please post the full log of ldd, versions of
qtox dependencies, and don't forget to cc bugs.d.o.

Bug#916879: qtox: missing library libsodium.so.18

[Christian Weinz]

Am Freitag, den 21.12.2018, 00:17 +0800 schrieb Yangfl:
> Please do an upgrade. I just tried qtox on the latest sid, the latest
> testing, and debs from ftp.de, everything looks fine and works well.
> 
> If problem still exists, please post the full log of ldd, versions of
> qtox dependencies, and don't forget to cc bugs.d.o.

I did an upgrade before, too. Anyways, I did again one, but apt didn't
update anything. I forgot to cc bugs.debian.org before, sorry.

$ sudo apt update
OK:1 http://ftp.de.debian.org/debian sid InRelease
OK:2 http://ftp.de.debian.org/debian buster InRelease
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
Aktualisierung für 27 Pakete verfügbar. Führen Sie »apt list --
upgradable« aus, um sie anzuzeigen.
$ sudo apt upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
Die folgenden Pakete sind zurückgehalten worden:
  cups cups-bsd cups-client cups-core-drivers cups-daemon cups-ipp-
utils gap icedtea-netx icu-devtools libcups2 libcups2:i386
libcupsimage2
  libicu-dev libicu63 libicu63:i386 libpynac18 libsane-common libsnmp30
libsnmp30:i386 libvoikko1 libvtk6.3 lm-sensors python3-libvoikko
  singular-data singular-modules singular-ui sysstat
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 27 nicht
aktualisiert.
$ ldd /usr/bin/qtox
linux-vdso.so.1 (0x7ffd053c6000)
libQt5Network.so.5 => /usr/lib/x86_64-linux-
gnu/libQt5Network.so.5 (0x7f1da6fa7000)
libQt5Svg.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Svg.so.5
(0x7f1da6f51000)
libQt5Widgets.so.5 => /usr/lib/x86_64-linux-
gnu/libQt5Widgets.so.5 (0x7f1da68f9000)
libQt5Xml.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Xml.so.5
(0x7f1da68ba000)
libavcodec.so.58 => /usr/lib/x86_64-linux-gnu/libavcodec.so.58
(0x7f1da53c3000)
libavdevice.so.58 => /usr/lib/x86_64-linux-
gnu/libavdevice.so.58 (0x7f1da5391000)
libavformat.so.58 => /usr/lib/x86_64-linux-
gnu/libavformat.so.58 (0x7f1da5137000)
libavutil.so.56 => /usr/lib/x86_64-linux-gnu/libavutil.so.56
(0x7f1da50b9000)
libexif.so.12 => /usr/lib/x86_64-linux-gnu/libexif.so.12
(0x7f1da4e74000)
libqrencode.so.4 => /usr/lib/x86_64-linux-gnu/libqrencode.so.4
(0x7f1da4e66000)
libsodium.so.23 => /usr/lib/x86_64-linux-gnu/libsodium.so.23
(0x7f1da4c13000)
libswscale.so.5 => /usr/lib/x86_64-linux-gnu/libswscale.so.5
(0x7f1da4b8)
libsqlcipher.so.0 => /usr/lib/x86_64-linux-
gnu/libsqlcipher.so.0 (0x7f1da48a5000)
libtoxcore.so.2 => /usr/local/lib/libtoxcore.so.2
(0x7f1da4667000)
libopenal.so.1 => /usr/lib/x86_64-linux-gnu/libopenal.so.1
(0x7f1da457f000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
(0x7f1da443e000)
libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1
(0x7f1da4439000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-
gnu/libgdk_pixbuf-2.0.so.0 (0x7f1da4413000)
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-
2.0.so.0 (0x7f1da43bd000)
libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
(0x7f1da42a)
libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-
2.0.so.0 (0x7f1da3e59000)
libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-
2.0.so.0 (0x7f1da3da2000)
libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2
(0x7f1da3c82000)
libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
(0x7f1da3ade000)
libQt5Gui.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
(0x7f1da3554000)
libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
(0x7f1da305a000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f1da2ed7000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
(0x7f1da2d54000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f1da2d33000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
(0x7f1da2b72000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
(0x7f1da2952000)
libswresample.so.3 => /usr/lib/x86_64-linux-
gnu/libswresample.so.3 (0x7f1da2931000)
libvpx.so.5 => /usr/lib/x86_64-linux-gnu/libvpx.so.5
(0x7f1da24e2000)
libwebpmux.so.3 => /usr/lib/x86_64-linux-gnu/libwebpmux.so.3
(0x7f1da22d8000)
libwebp.so.6 => /usr/lib/x86_64-linux-gnu/libwebp.so.6
(0x7f1da206f000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5
(0x7f1da1e49000)
libcrystalhd.so.3 => /usr/lib/x86_64-linux-
gnu/libcrystalhd.so.3 (0x7f1da1c2c000)
librsvg-2.so.2 => /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
(0x7f1da16b6000)
libzvbi.so.0 => /usr/lib/x86_64-linux-gnu/libzvbi.so

Bug#836934: Bug#871215: Does it make sense to keep frobtads?

[Daniel Schepler]

On Wed, Dec 19, 2018 at 3:42 PM Sebastian Andrzej Siewior
 wrote:
> frobtads wasn't part of Stretch and has two RC bugs open with no action
> in over a year.
> Can it be removed or is somehow important?

In a Google search, I found newer upstream releases on GitHub -
https://github.com/realnc/frobtads/releases .  The release notes do
mention fixing some compilation issues with newer gcc.

Same goes for qtads - there's a 2.1.7 release, though that's from
2016.  It might be worth checking if that version builds, and whether
it works with Qt 5.  (The latter needs a run-time test: when I tried
it last, 2.1.6 built successfully against Qt 5 but then the resulting
executable was completely broken.)

Currently, though, my previous GPG key was removed from the Debian
keyring and I haven't gotten around to finding somebody locally who
could sign a new key for me.  So, I wouldn't be able to upload updated
packages myself.
-- 
Daniel Schepler

Bug#916933: RFS: libgsm/1.0.18-1 [ITA]

[Felix Lechner]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: Mattia Rizzolo 

  Dear mentors,

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

 * Package name: libgsm
   Version : 1.0.18-1
   Upstream Author : Jutta Degener 
 * URL : http://www.quut.com/gsm/
 * License : TU-Berlin-2.0
   Section : libs

  It builds those binary packages:

 libgsm-tools - User binaries for a GSM speech compressor
 libgsm1- Shared libraries for GSM speech compressor
 libgsm1-dev - Development libraries for a GSM speech compressor

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/libg/libgsm/libgsm_1.0.18-1.dsc

  The last upload for this library was in 2012. Since two of my
packages use it, I decided to adopt it.

  Changes since the last upload:

  * New upstream version
  * New maintainer (Closes: #891760)
  * Only ship gsm.h (Closes: #882176)
  * Migrated rules to dh(1)
  * Updated patches (most of 05 was accepted upstream)
  * Bumped shared object version in 01 patch
  * Made copyright file dep5 machine readable
  * Added README.Debian about (non-)patent status
  * Updated upstream URL in watch file
  * Turned on migration to automatic debug packages
  * Removed old debug package from control
  * Removed libgsm1-dbg.install
  * Added homepage field to control
  * Removed trailing whitespace from changelog
  * Removed trailing whitespace from control
  * Removed ancient Conflicts: from control
  * Corrected two misspellings in man via 06 patch
  * Removed duplicate binary control field for section
  * Set Build-Depends: debhelper (>= 11)
  * Set compat to 11
  * Updated Standards-Version: 4.2.1


  Regards,
   Felix Lechner

Bug#916879: qtox: missing library libsodium.so.18

[Yangfl]

Christian Weinz  于2018年12月21日周五 上午12:27写道：
>
> libtoxcore.so.2 => /usr/local/lib/libtoxcore.so.2
> (0x7f1da4667000)
>

$ ldd /usr/lib/x86_64-linux-gnu/libtoxcore.so.2 | grep sod
libsodium.so.23 => /usr/lib/x86_64-linux-gnu/libsodium.so.23
(0x7f1ff9ea5000)

Please remove local toxcore.

Bug#882255: libc6-dev: #define _SC_PAGESIZE _SC_PAGESIZE in /usr/include/x86_64-linux-gnu/bits/confname.h

[Aurelien Jarno]

control: notfound -1 glibc/2.28-2

On 2018-12-20 09:55, Florin Iucha wrote:
> Package: libc6-dev
> Version: 2.28-2
> Followup-For: Bug #882255

Please do not reuse unrelated bug for reporting new ones.

> Trying to compile a personal project using Clang7 and maximum warning
> settings, it produced the following warning:
> 
> error: disabled expansion of recursive macro
> [-Werror,-Wdisabled-macro-expansion]
> 
> /usr/include/x86_64-linux-gnu/bits/confname.h:134:24: note: expanded
> from macro '_SC_PAGESIZE' 
>
> #define _SC_PAGESIZE_SC_PAGESIZE
> 
> I think the confname.h has that line as a result of a mis-merge. There's
> no point in defining X as X.

No this is not a merge issue and it is correct. It is there to define
_SC_PAGESIZE both as an enum value and a defined value that can be
tested with #ifdef.

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

Bug#916879: qtox: missing library libsodium.so.18

[Christian Weinz]

Am Freitag, den 21.12.2018, 00:40 +0800 schrieb Yangfl:
> Christian Weinz  于2018年12月21日周五 上午12:27写道：
> > libtoxcore.so.2 => /usr/local/lib/libtoxcore.so.2
> > (0x7f1da4667000)
> > 
> 
> $ ldd /usr/lib/x86_64-linux-gnu/libtoxcore.so.2 | grep sod
> libsodium.so.23 => /usr/lib/x86_64-linux-gnu/libsodium.so.23
> (0x7f1ff9ea5000)
> 
> Please remove local toxcore.

This solved the problem. qTox starts now just fine.

Bug#916934: override: i3pystatus:x11/required

[Esteban Bosse]

Package: ftp.debian.org
Severity: normal

The new version of package: 3.35~git20180925.a586a50-2 have a section
bug fix. Before the fix the section was: `python`. And the fix change it
for x11. 
For some reason, when I run `apt show i3pystatus | grep Section`
the section still be de previous one (python).
Can someone help? 
Thanks!

Bug#890342: Sorry for the late response from my side too.

[Gregor Riepl]

> I just ran the latest version of telegram-desktop and this is what I
> see on the CLI -
> 
> $ telegram-desktop
>   OpenType support missing for "Open Sans Semibold", script 11
>   OpenType support missing for "Open Sans", script 11
>   OpenType support missing for "Open Sans", script 11
> 
> Now I dont' know what script 11 means, does it mean something getting
> triggered in telegram-desktop or something elsewhere ?

Script 11 probably means font size 11pt.

Do you only see the error message or are there also font rendering errors in
Telegram? If not, it's probably best to ignore the error.
If there are problems, you should contact the Telegram developers or open a
new bug report for the telegram package.

As far as I know, there only is a TrueType version of Open Sans. Anything else
would have to be converted.

There's also no bug tracker, version information or other developer
information, except for what you can find on https://www.opensans.com/ and
https://fonts.google.com/?selection.family=Open+Sans

I don't think there's anything that can be done for fonts-open-sans, so I'm
going to close this bug as wontfix.