Bug#905996: nmu: clsync_0.4.1-1

[Niels Thykier]

Aurelien Jarno:
> [...]
>>
>> Hi Aurelien,
>>
>> If the goal is to make testing free of packages (Pre-)Depending on
>> multiarch-support
> 
> Yes, that's exactly the goal, that way we can just stop building the
> package in the next upload. There are still a few depending packages
> in sid/experimental, but given the bug reports have been sent with
> patches attached more than one year ago, I don't mind breaking them.
> 

Ok, thanks for confirming.

>> then removing clsync from testing is also an option
>> AFAICT.
>>
>> I am considering since clsync has had its FTBFS bug against sid for
>> almost 2 years now with no reaction from its maintainers.
> 
> That solution has the same result than the binNMU, so that's also fine
> for me. I would leave the decision about what is the best way to achieve
> that to the release team.
> 
> Thanks,
> Aurelien
> 

Could you please file an RC bug against clsync that affects the
*testing* version (tags sid + buster if that version is also in stable)
about this issue?

I am happy to consider removing clsync earlier than the auto-removal
would have if time is an issue.

Thanks,
~Niels

Bug#906154: remmina: ssh tunnelling does not work any more

[jfp]

Package: remmina
Version: 1.2.31.2+dfsg-2
Severity: important
Tags: upstream

Dear Maintainer,

Looks like ssh tunnelling has stopped working.

When connecting  I get one of two things:
- Gets stuck on "connectiong to localhost through SSH tunnel" dialog.
or
- Failed to startup SSH session: No route to host.
[SSH] socket_callback_connected: Socket connection callback: 2 (113)
[SSH] socket_callback_connected: No route to host

I have a number of remote hosts I connect too, they all are failing.

A connection setup is as follows:
server: localhost
ssh tunnel
no loopback address
custom: SERVERNAME:PORT
username: USER
SSH Agent




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

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

Versions of packages remmina depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.10-1
ii  dbus-x11 [dbus-session-bus]   1.12.10-1
ii  libatk1.0-0   2.28.1-1
ii  libavahi-client3  0.7-4
ii  libavahi-common3  0.7-4
ii  libavahi-ui-gtk3-00.7-4
ii  libayatana-appindicator3-10.5.3-4
ii  libc6 2.27-5
ii  libcairo2 1.15.10-3
ii  libgcrypt20   1.8.3-1
ii  libgdk-pixbuf2.0-02.36.12-1
ii  libglib2.0-0  2.56.1-2
ii  libgtk-3-03.22.30-2
ii  libice6   2:1.0.9-2
ii  libjson-glib-1.0-01.4.2-4
ii  libpango-1.0-01.42.1-2
ii  libsm62:1.2.2-1+b3
ii  libsoup2.4-1  2.62.2-2
ii  libssh-4  0.8.1-1
ii  libssl1.1 1.1.0h-4
ii  libvte-2.91-0 0.52.2-1
ii  libx11-6  2:1.6.5-1
ii  libxext6  2:1.3.3-1+b2
ii  remmina-common1.2.31.2+dfsg-2

Versions of packages remmina recommends:
ii  remmina-plugin-rdp 1.2.31.2+dfsg-2
pn  remmina-plugin-secret  
ii  remmina-plugin-vnc 1.2.31.2+dfsg-2

Versions of packages remmina suggests:
pn  remmina-plugin-exec   
pn  remmina-plugin-nx 
pn  remmina-plugin-spice  
pn  remmina-plugin-telepathy  
pn  remmina-plugin-xdmcp  

-- no debconf information

Bug#906131: CVE-2018-14722

[Nicholas D Steeves]

Dear Moritz and Sven,

On Tue, Aug 14, 2018 at 07:24:26PM +0200, Moritz Muehlenhoff wrote:
> Package: btrfsmaintenance
> Severity: grave
> Tags: security
> 
> Please see http://www.openwall.com/lists/oss-security/2018/08/14/7
> 
> Cheers,
> Moritz

Thank you for forwarding this report.  Unfortunately I do not yet have
DM for btrfsmaintenance so cannot upload.  I've CCed Sven in case he
wants to sponsor, but if he's on holidays would you be willing to
sponsor it?

I've uploaded to mentors

  https://mentors.debian.net/package/btrfsmaintenance
  dget 
https://mentors.debian.net/debian/pool/main/b/btrfsmaintenance/btrfsmaintenance_0.4.1-2.dsc

The package's repo can also be cloned:
  git clone https://salsa.debian.org/sten-guest/btrfsmaintenance.git

I don't use dgit, except to quickly download the latest
orig.tarball...  Maybe something like this would be fastest:
  dgit clone btrfsmaintenance
  cd btrfsmaintenace
  git remote add salsa https://salsa.debian.org/sten-guest/btrfsmaintenance.git
  git fetch salsa && git merge --allow-unrelated-histories -X theirs 
salsa/master

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#904950: Bug apparently resolved in version 1:6.1.0-1

[Jape Person]

testing systems upgraded today (08/15/2018) eliminated the issue reported

Thanks!

Bug#906153: jnoisemeter FTCBFS: upstream Makefile hard codes build architecture g++ in one place

[Helmut Grohne]

Source: jnoisemeter
Version: 0.1.0-4
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

jnoisemeter fails to cross build from source, because there is one bare
g++ invocation left in the upstream Makefile. After making it
substitutable, jnoisemeter cross builds successfully. Please consider
applying the attached patch.

Helmut
--- jnoisemeter-0.1.0.orig/source/Makefile
+++ jnoisemeter-0.1.0/source/Makefile
@@ -35,7 +35,7 @@
 jnoisemeter:	LDLIBS += -lclthreads -lclxclient -lpthread -ljack -lXft -lpng -lX11 -lrt
 jnoisemeter:	LDFLAGS += -L$(PREFIX)/$(LIBDIR) -L/usr/X11R6/$(LIBDIR)
 jnoisemeter:	$(JNOISEMETER_O)
-	g++ $(LDFLAGS) -o $@ $(JNOISEMETER_O) $(LDLIBS)
+	$(CXX) $(LDFLAGS) -o $@ $(JNOISEMETER_O) $(LDLIBS)
 
 $(JNOISEMETER_O):
 -include $(JNOISEMETER_O:%.o=%.d)

Bug#906152: libopenblas-base: version 0.3.2+ds-1 makes gimp hang indefinitely

[Rogério Brito]

Package: libopenblas-base
Version: 0.3.2+ds-1
Severity: serious
Justification: breaks unrelated software

Hi.

First of all, I selected serious instead of the more appropriate critical
severity because I don't want to severity inflation.

On the other hand, if you think that this is a severity too high, feel free
to set it to a more appropriate level (as long as we get everything fixed).

OK, now, to the actual report. With version 0.3.2 of openblas installed,
whenever I call gimp (I always start programs from the command line), it
just sits there and doesn't even show its splash screen.

If I interrupt the execution with Ctrl+C, then I get a "Segmentation fault"
message, which would lead me to think that the program would not even have
finished being linked to all the shared libraries that it needs.

If I run gimp under strace, I see that it hangs in a mutex call that never
proceeds.

I searched the web and I found the following discussion:
.

In it, it is suggested that the problem might have be with openblas and,
indeed, I removed libopenblas-base and voilá: with just atlas and the
reference blas installed, gimp fires up as expected on this machine.

This computer is, BTW, a notebook with a Core 2 Duo processor and, when I
start gimp now, I get the following message (that I used to get with
openblas before the upgrade to 0.3):

,
| Missing fast-path babl conversion detected, Implementing missing babl fast 
paths
| accelerates GEGL, GIMP and other software using babl, warnings are printed on
| first occurance of formats used where a conversion has to be synthesized
| programmatically by babl based on format description
| 
| *WARNING* missing babl fast path(s): "R'G'B' double" to "CIE Lab double"
`

If any further information is needed, please let me know.


Thanks,

Rogério Brito.

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

Kernel: Linux 4.16.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.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)

Versions of packages libopenblas-base depends on:
ii  libc6 2.27-5
ii  libgfortran5  8.2.0-3

libopenblas-base recommends no packages.

libopenblas-base suggests no packages.

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#906003: Keep plowshare-modules out of Debian releases

[Carl Suster]

It probably shouldn't have been in stretch, but as long as it does not
cause trouble, you can let it rot there :-)


Agreed that it shouldn't have been released in stretch; at the time I 
had the idea of supporting it through backports. Given the relatively 
low popcon statistics and activity in bts, I think I prefer to just 
leave the package in stretch alone for now. If anyone is caught out by 
the situation later I can proceed with the patching and removing as 
outline above.


Carl

Bug#906151: ERROR: invalid alloc size 143799 at ytnef.c : 1183, suspected corruption

[jfp]

Package: libytnef0
Version: 1.9.2-2
Severity: important
Tags: upstream

Dear Maintainer,

I Reported an issue to upstream, which has been fixed in

https://github.com/Yeraze/ytnef/pull/74

"raise the limit of this from from 100k to 1M. This accomodates a winmail.dat
file he has with a 150k unknown block."




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

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

Versions of packages libytnef0 depends on:
ii  libc6  2.27-5

libytnef0 recommends no packages.

libytnef0 suggests no packages.

-- no debconf information

Bug#906150: /usr/bin/uscan: OAOOOOProblem with uscan when scan on Github

[Emmanuel Arias]

Package: devscripts
Version: 2.17.6+deb9u2
Severity: important
File: /usr/bin/uscan

Dear Maintainer,

  I use the uscan to scan from Github a new upstream. I used it normally
  on Sunday but now Lintian, and uscan in my computer too,
  give me the next error:
  
eamanu@debian:~/src/packages/python-scp_git/python-scp$ uscan --no-download 
--verbose --debug
uscan info: uscan (version 2.17.6+deb9u2) See uscan(1) for help
uscan info: Scan watch files in .
uscan debug: Found ./debian
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="python-scp" version="0.11.0-1" (as seen in 
debian/changelog)
uscan info: package="python-scp" version="0.11.0" (no epoch/revision)
uscan info: ./debian/changelog sets package="python-scp" version="0.11.0"
uscan info: Process ./debian/watch (package=python-scp version=0.11.0)
uscan info: opts: filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/scp.py-$1\.tar\.gz/
uscan info: line: https://github.com/jbardin/scp.py/tags .*/v?(\d\S+)\.tar\.gz
uscan info: Parsing filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/scp.py-$1\.tar\.gz/
uscan info: line: https://github.com/jbardin/scp.py/tags .*/v?(\d\S+)\.tar\.gz
uscan debug: $options{'pgpmode'}=default, $options{'pgpsigurlmangle'}=undef
uscan info: Last orig.tar.* tarball version (from debian/changelog): 0.11.0
uscan info: Last orig.tar.* tarball version (dversionmangled): 0.11.0
uscan info: Requesting URL:
   https://github.com/jbardin/scp.py/tags
uscan debug: received content:
  v0.11.0
  v0.10.2
  v0.10.0
  v0.9.0

[End of received content] by HTTP
uscan debug: processed content:
  v0.11.0
  v0.10.2
  v0.10.0
  v0.9.0

[End of processed content] by fix bad HTML code
uscan info: Matching pattern:
   (?:(?:https://github.com)?\/jbardin\/scp\.py\/tags)?.*/v?(\d\S+)\.tar\.gz
uscan warn: In debian/watch no matching files for watch line
  https://github.com/jbardin/scp.py/tags .*/v?(\d\S+)\.tar\.gz
uscan info: Scan finished

  
Seems like that github change its form to respond for scan and scan do not 
interpret
the new input.

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I -us -uc"
DEBUILD_LINTIAN_OPTS="-i -I --show-overrides"
DEBSIGN_KEYID="630362FCC33595B4CA3BCFB1D85007169B2B9F26"

-- 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=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)

Versions of packages devscripts depends on:
ii  dpkg-dev  1.18.24
ii  libc6 2.24-11+deb9u3
ii  libfile-homedir-perl  1.00-1
ii  perl  5.24.1-3+deb9u4
ii  python3   3.5.3-1

Versions of packages devscripts recommends:
ii  apt 1.4.8
ii  at  3.1.20-3
ii  curl7.52.1-5+deb9u6
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2017.05.28
ii  dput0.12.1
ii  dupload 2.8.4
ii  equivs  2.0.9+nmu1
ii  fakeroot1.21-3.1
ii  file1:5.30-1+deb9u1
ii  gnupg   2.1.18-8~deb9u2
ii  gnupg2  2.1.18-8~deb9u2
ii  libdistro-info-perl 0.14
ii  libdpkg-perl1.18.24
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.047-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.06-2
ii  libsoap-lite-perl   1.20-1
ii  liburi-perl 1.71-1
ii  libwww-perl 6.15-1
ii  licensecheck3.0.29-1
ii  lintian 2.5.50.4
ii  man-db  2.7.6.1-2
ii  patch   2.7.5-1+b2
ii  patchutils  0.3.4-2
ii  python3-debian  0.1.30
ii  python3-magic   1:5.30-1+deb9u1
ii  sensible-utils  0.0.9+deb9u1
ii  strace  4.15-2
ii  unzip   6.0-21
ii  wdiff   1.2.2-2
ii  wget1.18-5+deb9u2
ii  xz-utils5.2.2-1.2+b1

Versions of packages devscripts suggests:
pn  adequate 
ii  autopkgtest  4.4
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-4
ii  build-essential  12.3
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
pn  gnuplot  
ii  gpgv 2.1.18-8~deb9u2
ii  how-can-i-help   15
ii  libauthen-sasl-perl  

Bug#906085: gcc-8: 2 simultaneous threads of compilation cause machine shutdown

[Arthur Marsh]

Hi, it appears that the symptoms were caused by running the build under a 
kernel revision (between 4.18.0-rc8 and 4.18.0) that had issues.

Apologies for the trouble. 

Please close the bug report.

On 14 August 2018 4:07:30 pm ACST, Bastian Blank  wrote:
>Hi Arthur
>
>On Tue, Aug 14, 2018 at 08:32:18AM +0930, Arthur Marsh wrote:
>> results in machine shutdown. Setting CONCURRENCY_LEGVEL=1 avoids the
>problem.
>
>While gcc may use the system in unusual ways, it does not have the
>permissions to shutdown a system.
>
>If a user space program breaks a system, it is either a broken kernel
>or
>broken hardware.
>
>> -- System Information:
>> Debian Release: buster/sid
>>   APT prefers oldstable
>>   APT policy: (500, 'oldstable'), (1, 'experimental')
>> Architecture: i386 (i686)
>
>buster and oldstable?  This policy makes no sense.
>
>> Kernel: Linux 4.18.0+ (SMP w/2 CPU cores; PREEMPT)
>
>I don't think we have unreleased kernels in Debian.  You may want to
>re-chekc this using a released version.
>
>Bastian
>
>-- 
>Humans do claim a great deal for that particular emotion (love).
>   -- Spock, "The Lights of Zetar", stardate 5725.6

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

Bug#905342: [pkg-apparmor] Bug#905342: apache fpm not working anymore

[Seth Arnold]

On Tue, Aug 14, 2018 at 01:01:59AM +0200, Ivan Sergio Borgonovo wrote:
> It seems that the new apparmor makes php-fpm start time sensibly higher and
> systemd timeout.
> 
> There is a correlation between php-fpm slowing down and the new version of
> apparmor but at the moment I just increased systemd timeout
> (TimeoutStartSec).

What was the old value, what is the new value?

Thanks


signature.asc
Description: PGP signature

Bug#906061: ledgersmb: [INTL:nl] Dutch translation of debconf messages

[Robert James Clay]

 On 13 Aug 2018 at 21:30, Frans Spiesschaert 
wrote:  

> Please find attached the updated Dutch translation of ledgersmb debconf  

> messages.  

   

This is to advise that I have imported the new version of the nl.po file into
the package git repository[1] and the update will be included with the next
package release  

Thanks!  

   

   

   

Robert James Clay, j...@rocasa.us  

[1] https://github.com/ledgersmb/pkg-ledgersmb  

 

Bug#906128: libykpiv1 impacted by CVE-2018-14779 and CVE-2018-14780

[Nicolas Braud-Santoni]

Hi Salvatore,

On Tue, Aug 14, 2018 at 09:55:39PM +0200, Salvatore Bonaccorso wrote:
> On Tue, Aug 14, 2018 at 08:36:10PM +0200, Nicolas Braud-Santoni wrote:
> > Hi,
> > 
> > Gunnar Wolf sponsored the upload to sid (thanks!) and I just prepared an
> > upload for stretch-security.  It is available in the branch debian/stretch 
> > on:
> > 
> >   https://salsa.debian.org/auth-team/yubico-piv-tool.git
> > 
> > If the security team finds it suitable, please upload directly.
> 
> The issue does not warrant a DSA (was marked no-dsa in the tracker
> already). Can you though propose a fix to be included in the next
> stretch point release?

Yes, jcristau pointed out on IRC that there was a race condition between my mail
and the update of the security-tracker; I updated the changelog for an upload
to stretch-p-u, and jcc@ said he will look at it tomorrow.

Thanks for the swift reply  :)


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#906017: java.lang.UnsatisfiedLinkError: Cannot load 64-bit SWT libraries on 32-bit JVM

[tony mancill]

On Mon, Aug 13, 2018 at 11:43:42AM +0200, Dirk Griesbach wrote:
> Package: jameica
> Version: 2.8.0+dfsg-1
> Severity: normal
> 
> I tried to test jameica (well, hibiscus to be precise) but it fails to 
> start with:
> 
> ~$ jameica
> NOTE: Picked up JDK_JAVA_OPTIONS: --add-modules=java.se.ee
> java.lang.UnsatisfiedLinkError: Cannot load 64-bit SWT libraries on 32-bit JVM
>
> 
> 
> This is a 32bit machine using system openjdk-10-jre 10.0.2+13-1.

Hello Dirk,

stegosuite currently has the exact same problem [1].  I suspect there's
something generally wrong with our SWT packaging, although I haven't
figured out what it is yet.  Once I do, I'll assign the bug report(s)
appropriately.

Thank you for reporting this issue.
tony

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


signature.asc
Description: PGP signature

Bug#906149: gnu-smalltalk: 'ZeroDivide' error

[bill-auger]

Package: gnu-smalltalk
Version: 3.2.5-1+b3
Severity: important

Dear Maintainer,

1. install gnu-smalltalk from debian 9 main
2. launch gst REPL
3. enter 0.05 or 1e-4
4. expected: 0.05 or 0.0001
5. actual:
  $ gst
  st> x := 1e-4
  Object: 1 error: The program attempted to divide a number by zero
  ZeroDivide(Exception)>>signal (ExcHandling.st:254)
  SmallInteger(Number)>>zeroDivide (SysExcept.st:1426)
  Fraction>>setNumerator:setDenominator: (Fraction.st:485)
  Fraction class>>numerator:denominator: (Fraction.st:66)
  Fraction>>- (Fraction.st:151)
  FloatE(Float)>>printOn:special: (Float.st:533)
  FloatE(Float)>>printOn: (Float.st:436)
  FloatE(Object)>>printString (Object.st:534)
  FloatE(Object)>>printNl (Object.st:571)


this error is also present in the current unstable package
'gnu-smalltalk_3.2.5-1.1+b1_amd64.deb'

compiling from source fixes the problem

it was suggested on the gnu-smalltalk mailing list-1= that this error
may be caused by the package being compiled with option -pie; but it is
not clear that the -pie flag is the cause

`gcc -v` and `g++ -v` both show --enable-default-pie; but i can not
reproduce the 'ZeroDivide' problem compiling myself from git[2] -
compiling with all of the following flags produce the same (non-error)
result for 1e-4 and 0.05:

  $ make CFLAGS='-no-pie'
  $ make CFLAGS='-pie'
  $ make

  $ /usr/local/bin/gst
  GNU Smalltalk ready

  st> 0.05
  0.05


[1]: http://lists.gnu.org/archive/html/help-smalltalk/2018-08/msg4.html
[2]: http://git.savannah.gnu.org/cgit/smalltalk.git/


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

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

Versions of packages gnu-smalltalk depends on:
ii  libc62.24-11+deb9u3
ii  libgnutls30  3.5.8-5+deb9u3
ii  libgst7  3.2.5-1+b3
ii  unzip6.0-21
ii  zip  3.0-11+b1

Versions of packages gnu-smalltalk recommends:
ii  gnu-smalltalk-common  3.2.5-1

Versions of packages gnu-smalltalk suggests:
ii  gnu-smalltalk-doc  3.2.5-1

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#848190: marked as done (libmozjs-24-0: gnome-shell segfault and hundreds of libmozjs tests fails)

[Simon McVittie]

On Tue, 14 Aug 2018 at 22:50:50 +0100, Liam Wilson wrote:
> Sorry, not sure if I follow. Do you mean that this issue with mozjs24
> will not be fixed for stretch on armhf?

Closing the bug in the context of unstable has no influence on whether
it exists or will be fixed in stretch, but it makes it one less thing
to triage for people who are working on unstable. The reason I was
looking at mozjs24 bugs was to check whether any of them needed to be
cloned or reassigned to mozjs52 before mozjs24 is removed from unstable.

Release-critical or important bugs can be fixed in stretch if the benefit
of fixing them is greater than the risk of regressions. However, we have
to be conservative about what goes into stretch, because if we didn't,
there would be no benefit in making stable releases; for people with
more tolerance of regressions, there's testing/unstable.

> Also you
> appear to have disabled jsctypes in mozjs52 (which is a very useful
> FFI, which I happen to require).

The reason that mozjs52 was packaged by the GNOME team was for the
benefit of gjs and policykit-1, which as far as I know don't benefit from
jsctypes. If you propose a patch on a separate bug that enables jsctypes
without causing regressions for mozjs/gjs, that seems like something
that could be enabled in mozjs52 (or perhaps more likely mozjs60 at this
point). mozjs24 no longer exists in unstable, and feature enhancements are
out of scope for stable, so if it doesn't already have jsctypes enabled,
it probably never will.

I'm only working on these packages because they block inclusion of
newer versions of GNOME, and I don't really understand JavaScript, so
I'm really not the right person to be doing the cost/benefit analysis
here and would prefer to defer to people who know mozjs better.

> I think adding some compiler flags to disable problematic
> optimisations will resolve the issue. Adding the following lines to
> debian/rules seems to fix the crashes and test failures:
> 
> export DEB_CFLAGS_MAINT_APPEND = -fno-schedule-insns2
> -fno-lifetime-dse -fno-delete-null-pointer-checks -fno-schedule-insns
> export DEB_CXXFLAGS_MAINT_APPEND = -fno-schedule-insns2
> -fno-lifetime-dse -fno-delete-null-pointer-checks -fno-schedule-insns

mozjs52 in unstable has similar options set, so that looks promising.
It's unfortunate that the mozjs24 packaging ignored build-time test
failures, which I think led to it being built but partially or entirely
non-functional on many architectures; we've been trying to do better
in mozjs52.

> When I was building test packages locally I tried to enable these
> flags conditionally, but I had trouble doing so (maybe something to do
> with being on Raspbian?). Any chance you can enable those compiler
> flags on stretch armhf?

Debian is not responsible for Raspbian: it is a separate (derivative)
distribution, built with a different architecture baseline. Any changes
made to a Debian package should have been tested on a Debian system.

(I believe all Raspberry Pi models can run Debian armel with a third-party
kernel, while the Raspberry Pi 2 and up can run Debian armhf, and the
Pi 3 should be able to run arm64. There are some shared machines where
Debian developers can test proposed patches, but they're rather slow.)

You might find the mozjs52 packaging in unstable helpful: it sets a lot
of architecture-conditional compiler options.

Sorry, I'm already at the limits of my JavaScript and compiler knowledge
with mozjs52 uploads in unstable, so I am certainly not the right person
to be backporting this to stable. Perhaps the mozjs24 package's maintainer
can help?

Alternatively, if this bug is more severe in Raspbian than it is in
Debian due to Raspbian's focus on armhf, you could see whether there are
Raspbian developers who could integrate changes there.

smcv

Bug#906148: plasma-wallpapers-addons: It does not work the picture of the day with kscreenlocker5.

[Santiago José López Borrazás]

Package: plasma-wallpapers-addons
Version: 4:5.13.2-1
Severity: normal

Dear Maintainer,

On having formed correctly and having been able to see the picture of the day, 
they do not show me in the screenlocker. It goes out quite black.

Only, to point out one of the places that Bing should have picture of the day, 
for example, or Wikimedia. They do not appear. But yes, they go out perfectly 
in the desktop.

In the file.xsession-errors it shows me:

lock called
Lock window Id:  18874395
CreateNotify: 18874395
CreateNotify: 79691780
CreateNotify: 79691783
CreateNotify: 79691787
CreateNotify: 79691789
CreateNotify: 79691791
CreateNotify: 79691793
MapNotify: 79691791
kf5.kio.core: KIO Connection server not listening, could not connect
kf5.kio.core: KIO Connection server not listening, could not connect
kf5.kio.core: couldn't create slave: "No se ha podido crear un socket para 
lanzar el esclavo de e/s para el protocolo «https»."

It is understood, that I have no entry / exit for the protocol https.

Or it is a mistake of the bundle or that something is missing. Am I wrong?

Thanks.

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

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

Versions of packages plasma-wallpapers-addons depends on:
ii  kdeplasma-addons-data  4:5.13.2-1
ii  plasma-framework   5.47.0-1

plasma-wallpapers-addons recommends no packages.

plasma-wallpapers-addons suggests no packages.

-- no debconf information

Bug#883950: Next steps on "[GPL-3+]" proposal

[Russ Allbery]

Ian Jackson  writes:

> I am against the version number change.  Version numbers, and particular
> version number bumps, in protocols like this are a very heavy hammer.
> Where present, they should be bumped only when necessary.  They are
> necessary only when a tool which is written to the old format will *do
> the wrong thing* with the extended format.

> If a reasonable tool written to the old format will either do a
> plausible thing, or reject the input, if fed the new format, then it
> is a bad idea to bump the version number.

> That is the case here.

My preference is that at the end of this change we have two fields, a
License field that includes the full license text and a License-Identifier
field that has just short identifiers (including now using
License-Identifier in places where the current format uses License without
an accompanying license paragraph).  That change will require changing all
parsers to understand the new format.

That change is somewhat painful, but avoiding it is going to be more
painful in the long run.  It was a mistake in the original specification
to allow one field to have two different syntaxes in a very
context-sensitive way, and now we would be adding even more complexity to
the decision between those two syntaxes.  I believe we should just fix the
original specification bug and be done, painful though that may be, and
allow parsers to not carry this complexity load forever.

> TBH I think even having a version number at all in the
> machine-readable copyright format is quite possibly a mistake.

That's other entirely valid approach: to just set the format in stone,
never admit a backward-incompatible change, and live with the initial
decisions, warts and all, that cannot be fixed without breaking backwards
compatibility.  That's what MIME ended up doing.

But I don't think our install base is so large as to require that, and I
do think it's feasible to fix all the parsers.  The reason MIME went down
that path is because it was not reasonable to fix all the parsers.

-- 
Russ Allbery (r...@debian.org)   

Bug#906147: python-smoke-zephyr ftbfs (failing tests)

[Matthias Klose]

Package: src:python-smoke-zephyr
Version: 1.2.0-1
Severity: serious
Tags: sid buster

python-smoke-zephyr ftbfs (failing tests). Please also make it clear which
Python version is used during the tests.


   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:217: cd
/<>/.pybuild/cpython2_2.7_smoke-zephyr/build; python2.7 -m unittest
discover -v -s /<>/tests -p "[a-z]*.py"
test_job_add (job.JobManagerTests) ... ok
test_job_delete (job.JobManagerTests) ... ok
test_job_disable (job.JobManagerTests) ... ok
test_job_init (job.JobManagerTests) ... ok
test_job_request_delete (job.JobManagerTests) ... ok
test_job_run (job.JobManagerTests) ... ok
test_cache (utilities.UtilitiesCacheTests) ... ok
test_cache_cache_clear (utilities.UtilitiesCacheTests) ... ok
test_cache_flatten_args (utilities.UtilitiesCacheTests) ... ok
test_attribute_dict (utilities.UtilitiesTests) ... ok
test_escape_single_quote (utilities.UtilitiesTests) ... ok
test_is_valid_email_address (utilities.UtilitiesTests) ... ok
test_parse_case_camel_to_snake (utilities.UtilitiesTests) ... ok
test_parse_case_snake_to_camel (utilities.UtilitiesTests) ... ok
test_parse_server (utilities.UtilitiesTests) ... ok
test_parse_timespan (utilities.UtilitiesTests) ... ok
test_parse_to_slug (utilities.UtilitiesTests) ... ok
test_selection_collision (utilities.UtilitiesTests) ... ok
test_unescape_single_quote (utilities.UtilitiesTests) ... ok
test_bin_b64_type (argparse_types.ArgparseTypeTests) ... ok
test_bin_hex_type (argparse_types.ArgparseTypeTests) ... ok
test_dir_type (argparse_types.ArgparseTypeTests) ... ok
test_log_level_type (argparse_types.ArgparseTypeTests) ... ok
test_port_type (argparse_types.ArgparseTypeTests) ... ok
test_timespan_type (argparse_types.ArgparseTypeTests) ... ok

--
Ran 25 tests in 14.038s

OK
I: pybuild base:217: cd
/<>/.pybuild/cpython3_3.7_smoke-zephyr/build; python3.7 -m unittest
discover -v -s /<>/tests -p "[a-z]*.py"
test_bin_b64_type (argparse_types.ArgparseTypeTests) ... ok
test_bin_hex_type (argparse_types.ArgparseTypeTests) ... ok
test_dir_type (argparse_types.ArgparseTypeTests) ... ok
test_log_level_type (argparse_types.ArgparseTypeTests) ... ok
test_port_type (argparse_types.ArgparseTypeTests) ... ok
test_timespan_type (argparse_types.ArgparseTypeTests) ... ok
test_job_add (job.JobManagerTests) ... ok
test_job_delete (job.JobManagerTests) ... ok
test_job_disable (job.JobManagerTests) ... ok
test_job_init (job.JobManagerTests) ... ok
test_job_request_delete (job.JobManagerTests) ... FAIL
test_job_run (job.JobManagerTests) ... ok
test_cache (utilities.UtilitiesCacheTests) ...
/<>/.pybuild/cpython3_3.7_smoke-zephyr/build/smoke_zephyr/utilities.py:135:
DeprecationWarning: inspect.getargspec() is deprecated, use inspect.signature()
or inspect.getfullargspec()
  arg_spec = inspect.getargspec(target_function)  # pylint: disable=W1505
/<>/.pybuild/cpython3_3.7_smoke-zephyr/build/smoke_zephyr/utilities.py:144:
DeprecationWarning: Using or importing the ABCs from 'collections' instead of
from 'collections.abc' is deprecated, and in 3.8 it will stop working
  if not isinstance(args, collections.Hashable):
ok
test_cache_cache_clear (utilities.UtilitiesCacheTests) ... ok
test_cache_flatten_args (utilities.UtilitiesCacheTests) ... ok
test_attribute_dict (utilities.UtilitiesTests) ... ok
test_escape_single_quote (utilities.UtilitiesTests) ... ok
test_is_valid_email_address (utilities.UtilitiesTests) ... ok
test_parse_case_camel_to_snake (utilities.UtilitiesTests) ... ok
test_parse_case_snake_to_camel (utilities.UtilitiesTests) ... ok
test_parse_server (utilities.UtilitiesTests) ... ok
test_parse_timespan (utilities.UtilitiesTests) ... ok
test_parse_to_slug (utilities.UtilitiesTests) ... ok
test_selection_collision (utilities.UtilitiesTests) ... ok
test_unescape_single_quote (utilities.UtilitiesTests) ... ok

==
FAIL: test_job_request_delete (job.JobManagerTests)
--
Traceback (most recent call last):
  File "/<>/tests/job.py", line 97, in test_job_request_delete
self.assertFalse(self.jm.job_exists(jid))
AssertionError: True is not false

--
Ran 25 tests in 16.037s

FAILED (failures=1)
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd
/<>/.pybuild/cpython3_3.7_smoke-zephyr/build; python3.7 -m unittest
discover -v -s {dir}/tests -p "[a-z]*.py"
dh_auto_test: pybuild --test -i python{version} -p "3.7 3.6" returned exit code 
13

Bug#898520: u-boot-rockchip: firefly-rk3288 hangs on: Loading Environment from MMC

[Vagrant Cascadian]

On 2018-08-14, Vagrant Cascadian wrote:
>> Also just tried with v2018.09-rc2, same problem.

With some debugging in mmc enabled (#define DEBUG at the top of dw_mmc.c
mmc-uclass.c mmc.c rockchip_dw_mmc.c) and CONFIG_MMC_TRACE=y, it gives a
little more information:

U-Boot SPL 2018.09-rc2+dfsg-1~20180814~6 (Aug 14 2018 - 21:58:09 +)
Returning to boot ROM...
mmc_bind: alias ret=0, devnum=1


U-Boot 2018.09-rc2+dfsg-1~20180814~6 (Aug 14 2018 - 21:58:09 +)

Model: Firefly-RK3288
DRAM:  2 GiB
mmc_bind: alias ret=0, devnum=1
mmc_bind: alias ret=0, devnum=0
MMC:   dwmmc@ff0c: 1, dwmmc@ff0f: 0
Loading Environment from MMC... clock is disabled (0Hz)

Buswidth = 0, clock: 0


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#892543: network-manager-gnome: nm-applet in xfce4 notification area is active but has no icon

[Michael Biebl]

Control: tags -1 moreinfo

On Sat, 10 Mar 2018 05:13:25 -0500 Arjen Balfoort
 wrote:
> Package: network-manager-gnome
> Version: 1.8.10-2
> Severity: important
> Tags: a11y
> 
> Dear Maintainer,
> 
>* What led up to the situation?
>Setting up Network Manager on Xfce4 (aarch64) resulted in having an 
> invisible Network Manger applet in the notification area.
>On boot the icon flashes just before disappearing.
>Left and right actions do function properly (I let the notification area 
> show its borders to make it easier to find the nm-applet).
> 
>Other icons show correctly in the notification area.
> 
>* What exactly did you do (or not do) that was effective (or ineffective)?
>I found these similar reports but I decided to report this issue because 
> this issue was found on aarch64 and the other reports did not describe 
> exactly this issue (nm-applet is functional but just not showing in the 
> notification area):
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549541 > 4 Oct 2009, no 
> solution
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572714 > 5 March 2010, 
> no solution
> 
>I tested with several styles and icon themes (Gnome, Breeze, etc.) and 
> tried to change icon size for the notification area but the icon still did 
> not show.
>Although the icon flashes on boot I still checked that nm-applet* icons 
> existed in the icon themes (all svg).
> 
>* What was the outcome of this action?
>There was no change.
> 
>* What outcome did you expect instead?
>Network Manager applet would show the correct icon in the notification 
> area.
> 
>If you want I can provide an image for the RPi3.

Unfortunately I can't reproduce your problem on Debian.
Is this problem reproducible on a Debian stretch or sid system?
If you start nm-applet from the console, do you get any error messages?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#906138: [Pkg-auth-maintainers] Bug#906138: libykneomgr: out of bounds read/writes

[Salvatore Bonaccorso]

Hi Simon,

On Tue, Aug 14, 2018 at 10:35:26PM +0200, Simon Josefsson wrote:
> Yes, removing the package from testing seems reasonable to me.

Can you fill a separate bug to ftp.debian.org to request a removal from
unstable (and so buster/testing)? Having this RC bug will at least
though ensure it will be removed at some point from testing.

I just checked, there should be no conflict in doing so:

> $ dak rm --suite=sid -n -R libykneomgr
> Will remove the following packages from sid:
> 
> libykneomgr |  0.1.8-2.2 | source
> libykneomgr-dev |  0.1.8-2.2 | amd64, arm64, armel, armhf, hurd-i386, i386, 
> kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, ppc64el, s390x
> libykneomgr0 |  0.1.8-2.2 | amd64, arm64, armel, armhf, hurd-i386, i386, 
> kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, ppc64el, s390x
>   ykneomgr |  0.1.8-2.2 | amd64, arm64, armel, armhf, hurd-i386, i386, 
> kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, ppc64el, s390x
> 
> Maintainer: Debian Authentication Maintainers 
> 
> 
> --- Reason ---
> 
> --
> 
> Checking reverse dependencies...
> No dependency problem found.

Regards,
Salvatore

Bug#848190: marked as done (libmozjs-24-0: gnome-shell segfault and hundreds of libmozjs tests fails)

[Liam Wilson]

> -- Forwarded message --
> From: Simon McVittie 
> To: Alban Browaeys , 848190-d...@bugs.debian.org, Liam 
> Wilson , Marian Mihailescu 
> Cc:
> Bcc:
> Date: Mon, 13 Aug 2018 09:47:15 +0100
> Subject: Re: Bug#848190: libmozjs-24-0: gnome-shell segfault and hundreds of 
> libmozjs tests fails
> Package: libmozjs-52-0
> Version: 52.9.1-1
>
> On Thu, 15 Dec 2016 at 01:07:14 +0100, Alban Browaeys wrote:
>> gnome-shell ion armhf segfaults
>
> On Thu, 05 Apr 2018 at 16:10:23 +0100, Liam Wilson wrote:
>> This package is totally bust on armhf in stretch
>
> mozjs24 has been superseded by mozjs52 in testing/unstable, and mozjs52
> passes tests on armhf. This bug remains present in mozjs24 in stretch,
> but version tracking will keep track of that.
>
> smcv

Sorry, not sure if I follow. Do you mean that this issue with mozjs24
will not be fixed for stretch on armhf? mozjs52 is not a drop in
replacement for mozjs24 (it is not API or ABI compatible). Also you
appear to have disabled jsctypes in mozjs52 (which is a very useful
FFI, which I happen to require). For my purposes I've built my own
armhf shell build of mozjs60, but it would be nice if the version that
shipped with stretch armhf worked.

I think adding some compiler flags to disable problematic
optimisations will resolve the issue. Adding the following lines to
debian/rules seems to fix the crashes and test failures:

export DEB_CFLAGS_MAINT_APPEND = -fno-schedule-insns2
-fno-lifetime-dse -fno-delete-null-pointer-checks -fno-schedule-insns
export DEB_CXXFLAGS_MAINT_APPEND = -fno-schedule-insns2
-fno-lifetime-dse -fno-delete-null-pointer-checks -fno-schedule-insns

I then built js24 with debian/rules build. Once it had built I ran
both the jit-tests and the jstests. There were vastly fewer test
failures (about 7 total as opposed to hundreds). The test case I
posted also runs to completion without segfaulting:

pi@raspberrypi:~/src/mozjs/mozjs24-24.2.0/js/src $ dist/bin/js24  -e
"for(var i=0;i<1e5;i++){}"
pi@raspberrypi:~/src/mozjs/mozjs24-24.2.0/js/src $ echo $?
0

Test results (I think the format is something like [PASS|UNEXPECTED
FAILURE|EXPECTED FAILURE|SKIPPED]):

pi@raspberrypi:~/src/mozjs/mozjs24-24.2.0/js/src $ time
./jit-test/jit_test.py  dist/bin/js24
[ 928|   0|   0|   0]  25% => |  77.8s
FAIL - 
/home/pi/src/mozjs/mozjs24-24.2.0/js/src/jit-test/tests/basic/bug698584.js
[1033|   1|   0|   0]  28% ===>   |  86.9s
FAIL - 
/home/pi/src/mozjs/mozjs24-24.2.0/js/src/jit-test/tests/basic/bug839215.js
[3685|   2|   0|   0] 100% ==>| 296.6s
FAILURES:
/home/pi/src/mozjs/mozjs24-24.2.0/js/src/jit-test/tests/basic/bug698584.js
/home/pi/src/mozjs/mozjs24-24.2.0/js/src/jit-test/tests/basic/bug839215.js
TIMEOUTS:


pi@raspberrypi:~/src/mozjs/mozjs24-24.2.0/js/src $ time
./tests/jstests.py  dist/bin/js24
[ 146|   0|   0| 601]  11% >  |  11.2s
REGRESSION - js1_8_5/extensions/typedarray.js
[ 991|   1|   0| 601]  25% => | 110.5s
REGRESSION - js1_5/extensions/toLocaleFormat-01.js
[1118|   2|   0| 602]  27% ==>| 119.3s
REGRESSION - js1_5/extensions/toLocaleFormat-02.js
[1552|   3|   0| 603]  34% => | 145.2s
REGRESSION - ecma_5/RegExp/regress-617935.js
[5601|   4|   0| 607]  98% => | 566.7s
REGRESSION - ecma_3/Date/15.9.5.6.js
[5706|   5|   0| 609] 100% ==>| 572.4s
REGRESSIONS
js1_8_5/extensions/typedarray.js
js1_5/extensions/toLocaleFormat-01.js
js1_5/extensions/toLocaleFormat-02.js
ecma_5/RegExp/regress-617935.js
ecma_3/Date/15.9.5.6.js
FAIL

When I was building test packages locally I tried to enable these
flags conditionally, but I had trouble doing so (maybe something to do
with being on Raspbian?). Any chance you can enable those compiler
flags on stretch armhf?

Thanks
Liam

Bug#887467: hpanel: x86_64 shows broken icons

[Paul Szabo]

Dear Bernhard,

Thanks, your patches (this one for icons, and bug#887468 for crash)
work perfectly!

Thanks, Paul
-- 
Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

Bug#905996: nmu: clsync_0.4.1-1

[Aurelien Jarno]

Hi Niels,

On 2018-08-14 17:53, Niels Thykier wrote:
> Control: tags -1 moreinfo
> 
> Aurelien Jarno:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: binnmu
> > 
> > Hi release team,
> > 
> > One of the goal of the glibc team for buster is to get rid of the
> > multiarch-support package, given that multiarch support in the dynamic
> > loader is fully supported in debian for a long time. Debhelper used to
> > add this dependency, but it's not the case anymore.
> > 
> > clsync is one out of two packages left in buster, the other one,
> > gtk2-engines-oxygen, should hopefully migrate in the next days.
> > Unfortunately clsync has an RC bug in sid, which prevents it to migrate
> > to buster. This RC bug is not present in buster, so the package hasn't
> > been autoremoved from there.
> > 
> > Therefore the easiest way to fix the issue is to trigger a binNMU in
> > *buster*, against a "recent" debhelper:
> > 
> > nmu clsync_0.4.1-1 . ANY . buster . -m "Rebuild to remove the 
> > pre-dependency on multiarch-support"
> > 
> > Thanks,
> > Aurelien
> > 
> > [...]
> 
> Hi Aurelien,
> 
> If the goal is to make testing free of packages (Pre-)Depending on
> multiarch-support

Yes, that's exactly the goal, that way we can just stop building the
package in the next upload. There are still a few depending packages
in sid/experimental, but given the bug reports have been sent with
patches attached more than one year ago, I don't mind breaking them.

> then removing clsync from testing is also an option
> AFAICT.
> 
> I am considering since clsync has had its FTBFS bug against sid for
> almost 2 years now with no reaction from its maintainers.

That solution has the same result than the binNMU, so that's also fine
for me. I would leave the decision about what is the best way to achieve
that to the release team.

Thanks,
Aurelien

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

Bug#906146: upload queues: changes files should be transferred last

[Aurelien Jarno]

Package: ftp.debian.org
Severity: important

Transfers between the upload queues and ftp-master / security-master are
done using rsync. The connection sometimes fail, which causes some files
to be missing and the package to be rejected. In that cases it's not
possible to reupload the package from the buildd as the signature has
already been seen by dak.

I guess the same strategy than in dput / dupload should be applied, that
is to transfer the changes file last. That way the next rsync run could
transfer the missing files.

Bug#905171: [Pkg-utopia-maintainers] Bug#905171: Subject: network-manager: Network-manager will not connect to known wifi networks "no secrets provided"

[Michael Biebl]

Control: reassign -1 plasma-nm

On Wed, 1 Aug 2018 13:13:59 +0200 Michael Biebl  wrote:
> Control: tags -1 moreinfo
> 
> Am 01.08.2018 um 08:57 schrieb Jon Westgate:
> > Package: network-manager
> > Version: 1.12.2-1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > Since upgrading from NM version 1.10.x I've noticed that it is getting
> > increasingly hard to connect to wifi networks.
> > With version 1.11.x you couldn't switch networks without first
> > disconnecting. That was not ideal but I could deal with it.
> > Version 1.12.x is just unusable it just tells me "No secrets provided"
> > and or "No Agents were available for this request"
> > I'm running KDE so using the plasma UI. If I just downgrade to 1.10.x
> > everything just works again wifi automaticly connects as soon as dpkg
> > has finished.
> > Is there something silly that needs doing like purging settings that
> > will fix this? The annoying thing about downgrading is that it means I
> > can't use PPP and therefore
> > most VPN's are unavailable to me.
> 
> Secrects are typically provided by a desktop component. In your case plasma.
> 
> Can you try with a minimal desktop environment and network-manager-gnome
> (nm-applet) if the problem is reproducible there?
> If not, this should probably be reassigned to the plasma desktop (not
> sure which component exactly is responsible there for NM support)
> 
> An (temporary) workaround might be to store the wifi password system
> wide. You can use nm-connection-editor.
> In the WiFi Security tab, choose the option "Store the password for all
> users"

This sounds like a plasma-nm related problem, as I can't reproduce the
problem with either GNOME nor nm-applet.

Reassigning accordingly.
Jon, you might add the version information by running
reportbug --template plasma-nm

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#902875: Patch

[Francois Marier]

tags 902875 +patch
thanks

According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902413#12,
all that's needed is to change `/var/run/` to `/run/` in
/usr/lib/tmpfiles.d/postgresql.conf.

I've attached a patch.

Francois

-- 
https://fmarier.org/
diff --git a/debian/postgresql-common.postgresql.tmpfile b/debian/postgresql-common.postgresql.tmpfile
index fba0fc9..7974636 100644
--- a/debian/postgresql-common.postgresql.tmpfile
+++ b/debian/postgresql-common.postgresql.tmpfile
@@ -1,4 +1,4 @@
 # Directory for PostgreSQL sockets, lockfiles and stats tempfiles
-d /var/run/postgresql 2775 postgres postgres - -
+d /run/postgresql 2775 postgres postgres - -
 # Log directory
 d /var/log/postgresql 1775 root postgres - -

Bug#898520: u-boot-rockchip: firefly-rk3288 hangs on: Loading Environment from MMC

[Vagrant Cascadian]

On 2018-08-14, Vagrant Cascadian wrote:
> On 2018-06-05, Vagrant Cascadian wrote:
>> On 2018-05-21, Vagrant Cascadian wrote:
>>> On 2018-05-12, Vagrant Cascadian wrote:
 On 2018-05-12, Vagrant Cascadian wrote:
> Booting firefly-rk3288 seems to hang looking for environment:
>
>   U-Boot 2018.05+dfsg-1 (May 10 2018 - 20:24:57 +)
>   
>   Model: Firefly-RK3288
>   DRAM:  2 GiB
>   MMC:   dwmmc@ff0c: 1, dwmmc@ff0f: 0
>   Loading Environment from MMC...
>
> And just hangs there.
>>
>> Still happening with v2018.07-rc1, too.
>
> Also just tried with v2018.09-rc2, same problem.

Adding Philipp Tomsich to CC.

The not very detailed log of the Debian bug report is at:

  https://bugs.debian.org/898520

v2018.01 works, v2018.03 doesn't, the closest I got to bisecting the
issue:

>>> I tried to bisect this, and got:
>>>
>>> commit 04a2ea248f58b3b6216d0cd0a6b8698df8b14355
>>> Author: Jean-Jacques Hiblot 
>>> Date:   Thu Sep 21 16:30:08 2017 +0200
>>>
>>> mmc: disable UHS modes if Vcc cannot be switched on and off
>>>
>>>
>>> But it fails in a slightly different way:
>>>
>>>   U-Boot 2018.01-00026-g04a2ea248f (May 21 2018 - 21:46:18 +)
>>>
>>>   Model: Firefly-RK3288
>>>   DRAM:  2 GiB
>>>   MMC:   dwmmc@ff0c: 1, dwmmc@ff0f: 0
>>>
>>> And just hangs without the "Loading Environment from MMC..."
>>> part...
>>>
>>>
>>> It is not a trivial revert on top of 2018.05, so I haven't been able to
>>> do that simple test.

Any further suggestions would be appreciated.

Thanks!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#898520: u-boot-rockchip: firefly-rk3288 hangs on: Loading Environment from MMC

[Vagrant Cascadian]

On 2018-06-05, Vagrant Cascadian wrote:
> On 2018-05-21, Vagrant Cascadian wrote:
>> On 2018-05-12, Vagrant Cascadian wrote:
>>> On 2018-05-12, Vagrant Cascadian wrote:
 Booting firefly-rk3288 seems to hang looking for environment:

   U-Boot 2018.05+dfsg-1 (May 10 2018 - 20:24:57 +)
   
   Model: Firefly-RK3288
   DRAM:  2 GiB
   MMC:   dwmmc@ff0c: 1, dwmmc@ff0f: 0
   Loading Environment from MMC...

 And just hangs there.
>
> Still happening with v2018.07-rc1, too.

Also just tried with v2018.09-rc2, same problem.

live well,
  vagrant

>> I tried to bisect this, and got:
>>
>> commit 04a2ea248f58b3b6216d0cd0a6b8698df8b14355
>> Author: Jean-Jacques Hiblot 
>> Date:   Thu Sep 21 16:30:08 2017 +0200
>>
>> mmc: disable UHS modes if Vcc cannot be switched on and off
>>
>>
>> But it fails in a slightly different way:
>>
>>   U-Boot 2018.01-00026-g04a2ea248f (May 21 2018 - 21:46:18 +)
>>
>>   Model: Firefly-RK3288
>>   DRAM:  2 GiB
>>   MMC:   dwmmc@ff0c: 1, dwmmc@ff0f: 0
>>
>> And just hangs without the "Loading Environment from MMC..."
>> part...
>>
>>
>> It is not a trivial revert on top of 2018.05, so I haven't been able to
>> do that simple test.


signature.asc
Description: PGP signature

Bug#906145: stretch-pu: package vmtk/1.3+dfsg-2.1+deb9u1

[Adrian Bunk]

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

  * python-vmtk: Add the missing dependency on python-vtk6.
(Closes: #904763)
diff -Nru vmtk-1.3+dfsg/debian/changelog vmtk-1.3+dfsg/debian/changelog
--- vmtk-1.3+dfsg/debian/changelog  2017-01-18 23:36:18.0 +0200
+++ vmtk-1.3+dfsg/debian/changelog  2018-08-14 23:17:15.0 +0300
@@ -1,3 +1,11 @@
+vmtk (1.3+dfsg-2.1+deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * python-vmtk: Add the missing dependency on python-vtk6.
+(Closes: #904763)
+
+ -- Adrian Bunk   Tue, 14 Aug 2018 23:17:15 +0300
+
 vmtk (1.3+dfsg-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru vmtk-1.3+dfsg/debian/control vmtk-1.3+dfsg/debian/control
--- vmtk-1.3+dfsg/debian/control2017-01-18 23:36:13.0 +0200
+++ vmtk-1.3+dfsg/debian/control2018-08-14 23:17:15.0 +0300
@@ -47,6 +47,7 @@
 Section: non-free/python
 Depends: libvmtk1.3 (= ${binary:Version}),
  ${python:Depends},
+ python-vtk6,
  ${shlibs:Depends},
  ${misc:Depends}
 Description: Python interface for vmtk

Bug#906138: [Pkg-auth-maintainers] Bug#906138: libykneomgr: out of bounds read/writes

[Simon Josefsson]

Yes, removing the package from testing seems reasonable to me.

/Simon

> 14 aug. 2018 kl. 20:39 skrev Salvatore Bonaccorso :
> 
> Source: libykneomgr
> Version: 0.1.8-1
> Severity: grave
> Tags: security upstream
> 
> Hi
> 
> See https://www.x41-dsec.de/lab/advisories/x41-2018-004-libykneomgr/
> for details. Upstream will  not issue a patch for it as vendor does
> not support the library anymore.
> 
> Should we consider removing libykneomgr from Debian?
> 
> Regards,
> Salvatore
> 
> ___
> Pkg-auth-maintainers mailing list
> pkg-auth-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-auth-maintainers

Bug#886291: Fwd: Re: pycryptodome naming

[Alexis Murzeau]

--- Begin Message ---
[Alexis Murzeau]
> Currently, packages which depends on python3-pycryptodome are:
> - python3-httpsig
> - python3-pysnmp4

Note, I had to patch python3-httpsig to get it to use the current
namespace.  Feel free to NMU when needed, but remember to check out
debian/patches/2001-cryptodomex-namespace.patch.

I'll update it with the missing build-dep soon, unless you beat me to
it. :)

-- 
Happy hacking
Petter Reinholdtsen
--- End Message ---

Bug#906144: libmypaint-common: drop Conflicts: mypaint-data

[Adrian Bunk]

Package: libmypaint-common
Version: 1.3.0-2
Severity: important
Control: affects -1 mypaint-data mypaint gimp

The Conflicts: mypaint-data should be dropped when the
file conflict is resolved, see #894757 for background.

Bug#905650: Tested on Debian buster : bug fixed

[Benoit Bolsee]

Hi,

Following your advise I first tested if the bug is still there on Debian
testing and it's not : the sequence of event is still the same as I
described except that the relocation dependency of libm towards libperl
is gone and now libperl unloads properly when mod_perl is unloaded =>
the PL_check array is fresh clean on the second reload and there is no
invalid pointer.

So there is a fix that could perhaps be backported in Debian stretch
about removing this relocation dependency. I didn't investigate what it
could be.

Bug#906143: shotwell: Apply packaging updates from Ubuntu

[Jeremy Bicha]

Source: shotwell
Version: 0.28.4-1
Tags: patch

The Ubuntu package has several packaging improvements, many of which
can be applied in Debian too. Specifically these commits:

- Don't clutter up debian/ with old, disabled patches
- Clean up rules
- Install Appstream metadata
- Build with meson
- Build with gnome-pkg-tools

https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/shotwell

Thanks,
Jeremy Bicha

Bug#906112: closed by Niels Thykier (Bug#906112: fixed in libcdio-paranoia 10.2+0.94+2-4)

[Andreas Beckmann]

On 2018-08-14 21:27, Debian Bug Tracking System wrote:
>* Remove cd-paranoia package again; the binary is also provided by
>  libcdio-utils.  (Reopens: #889803, Closes: #906112)

Nope, it is no longer provided by libcdio-utils >= 0.92

This was an issue upgrading from stretch.


Andreas

Bug#906142: stretch-pu: package vulture/0.11-1+deb9u1

[Adrian Bunk]

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

  * Non-maintainer upload.
  * Add the missing dependency on python3-pkg-resources.
(Closes: #904762)
diff -Nru vulture-0.11/debian/changelog vulture-0.11/debian/changelog
--- vulture-0.11/debian/changelog   2016-12-01 22:15:48.0 +0200
+++ vulture-0.11/debian/changelog   2018-08-14 22:53:33.0 +0300
@@ -1,3 +1,11 @@
+vulture (0.11-1+deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Add the missing dependency on python3-pkg-resources.
+(Closes: #904762)
+
+ -- Adrian Bunk   Tue, 14 Aug 2018 22:53:33 +0300
+
 vulture (0.11-1) unstable; urgency=medium
 
   * New upstream release:
diff -Nru vulture-0.11/debian/control vulture-0.11/debian/control
--- vulture-0.11/debian/control 2016-12-01 22:15:48.0 +0200
+++ vulture-0.11/debian/control 2018-08-14 22:53:33.0 +0300
@@ -19,7 +19,8 @@
 Architecture: all
 Depends:
  ${misc:Depends},
- ${python3:Depends}
+ ${python3:Depends},
+ python3-pkg-resources
 Enhances:
  prospector
 Description: scans for unused ("dead") code in a Python program

Bug#906141: linux-headers: Fail to load desktop after computer login

[Cody Jackson]

Package: linux-headers-4.9.0-7-amd64
Version: 4.9.110-3+deb9u1
Severity: important
File: linux-headers

Dear Maintainer,

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

   * What led up to the situation?

I was updating the linux headers from 4.9.0-6 to 4.9.0-7.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Once every month I run apt-get dist-upgrade. That's what I did in this case.

   * What was the outcome of this action?

The computer will load the headers, I am able to login, but after I enter my 
password, the computer screen goes gray, the fan kicks in, and the desktop will 
not load. In order to get my computer to work, I have to load the 4.9.0-6 
headers. 

   * What outcome did you expect instead?

My computer to continue to work with the new header.


-- System Information:
Debian Release: 9.5
  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=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)

Versions of packages linux-headers-4.9.0-7-amd64 depends on:
ii  linux-compiler-gcc-6-x86  4.9.110-3+deb9u1
ii  linux-headers-4.9.0-7-common  4.9.110-3+deb9u1
ii  linux-kbuild-4.9  4.9.110-3+deb9u1

linux-headers-4.9.0-7-amd64 recommends no packages.

linux-headers-4.9.0-7-amd64 suggests no packages.

-- no debconf information

Bug#906128: libykpiv1 impacted by CVE-2018-14779 and CVE-2018-14780

[Salvatore Bonaccorso]

Hi Nicolas,

On Tue, Aug 14, 2018 at 08:36:10PM +0200, Nicolas Braud-Santoni wrote:
> Hi,
> 
> Gunnar Wolf sponsored the upload to sid (thanks!) and I just prepared an
> upload for stretch-security.  It is available in the branch debian/stretch on:
> 
>   https://salsa.debian.org/auth-team/yubico-piv-tool.git
> 
> If the security team finds it suitable, please upload directly.

The issue does not warrant a DSA (was marked no-dsa in the tracker
already). Can you though propose a fix to be included in the next
stretch point release?

Regards,
Salvatore

Bug#900240: cmake: FTBFS on hurd-i386

[Samuel Thibault]

Hello,

Petter Reinholdtsen, le sam. 11 août 2018 21:09:37 +0200, a ecrit:
> Btw, I had a look at the patch, and perhaps it is better to not depend on 
> lstat(),
> as it fail in files like /proc/*/exe, where size is always 0.  Here is an
> alternative proposal:

Actually we need to push this to libuv itself.  Once it's accepted there,
we can update cmake's copy.  Could you have a look at doing it?

Samuel

Bug#897767: closed by Mo Zhou (Bug#897767: fixed in highwayhash 0~20180209-g14dedec-5)

[Adrian Bunk]

Control: severity -1 serious

On Mon, Aug 06, 2018 at 07:20:22AM +0800, Lumin wrote:
> control: retitle -1 non-x86 symbols out of date
> control: severity -1 normal
> 
> This non-x86 arches are not my priorities currently. It doesn't deserve
> another RFS bug to the mentors list, and it can be easily fixed by me when
> I get my Debian Developer account.

The binaries currently in testing cannot be rebuilt inside testing,
which is RC.

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#906140: arduino-mk: not compatible with ccache

[Benoît]

Package: arduino-mk
Version: 1.5.2-1
Severity: wishlist

Dear Maintainer,

/usr/share/arduino/Arduino.mk is not compatible with ccache.
When compiling, we can see that the compiler is called with a complete path:

/usr/share/arduino/hardware/tools/avr/bin/avr-g++

It would be nice if it could use the short name instead (if it's the same 
compiler)
so that ccache could kick in.

$ /usr/lib/ccache/avr-g++ --version
avr-g++ (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ /usr/share/arduino/hardware/tools/avr/bin/avr-g++ --version
avr-g++ (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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

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

Versions of packages arduino-mk depends on:
ii  arduino-core   2:1.0.5+dfsg2-4.1
ii  make   4.2.1-1.2
ii  python 2.7.15-3
ii  python-serial  3.4-4

Versions of packages arduino-mk recommends:
ii  screen  4.6.2-3

arduino-mk suggests no packages.

-- debconf-show failed

Bug#906139: debian-policy: versioned depends on libjs-sphinxdoc unsatisfiable on stretch

[Vagrant Cascadian]

Package: debian-policy
Version: 4.2.0.1
Severity: wishlist

Thanks for maintaining debian-policy; it is one of the things that
really distinguishes Debian in an excellent way!


For many years, I've installed debian-policy from sid on a stable system
to have it readily available, but recent versions of debian-policy have
a versioned dependency that is unsatisfyable in stable:

  Depends: libjs-sphinxdoc (<< 1.7.6.0~), libjs-sphinxdoc (>= 1.7.6)

I'm not sure exactly what necessitates a dependency on these (html
documentation?). The main files of interest to me are policy.txt.gz and
upgrading-checklist.txt.gz, and find it hard to believe those require
libjs-sphinxdoc to read. I imagine several of the other formats (.epub,
.pdf) also shouldn't require libjs-sphinxdoc.

If it is plausible to downgrade to a Recommends, or split out the
libjs-sphinxdoc documentation into a separate package, or the text-only
documentation into a separate package, or some other resolution, that
would be much appreciated!


live well,
  vagrant

-- System Information:
Debian Release: 9.5
  APT prefers stable
  APT policy: (500, 'stable'), (120, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, arm64

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

Versions of packages debian-policy depends on:
ii  libjs-sphinxdoc  1.4.9-2

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base  

-- no debconf information


signature.asc
Description: PGP signature

Bug#906130: allow autopkg restrictions in debian/control

[Antonio Terceiro]

Control: tag -1 + wontfix
Control: close -1

On Tue, Aug 14, 2018 at 06:46:56PM +0200, Matthias Klose wrote:
> Package: autopkgtest
> Version: 5.5
> 
> Seen when the Python autodep8 tests were enabled.  Tests start failing when
> these have e.g. output on stderr.  It should be possible to specify package
> specific restrictions for these.

I don't think this is something that should be fixed in autopkgtest.
Everything related to autopkgtest should be in debian/tests/control. If
debian/tests/control does not exist because the package is relying on
autodep8, we should be improving the python support in autodep8 instead.

> Unlike the perl or ruby autopkg tests, python
> has many different test systems, some of which write output on stderr.

That has nothing to do with having different test systems:

- First, the python support in autodep8 does not actually run tests, it
  just does a simple "import" test. If suddently there is output on
  stderr, it's because something inside the actual python code in the
  package started warning something to stderr.

- Second, Ruby and Perl are not affected by a similar issue because the
  perl and ruby support actually redirects stderr to stdout when running
  tests, so only the exit status is considered.


signature.asc
Description: PGP signature

Bug#883950: Next steps on "[GPL-3+]" proposal

[Jonathan Nieder]

Hi,

Ian Jackson wrote:
> Russ Allbery writes ("Bug#883950: Next steps on "[GPL-3+]" proposal"):

>>  Currently, copyright-format
>> 1.0 requires either that every License stanza in a Files paragraph contain
>> some "license text" in the copyright-format text (which may just be the
>> common-licenses pointer) or that there be a later stand-alone License
>> paragraph with the same short license identifier that has that text.  This
>> proposal breaks that property by introducing the possibility of a short
>> license identifier with no accompanying text.  This will require parser
>> changes.
>
> It will require parser changes in some, but not all, parsers.
>
> Changing the version would involve parser changes in all parsers.

I don't follow.  Why wouldn't a non-validating parser be able to simply
ignore the Format field?

Thanks,
Jonathan

Bug#906128: libykpiv1 impacted by CVE-2018-14779 and CVE-2018-14780

[Nicolas Braud-Santoni]

Hi,

Gunnar Wolf sponsored the upload to sid (thanks!) and I just prepared an
upload for stretch-security.  It is available in the branch debian/stretch on:

  https://salsa.debian.org/auth-team/yubico-piv-tool.git

If the security team finds it suitable, please upload directly.


Best,

  nicoo

PS: In case I need to be reached swiftly, IRC might be the most effective medium
(nicoo on irc.oftc.net/#debian-security)

On Tue, Aug 14, 2018 at 06:39:43PM +0200, Nicolas Braud-Santoni wrote:
> Package: libykpiv1
> Severity: serious
> Tags: security pending stretch buster sid
> Justification: security
> 
> libykpiv1 versions below 1.6.0 are affected by a buffer overflow, exploitable 
> by
> malicious USB devices, that can lead to arbitrary code execution.
> 
> I will upload the fixed upstream version later today, and coordinate with
> the security team to get fixed in stretch and jessie-backports
> 
> 
> Best,
> 
>   nicoo
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages libykpiv1 depends on:
> ii  libc6 2.27-5
> ii  libpcsclite1  1.8.23-3
> ii  libssl1.1 1.1.0h-4
> 
> Versions of packages libykpiv1 recommends:
> ii  pcscd  1.8.23-3
> 
> libykpiv1 suggests no packages.
> 


signature.asc
Description: PGP signature

Bug#906138: libykneomgr: out of bounds read/writes

[Salvatore Bonaccorso]

Source: libykneomgr
Version: 0.1.8-1
Severity: grave
Tags: security upstream

Hi

See https://www.x41-dsec.de/lab/advisories/x41-2018-004-libykneomgr/
for details. Upstream will  not issue a patch for it as vendor does
not support the library anymore.

Should we consider removing libykneomgr from Debian?

Regards,
Salvatore

Bug#902003: mccs: Add support for clasp using -pblib option

[Ralf Treinen]

Hello,

On Thu, Jun 21, 2018 at 01:01:44PM +0200, Julian Andres Klode wrote:

> With the attached patch, mccs understands clasps output (which does
> not always end with a space at the end of a line, as mccs seems to
> expect) and writes the PB problem in a way that clasp understands it,
> by rendering <= constraints as >= ones.
> 
> This allows mccss -pblib /usr/bin/clasp to work, which is faster than
> the standard solver, and significantly outperforms aspcud (well aspcud
> tries to cross-grade part of my system to i386..., so not really comparable).

Unfortunately, mccs with the patch applied returns incorrect results
when launched with option "-pblib clasp". For instance, when you
lauch it on examples/legacy.cudf from the mccs package you obtain
a result which is not accepted by cudf-check since it says to
install both gasoline-engine and electric-engine, which are in
conflict.

-Ralf.

Bug#906137: courier-authlib-pipe: authdaemon passes the socket FD to the authProg worker, causing an usuccessful close for the first connecting client

[Heiko Schlittermann (HS12-RIPE)]

Package: courier-authlib-pipe
Version: 0.66.4-9
Severity: important
Tags: upstream

Dear Maintainer,

   * What led up to the situation?

I'm using a variant of the example authProg script.

The authdaemon starts the external authProg *after* accepting the first
connection from the client.

accept(5, {sa_family=AF_UNIX}, [16->2]) = 4 <0.33>
fcntl(4, F_SETFL, O_RDONLY) = 0 <0.000151>
...
select(5, [4], NULL, NULL, {tv_sec=10, tv_usec=0}) = 1 (in [4], left {tv_sec=9, 
tv_usec=96}) <0.54>
read(4, "AUTH 40\nimap\nlogin\n...@dynapic.ne"..., 8192) = 48 <0.29>
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f62cbd2c9d0) = 4644 <0.000202>

This leaks the filedescriptor for the client connection to the forked authProg 
process.
If the authProg doesn't care about file descriptors (as the example Perl 
script), the
client connection FD is open twice: opened by the process which accepted the 
connection, and open
by the process which inherited the FD.

After sending the auth results to the client, the authdaemon close()es the 
client connection. But
this doesn't really close the connection, because it is held open by the forked 
authProg process.

The client runs into a timeout. (reproducable using socat -t 5 - 
/run/courier/authdaemon/socket <...)
All connections following that first one do not have this problem, as now the 
authProg is running already and doesn't
the the new FDs created by accepting the new connections.

Solution:
Either fork the authProg *before* accepting the first connection.
Or use CLOSE_ON_EXEC on the FD returned from accepting the connection.

Workaround: The example script can use

use POSIX;
POSIX::close($_) for 3..1024;

This workaround solved the problem for me, so I'd consider it as a proof.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Use 'authpipe' as the only module in the authmodulelist.
Use the example Perl script as an authProg.

systemctl restart courier-authdaemon

socat -t5 - /run/courier/authdaemon/socket <<_
AUTH 35
imap
login
f...@example.com
foobar
_

   * What was the outcome of this action?

The first invocation after restarting the daemon leads to a timeout.
Every following invocation succeeds. (Given there is only one daemon
running, controlled via the daemons setting in authdaemonrc.

   * What outcome did you expect instead?


I think, the bugfix is easy, using fcntl and setting CLOSE_ON_EXEC in
authdaemon.c, just after accepting the connection.
But as I do not have a good testing environment, I can't do any tests.
And as the package seems to be orphaned, I'm not sure if it is worth the
effort. I'll need to switch to dovecot, I'm afraid.

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

Kernel: Linux 4.15.9 (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)

Versions of packages courier-authlib-pipe depends on:
pn  courier-authlib  
ii  libc62.24-11+deb9u3

courier-authlib-pipe recommends no packages.

courier-authlib-pipe suggests no packages.

Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Vagrant Cascadian]

On 2018-03-01, Guillem Jover wrote:
> On Thu, 2018-03-01 at 15:22:30 +, Holger Levsen wrote:
>> On Wed, Jan 24, 2018 at 04:05:39PM +0100, Salvatore Bonaccorso wrote:
>> We (reproducible builds) really dont want "our" tools (=.buildinfo files)
>> to cause grief to other teams in Debian, and especially not on a regular
>> basis... so as a first step to fix this, I'd like to collect opinions
>> how to best fix this issue here.
>
> The problem got introduced when I proposed changing the filename
> format, and dropping the annoying timestamp. I also though there was
> talk at some point initially about DAK renaming those files to cope
> with possible multiple uploads if the conflicting names?

It seems DAK is doing this, at least in some cases:

vagrant@coccia:/srv/ftp-master.debian.org/buildinfo/2018/08/01$ ls 
/srv/ftp-master.debian.org/buildinfo/2018/08/01/libthai*amd64*

/srv/ftp-master.debian.org/buildinfo/2018/08/01/libthai_0.1.28-1_amd64.buildinfo
/srv/ftp-master.debian.org/buildinfo/2018/08/01/libthai_0.1.28-1_amd64.buildinfo.0

I'm fairly sure in this case the .0 one is from the buildd.

Could something similar be done with the security and other upload
queues? maybe even appending .quename.N or something. e.g. security.0.


> I guess, the ideal solution would be to qualify the buildinfo file
> with the builder user and hostname, because that in a way denotes the
> build environment. But that seems like too much leakage. As in:
>
>   pkgfoo_1.0.0-1_mips64el_username@hostname.buildinfo

What about having an option to enable this, and the buildd's would
enable it, and it otherwise defaults to false?


Do binNMUs produce a distinct .buildinfo filename? I seem to recall
local builds with sbuild producing an identical .buildinfo filename to
the regular build using --append-to-version and re-building the .dsc,
but I'm not sure about how the official buildds work with binNMUs.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#902923: Bug#901164: caja-eiciel FTCBFS: configure.ac hard codes build architecture pkg-config

[Mike Gabriel]

Control: close -1
Control: tags -1 wontfix

Hi,

On  Do 12 Jul 2018 13:58:49 CEST, Mike Gabriel wrote:


Hi Helmut,

On Tue, 3 Jul 2018 16:40:35 +0200 Helmut Grohne  wrote:

Control: clone -1 -2
Control: retitle -2 register eiciel fork
Control: tags -2 =
Control: severity -2 important

Hi Alex,

On Tue, Jul 03, 2018 at 11:50:04AM +0200, Alex ARNAUD wrote:
> If it's an upstream issue, could you report and submit your patch  
upstream?

> Upstream is here:https://github.com/darkshram/mate-eiciel

I think you mean https://github.com/rofirrim/eiciel. It seems you
packaged a fork and thus you should register your code copy. See
https://wiki.debian.org/EmbeddedCodeCopies for details. By forking
upstreams, you are copying bugs (like this one). That is why the Debian
policy discourages forking or packaging forks. I've clone bug -2 for
dealing with the code copy.


Please note that caja-* packages are addons for the file browser  
caja (part of the MATE desktop).


The original application is for nautilus. It is not possible to use  
the addons cross-wise.


The projects that people derive from nautilus add-ons for caja are  
technically forks, but they are not two possible options for the  
same use case. They forks target being used in caja, whereas the  
originals are for nautilus.


So, what exactly do you mean by "register eiciel fork"???

Greets,
Mike



Closing this discussion. caja-eiciel is a fork of eiciel. Forking is  
required to make it work against the Caja browser (from MATE desktop  
env). The fork is (to my knowledge) maintained upstream.


Thanks+Greets,
Mike
--

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

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



pgpEJR00vf8Zs.pgp
Description: Digitale PGP-Signatur

Bug#906136: sensible-browser doesn't seem to have a user local way of changing it

[Phillip Susi]

Package: sensible-utils
Version: 0.0.12

Unlike for editor and pager, sensible-browser does not appear to have an
environment variable for a user to choose their sensible browser ( as
opposed to the admin making system wide symlink changes ).




signature.asc
Description: OpenPGP digital signature

Bug#905392: Does a generator need to take care of overrides in /etc?

[Michael Biebl]

Am 14.08.2018 um 19:53 schrieb Michael Biebl:
> Would probably be a good idea to raise this on the upstream mailing list.

upstream mailing list:
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#906135: gengetopt: Generates code with warnings

[Aiden Woodruff]

Package: gengetopt
Version: 2.22.6+dfsg0-1+b3
Severity: minor

Dear Maintainer,

Produced code (cmdline.c) has warnings when used with CC -Wall and without any 
required options.
int check_required unused
Could this be removed?

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

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

Versions of packages gengetopt depends on:
ii  libc6   2.24-11+deb9u3
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libstdc++6  6.3.0-18+deb9u1

gengetopt recommends no packages.

gengetopt suggests no packages.

-- no debconf information

Bug#905996: nmu: clsync_0.4.1-1

[Niels Thykier]

Control: tags -1 moreinfo

Aurelien Jarno:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> Hi release team,
> 
> One of the goal of the glibc team for buster is to get rid of the
> multiarch-support package, given that multiarch support in the dynamic
> loader is fully supported in debian for a long time. Debhelper used to
> add this dependency, but it's not the case anymore.
> 
> clsync is one out of two packages left in buster, the other one,
> gtk2-engines-oxygen, should hopefully migrate in the next days.
> Unfortunately clsync has an RC bug in sid, which prevents it to migrate
> to buster. This RC bug is not present in buster, so the package hasn't
> been autoremoved from there.
> 
> Therefore the easiest way to fix the issue is to trigger a binNMU in
> *buster*, against a "recent" debhelper:
> 
> nmu clsync_0.4.1-1 . ANY . buster . -m "Rebuild to remove the pre-dependency 
> on multiarch-support"
> 
> Thanks,
> Aurelien
> 
> [...]

Hi Aurelien,

If the goal is to make testing free of packages (Pre-)Depending on
multiarch-support, then removing clsync from testing is also an option
AFAICT.

I am considering since clsync has had its FTBFS bug against sid for
almost 2 years now with no reaction from its maintainers.

Thanks,
~Niels

Bug#906134: RFS

[Jason Guy]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I have been doing a lot of work on the isc-kea package. The new maintainer
Ondrej Sury suggested I get a mentor to help me refine my packaging skills.

I am fairly comfortable with the package layout, and most of the basics of
building. I have read everything I can find on maintaining debian packages,
but it would be great to expand on that and learn more.

Thanks,
Jason

Bug#905392: Does a generator need to take care of overrides in /etc?

[Michael Biebl]

Am 14.08.2018 um 00:09 schrieb Bernhard Schmidt:
> Hi,
> 
> on src:openvpn we have recently gotten a bug report about local
> modifications of the openvpn@.service file in /etc being ignored when
> the instance is started by the systemd generator, because the generator
> unconditionally links to the file in /lib/systemd and does not check for
> the presence of a modified file in /etc/systemd
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905392
> 
> My first instinct was that this could not be true, as it would be the
> complete opposite to my expectations as regular systemd user, where
> overriding something in /etc (either by copying and modifying the
> .service file, or by adding dropins in .service.d) is adhered to by all
> systemd management commands. But I can reproduce this in a sid container
> (please ignore the activating/failed status below, openvpn in the
> container could not create a tun device, just look at the path to the
> unit and to the ExecStart line
> 
> /etc/openvpn# openvpn --genkey --secret static.key
> /etc/openvpn# head test1.conf
> dev tun
> ifconfig 10.1.0.1 10.1.0.2
> secret static.key
> 
> # cp /lib/systemd/system/openvpn\@.service /etc/systemd/system
> # sed -ri 's:ExecStart=.+$:ExecStart=/bin/sleep 10:'
> /etc/systemd/system/openvpn\@.service
> 
> # reboot
> 
> # systemctl status openvpn@test1.service
> ● openvpn@test1.service - OpenVPN connection to test1
>Loaded: loaded (/lib/systemd/system/openvpn@.service;
> enabled-runtime; vendor preset: enabled)
> [...]
>   Process: 231 ExecStart=/usr/sbin/openvpn --daemon ovpn-test1 --status
> /run/openvpn/test1.status 10 --cd /etc/openvpn --config
> /etc/openvpn/test1.conf --writepid /run/openvpn/test1.pid (code=exited,
> status=1/
>  Main PID: 231 (code=exited, status=1/FAILURE)
> 
> # systemctl start openvpn@test2.service
> # systemctl status openvpn@test2.service
> ● openvpn@test2.service - OpenVPN connection to test2
>Loaded: loaded (/etc/systemd/system/openvpn@.service; disabled;
> vendor preset: enabled)
>   Process: 334 ExecStart=/bin/sleep 10 (code=exited, status=0/SUCCESS)
> 
> So openvpn@test1.service (that is .wants by the generator) is using the
> shipped configuration, but any other instance is using the version in
> /etc as expected.
> 
> /run/systemd/generator/openvpn.service.wants# ls -la
> lrwxrwxrwx 1 root root  36 Aug 13 23:54 openvpn@test1.service ->
> /lib/systemd/system/openvpn@.service
> 
> The proposed fix indeed changes this by checking the existence of the
> file in /etc first and symlinking to this, but I would not have expected
> the logic for overriding configuration in /etc necessary to be
> implemented in each and every generator.

Would be interesting to know, why exactly the file in /etc is not taking
precedence:
a/ Is it because of the template
b/ Is it because of you generate the symlink in
/run/systemd/generator/openvpn.service.wants

> Are my expectations wrong? Is this a bug somewhere?

My first instinct was, that yes, a file in /etc should take precedence
over the one from /lib, as everything else would be inconsistent.

There might be an underlying reason for this behaviour which I don't
know of or maybe it's simply a bug.

Would probably be a good idea to raise this on the upstream mailing list.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#891063:

[Chris Waters]

Vincent Lefevre  writes:

> But in any case, the bug needs to be fixed.

Yeah, I don't believe this can reasonably be called a bug. Emacs, like
a lot of big complex apps, can and does write to various parts of the
filesystem when used. There's a good chance that if you check your
home directory, you'll find more files owned by root. Files like
.emacs.d/recentf or .emacs.d/auto-save-list/* or .emacs-places.

At least, those are some of the files that Emacs has silently modified
recently on *my* system. It may depend on which emacs features you
have enabled, but that's something you shouldn't have to worry about.

Typing "su emacs [filename]" is simply not something you can
reasonably expect to do safely. Which is why emacs has features to
work around that. Like typing "emacs /su::[filename]" instead. Or
using "C-x C-f /su::[filename]" from within emacs. (Or, better yet,
"emacs /sudo::[filename]" or "C-x C-f /sudo::[filename]".)

If it *really* bothers you to type the pathname, you can make an alias
like: "eroot='emacs /sudo::$(pwd)/$1'". Or even "su -l emacs $(pwd)/$1".

However, turning off dbus access for emacs, which is something some of
us actually *use*, just to support a non-standard and unnecessary
workflow, is *not* a good option.

Bug#906133: ocrodjvu: Please make Tesseract messages less confusing

[Janusz S. Bień]

Package: ocrodjvu
Version: 0.10.4-1
Severity: wishlist

Hi!

I run ocrodjvu with "-j 3" and get the following messages:

--8<---cut here---start->8---
tesseract: Tesseract Open Source OCR Engine v4.0.0-beta.3-249-g607e with 
Leptonica
tesseract: Page 1
tesseract: no best words!!
tesseract: no best words!!
tesseract: no best words!!
- Page #90
- Page #91
- Page #92
tesseract: Tesseract Open Source OCR Engine v4.0.0-beta.3-249-g607e with 
Leptonica
tesseract: Page 1
tesseract: no best words!!
tesseract: no best words!!
tesseract: no best words!!
tesseract: no best words!!
tesseract: no best words!!
tesseract: no best words!!
tesseract: no best words!!
- Page #93
- Page #94
--8<---cut here---end--->8---

I have no idea to which page Tesseract refers as " Page 1" and to which
pages " no best words!!" applies.

Is using "-j 1" the only solution?

BTW, I'm unable to find any explanation of the "no best words!!"
message. Use the force, read the source? :-)

Best regards

Janusz


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

Kernel: Linux 4.17.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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ocrodjvu depends on:
ii  djvulibre-bin  3.5.27.1-9
ii  libpython2.7-stdlib [python-argparse]  2.7.15-3
ii  python 2.7.15-3
ii  python-djvu0.8.1-1

Versions of packages ocrodjvu recommends:
ii  python-html5lib  1.0.1-1
ii  python-lxml  4.2.3-1
ii  python-pyicu 2.0.3-1+b2
ii  python-subprocess32  3.5.2-1
ii  tesseract-ocr4.00~git2844-607e8fd8-2

Versions of packages ocrodjvu suggests:
pn  cuneiform  
pn  gocr   
pn  ocrad  

-- no debconf information

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#906132: usbtop: auto-load the usbmon module?

[Adam Borowski]

Package: usbtop
Version: 0.2-1
Severity: wishlist

Hi!
Upon starting, usbtop throws 18 lines of error messages:

Error while capturing traffic from usbmon1: usbmon1: Can't open USB bus file 
/sys/kernel/debug/usbmon/1t: No such file or directory
Error while capturing traffic from usbmon2: usbmon2: Can't open USB bus file 
/sys/kernel/debug/usbmon/2t: No such file or directory
Error while capturing traffic from usbmon3: usbmon3: Can't open USB bus file 
/sys/kernel/debug/usbmon/3t: No such file or directory
Error while capturing traffic from usbmon4: usbmon4: Can't open USB bus file 
/sys/kernel/debug/usbmon/4t: No such file or directory
Error while capturing traffic from usbmon5: usbmon5: Can't open USB bus file 
/sys/kernel/debug/usbmon/5t: No such file or directory
Error while capturing traffic from usbmon6: usbmon6: Can't open USB bus file 
/sys/kernel/debug/usbmon/6t: No such file or directory
Error while capturing traffic from usbmon7: usbmon7: Can't open USB bus file 
/sys/kernel/debug/usbmon/7t: No such file or directory
FATAL ERROR: couldn't open any USB buses with pcap. Did you load the usbmon 
module (sudo modprobe usbmon)?
You might also need to run this software as root.

It'd be nice if they could be coalesced into one, as they have a single
well-known cause.  The current spam is so long that an inattentive reader
might miss the modprobe suggestion (as I did).

But, as usbtop already needs root, why not just load the module yourself?


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

Kernel: Linux 4.18.0+ (SMP w/6 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: sysvinit (via /sbin/init)

Versions of packages usbtop depends on:
ii  ca-certificates   20180409
ii  libboost-atomic1.62.0 1.62.0+dfsg-8
ii  libboost-chrono1.62.0 1.62.0+dfsg-8
ii  libboost-date-time1.62.0  1.62.0+dfsg-8
ii  libboost-system1.62.0 1.62.0+dfsg-8
ii  libboost-thread1.62.0 1.62.0+dfsg-8
ii  libc6 2.27-5
ii  libgcc1   1:8.2.0-3
ii  libpcap0.81.8.1-6
ii  libstdc++68.2.0-3

usbtop recommends no packages.

usbtop suggests no packages.

-- no debconf information

Bug#904608: Support specifying upstream VCS location in debian/control

[Ian Jackson]

Sean Whitton writes ("Bug#904608: Support specifying upstream VCS location in 
debian/control"):
> No-one needs to do that extra work anytime soon.  Policy lags best
> practices.  The fact that debian/upstream/metadata is already being used
> to store a URI to the upstream repository for a large number of packages
> counts as standardisation, in Debian Policy terms.  You can refer to it
> in tools that you write.

YAML is utterly awful.  The spec is gigantic.  We should not
perpetuate it.

Ian.

Bug#883950: Next steps on "[GPL-3+]" proposal

[Ian Jackson]

Paul Hardy writes ("Bug#883950: Next steps on "[GPL-3+]" proposal"):
>  License: GPL-2
>   file:///usr/share/common-licenses/GPL-2

I'm late to this party, but one of the things that is wrong[1] with
SPDX is that it implicitly encourages what I would call GPL-v2-only or
whatever, rather than (say) GPLv2+.

IMO in Debian we should not perpetuate this.

Ian.

[1] politically opposed to my own goals, probably deliberately so on
the part of the SPDX authors

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#906131: CVE-2018-14722

[Moritz Muehlenhoff]

Package: btrfsmaintenance
Severity: grave
Tags: security

Please see http://www.openwall.com/lists/oss-security/2018/08/14/7

Cheers,
Moritz

Bug#883950: Next steps on "[GPL-3+]" proposal

[Ian Jackson]

Russ Allbery writes ("Bug#883950: Next steps on "[GPL-3+]" proposal"):
> To be clear, I don't believe there's a way forward here that doesn't
> require at least some rewriting of parsers.  Currently, copyright-format
> 1.0 requires either that every License stanza in a Files paragraph contain
> some "license text" in the copyright-format text (which may just be the
> common-licenses pointer) or that there be a later stand-alone License
> paragraph with the same short license identifier that has that text.  This
> proposal breaks that property by introducing the possibility of a short
> license identifier with no accompanying text.  This will require parser
> changes.

It will require parser changes in some, but not all, parsers.

Changing the version would involve parser changes in all parsers.

Ian.

Bug#883950: Next steps on "[GPL-3+]" proposal

[Ian Jackson]

Russ Allbery writes ("Bug#883950: Next steps on "[GPL-3+]" proposal"):
> Markus Koschany  writes:
> > I have a hard time to imagine what kind of breakage might occur with
> > those non-Lintian parsers.
> 
> It's pretty straightforward: currently, a License field must either
> contain an extended paragraph or references one elsewhere in the document.
> Therefore, whenever a parser sees a License field without an extended
> paragraph, it currently knows (and expects) there to be a stand-alone
> license paragraph later in the document.  But with this change that
> paragraph wouldn't exist.

I am against the version number change.  Version numbers, and
particular version number bumps, in protocols like this are a very
heavy hammer.  Where present, they should be bumped only when
necessary.  They are necessary only when a tool which is written to
the old format will *do the wrong thing* with the extended format.

If a reasonable tool written to the old format will either do a
plausible thing, or reject the input, if fed the new format, then it
is a bad idea to bump the version number.

That is the case here.

TBH I think even having a version number at all in the
machine-readable copyright format is quite possibly a mistake.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#906126: libeigen3-dev: suggest libmrpt-dev but should be libmpfrc++-dev

[Anton Gladky]

Hello Jochen,

thanks for catching it.

> I can change it in git if you agree.

Yes, sure, please push in git. I am preparing the newer eigen3 version.
So these changes will be uploaded soon.

Regards

Anton


2018-08-14 18:31 GMT+02:00 Jochen Sprickerhof :
> Package: libeigen3-dev
> Version: 3.3.4-4
> Severity: normal
>
> Hi Anton,
>
> in #731050 Jerome proposed to add a suggest on libmpfrc++-dev but you
> added libmrpt-dev to close the issue.
>
> https://packages.debian.org/search?searchon=contents=mpreal.h=path=unstable=any
>
> is telling me that libmpfrc++-dev would still be the right package and
>
> $ dpkg -L libeigen3-dev | xargs grep mpreal.h
> /usr/include/eigen3/unsupported/Eigen/MPRealSupport:#include 
>
> indicates that it should still be added.
>
> I can change it in git if you agree.
>
> Cheers Jochen
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages libeigen3-dev depends on:
> ii  pkg-config  0.29-4+b1
>
> libeigen3-dev recommends no packages.
>
> Versions of packages libeigen3-dev suggests:
> pn  libeigen3-doc  
> pn  libmrpt-dev
>
> -- no debconf information
>
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#459427: Patch seeking seconds on changelog vs. NEWS handling [and 1 more messages]

[Ian Jackson]

Simon McVittie writes ("Bug#459427: Patch seeking seconds on changelog vs. NEWS 
handling"):
> Debian packages have a Debian changelog and (when the source package
> is included, without which we are not GPL-compliant anyway) a Debian
> diff/tar, so there is certainly a prominent notice that we have modified
> it. I am not a lawyer, but I believe this is enough for the letter and
> spirit of the license: it tells a user "if you are looking for an
> unmodified GNU Hello, this is not it".

I agree.  So maybe my suggested text should read something like this:

Ian Jackson writes ("Re: Bug#459427: Patch seeking seconds on changelog vs. 
NEWS handling"):
>   Code changelogs are not very useful without the source code.  They
>   should not normally be installed in the binary package unless this
>   is required by the package's licence.

   (Note that this is NOT
required by any version of the GNU GPL.)

>  When they are installed, they
>   should be installed as /usr/share/doc/PACKAGE/changelog.gz.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#901594: DE-agnostic agent

[Eugene Zhukov]

Valentin Blot  writes:
> I don't use a DE. Maybe the "demo" agent should be renamed and enhanced
> into a "default" agent for all the people who don't use a DE?

Same here. geoclue-2.0 should at least recommend an agent, be it some demo
agent or some DE agent. Without an agent there is a major effect on the
usability of a package.
According to upstream author himself, an agent is required by default now:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900936#20

Bug#901594: (no subject)

[Eugene Zhukov]

severity serious

Bug#906130: allow autopkg restrictions in debian/control

[Matthias Klose]

Package: autopkgtest
Version: 5.5

Seen when the Python autodep8 tests were enabled.  Tests start failing when
these have e.g. output on stderr.  It should be possible to specify package
specific restrictions for these. Unlike the perl or ruby autopkg tests, python
has many different test systems, some of which write output on stderr.

Bug#901594: (no subject)

[Eugene Zhukov]

severity important

Bug#459427: Patch seeking seconds on changelog vs. NEWS handling

[Ian Jackson]

Sean Whitton writes ("Bug#459427: Patch seeking seconds on changelog vs. NEWS 
handling"):
> +If an upstream release notes file is available, containing a summary
> +of changes between upstream releases intended for end users of the
> +package and often called ``NEWS``, it should be accessible as
> +``/usr/share/doc/package/NEWS.gz``.  An older practice of installing
> +the upstream release notes as ``/usr/share/doc/package/changelog.gz``
> +is permitted but deprecated.

I think part of the difficulty we are having with this is by failing
to have a kind of contextual introduction.

How about:

  Upstreams provide information about changes between upstream ersions
  in a variety of formats and with a variety of content.  Typically
  there are two distinct kinds of change informatiion:

   * Release notes style: describes user-visible changes such as new
 features, backwards compatibility issues, and perhapz significant
 bugfixes.  Examples: [...]

   * Code changelog style: lists all changes made to the source code,
 even ones which are not user-visible, often by reference to
 source code filenames.  Examples: [...]

  Release notes are useful to users.  If available, they should be
  installed as /usr/share/doc/PACKAGE/NEWS.gz.

  Code changelogs are not very useful without the source code.  They
  should not normally be installed in the binary package unless this
  is required by the package's licence.  When they are installed, they
  should be installed as /usr/share/doc/PACKAGE/changelog.gz.

  Note that terminology and filenames for these vary.  We want to
  provide Debian's users with consistency across packages, so you
  should rename the file(s) according to their contents.  Some
  language- or domain-specific packaging teams have more specific
  policies.  You should follow them, so that all packages in a
  particular domain are consistent.

  If information provided by upstream does not fit neatly into these
  categories, you should use your best judgement.  All documents that
  are useful to users should be in the binary package.

Ian.

Bug#906129: firefox: switch default to not permanently store certs when making an exception

[Christoph Anton Mitterer]

Package: firefox
Version: 61.0.1-1
Severity: wishlist


Hi.

With the removal of FF 52 ESR from Debian, the xul-ext-y-u-no-validate has 
become
disfunctional.

This extension changed the default of the dialogue question wheter to 
permanently
store certs when making an exception (e.g. untrusted certs), to not store them
permanently.

As the name says, exceptions should be exceptions and thus typically not
permanent, at least not per default.


Mozilla has denied any requests to make this configurable:
https://bugzilla.mozilla.org/show_bug.cgi?id=762985

The upstream author of the add-on thinks it may not be possible to port it to
WebExtensions:
https://github.com/wodny/y-u-no-validate/issues/5


It seems a change of the default value is as easy as:
https://github.com/jrchamp/gecko-dev/commit/f13ad2775d4eb461fd5c1c416b9fad35c5aa104f


Could you possibly consider to apply this to the Debian packages?

Thanks,
Chris.

Bug#906128: libykpiv1 impacted by CVE-2018-14779 and CVE-2018-14780

[Nicolas Braud-Santoni]

Package: libykpiv1
Severity: serious
Tags: security pending stretch buster sid
Justification: security

libykpiv1 versions below 1.6.0 are affected by a buffer overflow, exploitable by
malicious USB devices, that can lead to arbitrary code execution.

I will upload the fixed upstream version later today, and coordinate with
the security team to get fixed in stretch and jessie-backports


Best,

  nicoo

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

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

Versions of packages libykpiv1 depends on:
ii  libc6 2.27-5
ii  libpcsclite1  1.8.23-3
ii  libssl1.1 1.1.0h-4

Versions of packages libykpiv1 recommends:
ii  pcscd  1.8.23-3

libykpiv1 suggests no packages.

Bug#906127: Incorrect check of httplib2 version

[Aiden Woodruff]

Package: python3-pysimplesoap
Version: 1.16-2

This check fails and breaks the reportbug command when used with SMTPS.
The issue is in file transport.py
Included is a patch to fix it.


fix-httplib2-version-check.patch
Description: Binary data

Bug#881970: xul-ext-foxyproxy-standard: new upstream version (with WebExtensions support)

[Christoph Anton Mitterer]

Control: severity -1 grave

Since FF ESR 52 has now left Debian unstable, the XUL version of this
is no longer usable in Debian.

Please upgrade to the WebExtensions version.

Thanks and best wishes,
Chris.

Bug#906126: libeigen3-dev: suggest libmrpt-dev but should be libmpfrc++-dev

[Jochen Sprickerhof]

Package: libeigen3-dev
Version: 3.3.4-4
Severity: normal

Hi Anton,

in #731050 Jerome proposed to add a suggest on libmpfrc++-dev but you
added libmrpt-dev to close the issue.

https://packages.debian.org/search?searchon=contents=mpreal.h=path=unstable=any

is telling me that libmpfrc++-dev would still be the right package and

$ dpkg -L libeigen3-dev | xargs grep mpreal.h
/usr/include/eigen3/unsupported/Eigen/MPRealSupport:#include 

indicates that it should still be added.

I can change it in git if you agree.

Cheers Jochen

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

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

Versions of packages libeigen3-dev depends on:
ii  pkg-config  0.29-4+b1

libeigen3-dev recommends no packages.

Versions of packages libeigen3-dev suggests:
pn  libeigen3-doc  
pn  libmrpt-dev

-- no debconf information

Bug#882287: xul-ext-noscript: new upstream version (WebExtensions)

[Christoph Anton Mitterer]

Control: severity -1 grave

Since FF ESR 52 has now left Debian unstable, the XUL version of this
is no longer usable in Debian.

Please upgrade to the WebExtensions version.

Thanks and best wishes,
Chris.

Bug#906125: please support environment settings or build profiles in autopkg tests

[Matthias Klose]

Package: autopkgtest
Version: 5.5
Severity: important

Currently, the binutils autopkg tests are disabled on the DebianCI
infratstructure, because the maintainers don't want to have a too long running
build.

The binutils autopkg tests include a binutils build, which should be triggered
when uploading a new glibc or gcc, however it's not necessary to build all
variants (multilib and cross binutils), so I'd like to disable these builds
during the autopkg tests.

Apparently the Ubuntu CI has an environment variable which can be asked for the
autopkg tests:

# only build the basic package when running the autopkg tests
ifneq (,$(ADT_TEST_TRIGGERS))
  CROSS_ARCHS :=
  with_hppa64 :=
  with_multiarch :=
endif

however the Debian CI doesn't set that.  So please either support running a
build with an environment variable set, or let an autopkg test run with a build
profile (e.g. autopkgtest).

Bug#887467: hpanel: x86_64 shows broken icons

[Bernhard Übelacker]

Hello Paul,
just tried to reproduce this issue.

hpanel (and also fspanel) queries the window manager hints via
XGetWindowProperty and XA_WM_HINTS.

The result is just casted to a XWMHints structure.
This seems to have worked on 32bit systems as padding made
all elements at 4 bytes boundaries.

On amd64 XGetWindowProperty seems to return the same
layout, but the memory layout of XWMHints struct is different.
I "think" form reading [1] that XGetWindowProperty just
returns an array of 32bit fields, that "accidentically"
matched the layout of struct XWMHints on i386.

Attached patch replaces XGetWindowProperty by XGetWMHints.
This worked in a i386 and amd64 VM for me.

Kind regards,
Bernhard

[1] https://linux.die.net/man/3/xgetwindowproperty

apt update
apt install xserver-xorg lightdm openbox pulseaudio xterm psmisc htop mc tmux 
strace dpkg-dev devscripts quilt gdb valgrind systemd-coredump dh-buildinfo
apt install hpanel libxft2-dbgsym libx11-6-dbgsym
apt build-dep hpanel


mkdir -p hpanel/orig
cd   hpanel/orig
apt source hpanel
cd ..
cp -a orig try1
cd try1/hpanel-0.3.2
DEB_BUILD_OPTIONS='nostrip noopt debug' dpkg-buildpackage -uc -us
dpkg -i /home/benutzer/hpanel/try1/hpanel_0.3.2-4_*.deb


mkdir -p libx11-6/orig
cd   libx11-6/orig
apt source libx11-6




cd
export DISPLAY=:0

gdb -q --args hpanel

directory /home/benutzer/hpanel/try1/hpanel-0.3.2
directory /home/benutzer/libx11-6/orig/libx11-1.6.5/src/util
set pagination off
set height 0
set width 0
b get_task_hinticon
run




32bit:
157 XGetWindowProperty (dd, win, prop, 0, 0x7fff, False,
(gdb) print *hin
$24 = {flags = 39, input = 1, initial_state = 1, icon_pixmap = 12582937, 
icon_window = 0, icon_x = 0, icon_y = 0, icon_mask = 12582939, window_group = 0}
(gdb) print sizeof(*hin)
$25 = 36




64bit:
157 XGetWindowProperty (dd, win, prop, 0, 0x7fff, False,
(gdb) print *hin
$17 = {flags = 39, input = 1, initial_state = 0, icon_pixmap = 1, icon_window = 
12582937, icon_x = 0, icon_y = 0, icon_mask = 0, window_group = 0}
(gdb) print sizeof(*hin)
$18 = 56
Description: Use XGetWMHints instead of XGetWindowProperty with XA_WM_HINTS to support LP64.

Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/887467
Last-Update: 2018-08-14

--- hpanel-0.3.2.orig/hpanel.c
+++ hpanel-0.3.2/hpanel.c
@@ -235,7 +235,7 @@ get_task_hinticon (task *tk)
 	tk->icon = None;
 	tk->mask = None;
 
-	hin = (XWMHints *) get_prop_data (tk->win, XA_WM_HINTS, XA_WM_HINTS, 0);
+	hin = XGetWMHints(dd, tk->win);
 	if (hin)
 	{
 		if ((hin->flags & IconPixmapHint))

Bug#890804: xul-ext-tabmixplus: add WebExtensions version

[Christoph Anton Mitterer]

Control: severity -1 grave

Since FF ESR 52 has now left Debian unstable, the XUL version of this
is no longer usable in Debian.
Please upgrade to the WebExtensions version ASAP.

Thanks and best wishes,
Chris.

Bug#902617: gnome-maps, totem: Cannot move map, play video without allow_rgb10_configs=false

[Michel Dänzer]

On 2018-08-14 10:33 AM, Simon McVittie wrote:
> Control: reassign 902617 libgl1-mesa-dri 18.1.2-1
> Control: retitle 902617 gnome-maps, totem: Cannot move map, play video 
> without allow_rgb10_configs=false
> Control: tags 902617 + moreinfo
> 
> On Thu, 28 Jun 2018 at 17:15:12 +0200, Onno Leerink wrote:
>> Since installing Debian buster it is not possible to move the map using the
>> mouse in gnome-maps. Before this, moving the map was no problem.
>>
>> I found the following temporary solution in Redhat bug 1560481, start gnome-
>> maps with:
>>
>> allow_rgb10_configs=false gnome-maps
>>
>> This causes to gnome-maps to function normally again.
>>
>> This same solution also solves a bug concerning Totem not playing videos
>> anymore.
>>
>> I have a amd graphics card.
> 
> This sounds like a bug in your graphics driver rather than gnome-maps, so
> I'm reassigning it to the libgl1-mesa-dri package. The allow_rgb10_configs
> environment variable that you're using to work around this is a Mesa
> feature.

While the allow_rgb10_configs environment variable is a Mesa feature,
it's usually only needed to work around application / framework issues.

In this particular case, it's probably a known issue with the way
clutter does hit testing, which needs to be adapted to work with 10 bits
per component colour formats. This has been fixed in the current
upstream version of clutter used by mutter / gnome-shell, not sure about
the standalone clutter.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Bug#906065: ITP: postgrest -- Serve a RESTful API from any Postgres database

[Christoph Berg]

Re: Jonas Weber 2018-08-13 
<153419233728.5094.8626557681114177791.report...@carnifex.home.jonasw.de>
> I'll need a sponsor to upload the resulting packages to the
> repositories.

Hi,

would you want to maintain the package in the PostgreSQL team on
salsa.debian.org? I can sponsor uploads for you.

Christoph

Bug#904506: pcre3: FTBFS on most architectures: more STL symbols disappear

[Matthew Vernon]

severity 904506 important
quit

So this has now built successfully (I think version skew between gcc :-/
), so I think the severity is now important. Probably still worth making
more symbols optional.

Regards,

Matthew

Bug#906124: grub-efi: Secureboot GPG signature validation fails since 2.02+dfsg1-5 Package: grub-efi

[Somebody else]

Package: grub-efi
Version: 2.02+dfsg1-5
Severity: grave Justification: renders package unusable

Dear Maintainer,

I use Debian Buster with secureboot turned on on my Dell XPS13. I replaced
all UEFI keys with my own RSA keys and created a standalone grub_efi using
the scripts at https://github.com/jdelic/secureboot/.

Since updating to 2.02+dfsg1-5, booting in secureboot mode fails with an
"invalid signature" error for vmlinuz-4.17.0-1-amd64. I turned on "crypt"
debug mode on the signed grub image and the last logged "alive" line is
verify.c:620. So Grub detects secureboot and starts verifying and then fails.

I use my public GPG key (0x7CDC4589) for signing. The detached signature is:
iQIzBAABCgAdFiEE5NQyBIYeHiZU1onRn+lmU4TReRgFAltyqNwACgkQn+lmU4TReRgnjRAA0dMV
eS7BSs61qtJKjJ+RlpXj9O73rMTBkkCArHfYD7/RX2G6f09We50ZT7CtTPtt+sSYutppOjIbRucd
paQSGox18JH1JMpjjiZYdzCXmJEpwuwuvYHyrYF1DVczB2rbk1AtpTq8fvir4W5fnj/CS20g35em
uCiUtnuyDotJ3/Z3tIKVlvfpiA8ndvUSl37SxX3K/pQ1EQocyGaKFsythFFhK838/Y97BSQyw8h4
h0MU1hBgmdANmy1UsaAlyfbozXnT2UDOlnyfIvR9f0K7ldTZqxGkhZhixFjRlV9LLNLbC7wIxY2a
MrJVmEO8r1JMwp4Tbysplv6zY3JYnKXP++b+WnQr4aRSdzzcn7KbU3uDT6EdtO9pUJ6/5agMScMi
NJWFNa4vQ0UAtc1Og/9ZSt+k8BhX7wXTYreuAOKDCBpd1FvgOMHdCuQscI2xSLtczV5b76TbjxoP
vk0SIzqO6Sko71MMHgJEodTY1oTEFbeyGJmPhyTMuv67R1aF5LRtHVK3Pdt7Hf9M71Mzl+YbGXjb
fXti1BYaLQstKvyaQYhKVIhn6I9ZAQGPuXpr0fp7NFngajDrinFtjJHJQ98E/PQCUTQRNy7MqPNu
MDf/WlNMpzrOzo2fpwWqfwtlXbVCZWcKJjmFg5MuEBpX6cO4n5OmOMZ9xf6877LQgfr3+yU=

You can verify the signature like this:
mkdir /tmp/sigtest
cd /tmp/sigtest
apt download linux-image-4.17.0-1-amd64
dpkg-deb -x \
linux-image-4.17.0-1-amd64_4.17.8-1_amd64.deb \
unpack
base64 -d > unpack/boot/vmlinuz-4.17.0-1-amd64.sig
# (copy paste the above signature)
gpg --recv-key 7CDC4589
gpg --verify unpack/boot/vmliuz-4.17.0-1-amd64.sig

You should then see output like this:
gpg: assuming signed data in 'unpack/boot/vmlinuz-4.17.0-1-amd64'
gpg: Signature made Tue 14 Aug 2018 12:03:08 PM CEST
gpg:using RSA key E4D43204861E1E2654D689D19FE9665384D17918
gpg: Good signature from "Jonas Maurus " [ultimate]
gpg: aka "Jonas Maurus " [ultimate]
gpg: aka "Jonas Maurus " [ultimate]

Please contact me if you need any more information.
Thank you,
Jonas Maurus

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/vg0-root / ext4 rw,relatime,errors=remount-ro 0 0
/dev/nvme0n1p2 /boot ext2 rw,relatime,block_validity,barrier,user_xattr,acl 0 0
/dev/nvme0n1p1 /boot/efi vfat
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
0 0
/dev/mapper/vg0-home /home ext4 rw,relatime 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  41f85d8a-3669-417c-8a68-31b1edd73596
else
  search --no-floppy --fs-uuid --set=root 41f85d8a-3669-417c-8a68-31b1edd73596
fi
font="/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=hidden
set timeout=0
  # Fallback hidden-timeout code in case the timeout_style feature is
  # unavailable.
  elif sleep --interruptible 0 ; then
set timeout=0
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian 

Bug#905106: gnome-shell-extension-dashtodock: global.screen is not available in GNOME Shell 3.29

[Jeremy Bicha]

I believe you'll want to cherry-pick this commit to fix the GNOME
Shell 3.30 compatibility.

https://github.com/micheleg/dash-to-dock/commit/8398d41c6

Thanks,
Jeremy Bicha

Bug#903533: yapf FTBFS with Python 3.7 as supported version

[Ana C. Custura]

Ah, I missed this - thank you.

Ana

On Tue, Aug 14, 2018, at 3:05 PM, Matthias Klose wrote:
>* debian/rules:
>- prevents some Python3 tests from running (Closes: #903533)
> 
> this doesn't address the failures in the autopkg tests.

Bug#906123: texlive-extra-utils: The patch of a2ping is incorrect

[Norbert Preining]

> $ head /usr/share/texlive/texmf-dist/scripts/a2ping/a2ping.pl
> +#! /usr/bin/perl -w
> +package Htex::a2ping;

Ouch  that is bad. Thanks for reporting.

Fixed in the git repo, will be in the next upload.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#905615: healpy: FTBFS with python 3.7

[Ole Streicher]

Control: tags -1 patch

The following patch fixes the FTBFS.

Cheers

Ole
>From 86111629ba3b99df2aacdc9dd4e777cc9ed9f76c Mon Sep 17 00:00:00 2001
From: Ole Streicher 
Date: Tue, 14 Aug 2018 16:36:03 +0200
Subject: [PATCH] Rebuild C++ files from Cython sources

This is required for Python 3.7 since the API changed a bit.

Closes: #905615
---
 debian/clean   | 3 +++
 debian/control | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/debian/clean b/debian/clean
index fdc9787..c418c17 100644
--- a/debian/clean
+++ b/debian/clean
@@ -1 +1,4 @@
 matplotlibrc
+healpy/src/_pixelfunc.cpp
+healpy/src/_query_disc.cpp
+healpy/src/_sphtools.cpp
diff --git a/debian/control b/debian/control
index 79076e7..4b38474 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,8 @@ Uploaders: Leo Singer 
 Homepage: http://healpy.readthedocs.org
 Section: python
 Build-Depends:
+ cython,
+ cython3,
  python-setuptools (>= 0.6.14),
  python-all-dev (>= 2.7),
  python-matplotlib,
-- 
2.18.0

Bug#879728: mysqld fails to start not finding messagefile when started by systemd

[Faustin Lammler]

Hi Thomas,
can you please investigate further on Ondřej's suggestion (apparmor).

Please check out this for information on how to verify it:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900398#10

Is there any chance that you are using a "non official kernel"?
What is the systemd version installed on your system?
$ uname -r
$ dpkg -l | grep systemd

Faustin

Bug#906123: texlive-extra-utils: The patch of a2ping is incorrect

[OGAWA Hirofumi]

Package: texlive-extra-utils
Severity: normal

$ head /usr/share/texlive/texmf-dist/scripts/a2ping/a2ping.pl
+#! /usr/bin/perl -w
+package Htex::a2ping;
#
# This program is free software, licensed under the GNU GPL, >=2.0.
# This software comes with absolutely NO WARRANTY. Use at your own risk!
#

Note, this is not a patch, is actual installed script. Like this, the
patch for a2ping.pl is incorrect (adding "+" for 2 lines at top).

Please removing incorrect "+" from the patch for a2ping.pl.

Thanks.

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

Kernel: Linux 4.17.14 (SMP w/8 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/bash
Init: sysvinit (via /sbin/init)

-- 
OGAWA Hirofumi 

Bug#889904: /etc/flash-kernel/dtbs versioning

[Joey Hess]

Uwe Kleine-König wrote:
> Right, in theory the dtbs are independant from the kernel, but real life
> is different. That's why the linux image packages ship their matchin
> device trees. I don't know your setup, but it would be easiest to use
> these. If you don't provide your own dtb and just use
> 
>   DTB-Id: sun7i-a20-cubietruck.dtb
> 
> everything should simply work.

I'm using a custom device tree file to enable onewire temperature
sensors. More generally, 
http://joeyh.name/blog/entry/easy-peasy-devicetree-squeezy/
currently puts its device tree file in /etc/flash-kernel/dtbs/
and thus is affected by the lack of kernel versioning.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#906122: thunar: Thunar doesn't show a deleted file which is present in /.Trash-1000/files/

[Serge Pouliquen]

Package: thunar
Version: 1.6.11-1
Severity: normal

Dear Maintainer,

On my system, there are 2 partitions : / and /home

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

In order to have a functional trash for root partition, I made a directory 
called /.Trash-1000/
  ls -l 
  drwxr-xr-x   44096 Aug 12 19:42 .Trash-1000

When I delete a file (from /usr/local/...) with Thunar, It is correctly moved 
to /.Trash-1000/files/

When using Thunar with location "trash:///", I didn't see my deleted file.

   * What outcome did you expect instead?

I was expecting to see the deleted file with Thunar in trash.

in https://specifications.freedesktop.org/trash-spec/trashspec-latest.html
> For showing trashed files, implementations SHOULD support (1) and (2) at the 
> same time (that is, if both $topdir/.Trash/$uid and $topdir/.Trash-$uid are 
> present, it should list trashed files from both of them).

I didn't read anywhere in the document that $topdir can't be root partition. 
But I may have misunderstood the document.
If it looks inappropriate to developper, you can close it.

I didn't try to empty trash, so I don't know if it will be removing the deleted 
file.

Regards,


-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (80, 'testing'), (58, 
'unstable'), (55, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-1
ii  exo-utils   0.10.7-1
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-11+deb9u3
ii  libcairo2   1.14.8-1
ii  libdbus-1-3 1.10.26-0+deb9u1
ii  libdbus-glib-1-20.108-2
ii  libexo-1-0  0.10.7-1
ii  libgdk-pixbuf2.0-0  2.36.5-2+deb9u2
ii  libglib2.0-02.50.3-2
ii  libgtk2.0-0 2.24.31-2
ii  libgudev-1.0-0  230-3
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.7-2
ii  libpango-1.0-0  1.40.5-1
ii  libsm6  2:1.2.2-1+b3
ii  libthunarx-2-0  1.6.11-1
ii  libxfce4ui-1-0  4.12.1-2
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  shared-mime-info1.8-1+deb9u1
ii  thunar-data 1.6.11-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.10.26-0+deb9u1
ii  dbus-x11 [dbus-session-bus]   1.10.26-0+deb9u1
ii  gvfs  1.30.4-1
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libpangocairo-1.0-0   1.40.5-1
ii  libpangoft2-1.0-0 1.40.5-1
ii  thunar-volman 0.8.1-2
ii  tumbler   0.1.31-2+b3
ii  xdg-user-dirs 0.15-2+b1
ii  xfce4-panel   4.12.1-2

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.3.1-4
ii  thunar-media-tags-plugin  0.2.1-1+b2

-- no debconf information

Bug#905938: git-rebase(1) has wrong filename for revert-a-faulty-merge.html

[Ben Hutchings]

Control: severity -1 minor
Control: retitle -1 Files in git-doc may not be findable by apt-file search

On Mon, 2018-08-13 at 19:27 -0700, Jonathan Nieder wrote:
> tags 905938 + moreinfo
> quit
> 
> Hi Ben,
> 
> Ben Hutchings wrote:
> 
> > git-rebase(1) refers to
> > /usr/share/doc/git/html/howto/revert-a-faulty-merge.html, but this
> > filename does not exist in any package.  git-doc contains
> > /usr/share/doc/git-doc/howto/revert-a-faulty-merge.html which is
> > presumably the right file to refer to.
> 
> $ ls -ld /usr/share/doc/git/html
> lrwxrwxrwx 1 root root 10 May 30  2017 /usr/share/doc/git/html -> ../git-doc
> 
> Is it configured differently on your machine?

No, it's not.  Now that I have git-doc installed, the symlink is there
and I can access the document through both filenames.

Initially I did not have git-doc installed, and "apt-file search"
couldn't find the file by the name given in git-rebase(1) because it
doesn't take symlinks into account.

[...]
> Arguably it would be better to install directly into
> /usr/share/doc/git/html, but that would have broken links (e.g.
> kernel-handbook links to [1]).  Perhaps the package should install
> docs directly to /usr/share/doc/git/html and put some symlinks in
> /usr/share/doc/git-doc --- what do you think?

I don't know.  Do whichever you think is likely to cause least
confusion.

Ben.

-- 
Ben Hutchings
The Peter principle: In a hierarchy, every employee tends to rise to
their level of incompetence.



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

Bug#906121: RM: qrfcview -- RoQA; Unmaintained; Upstream dead; Affected by Qt4 Removal

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: christ...@debian.org bi...@debian.org frede...@lehobey.net

Dear FTP Masters,

Please remove package qrfcview from Debian Archive.

This package currently:

* received no packaging activity since 2013
* no maintainer activity since 2008
* upstream dead, last upstream activity in 2006
* homepage defunct
* affected by Qt4 Removal in Debian [1]
* has low, declining popcon
* previous maintainers didn't respond to the public query [2] sent out
  fourteen days ago

As a result, I think this package is eligible to removal from Debian,
right now.

Package qrfcview has no reverse dependencies.

Dear qrfcview maintainers and uploaders, if you have any ideas or doubts
on this RM request, please respond to this RM bug **now** and let me know
about the future plan on dealing with qrfcview in Debian.

--
Regards,
Boyuan Yang


[1] https://wiki.debian.org/Qt4Removal
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875143#10

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

Bug#867137: [debian-mysql] Bug#867137: mariadb-server-10.1: mariadb install fails with NO_NEW_PRIVILEGES

[Faustin Lammler]

Hi Ozzloy,
from what I see, you are using the Linux 3.2.0-4-amd64 kernel that is
the oldoldstable kernel.
https://packages.debian.org/search?keywords=linux-image-3.2.0-4-amd64

Is there any reason why you are using this kernel version?
Can you try to reproduce the bug with a more recent kernel (3.16 or 4.9)?

I can not boot on the 3.2.0-4-amd64 kernel on my test platform (Debian 9
KVM), and so I can not try to reproduce this issue that may be related to
systemd — kernel interaction.

Faustin

Bug#906120: RM: libsass0 -- NBS; replaced by libsass1, not used anymore

[Aurelien Jarno]

Package: ftp.debian.org
Severity: normal

Due to the libsass transition, the libsass0 package has been replaced by
libsass1. The libsass0 and the associated libsass0-dbg packages are not
used by other dependencies and can therefore be removed from the archive.

(Filling this request as it's one of the last package still
pre-depending on multiarch-support).

Bug#906119: Gratuitous sexual references

[Ian Jackson]

Package: weboob
Version: 1.3-1
Severity: serious

Hi.

As has been extensively discussed elsewhere (eg [1]), this package has
some unfortunate sexual references.  These problems include:
 * Command names which contain sexual references
 * Sexually suggestive icons etc.
There are, I suspect, other problems.  The sexualised content is both
gratuitous and unambiguous.

IMO this is in conflict with with Debian's values, in particular those
underlying the Diversity Statement.  gregor herrmann explained very
well why this is unacceptable here [0].  As you know, the matter has
been discussed with upstream.  It appears that upstream are,
unfortunately, not willing to change this. [2]

This situation is very unfortunate.  As I understand it the package
itself is very useful for some otherwise difficult situations.
However, IMO the problems are sufficiently serious that the package as
it is is not suitable for Debian, no matter how useful it is.

So, given that upstream have rejected requests for change, IMO the
available responses for the Debian project are to bowdlerise the
package (that is, to rename the commands, review the documentation,
change the icons, and so on), or to remove the package.

It seems to me from reading the thread on -devel that a substantial
majority of the Debian contributors there agree with that conclusion.
Accordingly I have marked this bug as "serious".


I think I need to make some points about the right process for
handling this disagreement:

Of course these postings to -devel may not represent a real view of
the project's consensus.  Mailing list traffic is not a particularly
good way of judging these matters.  A better guide is the Diversity
Statement GR, perhaps: although it is not directly on point, the
majority in favour was overwhelming.  Nevertheless there is probably
some room for differing assessments of the project's overall view.

While there is no requirement for a package maintainer to abide by the
project consensus, whether a package is suitable for the release is
ultimately a matter for the Release Team.  On a matter like this I
would expect the Release Team to follow what they see as the project's
rough consensus.

I had hoped that this matter could be brought to a satisfactory
resolution amicably.  However that does not now appear to be possible.
The discussion on -devel is becoming a distraction.  IMO we need to
bring it to a close.

I consider this matter important, and I am convinced that the project
consensus is with me.  Under the circumstances it would be quite wrong
to just drop it, and accept the unacceptable status quo.

So that is why I am filing this bug now.  If you as maintainer
disagree with my assessment, then we should refer the dispute about
the bug severity to the Release Team, in accordance with usual
practice.

For the avoidance of doubt: if the Release Team feel the project's
consensus is not sufficiently clear; or that a removal decision by the
Release Team would lack legitimacy, I would quite understand.
In that case the right next step would be a General Resolution.  If
necessary I will propose and/or sponsor a GR to definitively establish
Debian's view that this package is unacceptable.

With regret,
Ian.

[0] https://lists.debian.org/debian-devel/2018/07/msg00428.html
[1] https://lists.debian.org/debian-devel/2018/07/msg00263.html
[2] See for example:
  https://lists.debian.org/debian-devel/2018/07/msg00386.html

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#886291: pycryptodome naming

[Vincent Bernat]

 ❦ 13 août 2018 22:05 +0200, Alexis Murzeau :

> Currently, packages which depends on python3-pycryptodome are:
> - python3-httpsig
> - python3-pysnmp4
>
> python3-httpsig exists only in unstable.
> python3-pysnmp4 exists in stable but depends on python3-crypto and the
> version in testing/unstable is the same.
>
> I suggests this to ensure an upgrade path while renaming around this
> package:
> - Change httpsig and pysnmp4 dependencies on python3-pycryptodome to
> "python3-pycrytodomex (>= 3.6.1-3) | python3-pycrytodome (<< 3.6.1-3)"
> - Wait both package to enter testing (at this time, python3-pycrytodomex
> doesn't exists yet)
> - Update python3-pycryptodome to version 3.6.1-3 to build pycryptodome
> instead of pycryptodomex
> - Introduce python3-pycryptodomex at version 3.6.1-3
> - After python3-pycryptodomex version 3.6.1-3 enter testing, maybe
> update httpsig and pysnmp4 dependencies on python3-pycryptodome to
> "python3-pycrytodomex" only
>
> Adding maintainers of python3-pysnmp4 as they are involved in this
> scenario.

python-pysnmp4 is team-maintained. Feel free to do the upload yourself
if you have the rights. Otherwise, I can do the upload when you see fit.
-- 
As to the Adjective: when in doubt, strike it out.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


signature.asc
Description: PGP signature