Bug#913586: texlive-binaries 2018.20181104.49075-1 breaks context

[Hilmar Preuße]

Am 13.11.2018 um 03:22 teilte Norbert Preining mit:

Hi,


Can you please run on the command line as root!

mtxrun --generate

That should rebuild the ConTeXt MarkIV format. It does work here.


This still runs fine. The next step hangs:

(Reading database ... 284193 files and directories currently installed.)
Preparing to unpack .../context_2018.04.04.20180416-1_all.deb ...
Unpacking context (2018.04.04.20180416-1) over (2018.04.04.20180416-1) ...
Processing triggers for tex-common (6.10) ...
Running mktexlsr. This may take some time... done.
Setting up context (2018.04.04.20180416-1) ...
Running mtxrun --generate. This may take some time... done.
Pregenerating ConTeXt MarkIV format. This may take some time...

...and the hanging command is

luatex --ini --lua=/usr/share/texmf/tex/context/base/mkiv/luat-cod.lua 
/usr/share/texmf/tex/context/base/mkiv/cont-en.mkiv dump


Hilmar
--
#206401 http://counter.li.org

Bug#912532: stunnel4: "Internal error: double free attempt" with OpenSSL 1.1.1-1 and 1.1.1-2

[Peter Pentchev]

On Tue, Nov 13, 2018 at 11:25:05AM +0800, Frank Chung wrote:
> Dear maintainer,
> 
> Another quick update: on another machine running stunnel4 3:5.49-1 as
> server, I tried upgrading openssl to 1.1.1-2 and then adding "options =
> NO_TLSv1.3" to stunnel.conf, thus forcing the two ends (both running
> stunnel4 3:5.49-1 and openssl 1.1.1-2) to negotiate TLS 1.2. This proves
> effective at preventing segfaults as well. So the problem seems to have
> something to do with TLS 1.3.

Thanks for the analysis, and sorry that I have not replied until now!

I'll take a look at this problem in the next couple of days, thanks for
your work so far!

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#913601: [Ceph-maintainers] Bug#913601: ceph: FTBFS on mips/el: /usr/include/c++/8/bits/atomic_base.h:304: undefined reference to `__atomic_fetch_sub_8'

[Emilio Pozuelo Monfort]

On 13/11/2018 08:28, Gaudenz Steinlin wrote:
> 
> Hi
> 
> Emilio Pozuelo Monfort  writes:
>>
>> Your package failed to build on mips/el:
>> /usr/bin/ld: CMakeFiles/ceph-mgr.dir/mgr/DaemonServer.cc.o: in function
>> `RefCountedObject::~RefCountedObject()':
>> /usr/include/c++/8/bits/atomic_base.h:396: undefined reference to
>> `__atomic_load_8' /usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:396:
>> undefined reference to `__atomic_load_8' /usr/bin/ld:
>> CMakeFiles/ceph-mgr.dir/mgr/DaemonServer.cc.o: in function
>> `RefCountedObject::~RefCountedObject()':
>> You may need to link with -latomic.
> 
> As you can see from the rules file the package already links with -latomic by
> setting it in DEB_LDFLAGS_MAINT_APPEND. The problem is
> that cmake inserts this option before some of the object files so those don't
> get linked with libatomic.
> 
> I'm working on a fix for this. Do you know which architectures in Debian
> actually need libatomic? I would like to avoid any unnecessary linking to it.

I don't know. At least mips, mipsel and powerpc failed in this way:

https://buildd.debian.org/status/package.php?p=ceph

Maybe some others, but since most architectures can't currently build due to the
boost-context problem, we'll have to wait for that to be fixed to find out.

Emilio

Bug#913552: firehol: Firehol upgrade 3.1.6+ds-4 to 3.1.6+ds-5 leaves firehol broken

[Russel Winder]

> Package: usrmerge
> Description-en: Convert the system to the merged /usr directories scheme

That seems like the beastie, and it is a once and for all time thing it seems.
I have not installed this. At least not as yet. I am hesitant to do this as it
is clearly not Debian Sid standard and it is not reversible.




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

Bug#913626: r-cran-stringi ftbfs with the new icu

[Matthias Klose]

Package: src:r-cran-stringi
Version: 1.2.4-1
Severity: serious
Tags: sid buster

r-cran-stringi ftbfs with the new icu:

*** The available ICU4C cannot be used
checking whether we may compile src/icu61/common/putil.cpp... yes
checking whether we can fetch icudt... downloading the ICU data library (icudt)
output path: icu61/data/NA
trying URL 'http://www.ibspan.waw.pl/~gagolews/stringi/NA'
Error in download.file(paste(href, fname, sep = ""), icudtzipfname, mode =
"wb"): cannot open URL 'http://www.ibspan.waw.pl/~gagolews/stringi/NA'

trying URL 'http://www.gagolewski.com/software/stringi/NA'
Error in download.file(paste(href, fname, sep = ""), icudtzipfname, mode =
"wb"): cannot open URL 'http://www.gagolewski.com/software/stringi/NA'

trying URL
'https://raw.githubusercontent.com/gagolews/stringi/master/src/icu61/data/NA'
Error in download.file(paste(href, fname, sep = ""), icudtzipfname, mode =
"wb"): cannot open URL
'https://raw.githubusercontent.com/gagolews/stringi/master/src/icu61/data/NA'

trying URL
'https://raw.githubusercontent.com/gagolews/stringi/master/src/icu55/data/NA'
Error in download.file(paste(href, fname, sep = ""), icudtzipfname, mode =
"wb"): cannot open URL
'https://raw.githubusercontent.com/gagolews/stringi/master/src/icu55/data/NA'

trying URL
'http://raw.githubusercontent.com/gagolews/stringi/master/src/icu61/data/NA'
Error in download.file(paste(href, fname, sep = ""), icudtzipfname, mode =
"wb"): cannot open URL
'http://raw.githubusercontent.com/gagolews/stringi/master/src/icu61/data/NA'

trying URL
'http://raw.githubusercontent.com/gagolews/stringi/master/src/icu55/data/NA'
Error in download.file(paste(href, fname, sep = ""), icudtzipfname, mode =
"wb"): cannot open URL
'http://raw.githubusercontent.com/gagolews/stringi/master/src/icu55/data/NA'

icudt download failed
Error: Stopping on error
In addition: Warning messages:
1: In download.file(paste(href, fname, sep = ""), icudtzipfname, mode = "wb") :
  URL 'http://www.ibspan.waw.pl/~gagolews/stringi/NA': status was 'Couldn't
resolve host name'
2: In download.file(paste(href, fname, sep = ""), icudtzipfname, mode = "wb") :
  URL 'http://www.gagolewski.com/software/stringi/NA': status was 'Couldn't
resolve host name'
3: In download.file(paste(href, fname, sep = ""), icudtzipfname, mode = "wb") :
  URL
'https://raw.githubusercontent.com/gagolews/stringi/master/src/icu61/data/NA':
status was 'Couldn't resolve host name'
4: In download.file(paste(href, fname, sep = ""), icudtzipfname, mode = "wb") :
  URL
'https://raw.githubusercontent.com/gagolews/stringi/master/src/icu55/data/NA':
status was 'Couldn't resolve host name'
5: In download.file(paste(href, fname, sep = ""), icudtzipfname, mode = "wb") :
  URL
'http://raw.githubusercontent.com/gagolews/stringi/master/src/icu61/data/NA':
status was 'Couldn't resolve host name'
6: In download.file(paste(href, fname, sep = ""), icudtzipfname, mode = "wb") :
  URL
'http://raw.githubusercontent.com/gagolews/stringi/master/src/icu55/data/NA':
status was 'Couldn't resolve host name'
Execution halted
*** icudt download failed. stopping.
ERROR: configuration failed for package ‘stringi’
* removing 
‘/<>/debian/r-cran-stringi/usr/lib/R/site-library/stringi’
dh_auto_install: R CMD INSTALL -l
/<>/debian/r-cran-stringi/usr/lib/R/site-library --clean .
"--built-timestamp='Tue, 13 Nov 2018 08:02:59 +'" returned exit code 1
make: *** [debian/rules:4: binary-arch] Error 2

Bug#913463: corrected po file

[Markus Hiereth]

Hello

the previously sent po-file contained a line where single quotation
marks appeared that might cause problems. They have been replaced by "
in the attached file.

Best regards
Markus
# Übersetzung des Dialogs zur Konfiguration von shim-signed
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the shim-signed package.
# Markus Hiereth , 2018.
msgid ""
msgstr ""
"Project-Id-Version: shim-signed 1.28\n"
"Report-Msgid-Bugs-To: shim-sig...@packages.debian.org\n"
"POT-Creation-Date: 2018-11-04 08:13+0100\n"
"PO-Revision-Date: 2018-11-11 18:57+0200\n"
"Last-Translator: Markus Hiereth \n"
"Language-Team: debian-l10n-german \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Virtaal 0.7.1\n"

#. Type: text
#. Description
#: ../templates:1001
msgid "Configuring UEFI Secure Boot"
msgstr "UEFI Secure Boot konfigurieren"

#. Type: error
#. Description
#: ../templates:2001
msgid "Invalid password"
msgstr "Ungültiges Passwort"

#. Type: error
#. Description
#: ../templates:2001
msgid ""
"The Secure Boot key you've entered is not valid. The password used must be "
"between 8 and 16 characters."
msgstr ""
"Der von Ihnen für Secure Boot eingegebene Schlüssel ist ungültig. Das "
"verwendete Passwort muss zwischen 8 und 16 Zeichen lang sein."

#. Type: boolean
#. Description
#: ../templates:3001
msgid "Disable UEFI Secure Boot?"
msgstr "UEFI Secure Boot deaktivieren?"

#. Type: boolean
#. Description
#. Type: note
#. Description
#: ../templates:3001 ../templates:5001
msgid ""
"If Secure Boot remains enabled on your system, your system may still boot "
"but any hardware that requires third-party drivers to work correctly may not "
"be usable."
msgstr ""
"Wenn Secure Boot aktiviert bleibt, kann es sein, dass Ihr System zwar "
"noch startet, Sie aber jegliche Hardware, die von Dritten bereitgestellte "
"Treiber benötigt, nicht verwenden können."

#. Type: boolean
#. Description
#: ../templates:4001
msgid "Enable UEFI Secure Boot?"
msgstr "UEFI Secure Boot aktivieren?"

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"If Secure Boot is enabled on your system, your system may still boot but any "
"hardware that requires third-party drivers to work correctly may not be "
"usable."
msgstr ""
"Wenn Secure Boot aktiv ist, kann es sein, dass Ihr System zwar noch startet, "
"Sie aber jegliche Hardware, die von Dritten bereitgestellte Treiber "
"benötigt, nicht verwenden können."

#. Type: note
#. Description
#: ../templates:5001
msgid "Your system has UEFI Secure Boot enabled"
msgstr "UEFI Secure Boot ist auf Ihrem System aktiviert"

#. Type: note
#. Description
#: ../templates:5001
msgid "UEFI Secure Boot is not compatible with the use of third-party drivers."
msgstr ""
"UEFI Secure Boot ist mit von Dritten bereitgestellten Treibern inkompatibel."

#. Type: note
#. Description
#: ../templates:5001
msgid ""
"The system will assist you in toggling UEFI Secure Boot. To ensure that this "
"change is being made by you as an authorized user, and not by an attacker, "
"you must choose a password now and then use the same password after reboot "
"to confirm the change."
msgstr ""
"Das System wird Sie beim Ein- und Ausschalten von UEFI Secure Boot "
"unterstützen. Um sicherzustellen, dass hinter der entsprechenden Eingabe "
"nicht ein Angreifer, sondern Sie als berechtigter Benutzer stehen, müssen Sie "
"jetzt ein Passwort wählen. Dieses ist beim Wiederhochfahren "
"erneut einzugeben, um die Änderung zu bestätigen."

#. Type: note
#. Description
#: ../templates:5001
msgid ""
"If you choose to proceed but do not confirm the password upon reboot, the "
"Secure Boot configuration will not be changed, and the machine will continue "
"booting as before."
msgstr ""
"Wenn Sie fortfahren, aber das Passwort beim nächsten Start nicht bestätigen, "
"bleibt die Konfiguration von Secure Boot erhalten und Ihr Rechner wird "
"starten wie zuvor."

#. Type: password
#. Description
#: ../templates:6001
msgid "UEFI Secure Boot password:"
msgstr "UEFI Secure Boot Passwort:"

#. Type: password
#. Description
#: ../templates:6001
msgid "Please enter a password for configuring UEFI Secure Boot."
msgstr ""
"Bitte geben Sie zur Konfiguration von UEFI Secure Boot ein Passwort ein."

#. Type: password
#. Description
#: ../templates:6001
msgid ""
"This password will be used after a reboot to confirm authorization for a "
"change to Secure Boot state."
msgstr ""
"Dieses Passwort dient nach dem Wiederhochfahren zur Prüfung, ob der Benutzer "
"berechtigt ist, den Secure-Boot-Zustand zu ändern."

#. Type: password
#. Description
#: ../templates:7001
msgid "Re-enter password to verify:"
msgstr ""
"Bestätigen Sie die Richtigkeit des Passwortes, "
"indem Sie es noch einmal eingeben:"

#. Type: password
#. Description
#: ../templates:7001
msgid ""
"Please 

Bug#913636: context.postinstall "luatools --make cont-en" hangs, "attempt to call upvalue 'isfile' (a nil value)"

[Jonathon Fernyhough]

Package: context
Version: 2018.04.04.20180416-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When installing context with texlive-binaries=2018.20181104.49075-1 the
context.postinst task `luatools --make cont-en` fails to complete correctly
making package installation hang indefinitely:

$ luatools --make cont-en

resolvers   | formats | using format path 
'/var/lib/texmf/luatex-cache/context/b47c3d3cee7cb6c86268d0595268c442/formats/luatex'
resolvers   | resolving | using given filetype 'tex'
resolvers   | methods | resolving, method 'concatinators', how 'tag', tag 
'file'
resolvers   | resolving | remembering file 'cont-en.mkiv' using hash 
'tex::cont-en.mkiv'
resolvers   | formats | using tex source file 
'/usr/share/texmf/tex/context/base/mkiv/cont-en.mkiv'
resolvers   | resolving | checking qualified name 
'/usr/share/texmf/tex/context/base/mkiv/cont-en.lus'
resolvers   | resolving | using given filetype 'tex'
resolvers   | resolving | remembering file 
'/usr/share/texmf/tex/context/base/mkiv/cont-en.lus' using hash 
'tex::/usr/share/texmf/tex/context/base/mkiv/cont-en.lus'
resolvers   | resolving | remembering file 
'/usr/share/texmf/tex/context/base/mkiv/context.lus' using hash 
'tex::/usr/share/texmf/tex/context/base/mkiv/context.lus'
resolvers   | formats | executing runner 'make luatex format': luatex --ini 
 --lua=/usr/share/texmf/tex/context/base/mkiv/luat-cod.lua 
/usr/share/texmf/tex/context/base/mkiv/cont-en.mkiv  \dump This is LuaTeX, 
Version 1.09.0 (TeX Live 2019/dev/Debian)  (INITEX)
 system commands enabled.
error in callback: /usr/share/texmf/tex/context/base/mkiv/luat-cod.lua:166: 
attempt to call upvalue 'isfile' (a nil value)
.
  
 
<*> ...hare/texmf/tex/context/base/mkiv/cont-en.mkiv 
  dump
? 


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

Kernel: Linux 4.18.0-18.1-liquorix-amd64 (SMP w/16 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL 
set to C), LANGUAGE=en_GB: (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages context depends on:
ii  lmodern   2.004.5-5
ii  ruby  1:2.5.1
ii  tex-common6.10
ii  tex-gyre  20180621-2
ii  texlive-base  2018.20181106-1
ii  texlive-binaries  2018.20181104.49075-1
ii  texlive-metapost  2018.20181106-1

Versions of packages context recommends:
pn  context-modules   
pn  fonts-freefont
ii  fonts-gfs-artemisia   1.1-5
ii  fonts-gfs-baskerville 1.1-5
pn  fonts-gfs-bodoni-classic  
ii  fonts-gfs-didot   1.1-6
pn  fonts-gfs-didot-classic   
pn  fonts-gfs-gazis   
ii  fonts-gfs-neohellenic 1.1-6
ii  fonts-gfs-olga1.1-5
ii  fonts-gfs-porson  1.1-6
ii  fonts-gfs-solomos 1.1-5
pn  fonts-gfs-theokritos  
ii  fonts-sil-gentium 20081126:1.03-2

Versions of packages context suggests:
pn  context-doc-nonfree  
pn  context-nonfree  
pn  fontforge
pn  libxml-parser-perl   
pn  perl-tk  

-- no debconf information

Bug#913630: scilab: Raise java.lang.module.FindException on start

[Christophe Troestler]

Package: scilab
Version: 6.0.1-5
Severity: grave

Dear Maintainer,

When starting, scilab displays

Picked up _JAVA_OPTIONS: 
-Djava.class.path=/usr/share/java/flexdock.jar:/usr/share/java/skinlf.jar:/usr/share/java/looks.jar:/usr/share/java/commons-logging.jar:/usr/share/java/jhall.jar:/usr/share/java/lucene-core-4.10.4.jar:/usr/share/java/lucene-analyzers-common-4.10.4.jar:/usr/share/java/lucene-queryparser-4.10.4.jar:/usr/share/maven-repo/org/freehep/freehep-util/debian/freehep-util-debian.jar:/usr/share/maven-repo/org/freehep/freehep-io/debian/freehep-io-debian.jar:/usr/share/maven-repo/org/freehep/freehep-graphicsio/debian/freehep-graphicsio-debian.jar:/usr/share/java/freehep-graphicsio-emf-2.1.jar:/usr/share/java/freehep-graphics2d-2.1.1.jar:/usr/share/java/jrosetta-API.jar:/usr/share/java/jrosetta-engine-1.0.4.jar:/usr/share/java/jgraphx.jar:/usr/share/java/jogl2.jar:/usr/share/java/gluegen2-rt.jar:/usr/share/java/jeuclid-core.jar:/usr/share/java/jlatexmath-fop-1.0.7.jar:/usr/share/java/fop.jar:/usr/share/java/saxon.jar:/usr/share/java/batik.jar:/usr/share/java/xml-apis-ext.jar:/usr/share/java/commons-io.jar:/usr/share/java/xmlgraphics-commons.jar:/usr/share/java/avalon-framework.jar:/usr/share/java/jlatexmath-1.0.7.jar:/usr/share/java/ecj.jar:/usr/share/scilab/modules/types/jar/org.scilab.modules.types.jar:/usr/share/scilab/modules/core/jar/org.scilab.modules.core.jar:/usr/share/scilab/modules/jvm/jar/org.scilab.modules.jvm.jar:/usr/share/scilab/modules/javasci/jar/org.scilab.modules.javasci.jar:/usr/share/scilab/modules/graphic_objects/jar/org.scilab.modules.graphic_objects.jar:/usr/share/scilab/modules/completion/jar/org.scilab.modules.completion.jar:/usr/share/scilab/modules/action_binding/jar/org.scilab.modules.action_binding.jar:/usr/share/scilab/modules/renderer/jar/org.scilab.modules.renderer.jar:/usr/share/scilab/modules/scirenderer/jar/scirenderer.jar:/usr/share/scilab/modules/scinotes/jar/org.scilab.modules.scinotes.jar:/usr/share/scilab/modules/commons/jar/org.scilab.modules.commons.jar:/usr/share/scilab/modules/external_objects_java/jar/org.scilab.modules.external_objects_java.jar:/usr/share/scilab/modules/gui/jar/org.scilab.modules.gui.jar:/usr/share/scilab/modules/xcos/jar/org.scilab.modules.xcos.jar:/usr/share/scilab/modules/graphic_export/jar/org.scilab.modules.graphic_export.jar:/usr/share/scilab/modules/console/jar/org.scilab.modules.console.jar:/usr/share/scilab/modules/preferences/jar/org.scilab.modules.preferences.jar:/usr/share/scilab/modules/history_manager/jar/org.scilab.modules.history_manager.jar:/usr/share/scilab/modules/ui_data/jar/org.scilab.modules.ui_data.jar:/usr/share/scilab/modules/graph/jar/org.scilab.modules.graph.jar:/usr/share/scilab/modules/localization/jar/org.scilab.modules.localization.jar:/usr/share/scilab/modules/helptools/jar/scilab_ru_RU_help.jar:/usr/share/scilab/modules/helptools/jar/scilab_images.jar:/usr/share/scilab/modules/helptools/jar/scilab_en_US_help.jar:/usr/share/scilab/modules/helptools/jar/org.scilab.modules.helptools.jar:/usr/share/scilab/modules/history_browser/jar/org.scilab.modules.history_browser.jar:
 --add-modules=java.activation,java.xml.bind
Error occurred during initialization of boot layer
java.lang.module.FindException: Module java.xml.bind not found

and stops there.

Best,
C.

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

Kernel: Linux 4.19.1 (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 scilab depends on:
ii  scilab-cli   6.0.1-5
ii  scilab-full-bin  6.0.1-5

Versions of packages scilab recommends:
ii  scilab-doc  6.0.1-5

Versions of packages scilab suggests:
pn  scilab-doc-fr 
pn  scilab-doc-ja 
pn  scilab-doc-pt-br  

-- no debconf information

Bug#913600: [Ceph-maintainers] Bug#913600: ceph: bd-uninst on several architectures: libboost-context1.67-dev not available

[Emilio Pozuelo Monfort]

On 13/11/2018 08:24, Gaudenz Steinlin wrote:
> 
> Hi
> 
> Emilio Pozuelo Monfort  writes:
>> Your package can no longer be built on several architectures, as
>> libboost-context is not built everywhere. Possible solutions would be:
>> 1) Make that build-dep optional
> 
> I don't think that's possible. Or do you have any pointers how Ceph could be
> built without libboost-context?

There's a pull request here to make boost-context optional for this very same
reason: https://github.com/ceph/ceph/pull/15225

> The only option I see going in that direction is to use the embedded copy of
> Boost which ships with the Ceph sources. But I'd like to avoid that and I
> actually doubt this will build on these architectures if the Boost Debian
> package does not build.

Yeah that won't work, given ceph requires boost-context, which doesn't work on
some architectures.

>> 2) Look if that boost library can now be built on more architectures
> 
> Was the boost build disabled on these architectures? I was under the 
> impression
> that we are just missing builds for these and that they will eventually get
> done. My time resources to work on other packages are a bit limited. Do you 
> know
> why Boost is not built on these architectures?

boost in general builds on those architectures. It's only boost-context that is
disabled on some architectures where it doesn't work:

 libboost-context-dev deb libdevel optional
arch=any-i386,any-amd64,armel,armhf,arm64,mips,mipsel,powerpc,ppc64el

>> 3) Remove ceph from the affected architectures
> 
> If we can't get this fixed and all the other architectures build fine this is
> probably the easiest option. However sad...

Let's leave that as the last resort.

>> See the affected architectures at
>> https://buildd.debian.org/status/package.php?p=ceph 
> 
> I'm currently working on the build failures on mips, mipsel and armel.

Great!

Emilio

Bug#913552: firehol: Firehol upgrade 3.1.6+ds-4 to 3.1.6+ds-5 leaves firehol broken

[Cristian Ionescu-Idbohrn]

On Tue, 13 Nov 2018, Jerome BENOIT wrote:
> On 12/11/2018 22:42, Cristian Ionescu-Idbohrn wrote:
> > You don't happen to have that "move everything from /bin, /sbin, /lib 
> > to /usr/..." package installed?
> 
> Do know have the short name (or regular name) of this package ? 

I guess it's this I was referring to:

Package: usrmerge
Description-en: Convert the system to the merged /usr directories scheme


-- 
Cristian

Bug#913586: texlive-binaries 2018.20181104.49075-1 breaks context

[Norbert Preining]

On Tue, 13 Nov 2018, Hilmar Preuße wrote:
> Pregenerating ConTeXt MarkIV format. This may take some time...

Arg, indeed. Why didn't that happen here is a surprise to me, but now I
can reproduce it.

Thanks.

Norbert

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

Bug#913628: dnssec-trigger: segfault after updating package libnm-glib4

[Daniel Dupont]

Package: dnssec-trigger
Version: 0.13-6
Severity: normal

Dear Maintainer,


1. apt full-upgrade

/var/log/apt/history.log:

Start-Date: 2018-11-12  19:20:26
Commandline: apt full-upgrade
Upgrade: libnm-glib4:amd64 (1.6.2-3, 1.6.2-3+deb9u2), 
gir1.2-networkmanager-1.0:amd64 (1.6.2-3, 1.6.2-3+deb9u2), libseccomp2:amd64 
(2.3.1-2.1, 2.3.1-2.1+deb9u1), libcurl3:amd64 (7.52.1-5+deb9u7, 
7.52.1-5+deb9u8), gnupg-agent:amd64
 (2.1.18-8~deb9u2, 2.1.18-8~deb9u3), libxapian30:amd64 (1.4.3-2+deb9u1, 
1.4.3-2+deb9u2), unbound-host:amd64 (1.6.0-3+deb9u1, 1.6.0-3+deb9u2), 
libsystemd0:amd64 (232-25+deb9u4, 232-25+deb9u6), grub-common:amd64 
(2.02~beta3-5, 2.02~
beta3-5+deb9u1), libxcursor1:amd64 (1:1.1.14-1+deb9u1, 1:1.1.14-1+deb9u2), 
grub2-common:amd64 (2.02~beta3-5, 2.02~beta3-5+deb9u1), udev:amd64 
(232-25+deb9u4, 232-25+deb9u6), libnm0:amd64 (1.6.2-3, 1.6.2-3+deb9u2), 
grub-pc:amd64 (2
.02~beta3-5, 2.02~beta3-5+deb9u1), libx11-6:amd64 (2:1.6.4-3, 
2:1.6.4-3+deb9u1), libudev1:amd64 (232-25+deb9u4, 232-25+deb9u6), 
libnm-util2:amd64 (1.6.2-3, 1.6.2-3+deb9u2), grub-pc-bin:amd64 (2.02~beta3-5, 
2.02~beta3-5+deb9u1), li
bunbound2:amd64 (1.6.0-3+deb9u1, 1.6.0-3+deb9u2), libfuse2:amd64 
(2.9.7-1+deb9u1, 2.9.7-1+deb9u2), systemd-sysv:amd64 (232-25+deb9u4, 
232-25+deb9u6), unbound:amd64 (1.6.0-3+deb9u1, 1.6.0-3+deb9u2), gpgv:amd64 
(2.1.18-8~deb9u2, 2.1
.18-8~deb9u3), systemd:amd64 (232-25+deb9u4, 232-25+deb9u6), libx11-data:amd64 
(2:1.6.4-3, 2:1.6.4-3+deb9u1), firmware-misc-nonfree:amd64 (20161130-3, 
20161130-4), libgnutls30:amd64 (3.5.8-5+deb9u3, 3.5.8-5+deb9u4), gnupg:amd64 (2
.1.18-8~deb9u2, 2.1.18-8~deb9u3), linux-image-4.9.0-8-amd64:amd64 
(4.9.110-3+deb9u6, 4.9.130-2), curl:amd64 (7.52.1-5+deb9u7, 7.52.1-5+deb9u8), 
unbound-anchor:amd64 (1.6.0-3+deb9u1, 1.6.0-3+deb9u2), base-files:amd64 
(9.9+deb9u5, 9
.9+deb9u6), tzdata:amd64 (2018e-0+deb9u1, 2018g-0+deb9u1)
End-Date: 2018-11-12  19:21:43


2. dnssec-trigger- segfault

/var/log/syslog:

Nov 12 19:20:58 emt-g1 dnssec-triggerd: [8832] info: dnssec-trigger 0.13 stop
Nov 12 19:20:58 emt-g1 systemd[1]: Stopping Reconfigure local DNSSEC resolver 
on connectivity changes...
Nov 12 19:20:58 emt-g1 dnssec-trigger-[17431]: 
(libnm-glib/nm-object.c:179):constructor: code should not be reached
Nov 12 19:20:58 emt-g1 dnssec-trigger-script[17431]: 
/usr/lib/dnssec-trigger/dnssec-trigger-script:469: Warning: object NMClient 
0x563f70690100 finalized while still in-construction
Nov 12 19:20:58 emt-g1 dnssec-trigger-script[17431]:   self.client = 
NMClient.Client().new()
Nov 12 19:20:58 emt-g1 dnssec-trigger-script[17431]: 
/usr/lib/dnssec-trigger/dnssec-trigger-script:469: Warning: Custom constructor 
for class NMClient returned NULL (which is invalid). Please use GInitable 
instead.
Nov 12 19:20:58 emt-g1 dnssec-trigger-script[17431]:   self.client = 
NMClient.Client().new()
Nov 12 19:20:58 emt-g1 dnssec-trigger-script[17431]: 
/usr/lib/dnssec-trigger/dnssec-trigger-script:469: Warning: 
g_object_is_floating: assertion 'G_IS_OBJECT (object)' failed
Nov 12 19:20:58 emt-g1 dnssec-trigger-script[17431]:   self.client = 
NMClient.Client().new()
Nov 12 19:20:58 emt-g1 kernel: [2101277.920356] dnssec-trigger-[17431]: 
segfault at 8 ip 7f72f052be5a sp 7ffcff80a600 error 4 in 
_gi.x86_64-linux-gnu.so[7f72f0514000+45000]
Nov 12 19:20:58 emt-g1 systemd[1]: Stopped Reconfigure local DNSSEC resolver on 
connectivity changes.
Nov 12 19:20:58 emt-g1 systemd[1]: Stopping Unbound DNS server...
Nov 12 19:20:58 emt-g1 systemd[1]: Stopped Unbound DNS server.


3. Same problem even after reboot

/var/log/syslog:

Nov 12 19:51:52 emt-g1 dnssec-trigger-[683]: 
(libnm-glib/nm-object.c:179):constructor: code should not be reached
Nov 12 19:51:52 emt-g1 kernel: [   13.254624] dnssec-trigger-[683]: segfault at 
8 ip 7f5ca4680e5a sp 7ffc4d7bad50 error 4 in 
_gi.x86_64-linux-gnu.so[7f5ca4669000+45000]
Nov 12 19:51:52 emt-g1 dnssec-trigger-script[683]: 
/usr/lib/dnssec-trigger/dnssec-trigger-script:469: Warning: object NMClient 
0x5590806f7100 finalized while still in-construction
Nov 12 19:51:52 emt-g1 dnssec-trigger-script[683]:   self.client = 
NMClient.Client().new()
Nov 12 19:51:52 emt-g1 dnssec-trigger-script[683]: 
/usr/lib/dnssec-trigger/dnssec-trigger-script:469: Warning: Custom constructor 
for class NMClient returned NULL (which is invalid). Please use GInitable 
instead.
Nov 12 19:51:52 emt-g1 dnssec-trigger-script[683]:   self.client = 
NMClient.Client().new()
Nov 12 19:51:52 emt-g1 dnssec-trigger-script[683]: 
/usr/lib/dnssec-trigger/dnssec-trigger-script:469: Warning: 
g_object_is_floating: assertion 'G_IS_OBJECT (object)' failed
Nov 12 19:51:52 emt-g1 dnssec-trigger-script[683]:   self.client = 
NMClient.Client().new()
Nov 12 19:51:52 emt-g1 dnssec-trigger-[802]: 
(libnm-glib/nm-object.c:179):constructor: code should not be reached
Nov 12 19:51:52 emt-g1 dnssec-trigger-script[802]: 
/usr/lib/dnssec-trigger/dnssec-trigger-script:469: Warning: object NMClient 
0x565260123100 

Bug#913627: [pkg-uWSGI-devel] Bug#913627: Query: mountpoints and uwsgi 2.1

[Jonas Smedegaard]

Quoting Dean Hamstead (2018-11-13 09:15:19)
> I posted this here https://github.com/unbit/uwsgi/issues/1895 but 
> didnt get a response. I wonder if debian maintainers know whats 
> happening?
> 
> According to this documentation mountpoints will be available in uwsgi 
> 2.1 (see 
> https://uwsgi-docs.readthedocs.io/en/latest/SubscriptionServer.html)
> 
> The 2.1 milestone appears to have been met but there is no 2.1 tagged 
> release.
> 
> I am curious if this feature will find its way in to 2.0.x releases or 
> if 2.1 has a future?

Sorry, I have no special knowledge about uWSGI development.

My guess is that 2.1 is the development branch, and as such it won't 
ever get "released" but instead features from there will get 
cherry-picked into the 2.0 branch.

But that's just a guess...


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#909574: [Pkg-utopia-maintainers] Bug#909574: Bug#909574: firewalld: FirewallBackend=nftables breaks NAT networks in libvirt

[Ralf Jung]

Hi,

> To avoid yet another one, it would be awesome, if you Ralf or you Tomas,
> could raise this issue with the libvirt and docker maintainer and file a
> corresponding Debian bug report and tell me the bug numer
> I would then file a Debian bug against firewalld for switching the
> backend back to nftables, and block it with those other bug reports.

I reported this against libvirt as #913633.  I am not using docker+firewalld, so
I did not make a report there.

Kind regards,
Ralf

Bug#913633: libvirt-daemon: libvirt NAT firewall rules broken when firewalld runs (with FirewallBackend=nftables)

[Ralf Jung]

Package: libvirt-daemon
Version: 4.7.0-1+b1
Severity: normal
Tags: upstream

Dear Maintainer,

when both firewalld and libvirt are installed, libvirt guests using NAT do not
have internet access.  The problem is that libvirt is not compatible (yet) with
firewalld's new nftables backend.

Also see  and
.

Kind regards,
Ralf

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

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

Versions of packages libvirt-daemon depends on:
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.13.1-3+b1
ii  libaudit1   1:2.8.4-2
ii  libavahi-client30.7-4+b1
ii  libavahi-common30.7-4+b1
ii  libblkid1   2.32.1-0.1
ii  libc6   2.27-8
ii  libcap-ng0  0.7.9-1
ii  libcurl3-gnutls 7.61.0-1
ii  libdbus-1-3 1.12.10-1
ii  libdevmapper1.02.1  2:1.02.145-4.1
ii  libfuse22.9.8-2
ii  libgcc1 1:8.2.0-9
ii  libgnutls30 3.5.19-1+b1
ii  libnetcf1   1:0.2.8-1+b2
ii  libnl-3-200 3.4.0-1
ii  libnl-route-3-200   3.4.0-1
ii  libnuma12.0.12-1
ii  libparted2  3.2-23
ii  libpcap0.8  1.8.1-6
ii  libpciaccess0   0.14-1
ii  libsasl2-2  2.1.27~rc8-1
ii  libselinux1 2.8-1+b1
ii  libssh2-1   1.8.0-2
ii  libudev1239-11
ii  libvirt04.7.0-1+b1
ii  libxenmisc4.11  4.11.1~pre.20180911.5acdd26fdc+dfsg-5
ii  libxenstore3.0  4.11.1~pre.20180911.5acdd26fdc+dfsg-5
ii  libxentoollog1  4.11.1~pre.20180911.5acdd26fdc+dfsg-5
ii  libxml2 2.9.4+dfsg1-7+b1
ii  libyajl22.1.0-3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-7+b1
ii  netcat-openbsd  1.195-1
ii  qemu-kvm1:2.12+dfsg-3+b1

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster   
pn  libvirt-daemon-driver-storage-rbd   
pn  libvirt-daemon-driver-storage-sheepdog  
pn  libvirt-daemon-driver-storage-zfs   
ii  libvirt-daemon-system   4.7.0-1+b1
pn  numad   

-- no debconf information

Bug#913413: [PATCH] Map Shift+Win to Menu

[Łukasz Stelmach]

---
 rules/base.o_s.part |  3 +++
 rules/base.xml.in   | 18 ++
 symbols/altwin  | 18 ++
 3 files changed, 39 insertions(+)

Patch created against debian-unstable branch of 
https://salsa.debian.org/xorg-team/data/xkb-data.git

diff --git a/rules/base.o_s.part b/rules/base.o_s.part
index 505f094..1893ba6 100644
--- a/rules/base.o_s.part
+++ b/rules/base.o_s.part
@@ -10,6 +10,9 @@
   altwin:swap_lalt_lwin=   +altwin(swap_lalt_lwin)
   altwin:swap_alt_win  =   +altwin(swap_alt_win)
   altwin:prtsc_rwin=   +altwin(prtsc_rwin)
+  altwin:lwin_menu =   +altwin(lwin_menu)
+  altwin:rwin_menu =   +altwin(rwin_menu)
+  altwin:win_menu  =   +altwin(win_menu)
   grab:debug   =   +srvr_ctrl(grab_debug)
   grp:switch   =   +group(switch)
   grp:lswitch  =   +group(lswitch)
diff --git a/rules/base.xml.in b/rules/base.xml.in
index 3a3a9cd..531755c 100644
--- a/rules/base.xml.in
+++ b/rules/base.xml.in
@@ -6789,6 +6789,24 @@
   <_description>Win is mapped to PrtSc and the usual Win
 
   
+  
+
+  altwin:rwin_menu
+  <_description>Map Shift+Right Win to Menu
+
+  
+  
+
+  altwin:lwin_menu
+  <_description>Map Shift+Left Win to Menu
+
+  
+  
+
+  altwin:win_menu
+  <_description>Map Shift+Win (left and right) to Menu
+
+  
 
 
   
diff --git a/symbols/altwin b/symbols/altwin
index 7240ab8..587c215 100644
--- a/symbols/altwin
+++ b/symbols/altwin
@@ -114,3 +114,21 @@ xkb_symbols "prtsc_rwin" {
 replace key  { [ Super_R, Super_R ] };
 modifier_map Mod4 { ,  };
 };
+
+// Pressing the Shift+Win (left or right, respectively) acts as Menu
+// while Shift+Win acts as Menu.
+partial modifier_keys
+xkb_symbols "win_switch" {
+include "altwin(lwin_menu)"
+include "altwin(rwin_menu)"
+};
+
+partial modifier_keys
+xkb_symbols "rwin_menu" {
+key  { [ Super_R, Menu ] };
+};
+
+partial modifier_keys
+xkb_symbols "lwin_menu" {
+key  { [ Super_L, Menu ] };
+};
-- 
2.19.1

Bug#913413: +patch

[Łukasz Stelmach]

Control: tag -1 + patch

Bug#896911: fixed in linux 4.9.130-1

[Yanhui He]

 Hi Salvatore,

Debian 9.6.0 is released on Nov. 10th, 2018.

We tested E1000E on Debian 9.6.0, and it runs OK.

Thanks!
Yanhui

On Tue, 6 Nov 2018 10:53:50 +0800 Yanhui He  wrote:
> Hi Salvatore,
> 
> I used the following steps to verify E1000E network working on Debian 9.5.0, 
> but still failed.
> 
> ---Test Steps--
> # sed -i "s/^/#/g" /etc/apt/sources.list> Comment the other Debian 
> sources
> # echo “deb http://ftp.debian.org/debian  sid 
> main" >>/etc/apt/sources.list> Add the unstable source 
> # apt-get update
> # apt-get upgrade
> # vi /etc/network/interfaces   <———Add the following 2 lines, ens224 is a 
> e1000e network
> auto ens224
> iface ens224 inet dhcp
> # dhclient ens224
> # ifconfig
> ……
> ens224: flags=4099  mtu 1500
> ether 00:50:56:89:65:e8  txqueuelen 1000  (Ethernet)
> RX packets 0  bytes 0 (0.0 B)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 0  bytes 0 (0.0 B)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> device interrupt 16  memory 0xfd3a-fd3c  
> ……  
> 
> There is still no address allocating.
> 
> # uname -a
> Linux pek2-gosv-16-dhcp14 4.9.0-7-amd64 #1 SMP Debian 4.9.110-3+deb9u2 
> (2018-08-13) x86_64 GNU/Linux
> # ethtool -i ens224
> driver: e1000e
> version: 3.2.6-k
> firmware-version: 1.8-0
> expansion-rom-version: 
> bus-info: :13:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: no
> 
> Would you please tell me the reason?
> 
> Thanks!
> Yanhui
>  
> 
> On Fri, 12 Oct 2018 19:02:08 + Salvatore Bonaccorso  
> wrote:
> > Source: linux
> > Source-Version: 4.9.130-1
> > 
> > We believe that the bug you reported is fixed in the latest version of
> > linux, which is due to be installed in the Debian FTP archive.
> > 
> > A summary of the changes between this version and the previous one is
> > attached.
> > 
> > Thank you for reporting the bug, which will now be closed.  If you
> > have further comments please address them to 896...@bugs.debian.org,
> > and the maintainer will reopen the bug report if appropriate.
> > 

Bug#913632: connmand service segfaults on start after iwd-0.10 package upgrade

[Sergey Popov]

Package: connman
Version: 1.36-1
Severity: normal
Tags: patch

Dear Maintainer,

Since iwd-0.10-1 is now in sid and buster, connmand is no longer able to
start. The issue is already fixed in upstream 
(https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=bc97d6602f7991e8c36252dae15673fb0b250d00),
 but there's no release
yet. Probably the patch should be included in the debian package?

Here's an excerpt fron commnand startup log:

connmand[4694]: Connection Manager version 1.36
connmand[4694]: Checking loopback interface settings
connmand[4694]: System hostname is thinkpad
connmand[4694]: __connman_inet_get_pnp_nameservers: Cannot read /proc/net/pnp 
Failed to open file “/proc/net/pnp”: No such file or directory
connmand[4694]: lo {newlink} index 1 address 00:00:00:00:00:00 mtu 65536
connmand[4694]: lo {newlink} index 1 operstate 0 
connmand[4694]: enp0s31f6 {create} index 2 type 1 
connmand[4694]: enp0s31f6 {update} flags 4098 
connmand[4694]: enp0s31f6 {newlink} index 2 address 50:7B:9D:CC:93:32 mtu 1500
connmand[4694]: enp0s31f6 {newlink} index 2 operstate 2 
connmand[4694]: Adding interface enp0s31f6 [ ethernet ]
connmand[4694]: wlp3s0 {create} index 3 type 1 
connmand[4694]: wlp3s0 {RX} 12982 packets 11512328 bytes
connmand[4694]: wlp3s0 {TX} 7715 packets 1198041 bytes
connmand[4694]: wlp3s0 {update} flags 36866 
connmand[4694]: wlp3s0 {newlink} index 3 address 44:85:00:73:44:F7 mtu 1500
connmand[4694]: wlp3s0 {newlink} index 3 operstate 2 
connmand[4694]: Adding interface wlp3s0 [ wifi ]
connmand[4694]: docker0 {create} index 4 type 1 
connmand[4694]: docker0 {update} flags 36866 
connmand[4694]: docker0 {newlink} index 4 address 02:42:6D:BC:45:F8 mtu 1500
connmand[4694]: docker0 {newlink} index 4 operstate 2 
connmand[4694]: wlp3s0 {RX} 12982 packets 11512328 bytes
connmand[4694]: wlp3s0 {TX} 7715 packets 1198041 bytes
connmand[4694]: wlp3s0 {update} flags 36867 
connmand[4694]: wlp3s0 {newlink} index 3 address 44:85:00:73:44:F7 mtu 1500
connmand[4694]: wlp3s0 {newlink} index 3 operstate 2 
connmand[4694]: Aborting (signal 11) [/usr/sbin/connmand]
connmand[4694]:  backtrace 
connmand[4694]: #0  0x7efd7c3dbfc0 in /lib/x86_64-linux-gnu/libc.so.6
connmand[4694]: #1  0x556a4c101217 in /usr/sbin/connmand
connmand[4694]: #2  0x556a4c101773 in /usr/sbin/connmand
connmand[4694]: #3  0x556a4c1676df in /usr/sbin/connmand
connmand[4694]: #4  0x556a4c168ae8 in /usr/sbin/connmand
connmand[4694]: #5  0x7efd7c720ada in /lib/x86_64-linux-gnu/libdbus-1.so.3
connmand[4694]: #6  0x7efd7c724448 in /lib/x86_64-linux-gnu/libdbus-1.so.3
connmand[4694]: #7  0x556a4c162780 in /usr/sbin/connmand
connmand[4694]: #8  0x7efd7c7adae8 in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
connmand[4694]: #9  0x7efd7c7aded8 in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
connmand[4694]: #10 0x7efd7c7ae1d2 in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
connmand[4694]: #11 0x556a4c0e2868 in /usr/sbin/connmand
connmand[4694]: #12 0x7efd7c3c8b17 in /lib/x86_64-linux-gnu/libc.so.6
connmand[4694]: +++





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

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 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 connman depends on:
ii  dbus  1.12.10-1
ii  iptables  1.8.1-2
ii  libc6 2.27-8
ii  libdbus-1-3   1.12.10-1
ii  libglib2.0-0  2.58.1-2
ii  libgnutls30   3.5.19-1+b1
ii  libreadline7  7.0-5
ii  libxtables12  1.8.1-2
ii  lsb-base  9.20170808

Versions of packages connman recommends:
ii  bluez  5.50-1
ii  iwd0.10-1
ii  ofono  1.21-1
ii  wpasupplicant  2:2.6-18

Versions of packages connman suggests:
ii  connman-vpn  1.36-1

-- no debconf information

Bug#913620: Happened before in #905187

[Kunal Mehta]

This is the same regression as #905187 - is there a good way we can
prevent this from happening again?

HTH,
-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#913627: Query: mountpoints and uwsgi 2.1

[Dean Hamstead]

Source: uwsgi
Severity: wishlist

Dear Maintainer,

I posted this here https://github.com/unbit/uwsgi/issues/1895 but didnt
get a response. I wonder if debian maintainers know whats happening?

According to this documentation mountpoints will be available in uwsgi 2.1 (see 
https://uwsgi-docs.readthedocs.io/en/latest/SubscriptionServer.html)

The 2.1 milestone appears to have been met but there is no 2.1 tagged release.

I am curious if this feature will find its way in to 2.0.x releases or if 2.1 
has a future?

thanks


Dean


Psst! It's possible that this email contains information that is on the super 
secret side of confidential. So if you received it accidentally, let the sender 
know straight away and delete it (and the email you sent them). Also, we should 
let you know that any emails that come and go through Winc might be 
scanned, stored or read by Winc at its discretion. If you've got a 
question, please give us a buzz on +61 2 9335 0555 (Australia) or +64 9 271 
7600 (NZ). Oh, and Winc does its best to avoid errors on emails it 
sends, but we can't promise that it will be error free. So, please don't hold 
it against us.

Bug#913629: mpt-status only works on controller 0

[Giuseppe Sacco]

Package: mpt-status
Version: 1.2.0-8
Severity: normal

Hello,
if you have more than one SCSI controller, depending on the order they
are loaded at boot, the mpt-status does not work.

As an example, if the the machine with these controllers

agenzia-480:~# lspci | grep SCS
03:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068E PCI-Express 
Fusion-MPT SAS (rev 08)
07:08.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X 
Fusion-MPT Dual Ultra320 SCSI (rev c1)

load the drivers in this (problematic) order:

agenzia-480:~# cat /proc/mpt/summary 
ioc0: LSI53C1020A A1, FwRev=01032700h, Ports=1, MaxQ=255, IRQ=16
ioc1: LSISAS1068E B3, FwRev=00192f00h, Ports=1, MaxQ=266, IRQ=16

mpt-status does not work. See:

agenzia-480:~# mpt-status -u0 -p
Checking for SCSI ID:0
Checking for SCSI ID:1
Checking for SCSI ID:2
Checking for SCSI ID:3
Checking for SCSI ID:4
Checking for SCSI ID:5
Checking for SCSI ID:6
Checking for SCSI ID:7
Checking for SCSI ID:8
Checking for SCSI ID:9
Checking for SCSI ID:10
Checking for SCSI ID:11
Checking for SCSI ID:12
Checking for SCSI ID:13
Checking for SCSI ID:14
Checking for SCSI ID:15
Nothing found, contact the author
agenzia-480:~# mpt-status -u1 -p
Checking for SCSI ID:0
Checking for SCSI ID:1
Checking for SCSI ID:2
Checking for SCSI ID:3
Checking for SCSI ID:4
Checking for SCSI ID:5
Checking for SCSI ID:6
Checking for SCSI ID:7
Checking for SCSI ID:8
Checking for SCSI ID:9
Checking for SCSI ID:10
Checking for SCSI ID:11
Checking for SCSI ID:12
Checking for SCSI ID:13
Checking for SCSI ID:14
Checking for SCSI ID:15
Nothing found, contact the author

If you reboot the machine and the scsi drivers are loaded in the
reverse (correct?) order, i.e.:

agenzia-480:~#  cat /proc/mpt/summary
ioc0: LSISAS1068E B3, FwRev=00192f00h, Ports=1, MaxQ=266, IRQ=16
ioc1: LSI53C1020A A1, FwRev=01032700h, Ports=1, MaxQ=255, IRQ=16

the command work:

agenzia-480:~# mpt-status 
ioc0 vol_id 0 type IM, 2 phy, 278 GB, state OPTIMAL, flags ENABLED
ioc0 phy 1 scsi_id 8 SEAGATE  ST3300656SS  HS0A, 279 GB, state ONLINE, 
flags NONE
ioc0 phy 0 scsi_id 1 SEAGATE  ST3300656SS  HS0A, 279 GB, state ONLINE, 
flags NONE

Please note that I have no other parameters:

agenzia-480:~# LC_ALL=C cat /etc/default/mpt-statusd
cat: /etc/default/mpt-statusd: No such file or directory

This is on debian stretch 9.5, kernel 4.9.0-8-686, but the problem was
present even with debian 8 and debian 7.

Bye,
Giuseppe

P.S. the license file states that the source was downloaded from
https://www.drugphish.ch/~ratz/mpt-status/ , but it seems that this
page is not available.

Bug#913594: [apt-cacher-ng] Vcs-Git field lacks branch information

[Eduard Bloch]

reassign 913594 tracker.debian.org
thanks

Hallo,
* Jens Reyer [Mon, Nov 12 2018, 08:19:27PM]:
> Package: apt-cacher-ng
> Version: 3.2-1
> Severity: minor
> Tags: patch
> 
> Hi,
> 
> https://tracker.debian.org/pkg/apt-cacher-ng believes that the git repo
> is outdated, because it's looking at branch master instead of debian/sid.
> 
> To fix either adapt the salsa project, or debian/control.
> 
> Patch for the latter solution is attached.

Cannot confirm. Clicking "VCS: Git (Browse" leads to the correct branch.

And injecting git CLI parameters is not a solution, a bad kludge at best.

Reassigning to tracker - please teach the scanner to consider branches.

BR, Eduard.

Bug#904316: transition: boost-defaults

[Dimitri John Ledkov]

On Tue, 13 Nov 2018 at 10:40, Giovanni Mascellani  wrote:
>
> Dear pochu,
>
> Il 12/11/18 22:05, Emilio Pozuelo Monfort ha scritto:
> > The icu transition has started now. Can you make a boost1.67 upload
> > build-depending on the new icu, with a bumped shlibs, similar to [1] ? That 
> > will
> > break ceph from sid (which depends on boost1.67), so an appropriate breaks 
> > would
> > be good. However please don't just break all the old versions, as the 
> > package
> > from testing doesn't break (it uses boost1.62) and if you break that, then
> > boost1.67 won't migrate until ceph gets fixed (it currently is in a bad 
> > shape in
> > sid). A breaks on (= 12.2.8+dfsg1-1), (= 12.2.8+dfsg1-2) should do the 
> > trick.
>
> I do not really master shlibs and stuff yet, so I would like to have
> your confirmation the upload is correct:
>
>
> https://salsa.debian.org/debian/boost/commit/7962a7a35514e1351a9545613052f397d9549866
>
> BTW, I put the breakages on ceph-common, which is same-version depended
> by most of other ceph packages. However others, like librados2, are not
> covered. Also, package nheko too depends on libboost-regex1.67.0. Should
> that be broken as well?
>

librados2 -> it comes from ceph, and ceph-common is enough of an
anchor to cause an upgrade in unstable. And I expect ceph in unstable
to be rebuilt fairly quickly after this.

nheko -> yes needs a breaks, added.

> I am also fixing #912910[1] with the same upload, hope this is not
> getting in the middle. I will try a local build now.
>
>  [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912910
>

this looks ok too.

Test building locally too, and uploading.

-- 
Regards,

Dimitri.

Bug#913641: libreoffice-report-builder: report builder reports fail to run

[rene . engelhard]

tag 913641 - moreinfo
retitle 913641 libreoffice-report-builder: report builder reports fail to run 
after S8195874 in OpenJDK
thanks

Am 13. November 2018 13:13:09 MEZ schrieb Lionel Elie Mamane :
>On Tue, Nov 13, 2018 at 12:58:02PM +0100, rene.engelh...@mailbox.org
>wrote:
>> Am 13. November 2018 12:13:52 MEZ schrieb Lionel Elie Mamane
>:
>>> Package: libreoffice-report-builder
>>> Version: 1:6.1.3-1
>>> Severity: normal
>
>> Huh, what? On a stable? Seriousl
>
>Yes, I'm dogfooding more recent version of LibreOffice. Seriously,
>that's how one gets early testers and bug reports before release.

Use testing or sid. Or use the backport. Installing sid packages per se on 
stable is broken.

>>> Trying to run any report (a report builder one, not a legacy one)
>>> fails with error message:
>
>>> Can not activate the factory for
>>>
>org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory
>
>> I assume it's related to stables openjdk 8 update and the discussion
>> in https://gerrit.libreoffice.org/63118.
>
>Hmmm... Switching LibreOffice to use OpenJDK 7 solves that issue. I
>guess this confirms your assumption?

Yes.

>> Need to file a bug on openjdk...
>
>Not clear if you are saying I need to do it, or you need to do it. I
>don't quite understand the issue, you do, so I assume you will, you
>will be able to explain to the Java package maintainers the issue?

I will do, yes.

>Please CC me, I'd like to be educated on that.

The Gerrit discussion explains it..openjdk doesn't honour some classpath 
specifications anymore so stuff is simply not found.

>>> ii  openjdk-8-jre [java6-runtime]  8u181-b13-2~deb9u1
>
>> This is probably the cause What happens with the old openjdk 8 on
>> stretch or openjdk 11.0.1+13?
>
>Downgrading to 8u171-b11-2 makes this problem disappear.

Ok, that also confirms it...

Regards,

René

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#913646: quodlibet 4.2.0-1 refuses to start

[Klaumi Klingsporn]

Package: quodlibet
Version: 4.2.0-1
Severity: important

Dear Maintainer,

after todays upgrade to 4.2.0 i testing quodlibet doesn't start any more. I 
only get an 
error-window, where I can ignore the errror or end he program. In both cases 
quodlibet 
doesn't show up. The error message in this window is:

Error: g-dbus-error-quark: 
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method 
"GrabMediaPlayerKeys" with signature "su" on interface 
"org.mate.SettingsDaemon.MediaKeys" doesn't exist
--
Traceback (most recent call last):

  File "/usr/bin/quodlibet", line 15, in 
sys.exit(main())

  File "/usr/lib/python3/dist-packages/quodlibet/main.py", line 162, in main
mmkeys_handler.start()

  File "/usr/lib/python3/dist-packages/quodlibet/mmkeys/__init__.py", line 77, 
in start
self._backend.grab()

  File "/usr/lib/python3/dist-packages/quodlibet/mmkeys/gnome.py", line 72, in 
grab
iface.GrabMediaPlayerKeys('(su)', self.__name, self.__grab_time)

  File "/usr/lib/python3/dist-packages/gi/overrides/Gio.py", line 295, in 
__call__
None)

gi.repository.GLib.GError: g-dbus-error-quark: 
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method 
"GrabMediaPlayerKeys" with signature "su" on interface 
"org.mate.SettingsDaemon.MediaKeys" doesn't exist
 (19)

This makes the program unusable.

Klaumi


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

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE:de: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 quodlibet depends on:
ii  exfalso  4.2.0-1
ii  gir1.2-gst-plugins-base-1.0  1.14.4-1
ii  gir1.2-gstreamer-1.0 1.14.4-1
ii  gir1.2-keybinder-3.0 0.3.2-1
ii  gstreamer1.0-alsa1.14.4-1
ii  gstreamer1.0-plugins-base1.14.4-1
ii  gstreamer1.0-plugins-good1.14.4-1
ii  gstreamer1.0-plugins-ugly1.14.4-1
ii  gstreamer1.0-pulseaudio  1.14.4-1
ii  python3  3.6.7-1

Versions of packages quodlibet recommends:
ii  gir1.2-gtksource-3.03.24.9-1
ii  gir1.2-webkit2-4.0  2.22.3-1
ii  lxqt-notificationd [notification-daemon]0.13.0-1
ii  mate-notification-daemon [notification-daemon]  1.20.1-1
ii  notification-daemon 3.20.0-3
ii  plasma-workspace [notification-daemon]  4:5.13.5-1+b1
ii  python3-dbus1.2.8-2+b1
pn  python3-pyinotify   
ii  xfce4-notifyd [notification-daemon] 0.4.2-1

Versions of packages quodlibet suggests:
ii  gstreamer1.0-plugins-bad  1.14.4-1+b1

-- no debconf information

Bug#913639: unclutter: change upstream to unclutter-xfixes

[nfb]

Package: unclutter
Version: 8-21
Severity: wishlist

Dear Maintainer,

since unclutter seems very old (so old that it doesn't even have an
Homepage, but it must be referred to by a web.archive snapshot among
the other things), would you mind switching upstream location to
unclutter-xfixes[0] for an hopefully actively maintained alternative
which also seems to solve many known bugs with modern WMs?

By the way, this is a rewrite of the program, so maybe a new package
with a different name is more appropriate?

Thank you.

[0] https://github.com/Airblader/unclutter-xfixes

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

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

Versions of packages unclutter depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  libc6  2.27-8
ii  libx11-6   2:1.6.7-1

unclutter recommends no packages.

unclutter suggests no packages.

-- debconf information excluded

Bug#913234: shibboleth-sp2-utils: systemd service does not warn if certs not accessible as _shibd (like init.d did)

[Ferenc Wágner]

Andreas Ley  writes:

> Did not realize there now is a _shibd user that needs to access the
> keys since on jessie, shibd automatically runs as root in such a
> situation.
> [...]
> On stretch, there is a /lib/systemd/system/shibd.service which misses
> both the automatism and the warning.

Hi Andreas,

I can see the problem, but I'm not sure how to improve on this.  We
don't want to support running shibd as root, so we added the warning to
prod admins to migrate under jessie.  There was a NEWS entry as well.
Systemd can't really provide a fallback to root anyway.  Now we're
nearing the buster freeze already; I think the best thing to do would be
decoding the error codes so that the daemon prints human readable error
messages (for example "permission denied" in this case).  Would you find
that a valid fix?  However, this wouldn't help current stretch users
(who must have already solved this) nor future upgrades to buster.
Still, it would be a slight improvement upstream, I guess.
-- 
Regards,
Feri

Bug#913626: [R-pkg-team] Bug#913626: r-cran-stringi ftbfs with the new icu

[Graham Inggs]

Control: forwarded -1 https://github.com/gagolews/stringi/issues/334

Hi

I had a quick look at this.  The FTBFS only occurs on big-endian 
architectures, however on little-endian architectures r-cran=stringi is 
now built against the bundled icu61.


checking programmatically for U_CHARSET_IS_UTF8==0... no
*** The available ICU4C cannot be used

Configure finds that U_CHARSET_IS_UTF8 != 0 therefore tries to build 
with the bundled icu61.  However, there is no local copy of the 
big-endian data, only src/icu61/data/icudt61l.zip is present, and the 
build fails.


According to the upstream issue [1], ICU upstream defaults to building 
with U_CHARSET_IS_UTF8 on since version 61.


Regards
Graham


[1] https://github.com/gagolews/stringi/issues/314

Bug#913643: RM: netspeed -- RoM; RoQA; arch:all transitional NBS package

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-CC: gnome-appl...@packages.debian.org

gnome-applets added a transitional netspeed binary package.

The netspeed source package was removed from unstable with
https://bugs.debian.org/789584 and gnome-applets stopped building the
transitional netspeed binary in 3.22.0-3. Currently, arch:all package
removals need manual decrufting.

Please remove the arch:all netspeed binary package previously built by
gnome-applets.

Thanks,
Jeremy Bicha

Bug#913645: Upgrade to thunderbird 1:60.3.0-1~deb9u1 will purge user private keys if they are not stored in sqlite

[Bastian Neuburger]

Package: thunderbird
Version: 1:60.3.0-1~deb9u1

Two coworkers experienced the following problem on Debian Stretch after 
upgrading from 1:60.2.1-2~deb9u1 to 1:60.3.0-1~deb9u1:


After upgrading they no longer had their X509 certificate for signing 
and encryption listed in the "Your certificates" tab.


Running sqlite on their profiles' key4.db made it apparent that the 
nssPrivate table contained no entries whatsoever. Also key3.db contained 
no entries wrt to certificates and/or private keys.


I then restored a backup of their profiles from last week (before the 
upgrade) and I saw that this snapshot didn't contain the new sqlite 
versions of cert9.db and key4.db but only the Berkeley DB variants 
cert8.db and key3.db. Running strings on the restored key3.db I was able 
to see the CA that issued the certificate and the DN.


After starting thunderbird 1:60.3.0-1~deb9u1 with the restored profile 
key4.db was created again - and again empty - and the entry in key3.db 
vanished.


After restoring the profile once more and starting it with thunderbird 
1:60.2.1-2~deb9u1 the certificate was listed in the "Your certificates" 
tab and after unlocking it with the master password they could send 
signed e-mails again.


Another upgrade to 1:60.3.0-1 wiped the private key again. I suppose 
something goes horribly wrong when thunderbird tries to convert from 
Berkeley DB to sqlite.


For other users (including myself) who already had a key4.db in place 
this issue does not occur.


Even though the original thunderbird profiles were created probably on a 
Debian Wheezy icedove back in the day, I think this is a serious bug 
since it wipes private keys.


If you need any further information please let me know.

Kind regards,

Bastian

Bug#912853: transition: icu

[GCS]

On Mon, Nov 12, 2018 at 4:05 PM Emilio Pozuelo Monfort  wrote:
> On 11/11/2018 11:24, László Böszörményi (GCS) wrote:
> > On Sun, Nov 4, 2018 at 4:45 PM Laszlo Boszormenyi (GCS)  
> > wrote:
> >> I'd like to upload ICU 63.1 which was recently released for Buster.
> >  I still miss the last three packages rebuilt, but I don't expect any
> > problems with those.
> > First, my methodology was to build the related packages both on i386
> > and amd64 (32 and 64 bit) to detect all possible problems in advance.
> > If a package failed due to ICU, I've patched it. If the reason was not
> > clear, rebuilt the package for Sid to check that result as well.
> > The order of rebuilds was harfbuzz -> boost1.67 -> make boost-defaults
> > point to it, then all other packages.
> Please go ahead with this. I will ack the boost transition once this is built.
 Small update and a problem I might caused. ICU needs to be
bootstrapped via icu-le-hb. But the latter build depends on
src:harfbuzz which should have been binNMUed with the new ICU (63.1-3)
package version. The only package that can be affected over icu-le-hb
itself is openttd.
I've filed bugs for the ICU update request with the proposed patches.
Only sword is updated at the time of writing and it's own transition
with bibletime and xiphos said to be ongoing.
It is said that nodejs will upload its new major upstream release
which handles this ICU transition as soon as it's accepted from the
NEW queue and built fine for experimental.
The libkiwix maintainer also choose to use the new upstream release
for the transition, but it will need its zimlib build dependency
updated, which sits in the NEW queue as well.

Cheers,
Laszlo/GCS

Bug#913640: sword: apply upstream ICU 63 support

[Teus Benschop]

Source: sword
Severity: wishlist

Dear Maintainer,

See this link:

http://tracker.crosswire.org/browse/API-214

Upstream suggests that they've got
a good way of letting libsword work
with ICU 63.

Suggestion is to follow their implementation,
once a new upstream version is available.


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

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

Bug#912463: Tested upstream

[Neil Williams]

We've designed a new test job using a device which cannot support KVM
to test this support prior to the next release.

https://lkft-staging.validation.linaro.org/results/16009/0_dispatcher-unittests-stretch?sort=-result#table

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpb1zutWtD3W.pgp
Description: OpenPGP digital signature

Bug#913552: firehol: Firehol upgrade 3.1.6+ds-4 to 3.1.6+ds-5 leaves firehol broken

[Cristian Ionescu-Idbohrn]

On Tue, 13 Nov 2018, Russel Winder wrote:
> 
> > Try this:
> > 
> > https://snapshot.debian.org/binary/firehol/
> 
> Thanks for the pointer. I run Approx, so I have the history of 
> packages here anyway. The issue is whether I have to delve into it 
> for manual installation, or whether the Debian Sid package can be 
> rescinded. I suspect not, I think Debian is "the only direction is 
> forward" which is fair enough.

That's my experience.

> It sounds like usrmerge is becoming a Debian standard, so I might 
> try it on that one machine.

Heads up.  A move like that might break other packages too.

The other thing you might want to careful with is what I wrote in bug 
#912624:

> Repeating the upgrade process I found out that /etc/firehol/firehol.conf 
> is _forcebly_ overwritten.  So, that's one bug:
> 
>   Installing new version of config file /etc/firehol/firehol.conf ...
> 
> I'm asked if I want to keep /etc/default/firehol, though.


-- 
Cristian

Bug#911533: gandi-cli: missing dependencies for python3 setuptools and ipy

[Michele Orrù]

Package: gandi-cli
Followup-For: Bug #911533


Hi,

I am having a similar issue: this package is not properly installing all 
dependencies!
In fact, running the following on my debian testing:

mu@myrtle:~$ sudo apt install gandi-cli
[...]
Unpacking gandi-cli (1.2-1) ...
Setting up gandi-cli (1.2-1) ...
mu@myrtle:~$ gandi
Traceback (most recent call last):
  File "/usr/bin/gandi", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3112, 
in 
@_call_aside
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3096, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3125, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 578, in 
_build_master
ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 895, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 781, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'pyyaml' distribution was not found and 
is required by gandi.cli

one can see that at least the packages python3-ipy, python3-click, and 
python3-yaml are missing. 

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

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

Versions of packages gandi-cli depends on:
ii  python33.6.7-1
ii  python3-pkg-resources  40.5.0-1

gandi-cli recommends no packages.

gandi-cli suggests no packages.

Bug#913228: /usr/bin/sbuild-createchroot: consider running debootstrap with --no-merged-usr

[Michael Biebl]

On Thu, 8 Nov 2018 13:27:59 + Simon McVittie  wrote
> Depending on the level of testing done, number of bugs found and fixed,
> and level of adoption of merged /usr, we could assess whether to revert
> that change after buster is released.


I guess we will only ever start finding those bugs, if we actually build
stuff in a merged-/usr environment.
Given how far we are in the buster development cycle and seeing that the
freeze is not that far away, switching the buildds back to
non-merged-/usr seems like a conservative and reasonable approach.

As soon as buster+1 is open for development I would definitely revert
this change though for unstable, to find those bugs early. If we just
wait and see if bugs are found and fixed, we will be in the same
situation again, just a release cycle later.

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#913647: nasm: new upstream version 2.14 available

[Michael Prokop]

Package: nasm
Version: 2.13.03-2
Severity: wishlist

Hi,

nasm version 2.14 is available since 2018-11-07, reporting it here
to give it a change that we might see it in Debian/buster. :)

regards,
-mika-

Bug#784860: splat: New upstream version (1.4.2) Available

[Apostolos]

Package: splat
Version: 1.4.0-3+b1
Followup-For: Bug #784860

Dear Maintainer,

please consider updating SPLAT to version 1.4.2 as it resolve some nasty bugs.

I spent a couple of hours only to finally find that the image size written to
the header of Xastir-compatible
.ppm maps was a known bug and corrected in version 1.4.1.


Thank you in advance
Apostolos



-- System Information:
Debian Release: 9.6
  APT prefers stable
  APT policy: (650, 'stable'), (500, 'stable-updates'), (500, 
'proposed-updates'), (450, 'testing'), (400, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages splat depends on:
ii  gnuplot 5.0.5+dfsg1-6+deb9u1
ii  libbz2-1.0  1.0.6-8.1
ii  libc6   2.24-11+deb9u3
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libstdc++6  6.3.0-18+deb9u1
ii  zlib1g  1:1.2.8.dfsg-5

splat recommends no packages.

splat suggests no packages.

-- no debconf information

Bug#690750: Bug#912724: Broken links in developers-reference as published on the Debian's website

[Holger Wansing]

Hi,

Am Montag, 12. November 2018 schrieb Lev Lamberov:
> Вс 04 ноя 2018 @ 12:00 Holger Wansing :
> 
> > Proposal: maybe the easiest way to make all variants (view via debian.org
> > and opened locally) work correctly, would be to change it this way:
> >
> > "This page is also available in
> > https://www.debian.org/doc/devel-manuals#devref;>French, 
> > German, 
> > Italian, Russian, and Japanese."
> >
> > since the links on that page are fine and can be linked from everywhere
> > with one single static link.
> > Of course, there are still some corner cases which do not work (for 
> > example, 
> > when you have the packages installed locally, you cannot switch from the 
> > local english to the local german version via that links, and when you
> > have no internet connection, you also get an irritating situation), but 
> > most 
> > usecases should be fine, and it would be an improvement compared to the 
> > current situation, where all links do not work!
> >
> > Would fix #690750 and #912724.
> >
> > Comments?
> 
> In case one take a look into other documentation (togather with its
> translation), one will not find any such notes and links to
> translations. Maybe there's no need in such note in "Debian Developer's
> Reference"? Or at least no need in explicit links? What about to remove
> it completely or change text to something like "This documentation is
> also available in some other languages"?

Yes, I had also thought about that.
Another benefit would be, that we don't need to rephrase
the sentence, when new translations are added or outdated
onces removed.
But I still would like to make that a link, for usability.
 

Holger

-- 
Sent from my Jolla phone
http://www.jolla.com/

Bug#845715: Required targets must not write outside of the source package tree

[Ian Jackson]

Stuart Prescott writes ("Bug#845715: Required targets must not write outside of 
the source package tree"):
> Bill Allombert wrote:
> > +This restriction is intended to prevent source package builds creating
> > +and depending on state outside of themselves, thus affecting multiple
> > +independent rebuilds.  In particular, the required targets must not
> > +attempt to write into ``HOME``.
> 
> At the risk of letting perfect be the enemy of good, is it obvious following 
> this final remark about HOME that:

Thanks for your attention to detail :-), but:

Yes, I think it is.  "In particular" introduces a statement which is
clarifies the meaning of the general rule, and assists the reader, by
giving an example.  I don't think "in particular" can be correctly
used to extend (or except from) a general rule in the way required by
the misreadings you are concerned about.

   "All felines have four legs.  In particular, cats do."
 * "All felines have four legs.  In particular, dogs do." <- wrong

> It's reasonably common to redefine HOME within d/rules to make the
> build robust against a user's config files and/or to prevent
> unwanted config files being created.

Having said all that, I don't know if it would be worth explicitly
mentioning this very general and useful technique for the benefit of
readers who haven't osmosed or reinvented it.

Thanks,
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#913552: firehol: Firehol upgrade 3.1.6+ds-4 to 3.1.6+ds-5 leaves firehol broken

[Jerome BENOIT]

On 13/11/2018 16:23, Russel Winder wrote:
> 
>> It does not look as a solution anyway.
>> And the issue does not seem to be a FireHOL issue.
>> I guess that we have to stick to package 3.1.6+ds-4 for a while.
> 
> I've held all but one machine on 3.1.6+ds-4 but now need to revert the one
> test machine.  Aptitude is telling me there is only 3.1.6+ds-5. Can this
> version be removed from the repository and 3.1.6+ds-4 reinstated, or do I just
> have to manually grab the packages and install them?

It is a building environment issue: I would build the debian package from 
source,
and them install it.

I have just submitted the issue to the debian-devel debian list (I CCed to you).
As temporary solution, I can submit a package built from a local chroot 
environment.

Jerome


> 

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



signature.asc
Description: OpenPGP digital signature

Bug#913552: firehol: Firehol upgrade 3.1.6+ds-4 to 3.1.6+ds-5 leaves firehol broken

[Russel Winder]

Hi,

> Try this:
> 
>   https://snapshot.debian.org/binary/firehol/

Thanks for the pointer. I run Approx, so I have the history of packages here
anyway. The issue is whether I have to delve into it for manual installation,
or whether the Debian Sid package can be rescinded. I suspect not, I think
Debian is "the only direction is forward" which is fair enough.

It sounds like usrmerge is becoming a Debian standard, so I might try it on
that one machine.



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

Bug#913641: libreoffice-report-builder: report builder reports fail to run

[Lionel Elie Mamane]

On Tue, Nov 13, 2018 at 12:58:02PM +0100, rene.engelh...@mailbox.org wrote:
> Am 13. November 2018 12:13:52 MEZ schrieb Lionel Elie Mamane 
> :
>> Package: libreoffice-report-builder
>> Version: 1:6.1.3-1
>> Severity: normal

> Huh, what? On a stable? Seriousl

Yes, I'm dogfooding more recent version of LibreOffice. Seriously,
that's how one gets early testers and bug reports before release.

>> Trying to run any report (a report builder one, not a legacy one)
>> fails with error message:

>> Can not activate the factory for
>> org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory

> I assume it's related to stables openjdk 8 update and the discussion
> in https://gerrit.libreoffice.org/63118.

Hmmm... Switching LibreOffice to use OpenJDK 7 solves that issue. I
guess this confirms your assumption?

> Need to file a bug on openjdk...

Not clear if you are saying I need to do it, or you need to do it. I
don't quite understand the issue, you do, so I assume you will, you
will be able to explain to the Java package maintainers the issue?
Please CC me, I'd like to be educated on that.

> >-- System Information:
> >Debian Release: 9.6
> >  APT prefers stable-updates
> >APT policy: (600, 'stable-updates'), (600, 'stable'), (400, 'testing'),
> >(300, 'unstable'), (1, 'experimental')
> >Architecture: amd64 (x86_64)
> >Foreign Architectures: i386
> > [...]
> >Versions of packages libreoffice-report-builder depends on:
> >ii  libbase-java   1.1.6-2
> >ii  libcommons-logging-java1.2-1
> >ii  libflute-java  1:1.1.6-3
> >ii  libfonts-java  1.1.6.dfsg-3
> >ii  libformula-java1.1.7.dfsg-2
> >ii  liblayout-java 0.2.10-2
> >ii  libloader-java 1.1.6.dfsg-4
> >ii  libpentaho-reporting-flow-engine-java  0.9.4-4
> >ii  libreoffice-common 1:6.1.3-1
> >ii  libreoffice-core   1:6.1.3-1
> >ii  libreoffice-java-common1:6.1.3-1
> >ii  libreoffice-report-builder-bin 1:6.1.3-1
> >ii  librepository-java 1.1.6-3
> >ii  libsac-java1.3+dfsg-2
> >ii  libserializer-java 1.1.6-4
> >ii  libxml-java1.1.6.dfsg-3

> This honestly is Soo broken. Ok, the backport will have the same problem 
> (that's why I needed +2 there) but..

That's honestly not broken at all. That's why our packages have
dependencies, so that they can have what they require.

>> ii  openjdk-8-jre [java6-runtime]  8u181-b13-2~deb9u1

> This is probably the cause What happens with the old openjdk 8 on
> stretch or openjdk 11.0.1+13?

Downgrading to 8u171-b11-2 makes this problem disappear.

Bug#899108: Bug#884956: HiDPI scaling is still broken with libqt5core5a 5.10.1+dfsg-6

[Dmitry Shachnev]

Hi Vincent and all!

On Sun, May 06, 2018 at 11:09:09AM +0200, Vincent Lefevre wrote:
> Control: reopen -1
> Control: found -1 5.10.1+dfsg-6
>
> The bug is still there. The upgrade of the qtbase-opensource-src
> packages to 5.10.1+dfsg-6 had no effect.

Can you please check if this is still an issue with qtbase 5.11.2+dfsg-4?

There have been some upstream changes in 5.11.x, plus I have backported
this commit [1] which may make things better.

[1]: https://code.qt.io/cgit/qt/qtbase.git/commit/?id=5e6bbbc1b86905c4

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#913077: closed by Debian FTP Masters (Bug#913077: Removed package(s) from unstable)

[Iain Lane]

Control: reopen -1

On Thu, Nov 08, 2018 at 06:36:06AM +, Debian Bug Tracking System wrote:
>   gdm3 |   3.30.1-1 | s390x

I think we missed some of gdm3's binaries here (thanks jcristau)

laney@nightingale> rmadison -u debian -S -s unstable -a s390x gdm3  

  ~
gir1.2-gdm-1.0 | 3.30.1-1  | unstable   | s390x
libgdm-dev | 3.30.1-1  | unstable   | s390x
libgdm1| 3.30.1-1  | unstable   | s390x

Could those be removed too, please?

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature

Bug#913644: /usr/bin/plasmashell: crash on startup

[Arthur Marsh]

Package: plasma-workspace
Version: 4:5.13.5-1+b1
Severity: important
File: /usr/bin/plasmashell

Dear Maintainer,

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

   * What led up to the situation?

Upgrading packages that plasmashell depended on.

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

Downgrading the packages.

   * What was the outcome of this action?
   * What outcome did you expect instead?

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

Output from when attempting to run plasmashell now:

$ plasmashell
Invalid Context= "places" line for icon theme:  
"/usr/share/icons/DarkPurpy/48x48/places/"
org.kde.plasmaquick: Applet preload policy set to 1
Empty filename passed to function
last screen is < 0 so putting containment on screen  0
KCrash: Attempting to start /usr/bin/plasmashell from kdeinit
sock_file=/run/user/1000/kdeinit5__0
Warning: connect() failed: : No such file or directory
KCrash: Attempting to start /usr/bin/plasmashell directly
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = plasmashell path = /usr/bin pid = 21165
KCrash: Arguments: /usr/bin/plasmashell 
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi from 
kdeinit
sock_file=/run/user/1000/kdeinit5__0
Warning: connect() failed: : No such file or directory
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi directly
QSocketNotifier: Invalid socket 11 and type 'Read', disabling...
QSocketNotifier: Invalid socket 14 and type 'Read', disabling...
QSocketNotifier: Invalid socket 13 and type 'Read', disabling...
"Message recipient disconnected from message bus without replying"
QSystemTrayIcon::setVisible: No Icon set

[1]+  Stopped plasmashell


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

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

Versions of packages plasma-workspace depends on:
ii  dbus-x11 [dbus-session-bus]  1.12.10-1+devuan1
ii  drkonqi  5.13.4-1
ii  frameworkintegration 5.51.0-1
ii  gdb  8.1-4+b1
ii  iso-codes4.1-1
ii  kactivitymanagerd5.13.5-1
ii  kded55.51.0-1
ii  kinit5.51.0-1
ii  kio  5.51.0-1
ii  kpackagetool55.51.0-1
ii  kwin-common  4:5.13.5-1+b1
ii  libappstreamqt2  0.12.3-1
ii  libc62.27-8
ii  libcln6  1.3.4-4
ii  libcolorcorrect5 4:5.13.5-1+b1
ii  libgcc1  1:8.2.0-9
ii  libgps23 3.17-5+b1
ii  libice6  2:1.0.9-2
ii  libkf5activities55.51.0-1
ii  libkf5auth5  5.51.0-1
ii  libkf5baloo5 5.51.0-1
ii  libkf5bookmarks5 5.51.0-1
ii  libkf5calendarevents55.51.0-1
ii  libkf5completion55.51.0-1
ii  libkf5config-bin 5.51.0-1
ii  libkf5configcore55.51.0-1
ii  libkf5configgui5 5.51.0-1
ii  libkf5configwidgets5 5.51.0-1
ii  libkf5coreaddons55.51.0-1
ii  libkf5crash5 5.51.0-1
ii  libkf5dbusaddons55.51.0-1
ii  libkf5declarative5   5.51.0-1
ii  libkf5globalaccel-bin5.51.0-1
ii  libkf5globalaccel5   5.51.0-1
ii  libkf5guiaddons5 5.51.0-1
ii  libkf5holidays5  1:5.51.0-1
ii  libkf5i18n5  5.51.0-1
ii  libkf5iconthemes55.51.0-1
ii  libkf5idletime5  5.51.0-1
ii  libkf5itemviews5 5.51.0-1
ii  libkf5jobwidgets55.51.0-1
ii  libkf5js55.51.0-1
ii  libkf5jsembed5   5.51.0-1
ii  libkf5kdelibs4support5   5.51.0-1
ii  libkf5kiocore5   5.51.0-1
ii  libkf5kiofilewidgets55.51.0-1
ii  libkf5kiogui55.51.0-1
ii  libkf5kiowidgets55.51.0-1
ii  libkf5networkmanagerqt6  5.51.0-1
ii  libkf5newstuff5  5.51.0-1
ii  libkf5notifications5 5.51.0-1

Bug#913614: gnupg2 fails with "cannot open '/dev/tty': No such device or address"

[Bernhard Schmidt]

Hi,

confirmed, I see this as well after the point release.

Passing "--no-tty" to gpg works around this issue.

Bernhard

Bug#913638: Please, Depends: info-browser | info

[Barak A. Pearlmutter]

Package: octave-doc:
Version: 4.4.1-2

The octave-doc "Depends: info" have an "| info-browser", which is
provided by info but also by GNU Emacs.

Bug#897623: fortunate.app

[Gürkan Myczko]

Hi Yavor

Can you confirm this update is right?

http://phd-sid.ethz.ch/debian/fortunate.app/fortunate.app_3.1-2.dsc

maybe also add the vcs fields and the repo to salsa.d.o?

Bug#913641: libreoffice-report-builder: report builder reports fail to run

[Lionel Elie Mamane]

Package: libreoffice-report-builder
Version: 1:6.1.3-1
Severity: normal

Trying to run any report (a report builder one, not a legacy one)
fails with error message:

Can not activate the factory for
org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory

Nothing particular on stderr.

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (600, 'stable-updates'), (600, 'stable'), (400, 'testing'), (300, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libreoffice-report-builder depends on:
ii  libbase-java   1.1.6-2
ii  libcommons-logging-java1.2-1
ii  libflute-java  1:1.1.6-3
ii  libfonts-java  1.1.6.dfsg-3
ii  libformula-java1.1.7.dfsg-2
ii  liblayout-java 0.2.10-2
ii  libloader-java 1.1.6.dfsg-4
ii  libpentaho-reporting-flow-engine-java  0.9.4-4
ii  libreoffice-common 1:6.1.3-1
ii  libreoffice-core   1:6.1.3-1
ii  libreoffice-java-common1:6.1.3-1
ii  libreoffice-report-builder-bin 1:6.1.3-1
ii  librepository-java 1.1.6-3
ii  libsac-java1.3+dfsg-2
ii  libserializer-java 1.1.6-4
ii  libxml-java1.1.6.dfsg-3

libreoffice-report-builder recommends no packages.

libreoffice-report-builder suggests no packages.

Versions of packages libreoffice-base depends on:
ii  libc6 2.27-8
ii  libgcc1   1:8.2.0-9
ii  libreoffice-base-core 1:6.1.3-1
ii  libreoffice-base-drivers  1:6.1.3-1
ii  libreoffice-core  1:6.1.3-1
ii  libstdc++68.2.0-9
ii  uno-libs3 6.1.3-1
ii  ure   6.1.3-1

Versions of packages libreoffice-base recommends:
ii  default-jre [java6-runtime]2:1.8-58
ii  libreoffice-java-common1:6.1.3-1
ii  libreoffice-writer 1:6.1.3-1
ii  openjdk-7-jre [java6-runtime]  7u151-2.6.11-3
ii  openjdk-8-jre [java6-runtime]  8u181-b13-2~deb9u1

Versions of packages libreoffice-base suggests:
ii  unixodbc  2.3.4-1

-- no debconf information

Bug#913552: firehol: Firehol upgrade 3.1.6+ds-4 to 3.1.6+ds-5 leaves firehol broken

[Jerome BENOIT]

On 13/11/2018 12:24, Russel Winder wrote:
> 
>> Package: usrmerge
>> Description-en: Convert the system to the merged /usr directories scheme
> 
> That seems like the beastie, and it is a once and for all time thing it seems.
> I have not installed this. At least not as yet. I am hesitant to do this as it
> is clearly not Debian Sid standard and it is not reversible.
> 
> 

It does not look as a solution anyway.
And the issue does not seem to be a FireHOL issue.
I guess that we have to stick to package 3.1.6+ds-4 for a while.

Jerome


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



signature.asc
Description: OpenPGP digital signature

Bug#913586: texlive-binaries 2018.20181104.49075-1 breaks context

[Thanasis Kinias]

Hi Norbert,

Sorry about my last e-mail; I sent it before I saw your latest.

—TK


On Tue, 13 Nov 2018 at 03:08, Norbert Preining  wrote:

> On Tue, 13 Nov 2018, Hilmar Preuße wrote:
> > Pregenerating ConTeXt MarkIV format. This may take some time...
>
> Arg, indeed. Why didn't that happen here is a surprise to me, but now I
> can reproduce it.
>
> Thanks.
>
> Norbert
>
> --
> PREINING Norbert   http://www.preining.info
> Accelia Inc. +JAIST +TeX Live +Debian Developer
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
>


-- 
Thanasis Kinias
Instructor & Doctoral Candidate, Department of History, Northeastern
University
kinia...@husky.neu.edu

Bug#913641: libreoffice-report-builder: report builder reports fail to run

[rene . engelhard]

notfound 913641 1:6.1.3-1
found 1:5.2.7-1+deb9u4
severity 913641 grave
tag 913641 + moreinfo
thanks

Am 13. November 2018 12:13:52 MEZ schrieb Lionel Elie Mamane :
>Package: libreoffice-report-builder
>Version: 1:6.1.3-1
>Severity: normal

Huh, what? On a stable? Seriousl

>Trying to run any report (a report builder one, not a legacy one)
>fails with error message:
>
>Can not activate the factory for
>org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory
>
>Nothing particular on stderr.

I assume it's related to stables openjdk 8 update and the discussion in 
https://gerrit.libreoffice.org/63118.

Doesn't affect sid or buster with jdk 11 (which is default there.. )

Need to file a bug on openjdk...

>-- System Information:
>Debian Release: 9.6
>  APT prefers stable-updates
>APT policy: (600, 'stable-updates'), (600, 'stable'), (400, 'testing'),
>(300, 'unstable'), (1, 'experimental')
>Architecture: amd64 (x86_64)
>Foreign Architectures: i386
> [...]
>Versions of packages libreoffice-report-builder depends on:
>ii  libbase-java   1.1.6-2
>ii  libcommons-logging-java1.2-1
>ii  libflute-java  1:1.1.6-3
>ii  libfonts-java  1.1.6.dfsg-3
>ii  libformula-java1.1.7.dfsg-2
>ii  liblayout-java 0.2.10-2
>ii  libloader-java 1.1.6.dfsg-4
>ii  libpentaho-reporting-flow-engine-java  0.9.4-4
>ii  libreoffice-common 1:6.1.3-1
>ii  libreoffice-core   1:6.1.3-1
>ii  libreoffice-java-common1:6.1.3-1
>ii  libreoffice-report-builder-bin 1:6.1.3-1
>ii  librepository-java 1.1.6-3
>ii  libsac-java1.3+dfsg-2
>ii  libserializer-java 1.1.6-4
>ii  libxml-java1.1.6.dfsg-3

This honestly is Soo broken. Ok, the backport will have the same problem 
(that's why I needed +2 there) but..

>ii  openjdk-8-jre [java6-runtime]  8u181-b13-2~deb9u1

This is probably the cause What happens with the old openjdk 8 on stretch or 
openjdk 11.0.1+13?

Regards

Rene

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#913586: texlive-binaries 2018.20181104.49075-1 breaks context

[Thanasis Kinias]

Hi Norbert,

The packages currently will not install at all, because APT hangs during
the format-building part of the installation process.  (See discussion with
Hilmar from yesterday.)

Best,
Thanasis

On Mon, 12 Nov 2018 at 21:22, Norbert Preining  wrote:

> Hi,
>
> I cannot reproduce this.
>
> Can you please run on the command line as root!
>
> mtxrun --generate
>
> That should rebuild the ConTeXt MarkIV format. It does work here.
>
> Thanks
>
> Norbert
>
> --
> PREINING Norbert   http://www.preining.info
> Accelia Inc. +JAIST +TeX Live +Debian Developer
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
>


-- 
Thanasis Kinias
Instructor & Doctoral Candidate, Department of History, Northeastern
University
kinia...@husky.neu.edu

Bug#913552: firehol: Firehol upgrade 3.1.6+ds-4 to 3.1.6+ds-5 leaves firehol broken

[Russel Winder]

> It does not look as a solution anyway.
> And the issue does not seem to be a FireHOL issue.
> I guess that we have to stick to package 3.1.6+ds-4 for a while.

I've held all but one machine on 3.1.6+ds-4 but now need to revert the one
test machine.  Aptitude is telling me there is only 3.1.6+ds-5. Can this
version be removed from the repository and 3.1.6+ds-4 reinstated, or do I just
have to manually grab the packages and install them? 



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

Bug#913594: [apt-cacher-ng] Vcs-Git field lacks branch information

[James McCoy]

Control: reassign -1 apt-cacher-ng 3.2-1

On Tue, Nov 13, 2018 at 12:42:59PM +0100, Eduard Bloch wrote:
> Hallo,
> * Jens Reyer [Mon, Nov 12 2018, 08:19:27PM]:
> > https://tracker.debian.org/pkg/apt-cacher-ng believes that the git repo
> > is outdated, because it's looking at branch master instead of debian/sid.
> > 
> > To fix either adapt the salsa project, or debian/control.
> > 
> > Patch for the latter solution is attached.
> 
> Cannot confirm. Clicking "VCS: Git (Browse" leads to the correct branch.

That's because Vcs-Browse in debian/control points to the debian/sid
branch.  Vcs-Git does not.

Either the repo on Salsa should be configured to make debian/sid the
default branch, in which case Vcs-Browse can lose the branch
information, or Vcs-Git should use "-b debian/sid" as documented in
policy[0] and supported by the tools that understand Vcs-*.

[0]: 
https://www.debian.org/doc/debian-policy/ch-controlfields.html#version-control-system-vcs-fields

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#910512: pulseaudio: Pulseaudio takes longer to start than default systemd timeout

[Felipe Sateler]

On Sat, Nov 10, 2018 at 5:39 AM Mr riaas mokiem  wrote:

> > If you issue a `systemctl --user restart pulseaudio`, does it take a
> long time too?
> This is how I originally verified that it took too long. I don't remember
> exactly whether I tried this "restart" specifically or whether I just used
> "stop" and then "start" but my best guess is that i tried it both ways. I
> don't think it matters though as it should be pretty much equivalent. And
> of course, I also verified that it took a long time during boot too.
>

Hmm. This is very strange. Could you get the logs of rtkit.service?

-- 

Saludos,
Felipe Sateler

Bug#913552: firehol: Firehol upgrade 3.1.6+ds-4 to 3.1.6+ds-5 leaves firehol broken

[Cristian Ionescu-Idbohrn]

On Tue, 13 Nov 2018, Russel Winder wrote:
> 
> > It does not look as a solution anyway.
> > And the issue does not seem to be a FireHOL issue.
> > I guess that we have to stick to package 3.1.6+ds-4 for a while.
> 
> I've held all but one machine on 3.1.6+ds-4 but now need to revert 
> the one test machine.  Aptitude is telling me there is only 
> 3.1.6+ds-5. Can this version be removed from the repository and 
> 3.1.6+ds-4 reinstated, or do I just have to manually grab the 
> packages and install them?

Try this:

https://snapshot.debian.org/binary/firehol/


-- 
Cristian

Bug#904316: transition: boost-defaults

[Giovanni Mascellani]

Dear pochu,

Il 12/11/18 22:05, Emilio Pozuelo Monfort ha scritto:
> The icu transition has started now. Can you make a boost1.67 upload
> build-depending on the new icu, with a bumped shlibs, similar to [1] ? That 
> will
> break ceph from sid (which depends on boost1.67), so an appropriate breaks 
> would
> be good. However please don't just break all the old versions, as the package
> from testing doesn't break (it uses boost1.62) and if you break that, then
> boost1.67 won't migrate until ceph gets fixed (it currently is in a bad shape 
> in
> sid). A breaks on (= 12.2.8+dfsg1-1), (= 12.2.8+dfsg1-2) should do the trick.

I do not really master shlibs and stuff yet, so I would like to have
your confirmation the upload is correct:


https://salsa.debian.org/debian/boost/commit/7962a7a35514e1351a9545613052f397d9549866

BTW, I put the breakages on ceph-common, which is same-version depended
by most of other ceph packages. However others, like librados2, are not
covered. Also, package nheko too depends on libboost-regex1.67.0. Should
that be broken as well?

I am also fixing #912910[1] with the same upload, hope this is not
getting in the middle. I will try a local build now.

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

Thanks, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#913637: /usr/bin/prefix: won't work if built on a merged-/usr system and used on an unmerged-/usr system

[Simon McVittie]

Source: libapp-options-perl
Version: 1.12-2
Severity: important
User: m...@linux.it
Usertags: usrmerge

libapp-options-perl appears to have a build bug that can be reproduced
as follows (I haven't actually tested this myself, I'm basing this on
reproducible-builds logs):

* Have two systems/chroots/containers, one with merged /usr (/bin is a
  symlink to /usr/bin) and one without
* Build libapp-options-perl on the first system
* Install it on the second system and use /usr/bin/prefix

Expected result:

* prefix is a #!/bin/bash script and works correctly

Actual result:

* prefix is a #!/usr/bin/bash script and won't start on non-merged-/usr
  systems

Broader context: I recently added a new point of variation (#901473)
to Debian's reproducible builds infrastructure: the first build is done
in a traditional Debian system with separate /bin and /usr/bin, while
the second is done with merged /usr (/bin is a symbolic link to /usr/bin).
This was done to detect bugs similar to #913226 in quilt.

libapp-options-perl appears to have the class
of bug that this was meant to detect.  If you look at
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libapp-options-perl.html
you'll see that in the first build, /usr/bin/prefix has

#!/bin/bash

whereas in the second, /usr/bin/prefix has

#!/usr/bin/bash

an interpreter that doesn't exist on non-merged-/usr systems.

I don't know what part of the build rewrites that first line or how to
fix it. Please reassign this bug if it's really a bug in generic Perl
build infrastructure.

Mitigation: if you do source-only uploads, the older debootstrap currently
in use on buildds will create non-merged-/usr schroot tarballs, so users
will not currently experience this bug. (However, if stretch-backports'
debootstrap is brought up to date with buster and deployed to buildds
without first applying #913228, that mitigation will go away.)

smcv

Bug#913627: [pkg-uWSGI-devel] Bug#913627: Query: mountpoints and uwsgi 2.1

[Dean Hamstead]

Ok thanks for a quick response.

The absence of much response in their GH bugs makes me wonder if unbit 
people are looking or not


Some PR seem to be actioned but thats about it


On Tue, 13 Nov 2018 10:40:04 +0100 Jonas Smedegaard  wrote:

> Quoting Dean Hamstead (2018-11-13 09:15:19)
> > I posted this here https://github.com/unbit/uwsgi/issues/1895 but
> > didnt get a response. I wonder if debian maintainers know whats
> > happening?
> >
> > According to this documentation mountpoints will be available in uwsgi
> > 2.1 (see
> > https://uwsgi-docs.readthedocs.io/en/latest/SubscriptionServer.html)
> >
> > The 2.1 milestone appears to have been met but there is no 2.1 tagged
> > release.
> >
> > I am curious if this feature will find its way in to 2.0.x releases or
> > if 2.1 has a future?
>
> Sorry, I have no special knowledge about uWSGI development.
>
> My guess is that 2.1 is the development branch, and as such it won't
> ever get "released" but instead features from there will get
> cherry-picked into the 2.0 branch.
>
> But that's just a guess...
>
>
> - Jonas
>
> --
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136 Website: http://dr.jones.dk/
>
> [x] quote me freely [ ] ask before reusing [ ] keep private

Bug#913234: shibboleth-sp2-utils: systemd service does not warn if certs not accessible as _shibd (like init.d did)

[Andreas Ley]

> I can see the problem, but I'm not sure how to improve on this.  We
> don't want to support running shibd as root, so we added the warning to

I'm totally with you here!

> prod admins to migrate under jessie.

It seems you didn't use a big enough cattle prod here ;-) Without the
explicit systemd service, it still runs seamlessly as root...

> There was a NEWS entry as well.

I had something in mind like the warning mails I get for behaviour changes
from unattended upgrades... Since I don't do dist-upgrades, but clean
re-installs to get rid of no-longer-needed stuff on my servers, it seems
I have to improve my reading and include all the NEWS* files for all the
packages...

> Systemd can't really provide a fallback to root anyway.  Now we're
> nearing the buster freeze already; I think the best thing to do would be
> decoding the error codes so that the daemon prints human readable error
> messages (for example "permission denied" in this case).  Would you find
> that a valid fix?  However, this wouldn't help current stretch users
> (who must have already solved this) nor future upgrades to buster.
> Still, it would be a slight improvement upstream, I guess.

Yes, this might help - and now that I'm better aware of the NEWS* files,
perhaps an entry in a shibboleth-sp2-utils (where _this_ change really
happend) NEWS file, like, "now we have a systemd service, now you not
only SHOULD change to _shibd, now you MUST" or anything more prominent.

You're right, you did document the change, and it's the ignorant admins
out there that have a problem, so everything should be fine, but now that
you know of these admins, perhaps you stumble upon a bigger prod - if not,
ok, it's us admins that have to learn the hard way ;-)

Thanks for your time, for the work that you put in these packages and for
dealing with people like me :)

Bye, Andy

-- 
Andreas Ley, SCC, Karlsruhe Institute of Technology (KIT), D-76128 Karlsruhe
E-Mail: andreas@kit.edu, Telephone: +49 721 608 46341, Fax: +49 721 32550
"It's 106 ms to Chicago, we've got a full disk of GIFs, half a meg of hypertext,
it's dark, and we're wearing sunglasses."  "Click it." -- Christopher Davis

Bug#913636: context.postinstall "luatools --make cont-en" hangs, "attempt to call upvalue 'isfile' (a nil value)"

[Hilmar Preuße]

block 913636 by 913586
stop

Am 13.11.2018 um 11:20 teilte Jonathon Fernyhough mit:

Hi,


Dear Maintainer,

When installing context with texlive-binaries=2018.20181104.49075-1 the
context.postinst task `luatools --make cont-en` fails to complete correctly
making package installation hang indefinitely:

$ luatools --make cont-en

Seems an incompatible change in luatex caused the problem (see #913586). 
I mark #913636 as blocked by #913586. I tend not to merge them as I'm 
afraid other people would again blame context although the fault is in 
luatex.


Hilmar
--
#206401 http://counter.li.org

Bug#913631: FTBFS: libapache2-mod-auth-openidc on multiple arches

[Frédéric Bonnard]

Package: src:libapache2-mod-auth-openidc
Version: 2.3.8-1
Control: tags -1 patch pending ftbfs

--

Hi,

libapache2-mod-auth-openidc fails to build on amd64, ppc64el and a
number of unofficial arches. I think this is due to the parallel build.
Here is a patch that I tested successfully :

https://salsa.debian.org/debian/libapache2-mod-auth-openidc/merge_requests/1

Regards,


F.


pgpX8kMZT7yZV.pgp
Description: PGP signature

Bug#913634: osmo-iuh not ready for big endian archs

[Matthias Klose]

Package: src:osmo-iuh
Version: 0.3.0-4

looks like osmo-iuh is not ready for big endian archs, the output for failing
tests smells like that:

dh_auto_test: make -j2 check VERBOSE=1 returned exit code 2
# -*- compilation -*-
3. testsuite.at:18: testing ranap ...
./testsuite.at:21: $abs_top_builddir/src/tests/test-ranap
--- expout  2018-11-06 00:09:22.971710673 +
+++ /<>/src/tests/testsuite.dir/at-groups/3/stdout 2018-11-06
00:09:22.979710673 +
@@ -172,12 +172,12 @@
 
 15
 
-00 09 01 99 42 23
+00 09 01 99 23 42
 
 
 58
 
-00 09 01 99 42 23 42 23
+00 09 01 99 23 42 23 42
 
 
 16
@@ -194,7 +194,7 @@
 
 09 01 99 09 26
 
-00 13 00 36 00 00 06 00 03 40 01 00 00 0f 40 06 00 09 01 99 42 23 00 3a 40 08
00 09 01 99 42 23 42 23 00 10 40 04 03 aa bb cc 00 4f 40 03 00 00 17 00 56 40 05
09 01 99 09 26
+00 13 00 36 00 00 06 00 03 40 01 00 00 0f 40 06 00 09 01 99 23 42 00 3a 40 08
00 09 01 99 23 42 23 42 00 10 40 04 03 aa bb cc 00 4f 40 03 00 00 17 00 56 40 05
09 01 99 09 26

 ==> IU RELEASE REQ
 
3. testsuite.at:18: 3. ranap (testsuite.at:18): FAILED (testsuite.at:21)
# -*- compilation -*-
1. testsuite.at:5: testing helpers ...
./testsuite.at:9: $abs_top_builddir/src/tests/test-helpers
--- expout  2018-11-06 00:09:22.935710673 +
+++ /<>/src/tests/testsuite.dir/at-groups/1/stdout 2018-11-06
00:09:22.947710673 +
@@ -6,7 +6,7 @@
 Encoding 0xdeadbeef to asn.1 bitstring
 Encoded: 20deadbeef
 Decoding back to uint32_t: 0xdeadbeef
-Encoding efbead to 24-bit asn.1 bitstring
+Encoding deadbe to 24-bit asn.1 bitstring
 Encoded: 18adbeef
 Decoding string from asn.1: 0123456789012345
 Decoding large string from asn1: 0123456789012345678901234567890
1. testsuite.at:5: 1. helpers (testsuite.at:5): FAILED (testsuite.at:9)
## -- ##

Bug#913635: php7.3-common: Repeatable segfault in php7.3 when running Cacti poller since upgrade to 7.3

[Jarno Paananen]

Package: php7.3-common
Version: 7.3.0~rc5-1
Severity: normal

Dear Maintainer,

Since php was upgraded to 7.3 I get constant segfaults triggered by Cacti
poller being run from cron. So my dmesg is filled with messages such as this:

[22641940.244787] php[28600]: segfault at 7f3c45c005cc ip 559f0d644d5a sp
7ffcc4f01080 error 4 in php7.3[559f0d49d000+25f000]
[22641946.234158] php[28597]: segfault at 7fbec9c005cc ip 564c154dcd5a sp
7ffd85238da0 error 4 in php7.3[564c15335000+25f000]
[22642238.659938] php[28915]: segfault at 7f91ce0005cc ip 55c37af78d5a sp
7fff60a8d150 error 4 in php7.3[55c37add1000+25f000]
[22642244.906287] php[28913]: segfault at 7fc4026005cc ip 55655c313d5a sp
7fffcaa166a0 error 4 in php7.3[55655c16c000+25f000]

There are two hosts being polled so there are two of these lines every 5
minutes. However Cacti still seems to get the data so the crash doesn't seem
fatal. This has continued since first 7.3 version, didn't get this on 7.2.


-- Package-specific info:
 Additional PHP 7.3 information 

 PHP @PHP_VERSION SAPI (php7.3query -S): 

 PHP 7.3 Extensions (php7.3query -M -v): 

 Configuration files: 
 /etc/php/7.3/mods-available/calendar.ini 
extension=calendar.so

 /etc/php/7.3/mods-available/ctype.ini 
extension=ctype.so

 /etc/php/7.3/mods-available/exif.ini 
extension=exif.so

 /etc/php/7.3/mods-available/fileinfo.ini 
extension=fileinfo.so

 /etc/php/7.3/mods-available/ftp.ini 
extension=ftp.so

 /etc/php/7.3/mods-available/gettext.ini 
extension=gettext.so

 /etc/php/7.3/mods-available/iconv.ini 
extension=iconv.so

 /etc/php/7.3/mods-available/pdo.ini 
extension=pdo.so

 /etc/php/7.3/mods-available/phar.ini 
extension=phar.so

 /etc/php/7.3/mods-available/posix.ini 
extension=posix.so

 /etc/php/7.3/mods-available/shmop.ini 
extension=shmop.so

 /etc/php/7.3/mods-available/sockets.ini 
extension=sockets.so

 /etc/php/7.3/mods-available/sysvmsg.ini 
extension=sysvmsg.so

 /etc/php/7.3/mods-available/sysvsem.ini 
extension=sysvsem.so

 /etc/php/7.3/mods-available/sysvshm.ini 
extension=sysvshm.so

 /etc/php/7.3/mods-available/tokenizer.ini 
extension=tokenizer.so


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

Kernel: Linux 4.15.0-1-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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages php7.3-common depends on:
ii  libc6   2.27-8
ii  libssl1.1   1.1.1-2
ii  php-common  2:68
ii  ucf 3.0038

php7.3-common recommends no packages.

php7.3-common suggests no packages.

Versions of packages php7.3-cli depends on:
ii  libargon2-1  0~20171227-0.1
ii  libc62.27-8
ii  libedit2 3.1-20180525-1
ii  libmagic11:5.34-2
ii  libpcre2-8-0 10.32-3
ii  libsodium23  1.0.16-2
ii  libssl1.11.1.1-2
ii  libxml2  2.9.4+dfsg1-7+b1
ii  mime-support 3.61
ii  php7.3-json  7.3.0~rc5-1
ii  php7.3-opcache   7.3.0~rc5-1
ii  php7.3-readline  7.3.0~rc5-1
ii  tzdata   2018g-1
ii  ucf  3.0038
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages php7.3-cli suggests:
ii  php-pear  1:1.10.6+submodules+notgz-1

Versions of packages libapache2-mod-php7.3 depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.37-1
ii  libargon2-1 0~20171227-0.1
ii  libc6   2.27-8
ii  libmagic1   1:5.34-2
ii  libpcre2-8-010.32-3
ii  libsodium23 1.0.16-2
ii  libssl1.1   1.1.1-2
ii  libxml2 2.9.4+dfsg1-7+b1
ii  mime-support3.61
ii  php7.3-cli  7.3.0~rc5-1
ii  php7.3-json 7.3.0~rc5-1
ii  php7.3-opcache  7.3.0~rc5-1
ii  tzdata  2018g-1
ii  ucf 3.0038
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages libapache2-mod-php7.3 recommends:
ii  apache2  2.4.37-1

Versions of packages libapache2-mod-php7.3 suggests:
ii  php-pear  1:1.10.6+submodules+notgz-1

-- no debconf information

Bug#913648: dgit should fail early if bpd does not exist

[Ian Jackson]

Package: dgit
Version: 8.1

I keep finding that I `dgit clone' or `dgit fetch' and it downloads
some stuff and then falls over because bpd doesn't exist.  This is
mildly irritating.

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#913385: Cacti Package Dependancy Issues

[Mark Brugnoli-Vinten]

I believe the issue is present in previous versions since the intropage plugin 
can be used on earlier versions. I would have to double check what core 
features or any of our plugins use those three items but given that a plugin 
can come from anywhere and developers will most likely build against Cacti from 
GitHub sources rather than packages, this could affect any number of plugins 
that are out there that I wouldn’t know about. 

Obviously minor variations in package versions sometimes happen but as long as 
they are close to the one we have it will likely be only minor bugs that are 
unlikely to affect us. Major ones will be an issue since that can be whole 
functionality missing or changed. 

Mark

> On 10 Nov 2018, at 21:52, Paul Gevers  wrote:
> 
> Dear Mark,
> 
> Thanks for filing this bug.
> 
> On 10-11-18 12:27, Mark Brugnoli-Vinten wrote:
>> libjs-C3: 0.4.11+dfsg-2 < 0.6.8
>> libjs-D3: 3.5.17-2 < 5.7.0
>> libjs-chartjs: 1.0.2 < 2.7.3
>> 
>> The other package dependencies should probably also be checked since they 
>> could also cause issues.
> 
> Apart from the issues we noticed with Chart.js, do you know if Cacti is
> using features from the versions of C3 and D3 shipped by Cacti that are
> lacking in the versions in Debian?
> 
> Do you know if the issue with Chart.js is already present in 1.1.38?
> 
> Paul
> 

Bug#726953: #726953: dgit fails with submodules

[Ian Jackson]

I wrote:
> So, this bug is about (if we ignore the various other difficulties)
> the fact that dgit doesn't work with submodules.  It is not clear to
> me how it could.  At the very least this is a tricky design problem.
> 
> I'm going to tag the bug wontfix,wishlist for now.  If someone would
> care to do the hard thinking and propose a coherent scheme for how
> dgit should interact with submodules I will of course consider it.

Nowadays, dgit has split view mode.  This makes this problem soluble,
in principe: dgit could convert the supplied git tree, with
submodules, into a new git tree, without.

Each submodules could be resolved by being stripped, or by being
populated (replaced by the tree object of the gitlink commit).  In the
latter case the objects would have to be available.

I need to do some tests to discover what happens if you have a
.gitmodules file with no corresponding gitlink commits.  If that does
not work properly then dgit will have to delete the .gitmodules file
in a patch, I think.  Which is also awkward.


There will have to be a way to control what to do with submodules.

Should there be in-tree options in debian/ ?  dgit normally doesn't
look in debian/ to decide what to do but this may merit an excuse
given the submodule-wantedness is a property (per submodule) of the
with-submodule git-tree-object with debian/ directory, not of the
branch or the repo or the user.

The natural place to control this would be the .gitmodules file but
that would involve patching it.

So maybe:

  debian/source/dgit-gitmodules

contains one per line possibly-negated-with-! glob patterns
specifying matching s (see gitmodules(5) which should be
included or excluded

it is an error for a submodule to not be dealt with

things listed which are not submodules are ignored
(so the processing is idempotent)


I may implement stripping before I implement filling in.

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#913651: steam: please consider importing into salsa.debian.org git

[Simon McVittie]

Source: steam
Severity: wishlist

It would be useful to be able to track the history of the steam package
in a VCS - at least the MIT-licensed debian/ part, even if we don't want
to import historical versions of the proprietary bootstrapper binary.

I'd be happy to import the history from snapshot.debian.org if that would
be helpful, either the whole thing or just debian/.

smcv

Bug#913650: syncthing-gtk: Please add Enhances hints for supported file managers

[Jonas Smedegaard]

Package: syncthing-gtk
Version: 0.9.4.2-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Long description says syncthing-gtk "provides desktop integration with
various file managers" - which sounds like the perfect use of control
file Enhances: hints.

Please consider adding something like the following to control file:

  Enhances: nautilus, nemo, caja


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlvq5KcACgkQLHwxRsGg
ASG1KA//YCDShYO6ysXvDekfTzXnv2c/hvUWSJ3bzoIFAtAHgaZHeC5NDwdGhv3R
wHlxvYuaURBR3plhibXQuMlCpbgUT0M4iUC+RDlQyGoZ3jb4jnmVMGmUOgt+IxLG
+f2g1dlNianw2xtU+y1L7l8FfysSDOWNHyNtZvu41NUdqor0nFMm1f6av5BopuvK
+uAp/BLgitjfv4drMDNztDnOA1d/yxO3+KiISOTIO71T19CBB+ND7rveQgm9bKdW
/AYK1XhQzmffRcTc+fZdk5wVZTid8Lba0Pcu/pqDbflB6OMhI426GvqE84AoKl3z
81fV4fwugWiMYkkjYDFRO4D9taaQySp18jKjZ5RnZSvXMTFZlBeSDccklzD1S8tF
nKoHNQluhbITD+CC8UJvpQ9eCmBxjjUKV4I4A0WJbggIozbHj/rEI10oWZgt7YOR
Kf+meK4KSgLdnugs4l+yWhRwG4WICaPdr4WHSbgsAaJ/Ajab/HGfdhyIvbs20CQo
6MKQ7Ne0iCtRPZ1AJ5Rd0JtNnSAWjZAfsC2fbVMFmTOEzCbjfLVk6jLHqxfzeuS9
1mO0zrR0kl6JofOLarSV49EtxYbvTnR7BGjOntIjzwM0eDNVnMxozMSVWDoaANCz
KNmjNaVZ8C8gJpOzSRYJw9ecDNhx0yMUtkWDv8rfwE+mNIJiaIs=
=xAgD
-END PGP SIGNATURE-

Bug#913480: elpa-ghub: Could you package last version?

[Matteo F. Vescovi]

Hi again!

On Sun, Nov 11, 2018 at 3:27 PM Remi Vanicat  wrote:
> The new 3.0.0 is available, and the new verison of magit depend on it.
> Could you package it?

Digging deeper while packaging this new release, I faced the problem
that a couple of new dependencies were added, namely graphql and
treepy.
Both are in melpa archive and need to be debianized yet. As told you
earlier in IRC, I'll work on their packaging since Friday this week,
because work comes first ;-)

Cheers.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A

Bug#910584: hunspell-fr-classical: should be it section text (not localization)

[Jonas Smedegaard]

Quoting Sébastien Villemot (2018-11-13 15:28:08)
> Dear Jonas,
> 
> Le lundi 08 octobre 2018 à 14:29 +0200, Jonas Smedegaard a écrit :
> > Package: hunspell-fr-classical
> > Version: 1:6.3-1
> > Severity: normal
> > 
> > Package hunspell-fr-classical (and other packages from same source)
> > is placed in package section localization.
> > 
> > Package section localization is for localizations.
> > Dictionaries belong in text.
> 
> This is not what lintian thinks. If I use the section "text", I get:
> 
> I: hunspell-fr-classical: wrong-section-according-to-package-name 
> hunspell-fr-classical => localization
> 
> which is the reason why I moved those package from text to localization
> in release 1:6.2-1.
> 
> Indeed, the file data/fields/name_section_mappings in lintian source
> contains this rule:
> 
> ^(?:aspell|hunspell|myspell|mythes)-=> localization
> 
> So, before making this change, I'd prefer you convince the lintian
> maintainers first (unless there is some clear authoritative ressource
> that would give me confidence that this lintian tag is incorrect).

I consider lintian an _aid_ but not authoritative.

So don't expect me to file what seems to be a bug in lintian - I 
encourage you to consider doing that yourself (since clearly you seem 
more familiar with the internals of lintian than me).

...or alternatively you might consider mass-filing bugreports against 
literally *every* hunspell package other than the french one: All others 
agree on using text section. ;-)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#913654: RM: golang-github-rs-zerolog -- ROM; no longer needed

[Alexandre Viau]

Package: ftp.debian.org
Severity: normal

golang-github-rs-zerolog is no longer needed by any package.

This was initially packaged for zap which apparently doesn't need
it anymore.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#913625: Upstream default pidfile location changed

[Christian Ehrhardt]

On Tue, Nov 13, 2018 at 3:12 PM Vincent Blut  wrote:
>
> Hello,
>
> On Tue, Nov 13, 2018 at 08:34:25AM +0100, Christian Ehrhardt wrote:
> >Package: chrony
> >Version: 3.4-1
> >Severity: normal
> >
> >Hi,
> >in upstream chrony 3.4 there was a change [1] to the default pidfile path.
> >Since we do not configure at build
>
> We do ;-)
>
> From d/rules:
> “--with-pidfile=/run/chronyd.pid”

I should get some more sleep, how could I overlook this.
I remember looking at the config call ?!
Sorry to bother you!

> >nor in the .conf file a different path we have followed this changed
> >default path.
> >
> >Therefore I think we need a change to our service file like [2] to
> >have it be aware of the right PIDs.
> >What do you think?
>
> As you can see above, only modifying the service file is certainly not
> enough. But I think there is something potentially subtler behind this
> change; since debhelper compat 10, the default behaviour is to not stop
> the service until after the package upgrade has been completed (i.e. in
> postinst) so I’m fairly sure that if you don’t override
> “dh_systemd_start” with the “--no-restart-after-upgrade” option, you are
> going to have a stale pidfile (our good old /run/chronyd.pid) while
> upgrading from a prior chrony version.
>
> Considering these factors, I preferred not to change the pidfile
> location in Debian, even though I agree that it would be cleaner to have
> it in the “/run/chrony/” directory.

I agree to you, better patch next time :-/.
Self-slap and close this bug :-)

> >
> >[1]: 
> >https://git.tuxfamily.org/chrony/chrony.git/commit/?id=e50dc739d88feca6e0da034406034f3d3cf60ca4
> >[2]: 
> >https://git.launchpad.net/~paelzer/ubuntu/+source/chrony/commit/?id=a035dfd03423a097e7f1bf27d7d4f124f03fdcc1
> >
> >--
> >Christian Ehrhardt
> >Software Engineer, Ubuntu Server
> >Canonical Ltd
>
> Have a good day Christian,
> Vincent



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#913655: grub-pc: id caching in postinst does not work

[Jeroen Coekaerts]

Package: grub-pc
Version: 2.02+dfsg1-8
Severity: minor

On a system with almost a thousand devices (don't ask) I noticed that 
installing grub
takes over an hour. It was sorting device ids the whole time.
In the post install script there is a "cached_available_ids" variable set to 
prevent this.
But the available_ids() function gets called in a subshell like this 
for id in $(available_ids) ...
so the cache variable is never set in the main script.

If I change the script to call it once in the mainscript it gets fast

--- /var/lib/dpkg/info/grub-pc.postinst 2017-02-11 16:09:19.0 +0100
+++ grub-pc.postinst2018-11-13 16:12:51.884531798 +0100
@@ -44,7 +44,6 @@
 # This only works on a Linux system with udev running.  This is probably the
 # vast majority of systems where we need any of this, though, and we fall
 # back reasonably gracefully if we don't have it.
-cached_available_ids=
 available_ids()
 {
   local id path
@@ -55,14 +54,12 @@
   fi
 
   [ -d /dev/disk/by-id ] || return
-  cached_available_ids="$(
-for path in /dev/disk/by-id/*; do
-  [ -e "$path" ] || continue
-  printf '%s %s\n' "$path" "$(readlink -f "$path")"
-done | sort -k2 -s -u | cut -d' ' -f1
-  )"
-  echo "$cached_available_ids"
+  for path in /dev/disk/by-id/*; do
+[ -e "$path" ] || continue
+printf '%s %s\n' "$path" "$(readlink -f "$path")"
+  done | sort -k2 -s -u | cut -d' ' -f1
 }
+cached_available_ids=$(available_ids)

but that probably not a universal solution.

The device_to_id() for each device looping over all ids is O(n^2) too so it is 
still slow ofcourse..

Bug#913635: php7.3-common: Repeatable segfault in php7.3 when running Cacti poller since upgrade to 7.3

[Ondřej Surý]

Hi,

could you please install php7.3-cli-dbgsym debugging package, and then
run:

addr2line -e /usr/bin/php7.3 559f0d644d5a

(for all the values of `ip`)

Thanks,
--
Ondřej Surý
ond...@sury.org



> On 13 Nov 2018, at 10:34, Jarno Paananen  wrote:
> 
> Package: php7.3-common
> Version: 7.3.0~rc5-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Since php was upgraded to 7.3 I get constant segfaults triggered by Cacti
> poller being run from cron. So my dmesg is filled with messages such as this:
> 
> [22641940.244787] php[28600]: segfault at 7f3c45c005cc ip 559f0d644d5a sp
> 7ffcc4f01080 error 4 in php7.3[559f0d49d000+25f000]
> [22641946.234158] php[28597]: segfault at 7fbec9c005cc ip 564c154dcd5a sp
> 7ffd85238da0 error 4 in php7.3[564c15335000+25f000]
> [22642238.659938] php[28915]: segfault at 7f91ce0005cc ip 55c37af78d5a sp
> 7fff60a8d150 error 4 in php7.3[55c37add1000+25f000]
> [22642244.906287] php[28913]: segfault at 7fc4026005cc ip 55655c313d5a sp
> 7fffcaa166a0 error 4 in php7.3[55655c16c000+25f000]
> 
> There are two hosts being polled so there are two of these lines every 5
> minutes. However Cacti still seems to get the data so the crash doesn't seem
> fatal. This has continued since first 7.3 version, didn't get this on 7.2.
> 
> 
> -- Package-specific info:
>  Additional PHP 7.3 information 
> 
>  PHP @PHP_VERSION SAPI (php7.3query -S): 
> 
>  PHP 7.3 Extensions (php7.3query -M -v): 
> 
>  Configuration files: 
>  /etc/php/7.3/mods-available/calendar.ini 
> extension=calendar.so
> 
>  /etc/php/7.3/mods-available/ctype.ini 
> extension=ctype.so
> 
>  /etc/php/7.3/mods-available/exif.ini 
> extension=exif.so
> 
>  /etc/php/7.3/mods-available/fileinfo.ini 
> extension=fileinfo.so
> 
>  /etc/php/7.3/mods-available/ftp.ini 
> extension=ftp.so
> 
>  /etc/php/7.3/mods-available/gettext.ini 
> extension=gettext.so
> 
>  /etc/php/7.3/mods-available/iconv.ini 
> extension=iconv.so
> 
>  /etc/php/7.3/mods-available/pdo.ini 
> extension=pdo.so
> 
>  /etc/php/7.3/mods-available/phar.ini 
> extension=phar.so
> 
>  /etc/php/7.3/mods-available/posix.ini 
> extension=posix.so
> 
>  /etc/php/7.3/mods-available/shmop.ini 
> extension=shmop.so
> 
>  /etc/php/7.3/mods-available/sockets.ini 
> extension=sockets.so
> 
>  /etc/php/7.3/mods-available/sysvmsg.ini 
> extension=sysvmsg.so
> 
>  /etc/php/7.3/mods-available/sysvsem.ini 
> extension=sysvsem.so
> 
>  /etc/php/7.3/mods-available/sysvshm.ini 
> extension=sysvshm.so
> 
>  /etc/php/7.3/mods-available/tokenizer.ini 
> extension=tokenizer.so
> 
> 
> -- System Information:
> Debian Release: buster/sid
>  APT prefers unstable
>  APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.15.0-1-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/bash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages php7.3-common depends on:
> ii  libc6   2.27-8
> ii  libssl1.1   1.1.1-2
> ii  php-common  2:68
> ii  ucf 3.0038
> 
> php7.3-common recommends no packages.
> 
> php7.3-common suggests no packages.
> 
> Versions of packages php7.3-cli depends on:
> ii  libargon2-1  0~20171227-0.1
> ii  libc62.27-8
> ii  libedit2 3.1-20180525-1
> ii  libmagic11:5.34-2
> ii  libpcre2-8-0 10.32-3
> ii  libsodium23  1.0.16-2
> ii  libssl1.11.1.1-2
> ii  libxml2  2.9.4+dfsg1-7+b1
> ii  mime-support 3.61
> ii  php7.3-json  7.3.0~rc5-1
> ii  php7.3-opcache   7.3.0~rc5-1
> ii  php7.3-readline  7.3.0~rc5-1
> ii  tzdata   2018g-1
> ii  ucf  3.0038
> ii  zlib1g   1:1.2.11.dfsg-1
> 
> Versions of packages php7.3-cli suggests:
> ii  php-pear  1:1.10.6+submodules+notgz-1
> 
> Versions of packages libapache2-mod-php7.3 depends on:
> ii  apache2-bin [apache2-api-20120211]  2.4.37-1
> ii  libargon2-1 0~20171227-0.1
> ii  libc6   2.27-8
> ii  libmagic1   1:5.34-2
> ii  libpcre2-8-010.32-3
> ii  libsodium23 1.0.16-2
> ii  libssl1.1   1.1.1-2
> ii  libxml2 2.9.4+dfsg1-7+b1
> ii  mime-support3.61
> ii  php7.3-cli  7.3.0~rc5-1
> ii  php7.3-json 7.3.0~rc5-1
> ii  php7.3-opcache  7.3.0~rc5-1
> ii  tzdata  2018g-1
> ii  ucf 3.0038
> ii  zlib1g  1:1.2.11.dfsg-1
> 
> Versions of packages libapache2-mod-php7.3 recommends:
> ii  apache2  2.4.37-1
> 
> Versions of 

Bug#897623: fortunate.app

[Yavor Doganov]

Gürkan Myczko wrote:
> Can you confirm this update is right?
> 
> http://phd-sid.ethz.ch/debian/fortunate.app/fortunate.app_3.1-2.dsc

Basically yes, just a few remarks:

* It's better to use dh_auto_build instead of $(MAKE) in the
  dh_auto_build override; that way options for parallel builds (-jN)
  will propagate automatically:

override_dh_auto_build:
dh_auto_build -- $(optim) messages=yes $(shell dpkg-...

* The "optim" variable is already defined conditionally in
  /usr/share/GNUstep/debian/config.mk; there is no need to define it
  again.  Just build-depend on gnustep-make (>= 2.7.0-3).

* The dh_clean override seems unnecessary?

* As you're moving Resources to /usr/share you need to add a
  maintscript with dir_to_symlink to handle the transition.

> maybe also add the vcs fields and the repo to salsa.d.o?

Sure, feel free to import it at Salsa.

Bug#908678: Testing the filter-branch scripts

[Antoine Beaupré]

On 2018-11-12 12:22:58, Antoine Beaupré wrote:
> I'll start a run on the whole history to see if I can find any problems,
> as soon as a first clone finishes resolving those damn deltas. ;)

The Python job finished successfully here after 10 hours.

I did some tests on the new git repository. Cloning the repository from
scratch takes around 2 minutes (the original repo: 21 minutes). It is
145MB while the original repo is 1.6GB.

Running git annotate on data/CVE/list.2018 takes about 26 seconds, while
it takes basically forever to annotate the original data/CVE/list. (It's
been running for 10 minutes here already.)

So that's about it. I have not done a thorough job at checking the
actual *integrity* of the results. It's difficult, considering CVE
identifiers are not sequential in the data/CVE/list file, so a naive
diff like this will fail:

$ diff -u <(cat 
../security-tracker-full-test-filtered-bis/data/CVE/list.{2019,2018,2017,2016,2015,2014,2013,2012,2011,2010,2009,2008,2007,2006,2005,2004,2003,2002,2001,2000,1999}
 ) data/CVE/list | diffstat
 list |106562 
+--
 1 file changed, 53281 insertions(+), 53281 deletions(-)

But at least the numbers add up: it looks like no line is lost. And
indeed, it looks like all CVEs add up:

$ diff -u <(cat 
../security-tracker-full-test-filtered-bis/data/CVE/list.{2019,2018,2017,2016,2015,2014,2013,2012,2011,2010,2009,2008,2007,2006,2005,2004,2003,2002,2001,2000,1999}
 | grep ^CVE | sort -n ) <( grep ^CVE data/CVE/list | sort -n  ) | diffstat
 0 files changed

A cursory look at the diff seems to indicate it is clean, however.

I looked at splitting that file per CVE. That did not scale and just
created new problems. But splitting by *year* seems like a very
efficient switch, and I think it would be worth pursuing that idea
forward.

A.

-- 
There is no cloud, it's just someone else's computer.
   - Chris Watterson

Bug#896710: harfbuzz: autopkgtest to detect freetype regressions

[Emilio Pozuelo Monfort]

Hi Steve,

On Mon, 23 Apr 2018 17:14:19 -0700 Steve Langasek 
wrote:
> Package: harfbuzz
> Version: 1.7.2-1
> Severity: minor
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu bionic ubuntu-patch
> 
> Dear maintainers,
> 
> In Ubuntu we found a regression in freetype 2.8.1 due to unaligned memory
> access on armhf (when running on certain chips in certain kernel
> configurations) that was only discovered because it caused harfbuzz to fail
> to build on this architecture.
> 
> It would have been useful to catch this regression much earlier, if the
> harfbuzz build-time test suite were run at the time the new version of
> freetype was introduced, instead of later as part of an archive rebuild test.
> 
> So I've added a simple build-only autopkgtest to harfbuzz in Ubuntu; please
> see the attached patch, and please consider whether you think this would
> also be useful to have in Debian.

Is that patch correct? It doesn't seem to be building anything?

Emilio

Bug#904316: transition: boost-defaults

[Emilio Pozuelo Monfort]

On 13/11/2018 11:40, Giovanni Mascellani wrote:
> Dear pochu,
> 
> Il 12/11/18 22:05, Emilio Pozuelo Monfort ha scritto:
>> The icu transition has started now. Can you make a boost1.67 upload
>> build-depending on the new icu, with a bumped shlibs, similar to [1] ? That 
>> will
>> break ceph from sid (which depends on boost1.67), so an appropriate breaks 
>> would
>> be good. However please don't just break all the old versions, as the package
>> from testing doesn't break (it uses boost1.62) and if you break that, then
>> boost1.67 won't migrate until ceph gets fixed (it currently is in a bad 
>> shape in
>> sid). A breaks on (= 12.2.8+dfsg1-1), (= 12.2.8+dfsg1-2) should do the trick.
> 
> I do not really master shlibs and stuff yet, so I would like to have
> your confirmation the upload is correct:
> 
> 
> https://salsa.debian.org/debian/boost/commit/7962a7a35514e1351a9545613052f397d9549866

Looks good.

> BTW, I put the breakages on ceph-common, which is same-version depended
> by most of other ceph packages. However others, like librados2, are not
> covered. Also, package nheko too depends on libboost-regex1.67.0. Should
> that be broken as well?

Ack. Thanks for adding that.

> I am also fixing #912910[1] with the same upload, hope this is not
> getting in the middle. I will try a local build now.

Sure, that's fine.

Thanks for the upload.

Cheers,
Emilio

Bug#913586: texlive-binaries 2018.20181104.49075-1 breaks context

[Norbert Preining]

> Arg, indeed. Why didn't that happen here is a surprise to me, but now I
> can reproduce it.

I reverted luatex to the previous version 1.07 which works (at least
here) and uploaded a new package of texlive-bin.

Thanasis: If you are in hurry, please get the binaries from unstable.

Thanks

Norbert

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

Bug#664141: fancontrol: service needs restarting after sleep

[Emilan Nowak]

Here is the patch attached that fixes that issuediff -r 49f974c860fe lm_sensors-3.4.0/debian/fancontrol-systemd-pm
--- /dev/null	Thu Jan 01 00:00:00 1970 +
+++ b/lm_sensors-3.4.0/debian/fancontrol-systemd-pm	Tue Nov 13 17:11:58 2018 +0100
@@ -0,0 +1,12 @@
+#!/bin/bash
+
+PATH=/usr/sbin:/bin
+
+case "$1" in
+post)   systemctl restart fancontrol
+exit 0
+;;
+*)  exit 1
+;;
+esac
+
diff -r 49f974c860fe lm_sensors-3.4.0/debian/rules
--- a/lm_sensors-3.4.0/debian/rules	Tue Nov 13 17:10:50 2018 +0100
+++ b/lm_sensors-3.4.0/debian/rules	Tue Nov 13 17:11:58 2018 +0100
@@ -24,6 +24,8 @@
 
 override_dh_auto_install-indep:
 	$(MAKE) install-prog-pwm $(MAKEARGS_INDP)
+	mkdir -p $(CURDIR)/debian/fancontrol/lib/systemd/system-sleep/
+	cp $(CURDIR)/debian/fancontrol-systemd-pm $(CURDIR)/debian/fancontrol/lib/systemd/system-sleep/fancontrol
 
 override_dh_installinit-indep:
 	dh_installinit -pfancontrol --restart-after-upgrade

Bug#913656: buildd.debian.org: dpkg ends up with error 2 due to miss path for /etc/profile

[edneyhelene]

Package: buildd.debian.org
Severity: normal
Tags: patch

Dear Maintainer,
Debian buster have a strange problem at the momment!

DPKG cant find ldconfig path and it gives error 2!

The solution is to edit /etc/profile
Bugged version :

if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/games"
fi

___
Solution: /Sbin is missing after games and needs an patch for solution.

Temporary fix is to edit like this:

if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/games/sbin"
fi

and then
source /etc/profile

If someone could please make this permanent fix for the system on an next
update would be great!



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

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash

Bug#877913: ITA: easy-rsa -- Simple shell based CA utility

[Michele Orru]

Hi! I am working on updating this package to the latest upstream version.


--
μ.

Bug#910584: hunspell-fr-classical: should be it section text (not localization)

[Jonas Smedegaard]

Dear Sébastien,

Quoting Sébastien Villemot (2018-11-13 16:34:05)
> Le mardi 13 novembre 2018 à 16:12 +0100, Jonas Smedegaard a écrit :
>> I consider lintian an _aid_ but not authoritative.
> I tend to consider lintian authoritative when there is no “higher 
> source of law” (such as the Policy, DevRef, team policies…).

Ok, so we agree that Debian Policy is more authoritative than lintian.

Debian Policy states § 2.4 says this about section definitions:

> For more information about the sections and their definitions, see the 
> list of sections in unstable.

The web page https://packages.debian.org/unstable/ says this about 
section "localization":

> Localization support for big software packages.

...and this about section "text":

> Utilities to format and print text documents.


It seems sensible to me that hunspell dictionaries are treated as 
utilites to process text documents rather than localization support.

Localization is specific to mapping internationalization strings into a 
local context - purpos of a dictionary is far more general than that - 
and it seems all other maintainers of hunspell dictionaries besides you 
came to that same conclusion.


Please reconsider your verdict of this bugreport.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#913656: buildd.debian.org: dpkg ends up with error 2 due to miss path for /etc/profile

[Philipp Kern]

On 2018-11-13 17:24, edneyhelene wrote:

Package: buildd.debian.org
Severity: normal
Tags: patch

Dear Maintainer,
Debian buster have a strange problem at the momment!

DPKG cant find ldconfig path and it gives error 2!

The solution is to edit /etc/profile
Bugged version :

if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/games"
fi

___
Solution: /Sbin is missing after games and needs an patch for solution.

Temporary fix is to edit like this:

if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/games/sbin"
fi

and then
source /etc/profile

If someone could please make this permanent fix for the system on an 
next

update would be great!


Maybe you should make sure that your environment is correct when 
escalating your privileges to root, e.g. using "sudo -i". Anyway you 
reported this against a wrong component and this is in fact a user 
error. I suggest reaching out to debian-u...@lists.debian.org for help.


Kind regards
Philipp Kern

Bug#913614: [pkg-gnupg-maint] Bug#913614: gnupg2 fails with "cannot open '/dev/tty': No such device or address"

[Tianon Gravi]

On Tue, 13 Nov 2018 15:18:22 +0100 Werner Koch  wrote:
> For any script use you should anyway use --batch which disables the use
> of the tty as a side-effect.

Even for something that shouldn't have a reason to prompt, like
"--recv-keys" with a full fingerprint?

It makes some sense logically, but seems a bit overkill (and worked
fine without in the previous Debian Stable version of gnupg), and is
now a pretty common pattern in the Docker ecosystem (I've seen failing
builds in a huge number of repositories now with this exact
tty-related error on similar "--recv-keys" invocations).

Would it make sense to detect that there's no TTY present and assume
batch mode?  (apologies if something like that's been proposed before)

(And to be explicitly clear, your work on GnuPG is appreciated!)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#909465: Similiar issue when upgrading samba - fixed by mapping BUILTIN\Guests to nobody group

[Bernhard Schmidt]

Control: notfound -1 2:4.9.1+nmu-1~deb9
Control: found -1 2:4.9.1+dfsg-2
Control: tags -1 - d-i
Control: severity -1 important
Control: retitle -1 smbd fails to start in 2:4.9.1+dfsg-2, "failed to setup 
guest info."

On Sun, Nov 11, 2018 at 09:48:51AM +0100, Javier Fernandez-Sanguino wrote:

Dear Javier,

> Yesterday I upgraded to samba (from 2:4.8.5+dfsg-1 to 2:4.9.1+dfsg-2)
> and had a similar issue, after the upgrade samba would not start,
> breaking the 'apt-get dist-upgrade' at the end. To fix it I had to run
> 'net -s /dev/null groupmap add sid=S-1-5-32-546 unixgroup=nobody
> type=builtin' and restart the smbd service.

Thanks!!! I've been scratching my head about this.

I'm changing the version tracking and description to properly fit the
symptoms/versions in Debian.

Bernhard

Bug#912937: runit: Can't shutdown or reboot when using single user mode

[alecfeldman]

It is quite strange how debian uses /etc/service to store currently active 
services. Other
distributions use /run/runit or /var/service, though /run makes more sense. 
Perhaps /etc/service
could be moved somewhere else? This would solve the issue with etc being 
read-only. The concept of
symlinks from /etc/sv to /run, and then to current would still apply though. 
This would require
some package changes. To be honest, there's a lot about the way runit is 
packaged on Debian that
should be changed. The part about only having a handful of -run packages isn't 
a huge deal. I can
make them myself, although creating packages for those services would be handy.

On an unrelated note, runit uses sysvinit scripts to boot. While this is fine, 
if I want to use
runit and nothing else, I shouldn't need to have sysv-rc installed as some sort 
of backend. This
sort of leads to a wider issue that I'm not sure I should discuss here.

November 11, 2018 4:08 PM, "Dmitry Bogatov"  wrote:

> Please keep BTS in CC.
> 
> [2018-11-09 22:35] alecfeld...@disroot.org
> 
>> If you look at the changes I made to stage 2, changing back to default
>> won't be a problem.
>> 
>> runlevel=default
>> for arg in $(cat /proc/cmdline); do
>> if [ -d /etc/runit/runsvdir/"$arg" ]; then
>> echo "Runlevel detected: '$arg' (via kernel cmdline)"
>> runlevel="$arg"
>> fi
>> done
>> 
>> runsvchdir "${runlevel}"
> 
> Ah, I start to understand your idea. While I see its merits, I believe
> it introduces even more moving parts in /etc, which ideally should be
> mounted read-only.
> 
> In any case, patch aganist https://salsa.debian.org/runit-team/runit
> would greatly help me understand your ideas fully.
> 
>> If there's a power outage, on the next boot runsvchdir will change
>> current back to default. It seems relatively simple to me, with the
>> unlikelihood of corner cases to develop. This is how runsvdirs are
>> handled in other runit based distributions from my experience.
> 
> In Debian situation is complicated by huge number of daemons, that do
> not have corresponding runscript. Actually, there is ~1300 daemons and
> handful of -run packages in sid.

Bug#913657: grep: Regex grep on stretch is slower than jessie

[Jan van den Berg]

Package: grep
Version: 2.27-2
Severity: normal

Dear Maintainer,

I just upgraded from Debian 8 to 9 and noticed that a script which I run
several times per day was really slow:

real0m6.384s
user0m6.288s
sys 0m0.036s

This used to take well under a second.

I dug a little deeper and noticed the problem was here:

grep 'best_bid\|fixed_' /var/www/logs/large_log_file

Playing around with the grep parameters en locale settings, and narrowed it
down to the regex, because this is way faster:

grep -F best_bid /var/www/logs/large_log_file
grep -F fixed /var/www/logs/large_log_file

So much faster in fact, that I can run 2 grep command faster than one.

real0m0.199s
user0m0.108s
sys 0m0.032s

However, this is strange and unexpected that after an upgrade a
unaltered grep script is slower. I dug a little deeper and it seem related to 
#761157
(and #18454) because of a change in de PCRE library between jessie and
stretch.

I have not seen a real fix yet (other than altering my script/grep commands), 
but I expect the regex library needs work, to match the previous behaviour so 
therefore I'm deeming it a 'bug'?

--
Jan


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

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

Versions of packages grep depends on:
ii  dpkg  1.18.25
ii  install-info  6.3.0.dfsg.1-1+b2
ii  libc6 2.24-11+deb9u3
ii  libpcre3  2:8.41-1+0~20180910100527.3+stretch~1.gbp97d153

grep recommends no packages.

Versions of packages grep suggests:
ii  libpcre3  2:8.41-1+0~20180910100527.3+stretch~1.gbp97d153

-- no debconf information

Bug#913637: Proposed upstream fix

[Dagfinn Ilmari Mannsåker]

reassign 913637 perl
forwarded 913637 
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/330
thanks

Hi,

I've proposed fixing this upsteream by leaving the shebang alone if it's
absolute, in PATH, and has the same dev/ino numbers as the first one in
PATH.

If/when this gets merged, it shoud be backported to the Debian perl
package.

- ilmari
-- 
- Twitter seems more influential [than blogs] in the 'gets reported in
  the mainstream press' sense at least.   - Matt McLeod
- That'd be because the content of a tweet is easier to condense down
  to a mainstream media article.  - Calle Dybedahl

Bug#913572: Shouldn't shipping broken symlinks be against policy?

[G. Branden Robinson]

Not reopening, but I have some questions for the Policy team.

At 2018-11-13T16:26:00+, Ximin Luo wrote:
> Control: notfound -1 1.28.0+dfsg1-2
> 
> Closing, as far as I can tell it is not against Policy to ship a
> broken symlink,

I could have sworn you were incorrect, but sure enough, I read §10.5
carefully and grepped the rest of the policy manual and could find no
such prohibition.

It is certainly untidy.  So I ask the Policy team--_shouldn't_ it be
prohibited?

> if it doesn't affect the functionality of the package.

Well, when a package ships a man page, I expect something more
illuminating to happen than:

$ man rust-gdb
/usr/bin/man: warning: /usr/share/man/man1/rust-gdb.1.gz is a dangling symlink
No manual entry for rust-gdb
See 'man 7 undocumented' for help when manual pages are not available.

> The man page is available in the rust-doc package which is already in
> Suggests.

In that case, isn't a better fix to put the symlink in that package,
too?

On my buster system, this is the only one of over 4,300 symlinks in
/usr/share/man that is broken:

$ find /usr/share/man -type l | wc -l; for F in $(find /usr/share/man \
-type l); do if ! test -f "$F"; then file "$F"; dpkg -S "$F"; fi; done
4938
/usr/share/man/man1/rust-gdb.1.gz: broken symbolic link to gdb.1.gz
rust-gdb: /usr/share/man/man1/rust-gdb.1.gz

> X
> 
> G. Branden Robinson:
> > Package: rust-gdb
> > Version: 1.28.0+dfsg1-2
> > Severity: normal
> > File: /usr/share/man/man1/rust-gdb.1.gz
> > 
> > $ dpkg -S /usr/share/man/man1/rust-gdb.1.gz
> > rust-gdb: /usr/share/man/man1/rust-gdb.1.gz
> > 
> > $ file /usr/share/man/man1/rust-gdb.1.gz
> > /usr/share/man/man1/rust-gdb.1.gz: broken symbolic link to gdb.1.gz
[snip]

Thanks for your time.  Policy mavens, please CC me or the bug on
replies; I don't subscribe to a billion lists like I did in the old
days.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#912853: transition: icu

[GCS]

On Mon, Nov 12, 2018 at 4:05 PM Emilio Pozuelo Monfort  wrote:
> On 11/11/2018 11:24, László Böszörményi (GCS) wrote:
> > On Sun, Nov 4, 2018 at 4:45 PM Laszlo Boszormenyi (GCS)  
> > wrote:
> >> I'd like to upload ICU 63.1 which was recently released for Buster.
> >  I still miss the last three packages rebuilt, but I don't expect any
> > problems with those.
> > First, my methodology was to build the related packages both on i386
> > and amd64 (32 and 64 bit) to detect all possible problems in advance.
> > If a package failed due to ICU, I've patched it. If the reason was not
> > clear, rebuilt the package for Sid to check that result as well.
> > The order of rebuilds was harfbuzz -> boost1.67 -> make boost-defaults
> > point to it, then all other packages.
> Please go ahead with this. I will ack the boost transition once this is built.
 Please note that src:harfbuzz currently has a problem on armhf, it
failed to build three times in line. The reason is known: the
arm-arm-01 named buildd always failed to build it[1]. Can you schedule
its build on an other armhf machine or a buildd admin (in Cc) can do
it? There's no sense trying to build it on the mentioned box again and
again or even later. If possible, please set that src:harfbuzz
shouldn't be tried to build on the arm-arm-01 machine in the future.

Thanks,
Laszlo/GCS
[1] https://buildd.debian.org/status/logs.php?pkg=harfbuzz=armhf

Bug#913542: teckit: Fails to build on Ubuntu's ppc64el (symbols)

[Matthias Klose]

the main question is: are these symbols part of the ABI?  And I very much doubt
that they are.  symbols files for C++ are so yesterday.  There are better tools
like abi-compliance-checker and abigail.

Bug#911925: Bug#913641: libreoffice-report-builder: report builder reports fail to run

[rene . engelhard]

block 913641 by 911925
affects 911925 libreoffice-report-builder
thanks

>>Not clear if you are saying I need to do it, or you need to do it. I
>>don't quite understand the issue, you do, so I assume you will, you
>>will be able to explain to the Java package maintainers the issue?
>
>I will do, yes.
>
>>Please CC me, I'd like to be educated on that.
>
>The Gerrit discussion explains it..openjdk doesn't honour some
>classpath specifications anymore so stuff is simply not found.

Ah, there is already 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925#29 etc.

For #911925 readers: LibreOffice with it's (relative) Class-Path: entries is 
affected as well, breaking build and runtime...

Regards,

René


-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#903665: boost1.62: merge request for #903665

[Frédéric Bonnard]

Hi,

here is a merge request :
https://salsa.debian.org/debian/boost/merge_requests/3
Tested successfully for bali-phy .
Regards,


F.


pgp0HOIxDc0jE.pgp
Description: PGP signature

Bug#913653: RM: golang-go.pedge-lion -- ROM; no longer needed

[Alexandre Viau]

Package: ftp.debian.org
Severity: normal

golang-go.pedge-lion is no longer needed by any package.

This was initially packaged for InfluxDB which apparently doesn't need
it anymore.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#913540: "crypto: stream: repeat IV detected" after upgrading to newest version.

[Roger Shimizu]

On Mon, Nov 12, 2018 at 11:06 AM Gong S.  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Package: shadowsocks-libev
> Version: 3.2.1+ds-1
>
> After upgrading to the latest version, any connection attempts through the 
> proxy would be closed with:
>  2018-11-12 09:46:44 ERROR: invalid password or cipher
>  2018-11-12 09:46:45 ERROR: crypto: stream: repeat IV detected
> despite the passwords are correct.
> If I downgrade to the previous version (3.2.0+ds-5) it works as normal.
> Config files "/etc/shadowsocks-libev/config.json:
> {
> "server":[REDACTED],
> "server_port":[REDACTED],
> "local_port":1080,
> "password":[REDACTED],
> "timeout":4,
> "method":"aes-256-cfb"
> }

Thanks for your report!

I think maybe it's related upstream ticket:
- https://github.com/shadowsocks/shadowsocks-libev/issues/2215

I'll try to upload a version with the patch, so you can test.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1