Bug#918037: Manpage of ntfsinfo is pretty spartan and doesn't give any details

[Jean-Pierre André]

> Now I have been trying to figure out what each of the statements
> mean but have come up naught.

These are the parameters which define the layout of the data
in the ntfs partition. Most of them are meaningless to the end
user.

> For instance what does Device state: 11 mean or what does Volume
> State: 91 mean ?

Only the Microsoft developers know. These may depend on the
operating system and its state, or be obsolete. They are never
used or updated by ntfs-3g.

> It is and was a pre-formatted hdd AFAIK/remember.
>
> inxi shares the following info. -
>
> info: Seagate RSS LLC type: Mass Storage driver: uas interfaces: 1 
rev: 2.1

>speed: 480 Mb/s chip ID: 0bc2:ab24
>
> The last one is probably the hdd controller details if that gives
> any more info.
>
> It doesn't give any info. on the state of the hdd :( or if it does
> I am not able to make sense of it.

You did not tell what you were searching for. If you want the state
of the hdd, you probably need "smartctl", ntfsinfo is about a partition
and files, not the whole disk.

Bug#918090: theano: C-optimized ops fail with "module 'numpy.core.multiarray' has no attribute '_get_ndarray_c_version'"

[Rebecca N. Palmer]

Source: theano
Version: 1.0.2+dfsg-1
Severity: serious
Control: tags -1 patch

Many Theano operations include C code for speed; the compilation process 
uses an undocumented Numpy function to check ABI compatibility.


In Numpy 1.16 (recently added to sid), this function is moved, causing 
all compiles to fail: 
https://ci.debian.net/data/packages/unstable/amd64/t/theano/latest-autopkgtest/log.gz


Fix:

--- a/theano/theano/gof/cc.py
+++ b/theano/theano/gof/cc.py
@@ -1375,12 +1375,8 @@

 # We must always add the numpy ABI version here as
 # DynamicModule always add the include 
-if np.lib.NumpyVersion(np.__version__)<'1.16.0a':
-ndarray_c_version = np.core.multiarray._get_ndarray_c_version()
-else:
-ndarray_c_version = 
np.core._multiarray_umath._get_ndarray_c_version()

 sig.append('NPY_ABI_VERSION=0x%X' %
-   ndarray_c_version)
+   np.core.multiarray._get_ndarray_c_version())
 if c_compiler:
 sig.append('c_compiler_str=' + c_compiler.version_str())

Bug#918089: wireshark: d/copyright does not mention SAMBA's Pidl parser

[Andrius Merkys]

Source: wireshark

Hello,

wireshark source package contains embedded copy of SAMBA's Pidl parser under 
tools/pidl/, which is not mentioned in d/copyright. As Pidl parser does not 
seem to be used in wireshark at all, it is possibly better to exclude it from 
the source. Otherwise libparse-pidl-perl binary package could be used.

Best wishes,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Bug#917001: MR

[Sébastien Delafond]

Here is the corresponding MR:

  https://salsa.debian.org/python-team/modules/python-twilio/merge_requests/1

Cheers,

-- 
Seb

Bug#915765: MR

[Sébastien Delafond]

Here is the corresponding MR:

  
https://salsa.debian.org/python-team/modules/pystaticconfiguration/merge_requests/1

Cheers,

-- 
Seb

Bug#610839: [StinsonHub Feedback] Hei?e Frauen fur Sex in deiner Stadt

[feedback]

Thank you for your email.
Your questions and comments are important to us.
We will respond shortly.

Bug#918088: autofs-ldap: automount dies with SIGABRT after libkrb5-3 upgrade - "(k5_mutex_lock: Assertion `r == 0' failed.)"

[Andreas Maus]

Package: autofs-ldap
Version: 5.1.2-4
Severity: grave
Justification: renders package unusable

Good morning.

After the latest upgrade of libkrb5-3 (1.16.1-1 -> 1.16.2-1) automount
starts but dies immediately after accessing a automounter point.

Automount is configured to authenticate via GSSAPI using system keytab.
After the GSSAPI authentication succeeded, any access to a configure
automount entry causes automount to die with an assertion failure
(followed by an abort()):

root@dagon:~# /usr/sbin/automount -d -f 
Starting automounter version 5.1.2, master map /etc/auto.master
using kernel protocol version 5.03
lookup_nss_read_master: reading master file /etc/auto.master
do_init: parse(sun): init gathered global options: (null)
lookup_read_master: lookup(file): read entry /home
master_do_mount: mounting /home
automount_path_to_fifo: fifo name /var/run/autofs.fifo-home
lookup_nss_read_map: reading map ldap 
ldap:automountmapname=auto.home,cn=badphish,cn=automount,dc=badphish,dc=ypbind,dc=de
parse_server_string: lookup(ldap): Attempting to parse LDAP information from 
string 
"ldap:automountmapname=auto.home,cn=badphish,cn=automount,dc=badphish,dc=ypbind,dc=de".
parse_server_string: lookup(ldap): server "(default)", base dn 
"automountmapname=auto.home,cn=badphish,cn=automount,dc=badphish,dc=ypbind,dc=de"
parse_ldap_config: lookup(ldap): ldap authentication configured with the 
following options:
parse_ldap_config: lookup(ldap): use_tls: 1, tls_required: 0, auth_required: 2, 
sasl_mech: GSSAPI
parse_ldap_config: lookup(ldap): user: (null), secret: unspecified, client 
principal: host/dagon.badphish.ypbind...@badphish.ypbind.de credential cache: 
(null)
do_init: parse(sun): init gathered global options: rw,hard,intr,nosuid
find_server: trying server uri ldap://ipa-1.badphish.ypbind.de
do_bind: lookup(ldap): auth_required: 2, sasl_mech GSSAPI
sasl_do_kinit: initializing kerberos ticket: client principal 
host/dagon.badphish.ypbind...@badphish.ypbind.de
sasl_do_kinit: calling krb5_parse_name on client principal 
host/dagon.badphish.ypbind...@badphish.ypbind.de
sasl_do_kinit: Using tgs name krbtgt/badphish.ypbind...@badphish.ypbind.de
sasl_do_kinit: Kerberos authentication was successful!
sasl_bind_mech: Attempting sasl bind with mechanism GSSAPI
sasl_log_func: GSSAPI client step 1
getuser_func: called with context (nil), id 16385.
sasl_log_func: GSSAPI client step 1
getuser_func: called with context (nil), id 16385.
sasl_log_func: GSSAPI client step 2
sasl_bind_mech: sasl bind with mechanism GSSAPI succeeded
do_bind: lookup(ldap): autofs_sasl_bind returned 0
get_query_dn: lookup(ldap): found query dn 
automountmapname=auto.home,cn=badphish,cn=automount,dc=badphish,dc=ypbind,dc=de
connected to uri ldap://ipa-1.badphish.ypbind.de
read_one_map: lookup(ldap): searching for "(objectclass=automount)" under 
"automountmapname=auto.home,cn=badphish,cn=automount,dc=badphish,dc=ypbind,dc=de"
do_get_entries: lookup(ldap): examining entries
do_get_entries: lookup(ldap): failed to get next entry for query 
(objectclass=automount)
read_one_map: lookup(ldap): done updating map
remount_active_mount: trying to re-connect to mount /home
mounted indirect on /home with timeout 300, freq 75 seconds
remount_active_mount: re-connected to mount /home
st_ready: st_ready(): state = 0 path /home
ghosting enabled
handle_packet: type = 3
handle_packet_missing_indirect: token 3, name maus, request pid 6541
attempting to mount entry /home/maus
lookup_mount: lookup(ldap): looking up maus
do_bind: lookup(ldap): auth_required: 2, sasl_mech GSSAPI
sasl_bind_mech: Attempting sasl bind with mechanism GSSAPI
sasl_log_func: GSSAPI client step 1
getuser_func: called with context (nil), id 16385.
k5_mutex_lock: Received error 22 (Invalid argument)
automount: ../../../../src/include/k5-thread.h:376: k5_mutex_lock: Assertion `r 
== 0' failed.
Aborted (core dumped)

Backtrace of the core dump:

root@dagon:~# gdb /usr/sbin/automount /core
GNU gdb (Debian 8.2-1) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/automount...(no debugging symbols found)...done.
[New LWP 6542]
[New LWP 6521]
[New LWP 6522]
[New LWP 6523]
[New LWP 6526]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by 

Bug#918086: gitlab: CVE-2018-20488 CVE-2018-20489 CVE-2018-20490 CVE-2018-20491 CVE-2018-20492 CVE-2018-20493 CVE-2018-20494 CVE-2018-20495 CVE-2018-20496 CVE-2018-20497 CVE-2018-20498 CVE-2018-20499

[Salvatore Bonaccorso]

Source: gitlab
Version: 11.5.5+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
Control: found -1 11.6.0+dfsg-1

Hi,

The following vulnerabilities were published for gitlab, fixed in the
11.6.1, 11.5.6, and 11.4.13 versions, cf [15].

CVE-2018-20488[0]:
Secret CI variable exposure

CVE-2018-20489[1]:
URL rel attribute not set

CVE-2018-20490[2]:
Persistent XSS Autocompletion

CVE-2018-20491[3]:
Persistent XSS wiki in IE browser

CVE-2018-20492[4]:
Todos improper access control

CVE-2018-20493[5]:
Source code disclosure merge request diff

CVE-2018-20494[6]:
Guest user CI job disclosure

CVE-2018-20495[7]:
CI job token LFS error message disclosure

CVE-2018-20496[8]:
Persistent XSS label reference

CVE-2018-20497[9]:
SSRF repository mirroring

CVE-2018-20498[10]:
Improper access control branches and tags

CVE-2018-20499[11]:
SSRF in project imports with LFS

CVE-2018-20500[12]:
Improper access control CI/CD settings

CVE-2018-20501[13]:
Missing authorization control merge requests

CVE-2018-20507[14]:
Missing authentication for Prometheus alert endpoint

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-20488
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20488
[1] https://security-tracker.debian.org/tracker/CVE-2018-20489
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20489
[2] https://security-tracker.debian.org/tracker/CVE-2018-20490
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20490
[3] https://security-tracker.debian.org/tracker/CVE-2018-20491
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20491
[4] https://security-tracker.debian.org/tracker/CVE-2018-20492
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20492
[5] https://security-tracker.debian.org/tracker/CVE-2018-20493
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20493
[6] https://security-tracker.debian.org/tracker/CVE-2018-20494
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20494
[7] https://security-tracker.debian.org/tracker/CVE-2018-20495
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20495
[8] https://security-tracker.debian.org/tracker/CVE-2018-20496
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20496
[9] https://security-tracker.debian.org/tracker/CVE-2018-20497
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20497
[10] https://security-tracker.debian.org/tracker/CVE-2018-20498
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20498
[11] https://security-tracker.debian.org/tracker/CVE-2018-20499
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20499
[12] https://security-tracker.debian.org/tracker/CVE-2018-20500
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20500
[13] https://security-tracker.debian.org/tracker/CVE-2018-20501
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20501
[14] https://security-tracker.debian.org/tracker/CVE-2018-20507
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20507
[15] 
https://about.gitlab.com/2018/12/31/security-release-gitlab-11-dot-6-dot-1-released/
  

Regards,
Salvatore

Bug#918085: kmymoney: recompile against latest qt 5-11-3 ABI

[Achim Schaefer]

Package: kmymoney
Version: 5.0.2-1
Severity: normal

Dear Maintainer,

please recompile again the latest QT ABI, , as QT 5.11.3 is migrating already 
to testing.

Thanks

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

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

Versions of packages kmymoney depends on:
ii  kio   5.51.0-1
ii  kmymoney-common   5.0.2-1
ii  libalkimia5-7 7.0.1-1
ii  libaqbanking355.7.8-3
ii  libaqbanking35-plugins5.7.8-3
ii  libc6 2.28-4
ii  libgcc1   1:8.2.0-13
ii  libgmp10  2:6.1.2+dfsg-4
ii  libgpgmepp6   1.12.0-4
ii  libgwengui-cpp0   4.20.0-7
ii  libgwengui-qt5-0  4.20.0-7
ii  libgwenhywfar60   4.20.0-7
ii  libical3  3.0.4-1+b1
ii  libkchart22.6.1-1
ii  libkf5activities5 5.51.0-2
ii  libkf5akonadicore5abi24:18.08.1-1+b2
ii  libkf5archive55.51.0-1
ii  libkf5codecs5 5.51.0-1
ii  libkf5completion5 5.51.0-1
ii  libkf5configcore5 5.51.0-1
ii  libkf5configgui5  5.51.0-1
ii  libkf5configwidgets5  5.51.0-1
ii  libkf5contacts5   4:18.08.1-1
ii  libkf5coreaddons5 5.51.0-1
ii  libkf5holidays5   1:5.51.0-1
ii  libkf5i18n5   5.51.0-1
ii  libkf5identitymanagement5 18.08.1-1
ii  libkf5itemmodels5 5.51.0-1
ii  libkf5itemviews5  5.51.0-1
ii  libkf5jobwidgets5 5.51.0-1
ii  libkf5kcmutils5   5.51.0-1
ii  libkf5kiocore55.51.0-1
ii  libkf5kiofilewidgets5 5.51.0-1
ii  libkf5kiogui5 5.51.0-1
ii  libkf5kiowidgets5 5.51.0-1
ii  libkf5notifications5  5.51.0-1
ii  libkf5service-bin 5.51.0-1
ii  libkf5service55.51.0-1
ii  libkf5sonnetui5   5.51.0-1+b1
ii  libkf5textwidgets55.51.0-1
ii  libkf5wallet-bin  5.51.0-1
ii  libkf5wallet5 5.51.0-1
ii  libkf5webkit5 5.51.0-1
ii  libkf5widgetsaddons5  5.51.0-1
hi  libkf5xmlgui5 5.51.0-1
ii  libofx7   1:0.9.13-2
ii  libpython2.7  2.7.15-5
hi  libqt5core5a [qtbase-abi-5-11-2]  5.11.2+dfsg-7
hi  libqt5dbus5   5.11.2+dfsg-7
hi  libqt5gui55.11.2+dfsg-7
hi  libqt5network55.11.2+dfsg-7
hi  libqt5printsupport5   5.11.2+dfsg-7
hi  libqt5quickwidgets5   5.11.2-3
hi  libqt5sql55.11.2+dfsg-7
hi  libqt5webkit5 5.212.0~alpha2-17+b1
hi  libqt5widgets55.11.2+dfsg-7
hi  libqt5xml55.11.2+dfsg-7
ii  libsqlcipher0 3.4.1-1+b1
ii  libstdc++68.2.0-13

Versions of packages kmymoney recommends:
ii  gnupg-agent 2.2.12-1
ii  gpg-agent [gnupg-agent] 2.2.12-1
ii  pinentry-gnome3 [pinentry-x11]  1.1.0-1+b1
ii  pinentry-gtk2 [pinentry-x11]1.1.0-1+b1
ii  pinentry-qt [pinentry-x11]  1.1.0-1+b1

Versions of packages kmymoney suggests:
ii  kcalc  4:18.04.1-1

-- no debconf information

Bug#916447: Please copy win32-loader/0.9.3 from unstable to testing

[Didier 'OdyX' Raboud]

Control: retitle -1 Tools: Please copy win32-loader/0.9.3 from unstable to 
testing

Le vendredi, 14 décembre 2018, 16.21:15 h CET Didier 'OdyX' Raboud a écrit :
> win32-loader 0.9.2 migrated automatically, but its byhand counterpart
>   ./debian/tools/win32-loader/testing/*
> … is still 0.8.4.
> 
> Please copy debian/tools/win32-loader/unstable into …/testing

Cheers,
OdyX

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

Bug#918084: zita-lrx FTCBFS: upstream Makefile hard codes the wrong compiler

[Helmut Grohne]

Source: zita-lrx
Version: 0.1.0-3
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

zita-lrx fails to cross build from source, because the upstream Makefile
hard codes the build architecture compiler "g++". After making it
substitutable, dh_auto_build's substitution is used and zita-lrx becomes
cross buildable. Please consider applying the attached patch.

Helmut
--- zita-lrx-0.1.0.orig/source/Makefile
+++ zita-lrx-0.1.0/source/Makefile
@@ -35,7 +35,7 @@
 
 zita-lrx:	LDLIBS += -lclthreads -lpthread -ljack -lrt
 zita-lrx:	$(ZITA-LRX_O)
-	g++ $(LDFLAGS) -o $@ $(ZITA-LRX_O) $(LDLIBS)
+	$(CXX) $(LDFLAGS) -o $@ $(ZITA-LRX_O) $(LDLIBS)
 $(ZITA-LRX_O):
 -include $(ZITA-LRX_O:%.o=%.d)
 

Bug#918083: cutesdr FTCBFS: does not pass cross flags to cmake

[Helmut Grohne]

Source: cutesdr
Version: 1.20-2
Severity: serious
Justification: policy 4.6
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

cutesdr fails to cross build from source, because its builds two cmake
projects (one via dh_auto_foo and then the siqs directory explicitly in
override_dh_auto_install) and the latter invocation lacks cross flags.
The easiest way of fixing that is using dh_auto_configure. Doing so is
sufficient to make cutesdr cross buildable. Please consider applying the
attached patch.

I also noticed that cutesdr chains build commands with ";". Doing so is
prohibited by Debian policy section 4.6, thus satisfying serious
severity. My patch fixes this issue as well. Please lower the severity
of this bug if you fix the policy violation independently, but I think
it would be least effort to simply use the patch thus filing only one
bug.

Helmut
diff --minimal -Nru cutesdr-1.20/debian/changelog cutesdr-1.20/debian/changelog
--- cutesdr-1.20/debian/changelog   2018-08-29 06:18:15.0 +0200
+++ cutesdr-1.20/debian/changelog   2019-01-02 22:07:05.0 +0100
@@ -1,3 +1,11 @@
+cutesdr (1.20-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass cross flags to cmake. (Closes: #-1)
+  * Propagate errors from cmake (policy 4.6).
+
+ -- Helmut Grohne   Wed, 02 Jan 2019 22:07:05 +0100
+
 cutesdr (1.20-2) unstable; urgency=medium
 
   * update to svn r75, builds with qt5.11. (Closes:#907226)
diff --minimal -Nru cutesdr-1.20/debian/rules cutesdr-1.20/debian/rules
--- cutesdr-1.20/debian/rules   2018-05-23 05:01:12.0 +0200
+++ cutesdr-1.20/debian/rules   2019-01-02 22:07:05.0 +0100
@@ -8,7 +8,8 @@
 override_dh_auto_install:
dh_auto_install
mkdir siqsbuild
-   (cd siqsbuild ; cmake ../siqs ; make)
+   dh_auto_configure --builddirectory=siqsbuild --sourcedirectory=siqs
+   dh_auto_build --builddirectory=siqsbuild
cp siqsbuild/siqs_ftdi debian/cutesdr/usr/bin/siqs_ftdi
rm -rf siqsbuild
cp CuteSdr debian/cutesdr/usr/bin/CuteSdr

Bug#916012: emacs-gtk crashes when rendering U+2728 SPARKLES

[Rob Browning]

Daniel Kahn Gillmor  writes:

> Indeed, when i "apt purge fonts-noto-color-emoji" i also stop having a
> crash with emacs-gtk when rendering certain high-plane Unicode
> characters (they render as unintelligible boxes instead, of course, but
> that's better than crashing i guess.  thanks for finding that workaround!
>
> so, how do we fix it?

No idea yet -- I imagine the next step is to see if we can come up with
an even simpler way to reproduce it, and either way, report it upstream.
I'll plan to do that when I have some time.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#918030: please provide DEB_HOST_UNAME_MACHINE

[Helmut Grohne]

Hi Jonathan,

On Wed, Jan 02, 2019 at 05:49:48PM -0800, Jonathan Nieder wrote:
> Interesting.  Can you give an example of a package that would benefit
> from this?

https://sources.debian.org/src/klibc/2.0.4-14/Makefile/?hl=33#L33
https://sources.debian.org/src/lm-sensors/1:3.5.0-3/Makefile/?hl=80#L80
https://sources.debian.org/src/libselinux/2.8-1/src/Makefile/?hl=111#L111
https://sources.debian.org/src/dmidecode/3.2-1/Makefile/?hl=46#L46
https://sources.debian.org/src/glew/2.1.0-3/config/Makefile.linux/?hl=4#L4

You'll find lots with:

https://codesearch.debian.net/search?q=uname+-m+path%3Aakefile

Here is an implemented mapping, that could likely go away:
https://sources.debian.org/src/tbb/2018%7EU6-4/debian/rules/?hl=33#L27

Still that was a useful question. I should have included these links in
my initial submission. Thank you.

Helmut

Bug#918082: sjfonts: new upstream release (2.1)

[Paul Wise]

Source: sjfonts
Severity: wishlist

Upstream made a new release (2.1) in time for the buster freeze:

https://tsdgeos.blogspot.com/2019/01/sjfonts-21-released.html
https://sourceforge.net/projects/sjfonts/files/sjfonts/sjfonts-2.1/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#917848: closed by Don Armstrong (Bug#917848: fixed in autorandr 1.7-1)

[Rob Browning]

"Debian Bug Tracking System"  writes:

> This is an automatic notification regarding your Bug report
> which was filed against the autorandr package:
>
> #917848: autorandr: bottom of rotated display cut off
>
> It has been closed by Don Armstrong .

Nice -- thanks.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#917319: libdovecot: Segfault -- service(dict) killed with signal 11

[Christian Schrötter]

Patch possibly already available:
https://github.com/dovecot/core/commit/aa5c05ebd5e2a2474514020d2114602bcb2f1157.patch

Not tested yet, but it looks like the right commit...

Bug#916012: emacs-gtk crashes when rendering U+2728 SPARKLES

[Daniel Kahn Gillmor]

On Wed 2019-01-02 19:40:43 -0600, Rob Browning wrote:
> Daniel Kahn Gillmor  writes:
>
>> Control: found 916012 1:26.1+1-2
>>
>> running emacs-gtk 26.1 from unstable, I still get crashes on U+2728
>> SPARKLES .  I'm also seeing a crash when trying to render U+26C4 SNOWMAN
>> WITHOUT SNOW.
>
> So I just hit a random crash when trying to look at my INBOX in
> notmuch.  Searching for the error turned up this:
>
>   
> https://askubuntu.com/questions/1076735/emacs-crashes-on-pasting-the-unicode-symbol
>
> And indeed, purging fonts-noto-color-emoji "fixed" the problem.  I
> wonder if it's at all related...

Indeed, when i "apt purge fonts-noto-color-emoji" i also stop having a
crash with emacs-gtk when rendering certain high-plane Unicode
characters (they render as unintelligible boxes instead, of course, but
that's better than crashing i guess.  thanks for finding that workaround!

so, how do we fix it?

--dkg


signature.asc
Description: PGP signature

Bug#909479: sogo: All resources are not found (404)

[James Andrewartha]

Hi Vincent,

What is /usr/lib/GNUstep/SOGo/WebServerResources - is it a directory (empty?) 
or a symlink to ../../../share/GNUstep/SOGo/WebServerResources

I somehow ended up with it being an empty directory, but in the package it is a 
symlink and making it so again fixed the problem.

Thanks,

--
# TRS-80  trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \
# UCC Wheel Member http://trs80.ucc.asn.au/ #|  what squirrels do best |
[ "There's nobody getting rich writing  ]|  -- Collect and hide your   |
[  software that I know of" -- Bill Gates, 1980 ]\  nuts." -- Acid Reflux #231 /

Bug#913567: python-numpy: Why depend on libatlas3-base?

[Thorsten Glaser]

Hi Sandro,

>provided by ATLAS; is this causing any problem?

yes: ATLAS does not work on all architectures (see #918076
for an example) and is generally harder to port.

I’ve seen you will upload a new version that works without,
but I wanted to still contribute this data point, so you
see that porters will also appreciate it ;-)

bye,
//mirabilos

PS: When adding pypy, please remember that also it is not
portable and will need an architecture whitelist. Thanks!
-- 
> emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig
> bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;)
Hallo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
... pine-User, und das auch noch gewohnheitsmäßig ("Oooohhh").  [aus dasr]

Bug#917566: lintian: please warn about non-supported previous versions

[Dmitry Bogatov]

[2018-12-30 23:09] Chris Lamb 
> > > > As of implementation side, given that Lintian by design do not use
> > > > network, it is possible to assume that Debian release happens once a 2.5
> > > > year (or so), so versions older then 5.5 years (possible to lookup in
> > > > d/changelog) are below threhold.
> > > 
> > > Alas, unless we can think of a more-reliable way of doing this I fear this
> > > will be far too full of false-positives or will simply not detect enough
> > > cases to be prioritised. :(
> > 
> > Well, we could hardcode dates of Debian releases in Lintian.
> 
> This is the easy part. The difficult parts I was referring to are:
> 
>   a) The dates in the debian/changelog file cannot "know" that that
>  was the version in a stable release.

Probably I missing something oblivious, but still: if you know that
version X is latest, such as

date(X) < date(oldstable)

then all versions X' < X are too old, upgrade from them is not
supported.

>   b) The parsing of the maintainer scripts is going to be very messy
>  and error prone.

Again, maybe I miss something, but I believe this is as simple, as two
grep(1), like following:

for v in ${too_old_versions} ; do
if grep -v '#' $maintscript | grep -F "$v" ; then
echo "bad, bad"
fi
done

I got inspiration for this check during work on sysvinit, which keeps
checking upgrades from 10-years old versions.

But issue is not sysvinit-specific. I have number of packages, that have
code in maintainer scripts, that deals with upgrades from specific
versions. And in 5 years, this code should be removed. But I doubt I
will remember it then.

Bug#917418: nbsphinx no more support Python 2

[Thorsten Glaser]

Hi,

>My understanding is that sphinx no more support Python as well
>(this is the excuse from the uptream maintainer):

hm, perhaps upstream. In Debian, the consensus was to keep
Python 2 working for old things until some time after the
release AIUI.

>if sphinx still supports Python 2 in Buster,
>then it makes sense to make nbsphin supporting Python 2 in Buster.

OK. Perhaps it’s not too much effort, and then, after the
unfreeze, things can get de-python2-ised in a controlled
way (reversely down the dependency tree from leaf packages
down to libraries).

I didn’t check to see how often it’s still used in Depends
or B-D (UDD might know), but perhaps just before the freeze
is a bit tight to introduce deep changes, especially as, in
my experience, not all upstreams are fast enough to adopt.

>Ok, I will have a look this week end.

Thanks!

bye,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

Bug#917854: RFS: pygithub/1.43.3-1

[Dmitry Bogatov]

As other folks already mentioned, you do not use CC: you already use
X-Debbugs-CC. In this particular case, email with bug number got
filtered-out as duplicate in my setup.

[2018-12-31 00:16] eamanu15 
> I am looking for a sponsor for my package "pygithub"
> 
> * Package name: pygithub
> Version : 1.43.3-1
> Upstream Author : Adam Dangoor 
>   Vincent Jacques 
>   Jeremy Phelps 
> * URL : https://pypi.python.org/pypi/PyGithub
> * License : LGPL-3+
>   Section : python
> 
> It builds those binary packages:
> 
> python-github - Access to full Github API v3 from Python2
> python3-github - Access the full Github API v3 from Python3

Looks fine, but I do not understand following line in `debian/rules':

rm -rfv debian/python3-github/usr/lib/python3.*

What is removed and why same statement it is not needed for python2
version?  Comment in `debian/rules' would be nice.

And some very minor suggestions:

 * Standards-Version slightly outdated
 * debhelper-compat style reduces redundancy
 * Probably F-variables could be used to avoid repetition in
   binary package descriptions? (See dpkg-substvars(5))

I do not know habits of Python Modules Team, but would not it be more
apporiate for this packages to be sponsored by DD from team? I can check
basic things, but I do not know whole picture, like transitions or
reverse dependencies.

PS. I am glad to see that pygithub finally moved under aegis of
Python Modules Team.

Bug#917624: RFS: ncurses-hexedit/0.9.7+orig-6

[Dmitry Bogatov]

[2018-12-31 09:20] Carlos Maddela 
> > [ Dmitry Bogatov ]
> > Looks fine. Uploaded. But what does +orig means in version?
> > 
> 
> When I took over as maintainer, I wanted to know why the project's
> original tarball in Debian differed from that of the one available
> upstream. I found that they only differed in the way that the top level
> directory was named. From what I gather, this was necessary for Debian's
> earlier build system, as documented here:
> https://wiki.debian.org/Packaging/Intro. See Q for "do we need to
> repack the original tarball if it doesn't contains a properly named
> foo-1.0 folder?" Since, it's no longer necessary to repack the original
> tarball, I thought it would be best to revert to using the original
> upstream tarball without any changes. However, the only way I could do
> so was to upload it with a higher version number, hence the +orig. If in
> the unlikely event that a new upstream version were to be released, the
> +orig can be dropped once again.

I see. Thank you. May I suggest you to put this wonderful explanation into
`debian/README.source'. It may save trouble for future maintainer or
save you from questions from another sponsor :)

Bug#916230: Log rotation issue with runit

[Dmitry Bogatov]

control: tags -1 +moreinfo +unreproducible

[2018-12-31 11:20] Lorenz 
> Hi, sorry for the late response.
> 
> > Can you reproduce this issue with regular usage of runit
> 
> Unfortunately I am not able to reproduce systematically. I'm still trying to
> understand what causes the creation of those .u files  ( i don't do kill on
> runsv),
> but this is not easy and also will not be quick.
> I read the discussion on Supervision mailing list, I understand the
> rationale behind the creation of those .u files and i'm fine with it.
> I'm available to provide more details on Supervision list, if there is some
> interest to dig this issue there, otherwise i will try by myself.
> Feel free to put on hold or close this bug, i will reopen if I can
> find a exact sequence to reproduce with regular use.

Let it hang around for a while. I usually close bugs in 6-12 month, if
there is nobody, who can reproduce them.

Bug#833116: fgetty: Incorrect keystroke interpretation

[Dmitry Bogatov]

[2018-12-31 13:46] Ricardo Peliquero 
> >  * setenv("LANG", "C.UTF-8", 1)
> 
> It works as a breeze.
> Able to type 'ñandú' and other stuff with LANG=C.UTF-8.
> I can always put LANG=es_AR.UTF-8 and LANGUAGE=es_AR:es into .rcrc in
> order to fit my local needs, and it still works perfectly well.

Great. Seems we found solution. Let us make it minimal. I believe
of three places, changed in previous patch, only one is truly required.

Please try patch in this mail (at bootom).

> >  * setenv("LC_ALL", "C.UTF-8", 1)
> 
> It works, but LC_ALL variable might not be neccessary here. I'll of
> course respect your choice.

Of course, I agree that LC_ALL is big hammer here, that will overrule
user preferences, which is not apporiate.

> Thank you very much, and happy new year!

Thank you. It is pleasure to work with you.

From 200b7d217ee3ac54b376116e7d64ce0844ecbed9 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Tue, 1 Jan 2019 22:52:18 +
Subject: [PATCH] Fix #833116

---
 login2.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/login2.c b/login2.c
index 8aaf6d6..156105b 100644
--- a/login2.c
+++ b/login2.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -61,6 +62,8 @@ main(int argc,char *argv[]) {
   char *shell=getenv("SHELL");
   char *Argv[]={"-sh",0};
   char *login=getenv("USER");
+
+  setenv("LANG", "C.UTF-8", 1);
   if (getuid()==0) {   /* checkpassword honored "nosetuid" */
 char *tmp=getenv("UID");
 char *tty=getenv("TTY");

Bug#692559: RAMTMP is missing too

[Dmitry Bogatov]

control: tags -1 +confirmed

[2018-12-31 08:54] Thorsten Glaser 
> On Sat, 29 Dec 2018, Dmitry Bogatov wrote:
> 
> > Regarding RAMTMP, I am not sure whether it is actually useful. Really,
> > if you want /tmp in tmpfs, just add entry into /etc/fstab. There
> > should be one, and only one oblivious way to do it.
> 
> Normally, yes, but it’s there now, so please don’t remove it,
> that would change existing systems to the worse.
> 
> I had been using the variable because the verbiage in the
> /etc/default/* files indicated that it was “the Debian way”
> now to do things like mounting /tmp there.

No, no, I do not plan to remove it. Probably, at least comment in
/etc/default/tmpfs regarding it should be added.

Bug#918081: /usr/bin/nm-applet: Cellular icon overlap in xfce4 notification tray

[Minh Duc Vo]

Package: network-manager-gnome
Version: 1.8.18-2
Severity: minor
File: /usr/bin/nm-applet
Tags: patch

The icon of nm-applet when mobile broadband connection is used are overlapped
with other icons, rendering a look-like-faulted indicator.



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

Kernel: Linux 4.19.0-12.3-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.12-1
ii  dbus-x11 [dbus-session-bus]   1.12.12-1
ii  dconf-gsettings-backend [gsettings-backend]   0.30.1-2
ii  libatk1.0-0   2.30.0-2
ii  libayatana-appindicator3-10.5.3-4
ii  libc6 2.28-3
ii  libcairo2 1.16.0-2
ii  libgdk-pixbuf2.0-02.38.0+dfsg-7
ii  libglib2.0-0  2.58.1-2
ii  libgtk-3-03.24.2-3
ii  libjansson4   2.12-1
ii  libmm-glib0   1.8.2-1
ii  libnm01.14.4-4
ii  libnma0   1.8.18-2
ii  libnotify40.7.7-4
ii  libpango-1.0-01.42.4-6
ii  libpangocairo-1.0-0   1.42.4-6
ii  libsecret-1-0 0.18.6-4
ii  libselinux1   2.8-1+b1
ii  network-manager   1.14.4-4
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7

Versions of packages network-manager-gnome recommends:
ii  dunst [notification-daemon]  1.3.2-1
ii  gnome-keyring3.28.2-2
ii  iso-codes4.1-1
ii  mobile-broadband-provider-info   20170903-1
ii  notification-daemon  3.20.0-4
ii  xfce4-notifyd [notification-daemon]  0.4.3-1

Versions of packages network-manager-gnome suggests:
pn  network-manager-openconnect-gnome  
ii  network-manager-openvpn-gnome  1.8.8-2
pn  network-manager-pptp-gnome 
pn  network-manager-vpnc-gnome 

-- no debconf information

Bug#917206: linux-image-4.9.0-8-amd64: NULL ptr dereference in xhci_hub_control [xhci_hcd] with USB Mass Storage (Kingston)

[Cyril Brulebois]

Hi Christoph,

Christoph Pfister  (2019-01-02):
> tl;dr: This is a regression introduced in Debian 9.6
> (linux/4.9.130-2); it is caused by [1] and fixed by [2]. Please fix :)
> 
> I'm taking the liberty to hijack this bug because I'm experiencing the
> same issue [3] when powering off a usb3 hdd. The oops is easy to
> reproduce; I've tested the following versions of
> linux-image-4.9.0-8-amd64:
> 
> - 4.9.110-3+deb9u6: works
> - 4.9.130-2 (current stretch): affected
> - 4.9.135-1 (stretch-proposed-updates): affected
> - 4.9.130-2 + manually applying [2]: works

No worries (from my point of view) with hijacking the bug report, esp.
with all the nice pointers! Thanks for tracking that down. :)


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


signature.asc
Description: PGP signature

Bug#917418: nbsphinx no more support Python 2

[Jerome BENOIT]

Hello,

On 03/01/2019 07:20, Thorsten Glaser wrote:
> Hi Jerome,
> 
>> The issue was resolved in package 0.4.1+ds-2.
> 
> you “resolved” it by no longer building the binary package.
> 
> However, there are packages still (build-)depending on it,
> which you might wish to inform: see #918079 for an example,
> 
> You might also with to file an RM (RoM) bug with ftpmasters
> so that they remove the stray binary package from the archive;
> the current situation has it still available, making quinn-diff
> believe that its r-build-depends are installable, whereas the
> package fails to configure. This is bad.
> 
> If not all users can switch to python3-nbsphinx in time for
> the release, it might make sense to package python-nbsphinx
> 0.3.x separately, like it was done with src:matplotlib2, for
> the packages still depending on the Python 2 version. (It is
> intended, after all, that Python 2 support will be kept until
> some time after buster, but before bullseye, after all.)


My understanding is that sphinx no more support Python as well
(this is the excuse from the uptream maintainer):
if sphinx still supports Python 2 in Buster,
then it makes sense to make nbsphin supporting Python 2 in Buster.

Ok, I will have a look this week end.

Cheers,
Jerome

> 
> Thanks,
> //mirabilos
> 

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature

Bug#918080: breeze-gtk: symlink /usr/share/themes/Breeze/{gtk-3.20,gtk-3.0}/

[Simon Quigley]

Package: breeze-gtk
Severity: normal
Version: 5.14.3-1

Hello fellow maintainers,

It was raised to my attention from LXQt users that the Breeze GTK theme
cannot be used under LXQt as packaged. This is because the theme exists
in /usr/share/themes/Breeze/gtk-3.18/ and
/usr/share/themes/Breeze/gtk-3.20/ but doesn't exist in
/usr/share/themes/Breeze/gtk-3.0/ which is inconsistent to other GTK
themes in the archive. For example, the arc-theme package just installs
in gtk-3.0.

This raises a few questions for me. Is this just a hidden use of the
standard, or something Plasma-specific? Are the themes meant to only be
used on those minor versions of GTK?

Simply symlinking gtk-3.20 to gtk-3.0 solves the problem under LXQt. Is
it rational to ship this as default?

Thanks folks!

-- 
Simon Quigley
tsimo...@debian.org
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4



signature.asc
Description: OpenPGP digital signature

Bug#917418: nbsphinx no more support Python 2

[Thorsten Glaser]

Hi Jerome,

>The issue was resolved in package 0.4.1+ds-2.

you “resolved” it by no longer building the binary package.

However, there are packages still (build-)depending on it,
which you might wish to inform: see #918079 for an example,

You might also with to file an RM (RoM) bug with ftpmasters
so that they remove the stray binary package from the archive;
the current situation has it still available, making quinn-diff
believe that its r-build-depends are installable, whereas the
package fails to configure. This is bad.

If not all users can switch to python3-nbsphinx in time for
the release, it might make sense to package python-nbsphinx
0.3.x separately, like it was done with src:matplotlib2, for
the packages still depending on the Python 2 version. (It is
intended, after all, that Python 2 support will be kept until
some time after buster, but before bullseye, after all.)

Thanks,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...

Bug#918079: pandas: FTBFS: B-D on python-nbsphinx which is no longer installable nor built any more

[Thorsten Glaser]

Source: pandas
Version: 0.23.3-1
Severity: serious

See #917418 for “python-nbsphinx (0.4.1+ds-1) is not installable”.

src:nbsphinx (0.4.1+ds-3) now only builds the py3k package.

python-nbsphinx (= 0.3.5+ds-1) is installable and usable, but no
longer in Debian, so please move to python3-nbsphinx instead.

Bug#918078: procmeter3: no longer has lm-sensors support

[Jeremy Bicha]

Source: procmeter3
Version: 3.6.1-1.1
Severity: important
X-Debbugs-CC: aure...@debian.org

procmeter3 no longer builds with lm-sensors support.

See modules/check-no-libsensors.sh

Build log excerpt
---
libsensors does not appear to be installed - skipping compilation.

Full build logs
---
https://buildd.debian.org/status/package.php?p=procmeter3

Thanks,
Jeremy Bicha

Bug#918077: python-meep-mpich2 fails to install, postinst script looks for wrong package name.

[peter green]

Package: python-meep-lam4
Version: 1.7.0-2
Severity: serious

https://piuparts.debian.org/sid/fail/python-meep-lam4_1.7.0-2.log

  Setting up python-meep-lam4 (1.7.0-2) ...
  dpkg-query: package 'python-meep' is not installed
  Use dpkg --contents (= dpkg-deb --contents) to list archive files contents.
  Traceback (most recent call last):
File "/usr/bin/pycompile", line 289, in 
  main()
File "/usr/bin/pycompile", line 262, in main
  options.force, options.optimize, e_patterns)
File "/usr/bin/pycompile", line 154, in compile
  for fn, versions_to_compile in filter_files(files, e_patterns, versions):
File "/usr/bin/pycompile", line 109, in filter_files
  for fn in files:
File "/usr/share/python/debpython/files.py", line 77, in filter_out_ext
  for fn in files:
File "/usr/share/python/debpython/namespace.py", line 77, in 
add_namespace_files
  for fn in files:
File "/usr/share/python/debpython/files.py", line 69, in filter_public
  for fn in files:
File "/usr/share/python/debpython/files.py", line 53, in from_package
  raise Exception("cannot get content of %s" % package_name)
  Exception: cannot get content of python-meep
  dpkg: error processing package python-meep-lam4 (--configure):
   installed python-meep-lam4 package post-installation script subprocess 
returned error exit status 1
  Processing triggers for libc-bin (2.28-4) ...
  Errors were encountered while processing:
   python-meep-lam4
  E: Sub-process /usr/bin/dpkg returned an error code (1)



After some investigating it looks like this was caused by failing to update the 
package name in the postinst script
when copying the python changes from the plain meep source package to the 
meep-lam4 source package. The prerm
script also seems to suffer from a similar issue.

A debdiff fixing that is attatched, no intent to NMU.



diff -Nru meep-lam4-1.7.0/debian/changelog meep-lam4-1.7.0/debian/changelog
--- meep-lam4-1.7.0/debian/changelog2018-12-25 15:30:09.0 +
+++ meep-lam4-1.7.0/debian/changelog2019-01-03 02:10:44.0 +
@@ -1,3 +1,9 @@
+meep-lam4 (1.7.0-2+rpi1) buster-staging; urgency=medium
+
+  * Fix postinst and prerm scripts for python-meep-mpich2 to use correct 
package name.
+
+ -- Peter Michael Green   Thu, 03 Jan 2019 02:10:44 
+
+
 meep-lam4 (1.7.0-2) unstable; urgency=medium
 
   * upload to unstable
diff -Nru meep-lam4-1.7.0/debian/python-meep-lam4.postinst 
meep-lam4-1.7.0/debian/python-meep-lam4.postinst
--- meep-lam4-1.7.0/debian/python-meep-lam4.postinst2018-12-23 
11:39:19.0 +
+++ meep-lam4-1.7.0/debian/python-meep-lam4.postinst2019-01-03 
02:10:44.0 +
@@ -2,7 +2,7 @@
 set -e
 
 if which pycompile >/dev/null 2>&1; then
-  pycompile -p python-meep
+  pycompile -p python-meep-lam4
 fi
 
 #DEBHELPER#
diff -Nru meep-lam4-1.7.0/debian/python-meep-lam4.prerm 
meep-lam4-1.7.0/debian/python-meep-lam4.prerm
--- meep-lam4-1.7.0/debian/python-meep-lam4.prerm   2018-12-23 
11:39:19.0 +
+++ meep-lam4-1.7.0/debian/python-meep-lam4.prerm   2019-01-03 
02:10:44.0 +
@@ -2,7 +2,7 @@
 set -e
 
 if which pyclean >/dev/null 2>&1; then
-  pyclean -p python-meep 
+  pyclean -p python-meep-lam4
 else
   dpkg -L python-meep | grep \.py$ | while read file
   do  

Bug#918076: atlas: FTBFS on x32: Configured arch: /bin/sh: 1: cannot open build/Make.inc: No such file

[Thorsten Glaser]

Source: atlas
Version: 3.10.3-7
Severity: important

This is even more important now that src:python-numpy
build-depends on atlas unconditionally.

I: Using pkgname logfile
I: Current time: Thu Jan  3 03:08:53 CET 2019
I: pbuilder-time-stamp: 1546481333
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [/tmp/atlas_3.10.3-7.dsc]
I: copying [/tmp/atlas_3.10.3.orig.tar.bz2]
I: copying [/tmp/atlas_3.10.3-7.debian.tar.xz]
I: Extracting source
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/tglase/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made Sat Jun  9 17:18:57 2018 UTC
gpgv:using RSA key 53951D95272E0C5B82BE8C4A2CECE9350ECEBE4A
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./atlas_3.10.3-7.dsc
dpkg-source: info: extracting atlas in atlas-3.10.3
dpkg-source: info: unpacking atlas_3.10.3.orig.tar.bz2
dpkg-source: info: unpacking atlas_3.10.3-7.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying rename-lapack-atlas.patch
dpkg-source: info: applying mips.patch
dpkg-source: info: applying kfreebsd.patch
dpkg-source: info: applying armel-is-v4t.patch
dpkg-source: info: applying generic.patch
dpkg-source: info: applying ppc64el-abiv2.patch
dpkg-source: info: applying ppc64el-ifdef-files-with-lvx.patch
dpkg-source: info: applying powerpc-dcbt.patch
dpkg-source: info: applying fix-typos.patch
dpkg-source: info: applying missing-cflags.patch
dpkg-source: info: applying ppc64-endianness.patch
I: using fakeroot in build.
I: Installing the build-deps
I: user script /var/cache/pbuilder/build/cow.22017/tmp/hooks/D00-preseed 
starting
+ debconf-set-selections
I: user script /var/cache/pbuilder/build/cow.22017/tmp/hooks/D00-preseed 
finished
W: execute priv not set on file D00local, not executing.
W: execute priv not set on file D01slashrepo, not executing.
W: execute priv not set on file D02debhelper, not executing.
W: execute priv not set on file D05agu, not executing.
W: execute priv not set on file D06agdu, not executing.
W: execute priv not set on file D09buildd, not executing.
W: execute priv not set on file D10ppa, not executing.
W: execute priv not set on file D10wtfrepo, not executing.
W: execute priv not set on file D11klibc-jessie, not executing.
W: execute priv not set on file D20repo, not executing.
W: execute priv not set on file D25backports, not executing.
W: execute priv not set on file D26contrib, not executing.
W: execute priv not set on file D29dhbpo, not executing.
W: execute priv not set on file D30java, not executing.
W: execute priv not set on file D40wheezy, not executing.
W: execute priv not set on file D50agu, not executing.
W: execute priv not set on file D80experimental, not executing.
W: execute priv not set on file D80shell-jupp, not executing.
W: execute priv not set on file D90agdu, not executing.
W: execute priv not set on file D98tmp, not executing.
W: execute priv not set on file D99shell, not executing.
I: -> Attempting to satisfy build-dependencies
Note, using file '/tmp/buildd/atlas_3.10.3-7.dsc' to get the build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  autoconf automake autopoint autotools-dev bsdmainutils debhelper
  dh-autoreconf dh-exec dh-strip-nondeterminism dwz file fontconfig-config
  fonts-dejavu-core fonts-lmodern gettext gettext-base gfortran gfortran-8
  ghostscript groff-base intltool-debian libarchive-zip-perl libavahi-client3
  libavahi-common-data libavahi-common3 libbrotli1 libbsd0 libcairo2 libcroco3
  libcups2 libcupsimage2 libdbus-1-3 libelf1 libexpat1
  libfile-stripnondeterminism-perl libfontconfig1 libfreetype6
  libgfortran-8-dev libgfortran5 libglib2.0-0 libgraphite2-3 libgs9
  libgs9-common libharfbuzz-icu0 libharfbuzz0b libice6 libicu63 libidn11
  libijs-0.35 libjbig0 libjbig2dec0 libjpeg62-turbo libkpathsea6 liblapack-pic
  liblcms2-2 libmagic-mgc libmagic1 libopenjp2-7 libpaper-utils libpaper1
  libpipeline1 libpixman-1-0 libpng16-16 libpotrace0 libptexenc1 libsigsegv2
  libsm6 libsynctex2 libteckit0 libtexlua52 libtexlua53 libtiff5 libtool
  libuchardet0 libwebp6 libwoff1 libx11-6 libx11-data libxau6 libxaw7
  libxcb-render0 libxcb-shm0 libxcb1 libxdmcp6 libxext6 libxi6 libxml2 libxmu6
  libxpm4 libxrender1 libxt6 libxxhash0 libzzip-0-13 m4 man-db po-debconf
  poppler-data t1utils tex-common texlive-base texlive-binaries
  texlive-latex-base ucf x11-common xdg-utils
0 upgraded, 105 newly installed, 0 to remove and 0 not 

Bug#816640: Bug #816640 in ruby-eventmachine marked as pending

[Hideki Yamane]

Hi,

On Fri, 16 Feb 2018 13:48:16 + z...@debian.org wrote:
> Bug #816640 in ruby-eventmachine reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below, and you can check the diff of the fix at:
> 
> https://salsa.debian.org/ruby-team/ruby-eventmachine/commit/a752744e504c657cc43044df98881b6713d6bd65
> 
> 
> Blacklist another "network"-needing test. Closes: #816640

 Is there any reason not upload to the repository?
 It would be nice to fix this FTBFS :)


-- 
Regards,

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

Bug#916012: emacs-gtk crashes when rendering U+2728 SPARKLES

[Rob Browning]

Daniel Kahn Gillmor  writes:

> Control: found 916012 1:26.1+1-2
>
> running emacs-gtk 26.1 from unstable, I still get crashes on U+2728
> SPARKLES .  I'm also seeing a crash when trying to render U+26C4 SNOWMAN
> WITHOUT SNOW.

So I just hit a random crash when trying to look at my INBOX in
notmuch.  Searching for the error turned up this:

  
https://askubuntu.com/questions/1076735/emacs-crashes-on-pasting-the-unicode-symbol

And indeed, purging fonts-noto-color-emoji "fixed" the problem.  I
wonder if it's at all related...

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#883778: problems building guile-2.0 on armel

[Rob Browning]

Kurt Roeckx  writes:

> I've enabled guile-2.0 and 2.2 again on armel yesterday, and it
> seems to build without issues now.

Nice!  And thanks much.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#917789: Wrong tarball id (pristine-tar) when import-orig with --components

[Mo Zhou]

On Sun, Dec 30, 2018 at 12:53:18PM +0100, Guido Günther wrote:
> > I noticed that the pristine-tar tarball id for the source is incorrect
> > if the set of orig-tarballs are imported with
> > 
> >   gbp-import-orig XXX.orig.tar.xz --components YYY
> > 
> > For example, after importing the opencv tarball, I have to manually
> > fix the reference for the main component, while the id "contrib"
> > component is correct:
> 
> By incorrect I _assume_ you mean it's pointing to the wrong tree? gbp
> basically passes on data to pristine tar - it doesn't calculate these
> things by itself so I would again _assume_ it's pointing pristine-tar to
> the wrong git tree? Which tree is it pointing as in your case and which
> tree should it point at?
> The whole machinery is in use by e.g. thunderbird since some time so I
> don't think it completely bogus.
>  -- Guido

Yes, it's pointing to a wrong tree. The correct reference should be

  ~/D/o/opencv ❯❯❯ git cat-file -p upstream
  tree a18a03170473e1773e1f571e561441bc83a3861e

However gbp/pristine-tar refers a67d0acc9952eb94c9dc0f50eb1f73777695418e
(I don't know what this hash points to)

Another observation is that, the tarball can be checked out from the
repo where orig tarballs were imported. But after cloning the repo to
another machine, doing the same checkout would end up with failure,
even if all branches and commits have been pushed.
 
> > 
> >   opencv_3.4.5+dfsg.orig.tar.xz.id  INCORRECT
> >   opencv_3.4.5+dfsg.orig-contrib.tar.xz.id  CORRECT
> > 
> > https://salsa.debian.org/science-team/opencv/commit/a0bd84b30b388b9811bc300e9a62801cf89c8966
> > 
> > It seems that the /tree/ hash is the correct one for the master
> > component (Mattia tought me this but I don't understand what's going on):
> > 
> >   git cat-file -p upstream  # /tree/ main component
> > 

Bug#918075: dar: enable new 2.6 features (FTP/SFTP, binary deltas)

[Christoph Anton Mitterer]

Package: dar
Version: 2.6.0-1
Severity: wishlist


Hi.

Would be nice if the new features from 2.6 (FTP/SFTP support and
binary deltas) could be enabled :-)


Thanks,
Chris.

Bug#918030: please provide DEB_HOST_UNAME_MACHINE

[Jonathan Nieder]

Hi,

Helmut Grohne wrote:

> I find myself repeating a mapping from Debian architectures to the
> typical output of uname -m (and occasionally -s) in various packages.
> Copying such code is going to be a maintenance nightmare, so it should
> live somewhere central. I propose dpkg-dev/dpkg-architecture.

Interesting.  Can you give an example of a package that would benefit
from this?

Thanks,
Jonathan

Bug#917586: other kernel change affecting nvidia

[Jiri Palecek]

Hello,

commit 
https://github.com/torvalds/linux/commit/ae2b01f37044c10e975d22116755df56252b09d8 
also affects nvidia. vm_insert_pfn is used in 
nvidia-drm/nvidia-drm-gem-nvkms-memory.c. It can be easily converted to 
vmf_insert_pfn, by removing the following switch (which only converts 
the errno to a vm fault, which vmf_... returns directly).


With this and the ipmi_user_t fixed, nvidia module can be compiled again.

Regards

    Jiri Palecek

Bug#918074: python-meep-mpich2 fails to install, postinst script looks for wrong package name.

[peter green]

Package: python-meep-mpich2
Version: 1.7.0-2
Severity: serious

https://piuparts.debian.org/sid/fail/python-meep-mpich2_1.7.0-2.log


Setting up python-meep-mpich2 (1.7.0-2) ...
   dpkg-query: package 'python-meep' is not installed
   Use dpkg --contents (= dpkg-deb --contents) to list archive files contents.
   Traceback (most recent call last):
 File "/usr/bin/pycompile", line 289, in 
   main()
 File "/usr/bin/pycompile", line 262, in main
   options.force, options.optimize, e_patterns)
 File "/usr/bin/pycompile", line 154, in compile
   for fn, versions_to_compile in filter_files(files, e_patterns, versions):
 File "/usr/bin/pycompile", line 109, in filter_files
   for fn in files:
 File "/usr/share/python/debpython/files.py", line 77, in filter_out_ext
   for fn in files:
 File "/usr/share/python/debpython/namespace.py", line 77, in 
add_namespace_files
   for fn in files:
 File "/usr/share/python/debpython/files.py", line 69, in filter_public
   for fn in files:
 File "/usr/share/python/debpython/files.py", line 53, in from_package
   raise Exception("cannot get content of %s" % package_name)
   Exception: cannot get content of python-meep
   dpkg: error processing package python-meep-mpich2 (--configure):
installed python-meep-mpich2 package post-installation script subprocess 
returned error exit status 1
   Processing triggers for libc-bin (2.28-4) ...
   Errors were encountered while processing:
python-meep-mpich2
   E: Sub-process /usr/bin/dpkg returned an error code (1)

After some investigating it looks like this was caused by failing to update the 
package name in the postinst script when copying the python changes from the 
plain meep source package to the meep-mpich2 source package. The prerm script 
also seems to suffer from a similar issue.

While working on the above issues I also discovered that the clean target did 
not clean up properly, so I fixed that too.

A debdiff fixing that is attatched, no intent to NMU.


diff -Nru meep-mpich2-1.7.0/debian/changelog meep-mpich2-1.7.0/debian/changelog
--- meep-mpich2-1.7.0/debian/changelog  2018-12-25 15:29:02.0 +
+++ meep-mpich2-1.7.0/debian/changelog  2019-01-03 01:21:28.0 +
@@ -1,3 +1,9 @@
+meep-mpich2 (1.7.0-2+rpi1) buster-staging; urgency=medium
+
+  * Fix postinst script for python-meep-mpich2 to use correct package name.
+
+ -- Peter Michael Green   Thu, 03 Jan 2019 01:21:28 
+
+
 meep-mpich2 (1.7.0-2) unstable; urgency=medium
 
   * upload to unstable
diff -Nru meep-mpich2-1.7.0/debian/python-meep-mpich2.postinst 
meep-mpich2-1.7.0/debian/python-meep-mpich2.postinst
--- meep-mpich2-1.7.0/debian/python-meep-mpich2.postinst2018-12-23 
11:41:15.0 +
+++ meep-mpich2-1.7.0/debian/python-meep-mpich2.postinst2019-01-03 
01:19:17.0 +
@@ -2,7 +2,7 @@
 set -e
 
 if which pycompile >/dev/null 2>&1; then
-  pycompile -p python-meep
+  pycompile -p python-meep-mpich2
 fi
 
 #DEBHELPER#
diff -Nru meep-mpich2-1.7.0/debian/python-meep-mpich2.prerm 
meep-mpich2-1.7.0/debian/python-meep-mpich2.prerm
--- meep-mpich2-1.7.0/debian/python-meep-mpich2.prerm   2018-12-23 
11:41:15.0 +
+++ meep-mpich2-1.7.0/debian/python-meep-mpich2.prerm   2019-01-03 
01:21:28.0 +
@@ -2,7 +2,7 @@
 set -e
 
 if which pyclean >/dev/null 2>&1; then
-  pyclean -p python-meep 
+  pyclean -p python-meep-mpich2
 else
   dpkg -L python-meep | grep \.py$ | while read file
   do  
diff -Nru meep-mpich2-1.7.0/debian/rules meep-mpich2-1.7.0/debian/rules
--- meep-mpich2-1.7.0/debian/rules  2018-12-23 15:24:08.0 +
+++ meep-mpich2-1.7.0/debian/rules  2019-01-03 01:21:28.0 +
@@ -50,6 +50,7 @@
rm -f meep_mpi.pc
rm -f src/libmeep_mpi.la
dh_clean
+   rm -f scheme/meep_enum_renames.i scheme/meep_renames.i 
scheme/meep_swig_bug_workaround.i scheme/meep_wrap.cxx src/sphere-quad.h 
src/step_generic_stride1.cpp
 
 override_dh_auto_test:
echo ${arch}

Bug#918073: git-buildpackage: please document effect of --git-color, --git-notify tristate options

[Mike Miller]

Package: git-buildpackage
Version: 0.9.13
Severity: wishlist

Dear maintainer,

Please document the actual effect of specifying "auto" for tristate
command-line options such as --git-color and --git-notify. For example,
the current documentation

  --git-color=COLOR Whether to use colored output, default is 'auto'

doesn't actually tell the user what the value "auto" means. It can be
inferred if they are familiar with git's color options.

Similarly, with --git-notify set to "auto", the user is left to infer
what is decided automatically. Is it the presence of a terminal? The
presence of an active desktop session? The presence of a particular
Python library? I had to use the source to find the answer, and only
then notice that the suggested python3-notify2 was not installed.

Thank you for your valuable contributions to Debian!


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

Kernel: Linux 4.19.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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-buildpackage depends on:
ii  devscripts 2.18.10
ii  git1:2.19.2-1
ii  man-db 2.8.4-3
ii  python33.7.1-3
ii  python3-dateutil   2.6.1-1
ii  python3-pkg-resources  40.6.2-1
ii  sensible-utils 0.0.12

Versions of packages git-buildpackage recommends:
ii  pristine-tar  1.45
ii  python3-requests  2.20.0-2
ii  sbuild0.77.1-2

Versions of packages git-buildpackage suggests:
ii  python3-notify2  0.3-3
ii  sudo 1.8.26-2
ii  unzip6.0-21

-- no debconf information

Bug#917022: no multiarch support for wxrc

[Olly Betts]

On Thu, Dec 27, 2018 at 11:37:28PM -0500, Scott Talbert wrote:
> On Fri, 21 Dec 2018, Tomasz Słodkowicz wrote:
> > wxrc (command line compiler for wxWidgets XML resources) binary is
> > installed in /usr/bin. This blocks installing the same package with
> > different architecture - required for cross compile. This can be moved
> > to /usr/lib/ as described at
> > https://wiki.ubuntu.com/MultiarchCross#Executables_in_-dev_packages.
> > 
> > I'm trying to install this on an amd64 host:
> > apt-get install libwxgtk-webview3.0-dev:armhf wx-common
> 
> I'm wondering if instead we could just mark wx-common as Multi-Arch:
> foreign?

Probably, assuming the other files in there are safe too.

I have been repeatedly bitten by unwanted consequences from previous
multi-arch changes to wx and other packages, but marking it as foreign
seems less likely to cause problems than trying to move binaries around
with the freeze looming.

Cheers,
Olly

Bug#918072: RFP: md4c -- C Markdown parser

[Lisandro Damián Nicanor Pérez Meyer]

Package: wnpp
Severity: wishlist

* Package name: md4c
  Version : 0.2.7
  Upstream Author : Martin Mitáš
* URL : https://github.com/mity/md4c
* License : MIT
  Programming Lang: C
  Description : C Markdown parser

 MD4C is C Markdown parser with the following features:
 .
 Compliance: Generally MD4C aims to be compliant to the latest version of
 CommonMark specification. Right now fully compliant to CommonMark 0.28.
 .
 Extensions: MD4C supports some commonly requested and accepted extensions.
 .
 Compactness: MD4C is implemented in one source file and one header file.
 .
 Embedding: MD4C is easy to reuse in other projects, its API is very 
 straightforward: There is actually just one function, md_parse().
 .
 Push model: MD4C parses the complete document and calls callback functions
 provided by the application for each start/end of block, start/end of a span,
 and with any textual contents.
 .
 Portability: MD4C builds and works on Windows and Linux, and it should
 be fairly simple to make it run also on most other systems.
 .
 Encoding: MD4C can be compiled to recognize ASCII-only control characters,
 UTF-8 and, on Windows, also UTF-16, i.e. what is on Windows commonly
 called just "Unicode". See more details below.
 .
 Permissive license: MD4C is available under the MIT license.

This source code will be needed by Qt in the future, see

Bug#917247: udev: Many modules are no longer automatically loaded at boot

[gregor herrmann]

On Wed, 02 Jan 2019 22:29:17 +0100, Michael Biebl wrote:

> could you provide the complete debug log. What you quoted look like
> excerpts.
> Seems the kernel rate limiting unhelpfully kicked in as well (Jan  1
> 23:57:06 jadzia kernel: [  392.915694] systemd-udevd: 2084 output lines
> suppressed due to ratelimiting), so best disable that [1]

Thanks again for your help.

I've tried 3 different scenarios now, all with
printk.devkmsg=on udev.log_priority=debug rd.udev.log_priority=debug
in the kernel command line (and udev_log=debug).

1) keep lvm2 at 2.02.176-4.1, upgrade udev to 240-2

Result: missing modules, no lvm warnings.

2) keep udev at 240-2, upgrade lvm2 to 2.03.02-1

Result: missing modules, and lvm warnings.

3) keep lvm2 at 2.03.02-1, downgrade udev to 239-15

Results: modules are back, and no more lvm warnings.

So it looks like the udev upgrade is reponsible for both the modules
and the lvm troubles (although the latter still has to be confirmed
in actual use over time).


After each boot I saved parts of /var/log away.
Find attached dmesg and kern.log for the above mentioned 3 scenarios.


Cheers,
gregor, about to add a comment on the github issue as well

-- 
 .''`.  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: Ry Cooder: Maria Elena


scenario-1.tar.gz
Description: application/gzip


scenario-2.tar.gz
Description: application/gzip


scenario-3.tar.gz
Description: application/gzip


signature.asc
Description: Digital Signature

Bug#918031: openmpi: mpi_init pmix error (gds_dstore.c line 1030)

[Samuel Thibault]

Control: reassign -1 pmix
Control: tags -1 + patch

Boud Roukema, le mer. 02 janv. 2019 15:27:11 +0100, a ecrit:
>  [exodar:00753] PMIX ERROR: INIT in file 
> ../../../../../../src/mca/gds/ds12/gds_dstore.c at line 1030

Actually this is inside pmix. It's trying to use
pthread_mutexattr_setpshared, which is actually not supported. I have
pushed patches into glibc to make autoconf avoid them.

Now, we get to another issue:

[hurd:09500] PMIX ERROR: UNREACHABLE in file 
../../../../../../src/mca/ptl/tcp/ptl_tcp_component.c at line 1619
[hurd:09505] OPAL ERROR: Unreachable in file ext2x_client.c at line 109

and with some more debugging flags:

[hurd:10185] pmix: recv_connect_ack could not setsockopt SO_RCVTIMEO

It seems that recv_connect_ack tests for getsockopt returning
ENOPROTOOPT:

if (0 != getsockopt(sd, SOL_SOCKET, SO_RCVTIMEO, (void*), )) {
if (ENOPROTOOPT == errno || EOPNOTSUPP == errno) {
sockopt = false;
}

but not for setsockopt returning ENOPROTOOPT. In the attached patch I
have fixed it, and then mpirun works fine on GNU/Hurd.

Samuel

Bug#918031: openmpi: mpi_init pmix error (gds_dstore.c line 1030)

[Samuel Thibault]

Samuel Thibault, le jeu. 03 janv. 2019 00:41:57 +0100, a ecrit:
> In the attached patch I have fixed it, and then mpirun works fine on
> GNU/Hurd.

Here is the actual patch

Samuel
Index: pmix-3.1.0~rc2/src/mca/ptl/tcp/ptl_tcp.c
===
--- pmix-3.1.0~rc2.orig/src/mca/ptl/tcp/ptl_tcp.c
+++ pmix-3.1.0~rc2/src/mca/ptl/tcp/ptl_tcp.c
@@ -1253,9 +1253,13 @@ static pmix_status_t recv_connect_ack(in
 tv.tv_sec  = mca_ptl_tcp_component.handshake_wait_time;
 tv.tv_usec = 0;
 if (0 != setsockopt(sd, SOL_SOCKET, SO_RCVTIMEO, , sizeof(tv))) {
-pmix_output_verbose(2, pmix_ptl_base_framework.framework_output,
-"pmix: recv_connect_ack could not setsockopt 
SO_RCVTIMEO");
-return PMIX_ERR_UNREACH;
+if (ENOPROTOOPT == errno || EOPNOTSUPP == errno) {
+sockopt = false;
+} else {
+pmix_output_verbose(2, 
pmix_ptl_base_framework.framework_output,
+"pmix: recv_connect_ack could not 
setsockopt SO_RCVTIMEO");
+return PMIX_ERR_UNREACH;
+}
 }
 }
 

Bug#908744: ecb: warning messages during package loading

[Julian Gilbey]

On Thu, Sep 13, 2018 at 12:06:24PM +0100, Julian Gilbey wrote:
> Package: ecb
> Version: 2.40+git20140216-2
> Severity: normal
> 
> Hi!
> 
> I was just looking at the startup messages for emacs, and noticed the
> following when ECB loads:
> [...]

And with the new version of emacs (1:26.1+1-3), the startup messages
are even worse:

Loading /etc/emacs/site-start.d/50ecb.el (source)...
Compiler-macro error for cl-typep: (error "Unknown type button-release-event")
Compiler-macro error for cl-typep: (error "Unknown type button-press-event")
ECB 2.40 uses CEDET 2.0 (contains semantic 2.2, eieio 1.4, speedbar ).
Compiler-macro error for cl-typep: (error "Unknown type button-release-event")
Compiler-macro error for cl-typep: (error "Unknown type button-press-event")
../usr/share/emacs/site-lisp/ecb/tree-buffer.el: Missing value for option `t' 
of slot `modeline-menu-creator' in struct tree-buffer-spec!
../usr/share/emacs/site-lisp/ecb/tree-buffer.el:   I'll take `:read-only' to be 
an option rather than a default value.
../usr/share/emacs/site-lisp/ecb/tree-buffer.el: Missing value for option `t' 
of slot `sticky-parent-p' in struct tree-buffer-spec!
../usr/share/emacs/site-lisp/ecb/tree-buffer.el:   I'll take `:read-only' to be 
an option rather than a default value.
../usr/share/emacs/site-lisp/ecb/tree-buffer.el: Missing value for option `t' 
of slot `sticky-indent-string' in struct tree-buffer-spec!
../usr/share/emacs/site-lisp/ecb/tree-buffer.el:   I'll take `:read-only' to be 
an option rather than a default value.
../usr/share/emacs/site-lisp/ecb/tree-buffer.el: Missing value for option `t' 
of slot `sticky-parent-fn' in struct tree-buffer-spec!
../usr/share/emacs/site-lisp/ecb/tree-buffer.el:   I'll take `:read-only' to be 
an option rather than a default value.
../usr/share/emacs/site-lisp/ecb/tree-buffer.el: Missing value for option `t' 
of slot `reduce-tree-for-incr-search-fn' in struct tree-buffer-spec!
../usr/share/emacs/site-lisp/ecb/tree-buffer.el:   I'll take `:read-only' to be 
an option rather than a default value.
../usr/share/emacs/site-lisp/ecb/ecb-navigate.el: Obsolete name arg "node" to 
constructor ecb-dlist-node
../usr/share/emacs/site-lisp/ecb/ecb-navigate.el: Obsolete name arg "First 
item" to constructor ecb-nav-history-item [2 times]
Loading /etc/emacs/site-start.d/50ecb.el (source)...done


Best wishes,

   Julian

Bug#776450: Xen PVH support for grub-xen in Buster

[Hans van Kranenburg]

Hi Debian Grub maintainer,

In december, Xen PVH support has been committed in grub master:
https://www.mail-archive.com/grub-devel@gnu.org/msg28125.html

The last pieces needed in the Linux kernel to boot PVH with grub2 landed
in Linux 4.20. I asked our kernel team to carry those patches on top of
the Linux 4.19 kernel that is going to ship in Buster, and that wish was
granted:

https://salsa.debian.org/kernel-team/linux/commit/4d63e6ccbbd6081068633b1147e0f77a59379795

Please see the commit message in there for an explanation why having the
possibility to boot PVH+grub in Debian Buster out of the box would be great.

So here's the question: Do you want to help completing the puzzle and
getting a PVH capable grub2 boot image in the grub-xen-* packages in Buster?

 >8 

I'm currently running self-built boot images, and use the following
recipe to create those:

git clone https://git.savannah.gnu.org/git/grub.git
cd grub
./autogen.sh
rm -rf foo/build
mkdir -p foo/build
cd foo/build
../../configure TARGET_LDFLAGS=-static --target=i386 --with-platform=xen_pvh
make

Now, I create a grub.cfg file and then...

./grub-mkstandalone --grub-mkimage=./grub-mkimage -o
grub-i386-xen_pvh.bin -O i386-xen_pvh -d grub-core/
boot/grub/grub.cfg=grub.cfg

...I end up with something that I can use as kernel image for the Xen
PVH virtual machine.

 >8 

I tried a bit to find out how to change debian/rules in the grub
packaging to make this happen in a similar way as the current support
for PV mode is done, but I have to admit that that's a bit above my
"paygrade". So, I can't attach some patch here yet that already makes it
happen.

However, I'm available to help with testing etc. any time.

 >8 

Slightly OT, but may be interesting for others reading this:

At work, I'm using this in a bit different way than the debian
grub-xen-host/bin package does, since I avoid having anything grub
related in virtual machines.

An example config file is:

root='(xen/xvda)'
insmod xzio
insmod gzio
insmod zstd
insmod btrfs
insmod ext2
echo 'Loading Linux ...'
linux /vmlinuz root=/dev/xvda ro console=hvc0 elevator=noop
echo 'Loading initial ramdisk ...'
initrd /initrd.img
echo 'There we go! ...'
boot

I have a bunch of those with different options etc, and we create the
images and package those up and install them on all the Xen hosts. Since
the disk is always xvda and the right kernel image is always symlinked,
this works for us.

 >8 

Thanks,
Hans van Kranenburg

Bug#918071: RM: conkeror -- ROM; dead upstream, no more works with recent firefox versions

[Axel Beckert]

Package: ftp.debian.org
Severity: normal

Hi,

please remove the source package conkeror and its binary packages from
unstable.

Upstream is dead and it no more works[1] after Firefox moved away from
XUL (which conkeror as many other projects was relying on).

[1] https://bugs.debian.org/906644

The last upstream commit was done by myself and has been made more
than one year ago. It was a nice journey, but it's over now. :-(

Not sure if conkeror should also be removed from stable (and
oldstable). It no more works there either.

-- TIA, Axel

Bug#908834: please build libzstd udeb so that btrfs-progs can use zstd in Debian Installer

[Nicholas D Steeves]

On Sat, Dec 29, 2018 at 04:51:49PM +1100, Dimitri John Ledkov wrote:
> On Sat, 29 Dec 2018 at 15:54, Nicholas D Steeves  wrote:
> >
> > Hi Alex, Cyril, Dimitri, and anyone else reading this,
> >
> > On Wed, Nov 28, 2018 at 08:41:18PM +0100, Alex Mestiashvili wrote:
> > >
> > > Hi Nicholas, it is in the new queue:
> > >
> > >  https://ftp-master.debian.org/new/libzstd_1.3.5+dfsg-2.html
> > >
> > > We just need to wait or ?
> >
> > I fear that waiting will put us too close to the freeze, and then it
> > will be an inappropriate time to make these changes.  I've asked
> > #ftp-masters on irc.oftc about the status of libzstd in NEW (2 months
> > and counting)
> >
> > Cyril and Dimitri, if either of you have a chance to ask an ftp-master
> > for feedback, and it wouldn't be too much of a bother, would you
> > please?
> 
> 
> I'm happy. From btrfs-progs point of view, it simply needs a binNMU to
> pick up and start using libzstd udeb which release team can schedule.

Brilliant! :-)  It looks like we're finally good to go.

I'll also ask the backports team if that (is_udeb_available)
conditional will now violate backports policy, eg: if it's a problem
that the the stretch-backports btrfs-progs will not have zstd support
when the buster one does.  I worry it might, and will follow up with a
btrfs-progs bug if it does.

Happy New Year!
Nicholas


signature.asc
Description: PGP signature

Bug#908834: please build libzstd udeb so that btrfs-progs can use zstd in Debian Installer

[Nicholas D Steeves]

On Sat, Dec 29, 2018 at 04:53:02PM +0100, Cyril Brulebois wrote:
> Hi FTP team,
> 
> I've just been reminded (see below) of the zstd udeb addition currently
> sitting in NEW; the udeb addition was reviewed (even amended) and should
> be ready for use in other d-i components. Could you please let this
> package through? Thanks already!
> 
> Cheers,
> Cyril.

Thank you Cyril!  Yay, libzstd_1.3.5+dfsg-2 (with udeb) is in sid, and
has also migrated to testing!  I took a look at partman-btrfs, which
brings in the btrfs udeb.  Does partman-btrfs need to be modified to
also depend on the new zstd udeb, or will it be added as a recursive
dep when btrfs-progs is rebuilt?

Happy New Year!
Nicholas


signature.asc
Description: PGP signature

Bug#907191: golang-golang-x-sys: FTBFS if /dev/random is a link to /dev/urandom

[Santiago Vila]

Hi.

For your consideration: The following patch works for me (but I don't
know anything about Go, please double-check).

As I said in my initial report, unit tests are mostly useful when they
test the package which is being built, but this one checks the underlying
system, not the package itself, which is a little bit odd and not so useful.

Thanks.diff -Nru golang-golang-x-sys-0.0~git20181228.9a3f9b0/debian/changelog 
golang-golang-x-sys-0.0~git20181228.9a3f9b0/debian/changelog
--- golang-golang-x-sys-0.0~git20181228.9a3f9b0/debian/changelog
2018-12-31 10:40:44.0 +0100
+++ golang-golang-x-sys-0.0~git20181228.9a3f9b0/debian/changelog
2019-01-03 00:17:22.0 +0100
@@ -1,3 +1,10 @@
+golang-golang-x-sys (0.0~git20181228.9a3f9b0-2) unstable; urgency=medium
+
+  * Add 02-do-not-check-for-device-files.patch. Assume that device
+files are ok and do not check them. Closes: #907191.
+
+ -- Anthony Fok   Wed, 02 Jan 2019 23:44:12 +
+
 golang-golang-x-sys (0.0~git20181228.9a3f9b0-1) unstable; urgency=medium
 
   * New upstream version 0.0~git20181228.9a3f9b0
diff -Nru 
golang-golang-x-sys-0.0~git20181228.9a3f9b0/debian/patches/02-do-not-check-for-device-files.patch
 
golang-golang-x-sys-0.0~git20181228.9a3f9b0/debian/patches/02-do-not-check-for-device-files.patch
--- 
golang-golang-x-sys-0.0~git20181228.9a3f9b0/debian/patches/02-do-not-check-for-device-files.patch
   1970-01-01 01:00:00.0 +0100
+++ 
golang-golang-x-sys-0.0~git20181228.9a3f9b0/debian/patches/02-do-not-check-for-device-files.patch
   2019-01-03 00:14:52.0 +0100
@@ -0,0 +1,13 @@
+From: Santiago Vila 
+Subject: Do not check for device files and assume they are ok
+
+--- a/unix/dev_linux_test.go
 b/unix/dev_linux_test.go
+@@ -14,6 +14,7 @@
+ )
+ 
+ func TestDevices(t *testing.T) {
++  return
+   testCases := []struct {
+   path  string
+   major uint32
diff -Nru golang-golang-x-sys-0.0~git20181228.9a3f9b0/debian/patches/series 
golang-golang-x-sys-0.0~git20181228.9a3f9b0/debian/patches/series
--- golang-golang-x-sys-0.0~git20181228.9a3f9b0/debian/patches/series   
2018-03-02 07:23:30.0 +0100
+++ golang-golang-x-sys-0.0~git20181228.9a3f9b0/debian/patches/series   
2019-01-03 00:13:58.0 +0100
@@ -1 +1,2 @@
 01-Fix-mips-build-issues.patch
+02-do-not-check-for-device-files.patch

Bug#917959: octave: segfault on complex dot product

[Bernhard Übelacker]

Hello Adam Knapp,
you might run octave inside gdb to retrieve a backtrace of the crash.

Run below command inside a terminal application and you should
receive a file gdb-octave*.log that you might forward to this bug.

  gdb -q -batch -ex 'set pagination off' -ex 'set width 0' -ex run -ex 'bt 
full' --args octave  2>&1 | tee -a gdb-octave_$(date +%Y-%m-%d_%H-%M-%S).log

Even better would be if debug symbol packages would be installed before
like described in [1].

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace

Bug#917984: [Pkg-dpdk-devel] Bug#917984: Bug#917984: Can not link ODP with newer DPDK

[Dmitry Eremin-Solenikov]

Hello,

чт, 3 янв. 2019 г. в 02:09, Luca Boccassi :
> On Wed, 2019-01-02 at 14:55 +0300, Dmitry Eremin-Solenikov wrote:
> > ср, 2 янв. 2019 г. в 14:49, Luca Boccassi :
> > > On Wed, 2019-01-02 at 01:43 +0300, Dmitry Eremin-Solenikov wrote:
> > > Strange that libtool is messing things up, I've used the same
> > > pkgconfig
> > > file in a few different projects that use autoconf/automake and I
> > > haven't seen this issue.
> >
> > libtool rearranges/squashes linking flags in an attempt to find
> > 'better'
> > linking flags. Unfortunately this fail for DPDK. We have worked
> > around
> > this by squashing all PMDs into a single gcc argument:
> > -Wl,--whole-archive,-lrte_pmd_af_packet,-lrte_pmd_ark,,-
> > lrte_pmd_vmxnet3_uio,--no-whole-archive
> > -ldpdk
> >
> > Thus libtool won't move PMDs from --whole-archive/--no-whole-archive
> > brackets.
> >
> > > I had a look on github, and it does not seem that odp is currently
> > > using pkg-config, but rather doing some manual check - is there a
> > > branch in a fork or a patch you could point me to so that I can try
> > > to
> > > reproduce?
> >
> > No, I have not pushed my code to github yet. The easies way to
> > reproduce
> > is to statically link a sample program with libtool and check that
> > generated
> > ELF contains all PMDs.
>
> That looks like a very very old libtool bug:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347650
>
> Have you tried patching config/ltmain.sh as it's suggested on that bug?

I can try doing that as a test, but I wouldn't like to have patched ltmain.sh
in the source tree.

> Something like:

[patch skipped]

> Note that the current version of Meson does not do a good job of
> generating the pkg-config file, but it's fixed in the version in
> development. I also found a couple of bugs in dpdk. So the following
> content for libdpdk.pc is more correct:

[libdpdk.pc skipped]

Do you plan to upload fixed dpdk packages?

> With that I can manually do a static link (without using libtool).

Good!

BTW: Is there any chance to get libdpdk.a back? We can then work
on fixing linking with libdpdk.pc as the time permits. Note: according
to README.md the 'official' DPDK build is one done using GNU Make
and this build has libdpdk.a instead of libdpdk.pc.

-- 
With best wishes
Dmitry

Bug#918070: gitaly: Expects gitlab socket directory

[Dominik George]

Package: gitaly
Version: 0.129.0+debian-3
Severity: normal

gitaly tries to create a asocket in /run/gitlab/sockets when starting up. 
However, when it tries that, that directory does not exist.  Manually
creating it and then starting gitaly works.

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

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

Versions of packages gitaly depends on:
ii  gitlab-common   11.5.5+dfsg-1
ii  libc6   2.28-4
ii  pipexec 2.5.5-2
ii  procps  2:3.3.15-2
ii  ruby1:2.5.1
ii  ruby-activesupport  2:4.2.10-1
ii  ruby-faraday0.13.1-2
pn  ruby-gitaly-proto   
ii  ruby-github-linguist6.4.0-2
ii  ruby-github-markup  1.7.0+dfsg-2
ii  ruby-gollum-lib 4.2.7.5-3
ii  ruby-gollum-rugged-adapter  0.4.4.1-2
ii  ruby-google-protobuf3.6.1.3-1
ii  ruby-grpc   1.16.1-1
ii  ruby-licensee   8.9.2-1
ii  ruby-rugged 0.27.4+ds-1
ii  ruby-sentry-raven   2.7.4-1

gitaly recommends no packages.

gitaly suggests no packages.

-- no debconf information

Bug#918069: ITP: nitrocli -- Command-line interface for Nitrokey devices

[Robin Krahl]

Package: wnpp
Severity: wishlist
Owner: Robin Krahl 

* Package name: nitrocli
  Version : 0.2.0
  Upstream Author : Daniel Mueller 
* URL : https://github.com/d-e-s-o/nitrocli
* License : GPLv3
  Programming Lang: Rust
  Description : Command-line interface for Nitrokey devices

nitrocli provides a command-line interface for Nitrokey devices.
The Nitrokey Pro provides an OpenPGP smart card, one-time password
generation (HOTP and TOTP) and a password safe.  The Nitrokey Storage
additionally provides hardware-encrypted storage.

nitrocli’s functionality is similar to that of nitrokey-app, which is
already packaged for Debian.  Yet nitrokey-app has a Qt-based user
inface while nitrocli has a command-line interface.  nitrocli and
nitrokey-app are both based on libnitrokey.

I intend to package nitrocli within the Rust packaging team.


signature.asc
Description: PGP signature

Bug#917196: transition: qtbase-opensource-src

[Lisandro Damián Nicanor Pérez Meyer]

Hi Nicholas!

On Wed, 2 Jan 2019 at 19:19, Nicholas D Steeves  wrote:
>
> On Sun, Dec 30, 2018 at 11:08:52PM -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
> > Hi! For what I understand, at this point, we currently need to:
> >
> > - Wait for calibre being built
> > - Somehow make ci.debian.net understand that the latest kdeconnect upload
> > fixed a buggy test (so not really a qt issue, just a race condition in the
> > test)
> > - Wait ~1 more day.
>
> At this time (2 jan) would it be better to upload the new upstream
> version of Calibre, or to wait a bit longer?  "Wait for calibre being
> built" seems like the upload might help the transition :-)

The transition is already over, Qt is in testing.


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

Bug#918068: sagemath: still not building on unstable :-(

[Julian Gilbey]

Package: sagemath
Version: 8.4-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Thanks for fixing the build dependencies!

Unfortunately the build of 8.4-3 is now failing on the buildds :-(

I presume you realise this, but letting you know just in case you
don't.

Best wishes,

   Julian

Bug#917984: [Pkg-dpdk-devel] Bug#917984: Can not link ODP with newer DPDK

[Luca Boccassi]

On Wed, 2019-01-02 at 14:55 +0300, Dmitry Eremin-Solenikov wrote:
> Hello,
> 
> ср, 2 янв. 2019 г. в 14:49, Luca Boccassi :
> > 
> > On Wed, 2019-01-02 at 01:43 +0300, Dmitry Eremin-Solenikov wrote:
> > Strange that libtool is messing things up, I've used the same
> > pkgconfig
> > file in a few different projects that use autoconf/automake and I
> > haven't seen this issue.
> 
> libtool rearranges/squashes linking flags in an attempt to find
> 'better'
> linking flags. Unfortunately this fail for DPDK. We have worked
> around
> this by squashing all PMDs into a single gcc argument:
> -Wl,--whole-archive,-lrte_pmd_af_packet,-lrte_pmd_ark,,-
> lrte_pmd_vmxnet3_uio,--no-whole-archive
> -ldpdk
> 
> Thus libtool won't move PMDs from --whole-archive/--no-whole-archive
> brackets.
> 
> > I had a look on github, and it does not seem that odp is currently
> > using pkg-config, but rather doing some manual check - is there a
> > branch in a fork or a patch you could point me to so that I can try
> > to
> > reproduce?
> 
> No, I have not pushed my code to github yet. The easies way to
> reproduce
> is to statically link a sample program with libtool and check that
> generated
> ELF contains all PMDs.

That looks like a very very old libtool bug:

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

Have you tried patching config/ltmain.sh as it's suggested on that bug?
Something like:

--- a/config/ltmain.sh
+++ b/config/ltmain.sh
@@ -4716,6 +4716,11 @@ func_mode_link ()
arg=$func_stripname_result
;;
 
+  
-Wl,--as-needed|-Wl,--no-as-needed|-Wl,--whole-archive|-Wl,--no-whole-archive)
+   deplibs="$deplibs $arg"
+   continue
+   ;;
+
   -Wl,*)
func_stripname '-Wl,' '' "$arg"
args=$func_stripname_result
@@ -5067,6 +5072,15 @@ func_mode_link ()
lib=
found=false
case $deplib in
+   
-Wl,--as-needed|-Wl,--no-as-needed|-Wl,--whole-archive|-Wl,--no-whole-archive)
+ if test "$linkmode,$pass" = "prog,link"; then
+   compile_deplibs="$deplib $compile_deplibs"
+   finalize_deplibs="$deplib $finalize_deplibs"
+ else
+   deplibs="$deplib $deplibs"
+ fi
+ continue
+ ;;
-mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe \
 |-threads|-fopenmp|-openmp|-mp|-xopenmp|-omp|-qsmp=*)
  if test prog,link = "$linkmode,$pass"; then

Note that the current version of Meson does not do a good job of
generating the pkg-config file, but it's fixed in the version in
development. I also found a couple of bugs in dpdk. So the following
content for libdpdk.pc is more correct:

prefix=/usr
libdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include/dpdk

Name: DPDK
Description: The Data Plane Development Kit (DPDK)
Version: 18.11.0
Requires.private: libbsd, zlib, libmnl, libmlx4, libibverbs, libmlx5, 
libcrypto, jansson, libelf
Libs: -L${libdir} -lrte_telemetry -lrte_bpf -lrte_flow_classify -lrte_pipeline 
-lrte_table -lrte_port -lrte_vhost -lrte_security -lrte_sched -lrte_reorder 
-lrte_rawdev -lrte_pdump -lrte_power -lrte_meter -lrte_member -lrte_lpm 
-lrte_latencystats -lrte_kni -lrte_jobstats -lrte_ip_frag -lrte_gso -lrte_gro 
-lrte_eventdev -lrte_efd -lrte_distributor -lrte_cryptodev -lrte_compressdev 
-lrte_cfgfile -lrte_bitratestats -lrte_bbdev -lrte_acl -lrte_timer -lrte_hash 
-lrte_metrics -lrte_pci -lrte_ethdev -lrte_net -lrte_mbuf -lrte_mempool 
-lrte_ring -lrte_eal -lrte_kvargs -lrte_cmdline
Libs.private: -Wl,--whole-archive -L${libdir} -lrte_common_cpt 
-lrte_common_dpaax -lrte_common_octeontx -lrte_bus_dpaa -lrte_bus_fslmc 
-lrte_bus_ifpga -lrte_bus_pci -lrte_bus_vdev -lrte_bus_vmbus 
-lrte_mempool_bucket -lrte_mempool_dpaa -lrte_mempool_dpaa2 
-lrte_mempool_octeontx -lrte_mempool_ring -lrte_mempool_stack 
-lrte_pmd_af_packet -lrte_pmd_ark -lrte_pmd_atlantic -lrte_pmd_avf 
-lrte_pmd_avp -lrte_pmd_axgbe -lrte_pmd_bond -lrte_pmd_bnx2x -lrte_pmd_bnxt 
-lrte_pmd_cxgbe -lrte_pmd_dpaa -lrte_pmd_dpaa2 -lrte_pmd_e1000 -lrte_pmd_ena 
-lrte_pmd_enetc -lrte_pmd_enic -lrte_pmd_failsafe -lrte_pmd_fm10k 
-lrte_pmd_i40e -lrte_pmd_ifc -lrte_pmd_ixgbe -lrte_pmd_kni -lrte_pmd_liquidio 
-lrte_pmd_mlx4 -lrte_pmd_mlx5 -lrte_pmd_netvsc -lrte_pmd_nfp -lrte_pmd_null 
-lrte_pmd_octeontx -lrte_pmd_pcap -lrte_pmd_qede -lrte_pmd_ring -lrte_pmd_sfc 
-lrte_pmd_softnic -lrte_pmd_tap -lrte_pmd_thunderx -lrte_pmd_vdev_netvsc 
-lrte_pmd_vhost -lrte_pmd_virtio -lrte_pmd_vmxnet3 -lrte_pmd_aesni_gcm 
-lrte_pmd_aesni_mb -lrte_pmd_caam_jr -lrte_pmd_ccp -lrte_pmd_dpaa_sec 
-lrte_pmd_dpaa2_sec -lrte_pmd_null_crypto -lrte_pmd_octeontx_crypto 
-lrte_pmd_openssl -lrte_pmd_crypto_scheduler -lrte_pmd_virtio_crypto 
-lrte_pmd_octeontx_compress -lrte_pmd_qat -lrte_pmd_zlib -lrte_pmd_dpaa_event 
-lrte_pmd_dpaa2_event -lrte_pmd_octeontx_event -lrte_pmd_opdl_event 
-lrte_pmd_skeleton_event -lrte_pmd_sw_event -lrte_pmd_dsw_event 
-lrte_pmd_bbdev_null -lrte_pmd_skeleton_rawdev 

Bug#913604: Please downgrade [Lack of login storage API]

[Simon Valiquette]

Package: firefox-esr
Version: 60.3.0esr-1~deb9u1
Followup-For: Bug #913604


Bernie Elbourn wrote:

> Hello,
>
> I am not maintainer. Just regular "Joe" trying to get to grips with why
> firefox updates have stopped due to apt-listbugs.
>
> I have sympathy with the sentiment ..
>
> "By implementing the nsiLoginStorage API, this lets the users choose a
> single password manager they want to use and integrate it with Firefox."
>
>.. may I gently suggest it is not really a serious Debian bug. These are:

While I understand your point, my understanding is that it is a regression
after Debian Stable (Stretch) was released and that is worked at least in
Firefox 56. A feature regression within Debian Stable usually shouldn't
be marked only as 'wishlist' or 'minor', especially if no workaround is
provided.

Unless of course it was already broken when Debian Stable was released,
in which case 'serious' is way too high, but I don't think so.

It would be interesting to know in which version exactly it stoped working,
as if it only stopped from version 60.3.0esr-1~deb9u1, then it should
definitely be tagged as a security-upgrade regression.

At least the current bug level will make it noticed for Buster and give an
opportunity to provide at least another way to provide a similar feature,
an perhaps even an upgrade path from Debian-oldstable (Jessie).

That said, I wouldn't be against downgrading it to important, especially
as this regression don't seems to be written in the changelog (as required
in the Debian Policy if done on purpose or knowingly). But having it at an
higher level than 'normal' is necessary IMHO if it is a Debian-stable
regression (a problem that was far less common when maintaining of the
original version was still possible).

Have a nice day,

Simon Valiquette


-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: 9.5
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-8-686-pae (SMP w/2 CPU cores)
Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1), LANGUAGE=fr_CA 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#918066: debhelper: please include meson's testlog.txt in build logs

[Jeremy Bicha]

Source: debhelper
Version: 12

I think it would be appropriate if debhelper's meson backend would
include in the build logs the content of
$(CURDIR)/obj-$(DEB_HOST_GNU_TYPE)/meson-logs/testlog.txt at least
when the build tests fail. This can help diagnose test failures
(especially on obscure architectures.)

I think this is encouraged by Debian Policy §4.9's paragraph about the
build being as verbose as possible.

Test Case
===
https://buildd.debian.org/status/fetch.php?pkg=bolt=mips=0.7-1=1546406185

excerpt of the build log

ERROR:../tests/test-journal.c:399:test_journal_invalid_file: child
process (/journal/invalid_file [15310]) failed unexpectedly
---

Full log written to /<>/obj-mips-linux-gnu/meson-logs/testlog.txt

Thanks,
Jeremy Bicha

Bug#918067: pulseaudio: Not all devices of Steelseries Arctic 7 available (new USB id)

[Fredrik Olofsson]

Source: pulseaudio
Version: 12.2-2
Severity: normal
Tags: patch

Dear Maintainer,

The udev rules file already contains a workaround for this headset. But newer 
headset firmware uses a different USB id. Duplicating the rule for the new USB 
id makes the headset work correctly again.

Thanks
/Fredrik

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

Kernel: Linux 4.18.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8), 
LANGUAGE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- orig/lib/rules.d/90-pulseaudio.rules2019-01-02 23:35:33.731931802 
+0100
+++ new/lib/udev/rules.d/90-pulseaudio.rules2019-01-02 23:36:13.480314092 
+0100
@@ -106,5 +106,6 @@
 ATTRS{idVendor}=="041e", ATTRS{idProduct}=="322c", 
ENV{PULSE_PROFILE_SET}="sb-omni-surround-5.1.conf"
 ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="4014", 
ENV{PULSE_PROFILE_SET}="dell-dock-tb16-usb-audio.conf"
 ATTRS{idVendor}=="1038", ATTRS{idProduct}=="1260", 
ENV{PULSE_PROFILE_SET}="steelseries-arctis-usb-audio.conf"
+ATTRS{idVendor}=="1038", ATTRS{idProduct}=="12ad", 
ENV{PULSE_PROFILE_SET}="steelseries-arctis-usb-audio.conf"
 
 LABEL="pulseaudio_end"

Bug#917247: udev: Many modules are no longer automatically loaded at boot

[Michael Biebl]

Control: forwarded -1 https://github.com/systemd/systemd/issues/11314

Am 02.01.19 um 23:12 schrieb gregor herrmann:
> Thanks; I guess you mean https://github.com/systemd/systemd/issues/11314
> (which then refers to the pull request)


Urgh, c fail. Thanks for the correction.


-- 
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#918065: RM: mozilla-dom-inspector -- RoQA; Broken with Firefox Quantum

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove mozilla-dom-inspector. It's broken with Firefox >= 57.

Cheers,
Moritz

Bug#906859: xul-ext-dom-inspector no longer works with firefox-esr 60

[Moritz Mühlenhoff]

On Wed, Oct 03, 2018 at 05:19:49PM +0200, Moritz Mühlenhoff wrote:
> On Sat, Sep 08, 2018 at 03:12:40PM +0800, Paul Wise wrote:
> > On Tue, 21 Aug 2018 21:11:16 +0300 Adrian Bunk wrote:
> > 
> > > Package: xul-ext-dom-inspector
> > > 
> > > XUL addons are no longer supported.
> > 
> > The native Firefox developer tools are almost a replacement,
> > so I think this package can just be removed from Debian.
> 
> David, agreed to remove?

I've filed a removal bug now.

Cheers,
Moritz

Bug#918064: RM: toggle-proxy -- RoQA; Broken with Firefox Quantum

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove toggle-proxy. It's broken with Firefox >= 57
and current Thunderbird.

Cheers,
Moritz

Bug#906868: xul-ext-toggle-proxy no longer works with firefox-esr 60

[Moritz Mühlenhoff]

On Wed, Sep 26, 2018 at 06:42:31PM +0200, Sascha Girrulat wrote:
> Hi,
> 
> would be ok for me.

I've filed a removal bug now.

Cheers,
Moritz

Bug#918063: RM: adblock-plus -- RoQA; Broken with Firefox Quantum

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove adblock-plus. It's broken with Firefox >= 57 and
current Thunderbird.

Cheers,
Moritz

Bug#918062: RM: firefox-kwallet5 -- RoQA; Broken with Firefox Quantum

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove firefox-kwallet5. It's broken with Firefox >= 57.

Cheers,
Moritz

Bug#906832: xul-ext-kwallet5 no longer works with firefox-esr 60

[Moritz Mühlenhoff]

On Wed, Oct 03, 2018 at 05:20:23PM +0200, Moritz Mühlenhoff wrote:
> On Tue, Aug 21, 2018 at 07:53:52PM +0300, Adrian Bunk wrote:
> > On Tue, Aug 21, 2018 at 07:11:59PM +0300, Adrian Bunk wrote:
> > > Package: xul-ext-kwallet5
> > > Version: 1.0-2
> > > Severity: serious
> > > 
> > > XUL addons are no longer supported.
> > 
> > If it is confirmed that this package works with thunderbird 60,
> > it might be an option to change the dependency to only thunderbird.
> 
> addons.thunderbird.net only lists it as compatible to versions
> up to 49.
> 
> Shall we remove xul-ext-kwallet5 from the archive?

No objections in three months, filed a removal bug.

Cheers,
Moritz

Bug#918061: Should ckermit be removed?

[Moritz Muehlenhoff]

Package: ckermit
Severity: serious

Should ckermit be removed from the archive?
- Hasn't seen a maintainer upload in almost six years
- Multiple RC bugs at this point

Cheers,
Moritz

Bug#845113: scala: Upgrade to 2.12.x

[Antonio Ospite]

Package: scala
Version: 2.11.12-4
Followup-For: Bug #845113

Dear Maintainer,

I tried using the 'sbt' from debian to build scala 2.12.x and I get this
error:

---
...
[warn]  module not found: com.eed3si9n#sbt-buildinfo;0.6.1
[warn]  typesafe-ivy-releases: tried
[warn]   
https://repo.typesafe.com/typesafe/ivy-releases/com.eed3si9n/sbt-buildinfo/scala_2.11.x/sbt_0.13/0.6.1/ivys/ivy.xml
[warn]  sbt-plugin-releases: tried
[warn]   
https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/com.eed3si9n/sbt-buildinfo/scala_2.11.x/sbt_0.13/0.6.1/ivys/ivy.xml
[warn]  debian-local-maven: tried
[warn]   
file:/usr/share/maven-repo/com/eed3si9n/sbt-buildinfo_2.11.x_0.13/0.6.1/sbt-buildinfo-0.6.1.pom
[info] Resolving org.scala-sbt#logic;debian ...
[warn]  ::
[warn]  ::  UNRESOLVED DEPENDENCIES ::
[warn]  ::
[warn]  :: com.eed3si9n#sbt-buildinfo;0.6.1: not found
[warn]  ::
[warn] 
[warn]  Note: Some unresolved dependencies have extra attributes.  Check that 
these dependencies exist with the requested attributes.
[warn]  com.eed3si9n:sbt-buildinfo:0.6.1 (scalaVersion=2.11.x, 
sbtVersion=0.13)
[warn] 
[warn]  Note: Unresolved dependencies path:
[warn]  com.eed3si9n:sbt-buildinfo:0.6.1 (scalaVersion=2.11.x, 
sbtVersion=0.13) (/home/ao2/WIP/scala/scala/project/project/plugins.sbt#L1-2)
[warn]+- default:scala-build-build:0.1-SNAPSHOT 
(scalaVersion=2.11.x, sbtVersion=0.13)
sbt.ResolveException: unresolved dependency: com.eed3si9n#sbt-buildinfo;0.6.1: 
not found
...
---

the sbt-buildinfo plugin for sbt 0.13 is not available for scala 2.11:
https://dl.bintray.com/sbt/sbt-plugin-releases/com.eed3si9n/sbt-buildinfo/scala_2.11/

But only for scala 2.10:
https://dl.bintray.com/sbt/sbt-plugin-releases/com.eed3si9n/sbt-buildinfo/scala_2.10/

However this is only part of the problem, other dependencies too would
need to be updated in debian, like libjarjar-java which now have a new
upstream: https://github.com/pantsbuild/jarjar

I know this is not really helpful, I just wanted to give sbt a try and
see where we were at.

Ciao,
   Antonio


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

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

Versions of packages scala depends on:
ii  libjline2-java   2.14.6-1
ii  openjdk-8-jre-headless [java7-runtime-headless]  8u191-b12-2
ii  scala-library2.11.12-4
ii  scala-parser-combinators 1.0.3-3
ii  scala-xml1.0.3-3

scala recommends no packages.

Versions of packages scala suggests:
pn  scala-doc  

-- no debconf information
-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#917196: transition: qtbase-opensource-src

[Nicholas D Steeves]

On Sun, Dec 30, 2018 at 11:08:52PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Hi! For what I understand, at this point, we currently need to:
> 
> - Wait for calibre being built
> - Somehow make ci.debian.net understand that the latest kdeconnect upload 
> fixed a buggy test (so not really a qt issue, just a race condition in the 
> test)
> - Wait ~1 more day.

At this time (2 jan) would it be better to upload the new upstream
version of Calibre, or to wait a bit longer?  "Wait for calibre being
built" seems like the upload might help the transition :-)

Cheers,
Nicholas



signature.asc
Description: PGP signature

Bug#917247: udev: Many modules are no longer automatically loaded at boot

[gregor herrmann]

On Wed, 02 Jan 2019 22:42:46 +0100, Michael Biebl wrote:

> Control: forwarded -1 https://github.com/systemd/systemd/pull/11244
> 
> I've forwarded this issue upstream.

Thanks; I guess you mean https://github.com/systemd/systemd/issues/11314
(which then refers to the pull request)

> Gregor, Frédéric, maybe it's best if you directly follow-up there, in
> case you have a github account.

Will try.


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: Beatles: Honey Pie


signature.asc
Description: Digital Signature

Bug#918001: [intl:sv] Updated translation (sv) for apt-listbugs package

[Francesco Poli]

On Wed, 2 Jan 2019 08:41:17 +0100 Martin Bagge / brother wrote:

> package: apt-listbugs
> tags: l10n, patch
> 
> thanks
> 
> Plz find the updated translation attached.

Hello Martin,
thanks for sending the updated translation.

I have a couple of questions.

First of all:

#: ../lib/aptlistbugs/logic.rb:533
msgid "You must install the reportbug package to be able to do this"
msgstr "Du måste installera paketet reportbug för att kunna göra det här"

#: ../lib/aptlistbugs/logic.rb:584
msgid "You must install a web browser package to be able to do this"
msgstr "Du måste installera en webbläsare för att kunna göra detta"

Why is "to be able to do this" translated differently in these two
cases?


Secondly:

#. TRANSLATORS: %{prog} is the name of a program, %{user} is a user name.
#: ../lib/aptlistbugs/logic.rb:647
msgid ""
"  - query the specified bug number\n"
" (uses %{prog} as user %{user}).\n"
msgstr ""
"  - frågar efter fel identifierat med \n"
" (genom %{prog} som användare %{user}).\n"

The previous translation of "query the specified bug number" was
"fråga efter det angivna felnumret": why was it replaced? Is the new
translation more accurate?
The new translation seems to correspond more to "query the bug
identified by "...


Please note that I do not speak Swedish, hence I can well be completely
off-track. Bear with me!

Please let me know, thanks for your time.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpJx8cDYNrb7.pgp
Description: PGP signature

Bug#853205: (no subject) (dbrc: message 18 of 20)

[Hugh Morris]

On 02/01/19 21:41, Samuel Thibault wrote:

Hugh Morris, le mer. 02 janv. 2019 21:33:28 +, a ecrit:

Yes. Unmodified Sid, with MATE and BlackMATE theme. Previous versions of
Compiz from the repository would work for me somewhat,


Which versions exactly? The 0.9 versions, or where some 0.8.14 or 0.8.16
version of compiz-reloaded work?

Samuel


I am not exactly sure. I have just looked at
http://snapshot.debian.org/package/compiz/ and I am a bit confused by 
the chronology. I have only ever installed from the repository and 
updated when prompted. I could install an older version from a snapshot.


A working version was fairly recent, the last few months.

Hugh

Bug#907632: [ppc64-el] Breaks building aspectc++

[Reinhard Tartler]

No problem at all. Thanks for taking care of the sync for me, Steve!

Reinhard

On January 2, 2019 2:30:50 PM EST, Steve Langasek 
 wrote:
>On Tue, Jan 01, 2019 at 04:32:38PM -0500, Reinhard Tartler wrote:
>> On 12/25/18 11:53 AM, Steve Langasek wrote:
>> > Package: aspectc++
>> > Version: 1:2.2+git20170823-7
>> > Followup-For: Bug #907632
>> > User: ubuntu-de...@lists.ubuntu.com
>> > Usertags: origin-ubuntu disco ubuntu-patch
>> > 
>> > Hello,
>> > 
>> > Based on the bug history, I don't think this is a bug in gcc-8 but
>in
>> > aspectc++ (or in llvm), so I have reassigned.
>> > 
>> > I have also refined the patch provided by Frédéric, to avoid
>repetition in
>> > the code; please find it attached.
>> > 
>> > I have uploaded this patch to Ubuntu, where I confirm it fixes the
>build
>> > failure on ppc64el.
>
>> I've already incorporated Frederic's patch in aspectc++
>1:2.2+git20181008-2,
>> which I've uploaded to unstable on Tue, 23 Oct 2018.
>
>> Maybe it would be appropriate to sync that version over to ubuntu?
>
>Indeed, sorry for overlooking, I missed this because there was an
>Ubuntu
>delta stuck in devel-proposed where I had previously tried to fix up
>the
>llvm-version-related FTBFS.  I've synced this now and it has built fine
>on
>ppc64el.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#803675: [Reportbug-maint] Bug#803675: reportbug: unable to report bug on kernel

[Nis Martensen]

On 01/01/2019 22.18, Sandro Tosi wrote:
> 
> alternatively, we can force bugscript execution in an actual terminal,
> when using GTK, it may not be visually pleasing to see a window pop
> up, but it would be the safest way to gather all the information the
> maintainer wants via bugscripts
> 
> what you think?
> 

Excellent idea. Like this?

diff --git a/bin/reportbug b/bin/reportbug
index f3d1c3e..9407bca 100755
--- a/bin/reportbug
+++ b/bin/reportbug
@@ -2104,7 +2104,7 @@ For more details, please see:
http://www.debian.org/devel/wnpp/''')
 # we get the return code of the script, headers and pseudo- set
 # by the script, and last the text output of the script
 (rc, bugscript_hdrs, bugscript_pseudo, text,
bugscript_attachments) = \
-utils.exec_and_parse_bugscript(handler, bugexec)
+utils.exec_and_parse_bugscript(handler, bugexec, ui.system)

 if rc and not notatty:
 if not ui.yes_no('The package bug script %s exited with
an error status (return '
diff --git a/reportbug/utils.py b/reportbug/utils.py
index 7f90344..621b4b1 100644
--- a/reportbug/utils.py
+++ b/reportbug/utils.py
@@ -1218,13 +1218,13 @@ def get_running_kernel_pkg():
 return None


-def exec_and_parse_bugscript(handler, bugscript):
+def exec_and_parse_bugscript(handler, bugscript, runner):
 """Execute and parse the output of the package bugscript, in particular
 identifying the headers and pseudo-headers blocks, if present"""

 fh, filename = TempFile()
 fh.close()
-rc = os.system('LC_ALL=C %s %s %s' % (handler, pipes.quote(bugscript),
+rc = runner('LC_ALL=C %s %s %s' % (handler, pipes.quote(bugscript),
   pipes.quote(filename)))

 isheaders = False

Bug#918060: iwyu FTBFS on armel: undefined reference to symbol '__atomic_load_4@@LIBATOMIC_1.0'

[Adrian Bunk]

Source: iwyu
Version: 7.0-1
Severity: serious
Tags: ftbfs patch

https://buildd.debian.org/status/fetch.php?pkg=iwyu=armel=7.0-2=1545913678=0

...
/usr/bin/c++   -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 
-w -ffunction-sections -fdata-sections  -Wl,-z,relro  -Wl,-rpath-link,  -Wl,-O3 
-Wl,--gc-sections CMakeFiles/include-what-you-use.dir/iwyu.cc.o 
CMakeFiles/include-what-you-use.dir/iwyu_ast_util.cc.o 
CMakeFiles/include-what-you-use.dir/iwyu_cache.cc.o 
CMakeFiles/include-what-you-use.dir/iwyu_driver.cc.o 
CMakeFiles/include-what-you-use.dir/iwyu_getopt.cc.o 
CMakeFiles/include-what-you-use.dir/iwyu_globals.cc.o 
CMakeFiles/include-what-you-use.dir/iwyu_include_picker.cc.o 
CMakeFiles/include-what-you-use.dir/iwyu_lexer_utils.cc.o 
CMakeFiles/include-what-you-use.dir/iwyu_location_util.cc.o 
CMakeFiles/include-what-you-use.dir/iwyu_output.cc.o 
CMakeFiles/include-what-you-use.dir/iwyu_path_util.cc.o 
CMakeFiles/include-what-you-use.dir/iwyu_preprocessor.cc.o 
CMakeFiles/include-what-you-use.dir/iwyu_verrs.cc.o  -o 
bin/include-what-you-use -Wl,-rpath,"\$ORIGIN/../lib:/usr/lib/llvm-7/lib" 
-lpthread /usr/lib/llvm-7/lib/libclangBasic.a /usr/lib/llvm-7/lib/libclangLex.a 
/usr/lib/llvm-7/lib/libclangAST.a /usr/lib/llvm-7/lib/libclangSema.a 
/usr/lib/llvm-7/lib/libclangFrontend.a /usr/lib/llvm-7/lib/libclangDriver.a 
/usr/lib/llvm-7/lib/libclangParse.a /usr/lib/llvm-7/lib/libclangSerialization.a 
/usr/lib/llvm-7/lib/libclangSema.a /usr/lib/llvm-7/lib/libclangAnalysis.a 
/usr/lib/llvm-7/lib/libclangEdit.a /usr/lib/llvm-7/lib/libclangAST.a 
/usr/lib/llvm-7/lib/libclangLex.a /usr/lib/llvm-7/lib/libclangBasic.a 
/usr/lib/llvm-7/lib/libLLVM-7.so.1 
/usr/bin/ld: 
/usr/lib/llvm-7/lib/libclangFrontend.a(SerializedDiagnosticReader.cpp.o): 
undefined reference to symbol '__atomic_load_4@@LIBATOMIC_1.0'
/usr/bin/ld: //usr/lib/arm-linux-gnueabi/libatomic.so.1: error adding symbols: 
DSO missing from command line
collect2: error: ld returned 1 exit status
make[4]: *** [CMakeFiles/include-what-you-use.dir/build.make:282: 
bin/include-what-you-use] Error 1


Fix:

--- debian/rules.old2019-01-02 21:28:52.105189952 +
+++ debian/rules2019-01-02 21:29:17.129189713 +
@@ -13,6 +13,10 @@
ADDITIONAL_CXX_FLAGS += -mxgot
 endif
 
+ifneq (,$(filter $(DEB_HOST_ARCH), armel))
+   export DEB_LDFLAGS_MAINT_APPEND = -latomic
+endif
+
 %:
dh $@ --buildsystem=cmake --builddirectory=$(TARGET_BUILD)
 

Bug#917648: clamav-freshclam: doesn't properly clean up temporary files, consumes all disk

[Sebastian Andrzej Siewior]

On 2018-12-29 20:28:23 [+], Witold Baryluk wrote:
> It looks it is by default on Debian, because libgtk or something depends
> on apparmor and then it is automatically enabled. Or some package
> suggests it and my apt by default probably install suggests or something.
that and the fact that apparmor is enabled by default in the kernel.
Earlier, the default was what you can achieve now if add
apparmor=0
to the kernel command line (disable kernel support for apparmor).

> I did:
> 
> 1) aa-disable  /usr/bin/freshclam
…
> And it works, it updates a database, and removes temporary directory.

perfect. So it works in general but the apparmor profile lacks some
permissions.

> Reenableing it (aa-enforce), and restarting, bring old behaviour, even if
> all databases are up to date, it creates an empty temporary directory
> that is not removed when it finished update process.

okay. Thanks for the analysis.

> openat(AT_FDCWD, 
> "/var/lib/clamav/clamav-b2d56c174f79ecbf7d1264dd93f6fc1e.tmp", 
> O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 EACCES (Permission denied)
> stat("/var/log/clamav/freshclam.log", {st_mode=S_IFREG|0640, st_size=93037, 
> ...}) = 0
> 
> 
> No idea why it does a 'stat' of the log all the time (maybe log rotation
> functionality), because it is in append mode, so it shouldn't be doing
> this maybe.

It might be part of some higher API. I dunno.

> 
> Anyhow, you can see
> 
> openat(AT_FDCWD, 
> "/var/lib/clamav/clamav-b2d56c174f79ecbf7d1264dd93f6fc1e.tmp", 
> O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY)
> 
> fails with permission denied message.
> 
> However, it doesn't even attempt to remove the directory in the case of
> an error. That is a bug in the freshclam, not apparmor profile. (The
> removal might still fail due to apparmor or other issues, like broken
> file system, nfs mount, etc, but it does change the fact that clamav
> should attempt to clean files and directory even on failure, and if it fails
> to remove, emit a log message).

hmm. I'm not sure if that is the problem. It might however. If it is the
cleaning up part then it should be followed by unlinkat(2) if the
openat(2) would not fail.
"dmesg" should give you the output you look for. Like "apparmor: denied
$this because of $reason".
Looking at the profile it should allow creating and removing
files/directories below /var/lib/clamav/. But then it only allows
reading in /var/lib/clamav and there are cvd written so I miss
something.
Anyway, I have currently no access to box due to vacation time. I will
take a look next week. I would suggest you to remove the freshclam
apparmor profile if you want to use apparmor but it seems you do not
rely on it.

> Regards,
> Witold

Sebastian

Bug#917247: udev: Many modules are no longer automatically loaded at boot

[Michael Biebl]

Control: forwarded -1 https://github.com/systemd/systemd/pull/11244

I've forwarded this issue upstream.
Gregor, Frédéric, maybe it's best if you directly follow-up there, in
case you have a github account.

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#918059: New upstream released GnuCash 3.4

[Andrew Clark]

Package: gnucash
Version: 3.3-2+b2

There's a new version of GnuCash available upstream:
https://github.com/Gnucash/gnucash/releases/tag/3.4

I've built it using the debian/rules from the 3.3-2+b2 source package
and it seems to work without further changes.

Bug#853205: (no subject) (dbrc: message 18 of 20)

[Samuel Thibault]

Hugh Morris, le mer. 02 janv. 2019 21:33:28 +, a ecrit:
> Yes. Unmodified Sid, with MATE and BlackMATE theme. Previous versions of
> Compiz from the repository would work for me somewhat,

Which versions exactly? The 0.9 versions, or where some 0.8.14 or 0.8.16
version of compiz-reloaded work?

Samuel

Bug#888266: stterm: Space between letters when using GNU Unifont

[Paride Legovini]

On Wed, 24 Jan 2018 14:22:24 +0100 Nils Dagsson Moskopp
 wrote:> when starting
stterm with GNU Unifont, with “stterm -f unifont”, the
> letter spacing is much too wide. This makes this terminal unpleasant
> to read. Also the terminal window became unusually wide due to this.

Hello Nils,

I can't reproduce the issue with stterm 0.8.1-1. Could you please give
it a try and confirm it's fixed?

Thank you,

Paride

Bug#801084: bluez-firmware: Please include firmware for Broadcom Corp. BCM20702 Bluetooth 4.0

[Nicolas Braud-Santoni]

Control: fixed -1 1.2-4
Control: tag -1 + stretch

Hi,

The exact same controller works on Buster, with bluez-firmware/1.2-4,
so I am marking it as fixed there.


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#853205: (no subject) (dbrc: message 18 of 20)

[Hugh Morris]

On 02/01/19 21:05, Samuel Thibault wrote:

Hugh Morris, le mar. 01 janv. 2019 19:35:38 +, a ecrit:

With the latest version in
Sid, 2:0.8.16.1-3, Compiz does not work for me at all. In that the desktop
is not drawn properly, with blocks of colour and strange artifacts all over.

Desktop system with:
Gigabyte AB350-Gaming 3 Motherboard
AMD Ryzen 5 1500X Quad-Core Processor
nVidia GK208B [GeForce GT 710] Video card
Nouveau Graphics driver


Mmm :/

Just to rule factors out, what is your software desktop?  Just MATE with
the BlackMATE theme?

Samuel

Yes. Unmodified Sid, with MATE and BlackMATE theme. Previous versions of 
Compiz from the repository would work for me somewhat, not perfectly, 
but now not at all.


I am very interested in getting Compiz working, so let me know if there 
is anything else useful I can tell you.


I am currently using Marco, the MATE window manager, with Compton for 
compositing, and all is smooth and stable.


Hugh

Bug#917247: udev: Many modules are no longer automatically loaded at boot

[Michael Biebl]

Hi Gregor,

could you provide the complete debug log. What you quoted look like
excerpts.
Seems the kernel rate limiting unhelpfully kicked in as well (Jan  1
23:57:06 jadzia kernel: [  392.915694] systemd-udevd: 2084 output lines
suppressed due to ratelimiting), so best disable that [1]

Regards,
Michael

[1] https://lore.kernel.org/patchwork/patch/698730/

-- 
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#916705: Please patch DHT

[Sandro Tosi]

it's no problem, i'll just leave it then -- thanks!

On Wed, Jan 2, 2019 at 4:09 PM Juliusz Chroboczek  wrote:
>
> > point it, it's already been applied - should i remove it or not?
>
> It doesn't hurt, so if you'd rather not bother with a new upload, feel
> free to leave it as it is.
>
> Sorry again for the confusion,
>
> -- Juliusz



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

Bug#916705: Please patch DHT

[Juliusz Chroboczek]

> point it, it's already been applied - should i remove it or not?

It doesn't hurt, so if you'd rather not bother with a new upload, feel
free to leave it as it is.

Sorry again for the confusion,

-- Juliusz

Bug#918054: [Debichem-devel] Bug#918054: elkcode: frequent test hangs

[Michael Banck]

Hi,

On Wed, Jan 02, 2019 at 10:36:48PM +0200, Adrian Bunk wrote:
> Source: elkcode
> Version: 5.2.14-1
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/package.php?p=elkcode=sid
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/elkcode.html
> 
> Tests seems to frequently hang, with no clear pattern which test
> or which architecture (amd64 built on the buildd but hangs in
> reproducible).

Yeah, I noticed, but I didn't get around to dig into it yet.  I thought
I'd had to checkout one of the porter boxes but if you say it sometimes
hangs on amd64 as well, I will try to reproduce locally.


Michael

Bug#917687: [3dprinter-general] Bug#917687: cura-engine: FTBFS: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8: undefined reference to `pth

[Adrian Bunk]

On Wed, Jan 02, 2019 at 09:56:51PM +0100, Gregor Riepl wrote:
> >> That, or the fix wasn't enough.
> > 
> > Works for me.
> 
> Odd.
> 
> > What failure are you getting, and what is the contents
> > of /usr/lib/x86_64-linux-gnu/pkgconfig/polyclipping.pc ?
> 
> I'm getting the same pthread detection error as reported in the bug.

The pthread detection error is just part of a huge log file that gets 
dumped when cmake fails, with contents mostly unrelated to the problem.

In your build log, what are the lines *before*
  ==> CMakeCache.txt <==
?

> Contents:
> 
> $ cat /usr/lib/x86_64-linux-gnu/pkgconfig/polyclipping.pc
> prefix=/usr
> exec_prefix=${prefix}
> libdir=${prefix}/lib/x86_64-linux-gnu
> sharedlibdir=${prefix}/lib/x86_64-linux-gnu
> includedir=${prefix}/include/polyclipping
> 
> Name: polyclipping
> Description: polygon clipping library
> Version:
> 
> Requires:
> Libs: -L${libdir} -L${sharedlibdir} -lpolyclipping
> Cflags: -I${includedir}

Looks OK to me.

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#853205: (no subject) (dbrc: message 18 of 20)

[Samuel Thibault]

Hugh Morris, le mar. 01 janv. 2019 19:35:38 +, a ecrit:
> With the latest version in
> Sid, 2:0.8.16.1-3, Compiz does not work for me at all. In that the desktop
> is not drawn properly, with blocks of colour and strange artifacts all over.
> 
> Desktop system with:
> Gigabyte AB350-Gaming 3 Motherboard
> AMD Ryzen 5 1500X Quad-Core Processor
> nVidia GK208B [GeForce GT 710] Video card
> Nouveau Graphics driver

Mmm :/

Just to rule factors out, what is your software desktop?  Just MATE with
the BlackMATE theme?

Samuel

Bug#825975: sysvinit: Add missing poweroff on hurd-i386

[Samuel Thibault]

Dmitry Bogatov, le sam. 29 déc. 2018 18:34:03 +, a ecrit:
> Would you object if I will add you to threads, related to Hurd?

Please do add me :)

Samuel

Bug#883778: problems building guile-2.0 on armel

[Kurt Roeckx]

I've enabled guile-2.0 and 2.2 again on armel yesterday, and it
seems to build without issues now.

Bug#918031: schroot typo in report

[Boud Roukema]

* typo:

Obviously I cut and paste some CONTEXT lines wrongly in bug report 918031.

$ schroot -e -c ${sessionid} # exit schroot

should be

$ schroot -r -c ${sessionid} # run schroot

Don't waste time by using the -e option until you're ready.


* also: mpifort is not a separate package; it's in libopenmpi-dev

Sorry
Boud

Bug#917687: [3dprinter-general] Bug#917687: cura-engine: FTBFS: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8: undefined reference to `pth

[Gregor Riepl]

>> That, or the fix wasn't enough.
> 
> Works for me.

Odd.

> What failure are you getting, and what is the contents
> of /usr/lib/x86_64-linux-gnu/pkgconfig/polyclipping.pc ?

I'm getting the same pthread detection error as reported in the bug.

Contents:

$ cat /usr/lib/x86_64-linux-gnu/pkgconfig/polyclipping.pc
prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/x86_64-linux-gnu
sharedlibdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include/polyclipping

Name: polyclipping
Description: polygon clipping library
Version:

Requires:
Libs: -L${libdir} -L${sharedlibdir} -lpolyclipping
Cflags: -I${includedir}