Bug#905885: diffoscope: skipping tests on ci.debian.net is perhaps wrong?

[Stuart Prescott]

Package: diffoscope
Version: 99
Severity: normal

Dear Maintainers,

diffoscope recommends apktool but apktool is not currently in buster. The
test suite of diffoscope currently passes without error because the tests
that use apktool are decorated with @tool_required('apktool').

Consequently:

* the code paths that use apktool are not being tested in buster

* these tests are not actually passing but ci.debian.net is saying that
  the test suite has passed (skipping tests to hide errors isn't the
  same as a test passing)

There is clear value in being able to skip tests for the casual user on
another platform or when not interested in diffoscope's abilities in
file formats about which one does not care. For the Debian package,
however, I think every functionality of the Debian package should be
tested in autopkgtest. The current situation does not pick up that apktool
is not installable in buster, for instance, and would not pick up
something like /usr/bin/apktool being renamed.

Perhaps @tool_required could be extended with an "all tools required"
mode such that no tests are skipped or missing tools are a test failure
(or error). An environment variable would work for setting that mode
and that mode used at package build time and in autopkgtest.

BTW other latent bugs here:

* diffoscope has an unsatisfiable recommends

* diffoscope cannot be built in buster (unsatisfiable build-deps,
  this is RC)

cheers
Stuart

Bug#905790: ibus-gtk3: ibus pop-up on login is distracting

[Osamu Aoki]

Hi,

On Thu, Aug 09, 2018 at 05:30:06PM +0200, Jonathan Carter wrote:
> Package: ibus-gtk3
> Severity: normal
> 
> Dear Maintainer,
> 
> ibus is installed by default on a Debian desktop (or at least
> on debian live media).

I see your concern.  I want live media to be useful, too ;-)
 
> When logging into an Xfce or Gnome session, an ibus pop-up is
> displayed. This can be particularly annoying or distracting to
> users who are trying out a live image, who won't know what ibus
> even is, and what typically happens is that they perceive it
> as an error message, which doesn't leave a great impression on
> new Debian users.
> 
> Would you perhaps consider removing the notification of the new
> default ibus shortcut pop-up? It's been there for a few releases

I never saw such thing.

> already, not sure if it really is all that useful anymore.

I am using ibus with Gnome on my Desktop and I see no pop-up.  It may be
because I already activate ibus for my Japanese input.

My problem is 3 folds:
 * I don't see your problem here.
 * I don't know why upstream placed such thing.
 * I don't know which part of the code is causing problem.

Also, are you sure the problem coming from ibus-gtk3 (not from ibus).

Your help to identify the source of problem is highly appreciated.

Regards

Osamu

Bug#905884: RFS: chafa/0.9.0+git20180731.5ddfe4c-1 [ITP]

[Lumin]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

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

 * Package name: chafa
   Version : 0.9.0+git20180731.5ddfe4c-1
   Upstream Author : Hans Petter Jansson
 * URL : https://hpjansson.org/chafa/
 * License : LGPL-3
   Section : graphics

  It builds those binary packages:

chafa - Image-to-text converter supporting a wide range of symbols, etc.
libchafa-dev - development files for image-to-text converter chafa
libchafa0  - library for image-to-text converter chafa

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/c/chafa/chafa_0.9.0+git20180731.5ddfe4c-1.dsc

  More information about hello can be obtained from 

  
http://debomatic-amd64.debian.net/distribution#unstable/chafa/0.9.0+git20180731.5ddfe4c-1/buildlog

chafa (0.9.0+git20180731.5ddfe4c-1) unstable; urgency=low

  * Initial release. (Closes: #905882)

Bug#905883: RFP: purple-lurch -- XEP-0384: OMEMO Encryption for libpurple

[Paul Wise]

Package: wnpp
Severity: wishlist

* Package name: purple-lurch
  Version : 0.6.7
  Upstream Author : Richard Bayerle 
* URL : https://github.com/gkdr/lurch/
* License : GPL
  Programming Lang: C
  Description : XEP-0384: OMEMO Encryption for libpurple

This is the more active of the two OMEMO libpurple plugins:

https://developer.pidgin.im/ticket/16801
https://github.com/gkdr/lurch
https://github.com/manchito/libpurple-omemo-plugin/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#905384: libmuscle does not build any more - probably some issue of newer automake

[Andreas Tille]

Hi,

libmuscle[1] was bilding fine in several uploads but when I now
try to rebuild to fix #904690 I get:

...
dh_auto_build --no-parallel
make -j1
make[2]: Entering directory '/build/libmuscle-3.7+4565'
Making all in libMUSCLE
make[3]: Entering directory '/build/libmuscle-3.7+4565/libMUSCLE'
g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" 
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT
_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 
-DLT_OBJDIR=\".libs/\" -DSTDC_HEADERS=
1 -DTIME_WITH_SYS_TIME=1 -I. -I..  -Wdate-time -D_FORTIFY_SOURCE=2 -O2 
-funroll-loops -fomit-frame-pointer -ftree-vectorize  -DNDEBUG=1  -fopenmp -g 
-O2 -fdebug-prefix-map=/build/libmuscle-
3.7+4565=. -fstack-protector-strong -Wformat -Werror=format-security -c -o 
main.o main.cpp
make[3]: *** No rule to make target '../libMUSCLE/libMUSCLE.la', needed by 
'muscle'.  Stop.
make[3]: Leaving directory '/build/libmuscle-3.7+4565/libMUSCLE'
...


I suspect an issue in libMUSCLE/Makefile.am.  Any hint how to fix this?

Kind regards

  Andreas.


[1] https://salsa.debian.org/med-team/libmuscle

-- 
http://fam-tille.de

Bug#905750: RFS: elpy/1.23.0-1

[Chris Lamb]

[Not prematurely sending mail this time]

Nicholas,

Alas I wrote before, whilst I appreciate the sentiment, please spend any
limited time you have for Debian work writing such things in suitable
venue(s) and not in an adjunct sponsorship bug. Otherwise I fear the
effort expended in such a voluminous and detailed response will be in
vain.

> >  * Please fix "wrong-section-according-to-package-name" on your next
> >upload (or otherwise fix Lintian).
> 
> This is currently an Informational level message.  When it was a
> Warning I declared Section: lisp, even though I do not believe that
> this is accurate.

Please strive to be Lintian clean not fuss about "warning" about
"informational" which are not subject to strict scrutinity and
classification by the Lintian maintainers as you seem to infer.

> Re: fixing Lintian, this will require a discussion and a more clear
> definition of Section: lisp.  Most Emacs modes should probably be in
> Section: editors, because they are interactive extensions to an
> editor.  Magit is definitely in the right section eg: vcs.  Emacs
> packages that enable IDE modes should be in Section: devel.
> 
> Section: lisp should be reserved for libraries like dash-el.

This is a topic for elsewhere.

> >  * gzip -9 might need to be gzip -9n for a reproducible build
> >(unchecked) but I'm surprised it's not compressed by another tool
> >too (unchecked).
> 
> Thank you for pointing this out.  I've reverted @commit:9095c18
> because README.rst is only 2.8k and dh_compress already does the
> right thing automatically; that is to say, README.rst is not
> "larger than 4k in size" and should not be compressed.

?? I was talking about -n, not -9. Nothing to do with 4k limits but
rather reproducibly.
> 
> On the topic of reproducibility, generating an info page made Elpy
> unreproducible!
>   https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/elpy.html
> 
> This will take time to look into.  Possibilities are:
>   1) sphinx-build is at fault
>   2) makeinfo is at fault
>   3) something is missing how I'm using 1 and/or 2.
>  - if this is the case then it's also a case of incomplete
>documentation

Likely #2 or something similar. https://bugs.debian.org/826158?

But again, this is really the wrong venue for these 4/5 topics as it will
quickly get lost..


Regards,

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

Bug#905750: RFS: elpy/1.23.0-1

[Chris Lamb]

Nicholas,



> > For your wishlist/TODO:
> > 
> >  * Please fix "wrong-section-according-to-package-name" on your next
> >upload (or otherwise fix Lintian).
> 
> This is currently an Informational level message.  When it was a
> Warning I declared Section: lisp, even though I do not believe that
> this is accurate.
> 
> Re: fixing Lintian, this will require a discussion and a more clear
> definition of Section: lisp.  Most Emacs modes should probably be in
> Section: editors, because they are interactive extensions to an
> editor.  Magit is definitely in the right section eg: vcs.  Emacs
> packages that enable IDE modes should be in Section: devel.
> 
> Section: lisp should be reserved for libraries like dash-el.
> 
> >  * You should probably avoid building the documentation too if the
> >nodocs build profile is enabled.
> 
> I've added it to my TODO and will start learning about how to do
> this.
> 
> >  * gzip -9 might need to be gzip -9n for a reproducible build
> >(unchecked) but I'm surprised it's not compressed by another tool
> >too (unchecked).
> 
> Thank you for pointing this out.  I've reverted @commit:9095c18
> because README.rst is only 2.8k and dh_compress already does the
> right thing automatically; that is to say, README.rst is not
> "larger than 4k in size" and should not be compressed.

That's not what I was talking about, ie. "reproducibility".

> On the topic of reproducibility, generating an info page made Elpy
> unreproducible!
>   https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/elpy.html
> 
> This will take time to look into.  Possibilities are:
>   1) sphinx-build is at fault
>   2) makeinfo is at fault
>   3) something is missing how I'm using 1 and/or 2.
>  - if this is the case then it's also a case of incomplete
>documentation
> 





Regards,

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

Bug#905882: ITP: chafa -- Image-to-text converter supporting a wide range of symbols and palettes, transparency, animations, etc.

[Lumin]

Package: wnpp
Severity: wishlist
Owner: lumin 

* Package name: chafa
  Version : 0.9.0+git20180731.5ddfe4c
  Upstream Author : Hans Petter Jansson
* URL : https://hpjansson.org/chafa/
* License : LGPL-3.0+
  Programming Lang: C
  Description : Image-to-text converter supporting a wide range of symbols 
and palettes, transparency, animations, etc.

Bug#880245: New version of statsmodels is out possibly fixing important bug - any volunteer

[Andreas Tille]

Hi,

it seems upstream dealt with issue #3892 in latest upstream version 0.9.
As far as I can see this will fix #880245.

Any volunteer to upgrade the package?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#905622: julia 0.7.0~rc3 is available

[Lumin]

close -1

already in unstable

Bug#904544: gimp hangs on startup if libopenblas-base is installed

[CHristoph Zaunmayr]

removing  libopenblas-base solved the problem for me!

On Thu, 9 Aug 2018 14:11:11 +0100 Simon McVittie  wrote:
> Control: retitle 904544 gimp hangs on startup if libopenblas-base is
installed
> Control: reassign 904544 src:glibc 2.27-5
> Control: forcemerge 903514 904544
>
> On Thu, 09 Aug 2018 at 19:00:32 +0800, Jun Jiang wrote:
> > I saw  James Van Zandt mentioned in [4]https://bugs.debian.org/cgi-bin/
> > bugreport.cgi?bug=903514:
> >
> > "Specifically:
> >sudo apt-get install libopenblas-base- libopenblas-dev- \
> >  libblas3 liblapack3 libblas-dev liblapack-dev
> ...
> > And that solved my problem too. In my case, libopenblas-dev:amd64
(0.3.2+ds-1)
> > and libopenblas-base:amd64 (0.3.2+ds-1) got removed and after that, GIMP
> > launched successsfully just like it used to do. Hope it helps.
>
> OK, then it looks like this is another report of #903514.
>
> Thanks,
> smcv
>
>

Bug#905881: lintian: detect packages containing X11 fonts that do not run update-fonts-* or do not dep on xfonts-utils

[Paul Wise]

Package: lintian
Version: 2.5.96
Severity: wishlist

As a result of a thread[1] on debian-fonts, I found that lmodern and
tex-gyre contain X11 fonts but do not run update-fonts-* from their
postinst and do not depend on xfonts-utils via ${misc:Depends}, both
of these are automatically added by dh_installxfonts if run correctly.

I filed bugs[2] about these issues but it would be nice to have lintian
detect binary packages containing X11 fonts[3] that do not depend on
xfonts-utils or do not have the dh_installxfonts snippet[4] that
debhelper installs into the maintainer scripts.

1. 
https://lists.debian.org/msgid-search/CAJqvfD-A1EPXxF_mS=_baq0ftqygvwruf+23wqsqrksmygv...@mail.gmail.com
2. https://bugs.debian.org/905879
   https://bugs.debian.org/905880
3. /usr/share/fonts/X11/**/*.pcf.gz
   /usr/share/fonts/X11/**/*.pcf
   /usr/share/fonts/X11/**/*.pfa
   /usr/share/fonts/X11/**/*.pfb
   /usr/share/fonts/X11/**/*.afm
4. For example:
 # Automatically added by dh_installxfonts/11.3.5
 if [ -x "`which update-fonts-dir 2>/dev/null`" ]; then
update-fonts-scale Type1;update-fonts-dir --x11r7-layout Type1
 fi

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-2
ii  bzip2  1.0.6-8.1
ii  diffstat   1.61-1+b1
ii  dpkg   1.19.0.5+b1
ii  file   1:5.33-3
ii  gettext0.19.8.1-6+b1
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34
ii  libarchive-zip-perl1.60-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.39-1
ii  libdpkg-perl   1.19.0.5
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b3
ii  libparse-debianchangelog-perl  1.2.0-12
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.72+repack-1
ii  man-db 2.8.4-2
ii  patchutils 0.3.4-2
ii  perl [libdigest-sha-perl]  5.26.2-6
ii  t1utils1.41-2
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

Versions of packages lintian suggests:
ii  binutils-multiarch 2.31.1-2
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.53-1

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#905879: lmodern: contains X11 fonts but does not run update-fonts-* in postinst nor dep on xfonts-utils

[Paul Wise]

Source: lmodern
Version: 2.004.5-3
Severity: minor

The lmodern package contains X11 fonts but does not run update-fonts-*
from the postinst nor does it depend on xfonts-utils. Consequently the
installed fonts are not registered properly with the X11 fonts system.

The issue is caused by the X11 fonts being symlinks installed by
dh_link and the dh_installxfonts command being run before the symlinks
are installed into the package, so it thinks there are no fonts present.

PS: I think you can drop the defoma stuff for buster.

$ grep xfont -B1 -A2 debian/rules 
dh_install
dh_installxfonts
dh_installtex --package=lmodern map=Map,lm.map
dh_link

$ grep -ri usr/share/font | head
doc/fonts/lm-math/INSTALL.txt:copy the font file to ~/.fonts or 
/usr/share/fonts ). If the font
debian/changelog:  /usr/share/fonts/X11/Type1
debian/lmodern.README.Debian:/usr/share/fonts/X11/Type1. If this path is not 
present in your
debian/rules: sed -ne 
's!^\(.*\)$$!usr/share/texmf/fonts/type1/public/lm/\1.pfb 
usr/share/fonts/X11/Type1/\1.pfb\nusr/share/texmf/fonts/afm/public/lm/\1.afm 
usr/share/fonts/X11/Type1/\1.afm!p' \
debian/lmodern.links:usr/share/texmf/fonts/type1/public/lm/lmb10.pfb 
usr/share/fonts/X11/Type1/lmb10.pfb
debian/lmodern.links:usr/share/texmf/fonts/afm/public/lm/lmb10.afm 
usr/share/fonts/X11/Type1/lmb10.afm
debian/lmodern.links:usr/share/texmf/fonts/type1/public/lm/lmbo10.pfb 
usr/share/fonts/X11/Type1/lmbo10.pfb
debian/lmodern.links:usr/share/texmf/fonts/afm/public/lm/lmbo10.afm 
usr/share/fonts/X11/Type1/lmbo10.afm
debian/lmodern.links:usr/share/texmf/fonts/type1/public/lm/lmbx10.pfb 
usr/share/fonts/X11/Type1/lmbx10.pfb
debian/lmodern.links:usr/share/texmf/fonts/afm/public/lm/lmbx10.afm 
usr/share/fonts/X11/Type1/lmbx10.afm

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#905880: tex-gyre: contains X11 fonts but does not run update-fonts-* in postinst nor dep on xfonts-utils

[Paul Wise]

Source: tex-gyre
Version: 20180621-1
Severity: minor

The tex-gyre package contains X11 fonts but does not run update-fonts-*
from the postinst nor does it depend on xfonts-utils. Consequently the
installed fonts are not registered properly with the X11 fonts system.

The issue is caused by the X11 fonts being symlinks installed by
dh_link and the dh_installxfonts command being run before the symlinks
are installed into the package, so it thinks there are no fonts present.

PS: I think you can drop the defoma stuff for buster.

$ grep -EC3 'dh_installxfonts|dh_link' debian/rules 
dh_testroot
dh_clean

# We will call dh_link only once for the build, with all desired links
# specified in $(PKG).links because it is much faster than spawning
# a dh_link (actually, Perl) process for every symbolic link in this
# package. So, $(PKG).links starts as an empty file and (target, link)
# pairs will be added to it in the relevant places.
: > "debian/$(PKG).links"
--
  "debian/$(PKG).fontlist-x11" >> "debian/$(PKG).links"

dh_install
dh_installxfonts
dh_installtex --package=$(PKG) mapfile=debian/tex-gyre.cfg

$(foreach PPP, $(PKG) $(PKGFONTS), \
  dh_link -p $(PPP) \
$(foreach FAM, $(FAMILYNAMES), \
  usr/share/texmf/doc/fonts/tex-gyre/README-TeX-Gyre-$(FAM).txt \
  usr/share/doc/$(PPP)/README-TeX-Gyre-$(FAM).txt) \
--

usr/share/texmf/doc/fonts/tex-gyre-math/README-TeX-Gyre-DejaVu-Math.txt \
usr/share/doc/$(PPP)/README-TeX-Gyre-DejaVu-Math.txt \
  ; )
dh_link -p $(PKGFONTS) \
etc/fonts/conf.avail/65-$(PKGFONTS).conf \
etc/fonts/conf.d/65-$(PKGFONTS).conf

$ grep -ri usr/share/font
doc/fonts/tex-gyre-math/INSTALL.txt:copy the font file to ~/.fonts or 
/usr/share/fonts ). If the font
debian/sed_scripts/gen-x-fonts-links-list:s@^\(.*\)$@usr/share/texmf/fonts/type1/public/tex-gyre/\1.pfb
 usr/share/fonts/X11/Type1/\1.pfb\
debian/sed_scripts/gen-x-fonts-links-list:usr/share/texmf/fonts/afm/public/tex-gyre/\1.afm
 usr/share/fonts/X11/Type1/\1.afm@p

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#905735: emacs-goodies-el: postinst failure due to missing lcomp.el

[Nicholas D Steeves]

Hi Sebastian,

On Thu, Aug 09, 2018 at 06:09:29PM -0500, Sebastian P. Luque wrote:
> On Wed, 8 Aug 2018 22:50:16 -0400,
> Nicholas D Steeves  wrote:
> 
> [...]
> 
> > It is highly probable that this bug occurred due to breaking changes
> > introduced with emacsen-common 3.0.2, rather than from removal of this
> > file.
> 
> But I have emacsen-common 2.0.8 installed as per the report.

Exactly.  Upgrading between goodies-old_version (built with 2.0.8) and
goodies-new_version (built with 3.0.2) fails when emacsen-common_3.0.2
is not first installed.  This is why emacs-goodies-el_40.1 now depends
on emacsen-common_3.0.2.

> >> -- System Information: Debian Release: buster/sid APT prefers testing
> >> APT policy: (990, 'testing'), (300, 'unstable') Architecture: amd64
> >> (x86_64) Foreign Architectures: i386
> 
> > I see you're mixing testing and unstable.  Are you willing to test an
> > upgrade to unversioned emacs?  It would be a valuable data-point to
> > solving this emacs-goodies-el bug!  If so, please use the following
> > procedure:
> 
> > # This bit returns goodies to the state it was for Stretch
> > apt purge --autoremove emacs-goodies-el
> > wget 
> > https://snapshot.debian.org/archive/debian/20161122T032842Z/pool/main/e/emacs-goodies-el/emacs-goodies-el_36.3_all.deb
> > # this next line might be paranoia
> > apt autoremove --purge
> > # and finally install the package
> > dpkg -i emacs-goodies-el_36.3_all.deb
> 
> > # This installs emacs-goodies-el from stretch, and will pull in the
> > new unversioned emacs.  Please note the list of packages, in case you
> > need to roll back.
> > apt install emacs-goodies-el=40.1
> 
> The last step failed for me:

My apologies, I failed to account for pinning priorities.  If you
wouldn't mind, would you please retry that series again, but instead
of a last step of "apt install emacs-goodies-el=40.1" try "apt install
-t unstable emacs-goodies-el=40.1"?

> ------
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  emacs-goodies-el : Depends: emacsen-common (>= 3.0.2) but 2.0.8 is to be 
> installed
> Recommends: elpa-bm but it is not installable
> E: Unable to correct problems, you have held broken packages.
> ------
> 
> But succeeded by letting it choose my default testing version of the
> package (40.0):

That makes sense.  See explanation above.

> ------
> $ sudo aptitude safe-upgrade 
> The following packages will be upgraded: 
>   emacs-goodies-el 
> 1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0 B/96.4 kB of archives. After unpacking 3,177 kB will be freed.
> Do you want to continue? [Y/n/?] y
> Reading changelogs... Done   
> (Reading database ... 682251 files and directories currently installed.)
> Preparing to unpack .../emacs-goodies-el_40.0_all.deb ...
> Remove emacs-goodies-el for emacs25
> remove/emacs-goodies-el: purging byte-compiled files for emacs25
> Unpacking emacs-goodies-el (40.0) over (36.3) ...
> Processing triggers for install-info (6.5.0.dfsg.1-4) ...
> Setting up emacs-goodies-el (40.0) ...
> Install emacsen-common for emacs25
> emacsen-common: Handling install of emacsen flavor emacs25
> Install emacs-goodies-el for emacs25
> install/emacs-goodies-el: Handling emacs25, logged in /tmp/elc_b2o0sx.log
> Building autoloads for emacs25 in 
> /usr/share/emacs25/site-lisp/emacs-goodies-el
> install/emacs-goodies-el: Deleting /tmp/elc_b2o0sx.log
>  
> Current status: 0 (-1) upgradable.
> ------
> 
> Thank you for your quick follow-up and hopefully this is useful.

You're welcome!  Thank you, yes, this has been unexpectedly useful!
If my previous working hypothesis was correct, then upgrading from
goodies 36.3 to 40.0 without emacsen-common-3.0.2 should fail, but
this didn't occur!

Consequently, it would seem that only upgrades from goodies 39.0 to
40.0 without emacsen-common-3.0.2 are affected.  Unfortunately 39.0
isn't doesn't seem to be available anymore, so I'm not sure how to
test this unless someone has a cached version
  https://snapshot.debian.org/binary/emacs-goodies-el

Thank you for confirming emacs-goodies-el stable2testing succeeds.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#905877: regression in 1.4: upgrades random packages from testing to experimental (doesn't respect pinning?)

[Paul Wise]

Package: unattended-upgrades
Version: 1.4
Severity: serious

Recently I have had unattended-upgrades upgrade random packages from
testing to experimental. If I downgrade the packages upgraded, I won't
get the same packages upgraded the next day. I run apt-show-versions
daily and save the output to my mail store. Using my mail store I found
that the first instance of this happening was on 2018-07-06, there were
earlier instances but they were from me manually installing packages
from experimental and u-u doing subsequent upgrades. I noticed that I
upgraded unattended-upgrades on that date from 1.3 to 1.4. I'm not
sure, but the changelog indicates some package candidate changes,
perhaps this caused the issue? I think this bug should be fixed before Debian 
releases buster, this could break some setups.

$ notmuch search --output files --format text0 subject:apt-show-versions AND 
experimental | xargs -0 grep -Zl ^+.*/experimental | xargs -0 grep ^Date:
grep: /home/pabs/mail/cur/1533911695.H364727P6217.chianamo:2,: No such file or 
directory
/home/pabs/mail/.archives.chianamo/cur/1533738479.H931450P19950.chianamo:2,S:Date:
 Wed, 08 Aug 2018 22:27:59 +0800
/home/pabs/mail/.archives.chianamo/cur/1533452480.H469089P20113.chianamo:2,S:Date:
 Sun, 05 Aug 2018 15:01:20 +0800
/home/pabs/mail/.archives.chianamo/cur/1532469048.H39195P10262.chianamo:2,S:Date:
 Wed, 25 Jul 2018 05:50:47 +0800
/home/pabs/mail/.archives.chianamo/cur/1532009473.H904807P26370.chianamo:2,S:Date:
 Thu, 19 Jul 2018 22:11:13 +0800
/home/pabs/mail/.archives.chianamo/cur/1531406466.H36620P31910.chianamo:2,S:Date:
 Thu, 12 Jul 2018 22:41:05 +0800
/home/pabs/mail/.archives.chianamo/cur/1531318643.H907159P2397.chianamo:2,S:Date:
 Wed, 11 Jul 2018 22:17:23 +0800
/home/pabs/mail/.archives.chianamo/cur/1531231937.H239897P6579.chianamo:2,S:Date:
 Tue, 10 Jul 2018 22:12:17 +0800
/home/pabs/mail/.archives.chianamo/cur/1531145728.H178673P15461.chianamo:2,S:Date:
 Mon, 09 Jul 2018 22:15:28 +0800
/home/pabs/mail/.archives.chianamo/cur/1530973747.H830435P12225.chianamo:2,S:Date:
 Sat, 07 Jul 2018 22:29:07 +0800
/home/pabs/mail/.archives.chianamo/cur/1530887497.H217865P26358.chianamo:2,S:Date:
 Fri, 06 Jul 2018 22:31:36 +0800
/home/pabs/mail/.archives.chianamo/cur/1528812402.H467547P3507.chianamo:2,S:Date:
 Tue, 12 Jun 2018 22:06:42 +0800
/home/pabs/mail/.archives.chianamo/cur/1528121929.H964004P25155.chianamo:2,S:Date:
 Mon, 04 Jun 2018 22:18:49 +0800
/home/pabs/mail/.archives.chianamo/cur/1527948341.H185749P9358.chianamo:2,S:Date:
 Sat, 02 Jun 2018 22:05:41 +0800
/home/pabs/mail/.archives.chianamo/cur/1527863815.H640051P20918.chianamo:2,S:Date:
 Fri, 01 Jun 2018 22:36:55 +0800
...

$ which-pkg-broke unattended-upgrades | grep -C3 'Jul *6'
libpython3.6-stdlib:amd64  Sun Jul  1 13:07:11 2018
python3.6-minimal  Sun Jul  1 13:07:14 2018
libpython3.6-minimal:amd64 Sun Jul  1 13:07:19 2018
unattended-upgradesFri Jul  6 21:03:10 2018
install-info   Sat Jul  7 12:22:43 2018
libapt-pkg5.0:amd64Mon Jul 16 15:38:37 2018
libapt-inst2.0:amd64   Mon Jul 16 15:38:43 2018

$ zgrep -B2 -A1 unattended-upgrades /var/log/apt/history.log.1.gz 
Start-Date: 2018-07-06  21:03:00
Requested-By: pabs (1000)
Upgrade: unattended-upgrades:amd64 (1.3, 1.4)
End-Date: 2018-07-06  21:03:21

unattended-upgrades (1.4) unstable; urgency=medium
...
  * Adjust candidates only for packages to be possibly installed
(Closes: #892028, #899366) (LP: #1396787)

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  gir1.2-glib-2.01.56.1-1
ii  lsb-base   9.20170808
ii  lsb-release9.20170808
ii  powermgmt-base 1.33
ii  python33.6.5-3
ii  python3-apt1.6.2
ii  python3-gi 3.28.2-1+b1
ii  ucf3.0038
ii  xz-utils   5.2.2-1.3

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-24
ii  cron [cron-daemon]  3.0pl1-130

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20160123cvs-4
ii  exim4-daemon-light [mail-transport-agent]  4.91-6
ii  needrestart3.3-1

-- debconf information:
* unatte

Bug#905878: notmuch: manuals use – option prefix in documentation instead of --

[Paul Wise]

Package: notmuch
Version: 0.27-2
Severity: minor
File: /usr/share/man/man1/notmuch-address.1.gz
File: /usr/share/man/man1/notmuch-compact.1.gz
File: /usr/share/man/man1/notmuch-dump.1.gz
File: /usr/share/man/man1/notmuch-reply.1.gz
File: /usr/share/man/man1/notmuch-restore.1.gz
File: /usr/share/man/man1/notmuch-search.1.gz
File: /usr/share/man/man1/notmuch-show.1.gz

The notmuch manuals use the en dash (–) option prefix in documentation
instead of the double dash (--). The former does not work when being
copy-pasted to the command-line but the latter does. I'm guessing this
is either a bug in rst2man or in the source files for the manual pages.

$ dpkg -L notmuch | grep /usr/share/man/ | xargs zgrep –
/usr/share/man/man1/notmuch-address.1.gz:neither –output=sender nor 
–output=recipients is
/usr/share/man/man1/notmuch-address.1.gz:given, –output=sender is implied.
/usr/share/man/man1/notmuch-address.1.gz:messages. This is not applicable with 
–output=count.
/usr/share/man/man1/notmuch-address.1.gz:piping the –deduplicate=no output to 
\fBsort | uniq\fP, except
/usr/share/man/man1/notmuch-address.1.gz:matching messages. If –output=count is 
specified, include all
/usr/share/man/man1/notmuch-address.1.gz:However, if either –output=count or 
–deduplicate=address is
/usr/share/man/man1/notmuch-compact.1.gz:\fBnotmuch\fP \fBcompact\fP [–quiet] 
[–backup=<\fIdirectory\fP>]
/usr/share/man/man1/notmuch-dump.1.gz:\fBnotmuch\fP \fBdump\fP [–gzip] 
[–format=(batch\-tag|sup)] [–output=<\fIfile\fP>] [–] [<\fIsearch\-term\fP> …]
/usr/share/man/man1/notmuch-dump.1.gz:the database will be generated. A “–” 
argument instructs notmuch that
/usr/share/man/man1/notmuch-reply.1.gz:with –format=json and –format=sexp), and 
on successful
/usr/share/man/man1/notmuch-restore.1.gz:\fBnotmuch\fP \fBrestore\fP 
[–accumulate] [–format=(auto|batch\-tag|sup)] [–input=<\fIfilename\fP>]
/usr/share/man/man1/notmuch-search.1.gz:the search terms, either one per line 
(–format=text),
/usr/share/man/man1/notmuch-search.1.gz:separated by null characters 
(–format=text0), as a JSON array
/usr/share/man/man1/notmuch-search.1.gz:(–format=json), or an S\-Expression 
list (–format=sexp).
/usr/share/man/man1/notmuch-search.1.gz:terms, either one per line 
(–format=text), separated by null
/usr/share/man/man1/notmuch-search.1.gz:characters (–format=text0), as a JSON 
array (–format=json),
/usr/share/man/man1/notmuch-search.1.gz:or as an S\-Expression list 
(–format=sexp).
/usr/share/man/man1/notmuch-search.1.gz:terms, either one per line 
(–format=text), separated by null
/usr/share/man/man1/notmuch-search.1.gz:characters (–format=text0), as a JSON 
array (–format=json),
/usr/share/man/man1/notmuch-search.1.gz:or as an S\-Expression list 
(–format=sexp).
/usr/share/man/man1/notmuch-search.1.gz:limited with the –duplicate=N option). 
This may be
/usr/share/man/man1/notmuch-search.1.gz:terms, either one per line 
(–format=text), separated by null
/usr/share/man/man1/notmuch-search.1.gz:characters (–format=text0), as a JSON 
array (–format=json),
/usr/share/man/man1/notmuch-search.1.gz:or as an S\-Expression list 
(–format=sexp).
/usr/share/man/man1/notmuch-show.1.gz:\fBraw\fP (default if –part is given)
/usr/share/man/man1/notmuch-show.1.gz:supported with –format=json and 
–format=sexp), and the
/usr/share/man/man1/notmuch-show.1.gz:with –format=json and –format=sexp) and 
on successful
/usr/share/man/man1/notmuch-show.1.gz:If –entire\-thread is specified then 
complete threads are returned
/usr/share/man/man1/notmuch-show.1.gz:supported with –format=json and 
–format=sexp). By default,

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages notmuch depends on:
ii  libc6   2.27-5
ii  libglib2.0-02.56.1-2
ii  libgmime-3.0-0  3.2.0-1
ii  libnotmuch5 0.27-2
ii  libtalloc2  2.1.14-1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages notmuch recommends:
ii  alot 0.7-1
ii  elpa-notmuch 0.27-2
ii  gnupg-agent  2.2.9-1
ii  gpg-agent [gnupg-agent]  2.2.9-1
ii  gpgsm2.2.9-1
ii  notmuch-mutt 0.27-2

notmuch suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#892854: Hostname resolution getting stuck for many seconds

[Matthijs van Duin]

On 10 August 2018 at 18:50, Simon McVittie  wrote:
> Which nss-mdns version are you using?

0.14.1-1

> What's in the hosts: line in your /etc/nsswitch.conf?

I currently have:
hosts:  files mymachines mdns_minimal resolve [!UNAVAIL=return] dns 
myhostname

but I also tried some variations. The delay simply occurs once it hits
the mdns_minimal module.

> I suspect that you and Eduard might be experiencing different issues
> that have the same high-level symptom (delays in name resolution).

Oops, I think you're right.  While quickly scanning through the bug
report it seemed to match, but I somehow managed to overlook that it
was resolved for the original poster, I thought the issue was still
open for him.  My sincere apologies!


> This effectively disables the code that tries to avoid interfering with
> a .local domain if one exists in normal (non-multicast) DNS, so it's
> likely to solve problems for some people but cause problems for others.

Yes I didn't mean to imply this is a valid solution, it simply
confirms that this particular code is indeed responsible for the delay
for me (and provides a workaround for me, since I personally don't
care about this feature).


> time host -t SOA debian.org.
> time host -t SOA local.

The first works, the second hangs for 10 seconds until
;; connection timed out; no servers could be reached

However, I'm using systemd-resolved and /etc/resolv.conf points to its
stub resolver.  If I ask the upstream dns server instead, I do get a
prompt answer.  So, it would seem that the bug actually lies in
systemd-resolved.

Matthijs

Bug#905875: linux-image-amd64 outdated in jessie-backports

[Ivan Baldo]

Package: linux-image-amd64
Version: 4.9+80+deb9u4~bpo8+1
Severity: normal
Tags: security

In Jessie Backports, linux-image-amd64 4.9+80+deb9u4~bpo8+1 depends on linux-
image-4.9.0-0.bpo.6-amd64.
A newer linux-image-amd64 should be backported to depend on linux-
image-4.9.0-0.bpo.7-amd64 which currently has version 4.9.110-1~deb8u1.
Thanks a lot!!!



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

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

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.9.0-0.bpo.6-amd64  4.9.88-1+deb9u1~bpo8+1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#905876: APT::Get::List-Cleanup also affects /var/lib/apt/lists/partial

[積丹尼 Dan Jacobson]

Package: apt
Version: 1.7.0~alpha2
File: /usr/bin/apt-get

People using a shared between e.g., amd64 and i386 architectures should set
APT::Get::List-Cleanup false;

But it turns out this has the ugly side effect of also not cleaning up
# ls /var/lib/apt/lists/partial
which gets filled with junk forever and should have a separate option.
Else the disk will eventually be unusable.

Bug#905874: libreoffice: No input of accented characters through dead-key composition

[Mario L. Epp]

Package: libreoffice
Version: 1:5.2.7-1+deb9u4
Severity: important

Dear Maintainer,

   * What led up to the situation?

After reinstalling Debian 9.5 on my main workstation, accented characters in
would not appear in Writer when I used the dead keys on the "Spanish" keyboard
layout. Previously I had been using Debian 8 without any problems. I am using
KDE as GUI. The problem  manifested also in Calc. Though other applications had
no problem.

On a secondary computer I upgraded from Debian 8 to Debian 9 with the standard
aplications in KDE. And here I observed the same problem of the accented
characters not showing up when composed with the dead keys.

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

First I closed and restarted LibreOffice: Same problem.
Then I logged out and back in: Same problem.
Then I rebooted the whole system: Problem continues.

I added several other keyboard layouts, with no solution to the problem. Apart
from my normal "Spanish" layout, I tried the US-QWERTY and the German layouts.

I can insert the accented characters with the "Special Character" feature. But
when typing text, that is NOT a workable workaround.

   * What was the outcome of this action?

No solution so far. So far all other aplications have no problem with dead-key-
composition.

   * What outcome did you expect instead?

Input the accented characters for different languages without having to do menu
and dialog acrobatics, instead of the standard dead-key-composition.


On researching the issue prior to making this report, I found this issue
reported on the DocumentFoundation Bugzilla as "Bug 112770" at
. But I am not
shure how to implement the solution from 6.0.0 to 5.2.7.2 for KDE5 on Debian 9.



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

Kernel: Linux 4.9.0-7-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en (charmap=locale: Cannot set LC_ALL to default locale: 
No such file or directory
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libreoffice depends on:
ii  dpkg   1.18.25
ii  fonts-dejavu   2.37-1
ii  libreoffice-avmedia-backend-gstreamer  1:5.2.7-1+deb9u4
ii  libreoffice-base   1:5.2.7-1+deb9u4
ii  libreoffice-calc   1:5.2.7-1+deb9u4
ii  libreoffice-core   1:5.2.7-1+deb9u4
ii  libreoffice-draw   1:5.2.7-1+deb9u4
ii  libreoffice-impress1:5.2.7-1+deb9u4
ii  libreoffice-java-common1:5.2.7-1+deb9u4
ii  libreoffice-math   1:5.2.7-1+deb9u4
ii  libreoffice-report-builder-bin 1:5.2.7-1+deb9u4
ii  libreoffice-writer 1:5.2.7-1+deb9u4
ii  python3-uno1:5.2.7-1+deb9u4

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-1
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-linuxlibertine5.3.0-2
ii  fonts-sil-gentium-basic 1.1-7
ii  libreoffice-librelogo   1:5.2.7-1+deb9u4
ii  libreoffice-nlpsolver   0.9+LibO5.2.7-1+deb9u4
ii  libreoffice-ogltrans1:5.2.7-1+deb9u4
ii  libreoffice-pdfimport   1:5.2.7-1+deb9u4
ii  libreoffice-report-builder  1:5.2.7-1+deb9u4
ii  libreoffice-script-provider-bsh 1:5.2.7-1+deb9u4
ii  libreoffice-script-provider-js  1:5.2.7-1+deb9u4
ii  libreoffice-script-provider-python  1:5.2.7-1+deb9u4
ii  libreoffice-sdbc-postgresql 1:5.2.7-1+deb9u4
ii  libreoffice-wiki-publisher  1.2.0+LibO5.2.7-1+deb9u4

Versions of packages libreoffice suggests:
ii  cups-bsd   2.2.1-8+deb9u2
ii  default-jre [java5-runtime]2:1.8-58
pn  gstreamer1.0-libav 
pn  gstreamer1.0-plugins-bad   
ii  gstreamer1.0-plugins-base  1.10.4-1
ii  gstreamer1.0-plugins-good  1.10.4-1
pn  gstreamer1.0-plugins-ugly  
ii  hunspell-de-at [hunspell-dictionary]   20161207-1
ii  hunspell-de-de-frami [hunspell-dictionary] 1:5.2.5-1
ii  hunspell-en-us [hunspell-dictionary]   20070829-7
ii  hunspell-es [hunspell-dictionary]  1:5.2.5-1
ii  hunspell-pt-br [hunspell-dictionary]   1:5.2.5-1
ii  hyphen-de [hyphen-hyphenation-patterns]1:5.2.5-1
ii  hyphen-en-us [hyphen-hyphenation-patterns] 2.8.8-5
ii  hyphen-es [hyphen-hyphenation-patterns]1:5.2.5-1
ii  hyphen-pt-br [hyphen-hyphenation-

Bug#905393:

[Paul Wise]

On Fri, 2018-08-10 at 10:40 +0200, Thomas Lange wrote:

> OK, we have ONE person that still likes newsgroups.

Correction, one person that likes newsgroups, follows www.debian.org
bug reports and is up-to-date on their reading. The intersection of those sets 
of people is unlikely to be large.

> Can we remove the outdated newsgroups?

Seems reasonable to me but I'm unable to judge which should be removed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#905873: debootstrap: trusty and xenial not included in merged-usr blacklist

[Randy Goldenberg]

Package: debootstrap
Version: 1.0.106
Severity: normal
Tags: patch

Dear Maintainer,

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

debootstrap 1.0.106 installs a merged-usr file system by default.  Distros that 
do not use a merged-usr file system are blacklisted in 
/usr/share/debootstrap/scripts/.  /usr/share/debootstrap/scripts/trusty and 
/usr/share/debootstrap/scripts/xenial are symlinked to 
/usr/share/debootstrap/scripts/gutsy.  The script for gutsy does not include 
trusty and xenial as distros blacklisted for merged-usr file system deployment. 
 Consequently, merged-usr file systems are set up, resulting in failure when 
installation of non-merged-usr packages is attempted.  Below please find patch 
to blacklist trusty and xenial from merged-usr file system deployment.

--- gutsy.a 2018-08-10 14:37:30.569331851 -0700
+++ gutsy.b 2018-08-10 14:32:24.633067670 -0700
@@ -68,7 +68,7 @@ work_out_debs () {
 first_stage_install () {
case "$CODENAME" in
# "merged-usr" blacklist for past releases
-   
gutsy|hardy|intrepid|jaunty|karmic|lucid|maverick|natty|oneiric|precise|quantal|raring|saucy|utopic|vivid|wily|yakkety|zesty|artful|bionic|cosmic)
+   
gutsy|hardy|intrepid|jaunty|karmic|lucid|maverick|natty|oneiric|precise|quantal|raring|saucy|trusty|utopic|vivid|wily|xenial|yakkety|zesty|artful|bionic|cosmic)
[ -z "$MERGED_USR" ] && MERGED_USR="no"
;;
*)

Bug#905750: RFS: elpy/1.23.0-1

[Nicholas D Steeves]

Hi Chris,

Thank you for sponsoring and reviewing!  Reply follows inline.

On Thu, Aug 09, 2018 at 08:06:43AM +0100, Chris Lamb wrote:
> For your wishlist/TODO:
> 
>  * Please fix "wrong-section-according-to-package-name" on your next
>upload (or otherwise fix Lintian).

This is currently an Informational level message.  When it was a
Warning I declared Section: lisp, even though I do not believe that
this is accurate.

Re: fixing Lintian, this will require a discussion and a more clear
definition of Section: lisp.  Most Emacs modes should probably be in
Section: editors, because they are interactive extensions to an
editor.  Magit is definitely in the right section eg: vcs.  Emacs
packages that enable IDE modes should be in Section: devel.

Section: lisp should be reserved for libraries like dash-el.

>  * You should probably avoid building the documentation too if the
>nodocs build profile is enabled.

I've added it to my TODO and will start learning about how to do
this.

>  * gzip -9 might need to be gzip -9n for a reproducible build
>(unchecked) but I'm surprised it's not compressed by another tool
>too (unchecked).

Thank you for pointing this out.  I've reverted @commit:9095c18
because README.rst is only 2.8k and dh_compress already does the
right thing automatically; that is to say, README.rst is not
"larger than 4k in size" and should not be compressed.

On the topic of reproducibility, generating an info page made Elpy
unreproducible!
  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/elpy.html

This will take time to look into.  Possibilities are:
  1) sphinx-build is at fault
  2) makeinfo is at fault
  3) something is missing how I'm using 1 and/or 2.
 - if this is the case then it's also a case of incomplete
   documentation

Sincerely,
Nicholas


signature.asc
Description: PGP signature

Bug#905872: py3compile exception regex doesn't seem to work as expected

[Dererk]

Package: python3-minimal
Severity: normal


Hi.
I was trying to avoid py3compile hook on some files of a package, mainly
since they provide no usability on a device that storage is quite poor.
Following py3compile manpage and jinja2 examples, It seems that the
exception is not working as expected:

root  aether[~]$ echo
're|-3.7|/usr/lib/python3/dist-packages/scipy|\w+/tests/.*.py' >
/usr/share/python3/bcep/python3-scipy.bcep

root  aether[~]$ ls -la
/usr/lib/python3/dist-packages/scipy/stats/tests/test_mstats_basic.py
/usr/lib/python3/dist-packages/scipy/stats/tests/test_tukeylambda_stats.py
ls: cannot access
'/usr/lib/python3/dist-packages/scipy/stats/tests/test_mstats_basic.py':
No such file or directory
ls: cannot access
'/usr/lib/python3/dist-packages/scipy/stats/tests/test_tukeylambda_stats.py':
No such file or directory

root  aether[~]$ PYCOMPILE_DEBUG=1 py3compile -p python3-scipy -v D:
py3compile:226: argv: ['/usr/bin/py3compile', '-p', 'python3-scipy', '-v']
D: py3compile:227: options: {'verbose': True, 'force': False,
'optimize': False, 'package': 'python3-scipy', 'vrange': None,
'regexpr': None}
D: py3compile:228: args: []
[Errno 2] No such file or directory:
'/usr/lib/python3/dist-packages/scipy/stats/tests/test_mstats_basic.py'
[Errno 2] No such file or directory:
'/usr/lib/python3/dist-packages/scipy/stats/tests/test_tukeylambda_stats.py'
[Errno 2] No such file or directory:
'/usr/lib/python3/dist-packages/scipy/stats/tests/test_mstats_basic.py'
[Errno 2] No such file or directory:
'/usr/lib/python3/dist-packages/scipy/stats/tests/test_tukeylambda_stats.py'


Is this expected behaviour, to try to open files for compiling even
though they are excluded?

What am I missing?


Thanks in advance,

Dererk

-- 
BOFH excuse #154:

You can tune a file system, but you can't tune a fish (from most tunefs man 
pages)

Bug#852397: Problem resolved with latest Cygwin Xorg server

[Paul Ausbeck]

I recently tested connecting to Debian Stretch from Debian Jessie via XDMCP and 
had no problems. That and the passage of time led me to look to see if a newer 
Xorg server was available from Cygwin and there was. I just downloaded the 
latest Cygwin Xorg server, version 1.20, and it connects to Debian Stretch via 
XDMCP just fine. Therefore, I consider the problem to now be resolved.

Bug#905868: ffmpeg fails autopkgtest on ppc64el

[James Cowgill]

Control: reassign -1 gcc-8 8.2.0-3
Control: severity -1 normal
Control: retitle -1 gcc-8: miscompiles vec_sl at -O3 with -fwrapv on ppc64el
Control: affects -1 src:ffmpeg
Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86731
Control: tags -1 upstream

Hi,

On 10/08/18 23:54, Simon Quigley wrote:
> Package: ffmpeg
> Severity: important
> 
> Attached is the most recent autopkgtest failure log against the new
> ffmpeg release in Ubuntu.

I managed to debug this issue during DebConf and I think it is a gcc-8
regression. I filed this upstream bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86731

> I don't believe this is an Ubuntu-only issue.

The bug only happens when -O3 is passed and this only happens on Ubuntu
so this bug is Ubuntu specific. I suggest Ubuntu temporarily patches
ffmpeg to strip the -O3 option and pass -O2 instead. Alternatively you
could try rewriting the broken code (in libavcodec/ppc/fdctdsp.c) to
avoid the miscompilation.

James



signature.asc
Description: OpenPGP digital signature

Bug#905856: firefox-esr: Firefox no longer honors locales for the date in "View Page Info"

[Vincent Lefevre]

On 2018-08-10 20:44:59 +0200, Vincent Lefevre wrote:
> I have:
> 
> LANG=POSIX
> LANGUAGE=
> LC_CTYPE=en_US.UTF-8
> LC_NUMERIC="POSIX"
> LC_TIME=en_DK
> LC_COLLATE=POSIX
> LC_MONETARY="POSIX"
> LC_MESSAGES="POSIX"
> LC_PAPER="POSIX"
> LC_NAME="POSIX"
> LC_ADDRESS="POSIX"
> LC_TELEPHONE="POSIX"
> LC_MEASUREMENT="POSIX"
> LC_IDENTIFICATION="POSIX"
> LC_ALL=
> 
> i.e. en_DK for LC_TIME, but I get with "View Page Info", e.g.
> 
>   July 14, 2018, 3:59:40 PM
> 
> which does not follow the locale at all.

Upstream says:

  The date format should absolutely follow whatever the default date
  format for the locale is.

in https://bugzilla.mozilla.org/show_bug.cgi?id=140814#c2

This was probably this bug:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1308329

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#905198: python-ldap-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Pierre-Elliott Bécue]

Le 10 août 2018 23:27:02 GMT+02:00, Andreas Beckmann  a écrit :
>Hi Pierre,
>
>On 2018-08-10 18:01, Pierre-Elliott Bécue wrote:
>> I tried to fix that in a separate branch on salsa[1], see
>specifically
>> commit 988d4f6[2]. Unfortunately, although I followed all the steps
>I'm
>> aware of, `sudo piuparts -d stretch -d buster
>> python-ldap-dbg_3.1.0-3_amd64.deb python-ldap_3.1.0-3_amd64.deb`
>still
>> returns the same error.
>
>3.1.0-3 sounds wrong if sid has only 3.1.0-1
>
>In the .maintscript you want the version 3.1.0-3~ since you also want
>to
>fix this on upgrades from the buggy versions that didn't do
>symlink_to_dir. (or -2~ if you plan to upload it as -2)
>
>The piuparts options --testdebs-repo, --bindmount and
>--distupgrade-to-testdebs might be helpful to test upgrading from
>stretch directly to the new packages (and then use -a python-ldap-dbg,
>don't pass .deb files).
>If it isn't clear from the documentation, a plain directory with *.deb
>and the corresponding Packages file (from dpkg-scanpackages . >
>Packages) can be given to both --testdebs-repo and --bindmount, no need
>to fiddle with a 'deb [trusted=yes] file://' prefix and ' ./' suffix
>for
>--testdebs-repo.   
>
>
>
>Andreas

Dear Andreas,

Indeed, the repo has a 3.1.0-2 tag but no upload was done. I fixed all this.

I'm not a DD yet, only a DM. Can you review and upload the latest version 
that's in salsa ?

https://salsa.debian.org/python-team/modules/python-ldap

Thanks !
-- 
PEB

Bug#905871: mailman-suite: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: mailman-suite
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#905870: ledgersmb: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: ledgersmb
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#905869: lxc-create fails creating ubuntu-bionic containers on stable/stretch

[Karl Goetz]

Package: lxc
Version: 1:2.0.7-2+deb9u2


Required setup:
* Stable install (Stretch)
* LXC 1:2.0.7-2+deb9u2
* Debootstrap 1.0.89
* Ubuntu Bionic debootstrap script

> root@mainserver:/usr/share/debootstrap/scripts# ls -lh $PWD/bionic 
> lrwxrwxrwx 1 root root 5 Aug 10 11:25 /usr/share/debootstrap/scripts/bionic 
> -> gutsy



When trying to bootstrap a new Ubuntu Bionic container the lxc-ubuntu
template fails to move a file that looks suspiciously like an upstart
config file (which is no longer used in Ubuntu)

> root@mainserver:/var/log/lxc# /usr/bin/lxc-create --name tendenci11-combined 
> --template ubuntu --bdev dir --logfile 
> /var/log/lxc/lxc-tendenci11-combined.log --logpriority INFO -- --release 
> bionic
> lxc-create: lxccontainer.c: lxc_container_new: 4151 Error: 
> tendenci11-combined creation was not completed
> Checking cache download in /var/cache/lxc/bionic/rootfs-amd64 ... 
> Copy /var/cache/lxc/bionic/rootfs-amd64 to 
> /var/lib/lxc/tendenci11-combined/rootfs ... 
> Copying rootfs to /var/lib/lxc/tendenci11-combined/rootfs ...
> Generating locales (this might take a while)...
>   en_AU.UTF-8... done
> Generation complete.
> mv: cannot stat '/var/lib/lxc/tendenci11-combined/rootfs/etc/init/ssh.conf': 
> No such file or directory
> lxc-create: lxccontainer.c: create_run_template: 1297 container creation 
> template for tendenci11-combined failed
> lxc-create: tools/lxc_create.c: main: 318 Error creating container 
> tendenci11-combined


Guarding the file moves with if statements works for me allowing me to
deploy Bionic hosts:


root@mainserver:/usr/share/lxc/templates# diff -ruNa lxc-ubuntu{-backup,}
--- lxc-ubuntu-backup   2018-08-10 11:41:25.920662559 +
+++ lxc-ubuntu  2018-08-10 11:42:18.865713548 +
@@ -153,9 +153,9 @@
 chmod +x $rootfs/usr/sbin/policy-rc.d

 rm -f $rootfs/etc/ssh/ssh_host_*key*
-mv $rootfs/etc/init/ssh.conf $rootfs/etc/init/ssh.conf.disabled
+if [ -x $rootfs/etc/init/ssh.conf ]; then mv
$rootfs/etc/init/ssh.conf $rootfs/etc/init/ssh.conf.disabled; fi
 DPKG_MAINTSCRIPT_PACKAGE=openssh DPKG_MAINTSCRIPT_NAME=postinst
chroot $rootfs /var/lib/dpkg/info/openssh-server.postinst configure
-mv $rootfs/etc/init/ssh.conf.disabled $rootfs/etc/init/ssh.conf
+if [ -x $rootfs/etc/init/ssh.conf.disabled ]; then mv
$rootfs/etc/init/ssh.conf.disabled $rootfs/etc/init/ssh.conf; fi

 sed -i "s/root@$(hostname)/root@$hostname/g"
$rootfs/etc/ssh/ssh_host_*.pub


Would be good to see a fix (that or something from upstream) so we can
deploy future OS' on stable.

thanks,
Karl.



signature.asc
Description: OpenPGP digital signature

Bug#831850: All templates are passwordless

[Karl Goetz]

Hi,
A quick line to note that all templates are now root passwordless. I
updated wiki to mention that.

https://wiki.debian.org/LXC?action=diff&rev1=155&rev2=156

Looks like I forgot the link to upstream/salsa to wiki but its easy
enough to find when you know the version.

Wiki suggests the same method as README.Debian.

https://wiki.debian.org/LXC#root_passwords

Karl.



signature.asc
Description: OpenPGP digital signature

Bug#885016: Closed Bug

[Soren Stoutner]

Ben,

This bug is titled "firmware-realtek: Missing firmware rtlwifi: rtl8822be".  
It was closed when firmware was added to enable Bluetooth on the chip.  
However, as the title of the bug specified "rltwifi" and neither the title nor 
the body of the bug report says anything about Bluetooth, it seemed to me that 
it was closed inappropriately.

However, I can see your point that I could be experiencing a different issue.  
Perhaps the correct firmware is present and just isn't being loaded for some 
reason.  As such, I have opened a new bug report:

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

Thank you.

-- 
Soren Stoutner
Small Business Tech Solutions
623-262-6169
so...@smallbusinesstech.net

Bug#905867: firmware-realtek: Wi-Fi does not work on rtl8822be but Bluetooth does

[Soren Stoutner]

Package: firmware-realtek
Version: 20180518-1
Severity: normal

Dear Maintainer,

The recent update of the firmware-realtek package added support for the 
rtl8822be chipset.  Bluetooth now works but Wi-Fi doesn't.
Dmesg doesn't even indicate the they system attempts to load the Wi-Fi firmware.

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

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

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.132

-- no debconf information

Bug#905866: uscan: prefers watch files from a random dir over debian/watch

[Adam Borowski]

Package: devscripts
Version: 2.18.3
Severity: normal

Hi!
If the upstream source includes some bad debian packaging, it's likely
there'll be a watch file somewhere, usually bogus and/or stale.
For this reason, source format 3.0 deletes /debian/ from inside the
tarball -- and if the upstream packaging lives in a non-standard places,
that's harmless as no tool has bogus ideas like searching elsewhere.
Other than uscan, that is.

If there's a bad watch file, let's say source/debian/watch, uscan will
randomly (based on filesystem order?) prefer that over debian/watch.

Source format 3.0 (quilt) doesn't allow deleting files sanely: it ignores
deletions, assuming that the clean target will delete them before build. 
This works for anything that calls debian/rules targets, but not for uscan.
Thus, I'd need to repack the .orig tarball just to workaround this.

This is similar to #895982 (uscan looking for debian/changelog in VCS) dirs.

What's even the purpose of search for watch and changelog in places other
than debian/ ?


Meow.
-- Package-specific info:

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

--- ~/.devscripts ---
DEBCHANGE_RELEASE_HEURISTIC=log
DEBSIGN_KEYID=FD9CE2D8D7754B78AB279BBD2C3B436FEAC68101
DSCVERIFY_KEYRINGS="~/.gnupg/pubring.gpg"

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

Kernel: Linux 4.18.0-rc7-debug-00037-gda205b923a99 (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#905865: armagetronad: sometimes fails to start, often fails to actually quit

[Francesco Poli (wintermute)]

Package: armagetronad
Version: 0.2.8.3.4-2
Severity: normal

Hello!

I've just installed armagetronad: thanks for maintaining it in Debian!
I am experiencing a weird behavior, though.

The first time I started the game from an xterm, I obtained the following
output:

  A$ armagetronad
  Trying to start sound. Just restart Armagetron Advanced in case of crash.

and then nothing happened for a long time. The process armagetronad.real
was running, but nothing was apparently happening.
Hitting [Ctrl+C] was useless. Until I decided to kill the process from
another xterm:

  B$ killall -KILL armagetronad.real 

Of course, the effect on the first xterm was:

  ^C^C^C^CKilled

At the second try, I obtained the same output:

  A$ armagetronad
  Trying to start sound. Just restart Armagetron Advanced in case of crash.

but, this time, the game started and was playable (and enjoyable!).
The weird behavior is that, after playing for a while, I selected
"Exit game" and I was brought back to my desktop session, as expected,
but the process did not actually exit and I failed to get my prompt back
on the xterm. Until I had to kill the process from another xterm:

  B$ killall -KILL armagetronad.real 

Once again, the effect on the first xterm was:

  Killed

On the third try, I got no output regarding sound, but I again had to kill
the process, after exiting from the game:

  A$ armagetronad
  Killed

On the fourth and fifth tries, the game again failed to start:

  A$ armagetronad
  ^CKilled

On the sixth try, the game started and exited without issues:

  A$ armagetronad
  A$

On the seventh and eighth tries, the game again failed to start:

  A$ armagetronad
  ^CKilled

On the ninth try, the game again failed to quit, but this time I could
kill it with [Ctrl+C]:

  A$ armagetronad
  ^C

And so forth...


Please investigate the issues and fix this bug.
Thanks for your time, bye!


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

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
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 armagetronad depends on:
ii  armagetronad-common 0.2.8.3.4-2
ii  libc6   2.27-5
ii  libgcc1 1:8.2.0-3
ii  libgl1  1.0.0+git20180308-3
ii  libgl1-mesa-glx 18.1.5-1
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libpng16-16 1.6.34-2
ii  libsdl-image1.2 1.2.12-8
ii  libsdl1.2debian 1.2.15+dfsg2-1
ii  libstdc++6  8.2.0-3
ii  libxml2 2.9.4+dfsg1-7+b1

armagetronad recommends no packages.

armagetronad suggests no packages.

-- no debconf information

Bug#905864: Ubuntu trusty and xenial are installed with merged-/usr by default

[Derek Poon]

Package: debootstrap
Version: 1.0.106
Tags: patch

Since debootstrap 1.0.102, merged-/usr installs are the default, except when 
installing blacklisted suites.  The blacklist was established in 
https://salsa.debian.org/installer-team/debootstrap/commit/4a1b3ca, whose 
commit message says:

Set non merged-usr release

We do not apply merged-usr until Debian stretch and Ubuntu cosmic.

However, the actual blacklist is (from scripts/gutsy):

case "$CODENAME" in

…|quantal|raring|saucy|utopic|vivid|wily|yakkety|zesty|artful|bionic|cosmic)

Note that trusty and xenial are missing.  This causes their installation to 
fail due to file conflicts in certain packages.

My speculation is that the omission was due to a copy-paste error from line 4 
of scripts/gutsy.






From: Derek Poon 
Date: Fri, 10 Aug 2018 14:47:05 -0700
Subject: [PATCH] Added trusty and xenial to merged-/usr blacklist

The blacklist should include all Ubuntu releases up to cosmic.
---
 scripts/gutsy | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/gutsy b/scripts/gutsy
index b460e90..82c59c5 100644
--- a/scripts/gutsy
+++ b/scripts/gutsy
@@ -68,7 +68,7 @@ work_out_debs () {
 first_stage_install () {
case "$CODENAME" in
# "merged-usr" blacklist for past releases
-   
gutsy|hardy|intrepid|jaunty|karmic|lucid|maverick|natty|oneiric|precise|quantal|raring|saucy|utopic|vivid|wily|yakkety|zesty|artful|bionic|cosmic)
+   
gutsy|hardy|intrepid|jaunty|karmic|lucid|maverick|natty|oneiric|precise|quantal|raring|saucy|trusty|utopic|vivid|wily|xenial|yakkety|zesty|artful|bionic|cosmic)
[ -z "$MERGED_USR" ] && MERGED_USR="no"
;;
*)
-- 
2.17.1

Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)

[James Van Zandt]

Awesome, thanks!

On Fri, Aug 10, 2018, 5:27 PM Alexis Murzeau  wrote:

> On 09/08/2018 00:22, Alexis Murzeau wrote:
> > On 08/08/2018 00:59, Alexis Murzeau wrote:
> >> severity 903514 important
> >> thanks
> >>
> >>> Reassigning to glibc with affects on openblas and gimp as this is
> caused
> >>> by a deadlock inside glibc.
> >>
> >> Done.
> >>
> >> Lowering severity as this does not render any package unusable by
> >> themselves, but only a combination of them (GIMP + OpenBLAS).
> >>
> >> I think a workaround solution against GIMP OpenBLAS should be done as
> >> I'm not sure a good solution will emerge in glibc given attempts done in
> >> the past. The work to be done seems non trivial.
> >>
> >> My though on possible solutions:
> >>  * Add a breaks between GIMP and OpenBLAS
> >>  * Disable TLS in OpenBLAS build (if possible, but this would cause a
> >> performance loss for users that use OpenBLAS without gimp)
> >>  * Add a delay in GIMP to not load then close libraries too fast (so
> >> OpenBLAS threads are fully initialized when dl_close is called on it)
> >>
> >
> > Hi,
> >
> > I've posted a issue on openblas upstream project [0] and they suggested
> > some solutions.
> > One of them is to disable the use of compiler supported TLS and instead
> > use pthreads.
> >
> > I tested this and it seems to fix deadlocks while starting gimp (I tried
> > without arguments, with a non existing file and with an existing file).
> >
> > I've pushed a merge request with the patch at [1].
> > I've also asked openblas upstream if this patch could be a good solution.
> >
> > In that case would it be possible to have this patch tested for ones who
> > have major instabilities with gimp + openblas ?
> >
> > Thanks :)
> >
>
> Hi,
>
> I've updated the merge request [0] with the upstream proposed patch [1].
>
> @openblas maintainers, maybe someone can build a package with this patch
> and upload to experimental so others can check if gimp works fine with it ?
>
> I've myself tested it and gimp does not deadlock.
>
> I can provide a binary package that include this patch, but I'm not sure
> this is the best thing to do (I'm not the official maintainer, nor know
> a good place to upload it).
>
> [0] https://salsa.debian.org/science-team/openblas/merge_requests/1
> [1] https://github.com/xianyi/OpenBLAS/pull/1726
>
> --
> Alexis Murzeau
> PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F
>
>

Bug#904256: chromium does not load Debian packaged webext extensions

[Martin Steigerwald]

Hi!

Neither your suggestion nor:

% /usr/share/doc/webext-ublock-origin> cat chromium.d/load_extensions 
export CHROMIUM_FLAGS="${CHROMIUM_FLAGS} --load-extension=`ls -dm /usr/
share/chromium/extensions/*|tr -d '\n'`"

makes Chromium 68.0.3440.75-2 load the extension for me.

However Chromium also does not load HTTPS Everywhere, installed as 
Debian package.

So I keep them installed from plugin store, with the following work-
around to make that possible, for now:

% cat /etc/chromium.d/extensions 
# remote extensions on by default
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --enable-remote-extensions"

According to manpage of chromium it does not support "--load-extension" 
at all. Also "chromium --help" does not show this option.

I would like the Debian packaged version of uBlock Origin also in 
Chromium.

Thanks,
-- 
Martin

Bug#903743: Should opennebula be removed?

[Moritz Mühlenhoff]

reassign 903743 ftp.debian.org
retitle 903743 RM: RoQA: opennebula - unmaintained, RC-buggy, not in stable
severity 903743 normal
thanks

On Fri, Jul 13, 2018 at 11:23:35PM +0200, Moritz Muehlenhoff wrote:
> Source: opennebula
> Severity: grave
> 
> Should opennebula be removed?
> 
> - No maintainer upload since 2015
> - RC-buggy due to OpenSSL 1.1
> - Already missed stretch
> 
> Unless there are any objections/fixes, I'd reassign this to ftp.debian.org 
> for removal in a few weeks.

No objections for a month, reassigning.

Cheers,
Moritz

Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)

[Alexis Murzeau]

On 09/08/2018 00:22, Alexis Murzeau wrote:
> On 08/08/2018 00:59, Alexis Murzeau wrote:
>> severity 903514 important
>> thanks
>>
>>> Reassigning to glibc with affects on openblas and gimp as this is caused
>>> by a deadlock inside glibc.
>>
>> Done.
>>
>> Lowering severity as this does not render any package unusable by
>> themselves, but only a combination of them (GIMP + OpenBLAS).
>>
>> I think a workaround solution against GIMP OpenBLAS should be done as
>> I'm not sure a good solution will emerge in glibc given attempts done in
>> the past. The work to be done seems non trivial.
>>
>> My though on possible solutions:
>>  * Add a breaks between GIMP and OpenBLAS
>>  * Disable TLS in OpenBLAS build (if possible, but this would cause a
>> performance loss for users that use OpenBLAS without gimp)
>>  * Add a delay in GIMP to not load then close libraries too fast (so
>> OpenBLAS threads are fully initialized when dl_close is called on it)
>>
> 
> Hi,
> 
> I've posted a issue on openblas upstream project [0] and they suggested
> some solutions.
> One of them is to disable the use of compiler supported TLS and instead
> use pthreads.
> 
> I tested this and it seems to fix deadlocks while starting gimp (I tried
> without arguments, with a non existing file and with an existing file).
> 
> I've pushed a merge request with the patch at [1].
> I've also asked openblas upstream if this patch could be a good solution.
> 
> In that case would it be possible to have this patch tested for ones who
> have major instabilities with gimp + openblas ?
> 
> Thanks :)
> 

Hi,

I've updated the merge request [0] with the upstream proposed patch [1].

@openblas maintainers, maybe someone can build a package with this patch
and upload to experimental so others can check if gimp works fine with it ?

I've myself tested it and gimp does not deadlock.

I can provide a binary package that include this patch, but I'm not sure
this is the best thing to do (I'm not the official maintainer, nor know
a good place to upload it).

[0] https://salsa.debian.org/science-team/openblas/merge_requests/1
[1] https://github.com/xianyi/OpenBLAS/pull/1726

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#905198: python-ldap-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Hi Pierre,

On 2018-08-10 18:01, Pierre-Elliott Bécue wrote:
> I tried to fix that in a separate branch on salsa[1], see specifically
> commit 988d4f6[2]. Unfortunately, although I followed all the steps I'm
> aware of, `sudo piuparts -d stretch -d buster
> python-ldap-dbg_3.1.0-3_amd64.deb python-ldap_3.1.0-3_amd64.deb` still
> returns the same error.

3.1.0-3 sounds wrong if sid has only 3.1.0-1

In the .maintscript you want the version 3.1.0-3~ since you also want to
fix this on upgrades from the buggy versions that didn't do
symlink_to_dir. (or -2~ if you plan to upload it as -2)

The piuparts options --testdebs-repo, --bindmount and
--distupgrade-to-testdebs might be helpful to test upgrading from
stretch directly to the new packages (and then use -a python-ldap-dbg,
don't pass .deb files).
If it isn't clear from the documentation, a plain directory with *.deb
and the corresponding Packages file (from dpkg-scanpackages . >
Packages) can be given to both --testdebs-repo and --bindmount, no need
to fiddle with a 'deb [trusted=yes] file://' prefix and ' ./' suffix for
--testdebs-repo.



Andreas

Bug#905863: RM: bugsx -- RoQA; RC_buggy, unmaintained, dead upstream, unused

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Hi,
please remove bugsx. It's RC-buggy since 3.5 years, upstream has vanished,
it was missed the last stable release, it's unmaintained (last maintainer
upload in 2010) and unused per popcon.

Cheers,
Moritz

Bug#859675: radsecproxy: Please migrate to openssl1.1 in Buster

[Moritz Mühlenhoff]

On Wed, Apr 05, 2017 at 09:56:21PM +0200, Sebastian Andrzej Siewior wrote:
> Package: radsecproxy
> Version: 1.6.7-1
> Severity: important
> Tags: sid buster fixed-upstream
> User: pkg-openssl-de...@lists.alioth.debian.org
> Usertags: openssl-1.1-trans
> control: forwarded -1 https://project.nordu.net/browse/RADSECPROXY-66
> 
> Please migrate to libssl-dev in the Buster cycle. The bug report about
> the FTBFS is #828527. The log of the FTBFS can be found at
>   
> https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/radsecproxy_1.6.7-1_amd64-20160529-1530

I've been going through the remaining OpenSSL 1.1 bugs and radsecproxy
appears to have been fixed in the latest 1.7.1 upstream release.

Cheers,
Moritz

Bug#905198: python-ldap-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Pierre-Elliott Bécue]

Control: tags -1 + pending

Le vendredi 10 août 2018 à 18:22:12+0200, Pierre-Elliott Bécue a écrit :
> Le vendredi 10 août 2018 à 18:01:11+0200, Pierre-Elliott Bécue a écrit :
> > Le mercredi 01 août 2018 à 14:23:42+0200, Andreas Beckmann a écrit :
> > > [python-ldap-dbg is a bad boy]
> > [not working properly]
> [Not so relevant stuff about multiarch]

Ok, found, thanks to mentors.

The package is ready. It'll be uploaded soon.

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


signature.asc
Description: PGP signature

Bug#905861: RM: pavuk -- RoQA; dead upstream, RC-buggy, alternatives exist

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Hi,
please remove pavuk. Noone objected to my proposed removal
in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859540#19
for almost three months. Quoting in full:

| Let's just remove it, the version currently in the archive has virtually no
| users according to popcon, was released a decade ago by upstream and
| there's a plethora of alternative download managers in the archive.

Cheers,
Moritz

Bug#905862: RM: sslscan -- RoQA; incompatible with OpenSSL 1.1, won't get ported

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Hi,
please remove sslscan. The package is unmaintained and incompatible with 
OpenSSL 1.1
(and upstream has indicated that they won't port it to 1.1 in
https://github.com/rbsec/sslscan/issues/108)

Cheers,
Moritz

Bug#904382: python3-doublex: fails to install with Python 3.7

[Pierre-Elliott Bécue]

Le mardi 24 juillet 2018 à 11:01:42+0200, David Villa a écrit :
> Hi Andreas:
> 
> I just fixed this issue with this module and it's available in the upstream
> repository [1]. Unfortunately when the Debian Python Modules Team changed the
> package building system to git-buildpackage, I stopped maintaining my packages
> for Debian. I have not had time to understand and apply the new system. I 
> would
> appreciate some help in making the conversion to the new package building
> system. 
> 
> Thank you

Hi David,

I'll be happy to help you.

What exactly would you like me to do? Explain the steps to go to
git-buildpackage? Do the work, commit & let you review? Someting else?

Cheers!

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


signature.asc
Description: PGP signature

Bug#905827: Buster on Dell XPS 15 9570

[Ben Hutchings]

On Fri, 2018-08-10 at 12:21 +0200, Geert Stappers wrote:
[...]
> Changed boot mode to
>   1) Legacy External Device Boot Mode, Secure Boot OFF
[...]

This sounds like BIOS emulation, which is not really recommended on
current UEFI systems.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that
everything doesn't happen at once.



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

Bug#905860: libgpars-groovy-java build depends on libnetty-3.9-java

[Adrian Bunk]

Source: libgpars-groovy-java
Version: 1.2.1-9
Severity: serious
Control: block 888255 by -1

libgpars-groovy-java build depends on libnetty-3.9-java,
which is scheduled for removal (see #888255).

Bug#905859: async-http-client build depends on libnetty-3.9-java

[Adrian Bunk]

Source: async-http-client
Version: 1.6.5-5
Severity: serious
Control: block 888255 by -1

async-http-client build depends on libnetty-3.9-java,
which is scheduled for removal (see #888255).

Bug#905858: osmosis build depends on libnetty-3.9-java

[Adrian Bunk]

Source: osmosis
Version: 0.46-5
Severity: serious
Control: block 888255 by -1

osmosis build depends on libnetty-3.9-java,
which is scheduled for removal (see #888255).

Bug#904368: panoramisk: diff for NMU version 1.0-1.1

[Adrian Bunk]

Control: tags 904368 + patch
Control: tags 904368 + pending

Dear maintainer,

I've prepared an NMU for panoramisk (versioned as 1.0-1.1) and uploaded 
it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

diff -Nru panoramisk-1.0/debian/changelog panoramisk-1.0/debian/changelog
--- panoramisk-1.0/debian/changelog	2016-10-04 20:05:37.0 +0300
+++ panoramisk-1.0/debian/changelog	2018-08-10 23:47:57.0 +0300
@@ -1,3 +1,11 @@
+panoramisk (1.0-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Add upstream fix for compatibility with Python 3.7.
+(Closes: #904368)
+
+ -- Adrian Bunk   Fri, 10 Aug 2018 23:47:57 +0300
+
 panoramisk (1.0-1) unstable; urgency=medium
 
   * Initial release. (Closes: #829504)
diff -Nru panoramisk-1.0/debian/patches/0001-python3.7-support-68.patch panoramisk-1.0/debian/patches/0001-python3.7-support-68.patch
--- panoramisk-1.0/debian/patches/0001-python3.7-support-68.patch	1970-01-01 02:00:00.0 +0200
+++ panoramisk-1.0/debian/patches/0001-python3.7-support-68.patch	2018-08-10 23:47:50.0 +0300
@@ -0,0 +1,31 @@
+From 2deada71295fe6c04564a52edf075c164c55942a Mon Sep 17 00:00:00 2001
+From: Quentin Dawans 
+Date: Fri, 20 Jul 2018 15:20:06 +0200
+Subject: python3.7 support (#68)
+
+Index: panoramisk-1.0/panoramisk/actions.py
+===
+--- panoramisk-1.0.orig/panoramisk/actions.py
 panoramisk-1.0/panoramisk/actions.py
+@@ -61,7 +61,7 @@ class Action(utils.CaseInsensitiveDict):
+ return True
+ elif msg.startswith('added') and msg.endswith('to queue'):
+ return True
+-elif msg.endswith('successfully queued') and self.async != 'false':
++elif msg.endswith('successfully queued') and self['async'] != 'false':
+ return True
+ elif self.as_list:
+ return True
+Index: panoramisk-1.0/panoramisk/manager.py
+===
+--- panoramisk-1.0.orig/panoramisk/manager.py
 panoramisk-1.0/panoramisk/manager.py
+@@ -209,7 +209,7 @@ class Manager(object):
+ ret = callback(self, event)
+ if (asyncio.iscoroutine(ret) or
+ isinstance(ret, asyncio.Future)):
+-asyncio.async(ret, loop=self.loop)
++asyncio.ensure_future(ret, loop=self.loop)
+ return matches
+ 
+ def close(self):
diff -Nru panoramisk-1.0/debian/patches/series panoramisk-1.0/debian/patches/series
--- panoramisk-1.0/debian/patches/series	2016-09-18 16:21:01.0 +0300
+++ panoramisk-1.0/debian/patches/series	2018-08-10 23:46:24.0 +0300
@@ -1 +1,2 @@
 0001-hardcode-version-in-docs-since-package-not-yet-insta.patch
+0001-python3.7-support-68.patch

Bug#903527: python-motor: diff for NMU version 1.2.3-1.1

[Adrian Bunk]

Control: tags 903527 + patch
Control: tags 903527 + pending

Dear maintainer,

I've prepared an NMU for python-motor (versioned as 1.2.3-1.1) and 
uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

diff -Nru python-motor-1.2.3/debian/changelog python-motor-1.2.3/debian/changelog
--- python-motor-1.2.3/debian/changelog	2018-05-29 14:30:50.0 +0300
+++ python-motor-1.2.3/debian/changelog	2018-08-10 23:31:48.0 +0300
@@ -1,3 +1,11 @@
+python-motor (1.2.3-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Add upstream fix for compatibility with Python 3.7.
+(Closes: #903527)
+
+ -- Adrian Bunk   Fri, 10 Aug 2018 23:31:48 +0300
+
 python-motor (1.2.3-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru python-motor-1.2.3/debian/patches/0001-MOTOR-248-Don-t-use-async-as-variable-name.patch python-motor-1.2.3/debian/patches/0001-MOTOR-248-Don-t-use-async-as-variable-name.patch
--- python-motor-1.2.3/debian/patches/0001-MOTOR-248-Don-t-use-async-as-variable-name.patch	1970-01-01 02:00:00.0 +0200
+++ python-motor-1.2.3/debian/patches/0001-MOTOR-248-Don-t-use-async-as-variable-name.patch	2018-08-10 23:25:42.0 +0300
@@ -0,0 +1,49 @@
+From aced74e749bd22efdeef891e1f345ec1923403ae Mon Sep 17 00:00:00 2001
+From: "A. Jesse Jiryu Davis" 
+Date: Wed, 27 Jun 2018 22:47:48 -0400
+Subject: MOTOR-248 Don't use "async" as variable name
+
+In Python 3.7, "async" becomes a full-fledged keyword.
+---
+ motor/frameworks/asyncio/__init__.py | 5 -
+ test/asyncio_tests/__init__.py   | 6 +-
+ 2 files changed, 1 insertion(+), 10 deletions(-)
+
+diff --git a/motor/frameworks/asyncio/__init__.py b/motor/frameworks/asyncio/__init__.py
+index 098f24c..21bb3f0 100644
+--- a/motor/frameworks/asyncio/__init__.py
 b/motor/frameworks/asyncio/__init__.py
+@@ -26,11 +26,6 @@ import functools
+ import multiprocessing
+ from concurrent.futures import ThreadPoolExecutor
+ 
+-try:
+-from asyncio import ensure_future
+-except ImportError:
+-from asyncio import async as ensure_future
+-
+ CLASS_PREFIX = 'AsyncIO'
+ 
+ 
+diff --git a/test/asyncio_tests/__init__.py b/test/asyncio_tests/__init__.py
+index b5ed7b9..05d8642 100644
+--- a/test/asyncio_tests/__init__.py
 b/test/asyncio_tests/__init__.py
+@@ -20,13 +20,9 @@ import gc
+ import inspect
+ import os
+ import unittest
++from asyncio import ensure_future
+ from unittest import SkipTest
+ 
+-try:
+-from asyncio import ensure_future
+-except ImportError:
+-from asyncio import async as ensure_future
+-
+ from mockupdb import MockupDB
+ 
+ from motor import motor_asyncio
+-- 
+2.11.0
+
diff -Nru python-motor-1.2.3/debian/patches/series python-motor-1.2.3/debian/patches/series
--- python-motor-1.2.3/debian/patches/series	1970-01-01 02:00:00.0 +0200
+++ python-motor-1.2.3/debian/patches/series	2018-08-10 23:31:48.0 +0300
@@ -0,0 +1,2 @@
+0001-MOTOR-248-Don-t-use-async-as-variable-name.patch
+

Bug#905801: wwwconfig-common: script directly accesses internal dpkg database

[Ola Lundqvist]

Hi

Thank you for the report. I have checked the archives and it looks like it
is just one package that actually use wwwconfig-common and then not this
script. This is a good thing because then I may finally be able to remove
this package altogether.

// Ola

On 10 August 2018 at 01:41, Guillem Jover  wrote:

> Source: wwwconfig-common
> Source-Version: 0.3.0
> Severity: important
> User: debian-d...@lists.debian.org
> Usertags: dpkg-db-access-blocker
>
> Hi!
>
> This package contains a script that directly accesses the dpkg
> internal database [S], instead of using the correct public interface
> such as «dpkg-query --showformat '${db:Status-Status} ${Package}\n'
> --show 'php?.?-*'|grep '^installed '» (also notice that the current
> glob will not match current php packages in the archive with N.M
> versioning, although perhaps the code should instead be dropped?).
>
>   [S] php-extensions.sh
>
> This a problem for multiple reasons. Even though the layout and format
> of the dpkg database is administrator friendly, and it's expected that
> those might need to mess with it, in case of emergency, this interface
> does not extend to other programs besides the dpkg suite of tools. The
> admindir can also be configured differently at dpkg build or run-time.
> And finally, the contents and its format, will be changing in the near
> future.
>
> Thanks,
> Guillem
>



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

Bug#904652: pulseaudio: looses device and replace it with dummy package so no sound possible

[Felipe Sateler]

(Please keep the bug in CC)
On Fri, Aug 10, 2018 at 4:06 PM Meinolf Gödde  wrote:

> Hi,
>
> Here is the output.
>
> Hope you can find a hint.
>
> Greetings
>

Unfortunately it is not useful unless it is a log of the problem occurring.

Saludos


>
> Meinolf
>
> Am 07.08.2018 17:39 schrieb Felipe Sateler:
> > On Sat, Jul 28, 2018 at 8:24 AM Charlemagne Lasse <
> > charlemagnela...@gmail.com> wrote:
> >
> >> found 904652 11.1-5
> >> thanks
> >>
> >> > i didn't do anything.
> >> > Upgrading the system like always.
> >> > Suddenly there was no sound available.
> >>
> >> Change /etc/pulse/default.pa to automatically load module-alsa-sink on
> >> boot (module-udev-detect is broken and will not load the alsa-sink
> >> anymore)
> >>
> >> This is also a problem in buster (which is still using 11.1-5)
> >>
> >
> > Seems like pulseaudio is not starting. Please attach the output of
> > `pulseaudio - --daemonize=no`, without applying your workaround.



-- 

Saludos,
Felipe Sateler

Bug#902788: python3-minimal needs Breaks for software/modules broken by 3.7

[Adrian Bunk]

Control: reopen -1

On Tue, Jul 03, 2018 at 05:21:29AM +0200, Matthias Klose wrote:
> Control: reassign -1 python3.7
> 
> On 30.06.2018 22:58, Adrian Bunk wrote:
> > Package: python3-minimal
> > Version: 3.6.6-1
> > Severity: serious
> > Control: block -1 by 902757 902631 902766 902646 902715 902650
> > Control: block 902582 by -1
> > 
> > Plenty of packages fail to work or even install with Python 3.7
> > for reasons like 'async' now being a keyword.
> > 
> > python3-minimal needs Breaks for against all versions of other
> > packages in stretch or buster that don't work with 3.7.
> 
> if at all, python3.7 needs these breaks, not the dependency packages.

It is actually python3.7-minimal that needs them, and they should be 
moved there:

# apt-get install python3-motor
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following package was automatically installed and is no longer required:
  python3.7-minimal
Use 'apt autoremove' to remove it.
Suggested packages:
  python3-aiohttp
The following packages will be REMOVED:
  python3-all python3-all-dev python3-coverage python3-hypothesis
  python3-numpy python3.7 python3.7-dev
The following NEW packages will be installed:
  python3-motor
0 upgraded, 1 newly installed, 7 to remove and 0 not upgraded.
Need to get 0 B/45.6 kB of archives.
After this operation, 17.6 MB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 797869 files and directories currently installed.)
Removing python3-all-dev (3.6.6-1) ...
Removing python3-all (3.6.6-1) ...
Removing python3-hypothesis (3.44.1-2) ...
Removing python3-coverage (4.5.1+dfsg.1-1) ...
Removing python3-numpy (1:1.14.5-1+b1) ...
Removing python3.7-dev (3.7.0-4) ...
Removing python3.7 (3.7.0-4) ...
Selecting previously unselected package python3-motor.
(Reading database ... 797288 files and directories currently installed.)
Preparing to unpack .../python3-motor_1.2.3-1_all.deb ...
Unpacking python3-motor (1.2.3-1) ...
Processing triggers for mime-support (3.61) ...
Processing triggers for desktop-file-utils (0.23-3) ...
Setting up python3-motor (1.2.3-1) ...
  File "/usr/lib/python3/dist-packages/motor/frameworks/asyncio/__init__.py", 
line 32
from asyncio import async as ensure_future
^
SyntaxError: invalid syntax

dpkg: error processing package python3-motor (--configure):
 installed python3-motor package post-installation script subprocess returned 
error exit status 1
Processing triggers for man-db (2.8.4-2) ...
Errors were encountered while processing:
 python3-motor
E: Sub-process /usr/bin/dpkg returned an error code (1)
# 

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#905857: r-cran-scales: autopkgtest regression: there is no package called 'hms'

[Paul Gevers]

Source: r-cran-scales
Version: 1.0.0-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Since the last upload of your package the autopkgtest started to fail. I
have copied the output below.

Could you please investigate? Looking at the error it seems you need to
add a new (test) dependency. Currently this failure is contributing to
delaying the migration to testing with 13 days.

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-scales/797067/log.gz

-- 1. Error: time_format formats hms objects (@test-formatter.r#9)

there is no package called 'hms'
1: expect_equal(time_format()(hms::as.hms(a_time, tz = "UTC")),
"11:30:00") at testthat/test-formatter.r:9
2: quasi_label(enquo(object), label)
3: eval_bare(get_expr(quo), get_env(quo))
4: time_format()(hms::as.hms(a_time, tz = "UTC"))
5: hms::as.hms
6: getExportedValue(pkg, name)
7: asNamespace(ns)
8: getNamespace(ns)
9: tryCatch(loadNamespace(name), error = function(e) stop(e))
10: tryCatchList(expr, classes, parentenv, handlers)
11: tryCatchOne(expr, names, parentenv, handlers[[1L]])
12: value[[3L]](cond)

== testthat results
===
OK: 278 SKIPPED: 0 FAILED: 1
1. Error: time_format formats hms objects (@test-formatter.r#9)

Error: testthat unit tests failed
Execution halted



signature.asc
Description: OpenPGP digital signature

Bug#901701: bumblebee: using optirun introduces segfault in i965_dri.so

[Vincas Dargis]

Sadly, `PRIMUS_UPLOAD=1 primusrun glxgears` does not work any more, also 
segfaults:

Thread 2 "glxgears" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f3a8041c700 (LWP 12698)]
0x7f3a8152b2ef in do_blit_drawpixels (pixels=0x0, unpack=0x7f3a78150598, type=5121, 
format=32993, height=1080, width=1920, y=0, x=0, ctx=0x7f3a78147010)

at ../../../../../../src/mesa/drivers/dri/i965/intel_pixel_draw.c:83
83  ../../../../../../src/mesa/drivers/dri/i965/intel_pixel_draw.c: Toks failas ar aplankas 
neegzistuoja.

(gdb) bt
#0  0x7f3a8152b2ef in do_blit_drawpixels (pixels=0x0, unpack=0x7f3a78150598, type=5121, 
format=32993, height=1080, width=1920, y=0, x=0,
ctx=0x7f3a78147010) at ../../../../../../src/mesa/drivers/dri/i965/intel_pixel_draw.c:83 

#1  intelDrawPixels (ctx=0x7f3a78147010, x=0, y=0, width=1920, height=1080, format=32993, type=5121, 
unpack=0x7f3a78150598, pixels=0x0)

at ../../../../../../src/mesa/drivers/dri/i965/intel_pixel_draw.c:167
#2  0x7f3a8118039c in _mesa_DrawPixels (width=1920, height=1080, format=32993, type=5121, 
pixels=0x0) at ../../../src/mesa/main/drawpix.c:162
#3  0x7f3a86fb7345 in test_drawpixels_fast (dconfig=, ctx=0x7f3a78023ae0, 
dpy=0x7f3a78000b20) at libglfork.cpp:362

#4  display_work (vd=) at libglfork.cpp:402
#5  0x7f3a86537f2a in start_thread (arg=0x7f3a8041c700) at pthread_create.c:463 


#6  0x7f3a867e5edf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Applications can be launched only on integrated Intel graphics.

Bug#878816: stretch-pu: package lttng-modules/2.9.0-1+deb9u1

[Michael Jeanson]

Hi,

Here is an updated debdiff with a fix for an additional bug, both are
failure to build the dkms modules on recent kernels. I've also addressed
the metadata problems on #864404 to properly report the fixed version in
unstable.

Changes:

 lttng-modules (2.9.0-1+deb9u1) stable; urgency=medium

  * [ee40323] Fix build on linux-rt 4.9 kernels. (Closes: #864404)
  * [b20f74a] Fix build on >= 4.9.0-3 kernels (Closes: #889901)


Cheers,

Michael
diff -Nru lttng-modules-2.9.0/debian/changelog 
lttng-modules-2.9.0/debian/changelog
--- lttng-modules-2.9.0/debian/changelog2016-11-29 18:13:55.0 
-0500
+++ lttng-modules-2.9.0/debian/changelog2018-08-10 12:47:14.0 
-0400
@@ -1,3 +1,11 @@
+lttng-modules (2.9.0-1+deb9u1) stable; urgency=medium
+
+  * [c3d8eab] Stretch gbp branch config
+  * [ee40323] Fix build on linux-rt 4.9 kernels. (Closes: #864404)
+  * [b20f74a] Fix build on >= 4.9.0-3 kernels (Closes: #889901)
+
+ -- Michael Jeanson   Fri, 10 Aug 2018 12:47:14 -0400
+
 lttng-modules (2.9.0-1) unstable; urgency=medium
 
   * [500ac85] New upstream version 2.9.0
diff -Nru lttng-modules-2.9.0/debian/gbp.conf 
lttng-modules-2.9.0/debian/gbp.conf
--- lttng-modules-2.9.0/debian/gbp.conf 1969-12-31 19:00:00.0 -0500
+++ lttng-modules-2.9.0/debian/gbp.conf 2018-08-10 12:10:26.0 -0400
@@ -0,0 +1,3 @@
+[DEFAULT]
+upstream-branch=upstream/2.9.0
+debian-branch=debian/stretch
diff -Nru 
lttng-modules-2.9.0/debian/patches/fix-debian-kernel-version-parsing.patch 
lttng-modules-2.9.0/debian/patches/fix-debian-kernel-version-parsing.patch
--- lttng-modules-2.9.0/debian/patches/fix-debian-kernel-version-parsing.patch  
1969-12-31 19:00:00.0 -0500
+++ lttng-modules-2.9.0/debian/patches/fix-debian-kernel-version-parsing.patch  
2018-08-10 12:38:51.0 -0400
@@ -0,0 +1,66 @@
+From 671137d5cda4a7415b34246bd8842650a7c6ddd9 Mon Sep 17 00:00:00 2001
+From: Michael Jeanson 
+Date: Tue, 9 Jan 2018 15:43:19 -0500
+Subject: [PATCH] Fix: debian kernel version parsing
+
+The debian version script only worked for ckt kernels and that was fine
+until now because we only had checks for those versions in the code.
+
+ckt (Canonical Kernel Team) kernels were used for a while during the jessie
+cycle, their versionning is a bit different. They track the upstream vanilla
+stable updates but they don't update the minor version number and instead add
+an additionnal -cktX. They were all 3.16.7-cktX and after a while the version
+switched back to upstream style at 3.16.36.
+
+Knowing that, we can compare regular debian and ckt kernel versions
+using this scheme :
+
+  MAJOR.PATCHLEVEL.SUBLEVEL.CKT.DEBABI.DEBPATCH
+
+And setting CKT to zero for non-ckt kernels.
+
+Signed-off-by: Michael Jeanson 
+Signed-off-by: Mathieu Desnoyers 
+---
+ abi-debian-version.sh | 18 ++
+ 1 file changed, 10 insertions(+), 8 deletions(-)
+
+diff --git a/abi-debian-version.sh b/abi-debian-version.sh
+index 310d6a8..36da212 100755
+--- a/abi-debian-version.sh
 b/abi-debian-version.sh
+@@ -12,24 +12,26 @@ fi
+ 
+ # Assuming KPATH is the target kernel headers directory
+ DEB_PACKAGE_VERSION=$(sed -rn 's/^#define LINUX_PACKAGE_ID " Debian 
(.*)"/\1/p' ${KPATH}/include/generated/package.h)
++
+ # Ignore backports part
+ DEB_PACKAGE_VERSION=$(echo ${DEB_PACKAGE_VERSION} | sed -r 's/~(bpo|deb).*//')
++
++# ckt (Canonical Kernel Team) kernels were used for a while during the jessie
++# cycle, their versionning is a bit different. They track the upstream vanilla
++# stable updates but they don't update the minor version number and instead 
add
++# an additionnal -cktX. They were all 3.16.7-cktX and after a while the 
version
++# switched back to upstream style at 3.16.36.
++
+ # Get -ckt update number, if present
+ KERNEL_CKT_UPDATE=$(echo ${DEB_PACKAGE_VERSION} | sed -rn 
's/^[0-9]+\.[0-9]+\.[0-9]+-ckt([0-9]+).*/\1/p')
+-
+-# Only care about the rest if it is a -ckt kernel, making sure we do not
+-# clash with older Debian kernels (e.g. Debian 3.2.65-1+deb7u2).
+-if [ -z "${KERNEL_CKT_UPDATE}" ]; then
+-  echo 0
+-  exit 0
+-fi
++test -n "${KERNEL_CKT_UPDATE}" || KERNEL_CKT_UPDATE=0
+ 
+ # Get package revision
+ DEB_PACKAGE_REVISION=$(echo ${DEB_PACKAGE_VERSION} | sed -r 
's/.*-([^-]+)$/\1/')
+ # Get non-sec update number
+ DEB_PACKAGE_REVISION_BASE=$(echo ${DEB_PACKAGE_REVISION} | sed -r 
's/^([0-9]+).*/\1/')
+ # Get security update number, if present
+-DEB_PACKAGE_REVISION_SECURITY=$(echo ${DEB_PACKAGE_REVISION} | sed -rn 
's/.*\+(squeeze|deb[0-9])+u([0-9]+)$/\1/p')
++DEB_PACKAGE_REVISION_SECURITY=$(echo ${DEB_PACKAGE_REVISION} | sed -rn 
's/.*\+(squeeze|deb[0-9]+)+u([0-9]+)$/\2/p')
+ test -n "${DEB_PACKAGE_REVISION_SECURITY}" || DEB_PACKAGE_REVISION_SECURITY=0
+ # Combine all update numbers into one
+ DEB_API_VERSION=$((KERNEL_CKT_UPDATE * 1 + DEB_PACKAGE_REVISION_BASE * 
100 + DEB_PACKAGE_REVISION_SECURITY))
diff -Nru lttng-modules-2.9.0/debian/patches/fix-linux-rt-4.9-sched.patch 
lttng

Bug#905839: [pkg-go] Bug#905839: debiman: autopkgtest fails with mdocml version 1.14.4-1

[Michael Stapelberg]

control: tag -1 + pending

On Fri, Aug 10, 2018 at 2:59 PM, Michael Stapelberg 
wrote:

> This is fixed upstream in https://github.com/Debian/debiman/commit/
> 210e94b3cf101d62b74211d0866f6308c6bee4db
>
> Feel free to do what is necessary to get the fix into Debian.
>
> On Fri, Aug 10, 2018 at 2:37 PM, Paul Gevers  wrote:
>
>> Source: debiman
>> Version: 0.0~git20180711.cb414bd-2
>> X-Debbugs-CC: debian...@lists.debian.org, mdo...@packages.debian.org
>> User: debian...@lists.debian.org
>> Usertags: needs-update
>> Control: affects -1 src:mdocml
>>
>> Dear maintainers,
>>
>> Recently version 1.14.4-1 of mdocml was uploaded to the Debian archive.
>> Your autopkgtest started to fail with the error copied below.
>>
>> Could you please investigate? It seems that you are comparing generated
>> output with a reference. Looking at the text I can't spot obvious
>> mistakes (but I may be missing details), so I think you need to update
>> your reference to the new output. Please reassign this bug to mdocml if
>> you think that package has this bug instead. This regression is
>> currently delaying the migration of mdocml to unstable by 10 days, so
>> cooperation to fix this swiftly is appreciated.
>>
>> Don't forget the set the appropriate Versioned (test) depends to let
>> autopkgtest figure out which version is needed and maybe consider making
>> your tests less sensitive to this kind of changes if they shouldn't
>> delay or block other packages. If your tests aren't suitable for gating
>> other packages, you can also mark them skippable and exit 77 in case of
>> regressions.
>>
>> Paul
>>
>> https://ci.debian.net/data/autopkgtest/testing/amd64/d/debim
>> an/796100/log.gz
>>
>> 2018/08/10 05:11:23 mandocd not found, falling back to fork+exec for
>> each manpage
>> --- FAIL: TestToHTML (0.00s)
>> --- FAIL: TestToHTML/i3lock (0.01s)
>> convert_test.go:92: unexpected conversion result: (diff from want
>> →
>> got):
>> --- /tmp/debiman-314812002  2018-08-10
>> 05:11:23.148127262 +
>> +++ /tmp/debiman-841037135  2018-08-10
>> 05:11:23.148127262 +
>> @@ -7,65 +7,65 @@
>>
>>  
>>  
>> +
>> +
>>  NAME> href="#NAME">¶
>>  i3lock - improved screen locker
>> - 
>> +
>>  SYNOPSIS> href="#SYNOPSIS">¶
>>  i3lock [-v] [-c color]
>> - 
>> +
>>  DESCRIPTION> class="anchor"
>> href="#DESCRIPTION">¶
>>  i3lock is a simple screen locker like slock. After
>> starting it, you will
>>see a white screen (you can configure the color/an
>> image). You
>> can return to
>>your screen by entering your password.
>> - 
>> +
>>  IMPROVEMENTS> class="anchor"
>> href="#IMPROVEMENTS">¶
>>  
>> -  •
>> -  i3lock forks, so you can combine it
>> with an
>> alias to
>> -  suspend to RAM (run "i3lock && echo
>> mem >
>> -  /sys/power/state" to get a locked screen after
>> waking
>> up your
>> -  computer from suspend to RAM)
>> +  •
>> +  i3lock forks, so you can combine it with an alias
>> to
>> suspend to RAM (run
>> +  "i3lock && echo mem >
>> /sys/power/state"
>> to get a
>> +  locked screen after waking up your computer from
>> suspend to
>> RAM)
>>  
>>  
>> -  •
>> -  You can specify either a background
>> color or
>> a PNG image
>> -  which will be displayed while your screen is
>> locked.
>> +  •
>> +  You can specify either a background color or a PNG
>> image
>> which will be
>> +  displayed while your screen is locked.
>>  
>>  
>> -  •
>> -  You can specify whether i3lock
>> should bell
>> upon a wrong
>> -  password.
>> +  •
>> +  You can specify whether i3lock should bell upon a
>> wrong
>> password.
>>  
>>  
>> -  •
>> -  i3lock uses PAM and therefore is
>> compatible
>> with LDAP, etc.
>> - 
>> - 
>> +  •
>> +  i3lock uses PAM and therefore is compatible with
>> LDAP, etc.
>> +
>> +
>>
>>  
>>  OPTIONS> href="#OPTIONS">¶
>>  
>> -  -v, --version
>> -  Display the version of your
>> i3lock
>> - 
>> +  -v, --v

Bug#905856: firefox-esr: Firefox no longer honors locales for the date in "View Page Info"

[Vincent Lefevre]

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

I have:

LANG=POSIX
LANGUAGE=
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="POSIX"
LC_TIME=en_DK
LC_COLLATE=POSIX
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

i.e. en_DK for LC_TIME, but I get with "View Page Info", e.g.

  July 14, 2018, 3:59:40 PM

which does not follow the locale at all.

-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.6
ii  fontconfig2.12.6-0.1
ii  libasound21.1.6-1
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-5
ii  libcairo-gobject2 1.14.10-1
ii  libcairo2 1.14.10-1
ii  libdbus-1-3   1.12.10-1
ii  libdbus-glib-1-2  0.110-3
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.12.6-0.1
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:8.2.0-3
ii  libgdk-pixbuf2.0-02.36.12-1
ii  libglib2.0-0  2.56.1-2
ii  libgtk-3-03.22.30-2
ii  libgtk2.0-0   2.24.32-2
ii  libhunspell-1.6-0 1.6.2-1+b1
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.19-3
ii  libnss3   2:3.38-1
ii  libpango-1.0-01.42.1-1
ii  libsqlite3-0  3.24.0-1
ii  libstartup-notification0  0.12-5
ii  libstdc++68.2.0-3
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.5-1
ii  libx11-xcb1   2:1.6.5-1
ii  libxcb-shm0   1.13-2
ii  libxcb1   1.13-2
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.15-2
ii  zlib1g1:1.2.11.dfsg-1

firefox-esr recommends no packages.

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-3
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-6
ii  libgssapi-krb5-2   1.16-2
pn  mozplugger 

-- no debconf information

Bug#905503: networkd doesn't like fritzbox' IPv6 announcement, interface degraded

[Marc Haber]

fixed 905503 237-3~bpo9+1
fixed 905503 239-7

On Sun, Aug 05, 2018 at 03:49:37PM +0200, Marc Haber wrote:
> In the next days, I hope I will be able to reproduce this in a simpler
> test machine and then check whether the issue is still present in buster
> or sid. Sadly, it is becoming increasingly painful to run
> systemd-networkd in stretch.

I was able to reproduce this issue in stretch on an amd64 VM with the
following networkd configuration:


[Match]
Name=e*

[Network]
DHCP=Yes

The Fritzbox assigns and IPv4 address and announces an IPv6 prefix. WIth
the systemd in stretch, networkctl hangs at "degraded/failed", while the
systemd 237-3 from stretch-backports and systemd 239-7 works, resulting
in the following network configuration:

2: ens3:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether 52:54:00:a8:3e:97 brd ff:ff:ff:ff:ff:ff
inet 192.168.252.99/24 brd 192.168.252.255 scope global dynamic ens3
   valid_lft 861566sec preferred_lft 861566sec
inet6 2001:db8:3022:4100:5054:ff:fea8:3e97/64 scope global mngtmpaddr 
noprefixroute dynamic 
   valid_lft 6880sec preferred_lft 3280sec
inet6 fe80::5054:ff:fea8:3e97/64 scope link 
   valid_lft forever preferred_lft forever


default via 192.168.252.254 dev ens3 proto dhcp src 192.168.252.99 metric 1024 
192.168.252.0/24 dev ens3 proto kernel scope link src 192.168.252.99 
192.168.252.254 dev ens3 proto dhcp scope link src 192.168.252.99 metric 1024 

2001:db8:3022:4100::/64 dev ens3 proto ra metric 1024  pref medium
2001:db8:3022:4100::/56 via fe80::cece:1eff:x:y dev ens3 proto ra metric 1024  
pref medium
fe80::/64 dev ens3 proto kernel metric 256  pref medium
default via fe80::cece:1eff:x:y dev ens3 proto ra metric 1024  mtu 1492 pref 
medium

The Fritzbox is an extremely common DSL router in middle europe, and
dual-stack networking is becoming increasingly common. Deutsche Telekom
and 1&1, two of Germany's largest ISPs for consumer DSL, both provide
dual-stacked Internet. This issue should be addressed in stretch.

I'll keep the test VM around for a few months, so that I can test
tentative fixes.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#903211: release.debian.org: How to handle unbuildable packages in buster

[Santiago Vila]

> I wish I could say unconditionally yes, but I am not sure we are ready
> for it yet.  If your testing can trivially say which relation in
> Build-Depends/Build-Depends-Arch is broken, you could cross reference it
> with the [excuses] and see if they are permanently rejected due (and why).
> 
> I am not sure how feasible that is for you, but it might enable you to
> file RC bugs for a subset of the issues already now.

What I have is a bunch of build logs made by sbuild.

Those build logs always have a line at the end like this one:

E: Package build dependencies not satisfied; skipping

I could of course use grep and extract some information, but I don't
see how that would reduce the number of reports.

Let's take "diffoscope" as an example. In the build log we can see this:

The following packages have unmet dependencies:
 sbuild-build-depends-diffoscope-dummy : Depends: apktool but it is not 
installable
 Depends: oggvideotools but it is not 
installable

and later, this:
   
report:
 -
  package: sbuild-build-depends-diffoscope-dummy
  version: 0.invalid.0
  architecture: amd64
  status: broken
  reasons:
   -
missing:
 pkg:
  package: sbuild-build-depends-diffoscope-dummy
  version: 0.invalid.0
  architecture: amd64
  unsat-dependency: apktool:amd64


In which cases an unbuildable package like this one would not force us
to remove the package from buster immediately if we were to release
buster as stable tomorrow?

[ I fear that if I'm required to investigate all the issues myself,
then I will probably not report anything at all because of lack of
time. In this example, the diffoscope maintainers should be in a much
better position to investigate the issue than me ].

Would be ok, for example, to report any package which has been
unbuildable for more than one week? (or some other sensible amount of
time)

Thanks.

Bug#904045: enlightenment: no background image tiling

[Ross Vandegrift]

On Mon, Aug 06, 2018 at 11:45:41PM +0200, enno wrote:
> Thanks very much appreciate your time, tiling bg images works when I
> follow your advice, but all my screens get the same background, no
> matter if I check "only this desktop" or "only this screen".

Hmmm, I just tested with enlightenment 0.22.3-2 and this works for me:

- Import two images as tiled wallpaper
- Click Advanced in the Wallpaper Settings dialog
- Select the first wallpaper
- Select the "This Screen" option
- Click Apply
- Move the window to the other screen
- Select the second wallpaper
- Click Apply

Ross

Bug#710765: keynav startsup on CTRL+, not on CTRL+; as advertised

[Axel Beckert]

Control: tag -1 + confirmed
Control: retitle -1 keynav: startsup on CTRL+, not on CTRL+; as advertised 
(depending on chosen keyboard layout)

Thomas Koch wrote:
> on my machine (with awesome), keynav starts when I press CTRL+, not CTRL+;.

While I wasn't able to reproduce this on any of my machines (which all
have US-English keyboard layout), I just saw this on a friends machine
with Swiss-German keyboard layout.

And I assume that you have either Swiss-German or German-German
layout.

So it seems to only happen with keyboard layouts where ";" is actually
Shift-","

Will try to reflect that in the documentation.

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

Bug#905827: Buster on Dell XPS 15 9570, thunderbolt

[Geert Stappers]

On Fri, Aug 10, 2018 at 12:21:03PM +0200, Geert Stappers wrote:
> Package: installation-report
> 
> Summary: Customer did what hardware vendor should have done
> 
> The original plan was to order a XPS 15 pre-install with Linux.
> 
.. 
> 
> The Dell XPS 15 9570 now runs Debian Buster. What works:
> * the nice graphical screen
> * keyboard
> * touchpad
> * the NVMe  sdd
> * WIFI
> * and probably more  (untested yet)
> 

Thunderbolt docking station does work, initialy only in display port mode


To use wired ethernet interface and USB from the TB dock

Install the package `bolt`, plus this

root@trancilo:~# boltctl
 ● Dell Thunderbolt Cable
   ├─ type:  peripheral
   ├─ name:  Thunderbolt Cable
   ├─ vendor:Dell
   ├─ uuid:  00ed4274-2f5f-d400--
   ├─ status:connected
   │  ├─ authflags:  none
   │  └─ connected:  vr 10 aug 2018 16:43:13 UTC
   └─ stored:no

 ● Dell Thunderbolt Dock
   ├─ type:  peripheral
   ├─ name:  Thunderbolt Dock
   ├─ vendor:Dell
   ├─ uuid:  10b56968-2f5f-8680--
   ├─ status:connected
   │  ├─ authflags:  none
   │  └─ connected:  vr 10 aug 2018 16:43:14 UTC
   └─ stored:no

root@trancilo:~# boltctl enroll 00ed4274-2f5f-d400--
 ● Dell Thunderbolt Cable
   ├─ type:  peripheral
   ├─ name:  Thunderbolt Cable
   ├─ vendor:Dell
   ├─ uuid:  00ed4274-2f5f-d400--
   ├─ dbus path: 
/org/freedesktop/bolt/devices/00ed4274_2f5f_d400__
   ├─ status:authorized
   │  ├─ authflags:  none
   │  ├─ parent: c401-0080-7f18-2350-5310cc402021
   │  ├─ syspath:
/sys/devices/pci:00/:00:1b.0/:02:00.0/:03:00.0/:04:00.0/domain0/0-0/0-1
   │  ├─ authorized: vr 10 aug 2018 17:07:44 UTC
   │  └─ connected:  vr 10 aug 2018 16:43:13 UTC
   └─ stored:yes
  ├─ when:   vr 10 aug 2018 17:07:44 UTC
  ├─ policy: auto
  └─ key:no

root@trancilo:~# 
root@trancilo:~# boltctl enroll 10b56968-2f5f-8680--
 ● Dell Thunderbolt Dock
   ├─ type:  peripheral
   ├─ name:  Thunderbolt Dock
   ├─ vendor:Dell
   ├─ uuid:  10b56968-2f5f-8680--
   ├─ dbus path: 
/org/freedesktop/bolt/devices/10b56968_2f5f_8680__
   ├─ status:authorized
   │  ├─ authflags:  none
   │  ├─ parent: 00ed4274-2f5f-d400--
   │  ├─ syspath:
/sys/devices/pci:00/:00:1b.0/:02:00.0/:03:00.0/:04:00.0/domain0/0-0/0-1/0-301
   │  ├─ authorized: vr 10 aug 2018 17:09:51 UTC
   │  └─ connected:  vr 10 aug 2018 16:43:14 UTC
   └─ stored:yes
  ├─ when:   vr 10 aug 2018 17:09:51 UTC
  ├─ policy: auto
  └─ key:no

root@trancilo:~# 



Cheers
Geert Stappers
DevOps Engineer

Bug#905570: Info received (Bug#905570: fwupd: Firmware update failed on Lenovo P50)

[Mario.Limonciello]

This bug will be fixed in the fwupd 1.1.1 release.

> -Original Message-
> From: Debian Bug Tracking System [mailto:ow...@bugs.debian.org]
> Sent: Monday, August 6, 2018 7:39 AM
> To: Limonciello, Mario
> Subject: Bug#905570: Info received (Bug#905570: fwupd: Firmware update failed
> on Lenovo P50)
> 
> Thank you for the additional information you have supplied regarding
> this Bug report.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Debian EFI 
> 
> If you wish to submit further information on this problem, please
> send it to 905...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> --
> 905570: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905570
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#905772: Add interim summary

[Michael Biebl]

Am 10.08.2018 um 15:54 schrieb Felipe Sateler:
> I'm still not sure why we parse Also= for starting. Michael, do you
> remember the rationale?

I think this is simply a mistake and should be corrected.
Parsing Also= for dh_systemd_enable was done, so the tools behave
similar to how "systemctl enable foo" would behave.
I can't come up (or remember) a good idea why Also= would make sense for
the start case.


-- 
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#905772: Add interim summary

[Felipe Sateler]

On Fri, Aug 10, 2018 at 11:30 AM Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:

>
>
> On Fri, Aug 10, 2018 at 3:54 PM Felipe Sateler 
> wrote:
>
>>
>>
>> On Fri, Aug 10, 2018 at 7:42 AM Michael Biebl  wrote:
>>
>>> Am 10.08.2018 um 13:32 schrieb Christian Ehrhardt:
>>> > I think I'd want/need a "dh_systemd_start
>>> --no-dependent-services/sockets"
>>> > option to intentionally have it generate "just" for libvirt.service
>>> and not
>>> > the sockets it depends on.
>>> > As mentioned, for all of the complexity pulling in the systemd people
>>> might
>>> > help as well.
>>> > So I'm eager to see what they will reply here as well.
>>>
>>>
>>> I guess the complication arises from the fact that
>>> dh_installinit/invoke-rc.d directly handles systemd service files if the
>>> SysV init script and service file name match.
>>> dh_installsystemd only handles those unit files for which no
>>> corresponding SysV init script exists.
>>>
>>> I think the solutions for this could be, to let dh_installsystemd handle
>>> all systemd unit files.
>>> dh_installinit/invoke-rc.d on the other hand would be updated to only
>>> handle SysV init scripts.
>>>
>>> In the long run I guess this will be less confusing at is clearer which
>>> tool is responsible for which task and it makes it easier to override
>>> the behaviour in debian/rules.
>>>
>>> Felipe has been doing some initial work for enable that kind of
>>> behaviour at
>>> https://salsa.debian.org/debian/init-system-helpers/merge_requests/4
>>
>>
>> This should help, but then you get the next problem: dh_installsystemd
>> parses the Also= lines, and generates deb-systemd-invoke for all referenced
>> units.
>>
>> I think the Also= lines in libvirtd.service are superfluous and removing
>> them should avoid this problem.
>>
>> I'm still not sure why we parse Also= for starting. Michael, do you
>> remember the rationale?
>>
>
> Uh I see, you mean dropping this section from libvirtd.service right?
>
> [Install]
> WantedBy=multi-user.target
> Also=virtlockd.socket
> Also=virtlogd.socket
>
> The above is certainly worth a try - I need to check what I "loose" by
> that.
>

I'd say nothing. libvirtd.service already Requires the sockets, so they
will be pulled in anyway.

Note that the Also= lines are actively harmful. If you want to disable
automatic start at boot, and instead rely on socket activation, doing
`systemctl disable libvirtd.service` will also disable the sockets.


> I'd still need to drop virtlogd sysV script as the "invoke.rc virtlogd"
> will complain about missing dependencies (the new .socket for it can't be
> started since the service is already running).
> The dh_systemd_start generated code triggers "start" and ignores the
> retval, the dh_installinit code through invoke.rc calls start but fails
> since systemd replied "I'm running but there are dependency issues".
> Because virtlogd.service has Requires virtlogd.socket and
> virtlogd-admin.socket.
>

Yes, this is the part that could be addressed with the merge request
Michael referenced.

-- 

Saludos,
Felipe Sateler

Bug#892854: Hostname resolution getting stuck for many seconds

[Simon McVittie]

On Mon, 06 Aug 2018 at 13:41:27 +0200, Matthijs van Duin wrote:
> This problem seems to be cause by the local_soa() call in src/util.c

Which nss-mdns version are you using?

What's in the hosts: line in your /etc/nsswitch.conf?

I suspect that you and Eduard might be experiencing different issues
that have the same high-level symptom (delays in name resolution).
If that's the case, then I'll need to clone this bug for the two separate
issues. I'll also retitle the original bug to make it clearer that
it's about a specific source of delays.

On Mon, 06 Aug 2018 at 14:05:02 +0200, Matthijs van Duin wrote:
> The following patch fixes the problem for me:
> 
> diff --git c/src/util.c w/src/util.c
> index aaebd62..594ed42 100644
> --- c/src/util.c
> +++ w/src/util.c
> @@ -62,7 +62,7 @@ int verify_name_allowed_with_soa(const char* name, FILE* 
> mdns_allow_file) {
>  case VERIFY_NAME_RESULT_ALLOWED:
>  return 1;
>  case VERIFY_NAME_RESULT_ALLOWED_IF_NO_LOCAL_SOA:
> -return !local_soa();
> +return 1;
>  default:
>  return 0;
>  }

This effectively disables the code that tries to avoid interfering with
a .local domain if one exists in normal (non-multicast) DNS, so it's
likely to solve problems for some people but cause problems for others.

If you try to resolve a SOA record through your normal DNS resolver,
does that hang for a long time? These commands' output would be useful
information:

time host -t SOA debian.org.
time host -t SOA local.

If you happen to have macOS or Windows on the same LAN, it would also
be interesting to know whether they suffer similar delays for mDNS
resolution: the code disabled by the patch above is a standard heuristic
used in multiple (perhaps all) mDNS implementations, for example
 in macOS.

Thanks,
smcv

Bug#905855: ITP: qlogo -- Language using turtle graphics famous for teaching kids

[Barak A. Pearlmutter]

Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter" 

* Package name: qlogo
  Version : 0.92
  Upstream Author : Jason Sikes 
* URL : https://qlogo.org/
* License : GPL2+
  Programming Lang: C++
  Description : Language using turtle graphics famous for teaching kids

 QLogo is an interpreter for the Logo language written in C++ using
 Qt and OpenGL. Specifically, it mimics (as reasonably as possible)
 the UCBLogo interpreter developed at U.C. Berkeley. In fact, the
 UCBLogo manual describes about 99.9% of the functionality. You can
 find the UCBLogo Manual here:
 http://people.eecs.berkeley.edu/~bh/usermanual

Justification:

Basically, the ucblogo system is moribund, this is a proper clone using
somewhat modern tooling.

Bug#905198: python-ldap-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Pierre-Elliott Bécue]

Le vendredi 10 août 2018 à 18:01:11+0200, Pierre-Elliott Bécue a écrit :
> Le mercredi 01 août 2018 à 14:23:42+0200, Andreas Beckmann a écrit :
> > [python-ldap-dbg is a bad boy]
> [not working properly]

Hmmm, python-ldap-dbg is Multi-Arch: same, could it be the source of the
problem?

Cheers,

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


signature.asc
Description: PGP signature

Bug#905854: easy-rsa missing default openssl cnf for openssl 1.1

[Michael Braun]

Package: easy-rsa
Version: 2.2.2-2
Severity: minor

After make-cadir running ./vars complains about openssl.cnf is missing.
It turns out that whichopensslcnf does not detect openssl 1.1 and that there is 
no openssl 1.1 default config.
Proposed solution:
a) add version 1.1 detection to whichopensslcnf and copy openssl-1.0.cnf to 
openssl-1.1.cnf
b) provide an openssl.cnf by default which is compatible with openssl 1.1

Regards,
M. Braun

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

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

Versions of packages easy-rsa depends on:
ii  openssl  1.1.0f-3+deb9u2

Versions of packages easy-rsa recommends:
pn  opensc  

easy-rsa suggests no packages.

-- no debconf information

Bug#905853: ITP: tao-pegtl -- Parsing Expression Grammar Template Library

[Birger Schacht]

Package: wnpp
Severity: wishlist
Owner: Birger Schacht 

* Package name : tao-pegtl
  Version  : 2.7.0-1
  Upstream Author  : Dr. Colin Hirsch and Daniel Frey
* Url  : https://github.com/taocpp/PEGTL
* Licenses : MIT
  Programming Lang : C++
  Section  : libs

 The Parsing Expression Grammar Template Library (PEGTL) is a
 zero-dependency C++11 header-only parser combinator library for
 creating parsers according to a Parsing Expression Grammar (PEG).

 This is actually version 2 of
 https://tracker.debian.org/pkg/pegtl (which is version 1.3.1), but it
 is incompatible with version 1 because the file extensions changed from
 .hh to .hpp and the include path is now /usr/include/tao and thus the
 package name also changed, so me and muri (who packaged the version 1)
 figured it would be better to create a new package. There is only one
 build-dep on version 1 (usbguard), which switched to version 2 of
 tao-pegtl in its last upstream version.
 (I hope this approach is oke)

 I plan to maintain this package myself, keeping debianization in
 following Git repository:
 https://salsa.debian.org/bisco-guest/tao-pegtl

Bug#887394: Packaging Veyon (was: Re: Accepted italc 1:3.0.3+dfsg1-2 (source) into unstable)

[Mike Gabriel]

Hi Tobias,

On Thursday, August 9, 2018, Tobias Junghans wrote:
> Hi Mike,
> 
> any news on packaging Veyon for Debian? We released 4.1.1 this week and it's 
> quite a mature release which deserves being packaged for Debian before 
> feature 
> freeze.
> 
> Best regards
> 
> Tobias

It is still on my list for being uploaded to Debian before the freeze.

Sorry for the delay on my side... (paying customers come first...).

Mike
 
> Am Dienstag, 6. Februar 2018, 14:21:16 CEST schrieben Sie:
> > Hi Tobias,
> > 
> > a quick top posted mail... Can you also describe the dependency tree?
> > 
> > Master needs service and libveyon-core.
> > Configurator? Would it work standalone?
> > Master should probably recommend configurator.
> > 
> > Service needs Auth-Helper and Worker (they should be in the same package...
> > IMHO).
>  
> > veyon-ctl is useful for whom? For the PC running the Master application? Or
> > is it more useful on the PCs running the Service?
>  
> > And the Plugins? Needed on Master or on client systems running the Service?
> > 
> > Thanks, Mike 
> 
> 
> 
>

-- 
Sent from my Fairphone (powered by SailfishOS)

Bug#905852: /usr/games/sgt-solo: solo crashes when resizing

[treaki]

Package: sgt-puzzles
Version: 20170606.272beef-1
Severity: important
File: /usr/games/sgt-solo

Dear Maintainer,

* What led up to the situation?
playing solo
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
typed in a lot of hints (small numbers) in one field
resized the window vertical as small as possible (only menu bar visible)
   * What was the outcome of this action?
crash, see message below
   * What outcome did you expect instead?
no crash
$ sgt-solo sgt-solo: solo.c:5062: draw_number: Assertion `pbest > 0' failed.
Aborted

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


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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sgt-puzzles depends on:
ii  libatk1.0-0  2.26.1-3
ii  libc62.27-2
ii  libcairo-gobject21.15.10-1
ii  libcairo21.15.10-1
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.56.1-2
ii  libgtk-3-0   3.22.29-3
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1

Versions of packages sgt-puzzles recommends:
ii  chromium [www-browser] 64.0.3282.119-1~deb9u1
ii  firefox-esr [www-browser]  52.8.0esr-1
ii  khelpcenter4:17.08.3-1
ii  links [www-browser]2.14-5
ii  links2 [www-browser]   2.14-5
ii  lynx [www-browser] 2.8.9dev16-2
ii  w3m [www-browser]  0.5.3-36
ii  yelp   3.26.0-2

sgt-puzzles suggests no packages.

-- no debconf information

Bug#905198: python-ldap-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Pierre-Elliott Bécue]

Le mercredi 01 août 2018 à 14:23:42+0200, Andreas Beckmann a écrit :
> [python-ldap-dbg is a bad boy]

Hi Andreas,

I tried to fix that in a separate branch on salsa[1], see specifically
commit 988d4f6[2]. Unfortunately, although I followed all the steps I'm
aware of, `sudo piuparts -d stretch -d buster
python-ldap-dbg_3.1.0-3_amd64.deb python-ldap_3.1.0-3_amd64.deb` still
returns the same error.

I asked for some help on d-mentors IRC channel, but if you find some time,
please could you review and help me determine what my mistake is?

Cheers!

[1] https://salsa.debian.org/python-team/modules/python-ldap/tree/fix_905198
[2] 
https://salsa.debian.org/python-team/modules/python-ldap/commit/988d4f6418fb16762cd10022db2399de4c9d0438

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


signature.asc
Description: PGP signature

Bug#905393:

[Byung-Hee HWANG (황병희, 黃炳熙)]

Thanks for feedback, Steve^^^

Steve McIntyre  writes:

> On Fri, Aug 10, 2018 at 10:49:55PM +0900, Byung-Hee HWANG (황병희, 黃炳熙) wrote:
>>Thomas Lange  writes:
>>
>>> OK, we have ONE person that still likes newsgroups. But nevertheless
>>> most newsgroups (except two) are outdated and do not have useful
>>> information any more. Can we remove the outdated newsgroups?
>>>
>>> I would like to focus on less information which are up to date,
>>> instead of collecting a lot of outdated links.
>>
>>Well i think old history are valuable for people. So it is enough to add
>>label (historic) to the outdated links, i think. 
>>
>>Still removing is dangerous.
>
> No, I strongly disagree. We have way too much out-of-date stuff on the
> website, which makes it difficult for people to find useful, relevant
> information. It's way past time we cleared out.

Of course, i don't object removing on absolute useless stuff. However i
think Newsgroups/Usenet stuff are still useful resources.   

This is final feedback, thanks^^^

-- 
^고맙습니다 _地平天成_ 감사합니다_^))//

Bug#737921: WE PROVIDE BG, SBLC, MT103, POF, SKR, DISCOUNTING AND LOANS FOR YOUR PROJECTS.

[HALIFAX BANK]

Sir,

We Halifax Bank Plc provide Loans,BG,SBLC,MTN,POF,LC,SKR Discounting,Project
Funding,Letter of credit, and lots more for client all over the world.

Equally,we are ready to work with Brokers and financial consultants/consulting
firms in their respective countries.

we are equally ready to pay commission to those Brokers and financial
consultants/consulting firms.

For more information/detail contact us via E-mail:halifaxbnk...@gmail.com

Awaiting for your response.

Best Regards.

Advert Team.
Halifax Bank Plc.
244/246 High Street,Beckenham BR3 1DZ,
London, United Kingdom.

Bug#905851: add gstreamer audio backend as dependency

[cacatoes]

Package: subtitleeditor
Version: 0.54.0-3

Hello,

In order to get sound to work, I had to manualy install
gstreamer-1.0-alsa package.

Would it make sense to add a dependency to "some" audio backend ?

Had this warning when playing a video:

** (subtitleeditor:2542): WARNING **: 17:28:55.362: Impossible de créer
un GStreamer de sortie audio (alsasink). Veuillez vérifier votre
installation de GStreamer. [vp/gstplayer.cc(423): gen_audio_element ():
/gtkmm__GstPlayBin:pipeline]

Regards,

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

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

Versions of packages subtitleeditor depends on:
ii  gstreamer1.0-plugins-base   1.14.2-1
ii  gstreamer1.0-plugins-good   1.14.2-1
ii  gstreamer1.0-x  1.14.2-1
ii  libatkmm-1.6-1v52.24.2-3
ii  libc6   2.27-5
ii  libcairomm-1.0-1v5  1.12.2-3
ii  libgcc1 1:8.2.0-3
ii  libglib2.0-02.56.1-2
ii  libglibmm-2.4-1v5   2.56.0-2
ii  libgstreamer-plugins-base1.0-0  1.14.2-1
ii  libgstreamer1.0-0   1.14.2-2
ii  libgstreamermm-1.0-11.10.0+dfsg-2
ii  libgtk-3-0  3.22.30-2
ii  libgtkmm-3.0-1v53.22.2-2
ii  libpangomm-1.4-1v5  2.40.1-4
ii  libsigc++-2.0-0v5   2.10.0-2
ii  libstdc++6  8.2.0-3
ii  libsubtitleeditor0  0.54.0-3

subtitleeditor recommends no packages.

Versions of packages subtitleeditor suggests:
pn  gstreamer1.0-libav  

-- no debconf information

Bug#905772: Add interim summary

[Christian Ehrhardt]

On Fri, Aug 10, 2018 at 3:54 PM Felipe Sateler  wrote:

>
>
> On Fri, Aug 10, 2018 at 7:42 AM Michael Biebl  wrote:
>
>> Am 10.08.2018 um 13:32 schrieb Christian Ehrhardt:
>> > I think I'd want/need a "dh_systemd_start
>> --no-dependent-services/sockets"
>> > option to intentionally have it generate "just" for libvirt.service and
>> not
>> > the sockets it depends on.
>> > As mentioned, for all of the complexity pulling in the systemd people
>> might
>> > help as well.
>> > So I'm eager to see what they will reply here as well.
>>
>>
>> I guess the complication arises from the fact that
>> dh_installinit/invoke-rc.d directly handles systemd service files if the
>> SysV init script and service file name match.
>> dh_installsystemd only handles those unit files for which no
>> corresponding SysV init script exists.
>>
>> I think the solutions for this could be, to let dh_installsystemd handle
>> all systemd unit files.
>> dh_installinit/invoke-rc.d on the other hand would be updated to only
>> handle SysV init scripts.
>>
>> In the long run I guess this will be less confusing at is clearer which
>> tool is responsible for which task and it makes it easier to override
>> the behaviour in debian/rules.
>>
>> Felipe has been doing some initial work for enable that kind of
>> behaviour at
>> https://salsa.debian.org/debian/init-system-helpers/merge_requests/4
>
>
> This should help, but then you get the next problem: dh_installsystemd
> parses the Also= lines, and generates deb-systemd-invoke for all referenced
> units.
>
> I think the Also= lines in libvirtd.service are superfluous and removing
> them should avoid this problem.
>
> I'm still not sure why we parse Also= for starting. Michael, do you
> remember the rationale?
>

Uh I see, you mean dropping this section from libvirtd.service right?

[Install]
WantedBy=multi-user.target
Also=virtlockd.socket
Also=virtlogd.socket

The above is certainly worth a try - I need to check what I "loose" by that.

I'd still need to drop virtlogd sysV script as the "invoke.rc virtlogd"
will complain about missing dependencies (the new .socket for it can't be
started since the service is already running).
The dh_systemd_start generated code triggers "start" and ignores the
retval, the dh_installinit code through invoke.rc calls start but fails
since systemd replied "I'm running but there are dependency issues".
Because virtlogd.service has Requires virtlogd.socket and
virtlogd-admin.socket.

You end like:

virtlogd.service - Virtual machine log manager
   Loaded: loaded (/lib/systemd/system/virtlogd.service; indirect; vendor
preset: enabled)
   Active: active (running) since Thu 2018-08-09 05:26:07 UTC; 3h 45min ago
 Docs: man:virtlogd(8)
   https://libvirt.org
 Main PID: 4059 (virtlogd)
Tasks: 2 (limit: 4915)
   CGroup: /system.slice/virtlogd.service
   └─4059 /usr/sbin/virtlogd

Aug 09 09:10:37 c2 systemd[1]: Dependency failed for Virtual machine log
manager.
Aug 09 09:10:37 c2 systemd[1]: virtlogd.service: Job virtlogd.service/start
failed with result 'dependency'.

That has RC=1 if run directly.

And as I said, dh_systemd_start code will ignore the RC but dh_installinit
won't
If there is also a good hint on that let us know.



> --
>
> Saludos,
> Felipe Sateler
>


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#905821: author should be peterl...@peterlevi.com sorry

[shirish शिरीष]

Dear all,

Please change the author credentials, it's peterl...@peterlevi.com .

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

Bug#905850: cups-browsed: Creates a temporary queue for an IPP printer.

[Brian Potkin]

Package: cups-browsed
Version: 1.20.4-1
Severity: important
Tags: upstream



I have installed cups-browsed; cups is version 2.2.8-5. Only "LogDir"
and "DebugLogging file" were uncommented in the configuration file.
At the start,'lpstat -a' shows:

 dotmatrix_desktop accepting requests since Fri 10 Aug 2018 15:46:47 BST
 ENVY4500 accepting requests since Fri 10 Aug 2018 15:46:48 BST
 LaserJet_300_desktop accepting requests since Fri 10 Aug 2018 15:46:46 BST

ENVY4500 is an IPP printer. The other two entries are remote print
queues.

A minute later 'lpstat -a' has:

 dotmatrix_desktop accepting requests since Fri 10 Aug 2018 15:46:47 BST
 LaserJet_300_desktop accepting requests since Fri 10 Aug 2018 15:46:46 BST

Restarting cups-browsed gives the first set of entries again, but only
for a minute. A log is attached.

Regards,

Brian.
Fri Aug 10 16:00:09 2018 Caught signal 15, shutting down ...
Fri Aug 10 16:00:09 2018 main loop exited
Fri Aug 10 16:00:09 2018 update_cups_queues() in THREAD -1230665664
Fri Aug 10 16:00:09 2018 Processing printer list ...
Fri Aug 10 16:00:09 2018 === Remote printer overview ===
Fri Aug 10 16:00:09 2018 Printer 
ipps://desktop.local:631/printers/LaserJet-300: Local queue 
LaserJet_300_desktop, Remote CUPS Printer, Slave of None (Disappeared)
Fri Aug 10 16:00:09 2018 Printer ipps://desktop.local:631/printers/dotmatrix: 
Local queue dotmatrix_desktop, Remote CUPS Printer, Slave of None (Disappeared)
Fri Aug 10 16:00:09 2018 Printer ipp://envy4500.local:631/ipp/print: Local 
queue ENVY4500, IPP Printer, Slave of None (Disappeared)
Fri Aug 10 16:00:09 2018 ===
Fri Aug 10 16:00:09 2018 Removing entry LaserJet_300_desktop 
(ipps://desktop.local:631/printers/LaserJet-300) and its CUPS queue.
Fri Aug 10 16:00:09 2018 Recording printer options for LaserJet_300_desktop to 
/var/cache/cups/cups-browsed-options-LaserJet_300_desktop
Fri Aug 10 16:00:09 2018 Removing local CUPS queue LaserJet_300_desktop 
(ipps://desktop.local:631/printers/LaserJet-300).
Fri Aug 10 16:00:09 2018 Removing entry dotmatrix_desktop 
(ipps://desktop.local:631/printers/dotmatrix) and its CUPS queue.
Fri Aug 10 16:00:09 2018 Recording printer options for dotmatrix_desktop to 
/var/cache/cups/cups-browsed-options-dotmatrix_desktop
Fri Aug 10 16:00:09 2018 Removing local CUPS queue dotmatrix_desktop 
(ipps://desktop.local:631/printers/dotmatrix).
Fri Aug 10 16:00:09 2018 Removing entry ENVY4500 
(ipp://envy4500.local:631/ipp/print) and its CUPS queue.
Fri Aug 10 16:00:09 2018 Recording printer options for ENVY4500 to 
/var/cache/cups/cups-browsed-options-ENVY4500
Fri Aug 10 16:00:09 2018 Unable to get PPD file for ENVY4500: The printer or 
class does not exist.
Fri Aug 10 16:00:09 2018 Queue has still jobs or CUPS error!
Fri Aug 10 16:00:09 2018 ERROR: Failed disabling printer 'ENVY4500': The 
printer or class does not exist.
Fri Aug 10 16:00:09 2018 Removing local CUPS queue ENVY4500 
(ipp://envy4500.local:631/ipp/print).
Fri Aug 10 16:00:09 2018 Unable to remove CUPS queue!
Fri Aug 10 16:00:09 2018 === Remote printer overview ===
Fri Aug 10 16:00:09 2018 ===
Fri Aug 10 16:00:09 2018 cups-browsed [BrowsePoll /var/run/cups/cups.sock:0]: 
IPP-Cancel-Subscription
Fri Aug 10 16:00:09 2018 update_cups_queues() in THREAD -1230665664
Fri Aug 10 16:00:09 2018 Processing printer list ...
Fri Aug 10 16:00:09 2018 === Remote printer overview ===
Fri Aug 10 16:00:09 2018 ===
Fri Aug 10 16:00:09 2018 === Remote printer overview ===
Fri Aug 10 16:00:09 2018 ===
Fri Aug 10 16:00:09 2018 free_local_printer() in THREAD -1230665664
Fri Aug 10 16:00:09 2018 free_local_printer() in THREAD -1230665664
Fri Aug 10 16:00:09 2018 free_local_printer() in THREAD -1230665664
Fri Aug 10 16:00:09 2018 free_local_printer() in THREAD -1230665664
Fri Aug 10 16:00:09 2018 free_local_printer() in THREAD -1230665664
Fri Aug 10 16:00:09 2018 free_local_printer() in THREAD -1230665664
Fri Aug 10 16:00:09 2018 free_local_printer() in THREAD -1230665664
Fri Aug 10 16:00:09 2018 main() in THREAD -1230485440
Fri Aug 10 16:00:09 2018 cups-browsed: Creating http connection to local CUPS 
daemon: /var/run/cups/cups.sock:631
Fri Aug 10 16:00:09 2018 update_netifs() in THREAD -1230485440
Fri Aug 10 16:00:09 2018 network interface at 192.168.7.71
Fri Aug 10 16:00:09 2018 cups-browsed [BrowsePoll /var/run/cups/cups.sock:0]: 
IPP-Create-Subscription
Fri Aug 10 16:00:09 2018 cups-browsed [BrowsePoll /var/run/cups/cups.sock:0]: 
subscription ID=483
Fri Aug 10 16:00:09 2018 cups-browsed (/var/run/cups/cups.sock): cupsEnumDests
Fri Aug 10 16:00:09 2018 find_previous_queue() in THREAD -1230485440
Fri Aug 10 16:00:09 2018 find_previous_queue() in THREAD -1230485440
Fri Aug 10 16:00:09 2018 find_previous_queue() in THREAD -1230485440
Fri Aug 10 16:00:09 2018 find_previous_queue() in THREAD -1230485440
Fri Aug 10 16:00:09 2018 find_previous_queue() in THREAD -123

Bug#905849: problematic symlink /usr/lib/x86_64-linux-gnu/julia/.so found in libjulia0.7

[Lumin]

Package: libjulia0.7
Version: 0.7.0~beta2-1
Severity: important

~ ❯❯❯ dpkg -L libjulia0.7
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/julia
/usr/lib/x86_64-linux-gnu/julia/libccalltest.so
/usr/lib/x86_64-linux-gnu/julia/libsuitesparse_wrapper.so
/usr/lib/x86_64-linux-gnu/julia/sys.so
/usr/lib/x86_64-linux-gnu/libjulia.so.0.7.0
/usr/share
/usr/share/doc
/usr/share/doc/libjulia0.7
/usr/share/doc/libjulia0.7/NEWS.Debian.gz
/usr/share/doc/libjulia0.7/changelog.Debian.gz
/usr/share/doc/libjulia0.7/changelog.gz
/usr/share/doc/libjulia0.7/copyright
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/libjulia0.7
/usr/lib/x86_64-linux-gnu/julia/.so
/usr/lib/x86_64-linux-gnu/julia/libLLVM.so
/usr/lib/x86_64-linux-gnu/julia/libamd.so
/usr/lib/x86_64-linux-gnu/julia/libcamd.so
/usr/lib/x86_64-linux-gnu/julia/libccolamd.so
/usr/lib/x86_64-linux-gnu/julia/libcholmod.so
/usr/lib/x86_64-linux-gnu/julia/libcolamd.so
/usr/lib/x86_64-linux-gnu/julia/libcurl.so
/usr/lib/x86_64-linux-gnu/julia/libdSFMT.so
/usr/lib/x86_64-linux-gnu/julia/libgit2.so
/usr/lib/x86_64-linux-gnu/julia/libgmp.so
/usr/lib/x86_64-linux-gnu/julia/libmbedcrypto.so
/usr/lib/x86_64-linux-gnu/julia/libmbedtls.so
/usr/lib/x86_64-linux-gnu/julia/libmbedx509.so
/usr/lib/x86_64-linux-gnu/julia/libmpfr.so
/usr/lib/x86_64-linux-gnu/julia/libopenblas.so
/usr/lib/x86_64-linux-gnu/julia/libopenlibm.so
/usr/lib/x86_64-linux-gnu/julia/libopenspecfun.so
/usr/lib/x86_64-linux-gnu/julia/libpcre2-8.so
/usr/lib/x86_64-linux-gnu/julia/libspqr.so
/usr/lib/x86_64-linux-gnu/julia/libssh2.so
/usr/lib/x86_64-linux-gnu/julia/libsuitesparseconfig.so
/usr/lib/x86_64-linux-gnu/julia/libumfpack.so
/usr/lib/x86_64-linux-gnu/julia/libunwind.so
/usr/lib/x86_64-linux-gnu/julia/libutf8proc.so
/usr/lib/x86_64-linux-gnu/libjulia.so.0.7
~ ❯❯❯ file /usr/lib/x86_64-linux-gnu/julia/.so
/usr/lib/x86_64-linux-gnu/julia/.so: symbolic link to ../libfftw3_threads.so.3

Bug#905597: Acknowledgement (Debian 9.5 : "ip netns" does not work (iface ping test))

[peter.gasparovic]

Dear Debian team and owner,
Please cancel this issue in your database, I have overlooked some stuff not 
that explicitly stated in manual - however found that namespace works for me so 
far.

Thanks for comprehension.
BR
Peter Gasparovic

-Original Message-
From: Debian Bug Tracking System [mailto:ow...@bugs.debian.org] 
Sent: 6. augusta 2018 23:15
To: GASPAROVIC Peter OBS/OGSB
Subject: Bug#905597: Acknowledgement (Debian 9.5 : "ip netns" does not work 
(iface ping test))

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 905597: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905597.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Alexander Wirt 

If you wish to submit further information on this problem, please
send it to 905...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

-- 
905597: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905597
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Bug#905793: Why does the Installer formats given swap

[Lennart Sorensen]

On Fri, Aug 10, 2018 at 10:08:52AM +0200, Herbert Kaminski wrote:
> Am Thu, 9 Aug 2018 14:14:15 -0400
> schrieb lsore...@csclub.uwaterloo.ca (Lennart Sorensen):
> 
> > [...] 
> > Well 99.9% of installs don't have another linux on the system, 
>^
> Interesting. How did you get that figure?

Totally made it up. :)

I suspect I guessed low in fact.

-- 
Len Sorensen

Bug#905848: audacious: new upstream 3.10

[Jonatan Nyberg]

package: audacious
severity: normal

Please consider to upgrade to the current upstream version
(3.10).

Regards,
Jonatan

Bug#905843: lintian recognized "allow-stderr" as a non-standard autopkgtest restriction

[Chris Lamb]

tags 905843 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/91b7ec96722a3a456aa9d3a7ec6c8d23f3dd9535

  data/testsuite/known-restrictions | 1 +
  debian/changelog  | 4 
  2 files changed, 5 insertions(+)


Regards,

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

Bug#905847: Reinhard's email address on libaacs is typoed

[Christoph Berg]

Source: libaacs
Version: 0.9.0-1
Severity: normal

Uploaders: Reinhard Tartler 
should be
Uploaders: Reinhard Tartler 

Christoph

Bug#905478: Fwd: Re: Debian´s change of "su" to the one in util-linux

[Theodore Y. Ts'o]

On Fri, Aug 10, 2018 at 01:00:03PM +0200, Martin Steigerwald wrote:
> > As it turns out, I do something very differnt which is my .bashrc will
> > run ~/.ssh-setup, which looks for existing ssh-agents or gpg-agents,
> > and if it one doesn't exist, it will start one, e.g.:
> 
> I would not do this for the root user. I so not think it is wise to run 
> a ssh-agent or gpg-agent as root. To avoid that is the whole point of my 
> change to tell sudo to take over the environment for the SSH agent of 
> the user. I don´t even know why I would like searching for any running 
> SSH agent.

Starting a ssh-agent in practice never happens for the root user.
There's an ssh-agent or a gpg-agent running before I su or sudo as
root, so that part of the script never runs.  The reason why searching
for an SSH agent makes sense is for when I ssh into my desktop, and I
want to use the pre-existing ssh-agent running on my desktop.

Cheers,

- Ted

Bug#905393:

[Steve McIntyre]

On Fri, Aug 10, 2018 at 10:49:55PM +0900, Byung-Hee HWANG (황병희, 黃炳熙) wrote:
>Thomas Lange  writes:
>
>> OK, we have ONE person that still likes newsgroups. But nevertheless
>> most newsgroups (except two) are outdated and do not have useful
>> information any more. Can we remove the outdated newsgroups?
>>
>> I would like to focus on less information which are up to date,
>> instead of collecting a lot of outdated links.
>
>Well i think old history are valuable for people. So it is enough to add
>label (historic) to the outdated links, i think. 
>
>Still removing is dangerous.

No, I strongly disagree. We have way too much out-of-date stuff on the
website, which makes it difficult for people to find useful, relevant
information. It's way past time we cleared out.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Bug#905846: mbr FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: mbr
Version: 1.1.11-5.2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

mbr fails to cros build from source, because it configures for the build
architecture. It also forces the build architecture compiler and the
build architecture strip. The attached patch fixes all of that. Please
consider applying it.

Helmut
diff -u mbr-1.1.11/debian/changelog mbr-1.1.11/debian/changelog
--- mbr-1.1.11/debian/changelog
+++ mbr-1.1.11/debian/changelog
@@ -1,3 +1,13 @@
+mbr (1.1.11-5.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Pass --host to ./configure.
++ Let dpkg's buildtools.mk supply $(CC).
++ Defer all stripping to dh_strip.
+
+ -- Helmut Grohne   Fri, 10 Aug 2018 15:58:31 +0200
+
 mbr (1.1.11-5.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u mbr-1.1.11/debian/rules mbr-1.1.11/debian/rules
--- mbr-1.1.11/debian/rules
+++ mbr-1.1.11/debian/rules
@@ -1,8 +1,11 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+-include /usr/share/dpkg/buildtools.mk
+
 binaries := $(shell dh_listpackages)
 
-CC := gcc -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
+CC := $(CC) -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
 
 CFLAGS := -g -Wall -W
 INSTALL_PROGRAM := install
@@ -10,9 +13,6 @@
 ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
   CFLAGS += -O2
 endif
-ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-  INSTALL_PROGRAM += -s
-endif
 
 build: build-arch build-indep
 
@@ -21,7 +21,7 @@
 build-indep: build-stamp
 
 build-stamp:
-   ./configure --exec-prefix=`pwd`/debian/mbr/ 
--prefix=`pwd`/debian/mbr/usr
+   ./configure --exec-prefix=`pwd`/debian/mbr/ 
--prefix=`pwd`/debian/mbr/usr --build=$(DEB_BUILD_GNU_TYPE) 
--host=$(DEB_HOST_GNU_TYPE)
$(MAKE) CC="$(CC)" LD="$(LD)" CFLAGS="$(CFLAGS)"
touch build
 

Bug#905844: git-remote-hg: crash with recent mercurial: argument must be a string or a number, not 'changectx'

[Jonas Smedegaard]

Package: git-remote-hg
Version: 0.3-2
Severity: grave
Tags: upstream
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

After a recent update to mercurial, attempts at syncing fails:

LC_ALL=C git fetch upstream-git 
searching for changes
no changes found
ERROR: int() argument must be a string or a number, not 'changectx'
fatal: stream ends early
fast-import: dumping crash report to .git/fast_import_crash_12488
fatal: Error while running fast-import


It seems to be this upstream issue:
https://github.com/felipec/git-remote-hg/issues/72


 - Jonas

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

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

Versions of packages git-remote-hg depends on:
ii  git1:2.18.0-1
ii  mercurial  4.7-1
ii  python 2.7.15-3

git-remote-hg recommends no packages.

Versions of packages git-remote-hg suggests:
pn  git-doc  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlttn7oACgkQLHwxRsGg
ASF7uA//baOG8EdUMmM/TsBbSCBzCdYvsKo5PY29MeTyvhMWRhKGzKVwwoKs2C20
TCchG9J18T1U4fo1YE4igISAbwXhDlbm6JENFx1PnDwW+gZUkHSDs9awGfppnVMI
eJAY762m/KW6ZaXdnkyUERJU+wT7jBtD1kbWoLdOcBev1zlzJ28cIUDUFtnOEEx3
+vw9gu6wv4VhTLPIx5i4OFiXYepDz3I/ClG6NU6ol7o94v8e72myo0J1QomxnssO
8/FOd2OqZk/JU9TOlH8QSu2D50hV06UmlBYr+NDmwS9L+B/9Tx9RHn7fvW4/Joce
N63ISPQ6OiiK3HBRWhL1ULD1/jkgclbaEcYYQ0qJxWGZiE36PBu66hMYWtq95rxv
QKfwbg3oamyYb4YaGkeYRgJROKtLR7vrqDbxAzX/ByaYYZX21cprHS8i2BUN4RI4
pe2ifG/mQFij/RG7df6igUBrz0MGGJC7FjNnk9t1U6NBqDMEjx7p8R2nJerVC5En
qicsiRbCoTN9xZ7ulnIobKXuPMwSofz00hcFMUgVif22Q+g+Cu0FQ7Z665MakLHK
Jm+SFvJfXcSYMzF2ridwrhjsBaoOPWku6/VsN4g5JgcdNb1LE2NgD491GvkF/LZL
8HoJ3dPqQq6XjKXEbARVCYlzMfaAWeYh7D35gpvKoyy5R88K7X0=
=rT1r
-END PGP SIGNATURE-

Bug#905845: pkg-kde-tools: man page links to alioth.debian.org

[Jonas Smedegaard]

Package: pkg-kde-tools
Version: 0.15.28
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

man page for pkgkde-symbolshelper links in SEE ALSO section to
http://pkg-kde.alioth.debian.org/symbolfiles.html

Seems that should be updated to
https://qt-kde-team.pages.debian.net/symbolfiles.html

 - Jonas


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

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

Versions of packages pkg-kde-tools depends on:
ii  libdpkg-perl  1.19.0.5
ii  perl  5.26.2-6
ii  python3   3.6.6-1

Versions of packages pkg-kde-tools recommends:
ii  dpkg-dev 1.19.0.5
ii  libwww-perl  6.35-2

Versions of packages pkg-kde-tools suggests:
ii  cdbs   0.4.156
ii  debhelper  11.3.5

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlttoD8ACgkQLHwxRsGg
ASFQBg/+MaAXCMWv975RN4IwdCzX3zZzTGWVb/ukjuNMr/XG9EHjJ04Y95P7lGuE
a7ui0NHf5TAmUqH/5oDajTP/tQMa2fzGUXM5BqROUB2trDlZSMmz3sQP57x6cdEc
4DuYJJTE2ZSFu6GUDjbw+wrFR6zaQwqLsykJP7KMuQMmzDc9s7S1A69D1Js0O7m6
7npIuOzcWHnmVXX3H0Vj9eVC9jEK8Ujl8MiuqNuvAFAiSSgGElqa1wXTChxE8GvY
Pav6zo301Pi0YJ6ofDhoK40bFarjAGbJgYDaRbUnhN5iCwv8Bmo6LPA6efVMm/w+
5fIor6pq4GnyNzJTlPDSs0ZisVo71M1HBRXCKIjZk3fSxMh4sVhHD0dX7lWFKCMM
d2ttz2Fr8IgKsnByShgj90wQKmDNp5dEeKE6J9hBH1WFW/0Xx3BJNSNxp/Fsa9PN
XYV3Jh3E2K3moXMfOQ6XVnbPcYeCx8lH77lnqaxrE4LfEpo0N4rM49lXwaQ+Vppi
7hVJ82ZgKU7Jr+JSz+RmdIrmlOtN5dyEsWeGIITtnoGXFAtjK04tSjum65EhlA+Y
VRpYgCI7QT0to65fn6oPLxwuNTc+do4g4w3iX/kuS0+Mv2zH7ErujzCHW7Zp1DUx
b1iV8LNmm+r8H7QDxWTIgHqUgoRoJ93jifebbzjgzbIbipCyJS8=
=6pzq
-END PGP SIGNATURE-

Bug#63833: Avviso di Outlook

[Diana Krabbe]

la tua casella di posta elettronica é quasi piena.

2316MB



2400MB

Current size



Maximum size

Per favore CLICCA QUI per aumentare le 
dimensioni della tua casella di posta. e per l'aggiornamento alla nuova app Web 
di Microsoft Outlook. La tua attuale webmail non è aggiornata



DISCLAIMER
This email contains information that is confidential and which may be legally 
privileged. If you have received this email in error, please notify the sender 
immediately and delete the email. This email is intended solely for the use of 
the intended recipient and you may not use or disclose this email in any way.

Bug#885498: zenmap: Depends on unmaintained pygtk

[Jeremy Bicha]

On Thu, Aug 9, 2018 at 11:48 PM Samuel Henrique  wrote:
> I think this has nothing to do with the maintainer of the package, it's an 
> upstream issue.

It is a Debian issue since we are looking to remove pygtk during the
*Bullseye* cycle regardless of what upstream does.

For instance, we could just stop shipping zenmap…

> Can you forward this to them?

I've never worked with nmap upstream. Maybe it would be better if you
would forward the issue?

Thanks,
Jeremy Bicha

Bug#905772: Add interim summary

[Felipe Sateler]

On Fri, Aug 10, 2018 at 7:42 AM Michael Biebl  wrote:

> Am 10.08.2018 um 13:32 schrieb Christian Ehrhardt:
> > I think I'd want/need a "dh_systemd_start
> --no-dependent-services/sockets"
> > option to intentionally have it generate "just" for libvirt.service and
> not
> > the sockets it depends on.
> > As mentioned, for all of the complexity pulling in the systemd people
> might
> > help as well.
> > So I'm eager to see what they will reply here as well.
>
>
> I guess the complication arises from the fact that
> dh_installinit/invoke-rc.d directly handles systemd service files if the
> SysV init script and service file name match.
> dh_installsystemd only handles those unit files for which no
> corresponding SysV init script exists.
>
> I think the solutions for this could be, to let dh_installsystemd handle
> all systemd unit files.
> dh_installinit/invoke-rc.d on the other hand would be updated to only
> handle SysV init scripts.
>
> In the long run I guess this will be less confusing at is clearer which
> tool is responsible for which task and it makes it easier to override
> the behaviour in debian/rules.
>
> Felipe has been doing some initial work for enable that kind of
> behaviour at
> https://salsa.debian.org/debian/init-system-helpers/merge_requests/4


This should help, but then you get the next problem: dh_installsystemd
parses the Also= lines, and generates deb-systemd-invoke for all referenced
units.

I think the Also= lines in libvirtd.service are superfluous and removing
them should avoid this problem.

I'm still not sure why we parse Also= for starting. Michael, do you
remember the rationale?

-- 

Saludos,
Felipe Sateler

Bug#905393:

[Byung-Hee HWANG (황병희, 黃炳熙)]

Thomas Lange  writes:

> OK, we have ONE person that still likes newsgroups. But nevertheless
> most newsgroups (except two) are outdated and do not have useful
> information any more. Can we remove the outdated newsgroups?
>
> I would like to focus on less information which are up to date,
> instead of collecting a lot of outdated links.

Well i think old history are valuable for people. So it is enough to add
label (historic) to the outdated links, i think. 

Still removing is dangerous.

Sincerely, Byung-Hee.

-- 
^고맙습니다 _地平天成_ 감사합니다_^))//