Bug#898470: openssl says "Can't load /root/.rnd into RNG"

[Sander Jonkers]

On Mon, May 14, 2018 at 11:45 PM, Sebastian Andrzej Siewior <
sebast...@breakpoint.cc> wrote:

>
> It does say error, but everything completes as expected, correct?
>

Yes, correct: the cert file is created, despite the error message.


FWIW: with the older openssl 1.1.0  "libssl1.1:amd64 (1.1.0h-2)", there is
no error message with the cert-gen command; the file /root/.rnd is there
after the first openssl key-gen command

root@0e7025a0d9cc:/# openssl version
OpenSSL 1.1.0h  27 Mar 2018


root@0e7025a0d9cc:/# ls -al /root/.rnd
ls: cannot access '/root/.rnd': No such file or directory

root@0e7025a0d9cc:/# openssl genrsa -out example.com.key 2048
Generating RSA private key, 2048 bit long modulus
...+++
.+++
e is 65537 (0x010001)

root@0e7025a0d9cc:/# ls -al /root/.rnd
-rw--- 1 root root 1024 May 15 05:47 /root/.rnd

root@0e7025a0d9cc:/# openssl req -new -x509 -key example.com.key -out
example.com.cert -days 3650 -subj /CN=example.com
root@0e7025a0d9cc:/#

Bug#897572: [PATCH] Copy fontconfig .uuid files to avoid getrandom hang in early boot

[Ben Caradoc-Davies]

On 14/05/18 20:24, Laurent Bigonville wrote:
I was more thinking about regenerating the cache with fc-cache in the 
initramfs (or using uuidgen to generate the .uuid files) instead of 
copying them from the live system, I'll try to figure that out.


Thanks very much, Laurent. Confirmed fixed in 0.9.3-3 (with fontconfig 
2.13.0-5, your fix there also noted). I can also confirm that the 
generated initramfs contains the expected .uuid files. With these 
changes, plymouth passphrase screen is shown without delay.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#898681: RFP: webext-jsonview -- web extension that helps you view JSON documents in the browser

[Paul Wise]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-mozext-maintain...@lists.alioth.debian.org

* Package name: webext-jsonview
  Version : 2.0.0
  Upstream Author : Ben Hollis 
* URL : https://jsonview.com/
* VCS : https://github.com/bhollis/jsonview/
* License : MIT
  Programming Lang: TypeScript, JavaScript, CSS, Shell
  Description : web extension that helps you view JSON documents in the 
browser

This is helpful for web development and interacting with JSON APIs.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#429577: #429577: ITP: emacs-snapshot -- The GNU Emacs editor (development snapshot)

[Arnaud Fontaine]

Hi,

>> I  have  almost  finished preparing  emacs-snapshot  and  temporarily
>> pushed it there, so  please have a look when you have  some time as I
>> may have messed things around ;-):
>>   https://salsa.debian.org/arnau/deb-emacs
>
> Could you repost the questions that I don't sufficiently address below
> to debian-emac...@lists.debian.org?   I think  there are  people there
> who should also  see them, particularly those like David  and Sean who
> are working on the broad add-on packaging effort.

Ok.

>>   * I was thinking about having deb-emacs repository for both emacs25
>>   and emacs-snapshot in collab-maint Git  (as emacs.git) instead of a
>>   user repository. What do you think?
>
> For  the  moment  I'd  prefer  to  keep  the  "emacs25"  (soon  to  be
> "emacs"[1]) flavor repository separate, which might suggest creating a
> collab-maint emacs-snapshot  repository for now, if  that's what you'd
> like.

Ok.

> [1] In case you weren't already aware, we're about to unversion the
> emacsXY package to just be "emacs".  It's possible that won't affect
> your work too seriously, though it does involve a bunch of changes
> to the emacs25 debian/ files.  As part of that, the "emacsXY" binary
> package is becoming "emacs-gtk" because we're also moving the
> "emacs" metapackage into the upcoming unversioned emacs source
> package.
>
> I say "we" because although I'm handling the code, David, Sean,
> etc. have been helping figure out the details.
>
>>   * Rob: I  have made several  changes to  emacs25 branch, feel  free to
>> merge them if they look fine to you:
>> https://salsa.debian.org/arnau/deb-emacs/commits/deb/emacs25/d/sid/master
>
> Appreciated -- my current plan is to finish the unversioning, and then
> look back at what's pending elsewhere, emacs 26, bugs, etc.  I'd guess
> that it might make sense for you  to rebase at that point (or at least
> compare the changes), and then we can see where we stand.

There are not so many changes  and most of them are for debian/copyright
which  is  not  related  to   your  work  on  unversioning  the  emacsXY
package. Would you  mind at least applying the changes  I did which does
not clash with your work?

Cheers,
-- 
Arnaud Fontaine


signature.asc
Description: PGP signature

Bug#898680: ITP changeme -- default credential scanner

[Samuel Henrique]

Package: changeme
Owner: "Samuel Henrique" 
Severity: wishlist
User: samuel...@debian.org
Usertags: gsoc2018-portkalipackages


​* Package name: changeme
  Upstream Author : Zach Grace'-- (@*ztgrace*)
* URL : https://github.com/ztgrace/changeme

* License : GPL3+
  Programming Lang: Python
  Description : This package contains a default credential scanner.
Commercial vulnerability
 scanners miss common default credentials. Getting default credentials
added to
 commercial scanners is often difficult and slow. changeme is designed to be
 simple to add new credentials without having to write any code or modules.
 .
 changeme keeps credential data separate from code. All credentials are
stored
 in yaml files so they can be both easily read by humans and processed by
 changeme. Credential files can be created by using the ./changeme.py
--mkcred
 tool and answering a few questions.
 .
 changeme supports the http/https, MSSQL, MySQL, Postgres, ssh and ssh w/key
 protocols. Use ./changeme.py --dump to output all of the currently
available
 credentials.

​I intend to maintain this package under the pkg-security team.


-- 
Samuel Henrique 

Bug#894081: Libvirt debug symbols not available for latest version

[Paul Wise]

Control: retitle -1 security.debian.org: please publish dbgsym packages

On Tue, 27 Mar 2018 14:11:28 +0300 Mathieu Tarral wrote:

> But the reason i couldn't find them is that proposed-upates-debug is not 
> listed
> on the Wiki:
> https://wiki.debian.org/AutomaticDebugPackages#Status

Fixed:

https://wiki.debian.org/AutomaticDebugPackages?action=diff=29=30

I heard that the security archive saves dbgsym packages but does not
publish them anywhere. Retitling the bug to reflect that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#898527: libnss-mdns: Adding ipv6 scope id breaks NFS mounts

[Ross Vandegrift]

On Mon, May 14, 2018 at 01:38:15PM +0100, Simon McVittie wrote:
> On Sat, 12 May 2018 at 18:26:11 -0700, Ross Vandegrift wrote:
> > It looks like the scope id was added in #644912.  This may be a kernel bug 
> > if
> > the scope id should be accepted.
> 
> I think this might be a bug in whatever user-space tool calls
> getaddrinfo() and passes its result to the kernel, which probably means
> mount.nfs? If the kernel doesn't want to see scope IDs in this context,
> then the user-space tool shouldn't provide them: returning scope IDs is
> part of the getaddrinfo() API.

I did some digging, here's what I found.

mount.nfs accepts scoped ipv6 addresses:
  $ sudo mount.nfs -vf '[fd7d:612b:f36c:0:4d15:7364:6589:dbef%2]:/' /mnt/tmp -o 
nfsvers=4.2
  mount.nfs: timeout set for Mon May 14 19:11:01 2018
  mount.nfs: trying text-based options 
'vers=4.2,addr=fd7d:612b:f36c:0:4d15:7364:6589:dbef%2,clientaddr=fd7d:612b:f36c::4c5'

But mount(2) fails:
  $ sudo mount.nfs -v '[fd7d:612b:f36c:0:4d15:7364:6589:dbef%2]:/' /mnt/tmp -o 
nfsvers=4.2
  mount.nfs: timeout set for Mon May 14 19:12:48 2018
  mount.nfs: trying text-based options 
'nfsvers=4.2,addr=fd7d:612b:f36c:0:4d15:7364:6589:dbef%2,clientaddr=fd7d:612b:f36c::4c5'
  mount.nfs: mount(2): Invalid argument
  mount.nfs: an incorrect mount option was specified

nfs(5) has the following to say about the source argument:
  The server's hostname can be an unqualified hostname, a fully qualified
  domain name, a dotted quad IPv4 address, or an IPv6 address enclosed in square
  brackets.  Link-local and site-local IPv6 addresses must be accompanied by an
  interface identifier.  See ipv6(7) for details on specifying raw IPv6
  addresses.

And ipv6(7) has this to say about the scope id field:
  sin6_scope_id is an ID depending on the scope of the address.  It is new in
  Linux 2.4.  Linux supports it only for link-local addresses, in that case
  sin6_scope_id contains the interface index (see netdevice(7))


Best as I can figure there's three wishlist bugs here:

1. nss-mdns should not return scope id for global addresses
2. mount.nfs should strip scope id unless the address is link-local
3. the kernel should accept & ignore scope id on non-global addresses

Does this seems like a reasonable reading?

Ross

Bug#898679: palapeli: using palapeli if you try to navigate to hidden directory you cannot see hidden directory.

[shirish शिरीष]

Package: palapeli
Version: 4:17.12.2-1
Severity: normal

Dear Maintainer,

I tried adding an image which is in a hidden directory, i.e.
./$directory. I am on debian-mate on debian-testing. I am not using
konqueror

$ aptitude search konqueror nautilus
p   konqueror- advanced
file manager, web browser and document viewer
..
p   nautilus - file
manager and graphical shell for GNOME

So the only option left is caja and as can be seen it doesn't show the
hidden files and folders. Attaching two pictures which show the same.


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

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

Versions of packages palapeli depends on:
ii  kio   5.45.0-1
ii  libc6 2.27-3
ii  libkf5archive55.45.0-1
ii  libkf5completion5 5.45.0-1
ii  libkf5configcore5 5.45.0-1
ii  libkf5configgui5  5.45.0-1
ii  libkf5configwidgets5  5.45.0-1
ii  libkf5coreaddons5 5.45.0-1
ii  libkf5crash5  5.45.0-1
ii  libkf5i18n5   5.45.0-1
ii  libkf5itemviews5  5.45.0-1
ii  libkf5kiowidgets5 5.45.0-1
ii  libkf5notifications5  5.45.0-1
ii  libkf5service-bin 5.45.0-1
ii  libkf5service55.45.0-1
ii  libkf5widgetsaddons5  5.45.0-1
ii  libkf5xmlgui5 5.45.0-1
ii  libqt5core5a  5.10.1+dfsg-6
ii  libqt5gui55.10.1+dfsg-6
ii  libqt5svg55.10.1-2
ii  libqt5widgets55.10.1+dfsg-6
ii  libstdc++68.1.0-1
ii  palapeli-data 4:17.12.2-1

Versions of packages palapeli recommends:
ii  khelpcenter  4:18.04.0-1
ii  qhull-bin2015.2-4

palapeli suggests no packages.

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#898678: ca-certificates-java: convert PKCS12 cacerts keystore to JKS

[Tiago Stürmer Daitx]

Package: ca-certificates-java
Version: 20180413
Severity: important

Dear Maintainer,

The fix for bug #894979 which updated ca-certificates-java to generate
JKS keystores by default - instead OpenJDK's 9+ default of PKCS12 - only
fixes new installs.

Any user already affected by that issue won't benefit from the fix, as
the file /etc/ssl/certs/java/cacerts is at most updated by the
jks-keystore hook. The only way to actually change it from the PKCS12
to the JKS format is to remove the cacerts file and then calling
'update-ca-certificates -f' - which is also accomplished by removing and
then reinstalling the ca-certificates-java package.

The attached patch fixes this behavior by:
1) Detecting if a PKCS12 cacert exists
2) Converting it to JKS and saving it to cacerts.dpkg-new

Finally, if, and only if, 'cacerts_updates' is set to 'yes':
3) Moving the old PKCS12 cacerts to a cacerts.dpkg-old and the dpkg-new
into /etc/ssl/certs/java/cacerts.

Additionally, a few other fixes are also addressed in the debdiff:
1) Only set JAVA_HOME if a jvm is found. Previously if none of the the
jvms in the list were found the last one jvm was used - although that
didn't cause any unexpected errors, it was wrong.
2) Avoid generating a jvm.cfg as openjdk has it's own logic for
providing a well defined default jvm.cfg in such scenarios.
3) On Ubuntu it should depend on openjdk-11-jre-headless instead
of openjdk-8.


Please review and consider applying the provided debdiff.

Regards,
Tiago Daitx

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

Kernel: Linux 4.15.0-20-lowlatency (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru ca-certificates-java-20180413/debian/changelog 
ca-certificates-java-20180413.1/debian/changelog
--- ca-certificates-java-20180413/debian/changelog  2018-04-13 
09:15:39.0 -0300
+++ ca-certificates-java-20180413.1/debian/changelog2018-05-14 
23:16:43.0 -0300
@@ -1,3 +1,18 @@
+ca-certificates-java (20180413.1) unstable; urgency=medium
+
+  [ Tiago Stürmer Daitx ]
+  * debian/jks-keystore.hook.in: Don't create a jvm-*.cfg file, a default file
+with the right configuration is already supplied by the openjdk packages.
+  * debian/jks-keystore.hook.in, debian/postinst.in: Only export JAVA_HOME
+and update PATH if a known jvm was found.
+  * debian/postinst.in: Detect PKCS12 cacert keystore generated by
+previous ca-certificates-java and convert them to JKS.
+
+  [ Matthias Klose ]
+  * Explicitly depend on openjdk-11-jre-headless, needed to configure.
+
+ -- Tiago Stürmer Daitx   Tue, 15 May 2018 02:16:43 
+
+
 ca-certificates-java (20180413) unstable; urgency=medium
 
   * Team upload.
diff -Nru ca-certificates-java-20180413/debian/jks-keystore.hook.in 
ca-certificates-java-20180413.1/debian/jks-keystore.hook.in
--- ca-certificates-java-20180413/debian/jks-keystore.hook.in   2018-04-13 
09:02:14.0 -0300
+++ ca-certificates-java-20180413.1/debian/jks-keystore.hook.in 2018-05-14 
23:16:43.0 -0300
@@ -45,20 +45,12 @@
oracle-java10-jre-$arch oracle-java10-server-jre-$arch 
oracle-java10-jdk-$arch \
java-11-openjdk-$arch java-11-openjdk \
oracle-java11-jre-$arch oracle-java11-server-jre-$arch 
oracle-java11-jdk-$arch; do
-if [ -x /usr/lib/jvm/$jvm/bin/java ]; then
+if [ -x /usr/lib/jvm/$jvm/bin/java ]; then
+export JAVA_HOME=/usr/lib/jvm/$jvm
+PATH=$JAVA_HOME/bin:$PATH
break
-fi
+fi
 done
-export JAVA_HOME=/usr/lib/jvm/$jvm
-PATH=$JAVA_HOME/bin:$PATH
-
-temp_jvm_cfg=
-if [ ! -f /etc/${jvm%-$arch}/jvm-$arch.cfg ]; then
-# the jre is not yet configured, but jvm.cfg is needed to run it
-temp_jvm_cfg=/etc/${jvm%-$arch}/jvm-$arch.cfg
-mkdir -p /etc/${jvm%-$arch}
-printf -- "-server KNOWN\n" > $temp_jvm_cfg
-fi
 
 if dpkg-query --version >/dev/null; then
 nsspkg=$(dpkg-query -L "$(nsslib_name)" | sed -n 
's,\(.*\)/libnss3\.so$,\1,p'|head -n 1)
diff -Nru ca-certificates-java-20180413/debian/postinst.in 
ca-certificates-java-20180413.1/debian/postinst.in
--- ca-certificates-java-20180413/debian/postinst.in2018-04-13 
09:03:15.0 -0300
+++ ca-certificates-java-20180413.1/debian/postinst.in  2018-05-14 
23:16:43.0 -0300
@@ -35,12 +35,50 @@
oracle-java10-jre-$arch oracle-java10-server-jre-$arch 
oracle-java10-jdk-$arch \
java-11-openjdk-$arch java-11-openjdk \
oracle-java11-jre-$arch oracle-java11-server-jre-$arch 
oracle-java11-jdk-$arch; do
-if [ -x /usr/lib/jvm/$jvm/bin/java ]; then
-break
+if [ -x /usr/lib/jvm/$jvm/bin/java ]; then
+export JAVA_HOME=/usr/lib/jvm/$jvm
+

Bug#898677: RM: reinteract -- RoQA; unmaintained, depends on pygtk

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: reinter...@packages.debian.org, la...@debian.org

reinteract was orphaned in 2014 and apparently abandoned upstream
in 2011. It was removed from Testing in January because it depends on
the deprecated pygtk.

Therefore, please remove reinteract from Debian.

https://bugs.debian.org/590773 (orphan bug)

Thanks,
Jeremy Bicha

Bug#894519: python-gtkglext1: Intent to remove from Debian

[Jeremy Bicha]

I have received no replies. Please reply immediately to let me know if
you approve or object. If I don't hear from you, I will convert this
bug into a removal bug very soon.

Thanks,
Jeremy Bicha

Bug#885138: bauble: Depends on unmaintained pygtk

[Mario Frasca]

yes, upstream is aware of this problem, I've two issues open, one
relative to Python3 and one relative to Gtk3.
moving to Gtk3 is a bit complicated by the extensive usage that the
software makes of ComboBoxEntry, that disappeared in Gtk3.
any help very welcome.

Bug#898676: RM: pyneighborhood -- RoQA; unmaintained, depends on pygtk

[Jeremy Bicha]

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

pyneighborhood was orphaned in 2009 and apparently abandoned upstream
in 2011. It was removed from Testing in January because it depends on
the deprecated pygtk.

Therefore, please remove pyneighborhood from Debian.

https://bugs.debian.org/543880 (orphan bug)

Thanks,
Jeremy Bicha

Bug#898675: nn.1: Use the correct macro for a font change of one argument

[Bjarni Ingi Gislason]

Package: nn
Version: 6.7.3-10+b2
Severity: minor
Tags: patch

Dear Maintainer,

   * What led up to the situation?

chk_manuals: Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z 

:4039 (macro IR): only 1 argument, but more are expected
:4321 (macro BR): only 1 argument, but more are expected
:4323 (macro BR): only 1 argument, but more are expected
:4325 (macro BR): only 1 argument, but more are expected

["test-groff" is a developmental version of "groff"]

  Patch:

--- nn.12018-05-15 01:38:14.0 +
+++ nn.1.new2018-05-15 01:39:12.0 +
@@ -4036,7 +4036,7 @@ This is useful on slow terminals.
 .TP
 \-\fBL\fP[\fIf\fP] {\fBset layout\fP \fIf\fP}
 Select alternative menu layout
-.IR f
+.I f
 (0 to 4).
 If
 .I f
@@ -4318,11 +4318,11 @@ The fourteen multikeys are named:
 .BR up ,
 .BR down ,
 .BR right ,
-.BR left
+.B left
 (the four arrow keys), and
-.BR #0
+.B #0
 through
-.BR #9
+.B #9
 for the user-defined keys.
 .sp 0.5v
 Multikey #\fIi\fP (where \fIi\fP is a digit or an arrow key name) is

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

Kernel: Linux 4.9.88-1-u1 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages nn depends on:
ii  debconf [debconf-2.0]  1.5.66
ii  libc6  2.27-3
ii  libncurses66.1+20180210-2
ii  libtinfo6  6.1+20180210-2

Versions of packages nn recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.91-3

Versions of packages nn suggests:
ii  gnupg   2.2.5-1
ii  ispell  3.4.00-6+b1

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#898527: libnss-mdns: Adding ipv6 scope id breaks NFS mounts

[Ross Vandegrift]

On Mon, May 14, 2018 at 01:38:15PM +0100, Simon McVittie wrote:
> Not including the scope ID in the result of address resolution breaks IPv6
> link-local addressing (fe80:*), and link-local addressing and mDNS are both
> parts of the Zeroconf stack, so they (should) go well together.

Yep, this makes perfect sense - the scope id shouldn't go away entirely.

> Or possibly nss-mdns should be setting the scope ID to the interface
> index for link-local addresses, but not for other addresses? It isn't
> entirely clear to me what nss-mdns is meant to be doing here.

On one hand, rfc4007 11.1 says that the scope id should not be used for
global scope, loopback, and undefined addresses.  On the other, ping &
ssh both saw the scope id and handled it without complaint.


> Workarounds:
> 
> * don't use mDNS (.local names) to find NFS servers; or
> * configure mdns4[_minimal] instead of mdns[_minimal] so .local names
>   resolve to IPv4 addresses

Yea there are workarounds, but I think this use-case is a sensible one
that should be supported.

My home has provider-assigned addressing via DHCPv6 PD, so it isn't
static.  ipv6 wisdom might suggest ULA + DNS instead.  That requires
static addressing or dynamic DNS - both of which are overkill for home
users.  mDNSv6 has been providing a good solution to exactly this.

Ross

Bug#898663: python-testtools: Updates from Ubuntu

[Corey Bryant]

On Mon, May 14, 2018 at 4:25 PM, Thomas Goirand  wrote:

> On 05/14/2018 08:36 PM, Corey Bryant wrote:
> > Package: python-testtools
> > Version: 2.3.0-4
> > Severity: normal
> > Tags: patch
> > User: ubuntu-de...@lists.ubuntu.com
> > Usertags: origin-ubuntu cosmic ubuntu-patch
> >
> > Dear Maintainer,
> >
> > In Ubuntu, the attached patch was applied to achieve the following:
> >
> >   - d/control: Enable execution of autopkgtests.
> >   - d/p/fix-test-run.py.patch: Dropped. No longer needed.
> >   - d/tests/control: Drop python-testscenarios from Depends.
> >   - d/tests/testsuite-*: Set PYTHONPATH when running tests.
> >
> > Thanks for considering the patch.
>
> Thanks for this, however, this:
>
> +XS-Testsuite: autopkgtest
>
> is to be removed in Debian (it produces a lintian warning). Is this
> still in use in Ubuntu?
>

I think you're right that it's obsolete now. Please disregard.

Thanks,
Corey


>
> Cheers,
>
> Thomas Goirand (zigo)
>

Bug#833397: RFP: commix -- Automated All-in-One OS Command Injection and Exploitation Tool

[Samuel Henrique]

I was going to package commix until i realized that it Depends on
metasploit-framework (at least the Kali package does).

This is a note for anyone wanting to package commix, you either have to
drop that dependency (which probably isn't doable) or package
metasploit-framework*.

* I will probably package metasploit-framework, if i succeed i'll package
commix too (if nobody steps ahead).

-- 
Samuel Henrique 

Bug#898391:

[ciel]

Severity: grave

Hi how is this issue going? I don't understand even why you need to
add conflicts. If you care about glvnd so much, I even think you can
migrate all existing installation to nonglvnd edition. I'm having
segmentation fault on libgtk3 with glvnd edition, so nonglvnd is only
my option.

Anyway I have to update the severity to grave. Please consider to fix
the issue soon.

Bug#898620: libglu: Update VCS links in debian/control

[Stuart Young]

Realised I got the files around the wrong way in the patch. While it'll
probably apply, it'd be better to get it right.

Correct patch attached.

On 14 May 2018 at 20:51, Stuart Young  wrote:

> Source: libglu
> Severity: normal
> Tags: patch
>
> Dear Maintainer,
>
> The current Vcs tags in debian/control still refer to git.debian.org
>
> Attached is a patch to update them to point to the source at
> salsa.debian.org
>

-- 
Stuart Young (aka Cefiar)
--- libglu/debian/control.orig	2018-05-14 20:43:11.553964761 +1000
+++ libglu/debian/control	2018-05-14 20:44:04.912681221 +1000
@@ -9,8 +9,8 @@
  dh-autoreconf,
  pkg-config,
  libgl1-mesa-dev,
-Vcs-Git: git://git.debian.org/git/pkg-xorg/lib/libglu
-Vcs-Browser: http://git.debian.org/?p=pkg-xorg/lib/libglu.git
+Vcs-Git: https://salsa.debian.org/xorg-team/lib/libglu.git
+Vcs-Browser: https://salsa.debian.org/xorg-team/lib/libglu
 
 Package: libglu1-mesa
 Section: libs

Bug#898674: firefox-esr: broken symlink: /usr/lib/firefox-esr/browser/icons

[Manolo Díaz]

Package: firefox-esr
Version: 60.0esr-1
Severity: normal

Dear Maintainer,

This package ships /usr/lib/firefox-esr/browser/icons, a broken symlink
that points to ../../../share/firefox-esr/browser/icons. 

Best regards,
-- 
Manolo Díaz

Bug#849313: RFS: mate-equake-applet/1.3.8-1 [ITP]

[Jeroen van Aart]

Dear all,

I would need a sponsor for this package. I uploaded a previous version 
for the first time in December 2016, with the last update March 2017.


However I let the RFS expire and be archived because at the time mate in 
the upcoming debian stable had migrated to gtk3 and I first had to 
migrate this software to gtk3 as well before requesting sponsorship again.


I recently completed this hence I re-opened this older RFS bug.


Package: sponsorship-requests
Severity: wishlist

* Package name: mate-equake-applet
  Version : 1.3.8.2-1
  Upstream Author : Jeroen van Aart
* URL : https://www.e-quake.org
* License : GPL
  Section : x11

It builds those binary packages:

mate-equake-applet - Mate panel applet which monitors earthquakes

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


https://mentors.debian.net/package/mate-equake-applet

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

dget -x 
https://mentors.debian.net/debian/pool/main/m/mate-equake-applet/mate-equake-applet_1.3.8.1-1.dsc


Changes since the last upload:

* New upstream release (Closes: #849267)
* Migrated to gtk3 which is the default major version of gtk used by 
mate in the current debian stable and newer

* Limited the amount to which text can grow before being displayed into
GtkLabel when viewing historical data for the week, to prevent GtkLabel 
from crashing

* Added test to count amount of commas left in text to be processed


Best regards,
Jeroen van Aart

Bug#887904: RFR: Make dh_installinit and dh_installsystemd debhelper autoscript snippets independent in c12 (Was: Re: Bug#887904: dh_installsystemd will unmask services *after* an attempt to start the

[Felipe Sateler]

On Sun, May 13, 2018 at 1:54 PM Niels Thykier  wrote:

> Control: tags -1 -patch
>
> Felipe Sateler:
> > On Sun, May 13, 2018 at 11:34 AM Niels Thykier 
> wrote:
> >
> > [...]
> >
> > There is one case where I think things go wrong (but I haven't tested): A
> > package including only an init script will not run invoke-rc.d but it
> won't
> > have a dh_installsystemd snippet either, so the service won't get started
> > on installation.
> >
> >
> >
>
> That sounds like it is true.  However, it also seems to imply that
> dh_installsystemd and dh_installinit must forever be tangled some how.
> If true, that is very much unfortunate as it makes the interaction a lot
> more complicated than it should be (case in point, this bug is caused
> exactly by these two commands being tangled).
>
> Do you see a solution for this, where dh_installsystemd and
> dh_installinit can become independent/unaware of each other?
> Alternatively, should we merge them into a single helper instead?
>

I think the entanglement can be removed by runtime checking of the unit.

1. Swap the order of installinit and installsystemd so systemd acts first.
2. Have the installinit snippet do:

if [ -d /run/systemd/system ] && [ "/etc/init.d/#SCRIPT" != "$(systemctl
show --value --property SourcePath #SCRIPT#.service)" ] ; then
  # do nothing
else
  invoke-rc.d #SCRIPT# start || #ERROR_HANDLER#
fi

This checking could also be moved into invoke-rc.d via some flag. What do
you think?

Step one is needed in case the compatibility symlink is created at
systemd-enable time (via Alias)
-- 

Saludos,
Felipe Sateler

Bug#898619: [Pkg-zsh-devel] Bug#898619: Bug#898619: zsh autocompletion does not deal gracefully with upgrades in the background

[Philipp Kern]

Hi,

On 2018-05-15 00:09, Frank Terbeck wrote:

Axel Beckert wrote:

Philipp Kern wrote:

[...]

My gut feeling is that this is because I did not autocomplete in the
old shell yet but now the module is gone.


Yes, that's the same conclusion I came to.


At least with a new shell complist.so is only in /proc/$$/maps after
an attempted completion.


Yes, modules are loadable at run-time.


Would it be possible to make sure that the autocompletion system
loads the module on startup rather than on-demand?


Zsh is  setup to  do lots  of things  on demand.  It would  certainly 
be
conceivable  to be  more gracious  about  the issue.  But when  
versions
upgrade, I don't  think it's unreasonable to restart a  shell, like 
Axel

mentioned via "exec zsh".

If you'd really like that module loaded all the time, you can load it 
in

your setup. Personally, I'm loading a bunch of modules at startup time.


I'm caring about a large setup rather than a personal installation, 
though, which sort of shifts as to what's reasonable and what isn't. ;-)


Let's say I'm using /etc/zsh/newuser.zshrc.recommended (which is 
actually what I'm using verbatim). Could we at least fix it for that 
configuration? That one does this:


| # Use modern completion system
| autoload -Uz compinit
| compinit

/usr/share/zsh/functions/Completion/compinit does not invoke "zmodload 
-i zsh/complist" whereas the first invocation of the completion menu 
would. How bad would it be to add the module loading to the 
initialization? Is there a benefit to not doing that specific call on 
startup? The module itself is a 63k .so file.


In a very non-scientific test I get a VM increase from 37076 kB -> 43968 
kB (+18%), anon pages from 1840 -> 2148 kB (+16%) and file pages from 
3912 -> 4508 kB (+15%) on amd64 when running a full completion for 
l on my system. And that loads even more than just the module, 
because it goes through the whole setup.


I mean sure, I could add a zmodload call to our system-wide config. But 
I'd rather we solve this problem for all of Debian's users rather than 
just us. (This is assuming that people are on some variant of a rolling 
testing and don't reboot their machines all the time after updates - 
which currently violates other Debian assumptions like the kernel's as 
well.)


Kind regards and thanks for your consideration
Philipp Kern

Bug#898619: [Pkg-zsh-devel] Bug#898619: Bug#898619: zsh autocompletion does not deal gracefully with upgrades in the background

[Frank Terbeck]

Axel Beckert wrote:
> Philipp Kern wrote:
[...]
>> My gut feeling is that this is because I did not autocomplete in the
>> old shell yet but now the module is gone.
>
> Yes, that's the same conclusion I came to.
>
>> At least with a new shell complist.so is only in /proc/$$/maps after
>> an attempted completion.

Yes, modules are loadable at run-time.

>> Would it be possible to make sure that the autocompletion system
>> loads the module on startup rather than on-demand?

Zsh is  setup to  do lots  of things  on demand.  It would  certainly be
conceivable  to be  more gracious  about  the issue.  But when  versions
upgrade, I don't  think it's unreasonable to restart a  shell, like Axel
mentioned via "exec zsh".

If you'd really like that module loaded all the time, you can load it in
your setup. Personally, I'm loading a bunch of modules at startup time.


Regards, Frank

Bug#897492: [Debichem-devel] Bug#897492: what are you building?

[Michael Banck]

Hi Lori,

On Mon, May 14, 2018 at 11:18:43AM -0400, Lori Burns wrote:
> * What version of psi4 are you trying to build? 

This should be 1.1.

> Apparently not a git clone, so I can’t see the version info. If it’s
> 1.1, then the pybind11 2.2 that you’re using absolutely won’t work (I
> hadn’t added EXACT to `find_package(pybind11 2.0 EXACT REQUIRED)`
> then). Moreover, no pb11 2.0 _package_ will work (unless yours was
> built with CMake, not pip) and you just have to let psi4 build system
> pull and build its own. 

Back when 1.1. was introduced to Debian/Ubuntu, pybin11-2.0 was the
current version and yes, it seems like they were built with cmake, but I
didnt' dig very deep into this.

In the meantime, it appears that pybind11 got updated to 2.2.

> If it’s current master you’re trying to build, pb11 is set at 2.2.3.
> If it’s current master you’re building, though, be advised that the
> minimal dependencies are libint 1.2, gau2grid
> (https://github.com/dgasmith/gau2grid
> ), and libxc (4.0 now, but still
> forked (https://github.com/psi4/libxc 
> note the non-master branch). I don’t see any trace of gau2grid in the
> posted build log.

Thanks for the heads-up. It looks like psi4-1.2 is coming out RSN? So
we'll just switch to that then; I was going to try building the RC, but
didn't have time yet.

In any case, 
 
> * Why all the boost libs? Psi4 abandoned boost late 2016 (well before
> 1.1).

I see, we'll drop them then. I checked the psi4-1.1 release notes and it is
mentioned there in passing, but it's not very obvious to bystanders.
Missing build dependencies are obviously easy to figure out, but
deprecated ones are less likely to be noticed.
 
> * For production, libint should probably be built with MAX_AM_ERI = 6.

Ok.


Michael

Bug#877780: [Pkg-tigervnc-devel] Bug#877780: new upstream (1.8)

[Joachim Falk]

Hi Gianfranco,

Am 14.05.2018 um 11:54 schrieb Gianfranco Costamagna:
> On Thu, 5 Oct 2017 17:16:31 +0200 Daniel Baumann 
>  wrote:
>> Package: tigervnc
>> Severity: wishlist
>>
>> Hi,
>>
>> it would be nice if you could upgrade tigervnc to the current upstream
>> release (1.8).
>>
> 
> hello, ping?
there is a draft deb in https://salsa.debian.org/debian-remote-team/tigervnc.

> 
> G.
> 
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-tigervnc-devel

Regards

Joachim Falk
-- 
Dr.-Ing. Joachim Falk, Department of Computer Science 12
University of Erlangen-Nuremberg, D-91058 Erlangen / Germany
Tel. +49-9131-85-25143, Fax +49-9131-85-25149



signature.asc
Description: OpenPGP digital signature

Bug#898592: lintian: add tag debian-pyversions-is-obsolete

[Joseph Herlant]

Hi Chris,

On Mon, May 14, 2018 at 2:31 PM, Chris Lamb  wrote:
> (FYI I think your MR missed the debian/changelog entry as well as not
> shipping the two "pyversions" test fixtures, presumably because they
> were files "new" to Git?)

Oops, I indeed forgot the git add on the 2 test files and forgot to
update the changelog, sorry :\
Thanks a lot for taking care of that! :)

> Anyway, I've applied it in Git, pending upload:

Awesome, thanks a lot! :)

Joseph

Bug#898470: openssl says "Can't load /root/.rnd into RNG"

[Sebastian Andrzej Siewior]

On 2018-05-12 05:38:05 [+], Sander Jonkers wrote:
> Second command (goed wrong):
> # openssl req -new -x509 -key example.com.key -out example.com.cert -days 
> 3650 -subj /CN=example.com  
> Can't load /root/.rnd into RNG
> 140283178746304:error:2406F079:random number generator:RAND_load_file:Cannot 
> open file:../crypto/rand/randfile.c:88:Filename=/root/.rnd
> 
> I would have expected no error.

It does say error, but everything completes as expected, correct?

Sebastian

Bug#883734: half-fixed

[Rene Engelhard]

tag 883734 - pending
tag 883734 + wontfix
thanks

Hi,

this has been half-fixed. See 

libreoffice (1:6.1.0~alpha1-1) experimental; urgency=medium
[...]
  * merge from Ubuntu:
- debian/patches/hide-maths-desktop-file.patch: hide
  math icon from the shell (see #883734)

 -- Rene Engelhard   Fri, 27 Apr 2018 04:57:42 +

Keeping startcenter, though..

Regards,

Rene

Bug#869030: elixir: Please package v1.4

[Evgeny Golyshev]

I updated the package to the latest upstream version 1.6.5.
All of the work related to the package moved from alioth to salsa
(https://salsa.debian.org/eugulixes-guest/elixir-lang).
I had to temporarily disable the "gets and compiles dependencies for
Rebar" test because it caused some problems, but I'll try to find the
way how not to do that.
The source package and binary package were uploaded to mentors.debian.net.

$ dget 
https://mentors.debian.net/debian/pool/main/e/elixir-lang/elixir-lang_1.6.5-1.dsc

Dato, could you review the work and upload it to the archive?

Bug#898592: lintian: add tag debian-pyversions-is-obsolete

[Chris Lamb]

tags 898592 + pending
thanks

Hey Joseph,

> […]

Thanks so much for this. :)

(FYI I think your MR missed the debian/changelog entry as well as not
shipping the two "pyversions" test fixtures, presumably because they
were files "new" to Git?)

Anyway, I've applied it in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/98a9b69ec5a48bd59c0f3dfd0af3c11eb2dc98d3

  checks/cruft.desc   | 9 +
  checks/cruft.pm | 4 
  debian/changelog| 3 +++
  t/tests/cruft-python/debian/debian/pyversions   | 1 +
  t/tests/cruft-python/desc   | 1 +
  t/tests/cruft-python/tags   | 1 +
  t/tests/legacy-debconf/debian/debian/pyversions | 1 +
  t/tests/legacy-debconf/desc | 1 +
  t/tests/legacy-debconf/tags | 1 +
  9 files changed, 22 insertions(+)

Thanks again :)


Best wishes,

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

Bug#897061: [Pkg-javascript-devel] Bug#897061: libuv1: FTBFS on hurd-i386: PATH_MAX undefined (and kfreebsd as well)

[Samuel Thibault]

Hello,

Dominique Dumont, le mer. 09 mai 2018 15:47:29 +0200, a ecrit:
> On vendredi 27 avril 2018 21:39:04 CEST Samuel Thibault wrote:
> > libuv1 currently FTBFS on hurd-i386 because it unconditionally uses
> > PATH_MAX. The attached patch fixes this.
> > 
> > Also, the symbols file is only accurate for the Linux port, here is a
> > fix for that too.  Some symbols are really Linux-only in the source
> > code, they pose problem on kfreebsd as seen in buildd logs, so the patch
> > should fix the build there too.
> 
> I've applied both patches to libuv1 [1] . This will be uploaded with libuv1 
> 1.20.3 

Oops, it seems I missed some of my changes in the patch.  Here is a
fixed patch.

Samuel
Index: libuv1/src/unix/fs.c
===
--- libuv1.orig/src/unix/fs.c
+++ libuv1/src/unix/fs.c
@@ -416,6 +416,7 @@ static ssize_t uv__fs_scandir(uv_fs_t* r
 }
 
 
+#if _POSIX_VERSION < 200809L
 static ssize_t uv__fs_pathmax_size(const char* path) {
   ssize_t pathmax;
 
@@ -431,12 +432,19 @@ static ssize_t uv__fs_pathmax_size(const
 
   return pathmax;
 }
+#endif
 
 static ssize_t uv__fs_readlink(uv_fs_t* req) {
   ssize_t len;
   char* buf;
+  struct stat st;
+  int ret;
 
-  len = uv__fs_pathmax_size(req->path);
+  ret = lstat(req->path, );
+  if (ret != 0) {
+return -1;
+  }
+  len = st.st_size;
   buf = uv__malloc(len + 1);
 
   if (buf == NULL) {
@@ -463,9 +471,16 @@ static ssize_t uv__fs_readlink(uv_fs_t*
 }
 
 static ssize_t uv__fs_realpath(uv_fs_t* req) {
-  ssize_t len;
   char* buf;
 
+#if _POSIX_VERSION >= 200809L
+  buf = realpath(req->path, NULL);
+  if (buf == NULL) {
+return -1;
+  }
+#else
+  ssize_t len;
+
   len = uv__fs_pathmax_size(req->path);
   buf = uv__malloc(len + 1);
 
@@ -478,6 +493,7 @@ static ssize_t uv__fs_realpath(uv_fs_t*
 uv__free(buf);
 return -1;
   }
+#endif
 
   req->ptr = buf;
 

Bug#898672: iodine: iodine-client-start reports local address in seconds, e.g. as "7128sec"

[gregor herrmann]

Control: tag -1 + confirmed

On Mon, 14 May 2018 22:43:52 +0200, Axel Beckert wrote:

Hi Axel,

and thanks for your bug report.

I'm putting Barak in the loop as the author of the iodine-client-start
helper script.
 
> But what is odd is what iodine-client-start reports to me when starting
> up:
> 
> ~ # iodine-client-start
>  Creating IP-over-DNS tunnel over local network connection...
>  Local network interface: wlp3s0
>  Killing existing DNS tunnels...
>  Local address: 7128sec
>  Local network: 192.168.1.0/24
>  Local network router: 10.192.168.1
> 
> Please note the "Local address: 7128sec" line. It's always a different
> number, but it's always reported with the suffix "sec" — which is very
> odd.

Oops, that's odd indeed.
 
> Maybe some changes in the output format of net-tools or iproute2 caused
> this odd issue.

Sounds plausible.
And should be easy to check:

addr=$(ip -4 addr show dev ${interface} scope global \
| tail -1 | awk '{print $2}')
…
echo  Local address: ${addr}


% ip -4 addr show dev eth0 scope global | tail -1 | awk '{print $2}' 
forever

"forever" doesn't sound like a typical IPv4 address either but it
somehow matches your 7128sec (in the sense that it's a duration, and
my static vs. your (probably) DHCP address).


% ip -4 addr show dev eth0 scope global  
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
inet 192.168.0.33/24 brd 192.168.0.255 scope global eth0
   valid_lft forever preferred_lft forever

Looks like the line break causing the third line is new. *sigh*

Maybe "-oneline" would be helpful?

% ip -4 -oneline addr show dev eth0 scope global 
2: eth0inet 192.168.0.33/24 brd 192.168.0.255 scope global eth0\   
valid_lft forever preferred_lft forever

% ip -4 -oneline addr show dev eth0 scope global | awk '{print $4}'
192.168.0.33/24


And the whole script:

# iodine-client-start
 Creating IP-over-DNS tunnel over local network connection...
ERROR: No network interface found.

Oops.


if [ -z ${interface} ]; then
interface=$(ifconfig -a | egrep '^[^ ].*encap:Ethernet' \
| head -1 | awk '{print $1}')
fi


Ok, so the ifconfig output has changed as well (shouldn't affect you
as wlp3s0 is already found for you). *sigh*


When I set interface=eth0 manually in /etc/default/iodine-client,
I can run iodine-client-start successfully.


Good. So we need to fix the ip and ifconfig invocations one way or
another ...
Barak, do you have time to look into this issue?


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: Judy Collins: Send In The Clowns


signature.asc
Description: Digital Signature

Bug#898673: ITP: r-cran-brobdingnag -- Very Large Numbers in R

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-brobdingnag
  Version : 1.2
  Upstream Author : Robin K. S. Hankin
* URL : https://cran.r-project.org/package=Brobdingnag
* License : GPL-2
  Programming Lang: GNU R
  Description : Very Large Numbers in R
 Handles very large numbers in R.  Real numbers are held
 using their natural logarithms, plus a logical flag indicating
 sign.  The package includes a vignette that gives a
 step-by-step introduction to using S4 methods.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-brobdingnag
This package belongs to a set of dependencies for r-cran-brms which is
needed to upgrade r-cran-emmeans to the latest upstream version.

Bug#897138: O: anacron -- cron-like program that doesn't go by time

[Peter Eisentraut]

On 5/4/18 19:55, Sean Whitton wrote:
> On Sat, Apr 28, 2018 at 11:03:07PM +, Peter Eisentraut wrote:
>> The package is no longer maintained upstream,
> 
> Oh dear :(
> 
>> and it doesn't interact well with systemd.
> 
> Could you expand/provide some bug numbers, please?  What exactly can go
> wrong?

I think most of the "important" bugs are related to this and similar issues.

Bug#898666: ncurses-base: include screen.xterm-256color terminfo entry

[Axel Beckert]

Hi,

Sven Joachim wrote:
> Many terminal emulators default to TERM=xterm-256color these days, for
> instance those based on libvte-2.91 as well as KDE's konsole.  For
> better or worse, screen then by default sets TERM to
> screen.xterm-256color if the latter is present in the terminfo database.
> 
> Since terminal emulators setting TERM to xterm-256color are popular and
> screen is popular, it follows that screen.xterm-256color is also popular
> and thus should be included in ncurses-base.

Confirmed. Had reports about that combination recently, too, IIRC from
someone working on MacOS X locally.

> Opinions from the screen maintainers (in X-Debbugs-CC) would be
> welcome.

Sounds like a good idea to me, with the similar drawbacks in mind:

> The only downside I see is that one of the suggested workarounds for
> #854414 (installing ncurses-term locally) does no longer work,

There are also some cases, where uninstalling ncurses-term is a
proposed solution, which then wouldn't help respectively uninstalling
the according termcap entries will no more be possible.

> but I think uninstalling ncurses-term is not a great idea anyway.

Same here, but I know that there are people who think otherwise, see
e.g. https://pkgs.org/download/ncurses-term-considered-harmful

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#891956: Your mail

[Markus Koschany]

Am 14.05.2018 um 22:21 schrieb Rafi Rubin:
> The dependencies for 3.8.1-11 end up requiring libequinox-osgi-java >=
> 3.9.1 (through eclipse-rcp), which doesn't have
> /usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar
> 
> 
> Going back to stable, 3.8.1-10 for the eclipse packages at least catches
> that jar, but fails after an illegal reflection error.  Maybe it will
> work with an older jdk that's less picky, I haven't tried.
> 
> 
> 
> Is there any intent to package the newer versions of eclipse?  It looks
> like 3.8 is eol at this point.

We won't ship Elicpse 3.8 in Buster. The libequinox-osgi-java issue is
only one of the most obvious bugs in Eclipse and could be easily fixed
but the illegal reflection errors are all caused by Java 10. This
version is simply not ready for everything that is newer than OpenJDK 8.
The plan is to salvage the eclipse-platform package somehow which is a
build-dependency for some important packages but maintaining Eclipse and
its plugins requires more regular help from people who are interested in
keeping it in a good shape. At the moment those volunteers don't exist.

See also https://bugs.debian.org/681726

Markus



signature.asc
Description: OpenPGP digital signature

Bug#898619: [Pkg-zsh-devel] Bug#898619: zsh autocompletion does not deal gracefully with upgrades in the background

[Axel Beckert]

Control: tag -1 + confirmed
Control: severity -1 minor

Philipp Kern wrote:
> When zsh is upgraded behind the scenes, running shells will fail to
> autocomplete. When you press  you end up with this spam and no
> completion:
> 
> _setup:8: failed to load module `zsh/complist':
> /usr/lib/x86_64-linux-gnu/zsh/5.4.2/zsh/complist.so: cannot open
> shared object file: No such file or directory

Yes, this sounds very familiar and is IIRC a well-known issues since a
long time. I was though surprised to not find an already existing bug
report on this.

At least from my point of view, there seems no obvious solution than
to call "exec zsh" in the according shell.

> My gut feeling is that this is because I did not autocomplete in the
> old shell yet but now the module is gone.

Yes, that's the same conclusion I came to.

> At least with a new shell complist.so is only in /proc/$$/maps after
> an attempted completion.
>
> Would it be possible to make sure that the autocompletion system
> loads the module on startup rather than on-demand?

Good question. Maybe one of our zsh upstream gurus in the team knows
the answer on that.

> Is there a drawback to this approach?

In theory startup performance and maybe average memory completion. But
maybe there are others.

Another thing is that this might depend on your own .zshrc.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#898614: Apparmor should allow suggested paths

[Vincent Blut]

Control: tags -1 pending

On Mon, May 14, 2018 at 10:54:25AM +0200, Christian Ehrhardt wrote:

Package: chrony
Version: 3.3-1
Severity: normal

Hi,


Hello Christian,

the chrony.conf man page suggests a few more paths that are now yet 
allowed by the apparmor profile. I think it is fine to consider all too 
awkward use cases "special" and direct them to the local include for 
apparmor, but those that are in the man page we should consider 
"common" and allow (IMHO).


I very much agree! As a consequence, this should make our AppArmor 
profile even more usable by other distros.



Therefore I'd ask you to consider the following from [1]:
 # Support all paths suggested in the man page (LP: #1771028). Assume these
 # are common use cases; others should be set as local include (see below).
 # Configs using a 'chrony.' prefix like the tempcomp config file example
 /etc/chrony.* r,
 # Example gpsd socket is outside /{,var/}run/chrony/
 /{,var/}run/chrony.tty{,*}.sock rw,
 # To sign replies to MS-SNTP clients by the smbd daemon
 /var/lib/samba/ntp_signd r,
 /var/lib/samba/ntp_signd/{,*} rw,

[1]:
https://git.launchpad.net/~paelzer/ubuntu/+source/chrony/commit/?h=merge-cosmic-3.3-1=13339a04e989639c736b79b75b901be6ac561b76


Applied, thanks!


-- Christian Ehrhardt
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd


Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#898397: [pkg-go] Bug#898397: dh-make-golang: allow authentication to github API to avoid hitting limits

[Michael Stapelberg]

fixed in
https://github.com/Debian/dh-make-golang/commit/db00c3774281436cc182d81463fbc86d791ec019

On Fri, May 11, 2018 at 6:58 AM, Paul Wise  wrote:

> Package: dh-make-golang
> Version: 0.0~git20180410.bcfd5bf-1
> Severity: wishlist
>
> I packaged a bunch of dependencies for git-lab and then I started
> getting 403 errors from github URLs. It looks like dh-make-golang
> easily hits the github API rate limit for anonymous users.
>
> Allowing authenticated requests could help to avoid the limit.
>
> $ dh-make-golang make github.com/avast/retry-go
> 2018/05/11 12:51:52 Downloading "github.com/avast/retry-go/..."
> 2018/05/11 12:51:53 Determining upstream version number
> 2018/05/11 12:51:53 Package version is "1.0.2"
> 2018/05/11 12:51:53 Determining dependencies
> 2018/05/11 12:51:57 Could not determine long description for "
> github.com/avast/retry-go": unexpected HTTP status: got 403, want 200
> 2018/05/11 12:51:58 Could not determine copyright for "
> github.com/avast/retry-go": parsing time "" as "2006-01-02T15:04:05Z":
> cannot parse "" as "2006"
> 2018/05/11 12:51:59 Could not determine author for "
> github.com/avast/retry-go": parsing time "" as "2006-01-02T15:04:05Z":
> cannot parse "" as "2006"
> 2018/05/11 12:51:59 Could not determine long description for "
> github.com/avast/retry-go": unexpected HTTP status: got 403, want 200
> ...
>
> $ curl -s https://api.github.com/users/pabs3 | jq
> {
>   "message": "API rate limit exceeded for . (But here's the good
> news: Authenticated requests get a higher rate limit. Check out the
> documentation for more details.)",
>   "documentation_url": "https://developer.github.com/v3/#rate-limiting;
> }
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (800,
> 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700,
> 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8),
> LANGUAGE=en_AU.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages dh-make-golang depends on:
> ii  git   1:2.17.0-1
> ii  git-buildpackage  0.9.8
> ii  golang-any2:1.10~5
> ii  libc6 2.27-3
> ii  pristine-tar  1.42
>
> Versions of packages dh-make-golang recommends:
> ii  exim4-daemon-light [mail-transport-agent]  4.91-3
>
> dh-make-golang suggests no packages.
>
> -- no debconf information
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
> pkg-go-maintainers
>



-- 
Best regards,
Michael

Bug#898320: kdeconnect: 1.3.0 does not work with 1.8.2 android version

[Eric Valette]

On 5/11/18 10:42 PM, Eric Valette wrote:
Le 11 mai 2018 20:37:06 GMT+02:00, Diederik de Haas 
 a écrit :


On vrijdag 11 mei 2018 10:18:06 CEST Eric Valette wrote:

It can be on the client side (android both and 1.8.2 android version
both) but I have two differents. It could be network but no
firewall and
both machines do see each other using ssh, upnp, ...


With me it also fails from time to time and I have not found a pattern which
would explain it.
What very often helps, is starting kdeconnect explicitly on my phone and 
that
either fixes it or gives me a clue why it fails, which often means 
re-pairing
the devices.


Thanks for the hint. I started KDE connect explicitly, no help. I even 
added pc device by Name or ip without result. I'm good for a Wireshark 
session.


Well, I did a quick wireshark session, using my pĥone source ip address 
as a filter crietria on the PC running wireshark and I do see both 
devices (tel and PC) talking to each other, sending IPV4 payload message 
containing things like strings containing kdeconnect, PC name, tel name, 
various devices properties, but in the end they do not connect to each 
other. So this is not a simple "network problem".


I can send pcap traces if anyone speaks kde connect fluently ;-)

-- eric

Bug#898672: iodine: iodine-client-start reports local address in seconds, e.g. as "7128sec"

[Axel Beckert]

Package: iodine
Version: 0.7.0-7

Hi,

I can't get any iodine connection working with a wifi where DNS seems to
report the correct addresses for at least one of my machines. It may be
caused by some restrictions of that network, so this is not a "does not
work at all" report. (And I currently can't test it over another
connection where I control the local DNS cache.)

But what is odd is what iodine-client-start reports to me when starting
up:

~ # iodine-client-start
 Creating IP-over-DNS tunnel over local network connection...
 Local network interface: wlp3s0
 Killing existing DNS tunnels...
 Local address: 7128sec
 Local network: 192.168.1.0/24
 Local network router: 10.192.168.1

Please note the "Local address: 7128sec" line. It's always a different
number, but it's always reported with the suffix "sec" — which is very
odd.

Maybe some changes in the output format of net-tools or iproute2 caused
this odd issue.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), 
(111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), 
(105, 'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages iodine depends on:
ii  adduser3.117
ii  debconf [debconf-2.0]  1.5.66
ii  init-system-helpers1.51
ii  libc6  2.27-3
ii  libsystemd0238-4
ii  lsb-base   9.20170808
ii  net-tools  1.60+git20161116.90da8a0-2
ii  udev   238-4
ii  zlib1g 1:1.2.11.dfsg-1

iodine recommends no packages.

Versions of packages iodine suggests:
ii  dnsutils  1:9.11.3+dfsg-1
ii  fping 4.0-6
ii  gawk  1:4.1.4+dfsg-1+b1
ii  ipcalc0.41-5
ii  iproute2  4.16.0-2
ii  network-manager-iodine1.2.0-3
ii  network-manager-iodine-gnome  1.2.0-3
ii  oping 1.10.0-2+b1

-- debconf information:
  iodine/daemon_options:
  iodine/start_daemon: false

Bug#898671: ITP: libtest-more-utf8-perl -- enhance Test::More for UTF8-based projects

[Florian Schlichting]

Package: wnpp
Owner: Florian Schlichting 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtest-more-utf8-perl
  Version : 0.05
  Upstream Author : Mons Anderson 
* URL : https://metacpan.org/release/Test-More-UTF8
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : enhance Test::More for UTF8-based projects

Test::More::UTF8 is a simple extension for the widely used Test::More
module. By default, it will do a "binmode ':utf8'" on all of
Test::Builder's output handles thus enabling the easy use flagged
strings without warnings like "Wide character in print ..."

The package will be maintained under the umbrella of the Debian Perl Group.

libtest-more-utf8-perl is a new dependency of libtext-template-perl (from 1.53)

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#891956: Your mail

[Rafi Rubin]

The dependencies for 3.8.1-11 end up requiring libequinox-osgi-java >=
3.9.1 (through eclipse-rcp), which doesn't have
/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar


Going back to stable, 3.8.1-10 for the eclipse packages at least catches
that jar, but fails after an illegal reflection error.  Maybe it will
work with an older jdk that's less picky, I haven't tried.



Is there any intent to package the newer versions of eclipse?  It looks
like 3.8 is eol at this point.

Rafi

Bug#898663: python-testtools: Updates from Ubuntu

[Simon McVittie]

On Mon, 14 May 2018 at 14:36:22 -0400, Corey Bryant wrote:
> In Ubuntu, the attached patch was applied to achieve the following

(Not a maintainer of this particular package, just a team subscriber)

Thanks for your patch, but I think it indicates some misunderstandings
of autopkgtest; I'm hoping that by replying quickly, I can reduce delta
in Ubuntu packages other than this one, and avoid changes being upstreamed
back into Debian that shouldn't have been.

>   - d/tests/testsuite-*: Set PYTHONPATH when running tests.

Does this result in the version of testtools from the unpacked source
package being tested? If so, then it defeats one of the purposes of
autopkgtest (and one of the things that separates autopkgtests from
build-time testing), which is to test what is installed on the system
(for example in /usr/lib/python3/dist-packages).

If I modified testtools so that python3-testtools no longer contained
/usr/lib/python3/dist-packages, or the equivalent for python-testtools,
that should make it fail its autopkgtests. One of the things the
autopkgtests should be exercising is that the binary packages are not
empty, incorrectly structured or otherwise unusable. If you load the code
under test from the source package, then that won't be checked.

The autopkgtest seems to pass in Debian, so why was this change made?
If you are proposing a change, one of the things it should include is
why the change is desirable.

>   - d/control: Enable execution of autopkgtests.
...
> +XS-Testsuite: autopkgtest

This part is unnecessary. dpkg-dev in Debian stable automatically detects
Testsuite: autopkgtest from the existence of debian/tests/control,
and the XS- prefix hasn't been needed since before oldstable.

>   - d/tests/control: Drop python-testscenarios from Depends.

Again, please say why - if not in the changelog, then in the request to
make changes in Debian. This change makes sense, if python-testscenarios
is no longer used. However, if it is still used, and test coverage is
reduced (tests are skipped) without it, then it should not be dropped. I
don't know this particular package, so I can't say which one is true.

>   - d/p/fix-test-run.py.patch: Dropped. No longer needed.

This part seems to make sense, although the changelog entry is a little
misleading: the patch already wasn't being applied.

Thanks,
smcv

Bug#898663: python-testtools: Updates from Ubuntu

[Thomas Goirand]

On 05/14/2018 08:36 PM, Corey Bryant wrote:
> Package: python-testtools
> Version: 2.3.0-4
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu cosmic ubuntu-patch
> 
> Dear Maintainer,
> 
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   - d/control: Enable execution of autopkgtests.
>   - d/p/fix-test-run.py.patch: Dropped. No longer needed.
>   - d/tests/control: Drop python-testscenarios from Depends.
>   - d/tests/testsuite-*: Set PYTHONPATH when running tests.
> 
> Thanks for considering the patch.

Thanks for this, however, this:

+XS-Testsuite: autopkgtest

is to be removed in Debian (it produces a lintian warning). Is this
still in use in Ubuntu?

Cheers,

Thomas Goirand (zigo)

Bug#898664: [Pkg-mailman-hackers] Bug#898664: mailman3: [INTL:nl] Dutch translation of debconf messages

[Pierre-Elliott Bécue]

Le lundi 14 mai 2018 à 20:38:43+0200, Frans Spiesschaert a écrit :
>  
>  
> Package: mailman3 
> Severity: wishlist 
> Tags: l10n patch 
>  
> Dear Maintainer, 
>  
> Please find attached the updated Dutch translation of mailman3 debconf
> messages. 
> It has been submitted for review to the debian-l10n-dutch mailing
> list. 
> Please add it to your next package revision. 
> It should be put as debian/po/nl.po in your package build tree. 

Hi,

Thanks for your submission. Your updated file has been put into the
package's repository and will be part of the next release.

Thanks for your contribution!

Cheers,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#898656: [PKG-Openstack-devel] Bug#898656: python-stestr updates from ubuntu

[Thomas Goirand]

On 05/14/2018 07:54 PM, Corey Bryant wrote:
> Package: python-stestr
> Version: 1.1.0-1
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu cosmic ubuntu-patch
> 
> Dear Maintainer,
> 
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   - d/rules: Continue to run tests as we did in the past.

pkgos-dh_auto_install, through python setup.py, is installing the
package correctly, together with egg-info and such. Therefore, it's a
way better to test using that, rather than using files in $(CURDIR). So
I wonder why you would like to go back to what was done before.

>   - d/p/argparse-empty-array.patch: Deal with [] instead of 'None'
> when list is called with no additional parameters.

Thanks for this patch!

Cheers,

Thomas Goirand (zigo)

Bug#898669: java3d: FTBFS with Java 10 due to javah removal

[Emmanuel Bourg]

Source: java3d
Severity: serious
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java10

java3d fails to build with Java 10 due to the removal of javah:

  dependencyCheck:
   [echo] javahBuild.notRequired = ${javahBuild.notRequired}
   [echo] nativeOGLBuild.notRequired = ${nativeOGLBuild.notRequired}
  
  genJavah:
  [mkdir] Created dir: 
/build/1st/java3d-1.5.2+dfsg/j3d-core/build/linux-amd64/debug/native/javah/j3dcore
  
  BUILD FAILED
  /build/1st/java3d-1.5.2+dfsg/j3d-core/build.xml:436: The following error 
occurred while executing this line:
  /build/1st/java3d-1.5.2+dfsg/j3d-core/build.xml:440: The following error 
occurred while executing this line:
  /build/1st/java3d-1.5.2+dfsg/j3d-core/src/native/build.xml:361: javah does 
not exist under Java 10 and higher, use the javac task with nativeHeaderDir 
instead

Bug#898670: encfs crashes with malloc.c:2401 assertion

[Matej Zagiba]

Package: encfs
Version: 1.9.2-2+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

after uprading to encfs 1.9.2-2+b1 I was unable to mount encrypted filesystem.
encfs crashed with error:

encfs: malloc.c:2401: sysmalloc: Assertion `(old_top == initial_top (av) && 
old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse 
(old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.

Reverting back to encfs version 1.9.1-4 restored functionality.

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

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

Versions of packages encfs depends on:
ii  debconf [debconf-2.0]  1.5.66
ii  fuse   2.9.7-1
ii  libc6  2.27-3
ii  libfuse2   2.9.7-1
ii  libgcc11:8.1.0-3
ii  libssl1.1  1.1.0h-2
ii  libstdc++6 8.1.0-3
ii  libtinyxml2-4  4.0.1-1
ii  mount  2.32-0.1

encfs recommends no packages.

encfs suggests no packages.

Bug#898668: uwsgi shouldn't build-depends on gccgo-7

[Thomas Goirand]

Source: uwsgi
Version: 2.0.15-11
Severity: important


The last upload added a build-depends on gccgo-7. It was added because
otherwise the package FTBFS, but it doesn't seem to be the correct
solution. So I'm opening this bug as a reminder to myself and the rest
of the team.

Cheers,

Thomas Goirand (zigo)

Bug#895235: sugar-toolkit-gtk3 FTBFS: devlibs error: There is no package matching [libfribidi0-dev] and noone provides it

[Jeremy Bicha]

On Fri, Apr 20, 2018 at 3:02 AM, Adrian Bunk  wrote:
> Moving fribidi from Requires to Requires.private would fix this
> unnecessary linking.

I suggested that upstream, but the upstream developer was a bit
confused by the situation and just removed fribidi from the .pc file
completely unless someone can better explain what needs to be done.

Could someone interested in this issue follow up at
https://bugzilla.gnome.org/794570

Thanks,
Jeremy Bicha

Bug#895513: confirming 895513

[Jan Jeroným Zvánovec]

tags 895513 + confirmed wontfix
thanks

Thanks for reporting. The developers of Ghostscript have actually withdrawn
from removing the support for DELAYBIND and WRITESYSTEMDICT already in
November [1], and I have tested pstotext seems to work with Ghostscript 9.23
released in March [2], so the only problem seems to be with Ghostscript
version 9.22.

But it really worries me that we are talking about possible security issues in
software with no upstream activity for years. Not using SAFER when calling
Ghostscript has been considered security issue in Debian [3][4] and the
initiative to remove DELAYBIND and WRITESYSTEMDICT seems to be motivated by
the fact these options actually circumvent the SAFER.

While I could make a new package version requiring Ghostscript version at
least 9.23, I believe time has come to let the package go.  Ghostscript
developers published a warning which probably should not be just ignored, it
should trigger a security audit checking the correct usage of DELAYBIND and
WRITESYSTEMDICT in pstotext.  That's something I cannot do, I do not have the
knowledge and ambition to make up for the missing upstream - I am not an
experienced PostScript programmer.

Jan Jeroným Zvánovec

[1] 
https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=fa499a5809aab45b2891b5c8b2363d1bca890757
[2] https://www.ghostscript.com/doc/9.23/News.htm
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=319758
[4] https://people.debian.org/~koster/www/security/2005/dsa-792


-- 
Jan Jeroným Zvánovec, j...@zvano.net
Jabber: janjero...@jabber.cz
-- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Bug#898667: O: pstotext -- Extract text from PostScript and PDF files

[Jan Jeroným Zvánovec]

Package: wnpp
Severity: normal

I intend to orphan the pstotext package.

The package description is:
 pstotext extracts text (in the ISO 8859-1 character set) from a PostScript
 or PDF (Portable Document Format) file. Thus, pstotext is similar to the
 ps2ascii program that comes with ghostscript. The output of pstotext is
 however better than that of ps2ascii, because pstotext deals better with
 punctuation and ligatures.

There is no active upstream, last release was in 2004. 

I no longer use the software regularly and recent grave bug #895513 [1]
touches security issues which should be sorted out by someone who is actually
proficient in PostScript.

Anyone considering adopting this package should also consider adopting
and reviving the upstream.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895513

Bug#898055: ibverbs-providers is marked Multi-Arch: same but is not coinstallable

[Jason Gunthorpe]

On Sun, May 06, 2018 at 05:11:02AM -0400, Francois Gouget wrote:
> Package: ibverbs-providers
> Version: 17.1-2
> Severity: normal
> 
> Dear Maintainer,
> 
> Trying to install the amd64 and i386 versions of this package results in the 
> following error:
> 
> # apt-get install ibverbs-providers:amd64 ibverbs-providers:i386
> [...]
> Unpacking ibverbs-providers:i386 (17.1-1) ...
> Processing triggers for libc-bin (2.27-3) ...
> dpkg: dependency problems prevent configuration of ibverbs-providers:i386:
>  ibverbs-providers:amd64 (17.1-1) breaks libcxgb3-1 and is installed.
>   ibverbs-providers:i386 (17.1-1) provides libcxgb3-1.
>  ibverbs-providers:amd64 (17.1-1) breaks libipathverbs1 and is installed.
>   ibverbs-providers:i386 (17.1-1) provides libipathverbs1.
>  ibverbs-providers:amd64 (17.1-1) breaks libmlx4-1 and is installed.
>   ibverbs-providers:i386 (17.1-1) provides libmlx4-1.
>  ibverbs-providers:amd64 (17.1-1) breaks libmlx5-1 and is installed.
>   ibverbs-providers:i386 (17.1-1) provides libmlx5-1.
>  ibverbs-providers:amd64 (17.1-1) breaks libmthca1 and is installed.
>   ibverbs-providers:i386 (17.1-1) provides libmthca1.
>  ibverbs-providers:amd64 (17.1-1) breaks libnes1 and is installed.
>   ibverbs-providers:i386 (17.1-1) provides libnes1.
> 
> dpkg: error processing package ibverbs-providers:i386 (--configure):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  ibverbs-providers:i386
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> 
> So the source of the issue seems to be that ibverbs-providers:
> * Provides a bunch of virtual packages
> * Breaks + Replaces these virtual packages

They are not virtual packages, but obsolete real packages that this
package has replaced.

> Apt seems to consider that this means ibverbs-providers:amd64 breaks 
> ibverbs-providers:i386 through the virtual packages which prevents them from 
> being 
> coinstalled.

Curiously, this isn't apt complaining, but dpkg. This indicates there
is a apt bug, as it should never invoke dpkg in a way where it fails
like this.

> Note that, based on 7.6.2, the usual pattern for virtual packages would be 
> Provides + Conflicts + Replaces:

Well, that would still cause problems as Conflicts/Provides will still fail.

I think the correct solution is this text:

 If a relationship field has a version number attached, only real
 packages will be considered to see whether the relationship is
 satisfied (or the prohibition violated, for a conflict or
 breakage). In other words, if a version number is specified, this is a
 request to ignore all Provides for that package name and consider only
 real packages. The package manager will assume that a package
 providing that virtual package is not of the "right" version. A
 Provides field may not contain version numbers, and the version number
 of the concrete package which provides a particular virtual package
 will not be considered when considering a dependency on or conflict
 with the virtual package name.[52]

Ie add a version to the breaks so that dpkg will ignore the Provides
when matching it. This should allow multiple packages to provide at
once..

At least it suggests that is how Conflicts will work, and I don't
recall off hand :)

Jason

Bug#898557: RFS: doclifter/2.17-1 [QA upload]

[Fabian Wolff]

On Mon, May 14, 2018 at 08:10:24PM +0200, Tobias Frost wrote:
> On Mon, May 14, 2018 at 05:33:03PM +0200, Fabian Wolff wrote:
> > On Mon, May 14, 2018 at 11:03:58AM -0400, Sergio Durigan Junior wrote:
> > > Thanks!  And yeah, I'd say it's OK to just start from scracth in this
> > > case.
> > 
> > I have imported every version I found on snapshot.debian.org into the
> > repository, so at least some history is available now.
> 
> That sounds you've done it manually... In this case
> gbp import-dscs --debsnap will be your friend ;.)

Yes, I did indeed do it manually ... Thanks for the hint!

Bug#895718: python-pyqt5: import PyQt5.QtCore fails

[Lisandro Damián Nicanor Pérez Meyer]

On 14 May 2018 at 16:24, Mattia Rizzolo  wrote:
> On Mon, May 14, 2018 at 01:55:55PM -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
>> Quoting from the above:
>>
>>   The rationale of this system call is to provide resiliance against
>>   file descriptor exhaustion attacks, where the attacker consumes all
>>   available file descriptors, forcing the use of the fallback code where
>>   /dev/[u]random is not available.  Since the fallback code is often not
>>   well-tested, it is better to eliminate this potential failure mode
>>   entirely.
>>
>> So if we disable it we disable a feature providing a more robust method to
>> provide randomness to ours users.
>
> Reading this sounds like the presence of the syscall could be tested at
> runtime, and if present used and if not fall back to dev/urandom?

Patches directly at upstream (due to copyright issues) are welcomed :-)

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

Bug#894159: ICU transition: ICU version is part of the boost ABI

[Adrian Bunk]

On Mon, May 14, 2018 at 07:13:57PM +0200, Emilio Pozuelo Monfort wrote:
> On 13/05/18 16:08, Adrian Bunk wrote:
> > Control: reassign 898465 src:icu 60.1-1
> > Control: retitle 898369 boost: ICU version used is part of the ABI
> > Control: retitle 898465 ICU must not migrate to testing before the boost 
> > ABI breakage is resolved
> > Control: affects 898369 libmapnik3.0 viking
> > Control: block 898465 by 898369
> > Control: block 894159 by 898369 898465
> > 
> > On Thu, May 10, 2018 at 06:06:08PM -0300, Thadeu Lima de Souza Cascardo 
> > wrote:
> >> Source: boost1.62
> >> Version: 1.62.0+dfsg-5+b2
> >> Severity: serious
> >>
> >> After upgrading boost1.62 to 1.62.0+dfsg-5+b2, ncmpcpp does not start
> >> anymore.
> >>
> >> $ ncmpcpp
> >> ncmpcpp: symbol lookup error: ncmpcpp: undefined symbol: 
> >> _ZNK5boost16re_detail_10620031icu_regex_traits_implementation12do_transformEPKiS3_PKN6icu_578CollatorE
> >> ...
> > 
> > boost::re_detail_106200::icu_regex_traits_implementation::do_transform(int 
> > const*, int const*, icu_57::Collator const*) const
> > 
> > Yes, boost makes the ICU version it uses part of its ABI.
> > 
> > There is no obvious good way forward, the RC bug in ICU will ensure that 
> > the breakage won't migrate to testing before this got sorted out.
> 
> boost1.62 should:
> - bump the libicu-dev build-dependency to ensure it builds against icu 60
> - add breaks against the rdeps that use the affected symbols
>...

For the opposite problem this also requires:
- boost1.62 to add versions to the shlibs for the affected libraries 
- binNMUs of all users of these symbols to force a dependency on the
  icu 60 boost

> Cheers,
> Emilio

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#895718: python-pyqt5: import PyQt5.QtCore fails

[Mattia Rizzolo]

On Mon, May 14, 2018 at 01:55:55PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Quoting from the above:
> 
>   The rationale of this system call is to provide resiliance against
>   file descriptor exhaustion attacks, where the attacker consumes all
>   available file descriptors, forcing the use of the fallback code where
>   /dev/[u]random is not available.  Since the fallback code is often not
>   well-tested, it is better to eliminate this potential failure mode
>   entirely.
> 
> So if we disable it we disable a feature providing a more robust method to
> provide randomness to ours users.

Reading this sounds like the presence of the syscall could be tested at
runtime, and if present used and if not fall back to dev/urandom?

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#875790: fixed in scilab 6.0.1-2

[Emilio Pozuelo Monfort]

On Fri, 04 May 2018 05:05:48 + Julien Puydt  wrote:
>  .
>[ Emmanuel Bourg ]
>* Fixed the build failure with Java 9 (Closes: #875790)
>  .
>[ Julien Puydt ]
>* Depend on unversioned tcl/tk (Closes: #803526)
>* Force use of java 8 since later versions aren't supported (Closes: 
> #875790)

So is the build really fixed with Java 9 now? If so, why force Java 8? The build
is failing on i386 with Java 8, so it may be good to go back to default Java (9
at the moment) to attempt to fix the build.

Cheers,
Emilio

Bug#898666: ncurses-base: include screen.xterm-256color terminfo entry

[Sven Joachim]

Package: ncurses-base
Version: 6.1+20180210-3
Severity: wishlist

Many terminal emulators default to TERM=xterm-256color these days, for
instance those based on libvte-2.91 as well as KDE's konsole.  For
better or worse, screen then by default sets TERM to
screen.xterm-256color if the latter is present in the terminfo database.

Since terminal emulators setting TERM to xterm-256color are popular and
screen is popular, it follows that screen.xterm-256color is also popular
and thus should be included in ncurses-base.

Opinions from the screen maintainers (in X-Debbugs-CC) would be welcome.
The only downside I see is that one of the suggested workarounds for
#854414 (installing ncurses-term locally) does no longer work, but I
think uninstalling ncurses-term is not a great idea anyway.

Bug#898641: variety: please package upstream variety 0.6.8

[James Lu]

Hello,

Actually, I (the maintainer here) was the same person who synced the
packaging back upstream, so it wouldn't make much of a difference
personally. :)

FWIW 0.6.8 was a bit rushed and led to some regressions[1], so I'll skip
that and upload the next version (0.6.9) which I plan to tag today.

[1]:
https://github.com/varietywalls/variety/commit/b4f12693bddf5fefc1e41d6e22903c4f5273f348

Best,
James

On 2018-05-14 07:50 AM, shirish शिरीष wrote:
> Package: variety
> Version: 0.6.7-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Just saw that the upstream has made a new release of variety and also
> done some changes in the /debian/ directory which should make for
> easier packaging. See
> https://github.com/varietywalls/variety/tree/master/debian. Look
> forward to see the new version in Debian soonish.
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (500, 'unstable-debug'), (500,
> 'testing-debug'), (100, 'experimental'), (100, 'unstable'), (1,
> 'experimental-debug')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages variety depends on:
> ii  gir1.2-gdkpixbuf-2.0 2.36.11-2
> ii  gir1.2-gexiv2-0.10   0.10.8-1
> ii  gir1.2-glib-2.0  1.56.1-1
> ii  gir1.2-gtk-3.0   3.22.29-3
> ii  gir1.2-notify-0.70.7.7-3
> ii  gir1.2-pango-1.0 1.42.0-1
> ii  imagemagick  8:6.9.9.39+dfsg-1
> ii  imagemagick-6.q16 [imagemagick]  8:6.9.9.39+dfsg-1
> ii  python   2.7.15~rc1-1
> ii  python-bs4   4.6.0-1
> ii  python-cairo 1.16.2-1
> ii  python-configobj 5.0.6-2
> ii  python-dbus  1.2.6-1
> ii  python-gi-cairo  3.28.2-1
> ii  python-pil   4.3.0-2
> ii  python-pycurl7.43.0.1-0.2
> ii  python-requests  2.18.4-2
> ii  python2.72.7.15-1
> 
> Versions of packages variety recommends:
> ii  gir1.2-appindicator3-0.1  0.4.92-5
> ii  python-httplib2   0.9.2+dfsg-1
> 
> Versions of packages variety suggests:
> ii  feh
> 2.23.2-1
> pn  gnome-shell-extension-appindicator | gnome-shell-extension-top-ic  
> 
> -- no debconf information
> 



signature.asc
Description: OpenPGP digital signature

Bug#898665: [installation-guide] change "Alioth" and "svn" to "Salsa" and "git"

[Holger Wansing]

Package: installation-guide
Severity: serious


Since the source code repository has moved from Alioth (svn repo) to Salsa
(now git), the manual needs some editing to follow this:
Alioth -> Salsa
svn -> git
and relevant URLs

It should be possible to easily sync that changes to translations as well.



So long
Holger

-- 

Created with Sylpheed 3.2.0 under the new
D E B I A N   L I N U X   7 . 0   W H E E Z Y !

Registered Linux User #311290 - https://linuxcounter.net/

Bug#890607: hhvm: Please enable arm64 builds for hhvm

[Matthias Klose]

Control: tags -1 + moreinfo

this doesn't work, see
https://launchpad.net/ubuntu/+source/hhvm/3.24.7+dfsg-2ubuntu1/+build/14879986

/tmp/camlasm597ecf.s: Assembler messages:
/tmp/camlasm597ecf.s:153: Error: immediate out of range
File "parser/full_fidelity_validated_syntax.ml", line 1:
Error: Assembler error, input left in file /tmp/camlasm597ecf.s
Command exited with code 2.
Makefile:193: recipe for target '_build/hack.stamp' failed
make[5]: *** [_build/hack.stamp] Error 10
make[5]: Leaving directory '/<>/hhvm-3.24.7+dfsg/hphp/hack/src'

Bug#898604: geeqie: paste of image from GNOME screenshot tool causes crash

[Andreas Ronnquist]

On Mon, 14 May 2018 13:10:53 +0800
Paul Wise  wrote:

>When I take a screenshot using the GNOME screenshot tool and then open
>geeqie and press Ctrl+v to paste the image, I get a crash from geeqie.
>I don't know if this is a new crash because I think this is the first
>time I've tried pasting into geeqie.
>

Hi!

Please notice that Ctrl+V isn't for pasting, but for "View in New
Window" - see the "View" menu in geeqie.

With that said, of course the program shouldn't crash in this case.
I can confirm the crash - If I Ctrl+V when the program shows an image,
it doesn't crash, but opens the image in a new window. But if use the
folder view and go to a folder where there isn't any images, the
program crashes when pressing Ctrl+V.

Thanks for your report!
-- Andreas Rönnquist
gus...@debian.org

Bug#898664: mailman3: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: mailman3 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of mailman3 debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#898165: linux-image-3.16.0-6-amd64: can't mount NFS shares via nfs referrals

[Moritz Schlarb]

Hi Pradeep,

thanks for your response.

On 14.05.2018 17:48, Pradeep wrote:
> The patch is for NFS client side bug where it was initializing the
> attributes to zero if NFS4ERR_MOVED is returned in LOOKUP; but referral
> was not followed later. This only happens with NFSv4 server and the
> specific error (NFS4ERR_MOVED). 
> 
> It is not related to nfs-ganesha - it can be reproduced with kernel NFS
> as well.
> 
> Are you seeing any regressions with the patch?

I would think so.
Since that patch arrived in Kernel 3.16, it would not even try to follow
the referral as it did before. When I just revert this specific patch
for the kernel, it works.

On the referrer server, we use nfs-ganesha 2.4.5-2 with Christoph's
patch for nfs referral
(https://sources.debian.org/src/nfs-ganesha/2.4.5-2%7Ebpo9+1/debian/patches/nfs-ganesha-nfsrefer.patch).
The actual NFS server is a NetApp cluster.

I'm not so sure right now if it is not maybe a bug in nfs-ganesha (that
maybe even got fixed in the meantime), so I thought, maybe you know.

Thanks,
Moritz



signature.asc
Description: OpenPGP digital signature

Bug#898663: python-testtools: Updates from Ubuntu

[Corey Bryant]

Package: python-testtools
Version: 2.3.0-4
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  - d/control: Enable execution of autopkgtests.
  - d/p/fix-test-run.py.patch: Dropped. No longer needed.
  - d/tests/control: Drop python-testscenarios from Depends.
  - d/tests/testsuite-*: Set PYTHONPATH when running tests.

Thanks for considering the patch.


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

Kernel: Linux 4.15.0-20-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-testtools-2.3.0/debian/control 
python-testtools-2.3.0/debian/control
--- python-testtools-2.3.0/debian/control   2018-04-13 10:37:46.0 
-0400
+++ python-testtools-2.3.0/debian/control   2018-05-14 14:34:30.0 
-0400
@@ -41,6 +41,7 @@
 Vcs-Git: https://salsa.debian.org/openstack-team/python/python-testtools.git
 Vcs-Browser: https://salsa.debian.org/openstack-team/python/python-testtools
 Homepage: https://github.com/testing-cabal/testtools
+XS-Testsuite: autopkgtest
 
 Package: python-testtools
 Architecture: all
diff -Nru python-testtools-2.3.0/debian/patches/fix-test-run.py.patch 
python-testtools-2.3.0/debian/patches/fix-test-run.py.patch
--- python-testtools-2.3.0/debian/patches/fix-test-run.py.patch 2018-04-13 
10:37:46.0 -0400
+++ python-testtools-2.3.0/debian/patches/fix-test-run.py.patch 1969-12-31 
19:00:00.0 -0500
@@ -1,38 +0,0 @@
-Description: Do not run test_run_list_failed_import
- This test is broken, let's just remove it.
-Author: Thomas Goirand 
-Forwarded: no
-Last-Update: 2015-07-09
-
 python-testtools-1.8.0.orig/testtools/tests/test_run.py
-+++ python-testtools-1.8.0/testtools/tests/test_run.py
-@@ -191,29 +191,6 @@ class TestRun(TestCase):
- testtools.runexample.TestFoo.test_quux
- """, out.getvalue())
- 
--def test_run_list_failed_import(self):
--broken = self.useFixture(SampleTestFixture(broken=True))
--out = StringIO()
--# XXX: http://bugs.python.org/issue22811
--unittest2.defaultTestLoader._top_level_dir = None
--exc = self.assertRaises(
--SystemExit,
--run.main, ['prog', 'discover', '-l', broken.package.base, 
'*.py'], out)
--self.assertEqual(2, exc.args[0])
--self.assertThat(out.getvalue(), DocTestMatches("""\
--Failed to import test module: runexample
--Traceback (most recent call last):
--  File ".../loader.py", line ..., in _find_test_path
--package = self._get_module_from_name(name)
--  File ".../loader.py", line ..., in _get_module_from_name
--__import__(name)
--  File ".../runexample/__init__.py", line 1
--class not in
--...^...
--SyntaxError: invalid syntax
--
--""", doctest.ELLIPSIS))
--
- def test_run_orders_tests(self):
- self.useFixture(SampleTestFixture())
- out = StringIO()
diff -Nru python-testtools-2.3.0/debian/patches/series 
python-testtools-2.3.0/debian/patches/series
--- python-testtools-2.3.0/debian/patches/series2018-04-13 
10:37:46.0 -0400
+++ python-testtools-2.3.0/debian/patches/series2018-05-14 
14:33:56.0 -0400
@@ -1,2 +1 @@
 neutralize-failing-test.patch
-#fix-test-run.py.patch
diff -Nru python-testtools-2.3.0/debian/tests/control 
python-testtools-2.3.0/debian/tests/control
--- python-testtools-2.3.0/debian/tests/control 2018-04-13 10:37:46.0 
-0400
+++ python-testtools-2.3.0/debian/tests/control 2018-05-14 14:34:06.0 
-0400
@@ -1,7 +1,7 @@
 Tests: testsuite-py2
-Depends: python-testtools, python-testscenarios
+Depends: python-testtools
 Restrictions: allow-stderr
 
 Tests: testsuite-py3
-Depends: python3-testtools, python3-testscenarios
+Depends: python3-testtools
 Restrictions: allow-stderr
diff -Nru python-testtools-2.3.0/debian/tests/testsuite-py2 
python-testtools-2.3.0/debian/tests/testsuite-py2
--- python-testtools-2.3.0/debian/tests/testsuite-py2   2018-04-13 
10:37:46.0 -0400
+++ python-testtools-2.3.0/debian/tests/testsuite-py2   2018-05-14 
14:34:14.0 -0400
@@ -1,2 +1,2 @@
 #!/bin/sh -e
-python -m testtools.run testtools.tests.test_suite
+PYTHONPATH=`pwd` python -m testtools.run testtools.tests.test_suite
diff -Nru python-testtools-2.3.0/debian/tests/testsuite-py3 
python-testtools-2.3.0/debian/tests/testsuite-py3
--- python-testtools-2.3.0/debian/tests/testsuite-py3   2018-04-13 
10:37:46.0 -0400
+++ python-testtools-2.3.0/debian/tests/testsuite-py3   2018-05-14 
14:34:14.0 -0400
@@ -1,2 +1,2 @@
 #!/bin/sh -e
-python3 -m testtools.run 

Bug#898662: linux-support-4.9.0-6: If I try an installation at debian streatch starting from the old old-stable (debian jessie 8) I have no problem with the network card in question. If instead I try

[root]

Package: linux-support-4.9.0-6
Version: 26
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 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)
Good evening everyone. I have the following problem: I have a mainboard asus 
h81m-c with a network card 3: 00.0 Ethernet controller: Realtek Semiconductor 
Co., Ltd. RTL8111 / 8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c).
If I try an installation at debian streatch starting from the old old-stable 
(debian jessie 8) I have no problem with the network card in question. If 
instead I try a clean installation using the firmware-9.4.0-amd64-netinst.iso 1 
time out of 40 times I can get the dynamic IP address from the router. All the 
other times I can not get anything and therefore unable to go on with the 
installation. Even using a static IP address of the same / 24 class I can not 
ping the router. I have this situation with testing too. With other 
distributions (ubuntu, centos, freeebsd, fedora) I have no problem whatsoever. 
I do not know how to move anymore. I ask for help. Even if I had to open a 
bug-reporting on which package should I show it? On the kernel, on the 
debian-installer?

Bug#898661: network-manager-openconnect-gnome: Unnecessary dependencies break upgrade

[Andrew Perrin]

Package: network-manager-openconnect-gnome
Version: 1.2.4-1
Severity: important

Dear Maintainer,

The pacakge includes requirements for several packages that are not available
in current testing:

 network-manager-openconnect-gnome : Depends: libnm-glib-vpn1 (>= 0.7.999) but
it is not installable
 Depends: libnm-glib4 (>= 0.7.999) but it
is not installable
 Depends: libnm-util2 (>= 0.8.998) but it
is not installable



However intalling manually with dpkg --force-depends works fine, and the
package works. It would be helpful to remove these dependencies, since apt-get
blocks on these dependencies which makes updating the system difficult or
impossible.

Thanks.



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

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

Versions of packages network-manager-openconnect-gnome depends on:
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-3
ii  libcairo-gobject21.15.10-3
ii  libcairo21.15.10-3
ii  libdbus-1-3  1.12.8-2
ii  libdbus-glib-1-2 0.110-2
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libglib2.0-0 2.56.1-2
ii  libgtk-3-0   3.22.29-3
pn  libnm-glib-vpn1  
pn  libnm-glib4  
pn  libnm-util2  
ii  libnm0   1.10.6-3
ii  libopenconnect5  7.08-3
ii  libpango-1.0-0   1.42.0-1
ii  libpangocairo-1.0-0  1.42.0-1
ii  libsecret-1-00.18.6-1
ii  libxml2  2.9.4+dfsg1-6.1
ii  network-manager-openconnect  1.2.4-1

network-manager-openconnect-gnome recommends no packages.

network-manager-openconnect-gnome suggests no packages.

-- no debconf information

Bug#288763: Calling apt-list-changes via cron-apt

[Ola Lundqvist]

Hi

Sorry for late reply. Thank you for the contribution. I'll consider adding
this suggestion to the documentation of the package. For the time being it
is good that it is here in the bug report.

Best regards

// Ola

On 4 April 2018 at 17:01, Alexander Reichle-Schmehl 
wrote:

> Hi!
>
> I recently run into the same problem, found that ticket, found a work
> around, and thought I update the ticket, as my workaround might be
> useful for someone else, too.
>
> The basic idea is to call apt-listchanges over all files downloaded to
> /var/cache/apt/archives. To avoid getting the changelog of cruft
> collected in that directory, I first run apt-get.
>
> To do that, I created /etc/cron-apt/action.d/1-clean which contains:
> clean
>
> I also created /etc/cron-apt/config.d/4-listchanges containing:
> APTCOMMAND="/usr/bin/apt-listchanges"
> OPTIONS=""
>
> And finnally I created /etc/cron-apt/4-listchanges containing:
> /var/cahce/apt/archives/*.deb
>
>
> WARNING: Using this solution might not be what you want, as you'll
> download package updates daily, just to remove them the next day from
> the cache and downloading them again (unless you install them in time).
> It might also remove packages from the archive cache, you might want to
> keep.
>
>
>
> Best regards,
>   Alexander
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#898448: Makes vinagre segfault on authentication failure

[Josh Triplett]

On Mon, May 14, 2018 at 01:49:57PM +, Mike Gabriel wrote:
> HI Josh,
> 
> On  Fr 11 Mai 2018 21:02:04 CEST, Josh Triplett wrote:
> 
> > Package: libfreerdp2-2
> > Version: 2.0.0~git20180411.1.7a7b1802+dfsg1-1
> > Severity: important
> > 
> > After upgrading libfreerdp2-2, authentication failures (mistyped
> > password) started causing segfaults:
> > 
> > May 11 11:41:29 jtriplet-mobl2 vinagre.desktop[9277]: [11:41:29:080]
> > [9277:9277] [ERROR][com.freerdp.core] - freerdp_set_last_error
> > ERRCONNECT_LOGON_FAILURE [0x00020014]
> > May 11 11:41:29 jtriplet-mobl2 vinagre.desktop[9277]: [11:41:29:080]
> > [9277:9277] [ERROR][com.freerdp.core.rdp] - rdp_recv_callback:
> > CONNECTION_STATE_NLA - nla_recv_pdu() fail
> > May 11 11:41:29 jtriplet-mobl2 vinagre.desktop[9277]: [11:41:29:080]
> > [9277:9277] [ERROR][com.freerdp.core.transport] - transport_check_fds:
> > transport->ReceiveCallback() - -1
> > May 11 11:41:29 jtriplet-mobl2 kernel: vinagre[9277]: segfault at 9 ip
> > 7fbc84bf6ab0 sp 7ffc05377a40 error 4 in
> > libfreerdp2.so.2.0.0[7fbc84b1c000+137000]
> > 
> 
> I contacted one of the upstream authors on this.
> 
> Can you provide a gdb backtrace ("bt full") to get some more insight what
> happens to vinagre?

Sure. I can easily reproduce this, just by entering an incorrect
username and password.

Thread 1 "vinagre" received signal SIGSEGV, Segmentation fault.
clear_context_free (clear=0x1) at ./libfreerdp/codec/clear.c:1216
1216./libfreerdp/codec/clear.c: No such file or directory.
(gdb) bt full
#0  0x7528bab0 in clear_context_free (clear=0x1) at 
./libfreerdp/codec/clear.c:1216
clear = 0x1
#1  0x7522a9cd in codecs_free (codecs=0x55dd62b0) at 
./libfreerdp/core/codecs.c:213
#2  0x75224c77 in freerdp_disconnect (instance=0x55d14d00) at 
./libfreerdp/core/freerdp.c:508
rc = 1
rdp = 
#3  0x55584769 in vinagre_rdp_tab_dispose (object=0x55cfe920) at 
plugins/rdp/vinagre-rdp-tab.c:182
rdp_tab = 0x55cfe920
priv = 0x55cfe730
#4  0x75be1e03 in g_object_unref () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5  0x76b5da39 in gtk_container_remove () at 
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#6  0x55570748 in vinagre_notebook_close_tab (nb=0x55b06230, 
tab=0x55cfe920) at vinagre/vinagre-notebook.c:697
position = 0
notebook = 0x55b06230
previous_active_tab = 0x55cfe920
__func__ = "vinagre_notebook_close_tab"
#7  0x55583074 in idle_close (tab=0x55cfe920) at 
plugins/rdp/vinagre-rdp-tab.c:272
#8  0x759030f5 in g_main_context_dispatch () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x759034c0 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x7590354c in g_main_context_iteration () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x75ec3cdd in g_application_run () at 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#12 0x555655cf in main (argc=1, argv=0x7fffdf68) at 
vinagre/vinagre-main.c:196
app = 0x557e91a0
res = 

Bug#897653: tar 1.30 breaks pristine-tar

[Bdale Garbee]

Paul Eggert  writes:

> On 05/14/2018 07:56 AM, Antonio Terceiro wrote:
>> I still need to study the  > code a bit further to try to come up with a 
>> better suggestion.
> Sorry, the only suggestion I can make is that you should just use the 
> new GNU tar. The old one was obviously busted and it generated busted 
> tarballs.

Antonio, given this, I wonder if maybe the right approach might be to
come up with a work-around so that pristine-tar can collaborate with tar
to successfully extract older tarballs from git repos?  I could imagine
a Debian-specific patch that adds a long-form command-line option to do
the equivalent of reverting that one patch, and a mod to pristine-tar to
try that option if reproducing the tarball fails before giving up
entirely?  

In this way, Debian developers could continue to be able to rebuild and
work on packages with older tarballs captured using pristine-tar, but
all new work would be in the correct format.  This means all developers
would want to get to tar 1.30 or later as soon as possible, but at least
we wouldn't lose access to all our existing work.

What do you think?

Bdale


signature.asc
Description: PGP signature

Bug#898192: [Pkg-mailman-hackers] Bug#898192: mailman: [INTL:pt] Updated Portuguese translation for debconf messages

[Pierre-Elliott Bécue]

Le mardi 08 mai 2018 à 14:16:02+0100, Traduz - DebianPT a écrit :
> Package: mailman
> Version: 3_3.1.1-9
> Tags: l10n, patch
> Severity: wishlist
> 
> Updated Portuguese translation for mailman's debconf messages.
> Feel free to use it.
> 
> For translation updates please contact 'Last Translator' or the
> Portuguese Translation Team .

Hi,

Thanks for your submission. Your translation file has been updated and will
be part of the next release of mailman3.

Cheers!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#898557: RFS: doclifter/2.17-1 [QA upload]

[Tobias Frost]

On Mon, May 14, 2018 at 05:33:03PM +0200, Fabian Wolff wrote:
> On Mon, May 14, 2018 at 11:03:58AM -0400, Sergio Durigan Junior wrote:
> > Thanks!  And yeah, I'd say it's OK to just start from scracth in this
> > case.
> 
> I have imported every version I found on snapshot.debian.org into the
> repository, so at least some history is available now.

That sounds you've done it manually... In this case
gbp import-dscs --debsnap will be your friend ;.)

-- 
tobi

Bug#898660: Telegram can't connect to the servers

[Evgeny Kapun]

Package: telegram-desktop
Version: 1.2.17-1
Severity: important
Forwarded: https://github.com/telegramdesktop/tdesktop/issues/4652
Control: found -1 1.1.23-1~bpo9+1

There is an issue in Telegram Desktop which can make it impossible to connect 
to the servers [1]. This issue doesn't affect the latest upstream version, so 
this should probably be resolved by updating the Debian version.

[1] https://github.com/telegramdesktop/tdesktop/issues/4652

Bug#898658: f-irc gets SEGV with TERM=xterm-256color

[nozzy123nozzy]

Package: f-irc
Version: 1.36-1+b3
Severity: serious

Dear Maintainer,

 This version of f-irc always gets SEGV when TERM environmental
variable set to xterm-256color ,which is default under gnome-terminal.

 However, when I set TERM  to xterm,vt100 or kterm,f-irc seems to work
well.

 Does anyone fix this problem?

 Thanks in advance,
 Takahide Nojima

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

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

Versions of packages f-irc depends on:
ii  libc6 2.27-3
ii  libncursesw6  6.1+20180210-3
ii  libtinfo6 6.1+20180210-3

f-irc recommends no packages.

Versions of packages f-irc suggests:
pn  znc  

-- no debconf information

Bug#898659: mark symbol as optional, not found when building with -O3

[Matthias Klose]

Package: src:dde-qt-dbus-factory
Version: 1.0.1-2
Tags: patch

Mark symbol as optional, not found when building with -O3.

patch at
http://launchpadlibrarian.net/370217494/dde-qt-dbus-factory_1.0.1-2_1.0.1-2ubuntu1.diff.gz

Bug#898657: RFS: fonts-myanmar/1.0-1 sponsorship and upstream maintainer [ITP, ITA, NMU]

[kokoye2007]

Package: fonts-myanmar/1.0-1
Severity: normal

Dear Maintainer, Mentor and Developer,

  I am looking for a sponsor for my package "fonts-myanmar"
   also want official upstream for debian and ubuntu.
  
   Package name: fonts-myanmar
   Version : 1.0-1
   Upstream Author : kokoye2...@gmail.com
   URL : https://launchpad.net/ttf-burmese-fonts/
   : https://mentors.debian.net/package/fonts-myanmar
   License : gpl2+
   Section : fonts

  It builds those binary packages:

fonts-myanmar - ttf myanmar fonts:
 fonts-myanmar-angoun - myanmar fonts: angoun;
 fonts-myanmar-ayar - ttf myanmar fonts: ayar;
 fonts-myanmar-chatu - myanmar fonts: chatu;
 fonts-myanmar-chatulight - myanmar fonts: chatulight;
 fonts-myanmar-gantgaw - myanmar fonts: gantgaw;
 fonts-myanmar-khyay - myanmar fonts: khyay;
 fonts-myanmar-kuttar - myanmar fonts: kuttar;
 fonts-myanmar-myanmar3 - ttf myanmar fonts: Myanmar3;
 fonts-myanmar-myanmarcensus - ttf myanmar fonts: MyanmarCensus;
 fonts-myanmar-nayone - myanmar fonts: nayone;
 fonts-myanmar-njaun - myanmar fonts: njaun;
 fonts-myanmar-pauklay - myanmar fonts: pauklay;
 fonts-myanmar-phetsot - myanmar fonts: phetsot;
 fonts-myanmar-phiksel - myanmar fonts: phiksel;
 fonts-myanmar-phikselsmooth - myanmar fonts: phikselsmooth;
 fonts-myanmar-ponenyet - myanmar fonts: ponenyet;
 fonts-myanmar-pyidaungsu - ttf myanmar fonts: Pyidaungsu;
 fonts-myanmar-sabae - myanmar fonts: sabae;
 fonts-myanmar-sagar - myanmar fonts: sagar;
 fonts-myanmar-sanpya - myanmar fonts: sanpya;
 fonts-myanmar-squarelight - myanmar fonts: squarelight;
 fonts-myanmar-tagu - myanmar fonts: tagu;
 fonts-myanmar-thuriya - myanmar fonts: thuriya;
 fonts-myanmar-unicode - ttf myanmar unicode fonts
 fonts-myanmar-waso - myanmar fonts: waso;
 fonts-myanmar-yinmar - myanmar fonts: yinmar;
 fonts-myanmar-zawgyi - ttf myanmar fonts: ZawgyiOne2008;

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

  https://mentors.debian.net/package/fonts-myanmar


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

dget -x 
https://mentors.debian.net/debian/pool/main/f/fonts-myanmar/fonts-myanmar_1.0-1.dsc

  i will follow to main / upstream approve and bug fix / bug report
-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic-proposed'), (500, 'bionic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#898656: python-stestr updates from ubuntu

[Corey Bryant]

Package: python-stestr
Version: 1.1.0-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  - d/rules: Continue to run tests as we did in the past.
  - d/p/argparse-empty-array.patch: Deal with [] instead of 'None'
when list is called with no additional parameters.


Thanks for considering the patch.


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

Kernel: Linux 4.15.0-20-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-stestr-1.1.0/debian/patches/argparse-empty-array.patch 
python-stestr-1.1.0/debian/patches/argparse-empty-array.patch
--- python-stestr-1.1.0/debian/patches/argparse-empty-array.patch   
1969-12-31 19:00:00.0 -0500
+++ python-stestr-1.1.0/debian/patches/argparse-empty-array.patch   
2018-05-14 13:52:24.0 -0400
@@ -0,0 +1,18 @@
+Description: Deal with [] instead of 'None'
+ argparse returns an empty array for any unknown arguments; detect
+ this situation and default filters to None in this instance as
+ already performed in the 'run' cli module.
+Author: James Page 
+Forwarded: https://github.com/mtreinish/stestr/pull/129
+
+--- a/stestr/commands/list.py
 b/stestr/commands/list.py
+@@ -48,7 +48,7 @@ def set_cli_opts(parser):
+ 
+ def run(arguments):
+ args = arguments[0]
+-filters = arguments[1]
++filters = arguments[1] or None
+ return list_command(config=args.config, repo_type=args.repo_type,
+ repo_url=args.repo_url, group_regex=args.group_regex,
+ test_path=args.test_path, top_dir=args.top_dir,
diff -Nru python-stestr-1.1.0/debian/patches/series 
python-stestr-1.1.0/debian/patches/series
--- python-stestr-1.1.0/debian/patches/series   2018-03-03 13:24:52.0 
-0500
+++ python-stestr-1.1.0/debian/patches/series   2018-05-14 13:52:24.0 
-0400
@@ -1 +1,2 @@
 remove-privacy-breach-in-README.rst.patch
+argparse-empty-array.patch
diff -Nru python-stestr-1.1.0/debian/rules python-stestr-1.1.0/debian/rules
--- python-stestr-1.1.0/debian/rules2018-03-03 13:24:52.0 -0500
+++ python-stestr-1.1.0/debian/rules2018-05-14 13:52:24.0 -0400
@@ -7,27 +7,25 @@
dh $@ --buildsystem=python_distutils --with python2,python3,sphinxdoc
 
 export PATH:=$(PATH):$(CURDIR)/debian/bin
+export HOME:=/tmp
 
 override_dh_auto_install:
pkgos-dh_auto_install
 
-ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
-   cp debian/bin/pythonX-stestr debian/bin/stestr ;
-   sed -i s/z/2.7/ debian/bin/stestr ;
-   
PYTHONPATH=$(CURDIR)/debian/python-stestr/usr/lib/python2.7/dist-packages 
PYTHON=python2.7 stestr init ;
-   HOME=$(CURDIR) 
PYTHONPATH=$(CURDIR)/debian/python-stestr/usr/lib/python2.7/dist-packages 
PYTHON=python2.7 stestr run --subunit 
'stestr\.tests\.(?!(.*repository\.test_file\.TestFileRepository\.test_get_test_run_unexpected_ioerror_errno.*))'
 | subunit2pyunit ;
-   set -x ; set -e ; for i in $(PYTHON3S); do \
-   cp debian/bin/pythonX-stestr debian/bin/stestr ; \
-   sed -i s/z/$$i/ debian/bin/stestr ; \
-   
PYTHONPATH=$(CURDIR)/debian/python3-stestr/usr/lib/python3/dist-packages 
PYTHON=python$$i stestr init ; \
-   HOME=$(CURDIR) 
PYTHONPATH=$(CURDIR)/debian/python3-stestr/usr/lib/python3/dist-packages 
PYTHON=python$$i stestr run --subunit 
'stestr\.tests\.(?!(.*repository\.test_file\.TestFileRepository\.test_get_test_run_unexpected_ioerror_errno.*))'
 | subunit2pyunit ; \
-   done
-endif
-
 override_dh_python3:
dh_python3 --shebang=/usr/bin/python3
 
 override_dh_auto_test:
+ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
+   set -x ; set -e ; for pyvers in $(PYTHONS) $(PYTHON3S); do \
+   PYMAJOR=`echo $$pyvers | cut -d'.' -f1` ; \
+   echo "===> Testing with python$$pyvers (python$$PYMAJOR)" ; \
+   cp debian/bin/pythonX-stestr debian/bin/stestr ; \
+   sed -i s/z/$$pyvers/ debian/bin/stestr ; \
+   PYTHONPATH=$(CURDIR) PYTHON=python$$pyvers python$$pyvers -m 
stestr.cli init ; \
+   PYTHONPATH=$(CURDIR) PYTHON=python$$pyvers python$$pyvers -m 
stestr.cli run --subunit | subunit2pyunit ; \
+   done
+endif
 
 override_dh_sphinxdoc:
 ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS)))

Bug#855251: easytag corrupt ogg files

[Bruno Kleinert]

Am Sonntag, den 13.05.2018, 12:35 +0100 schrieb James Cowgill:
> Hi,
> 
> On 13/05/18 11:47, Bruno Kleinert wrote:
> > Hi James,
> > 
> > unfortunately it doesn't seem fixed to me. I tried the following
> > with
> > 2.4.3-4:
> >1. youtube-dl -x -f 'bestaudio' 'https://www.youtube.com/watch?v
> > =ui_odI
> >   vVIBE'
> >2. Use soundconverter to convert it to Ogg Vorbis
> >3. vorbisgain Flux\ Pavilion\ -\ Hold\ Me\ Close-ui_odIvVIBE.ogg 
> > (Add
> >   replay gain tags)
> >4. ogginfo Flux\ Pavilion\ -\ Hold\ Me\ Close-ui_odIvVIBE.ogg |
> > grep
> >   REPLAY (Confirm that the file contains replay gain tags)
> >5. Use easytag to add Title tag "abcd" and save the file
> >6. ogginfo Flux\ Pavilion\ -\ Hold\ Me\ Close-ui_odIvVIBE.ogg |
> > grep
> >   REPLAY (Won't output anything, replay gain tags got lost)
> > 
> > At least oggz-validate didn't complain about a broken Ogg file.
> > Neither
> > before, nor after editing it with easytag.
> 
> This is not the same bug. This bug is about easytag corrupting the
> audio
> data in vorbis files whereas for you it looks like easytag has
> removed a
> tag it (presumably) doesn't support. Could you file a separate bug?
> 
> Thanks,
> James

Hi James,

sorry for mixing things up. As you suggested, I filed a new bug. It's
this one:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898654

Cheers - Bruno

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

Bug#898655: RFS: speedcrunch/0.12.0-4 [RC]

[Felix Krull]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

* Package name: speedcrunch
  Version : 0.12.0-4
  Upstream Author : Helder Correia & others
* URL : http://speedcrunch.org
* License : GPL-2+
  Section : math

It builds those binary packages:

  speedcrunch - High precision calculator

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/s/speedcrunch/speedcrunch_0.12.0-4.dsc

Changes since the last upload:

  * d/control:
- update VCS-* urls
- bump Standards-Version
- use python3-sphinx instead of python-sphinx
  * d/compat: bump debhelper compat version to 10
  * d/patches, d/rules: build the HTML manual in a separate step
- Rebuilding the HTML manual during the build has proven fragile.
Instead,
  the manual is now built in a separate step and the application build
is
  pointed at the result of that build.
- Closes: #897531

---

In addition to some housekeeping, a change in... CMake? Qt? -- caused an
FTBFS. Instead of working around it, we changed the build process so that
building the HTML manual is now a separate step. This should be more
robust, but it makes d/rules a bit more complicated. I'm not sure I used
the dh_auto_* targets in the best possible fashion there.

Upstream bug:
https://bitbucket.org/heldercorreia/speedcrunch/issues/830/build-with-drebuild_manual-fails-on-debian

Regards,
Felix

Bug#898654: [easytag] Removes replaygain tags from Ogg files

[Bruno Kleinert]

Package: easytag
Version: 2.4.3-4
Severity: normal

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

when an arbitrary other tag of an Ogg Vorbis file with replay gain tags
is edited, added or removed, easytag removes the replay gain tags from
that file when it's saved.

The following steps reproduce the unintentional removal of the replay
gain tags:
   1. youtube-dl -x -f 'bestaudio' 
'https://www.youtube.com/watch?v=ui_odIvVIBE' (Or use any other audio file)
   2. Use soundconverter to convert it to Ogg Vorbis
   3. vorbisgain Flux\ Pavilion\ -\ Hold\ Me\ Close-ui_odIvVIBE.ogg (Add replay 
gain tags)
   4. ogginfo Flux\ Pavilion\ -\ Hold\ Me\ Close-ui_odIvVIBE.ogg | grep REPLAY 
(Confirm that the file contains replay gain tags)
   5. Use easytag to add Title tag "abcd" and save the file
   6. ogginfo Flux\ Pavilion\ -\ Hold\ Me\ Close-ui_odIvVIBE.ogg | grep REPLAY 
(Won't output anything, replay gain tags got lost)

Cheers - Bruno

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

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

--- Package information. ---
Depends(Version) | Installed
-+-=
dconf-gsettings-backend  | 0.28.0-2
 OR gsettings-backend| 
libc6  (>= 2.14) | 2.27-3
libflac8  (>= 1.3.0) | 1.3.2-2
libgcc1   (>= 1:3.0) | 1:8.1.0-3
libgdk-pixbuf2.0-0   (>= 2.30.1) | 2.36.11-2
libglib2.0-0   (>= 2.38) | 2.56.1-2
libgtk-3-0 (>= 3.10) | 3.22.30-1
libid3-3.8.3v5   | 3.8.3-16.2+b1
libid3tag0  (>= 0.15.1b) | 0.15.1b-13
libogg0  (>= 1.0rc3) | 1.3.2-1+b1
libopus0(>= 1.1) | 1.2.1-1
libopusfile0(>= 0.5) | 0.9+20170913-1
libspeex1   (>= 1.2~beta3-1) | 1.2~rc1.2-1+b2
libstdc++6(>= 5) | 8.1.0-3
libtag1v5(>= 1.9.1-2.2~) | 1.11.1+dfsg.1-0.2+b1
libvorbis0a   (>= 1.1.2) | 1.3.6-1
libvorbisfile3(>= 1.1.2) | 1.3.6-1
libwavpack1  (>= 4.40.0) | 5.1.0-3


Recommends(Version) | Installed
===-+-===
gnome-icon-theme| 3.12.0-3
gvfs| 1.36.1-1
yelp| 3.28.1-1


Suggests  (Version) | Installed
===-+-===
easytag-nautilus| 






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

Bug#897653: tar 1.30 breaks pristine-tar

[Paul Eggert]

On 05/14/2018 07:56 AM, Antonio Terceiro wrote:

I still need to study the  > code a bit further to try to come up with a better 
suggestion.
Sorry, the only suggestion I can make is that you should just use the 
new GNU tar. The old one was obviously busted and it generated busted 
tarballs.

Bug#891714: Bug#898651: fakemachine: missing dependencies

[Simon McVittie]

Control: tags 898651 + patch

On Mon, 14 May 2018 at 18:34:23 +0100, Simon McVittie wrote:
> Please consider the attached patch.

Note that this doesn't do anything for dependent packages like
debos, which will probably need similar dependencies.

What I proposed adding to fakemachine, which debos should probably also
get, are:

Architecture: amd64
Depends: busybox | busybox-static, qemu-system-x86, systemd
Recommends: e2fsprogs, linux-image-amd64

Thanks,
smcv

Bug#898652: golang-github-go-debos-fakemachine: autopkgtest doesn't actually run any tests

[Simon McVittie]

Source: golang-github-go-debos-fakemachine
Version: 0.0~git20180126.e307c2f-1
Severity: normal
Tags: patch

The tests for this package appear to pass, but if you look more closely,
there is very little actual testing going on:

autopkgtest [02:05:31]: test command1: /usr/bin/dh_golang_autopkgtest
autopkgtest [02:05:31]: test command1: [---
[info] Testing github.com/go-debos/fakemachine...
[info] Source code installed by binary package, overriding dh_auto_configure...
dh build --buildsystem=golang --with=golang
...
   debian/rules override_dh_auto_test
make[1]: Entering directory 
'/tmp/autopkgtest-lxc.6okl3mgq/downtmp/autopkgtest_tmp'
# Disable auto tests at build time
# fakemachine need to be able to use /dev/kvm
:
make[1]: Leaving directory 
'/tmp/autopkgtest-lxc.6okl3mgq/downtmp/autopkgtest_tmp'
   create-stamp debian/debhelper-build-stamp
autopkgtest [02:05:33]: test command1: ---]
autopkgtest [02:05:33]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 PASS

I suspect autopkgtest-pkg-go is not appropriate for this particular
package.

I attach a simple smoke-test which tries to detect whether fakemachine
should be expected to be able to operate or not. This would hopefully have
detected the missing runtime dependencies.

Regards,
smcv
>From 17bec09d74237f3961a423e416de72c6be30afd6 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 14 May 2018 18:21:50 +0100
Subject: [PATCH 1/3] Add an autopkgtest smoke test

Unlike the (disabled) build-time tests, this checks for access to
/dev/kvm and is skipped if that isn't possible.

Signed-off-by: Simon McVittie 
---
 debian/control   |  1 -
 debian/tests/control |  3 ++
 debian/tests/hello   | 72 
 3 files changed, 75 insertions(+), 1 deletion(-)
 create mode 100644 debian/tests/control
 create mode 100755 debian/tests/hello

diff --git a/debian/control b/debian/control
index 9d746bf..bd58272 100644
--- a/debian/control
+++ b/debian/control
@@ -18,7 +18,6 @@ Homepage: https://github.com/go-debos/fakemachine
 Vcs-Browser: https://salsa.debian.org/go-team/packages/golang-github-go-debos-fakemachine
 Vcs-Git: https://salsa.debian.org/go-team/packages/golang-github-go-debos-fakemachine.git
 XS-Go-Import-Path: github.com/go-debos/fakemachine
-Testsuite: autopkgtest-pkg-go
 
 Package: fakemachine
 Architecture: any
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..a7d8062
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,3 @@
+Tests: hello
+Depends: fakemachine, hello
+Restrictions: allow-stderr needs-recommends
diff --git a/debian/tests/hello b/debian/tests/hello
new file mode 100755
index 000..d99aef6
--- /dev/null
+++ b/debian/tests/hello
@@ -0,0 +1,72 @@
+#!/bin/bash
+
+# Copyright © 2018 Collabora Ltd.
+#
+# SPDX-License-Identifier: Apache-2.0
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+set -e
+set -u
+set -o pipefail
+
+cd "${AUTOPKGTEST_TMP:-"${ADTTMP}"}"
+
+if ! [ -w /dev/kvm ]; then
+echo "1..0 # SKIP no write access to /dev/kvm"
+exit 0
+fi
+
+if ! grep -E '^flags[[:space:]]*:.*[[:space:]](vmx|svm)( |$)' /proc/cpuinfo >&2; then
+echo "1..0 # SKIP could not find AMD-V (svm) or Intel VT-x (vmx) in /proc/cpuinfo"
+exit 0
+fi
+
+echo "1..3"
+fail=0
+
+# Filter out Esc and Tab for a cleaner log and easier grepping
+if timeout -k 5s -s ABRT 60s \
+fakemachine env LC_ALL=C hello &1 | \
+stdbuf -oL tr -d '\033\015' | \
+tee fakemachine.log >&2; then
+e=0
+else
+e=$?
+fi
+
+if [ "$e" -eq 0 ]; then
+echo "ok 1 - fakemachine hello exited successfully"
+elif [ "$e" -eq 124 ]; then
+echo "not ok 1 - fakemachine hello timed out"
+fail=1
+else
+echo "not ok 1 - fakemachine hello exited $e"
+fail=1
+fi
+
+if grep -E '^Running env LC_ALL=C hello$' fakemachine.log >&2; then
+echo "ok 2 - fakemachine tried to run hello"
+else
+echo "not ok 2 - fakemachine didn't get as far as running hello"
+fail=1
+fi
+
+if grep -E '^Hello, world!$' fakemachine.log >&2; then
+echo "ok 3 - received a friendly greeting"
+else
+echo "not ok 3 - did not receive a friendly greeting"
+fail=1
+fi
+
+exit "$fail"
-- 
2.17.0

Bug#898651: fakemachine: missing dependencies

[Simon McVittie]

Package: fakemachine
Version: 0.0~git20180126.e307c2f-1
Severity: grave
Justification: renders package unusable

In a relatively minimal (buildd) chroot:

smcv@archetype(sid-amd64):~$ sudo apt install fakemachine hello
...
smcv@archetype(sid-amd64):~$ fakemachine hello
2018/05/14 16:31:15 open failed: /bin/busybox - open /bin/busybox: no such file 
or directory
panic: open failed: /bin/busybox - open /bin/busybox: no such file or directory
smcv@archetype(sid-amd64):~$ sudo apt install busybox
...
smcv@archetype(sid-amd64):~$ fakemachine hello; echo $?
255
smcv@archetype(sid-amd64):~$ sudo apt install --no-install-recommends 
linux-image-amd64 qemu-system-x86
...
smcv@archetype(sid-amd64):~$ fakemachine hello; echo $?
...
Running hello
Hello, world!
Powering off.
[4.471990] reboot: Power down
0

fakemachine should have dependencies (or at least Recommends) on:

* busybox | busybox-static
* systemd
* linux-image-amd64 [1]
* qemu-system-x86   [2]

[1] Perhaps with linux-image-generic (Ubuntu), etc., as alternatives.
Upstream only supports x86_64 hosts, for which I've opened separate
bugs.
[2] Use of qemu-system-x86_64 is currently hard-coded.

By inspection of its source code, it should also have at least a Suggests
(probably a Recommends) on e2fsprogs, for mkfs.ext4.

Please consider the attached patch.

Thanks,
smcv
>From 67763c9fa94d9088537a314dbf050f69ac9af760 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 14 May 2018 18:24:26 +0100
Subject: [PATCH 3/3] Add missing dependencies

Signed-off-by: Simon McVittie 
---
 debian/control | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 53c7ded..93ee761 100644
--- a/debian/control
+++ b/debian/control
@@ -23,8 +23,13 @@ Testsuite: autopkgtest-pkg-go
 Package: fakemachine
 Architecture: amd64
 Built-Using: ${misc:Built-Using}
-Depends: ${shlibs:Depends},
+Depends: busybox | busybox-static,
+ qemu-system-x86,
+ systemd,
+ ${shlibs:Depends},
  ${misc:Depends}
+Recommends: e2fsprogs,
+linux-image-amd64
 Description: create and spawn virtual machines for building images with debos.
  Create and spawn virtual machines for building images with debos tool.
 
-- 
2.17.0

Bug#898650: golang-github-go-debos-fakemachine: non-amd64 binaries are unusable

[Simon McVittie]

Source: golang-github-go-debos-fakemachine
Version: 0.0~git20180126.e307c2f-1
Severity: grave
Tags: patch
Justification: renders package unusable

fakemachine currently assumes that the linker is
/lib64/ld-linux-x86-64.so.2, the standard C library is
/lib/x86_64-linux-gnu/libc.so.6, and qemu-system-x86_64 is an
appropriate way to run a virtual machine. None of these are true on
non-amd64 architectures.

Ideally fakemachine should be taught to cope with other architectures
(I've opened a wishlist bug and marked it as forwarded to
).

Until that happens, it should only be built on architectures where it
can work (see attached). This will require uploading a version marked
to be built on amd64 only, then asking the ftp team to remove the old
binaries on other architectures.

Thanks,
smcv
>From 03287930ceae69dff620c11ece2151f46331cd88 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 14 May 2018 18:24:09 +0100
Subject: [PATCH 2/3] Only build on amd64

fakemachine currently assumes that the linker is
/lib64/ld-linux-x86-64.so.2, the standard C library is
/lib/x86_64-linux-gnu/libc.so.6, and qemu-system-x86_64 is an
appropriate way to run a virtual machine. None of these are true on
other architectures.

Signed-off-by: Simon McVittie 
---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 9d746bf..53c7ded 100644
--- a/debian/control
+++ b/debian/control
@@ -21,7 +21,7 @@ XS-Go-Import-Path: github.com/go-debos/fakemachine
 Testsuite: autopkgtest-pkg-go
 
 Package: fakemachine
-Architecture: any
+Architecture: amd64
 Built-Using: ${misc:Built-Using}
 Depends: ${shlibs:Depends},
  ${misc:Depends}
@@ -29,7 +29,7 @@ Description: create and spawn virtual machines for building images with debos.
  Create and spawn virtual machines for building images with debos tool.
 
 Package: golang-github-go-debos-fakemachine-dev
-Architecture: any
+Architecture: amd64
 Built-Using: ${misc:Built-Using}
 Depends: ${shlibs:Depends},
  ${misc:Depends}
-- 
2.17.0

Bug#866440: mcomix: depends on obsolete python-imaging (replace with python3-pil or python-pil)

[Ernesto Domato]

Package: mcomix
Followup-For: Bug #866440

Hi,

mcomix works well with python-pil (as upstream mention too) so please change
python-imaging for python-pil on control file so
this bug can be closed.

Thanks.



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

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

Versions of packages mcomix depends on:
ii  python2.7.15~rc1-1
ii  python-gtk2   2.24.0-5.1+b1
ii  python-pil5.1.0-1
ii  python-pkg-resources  39.1.0-1

mcomix recommends no packages.

Versions of packages mcomix suggests:
ii  unrar  1:5.5.8-1

-- no debconf information

Bug#898649: golang-github-go-debos-fakemachine: should work on non-x86_64 machines

[Simon McVittie]

Source: golang-github-go-debos-fakemachine
Version: 0.0~git20180126.e307c2f-1
Severity: wishlist
Tags: upstream
Forwarded: https://github.com/go-debos/fakemachine/issues/18

fakemachine currently assumes that the linker is
/lib64/ld-linux-x86-64.so.2, the standard C library is
/lib/x86_64-linux-gnu/libc.so.6, and qemu-system-x86_64 is an
appropriate way to run a virtual machine. None of these are true on
other architectures.

Bug#635182: cdk 2.1 released

[Andrius Merkys]

control: retitle 635182 libcdk-java: new upstream release 2.1

The development of the package seems to have moved to GitHub at 
https://github.com/cdk/cdk/, and the most recent version there is 2.1 now. The 
package seems to have been moved to maven build system, with some of the build 
dependencies missing in Debian.

Best,
Andrius

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

Bug#866440: mcomix: depends on obsolete python-imaging (replace with python3-pil or python-pil)

[Ernesto Domato]

Package: mcomix
Followup-For: Bug #866440

Hi,

mcomix works well with python-pil (as upstream mention too) so please change
python-imaging for python-pil on control file so
this bug can be closed.

Thanks.



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

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

Versions of packages mcomix depends on:
ii  python2.7.15~rc1-1
ii  python-gtk2   2.24.0-5.1+b1
ii  python-pil5.1.0-1
ii  python-pkg-resources  39.1.0-1

mcomix recommends no packages.

Versions of packages mcomix suggests:
ii  unrar  1:5.5.8-1

-- no debconf information

Bug#894159: ICU transition: ICU version is part of the boost ABI

[Emilio Pozuelo Monfort]

On 13/05/18 16:08, Adrian Bunk wrote:
> Control: reassign 898465 src:icu 60.1-1
> Control: retitle 898369 boost: ICU version used is part of the ABI
> Control: retitle 898465 ICU must not migrate to testing before the boost ABI 
> breakage is resolved
> Control: affects 898369 libmapnik3.0 viking
> Control: block 898465 by 898369
> Control: block 894159 by 898369 898465
> 
> On Thu, May 10, 2018 at 06:06:08PM -0300, Thadeu Lima de Souza Cascardo wrote:
>> Source: boost1.62
>> Version: 1.62.0+dfsg-5+b2
>> Severity: serious
>>
>> After upgrading boost1.62 to 1.62.0+dfsg-5+b2, ncmpcpp does not start
>> anymore.
>>
>> $ ncmpcpp
>> ncmpcpp: symbol lookup error: ncmpcpp: undefined symbol: 
>> _ZNK5boost16re_detail_10620031icu_regex_traits_implementation12do_transformEPKiS3_PKN6icu_578CollatorE
>> ...
> 
> boost::re_detail_106200::icu_regex_traits_implementation::do_transform(int 
> const*, int const*, icu_57::Collator const*) const
> 
> Yes, boost makes the ICU version it uses part of its ABI.
> 
> There is no obvious good way forward, the RC bug in ICU will ensure that 
> the breakage won't migrate to testing before this got sorted out.

boost1.62 should:
- bump the libicu-dev build-dependency to ensure it builds against icu 60
- add breaks against the rdeps that use the affected symbols

And we should transition to a newer boost at some point.

Cheers,
Emilio

Bug#895940: RFS: python-dataclasses/0.5-1 [ITP]

[Joel Cross]

On Mon, 30 Apr 2018, at 6:21 PM, Joel Cross wrote:
> > Ah!  Found it.  It's listed in the "setup.py" file.  Hmm...  I wonder if
> > that's a problem, because no other file contains any kind of copyright
> > notice, and there's no LICENSE file.  I'd definitely file a bug against
> > upstream asking them to clarify this, but I honestly don't know if
> > ftp-master will accept the package as is.  Maybe there's some
> > precedence, but I'm short on time right now and can't really dive into
> > the archives to find something.  Perhaps someone more knowledgeable can
> > chime in?
> 
> Hi Sergio,
> 
> As an update to this, I filed a bug report upstream. The author 
> originally planned to license as Apache2 but neglected to add the 
> license to the repo (I guess 'MIT' was some default somewhere): see 
> discussion at https://github.com/ericvsmith/dataclasses/issues/123
> 
> Anyway, the author has now added the license, but has not yet released a 
> new version, as no code has actually changed. I was wondering if you 
> could help me with regards to packaging based on a specific upstream Git 
> commit rather than a release version, and how that works with the git-
> buildpackage flow (if it's even allowed/recommended).
> 
Hi again,

Did you get the chance to think about the above? I will happily repackage from 
the git master, but I'm not sure what to do about version numbers and stuff 
(and online informaition about this is hard to find!). Please can you help?

Bug#894159: transition: icu

[Emilio Pozuelo Monfort]

On 13/05/18 22:52, László Böszörményi (GCS) wrote:
> Last but not least I've a different understanding (again) of package
> transitions with Adrian Bunk. He reassigned #898465 [2] to ICU, when both
> related bugreports of ncmpcpp [3] and viking due to mapnik [4] are due to
> partial upgrades (shown in the package versions 0.8.1-1 and 3.0.20+ds-1
> respectively that these are _not_ the binNMUed ones). Checking the build
> logs show mapnik and ncmpcpp rebuilt normally and I've even tested those
> correctly. The bug reporters need to do a full packages upgrade, that's all.
> Then the migration script knows about dependencies and will not let icu
> enter testing by itself, only with the transitioned dependencies.

icu should migrate to testing even before all the rdeps migrate. That could
cause mapnik or ncmpcpp, for example, to stay at older versions, with boost1.62
and icu at the new ones, breaking those packages. Besides, we support partial
upgrades.

The solution I see here is to add Breaks in boost1.62 against mapnik and ncmpcpp
(and other affected packages, if any). That should solve this bug for now, and
while not ideal, we should have a boost transition eventually so I don't mind
using Breaks in this situation.

Cheers,
Emilio

Bug#898648: ProLiant DL380 Gen9 takes forever to reboot

[Ivan Sergio Borgonovo]

Package: linux-image-4.15.0-3-amd64
Version: 4.15.17-1

after running

reboot

machine start shutdown and hangs several minutes with this message on 
console


hpwdt: Unxpected close, not stopping watchdog!

Fans go to maximum speed and machine freeze for several minutes before 
rebooting.

Freezing time are not constant (from 5 extra minutes to over 10 minutes).

Same problem with
linux-image-4.16.0-1-amd64
4.16.5-1

I had to revert to
linux-image-4.14.0-3-amd64
4.14.17-1

thanks

--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net

Bug#898632: libreoffice: Cannot use IME under Wayland

[魏銘廷]

Package: libreoffice
Followup-For: Bug #898632

Confirmed that it is not reproducible in experimental version.


signature.asc
Description: PGP signature

Bug#895718: python-pyqt5: import PyQt5.QtCore fails

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 14 de mayo de 2018 13:43:18 -03 Dmitry Shachnev escribió:
[snip] 
> > - We do not know the impact we create by disabling the getentropy feature.
> > And normally that stuff is related to criptography. Believe me I don't
> > want to mess with that.
> 
> If we disable it, Qt will fall back to reading /dev/urandom directly.
> 
> As I understand, it will be a bit less secure because it is vulnerable
> to file descriptor exhaustion attacks, and also a bit slower. But on the
> other hand, it is a traditional interface for getting randomness, and the
> majority of software probably still uses it.
> 
> See for details:
> 
> - https://lwn.net/Articles/606141/
> - https://git.kernel.org/linus/c6e9d6f38894798696f23c8084ca7edbf16ee895

Quoting from the above:

  The rationale of this system call is to provide resiliance against
  file descriptor exhaustion attacks, where the attacker consumes all
  available file descriptors, forcing the use of the fallback code where
  /dev/[u]random is not available.  Since the fallback code is often not
  well-tested, it is better to eliminate this potential failure mode
  entirely.

So if we disable it we disable a feature providing a more robust method to 
provide randomness to ours users.

In this case our users come first, so no, we should not disable this.

-- 
Never attribute to malice that which is adequately explained by stupidity.
  http://en.wikipedia.org/wiki/Hanlon's_razor

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


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

Bug#876478: ben tracker --global-conf ignores settings

[Sebastiaan Couwenberg]

On 05/14/2018 08:26 AM, Mehdi Dogguy wrote:
> On 2018-05-14 08:01, Sebastiaan Couwenberg wrote:
>> Unfortunately that doesn't apply cleanly on top of 0.7.4 for stretch. If
>> you can provide a rebased commit for 0.7.4 I'm willing to test that.
>>
> 
> No problem. Here it is (attached). Thanks for your tests!

Thanks for the patch, it doesn't seem to work as expected, though.

`ben tracker` downloads the Packages & Sources files again even when
`ben download` downloaded them just before. It also uses the current
working directory for the downloaded files instead of the cache-dir from
the global.conf.

It looks like this is caused by the custom template that was built with
the old ben, because switching the template to debianrt in global.conf
results in the expected behaviour.

Rebuilding the template fails when executed from the root of the git
directory:

 $ ocamlbuild -pkg ben debiangis.cmxs
 + /usr/bin/ocamlopt unix.cmxa -I /usr/lib/ocaml/ocamlbuild
/usr/lib/ocaml/ocamlbuild/ocamlbuildlib.cmxa -I /usr/lib/ocaml -I
/usr/lib/ocaml/ben -I /usr/lib/ocaml/bytes -I /usr/lib/ocaml/ocamlgraph
-I /usr/lib/ocaml/pcre -I /usr/lib/ocaml/tyxml -I /usr/lib/ocaml/uutf
/usr/lib/ocaml/unix.cmxa /usr/lib/ocaml/pcre/pcre.cmxa
/usr/lib/ocaml/ocamlgraph/graph.cmxa /usr/lib/ocaml/str.cmxa
/usr/lib/ocaml/uutf/uutf.cmxa /usr/lib/ocaml/tyxml/tyxml.cmxa
/usr/lib/ocaml/ben/benl.cmxa myocamlbuild.ml
/usr/lib/ocaml/ocamlbuild/ocamlbuild.cmx -o myocamlbuild
 File "myocamlbuild.ml", line 1:
 Error: Files /usr/lib/ocaml/unix.cmxa and /usr/lib/ocaml/unix.cmxa
both define a module named Unix

Building the template from the templates directory works, but doesn't
generate any changes from the previous build.

Kind Regards,

Bas

Bug#897244: closed by Chris Lamb <la...@debian.org> (Bug#897244: fixed in lintian 2.5.85)

[Chris Lamb]

Dear Rene,

> > Lintian will look inside any dependencies since the previous chnage
> > but as you have only provided a single binary .deb, it has no way of
> > actually interrogating them.
> 
> Oh, right, indeed, should have thought of this.
[..]
> Sorry for the noise.

No problem at all, always good to "err" on checking. Out of interest,
in your workflow you run Lintian directly on the .debs itself?


Regards,

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