Bug#896866: linux-image-4.15.0-2-amd64: Unable to shutdown
Package: src:linux Version: 4.15.11-1 Severity: important Dear Maintainer, * What led up to the situation? When shuting down the computer, I've a console message: "do_IRQ 0.55 No irq handler for vector" and the computer is blocked, I've to press the power button for 10 s to effectively shut down the computer. Thois message appears at the realy end of the process, after the systemd "Shutting down." started. * What exactly did you do (or not do) that was effective (or ineffective)? This error appears since I'm using the 4.15 kernel. * What was the outcome of this action? * What outcome did you expect instead? EFfectively shutting down trhe computer. -- Package-specific info: ** Version: Linux version 4.15.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-12)) #1 SMP Debian 4.15.11-1 (2018-03-20) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-2-amd64 root=UUID=46ca182e-cbb4-42e6-a1eb-a454cecd7083 ro quiet init=/lib/systemd/systemd ** Not tainted ** Kernel log: [ 16.654077] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 16.654127] sr 1:0:0:0: Attached scsi generic sg1 type 5 [ 16.689466] asus_laptop: Asus Laptop Support version 0.42 [ 16.690334] asus_laptop: BSTS called, 0xfb5f returned [ 16.690349] asus_laptop: K61IC model detected [ 16.692251] input: Asus Laptop extra buttons as /devices/platform/asus_laptop/input/input16 [ 16.694319] ACPI: Battery Slot [BAT0] (battery present) [ 17.137698] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 17.138117] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 17.187477] platform regulatory.0: firmware: failed to load regulatory.db (-2) [ 17.187506] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware [ 17.187524] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 17.187529] cfg80211: failed to load regulatory.db [ 17.472379] intel_powerclamp: No package C-state available [ 17.553471] ACPI: PCI Interrupt Link [LN4A] enabled at IRQ 17 [ 17.600523] ath: phy0: Enable LNA combining [ 17.605805] ath: EEPROM regdomain: 0x60 [ 17.605808] ath: EEPROM indicates we should expect a direct regpair map [ 17.605811] ath: Country alpha2 being used: 00 [ 17.605812] ath: Regpair used: 0x60 [ 17.795554] input: PC Speaker as /devices/platform/pcspkr/input/input17 [ 17.858155] ACPI: PCI Interrupt Link [LAZA] enabled at IRQ 21 [ 17.858169] snd_hda_intel :00:08.0: Disabling MSI [ 18.058096] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 18.058821] ieee80211 phy0: Atheros AR9285 Rev:2 mem=0xb8b3c0e1, irq=17 [ 19.421495] media: Linux media interface: v0.10 [ 19.604086] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC662 rev1: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker [ 19.604092] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 19.604096] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) [ 19.604099] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0 [ 19.604102] snd_hda_codec_realtek hdaudioC0D0:inputs: [ 19.604107] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x19 [ 19.604111] snd_hda_codec_realtek hdaudioC0D0: Mic=0x18 [ 19.648245] Linux video capture interface: v2.00 [ 20.165172] uvcvideo: Found UVC 1.00 device CNF7129 (04f2:b071) [ 20.187892] uvcvideo 1-5:1.0: Entity type for entity Extension 5 was not initialized! [ 20.187897] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was not initialized! [ 20.187899] uvcvideo 1-5:1.0: Entity type for entity Processing 3 was not initialized! [ 20.187902] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not initialized! [ 20.188258] input: CNF7129: USB2.0 1.3M UVC WebCam as /devices/pci:00/:00:04.1/usb1/1-5/1-5:1.0/input/input18 [ 20.188372] usbcore: registered new interface driver uvcvideo [ 20.188373] USB Video Class driver (1.1.1) [ 21.225370] input: HDA Digital PCBeep as /devices/pci:00/:00:08.0/sound/card0/input19 [ 21.226427] input: HDA NVidia Mic as /devices/pci:00/:00:08.0/sound/card0/input20 [ 21.226515] input: HDA NVidia Headphone as /devices/pci:00/:00:08.0/sound/card0/input21 [ 26.005111] Adding 3951984k swap on /dev/sda2. Priority:-2 extents:1 across:3951984k FS [ 26.680823] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null) [ 28.614472] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) [ 29.173152] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 29.267053] audit: type=1400 audit(1524636120.300:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="system_tor" pid=576 comm="apparmor_parser" [ 29.372736] audit: type=1400 audit(1524636120.408:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=586 comm="apparmo
Bug#896865: ruby-grpc: FTBFS on ppc64el: Failure/Error: require_relative 'grpc_c'
Source: ruby-grpc Version: 1.3.2+debian-4 Severity: serious Your package failed to build on ppc64el: An error occurred while loading /<>/ruby-grpc-1.3.2+debian/src/ruby/spec/time_consts_spec.rb. Failure/Error: require_relative 'grpc_c' Full logs at: https://buildd.debian.org/status/fetch.php?pkg=ruby-grpc&arch=ppc64el&ver=1.3.2%2Bdebian-4%2Bb1&stamp=1522784711&raw=0 Emilio
Bug#849094: liblept5: Broken on s390x (+ other big endian archs)
Am 25.04.2018 um 03:37 schrieb Dan Bloomberg: > There's an endianness.h file in leptonica/src. Does it say BIG_ENDIAN > or LITTLE_ENDIAN on your s390? It says BIG_ENDIAN on my emulated S390X with Debian Testing. Is arrayaccess.h correct for big endian machines? The 16 and 32 bit accessors look strange because they swap the words, but not the bytes.
Bug#896864: python-redis autopkg test failures on i386
Package: src:python-redis
Version: 2.10.6-2
Severity: important
Tags: sid buster
Only seen on the Ubuntu CI, however I cannot see the Debian CI running this on
i386:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/i386/p/python-redis/20180409_182323_14366@/log.gz
same failures for Python2 and Python3
= test session starts ==
platform linux -- Python 3.6.5, pytest-3.3.2, py-1.5.2, pluggy-0.6.0
rootdir: /tmp/autopkgtest.3GpgXS/build.p2f/src, inifile:
collected 356 items
tests/test_commands.py . [ 13%]
[ 33%]
[ 54%]
...F.s...F...FF..[ 61%]
tests/test_connection_pool.py .. [ 73%]
.[ 73%]
tests/test_encoding.py [ 74%]
tests/test_lock.py . [ 83%]
tests/test_pipeline.py ..[ 87%]
tests/test_pubsub.py . [ 94%]
tests/test_scripting.py ... [ 96%]
tests/test_sentinel.py [100%]
=== FAILURES ===
TestRedisCommands.test_geopos _
self =
r = Redis>>
@skip_if_server_version_lt('3.2.0')
def test_geopos(self, r):
values = (2.1909389952632, 41.433791470673, 'place1') +\
(2.1873744593677, 41.406342043777, 'place2')
r.geoadd('barcelona', *values)
# redis uses 52 bits precision, hereby small errors may be introduced.
> assert r.geopos('barcelona', 'place1', 'place2') ==\
[(2.19093829393386841, 41.43379028184083523),
(2.18737632036209106, 41.40634178640635099)]
E assert [(2.190938293...634178640635)] == [(2.1909382939...634178640635)]
E At index 0 diff: (2.1909382939338684, 41.43379028184083) !=
(2.1909382939338684, 41.433790281840835)
E Use -v to get the full diff
tests/test_commands.py:1460: AssertionError
TestRedisCommands.test_georadius_with _
self =
r = Redis>>
@skip_if_server_version_lt('3.2.0')
def test_georadius_with(self, r):
values = (2.1909389952632, 41.433791470673, 'place1') +\
(2.1873744593677, 41.406342043777, 'place2')
r.geoadd('barcelona', *values)
# test a bunch of combinations to test the parse response
# function.
> assert r.georadius('barcelona', 2.191, 41.433, 1, unit='km',
withdist=True, withcoord=True, withhash=True) ==\
[['place1', 0.0881, 3471609698139488,
(2.19093829393386841, 41.43379028184083523)]]
E AssertionError: assert [['place1', 0...79028184083)]] == [['place1',
090281840835)]]
E At index 0 diff: ['place1', 0.0881, 3471609698139488,
(2.1909382939338684, 41.43379028184083)] != ['place1', 0.0881, 3471609698139488,
(2.1909382939338684, 41.433790281840835)]
E Use -v to get the full diff
tests/test_commands.py:1507: AssertionError
_ TestRedisCommands.test_georadius_store_dist __
self =
r = Redis>>
@skip_if_server_version_lt('3.2.0')
def test_georadius_store_dist(self, r):
values = (2.1909389952632, 41.433791470673, 'place1') +\
(2.1873744593677, 41.406342043777, 'place2')
r.geoadd('barcelona', *values)
r.georadius('barcelona', 2.191, 41.433, 1000,
store_dist='places_barcelona')
# instead of save the geo score, the distance is saved.
> assert r.zscore('places_barcelona', 'place1') == 88.05060698409301
E AssertionError: assert 88.05060698268038 == 88.05060698409301
E+ where 88.05060698268038 = >>>('places_barcelona',
'place1')
E+where >>> =
Redis>>.zscore
tests/test_commands.py:1564: AssertionError
TestRedisCommands.test_georadiusmember
self =
r = Redis>>
@skip_if_server_version_lt('3.2.0')
def test_georadiusmember(self, r):
values = (2.1909389952632, 41.433791470673, 'place1') +\
(2.1873744593677, 41.406342043777, 'place2')
r.geoadd('barcelona', *values)
assert r.georadiusbymember('barcelona', 'place1', 4000) ==\
['place2', 'place1']
assert r.georadiusbymember('barcelona', 'place1', 10) == ['place1']
> assert r.georadiusbymember('barcelona', 'place1', 4000,
Bug#896863: Makefile.ompi-rules: don't set silent building
Source: openmpi Version: 3.0.1-8 Severity: normal Tags: patch #896861 would be easier to debug with this information in the buildd log. Description: Makefile.ompi-rules: don't set silent building Author: Adrian Bunk --- openmpi-3.0.1.orig/Makefile.ompi-rules +++ openmpi-3.0.1/Makefile.ompi-rules @@ -53,7 +53,7 @@ endif # A little verbosity magic; "make" will show the terse output. "make # V=1" will show the actual commands used (just like the other # Automake-generated compilation/linker rules). -V=0 +#V=0 OMPI_V_LN_S = $(ompi__v_LN_S_$V) ompi__v_LN_S_ = $(ompi__v_LN_S_$AM_DEFAULT_VERBOSITY)
Bug#896128: glusterfs: CVE-2018-1088 privilege escalation flaw
Hi, On Thu, Apr 19, 2018 at 11:07:13PM +0200, Markus Koschany wrote: > Package: glusterfs > X-Debbugs-CC: t...@security.debian.org > Severity: grave > Tags: security > > Hi, > > The following vulnerability was published for glusterfs. > > CVE-2018-1088[0]: > | A privilege escalation flaw was found in gluster 3.x snapshot > | scheduler. Any gluster client allowed to mount gluster volumes could > | also mount shared gluster storage volume and escalate privileges by > | scheduling malicious cronjob via symlink. > > 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-1088 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1088 > > Please adjust the affected versions in the BTS as needed. When fixing the issue, please see https://bugzilla.redhat.com/show_bug.cgi?id=1570891 . The original patches did make possible that where auth.allow is used, all clients could mount volumes. So this comment just to make sure the complete fix will be applied, updated notes on security-tracker. Regards, Salvatore
Bug#896862: ITP: ruby-ed25519 -- efficient digital signature library providing the Ed25519 algorithm
Package: wnpp Severity: wishlist Owner: Unit 193 * Package name: ruby-ed25519 Version : 1.2.4 Upstream Author : Tony Arcieri * URL : https://github.com/crypto-rb/ed25519 * License : Expat Programming Lang: Ruby Description : efficient digital signature library providing the Ed25519 algorithm A Ruby binding to the Ed25519 elliptic curve public-key signature system described in RFC 8032. . Ed25519 is a modern implementation of a Schnorr signature system using elliptic curve groups. . Ed25519 provides a 128-bit security level, that is to say, all known attacks take at least 2^128 operations, providing the same security level as AES-128, NIST P-256, and RSA-3072. This package will be required for newer versions of ruby-net-ssh.
Bug#877202: pyxdg FTBFS and Debci failure: ERROR: test_validate_icon_theme (test-icon.IconThemeTest)
Package: pyxdg
Followup-For: Bug #877202
User: ubuntu-de...@lists.ubuntu.com
Usertags: bionic ubuntu-patch
Dear maintainers,
A fix for this is available upstream for this build failure in the form of a
new 0.26 release.
If for some reason you are not ready to take the new upstream version of
pyxdg, you can also cherry pick the attached two patches to fix the build
failure, as in the attached debdiff which I have uploaded to Ubuntu to fix
the failure there.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru
pyxdg-0.25/debian/patches/0001-Allow-ScaledDirectories-key-in-icon-theme-file.patch
pyxdg-0.25/debian/patches/0001-Allow-ScaledDirectories-key-in-icon-theme-file.patch
---
pyxdg-0.25/debian/patches/0001-Allow-ScaledDirectories-key-in-icon-theme-file.patch
1969-12-31 16:00:00.0 -0800
+++
pyxdg-0.25/debian/patches/0001-Allow-ScaledDirectories-key-in-icon-theme-file.patch
2018-04-24 22:47:59.0 -0700
@@ -0,0 +1,34 @@
+From 69707442963112f92d72ad39f8fda93d7760e437 Mon Sep 17 00:00:00 2001
+From: Thomas Kluyver
+Date: Fri, 2 Feb 2018 14:27:53 +
+Subject: [PATCH] Allow 'ScaledDirectories' key in icon theme file
+
+---
+ xdg/IconTheme.py | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/xdg/IconTheme.py b/xdg/IconTheme.py
+index e026d4e..bda8b8f 100644
+--- a/xdg/IconTheme.py
b/xdg/IconTheme.py
+@@ -37,6 +37,8 @@ class IconTheme(IniFile):
+ return self.get('Inherits', list=True)
+ def getDirectories(self):
+ return self.get('Directories', list=True)
++def getScaledDirectories(self):
++return self.get('ScaledDirectories', list=True)
+ def getHidden(self):
+ return self.get('Hidden', type="boolean")
+ def getExample(self):
+@@ -143,6 +145,8 @@ class IconTheme(IniFile):
+ self.checkValue(key, value, list=True)
+ elif key == "Directories":
+ self.checkValue(key, value, list=True)
++elif key == "ScaledDirectories":
++self.checkValue(key, value, list=True)
+ elif key == "Hidden":
+ self.checkValue(key, value, type="boolean")
+ elif key == "Example":
+--
+2.17.0
+
diff -Nru
pyxdg-0.25/debian/patches/0001-Allow-Scale-in-icon-theme-per-directory-sections.patch
pyxdg-0.25/debian/patches/0001-Allow-Scale-in-icon-theme-per-directory-sections.patch
---
pyxdg-0.25/debian/patches/0001-Allow-Scale-in-icon-theme-per-directory-sections.patch
1969-12-31 16:00:00.0 -0800
+++
pyxdg-0.25/debian/patches/0001-Allow-Scale-in-icon-theme-per-directory-sections.patch
2018-04-24 22:47:52.0 -0700
@@ -0,0 +1,36 @@
+From 056dbc12ed21abf601609751eee117a06d3d26a7 Mon Sep 17 00:00:00 2001
+From: Thomas Kluyver
+Date: Fri, 2 Feb 2018 14:26:28 +
+Subject: [PATCH] Allow 'Scale' in icon theme per-directory sections
+
+---
+ xdg/IconTheme.py | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/xdg/IconTheme.py b/xdg/IconTheme.py
+index d795484..e026d4e 100644
+--- a/xdg/IconTheme.py
b/xdg/IconTheme.py
+@@ -72,6 +72,10 @@ class IconTheme(IniFile):
+ else:
+ return 2
+
++def getScale(self, directory):
++value = self.get('Scale', type="integer", group=directory)
++return value or 1
++
+ # validation stuff
+ def checkExtras(self):
+ # header
+@@ -168,6 +172,8 @@ class IconTheme(IniFile):
+ self.checkValue(key, value, type="integer")
+ if self.type != "Threshold":
+ self.errors.append("Key 'Threshold' give, but Type is %s"
% self.type)
++elif key == "Scale":
++self.checkValue(key, value, type="integer")
+ elif re.match("^X-[a-zA-Z0-9-]+", key):
+ pass
+ else:
+--
+2.17.0
+
diff -Nru pyxdg-0.25/debian/patches/series pyxdg-0.25/debian/patches/series
--- pyxdg-0.25/debian/patches/series2014-01-27 10:04:35.0 -0800
+++ pyxdg-0.25/debian/patches/series2018-04-24 22:48:32.0 -0700
@@ -3,3 +3,5 @@
gettext-support.patch
prefer-first-glob-for-finding-mimetype.patch
fix-insecure-use-of-tmp.patch
+0001-Allow-Scale-in-icon-theme-per-directory-sections.patch
+0001-Allow-ScaledDirectories-key-in-icon-theme-file.patch
Bug#896861: openmpi: frequent FTBFS linking libmpi_usempi_ignore_tkr.la
Source: openmpi Version: 3.0.1-4 Severity: serious https://buildd.debian.org/status/fetch.php?pkg=openmpi&arch=i386&ver=3.0.1-8&stamp=1524561636&raw=0 https://buildd.debian.org/status/fetch.php?pkg=openmpi&arch=arm64&ver=3.0.1-4&stamp=1523694740&raw=0 https://buildd.debian.org/status/fetch.php?pkg=openmpi&arch=ppc64el&ver=3.0.1-5&stamp=1523910115&raw=0 ... make[3]: Entering directory '/<>/ompi/mpi/fortran/use-mpi-ignore-tkr' FCLD libmpi_usempi_ignore_tkr.la /usr/bin/i686-linux-gnu-ld: cannot find -l-L/usr/lib/gcc/i686-linux-gnu/7 collect2: error: ld returned 1 exit status Makefile:1866: recipe for target 'libmpi_usempi_ignore_tkr.la' failed make[3]: *** [libmpi_usempi_ignore_tkr.la] Error 1
Bug#896831: rapid-photo-downloader: needs a dependency on libmediainfo0v5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 reassign pymediainfo 2.2.0-1 thanks Hello Martin-Eric, thank you for spending your time helping to make Debian better with this bug report. I think that a package only include all own depends. So I assign this bug to pymediainfo. Am Dienstag, den 24.04.2018, 20:46 +0300 schrieb Martin-Éric Racine: > Package: rapid-photo-downloader > Version: 0.9.9-1 > Severity: important > > RPD currently depends on python3-pymediainfo, which itself does NOT > depend upon libmediainfo0v5. As a result, upon startup, RPD complains > that some features won't be available because mediainfo doesn't seem > to be installed. > > Solution: one of python3-pymediainfo or rapid-photo-downloader needs > an explicit dependency on libmediainfo0v5. > > Best Regards, > Martin-Éric CU Jörg - -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst IRC: j_...@freenode.net j_...@oftc.net My wish list: - Please send me a picture from the nature at your home. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlrgE20ACgkQCfifPIyh 0l2EaxAAibXVmkHI1fqBzf+ghtZDDUOX5cDMQh+ivoNlqh2KWKsqvLX4uGZ5ih9p IKdZX7SkfFMCN7n/rksLCEQwjCINzJzte6LdmBFAuNtsXLCPqQk7rmwrFqu+2HqM PW/f73IMt0wpkTn451bDjc7mnyuSSrkaqs4Z2Ih/AycSjq3YJ9bbOYifqHoxbxkX 0FdrZvwWYMM+xjE+7BFGT2lSqowzfHcdBAWEVRnjdE3fqIczbfWhfDn6aTKyp0Mp S6pZCGtsUDbU8Wn+mHqVp9TQuvCbaxlFm4n4EdmyjtnvSpBbotvroXvM9RtD1ZGc fYGqi/CQj1INp7PwrLt5PH4k6kkG+Na+XoRO0Wvg6HY+99cNii4YkMLJTmol0S1r wFLF+XTBkBfFbiUXWaLt9uCt+XwGbMN8XMDIM+9T9ov+5rsuB+51wmpirVDqnhTU yhxSzNUhnP53v+ufLgsiqG8TdnjV7HUGMq4aHa5xRojIekDcLig9BMKFR/8kmghS qlUyEY+ssTHhW12K3J8plqF0JCp75bWttU4qiwCMb+86/AkibdtFfsksRvb2Isj5 wsNG0HZYgXVHTiLAeA5ZtE3iOJ2v0YzqgCDqGBa6byQ9GiD6ZpHK1kZEVqkdXUH4 9UHOpBS70+e2Gn2o795EEJNoo6inMvxQEaHKJbensOZDCPyrMXY= =a2nm -END PGP SIGNATURE-
Bug#896860: lammps FTBFS with TeX Live 2018
Source: lammps Version: 0~20161109.git9806da6-7 Severity: serious Tags: buster sid patch https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/lammps.html ... ! Package inputenc Error: Invalid UTF-8 byte sequence. See the inputenc package documentation for explanation. Type H for immediate help. ... l.479 ...our header the same way. Otherwise, don�t ? Fix is attached. Description: Fix non-ASCII character in developer.tex This caused a FTBFS with TeX Live 2018. Author: Adrian Bunk --- lammps-0~20161109.git9806da6.orig/doc/src/Developer/developer.tex +++ lammps-0~20161109.git9806da6/doc/src/Developer/developer.tex @@ -476,7 +476,7 @@ is the name of the class. This code allo when it parses input script. In addition, your fix header must be included in the file "style\_fix.h". In case if you use LAMMPS make, this file is generated automatically - all files starting with prefix -fix\_ are included, so call your header the same way. Otherwise, donÕt +fix\_ are included, so call your header the same way. Otherwise, don't forget to add your include into "style\_fix.h". Let's write a simple fix which will print average velocity at the end
Bug#896859: ITP: node-fs-jetpack -- high-level file API for Node.js
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: node-fs-jetpack Version : 1.3.0 Upstream Author : Jakub Szwacz * URL : https://github.com/szwacz/fs-jetpack * License : Expat Programming Lang: JavaScript Description : high-level file API for Node.js Node's fs library is very low level and because of that often painful to use. fs-jetpack wants to fix that by giving you completely rethought, much more convenient API to work with file system.
Bug#896858: RM: libnet-whois-ripe-perl/1.23-2
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: rm The package is completely broken in stretch, see #896500 for details.
Bug#895792: gplaycli: dependency androguard switched to Python 3, gplaycli is incompatible with Python 3
Le 25 avril 2018 02:55:49 GMT+02:00, Paul Wise a écrit : >Control: tags -1 + fixed-upstream > >On Mon, 16 Apr 2018 09:40:50 +0200 Matlink wrote: > >> Gplaycli is using python3 upstream (since a while ago), and is no >more >> python2-compatible. > >Marked it as fixed upstream. Which version or commit is this in? > >> I guess we need to repack it as soon as possible. > >Preferably before it gets removed from Debian testing. > >-- >bye, >pabs > >https://wiki.debian.org/PaulWise https://github.com/matlink/gplaycli/commit/139cfbc38ba52d45e84b834c48194c503c96e9d7 Tagged as 3.9 -- Matlink
Bug#896704: RFS: python-picklable-itertools/0.1.1-2 [RC]
On Tuesday, April 24 2018, Fabian Wolff wrote:
> On Mon, Apr 23, 2018 at 08:58:30PM -0400, Sergio Durigan Junior wrote:
>> Hi Fabian,
>>
>> I can help with it, but there are two things I'd like to see first.
>
> Thank you for your review!
My pleasure. Thanks for the work on the package!
>> 1) There are no Vcs-* fields, and it's unclear to me where the git
>> repository for the package is located (I couldn't find it on
>> salsa.d.o).
>
> I did not maintain the package in a public Git repository so far, so I
> created a fresh repository, imported my changes and put it on Salsa:
>
> https://salsa.debian.org/wolff-guest/python-picklable-itertools
>
> I have added Vcs-Git and Vcs-Browser fields accordingly.
Thanks, much appreciated. I can also create a repository under the
Debian namespace on salsa if you want.
Or you can also move the package under the Debian Python Modules Team
umbrella, if it makes more sense. Packaging Python modules with the
DPMT is the preferred way nowadays, but that's really up to you (and
just to be clear, I have no problem if you decide to maintain the
package by yourself).
>> 2) If having the Python 2 version of this package is important for some
>> reason, could you please override the lintian warning
>> ("new-package-should-not-package-python2-module")?
>
> I think that the Python 2 version is not really important; in fact, I
> did not even include it in the original package, but my previous
> sponsor for this package suggested that I should add it (see #841228).
Oh, well. I don't want to go against Gianfranco here :-). I understand
his reasoning, and actually there's a very recent thread developing on
debian-devel about this exact topic; see:
> I have now simply removed the Python 2 package from debian/control; is
> this sufficient, or do I have to do anything more than that?
I think it's best if we keep the package unchanged for now. Sorry about
this extra round-trip, but can you please re-add the Python 2 package?
Actually, I've just noticed that the lintian flag in question
("new-package-should-not-package-python2-module") only applies to the
first upload of the package, and will actually be gone once we upload
this next version, so there's really nothing that needs to be done from
your part about it. I'm sorry about the noise.
Once you reintroduce the Python 2 package, I'll do the upload.
Thanks,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/
signature.asc
Description: PGP signature
Bug#896857: ITP: golang-github-phayes-permbits -- Easy file permissions for golang.
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: golang-github-phayes-permbits Version : 0.0~git20171109.529f712-1 Upstream Author : Patrick D Hayes * URL : https://github.com/phayes/permbits * License : Expat Programming Lang: Go Description : Easy file permissions for golang. Easily get and set file permission bits. This package makes it a breeze to check and modify file permission bits in Linux, Mac, and other Unix systems. Why packaging it? I'm packaging Docker and it's a dependency of the Docker engine.
Bug#896856: ITP: golang-github-ijc-gotty -- Gotty is a library written in Go that provides interpretation and loading of Termcap database files.
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: golang-github-ijc-gotty Version : 0.0~git20170406.a8b993b-1 Upstream Author : Neal van Veen, Ian Campbell * URL : https://github.com/ijc/Gotty * License : BSD-2-clause Programming Lang: Go Description : Go library for working with Termcap database files Gotty is a library written in Go that determines and reads termcap database files to produce an interface for interacting with the capabilities of a terminal. See the godoc documentation or the source code for more information about function usage. Why packaging it? I'm packaging Docker and it's a dependency of the Docker engine.
Bug#896855: ITP: fernet-go -- Generates and verifies HMAC-based authentication tokens
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: fernet-go Version : 0.0~git20151007.1b2437b-1 Upstream Author : Keith Rarick * URL : https://github.com/fernet/fernet-go * License : Expat Programming Lang: Go Description : Generates and verifies HMAC-based authentication tokens Fernet takes a user-provided *message* (an arbitrary sequence of bytes), a *key* (256 bits), and the current time, and produces a *token*, which contains the message in a form that can't be read or altered without the key. Why packaging it? I'm packaging Docker and it's a dependency of the Docker engine.
Bug#896854: ITP: golang-vbom-util -- Go utility packages
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: golang-vbom-util Version : 0.0~git20170409.256737a-1 Upstream Author : Frits van Bommel * URL : https://github.com/fvbommel/util * License : Expat Programming Lang: Go Description : Go utility packages Package util includes various small pieces of code. . cmd/short-regexp . short-regexp is a command-line utility that reads strings from standard input (one per line) and outputs a regexp that matches only those strings. . rope . Package rope implements a "heavy-weight string", which represents very long strings more efficiently (especially when many concatenations are performed). . sortorder . Package sortorder implements sort orders and comparison functions. Why packaging it? I'm packaging Docker, this is a dependency of Docker cli.
Bug#896853: ITP: golang-gopkg-gorethink-gorethink.v3 -- Go language driver for RethinkDB
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: golang-gopkg-gorethink-gorethink.v3 Version : 3.0.5-1 Upstream Author : Daniel Cannon * URL : https://github.com/gorethink/gorethink * License : Apache-2.0 Programming Lang: Go Description : Go language driver for RethinkDB Why packaging it? I'm packaging Docker, this is a dependency of Docker cli.
Bug#896852: ITP: golang-github-ishidawataru-sctp -- SCTP library for the Go programming language
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: golang-github-ishidawataru-sctp Version : 0.0~git20180208.07191f8-1 Upstream Author : Wataru Ishida * URL : https://github.com/ishidawataru/sctp * License : Apache-2.0 Programming Lang: Go Description : SCTP library for the Go programming language Stream Control Transmission Protocol (SCTP) Why packaging it? I'm packaging Docker, this is a dependency of Docker cli.
Bug#896851: [modemmanager] --filter-policy=strict fails to find (some) modems
Package: modemmanager Version: 1.7.990-1 Severity: important --- Please enter the report below this line. --- Dear Maintainer, This version of ModemManager cannot find my USB GSM modem with --filter-policy=strict Up to previous version (1.6.8-2) this problem didn't exist. This can be a serious problem, particularly for new users with no alternative connection, where the user gets stranded and has to work his way out by himself. Symptom: ~# journalctl -f Apr 25 02:24:08 torik ModemManager[569]: Couldn't check support for device '/sys/devices/pci:00/:00:13.2/usb2/2-2': not supported by any plugin According to Modem Manager Reference Manual (/usr/share/gtk-doc/html/ModemManager/ch03s02.html): - "The predefined filter policies are: Default: This policy is the default one when a different one not explicitly selected, **and is equivalent to the way ModemManager has worked in previous releases.**" - Workaround: Edit: /lib/systemd/system/ModemManager.service Change: ExecStart=/usr/sbin/ModemManager --filter-policy=strict To: ExecStart=/usr/sbin/ModemManager --filter-policy=default Additional info: Relevant part of /var/log/messages is attached. --- System information. --- Architecture: Kernel: Linux 4.9.0-4-amd64 Debian Release: buster/sid 500 testing ftp.tr.debian.org 20 unstableftp.tr.debian.org --- Package information. --- Depends (Version) | Installed ==-+-= libc6(>= 2.14) | 2.27-3 libglib2.0-0 (>= 2.36.0) | 2.56.1-2 libgudev-1.0-0(>= 147) | 232-2 libmbim-glib4 (>= 1.12.2) | 1.16.0-1 libmbim-proxy | 1.16.0-1 libmm-glib0 (>= 1.7.990) | 1.7.990-1 libpolkit-gobject-1-0(>= 0.99) | 0.105-20 libqmi-glib5 (>= 1.18.0) | 1.20.0-1 libqmi-proxy | 1.20.0-1 libsystemd0 (>= 209) | 238-4 Recommends (Version) | Installed =-+-=== usb-modeswitch| 2.5.2+repack0-2 Package's Suggests field is empty. -- Abdullah Ramazanoglu /var/log/messages Apr 25 02:22:18 torik kernel: [ 2989.129472] usb 2-1: new high-speed USB device number 6 using ehci-pci Apr 25 02:22:18 torik kernel: [ 2989.279319] usb 2-1: New USB device found, idVendor=19d2, idProduct=2000 Apr 25 02:22:18 torik kernel: [ 2989.279326] usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 Apr 25 02:22:18 torik kernel: [ 2989.279330] usb 2-1: Product: ZTE WCDMA Technologies MSM Apr 25 02:22:18 torik kernel: [ 2989.279334] usb 2-1: Manufacturer: ZTE,Incorporated Apr 25 02:22:18 torik kernel: [ 2989.279337] usb 2-1: SerialNumber: MF1900AVED01 Apr 25 02:22:18 torik kernel: [ 2989.281975] usb-storage 2-1:1.0: USB Mass Storage device detected Apr 25 02:22:18 torik kernel: [ 2989.282373] scsi host6: usb-storage 2-1:1.0 Apr 25 02:22:18 torik mtp-probe: checking bus 2, device 6: "/sys/devices/pci:00/:00:13.2/usb2/2-1" Apr 25 02:22:18 torik mtp-probe: bus: 2, device: 6 was not an MTP device Apr 25 02:22:19 torik usb_modeswitch: switch device 19d2:2000 on 002/006 Apr 25 02:22:20 torik kernel: [ 2990.848701] usb 2-1: USB disconnect, device number 6 Apr 25 02:22:20 torik kernel: [ 2991.217363] usb 2-1: new high-speed USB device number 7 using ehci-pci Apr 25 02:22:20 torik kernel: [ 2991.367441] usb 2-1: New USB device found, idVendor=19d2, idProduct=0031 Apr 25 02:22:20 torik kernel: [ 2991.367448] usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 Apr 25 02:22:20 torik kernel: [ 2991.367453] usb 2-1: Product: ZTE WCDMA Technologies MSM Apr 25 02:22:20 torik kernel: [ 2991.367457] usb 2-1: Manufacturer: ZTE,Incorporated Apr 25 02:22:20 torik kernel: [ 2991.367460] usb 2-1: SerialNumber: MF1900AVED01 Apr 25 02:22:20 torik kernel: [ 2991.371652] option 2-1:1.0: GSM modem (1-port) converter detected Apr 25 02:22:20 torik kernel: [ 2991.371889] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB0 Apr 25 02:22:20 torik kernel: [ 2991.372172] option 2-1:1.1: GSM modem (1-port) converter detected Apr 25 02:22:20 torik kernel: [ 2991.372366] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB1 Apr 25 02:22:20 torik kernel: [ 2991.372580] usb-storage 2-1:1.2: USB Mass Storage device detected Apr 25 02:22:20 torik kernel: [ 2991.372793] scsi host6: usb-storage 2-1:1.2 Apr 25 02:22:20 torik kernel: [ 2991.373224] option 2-1:1.3: GSM modem (1-port) converter detected Apr 25 02:22:20 torik kernel: [ 2991.373483] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB2 Apr 25 02:22:20 torik mtp-probe: checking bus 2, device 7: "/sys/devices/pci:00/:00:13.2/usb2/2-1" Apr 25 02:22:20 torik mtp-probe: bus: 2, device: 7 was not an MTP device Apr 25 02:22:21 torik root: usb_modeswitch: switched to 19d2:0031 on 002/007 Apr 25 02:22:21 torik ker
Bug#855908: marked as done (hiro: FTBFS: test_segment_not_complete_error [...] AssertionError: False is not true)
Control: reopen -1
Control: found -1 0.5-1
Seems that hiro still FTBFS in the reproducible-builds test environment. Ugh
timezones.
* Debian Bug Tracking System [2018-04-24 16:54:03
+]:
> Your message dated Tue, 24 Apr 2018 16:50:40 +
> with message-id
> and subject line Bug#855908: fixed in hiro 0.5-1
> has caused the Debian Bug report #855908,
> regarding hiro: FTBFS: test_segment_not_complete_error [...] AssertionError:
> False is not true
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 855908: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855908
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> Date: Thu, 23 Feb 2017 16:58:54 +0800
> From: Chris Lamb
> To: sub...@bugs.debian.org
> Subject: hiro: FTBFS: test_segment_not_complete_error [...] AssertionError:
> False is not true
> X-Mailer: MessagingEngine.com Webmail Interface - ajax-715c2c0c
> Message-Id:
> <1487840334.3416825.890217456.47fb8...@webmail.messagingengine.com>
>
> Source: hiro
> Version: 0.2-2
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> Dear Maintainer,
>
> hiro fails to build from source in unstable/amd64:
>
> […]
>
> dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:184: cd «BUILDDIR»/.pybuild/pythonX.Y_2.7/build; python2.7
> -m unittest discover -v
> test_accelerate (tests.test_context_mgr.TestScaledContext) ... ok
> test_check_time (tests.test_context_mgr.TestScaledContext) ... ok
> test_deccelerate (tests.test_context_mgr.TestScaledContext) ... ok
> test_utc (tests.test_context_mgr.TestScaledContext) ... ok
> test_decorated (tests.test_context_mgr.TestTimelineContext) ... ok
> test_decorated_with_argument (tests.test_context_mgr.TestTimelineContext)
> ... ok
> test_fluent (tests.test_context_mgr.TestTimelineContext) ... ok
> test_forward (tests.test_context_mgr.TestTimelineContext) ... ok
> test_freeze (tests.test_context_mgr.TestTimelineContext) ... ok
> test_freeze_forward_unfreeze (tests.test_context_mgr.TestTimelineContext)
> ... ok
> test_freeze_target (tests.test_context_mgr.TestTimelineContext) ... ok
> test_rewind (tests.test_context_mgr.TestTimelineContext) ... ok
> test_unfreeze (tests.test_context_mgr.TestTimelineContext) ... ok
> test_scale_up_runner (tests.test_runners.TestASyncRunner) ... ok
> test_scale_up_runner_fail (tests.test_runners.TestASyncRunner) ... ok
> test_segment_not_complete_error (tests.test_runners.TestASyncRunner) ... ok
> test_scale_up_runner (tests.test_runners.TestSyncRunner) ... ok
> test_scale_up_runner_fail (tests.test_runners.TestSyncRunner) ... ok
>
> --
> Ran 18 tests in 8.511s
>
> OK
> I: pybuild base:184: cd «BUILDDIR»/.pybuild/pythonX.Y_3.5/build; python3.5
> -m unittest discover -v
> test_accelerate (tests.test_context_mgr.TestScaledContext) ... ok
> test_check_time (tests.test_context_mgr.TestScaledContext) ... ok
> test_deccelerate (tests.test_context_mgr.TestScaledContext) ... ok
> test_utc (tests.test_context_mgr.TestScaledContext) ...
> «BUILDDIR»/.pybuild/pythonX.Y_3.5/build/tests/test_context_mgr.py:41:
> DeprecationWarning: Please use assertEqual instead.
> math.ceil((start_local - start_utc).seconds / 60.0 / 60.0))
> ok
> test_decorated (tests.test_context_mgr.TestTimelineContext) ...
> «BUILDDIR»/.pybuild/pythonX.Y_3.5/build/hiro/core.py:28: DeprecationWarning:
> inspect.getargspec() is deprecated, use inspect.signature() instead
> if "timeline" in inspect.getargspec(fn).args:
> ok
> test_decorated_with_argument (tests.test_context_mgr.TestTimelineContext)
> ... ok
> test_fluent (tests.test_context_mgr.TestTimelineContext) ... ok
> test_forward (tests.test_context_mgr.TestTimelineContext) ... ok
> test_freeze (tests.test_context_mgr.TestTimelineContext) ... ok
> test_freeze_forward_unfreeze (tests.test_context_mgr.TestTimelineContext)
> ... «BUILDDIR»/.pybuild/pythonX.Y_3.5/build/tests/test_context_mgr.py:145:
> ResourceWarning: unclosed file <_io.TextIOWrapper name=3 encoding='UTF-8'>
> self.assertEquals(int(time.time()), int(os.popen("date
> +%s").read().strip()))
> ok
> test_freeze_target (tests.test_context_mgr.TestTimelineContext) ...
> «BUILDDIR»/.pybuild/pythonX.Y_3.5/build/tests/test_context_mgr.py:91:
> DeprecationWarning: Please use assertAlmostEqual instead.
> self.assertAlmo
Bug#896850: ITP: golang-github-bruth-assert -- Simple test assertions for Golang tests
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: golang-github-bruth-assert Version : release.r60+git20130823.de420fa-1 Upstream Author : Byron Ruth * URL : https://github.com/bruth/assert * License : Expat Programming Lang: Go Description : Simple test assertions for Golang tests Assert Simple test assertions for Go. This is a fork of a fork of a bmizerany/assert (http://github.com/bmizerany/assert) with improved support for things like nil pointers, etc. Why packaging it? I'm packaging Docker, this is a dependency of Docker cli.
Bug#896464: Passing -V as default
On Tuesday, April 24, 2018 07:46:51 PM Lisandro Damián Nicanor Pérez Meyer wrote: > El mar., 24 de abr. de 2018 02:47, Niels Thykier > > escribió: > > Scott Kitterman: > > > On April 23, 2018 10:03:45 PM UTC, "Lisandro Damián Nicanor Pérez Meyer" > > > > wrote: > > >> If I understand correctly and, let's suppose, libQtFoo 5.10.2 is built > > >> with a patched compat 12, then all applications rebuilt against 5.10.2 > > >> would require at very least 5.10.2 even if symbols files allowed it to > > >> depend on a minor version. > > > > As far as I understand it, symbols files overrule shlibs. I.e. if your > > symbols files covers all the symbols required by the application, the > > version will be derived from the symbols file. > > > dpkg-shlibdeps(1) seems to agree with this: > [snip] > > Interesting. That sounds pretty good then. I'll check the next time I > rebuild qt. > > > If that's true, I doubt C++ symbols files are worth the trouble. > > > > > Scott K > > > > I think this case would still work as it used too (e.g. ok for .debs and > > ignored for .udebs - but as I recall, qtbase-abi does not have any udebs > > and should not be concerned by that) > > If everything works as we understand it now then yes, it should just simply > work. Yes, I agree. I appreciate the clarification. Scott K
Bug#893302: lwjgl FTBFS with openjdk-9
On Mon, Apr 23, 2018 at 4:57 PM, Markus Koschany wrote: > lwjgl 2.9.3 is a legacy release from 2015. It is the last version of the > 2.x series and no longer supported. Upstream moved to lwjgl 3. If nobody > can fix this we should consider to remove lwjgl because the new version > 3 would require new Kotlin build dependencies and more. Does anyone know what the plan is for openjdk-8 in buster? If it isn't going to go away, the easiest thing may be to depend on it instead of default-jdk. It look like after many years now, no one has tried to put together a kotlin compiler package, so supporting lwjgl3 seems very unlikely. Best wishes, Mike
Bug#895792: gplaycli: dependency androguard switched to Python 3, gplaycli is incompatible with Python 3
Just FYI, I have a new gplaycli package prepared (and its new gpapi dependency). It is python3 only. However, it requires a newer version of protobuf, so we've been stuck waiting on that. See https://bugs.debian.org/874498 for the status of that. And, of course, the gpapi package will be required to spend some time in NEW. László, I would encourage you to upload the new protobuf to experimental if you can't find any more testers for it; that will likely encourage testing (and I know there are other packages in Debian that also rely on the newer protobuf API). On Wed, 25 Apr 2018 08:55:49 +0800 Paul Wise wrote: > Control: tags -1 + fixed-upstream > > On Mon, 16 Apr 2018 09:40:50 +0200 Matlink wrote: > > > Gplaycli is using python3 upstream (since a while ago), and is no > > more python2-compatible. > > Marked it as fixed upstream. Which version or commit is this in? > > > I guess we need to repack it as soon as possible. > > Preferably before it gets removed from Debian testing. >
Bug#896849: bluez: plugable bluetooth mouse not detected, regression
Package: bluez Version: 5.49-1 Severity: normal Dear Maintainer, What is surprising is that this mouse works great when I boot into Ubuntu Artful. On Artful, I have bluez 5.46-0ubuntu3. hciconfig shows: hci0: Type: Primary Bus: USB BD Address: BC:A8:A6:86:BD:C4 ACL MTU: 1021:4 SCO MTU: 96:6 UP RUNNING PSCAN ISCAN RX bytes:3699 acl:79 sco:0 events:149 errors:0 TX bytes:5782 acl:13 sco:0 commands:112 errors:0 And the mouse is detected and pairs, joshua@pop-os:~$ bluetoothctl [NEW] Controller BC:A8:A6:86:BD:C4 pop-os [default] [NEW] Device 0C:FC:CA:00:07:60 Plugable BT-MOUSE3 Agent registered [Plugable BT-MOUSE3]# info Device 0C:FC:CA:00:07:60 Name: Plugable BT-MOUSE3 Alias: Plugable BT-MOUSE3 Class: 0x002580 Icon: input-mouse Paired: yes Trusted: yes Blocked: no Connected: yes LegacyPairing: no UUID: Human Interface Device... (1124--1000-8000-00805f9b34fb) UUID: PnP Information (1200--1000-8000-00805f9b34fb) Modalias: usb:vpd On Debian, the mouse is not detected. Any idea what I can try to troubleshoot? -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages bluez depends on: ii dbus 1.10.26-0+deb9u1 ii kmod 23-2 ii libasound21.1.3-5 ii libc6 2.27-3 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdw10.168-1 ii libglib2.0-0 2.56.0-4 ii libreadline7 7.0-3 ii libudev1 237-3~bpo9+1 ii lsb-base 9.20161125 ii udev 237-3~bpo9+1 bluez recommends no packages. Versions of packages bluez suggests: ii pulseaudio-module-bluetooth 10.0-1+deb9u1 -- no debconf information
Bug#895792: gplaycli: dependency androguard switched to Python 3, gplaycli is incompatible with Python 3
Control: tags -1 + fixed-upstream On Mon, 16 Apr 2018 09:40:50 +0200 Matlink wrote: > Gplaycli is using python3 upstream (since a while ago), and is no more > python2-compatible. Marked it as fixed upstream. Which version or commit is this in? > I guess we need to repack it as soon as possible. Preferably before it gets removed from Debian testing. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#896847: libsynctex2: texworks/texmaker both segfaulting with libsynctex1/libsynctex2 installed
> Package: libsynctex2 > Version: 2018.20180416.47457-2 > Severity: normal > > Dear Maintainer, > > TeXworks segaults with a core dump. Texmaker outputs undefined symbols and > segfaults. Happened right after the latest TeXLive restructure. Are you sure that you don't talk about libsynctex***1*** here? The first version that went into unstable shipped the synctex library as libsynctex1, which was bad since upstream broke the API without soname bump. I have re-uploaded with bumped soname so now we have libsynctex2. texworks is still linked against libsynctex1, texmaker the same. Please install libsynctex***1*** from ***testing*** and all this will be fixed. Make sure by setting it to hold that it is not updated. I have already filed a request for removal for libsynctex1 from unstable. Thanks Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#896848: csound: segfault on start
Package: csound Version: 1:6.10.0~dfsg-1 Severity: normal Dear Maintainer, * What led up to the situation? Installing Csound and Sugar. * What exactly did you do (or not do) that was effective (or ineffective)? Download and run Sugar activity Music Keyboard. * What was the outcome of this action? Segmentation fault. * What outcome did you expect instead? No segmentation fault. Upstream patch df5658c solves this problem, see also upstream issue 948. -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages csound depends on: ii libc62.24-11+deb9u3 ii libcsound64-6.0 1:6.10.0~dfsg-1 ii libgcc1 1:6.3.0-18+deb9u1 ii libstdc++6 6.3.0-18+deb9u1 Versions of packages csound recommends: ii csound-utils 1:6.10.0~dfsg-1 csound suggests no packages. -- no debconf information
Bug#896500: libnet-whois-ripe-perl: Can't use 'defined(@array)'
Control: retitle -1 RM: libnet-whois-ripe-perl -- ROM; broken and obsolete Control: reassign -1 ftp.debian.org On Apr 21, Niko Tyni wrote: > This has been fatal since Perl 5.22, so stretch is affected too. Thank you. So this shows that nobody uses this package anymore and it can be safely removed from unstable (and stable too, if appropriate). -- ciao, Marco signature.asc Description: PGP signature
Bug#887494: mozjs52: FTBFS on sparc64: interpreter segfaults
On 04/25/2018 12:37 AM, James Clarke wrote:
>> -#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) ||
>> defined(__aarch64__)
>> +#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) &&
>> (defined(__NetBSD__) || defined(__linux__)))
>
> I don't think you meant to drop the __aarch64__ here (the real commit
> upstream keeps it).
>
>> -#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) ||
>> defined(__aarch64__)
>> +#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) &&
>> (defined(__NetBSD__) || defined(__linux__)))
>
> Ditto.
Blergh. Attaching an updated version. Thanks for spotting this.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Description: Add support for sparc64
Author: John Paul Adrian Glaubitz
Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1275204
Last-Update: 2017-06-18
Index: firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
===
--- firefox-esr-52.2.0esr.orig/js/src/gc/Memory.cpp
+++ firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
@@ -501,7 +501,7 @@ static inline void*
MapMemoryAt(void* desired, size_t length, int prot = PROT_READ | PROT_WRITE,
int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 0)
{
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__)
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && (defined(__NetBSD__) || defined(__linux__))) || defined(__aarch64__)
MOZ_ASSERT((0x8000ULL & (uintptr_t(desired) + length - 1)) == 0);
#endif
void* region = mmap(desired, length, prot, flags, fd, offset);
@@ -524,7 +524,7 @@ static inline void*
MapMemory(size_t length, int prot = PROT_READ | PROT_WRITE,
int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 0)
{
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && defined(__NetBSD__))
/*
* The JS engine assumes that all allocated pointers have their high 17 bits clear,
* which ia64's mmap doesn't support directly. However, we can emulate it by passing
@@ -551,7 +551,7 @@ MapMemory(size_t length, int prot = PROT
return nullptr;
}
return region;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || (defined(__sparc__) && defined(__arch64__) && defined(__linux__))
/*
* There might be similar virtual address issue on arm64 which depends on
* hardware and kernel configurations. But the work around is slightly
Index: firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
===
--- firefox-esr-52.2.0esr.orig/js/src/jsapi-tests/testGCAllocator.cpp
+++ firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
@@ -312,7 +312,7 @@ void unmapPages(void* p, size_t size) {
void*
mapMemoryAt(void* desired, size_t length)
{
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__)
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && (defined(__NetBSD__) || defined(__linux__))) || defined(__aarch64__)
MOZ_RELEASE_ASSERT(0x8000ULL & (uintptr_t(desired) + length - 1) == 0);
#endif
void* region = mmap(desired, length, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
@@ -334,7 +334,7 @@ mapMemory(size_t length)
int fd = -1;
off_t offset = 0;
// The test code must be aligned with the implementation in gc/Memory.cpp.
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && defined(__NetBSD__))
void* region = mmap((void*)0x0700, length, prot, flags, fd, offset);
if (region == MAP_FAILED)
return nullptr;
@@ -344,7 +344,7 @@ mapMemory(size_t length)
return nullptr;
}
return region;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || (defined(__sparc__) && defined(__arch64__) && defined(__linux__))
const uintptr_t start = UINT64_C(0x0700);
const uintptr_t end = UINT64_C(0x8000);
const uintptr_t step = js::gc::ChunkSize;
Index: firefox-esr-52.2.0esr/memory/jemalloc/src/include/jemalloc/internal/mb.h
===
--- firefox-esr-52.2.0esr.orig/memory/jemalloc/src/include/jemalloc/internal/mb.h
+++ firefox-esr-52.2.0esr/memory/jemalloc/src/include/jemalloc/internal/mb.h
@@ -76,7 +76,7 @@ mb_write(void)
: "memory" /* Clobbers. */
);
}
-#elif defined(__sparc64__)
+#elif defined(__sparc__) && defined(__arch64__)
JEMALLOC_INLINE void
mb_write(void)
{
Index: firefox
Bug#895868: munin-cron: Fontconfig error: failed reading config file
The error appears to be coming from fontconfig as other programs are giving this error. In the folder /etc/fonts/conf.d there are symbolic links to directories in /etc/fonts/conf.avail which is causing fontconfig to throw an error for each directory. Removing these directory symbolic links solve the problem for me.
Bug#896846: ITP: node-compressjs -- fast pure-JavaScript compression/decompression algorithms
2018-04-25 0:32 GMT+02:00 Daniel Kahn Gillmor : > Package: wnpp > Severity: wishlist > Owner: Daniel Kahn Gillmor > > * Package name: node-compressjs > Version : 1.0.3 > Upstream Author : C. Scott Ananian > * URL : https://github.com/cscott/compressjs > * License : GPL > Programming Lang: Javascript > Description : fast pure-JavaScript compression/decompression > algorithms > > > Fast, pure-JavaScript implementations of various compression and > decompression algorithms, including: > > * bzip2 > * LZP3 > * a modified LZJB, and > * PPM-D > > --- > > this is needed for recent versions of OpenPGP.js, which i'm struggling > to package. > > This software is not actively maintained, and not so much used. However, it seems there isn't any better replacement for bzip2-on-browsers. Jérémy
Bug#896847: libsynctex2: texworks/texmaker both segfaulting with libsynctex1/libsynctex2 installed
Package: libsynctex2 Version: 2018.20180416.47457-2 Severity: normal Dear Maintainer, TeXworks segaults with a core dump. Texmaker outputs undefined symbols and segfaults. Happened right after the latest TeXLive restructure. - Marc Driftmeyer -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libsynctex2 depends on: ii libc6 2.27-3 ii zlib1g 1:1.2.8.dfsg-5 libsynctex2 recommends no packages. libsynctex2 suggests no packages. -- no debconf information
Bug#887494: mozjs52: FTBFS on sparc64: interpreter segfaults
On Tue, Apr 24, 2018 at 08:52:58PM +0200, John Paul Adrian Glaubitz wrote:
> On 01/17/2018 01:43 PM, John Paul Adrian Glaubitz wrote:
> > I can whip up a patch for mozjs52 to add sparc64 support if there is
> > a realistic chance for it to be merged. My m68k [3] and sh4 [4] patches for
> > mozjs52 are still without any reply, for example.
>
> Attaching said patch. I hope to get around sending a pull request on Salsa
> the next days.
>
> The patches should be applied in this order:
>
> - sh4-support.patch (#880692)
> - m68k-support.patch (#880693)
> - sparc64-support.patch (this bug report)
>
> I'll also send a clean one for alpha and ia64 (#887496).
>
> Adrian
>
> --
> .''`. John Paul Adrian Glaubitz
> : :' : Debian Developer - glaub...@debian.org
> `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
> `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
> Description: Add support for sparc64
> Author: John Paul Adrian Glaubitz
> Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1275204
> Last-Update: 2017-06-18
>
> Index: firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
> ===
> --- firefox-esr-52.2.0esr.orig/js/src/gc/Memory.cpp
> +++ firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
> @@ -501,7 +501,7 @@ static inline void*
> MapMemoryAt(void* desired, size_t length, int prot = PROT_READ | PROT_WRITE,
> int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset =
> 0)
> {
> -#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) ||
> defined(__aarch64__)
> +#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) &&
> (defined(__NetBSD__) || defined(__linux__)))
I don't think you meant to drop the __aarch64__ here (the real commit
upstream keeps it).
> MOZ_ASSERT((0x8000ULL & (uintptr_t(desired) + length - 1))
> == 0);
> #endif
> [...]
> Index: firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
> ===
> --- firefox-esr-52.2.0esr.orig/js/src/jsapi-tests/testGCAllocator.cpp
> +++ firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
> @@ -312,7 +312,7 @@ void unmapPages(void* p, size_t size) {
> void*
> mapMemoryAt(void* desired, size_t length)
> {
> -#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) ||
> defined(__aarch64__)
> +#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) &&
> (defined(__NetBSD__) || defined(__linux__)))
Ditto.
> MOZ_RELEASE_ASSERT(0x8000ULL & (uintptr_t(desired) + length
> - 1) == 0);
> #endif
> [...]
James
Bug#896846: ITP: node-compressjs -- fast pure-JavaScript compression/decompression algorithms
Package: wnpp Severity: wishlist Owner: Daniel Kahn Gillmor * Package name: node-compressjs Version : 1.0.3 Upstream Author : C. Scott Ananian * URL : https://github.com/cscott/compressjs * License : GPL Programming Lang: Javascript Description : fast pure-JavaScript compression/decompression algorithms Fast, pure-JavaScript implementations of various compression and decompression algorithms, including: * bzip2 * LZP3 * a modified LZJB, and * PPM-D --- this is needed for recent versions of OpenPGP.js, which i'm struggling to package. --dkg
Bug#896817: /usr/lib/gdm3/gdm-wayland-session: bash: ligne 0 : exec: -l : option non valable
Le 2018-04-24 19:33, Simon McVittie a écrit : Since very recently, when I try to log in with default choice, it does not work. (Retitled to something a little less generic.) Please try editing /usr/bin/gnome-session (it's a shell script) and making it log what it's doing: #!/bin/sh echo "SHELL: $SHELL" >&2 echo "XDG_SESSION_CLASS: $XDG_SESSION_CLASS" >&2 echo "XDG_SESSION_TYPE: $XDG_SESSION_TYPE" >&2 echo "\$0: $0" >&2 echo "bash: $(command -v bash)" >&2 echo "BASH_VERSION: $(bash -c 'echo $BASH_VERSION')" >&2 for arg in "$@"; do echo "\$@: $arg" >&2 done echo "end of \$@" ... continue with what the script does now ... Then try logging in again, in the same way. You should get more information logged. I cannot reproduce the bug any more. I'm not sure what "the default choice" was when I made my initial report. But I could proceed by selection "GNOME on Xorg". Here is what appears in /var/log/user.log when I select "GNOME": Apr 25 00:05:22 korell /usr/lib/gdm3/gdm-wayland-session[4753]: SHELL: /bin/zsh Apr 25 00:05:22 korell /usr/lib/gdm3/gdm-wayland-session[4753]: XDG_SESSION_CLASS: Apr 25 00:05:22 korell /usr/lib/gdm3/gdm-wayland-session[4753]: XDG_SESSION_TYPE: wayland Apr 25 00:05:22 korell /usr/lib/gdm3/gdm-wayland-session[4753]: $0: /usr/bin/gnome-session Apr 25 00:05:22 korell /usr/lib/gdm3/gdm-wayland-session[4753]: bash: /usr/bin/bash Apr 25 00:05:22 korell /usr/lib/gdm3/gdm-wayland-session[4753]: BASH_VERSION: 4.4.19(1)-release Apr 25 00:05:22 korell /usr/lib/gdm3/gdm-wayland-session[4753]: end of $@ Apr 25 00:05:22 korell /usr/lib/gdm3/gdm-wayland-session[4753]: SHELL: /bin/zsh Apr 25 00:05:22 korell /usr/lib/gdm3/gdm-wayland-session[4753]: XDG_SESSION_CLASS: Apr 25 00:05:22 korell /usr/lib/gdm3/gdm-wayland-session[4753]: XDG_SESSION_TYPE: wayland Apr 25 00:05:22 korell /usr/lib/gdm3/gdm-wayland-session[4753]: $0: /usr/bin/gnome-session Apr 25 00:05:22 korell /usr/lib/gdm3/gdm-wayland-session[4753]: bash: /usr/bin/bash Apr 25 00:05:22 korell /usr/lib/gdm3/gdm-wayland-session[4753]: BASH_VERSION: 4.4.19(1)-release Apr 25 00:05:22 korell /usr/lib/gdm3/gdm-wayland-session[4753]: $@: -l Apr 25 00:05:22 korell /usr/lib/gdm3/gdm-wayland-session[4753]: end of $@ Cheers, -- Stéphane
Bug#896845: bluetoothd crashes when turning on discoverable
Package: bluez Version: 5.49-1 Severity: important Tags: upstream Hello, bluetoothd crashes when turning on discoverable with some Bluetooth adapters. 5.47-1 works fine. # bluetoothctl discoverable on causes: Program received signal SIGSEGV, Segmentation fault. btd_adv_manager_refresh (manager=0x0) at src/advertising.c:1176 1176src/advertising.c: Toks failas ar aplankas neegzistuoja. (gdb) bt #0 btd_adv_manager_refresh (manager=0x0) at src/advertising.c:1176 #1 0x55bc1d76f702 in settings_changed (settings=, adapter=0x55bc1f0a5120) at src/adapter.c:543 #2 new_settings_callback (index=, length=, param=, user_data=0x55bc1f0a5120) at src/adapter.c:573 #3 0x55bc1d79efc8 in request_complete (mgmt=mgmt@entry=0x55bc1f09d3e0, status=, opcode=opcode@entry=6, index=index@entry=0, length=length@entry=4, param=0x55bc1f09d469) at src/shared/mgmt.c:261 #4 0x55bc1d79faed in can_read_data (io=, user_data=0x55bc1f09d3e0) at src/shared/mgmt.c:353 #5 0x55bc1d7ac203 in watch_callback (channel=, cond=, user_data=) at src/shared/io-glib.c:170 #6 0x7f9950d1e0f5 in g_main_context_dispatch () from target:/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #7 0x7f9950d1e4c0 in ?? () from target:/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #8 0x7f9950d1e7d2 in g_main_loop_run () from target:/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x55bc1d70f93b in main (argc=, argv=) at src/main.c:770 (gdb) Upstream seems to have fixes for that though but I have not tested them. It would nice to have them backported since this is a pretty significant regression. https://git.kernel.org/pub/scm/bluetooth/bluez.git/log/?qt=grep&q=btd_adv_manager_refresh -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (110, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages bluez depends on: ii dbus 1.12.6-2 ii kmod 25-1 ii libasound21.1.3-5 ii libc6 2.27-3 ii libdbus-1-3 1.12.6-2 ii libdw10.170-0.4 ii libglib2.0-0 2.56.1-2 ii libreadline7 7.0-3 ii libudev1 238-4 ii lsb-base 9.20170808 ii udev 238-4 bluez recommends no packages. Versions of packages bluez suggests: ii pulseaudio-module-bluetooth 11.1-5 -- no debconf information
Bug#662960: ssmtp doesn't validate server TLS certificates
Package: ssmtp Version: 2.64-8+b2 Followup-For: Bug #662960 Dear Maintainer, I'm changing the severity of this bug to 'serious'. I apologize if this is presumptuous, but it seems to me that software that advertises TLS functionality but neglects to check the supplied certificates is seriously flawed. At the very least, the documentation should contain a Big Fat Warning that the TLS functionality is limited to encryption and does not include authentication of the server. -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.95-lila (SMP w/4 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) Versions of packages ssmtp depends on: ii debconf [debconf-2.0] 1.5.61 ii libc6 2.24-11+deb9u3 ii libgnutls-openssl273.5.8-5+deb9u3 ssmtp recommends no packages. ssmtp suggests no packages. -- Configuration Files: /etc/logcheck/ignore.d.server/ssmtp [Errno 13] Permission denied: '/etc/logcheck/ignore.d.server/ssmtp' /etc/ssmtp/revaliases changed [not included] -- debconf information: ssmtp/overwriteconfig: true ssmtp/port: 25 ssmtp/root: postmaster ssmtp/mailname: ssmtp/mailhub: mail ssmtp/fromoverride: false ssmtp/hostname: ssmtp/rewritedomain:
Bug#896818: libnma over GI not working
Il 24/04/2018 23:07, Michael Biebl ha scritto: > > Thanks for the bug report. > Seems we don't have any package in stretch yet, which uses > gir1.2-nma-1.0, which is probably why this issue has went unnoticed. > > But that also means, it's probably not that important to fix this via a > stable upload. Or put this differently: Why do you want to have this > fixed in stretch, is there any software you use in stretch that requires > gir1.2-nma-1.0? > > Regards, > Michael > > Thanks for reply, probably I not able to explain good in english, latest Clem comment here probably can: https://github.com/linuxmint/Cinnamon/pull/7486 In this explain how to reproduce: https://gist.github.com/clefebvre/411ab17558fc4dc438085ce2b6cc9093 But also description of patch from upstream that fixed it I think explain good: > libnma/pygobject: libnma/NMA must use libnm/NM instead of legacy libraries > libnma uses libnm, and not libnm-util/libnm-glib. Hence, the python > bindings must load "NM" and not "NMClient"/"NetworkManager". > *As it was, the generated bindings for libnma were unusable and > loading them would fail with* > libnm-ERROR **: libnm-util symbols detected; Mixing libnm with > libnm-util/libnm-glib is not supported I personally think that only the fact the libnma binding is broken and anyone want use it in Stretch can have this issue is sufficient reason for fix it.
Bug#849094: liblept5: Broken on s390x (+ other big endian archs)
Given the date, it sounds like we have an emergency situation. I'm really stuck here. My only known access to a big endian is an emulator with Wheezy. http://create.stephan-brumme.com/big-endian/ That's good enough for checking suspicious parts of Leptonica. I tried and found nothing. But it is not good enough to check Tesseract 4.0. Your OCRMyPdf s390 test provides strong evidence that Tesseract is broken on big endian. http://autopkgtest.ubuntu.com/packages/o/ocrmypdf/bionic/s390x However, if I wipe out that package on big-endian, it will cause a cascading dependency failure affecting hundreds of other packages. Not great to do 36 hours before release. Recommend we talk in real time. Will send you contact details by private email.
Bug#896843: FTBFS: incorrect CPPFLAG for powerpc*
On Tue, Apr 24, 2018 at 03:24:11PM -0500, Barry Arndt wrote: > Source: ctsim > Version: 6.0.2 > Severity: serious > Tags: l10n patch > Justification: fails to build from source (but built successfully in the past) > > Dear Maintainer, > > FTBFS of ctsim-6.0.2 on ppc64el reported from unicamp. > > The build log reported: > g++: error: unrecognized command line option '-faltivec'; did you mean > '-maltivec' > > The correct flag for ppc64el (as well as powerpc*) is -maltivec. > > I changed -faltivec in configure.ac to -maltivec as follows: > > --- ctsim-6.0.2.orig/configure.ac > +++ ctsim-6.0.2/configure.ac > @@ -137,7 +137,7 @@ case $target_cpu in > CXXFLAGS="$CXXFLAGS $CPUEXT_FLAGS $SIMD_FLAGS" > ;; > powerpc*) > -ARCH_OPTION="-fno-common -faltivec";; > +ARCH_OPTION="-fno-common -maltivec";; > armv1*|armv2*|armv3*|armv4*|armv5*|armv6*) > ARCH_OPTION="-ffast-math";; > armv7*|armv8*) > > I then ran autoconf. After that, the package build properly. This whole compiler options block should be nuked, it also creates baseline violations on amd64 and i386. > This fix should also fix the FTBFS of ctsim on > powerpc, powerpcspe, and ppc64. None of these have AltiVec in the port baseline, so that mustn't be done there. (And ppc64el has it enabled by default, so no benefits from adding -maltivec there.) cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#896827: perl: FTBFS on riscv64: t/re/fold_grind timeout
Hi Niko,
2018-04-24 18:55 GMT+02:00 Niko Tyni :
> Package: perl
> Version: 5.26.2-2
> X-Debbugs-Cc: debian-ri...@lists.debian.org
>
> This package failed to build on riscv64.
>
> t/re/fold_grind # Test
> process timed out - terminating
> FAILED--no leader found
>
> [...]
>
> Failed 1 test out of 2457, 99.96% okay.
> re/fold_grind.t
>
> [...]
>
> Build needed 05:11:45, 350184k disk space
Thanks for taking care :)
> It looks to me like the buildd host is just too slow for this test.
> >From the test:
>
> my $time_out_factor = $ENV{PERL_TEST_TIME_OUT_FACTOR} || 1;
> $time_out_factor = 1 if $time_out_factor < 1;
>
> watchdog(5 * 60 * $time_out_factor);
>
> so the default timeout is five minutes but can be multiplied with
> PERL_TEST_TIME_OUT_FACTOR in the environment.
>
> AFAICS the build time of five hours is well above all the other
> architectures, even m68k and sh4, and it's still less than half of
> a successful build (we have to build perl three times with different
> options, and run the test suite for two of those builds.)
At the moment, these builds are using qemu-system emulation (not even
qemu-user, as --some, or all?-- of the m68k/sh4 buildds). And a new
implementation at that, not very streamlined or tuned for performance.
So yes, they are slower than any other arch at the moment.
It could also happen that the test is stuck due to bugs in qemu, the
toolchain, etc, we already found similar problems in other packages.
> @debian-riscv: I guess I can set PERL_TEST_TIME_OUT_FACTOR=2 for riscv64
> in debian/rules or something like that, do you think that's sensible or
> are the current riscv64 buildds going to get faster any time soon?
We hope to get (donations of) proper hardware at some point, but at
the moment there's only a very limited run of hardware in the world,
and the only one that I got so far is being used for testing and not
for building (not as part of the buildd network, at any rate).
The timeline for getting more hardware is unknown, but I cannot see us
getting faster buildds at least until July, even in the best scenario,
so it's better if you increase the time out factor by two, if not
more.
I'm just firing up a build in the board to see if it passes the tests,
I will report when it finishes, if everything goes all right.
--
Manuel A. Fernandez Montecelo
Bug#896818: [Pkg-utopia-maintainers] Bug#896818: libnma over GI not working
Am 24.04.2018 um 16:32 schrieb Fabio Fantoni: > Package: network-manager-applet > Version: 1.4.4-1 > Severity: important > Tags: stretch > > Trying to use libnma over GI from a python script is not working at all and > can also cause crash of other software using it. > This patch solved it: > https://git.gnome.org/browse/network-manager-applet/commit/?id=7a59d41e5fd0da51f1f7aae7518befdb1182 > I reported this because is a important bug using libnma and can be fixed with > a small patch, in case there was any possibility of a new build > (1.4.4-1+deb9u1). Thanks for the bug report. Seems we don't have any package in stretch yet, which uses gir1.2-nma-1.0, which is probably why this issue has went unnoticed. But that also means, it's probably not that important to fix this via a stable upload. Or put this differently: Why do you want to have this fixed in stretch, is there any software you use in stretch that requires gir1.2-nma-1.0? Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#896407: python-stfio: stfio fails to import
This fixes it: https://github.com/neurodroid/stimfit/commit/7edbf088
Thanks to Yaroslav for the pointer. Will release 0.15.6 including the bug
fix soon.
On Tue, Apr 24, 2018 at 9:29, Christoph Schmidt-Hieber
wrote:
Thanks for the bug report.
Looks like dh-python2 renames some shared library files. The relevant
output when running debuild is copied in below.
Does anyone know how to stop dh_python2 from renaming shared library files?
D: dh_python2 fs:47: moving files from
debian/python-stfio/usr/lib/python2.7/site-packages to
debian/python-stfio/usr/lib/python2.7/dist-packages/ D: dh_python2
tools:217: invoking: python2.7 -c 'import sysconfig as
s;print("__SEP__".join(i or "" for i in s.get_config_vars("SOABI",
"MULTIARCH", "INCLUDEPY", "LIBPL", "LDLIBRARY")))' I: dh_python2 fs:91:
renaming
debian/python-stfio/usr/lib/python2.7/site-packages/stfio/_stfio.so to
debian/python-stfio/usr/lib/python2.7/site-packages/stfio/_stfio.x86_64-linux-gnu.so
I: dh_python2 fs:91: renaming
debian/python-stfio/usr/lib/python2.7/site-packages/stfio/libstfio.so to
debian/python-stfio/usr/lib/python2.7/site-packages/stfio/libstfio.x86_64-linux-gnu.so
I: dh_python2 fs:91: renaming
debian/python-stfio/usr/lib/python2.7/site-packages/stfio/libstfnum.so to
debian/python-stfio/usr/lib/python2.7/site-packages/stfio/libstfnum.x86_64-linux-gnu.so
I: dh_python2 fs:91: renaming
debian/python-stfio/usr/lib/python2.7/site-packages/stfio/libbiosiglite.so
to
debian/python-stfio/usr/lib/python2.7/site-packages/stfio/libbiosiglite.x86_64-linux-gnu.so
W: dh_python2 dh_python2:67: public extension linked with libpython2.7:
_stfio.x86_64-linux-gnu.so
On Fri, Apr 20, 2018 at 22:01, Helmut Grohne wrote:
Package: python-stfio
Version: 0.15.5-1
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python-stfio importing the module stfio
into a python interpreter fails with the following error:
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/dist-packages/stfio/__init__.py", line 6, in
from .stfio import *
File "/usr/lib/python2.7/dist-packages/stfio/stfio.py", line 23, in
_stfio = swig_import_helper()
File "/usr/lib/python2.7/dist-packages/stfio/stfio.py", line 22, in
swig_import_helper
return importlib.import_module('_stfio')
File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
ImportError: No module named _stfio
The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via
${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by
incomplete
install_requires in setup.py. Sometimes a missing dependency of a
dependency
is the cause, in such cases this bug should be reassigned.
Helmut
Bug#883333: Mnemosyne fails to start (invalid node channel message)
I also had this problem. (Moreover mnemosyne ends with segmentation fault) But after installing python3-opengl mnemosyne start to work. So it would be worth to check dependencies. KJ -- http://wolnelektury.pl/wesprzyj/teraz/ Jesus is my POSTMASTER GENERAL ...
Bug#896844: auctex: Preview latex doesn't work - fixed upstream.
Package: auctex Version: 11.91-1 Severity: important Dear Maintainer, The 11.91 version of auctex cannot generate previews with ghostscript 9.22. However, it seems that the 11.92 version has fixed this problem. See https://bugs.ghostscript.com/show_bug.cgi?id=698680 See https://tex.stackexchange.com/questions/397147/can-not-generate-preview-by-auctex Would it be possible to update auctex to version 11.92? -BenRI -- Package-specific info: Content of '/usr/share/emacs/site-lisp/auctex' e2418263a7bd30d35d13116faef63f95 /usr/share/emacs/site-lisp/auctex/bib-cite.el 5ac2595246062777c61ed4104a93cf61 /usr/share/emacs/site-lisp/auctex/context-en.el 0a6bd12930a5771f6b89fcf16d479b08 /usr/share/emacs/site-lisp/auctex/context-nl.el 87b6a5b269a26c1a0f522ba3c4ec222e /usr/share/emacs/site-lisp/auctex/context.el d6f4d66582bbdd12eb0a295f87418b69 /usr/share/emacs/site-lisp/auctex/font-latex.el f176261b5a5511cbe1401ee72ffb8947 /usr/share/emacs/site-lisp/auctex/images/amstex.xpm d33121019448617a3ad3bcafdeb8db40 /usr/share/emacs/site-lisp/auctex/images/bibtex.xpm 1a43d6438010bceb374ab0a5f2bd05a8 /usr/share/emacs/site-lisp/auctex/images/dropdown.xpm 41f1ae0341ae2e307d92a7b8b815f868 /usr/share/emacs/site-lisp/auctex/images/dvipdf.xpm 2e4b8669b0168f32247411be3f999437 /usr/share/emacs/site-lisp/auctex/images/dvips.xpm 55f7600cadc3a209e94bacf6bbc42a7c /usr/share/emacs/site-lisp/auctex/images/error.xpm c29ad797273fd27201a40bd939a95fe0 /usr/share/emacs/site-lisp/auctex/images/exec.xpm 79b958849511c67d6b13ef9f5b3673e8 /usr/share/emacs/site-lisp/auctex/images/execbibtex.xpm a8570e26e9f96b6f527cdbe218d6c55f /usr/share/emacs/site-lisp/auctex/images/execdvips.xpm e647bc601aef2dc71b134a989df1adff /usr/share/emacs/site-lisp/auctex/images/execerror.xpm 4610ec6133f89ceb441c43dfee077361 /usr/share/emacs/site-lisp/auctex/images/execpdftex.xpm c9cd1fc9fe4fd122cbf900fae654a67b /usr/share/emacs/site-lisp/auctex/images/exectex.xpm 6a6b9af945d4735f048ea8e475f8d9b8 /usr/share/emacs/site-lisp/auctex/images/execviewdvi.xpm 466466f6d1867510b058a9c184ffce5d /usr/share/emacs/site-lisp/auctex/images/execviewpdf.xpm 39d8ccaffb40b0c118e000f45272db05 /usr/share/emacs/site-lisp/auctex/images/execviewps.xpm 6767e2583c668dcb47495197b9e8cb65 /usr/share/emacs/site-lisp/auctex/images/gv.xpm ff9c61ef5148a0cacd5422d7c0d99396 /usr/share/emacs/site-lisp/auctex/images/jumpdvi.xpm ece6608586b591f50f20d17cdb316a1c /usr/share/emacs/site-lisp/auctex/images/ltx-symb-turn-off.xpm b1f10de33dcf1b5ca9ac6155c13683a3 /usr/share/emacs/site-lisp/auctex/images/ltx-symb-turn-on.xpm 44e35faa18ab34f3c13ac3b0082bcc47 /usr/share/emacs/site-lisp/auctex/images/pdftex.xpm 84673eb20ac3be7bf0eb4e84e23e828f /usr/share/emacs/site-lisp/auctex/images/prverr16.xpm 59e6a0dddb00ab16c4209a2e4c6e283d /usr/share/emacs/site-lisp/auctex/images/prverr20.xpm 225929f8131bdd7b9b8207494a59619a /usr/share/emacs/site-lisp/auctex/images/prverr24.xpm 0dac3d8eb00c902037cc5fa6a03e53e3 /usr/share/emacs/site-lisp/auctex/images/prvtex-cap-up.xpm e1b3c9d6a6eb6fb6f096736cdfc059cf /usr/share/emacs/site-lisp/auctex/images/prvtex12.xpm cc4101ee6a3ab6a1f4e9991b91b3ff0b /usr/share/emacs/site-lisp/auctex/images/prvtex16.xpm d4dbe057a8d3b2facd61cf7583c1e97c /usr/share/emacs/site-lisp/auctex/images/prvtex20.xpm 28ac0855d853f606dd91e3cfacaa8a14 /usr/share/emacs/site-lisp/auctex/images/prvtex24.xpm 6ce704103821329336489e990bc6f267 /usr/share/emacs/site-lisp/auctex/images/prvwrk12.xpm 5607f4e8bc0eb555206e6a3542205f45 /usr/share/emacs/site-lisp/auctex/images/prvwrk14.xpm 878a72cde3bb6f0ea6d586cff56e619c /usr/share/emacs/site-lisp/auctex/images/prvwrk16.xpm 41811748a97673381115957d42a6529b /usr/share/emacs/site-lisp/auctex/images/prvwrk20.xpm 9690511307f3693e6f28e4db93fdc58c /usr/share/emacs/site-lisp/auctex/images/prvwrk24.xpm e30a80ecb0711ceb42a2ca966ad74bbb /usr/share/emacs/site-lisp/auctex/images/pspdf.xpm 5cc696e2c69ae401c0c223d84d013c8e /usr/share/emacs/site-lisp/auctex/images/sep.xpm e975868b87770a0e1a404292a314d246 /usr/share/emacs/site-lisp/auctex/images/spell.xpm 861fc288565e624ce8b34c1fc42e3496 /usr/share/emacs/site-lisp/auctex/images/tex.xpm 338158cc358b16daf9b58ee54bd14bad /usr/share/emacs/site-lisp/auctex/images/view.xpm 8147722e0061799437edf36d4466e5ab /usr/share/emacs/site-lisp/auctex/images/viewdvi.xpm 67d7ed652615a027038610f8370ba172 /usr/share/emacs/site-lisp/auctex/images/viewpdf.xpm 000ba76725a4fb8489916250544310c7 /usr/share/emacs/site-lisp/auctex/images/viewps.xpm 2cef3e02b54c2d0100d6cc009f26eca6 /usr/share/emacs/site-lisp/auctex/latex.el c8c776d8b945271c79bb93186d71c4a0 /usr/share/emacs/site-lisp/auctex/multi-prompt.el e3324dacb995c956e200d1214c0bc30e /usr/share/emacs/site-lisp/auctex/plain-tex.el 8253e1eaca7b8c39e24848a2b60e25e3 /usr/share/emacs/site-lisp/auctex/p
Bug#896843: FTBFS: incorrect CPPFLAG for powerpc*
Source: ctsim Version: 6.0.2 Severity: serious Tags: l10n patch Justification: fails to build from source (but built successfully in the past) Dear Maintainer, FTBFS of ctsim-6.0.2 on ppc64el reported from unicamp. The build log reported: g++: error: unrecognized command line option '-faltivec'; did you mean '-maltivec' The correct flag for ppc64el (as well as powerpc*) is -maltivec. I changed -faltivec in configure.ac to -maltivec as follows: --- ctsim-6.0.2.orig/configure.ac +++ ctsim-6.0.2/configure.ac @@ -137,7 +137,7 @@ case $target_cpu in CXXFLAGS="$CXXFLAGS $CPUEXT_FLAGS $SIMD_FLAGS" ;; powerpc*) -ARCH_OPTION="-fno-common -faltivec";; +ARCH_OPTION="-fno-common -maltivec";; armv1*|armv2*|armv3*|armv4*|armv5*|armv6*) ARCH_OPTION="-ffast-math";; armv7*|armv8*) I then ran autoconf. After that, the package build properly. This fix should also fix the FTBFS of ctsim on powerpc, powerpcspe, and ppc64. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 4.9.0-4-powerpc64le (SMP w/80 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#896842: ITP: gr-limesdr -- LimeSDR hardware support for GnuRadio
Package: wnpp Severity: wishlist Owner: "A. Maitland Bottoms" * Package name: gr-limesdr Version : 0.9~beta Upstream Author : Lime Microsystems Ltd, Jiang Wei * URL : https://wiki.myriadrf.org/Gr-limesdr_Plugin_for_GNURadio * License : MIT, GPL-3+ Programming Lang: C++, Python Description : LimeSDR hardware support for GnuRadio LimeSDR is a low cost, open source software defined radio (SDR) platform that can be used to support just about any type of wireless communication standard. gr-limesdr provides plugin blocks for GNU Radio software. Currently this plugin supports LimeSDR-USB and LimeSDR-Mini boards.
Bug#889854: RFS: lxml/4.2.1-1~bpo9+1 [intent to maintain bpo]
Dear Backports Team and Mentors, I am still pursuing sponsorship of a stretch-backport of calibre and its dependencies. On Wed, Feb 07, 2018 at 05:15:26PM -0500, Nicholas D Steeves wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my backport of "lxml". It is needed > for a bpo of calibre. I am collaborating with Norbert Preining for > the calibre and html5-parser backports, but have not received a reply > from Matthias Klose wrt lxml. > > https://lists.debian.org/debian-backports/2018/01/msg4.html Package name: lxml Version : 4.2.1-1~bpo9+1 Upstream Author : Stefan Behnel URL : http://lxml.de/ License : PSF, BSD, MIT, and GPL Section : python > It builds these binary packages: > > python-lxml - pythonic binding for the libxml2 and libxslt libraries > python-lxml-dbg - pythonic binding for the libxml2 and libxslt libraries > (debug ext > python-lxml-doc - pythonic binding for the libxml2 and libxslt libraries > (documenta > python3-lxml - pythonic binding for the libxml2 and libxslt libraries > python3-lxml-dbg - pythonic binding for the libxml2 and libxslt libraries > (debug ext > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/lxml Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lxml/lxml_4.2.1-1~bpo9+1.dsc > Finally, one can download it with git using this command. > > git clone https://salsa.debian.org/sten-guest/lxml.git \ > && git checkout stretch-backports > > More information about lxml can be obtained from http://lxml.de/. Changes since the last upload: lxml (4.2.1-1~bpo9+1) stretch-backports; urgency=medium * Rebuild for stretch-backports. -- Nicholas D Steeves Thu, 19 Apr 2018 19:55:28 -0400 lxml (4.2.1-1) unstable; urgency=medium Regards, Nicholas D Steeves signature.asc Description: PGP signature
Bug#893919: RFS: yasnippet-snippets/0.2-1
Hi Chris, On Tue, Apr 24, 2018 at 07:38:13AM +0100, Chris Lamb wrote: > Hi Nicholas, > > > If you have time to sponsor it I'd very much appreciate it :-) > > Link? :) > > > Best wishes, > > -- > ,''`. > : :' : Chris Lamb, Debian Project Leader > `. `'` la...@debian.org / chris-lamb.co.uk >`- Here are the up-to-date links: mentors -> https://mentors.debian.net/package/yasnippet-snippets dget -> https://mentors.debian.net/debian/pool/main/y/yasnippet-snippets/yasnippet-snippets_0.2-1.dsc git -> https://salsa.debian.org/emacsen-team/yasnippet-snippets.git The order of upload for src:elpy-1.19-1 and src:yasnippet-snippets-0.2-1 also doesn't matter at this time, because the changes to elpy's snippets location won't appear until these projects' next upstream release. Thank you :-D Nicholas signature.asc Description: PGP signature
Bug#896841: jessie-pu: package psensor/1.1.3-2
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I have prepared a security update for psensor to fix CVE-2014-10073 in
Jessie. This is Debian bug #896195. The security team has marked this
issue as no-dsa. I am going to upload the new revision shortly. Please
find attached the debdiff.
Regards,
Markus
diff -Nru psensor-1.1.3/debian/changelog psensor-1.1.3/debian/changelog
--- psensor-1.1.3/debian/changelog 2014-10-13 09:20:27.0 +0200
+++ psensor-1.1.3/debian/changelog 2018-04-24 21:23:26.0 +0200
@@ -1,3 +1,12 @@
+psensor (1.1.3-2+deb8u1) jessie; urgency=high
+
+ * Non-maintainer upload by the LTS team.
+ * Fix CVE-2014-10073: The create_response function in server/server.c in
+Psensor allows Directory Traversal because it lacks a check for whether a
+file is under the webserver directory. (Closes: #896195)
+
+ -- Markus Koschany Tue, 24 Apr 2018 21:23:26 +0200
+
psensor (1.1.3-2) unstable; urgency=medium
* debian/control
diff -Nru psensor-1.1.3/debian/patches/CVE-2014-10073.patch
psensor-1.1.3/debian/patches/CVE-2014-10073.patch
--- psensor-1.1.3/debian/patches/CVE-2014-10073.patch 1970-01-01
01:00:00.0 +0100
+++ psensor-1.1.3/debian/patches/CVE-2014-10073.patch 2018-04-24
21:23:26.0 +0200
@@ -0,0 +1,74 @@
+From: Markus Koschany
+Date: Mon, 23 Apr 2018 23:51:42 +0200
+Subject: CVE-2014-10073
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896195
+Origin:
http://git.wpitchoune.net/gitweb/?p=psensor.git;a=commitdiff;h=8b10426dcc0246c1712a99460dd470dcb1cc4d9c
+---
+ src/server/server.c | 26 ++
+ 1 file changed, 22 insertions(+), 4 deletions(-)
+
+diff --git a/src/server/server.c b/src/server/server.c
+index 5862586..fd5662a 100644
+--- a/src/server/server.c
b/src/server/server.c
+@@ -23,6 +23,7 @@
+ #include
+ #define _(str) gettext(str)
+
++#include
+ #include
+ #include
+ #include
+@@ -246,13 +247,24 @@ static struct MHD_Response *
+ create_response(const char *nurl, const char *method, unsigned int *rp_code)
+ {
+ struct MHD_Response *resp = NULL;
++ char *rpath;
++ int n;
+
+ if (!strncmp(nurl, URL_BASE_API_1_1, strlen(URL_BASE_API_1_1))) {
+ resp = create_response_api(nurl, method, rp_code);
+ } else {
+ char *fpath = get_path(nurl, server_data.www_dir);
+
+- resp = create_response_file(nurl, method, rp_code, fpath);
++ rpath = realpath(fpath, NULL);
++ if (rpath) {
++ n = strlen(server_data.www_dir);
++ if (!strncmp(server_data.www_dir, rpath, n))
++ resp = create_response_file(nurl,
++ method,
++ rp_code,
++ fpath);
++ free(rpath);
++ }
+
+ free(fpath);
+ }
+@@ -347,7 +359,7 @@ int main(int argc, char *argv[])
+ switch (optc) {
+ case 'w':
+ if (optarg)
+- server_data.www_dir = strdup(optarg);
++ server_data.www_dir = realpath(optarg, NULL);
+ break;
+ case 'p':
+ if (optarg)
+@@ -386,8 +398,14 @@ int main(int argc, char *argv[])
+ exit(EXIT_FAILURE);
+ }
+
+- if (!server_data.www_dir)
+- server_data.www_dir = strdup(DEFAULT_WWW_DIR);
++ if (!server_data.www_dir) {
++ server_data.www_dir = realpath(DEFAULT_WWW_DIR, NULL);
++ if (!server_data.www_dir) {
++ fprintf(stderr,
++ _("Webserver directory does not exist.\n"));
++ exit(EXIT_FAILURE);
++ }
++ }
+
+ if (!log_file)
+ log_file = strdup(DEFAULT_LOG_FILE);
diff -Nru psensor-1.1.3/debian/patches/series
psensor-1.1.3/debian/patches/series
--- psensor-1.1.3/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ psensor-1.1.3/debian/patches/series 2018-04-24 21:23:26.0 +0200
@@ -0,0 +1 @@
+CVE-2014-10073.patch
Bug#896195: psensor: directory traversal flaw
Control: tags -1 pending
Dear maintainer,
I've prepared a security update of psensor for Jessie versioned as
1.1.3-2+deb8u1. I intend to upload it shortly after this message. Please
find attached the debdiff.
Regards,
Markus
diff -Nru psensor-1.1.3/debian/changelog psensor-1.1.3/debian/changelog
--- psensor-1.1.3/debian/changelog 2014-10-13 09:20:27.0 +0200
+++ psensor-1.1.3/debian/changelog 2018-04-24 21:23:26.0 +0200
@@ -1,3 +1,12 @@
+psensor (1.1.3-2+deb8u1) jessie; urgency=high
+
+ * Non-maintainer upload by the LTS team.
+ * Fix CVE-2014-10073: The create_response function in server/server.c in
+Psensor allows Directory Traversal because it lacks a check for whether a
+file is under the webserver directory. (Closes: #896195)
+
+ -- Markus Koschany Tue, 24 Apr 2018 21:23:26 +0200
+
psensor (1.1.3-2) unstable; urgency=medium
* debian/control
diff -Nru psensor-1.1.3/debian/patches/CVE-2014-10073.patch
psensor-1.1.3/debian/patches/CVE-2014-10073.patch
--- psensor-1.1.3/debian/patches/CVE-2014-10073.patch 1970-01-01
01:00:00.0 +0100
+++ psensor-1.1.3/debian/patches/CVE-2014-10073.patch 2018-04-24
21:23:26.0 +0200
@@ -0,0 +1,74 @@
+From: Markus Koschany
+Date: Mon, 23 Apr 2018 23:51:42 +0200
+Subject: CVE-2014-10073
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896195
+Origin:
http://git.wpitchoune.net/gitweb/?p=psensor.git;a=commitdiff;h=8b10426dcc0246c1712a99460dd470dcb1cc4d9c
+---
+ src/server/server.c | 26 ++
+ 1 file changed, 22 insertions(+), 4 deletions(-)
+
+diff --git a/src/server/server.c b/src/server/server.c
+index 5862586..fd5662a 100644
+--- a/src/server/server.c
b/src/server/server.c
+@@ -23,6 +23,7 @@
+ #include
+ #define _(str) gettext(str)
+
++#include
+ #include
+ #include
+ #include
+@@ -246,13 +247,24 @@ static struct MHD_Response *
+ create_response(const char *nurl, const char *method, unsigned int *rp_code)
+ {
+ struct MHD_Response *resp = NULL;
++ char *rpath;
++ int n;
+
+ if (!strncmp(nurl, URL_BASE_API_1_1, strlen(URL_BASE_API_1_1))) {
+ resp = create_response_api(nurl, method, rp_code);
+ } else {
+ char *fpath = get_path(nurl, server_data.www_dir);
+
+- resp = create_response_file(nurl, method, rp_code, fpath);
++ rpath = realpath(fpath, NULL);
++ if (rpath) {
++ n = strlen(server_data.www_dir);
++ if (!strncmp(server_data.www_dir, rpath, n))
++ resp = create_response_file(nurl,
++ method,
++ rp_code,
++ fpath);
++ free(rpath);
++ }
+
+ free(fpath);
+ }
+@@ -347,7 +359,7 @@ int main(int argc, char *argv[])
+ switch (optc) {
+ case 'w':
+ if (optarg)
+- server_data.www_dir = strdup(optarg);
++ server_data.www_dir = realpath(optarg, NULL);
+ break;
+ case 'p':
+ if (optarg)
+@@ -386,8 +398,14 @@ int main(int argc, char *argv[])
+ exit(EXIT_FAILURE);
+ }
+
+- if (!server_data.www_dir)
+- server_data.www_dir = strdup(DEFAULT_WWW_DIR);
++ if (!server_data.www_dir) {
++ server_data.www_dir = realpath(DEFAULT_WWW_DIR, NULL);
++ if (!server_data.www_dir) {
++ fprintf(stderr,
++ _("Webserver directory does not exist.\n"));
++ exit(EXIT_FAILURE);
++ }
++ }
+
+ if (!log_file)
+ log_file = strdup(DEFAULT_LOG_FILE);
diff -Nru psensor-1.1.3/debian/patches/series
psensor-1.1.3/debian/patches/series
--- psensor-1.1.3/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ psensor-1.1.3/debian/patches/series 2018-04-24 21:23:26.0 +0200
@@ -0,0 +1 @@
+CVE-2014-10073.patch
signature.asc
Description: OpenPGP digital signature
Bug#886131: Same Problem with systemd
Hi, i have the same problem. Package: cryptsetup-bin Source: cryptsetup Version: 2:2.0.2-1 Architecture: amd64 My system has systemd BOOT_IMAGE=/vmlinuz-4.15.0-2-amd64 root=/dev/mapper/neo--vg-root ro quiet On Shutdown the system hangs completely.. root@neo:~# dmesg | grep systemd [ 12.848030] systemd[1]: systemd 238 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid) [ 12.872443] systemd[1]: Detected architecture x86-64. [ 12.874373] systemd[1]: Set hostname to . [ 12.944224] systemd[1]: Created slice system-getty.slice. [ 12.944355] systemd[1]: Listening on Syslog Socket. [ 12.91] systemd[1]: Listening on LVM2 metadata daemon socket. [ 12.944697] systemd[1]: Created slice system-systemd\x2dcryptsetup.slice. [ 12.944715] systemd[1]: Reached target Remote File Systems. [ 12.944792] systemd[1]: Listening on Journal Socket (/dev/log). [ 12.945012] systemd[1]: Created slice system-systemd\x2dfsck.slice. [ 13.033882] systemd-journald[406]: Received request to flush runtime journal from PID 1 Appreciate for any help.. /st
Bug#896464: Passing -V as default
El mar., 24 de abr. de 2018 02:47, Niels Thykier escribió: > Scott Kitterman: > > > > > > On April 23, 2018 10:03:45 PM UTC, "Lisandro Damián Nicanor Pérez Meyer" > wrote: > >> If I understand correctly and, let's suppose, libQtFoo 5.10.2 is built > >> with a patched compat 12, then all applications rebuilt against 5.10.2 > >> would require at very least 5.10.2 even if symbols files allowed it to > >> depend on a minor version. > >> > > As far as I understand it, symbols files overrule shlibs. I.e. if your > symbols files covers all the symbols required by the application, the > version will be derived from the symbols file. > > dpkg-shlibdeps(1) seems to agree with this: [snip] Interesting. That sounds pretty good then. I'll check the next time I rebuild qt. > If that's true, I doubt C++ symbols files are worth the trouble. > > > > Scott K > > > > I think this case would still work as it used too (e.g. ok for .debs and > ignored for .udebs - but as I recall, qtbase-abi does not have any udebs > and should not be concerned by that) > If everything works as we understand it now then yes, it should just simply work. >
Bug#896840: lintian: autopkgtest fails with new version of file
Source: lintian Version: 2.5.84 Severity: normal User: debian...@lists.debian.org Usertags: needs-update With the upload of version 1:5.33-1 of file, the autopkgtest of lintian¹ started to fail with the error copied below. The first change is caused by changed behavior in file regarding application/x-sharedlib vs application/x-pie-executable². Please investigate the situation and update your package accordingly. Paul ¹ https://ci.debian.net/packages/l/lintian/ ² https://github.com/file/file/commit/7dbecfe406a6bb2de1fe7ec2fe413dcd8871ac74#diff-02f0b547c2779d25cff89672135f20e3 autopkgtest [12:51:04]: test testsuite: [--- running tests mkdir -p "/tmp/autopkgtest-lxc.x6opmumq/downtmp/autopkgtest_tmp/testsuite" t/runtests -k -j 2 t "/tmp/autopkgtest-lxc.x6opmumq/downtmp/autopkgtest_tmp/testsuite" suite:changes,debs,source,tests ENV[LINTIAN_TEST_INSTALLED]=yes ENV[PATH]=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games S..S...T T... tests::binaries-libc-link: diff -u t/tests/binaries-libc-link/tags /tmp/autopkgtest-lxc.x6opmumq/downtmp/autopkgtest_tmp/testsuite/tests/binaries-libc-link/tags.binaries-libc-link --- t/tests/binaries-libc-link/tags 2018-04-23 11:50:51.0 + +++ /tmp/autopkgtest-lxc.x6opmumq/downtmp/autopkgtest_tmp/testsuite/tests/binaries-libc-link/tags.binaries-libc-link 2018-04-24 12:54:23.305457114 + @@ -1,3 +1,3 @@ -E: binaries-libc-link: library-not-linked-against-libc usr/lib/basic/libbasic-nolibc E: binaries-libc-link: program-not-linked-against-libc usr/bin/basic -W: binaries-libc-link: shared-lib-without-dependency-information usr/lib/basic/libbasic-nodeps +E: binaries-libc-link: program-not-linked-against-libc usr/lib/basic/libbasic-nolibc +E: binaries-libc-link: statically-linked-binary usr/lib/basic/libbasic-nodeps fail tests::binaries-libc-link: output differs! .S.S ..S.S..SS... .S.. ...S... tests::legacy-libbaz: diff -u t/tests/legacy-libbaz/tags /tmp/autopkgtest-lxc.x6opmumq/downtmp/autopkgtest_tmp/testsuite/tests/libbaz/tags.libbaz --- t/tests/legacy-libbaz/tags 2018-04-23 11:50:51.0 + +++ /tmp/autopkgtest-lxc.x6opmumq/downtmp/autopkgtest_tmp/testsuite/tests/libbaz/tags.libbaz 2018-04-24 13:20:23.395299338 + @@ -14,7 +14,6 @@ E: libbaz1: maintainer-shell-script-fails-syntax-check postinst E: libbaz1: missing-dependency-on-perlapi E: libbaz1: package-must-activate-ldconfig-trigger usr/lib/libfoo2.so.1.0.3b -E: libbaz1: sharedobject-in-library-directory-missing-soname usr/lib/libbaz1.so.1.0.3b E: libbaz1: shlib-missing-in-control-file libbaz2 1.0 for usr/lib/libfoo2.so.1.0.3b E: libbaz1: shlib-with-executable-bit usr/lib/libfoo2.so.1.0.3b 0755 E: libbaz1: symbols-declared-but-not-shlib libbaz 2 fail tests::legacy-libbaz: output differs! .. Skipped/disabled tests: [debs] deb-format-wrong-order: Unmet test dependencies: dpkg (<< 1.17.2) [tests] binaries-missing-lfs: architecture mismatch changelog-file-strange-date: Unmet test dependencies: dpkg (<< 1.18.2) deb-format-udeb-compression: Unmet test dependencies: dpkg (<< 1.18.11) debconf-config-not-executable: Unmet test dependencies: dpkg (<< 1.19.0) debhelper-compat: Unmet test dependencies: debhelper (<< 9.20151101~) debhelper-compat-empty: Unmet test dependencies: debhelper (<< 9.20151101~) runtests-arch-i386: architecture mismatch shared-libs-non-pic-i386: architecture mismatch version-substvars-obsolete: Unmet test dependencies: dpkg (<< 1.17.2) Failed tests (2) tests::binaries-libc-link tests::legacy-libbaz make: *** [debian/rules:50: runtests] Error 1 signature.asc Description: OpenPGP digital signature
Bug#895969: webkit2gtk: FTBFS on riscv64 due to not linking against libatomic
On Tue, Apr 24, 2018 at 09:18:13PM +0200, Aurelien Jarno wrote: > > > The correct way to link with -pthread instead of -lpthread is > > > to use define THREADS_PREFER_PTHREAD_FLAG before importing the > > > Thread package: > > > > Oh, great, I'll give it a try. That didn't fix the problem for me, I'm considering to try this instead: --- webkitgtk.orig/Source/JavaScriptCore/CMakeLists.txt +++ webkitgtk/Source/JavaScriptCore/CMakeLists.txt @@ -120,11 +120,9 @@ set(JavaScriptCore_LIBRARIES # __atomic_fetch_add_8 is not available as a compiler intrinsic. It is # available on other platforms (including 32-bit Arm), so the link # with libatomic is only neede on MIPS. -if (WTF_CPU_MIPS) list(APPEND JavaScriptCore_LIBRARIES --latomic +-Wl,--as-needed -Wl,-latomic -Wl,--no-as-needed ) -endif () > > > I haven't tried the patch for webkit2gtk, but it works > > > for qtwebkit. In addition I guess it's necessary to add > > > support for riscv64 in various places of WTF, by defining > > > WTF_CPU_RISCV64. At least it's the case also for qtwebkit. > > > > webkit has now WTF_CPU_UNKNOWN for cases like this so perhaps we > > don't need to do anything else. > > Hmm that might work for a first version, but it means that > USE_JSVALUE32_64 will be used instead of USE_JSVALUE64. And that > might disable a few features. > > Is that correct? I don't know, but it's worth checking. Platform.h suggests that it wouldn't be the case however: #if __SIZEOF_POINTER__ == 8 #define USE_JSVALUE64 1 #elif __SIZEOF_POINTER__ == 4 #define USE_JSVALUE32_64 1 Berto
Bug#896839: ITP: aes-js.js -- pure JavaScript implementation of the AES block cipher algorithm
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: aes-js.js Version : 3.1.1 Upstream Author : Richard Moore * URL : https://github.com/ricmoo/aes-js * License : Expat Programming Lang: JavaScript Description : pure JavaScript implementation of AES aes-js provides a pure JavaScript implementation of the AES block cipher algorithm and all common modes of operation (CBC, CFB, CTR, ECB and OFB). It also supports all key sizes (128-bit, 192-bit and 256-bit). It works in either node.js or web browsers.
Bug#896838: gnustep-back: autopkgtest fails with new version of file
Source: gnustep-back Version: 0.26.2-3 Severity: normal User: debian...@lists.debian.org Usertags: needs-update With the upload of version 1:5.33-1 of file, the autopkgtest of gnustep-back¹ started to fail with the error copied below. The first change is caused by changed behavior in file regarding application/x-sharedlib vs application/x-pie-executable. It now uses the executable bit to distinguish. Depending on if that is what you want, you may need to update your autopkgtest. On IRC (#debian-devel) it was suggested that instead of relying on file behavior you dlopen the files if that makes any sense (I can't judge). I don't know what happens in the second case. Please investigate and fix your autopkgtest. Paul ¹ https://ci.debian.net/packages/g/gnustep-back/ autopkgtest [09:28:56]: test file-tests: [--- test_art_backend ASSERT:expected: but was: ASSERT:Unknown failure encountered running a test Ran 2 tests. FAILED (failures=2) signature.asc Description: OpenPGP digital signature
Bug#895969: webkit2gtk: FTBFS on riscv64 due to not linking against libatomic
On 2018-04-23 10:22, Alberto Garcia wrote: > On Sun, Apr 22, 2018 at 08:48:19PM +0200, Aurelien Jarno wrote: > > > The correct way to link with -pthread instead of -lpthread is to > > use define THREADS_PREFER_PTHREAD_FLAG before importing the Thread > > package: > > Oh, great, I'll give it a try. > > > I haven't tried the patch for webkit2gtk, but it works for > > qtwebkit. In addition I guess it's necessary to add support for > > riscv64 in various places of WTF, by defining WTF_CPU_RISCV64. At > > least it's the case also for qtwebkit. > > webkit has now WTF_CPU_UNKNOWN for cases like this so perhaps we don't > need to do anything else. > Hmm that might work for a first version, but it means that USE_JSVALUE32_64 will be used instead of USE_JSVALUE64. And that might disable a few features. Is that correct? Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#879589: Combined patch backported from upstream
Hi!
The attached patch was taken from Mozilla's upstream bug report 1326496
and contains the two fixes for both alpha and ia64.
Please drop the incomplete patch Alpha-architecture-is-64-bit.patch from
the package.
On ia64, we also need to lower the optimization level to make the package
build due to issues with the toolchain.
ia64 might also need more adjustments regarding the memory allocator as
it partially suffers from the same problems as arm64 and sparc64 due to
its extended address space. Thus, if mozjs segfaults on ia64, we need
to include ia64 in the list of changes in the sparc64-support.patch.
Adrian
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1326496
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Description: Build fixes for alpha and ia64
Backported upstream build fixes for alpha and ia64,
taken from Mozilla bug 1326496.
See: https://bugzilla.mozilla.org/show_bug.cgi?id=1326496
Author: John Paul Adrian Glaubitz
Bug-Debian: https://bugs.debian.org/878285
Last-Update: 2018-04-20
--- mozjs52-52.3.1.orig/python/mozbuild/mozbuild/configure/constants.py
+++ mozjs52-52.3.1/python/mozbuild/mozbuild/configure/constants.py
@@ -40,7 +40,7 @@ Kernel = EnumString.subclass(
CPU_bitness = {
'aarch64': 64,
-'Alpha': 32,
+'Alpha': 64,
'arm': 32,
'hppa': 32,
'ia64': 64,
--- mozjs52-52.3.1.orig/testing/mozbase/mozinfo/mozinfo/mozinfo.py
+++ mozjs52-52.3.1/testing/mozbase/mozinfo/mozinfo/mozinfo.py
@@ -15,7 +15,7 @@ import platform
import re
import sys
from .string_version import StringVersion
-
+from ctypes.util import find_library
# keep a copy of the os module since updating globals overrides this
_os = os
@@ -150,7 +150,7 @@ if info['os'] == 'linux':
import errno
PR_SET_SECCOMP = 22
SECCOMP_MODE_FILTER = 2
-ctypes.CDLL("libc.so.6", use_errno=True).prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, 0)
+ctypes.CDLL(find_library("c"), use_errno=True).prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, 0)
info['has_sandbox'] = ctypes.get_errno() == errno.EFAULT
else:
info['has_sandbox'] = True
Bug#896704: RFS: python-picklable-itertools/0.1.1-2 [RC]
On Mon, Apr 23, 2018 at 08:58:30PM -0400, Sergio Durigan Junior wrote:
> Hi Fabian,
>
> I can help with it, but there are two things I'd like to see first.
Thank you for your review!
> 1) There are no Vcs-* fields, and it's unclear to me where the git
> repository for the package is located (I couldn't find it on
> salsa.d.o).
I did not maintain the package in a public Git repository so far, so I
created a fresh repository, imported my changes and put it on Salsa:
https://salsa.debian.org/wolff-guest/python-picklable-itertools
I have added Vcs-Git and Vcs-Browser fields accordingly.
> 2) If having the Python 2 version of this package is important for some
> reason, could you please override the lintian warning
> ("new-package-should-not-package-python2-module")?
I think that the Python 2 version is not really important; in fact, I
did not even include it in the original package, but my previous
sponsor for this package suggested that I should add it (see #841228).
I have now simply removed the Python 2 package from debian/control; is
this sufficient, or do I have to do anything more than that?
I have reuploaded the package to Mentors with the aforementioned
changes.
Best regards,
Fabian
Bug#887494: mozjs52: FTBFS on sparc64: interpreter segfaults
On 01/17/2018 01:43 PM, John Paul Adrian Glaubitz wrote:
> I can whip up a patch for mozjs52 to add sparc64 support if there is
> a realistic chance for it to be merged. My m68k [3] and sh4 [4] patches for
> mozjs52 are still without any reply, for example.
Attaching said patch. I hope to get around sending a pull request on Salsa
the next days.
The patches should be applied in this order:
- sh4-support.patch (#880692)
- m68k-support.patch (#880693)
- sparc64-support.patch (this bug report)
I'll also send a clean one for alpha and ia64 (#887496).
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Description: Add support for sparc64
Author: John Paul Adrian Glaubitz
Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1275204
Last-Update: 2017-06-18
Index: firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
===
--- firefox-esr-52.2.0esr.orig/js/src/gc/Memory.cpp
+++ firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
@@ -501,7 +501,7 @@ static inline void*
MapMemoryAt(void* desired, size_t length, int prot = PROT_READ | PROT_WRITE,
int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 0)
{
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__)
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && (defined(__NetBSD__) || defined(__linux__)))
MOZ_ASSERT((0x8000ULL & (uintptr_t(desired) + length - 1)) == 0);
#endif
void* region = mmap(desired, length, prot, flags, fd, offset);
@@ -524,7 +524,7 @@ static inline void*
MapMemory(size_t length, int prot = PROT_READ | PROT_WRITE,
int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 0)
{
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && defined(__NetBSD__))
/*
* The JS engine assumes that all allocated pointers have their high 17 bits clear,
* which ia64's mmap doesn't support directly. However, we can emulate it by passing
@@ -551,7 +551,7 @@ MapMemory(size_t length, int prot = PROT
return nullptr;
}
return region;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || (defined(__sparc__) && defined(__arch64__) && defined(__linux__))
/*
* There might be similar virtual address issue on arm64 which depends on
* hardware and kernel configurations. But the work around is slightly
Index: firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
===
--- firefox-esr-52.2.0esr.orig/js/src/jsapi-tests/testGCAllocator.cpp
+++ firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
@@ -312,7 +312,7 @@ void unmapPages(void* p, size_t size) {
void*
mapMemoryAt(void* desired, size_t length)
{
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || defined(__aarch64__)
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && (defined(__NetBSD__) || defined(__linux__)))
MOZ_RELEASE_ASSERT(0x8000ULL & (uintptr_t(desired) + length - 1) == 0);
#endif
void* region = mmap(desired, length, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
@@ -334,7 +334,7 @@ mapMemory(size_t length)
int fd = -1;
off_t offset = 0;
// The test code must be aligned with the implementation in gc/Memory.cpp.
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && defined(__NetBSD__))
void* region = mmap((void*)0x0700, length, prot, flags, fd, offset);
if (region == MAP_FAILED)
return nullptr;
@@ -344,7 +344,7 @@ mapMemory(size_t length)
return nullptr;
}
return region;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || (defined(__sparc__) && defined(__arch64__) && defined(__linux__))
const uintptr_t start = UINT64_C(0x0700);
const uintptr_t end = UINT64_C(0x8000);
const uintptr_t step = js::gc::ChunkSize;
Index: firefox-esr-52.2.0esr/memory/jemalloc/src/include/jemalloc/internal/mb.h
===
--- firefox-esr-52.2.0esr.orig/memory/jemalloc/src/include/jemalloc/internal/mb.h
+++ firefox-esr-52.2.0esr/memory/jemalloc/src/include/jemalloc/internal/mb.h
@@ -76,7 +76,7 @@ mb_write(void)
: "memory" /* Clobbers. */
);
}
-#elif defined(__sparc64__)
+#elif defined(__sparc__) && defined(__arch64__)
JEMALLOC_INLINE void
mb_write(void)
{
Index: firefox-esr-52.2.0esr/memory/mozjemalloc/jemalloc.c
===
--- firefox-esr-52.2.0esr.orig/memory/mozjemalloc/jem
Bug#896836: ktexteditor: ktexteditor / Kate local privilege escalation
Source: ktexteditor Version: 5.37.0-2 Severity: grave Tags: security upstream Hi See http://www.openwall.com/lists/oss-security/2018/04/24/1 for details (and proposed patch). Regards, Salvatore
Bug#896835: libassimp-dev: CMake configuration resolves incorrect paths with multiarch lib directory
Package: libassimp-dev
Severity: normal
Tags: upstream
Due to an upstream bug (1), Using libassimp-dev from CMake is broken due
to the way the upstream CMake config calculates the root directory and
the use of -DASSIMP_LIB_INSTALL_DIR to install assimp into a multiarch
directory.
The included example CMakeLists.txt displays the issue.
When I run it on stretch or buster I get output that includes
-- ASSIMP_ROOT_DIR: /usr/lib
-- ASSIMP_LIBRARY_DIRS: /usr/lib/lib/x86_64-linux-gnu
-- ASSIMP_INCLUDE_DIRS: /usr/lib/include
I have proposed a fix upstream (2) but I am not sure if or when it will
be accepted.
(1) https://github.com/assimp/assimp/issues/1914
(2) https://github.com/assimp/assimp/issues/1915
-- System Information:
Debian Release: 9.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Versions of packages libassimp-dev depends on:
pn libassimp3v5
libassimp-dev recommends no packages.
libassimp-dev suggests no packages.
*** example/CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
project(example)
find_package(assimp)
message(STATUS "ASSIMP_ROOT_DIR: ${ASSIMP_ROOT_DIR}")
message(STATUS "ASSIMP_LIBRARY_DIRS: ${ASSIMP_LIBRARY_DIRS}")
message(STATUS "ASSIMP_INCLUDE_DIRS: ${ASSIMP_INCLUDE_DIRS}")
Bug#894159: transition: icu
On Tue, Apr 24, 2018 at 6:46 PM, Rene Engelhard wrote: > On Mon, Apr 23, 2018 at 09:19:06PM +0200, László Böszörményi wrote: >> > I would appreciate a number of failing rdeps and how many are due to ICU >> > API >> > changes and how many are due to icu-config removal. >> [...] I do not >> recall any API change. In short, there are fifteen packages FTBFS and > > Interesting. I do. Let me rephrase my sentence. I do not remember any FTBFS reason which happens due to an ICU API change. I could build all dependent packages without any code change in those. Sorry for the bad wording. I'm in a run, but double checked my patches and all about ICU detection without icu-config installed - expect one. That is OpenTTD which need an additional build dependency on libicu-le-hb-dev. To be extra sure about the possible changes needed in the packages, I'll start the rebuild tests soon. Kind regards, Laszlo/GCS
Bug#896720: [Pkg-utopia-maintainers] Bug#896720: NetworkManager.pc lost
Hi Harald
Am 24.04.2018 um 18:29 schrieb Harald Dunkel:
> What is your suggestion to use as a replacement? Upstream (network-manager-
> strongswan) told me that I need to grab the variables plugindir and
> libgnome_serverdir provided by the old NetworkManager.pc from somewhere
> now.
>
> Are these directories the variables had pointed to obsolete as well?
The successor is libnm and there is a corresponding libnm.pc which
contains the following
# cat /usr/lib/x86_64-linux-gnu/pkgconfig/libnm.pc
prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include
vpnservicedir=${prefix}/lib/NetworkManager/VPN
Name: libnm
Description: Convenience library for clients of NetworkManager
Version: 1.11.3
Requires: gio-2.0
Cflags: -I${includedir}/libnm
Libs: -L${libdir} -lnm
What's definitely deprecated is the old location /etc/NetworkManager/VPN
The service .name files should be installed in vpnservicedir.
I would best take a look at how existing packages, like
network-manager-openvpn do it.
If you have more specific questions, it's probably best to ask upstream.
They have a mailing list at
https://mail.gnome.org/mailman/listinfo/networkmanager-list or are
reachable on IRC (freenode) at #nm.
Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Bug#896834: /usr/bin/apt-key: apt-key fails in an lxc environment after upgrade to stretch
Package: apt Version: 1.4.8 Severity: important File: /usr/bin/apt-key After dist-upgrading to stretch apt update is not able to update the package list anymore as apt-key fails with the following message: Couldn't execute /usr/bin/apt-key to check /var/lib/apt/lists/partial/security.debian.org_dists_stretch_updates_InRelease When running apt update with '-o Debug::Acquire::gpgv=1' this output is generated for each entr in sources.list: Holen:1 http://security.debian.org stretch/updates InRelease [94,3 kB] 0% [Verbindung mit ftp.de.debian.org (141.76.2.4)]inside VerifyGetSigners 0% [1 InRelease gpgv 94,3 kB] [Verbindung mit ftp.de.debian.org (141.76.2.4)]Preparing to exec: /usr/bin/apt-key --quiet --readonly verify --status-fd 3 /tmp/apt.sig.GUdUTV /tmp/apt.data.wZVPUb Read: [APTKEY:] ERROR Couldn't execute /usr/bin/apt-key to check /var/lib/apt/lists/partial/security.debian.org_dists_stretch_updates_InRelease gpgv exited with status 111 Summary: Good: Bad: Worthless: SoonWorthless: NoPubKey: NODATA: no Fehl:1 http://security.debian.org stretch/updates InRelease Couldn't execute /usr/bin/apt-key to check /var/lib/apt/lists/partial/security.debian.org_dists_stretch_updates_InRelease Ign:2 http://ftp.de.debian.org/debian stretch InRelease - This issue can be reproduced on each vhost which is upgraded to stretch on my system. As this means that I'm not able to get required security upgrades this is a quite urgent issue. I've tested up to now the following hot-fixes (whithout any effect): - using root as sandbox user - deleting and recreating /var/lib/apt/lists/* - reset /tmp/ world-writeable (it was world-writeable actually) - using this stanca in sources.list: deb [ trusted=yes allow-insecure=yes ] - installing linux-image (as dicussed in a ubuntu bug report) the only manual modification after the system upgrade of each unit was to remove systemd and replace it by sysvinit as systemd was not working out-of-the-box and I was running out of time. Any hints what's wrong here? Greetings Patrick -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "0"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-6-amd64$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-image"; APT::VersionedKernelPackages:: "linux-headers"; APT::VersionedKernelPackages:: "linux-image-extra"; APT::VersionedKernelPackages:: "linux-signed-image"; APT::VersionedKernelPackages:: "kfreebsd-image"; APT::VersionedKernelPackages:: "kfreebsd-headers"; APT::VersionedKernelPackages:: "gnumach-image"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::VersionedKernelPackages:: "linux-backports-modules-.*"; APT::VersionedKernelPackages:: "linux-tools"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "contrib/metapackages"; APT::Never-MarkAuto-Sections:: "non-free/metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Move-Autobit-Sections:: "contrib/oldlibs"; APT::Move-Autobit-Sections:: "non-free/oldlibs"; APT::Move-Autobit-Sections:: "restricted/oldlibs"; APT::Move-Autobit-Sections:: "universe/oldlibs"; APT::Move-Autobit-Sections:: "multiverse/oldlibs"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "false"; APT::Compressor::lz4::Cost "50"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressAr
Bug#896833: zita-alsa-pcmi FTCBFS: multiple issues
Source: zita-alsa-pcmi Version: 0.2.0-4 Tags: patch User: helm...@debian.org Usertags: rebootstrap zita-alsa-pcmi fails to cross build from source for multiple reasons: * It doesn't pass cross tools to make. -> Use dh_auto_build. * The upstream build system hard codes g++. -> Use $(CXX). * The upstream build system uses ldconfig. -> Make a symlink. After fixing these, it cross builds successfully. Please consider applying the attached patch. Helmut diff --minimal -Nru zita-alsa-pcmi-0.2.0/debian/changelog zita-alsa-pcmi-0.2.0/debian/changelog --- zita-alsa-pcmi-0.2.0/debian/changelog 2016-12-27 12:03:32.0 +0100 +++ zita-alsa-pcmi-0.2.0/debian/changelog 2018-04-24 19:30:43.0 +0200 @@ -1,3 +1,13 @@ +zita-alsa-pcmi (0.2.0-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ Let dh_auto_build pass cross tools to make. ++ Make g++ substitutable. ++ ldconfig doesn't work during cross. + + -- Helmut Grohne Tue, 24 Apr 2018 19:30:43 +0200 + zita-alsa-pcmi (0.2.0-4) unstable; urgency=medium * Set dh/compat 10. diff --minimal -Nru zita-alsa-pcmi-0.2.0/debian/patches/01-makefile.patch zita-alsa-pcmi-0.2.0/debian/patches/01-makefile.patch --- zita-alsa-pcmi-0.2.0/debian/patches/01-makefile.patch 2013-08-12 20:42:47.0 +0200 +++ zita-alsa-pcmi-0.2.0/debian/patches/01-makefile.patch 2018-04-24 19:30:43.0 +0200 @@ -28,7 +28,7 @@ install -Dm 644 $(ZITA-ALSA-PCMI_MIN) $(DESTDIR)$(PREFIX)/$(LIBDIR)/$(ZITA-ALSA-PCMI_MIN) ln -sf $(ZITA-ALSA-PCMI_MIN) $(DESTDIR)$(PREFIX)/$(LIBDIR)/$(ZITA-ALSA-PCMI_SO) - ldconfig -+ /sbin/ldconfig -n $(DESTDIR)$(PREFIX)/$(LIBDIR) ++ ln -sf $(ZITA-ALSA-PCMI_MIN) $(DESTDIR)$(PREFIX)/$(LIBDIR)/$(ZITA-ALSA-PCMI_MAJ) uninstall: rm -rf $(DESTDIR)$(PREFIX)/include/zita-alsa-pcmi.h diff --minimal -Nru zita-alsa-pcmi-0.2.0/debian/patches/05-cross.patch zita-alsa-pcmi-0.2.0/debian/patches/05-cross.patch --- zita-alsa-pcmi-0.2.0/debian/patches/05-cross.patch 1970-01-01 01:00:00.0 +0100 +++ zita-alsa-pcmi-0.2.0/debian/patches/05-cross.patch 2018-04-24 19:30:43.0 +0200 @@ -0,0 +1,37 @@ +Make g++ substitutable for cross compilation. + +Index: zita-alsa-pcmi-0.2.0/libs/Makefile +=== +--- zita-alsa-pcmi-0.2.0.orig/libs/Makefile zita-alsa-pcmi-0.2.0/libs/Makefile +@@ -45,7 +45,7 @@ + + + $(ZITA-ALSA-PCMI_MIN): $(ZITA-ALSA-PCMI_O) +- g++ -shared $(LDFLAGS) -Wl,-soname,$(ZITA-ALSA-PCMI_MAJ) -o $(ZITA-ALSA-PCMI_MIN) $(ZITA-ALSA-PCMI_O) $(ZITA-ALSA-PCMI_DEP) ++ $(CXX) -shared $(LDFLAGS) -Wl,-soname,$(ZITA-ALSA-PCMI_MAJ) -o $(ZITA-ALSA-PCMI_MIN) $(ZITA-ALSA-PCMI_O) $(ZITA-ALSA-PCMI_DEP) + + + install: $(ZITA-ALSA-PCMI_MIN) +Index: zita-alsa-pcmi-0.2.0/apps/Makefile +=== +--- zita-alsa-pcmi-0.2.0.orig/apps/Makefile zita-alsa-pcmi-0.2.0/apps/Makefile +@@ -34,7 +34,7 @@ + ALSA_LOOPBACK_O = alsa_loopback.o pxthread.o + alsa_loopback:LDLIBS += ../libs/libzita-alsa-pcmi.so.0.2.0 -lasound -lpthread -lrt + alsa_loopback:$(ALSA_LOOPBACK_O) +- g++ $(LDFLAGS) -o $@ $(ALSA_LOOPBACK_O) $(LDLIBS) ++ $(CXX) $(LDFLAGS) -o $@ $(ALSA_LOOPBACK_O) $(LDLIBS) + $(ALSA_LOOPBACK_O): + -include $(_ALSA_LOOPBACK_O:%.o=%.d) + +@@ -42,7 +42,7 @@ + ALSA_DELAY_O =alsa_delay.o mtdm.o pxthread.o + alsa_delay: LDLIBS += ../libs/libzita-alsa-pcmi.so.0.2.0 -lasound -lpthread -lrt + alsa_delay: $(ALSA_DELAY_O) +- g++ $(LDFLAGS) -o $@ $(ALSA_DELAY_O) $(LDLIBS) ++ $(CXX) $(LDFLAGS) -o $@ $(ALSA_DELAY_O) $(LDLIBS) + $(ALSA_DELAY_O): + -include $(ALSA_DELAY_O:%.o=%.d) + diff --minimal -Nru zita-alsa-pcmi-0.2.0/debian/patches/series zita-alsa-pcmi-0.2.0/debian/patches/series --- zita-alsa-pcmi-0.2.0/debian/patches/series 2016-12-27 12:03:32.0 +0100 +++ zita-alsa-pcmi-0.2.0/debian/patches/series 2018-04-24 19:30:43.0 +0200 @@ -2,3 +2,4 @@ 02-missing_include.patch 03-fix_usage.patch 04-spelling.patch +05-cross.patch diff --minimal -Nru zita-alsa-pcmi-0.2.0/debian/rules zita-alsa-pcmi-0.2.0/debian/rules --- zita-alsa-pcmi-0.2.0/debian/rules 2016-12-27 12:03:32.0 +0100 +++ zita-alsa-pcmi-0.2.0/debian/rules 2018-04-24 19:30:41.0 +0200 @@ -13,8 +13,8 @@ dh $@ -Smakefile override_dh_auto_build: - $(MAKE) -C libs/ - $(MAKE) -C apps/ + dh_auto_build --sourcedirectory=libs/ + dh_auto_build --sourcedirectory=apps/ override_dh_auto_clean: dh_auto_clean
Bug#896832: osmo-fl2k: Incomplete debian/copyright?
Source: osmo-fl2k Version: 0.1.0+20180423git9e79bde-1 Severity: serious Justication: Policy 12.5 X-Debbugs-CC: Thorsten Alteholz Hi, I just ACCEPTed osmo-fl2k from NEW but noticed it was missing attribution in debian/copyright for at least Christophe Jacquet, Bartek Kania, Kyle Keen, Michael Tatarinov, etc etc. (This is in no way exhaustive so please check over the entire package carefully and address these on your next upload.) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#896831: rapid-photo-downloader: needs a dependency on libmediainfo0v5
Package: rapid-photo-downloader Version: 0.9.9-1 Severity: important RPD currently depends on python3-pymediainfo, which itself does NOT depend upon libmediainfo0v5. As a result, upon startup, RPD complains that some features won't be available because mediainfo doesn't seem to be installed. Solution: one of python3-pymediainfo or rapid-photo-downloader needs an explicit dependency on libmediainfo0v5. Best Regards, Martin-Éric
Bug#854165: conf.avil subdirectories now causing fontconfig warnings
# fc-cache -s Fontconfig error: failed reading config file Fontconfig error: failed reading config file Fontconfig error: failed reading config file Fontconfig error: failed reading config file Fontconfig error: failed reading config file Turns out each of those is one place where /etc/fonts/conf.d has a symlink to one of these directories. I fixed the problem locally on my system by moving the directories out of the way and then moving the .dpkg-new file in to place.
Bug#896817: /usr/lib/gdm3/gdm-wayland-session: bash: ligne 0 : exec: -l : option non valable
Control: retitle -1 /usr/lib/gdm3/gdm-wayland-session: bash: ligne 0 : exec: -l : option non valable Control: tags -1 + moreinfo On Tue, 24 Apr 2018 at 16:29:26 +0200, Stéphane Glondu wrote: > Since very recently, when I try to log in with default choice, it does > not work. (Retitled to something a little less generic.) Please try editing /usr/bin/gnome-session (it's a shell script) and making it log what it's doing: #!/bin/sh echo "SHELL: $SHELL" >&2 echo "XDG_SESSION_CLASS: $XDG_SESSION_CLASS" >&2 echo "XDG_SESSION_TYPE: $XDG_SESSION_TYPE" >&2 echo "\$0: $0" >&2 echo "bash: $(command -v bash)" >&2 echo "BASH_VERSION: $(bash -c 'echo $BASH_VERSION')" >&2 for arg in "$@"; do echo "\$@: $arg" >&2 done echo "end of \$@" ... continue with what the script does now ... Then try logging in again, in the same way. You should get more information logged. Thanks, smcv
Bug#896822: sqitch: new upstream release 0.998 available
On Tue, 24 Apr 2018 19:29:31 +0300, Niko Tyni wrote: > > 0.9997-1 prepared in git; I don't see 0.9998 on github or CPAN ?! > Oh. The upstream master branch on github does refer to 0.9998 but > I guess it's just not released yet. Ack, git has 5 commits after the 0.9997 tag, where only 2 touch (the same line) of code. If there is any hurry, we could add this one-line-change as a patch as well. > Please let's keep this open until 0.9998 actual; the fixes there were > specifically requested. Understood. 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: Uriah Heep: Look At Yourself signature.asc Description: Digital Signature
Bug#896830: please backport
Source: python-certbot-dns-rfc2136 Severity: normal Could you please backport this package to stable? This is necessary to use letsencrypt's new wildcard cert support. I installed it (and a single python module it depends on) from unstable and it works fine with the certbot backport. -- see shy jo signature.asc Description: PGP signature
Bug#881725: apache2: reload fails inside (libvirt) lxc container
On Mon, Apr 23, 2018 at 09:48:03PM +0200, Stefan Fritsch wrote: > On Monday, 16 April 2018 21:51:36 CEST Stefan Fritsch wrote: > > So tmpreaper should exclude systemd-private-* files by default. Moritz, do > > you also have some cron job cleaning up stale files in /tmp ? > > tmpreaper needs to exclude dirs inside the systemd-private-* dir, too (there > is a tmp dir inside). There does not seem to be a recursive mode and > > TMPREAPER_PROTECT_EXTRA='/tmp/systemd-private*' > > did not help. Probably something like > > TMPREAPER_PROTECT_EXTRA='/tmp/systemd-private*/*' > > should work better. I've run some initial tests and that seems to fix it, but I'll do some more tests tomorrow. Cheers, Moritz
Bug#896829: refind FTCBFS: uses the build architecture toolchain
Source: refind Version: 0.11.2-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap refind fails to cross build from source, because it uses the build architecture toolchain. Using dh_auto_build mostly fixes that, but the build system also needs an ARCH variable for cross building. After doing both, refind cross builds successfully. Please consider applying the attached patch. Helmut diff --minimal -Nru refind-0.11.2/debian/changelog refind-0.11.2/debian/changelog --- refind-0.11.2/debian/changelog 2017-12-05 00:39:01.0 +0100 +++ refind-0.11.2/debian/changelog 2018-04-24 06:14:41.0 +0200 @@ -1,3 +1,12 @@ +refind (0.11.2-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ Pass ARCH= to make. ++ Let dh_auto_build pass cross tools to make. + + -- Helmut Grohne Tue, 24 Apr 2018 06:14:41 +0200 + refind (0.11.2-1) unstable; urgency=medium * Update to 0.11.2 upstream release diff --minimal -Nru refind-0.11.2/debian/rules refind-0.11.2/debian/rules --- refind-0.11.2/debian/rules 2015-12-01 05:09:38.0 +0100 +++ refind-0.11.2/debian/rules 2018-04-24 06:14:41.0 +0200 @@ -4,15 +4,19 @@ DEB_HOST_ARCH_CPU := $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU 2>/dev/null) ifeq (amd64, $(DEB_HOST_ARCH_CPU)) + ARCH := x86_64 EFI_ARCH := x64 else ifeq (i386, $(DEB_HOST_ARCH_CPU)) + ARCH := ia32 EFI_ARCH := ia32 else ifeq (arm64, $(DEB_HOST_ARCH_CPU)) + ARCH = aarch64 EFI_ARCH := aa64 else $(warning EFI architecture for $(DEB_HOST_ARCH_CPU) is unknown) + ARCH := $(DEB_HOST_ARCH_CPU) EFI_ARCH := $(DEB_HOST_ARCH_CPU) endif endif @@ -26,8 +30,8 @@ rm -rf drivers_*/ override_dh_auto_build: - $(MAKE) gnuefi - $(MAKE) fs_gnuefi + dh_auto_build -- gnuefi 'ARCH=$(ARCH)' + dh_auto_build -- fs_gnuefi 'ARCH=$(ARCH)' override_dh_auto_install: # "make install" actually runs "efi-install" for the current system, so let's not do that :)
Bug#896828: perl: FTBFS on ia64: t/op/sprintf2.t failure
Package: perl Version: 5.26.2-2 X-Debbugs-Cc: debian-i...@lists.debian.org This package failed to build on ia64. t/op/sprintf2 .. # Failed test 1492 - subnormal 0x1.fp-1022 %a 0x1.fp-1022 got 0x0p+0 at op/sprintf2.t line 812 # got "0x0p+0" # expected "0x1.fp-1022" # Failed test 1493 - subnormal 0x0.fp-1022 %a 0x1.ep-1023 got 0x0p+0 at op/sprintf2.t line 812 # got "0x0p+0" # expected "0x1.ep-1023" # Failed test 1494 - subnormal 0x0.7p-1022 %a 0x1.cp-1024 got 0x0p+0 at op/sprintf2.t line 812 # got "0x0p+0" # expected "0x1.cp-1024" # Failed test 1495 - subnormal 0x0.3p-1022 %a 0x1.8p-1025 got 0x0p+0 at op/sprintf2.t line 812 # got "0x0p+0" # expected "0x1.8p-1025" # Failed test 1496 - subnormal 0x0.1p-1022 %a 0x1.p-1026 got 0x0p+0 at op/sprintf2.t line 812 # got "0x0p+0" # expected "0x1.p-1026" # Failed test 1497 - subnormal 0x0.0p-1022 %a 0x1.fffep-1027 got 0x0p+0 at op/sprintf2.t line 812 # got "0x0p+0" # expected "0x1.fffep-1027" FAILED at test 1492 [...] Failed 1 test out of 2455, 99.96% okay. op/sprintf2.t This regressed between 5.26.1-5 and 5.26.1-6, but I doubt the source changes between those caused it. A toolchain regression seems more likely, but I haven't tested this in any way. @debian-ia64: would you please look into it? -- Niko Tyni nt...@debian.org
Bug#894159: transition: icu
On Mon, Apr 23, 2018 at 09:19:06PM +0200, László Böszörményi wrote: > > I would appreciate a number of failing rdeps and how many are due to ICU API > > changes and how many are due to icu-config removal. > [...] I do not > recall any API change. In short, there are fifteen packages FTBFS and Interesting. I do. https://cgit.freedesktop.org/libreoffice/core/diff/i18npool/source/breakiterator/breakiterator_unicode.cxx?id=3e42714c76b1347babfdea0564009d8d82a83af4 Regards, Rene
Bug#896827: perl: FTBFS on riscv64: t/re/fold_grind timeout
Package: perl
Version: 5.26.2-2
X-Debbugs-Cc: debian-ri...@lists.debian.org
This package failed to build on riscv64.
t/re/fold_grind # Test
process timed out - terminating
FAILED--no leader found
[...]
Failed 1 test out of 2457, 99.96% okay.
re/fold_grind.t
[...]
Build needed 05:11:45, 350184k disk space
It looks to me like the buildd host is just too slow for this test.
>From the test:
my $time_out_factor = $ENV{PERL_TEST_TIME_OUT_FACTOR} || 1;
$time_out_factor = 1 if $time_out_factor < 1;
watchdog(5 * 60 * $time_out_factor);
so the default timeout is five minutes but can be multiplied with
PERL_TEST_TIME_OUT_FACTOR in the environment.
AFAICS the build time of five hours is well above all the other
architectures, even m68k and sh4, and it's still less than half of
a successful build (we have to build perl three times with different
options, and run the test suite for two of those builds.)
@debian-riscv: I guess I can set PERL_TEST_TIME_OUT_FACTOR=2 for riscv64
in debian/rules or something like that, do you think that's sensible or
are the current riscv64 buildds going to get faster any time soon?
--
Niko Tyni nt...@debian.org
Bug#896815: Adopting clearlooks-phenix-theme
Control: retitle -1 ITA: clearlooks-phenix-theme -- GTK3 port of Clearlooks theme Control: owner -1 jbi...@debian.org I think it would be appropriate for the Debian Desktop Themes team to adopt this package. https://tracker.debian.org/teams/desktop-themes-team/ Thanks, Jeremy Bicha
Bug#896720: NetworkManager.pc lost
What is your suggestion to use as a replacement? Upstream (network-manager- strongswan) told me that I need to grab the variables plugindir and libgnome_serverdir provided by the old NetworkManager.pc from somewhere now. Are these directories the variables had pointed to obsolete as well? Regards Harri
Bug#896822: sqitch: new upstream release 0.998 available
* gregor herrmann [Tue Apr 24, 2018 at 06:07:41PM +0200]: > On Tue, 24 Apr 2018 18:38:21 +0300, Niko Tyni wrote: > > Package: sqitch > > Version: 0.9996-1 > > Severity: wishlist > > I got a private request for packaging upstream version 0.9998. > > Filing this publicly. I'm happy if somebody else in the team wants to > > handle it. > 0.9997-1 prepared in git; I don't see 0.9998 on github or CPAN ?! > I'll try and have another look later ... https://github.com/theory/sqitch/blob/master/README.md talks about 0.9998 and there's https://github.com/theory/sqitch/commit/8457221d635baa20e07a13e4ee0255ecca5ace37 though there's no such tag at https://github.com/theory/sqitch/tags nor any such release at https://github.com/theory/sqitch/releases - strange indeed :) regards, -mika- signature.asc Description: Digital signature
Bug#896822: sqitch: new upstream release 0.998 available
On Tue, Apr 24, 2018 at 06:07:41PM +0200, gregor herrmann wrote: > On Tue, 24 Apr 2018 18:38:21 +0300, Niko Tyni wrote: > > > Package: sqitch > > Version: 0.9996-1 > > Severity: wishlist > > > > I got a private request for packaging upstream version 0.9998. > > > > Filing this publicly. I'm happy if somebody else in the team wants to > > handle it. > > 0.9997-1 prepared in git; I don't see 0.9998 on github or CPAN ?! Oh. The upstream master branch on github does refer to 0.9998 but I guess it's just not released yet. Please let's keep this open until 0.9998 actual; the fixes there were specifically requested. Thanks, -- Niko
Bug#855016: Onionshare 1.3 implements possibility to use system tor
Onionshare 1.3 ships a bundled Tor and allows also to use system tor or TBB's tor. When wanting to use system tor, you - need to be in the debian-tor group - open tor's control port Also see https://github.com/micahflee/onionshare/wiki/Connecting-to-Tor for more information. I think we can now close this wishlist bug.
Bug#896826: partman-auto: Wrong minimal disk size calculation when using expert_recipe and lvm partitions
Package: partman-auto
Version: partman-auto
Severity: important
Tags: d-i
Dear Maintainer,
* What led up to the situation?
Trying to pressed the debian installer for automatic partitionning.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Used these preseed rules:
d-i partman-auto/disk string /dev/sda
d-i partman-auto/method string lvm
d-i partman-auto/expert_recipe string \
arcadia ::\
30 50 100 ext4\
$primary{ } $bootable{ } \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /boot } \
. \
64 1024 300% linux-swap \
method{ swap } format{ } \
. \
1980 3000 -1 ext4 \
$defaultignore{ } \
$primary{ } \
method{ lvm } \
device{ /dev/sda }\
vg_name{ system } \
. \
60 100 150 ext4 \
$lvmok{ } in_vg{ system } lv_name{ root } \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ / } \
. \
750 1000 15000 ext4 \
$lvmok{ } in_vg{ system } lv_name{ usr } \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /usr }\
. \
10 20 30 ext4 \
$lvmok{ } in_vg{ system } lv_name{ home } \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /home } \
. \
10 20 30 ext4 \
$lvmok{ } in_vg{ system } lv_name{ roothome } \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /root } \
. \
20 30 50 ext4 \
$lvmok{ } in_vg{ system } lv_name{ tmp } \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /tmp }\
. \
800 1000 1 ext4 \
$lvmok{ } in_vg{ system } lv_name{ var } \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /var }\
. \
250 500 1000 ext4 \
$lvmok{ } in_vg{ system } lv_name{ log } \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /var/log }\
. \
10 20 1 ext4 \
$lvmok{ } in_vg{ system } lv_name{ local }\
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /usr/local } \
. \
10 20 30 ext4 \
$lvmok{ } in_vg{ system } lv_name{ srv } \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /srv }\
.
* What was the outcome of this action?
Partitionning fails with the following message in syslog:
"partman-auto: Available disk space (2147) too small for expert recipe(3994);
skipping"
* What outcome did you expect instead?
Partitionning successfull, with LVM setup correctly.
The computed size should be /boot + swap + VG(system)
Bug#896825: libyami-utils: FTBFS with FFmpeg 4.0
Source: libyami-utils Version: 1.3.0-1 Severity: important User: debian-multime...@lists.debian.org Usertags: ffmpeg-4.0-transition Hi, Your package FTBFS with version 4.0 of FFmpeg. In FFmpeg 4.0, there are a number of API changes which have cause many packages to FTBFS. Incomplete list of changes (based on looking at common build failures): - Some fields in AVCodecContext have been removed and replaced with private options which can be set using the av_opt_set* APIs - Most CODEC_* constants have been renamed to AV_CODEC_* - The buffer constants FF_INPUT_BUFFER_PADDING_SIZE and FF_MIN_BUFFER_SIZE have been renamed to AV_INPUT_BUFFER_PADDING_SIZE and AV_INPUT_BUFFER_MIN_SIZE. - The old resampling API provided by libavcodec has been removed. Use libswresample instead. - The libavfilter/avfiltergraph.h header has been removed, include libavfilter/avfilter.h instead. - The AVFrac structure (representing mixed rational numbers) has been removed. Build log: https://people.debian.org/~jcowgill/ffmpeg-4.0-20180424/libyami-utils_amd64-2018-04-23T17:22:59Z.build Thanks, James signature.asc Description: OpenPGP digital signature
Bug#896822: sqitch: new upstream release 0.998 available
On Tue, 24 Apr 2018 18:38:21 +0300, Niko Tyni wrote: > Package: sqitch > Version: 0.9996-1 > Severity: wishlist > > I got a private request for packaging upstream version 0.9998. > > Filing this publicly. I'm happy if somebody else in the team wants to > handle it. 0.9997-1 prepared in git; I don't see 0.9998 on github or CPAN ?! I'll try and have another look later ... 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: Uriah Heep: Look At Yourself signature.asc Description: Digital Signature
Bug#896433: ifupdown: ifquery can't be called recursively from ifup/ifdown, but if-pre/up.d scripts call it
On Mon, Apr 23, 2018 at 05:18:53PM -0400, Dan Streetman wrote: > > The patch avoids locking at all when no_act == true. Consider this: > > > > iface foo inet ... > > pre-up ifquery --state bar > > > > iface bar inet ... > > > > Now if I call ifup foo and ifup bar at the same time, then the ifquery > > might theoretically read a half-written /run/network/ifstate.bar. > > Eh? > > ifquery --state doesn't use the ifstate.* files. It reads state from > the global ifstate file. Oh, you're absolutely right. It seems I mixed things up; ifquery --list and "plain" ifquery lock ifstate.* files, but ifquery --state indeed doesn't. And indeed, with --state we only look at the global ifstate file. And the other uses of ifquery only need to parse the interfaces file, so we shouldn't ever need to touch the ifstate.* files when running ifquery. But it's different for ifup and ifdown; even with --no-act we want to lock. So I've made a patch to only avoid locking for ifquery. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Bug#896823: aiscm: FTBFS with FFmpeg 4.0
Source: aiscm Version: 0.15.1-1 Severity: important User: debian-multime...@lists.debian.org Usertags: ffmpeg-4.0-transition Hi, Your package FTBFS with version 4.0 of FFmpeg. In FFmpeg 4.0, there are a number of API changes which have cause many packages to FTBFS. Incomplete list of changes (based on looking at common build failures): - Some fields in AVCodecContext have been removed and replaced with private options which can be set using the av_opt_set* APIs - Most CODEC_* constants have been renamed to AV_CODEC_* - The buffer constants FF_INPUT_BUFFER_PADDING_SIZE and FF_MIN_BUFFER_SIZE have been renamed to AV_INPUT_BUFFER_PADDING_SIZE and AV_INPUT_BUFFER_MIN_SIZE. - The old resampling API provided by libavcodec has been removed. Use libswresample instead. - The libavfilter/avfiltergraph.h header has been removed, include libavfilter/avfilter.h instead. - The AVFrac structure (representing mixed rational numbers) has been removed. Build log: https://people.debian.org/~jcowgill/ffmpeg-4.0-20180424/aiscm_amd64-2018-04-23T09:53:14Z.build Thanks, James signature.asc Description: OpenPGP digital signature
Bug#896824: ignition-common: FTBFS with FFmpeg 4.0
Source: ignition-common Version: 1.0.1-1 Severity: important User: debian-multime...@lists.debian.org Usertags: ffmpeg-4.0-transition Hi, Your package FTBFS with version 4.0 of FFmpeg. In FFmpeg 4.0, there are a number of API changes which have cause many packages to FTBFS. Incomplete list of changes (based on looking at common build failures): - Some fields in AVCodecContext have been removed and replaced with private options which can be set using the av_opt_set* APIs - Most CODEC_* constants have been renamed to AV_CODEC_* - The buffer constants FF_INPUT_BUFFER_PADDING_SIZE and FF_MIN_BUFFER_SIZE have been renamed to AV_INPUT_BUFFER_PADDING_SIZE and AV_INPUT_BUFFER_MIN_SIZE. - The old resampling API provided by libavcodec has been removed. Use libswresample instead. - The libavfilter/avfiltergraph.h header has been removed, include libavfilter/avfilter.h instead. - The AVFrac structure (representing mixed rational numbers) has been removed. Build log: https://people.debian.org/~jcowgill/ffmpeg-4.0-20180424/ignition-common_amd64-2018-04-23T16:45:23Z.build Thanks, James signature.asc Description: OpenPGP digital signature
Bug#888365: gazebo: FTBFS with FFmpeg 3.5
Control: reopen -1 9.0.0+dfsg5-4 Hi, On Fri, 23 Mar 2018 20:13:24 +0100 Jose Luis Rivero wrote: > Code in gazebo9 should be compatible with ffmpeg 4.0 Gazebo 9.0.0+dfsg5-4 FTBFS against ffmpeg 4.0 in another test rebuild I just ran. https://people.debian.org/~jcowgill/ffmpeg-4.0-20180424/gazebo_amd64-2018-04-23T16:03:04Z.build > /<>/gazebo-9.0.0+dfsg5/gazebo/common/AudioDecoder.cc: In member > function 'bool gazebo::common::AudioDecoder::SetFile(const string&)': > /<>/gazebo-9.0.0+dfsg5/gazebo/common/AudioDecoder.cc:258:35: error: > 'CODEC_CAP_TRUNCATED' was not declared in this scope >if (this->codec->capabilities & CODEC_CAP_TRUNCATED) >^~~ > /<>/gazebo-9.0.0+dfsg5/gazebo/common/AudioDecoder.cc:258:35: note: > suggested alternative: 'AV_CODEC_CAP_TRUNCATED' >if (this->codec->capabilities & CODEC_CAP_TRUNCATED) >^~~ >AV_CODEC_CAP_TRUNCATED > /<>/gazebo-9.0.0+dfsg5/gazebo/common/AudioDecoder.cc:259:30: error: > 'CODEC_FLAG_TRUNCATED' was not declared in this scope > this->codecCtx->flags |= CODEC_FLAG_TRUNCATED; > ^~~~ > /<>/gazebo-9.0.0+dfsg5/gazebo/common/AudioDecoder.cc:259:30: note: > suggested alternative: 'AV_CODEC_FLAG_TRUNCATED' > this->codecCtx->flags |= CODEC_FLAG_TRUNCATED; > ^~~~ > AV_CODEC_FLAG_TRUNCATED > make[3]: *** [gazebo/common/CMakeFiles/gazebo_common.dir/build.make:114: > gazebo/common/CMakeFiles/gazebo_common.dir/AudioDecoder.cc.o] Error 1 James signature.asc Description: OpenPGP digital signature
Bug#868609: le FTBFS with latest ncurses
X-Debbugs-CC: l...@netis.ru 在 2017年8月23日星期三 CST 下午10:27:46，您写道： > On 23 August 2017 at 14:56, Alexander V. Lukyanov wrote: > > On Fri, Aug 18, 2017 at 12:39:00PM +0200, Raphael Geissert wrote: > >> Do you plan to make a new release with the fixes? or should I grab the > >> patches from github? > > > > 1.16.5 has been released. > > Awesome, thanks. I'll take care of the upload. > > Cheers, Hi Raphael, I noticed that the new version of le with fix has been released for a while but no uploads have been made yet. Do you have spare time to fix this bug and upload a new version recently? Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part.
Bug#896822: sqitch: new upstream release 0.998 available
Package: sqitch Version: 0.9996-1 Severity: wishlist I got a private request for packaging upstream version 0.9998. Filing this publicly. I'm happy if somebody else in the team wants to handle it. -- Niko Tyni nt...@debian.org
Bug#895424: OCSIventory-Server maintenance in Debian
Le 24/04/2018 à 12:41, Jean-Michel wrote : > On Tuesday, 24 April 2018 06:45:03 CEST you wrote: >> Pierre Chiffier has request a RFA for ocsinventory-server. It is going >> to be taken under Pkg-Perl umbrella. >> You were mentioned as uploaders of this package and going to be removed >> except if you want to continue to maintain it. > > No problem. Go ahead. > > Sorry I have been able to help better on this one. > > Thank you! Thanks to you !
Bug#896821: O: libguess
Package: wnpp Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I intend to orphan the libguess package. The package description is: high-speed character set detection library . libguess employs discrete-finite automata to deduce the character set of the input buffer. The advantage of this is that all character sets can be checked in parallel, and quickly. - -- Cheers, and happy maintaining, Andrej -BEGIN PGP SIGNATURE- iQExBAEBCAAbBQJa30wBFBxhbmRyZXdzaEBkZWJpYW4ub3JnAAoJEF5AjNkc2DnS gqYH/RU3uQiMasKo7N/aTrgaGDRN8w0HTXpg/3xIcz3mqP0qYuTdV58o0rXsqPh/ o3LWJ3H4dAAoWPa6QWAuBqBF5i0Q3zlX9QNGwAgnnrpKazM1tFwwqarCi3urOKB5 Qq/Ihurr+gJwmbv0uP/ihYr8XKAJFOGbReDQ6/63WWzn8nAWgcHqwgJfmoZC6rfB BUZ9mPHHFVZ4V2ksTdzbFeeA+ynPQyQrObHUAYdGu18fkDcDK08audWiAF0fREgM ofVN71UYdVfRuPyQe8ote3XoKZRZUM9KtXeqsPY4WX+A16BZp9eqdEbVXDDk/nBV Vl4Q9LfxUpH3YXz6IfzXK6ROHvQ= =12wv -END PGP SIGNATURE-
Bug#747909: autopkgtest in docker on my pipeline.
Hi all ! Here [1] is a link where you can see the docker virt working on my pipeline. Hope you can consider adding it :) [1]_ https://salsa.debian.org/debian/doit/-/jobs/14389 -- - ina signature.asc Description: OpenPGP digital signature
Bug#896820: O: libmowgli-2
Package: wnpp Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I intend to orphan the libmowgli-2 package. The package description is: Mowgli is a development framework for C (like GLib), which provides high performance and highly flexible algorithms. It can be used as a supplement to GLib (to add additional functions (dictionaries, hashes), or replace some of the slow GLib list manipulation functions), or stand alone. It also provides a powerful hook system and convenient logging for your code, as well as high performance block allocator. - -- Cheers, and happy maintaining, Andrej -BEGIN PGP SIGNATURE- iQExBAEBCAAbBQJa30hwFBxhbmRyZXdzaEBkZWJpYW4ub3JnAAoJEF5AjNkc2DnS R74IAJxJ897QbEkBuo92GVWWuSNB4c1JuGiNl655HTIWVGLMq1NhOImC7yGzzHnn 8qww/mABhV5W1YVqRbSUFK4nVwDImvx5pPZOg5381nvUuUGYZhJiiklbT7uhh1mJ pE57pUb1SG2XSnk4n3E9Q9t+zDyYymN6NnDvzbcQV3LQuHIsYNrq8lF/EXYrO/JZ YEtK1NPsR38Tp9IdPkw5kBKnvsVVCqklaTCjhaNpm93xZQ+4OGtVEXt4M8/AuIpe 53kEmAfC2Q8/2FNZifpDCrLT5vuFdGvoFELDZEoWCcsmqX6h8aKBQZJpjARN6Shb COyelLkBIHK7G9rbdShtPzPk/vQ= =W+1v -END PGP SIGNATURE-
