Bug#691692: fixed in the new version

[shirish शिरीष]

fixed 691692 4.1.3-1
thanks

Bug#815225: missing death from 2009

[Paul Wise]

On Sun, 2018-09-23 at 23:35 +0900, Osamu Aoki wrote:

> Can anyone propose text to describe Steve Greenland if it needs to be
> included?  
> 
> I don't know him well and I don't know enough to decide who to be
> included.

Same here, but looking at my mailing list archives and his contributor
page it seems like he was an active package maintainer and participant
in the project in general.

https://contributors.debian.org/contributor/stevegr@debian/

> I think one criteria is if we mentioned in public as Debian News or nt.

The only place I see we mentioned it is in debian-timeline.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#909456: RFS: pokemmo-installer/1.4.7-1 -- Installer and Launcher for the PokeMMO emulator

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "pokemmo-installer"

 * Package name: pokemmo-installer
   Version : 1.4.7-1
   Upstream Author : Carlos Donizete Froes 
 * URL : https://gitlab.com/coringao/pokemmo-installer/wikis
 * License : GPL-3+ with OpenSSL exception
   Section : contrib/games

  It builds those binary packages:

  pokemmo-installer - Installer and Launcher for the PokeMMO emulator

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

  https://mentors.debian.net/package/pokemmo-installer

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

  dget -x 
https://mentors.debian.net/debian/pool/contrib/p/pokemmo-installer/pokemmo-installer_1.4.7-1.dsc

  More information about PokeMMO Installer can be obtained from 
https://gitlab.com/coringao/pokemmo-installer.

  Changes since the last upload:

  pokemmo-installer (1.4.7-1) unstable; urgency=medium

  * New upstream release
  * debian/control:
+ Declare compliance with Debian Policy: 4.2.1
  * Updated d/watch file

  Regards,
   Carlos Donizete Froes [a.k.a coringao]

Bug#807866: uploading github-hub? (was: Bug#807866: RFP: github-hub -- hub helps you win at git)

[Anthony Fok]

Hi Antoine,

On Sun, Sep 23, 2018 at 9:48 AM Antoine Beaupré  wrote:
>
> Ping!
>
> I've been running this package for about a month now and it works well.

Glad that you like the package!

> If no one else steps up, I will upload this within the next four weeks.

The "hub" package was uploaded to Debian three months ago,
or 2018-06-16 to be exact, currently in the NEW queue
pending verification by FTP masters.

See https://ftp-master.debian.org/new.html for more information.

Cheers,
Anthony

> Thanks!
>
> A.
>
> On 2018-08-26 23:11:26, Antoine Beaupré wrote:
> > Control: tag -1 +pending +patch
> >
> > Hi Anthony!
> >
> > I noticed on Salsa that you have worked on the Debian package for the
> > hub program:
> >
> > https://salsa.debian.org/go-team/packages/hub
> >
> > Are there any plans to upload that package into the archive? It would be
> > very useful... It seems to work here although it currently FTBFS because
> > of an incorrect dependency. The attached patch fixes that.
> >
> > Thanks for any update,
> >
> > A.
> >
> > From 3d72160700b43218557ad15f12633a2eb9568119 Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
> > Date: Sun, 26 Aug 2018 23:06:42 -0400
> > Subject: [PATCH] fix build dependency
> >
> > The ruby-ronn package does not ship the ronn program anymore
> > ---
> >  debian/control | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/debian/control b/debian/control
> > index 7d80a46..0103fac 100644
> > --- a/debian/control
> > +++ b/debian/control
> > @@ -20,7 +20,7 @@ Build-Depends: debhelper (>= 11),
> > golang-github-ogier-pflag-dev,
> > golang-golang-x-crypto-dev,
> > golang-gopkg-yaml.v2-dev,
> > -   ruby-ronn
> > +   ronn
> >  Standards-Version: 4.1.4
> >  Vcs-Browser: https://salsa.debian.org/go-team/packages/hub
> >  Vcs-Git: https://salsa.debian.org/go-team/packages/hub.git
> > --
> > 2.18.0
> >
>
> --
> A patriot must always be ready to defend his country
> against his government.
> - Edward Abbey

Bug#909455: systemd FTBFS: meson_options.txt:49:0: ERROR: Option name debug is reserved.

[Helmut Grohne]

Source: systemd
Version: 239-9
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
Control: reassign 909440 meson
Control: tags 909440 + ftbfs
Control: affects 909440 + src:systemd
Control: block -1 by 909440

systemd presently fails to build from source. The immediate reason is
that meson lacks a dependency on python3-pkg-resources. That problem can
be worked around e.g. by adding --add-depends=python3-pkg-resources to
an sbuild invocation. The missing dependency is already properly tracked
and not subject of this bug.

Once you work around the issue, systemd fails to build in a novel way:

| make[1]: Entering directory '/<>'
| dh_auto_configure --builddirectory=build-deb \
| -- -Db_lto=true -Drootlibdir=/lib/x86_64-linux-gnu -Dsplit-usr=true 
-Dquotaon-path=/sbin/quotaon -Dquotacheck-path=/sbin/quotacheck 
-Dkmod-path=/bin/kmod -Dkexec-path=/sbin/kexec -Dsulogin-path=/sbin/sulogin 
-Dmount-path=/bin/mount -Dumount-path=/bin/umount -Dloadkeys-path=/bin/loadkeys 
-Dsetfont-path=/bin/setfont -Dtelinit-path=/lib/sysvinit/telinit 
-Dsysvinit-path=/etc/init.d -Dsysvrcnd-path=/etc -Ddebug-shell=/bin/bash 
-Dzshcompletiondir=/usr/share/zsh/vendor-completions 
-Ddbuspolicydir=/usr/share/dbus-1/system.d/ 
-Dsupport-url=https://www.debian.org/support 
-Ddefault-kill-user-processes=false -Dpamconfdir=no -Drpmmacrosdir=no 
-Dqrencode=false -Dvconsole=false -Dfirstboot=false -Dxkbcommon=false 
-Dportabled=false -Dwheel-group=false -Dntp-servers="0.debian.pool.ntp.org 
1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org" 
-Dlink-udev-shared=false -Dsystem-uid-max=999 -Dsystem-gid-max=999 
-Dnobody-user=nobody -Dnobody-group=nogroup -Ddev-kvm-mode=0660   
-Dselinux=true -Dhwdb=true -Dsysusers=true -Dinstall-tests=true -Defi=true 
-Dnss-systemd=true -Dresolve=true -Daudit=true -Dlibcryptsetup=true 
-Dcoredump=true -Delfutils=true -Dapparmor=true -Dlibidn=true -Dlibiptc=true 
-Dlibcurl=true -Dimportd=true -Dmicrohttpd=true -Dgnutls=true
| cd build-deb && LC_ALL=C.UTF-8 meson .. --wrap-mode=nodownload 
--buildtype=plain --prefix=/usr --sysconfdir=/etc --localstatedir=/var 
--libdir=lib/x86_64-linux-gnu --libexecdir=lib/x86_64-linux-gnu -Db_lto=true 
-Drootlibdir=/lib/x86_64-linux-gnu -Dsplit-usr=true 
-Dquotaon-path=/sbin/quotaon -Dquotacheck-path=/sbin/quotacheck 
-Dkmod-path=/bin/kmod -Dkexec-path=/sbin/kexec -Dsulogin-path=/sbin/sulogin 
-Dmount-path=/bin/mount -Dumount-path=/bin/umount -Dloadkeys-path=/bin/loadkeys 
-Dsetfont-path=/bin/setfont -Dtelinit-path=/lib/sysvinit/telinit 
-Dsysvinit-path=/etc/init.d -Dsysvrcnd-path=/etc -Ddebug-shell=/bin/bash 
-Dzshcompletiondir=/usr/share/zsh/vendor-completions 
-Ddbuspolicydir=/usr/share/dbus-1/system.d/ 
-Dsupport-url=https://www.debian.org/support 
-Ddefault-kill-user-processes=false -Dpamconfdir=no -Drpmmacrosdir=no 
-Dqrencode=false -Dvconsole=false -Dfirstboot=false -Dxkbcommon=false 
-Dportabled=false -Dwheel-group=false "-Dntp-servers=0.debian.pool.ntp.org 
1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org" 
-Dlink-udev-shared=false -Dsystem-uid-max=999 -Dsystem-gid-max=999 
-Dnobody-user=nobody -Dnobody-group=nogroup -Ddev-kvm-mode=0660 -Dselinux=true 
-Dhwdb=true -Dsysusers=true -Dinstall-tests=true -Defi=true -Dnss-systemd=true 
-Dresolve=true -Daudit=true -Dlibcryptsetup=true -Dcoredump=true 
-Delfutils=true -Dapparmor=true -Dlibidn=true -Dlibiptc=true -Dlibcurl=true 
-Dimportd=true -Dmicrohttpd=true -Dgnutls=true
| The Meson build system
| Version: 0.48.0
| Source dir: /<>
| Build dir: /<>/build-deb
| Build type: native build
| 
| meson_options.txt:49:0: ERROR:  Option name debug is reserved.
| 
| A full log can be found at /<>/build-deb/meson-logs/meson-log.txt
| cd build-deb && tail -v -n \+0 meson-logs/meson-log.txt
| ==> meson-logs/meson-log.txt <==
| Build started at 2018-09-24T03:40:26.699787
| Main binary: /usr/bin/python3
| Python system: Linux
| The Meson build system
| Version: 0.48.0
| Source dir: /<>
| Build dir: /<>/build-deb
| Build type: native build
| 
| meson_options.txt:49:0: ERROR:  Option name debug is reserved.
| dh_auto_configure: cd build-deb && LC_ALL=C.UTF-8 meson .. 
--wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var --libdir=lib/x86_64-linux-gnu 
--libexecdir=lib/x86_64-linux-gnu -Db_lto=true 
-Drootlibdir=/lib/x86_64-linux-gnu -Dsplit-usr=true 
-Dquotaon-path=/sbin/quotaon -Dquotacheck-path=/sbin/quotacheck 
-Dkmod-path=/bin/kmod -Dkexec-path=/sbin/kexec -Dsulogin-path=/sbin/sulogin 
-Dmount-path=/bin/mount -Dumount-path=/bin/umount -Dloadkeys-path=/bin/loadkeys 
-Dsetfont-path=/bin/setfont -Dtelinit-path=/lib/sysvinit/telinit 
-Dsysvinit-path=/etc/init.d -Dsysvrcnd-path=/etc -Ddebug-shell=/bin/bash 
-Dzshcompletiondir=/usr/share/zsh/vendor-completions 
-Ddbuspolicydir=/usr/share/dbus-1/system.d/ 
-Dsupport-url=https://www.debian.org/support 
-Ddefault-kill-user-processes=false -Dpamconfdir=no -Drpmmacrosdir=no 

Bug#909454: nmu: gdb_8.1.90-1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu gdb_8.1.90-1 . amd64 i386 x32 . experimental . -m "Rebuild against libipt2."

This binNMU is the mini-transition of intel-processor-trace in
experimental.


Andreas

Bug#909440: meson: missing dependency on python3-pkg-resources

[Jeremy Bicha]

On Sun, Sep 23, 2018 at 10:53 PM Jussi Pakkanen  wrote:
> On Sun, Sep 23, 2018 at 10:03 AM Jeremy Bicha  wrote:
>
> > I tried building a package (gnome-games-app) using meson but the build
> > fails now. I guess meson needs to depend on python3-pkg-resources .
>
> No. We are not permitted to depend on anything outside of Python
> standard library. Thought looking at the package info that package is
> provided by setuptools which is a bit of an edge case because
> distutils is a bit neglected AFAICT.

This issue means that everything using meson in Debian fails to build
right now. Specifically, this is blocking us from being able to do the
GNOME 3.30.1 updates this week.

So I think a temporary fix now would be appropriate and then you can
take more time to figure out a different solution if you like.

Thanks,
Jeremy Bicha

Bug#909440: meson: missing dependency on python3-pkg-resources

[Jussi Pakkanen]

On Sun, Sep 23, 2018 at 10:03 AM Jeremy Bicha  wrote:

> I tried building a package (gnome-games-app) using meson but the build
> fails now. I guess meson needs to depend on python3-pkg-resources .

No. We are not permitted to depend on anything outside of Python
standard library. Thought looking at the package info that package is
provided by setuptools which is a bit of an edge case because
distutils is a bit neglected AFAICT.

Bug#909453: site of discussion for Debian digressions from ELPA spec

[Nicholas D Steeves]

Package: dh-elpa
Version: 1.14
Severity: normal

Hi David,

As discussed on IRC, filing this bug.  You had also mentioned how this
discussion might lead to an update of Policy and a wishlist bug
against the info package.  The resolution of this issue will affect
all elpa-packages that install things outside of their
elpa-src/package-version dir.

tldr ELPA spec: must directive to install everything to
elpa-src/package-version.

a) Information about the ELPA spec is found in "Multi-file Packages"
   in the GNU Emacs Lisp Reference Manual, available online or from
   the non-free package emacs-common-non-dfsg info "(elisp) Multi-file
   Packages".

Obviously we want to do what's best for Debian users, #1, this means
that /usr/share/doc/package should contain the expected documentation.

  b) It's possible that there exist Emacs packages that will not run
 if their bits are installed outside of their elpa-src dir.  We
 should have a policy on if they should be patched and/or if
 symlinks should be provided.  Of course this is just part of the
 work on packaging software...

#2 I think in most cases it would be better to digress from the
upstream spec and install things using dh_language (the packages I'm
aware of are irony-mode and elpy, but I'm sure there are others).  eg:
dh_elpa handles *.el and files from other languages should be handled
using other dh_helpers (eg: dh-python in the case of elpy).  See note
at [b] as it also applies here.  I anticipate that will emerge as more
of an issue in the next 5-to-10 years with the proliferation of
interpreted languages, deeper integration between Emacs and these
languages, along with a second class of potential issues when using a
dh_language.

#3 Info pages.  Related to #1 with one caveat: Debian's standalone
info program only support info pages outside of /usr/share/info by
using the INFOPATH variable.  If we follow a strict definition of [a]
then symlink /u/s/info/package.info -> elpa-src/package-version/package.info

However, this doesn't handle the case where GNU Emacs provides an info
page for a mode that exists as an elpa-package (eg: org-mode).  Workarounds:
  i) make Rob's life difficult by complicating how src:emacs handles Debian
 alternatives.
 ii) file a bug against src:info and hope that it gets fixed, and that info
 gains the ability to read info files outside of the system default 
INFOPATH.
iii) add support to dh-elpa for setting INFOPATH using a similar method to
 /etc/bash_completion.d (eg: drops a file in /etc/info.d)...I guess this
 could be useful to non-dh-elpa-using packages, but I'm not aware of any.

Meanwhile, the info issue does not exist for users who use Emacs'
info-mode to view info files...

I hope this bug entry is reasonably complete and not too long.

Sincerely,
Nicholas

Bug#861128: RFP: elpa-markdown-toc -- Generate a TOC in markdown file with Emacs

[Nicholas D Steeves]

On Fri, Sep 21, 2018 at 04:15:21PM -0400, Antoine Beaupré wrote:
> On 2018-09-17 22:40:10, Nicholas D Steeves wrote:
> > Re: a couple of markdown-toc bugs:
> >
> > https://github.com/ardumont/markdown-toc/issues/29
> >   * Solve in Debian with a hard depends on >= markdown-mode 2.2?
> >   * You mentioned markdown-mode 2.1 is bad, 20161222.1416 is good,
> > and 2.2 is from 20170526, thus 2.2 should be good.
> >   * possibly fixed in markdown-toc?
> 
> I can't reproduce this with the markdown-mode version in Debian. It
> might still occur with the version in stable, but then the bugfix is
> just an upgrade away.

Cool.  And I've patched in a hard ELPA dep on 2.2 so anyone who bpos
or installs the unstable dep to stable will have a hint about what's
going wrong.  Sounds like it will be automatically dropped with the
next upstream release :-)

> > https://github.com/ardumont/markdown-toc/issues/15
> >   * "Don't assume that a document has an h1"
> >   * How serious is this one?  Seems like it could be annoying.
> 
> I just tested this and can confirm the bug happens with your version of
> the package as well.
> 
> It's not a big deal: the generated TOC can be modified by hand so extra
> content or errors can be easily fixed. In fact, I very often tweak the
> TOC by hand myself because it's easier than changing the settings
> (e.g. to remove a subsection and so on).

Thank you for confirming this one, and that confirming it's not a big deal.

> > https://github.com/ardumont/markdown-toc/issues/35
> >   * "Lines starting with # in code sections are treated as headings"
> >   * I imagine this one will frustrate many users.
> 
> I can't reproduce this one, but this may be because of the version of
> markdown.el in Debian (2.3snapshot154).

Interesting!  I'm happy to hear that, and I'll add a manual hard dep
(for the next release) on >=2.3snapshot154 for the potential benefit
of anyone installing this package to stable.  'just a "nice to have"
thing, you know?

> So, conclusion: I'd be happy to sponsor the package as is any time. Just
> let me know when you're ready and let's get this one out the door!

Sweet.  Thank you for also addressing the two points I mentioned on
#debian-emacs.  I've already finalised the changelog.  Ready to
sponsor from git or mentors.

  git clone g...@salsa.debian.org:emacsen-team/markdown-toc-el.git
  # gbp will get orig tarball from upstream tag
  # alternatively: git deborig

  dget 
https://mentors.debian.net/debian/pool/main/m/markdown-toc-el/markdown-toc-el_0.1.2-1.dsc


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#865195: Bug 865195: [www.debian.org] Some broken links on the page

[Paulo Henrique de Lima Santana]

 "Downloading Debian CD images with BitTorrent"
Message-Id: <20180922142315.9067e510c35d9b3e755a6...@softwarelivre.org>
In-Reply-To: <0b2cf48b-4813-8951-6b95-e41691fd1...@debian.org>
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Laura,

On Sun, 18 Feb 2018 01:12:42 +0100 Laura Arjona Reina 
wrote:
> Hi Andrey
>=20
> Thanks for reporting this bug.
>=20
> About source CD, we're not providing source CD anymore, only source DVD,
> so the link shouldn't be there.
>=20
> For what I can see, the list of links is generated by this file:
>=20
> https://anonscm.debian.org/viewvc/webwml/webwml/english/template/debian/r=
elease_images.wml
>=20
> in particular, lines 44-45:
>=20
> 
> /@ARCH@/bt-cd/"
> arch=3D" multi-arch" />
>=20
> we should remove "source" from that list.
> I'm attaching a patch that I think it solves this issue.
> I've tested it locally and the resulting list of links looks ok for me,
> but I'll ping the CD team and wait some days for others to review.

May I apply your patch to solve this bug?

Best regards,

--=20
Paulo Henrique de Lima Santana (phls)
Curitiba - Brasil
Membro da Comunidade Curitiba Livre
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450

Apoie a campanha pela igualdade de g=EAnero #HeForShe (#ElesPorElas) =20
http://www.heforshe.org/pt


pgp1UfQVJIFeV.pgp
Description: PGP signature

Bug#909452: grub-efi-amd64: Can't boot from XFS root file system

[Peter.Chubb]

Package: grub-efi-amd64
Version: 2.02+dfsg1-6
Severity: important

Dear Maintainer,

When attempting to boot, grub drops into a commandline, and the system
is unbootable, because grub cannot read the XFS root partition.

I worked around the problem by adding:
 insmod $cmdpath/xfs

to /boot/efi/EFI/debian/grub.cfg
and copying xfs.mod into /boot/efi/EFI/debian/

I would have expected the grub-install process to do this (or
something equivalent) for me.

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/nvme0n1p6 / xfs rw,relatime,attr2,inode64,noquota 0 0
/dev/nvme0n1p1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro
 0 0
/dev/sda1 /usr/home f2fs 
rw,lazytime,relatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,fsync_mode=posix
 0 0
*** END /proc/mounts

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

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

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

export menuentry_id_option

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

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

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod xfs
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  4fe2144f-9685-46f4-a2d8-927aae009ac6
else
  search --no-floppy --fs-uuid --set=root 4fe2144f-9685-46f4-a2d8-927aae009ac6
fi
font="/usr/share/grub/unicode.pf2"
fi

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

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod xfs
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  4fe2144f-9685-46f4-a2d8-927aae009ac6
else
  search --no-floppy --fs-uuid --set=root 4fe2144f-9685-46f4-a2d8-927aae009ac6
fi
insmod png
if background_image /usr/share/desktop-base/softwaves-theme/grub/grub-16x9.png; 
then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-4fe2144f-9685-46f4-a2d8-927aae009ac6' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod xfs
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  
4fe2144f-9685-46f4-a2d8-927aae009ac6
else
  search --no-floppy --fs-uuid --set=root 
4fe2144f-9685-46f4-a2d8-927aae009ac6
fi
echo'Loading Linux 4.19.0-rc4-00086-g4ca719a338d5 ...'
linux   /boot/vmlinuz-4.19.0-rc4-00086-g4ca719a338d5 
root=UUID=4fe2144f-9685-46f4-a2d8-927aae009ac6 ro  fbcon=font:SUN12x22 
net.ifnames=0 no_console_suspend intel_iommu=on
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-4.19.0-rc4-00086-g4ca719a338d5
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-4fe2144f-9685-46f4-a2d8-927aae009ac6' {
menuentry 'Debian GNU/Linux, with Linux 4.19.0-rc4-00086-g4ca719a338d5' 
--class debian --class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-4.19.0-rc4-00086-g4ca719a338d5-advanced-4fe2144f-9685-46f4-a2d8-927aae009ac6'
 {
load_video

Bug#904316: transition: boost-defaults

[Dimitri John Ledkov]

On Sun, 23 Sep 2018 at 08:38, Adrian Bunk  wrote:
>
> On Wed, Sep 19, 2018 at 12:45:12PM +0200, Dimitri John Ledkov wrote:
> > On Sun, 16 Sep 2018 at 11:16, Niels Thykier  wrote:
> >...
> > > Hi,
> > >
> > > I noticed at least 13 packages that have boost-related changes in an
> > > Ubuntu diff (and I certainly have *not* checked all packages in the
> > > boost transition tracker; I only looked at dep level 3).
> > >
> > >  * libcutl
> > >  * lvtk
> > >  * minieigen
> > >  * opengm (removes binary packages)
> > >  * performous (moves to boost1.65)
> > >  * pyexiv2
> > >  * pytango
> > >  * shark (reduces test precision)
> > >  * tagpy
> > >  * vcmi (moves to boost1.65)
> > >  * anytun
> > >  * aptitude
> > >  * freeture
> > >
> > > Can you please provide a full list of packages that will break with the
> > > new boost default?  How will Debian handle the packages that Ubuntu
> >
> > I do not have a full list. These do not break on runtime in general
> > (apart from a very small subset of things which dlopen/link
> > incompatible plugins), since old boost is provided and is
> > co-installable. They may start to FTBFS.
>
> If you want to do the normal build-testing before the transition,
> it would be helpful to have updated boost-defaults in experimental.
>

Largely rebuilds in Ubuntu have been sufficient to identify and fix
the bulk of boost transition issues
http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.67.html

After the initial rounds of NMUs I typically work off the Debian
transition tracker to complete transition / files FTBFS bugs / NMU
patches.

I can prepare the boost-defaults upload into experimental, but I'd
rather have this transition approved and boost-defaults uploaded into
unstable.

> >...
> > those will stick on boost1.62. thus the option for those would be to
> > change build-dep to libboost1.62-all-dev.
>
> Changing build dependencies to 1.62 only makes sense if this version
> will be shipped in buster.
>

This request is for transitioning boost-defaults from 1.62 to 1.67,
without removal of 1.62.

> >...
> > The longer this transition is delayed the worse it gets. Thus already
> > default boost is 5 major releases behind.
>
> What is the version planned to be shipped in buster?
>

Source packages: boost1.67 boost1.62 boost-defaults

> 1.68 is already released, and 1.69 will be released in December.
>

Neither of which are packaged yet.

> IMHO doing 1.62 -> 1.67 -> 1.68 would not make sense at this point.
>
> Better options would be:
> 1.62 -> 1.68 -> 1.69
> 1.62 -> 1.68
> 1.62 -> 1.67 -> 1.69
>

Cool, are you signing up to package 1.68 & 1.69 then? - my reading of
your email seems to imply, that packaging of 1.68/1.69 is a given when
it is not.

Cause at the moment we have only 1.67 done, which was extremely hard
to complete in order to comply with copyright requirements.

> The critical question here is whether there will be a transition to 1.69
> before the transition freeze (January 12th).
>

At the moment there are no volunteers who can commit to packaging
1.68/1.69 and specifically updating the copyright file. Unless you can
volunteer to do that.

I have no intentions on packaging 1.68 or 1.69 in Ubuntu for the 19.04
release at the moment. Thus most likely can look into further boost
new upstream packaging in a years time only probably.

-- 
Regards,

Dimitri.

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

[Santiago Garcia Mantinan]

Helmut, thanks for your reply.

There is no reason not to call dh_strip, in fact if I had read your
changelog closely and thought about your dh_strip comment, I think I could
have imagined by myself that you were counting on that ;-)

I have added dh_strip and everything seems fine.

I've tried to get in touch with mbr author in case he wants to distribute
our changes, in case I don't get a reply or that he doesn't want I'll upload
the new package soon.

Regards.
-- 
Manty/BestiaTester -> http://manty.net

Bug#909451: pristine-tar: Be resilient in the face of hard links - simple patch?

[John Goerzen]

Package: pristine-tar
Version: 1.38
Severity: normal

I have a use case that occurs on a filesystem where jdupes is used
periodically to hardlink together duplicate files.  The tree which
tarballs will be used from contains such duplicates that may be
hardlinked either before or after the delta is generated.  GNU tar, by
default, inserts special "link to" records for a the second and
subsequent occurence of a reference to the same inode number.  That
such files may be hardlinked post-delta generation would cause the
generated tarball to be unpredictable and therefore quite possibly
broken.

I believe the very simple fix would be to add --hard-dereference to
the list of tar options in recreatetarball_helper.  In the case that
hard links were present in the tarball, xdelta ought to simply remove
the extra data and no harm would be done.

Thanks,

John

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

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

Versions of packages pristine-tar depends on:
ii  libbz2-1.0  1.0.6-8.1
ii  libc6   2.24-11+deb9u3
ii  perl5.24.1-3+deb9u4
ii  tar 1.29b-1.1
ii  xdelta  1.1.3-9.1+b1
ii  xdelta3 3.0.11-dfsg-1+b1
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages pristine-tar recommends:
ii  bzip2 1.0.6-8.1
ii  pbzip21.1.9-1+b1
ii  xz-utils  5.2.2-1.2+b1

pristine-tar suggests no packages.

-- no debconf information

Bug#909450: RM: androidsdk-tools -- ROM; obsolete, abandoned upstream, FTBFS

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Please remove the androidsdk-tools package, it has been abandoned
upstream and has been failing to build for nearly a year (#879175).

Thank you,

Emmanuel Bourg

Bug#909418: [uscan] mode=git leaves git repo on disk

[Xavier]

Hello,

I fixed the problem [MR32] and kept actual uscan behavior: keep
temporary dir when --verbose is set. I think we could change this and
keep temp dir only when uscan fails or (opened discussion) if --debug is
set.

Cheers,
Xavier

[MR32] https://salsa.debian.org/debian/devscripts/merge_requests/32

Bug#909449: RM: android-platform-tools-swt -- ROM; obsolete, abandoned upstream, FTBFS

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Please remove the android-platform-tools-swt package, it has been abandonned
upstream and has been failing to build for over a year (#852903).

Thank you,

Emmanuel Bourg

Bug#909133: ITP: auto-dictionary-el -- automatic dictionary switcher for Emacs spell checking

[Nicholas D Steeves]

On Sun, Sep 23, 2018 at 10:13:30AM -0400, Antoine Beaupré wrote:
> On 2018-09-22 18:37:29, Nicholas D Steeves wrote:
> > If you prefer a formal RFS say the word, though I'd prefer to be lazy about
> > this :-p
> 
> No problem of course. :) After a short review, build, install and smoke
> test, I've uploaded the package and it should end up in NEW shortly.
> 

Thank you! :-)


signature.asc
Description: PGP signature

Bug#909448: Dependencies suggestions

[Romain Beauxis]

Package: liquidsoap
Version: 1.3.3-2

The following dependencies changes can/should be considered:
- curl is now used instead of wget for file download
- awscli can optionally be used to download from s3 and/or generate speech
synthesis
- ffmpeg (command line) can optionally be used to convert to wav via the
ffmpeg2wav protocol
- ocaml-ffmpeg can be used to enable builtin operators and decoders
- youtube-dl can optionally be used to download videos from multiple
providers
- ocaml-ssl (libssl-ocaml-dev) can be used to enable https handlers
- libinotify-ocaml-dev can be used to enable use of inotify when monitoring
file changes (used for playlist reload)

I would advise again enabling support for the graphics library unless
there's a clear use case for it.

Thanks for the had work!
Romain

Bug#909328: More information and new backtrace

[Egmont Koblinger]

Hi Léon,

It indeed looks like a gnome-terminal crash. If only vim crashed, you'd
still have both of your terminal windows open.

All your backtraces are about vim. Do you have a backtrace of
gnome-terminal-server? That could help a lot. Without a backtrace, and
without being able to reproduce, unfortunately it's pretty unlikely that
I'll be able to find the problem.

I'm honestly lost about the various contradicting vim backtraces. The one
with SIGHUP, as you say, corresponds to the terminal disappearing, that's
the expected behavior in vim if the terminal crashes. But at the other two
occasions did vim really also segfault? (Now, it could be that vim doesn't
always handle correctly the terminal disappearing, and instead of a clean
SIGHUP exit it segfaults... who know.)

It's a bit suspicious to me that two pieces of software segfault at the
same time. Could it be a faulty hardware? Have you experienced any unusual
behavior in other software? Is there anything suspicious in "dmesg" output?

Could you please do the following for me: in gnome-terminal start "script
-f" and inside that start "vim". Do the ":set lines=999". Does it crash? If
it does, restart gnome-terminal and execute "cat typescript". Does it crash
again? If so, could you please attach this typescript file?

Thanks a lot,
egmont

Bug#904316: transition: boost-defaults

[Steve Robbins]

On Sunday, September 23, 2018 2:59:10 AM CDT Giovanni Mascellani wrote:

> I would suggest to avoid too much speculation on this point: uploading a
> new release to unstable is alone rather time consuming, because (beside
> the technical challenges of correctly installing dozens of binary
> packages) we have to fill a debian/copyright file for around 50k files
> with hundreds of contributors (this is why we were still stuck at 1.62).

If debian/copyright is indeed a blocker -- and it is for me, the primary 
reason I have stepped back from boost packaging -- then I think time is well 
spent on the unresolved policy issues around this file.

-Steve

Bug#909396: systemd: FTBFS on hppa and x32 - relocation can not be used when making a shared object

[John David Anglin]

On 2018-09-23 4:56 PM, Michael Biebl wrote:

Am 23.09.18 um 22:44 schrieb Michael Biebl:

Looking at the "ld" man page, it doesn't say anything about -fPIE, only
about -pie.
Can you please provide some references why on hppa the linker needs
-fPIE in addition to -pie

Fwiw, this command succeeded for 239-7

[425/1545] cc  -o src/udev/ata_id
'src/udev/src@udev@@ata_id@exe/ata_id_ata_id.c.o' -flto
-Wl,--no-undefined -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -pie
-Wl,--gc-sections -g -O2 -fdebug-prefix-map=/<>=. -Wformat
-Werror=format-security -Wl,--start-group src/udev/libudev_static.a
src/shared/libsystemd-shared-239.a src/libsystemd/libsystemd_static.a
src/basic/libbasic.a src/udev/libudev-basic.a -lrt
/usr/lib/hppa-linux-gnu/libcap.so -lacl
/usr/lib/hppa-linux-gnu/libcryptsetup.so -lgcrypt
/usr/lib/hppa-linux-gnu/libip4tc.so /usr/lib/hppa-linux-gnu/libip6tc.so
/usr/lib/hppa-linux-gnu/libselinux.so /usr/lib/hppa-linux-gnu/libidn.so
/usr/lib/hppa-linux-gnu/liblzma.so /usr/lib/hppa-linux-gnu/liblz4.so
/usr/lib/hppa-linux-gnu/libblkid.so -lrt
/usr/lib/hppa-linux-gnu/libmount.so -Wl,--end-group

Why is this now suddenly failing on hppa?
This is difficult to say as it's no longer possible to redo the 239-7 
without the exact same library

versions.  The meson package is now updated in sid.

Here is the gcc documentation for -flto:

@item -flto[=@var{n}]
@opindex flto
This option runs the standard link-time optimizer.  When invoked
with source code, it generates GIMPLE (one of GCC's internal
representations) and writes it to special ELF sections in the object
file.  When the object files are linked together, all the function
bodies are read from these ELF sections and instantiated as if they
had been part of the same translation unit.

To use the link-time optimizer, @option{-flto} and optimization
options should be specified at compile time and during the final link.
*It is recommended that you compile all the files participating in the**
**same link with the same options and also specify those options at**
**link time.*
For example:

@smallexample
gcc -c -O2 -flto foo.c
gcc -c -O2 -flto bar.c
gcc -o myprog -flto -O2 foo.o bar.o
@end smallexample

The first two invocations to GCC save a bytecode representation
of GIMPLE into special ELF sections inside @file{foo.o} and
@file{bar.o}.  The final invocation reads the GIMPLE bytecode from
@file{foo.o} and @file{bar.o}, merges the two files into a single
internal image, and compiles the result as usual.  Since both
@file{foo.o} and @file{bar.o} are merged into a single image, this
causes all the interprocedural analyses and optimizations in GCC to
work across the two files as if they were a single one.  This means,
for example, that the inliner is able to inline functions in
@file{bar.o} into functions in @file{foo.o} and vice-versa.

Another (simpler) way to enable link-time optimization is:

@smallexample
gcc -o myprog -flto -O2 foo.c bar.c
@end smallexample

The above generates bytecode for @file{foo.c} and @file{bar.c},
merges them together into a single GIMPLE representation and optimizes
them as usual to produce @file{myprog}.

The only important thing to keep in mind is that to enable link-time
optimizations you need to use the GCC driver to perform the link step.
GCC then automatically performs link-time optimization if any of the
objects involved were compiled with the @option{-flto} command-line option.
You generally
should specify the optimization options to be used for link-time
optimization though GCC tries to be clever at guessing an
optimization level to use from the options used at compile time
if you fail to specify one at link time.  You can always override
the automatic decision to do link-time optimization
by passing @option{-fno-lto} to the link command.

To make whole program optimization effective, it is necessary to make
certain whole program assumptions.  The compiler needs to know
what functions and variables can be accessed by libraries and runtime
outside of the link-time optimized unit.  When supported by the linker,
the linker plugin (see @option{-fuse-linker-plugin}) passes information
to the compiler about used and externally visible symbols.  When
the linker plugin is not available, @option{-fwhole-program} should be
used to allow the compiler to make these assumptions, which leads
to more aggressive optimization decisions.

When @option{-fuse-linker-plugin} is not enabled, when a file is
compiled with @option{-flto}, the generated object file is larger than
a regular object file because it contains GIMPLE bytecodes and the usual
final code (see @option{-ffat-lto-objects}.  This means that
object files with LTO information can be linked as normal object
files; if @option{-fno-lto} is passed to the linker, no
interprocedural optimizations are applied.  Note that when
@option{-fno-fat-lto-objects} is enabled the compile stage is faster
but you cannot perform a regular, non-LTO link on them.

...

--
John David Anglin  

Bug#909396: systemd: FTBFS on hppa and x32 - relocation can not be used when making a shared object

[John David Anglin]

On 2018-09-23 5:03 PM, Michael Biebl wrote:

Am 23.09.18 um 23:00 schrieb John David Anglin:

On 2018-09-23 4:44 PM, Michael Biebl wrote:

Can you please provide some references why on hppa the linker needs
-fPIE in addition to -pie

-fPIE is not a "ld" option.  It is a compiler option.

Right, that's why I don't see why it should be added to possible_link_flags
It's needed because the compiler driver is being used to optimize the 
link.  ld is not being
used directly.  The linker optimization involves various compilations 
which need the option.
The libtool driver is another example of this.  If ld were used 
directly, then the option wouldn't
be needed.  But then the build process would have to select the correct 
startup files, etc.


--
John David Anglin  dave.ang...@bell.net

Bug#722132:

[Roman Lebedev]

And this is a problem yet again with the current IWYU in debian sid.
Can it *please* be rebuilt yet again to fix this temporairly

Is there really no way to automate this?
To include it in automatic transition for it to be rebuilt each time
it's dependent llvm/clang version is rebuilt?

Roman.

Bug#909396: systemd: FTBFS on hppa and x32 - relocation can not be used when making a shared object

[Michael Biebl]

Am 23.09.18 um 23:00 schrieb John David Anglin:
> On 2018-09-23 4:44 PM, Michael Biebl wrote:

>> Can you please provide some references why on hppa the linker needs
>> -fPIE in addition to -pie
> -fPIE is not a "ld" option.  It is a compiler option. 

Right, that's why I don't see why it should be added to possible_link_flags


-- 
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#909396: systemd: FTBFS on hppa and x32 - relocation can not be used when making a shared object

[John David Anglin]

On 2018-09-23 4:44 PM, Michael Biebl wrote:

Am 23.09.18 um 22:27 schrieb John David Anglin:

Well the problem was latent in 239-7 and probably gcc changed.  The
thing is the error points
to an error in the link command.  On hppa, it is almost always necessary
to link shared and pie
objects with -fPIC or -fPIE, respectively.  There are compilations in
the link process and
the generated objects need to be position independent when doing shared
and pie links.

The attached patch fixes the failing link command although I'm not sure
it's optimal as
generally -fPIE and -pie need to be specified together.  Meson appears
to test the options
separately.  Putting them together as one option doesn't work.  The
systemd build completes
with the patch.  There was one timeout in the testsuite but the system
was under high load.

Looking at the "ld" man page, it doesn't say anything about -fPIE, only
about -pie.
Can you please provide some references why on hppa the linker needs
-fPIE in addition to -pie
-fPIE is not a "ld" option.  It is a compiler option.  Note that the 
code uses the "cc", compiler driver,
to perform the link.   The "-flto" option also is a compiler driver 
option that enables link-time optimization.
Take a look at what happens when you do a shared or pie link with 
compiler driver.  Add "-v" to see

the intermediate steps.

  -fPIC   Generate position-independent code if 
possible

  (large mode).

  -fPIE   Generate position-independent code for
  executables if possible (large mode).

  -flto   Enable link-time optimization.

  -pie Create a dynamically linked position independent
   executable.

  -shared  Create a shared library.

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#909396: systemd: FTBFS on hppa and x32 - relocation can not be used when making a shared object

[Michael Biebl]

Am 23.09.18 um 22:44 schrieb Michael Biebl:
> Looking at the "ld" man page, it doesn't say anything about -fPIE, only
> about -pie.
> Can you please provide some references why on hppa the linker needs
> -fPIE in addition to -pie

Fwiw, this command succeeded for 239-7

[425/1545] cc  -o src/udev/ata_id
'src/udev/src@udev@@ata_id@exe/ata_id_ata_id.c.o' -flto
-Wl,--no-undefined -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -pie
-Wl,--gc-sections -g -O2 -fdebug-prefix-map=/<>=. -Wformat
-Werror=format-security -Wl,--start-group src/udev/libudev_static.a
src/shared/libsystemd-shared-239.a src/libsystemd/libsystemd_static.a
src/basic/libbasic.a src/udev/libudev-basic.a -lrt
/usr/lib/hppa-linux-gnu/libcap.so -lacl
/usr/lib/hppa-linux-gnu/libcryptsetup.so -lgcrypt
/usr/lib/hppa-linux-gnu/libip4tc.so /usr/lib/hppa-linux-gnu/libip6tc.so
/usr/lib/hppa-linux-gnu/libselinux.so /usr/lib/hppa-linux-gnu/libidn.so
/usr/lib/hppa-linux-gnu/liblzma.so /usr/lib/hppa-linux-gnu/liblz4.so
/usr/lib/hppa-linux-gnu/libblkid.so -lrt
/usr/lib/hppa-linux-gnu/libmount.so -Wl,--end-group

Why is this now suddenly failing on hppa?


-- 
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#909396: systemd: FTBFS on hppa and x32 - relocation can not be used when making a shared object

[Michael Biebl]

Am 23.09.18 um 22:27 schrieb John David Anglin:
> Well the problem was latent in 239-7 and probably gcc changed.  The
> thing is the error points
> to an error in the link command.  On hppa, it is almost always necessary
> to link shared and pie
> objects with -fPIC or -fPIE, respectively.  There are compilations in
> the link process and
> the generated objects need to be position independent when doing shared
> and pie links.
> 
> The attached patch fixes the failing link command although I'm not sure
> it's optimal as
> generally -fPIE and -pie need to be specified together.  Meson appears
> to test the options
> separately.  Putting them together as one option doesn't work.  The
> systemd build completes
> with the patch.  There was one timeout in the testsuite but the system
> was under high load.

Looking at the "ld" man page, it doesn't say anything about -fPIE, only
about -pie.
Can you please provide some references why on hppa the linker needs
-fPIE in addition to -pie


-- 
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#906349: [Pkg-pascal-devel] Bug#906349: doublecmd: FTBFS in buster/sid (tries to write in /usr)

[Abou Al Montacir]

Hi Graham,
On Fri, 2018-09-21 at 15:40 +0200, Graham Inggs wrote:
> Hi Abou
> 
> On 27/08/2018 18:03, Abou Al Montacir wrote:
> > Maybe we shall think more about this change. Removing the manually flag
> > leads to
> > a deeper question: Do we need to distribute LCL units in binary form if they
> > will get recompiled anyway?
> 
> Have you had any time to consider this?
> 
> Both doublecmd and ddrescueview have been removed from testing now.
I've reverted this in b9ccece9. However this means that Bug#898310 needs to be
reopen.
-- 
Cheers,
Abou Al Montacir



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

Bug#909446: [debian-mysql] Bug#909446: Error installing mysql-server on Debian 9 Stretch (dependency problems)

[Olaf van der Spek]

On Sun, Sep 23, 2018 at 8:56 PM, Konrád Lőrinczi  wrote:
>  libhtml-template-perl : Depends: libcgi-pm-perl but it is not going to be
> installed or
>   perl (< 5.19) but 5.26.2-7 is to be
> installed

Hi,

Where did perl 5.26 come from?
AFAIK stretch has  5.24..

Gr,

-- 
Olaf

Bug#909396: systemd: FTBFS on hppa and x32 - relocation can not be used when making a shared object

[John David Anglin]

On 2018-09-23 4:06 AM, Michael Biebl wrote:

One obvious difference is that 239-7 was compiled with meson 0.47.1-1,
239-8 and 239-9 with 0.47.2-1

The systemd build breaks completely with meson 0.48.0-1.

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#909396: systemd: FTBFS on hppa and x32 - relocation can not be used when making a shared object

[John David Anglin]

On 2018-09-23 9:27 AM, Michael Biebl wrote:

Am 23.09.18 um 14:43 schrieb John David Anglin:

On 2018-09-23 4:06 AM, Michael Biebl wrote:

Am 23.09.18 um 10:01 schrieb Michael Biebl:


There weren't any relevant changes between 239-7 and 239-9 afaics, which
makes me think that this is rather a toolchain issue on hppa and not a
bug in systemd itself.

Would be great if you can investigate this.

One obvious difference is that 239-7 was compiled with meson 0.47.1-1,
239-8 and 239-9 with 0.47.2-1

Okay.  I don't know anything about systemd build and where one would
modify link options.
I can try if you can suggest a possible location for change.

It might be the "-flto" option would change things.  It causes various
compilations to occur
which might cause error linking.

My point is, that the systemd build system did not change between 239-7
and 239-8. So I suspect the root cause is elsewhere and not in systemd
directly.
Well the problem was latent in 239-7 and probably gcc changed.  The 
thing is the error points
to an error in the link command.  On hppa, it is almost always necessary 
to link shared and pie
objects with -fPIC or -fPIE, respectively.  There are compilations in 
the link process and
the generated objects need to be position independent when doing shared 
and pie links.


The attached patch fixes the failing link command although I'm not sure 
it's optimal as
generally -fPIE and -pie need to be specified together.  Meson appears 
to test the options
separately.  Putting them together as one option doesn't work.  The 
systemd build completes
with the patch.  There was one timeout in the testsuite but the system 
was under high load.


Dave

--
John David Anglin  dave.ang...@bell.net

--- meson.build.save2018-09-23 14:27:45.765707025 -0400
+++ meson.build 2018-09-23 14:40:20.002886449 -0400
@@ -341,7 +341,7 @@
 # enable it when we are linking against them
 if not fuzzer_build
 possible_cc_flags += '-fPIE'
-possible_link_flags += '-pie'
+possible_link_flags += [ '-fPIE', '-pie', ]
 endif
 
 if cc.get_id() == 'clang'

Bug#906816: thunderbird: Does not start

[Maximilian Gaukler]

I'd like to add that the bug you linked to has a patch upstream, which 
applies cleanly:


apt source thunderbird
cd thunderbird-60.0/
cd comm/
curl https://bug1482248.bmoattachments.org/attachment.cgi?id=8999262 | 
patch -p1

dpkg-buildpackage -b


Unfortunately, building on my machine (stable) fails due to unavailable 
build dependencies, so I cannot say if it really helps.


Would it be possible to add this patch to the debian package (or just 
switch to the newer upstream version?)?

Bug#907674: preparing an upload of xscreensaver 5.40 (and later)

[Antoine Beaupré]

On 2018-09-23 22:08:03, Tormod Volden wrote:
> On Wed, Sep 5, 2018 at 12:35 AM, Antoine Beaupré wrote:
>> Hi Tormod!
>>
>> I've noticed the Debian package of xscreensaver is somewhat lagging
>> behind the upstream version in "unstable". I also noticed you have done
>> good work in the git repository to package 5.39.
>>
>> I have taken that work and added packaging of 5.40 on top of that. In
>> accordance with the "collab-maint" policies, I have also pushed the
>> results to the git repository.
>>
>> I would be happy to sponsor an upload if that is what is holding you
>> from publishing those goods in the Debian archive. If you are not
>> available, I will proceed with a non-maintainer upload within four weeks
>> unless otherwise advised.
>>
>> Thank you for your hard work!
>
> Hi Antoine,
>
> Thanks! Yes, I have been waiting for sponsoring, but my regular
> sponsor seems MIA. And I didn't see your messages before now... Maybe
> because the address you cc'ed looks a bit scrambled by your mailer?

I did mess up one mailing, but resent it with a proper email. The email
was sent correctly to Google's servers on September 4th:

Sep  4 18:41:44 marcos postfix/smtp[3537]: A5EBA10E209: 
to=, 
relay=gmail-smtp-in.l.google.com[209.85.234.26]:25, delay=2, 
delays=0.03/0.03/1.6/0.4, dsn=2.0.0, status=sent (250 2.0.0 OK 1536100904 
l11-v6si303920itb.24 - gsmtp)

Maybe it ended up in your spam folder?

> Your changes look good. If your interested in becoming a co-maintainer
> or regular sponsor, please let me know.

I'm not sure I'm ready yet for the thankless task of maintaining a
package with such a hostile upstream (and I thank you for that work
while I'm here!) but I'd be happy to review future uploads.

Just give me a shout.

Cheers!

A.

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

Bug#909421: Warning from ldconfig

[Drew Parsons]

Package: libscotch-6.0
Followup-For: Bug #909421

I can't reproduce your ldconfig warning. I had it during development
but not in the final release. Are you sure that you're using the
official debs from the Debian archive?

Drew

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

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

Versions of packages libscotch-6.0 depends on:
ii  libbz2-1.0   1.0.6-9
ii  libc62.27-6
ii  liblzma5 5.2.2-1.3
ii  libopenmpi3  3.1.2-4
ii  zlib1g   1:1.2.11.dfsg-1

libscotch-6.0 recommends no packages.

libscotch-6.0 suggests no packages.

-- no debconf information

Bug#907674: preparing an upload of xscreensaver 5.40 (and later)

[Tormod Volden]

On Wed, Sep 5, 2018 at 12:35 AM, Antoine Beaupré wrote:
> Hi Tormod!
>
> I've noticed the Debian package of xscreensaver is somewhat lagging
> behind the upstream version in "unstable". I also noticed you have done
> good work in the git repository to package 5.39.
>
> I have taken that work and added packaging of 5.40 on top of that. In
> accordance with the "collab-maint" policies, I have also pushed the
> results to the git repository.
>
> I would be happy to sponsor an upload if that is what is holding you
> from publishing those goods in the Debian archive. If you are not
> available, I will proceed with a non-maintainer upload within four weeks
> unless otherwise advised.
>
> Thank you for your hard work!

Hi Antoine,

Thanks! Yes, I have been waiting for sponsoring, but my regular
sponsor seems MIA. And I didn't see your messages before now... Maybe
because the address you cc'ed looks a bit scrambled by your mailer?

Your changes look good. If your interested in becoming a co-maintainer
or regular sponsor, please let me know.

Best regards,
Tormod

Bug#909447: snapd-glib: FTBFS on mips, mipsel: symbols

[Ivo De Decker]

package: snapd-glib
version: 1.42-1
severity: serious
tags: ftbfs

Hi,

The latest version of snapd-glib in unstable fails on mips, mipsel:

https://buildd.debian.org/status/package.php?p=snapd-glib

It seems to be an issue with the symbols file.

Cheers,

Ivo

Bug#909446: Error installing mysql-server on Debian 9 Stretch (dependency problems)

[Konrád Lőrinczi]

Package: mysql-server
Severity: important

Dear Maintainer,

Error installing mysql-server on Debian 9 Stretch (dependency problems).
Using Debian 9.5, fresh install. I want to install mysql-server, but I run
into dependency problems.


The following packages have unmet dependencies:
 mysql-server : Depends: default-mysql-server but it is not going to be
installed
E: Unable to correct problems, you have held broken packages.

apt-get install mysql-server default-mysql-server
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:
 default-mysql-server : Depends: mariadb-server-10.1 but it is not going to
be installed
E: Unable to correct problems, you have held broken packages.

sudo apt-get install mysql-server default-mysql-server mariadb-server-10.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:
 mariadb-server-10.1 : Depends: libdbi-perl but it is not going to be
installed
   Recommends: libhtml-template-perl but it is not
going to be installed
E: Unable to correct problems, you have held broken packages.

sudo apt-get install mysql-server default-mysql-server mariadb-server-10.1
libhtml-template-perl
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:
 libhtml-template-perl : Depends: libcgi-pm-perl but it is not going to be
installed or
  perl (< 5.19) but 5.26.2-7 is to be
installed
 mariadb-server-10.1 : Depends: libdbi-perl but it is not going to be
installed
E: Unable to correct problems, you have held broken packages.

sudo apt-get install mysql-server default-mysql-server mariadb-server-10.1
libdbi-perl
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:
 libdbi-perl : Depends: perlapi-5.24.1
E: Unable to correct problems, you have held broken packages.


apt-cache policy
Package files:
 100 /var/lib/dpkg/status
 release a=now
 500 http://security.debian.org/debian-security stretch/updates/contrib
amd64 Packages
 release
v=9,o=Debian,a=stable,n=stretch,l=Debian-Security,c=contrib,b=amd64
 origin security.debian.org
 500 http://security.debian.org/debian-security stretch/updates/main amd64
Packages
 release
v=9,o=Debian,a=stable,n=stretch,l=Debian-Security,c=main,b=amd64
 origin security.debian.org
 500 http://deb.debian.org/debian stretch-updates/main amd64 Packages
 release
o=Debian,a=stable-updates,n=stretch-updates,l=Debian,c=main,b=amd64
 origin deb.debian.org
 500 http://deb.debian.org/debian stretch/main amd64 Packages
 release v=9.5,o=Debian,a=stable,n=stretch,l=Debian,c=main,b=amd64
 origin deb.debian.org
Pinned packages:


apt policy perl perl-base
perl:
  Installed: 5.26.2-7
  Candidate: 5.26.2-7
  Version table:
 *** 5.26.2-7 100
100 /var/lib/dpkg/status
 5.24.1-3+deb9u4 500
500 http://deb.debian.org/debian stretch/main amd64 Packages
500 http://security.debian.org/debian-security stretch/updates/main
amd64 Packages
perl-base:
  Installed: 5.26.2-7
  Candidate: 5.26.2-7
  Version table:
 *** 5.26.2-7 100
100 /var/lib/dpkg/status
 5.24.1-3+deb9u4 500
500 http://deb.debian.org/debian stretch/main amd64 Packages
500 http://security.debian.org/debian-security stretch/updates/main
amd64 Packages


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

Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)

Bug#909439: autopkgtest/debci: misleading "Version" if a new version becomes available during testing

[Paul Gevers]

Hi,

On 23-09-18 19:29, Rebecca N. Palmer wrote:
>> What kind of logic do you have in mind?
> 
> If any binary of the package under test is being installed and isn't the
> same version as the source, abort the run as a tmpfail.  (At least in a
> standard debci run, as some documented uses probably want to allow such
> mismatches:
> https://sources.debian.org/src/autopkgtest/5.5/doc/README.running-tests.rst/#L65
> )

As I mentioned in my previous reply, I consider the current behavior a
feature, so I don't like the logic you mention above. I have code laying
around for autopkgtest support of specifying the version one wants to
test. failing (or tmpfail, but I don't think I like that) in the case
where the version isn't matching the one requested makes sense to me.

> I don't know if this is actually worth the effort; it also assumes
> debci's displayed Version is the source version.

What autopkgtest outputs is the version of the package it took the test
from, which is still correct. It is however confusing in cases like this
(and in cases like those reported in bug #896023). debci just displays
whatever autopkgtest outputs here.

I guess the point is really that people, understandably, take the
version to mean something else than it really means as in most cases the
version is the same to what they believe it means. debci could stop
showing the version, but I don't think that is actually helpful except
in rare cases.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#909445: schroot FTCBFS: multiple reasons

[Helmut Grohne]

Source: schroot
Version: 1.6.10-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

schroot fails to cross build from source. The immediate reason is that
it configures for the build architecture and thus fails finding
dependencies that are only requested for the host architecture. Using
dh_auto_configure fixes that.

Then it fails configuring, because it uses check_cxx_source_runs and
that doesn't work at all for cross compilation. The check for cppunit
can be converted to check_cxx_source_compiles without loss in precision.
The regex check looses precision, but on Debian std::regex works
sufficiently well for all architectures, so assuming that it works
during cross compilation seems like a reasonable assumption and native
builds continue to use the thorough check.

Finally it runs tests despite DEB_BUILD_OPTIONS=nocheck. Tests fail.
Properly checking the nocheck option fixes that.

After all of these, schroot cross builds successfully. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru schroot-1.6.10/debian/changelog 
schroot-1.6.10/debian/changelog
--- schroot-1.6.10/debian/changelog 2018-06-06 11:29:14.0 +0200
+++ schroot-1.6.10/debian/changelog 2018-09-23 13:50:19.0 +0200
@@ -1,3 +1,13 @@
+schroot (1.6.10-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_configure pass cross flags to cmake.
++ cross.patch: Avoid check_cxx_source_runs.
++ Support DEB_BUILD_OPTIONS=nocheck.
+
+ -- Helmut Grohne   Sun, 23 Sep 2018 13:50:19 +0200
+
 schroot (1.6.10-5) unstable; urgency=medium
 
   * Orphan packages, this fixes the bouncing maintainer email. Closes: #899851
diff --minimal -Nru schroot-1.6.10/debian/patches/cross.patch 
schroot-1.6.10/debian/patches/cross.patch
--- schroot-1.6.10/debian/patches/cross.patch   1970-01-01 01:00:00.0 
+0100
+++ schroot-1.6.10/debian/patches/cross.patch   2018-09-23 13:50:19.0 
+0200
@@ -0,0 +1,46 @@
+--- schroot-1.6.10.orig/CMakeLists.txt
 schroot-1.6.10/CMakeLists.txt
+@@ -96,7 +96,7 @@
+ # Configure testing
+ SET(CMAKE_REQUIRED_LIBRARIES_SAVE ${CMAKE_REQUIRED_LIBRARIES})
+ SET(CMAKE_REQUIRED_LIBRARIES ${CMAKE_REQUIRED_LIBRARIES} cppunit)
+-check_cxx_source_runs(
++check_cxx_source_compiles(
+ "#include 
+ 
+ int main() {
+--- schroot-1.6.10.orig/cmake/regex-checks.cmake
 schroot-1.6.10/cmake/regex-checks.cmake
+@@ -3,7 +3,23 @@
+ function(regex_test namespace header library outvar outlib)
+   set(CMAKE_REQUIRED_LIBRARIES_SAVE ${CMAKE_REQUIRED_LIBRARIES})
+   set(CMAKE_REQUIRED_LIBRARIES ${CMAKE_REQUIRED_LIBRARIES} ${library})
+-  check_cxx_source_runs(
++
++  if (CMAKE_CROSSCOMPILING)
++message(WARNING "Using simplified regex check for cross compilation. 
Assuming that regex implementations work correctly.")
++check_cxx_source_compiles(
++"#include <${header}>
++
++int main() {
++  ${namespace} foo(\"x\");
++  ${namespace} bar(\"x\", ${namespace}::extended);
++  std::string test(\"x\");
++  ${namespace}_search(test, foo);
++  ${namespace}_match(test, foo);
++  return 0;
++}"
++${outvar})
++  else(CMAKE_CROSSCOMPILING)
++check_cxx_source_runs(
+ "#include <${header}>
+ #include 
+ 
+@@ -43,6 +59,7 @@
+   return 0;
+ }"
+ ${outvar})
++  endif(CMAKE_CROSSCOMPILING)
+ 
+   set(CMAKE_REQUIRED_LIBRARIES ${CMAKE_REQUIRED_LIBRARIES_SAVE})
+ 
diff --minimal -Nru schroot-1.6.10/debian/patches/series 
schroot-1.6.10/debian/patches/series
--- schroot-1.6.10/debian/patches/series2018-06-06 11:29:14.0 
+0200
+++ schroot-1.6.10/debian/patches/series2018-09-23 13:50:19.0 
+0200
@@ -9,3 +9,4 @@
 Unmount-everything-that-we-can-instead-of-giving-up.patch
 fix-killprocs.patch
 fix-bash-completion.patch
+cross.patch
diff --minimal -Nru schroot-1.6.10/debian/rules schroot-1.6.10/debian/rules
--- schroot-1.6.10/debian/rules 2018-06-06 11:29:14.0 +0200
+++ schroot-1.6.10/debian/rules 2018-09-23 13:50:19.0 +0200
@@ -44,14 +44,10 @@
 override_dh_auto_configure: debian/build/CMakeCache.txt
 
 debian/build/CMakeCache.txt: CMakeLists.txt
-   mkdir -p $(dir $@)
-   cd $(dir $@) ; \
- GTEST_ROOT="$(CURDIR)/debian/build/gtest" \
- CFLAGS="$(CFLAGS) $(CPPFLAGS)" \
- CXXFLAGS="$(CXXFLAGS) $(CPPFLAGS)" \
- cmake -DCMAKE_INSTALL_PREFIX=/usr \
-   -DCMAKE_INSTALL_SYSCONFDIR=/etc \
-   -DCMAKE_INSTALL_LOCALSTATEDIR=/var \
+   GTEST_ROOT="$(CURDIR)/debian/build/gtest" \
+   CFLAGS="$(CFLAGS) $(CPPFLAGS)" \
+   CXXFLAGS="$(CXXFLAGS) $(CPPFLAGS)" \
+   dh_auto_configure --builddirectory=$(dir $@) -- \
-DCMAKE_INSTALL_LIBEXECDIR=lib \
-DSCHROOT_LIBEXEC_DIR=/$(LIBDIR)/schroot \
-Ddebug=OFF -Ddchroot=OFF -Ddchroot-dsa=OFF \
@@ -86,8 +82,10 @@
 # Lintian overrides
mkdir -p $(CURDIR)/debian/schroot/usr/share/lintian/overrides
cp $(CURDIR)/debian/schroot.lintian-overrides 

Bug#907131: debuild: add --no-sign and --force-sign option in --help output and man page

[Mattia Rizzolo]

On Fri, Aug 24, 2018 at 09:29:48AM +0300, Sergey Alyoshin wrote:
> diff -Nur devscripts-2.18.3_orig/scripts/debuild.1 
> devscripts-2.18.3/scripts/debuild.1
> --- devscripts-2.18.3_orig/scripts/debuild.1  2018-03-06 17:42:39.0 
> +0300
> +++ devscripts-2.18.3/scripts/debuild.1   2018-08-23 23:43:54.058545238 
> +0300
> @@ -289,6 +289,12 @@
>  .B \-\-no\-lintian
>  Do not run \fBlintian\fR after \fBdpkg-buildpackage\fR.
>  .TP
> +.B \-\-force\-sign
> +Do sign after \fBdpkg-buildpackage\fR.
> +.TP
> +.B \-\-no\-sign
> +Do not sign after \fBdpkg-buildpackage\fR.
> +.TP

Not sure I want them tbh...

The manpage already mentions that the signing options are those of
dpkg-buildpackage, and with debuild that now is a full wrapper around it
feels superflous to me (and misleading, there are many other options
related to signing).

I'd personally prefer to not document these options here, unless
somebody else thinks we should.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#902817: fail2ban: diff for NMU version 0.10.2-2.1

[Mattia Rizzolo]

Control: tags 902817 + patch
Control: tags 902817 + pending

Dear maintainer,

I've prepared an NMU for fail2ban (versioned as 0.10.2-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
regards,
Mattia Rizzolo

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

 changelog   |7 +++
 patches/0005-python37.patch |   86 
 patches/series  |1 
 3 files changed, 94 insertions(+)

diff -Nru fail2ban-0.10.2/debian/changelog fail2ban-0.10.2/debian/changelog
--- fail2ban-0.10.2/debian/changelog	2018-04-04 06:47:53.0 +0200
+++ fail2ban-0.10.2/debian/changelog	2018-09-23 20:14:23.0 +0200
@@ -1,3 +1,10 @@
+fail2ban (0.10.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch from upstream to fix SyntaxError with Python 3.7. Closes: #902817
+
+ -- Mattia Rizzolo   Sun, 23 Sep 2018 20:14:23 +0200
+
 fail2ban (0.10.2-2) unstable; urgency=medium
 
   [ Arturo Borrero Gonzalez ]
diff -Nru fail2ban-0.10.2/debian/patches/0005-python37.patch fail2ban-0.10.2/debian/patches/0005-python37.patch
--- fail2ban-0.10.2/debian/patches/0005-python37.patch	1970-01-01 01:00:00.0 +0100
+++ fail2ban-0.10.2/debian/patches/0005-python37.patch	2018-09-23 20:13:46.0 +0200
@@ -0,0 +1,86 @@
+From ac9d5f61e7e9151f7518c26db192dd6d0bf56591 Mon Sep 17 00:00:00 2001
+From: sebres 
+Date: Wed, 24 Jan 2018 15:47:05 +0100
+Subject: [PATCH] rewrite keywords reserved in python 3.7 (`async` ->
+ `nonsync`)
+
+Origin: upstream, https://github.com/fail2ban/fail2ban/commit/ac9d5f61e7e9151f7518c26db192dd6d0bf56591
+Bug-Debian: https://bugs.debian.org/902817
+
+---
+ fail2ban/client/fail2banclient.py |  6 +++---
+ fail2ban/client/fail2banserver.py | 23 +--
+ 2 files changed, 16 insertions(+), 13 deletions(-)
+
+diff --git a/fail2ban/client/fail2banclient.py b/fail2ban/client/fail2banclient.py
+index 0a1ae4f11..13ebcdef4 100755
+--- a/fail2ban/client/fail2banclient.py
 b/fail2ban/client/fail2banclient.py
+@@ -228,9 +228,9 @@ def __startServer(self, background=True):
+ 		return True
+ 
+ 	##
+-	def configureServer(self, async=True, phase=None):
+-		# if asynchron start this operation in the new thread:
+-		if async:
++	def configureServer(self, nonsync=True, phase=None):
++		# if asynchronous start this operation in the new thread:
++		if nonsync:
+ 			th = Thread(target=Fail2banClient.configureServer, args=(self, False, phase))
+ 			th.daemon = True
+ 			return th.start()
+diff --git a/fail2ban/client/fail2banserver.py b/fail2ban/client/fail2banserver.py
+index 6c57fbf88..afe36cf43 100644
+--- a/fail2ban/client/fail2banserver.py
 b/fail2ban/client/fail2banserver.py
+@@ -164,21 +164,24 @@ def start(self, argv):
+ 	cli = self._Fail2banClient()
+ 	return cli.start(argv)
+ 
+-			# Start the server:
+-			from ..server.utils import Utils
+-			# background = True, if should be new process running in background, otherwise start in foreground
+-			# process will be forked in daemonize, inside of Server module.
+-			# async = True, if started from client, should...
++			# Start the server, corresponding options:
++			#   background = True, if should be new process running in background, otherwise start in
++			# foreground process will be forked in daemonize, inside of Server module.
++			#   nonsync = True, normally internal call only, if started from client, so configures
++			# the server via asynchronous thread.
+ 			background = self._conf["background"]
+-			async = self._conf.get("async", False)
++			nonsync = self._conf.get("async", False)
++
+ 			# If was started not from the client:
+-			if not async:
++			if not nonsync:
++# Load requirements on demand (we need utils only when asynchronous handling):
++from ..server.utils import Utils
+ # Start new thread with client to read configuration and
+ # transfer it to the server:
+ cli = self._Fail2banClient()
+ phase = dict()
+ logSys.debug('Configure via async client thread')
+-cli.configureServer(async=True, phase=phase)
++cli.configureServer(phase=phase)
+ # wait, do not continue if configuration is not 100% valid:
+ Utils.wait_for(lambda: phase.get('ready', None) is not None, self._conf["timeout"], 0.001)
+ logSys.log(5, '  server phase %s', phase)
+@@ -195,7 +198,7 @@ def _server_ready():
+ 			pid = os.getpid()
+ 			server = Fail2banServer.startServerDirect(self._conf, background)
+ 			# notify waiting thread server ready resp. done (background execution, error case, etc):
+-			if not async:
++			if not nonsync:
+ _server_ready()
+ 			# 

Bug#909444: Minor security issues, CVE-2018-{16391-16393,16418-16427}

[Eric Dorland]

Package: opensc
Version: 0.16.0-3
Severity: important
Tags: security

https://security-tracker.debian.org/tracker/source-package/opensc has the 
complete list.


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

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

Versions of packages opensc depends on:
ii  libc6  2.27-5
ii  libglib2.0-0   2.56.1-2
ii  libreadline7   7.0-5
ii  libssl1.1  1.1.1~~pre9-1
ii  opensc-pkcs11  0.18.0-3
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages opensc recommends:
ii  pcscd  1.8.23-3

opensc suggests no packages.

-- no debconf information

Bug#906075: gnunet: diff for NMU version 0.10.1-5.1

[Bertrand Marc]

Hi Adrian,

Le 22/09/2018 à 09:49, Adrian Bunk a écrit :
> Control: tags 906075 + patch
> Control: tags 906075 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for gnunet (versioned as 0.10.1-5.1) and uploaded 
> it to DELAYED/15. Please feel free to tell me if I should cancel it.
>
> cu
> Adrian
>
Be my guest.

Thanks,
Bertrand

Bug#881845: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

[Ximin Luo]

Aron Xu:
> [..]
>>
>> Aron, the next version 1.27.1 is already in binary-NEW so the same issue 
>> will block testing migration again, when that gets accepted.
>>
>> Earlier you said "Binary only upload from porter is allowed [..]" but I am 
>> not sure the other porters have access to a loongson-3a box. Will you 
>> continue to run builds of new rustc versions on your box? I think that is 
>> the key point here.
>>
> 
> Will do that and see if we can get the issue either fixed or have a
> blacklist placed at the same time.
> 

I have just uploaded 1.29.0 to unstable. It will need manual building with a 
non-buggy mips machine, to unblock us for Debian Testing. The previous build 
1.29.0+dfsg1-1~exp1 failed due to hanging atomic tests:

https://buildd.debian.org/status/fetch.php?pkg=rustc=mips64el=1.29.0%2Bdfsg1-1%7Eexp1=1537686627=0

test sync.rs - sync::Arc (line 124) ... test sync.rs - sync::Arc (line 124) has 
been running for over 60 seconds
test sync.rs - sync::Arc::downgrade (line 418) ... test sync.rs - 
sync::Arc::downgrade (line 418) has been running for over 60 seconds
test sync.rs - sync::Arc::get_mut (line 856) ... test sync.rs - 
sync::Arc::get_mut (line 856) has been running for over 60 seconds
test sync.rs - sync::Arc::make_mut (line 769) ... test sync.rs - 
sync::Arc::make_mut (line 769) has been running for over 60 seconds
E: Build killed with signal TERM after 150 minutes of inactivity

I still think we should just RM rustc on mips64el.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#909379: Info received (Bug#909379: segfault when leaving the python3-dbg interpreter)

[Andreas Beckmann]

On 2018-09-23 19:22, Tomasz Rybak wrote:
> IFAIR PyOpenCL was never built against Python3.7.

> Feel free to do NMU, but be careful with current git version (-3).

As a binNMU by the release team should be sufficient, there should be no
need for anyone to NMU.


Andreas

PS: feel free to ping me if you need a "sponsor" for uploading a new
version before your new key is available

Bug#909443: apt-clone: Silently fails when dpkg-repack fails

[Ben Wiederhake]

Package: apt-clone
Version: 0.4.1
Severity: normal

Dear Maintainer,

* What led up to the situation?

I invoked `apt-clone --with-dpkg-repack my-repacked.apt-clone.tar.gz`.

I have teamviewer installed, so one of the many packages is teamviewer.
Apparently, I deleted /etc/apt/sources.list.d/teamviewer.list at some point in
time.
This may have confused dpkg-repack.

* What was the outcome of this action?

The teamviewer package did not get repacked, and was missing from the generated
tarball.
No exit code indicated that there was an error.  (So automation would run into
trouble).

There was only one warning from apt-clone, buried among many other similar
lines:

dpkg-deb: Fehler: Conffile »/etc/apt/sources.list.d/teamviewer.list« kommt
nicht im Paket vor
dpkg -repack: Error running: dpkg-deb --build dpkg-repack.teamviewer.tTztGb
.
dpkg -repack: Problems were encountered in processing.
dpkg -repack: The package may be broken.

If this had been an important package (i.e., the printer drivers that brought
me here),
and if I hadn't caught this, then I would have been in trouble.

* What outcome did you expect instead?

I expected one of the following:
- Ideal: Set a non-zero exit code, include the "maybe broken" package anyway.
- Acceptable: Set a non-zero exit code.
- Acceptable: Set a non-zero exit code, refuse to generate apt-clone tarball.

Cheers,
Ben



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

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

Versions of packages apt-clone depends on:
ii  lsb-release  9.20170808
ii  python3  3.6.5-3
ii  python3-apt  1.6.2

Versions of packages apt-clone recommends:
ii  dpkg-repack  1.44

apt-clone suggests no packages.

-- no debconf information

Bug#902582: (some kind of) transition: add python3.7 as a supported python3 version

[Andreas Beckmann]

On 2018-09-23 19:43, Adam D. Barratt wrote:
> On Sun, 2018-09-23 at 15:40 +0200, Andreas Beckmann wrote:
>> Followup-For: Bug #902582
>>
>> Hi,
>>
>> the ben file is bad since it misses -dbg packages, the following
>> should
>> work better:
>>
>> is_affected = .build-depends ~ /python3-all-dev/;
>> is_good = .depends ~ /python3 \(<< 3\.8\)/ | .depends ~ /python3.7/ |
>> /python3-dbg \(<< 3\.8\)/ | .depends ~ /python3.7-dbg/;
> 
> That's missing a ".depends ~" on the third clause, making ben unhappy;
> fixed.

Thanks. Copy+paste error, not tested :-) The lines looked already long enough 
...

And as Frederic-Emmanuel Picca pointed out, there is also python3-all-dbg, so

is_affected = .build-depends ~ /python3-all-dev/ | .build-depends ~ 
/python3-all-dbg/;

(or something like that)


Andreas

Bug#909442: outguess: FTBFS in some architectures

[Joao Eriberto Mota Filho]

Package: outguess
Version: 0.2+dfsg.1-1
Severity: grave
Tags: upstream
Justification: renders package unusable

outguess is causing a FTBFS in experimental[1] for amd64, arm64, ppc64el,
powerpc and ppc64. It is a consequence of the changes to try solve #882538.

[1] https://buildd.debian.org/status/package.php?p=outguess=experimental

Regards,

Eriberto

Bug#902582: (some kind of) transition: add python3.7 as a supported python3 version

[Adam D. Barratt]

On Sun, 2018-09-23 at 15:40 +0200, Andreas Beckmann wrote:
> Followup-For: Bug #902582
> 
> Hi,
> 
> the ben file is bad since it misses -dbg packages, the following
> should
> work better:
> 
> is_affected = .build-depends ~ /python3-all-dev/;
> is_good = .depends ~ /python3 \(<< 3\.8\)/ | .depends ~ /python3.7/ |
> /python3-dbg \(<< 3\.8\)/ | .depends ~ /python3.7-dbg/;

That's missing a ".depends ~" on the third clause, making ben unhappy;
fixed.

Regards,

Adam

Bug#909441: ngspice: new upstream version available

[Oswald Buddenhagen]

Package: ngspice
Version: 27-1
Severity: wishlist

Dear Maintainer,

upstream released version 28 with some interesting new features 
a few months ago.

Bug#731429: gdm3: Set up tap to click by default

[tom]

Package: gdm3
Version: 3.30.0-1
Followup-For: Bug #731429

Dear Maintainer,

The problem described by the original reporter in 2013 still exists: The gdm
login screen ignores any mouse-related settings by the users which might come
as a surprise on laptops (especially on modern notebooks where users are used
to use tap to click) and desktops. IMHO the problem isn't just about "tap to
click" but also about mouse speed and similar parameters.

IMHO it would be best if the gdm login screen where configured so that the
mouse settings of the last user that logged in via gdm are used. If this isn't
possible, the users' mouse configuration dialog should probably include a
button that allows them to copy the current settings to the gdm login screen.
This way, the behaviour of the mouse/touchpad on the login screen would
perfectly line up with the users' expectations.

Regards,
Tom



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

Kernel: Linux 4.18.0-1-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)
LSM: AppArmor: enabled

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.45-1
ii  adduser   3.117
ii  dconf-cli 0.30.0-1
ii  dconf-gsettings-backend   0.30.0-1
ii  debconf [debconf-2.0] 1.5.69
ii  gir1.2-gdm-1.03.30.0-1
ii  gnome-session [x-session-manager] 3.28.1-1
ii  gnome-session-bin 3.28.1-1
ii  gnome-settings-daemon 3.30.0-1
ii  gnome-shell   3.30.0-1
ii  gnome-terminal [x-terminal-emulator]  3.30.0-1
ii  gsettings-desktop-schemas 3.28.0-1
ii  libaccountsservice0   0.6.45-1
ii  libaudit1 1:2.8.4-2
ii  libc6 2.27-6
ii  libcanberra-gtk3-00.30-6
ii  libcanberra0  0.30-6
ii  libgdk-pixbuf2.0-02.38.0+dfsg-6
ii  libgdm1   3.30.0-1
ii  libglib2.0-0  2.58.0-4
ii  libglib2.0-bin2.58.0-4
ii  libgtk-3-03.24.0-3
ii  libkeyutils1  1.5.9-9.3
ii  libpam-modules1.1.8-3.8
ii  libpam-runtime1.1.8-3.8
ii  libpam-systemd239-9
ii  libpam0g  1.1.8-3.8
ii  librsvg2-common   2.40.20-3
ii  libselinux1   2.8-1+b1
ii  libsystemd0   239-9
ii  libwrap0  7.6.q-27
ii  libx11-6  2:1.6.6-1
ii  libxau6   1:1.0.8-1+b2
ii  libxcb1   1.13-3
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  9.20170808
ii  mutter [x-window-manager] 3.30.0-1
ii  policykit-1   0.105-21
ii  ucf   3.0038
ii  x11-common1:7.7+19
ii  x11-xserver-utils 7.7+8
ii  xterm [x-terminal-emulator]   335-1

Versions of packages gdm3 recommends:
ii  at-spi2-core2.30.0-2
ii  desktop-base9.0.7
ii  x11-xkb-utils   7.7+4
ii  xserver-xephyr  2:1.20.1-1
ii  xserver-xorg1:7.7+19
ii  zenity  3.28.1-1

Versions of packages gdm3 suggests:
ii  gnome-orca3.28.1-3
pn  libpam-fprintd
ii  libpam-gnome-keyring  3.28.2-1

-- debconf information excluded

Bug#909439: autopkgtest/debci: misleading "Version" if a new version becomes available during testing

[Rebecca N. Palmer]

On 23/09/2018 18:04, Paul Gevers wrote:

I didn't came across it yet.


Probably because it's so rare, and easy not to notice if the status 
didn't change.



What kind of logic do you have in mind?


If any binary of the package under test is being installed and isn't the 
same version as the source, abort the run as a tmpfail.  (At least in a 
standard debci run, as some documented uses probably want to allow such 
mismatches: 
https://sources.debian.org/src/autopkgtest/5.5/doc/README.running-tests.rst/#L65 
)


I don't know if this is actually worth the effort; it also assumes 
debci's displayed Version is the source version.

Bug#909379: [Pkg-opencl-devel] Bug#909379: Bug#909379: Info received (Bug#909379: segfault when leaving the python3-dbg interpreter)

[Tomasz Rybak]

IFAIR PyOpenCL was never built against Python3.7.
dpkg -L python3-pyopecl and dpkg -L python3-pyopencl-dbg show
only files related to Python3.6.
I started working on update of package (and pushed changes
to git repository) but haven't yet uploaded new version.
compat 11 scripts mess a bit with -doc package and naming
of .so files for Python3.6 and 3.7.
Besides - upstream changed Python/C binding from cffi to pybind11;
I haven't looked into it yet.

Feel free to do NMU, but be careful with current git version (-3).
As my subkeys expired at the end of August and debian-keyring
hasn't been uploaded since end of July, I cannot upload
packages myself.

-- 
Tomasz Rybak, Debian Developer 
GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C


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

Bug#909207: pavucontrol: Pavucontrol don't see all the sound cards

[Felipe Sateler]

Hi Stefano

On Sat, Sep 22, 2018, 20:21 Stefano Simonucci 
wrote:

>
> stefano@debsim:~$ sudo lsof /dev/snd/*
> lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
>   Output information may be incomplete.
> COMMAND PID   USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
> timidity656   timidity  memCHR  116,2800
> /dev/snd/pcmC0D0p
> timidity656   timidity3r   CHR 116,33  0t0 12896 /dev/snd/timer
> timidity656   timidity4u   CHR  116,2  0t0   800
> /dev/snd/pcmC0D0p
> timidity656   timidity5u   CHR  116,7  0t0 14839
> /dev/snd/controlC0
> timidity656   timidity6u   CHR  116,1  0t0 12897 /dev/snd/seq
>

Ok, so you have timidity blocking the sound card, there is already a bug
report

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

As a workaround you can remove or disable timidity.

Saludos

>

Bug#909439: autopkgtest/debci: misleading "Version" if a new version becomes available during testing

[Paul Gevers]

Hi Rebecca,

Thanks for reporting this issue. I didn't came across it yet.

On 23-09-18 18:47, Rebecca N. Palmer wrote:
> When a new version of the package under test enters the archive during a
> test run, the tests towards the end of the run may use the binaries of
> the new version, but debci lists it as a test of the old version.

A race condition indeed. It's worse than you describe, not all tests are
run with the same binaries.

> Possibly related to #896023 / #902027, but those are about testing vs
> unstable, while this is changes within a suite.

No, not related. That issue I don't consider a bug anymore, but an
autopkgtest feature. In the Debian archive testing case, we just need to
try harder to detect which version we want to test against. The old
behavior is currently not possible in our setup because we run with the
new --disable-apt-fallback option.

> This is moderately unlikely, but not hugely so: for pymca (~15min of
> tests and a big enough dependency chain that it gets tested ~2x/day),
> ~2% chance per upload.
> 
> I'd guess the best solution is to make this a tmpfail, as testing an
> already-superseded version is probably a waste of resources.

What kind of logic do you have in mind?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#909440: meson: missing dependency on python3-pkg-resources

[Jeremy Bicha]

Source: meson
Version: 0.48.0-1
Severity: serious
X-Debbugs-CC: mp...@debian.org

I tried building a package (gnome-games-app) using meson but the build
fails now. I guess meson needs to depend on python3-pkg-resources .

Build log excerpt
--
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- --bindir=/usr/games
cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson ..
--wrap-mode=nodownload --buildtype=plain --prefix=/usr
--sysconfdir=/etc --localstatedir=/var --libdir=lib/x86_64-linux-gnu
--libexecdir=lib/x86_64-linux-gnu --bindir=/usr/games
Traceback (most recent call last):
  File "/usr/bin/meson", line 6, in 
from pkg_resources import load_entry_point
ModuleNotFoundError: No module named 'pkg_resources'

Thanks,
Jeremy Bicha

Bug#909439: autopkgtest/debci: misleading "Version" if a new version becomes available during testing

[Rebecca N. Palmer]

Package: autopkgtest
Version: 5.5

When a new version of the package under test enters the archive during a 
test run, the tests towards the end of the run may use the binaries of 
the new version, but debci lists it as a test of the old version.


If these tests fail because the new version contains a regression, this 
gives a "fail" entry for the _old_ version, and hence the false 
impression that the problem must be somewhere else.


Example: row 2018-09-20 11:04:29 of
https://ci.debian.net/packages/p/pymca/unstable/amd64/
(This is probably #909379 not a pymca regression, but this log isn't 
proof it isn't)


Possibly related to #896023 / #902027, but those are about testing vs 
unstable, while this is changes within a suite.


This is moderately unlikely, but not hugely so: for pymca (~15min of 
tests and a big enough dependency chain that it gets tested ~2x/day), 
~2% chance per upload.


I'd guess the best solution is to make this a tmpfail, as testing an 
already-superseded version is probably a waste of resources.

Bug#909438: timidity: new upstream release

[Reiner Herrmann]

Source: timidity
Version: 2.14.0-8
Severity: wishlist

Dear Maintainer,

version 2.15.0 of timidity is available, which mostly
contains a bunch of bugfixes.
It would be great if you could update the package.

Kind regards,
   Reiner


signature.asc
Description: PGP signature

Bug#909428: systray-mdstat: [regression] fails to correctly handle alpha channel in its own PNG images

[Francesco Poli]

On Sun, 23 Sep 2018 18:00:04 +0200 Axel Beckert wrote:

> Hi Francesco,
> 
> fullquote due to reassigning.
[...]

Thanks for your prompt reply!

Now let's hope the actual cause of the regression gets fixed soon.
Bye.


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


pgpRi9szAew4w.pgp
Description: PGP signature

Bug#909437: nfdump: Typo in manpage

[Christoph Biedl]

Source: nfdump
Version: 1.6.17-1
Severity: minor
Tags: upstream

Dear Maintainer,

while working on #644632, I stubled across ...

--- a/man/nfdump.1
+++ b/man/nfdump.1
@@ -1151,7 +1151,7 @@ To filter for netflow records with a specific number of 
aggregated flows.
 .I Type of Service (TOS)
 \fI[SourceDestination]\fR \fBtos \fR
 .br
-With \fI\fR 0..255. For compatibility with nfump 1.5.x:
+With \fI\fR 0..255. For compatibility with nfdump 1.5.x:
 \fBtos \fR is equivalent with \fBsrc tos \fR
 .TP 4
 .I Packets per second: Calculated value.

Please fix when convenient.

Cheers,

Christoph

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

Kernel: Linux 4.18.6 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect



signature.asc
Description: PGP signature

Bug#909436: libdrm: FTBFS on hurd-i386

[Svante Signell]

Source: libdrm
Version: 2.4.94-1
Severity: important
Tags: ftbfs, patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

Currently libdrm FTBFS on GNU/Hurd due to a missing case in
include/drm/drm.h. Attached is a patch, hurd-port.diff, to fix this and
fixes for PATH_MAX issues in in xf86dri.c and include+defines for GNU
in xf86dri.h.

Additionally the patches debian_rules.diff and debian_control.diff adds
Hurd to the architecture list.

Thanks!--- a/debian/control	2018-09-16 23:01:56.0 +0200
+++ b/debian/control	2018-09-16 23:03:11.0 +0200
@@ -13,7 +13,7 @@
  libudev-dev [linux-any],
  libpciaccess-dev,
  valgrind [amd64 armhf i386 mips mipsel powerpc s390x],
- libbsd-dev [kfreebsd-any],
+ libbsd-dev [kfreebsd-any hurd-any],
 Standards-Version: 4.1.4
 Section: libs
 Vcs-Git: https://salsa.debian.org/xorg-team/lib/libdrm
@@ -22,10 +22,10 @@
 
 Package: libdrm-dev
 Section: libdevel
-Architecture: linux-any kfreebsd-any
+Architecture: linux-any kfreebsd-any hurd-any
 Depends:
  libdrm2 (= ${binary:Version}),
- libdrm-intel1 (= ${binary:Version}) [amd64 i386 kfreebsd-amd64 kfreebsd-i386 x32],
+ libdrm-intel1 (= ${binary:Version}) [amd64 i386 kfreebsd-amd64 kfreebsd-i386 hurd-i386 x32],
  libdrm-radeon1 (= ${binary:Version}),
  libdrm-nouveau2 (= ${binary:Version}) [linux-any],
  libdrm-amdgpu1 (= ${binary:Version}),
@@ -46,7 +46,7 @@
  This package provides the development environment for libdrm.
 
 Package: libdrm2
-Architecture: linux-any kfreebsd-any
+Architecture: linux-any kfreebsd-any hurd-any
 Depends:
  libdrm-common (>= ${source:Version}),
  ${shlibs:Depends},
@@ -80,7 +80,7 @@
 Package: libdrm2-udeb
 Package-Type: udeb
 Section: debian-installer
-Architecture: linux-any kfreebsd-any
+Architecture: linux-any kfreebsd-any hurd-any
 Depends:
  ${shlibs:Depends},
  ${misc:Depends},
@@ -88,7 +88,7 @@
  This is a udeb, or a microdeb, for the debian-installer.
 
 Package: libdrm-intel1
-Architecture: amd64 i386 kfreebsd-amd64 kfreebsd-i386 x32
+Architecture: amd64 i386 kfreebsd-amd64 kfreebsd-i386 hurd-i386 x32
 Depends:
  ${shlibs:Depends},
  ${misc:Depends},
@@ -115,7 +115,7 @@
  OpenGL drivers.
 
 Package: libdrm-radeon1
-Architecture: linux-any kfreebsd-any
+Architecture: linux-any kfreebsd-any hurd-any
 Depends:
  ${shlibs:Depends},
  ${misc:Depends},
@@ -185,7 +185,7 @@
  OpenGL drivers.
 
 Package: libdrm-amdgpu1
-Architecture: linux-any kfreebsd-any
+Architecture: linux-any kfreebsd-any hurd-any
 Depends:
  ${shlibs:Depends},
  ${misc:Depends},
--- a/debian/rules	2018-08-31 15:01:29.0 +0200
+++ b/debian/rules	2018-09-01 00:16:08.0 +0200
@@ -33,7 +33,7 @@
 
 # Intel is only on x86:
 ifneq (,$(filter amd64 i386,$(DEB_HOST_ARCH_CPU)))
-ifneq (,$(filter linux kfreebsd,$(DEB_HOST_ARCH_OS)))
+ifneq (,$(filter linux kfreebsd hurd,$(DEB_HOST_ARCH_OS)))
 	INTEL = yes
 endif
 endif
Index: libdrm-2.4.94/include/drm/drm.h
===
--- libdrm-2.4.94.orig/include/drm/drm.h
+++ libdrm-2.4.94/include/drm/drm.h
@@ -57,6 +57,22 @@ typedef __uint64_t __u64;
 typedef size_t   __kernel_size_t;
 typedef unsigned long drm_handle_t;
 
+#elif defined(__GNU__)
+
+#include 
+#include 
+#include 
+typedef __int8_t   __s8;
+typedef __uint8_t  __u8;
+typedef __int16_t  __s16;
+typedef __uint16_t __u16;
+typedef __int32_t  __s32;
+typedef __uint32_t __u32;
+typedef __int64_t  __s64;
+typedef __uint64_t __u64;
+typedef size_t   __kernel_size_t;
+typedef unsigned int drm_handle_t;
+
 #else /* One of the BSDs */
 
 #include 
Index: libdrm-2.4.94/xf86drm.h
===
--- libdrm-2.4.94.orig/xf86drm.h
+++ libdrm-2.4.94/xf86drm.h
@@ -56,6 +56,16 @@ extern "C" {
 #define DRM_IOC_READWRITE	_IOC_READ|_IOC_WRITE
 #define DRM_IOC(dir, group, nr, size) _IOC(dir, group, nr, size)
 
+#elif defined(__GNU__)
+#include 
+#include 
+#define DRM_IOCTL_NR(n) ((n) & 0xff)
+#define DRM_IOC_VOIDIOC_VOID
+#define DRM_IOC_READIOC_OUT
+#define DRM_IOC_WRITE   IOC_IN
+#define DRM_IOC_READWRITE   IOC_INOUT
+#define DRM_IOC(dir, group, nr, size) _IOC(dir, group, nr, size)
+
 #else /* One of the *BSDs */
 
 #include 
Index: libdrm-2.4.94/xf86drm.c
===
--- libdrm-2.4.94.orig/xf86drm.c
+++ libdrm-2.4.94/xf86drm.c
@@ -2860,7 +2860,8 @@ static char *drmGetMinorNameForFD(int fd
 return NULL;
 #else
 struct stat sbuf;
-char buf[PATH_MAX + 1];
+char *buf = NULL;
+int len = 0;
 const char *dev_name;
 unsigned int maj, min;
 int n, base;
@@ -2892,11 +2893,18 @@ static char *drmGetMinorNameForFD(int fd
 if (base < 0)
 return NULL;
 
-n = snprintf(buf, sizeof(buf), dev_name, DRM_DIR_NAME, min - base);
-if (n == -1 || n >= sizeof(buf))
+len = snprintf(NULL, 0, dev_name, DRM_DIR_NAME, min - base);
+if (len < 0)
 return NULL;
+len++;
+

Bug#857807: Proposed fix https://salsa.debian.org/debian/dokuwiki/merge_requests/1

[Reinhard Tartler]

Control: tag -1 patch

Hi,

I think the issue is that the file got dropped from the package, yet the
default package is still referencing it. I took the liberty of taking the
image from the jessie package and propose a change at
https://salsa.debian.org/debian/dokuwiki/merge_requests/1.

Tanguy, do you have any concerns or comments about this patch?


-- 
regards,
Reinhard

Bug#909435: git-annex: Fails in obscure way with version in stable

[Tollef Fog Heen]

Package: git-annex
Version: 6.20180913-1
Severity: important

I have an ssh remote where the other end is running Debian stable (so
6.20170101-1+deb9u2).  If I do a `git annex copy . --to foo`, it fails
with the rather obscure error:

copy directory/some.file (fd:18: hClose: resource vanished (Broken pipe)) failed

The problem goes away by upgrading the remote end to the version in
backports.

Can git-annex either be fixed so it works across those versions, or at
least give a clear error message that the two ends are speaking
incompatible protocol versions?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#909434: git-annex: inappropriate recommends: youtube-dl

[Tollef Fog Heen]

Package: git-annex
Version: 6.20180913-1
Severity: normal

youtube-dl pulls in a bunch of extra dependencies, and I doubt it
fulfills the

> The Recommends field should list packages that would be found together
> with this one in all but unusual installations.

definition from policy.  Can it be demoted to Suggests, please?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#909433: O: tk-brief -- GUI for easily writing letters with LaTeX

[Tobias Frost]

Package: wnpp

The current maintainer of tk-brief, Yven Johannes Leist ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: tk-brief
Binary: tk-brief
Version: 5.10-0.1
Maintainer: Yven Johannes Leist 
Build-Depends: debhelper (>= 7)
Architecture: all
Standards-Version: 3.5.2
Format: 3.0 (quilt)
Files:
 37268b01522a815364627ac2dadb8aa0 1651 tk-brief_5.10-0.1.dsc
 452db4d7b4bdaffd13d0af634e835509 99516 tk-brief_5.10.orig.tar.gz
 f68f3d1c77f6c69fa45fbdd1da1f70c3 2708 tk-brief_5.10-0.1.debian.tar.xz
Checksums-Sha256:
 4f8dc032c89a174fc8ce6dcef13682dced5879c49f967873e58f492225064ad8 1651 
tk-brief_5.10-0.1.dsc
 6b93d6fa31ac98c44086ca19be1eb4d9cbea51728d1d02b090fd1f5a757d0379 99516 
tk-brief_5.10.orig.tar.gz
 4ccbd69cd3f2b06141323e7f656f8f40c1c14d32035b4b89b19f4f15dabd367e 2708 
tk-brief_5.10-0.1.debian.tar.xz
Package-List: 
 tk-brief deb tex optional arch=all
Directory: pool/main/t/tk-brief
Priority: source
Section: tex

Package: tk-brief
Version: 5.10-0.1
Installed-Size: 154
Maintainer: Yven Johannes Leist 
Architecture: all
Depends: tk8.3 | wish, texlive, texlive-latex-extra, texlive-latex-recommended, 
xterm | x-terminal-emulator
Recommends: lpr, ispell
Description-en: GUI for easily writing letters with LaTeX
 tk_Brief is a TK GUI for easily writing letters and even multiple letters
 with LaTeX
 .
 The following LaTeX letter classes are supported:
  - g-brief
  - dinbrief
  - letter
  - KOMA
  - brief
Description-md5: 4a66d5da0a4c6ca44dc7edc34f3c75f0
Tag: interface::graphical, interface::x11, role::program
Section: tex
Priority: optional
Filename: pool/main/t/tk-brief/tk-brief_5.10-0.1_all.deb
Size: 90440
MD5sum: 86f0e003e202646a50b96e982cb3b6b3
SHA256: 6d272742d62c0762979f765fbbb4133901a8f046e0cc2901ec282eaaf479676b

Bug#909432: ITP: python-djangosaml2 -- Django application that integrates PySAML2

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-djangosaml2
  Version : 0.17.2
  Upstream Author : Yaco Sistemas 
* URL : https://github.com/knaperek/djangosaml2/
* License : Apache-2.0
  Programming Lang: Python
  Description : Django application that integrates PySAML2

 djangosaml2 is a Django application that integrates the PySAML2 library into
 your project. This mean that you can protect your Django based project with a
 service provider based on PySAML. This way it will talk SAML2 with your
 Identity Provider allowing you to use this authentication mechanism.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlunu5MRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wqcygf+J7OWQSVepkV3TyHhGXqgWXAm/SwB0kt6
OZhN8CMi5zSj3V/hiFATIlkL6BrUFkUUaYAlQImN4H/oq7kOK9JJPhprb2OZedtA
7OaUlhN3kHJxqYa6kEzx9K08DkzjKnsfMxYpUWPXdBjaduzQJreHtFbkkjXhpq5R
Yo1gUGJDiOZ6YIfsqUbVMUWof8F+zn8Fr0iJ8Jpc7JU8bLQT/Nbr6V3S0A55v4/7
Ltr+mDdWyK8Bui3eK7HAC2zDmhxTt33z3yRb17P+moNAiM+La9xo/3k3k897Zs79
k0BEZ5F4W2r9fSDmB0E/xNcuKRDbt+mZdTDrVPy9UvH0aTQlJj5F0Q==
=VlT0
-END PGP SIGNATURE-

Bug#909249: 909249: Patch without fuzz

[Svante Signell]

Hi,

Attached is a refreshed patch for kfreebsd without fuzz. Please apply
this one instead of the previous one in this bug report.

Thanks!Index: libdrm-2.4.94/include/drm/drm.h
===
--- libdrm-2.4.94.orig/include/drm/drm.h
+++ libdrm-2.4.94/include/drm/drm.h
@@ -42,6 +42,21 @@
 #include 
 typedef unsigned int drm_handle_t;
 
+#elif   defined(__FreeBSD_kernel__)
+
+#include 
+#include 
+typedef __int8_t   __s8;
+typedef __uint8_t  __u8;
+typedef __int16_t  __s16;
+typedef __uint16_t __u16;
+typedef __int32_t  __s32;
+typedef __uint32_t __u32;
+typedef __int64_t  __s64;
+typedef __uint64_t __u64;
+typedef size_t   __kernel_size_t;
+typedef unsigned long drm_handle_t;
+
 #else /* One of the BSDs */
 
 #include 

Bug#909379: segfault when leaving the python3-dbg interpreter

[PICCA Frederic-Emmanuel]

Hello Andreas,

what about this build dependency ?

python3-all-dbg

Cheers

Bug#909428: systray-mdstat: [regression] fails to correctly handle alpha channel in its own PNG images

[Axel Beckert]

Control: reassign -1 gir1.2-gtk-3.0 3.24.0-3
Control: affects -1 gir1.2-appindicator3-0.1 libgtk3-perl systray-mdstat solaar 
redshift-gtk

Hi Francesco,

fullquote due to reassigning.

Francesco Poli (wintermute) wrote:
> Since some recent upgrade of my Debian testing boxes (I think it
> happened when I upgraded libgtk3-perl 0.034-1 -> 0.034-2), I have been
> experiencing a new bug in systray-mdstat: it seems to be unable to
> correctly repaint the transparent parts of its own PNG images (such as
> /usr/share/perl5/auto/share/dist/systray-mdstat/harddriveok.png) within
> the systray.
> 
> The practical effect is that, whatever has appeared (or has been moved)
> over the systray leaves a permanent trace in the transparent pixels of
> the displayed PNG image.  See the attached screenshot, for a visual
> example (you can see the image shown by systray-mdstat in the systray,
> along with a small part of the surrounding systray area...).
> 
> What used to happen before the above-mentioned upgrade, was that the
> transparent part used to be painted with the panel color (the fbpanel
> gray color, in my specific case).
> 
> I don't know whether this regression is due to some code in
> systray-mdstat that needs to be updated, or is caused by a regression
> in libgtk3-perl.

This is at least something which happens to other tools in the
systemtray, too, namely solaar and redshift-gtk for me.

Since the other two are written in python and systray-mdstat is
written in Perl, I assume that the issue is not even in libgtk3-perl
but in GTK3 itself or even deeper down.

The closest common dependency between systray-mdstat, solaar and
redshift-gtk seems to be gir1.2-gtk-3.0 (partially via
gir1.2-appindicator3-0.1), so reassigning there. Showed up for me
after upgrading from version 3.24.0-1 to 3.24.0-3.

gir1.2-gtk-3.0: Feel free to reassign further if the cause is deeper
down, e.g. in gdk-pixbuf or so.

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#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

[Peter Lebbing]

On 23/09/2018 17:02, Guilhem Moulin wrote:
> I was thinking about something like that, and that's why I was referring
> to by “the complexity is not worth it IMHO”.  `--list-secret-keys`
> implicitly launches gpg-agent(1) for that homedir, which will need to be
> shut down afterwards (unless it was started manually before).

Oh, I hadn't realized. That's a blocking issue.

> I'm reluctant to do that since there are plenty of options that would
> break the setup: ‘no-autostart’, ‘keyring’, ‘pinentry-program
> /path/to/custom/wrapper’, ‘pinentry-program /usr/bin/pinentry-gtk’,
> etc., and (beside ‘trusted-key’ maybe) I don't see a valid usecase for
> custom config files yet.

I meant *.conf files specific to the initramfs, so no breaking options
would be picked up from the normal homedir. scdaemon options like
disable-ccid, enable-pinpad-varlen, disable-pinpad and maybe reader-port
might be useful in some setups where card readers are not completely
compliant with GnuPG's expectations. I couldn't find any useful
(documented :-) options for gpg or gpg-agent either.

> The `--export` command produces RFC 4880 compatible output, which is
> also the format for gpgv(1) keyrings and is bound to be supported
> forever by gpg(1) (possibly via intermediate upgrade to .kbx like for
> the private key material).

Is this documented that it is bound to be supported by gpg? Because I
always hear and repeat myself that the format of a keyring is an
implementation detail, and anybody building keyrings this way should be
prepared for problems, which they do have. [1] is fresh in my memory,
but it might actually have been caused by a different problem. It's not
the first time it's cropped up though.

> Why would that block migration to GnuPG 2.1?

It's not related to migration here. I meant that you aren't supposed to
be constructing keyrings with --export, this has to my knowledge never
been an intended feature. You use --no-default-keyring --keyring X
--import to build keyrings only (well, appending is possible with
--primary-keyring as well). I don't see a reason to be using the
--export approach here anyway?

> gpgconf(1) honors GNUPGHOME (and has an undocumented --homedir flag
> since 2.1.7 AFAIK):

Ah yes, I forgot that it wasn't documented, so when I went to the
documentation to check, well... :-)

I'm going to raise the issue of how private the directory/filename
structure in private-keys-v1.d is on GnuPG-Users. Because if they are
deemed an acceptable API, we could just copy a configurable .key stub,
or even find it ourself from an OpenPGP key identifier and
--with-keygrip --with-colons --list-secret-keys etcetera.

It would be easier if we could just --import a stub.

On 23/09/2018 17:17, Guilhem Moulin wrote:
> If we want this to be widely used we should make initramfs image
> generation as quiet as possible.

I meant document it in README.gnupg-sc, not on every initramfs image
generation. Just say that anything in /etc/cryptsetup-initramfs is going
to end up unencrypted in the initramfs, but that since the key for
unlocking the filesystem is already stored encrypted in that directory,
this does not compromise the unlock key. This obviously implies anything
else would be compromised. IMHO, sometimes good documentation can take
the place of full automation/checking.

Cheers,

Peter.

[1] https://lists.gnupg.org/pipermail/gnupg-users/2018-September/060936.html

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 




signature.asc
Description: OpenPGP digital signature

Bug#905634: tasksel: Please remove dependency on manpages-fr in task-french (#871564)

[Holger Wansing]

Hi,

Niels Thykier  wrote:
> Source: tasksel
> Version: 3.44
> Severity: important
> 
> Hi,
> 
> The manpages-fr package is outdated and unmaintained
> (defacto-orphaned too).
> 
> Please remove the dependency on manpages-fr in task-french so we can
> remove the package from testing or the archive.

What about manpages-fr-extra?
It's the same maintainer and had no upload since 2015. Seems that above
arguments count for this package as well?

And this has already been reported in #871563.

Should we remove dependency for this one as well?


Holger


-- 

Created with Sylpheed 3.5.1 under 
D E B I A N   L I N U X   9   " S T R E T C H " .

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

Bug#909431: xscreensaver: diff for NMU version 5.40-1.1

[Antoine Beaupre]

Package: xscreensaver
Version: 5.36-1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for xscreensaver (versioned as 5.40-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

The patch was too large to attach here, please instead see the git
repository at:

https://salsa.debian.org/debian/xscreensaver

Regards.


signature.asc
Description: PGP signature

Bug#908061: RFS: rapid-photo-downloader/0.9.11-1

[Antoine Beaupré]

On 2018-09-16 18:47:10, Antoine Beaupré wrote:
> On 2018-09-10 12:13:00, Antoine Beaupré wrote:
>> On 2018-09-08 14:37:00, Jörg Frings-Fürst wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA512
>>>
>>> Hello Antoine,
>>>
>>> many thanks for your review.
>>
>> Hi!
>>
>> A pleasure working with you!
>>
>>> Am Mittwoch, den 05.09.2018, 13:01 -0400 schrieb Antoine Beaupré:
 Control: owner -1 anar...@debian.org
 
 On 2018-09-05 18:39:07, Jörg Frings-Fürst wrote:
 > -BEGIN PGP SIGNED MESSAGE-
 > Hash: SHA512
 > 
 > Package: sponsorship-requests
 > Severity: normal
 > 
 > Dear mentors,
 > 
 >   I am looking for a sponsor for my package "rapid-photo-
 > downloader"
 
 Hi!
 
 As the uploader for the package, I'll be happy to sponsor this.
 
 I've reviewed your changes and they seem mostly good. However, they
 seem
 to omit some changes I've uploaded to the git repository 4 weeks ago:
 
 https://salsa.debian.org/debian/rapid-photo-downloader
 
 ... namely:
 
 
>>> https://salsa.debian.org/debian/rapid-photo-downloader/commit/ff0358a5e0783fb2464391cd06d02021a881ccae
 
>>> https://salsa.debian.org/debian/rapid-photo-downloader/commit/c0027837223b83325d653a59146e16d2206fcccf
 
 Those are necessary (I think?) to completely fix #900709.
 
 With those changes, I'll be happy to do the upload.
 
>>>
>>> Sorry. I have first sync only the release 0.9.9-2. Your commits are now
>>> included. The package is uploaded to mentors[1].
>>
>> Understood. I had a conflict when merging the code from salsa with yours
>> because you keep the removed patch commented out (I just removed the
>> line) in debian/patches/series. I've also removed the unused patches
>> from debian/patches so we have only this one patch remaining.
>>
>> Another thing that's missing from the above .dsc file is the
>> "python3-colour" Depends. Any idea why that's also missing?
>>
>> I've pushed my resulting merge to salsa for now.
>>
 I would also encourage you to register on salsa.debian.org and upload
 your changes there, as it will make future collaboration easier: it
 would have avoided such confusion, for example.
 
>>>
>>> I do not use salsa because of the existing user restrictions.
>>
>> What do you mean by that?
>
> Hi!
>
> Any update here?

Ping! Could you provide an updated package with the new Depends?
Otherwise I'm happy to make the corrections myself.

Thanks!

A.

-- 
Vivre tous simplement pour que tous puissent simplement vivre.
- Gandhi

Bug#807866: uploading github-hub? (was: Bug#807866: RFP: github-hub -- hub helps you win at git)

[Antoine Beaupré]

Ping!

I've been running this package for about a month now and it works well.

If no one else steps up, I will upload this within the next four weeks.

Thanks!

A.

On 2018-08-26 23:11:26, Antoine Beaupré wrote:
> Control: tag -1 +pending +patch
>
> Hi Anthony!
>
> I noticed on Salsa that you have worked on the Debian package for the
> hub program:
>
> https://salsa.debian.org/go-team/packages/hub
>
> Are there any plans to upload that package into the archive? It would be
> very useful... It seems to work here although it currently FTBFS because
> of an incorrect dependency. The attached patch fixes that.
>
> Thanks for any update,
>
> A.
>
> From 3d72160700b43218557ad15f12633a2eb9568119 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
> Date: Sun, 26 Aug 2018 23:06:42 -0400
> Subject: [PATCH] fix build dependency
>
> The ruby-ronn package does not ship the ronn program anymore
> ---
>  debian/control | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/debian/control b/debian/control
> index 7d80a46..0103fac 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -20,7 +20,7 @@ Build-Depends: debhelper (>= 11),
> golang-github-ogier-pflag-dev,
> golang-golang-x-crypto-dev,
> golang-gopkg-yaml.v2-dev,
> -   ruby-ronn
> +   ronn
>  Standards-Version: 4.1.4
>  Vcs-Browser: https://salsa.debian.org/go-team/packages/hub
>  Vcs-Git: https://salsa.debian.org/go-team/packages/hub.git
> -- 
> 2.18.0
>

-- 
A patriot must always be ready to defend his country
against his government.
- Edward Abbey

Bug#907835: [Pkg-xen-devel] Bug#907835: newer version in stable

[Antoine Beaupré]

On 2018-09-05 12:36:54, Ian Jackson wrote:
> The 4.8-based security updates have not been going to sid/buster for
> rather obscure reasons.  We have packages for 4.11 in preparation, so
> hopefully this will become irrelevant soon.

It's been two weeks and stable still has a newer version than unstable,
which suffers from four security issues fixed in stable.

I understand you might have other plans in the long term, but in the
meantime, why not just upload deb9u10 to unstable?

a.

-- 
Instead of worrying about what somebody else is going to do, which is
not under your control, the important thing is, what are you going to
decide about what is under your control?
 - Richard Stallman

Bug#909328: More information and new backtrace

[Léon van Velzen]

Hello,

> How do you exactly set the size from vim? Do you put these lines in vimrc,
> or you type these commands interactively, etc., how exactly? I'm asking
> because let's say whether the two dimensions are modified in a single step
> or in two consecutive steps might make a difference.

I typ them in interactively. Although if I put the command in my .vimrc the 
same crash occurs.

> What's your display server (X vs. Wayland), what graphical desktop and
> window manager do you use? I'm asking because potentially all of them
> behaves somewhat differently.

I have a process called XWayland running so I suppose it's Wayland.

> Does vim's startup always crash gnome-terminal for you? If not then
> approximately how often?

It's not Vim's startup that causes the crash. It's only when issuing the 
command ':set lines=999'.
It does crash consistently, although I noticed if the terminal is already full 
screen the command
is ignored so the terminals do not crash. Maybe that's the reason you can not 
reproduce it?

> A backtrace would indeed be great, I'd add to Bernhard's response that
> libvte-2.91-0 should also be compiled with debug symbols, since the crash
> is most likely inside vte.

> nowadays there are -dbg packages not very common.
> Instead there is a different repository to deliver automatic -dbgsym packages.
> e.g. "deb
> http://debug.mirrors.debian.org/debian-debug/
> testing-debug main"
> as described in the link in the previous mail.
> From there a package like "vim-dbgsym_8.1.0320-1_amd64.deb should be 
> installable.

I have done my best to collect the dbg packages. I included the new backtrace 
(it is called backtrace2.txt). It seems the symbols
for the first few functions are not available but I do not know which debug 
packages are missing.

> So from your backtrace.txt it looks more like vim is crashing as 
> gnome-terminal.
> How have you started vim? Something like from a file explorer and open in vim?
> Or have you stared directly inside the terminal?
> I do not see currently any connection between all gnome-terminals closing and 
> one
> vim instance changing its size. Probably you can give some more details how
> this can be reporoduced?

Directly inside the terminal. Here you can see a screencast of me causing a 
crash: 
https://www.dropbox.com/s/h3bnsi4lbgymlk5/Screencast%20from%2009-23-2018%2004%3A35%3A13%20PM.webm?dl=0

> So what looks like the path like, at least how long is it?

As you can see in the linked screencast I do not specify a filename. Although 
when I do, for example
using 'vim test.txt' the problem persists.

I have also tried to attach gdb debugger using another terminal program to the 
Vim executable. This
results in the backtrace 'backtrace-vim.txt' which is also attached. I have 
found that my vim executable
is a symbolic link to the vim.basic executable. This would mean the two 
backtraces contradict each other.
The first, produced with 'coredumpctl gdb' talks about a segmentation fault. 
The backtrace produced
by attaching gdb directly (backtrace-vim.txt) mentions a 'SIGHUP' signal, which 
makes sense since
gnome-terminal does seem to crash.

Also, I am not affected anymore by this problem, but of course other people 
might run into this so it's still
worthwhile trying to find the root cause.

Thanks again,
Léon van Velzen   PID: 11571 (vim)
   UID: 1000 (leonvv)
   GID: 1000 (leonvv)
Signal: 11 (SEGV)
 Timestamp: Sun 2018-09-23 16:26:16 CEST (4min 22s ago)
  Command Line: vim
Executable: /usr/bin/vim.basic
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service
  Unit: user@1000.service
 User Unit: gnome-terminal-server.service
 Slice: user-1000.slice
 Owner UID: 1000 (leonvv)
   Boot ID: 2f91eff7da0e4bc7b014ba9f2c5fe4b1
Machine ID: 95762e21d5dc42ee92e8868d27171676
  Hostname: leonvv
   Storage: 
/var/lib/systemd/coredump/core.vim.1000.2f91eff7da0e4bc7b014ba9f2c5fe4b1.11571.153771277600.lz4
   Message: Process 11571 (vim) of user 1000 dumped core.

Stack trace of thread 11571:
#0  0x7ffa1d340227 kill (libc.so.6)
#1  0x55a5f9aa06fd may_core_dump (vim.basic)
#2  0x55a5f9b62eec getout (vim.basic)
#3  0x7ffa1d33ffc0 __restore_rt (libc.so.6)
#4  0x7ffa1d41090d ___vsprintf_chk (libc.so.6)
#5  0x7ffa1d41087a ___sprintf_chk (libc.so.6)
#6  0x7ffa1db204a6 sprintf (libtinfo.so.6)
#7  0x7ffa1db19889 _nc_setup_tinfo (libtinfo.so.6)
#8  0x7ffa1db19bef _nc_setupterm (libtinfo.so.6)
#9  0x7ffa1db1a0f3 tgetent_sp (libtinfo.so.6)
#10 0x55a5f9b1e1be tgetent_error (vim.basic)
#11 0x55a5f9b1e40b getlinecol (vim.basic)
#12 0x00300010 n/a (n/a)



#0  

Bug#909430: Regression: Cipher mismatch on reconnect after "TLS: soft reset"

[edv]

Package: openvpn
Version: 2.4.0-6+deb9u2
Severity: important

A standing connection, open continually since several weeks, suddenly
breaks down with error message "AEAD Decrypt error: cipher final
failed". Connection reopens only after complete reboot of server.

As it seems this regression has been solved in upstream some sixteen
months ago (https://community.openvpn.net/openvpn/ticket/887).

Relevant log messages (endlessly repeated):
AEAD Decrypt error: cipher final failed
AEAD Decrypt error: cipher final failed
AEAD Decrypt error: cipher final failed
PUSH: Received control message: 'PUSH_REQUEST'
PUSH: client wants to negotiate cipher (NCP), but server has already
generated data channel keys, ignoring client request
SENT CONTROL [Client-FQDN]: 'PUSH_REPLY,route [...]
AEAD Decrypt error: cipher final failed
AEAD Decrypt error: cipher final failed
AEAD Decrypt error: cipher final failed
.
.
.


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

Kernel: Linux 4.9.0-7-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15),
LANGUAGE=de$ Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.48
ii  iproute2   4.9.0-1+deb9u1
ii  libc6  2.24-11+deb9u3
ii  liblz4-1   0.0~r131-2+b1
ii  liblzo2-2  2.08-1.2+b2
ii  libpam0g   1.1.8-3.6
ii  libpkcs11-helper1  1.21-1
ii  libssl1.0.21.0.2l-2+deb9u3
ii  libsystemd0232-25+deb9u4
ii  lsb-base   9.20161125

Versions of packages openvpn recommends:
ii  easy-rsa  2.2.2-2

Versions of packages openvpn suggests:
ii  openssl 1.1.0f-3+deb9u2
pn  resolvconf  
-- debconf information:
  openvpn/create_tun: false


-- Bug report

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Guilhem Moulin]

Hi,

On Mon, 06 Aug 2018 at 13:09:13 +0200, Jonas Meurer wrote:
> Am 23.07.2018 um 14:42 schrieb Chris Lamb:
> Still, if we would split the gnupg smartcard keyscript into an own
> binary package, we would have to do the same for decrypt_gnupg,
> decrypt_opensc and decrypt_ssl. Which would mean four new binary
> packages.

More, if were to further split the initramfs integration.  For instance
in the case of OpenPGP smartcards, pinentry-gtk (the default pinentry
flavor) will suffice for the normal system, but pinentry-curses |
pinentry-tty is required for unlocking to work at early boot stage.

Tight dependencies are great, but is it really worth it for a package
with just a dozen of lines of shell code and 10× as much meta-data?

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

[Guilhem Moulin]

On Sun, 23 Sep 2018 at 16:00:30 +0200, Peter Lebbing wrote:
> I'm not really happy with the "wait for a random smartcard to be
> available and import that as stubs" solution,

Note that in principle we can wait for a smartcard with a given serial
number to be inserted, with `gpg-connect-agent 'SCD SERIALNO openpgp'
/bye` or similar.

> but copying the whole homedir might need some more tuning as
> well... Or we just accept that people who put data in a directory named
> cryptsetup-initramfs should expect that this data ends up in their
> initramfs, and limit our safety checks.  We can still document it,
> obviously, with a clearly phrased warning that although the key itself
> is encrypted, nothing else is.

If we want this to be widely used we should make initramfs image
generation as quiet as possible.  Users (understandably) become worried
— and file bugs — when kernel upgrades or similar produce warnings,
especially when early boot stage is involved ;-)
 
> Anyway, Guilhem, thanks for working on this!

Well, thank you for the original code! :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

[Guilhem Moulin]

Hi,

On Sun, 23 Sep 2018 at 13:32:44 +0200, Peter Lebbing wrote:
> --8<---cut here---start->8---
> #!/bin/sh
> 
> UNSAFEKEYS=$(gpg --batch --with-colons --homedir /etc/keys --list-secret-keys 
> | \
>   gawk -F: '$1=="sec" || $1=="ssb" \
>   { if ($15 !~ /D27600012401.*/ && $15 != "#") { print $5 } }')
> 
> if [ -n "$UNSAFEKEYS" ]; then
>   echo "Non-smartcard keys found:\n${UNSAFEKEYS}\nAborting" >&2
>   exit 1
> fi
> --8<---cut here---end--->8---

I was thinking about something like that, and that's why I was referring
to by “the complexity is not worth it IMHO”.  `--list-secret-keys`
implicitly launches gpg-agent(1) for that homedir, which will need to be
shut down afterwards (unless it was started manually before).  Also,
while the bits that matter (the pubring and the stubs) will seldom
change hence /etc is probably the right place to store these, /etc might
be read-only when the initramfs image is generated.  Since gpg(1) needs
a writeable homedir, we'd need to copy stuff around.
 
> Whatever the solution, I think it's a good idea to copy *.conf to the
> GnuPG homedir as well

I'm reluctant to do that since there are plenty of options that would
break the setup: ‘no-autostart’, ‘keyring’, ‘pinentry-program
/path/to/custom/wrapper’, ‘pinentry-program /usr/bin/pinentry-gtk’,
etc., and (beside ‘trusted-key’ maybe) I don't see a valid usecase for
custom config files yet.

> I'm a bit worried that currently, the implementation detail that the old
> pubring.gpg format is the same format as gpg --export is being used.
> This is tripping up people upgrading to GnuPG 2.1, and I think it's a
> better idea to avoid it here as well.

The `--export` command produces RFC 4880 compatible output, which is
also the format for gpgv(1) keyrings and is bound to be supported
forever by gpg(1) (possibly via intermediate upgrade to .kbx like for
the private key material).  Why would that block migration to GnuPG 2.1?

>> By the way, I also added a local-bottom script to kill gpg-agent and
>> scdaemon before execution is turned over to the init binary :-)
> 
> A good idea. If we copy a whole homedir, it might be needed to put the
> homedir in its regular place for that. I suppose this is possible? I
> think gpgconf can only manage daemons started with a default homedir.

gpgconf(1) honors GNUPGHOME (and has an undocumented --homedir flag
since 2.1.7 AFAIK):

$ GNUPGHOME=/tmp/abc gpgconf --list-dirs homedir
/tmp/abc
$ gpgconf --homedir /tmp/abc --list-dirs homedir
/tmp/abc

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#909429: ITP: osmo-sgsn -- Serving GPRS Support Node for Mobile Networks

[Ruben Undheim]

Package: wnpp
Severity: wishlist
Owner: Ruben Undheim 

* Package name: osmo-sgsn
  Version : 1.3.0
  Upstream Author : Osmocom
* URL : https://osmocom.org/projects/osmosgsn/wiki/OsmoSGSN
* License : AGPL-3
  Programming Lang: C
  Description : Serving GPRS Support Node for Mobile Networks


OsmoSGSN is the Serving GPRS Support Node: it handles signalling, i.e.
attach/detach of subscribers and PDP contexts for data services.

OsmoSGSN needs to reach the GGSN to establish GTP tunnels for subscribers. It
must have a separate GTP IP address from OsmoGGSN, as mentioned before.

It is needed for data support in the Osmocom mobile network infrastructure, 
and will be maintained in the Debian Mobcom team.

Bug#203031: missing death from 2009

[Osamu Aoki]

Hi,

Can anyone propose text to describe Steve Greenland if it needs to be
included?  

I don't know him well and I don't know enough to decide who to be
included.

I think one criteria is if we mentioned in public as Debian News or nt.

Osamu

Bug#909244: kobodeluxe not playable - immediately pauses and can't be resumed

[Reiner Herrmann]

The problem seems to be that on game start and every keypress
an SDL_ACTIVEEVENT with state SDL_APPINPUTFOCUS is emitted (kobo.cpp:1692).
So even when you try to unpause, this event is fired again and it pauses
again.
After changing the check to
  if(!ev.active.gain && ev.active.state != SDL_APPINPUTFOCUS)
I got it working without any noticable issues.
But I'm not sure what's causing those repeated SDL_APPINPUTFOCUS events.


signature.asc
Description: PGP signature

Bug#909428: systray-mdstat: [regression] fails to correctly handle alpha channel in its own PNG images

[Francesco Poli (wintermute)]

Package: systray-mdstat
Version: 1.1.0-1
Severity: normal

Hello!

Since some recent upgrade of my Debian testing boxes (I think it
happened when I upgraded libgtk3-perl 0.034-1 -> 0.034-2), I have been
experiencing a new bug in systray-mdstat: it seems to be unable to
correctly repaint the transparent parts of its own PNG images (such as
/usr/share/perl5/auto/share/dist/systray-mdstat/harddriveok.png) within
the systray.

The practical effect is that, whatever has appeared (or has been moved)
over the systray leaves a permanent trace in the transparent pixels of
the displayed PNG image.  See the attached screenshot, for a visual
example (you can see the image shown by systray-mdstat in the systray,
along with a small part of the surrounding systray area...).

What used to happen before the above-mentioned upgrade, was that the
transparent part used to be painted with the panel color (the fbpanel
gray color, in my specific case).

I don't know whether this regression is due to some code in
systray-mdstat that needs to be updated, or is caused by a regression
in libgtk3-perl.
Please investigate the bug and fix it and/or reassign the bug report,
as appropriate.

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.18.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 systray-mdstat depends on:
ii  libfile-sharedir-perl  1.116-2
ii  libgtk3-perl   0.034-2
ii  libtry-tiny-perl   0.30-1
ii  perl   5.26.2-7

systray-mdstat recommends no packages.

Versions of packages systray-mdstat suggests:
ii  fbpanel 7.0-4
pn  smart-notifier  

-- no debconf information

Bug#909426: RM: psphere -- ROM; dead upstream, replacement in repo

[Hideki Yamane]

package: ftp.debian.org

Hi,

 psphere upstream says it's no longer maintained and there's appropriate
 replacement, VMWare's "VMware pyvmomi" library and it's in Debian repo.
 
https://github.com/jkinred/psphere/commit/d0565266fa984591df46a361e20cc603dd19ec0a

 And there's no reverse dependencies for psphere package.

 So, I'll ask you to remove pshpere package from Debian.


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp
 http://wiki.debian.org/HidekiYamane

Bug#909427: please add @types/glob for node-xterm 3.x

[Pirate Praveen]

Package: node-typescript-types
severity: wishlist
version: 20170519-1
Control: block 909424 by -1

Please add type definitions for @types/glob. Also update other types
definitions compatible with,

"@types/chai": "^3.4.34",
"@types/glob": "^5.0.35",
"@types/jsdom": "11.0.1",
"@types/mocha": "^2.2.33",
"@types/node": "6.0.108",



signature.asc
Description: OpenPGP digital signature

Bug#766385: Generating /boot/initrd.img-* twice in the same full-upgrade

[積丹尼 Dan Jacobson]

Doesn't happen every time, only sometimes.

# egrep init.*Genera\|Log\ started /var/log/apt/term.log
Log started: 2018-09-23  09:51:40
update-initramfs: Generating /boot/initrd.img-4.18.0-1-686-pae
update-initramfs: Generating /boot/initrd.img-4.18.0-1-686-pae



term.log.gz
Description: application/gzip

Bug#909407: pybind11 breaks dolfin autopkgtest

[Paul Gevers]

Hi

On 23-09-18 16:11, Paul Gevers wrote:
> but this very much suggests that dolfin should at
> least go a versioned depends on pybind11.

To be completely clear, I should have mentioned that this may imply
versioned TEST dependencies only. I can't judge if the package works
with the current dependencies, only that the tests are broken.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#909407: pybind11 breaks dolfin autopkgtest

[Paul Gevers]

Hi all,

On Sun, 23 Sep 2018 08:55:49 +0200 Paul Gevers  wrote:
> Looking at the changelog of dolfin 2018.1.0.post1-11, I fear that a
> versioned depends or a versioned breaks is missing somewhere. Note that
> the Debian migration software considers those to determine if packages
> need to be tested together from unstable. If dolfin can't determine the
> upper version of pybind11 beforehand, a versioned breaks in pybind11
> helps the migration software to use the proper version of dolfin during
> dolfin's autopkgtesting. If dolfin 2018.1.0.post1-11 can migrate without
> the pybind11 2.2.4-1, you could decide to ignore this bug as once dolfin
> migrates, the test that is retried daily will be run with that version.

The autopkgtest of dolfin 2018.1.0.post1-11 passes in unstable, but
fails to run in testing. I'll trigger a run with both pybind11 and
dolfin from unstable, but this very much suggests that dolfin should at
least go a versioned depends on pybind11.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#909133: ITP: auto-dictionary-el -- automatic dictionary switcher for Emacs spell checking

[Antoine Beaupré]

On 2018-09-22 18:37:29, Nicholas D Steeves wrote:
> If you prefer a formal RFS say the word, though I'd prefer to be lazy about
> this :-p

No problem of course. :) After a short review, build, install and smoke
test, I've uploaded the package and it should end up in NEW shortly.

A.

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of speech
because I have nothing to say."
- Edward Snowden

Bug#909424: update node-xterm to 3.x

[Pirate Praveen]

Package: node-xterm
version: 2.7.0+ds1-1
severity: wishlist

I'd like to get node-xterm >= 3.5 for gitlab. I have started working on
the update, but it requires updating node-typescript-types with more
type definitions or simple embed it inside the package directly.



signature.asc
Description: OpenPGP digital signature

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

[Peter Lebbing]

On 23/09/2018 13:32, Peter Lebbing wrote:
> How about copying the whole homedir without
> random_seed, but first checking to make sure there are only smartcard
> keys as private keys?

O dear, this might not be enough. The agent can also hold non-OpenPGP
keys. SSH keys are an example of what I'm actually using myself.

This might need some more thought... I'm not really happy with the "wait
for a random smartcard to be available and import that as stubs"
solution, but copying the whole homedir might need some more tuning as
well... Or we just accept that people who put data in a directory named
cryptsetup-initramfs should expect that this data ends up in their
initramfs, and limit our safety checks. We can still document it,
obviously, with a clearly phrased warning that although the key itself
is encrypted, nothing else is.

Anyway, Guilhem, thanks for working on this!

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature

Bug#909423: cups-browsed: Unusual behaviour with the default CreateIPPPrinterQueues

[Brian Potkin]

Package: cups-browsed
Version: 1.21.2-1
Severity: minor
Tags: upstream


The default for CreateIPPPrinterQueues is "LocalOnly". All the lines for
the directive were commented out and cups-browsed restarted. AN IPP
printer on the network appears in the 'lpstat -a' output. A minute later
it disappears. A log is attached.

The IPP printer is not displayed at all after restarting cups-browsed
with "CreateIPPPrinterQueues LocalOnly" uncommented. Shouldn't the
default behave in the same way?

Regards,

Brian.




cups-browsed_log.gz
Description: application/gzip

Bug#909422: RM: monero [i386] -- ANAIS; buildd OOMs during build

[Niels Thykier]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove monero on i386 in unstable.  Unfortunately, it cannot
build i386 anymore (requring too much memory) and its presence in
unstable stalls a migration.

Thanks,
~Niels

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

[Peter Lebbing]

On 23/09/2018 13:32, Peter Lebbing wrote:
> How about copying the whole homedir without random_seed, but first
> checking to make sure there are only smartcard keys as private keys?

However, we should specifically exclude openpgp-revocs.d as well. The
whole "is the homedir an API or implementation detail" is a bit muddy
IMHO. I think openpgp-revocs.d is an API, since it is not *consumed* by
GnuPG AFAIK, so it must be something meant for others (users,
frontends), right? So I think we're not intruding on implementation
details by omitting this directory.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature

Bug#909379: segfault when leaving the python3-dbg interpreter

[Andreas Beckmann]

On 2018-09-23 14:54, Rebecca N. Palmer wrote:
> This also happens on amd64 (backtrace follows), where it only affects
> python3.7-dbg (not python3-dbg (3.6) or python3.7).  It happens on
> interpreter exit, not on import.

Given that the package python3-pyopencl-dbg
  Depends: python3-pyopencl (= 2018.1.1-2), python3-dbg (<< 3.7), ...
it is not surprising that it segfaults with python3.7-dbg.

The ben file used for
https://release.debian.org/transitions/html/python3.7.html (#902582)
is bad since it ignores -dbg interpreters. pyopencl only has a strict
(<< 3.7) dependency in the -dbg package, so it was not binNMUed.
I send a message about it to the release-team. The will need to schedule
some more binNMUs.


Andreas

Bug#902582: (some kind of) transition: add python3.7 as a supported python3 version

[Andreas Beckmann]

Followup-For: Bug #902582

Hi,

the ben file is bad since it misses -dbg packages, the following should
work better:

is_affected = .build-depends ~ /python3-all-dev/;
is_good = .depends ~ /python3 \(<< 3\.8\)/ | .depends ~ /python3.7/ | 
/python3-dbg \(<< 3\.8\)/ | .depends ~ /python3.7-dbg/;
is_bad = .depends ~ /python3 \(<< 3\.7\)/ | .breaks ~ /python \(>= 3\.7\)/ | 
.depends ~ /python3-dbg \(<< 3\.7\)/ | .breaks ~ /python-dbg \(>= 3\.7\)/;

see e.g. #909379: python3-pyopencl: segfault when leaving the python3-dbg 
interpreter

Please update and schedule more binNMUs.


Andreas

Bug#909378: sbuild: sbuild-createchroot must not consider “lost+found” for non empty directory

[Daniel Dehennin]

Johannes Schauer  writes:

> Hi,
>
> Quoting Daniel Dehennin (2018-09-22 19:52:55)
>> I'm trying to setup an LVM schroot but I got the following error:
>> 
>> #+begin_src
>> /srv/chroot/sid-amd64-sbuild is not empty at /usr/bin/sbuild-createchroot 
>> line 279,  line 13.
>> #+end_src
>> 
>> The problem is that sbuild-createchroot check for 3 directory entries without
>> taking “lost+found” as an exception.
>
> the reason why sbuild requires an empty target directory, are debootstrap bugs
> like these that make you loose everything in case a wrong code path is taken:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833525
>
> Now imagine that you actually had some previously recovered files in
> lost+found. If you are unlucky, those would then be deleted by a faulty
> debootstrap.
>
> Why don't you just rmdir the directory? Then you also made sure that there is
> indeed nothing inside that you still need. fsck will re-create it in case it
> needs it.

Thanks for the explanation, I already add a rmdir of “lost+found” as a
workaround.

You can considere this report closed.

Have a good day.
-- 
Daniel Dehennin
Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF
Fingerprint: 3E69 014E 5C23 50E8 9ED6  2AAD CC1E 9E5B 7A6F E2DF


signature.asc
Description: PGP signature