Bug#932163: RM: ossim [mips64el] -- ROM; FTBFS on mips64el

[Bas Couwenberg]

On 2019-07-16 07:34, Bastian Blank wrote:

On Tue, Jul 16, 2019 at 07:26:02AM +0200, Bas Couwenberg wrote:

Please remove ossim from mips64el where it FTBFS.


Why?


Because ossim missing for mips64el is not a problem.


Please follow the instructions given:


Feel free to do so if you think that needs doing.

Kind Regards,

Bas

Bug#932163: RM: ossim [mips64el] -- ROM; FTBFS on mips64el

[Bastian Blank]

On Tue, Jul 16, 2019 at 07:26:02AM +0200, Bas Couwenberg wrote:
> Please remove ossim from mips64el where it FTBFS.

Why?

Please follow the instructions given:

| Please submit a full bug report,
| with preprocessed source if appropriate.
| See  for instructions.

Bastian

-- 
Killing is stupid; useless!
-- McCoy, "A Private Little War", stardate 4211.8

Bug#932163: RM: ossim [mips64el] -- ROM; FTBFS on mips64el

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove ossim from mips64el where it FTBFS.

None of its rdeps require it on that arch.

Kind Regards,

Bas

Bug#932161: sitecopy: >100% finished reported

[Sandro Tosi]

Package: sitecopy
Version: 1:0.16.6-7+b2
Severity: normal

Hello,
i'm running sitecopy on a website where some files where moved, and now i get
messages saying it's above 100% finished, which clearly is not possible; it may
that files that are moved are still accounted as "to be transferred", but
anyway there something wrong going on with the progress messages:

...
Moving file1->old_file1: done.
Moving file2->old_file2: done.
Uploading file3: [] done. (142% finished)
Uploading file4: [] done. (142% finished)
Uploading file5: [] done. (142% finished)
...
Uploading fileN: [] done. (242% finished)
sitecopy: Update completed successfully.


thanks,
Sandro

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

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

Versions of packages sitecopy depends on:
ii  libc6 2.28-10
ii  libneon27-gnutls  0.30.2-3

sitecopy recommends no packages.

sitecopy suggests no packages.

-- no debconf information

Bug#932160: unattended-upgrades: regression: path to the kept-back file is not correctly determined

[Paul Wise]

Package: unattended-upgrades
Version: 1.13
Severity: important
Usertags: regression

With every run of unattended-upgrades since I upgraded to 1.13 where
some packages were kept back due to upgrade issues of some kind,
I see this message as the last line of the report:

Could not open var/lib/unattended-upgrades/kept-back for saving list of 
packages kept back.

It appears that the path to the kept-back file is not correctly
determined. If I am interpreting it correctly, no-where in the code
does it change to a particular directory, and os.path.join removes all
empty arguments except a trailing one, so the code writes to a relative
path when the current directory could be anywhere and consequently it
will usually fail unless the current dir happens to be the root dir.

I'm not entirely sure what the correct solution is but I think possibly
that when rootdir is unset it should be set to / like this:

   def main(options, rootdir=None):
   if rootdir:
  
   _setup_alternative_rootdir(rootdir)
   else:
   rootdir = '/'

The current code involved in this issue looks like this: 

KEPT_PACKAGES_FILE = "var/lib/unattended-upgrades/kept-back"
...
def update_kept_packages(kept_pkgs, kept_file):
# type: (DefaultDict[str, List[str]], str) -> None
if kept_pkgs:
pkgs_all_origins = set()
for origin_pkgs in kept_pkgs.values():
pkgs_all_origins.update(origin_pkgs)
try:
with open(kept_file, "w") as kf:
kf.write(" ".join(sorted(pkgs_all_origins)))
except FileNotFoundError:
logging.error(_("Could not open %s for saving list of packages "
"kept back." % kept_file))
else:
if os.path.exists(kept_file):
os.remove(kept_file)
...
def main(options, rootdir=""):
if rootdir:
_setup_alternative_rootdir(rootdir)
...
update_kept_packages(res.pkgs_kept_back,
 os.path.join(rootdir, KEPT_PACKAGES_FILE))
...
if __name__ == "__main__":
sys.exit(main(options))

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), 
LANGUAGE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.72
ii  lsb-base   10.2019051400
ii  lsb-release10.2019051400
ii  python33.7.3-1
ii  python3-apt1.8.4
ii  python3-dbus   1.2.8-3
ii  python3-distro-info0.21
ii  ucf3.0038+nmu1
ii  xz-utils   5.2.4-1

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-28
ii  cron [cron-daemon]  3.0pl1-134
ii  systemd-sysv241-6+b1

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20180807cvs-1
ii  exim4-daemon-light [mail-transport-agent]  4.92-9
ii  needrestart3.4-5
ii  powermgmt-base 1.34
ii  python3-gi 3.30.4-1

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#932159: drm:i915_gem_init_stolen *ERROR* Stolen reserved area outside stolen memory zone

[Nicholas D Steeves]

Package: src:linux
Version: 4.19.37-5
Severity: normal

Hi,

I should have filed this bug two years ago, because I'm guessing a fix
for this hardware requires an upstream quirk.

I forget how old the original installation was...probably squeeze, but
I upgraded to each stable release since then, plus one hardware
upgrade.  The kernel log that was auto inserted via report bug was
useless, so I've attached the relevant portions of one I manually
captured.  This bug is also applicable to all stretch kernels.

I somewhat worked around this issue on stretch, using
"enable_mtrr_cleanup mtrr_spare_reg_nr=1", but even then, a variety of
opengl and vaapi conditions trigger hard locks.  OpenGL performance is
also frequently worse than my X220 (SandyBridge), even though this
Haswell IGPU should be superior in every way.

Oh, also importantly, I'm booting using UEFI with CSM disabled;
although, IIRC the bug is still present when booting with legacy BIOS.

I've confirmed it's still present in upstream 4.19.59, even with NUMA
and paravirtualisation disabled.

Please let me know if there's anything else I can do to help debug and
facilitate quick resolution of this bug.

Regarding: [0.346133] pmd_set_huge: Cannot satisfy [mem 
0xf800-0xf820] with a huge-page mapping due to MTRR override.
...I'm not overriding it.  Maybe a BIOS bug?


Thanks!
Nicholas

-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-5 (2019-06-19)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 
root=UUID=134ba556-9c70-451f-a715-e3c73d65dd1d ro rootflags=subvol=@rootfs 
quiet splash random.trust_cpu=on usbcore.autosuspend=-1 dm_mod.use_blk_mq=0 
elevator=deadline

** Not tainted

** Kernel log:
[0.00] microcode: microcode updated early to revision 0x27, date = 
2019-02-26
[0.00] Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) 
(gcc version 8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-5 (2019-06-19)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 
root=UUID=134ba556-9c70-451f-a715-e3c73d65dd1d ro rootflags=subvol=@rootfs 
quiet splash random.trust_cpu=on usbcore.autosuspend=-1 dm_mod.use_blk_mq=0 
elevator=deadline
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x00057fff] usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009dfff] usable
[0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0x8b43afff] usable
[0.00] BIOS-e820: [mem 0x8b43b000-0x8b441fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x8b442000-0x8b88bfff] usable
[0.00] BIOS-e820: [mem 0x8b88c000-0x8bd53fff] reserved
[0.00] BIOS-e820: [mem 0x8bd54000-0x9c384fff] usable
[0.00] BIOS-e820: [mem 0x9c385000-0x9cc38fff] reserved
[0.00] BIOS-e820: [mem 0x9cc39000-0x9cc9cfff] ACPI data
[0.00] BIOS-e820: [mem 0x9cc9d000-0x9d08efff] ACPI NVS
[0.00] BIOS-e820: [mem 0x9d08f000-0x9db61fff] reserved
[0.00] BIOS-e820: [mem 0x9db62000-0x9dbfefff] type 20
[0.00] BIOS-e820: [mem 0x9dbff000-0x9dbf] usable
[0.00] BIOS-e820: [mem 0x9f00-0xdf1f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00081edf] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.31 by American Megatrends
[0.00] efi:  ESRT=0x9db60818  ACPI=0x9cc4d000  ACPI 2.0=0x9cc4d000  
SMBIOS=0x9db60418
[0.00] secureboot: Secure boot could not be determined (mode 0)
[0.00] SMBIOS 2.8 present.
[0.00] DMI: LENOVO ThinkServer TS140/ThinkServer TS140, BIOS FBKTD0AUS 
06/12/2018
[0.00] tsc: Fast TSC calibration using PIT
[

Bug#932138: minissdpd fails to upgrade from Stretch to Buster

[Yangfl]

On Mon, 15 Jul 2019 20:28:09 +0200 s3v  wrote:
> Package: minissdpd
> Severity: important
>
>
> Dear maintainer,
>
> minissdpd fails with the error reported below during upgrade fron Stretch to 
> Buster:
>
> Setting up minissdpd (1.5.20190210-1) ...
> Installing new version of config file /etc/init.d/minissdpd ...
> enp0s3 Job for minissdpd.service failed because the control process exited 
> with
> error code.
> See "systemctl status minissdpd.service" and "journalctl -xe" for details.
> invoke-rc.d: initscript minissdpd, action "restart" failed.
>  [0;1;31m??? [0m minissdpd.service - keep memory of all UPnP devices that
> announced themselves
>Loaded: loaded
> ( ]8;;file://debian/lib/systemd/system/minissdpd.service 
> /lib/systemd/system/minissdpd.service ]8;; ;
> enabled; vendor preset: enabled)
>Active:  [0;1;31mfailed [0m (Result: exit-code) since Sun 2019-07-14 
> 15:01:16
> CEST; 62ms ago
>  Docs:  ]8;;man:minissdpd(1) man:minissdpd(1) ]8;;
>   Process: 22441 ExecStart=/usr/lib/minissdpd/minissdpd-systemd-wrapper
> ${MiniSSDPd_INTERFACE_ADDRESS} $MiniSSDPd_OTHER_OPTIONS  [0;1;31m(code=exited,
> status=1/FAILURE) [0m
>
> lug 14 15:01:16 debian systemd[1]: Starting keep memory of all UPnP devices 
> that
> announced themselves...
> lug 14 15:01:16 debian minissdpd-systemd-wrapper[22441]: Usage:
> /usr/sbin/minissdpd [-d] [-6] [-s socket] [-p pidfile] [-t TTL] [-f device] -i
>  [-i ] ...
> lug 14 15:01:16 debian minissdpd-systemd-wrapper[22441]:is 
> either
> an IPv4 address with mask such as
> lug 14 15:01:16 debian minissdpd-systemd-wrapper[22441]:
> 192.168.1.42/255.255.255.0, or an interface name such as eth0.
> lug 14 15:01:16 debian minissdpd-systemd-wrapper[22441]:   By default, socket
> will be open as /var/run/minissdpd.sock
> lug 14 15:01:16 debian minissdpd-systemd-wrapper[22441]:   and pid written to
> file /var/run/minissdpd.pid
> lug 14 15:01:16 debian systemd[1]:  [0;1;39m [0;1;31m 
> [0;1;39mminissdpd.service:
> Control process exited, code=exited, status=1/FAILURE [0m
> lug 14 15:01:16 debian systemd[1]:  [0;1;39m [0;1;31m 
> [0;1;39mminissdpd.service:
> Failed with result 'exit-code'. [0m
> lug 14 15:01:16 debian systemd[1]:  [0;1;31m [0;1;39m [0;1;31mFailed to start
> keep memory of all UPnP devices that announced themselves. [0m
>  [1mdpkg: [0m error processing package minissdpd (--configure):
>  installed minissdpd package post-installation script subprocess returned 
> error
> exit status 1
>
> Please note that this issue prevents other packages from upgrading until
> affected package is purged or network interface is properly configured.
>
> Kind regards.
>

> Please note that this issue prevents other packages from upgrading until
> affected package is purged or network interface is properly configured.

Did you read the NEWS or answer the dconf questions properly? If not,
then the failure is what you want.

Bug#931774: RFS: paho.mqtt.c/1.3.0-1 [ITP] -- Eclipse Paho MQTT C client library

[Nobuhiro Iwamatsu]

HI again,

Your package has some warning of dh_missing.

dh_missing: usr/CONTRIBUTING.md exists in debian/tmp but is not
installed to anywhere
dh_missing: usr/README.md exists in debian/tmp but is not installed to anywhere
dh_missing: usr/notice.html exists in debian/tmp but is not installed
to anywhere
dh_missing: usr/edl-v10 exists in debian/tmp but is not installed to anywhere
dh_missing: usr/epl-v10 exists in debian/tmp but is not installed to anywhere

  I think that this file can ignore using debian/not-installed.

dh_missing: usr/samples/MQTTClient_publish_async.c exists in
debian/tmp but is not installed to anywhere
dh_missing: usr/samples/paho_cs_sub.c exists in debian/tmp but is not
installed to anywhere
dh_missing: usr/samples/MQTTAsync_publish.c exists in debian/tmp but
is not installed to anywhere
dh_missing: usr/samples/paho_c_pub.c exists in debian/tmp but is not
installed to anywhere
dh_missing: usr/samples/paho_cs_pub.c exists in debian/tmp but is not
installed to anywhere
dh_missing: usr/samples/pubsub_opts.c exists in debian/tmp but is not
installed to anywhere
dh_missing: usr/samples/MQTTAsync_subscribe.c exists in debian/tmp but
is not installed to anywhere
dh_missing: usr/samples/paho_c_sub.c exists in debian/tmp but is not
installed to anywhere
dh_missing: usr/samples/MQTTClient_publish.c exists in debian/tmp but
is not installed to anywhere
dh_missing: usr/samples/MQTTClient_subscribe.c exists in debian/tmp
but is not installed to anywhere
dh_missing: usr/bin/MQTTClient_publish_async exists in debian/tmp but
is not installed to anywhere
dh_missing: usr/bin/MQTTClient_publish exists in debian/tmp but is not
installed to anywhere
dh_missing: usr/bin/MQTTClient_subscribe exists in debian/tmp but is
not installed to anywhere
dh_missing: usr/bin/MQTTAsync_subscribe exists in debian/tmp but is
not installed to anywhere
dh_missing: usr/bin/MQTTVersion exists in debian/tmp but is not
installed to anywhere
dh_missing: usr/bin/MQTTAsync_publish exists in debian/tmp but is not
installed to anywhere

  I think that this file should be included in paho.mqtt.c-examples
package or other package.

Please fix this.
And static libraries has '-static' suffix. please remove this.


$ ls debian/tmp/usr/lib/x86_64-linux-gnu/libpaho-mqtt3*.a -1
debian/tmp/usr/lib/x86_64-linux-gnu/libpaho-mqtt3a-static.a
debian/tmp/usr/lib/x86_64-linux-gnu/libpaho-mqtt3as-static.a
debian/tmp/usr/lib/x86_64-linux-gnu/libpaho-mqtt3c-static.a
debian/tmp/usr/lib/x86_64-linux-gnu/libpaho-mqtt3cs-static.a


Best regards,
  Nobuhiro

2019年7月16日(火) 7:23 Roman Ondráček :
>
> Dear Mr Iwamatsu,
>
> The problems was fixed.
>
> Yours sincerely,
> Roman Ondráček
>
> Dne 15. 07. 19 v 2:05 Nobuhiro Iwamatsu napsal(a):
> > Hi,
> >
> > 2019年7月15日(月) 7:30 Roman Ondráček :
> >>
> >> Dear Mr Iwamatsu,
> >>
> >> I am not sure if you received my answer on your comment on the site
> >> mentors.debian.net because I replied you via comment on the site
> >> mentors.debian.net.
> >>
> >> It should be fixed in the latest upload where I uploaded the forgotten
> >> source tarball.
> >
> > Thanks, I can download all files from mentors.debian.net.
> > And I noticed two problem.
> >
> > debian/control:
> >
> >We does not need libc6-dev (>= 2.19.18) in Build-Depends.
> >This is provided in the build-essential package.
> >
> > debian/changelog:
> >
> >   Please squash changelog from -1 and -3.
> >   There are changelogs up to -3 now, but put them together. Packages 
> > uploaded to
> >   mentrors are not included in the package as Debian yet.
> >
> > Best regards,
> >   Nobuhiro
> >
>
--
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#932158: raspi3-firmware: add DTB support for Pi Compute Module 3

[Cyril Brulebois]

Package: raspi3-firmware
Severity: important
Tags: patch

Hi,

I've just opened a bug report and a merge request against the linux
kernel to get a DTB added to support Pi Compute Module 3:
 - https://bugs.debian.org/932157
 - https://salsa.debian.org/kernel-team/linux/merge_requests/155

The latter was just merged by Vagrant, so I hope to get this into sid
soon, and into buster after a while.

I've also pushed this commit into raspi3-firmware.git as the repository
is open to contributions from all DDs…
 - 
https://salsa.debian.org/debian/raspi3-firmware/commit/bf3b70946e2600c4197df9ca78996f10d134621e

… so that the extra DTB can be used when it's available.


It might be worth considering backporting this addition through
buster-pu so that buster users can benefit from it. I can probably
handle that on my own if you agree but:
 1. I'm not really familiar with this package and how often such
backports happen;
 2. Due to improved console handling, I might end up using a package
from buster-backports (either locally crafted or picked from that
repository if/when that ends up existing) anyway, instead of a
possibly updated buster package. But I suppose it would make sense
to help other users anyway. :)


Please let me know what you think of my commit to master, and about a
possible backport.

Thanks for your time.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#932157: Please add DTB support for Rasperry Pi Compute Module 3

[Cyril Brulebois]

Package: src:linux
Severity: important
Tags: patch

Hi,

Please consider backporting DTB support for Rasperry Pi Compute Module
3, which means 3 commits from v4.20-rc1. That was both (cross)build
tested on armhf, (cross)build tested and runtime tested on arm64
(tester in X-D-Cc).

I've tried pushing that towards stable@[0,1,2,3] but apparently a DTB
addition doesn't satisfy the device ID addition criterion for stable[4],
hence my proposing this downstream.

 0. https://www.spinics.net/lists/stable/msg315856.html
 1. https://www.spinics.net/lists/stable/msg315849.html
 2. https://www.spinics.net/lists/stable/msg316229.html
 3. https://www.spinics.net/lists/stable/msg315851.html
 4. https://www.spinics.net/lists/stable/msg316478.html

I've prepared a merge request against the sid branch and I'm opening
this bug report to also have a reference for the upcoming
raspi3-firmware bug report and patch to complete this DTB addition.

  https://salsa.debian.org/kernel-team/linux/merge_requests/155

Please let me know if you'd like those patches to be handled in a
different way.

Thanks for considering.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#883393: jool Debian packaging

[Alberto Leiva]

> No, it's absolutely fine by me.
> Alberto, sorry for the long delay, I didn't have time to respond yet.
> Do whatever is needed :-)
> I will help where I can, but currently my time is very limited.

Ok. No problem, thanks :-)

On Sat, Jul 13, 2019 at 4:49 PM Bjoern Buerger  wrote:
>
> Hi @all
>
> Am Sat, 13 Jul 2019 schrieb Vincent Bernat:
>
> >  ❦ 13 juillet 2019 12:29 -05, Alberto Leiva :
> > > I sent him another email on 2018-05-28, and then another one two days
> > > ago. Both of them have gone unanswered as of now.
> >
> > OK, if he disagrees, he still have a bit of time to make us aware of that.
>
> No, it's absolutely fine by me.
>
> Alberto, sorry for the long delay, I didn't have time to respond yet.
> Do whatever is needed :-)
>
> I will help where I can, but currently my time is very limited.
>
> With kind regards,
> Bjørn

Bug#932156: djangorestframework-gis build-depends on cruft package.

[peter green]

Package: djangorestframework-gis
Severity: serious
Tags: buster, sid

djangorestframework-gis build-depends on python-django-filters and 
python-djangorestframework-gis depends on it. python-django-filters is no 
longer built by the django-filter source package.

It's probably time to drop python2 support from your package.

Bug#932155: openstack-pkg-tools, non-buildd binaries

[peter green]

Package: openstack-pkg-tools
Version: 100

The release team have decided that packages with binaries not built on the 
buildds will not be allowed to migrate to testing, you will need to make a 
source-only upload before your package can migrate to testing.

Bug#932154: ITP: golang-github-briandowns-spinner -- Go library for providing a terminal spinner/progress indicator

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-briandowns-spinner
  Version : 1.6.1
  Upstream Author : Brian Downs 
* URL : https://github.com/briandowns/spinner
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library for providing a terminal spinner/progress 
indicator

 golang-github-briandowns-spinner-dev is a simple library to add a spinner or
 progress indicator to any terminal application.
 .
 This provides not only ascii art's spinners, but also spinners using Unicode 
emoji.

Bug#931852: [armel/marvell] cmdline mtd partition map without effect

[Ben Hutchings]

On Mon, 2019-07-15 at 09:31 +0200, Chris Laif wrote:
> On Sat, Jul 13, 2019 at 11:37 PM Ben Hutchings  wrote:
> > On Thu, 2019-07-11 at 15:11 +0200, Chris Laif wrote:
> > > Package: debian-installer
> > > Version: 20190702
> > > 
> > > I'm using the current Buster kernel/initrd on my Seagate Blackarmor NAS.
> > > 
> > > The mtd partition map ('mtdparts' cmdline variable) has no effect
> > > (even with 'cmdline' module loaded):
> > [...]
> > 
> > What if you replace "mtdparts=" with "cmdlineparts.mtdparts="?
> > 
> 
> With "cmdlineparts.mtdparts" it does not work:
[...]
> With "cmdlinepart.mtdparts" (without trailing "s", equal to the name
> of the kernel-module) it works!:

Sorry for the typo.

> ~ # cat /proc/cmdline
> console=ttyS0,115200
> cmdlinepart.mtdparts=orion_nand:0xa@0x0(uboot),0x01@0xa(env),0x50@0xc(uimage),0x1a4@0x5c(rootfs)
> ~ # cat /proc/mtd
> dev:size   erasesize  name
> mtd0: 000a 4000 "uboot"
> mtd1: 0001 4000 "env"
> mtd2: 0050 4000 "uimage"
> mtd3: 01a4 4000 "rootfs"
> ~ #
> 
> This seems to break backwards compatibility for a lot of devices
> (Google shows lots of hits for "mtdparts=" and only a handful for
> "cmdlinepart.mtdparts", so I think nobody is using the latter).
>
> I wonder what's the best way to have a both Stretch and Buster
> compatible cmdline. A quick test shows that "cmdlinepart.mtdparts"
> works with Stretch, too (even Stretch does not have a seperate
> "cmdlinepart" module). Do you have any recommendations?

I think that "cmdlinepart.mtdparts" will work whether or not the driver
is actually a module.  But I accept it would be better if "mtdparts"
also continued to work when the driver is a module.

Ben.

-- 
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.




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

Bug#931901: Ping to Ben Hutchings, identifying possible source of problem

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 2019-07-15 at 08:48 -0400, Kathryn Tolsen wrote:
> It would appear to my untrained eye, that this commit on May 15, 2018 by
> Ben Hutchings is responsible for this issue:
> 
> https://salsa.debian.org/kernel-team/linux/commit/e7bdd24f189b1b8775665d56a1230f7b12915ffe

No, this patch is much older than that.

> This appears to be debian specific and not an upstream issue as the
> upstream code doesn't contain any such checks:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/radeon/radeon_drv.c?h=v4.19.59#n340
> 
> It would appear this is an incorrect assumption to make, that all cards
> newer than the R600 require firmware.

I really don't think so.

> I can't make out what this code is
> doing without digging way deeper but I think this is what is causing this
> issue. There would need to be an exception here or the patch would need to
> be rolled back or came at from a different angle entirely.

I suspect that this bug is a duplicate of bug #928510, for which the
fix missed the buster release (but we can fix it in a point release). 
If you run "update-initramfs -u" and reboot, does that fix the problem?

Ben.

-- 
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.



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

Bug#932153: ITP: golang-github-caarlos0-env -- Go library for parse environment variables to structs

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-caarlos0-env
  Version : 6.0.0
  Upstream Author : Carlos Alexandro Becker
* URL : https://github.com/caarlos0/env
* License : Expat
  Programming Lang: Go
  Description : Go library for parse environment variables to structs

 This is a Simple Golang library to parse environment variables to structs.
 Out of the box all built-in types are supported, plus a few others that are
 commonly used. Supports the following type:
 .
  - string
  - bool
  - int
  - int8
  - int16
  - int32
  - int64
  - uint
  - uint8
  - uint16
  - uint32
  - uint64
  - float32
  - float64
  - string
  - time.Duration
  - encoding.TextUnmarshaler
  - url.URL

Bug#932152: debhelper: Make commands use pkgname.name.fragment automatically?

[Guillem Jover]

Source: debhelper
Source-Version: 12.2
Severity: wishlist

Hi!

I've noticed when using the dh sequencer, one of the common reasons
to override targets is to pass --name arguments to debhelper commands.
It would be nice if the name arguments would be inferred from the
presence of the filenames instead, so that if we have say:

  debian/pkgname-a.name-a.service
  debian/pkgname-a.name-b.service
  debian/pkgname-a.name-c.init
  debian/pkgname-b.name-d.logrotate

Then the commands would automatically use these w/o needing overrides.

Thanks,
Guillem

Bug#931975: dpkg-checkbuilddeps don't allow multiple Vcs-Git statements

[Guillem Jover]

On Sun, 2019-07-14 at 15:03:28 -0700, Russ Allbery wrote:
> In that case, should we increase the strength of this by changing the
> first sentence?  I'm not seeing much purpose served by developer
> discretion here, and this clarifies matters for tool developers.

Sure.

> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 81b3542..8124d64 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -979,7 +979,10 @@ repository where the Debian source package is developed.
>  or ``hg clone`` command. If no branch is specified, the packaging
>  should be on the default branch.
>  
> -More than one different VCS may be specified for the same package.
> +A package control file must not have more than one ``Vcs-``
> +field.  If the package is maintained in multple version control
> +systems, the maintainer should specify the one that they would prefer
> +other people to use as the basis for proposing changes to the package.
>  
>  For both fields, any URLs given should use a scheme that provides
>  confidentiality (``https``, for example, rather than ``http`` or ``git``)

Seconded, too.

Thanks,
Guillem

Bug#931774: RFS: paho.mqtt.c/1.3.0-1 [ITP] -- Eclipse Paho MQTT C client library

[Roman Ondráček]

Dear Mr Iwamatsu,

The problems was fixed.

Yours sincerely,
Roman Ondráček

Dne 15. 07. 19 v 2:05 Nobuhiro Iwamatsu napsal(a):
> Hi,
> 
> 2019年7月15日(月) 7:30 Roman Ondráček :
>>
>> Dear Mr Iwamatsu,
>>
>> I am not sure if you received my answer on your comment on the site
>> mentors.debian.net because I replied you via comment on the site
>> mentors.debian.net.
>>
>> It should be fixed in the latest upload where I uploaded the forgotten
>> source tarball.
> 
> Thanks, I can download all files from mentors.debian.net.
> And I noticed two problem.
> 
> debian/control:
> 
>We does not need libc6-dev (>= 2.19.18) in Build-Depends.
>This is provided in the build-essential package.
> 
> debian/changelog:
> 
>   Please squash changelog from -1 and -3.
>   There are changelogs up to -3 now, but put them together. Packages uploaded 
> to
>   mentrors are not included in the package as Debian yet.
> 
> Best regards,
>   Nobuhiro
> 



signature.asc
Description: OpenPGP digital signature

Bug#932151: ITP: ngtcp2 -- C-library for QUIC transport protocol

[Sakirnth Nagarasa]

Package: ngtcp2
Owner: sakir...@gmail.com

  * Package name: ngtcp2
Upstream Author : ngtcp contributors
  * License : GPL-3+
Description : C-library for QUIC transport protocol

Provides functions and settings to generate a QUIC connection.

Greetings,
Saki

Bug#218581: debhelper: please switch to debian/*.$(DEB_BUILD_GNU_TYPE)

[Guillem Jover]

Hi!

On Sat, 2003-11-01 at 13:47:30 +0100, Robert Millan wrote:
> Package: debhelper
> Version: 4.1.77
> Severity: wishlist

> I'm working on the Glibc-based GNU/KNetBSD port, and have some problems with
> the way debhelper determines its arch-specific files in debian/ directory.
> 
> Due to restrictions in the criteria used by dpkg maintainers to assign
> architecture names, we're having to use the same name "netbsd-i386" for both
> the port based on Glibc and the one using NetBSD's C library.
> 
> Then if the people working on NetBSD-libc add something (which they have done)
> like "debian/foo.install.netbsd-i386", it affects both ports and breaks for 
> the
> Glibc-based one.

This should not be the case, at least nowadays. The requirement is
that an arch should be bijective when it comes to its mapping between
Debian and GNU tuples/triplets.

> We have, however, distinct system triplets. So if instead of looking for:
> 
>   debian/foo.install.$(DEB_BUILD_ARCH)
> 
> debhelper looked for:
> 
>   debian/foo.install.$(DEB_BUILD_GNU_TYPE)
> 
> We could solve the problem in a flexible way. Would you like to do that?
> (and rising DH_COMPAT accordingly, etc).

So (besides this probably having been meant as s/BUILD/HOST/) it seems
this is not needed.

There are further requests to allow for cpu/os-specific files, but I'm
not sure there's a need for those either? Or if there is it's so
fringy they can be handled ad-hoc?

Thanks,
Guillem

Bug#932150: ricochet-im doesn't save user preferences due to broken(?) apparmor profile

[Constantin]

Package: ricochet-im
Version: 1.1.4-3
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
ricochet doesn't save settings, contacts, etc.
~/.local/share/Ricochet/ricochet/ricochet.json is empty


   * What exactly did you do (or not do) that was effective (or
 ineffective)?
ln -s /etc/apparmor.d/usr.bin.ricochet /etc/apparmor.d/disable/
cd /etc/apparmor.d
apparmor_parser -R usr.bin.ricochet

   * What was the outcome of this action?

ricochet works as expected, saving settings

   * What outcome did you expect instead?

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



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

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

Versions of packages ricochet-im depends on:
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libgl1   1.1.0-1
pn  libprotobuf17
ii  libqt5core5a 5.11.3+dfsg1-1
ii  libqt5gui5   5.11.3+dfsg1-1
pn  libqt5multimedia5
ii  libqt5network5   5.11.3+dfsg1-1
ii  libqt5qml5   5.11.3-4
ii  libqt5quick5 5.11.3-4
ii  libqt5widgets5   5.11.3+dfsg1-1
ii  libssl1.11.1.1c-1
ii  libstdc++6   8.3.0-6
ii  libubsan18.3.0-6
pn  qml-module-qtmultimedia  
ii  qml-module-qtquick-controls  5.11.3-2
ii  qml-module-qtquick-dialogs   5.11.3-2
ii  tor  0.3.5.8-1

ricochet-im recommends no packages.

ricochet-im suggests no packages.

-- no debconf information

Bug#932149: Early segfault in steal-ctty on Xen DomU install

[Martin Samuelsson]

Package: installation-reports

Boot method: xl create buster.cfg
Image version: Multiple. Please see below.
Machine: Xen DomU (on HP Proliant Dom0)
Memory: 512M
Partitions: N/A (10G allocated for xvda)

Base System Installation Checklist:
[O] = OK, [E] = Error, [ ] = didn't try it

Initial boot:   [E] Kernel boots, d-i fails to launch.
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Attempting to install Buster on a freshly created Xen DomU fails early with 
the following in the log:


[2.698206] Run /init as init process
[2.83] xen_netfront: Initialising Xen virtual ethernet driver
/sbin/reopen-console: line 26: can't create /var/log/reopen-console: 
nonexistent directory
/sbin/reopen-console: line 26: can't create /var/log/reopen-console: 
nonexistent directory
/sbin/reopen-console: line 26: can't create /var/log/reopen-console: 
nonexistent directory
/sbin/reopen-console: line 26: can't create /var/log/reopen-console: 
nonexistent directory
/sbin/reopen-console: line 26: can't create /var/log/reopen-console: 
nonexistent directory
/sbin/reopen-console: line 69: can't create /var/run/console-devices: 
nonexistent directory
/sbin/reopen-console: line 69: can't create /var/run/console-devices: 
nonexistent directory
/sbin/reopen-console: line 71: can't create /var/run/console-preferred: 
nonexistent directory
/sbin/reopen-console: line 26: can't create /var/log/reopen-console: 
nonexistent directory
/sbin/reopen-console: line 26: can't create /var/log/reopen-console: 
nonexistent directory
cat: can't open '/var/run/console-preferred': No such file or directory
[2.957523] steal-ctty[125]: segfault at 0 ip 7fbce02c4160 sp 
7ffe4dde3830 error 4 in libc.so.6[7fbce021f000+148000]
[2.957551] Code: 8b e8 74 36 04 00 0f 1f 40 00 55 48 89 e5 41 57 41 56 41 55 41 
54 53 48 83 ec 48 64 48 8b 04 25 28 00 00 00 48 89 45 c8 31 c0 <80> 3f 00 0f 84 
47 01 00 00 49 89 f4 be 2f 00 00 00 48 89 fb 49 89
Segmentation fault
cat: can't open '/var/log/reopen-console': No such file or directory
rm: can't remove '/var/log/reopen-console': No such file or directory
touch: /var/run/brltty-Xorg: No such file or directory
touch: /var/run/brltty-Xorg: No such file or directory
touch: /var/run/brltty-Xorg: No such file or directory

The last error, about brltty-Xorg, seems to be repeated perpetually.  
Proceeding with installation is not possible. Pressing Ctrl-C yields no 
visible result.


This happens both with the release image from:

http://deb.debian.org/debian/dists/buster/main/installer-amd64/20190702/images/netboot/xen/

and the latest nightly built from:

https://d-i.debian.org/daily-images/amd64/20190715-00:24/netboot/xen/

Providing "-- console=hvc0", "-- console=tty0", "-- console=" and "" as 
values for the 'extra' config variable makes no difference. No additional 
config options in xl.cfg, apart from pointing out kernel and initial 
ramdisk.


To the best of my understanding, this issue is not mentioned in neither the 
Release Notes nor the Installation Guide for Buster. The Xen page on 
Debian's wiki is also a bit thin on Buster specific details.


For what it's worth Dom0 is running Stretch with Xen 4.8, and has several 
fully functional DomU instances also running Stretch.


One might guess #768657 is related in some way, but unfortunately I do not 
currently fully understand it. I'm reluctant to post directly to it since it 
seems too old (November 2014) to be causing failure only for Buster, but 
please feel free to merge this report with it if confident the issue is 
caused by the same root cause.

--
/Martin

Bug#932148: RFS: pysolfc/2.6.4-1 [RC]

[Juhani Numminen]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: Hugo Lefeuvre 

Dear mentors,

I am looking for a sponsor for the games-team's package pysolfc.
Hugo Lefeuvre had been preparing an upload in git for quite some
time already. Due to #931851 I was inspired to join the effort.
For reference, I've notified Hugo (and the whole team) of my progress:
https://lists.debian.org/debian-devel-games/2019/07/msg1.html

 * Package name: pysolfc
   Version : 2.6.4-1
   Upstream Author : Shlomi Fish
 * URL : https://pysolfc.sourceforge.io/
   : https://github.com/shlomif/PySolFC/
 * License : GPL
   Section : games

It builds those binary packages:
  pysolfc - collection of more than 1000 solitaire card games

The source is not at mentors.debian.net since I'm away from my usual
GPG key and cannot sign the package today. You can get it from salsa
(the gbp command comes from the package git-buildpackage):

gbp clone https://salsa.debian.org/games-team/pysolfc.git
cd pysolfc/
gbp buildpackage -S

Changes since the last upload:

pysolfc (2.6.4-1) unstable; urgency=medium

  * Team upload.

  [ Hugo Lefeuvre ]
  * Migrate to Python 3 (Closes: #912508).
  * debian/control:
- Update Vcs-Git and Vcs-Browser fields (Salsa migration).
- Multiple build-dependency changes due to the migration to Python 3 and
  documentation generation which requires several binary dependencies to
  be build dependencies as well.
  * debian/copyright:
- Update copyright years.
- Refresh files list and copyrights to match new upstream release.
  * debian/patches:
- Refresh patches for new upstream release, remove merged patches.
- Add debian-specific patch which allows installation of cardsets from
  cardsets/ instead of data/.
- Add patch fixing import of pysollib submodules.
  * Update docs list.
  * debian/rules:
- Build translations from po.
- Build html documentation from source.
- Migrate to pybuild.
  * Bump watch file version to 4.

  [ Juhani Numminen ]
  * New upstream release (Closes: #919923).
- Compatible with the current version of Python Imaging Library
  (Closes: #931851).
- No longer crashes when there is no sound card (Closes: #781663).
  * debian/watch: Download a separate orig tarball for the minimal cardsets.
  * debian/gbp.conf:
- Add component=cardsets to tell gbp about the new additional tarball.
- Remove compression=bzip2, the defaults are good enough.
  * debian/clean: Clean up after localization build process, html generation,
and test suite.
  * debian/control:
- Update home page URL.
- Bump Standards-Version to 4.4.0.
- Bump compat level by depending on debhelper-compat (= 12).
- Add python3-random2 dependency.
- Declare Rules-Requires-Root: no.
  * debian/docs: AUTHORS is no longer in the tarball.
  * debian/patches:
- desktop: Add Comment, Keywords, StartupWMClass for better DE integration.
- manpage: Drop the patch, changes are incorporated upstream.
  * debian/rules:
- It is no longer necessary to rename the manpage either.
- Build docs/all_games.html from source.
- Run a part of the test suite. All tests can't be run as some dependencies
  are not in Debian.
  * debian/tests/: Run the same subset of tests also for the installed package.
  * Remove debian/menu because it's redundant with .desktop (Policy §9.6).
  * debian/copyright:
- Update home page URL.
- Add myself to the debian/ paragraph.


Regards,
 Juhani Numminen

Bug#932068: Fwd: Bug#932068: rsyslog FTCBFS: uses mysql_config

[Michael Biebl]

Am 15.07.19 um 18:50 schrieb Rainer Gerhards:
> looks like it doesn't work out... pls have a look at CI.
> 
> Thx,
> Rainer
> 
> El lun., 15 jul. 2019 a las 18:36, Rainer Gerhards
> () escribió:
>>
>> ah, it was all there, so I applied the patch and created a PR:
>>
>> https://github.com/rsyslog/rsyslog/pull/3747

Interesting.
One failure is

> checking for MYSQL... no
> checking for mysql_config... mysql_config
> checking for mysql_init in -lmysqlclient... yes
> checking if we have mysql_library_init... checking for LIBUUID... yes
> checking for OPENSSL... yes
> checking for libgcrypt-config... /usr/bin/libgcrypt-config
> checking for gcry_cipher_open in -lgcrypt... no
> configure: error: in `/worker/rsyslog_docker-centos6/build':
> configure: error: libgcrypt is missing
> See `config.log' for more details.


the other

> checking for MYSQL... no
> checking for mysql_config... mysql_config
> checking for mysql_init in -lmysqlclient... yes
> checking if we have mysql_library_init... checking for pg_config... pg_config
> checking for PQconnectdb in -lpq... no
> configure: error: in `/worker/rsyslog_docker-centos7_rsyslog/build':
> configure: error: PgSQL library is missing
> See `config.log' for more details

Seems like the change has a side-effect on other checks.

The other failures are test-suite failures which don't look related.

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

Bug#919317: [Pkg-shadow-devel] Bug#919317: shadow: French documentation translation update

[Bálint Réczey]

Control: fixed -1 1:4.7-1

Alban Vidal  ezt írta (időpont: 2019. febr.
11., H, 7:33):
>
> Control: tag -1 |upstream|
> Control: tag -1 |pending|
>
> ---
>
> Dear Maintainer,
>
> Merge request sended in upstream project:
> https://github.com/shadow-maint/shadow/pull/153
>
> Regards,
>
> Alban
>
>

Bug#801981: Fixed upstream

[Bálint Réczey]

Control: fixed -1 1:4.7-1

Bug#911604: haveged start up fails due to apparmor denying write access to /run/haveged.pid

[Cyril Brulebois]

Hi Justin,

(I'm adding back others in cc as the Debian BTS doesn't Cc people by
default.)

Justin Pasher  (2019-07-15):
> > From: Cyril Brulebois 
> >
> > But I'd be very happy to have success reports from sysvinit users
> > before considering backporting this to buster.
> 
> I use sysvinit. I've installed the 1.9.1-8 version of the package, and it
> seems to work properly for me. For reference, I did the following test:
> 
> 1. Blank out /etc/apparmor.d/local/usr.sbin.haveged to remove my added line
> 2. /etc/init.d/haveged stop
> 3. aa-enforce /usr/sbin/haveged
> 4. /etc/init.d/haveged start  --  It failed to start (as expected)
> 5. Update to haveged=1.9.1-8
> 6. Verify haveged has started (the post install scripts take care of
> apparmor and starting the process)
> 7. Verify /etc/apparmor.d/local/usr.sbin.haveged is still blank
> 8. Reboot and verify haveged still starts up properly
> 
> Thanks for the quick turn around!

Many thanks for the confirmation.

Meanwhile, I've confirmed with apparmor maintainers that the patch looks
good in theory as well, so having your confirmation that it works on the
practical level too means I'm well equipped to prepare the backport
dance. :)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#917773: [Pkg-shadow-devel] Bug#917773: shadow: doesn't respect SOURCE_DATE_EPOCH

[Bálint Réczey]

Control: fixed -1 1:4.7-1

Chris Lamb  ezt írta (időpont: 2019. jan. 2., Sze, 19:21):
>
> forwarded 917773 https://github.com/shadow-maint/shadow/pull/146
> thanks
>
> Hi josch,
>
> > the /etc/shadow as created by debootstrap does not respect the
> > SOURCE_DATE_EPOCH environment variable anymore. This bug was formerly
> > fixed in #857803.
>
> I have attempted to fix this upstream here:
>
>   https://github.com/shadow-maint/shadow/pull/146

Thanks!

Cheers,
Balint

>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#922935: Run without cron or is cron job still needed?

[Bálint Réczey]

Control: fixed -1 1:4.7-1

Bálint Réczey  ezt írta (időpont: 2019. máj.
14., K, 16:42):
>
> Hi Bryan,
>
> Bryan Quigley  ezt írta (időpont: 2019.
> febr. 22., P, 2:03):
> >
> > Package: passwd
> > Version: 1:4.5-1.1
> >
> > This is regards to passwd.cron.daily which backups 
> > passwd/group/shadow/gshadow daily, which AFAICT is not upstream, but may 
> > have been in the past.
> >
> > I'm looking at what it takes to run systems without cron and following the 
> > example of other packages like logrotate:
> >
> > They add this bit to the cron script:
> > # skip in favour of systemd timer
> > if [ -d /run/systemd/system ]; then
> > exit 0
> > fi
> >
> > and then create a systemd service/timer.  Happy to do the work to make a 
> > patch if the above is the preferred solution.
>
> Thank you for the offer. It is indeed a good solution and a patch is welcome.
>
> Cheers,
> Balint
>
> >
> > ___
> >
> > Alternatively, I have also wondered if the cron job functionality is still 
> > needed or if the built-in generated backups are enough - /etc/group- etc.
> >
> > On my machine the /etc/group- backup would have been much more useful then 
> > the one replaced daily by the cron job in /var/backups.
> >
> > Thanks!

Bug#906304: [Pkg-shadow-devel] Bug#906304: login: Failure to load desktop after login

[Bálint Réczey]

Control: tags -1 moreinfo

Hi Cody,

Cody Jackson  ezt írta (időpont: 2018. aug. 16.,
Cs, 21:57):
>
> Package: login
> Version: 1:4.4-4.1
> Severity: important
>
> Dear Maintainer,
>
>* What led up to the situation?
> Updating kernal from 4.9.0-6 to 4.9.0-7 using apt-get dist-upgrade
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> My once per month apt-get dist-upgrade
>
>
>
>* What was the outcome of this action?
>
> When I started the OS with the new kernal. I was able to login, but then the 
> screen went blank indefinitely. I tried shutting down and updating again. I 
> also submitted a bug report to the kernal team, but it wasn't the right 
> package.
>* What outcome did you expect instead?
>
> The new kernal version to let me log in and use the desktop.

Well, I believe the linux package would have still been better than
login, which is for _console_ logins, but please tell if your issue
was resolved because then we can close this bug instead of reassigning
it.

Thanks,
Balint

Bug#932147: oolite: No package for Debian 10

[Alexandros Prekates]

Package: oolite
Version: 1.84-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

There is no package for Debian 10.




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

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

Bug#923160: [Pkg-shadow-devel] Bug#923160: /usr/sbin/groupadd: Fail to add user pulse to group bluetooth.

[Bálint Réczey]

Control: notfound -1 1:4.4-4.1

Corcodel Marian  ezt írta (időpont: 2019.
febr. 24., V, 16:39):
>
> Package: passwd
> Version: 1:4.4-4.1
> Severity: important
> File: /usr/sbin/groupadd
>
> Run from terminal as root
>  root@debian:/home/as# useradd -g bluetooth pulse
> useradd: user 'pulse' already exists
> Inspect file etc/group but not see user pulse together with another
> usersseparate by semicolon , as manual group.

I believe you wanted to do:

usermod -g bluetooth pulse

Cheers,
Balint

>
>
>
> -- System Information:
> Debian Release: 9.8
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.0.0-rc6+ (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 passwd depends on:
> ii  libaudit1   1:2.6.7-2
> ii  libc6   2.24-11+deb9u4
> ii  libpam-modules  1.1.8-3.6
> ii  libpam0g1.1.8-3.6
> ii  libselinux1 2.6-3+b3
> ii  libsemanage12.6-2
>
> passwd recommends no packages.
>
> passwd suggests no packages.
>
> -- no debconf information
>
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#390190: texlive-base: Better dependency chains

[Hilmar Preuße]

On 29.09.06 19:25, Frank Küster wrote:

Hi Frank, hi Norbert,

> I was just trying to suggest proper dependencies for debiandoc-sgml, as
> an alternative to teTeX, and wondered why texlive-latex-extra does not
> depend on texlive-latex-recommended.  This means that a package that
> needs files from both packages has to depend on both.  However, I was
> under the impression that there's kind of a "hierarchy" of packages,
> texlive-latex-base < texlive-latex-recommended < texlive-latex-extra,
> and no one would only want -extra without recommended.  
> 
> Obviously this was wrong - why?
> 
What to w/ that report? Two drunken people speaking to each other, but
no real result. Do we hat to take that report seriously?

If yes, two new deps needs to be introduced:

- texlive-fonts-extra dep on texlive-fonts-recommended
- texlive-generic-extra dep on texlive-generic-recommended

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



signature.asc
Description: OpenPGP digital signature

Bug#932146: jhead: CVE-2019-1010302

[Salvatore Bonaccorso]

Source: jhead
Version: 1:3.03-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for jhead.

CVE-2019-1010302[0]:
| jhead 3.03 is affected by: Incorrect Access Control. The impact is:
| Denial of service. The component is: iptc.c Line 122 show_IPTC(). The
| attack vector is: the victim must open a specially crafted JPEG file.

The isse was reported in [1], might you try your luck in contacting
upstream? The issue is reproducible with the provided POC.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-1010302
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1010302
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1679978

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#932145: jhead: CVE-2019-1010301

[Salvatore Bonaccorso]

Source: jhead
Version: 1:3.03-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for jhead.

CVE-2019-1010301[0]:
| jhead 3.03 is affected by: Buffer Overflow. The impact is: Denial of
| service. The component is: gpsinfo.c Line 151 ProcessGpsInfo(). The
| attack vector is: Open a specially crafted JPEG file.

The issue has been reported to a downstream bugzilla at [1], could you
try your luck contacting upstream? The issue is reproducible with the
provided POC.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-1010301
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1010301
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1679952

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#914957: [Pkg-shadow-devel] Bug#914957: login: removal of pts/* from /etc/securetty wasn't applied in stretch

[Bálint Réczey]

Hi Michael,

Michael Biebl  ezt írta (időpont: 2018. dec. 9., V, 0:37):
>
> On Sat, 8 Dec 2018 21:57:11 +0100 =?UTF-8?B?QsOhbGludCBSw6ljemV5?=
>  wrote:
> > While I believe securetty should be disabled by default
>
> Fwiw, I agree that securetty is a bad idea and should be removed from
> the default pam configuration.
> There is a login-standing bug report, documenting that securetty breaks
> "machinectl login" [1] fwiw.
>
> Can we please revisit this and drop securetty from /etc/pam.d/login for
> buster?

Unfortunately this missed Buster, but it is at least done for Bullseye
and later.

Cheers,
Balint

>
> Regards,
> Michael
>
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771675#20
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>

Bug#890557: shadow: CVE-2018-7169: unprivileged user can drop supplementary groups

[Bálint Réczey]

Control: fixed -1 1:4.7-1

Salvatore Bonaccorso  ezt írta (időpont: 2018.
febr. 15., Cs, 22:33):
>
> Source: shadow
> Version: 1:4.5-1
> Severity: important
> Tags: security upstream
>
> Hi,
>
> the following vulnerability was published for shadow.
>
> CVE-2018-7169[0]:
> | An issue was discovered in shadow 4.5. newgidmap (in shadow-utils) is
> | setuid and allows an unprivileged user to be placed in a user namespace
> | where setgroups(2) is permitted. This allows an attacker to remove
> | themselves from a supplementary group, which may allow access to
> | certain filesystem paths if the administrator has used "group
> | blacklisting" (e.g., chmod g-rwx) to restrict access to paths. This
> | flaw effectively reverts a security feature in the kernel (in
> | particular, the /proc/self/setgroups knob) to prevent this sort of
> | privilege escalation.
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2018-7169
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7169
> [1] https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1729357
>
>
> Please adjust the affected versions in the BTS as needed.
>
> Regards,
> Salvatore
>

Bug#931899: login: still tries to open /etc/securetty

[m . alfaeko]

Package: login
Version: 1:4.7-1
Followup-For: Bug #931899

Hi

I found where is /etc/securetty referenced. Its referenced in config file 
/etc/pam.d/common-auth
on line specifing pam_unix. Just remove secure_nullok and the log message wont 
appear again.
Ofcourse someone should test this to be sure its the right solution.

Thank You

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

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

Versions of packages login depends on:
ii  libaudit1   1:2.8.4-3
ii  libc6   2.28-10
ii  libpam-modules  1.3.1-5
ii  libpam-runtime  1.3.1-5
ii  libpam0g1.3.1-5

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#932144: RM: ipsec-tools -- ROM; dead upstream, alternatives available

[Chris Hofstaedtler]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

Please remove ipsec-tools from unstable. It was not suitable to
include in buster and we the maintainers don't believe upstream will
wake up to improve the package.

There are alternatives (strongswan et al) available in Debian.

Noah's original explanation from #917847:

  The package is effectively orphaned upstream and has been for some time.
  Given the security-sensitive nature of the package, an active maintainer
  community is essential for safe usage. Racoon's lack of support for IKEv2,
  despite it being stable for a long time, and the availability of
  next-generation tunneling systems such as wireguard, also would seem to
  limit its future value. Setkey's functionality has been subsumed by 'ip
  xfrm'.

Thanks,
Chris

-- 
 ,''`.  Chris Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#859706: Additional info

[John Gateley]

This bug is present in Debian 10, and I am getting the following in my 
system logs:


Jul 15 18:14:15 elephant systemd-tmpfiles[21359]: [/usr/lib/tmpfiles.d/opendkim.conf:1] Line references path below legacy 
directory /var/run/, updating /var/run/opendkim → /run/opendkim; please 
update the tmpfiles.d/  drop-in file accordingly.

Bug#932143: mariadb-10.3.16 migration excuses indicate need for manual cleanup?

[Otto Kekäläinen]

Package: ftp.debian.org
Severity: normal

Currently the excuses at
https://qa.debian.org/excuses.php?package=mariadb-10.3 state:

old binaries left on amd64: libmariadbclient18 (from 1:10.3.13-1) (but
ignoring cruft, so nevermind)
old binaries left on arm64: libmariadbclient18 (from 1:10.3.13-1) (but
ignoring cruft, so nevermind)
old binaries left on armel: libmariadbclient18 (from 1:10.3.13-1) (but
ignoring cruft, so nevermind)
old binaries left on armhf: libmariadbclient18 (from 1:10.3.13-1) (but
ignoring cruft, so nevermind)
old binaries left on i386: libmariadbclient18 (from 1:10.3.13-1) (but
ignoring cruft, so nevermind)
old binaries left on mips: libmariadbclient18 (from 1:10.3.13-1) (but
ignoring cruft, so nevermind)
old binaries left on mips64el: libmariadbclient18 (from 1:10.3.13-1)
(but ignoring cruft, so nevermind)
old binaries left on mipsel: libmariadbclient18 (from 1:10.3.13-1)
(but ignoring cruft, so nevermind)
old binaries left on ppc64el: libmariadbclient18 (from 1:10.3.13-1)
(but ignoring cruft, so nevermind)
old binaries left on s390x: libmariadbclient18 (from 1:10.3.13-1) (but
ignoring cruft, so nevermind)

This has been there for many months now and does not seem to clean up
the cruft automatically (or remove the error message).

Could the ftp-masters please take a look and manually resolve it?

Thanks,

- Otto

Bug#932142: ITP: python3-colored -- Very simple Python library for color and form atting in terminal.

[Arthur Diniz]

Package: wnpp
Severity: wishlist
Owner: Arthur Diniz 

* Package name: python3-colored
  Version : 1.3.93
  Upstream Author : Dimitris Zlatanidis 
* URL : https://gitlab.com/dslackw/colored
* License : MIT
  Programming Lang: Python
  Description : Very simple Python library for color and formatting in
ter
minal.

Collection of color codes and names for 256 color terminal setups.
The following is a list of 256 colors for Xterm, containing an example
of the displayed color, Xterm Name, Xterm Number and HEX.

Bug#932141: ITP: python-sphinx-issues -- extension for linking to project's issue tracker

[Ondřej Nový]

Package: wnpp
Severity: wishlist
Owner: Ondřej Nový 

* Package name: python-sphinx-issues
  Version : 1.2.0
  Upstream Author : Steven Loria
* URL : https://github.com/sloria/sphinx-issues/
* License : Expat
  Programming Lang: Python
  Description : extension for linking to project's issue tracker

A Sphinx extension for linking to your project's issue tracker. Includes roles 
for linking to issues, pull requests, user profiles, with built-in support for 
GitHub (though this works with other services).

I'm going to maintain this inside DPMT team.

Bug#932140: fastboot: Manpage problems

[Matthias Urlichs]

Package: fastboot
Version: 1:8.1.0+r23-5
Severity: minor

man fastboot:

>> With devices command, list device paths."

These quotes are misplaced.

Also, the "--" prefix for long options is contracted to an em-dash, which
is not what you want in manpages. Those need proper escaping.


-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'unstable'), (550, 'experimental'), (550, 
'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages fastboot depends on:
ii  android-libadb 1:8.1.0+r23-5
ii  android-libbase1:8.1.0+r23-5
ii  android-libcutils  1:8.1.0+r23-5
ii  android-libf2fs-utils  8.1.0+r23-2
ii  android-libsparse  1:8.1.0+r23-5
ii  android-libutils   1:8.1.0+r23-5
ii  android-libziparchive  1:8.1.0+r23-5
ii  libc6  2.28-10
ii  libgcc11:9.1.0-2
ii  libstdc++6 9.1.0-2

Versions of packages fastboot recommends:
ii  android-sdk-platform-tools  27.0.0+10

fastboot suggests no packages.

-- no debconf information

Bug#932125: tor: missing dependency on procps

[Peter Palfrader]

On Mon, 15 Jul 2019, Dmitry Bogatov wrote:

> init.d script contains following code (line 239):
> 
>   if ps "$pid" >/dev/null 2>&1; then
>   log_success_msg "$NAME is running"
>   exit 0
>   else
>   log_failure_msg "$NAME is not running"
>   exit 1
>   fi

Thanks for your report.

I think the following should also fix this:

-   if ps "$pid" >/dev/null 2>&1; then
+   if start-stop-daemon --pid "$pid" -T ; then


Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#932089: openssh-server: Cannot log into openssh-server on buster/mipsel

[Francois Marier]

On 2019-07-15 at 10:33:26, Colin Watson wrote:
> However, openssh should just fall back to not using seccomp sandboxing
> in that case.  It should make it easier to debug though!  Perhaps you
> could run sshd under strace and we might be able to see where it goes
> wrong there?  (Be careful with the strace output, as it will contain
> secrets such as the private host key.)

I ran the following to get an strace from the point where I try to connect
from the client:

$ /usr/sbin/sshd
$ pgrep sshd
7816

$ strace -p 7816
strace: Process 7816 attached
_newselect(5, [3 4], NULL, NULL, NULL)  = 1 (in [3])
accept(3, {sa_family=AF_INET, sin_port=htons(33142), 
sin_addr=inet_addr("192.168.1.5")}, [128->16]) = 5
fcntl64(5, F_GETFL) = 0x2 (flags O_RDWR)
pipe([6, 7])= 6
socketpair(AF_UNIX, SOCK_STREAM, 0, [8, 9]) = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x765d2078) = 7821
close(7)= 0
write(8, "\0\0\1\v\0", 5)   = 5
write(8, "\0\0\1\6\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"..., 
266) = 266
close(8)= 0
close(9)= 0
close(5)= 0
time(NULL)  = 1563216707 (2019-07-15T18:51:47+)
time(NULL)  = 1563216707 (2019-07-15T18:51:47+)
clock_gettime(CLOCK_BOOTTIME, {tv_sec=437223, tv_nsec=281923987}) = 0
time(NULL)  = 1563216707 (2019-07-15T18:51:47+)
getpid()= 7816
clock_gettime(CLOCK_BOOTTIME, {tv_sec=437223, tv_nsec=283146422}) = 0
time(NULL)  = 1563216707 (2019-07-15T18:51:47+)
time(NULL)  = 1563216707 (2019-07-15T18:51:47+)
clock_gettime(CLOCK_BOOTTIME, {tv_sec=437223, tv_nsec=284680271}) = 0
time(NULL)  = 1563216707 (2019-07-15T18:51:47+)
time(NULL)  = 1563216707 (2019-07-15T18:51:47+)
time(NULL)  = 1563216707 (2019-07-15T18:51:47+)
_newselect(7, [3 4 6], NULL, NULL, NULL) = 1 (in [6])
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7821, si_uid=0, 
si_status=255, si_utime=23, si_stime=3} ---
waitpid(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 255}], WNOHANG) = 7821
waitpid(-1, 0x7fac9920, WNOHANG)= -1 ECHILD (No child processes)
sigreturn({mask=[]})= 1
close(6)= 0
_newselect(7, [3 4], NULL, NULL, NULLstrace: Process 7816 detached
 

Let me know if you need a full strace from the start of the sshd process.

> > By the way, this machine is sadly not using a Debian kernel. It's using
> > librecmc-ramips-mt7621-gb-pc1-squashfs-sysupgrade_2017-11-28.bin from
> > https://github.com/gnubee-git/gnubee-git.github.io/blob/master/debian/.
> 
> I hope that the source for this is available somewhere and that it isn't
> just a GPL violation?  I couldn't easily find the source.

I wasn't able to find it either, I filed
https://github.com/gnubee-git/gnubee-git.github.io/issues/4.

Francois

-- 
https://fmarier.org/

Bug#932136: udd: use reproducible builds data for bullseye

[Vagrant Cascadian]

On 2019-07-15, Vagrant Cascadian wrote:
> Package: qa.debian.org
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>
> udd.debian.org still reports reproducible builds results for buster, but
> it should now report issues for bullseye.
>
> If there's something we need to change on the reproducible builds side
> to fix this, please let us know!

It looks like it was actually a one-line fix to jenkins:

  
https://salsa.debian.org/qa/jenkins.debian.net/commit/ebf9906124c7ae1e1c3019de26577a6b4a3dff2b

I havent deployed it to give the other folks a chance to review to make
sure it's the correct fix.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#930952: RFS: libagentcrypt/1.0.5-2 [ITP] -- symmetric encryption with SSH Agent

[Adam Borowski]

On Sun, Jun 23, 2019 at 02:24:42PM +0200, Nicola Di Lieto wrote:
> * Package name: libagentcrypt
>  Version : 1.0.5-2
>  Upstream Author : Nicola Di Lieto 
> * URL : https://github.com/ndilieto/libagentcrypt

> It builds those binary packages:
> 
> libagentcrypt0 - Symmetric encryption with SSH Agent
> libagentcrypt-dev - Symmetric encryption with SSH Agent - headers
> libagentcrypt-bin - Symmetric encryption with SSH Agent - command line utility

Hi!
How do I use this program?  According to my reading of the man page,
the following should work:

[/tmp]$ echo meow >foo
[/tmp]$ agentcrypt foo
agentcrypt: failed to encrypt foo: Invalid argument
[/tmp]$ agentcrypt -v foo
agentcrypt: encrypting foo to foo.acb in binary mode
agentcrypt: failed to encrypt foo: Invalid argument

The ssh agent is running, and I can ssh normally.


You can run lintian to automate the bulk of reviewers' work.
Here, it says:
W: libagentcrypt-dev: manpage-has-bad-whatis-entry 
usr/share/man/man3/libagentcrypt.h.3.gz
W: libagentcrypt-dev: pkg-config-references-unknown-shared-library 
usr/lib/x86_64-linux-gnu/pkgconfig/libagentcrypt.pc -lsodium (line 26)
E: libagentcrypt0: repeated-trigger-name activate-noawait ldconfig (line 3) vs 
activate-noawait ldconfig (line 1)

repeated-trigger-name is because both you and dh add the same trigger; you
can remove it.

There's no reason for user programs to link with libsodium:
[~]$ ldd /usr/lib/x86_64-linux-gnu/libagentcrypt.so.0
linux-vdso.so.1 (0x7fff1b6ab000)
libgtk3-nocsd.so.0 => /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 
(0x7f5d7789e000)
libsodium.so.23 => /usr/lib/x86_64-linux-gnu/libsodium.so.23 
(0x7f5d77847000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f5d77686000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f5d77681000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f5d7766)
/lib64/ld-linux-x86-64.so.2 (0x7f5d77ad)
any program that uses your library will recursively pull in libsodium
via the loader; if you recompile against a different backend or even
a different soversion of libsodium that won't affect the programs.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts
⣾⠁⢰⠒⠀⣿⡁ productivity.  You can read it, too, you just need the
⢿⡄⠘⠷⠚⠋⠀ right music while doing so.  I recommend Skepticism
⠈⠳⣄ (funeral doom metal).

Bug#932139: ITP: r-cran-deoptim -- GNU R global optimization by differential evolution

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-deoptim -- GNU R global optimization by differential 
evolution
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-deoptim
  Version : 2.2
  Upstream Author : David Ardia,
* URL : https://cran.r-project.org/package=DEoptim
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R global optimization by differential evolution
 This GNU R package implements the differential evolution algorithm for
 global optimization of a real-valued function of a real-valued parameter
 vector.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-deoptim

Bug#932134: libossim1: Segmentation fault in ossimTiffProjectionFactory

[Sebastiaan Couwenberg]

Hi Guillaume,

Thanks for the extensive report.

On 7/15/19 7:15 PM, Guillaume Pasero wrote:
> I am using libossim1 through Orfeo ToolBox and I noticed a crash when 
> upgrading Ossim from 2.6.2 to 2.7.2.

We could try upgrading ossim to 2.8.2. maybe that contains a fix.

> There is a segmentation fault when using the 
> ossimImageHandler::getImageGeometry() on a TIFF file.
> 
> The steps to reproduce are: 
> 
>   * Get a docker image ready to build OTB : 
> registry.orfeo-toolbox.org/orfeotoolbox/otb-build-env/otb-debian-native:unstable
>   * run the docker container as root
>   * Upgrade Ossim to 2.7.2
>   * make sure LFS is installed: git lfs install
>   * clone OTB sources (develop branch) : git clone 
> https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb
>   * in OTB sources, run : ctest -VV -S CI/main_ci.cmake 
> -DIMAGE_NAME=debian-unstable-gcc
>   * after the test fails you can re-run a test manually, for instance: ctest 
> -VV -R ioTvMultiResolutionReadingInfo_TIFF

Since you're building OTB yourself, it's unlikely to be an ABI break
issue due to the otb package being built with an old version of ossim.

I didn't want to touch ossim in anticipation of the OTB 7 which won't
require it any more, but I guess I don't have much of a choice.

Please try to reproduce the issue when ossim (2.8.2-1) is available
unstable.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#932138: minissdpd fails to upgrade from Stretch to Buster

[s3v]

Package: minissdpd
Severity: important


Dear maintainer,

minissdpd fails with the error reported below during upgrade fron Stretch to 
Buster:

Setting up minissdpd (1.5.20190210-1) ...
Installing new version of config file /etc/init.d/minissdpd ...
enp0s3 Job for minissdpd.service failed because the control process exited with
error code.
See "systemctl status minissdpd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript minissdpd, action "restart" failed.
??? minissdpd.service - keep memory of all UPnP devices that
announced themselves
   Loaded: loaded
(]8;;file://debian/lib/systemd/system/minissdpd.service/lib/systemd/system/minissdpd.service]8;;;
enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2019-07-14 15:01:16
CEST; 62ms ago
 Docs: ]8;;man:minissdpd(1)man:minissdpd(1)]8;;
  Process: 22441 ExecStart=/usr/lib/minissdpd/minissdpd-systemd-wrapper
${MiniSSDPd_INTERFACE_ADDRESS} $MiniSSDPd_OTHER_OPTIONS (code=exited,
status=1/FAILURE)

lug 14 15:01:16 debian systemd[1]: Starting keep memory of all UPnP devices that
announced themselves...
lug 14 15:01:16 debian minissdpd-systemd-wrapper[22441]: Usage:
/usr/sbin/minissdpd [-d] [-6] [-s socket] [-p pidfile] [-t TTL] [-f device] -i
 [-i ] ...
lug 14 15:01:16 debian minissdpd-systemd-wrapper[22441]:is either
an IPv4 address with mask such as
lug 14 15:01:16 debian minissdpd-systemd-wrapper[22441]:
192.168.1.42/255.255.255.0, or an interface name such as eth0.
lug 14 15:01:16 debian minissdpd-systemd-wrapper[22441]:   By default, socket
will be open as /var/run/minissdpd.sock
lug 14 15:01:16 debian minissdpd-systemd-wrapper[22441]:   and pid written to
file /var/run/minissdpd.pid
lug 14 15:01:16 debian systemd[1]: minissdpd.service:
Control process exited, code=exited, status=1/FAILURE
lug 14 15:01:16 debian systemd[1]: minissdpd.service:
Failed with result 'exit-code'.
lug 14 15:01:16 debian systemd[1]: Failed to start
keep memory of all UPnP devices that announced themselves.
dpkg: error processing package minissdpd (--configure):
 installed minissdpd package post-installation script subprocess returned error
exit status 1

Please note that this issue prevents other packages from upgrading until
affected package is purged or network interface is properly configured.

Kind regards.

Bug#932044: calibre: PDF to EPUB conversion failed with "No module named html2text"

[Vincas Dargis]

On 2019-07-15 03:36, Norbert Preining wrote:

Can you try installing
python-html2text
And see if that fixes the problem? 


Yes, it did the trick!

Bug#932136: udd: use reproducible builds data for bullseye

[Vagrant Cascadian]

Package: qa.debian.org
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

udd.debian.org still reports reproducible builds results for buster, but
it should now report issues for bullseye.

If there's something we need to change on the reproducible builds side
to fix this, please let us know!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#911604: haveged start up fails due to apparmor denying write access to /run/haveged.pid

[Justin Pasher]

- Original Message -
> From: Cyril Brulebois 
> Date: Friday, July 12, 2019 06:45:08 PM CDT
> Subject: Re: Bug#911604: haveged start up fails due to apparmor 
denying write access to /run/haveged.pid

> To: Axel Beckert , 911604 <911...@bugs.debian.org>
> CC: Gert , Dean Hamstead , Justin 
Pasher 

>

Everyone: please deploy -8 (just uploaded) to your buster and/or
unstable systems and report back. I've tested this on a stretch system
that's running with systemd, using the daemon directly, or a hacked up
init script to make sure I was evading the initscript→systemd machinery
through LSB functions; and everything looks good with the patch.

But I'd be very happy to have success reports from sysvinit users before
considering backporting this to buster.


Cheers,



Hello,

I use sysvinit. I've installed the 1.9.1-8 version of the package, and 
it seems to work properly for me. For reference, I did the following test:


1. Blank out /etc/apparmor.d/local/usr.sbin.haveged to remove my added line
2. /etc/init.d/haveged stop
3. aa-enforce /usr/sbin/haveged
4. /etc/init.d/haveged start  --  It failed to start (as expected)
5. Update to haveged=1.9.1-8
6. Verify haveged has started (the post install scripts take care of 
apparmor and starting the process)

7. Verify /etc/apparmor.d/local/usr.sbin.haveged is still blank
8. Reboot and verify haveged still starts up properly

Thanks for the quick turn around!

Justin Pasher

Bug#931975: dpkg-checkbuilddeps don't allow multiple Vcs-Git statements

[Sean Whitton]

Hello,

On Sun 14 Jul 2019 at 03:03PM -07, Russ Allbery wrote:

> In that case, should we increase the strength of this by changing the
> first sentence?  I'm not seeing much purpose served by developer
> discretion here, and this clarifies matters for tool developers.
>
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 81b3542..8124d64 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -979,7 +979,10 @@ repository where the Debian source package is developed.
>  or ``hg clone`` command. If no branch is specified, the packaging
>  should be on the default branch.
>
> -More than one different VCS may be specified for the same package.
> +A package control file must not have more than one ``Vcs-``
> +field.  If the package is maintained in multple version control
> +systems, the maintainer should specify the one that they would prefer
> +other people to use as the basis for proposing changes to the package.
>
>  For both fields, any URLs given should use a scheme that provides
>  confidentiality (``https``, for example, rather than ``http`` or ``git``)

Seconded.

Thanks, Guillem, for the research!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#931975: dpkg-checkbuilddeps don't allow multiple Vcs-Git statements

[Sean Whitton]

Hello,

On Sun 14 Jul 2019 at 11:19AM -07, Russ Allbery wrote:

> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 81b3542..fb2b6e5 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -979,7 +979,8 @@ repository where the Debian source package is developed.
>  or ``hg clone`` command. If no branch is specified, the packaging
>  should be on the default branch.
>
> -More than one different VCS may be specified for the same package.
> +More than one ``Vcs-`` field may be specified for the same
> +package, but only if the  parameters are all unique.
>
>  For both fields, any URLs given should use a scheme that provides
>  confidentiality (``https``, for example, rather than ``http`` or ``git``)
>
> I think one could argue that the above change is informative, given that
> Policy already says "A paragraph must not contain more than one instance
> of a particular field name" in Policy 5.1.

I concur and so I've gone ahead and committed it to master.

We can continue to discuss the more substantial change proposal in this
bug.  I didn't mark this informative change as resolving the bug.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#932121: btrbk: please drop Depends on btrfs-tools

[Axel Burri]

Thanks, I have removed the "Depends: | btrfs-tools" in the
btrbk-packaging repository, this change will be included in the next
btrbk release:

https://github.com/digint/btrbk-packaging/commit/35973a03cb1da89998ca4b99d7b6010ed1e00612

Will close the bug on the next release.

On 15/07/2019 15.11, Adam Borowski wrote:
> Package: btrbk
> Version: 0.28.2-1
> Severity: minor
> 
> Hi!
> Your package still Depends: | btrfs-tools; that package has been dropped
> long ago.  It's time to purge references to it.
> 
> As it's only an alternative Dep to the current name (btrfs-progs), I'm filing
> as sev:minor as it's only a cosmetic issue.  It makes the old name still pop 
> up
> in searches, thus it'd be nice to get rid of it, though.
> 
> 
> Meow!
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
> (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.2.1-00036-gf2c1d208af28 (SMP w/64 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages btrbk depends on:
> ii  btrfs-progs [btrfs-tools]  5.2-1
> ii  perl   5.28.1-6
> 
> Versions of packages btrbk recommends:
> ii  mbuffer 20190127+ds1-1
> ii  openssh-client  1:8.0p1-3
> ii  pv  1.6.6-1
> 
> Versions of packages btrbk suggests:
> ii  openssl  1.1.1c-1
> ii  python3  3.7.3-1
> 
> -- no debconf information
> 

Bug#932134: libossim1: Segmentation fault in ossimTiffProjectionFactory

[Guillaume Pasero]

Package: libossim1
Version: 2.7.2-1
Severity: important

Dear Maintainer,

I am using libossim1 through Orfeo ToolBox and I noticed a crash when upgrading 
Ossim from 2.6.2 to 2.7.2.

There is a segmentation fault when using the 
ossimImageHandler::getImageGeometry() on a TIFF file.

The steps to reproduce are: 

  * Get a docker image ready to build OTB : 
registry.orfeo-toolbox.org/orfeotoolbox/otb-build-env/otb-debian-native:unstable
  * run the docker container as root
  * Upgrade Ossim to 2.7.2
  * make sure LFS is installed: git lfs install
  * clone OTB sources (develop branch) : git clone 
https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb
  * in OTB sources, run : ctest -VV -S CI/main_ci.cmake 
-DIMAGE_NAME=debian-unstable-gcc
  * after the test fails you can re-run a test manually, for instance: ctest 
-VV -R ioTvMultiResolutionReadingInfo_TIFF

Here is a backtrace I got on this test:

(gdb) r
Starting program: /opt/build/bin/otbImageIOTestDriver --compare-ascii 0.0 
/opt/src/Data/Baseline/OTB/Files/ioTvMultiResolutionReadingInfoOut_tiff.txt 
/opt/build/Testing/Temporary/ioTvMultiResolutionReadingInfoOut_tiff.txt 
otbMultiResolutionReadingInfo /opt/src/Data/Input/maur_rgb.tif 
/opt/build/Testing/Temporary/ioTvMultiResolutionReadingInfoOut_tiff.txt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
2019-07-15 16:09:05 (INFO): Default RAM limit for OTB is 256 MB
2019-07-15 16:09:05 (INFO): GDAL maximum cache size is 798 MB
2019-07-15 16:09:05 (INFO): OTB will use at most 4 threads

Program received signal SIGSEGV, Segmentation fault.
0x7658dbf7 in 
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() () from 
/usr/lib/libossim.so.1
(gdb) bt
#0  0x7658dbf7 in 
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() () from 
/usr/lib/libossim.so.1
#1  0x765332cf in ?? () from /usr/lib/libossim.so.1
#2  0x7fffda40 in ?? ()
#3  0x7fffd9c0 in ?? ()
#4  0x000c in ?? ()
#5  0x61665f656c616373 in ?? ()
#6  0x6700726f7463 in ?? ()
#7  0x5581ce70 in ?? ()
#8  0x167ef0d427ecc700 in ?? ()
#9  0x0016 in ?? ()
#10 0x557d8320 in ?? ()
#11 0x5581ce60 in ?? ()
#12 0x5581ce60 in ?? ()
#13 0x7fffdac0 in ?? ()
#14 0x7fffda40 in ?? ()
#15 0x5581ce70 in ?? ()
#16 0x76c1a9dc in 
ossimTiffProjectionFactory::createProjection(ossimImageHandler*) const () from 
/usr/lib/libossim.so.1
#17 0x76bc02a5 in 
ossimProjectionFactoryRegistry::createProjection(ossimImageHandler*) const () 
from /usr/lib/libossim.so.1
#18 0x768c7d7f in 
ossimImageGeometryFactory::extendGeometry(ossimImageHandler*) const () from 
/usr/lib/libossim.so.1
#19 0x768c8754 in 
ossimImageGeometryRegistry::extendGeometry(ossimImageHandler*) const () from 
/usr/lib/libossim.so.1
#20 0x768cc54b in ossimImageHandler::getImageGeometry() () from 
/usr/lib/libossim.so.1
#21 0x7759e7d2 in 
otb::ReadGeometryFromImage(std::__cxx11::basic_string, std::allocator > const&, bool) ()
   from /opt/build/lib/libOTBOSSIMAdapters-6.7.so.1
#22 0x77d07db2 in otb::ImageFileReader, 
otb::DefaultConvertPixelTraits >::GenerateOutputInformation() ()
   from /opt/build/lib/libOTBImageIO-6.7.so.1
#23 0x756e5c9d in itk::ProcessObject::UpdateOutputInformation() () from 
/usr/lib/libITKCommon-4.12.so.1
#24 0x55685472 in otbMultiResolutionReadingInfo(int, char**) ()
#25 0x555d39d3 in main ()


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

Kernel: Linux 3.13.0-170-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libossim1 depends on:
ii  libc62.28-10
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:9.1.0-8
ii  libgeos-3.7.13.7.1-1
ii  libgeos-c1v5 3.7.1-1
ii  libgeotiff2  1.4.3-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3
ii  libstdc++6   9.1.0-8
ii  libtiff5 4.0.10-4
ii  zlib1g   1:1.2.11.dfsg-1

libossim1 recommends no packages.

libossim1 suggests no packages.

-- no debconf information

Bug#932135: puppetdb can't create/upgrade its DB schema past version 65 with postgres-11 11.4-1

[Gabriel Filion]

Package: puppetdb
Version: 6.2.0-3
Severity: grave
Justification: renders package unusable

Hi there!

I've hit a bug with a new installation of puppetdb on buster (e.g. I've
re-created my puppetmaster vagrant box) where puppetdb would fail to start,
erroring out on an SQL upgrade of the database schema during the first service
start.

I'll include the error log lower down since it's pretty long.

I've found a bug report on pupperware (puppet packaged up in docker containers)
that describes exactly the same problem, identifies a faulty postgresql 9.6.x
version and seems to point to an upstream bug report that contains a fix.

https://github.com/puppetlabs/pupperware/issues/82

Since in buster we're using postgresql-11, we've had to identify which version
had introduced the problem. I'm not sure about the exact minor version of
postgres, but for certain when downgrading the debian package to postgres-11
version 11.3-1, then puppetdb is able to start and complete its schema upgrade.
So the bug must have been introduced somewhere between 11.3 and 11.4

The upstream bug report says that there might be a fix for puppetdb available:

https://tickets.puppetlabs.com/browse/PDB-4422

It might be interesting to test applying the fix from the most appropriate
branch (I'm not sure whether 6.0 or 6.3 makes more sense) and then test a new
install with postgresql-11 version 11.4-1 to see if it goes through the schema
upgrade successfully.

Here's the puppetdb log that shows the error happening during the first run of
a new puppetdb 6.2.0-3 install with postgresql-11 version 11.4-1:


--8<8<--
2019-07-15T05:11:14.759-04:00 INFO  [p.p.c.services] PuppetDB version 6.2.0
2019-07-15T05:11:14.760-04:00 WARN  [c.z.h.HikariConfig] The 
initializationFailFast propery is deprecated, see initializationFailTimeout
2019-07-15T05:11:14.761-04:00 INFO  [c.z.h.HikariDataSource] PDBMigrationsPool 
- Starting...
2019-07-15T05:11:14.763-04:00 INFO  [c.z.h.HikariDataSource] PDBMigrationsPool 
- Start completed.
2019-07-15T05:11:15.098-04:00 INFO  [p.p.s.migrate] Applying database migration 
version 28
2019-07-15T05:11:15.564-04:00 INFO  [p.p.s.migrate] Applied database migration 
version 28 in 465 ms
2019-07-15T05:11:15.564-04:00 INFO  [p.p.s.migrate] Applying database migration 
version 29
2019-07-15T05:11:15.865-04:00 INFO  [p.p.s.migrate] Applied database migration 
version 29 in 301 ms
2019-07-15T05:11:15.865-04:00 INFO  [p.p.s.migrate] Applying database migration 
version 30
2019-07-15T05:11:15.870-04:00 INFO  [p.p.s.migrate] Applied database migration 
version 30 in 5 ms
2019-07-15T05:11:15.870-04:00 INFO  [p.p.s.migrate] Applying database migration 
version 31
2019-07-15T05:11:15.897-04:00 INFO  [p.p.s.migrate] Applied database migration 
version 31 in 26 ms
2019-07-15T05:11:15.897-04:00 INFO  [p.p.s.migrate] Applying database migration 
version 32
2019-07-15T05:11:15.916-04:00 INFO  [p.p.s.migrate] Applied database migration 
version 32 in 19 ms
2019-07-15T05:11:15.917-04:00 INFO  [p.p.s.migrate] Applying database migration 
version 33
2019-07-15T05:11:15.940-04:00 INFO  [p.p.s.migrate] Applied database migration 
version 33 in 23 ms
2019-07-15T05:11:15.940-04:00 INFO  [p.p.s.migrate] Applying database migration 
version 34
2019-07-15T05:11:15.992-04:00 INFO  [p.p.s.migrate] Applied database migration 
version 34 in 52 ms
2019-07-15T05:11:15.992-04:00 INFO  [p.p.s.migrate] Applying database migration 
version 35
2019-07-15T05:11:15.993-04:00 INFO  [p.p.s.migrate] Applied database migration 
version 35 in 1 ms
2019-07-15T05:11:15.993-04:00 INFO  [p.p.s.migrate] Applying database migration 
version 36
2019-07-15T05:11:15.995-04:00 INFO  [p.p.s.migrate] Applied database migration 
version 36 in 2 ms
2019-07-15T05:11:15.995-04:00 INFO  [p.p.s.migrate] Applying database migration 
version 37
2019-07-15T05:11:15.997-04:00 INFO  [p.p.s.migrate] Applied database migration 
version 37 in 2 ms
2019-07-15T05:11:15.997-04:00 INFO  [p.p.s.migrate] Applying database migration 
version 38
2019-07-15T05:11:15.999-04:00 INFO  [p.p.s.migrate] Applied database migration 
version 38 in 1 ms
2019-07-15T05:11:15.999-04:00 INFO  [p.p.s.migrate] Applying database migration 
version 39
2019-07-15T05:11:16.055-04:00 INFO  [p.p.s.migrate] Applied database migration 
version 39 in 56 ms
2019-07-15T05:11:16.056-04:00 INFO  [p.p.s.migrate] Applying database migration 
version 40
2019-07-15T05:11:16.096-04:00 INFO  [p.p.s.migrate] Applied database migration 
version 40 in 40 ms
2019-07-15T05:11:16.097-04:00 INFO  [p.p.s.migrate] Applying database migration 
version 41
2019-07-15T05:11:16.099-04:00 INFO  [p.p.s.migrate] Applied database migration 
version 41 in 3 ms
2019-07-15T05:11:16.100-04:00 INFO  [p.p.s.migrate] Applying database migration 
version 42
2019-07-15T05:11:16.192-04:00 INFO  [p.p.s.migrate] Applied database migration 
version 42 in 92 ms
2019-07-15T05:11:16.192-04:00 INFO  

Bug#932133: sandsifter: FTBFS on i386

[Jiri Palecek]

Package: sandsifter
Version: 1.03-2
Severity: important
Tags: patch

Dear Maintainer,

sandsifter fails to build from source on i386 [1]. It is caused by a
rather naive asm code in the injector, which IIUC (don't take me at my
word) tries to use relocation which simply isn't there for the 8th
argument (the new stack). However, I've written a different assembly
routine, which, albeit not beingthe greatest assembler ever written,
gets the job done reliably (and should compile even with pie).

Please consider including this patch.

Regards
Jiri Palecek

Index: sandsifter-1.03/injector.c
===
--- sandsifter-1.03.orig/injector.c
+++ sandsifter-1.03/injector.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 

 /* configuration */

@@ -814,28 +815,31 @@ void inject(int insn_size)
 			  [packet]"m"(packet)
 			);
 #else
+	dummy_stack.dummy_stack_lo[0] = (uint64_t)packet;
 	__asm__ __volatile__ ("\
-			mov %[eax], %%eax \n\
-			mov %[ebx], %%ebx \n\
-			mov %[ecx], %%ecx \n\
-			mov %[edx], %%edx \n\
-			mov %[esi], %%esi \n\
-			mov %[edi], %%edi \n\
-			mov %[ebp], %%ebp \n\
-			mov %[esp], %%esp \n\
-			jmp *%[packet]\n\
+			mov %[dummy_stack], %%esp \n\
+			mov %[inject_state], %%ebp\n\
+			mov %c[eax](%%ebp), %%eax \n\
+			mov %c[ebx](%%ebp), %%ebx \n\
+			mov %c[ecx](%%ebp), %%ecx \n\
+			mov %c[edx](%%ebp), %%edx \n\
+			mov %c[esi](%%ebp), %%esi \n\
+			mov %c[edi](%%ebp), %%edi \n\
+			mov %c[ebp](%%ebp), %%ebp \n\
+			ret\n\
 			"
 			:
 			:
-			[eax]"m"(inject_state.eax),
-			[ebx]"m"(inject_state.ebx),
-			[ecx]"m"(inject_state.ecx),
-			[edx]"m"(inject_state.edx),
-			[esi]"m"(inject_state.esi),
-			[edi]"m"(inject_state.edi),
-			[ebp]"m"(inject_state.ebp),
-			[esp]"i"(_stack.dummy_stack_lo),
-			[packet]"m"(packet)
+			[inject_state]"r"(_state),
+			[eax]"i"(offsetof(state_t, eax)),
+			[ebx]"i"(offsetof(state_t, ebx)),
+			[ecx]"i"(offsetof(state_t, ecx)),
+			[edx]"i"(offsetof(state_t, edx)),
+			[esi]"i"(offsetof(state_t, esi)),
+			[edi]"i"(offsetof(state_t, edi)),
+			[ebp]"i"(offsetof(state_t, ebp)),
+			[dummy_stack]"r"(_stack.dummy_stack_lo),
+			[st_offset]"i"(offsetof(typeof(dummy_stack), dummy_stack_lo))
 			);
 #endif


1: 
https://buildd.debian.org/status/fetch.php?pkg=sandsifter=i386=1.03-2=1547570894=0

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 5.1.0-rc4-bughunt+ (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ 
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sandsifter depends on:
ii  libc62.28-10
ii  libcapstone3 4.0.1+really+3.0.5-1
ii  python   2.7.16-1
ii  python-capstone  4.0.1+really+3.0.5-1

Versions of packages sandsifter recommends:
ii  binutils  2.32.51.20190707-1
pn  nasm  

sandsifter suggests no packages.

-- no debconf information

Bug#932132: libkrb5-3: Don't require all enctypes in a keytab to be valid

[rharwood]

Package: libkrb5-3
Version: 1.17-4
Severity: normal
Tags: patch upstream

Hi Sam, Ben, Russ,

I really appreciate your assistance in backporting the 1DES-removal patchset.
I wanted to make sure you were aware of [1]: this fixes a bug where having an
invalid enctype in a keytab would cause credential acquisition from the keytab
to fail.  This becomes a problem because the 1DES enctypes are considered
"invalid" after their removal.

Hopefully this doesn't actually affect anyone.  (I only found it because I
removed 3DES as well in Fedora, which seems to be more common.)

Thanks,
--Robbie

1: 
https://github.com/krb5/krb5/pull/952/commits/38be1a0a31a6104cdf8c8d72828905775f6d6636

Bug#926753: fonts-noto-cjk: New version available upstream

[Gunnar Hjalmarsson]

We have upgraded to 2.001 in Ubuntu, also in the released Ubuntu 19.04 
and Ubuntu 18.04 LTS. I simply put together a new 'upstream' tarball 
named "fonts-noto-cjk_20190409+repack1.orig.tar.xz".


https://launchpad.net/ubuntu/+source/fonts-noto-cjk/1:20190409+repack1-0ubuntu1

I think it can be used by Debian too to save time.

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#932131: vlc: CVE-2019-13602

[Salvatore Bonaccorso]

Source: vlc
Version: 3.0.7.1-1
Severity: important
Tags: security upstream
Control: found -1 3.0.7-1
Control: found -1 3.0.7-0+deb9u1

Hi,

The following vulnerability was published for vlc.

CVE-2019-13602[0]:
| An Integer Underflow in MP4_EIA608_Convert() in
| modules/demux/mp4/mp4.c in VideoLAN VLC media player through 3.0.7.1
| allows remote attackers to cause a denial of service (heap-based
| buffer overflow and crash) or possibly have unspecified other impact
| via a crafted .mp4 file.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-13602
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13602

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#932068: Fwd: Bug#932068: rsyslog FTCBFS: uses mysql_config

[Rainer Gerhards]

looks like it doesn't work out... pls have a look at CI.

Thx,
Rainer

El lun., 15 jul. 2019 a las 18:36, Rainer Gerhards
() escribió:
>
> ah, it was all there, so I applied the patch and created a PR:
>
> https://github.com/rsyslog/rsyslog/pull/3747
>
> Let's see how it goes.
>
> Rainer
>
> El lun., 15 jul. 2019 a las 18:05, Rainer Gerhards
> () escribió:
> >
> > Hi all,
> >
> > thanks for your help! I'll give it a try, but please bear with me a
> > little bit. Hope to get to it this week (if all goes well tomorrow).
> >
> > Rainer
> >
> > El dom., 14 jul. 2019 a las 21:46, Helmut Grohne () 
> > escribió:
> > >
> > > Hi Michael,
> > >
> > > On Sun, Jul 14, 2019 at 09:10:45PM +0200, Michael Biebl wrote:
> > > > can you have a look at this?
> > > > I'd rather not ship this as a downstream patch.
> > >
> > > I tried to write the patch in an upstreamable way. I think that it
> > > should help other cross distributions as well. For instance, yocto
> > > carries
> > > http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/rsyslog/rsyslog/use-pkgconfig-to-check-libgcrypt.patch?h=master
> > > for avoiding libgcrypt-config. This patch could also be upstreamed by
> > > trying pkg-config before libgcrypt-config. ptxdist simply disabled mysql
> > > integration.
> > >
> > > > @Helmut: Is that mysqlclient.pc file provided via a Debian specific 
> > > > patch?
> > >
> > > Prior to the mariadb fork, the standard mysql client library provided
> > > this .pc file. As far as I understand, it is now provided by mariadb as
> > > a compatibility symlink much in the same way as it provides mysql_config
> > > as a compatibility symlink. I think it is pretty safe to assume its
> > > presence, but we can extend the patch to explicitly check for mariadb.pc
> > > if that is preferred. I don't expect mysqlclient.pc (or mysql_config) to
> > > go away anytime soon due to its widespread usage.
> > >
> > > Helmut
>

Bug#931710: [pkg-cryptsetup-devel] Bug#931710: Cryptroot-unlock Timeout on askpass

[Guilhem Moulin]

Control: retitle -1 `cryptroot-unlock` timeouts when Kali's 
cryptsetup-nuke-password package is installed

On Mon, 15 Jul 2019 at 07:05:46 +, Luke Flinders wrote:
> This is the package;
> https://gitlab.com/kalilinux/packages/cryptsetup-nuke-keys

Oh, didn't you mean
https://gitlab.com/kalilinux/packages/cryptsetup-nuke-password ?

AFAICT that package replaces /lib/cryptsetup/askpass with a script that calls
the original ‘askpass’ binary (renamed to /lib/cryptsetup/askpass.cryptsetup),
and erases the LUKS header if its digest value matches a special “nuke” hash;
otherwise the passphrase is forwarded to the ‘cryptsetup’ binary.


https://gitlab.com/kalilinux/packages/cryptsetup-nuke-password/blob/kali/master/askpass

(FWIW the script won't work with binary keyfiles dumped to the passfifo,
because the passphrase is held by a shell variable.  It'll also break if
the value ends with a linefeed ‘\n’ character.)

‘cryptroot-unlock’ timeouts waiting for a running /lib/cryptsetup/askpass
process with a file descriptor opened to the passfifo, because our
askpass binary was renamed to /lib/cryptsetup/askpass.cryptsetup.  I
don't see how that could have ever worked with ‘cryptroot-unlock’ (but
the diversion might have been new in Kali's ‘cryptsetup-nuke-password’).

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#932068: Fwd: Bug#932068: rsyslog FTCBFS: uses mysql_config

[Rainer Gerhards]

ah, it was all there, so I applied the patch and created a PR:

https://github.com/rsyslog/rsyslog/pull/3747

Let's see how it goes.

Rainer

El lun., 15 jul. 2019 a las 18:05, Rainer Gerhards
() escribió:
>
> Hi all,
>
> thanks for your help! I'll give it a try, but please bear with me a
> little bit. Hope to get to it this week (if all goes well tomorrow).
>
> Rainer
>
> El dom., 14 jul. 2019 a las 21:46, Helmut Grohne () 
> escribió:
> >
> > Hi Michael,
> >
> > On Sun, Jul 14, 2019 at 09:10:45PM +0200, Michael Biebl wrote:
> > > can you have a look at this?
> > > I'd rather not ship this as a downstream patch.
> >
> > I tried to write the patch in an upstreamable way. I think that it
> > should help other cross distributions as well. For instance, yocto
> > carries
> > http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/rsyslog/rsyslog/use-pkgconfig-to-check-libgcrypt.patch?h=master
> > for avoiding libgcrypt-config. This patch could also be upstreamed by
> > trying pkg-config before libgcrypt-config. ptxdist simply disabled mysql
> > integration.
> >
> > > @Helmut: Is that mysqlclient.pc file provided via a Debian specific patch?
> >
> > Prior to the mariadb fork, the standard mysql client library provided
> > this .pc file. As far as I understand, it is now provided by mariadb as
> > a compatibility symlink much in the same way as it provides mysql_config
> > as a compatibility symlink. I think it is pretty safe to assume its
> > presence, but we can extend the patch to explicitly check for mariadb.pc
> > if that is preferred. I don't expect mysqlclient.pc (or mysql_config) to
> > go away anytime soon due to its widespread usage.
> >
> > Helmut

Bug#932123: nullmailer-send does not work as /var/spool/nullmailer/trigger is missing

[David Bremner]

Alejandro Suarez  writes:

Control: severity -1 normal

> Package: nullmailer
> Version: 1:2.2-3
> Severity: grave
> Tags: patch
> Justification: renders package unusable

I'm using the package on about 10 systemd based machines, so I think
there is something else going on here. I'm dropping the severity for
now, until I can understand what the problem you are encountering is.

d

Bug#931710: [pkg-cryptsetup-devel] Bug#931710: Cryptroot-unlock Timeout on askpass

[Guilhem Moulin]

On Mon, 15 Jul 2019 at 07:05:46 +, Luke Flinders wrote:
> seen as this is not a Debian related package causing the issue, I am
> happy if you want to close.

I can still help with the debugging :-)  AFAICT the “Error: Timeout
reached while waiting for askpass.” condition is reached iff. the script
didn't find a running ‘/lib/cryptsetup/askpass’ process with a file
descriptor opened to ‘/lib/cryptsetup/passfifo’ (it'll keep trying for
10s then give up with that error message).

The ‘cryptsetup’ binary is out of the picture at that point, so I fail
to see how the ‘cryptsetup-nuke-keys’ patch from Kali can have any
effect here.  You should even get passed the timeout if you run askpass
standalone, for instance as `/lib/cryptsetup/askpass foo`.

Did you try to enable xtrace for ‘cryptroot-unlock’, like I suggested in
Message #28, like I suggested in https://bugs.debian.org/931710#28 ?
Might help figuring out what's going on.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#931854: liblopsub: please make the output of lopsubgen reproducible

[Andre Noll]

On Sun, Jul 14, 14:56, Adam Borowski wrote
> On Sun, Jul 14, 2019 at 12:28:33PM +0200, Andre Noll wrote:
> > On Sat, Jul 13, 22:48, Adam Borowski wrote
> > > I would gladly upload your updates, but I don't know what upstream tarball
> > > to use.  There's no watch file (the usual automated way to fetch one), you
> > > did not provide one by uploading to mentors.d.n or some site of your own,
> > > and neither did you provide instructions for some custom workflow (there 
> > > are
> > > many of those).
> 
> > git fetch
> > git archive --prefix liblopsub-1.0.3/ origin/master | xz > 
> > ../liblopsub_1.0.3.orig.tar.xz
> 
> This looks like the "git" mode of uscan; I haven't used it though as the
> vast majority of my upstreams use github or something similar that offers
> downloadable tarballs for tags.

We also have a gitweb instance which has the same contents as the
public git repos:

http://git.tuebingen.mpg.de/

The snapshot links of each project lets you download the tarball of
any commit. For example

wget -O liblopsub_1.0.3.orig.tar.gz 
'http://git.tuebingen.mpg.de/?p=lopsub.git;a=snapshot;h=master;sf=tgz'

However, you still need to specify the name of the output file, and
the tarball will extract into a directory named lopsub-master-$SHA1,
which is probably not optimal.

> > I could certainly create the tarball and upload it somewhere for the
> > tools to to pick up, but TBH I think that's a bit pointless because
> > everybody can create the tarball from the public git repo with a
> > command like the above.
> 
> Yeah, but there's no commonly agreed way to do that.  Or rather, there's
> _too many_ ways, with none being dominant.  And generating a bit-to-bit
> identical tarball is not as easy as it sounds.

Right. I don't know if git archive creates identical tarballs when
run from two different repos that share the same commit. The man page
does not mention anything about this.

> > My preferred choice would be to create a signed tag each time the
> > version number in debian/changelog changes, to indicate that a new
> > version should be uploaded, but I have no strong opinion in this
> > regard.
> 
> That's a common and recommended workflow, although when the package can't be
> uploaded immediately (eg. NEW or sponsoring), I'd recommend leaving not
> pushing the tag until the upload is done.  Thus, a finalized changelog
> version serves that purpose, yet is not immutable.
> 
> > Which mechanism do you prefer to get informed about pending updates?
> 
> Anything that's convenient for you; in general RFS bugs are best but some
> folks prefer other arrangements.

OK, then lets continue to use email for this. I'll always include a
suitable git archive command in the future.

Thanks
Andre
-- 
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/


signature.asc
Description: PGP signature

Bug#932068: Fwd: Bug#932068: rsyslog FTCBFS: uses mysql_config

[Rainer Gerhards]

Hi all,

thanks for your help! I'll give it a try, but please bear with me a
little bit. Hope to get to it this week (if all goes well tomorrow).

Rainer

El dom., 14 jul. 2019 a las 21:46, Helmut Grohne () escribió:
>
> Hi Michael,
>
> On Sun, Jul 14, 2019 at 09:10:45PM +0200, Michael Biebl wrote:
> > can you have a look at this?
> > I'd rather not ship this as a downstream patch.
>
> I tried to write the patch in an upstreamable way. I think that it
> should help other cross distributions as well. For instance, yocto
> carries
> http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/rsyslog/rsyslog/use-pkgconfig-to-check-libgcrypt.patch?h=master
> for avoiding libgcrypt-config. This patch could also be upstreamed by
> trying pkg-config before libgcrypt-config. ptxdist simply disabled mysql
> integration.
>
> > @Helmut: Is that mysqlclient.pc file provided via a Debian specific patch?
>
> Prior to the mariadb fork, the standard mysql client library provided
> this .pc file. As far as I understand, it is now provided by mariadb as
> a compatibility symlink much in the same way as it provides mysql_config
> as a compatibility symlink. I think it is pretty safe to assume its
> presence, but we can extend the patch to explicitly check for mariadb.pc
> if that is preferred. I don't expect mysqlclient.pc (or mysql_config) to
> go away anytime soon due to its widespread usage.
>
> Helmut

Bug#929786: origtargz does not download multiple tarballs

[Pirate Praveen]

On Fri, 31 May 2019 16:25:17 +0500 Pirate Praveen
 wrote:
> 
> 
> On Fri, May 31, 2019 at 3:12 PM, Mattia Rizzolo  
> wrote:
> > user devscri...@packages.debian.org
> > usertags 929786 origtargz
> > tags 929786 moreinfo
> > quit
> > 
> > On Thu, May 30, 2019 at 08:26:27PM +0500, Pirate Praveen wrote:
> >>  pravi@nishumbha:~/forge/debian/git/js-team/node-vinyl-fs$ origtargz
> >>  pristine-tar: successfully generated 
> >> ../node-vinyl-fs_3.0.3.orig.tar.gz
> >> 
> >>  But it failed to download multiple tarballs from archive. You can 
> >> use
> >>  https://salsa.debian.org/js-team/node-vinyl-fs to reproduce this 
> >> issue.
> > 
> > Honestly, I don't think there is any sane way for `origtargz` to 
> > fiugre
> > that it needs to download/produce/build more than one orig tarball, 
> > from
> > inside the unpacked source.
> > 
> > That's an information that is available *only* from the .dsc, which is
> > not something `origtargz` has access to.  Anything else would truly be
> > guesswork.
> > 
> > 
> > Suggestions?
> > 
> If #577113 gets implemented, that will give a uniform way to get list 
> of components. But even now this information is available in 
> debian/gbp.conf for packages that use git-buildpackage. I think 
> origtargz should look in gbp.conf for components if the file is present.
> 
> When pristine-tar branch is missing it does apt source, I think the 
> same could be tried here also.

pristine-tar list will show all the tarballs when it is a git clone and
has pristine-tar branch.



signature.asc
Description: OpenPGP digital signature

Bug#731656: [Pkg-shadow-devel] Bug#731656: /etc/securetty used in buster systemd-containers

[Bálint Réczey]

Hi Arne,

arne  ezt írta (időpont: 2019. júl. 13., Szo, 15:09):
>
> I had to modify /etc/securetty in buster systemd-containers
> in order to be able to log in as root.
>
> systemd-container still uses this file.
>
> I added
>
> # systemd containers
> pts/0
> pts/1
> pts/2
> pts/3
> pts/4
> pts/5
> pts/6
> pts/7
> pts/8
> pts/9
>
> to /etc/securetty in my containers

I followed https://wiki.debian.org/nspawn and could log in:

  153  sudo env http_proxy=http://10.84.73.1:8000 debootstrap buster
$CDIR-buster
  155  sudo systemd-nspawn -D $CDIR-buster  --machine FreedomBox-buster
  156  history
test@sid-vm-test:~$ sudo systemd-nspawn -D $CDIR-buster  --machine
FreedomBox-buster
Spawning container FreedomBox-buster on /var/lib/machines/freedombox-buster.
Press ^] three times within 1s to kill container.
root@FreedomBox-buster:~#

Buster is not fixed anyway.

Cheers,
Balint

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

Bug#931810: aeolus: segfault on startup

[Bernhard Übelacker]

Dear Maintainer,

> (On exit is another issue with the FILE structure
> in readline library, but saw it just on exit.)

I tried to follow why this crash on exit happens,
and found that this second issue is because aeolus
does a "fclose (stdin);" on purpose.

But libreadline is not prepared to that and raises this error.

Just removing that "fclose (stdin);" makes it
impossible to close aeolus.

Kind regards,
Bernhard



Aeolus> q
[Switching to Thread 0x76ea8700 (LWP 1514)]

Thread 8 "aeolus" hit Hardware watchpoint 1: rl_instream->_fileno

Old value = 0
New value = -1
_IO_new_file_close_it (fp=fp@entry=0x7751da00 <_IO_2_1_stdin_>) at 
fileops.c:161
161 fileops.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  _IO_new_file_close_it (fp=fp@entry=0x7751da00 <_IO_2_1_stdin_>) at 
fileops.c:161
#1  0x773d190f in _IO_new_fclose (fp=0x7751da00 <_IO_2_1_stdin_>) 
at iofclose.c:53
#2  0x77fcb642 in Tiface::handle_ifc_txtip (this=0x5563d7a0, 
M=) at tiface.cc:248
#3  0x77fcb728 in Tiface::handle_mesg (this=, 
M=0x7fffdc09f610) at tiface.cc:163
#4  0x77fcb7aa in Tiface::thr_main (this=0x5563d7a0) at 
/usr/include/clthreads.h:492
#5  0x77bb6a3a in P_thread_entry_point (arg=) at 
p_thread.cc:38
#6  0x77852fa3 in start_thread (arg=) at 
pthread_create.c:486
#7  0x7745b4cf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) cont
Continuing.
Aeolus> *** buffer overflow detected ***: /usr/bin/aeolus terminated

Thread 9 "aeolus" received signal SIGABRT, Aborted.
[Switching to Thread 0x76e58700 (LWP 1515)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50return ret;
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x77384535 in __GI_abort () at abort.c:79
#2  0x773db508 in __libc_message (action=, 
fmt=fmt@entry=0x774e607b "*** %s ***: %s terminated\n") at 
../sysdeps/posix/libc_fatal.c:181
#3  0x7746c80d in __GI___fortify_fail_abort 
(need_backtrace=need_backtrace@entry=true, msg=msg@entry=0x774e5ff8 "buffer 
overflow detected") at fortify_fail.c:28
#4  0x7746c841 in __GI___fortify_fail (msg=msg@entry=0x774e5ff8 
"buffer overflow detected") at fortify_fail.c:44
#5  0x7746a940 in __GI___chk_fail () at chk_fail.c:28
#6  0x7746c737 in __fdelt_chk (d=) at fdelt_chk.c:25
#7  0x770cdd67 in rl_getc (stream=0x7751da00 <_IO_2_1_stdin_>) at 
./input.c:518
#8  0x770ce61e in rl_read_key () at ./input.c:483
#9  0x770b64f5 in readline_internal_char () at ./readline.c:570
#10 0x770b6cd5 in readline_internal_charloop () at ./readline.c:656
#11 readline_internal () at ./readline.c:670
#12 readline (prompt=prompt@entry=0x77fcc01e "Aeolus> ") at ./readline.c:376
#13 0x77fc95ac in Reader::thr_main (this=0x5563db98) at tiface.cc:64
#14 0x77bb6a3a in P_thread_entry_point (arg=) at 
p_thread.cc:38
#15 0x77852fa3 in start_thread (arg=) at 
pthread_create.c:486
#16 0x7745b4cf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bug#932130: ODP: Bug#932130: Package: Debian-installer

[Steve McIntyre]

[ Responding to the bug# too so other people can see the information ]

Thanks!

On Mon, Jul 15, 2019 at 05:34:32PM +0200, Mmobilea wrote:
>I have lenovo thinkpad t410 laptop.
>
>Processor: Intel core i5 520M 2,4GHZ, 4GB RAM, Disk ssd sandisk 120GB,
>soundcard conexant cx20585
>
> 
>
>Wysłane z aplikacji Poczta dla Windows 10
>
> 
>
>Od: Steve McIntyre
>Wysłano: poniedziałek, 15 lipca 2019 17:21
>Do: Mmobilea a; 932...@bugs.debian.org
>Temat: Re: Bug#932130: Package: Debian-installer
>
> 
>
>On Mon, Jul 15, 2019 at 05:07:59PM +0200, Mmobilea a wrote:
>
>>Package: Debian-installer
>
>>Version: 20190702
>
>>Severity: high
>
>>I tried to install debian buster, from the accessibility mode, and it shows
>"No
>
>>sound card detected." I add, that in stretch all works fine.
>
> 
>
>Hi!
>
> 
>
>We're trying to track down what's causing this bug, as a few people
>
>have seen things like this. Can I ask what computer you have, please?
>
> 
>
>--
>
>Steve McIntyre, Cambridge, UK.    st...@einval.com
>
>Can't keep my eyes from the circling sky,
>
>Tongue-tied & twisted, Just an earth-bound misfit, I...
>
> 
>
> 
>
-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me 

Bug#932127: grub-common: Fails loading snapshot after snapper rollback

[Steve McIntyre]

On Mon, Jul 15, 2019 at 04:58:06PM +0200, Thomas Schneider wrote:
>Package: grub-common
>Version: 2.04-1
>Severity: important
>
>-- Detailed issue description
>After finalizing Debian installation I installed additional packages to make
>usage of Btrfs' snapshot functionality:
>- btrfs-progs
>- snapper
>
>Then I started installation of package "reportbug":
>apt install reportbug
>
>Snapper automatically created a snapshot pre and post the installation. This
>is exactly what is expected.
>
>Then I initiated rollback of this installation:
>snapper rollback 3
>(where 3 represents the snapshot ID of the pre snapshot).
>
>This created another 2 snapshots with ID 5 and 6; snapshot 6 becomes the new
>default snapshot then.
>To verify the new default snapshot I use this syntax: btrfs su get-default /
>and this correctly returns this:
>ID 272 gen 3658 top level 261 patch @snapshots/6/snapshot
>
>This is the time to reboot the system.
>
>However, when system is back from reboot the package "reportbug" is still
>installed; I verified this simply by entering this: apt-cache policy r
>eportbug
>
>Please check attached screenshots documenting these steps and the current
>Grub menu commands.

Hi Thomas,

Could you please explain why you think this is a problem in the Grub
packages? You've created a snapshot, but not configured Grub to use
it. If snapper is meant to make this work automatically, then it
sounds like there is missing functionality in snapper?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back

Bug#545174: insserv: Please add simple "if" conditionals to disable scripts

[Thorsten Glaser]

On Mon, 15 Jul 2019, Dmitry Bogatov wrote:

> Checking this condition /inside/ initscript has neglectable cost (like
> several /bin/sh processes) and gives you flexibility to check for
> conditions of arbitrary complexity.

And will work when running /etc/init.d/foo restart manually.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#932130: Package: Debian-installer

[Steve McIntyre]

On Mon, Jul 15, 2019 at 05:07:59PM +0200, Mmobilea a wrote:
>Package: Debian-installer
>Version: 20190702
>Severity: high
>I tried to install debian buster, from the accessibility mode, and it shows "No
>sound card detected." I add, that in stretch all works fine.

Hi!

We're trying to track down what's causing this bug, as a few people
have seen things like this. Can I ask what computer you have, please?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Bug#932129: postfix upgrade to 3.1.12 added garbage to dynamicmaps.cf and broke postfix

[Jonas Arndt]

Package: postfix
Version: 3.1.12-0+deb9u1

During the upgrade process garbage was added to 
/etc/postfix/dynamicmaps.cf, which prevented postfix from running.

Here is the important stuff from /var/log/apt/term.log


Setting up postfix-sqlite (3.1.12-0+deb9u1) ...
Adding sqlite map entry to /etc/postfix/dynamicmaps.cf
Processing triggers for rsyslog (8.24.0-1) ...
Setting up libdbus-1-3:amd64 (1.10.28-0+deb9u1) ...
Setting up postfix (3.1.12-0+deb9u1) ...


What went into the /etc/postfix/dynamicmaps.cf file after was the 
following (I don't know what that file looked like before)


===
ldap    /usr/lib/postfix/dict_ldap.so   dict_ldap_open lmdb 
postfix-lmdb.so dict_lmdb_open  mkmap_lmdb_open

sqlite  postfix-sqlite.so   dict_sqlite_open
===

It seems like the ldap line is the problem commenting that out addresses 
this. The postfix package also ended up in a "configuration failed" type 
of state


===
host:/etc$ dpkg -l | grep postfix
iF  postfix    3.1.12-0+deb9u1 amd64    
High-performance mail transport agent

host:/etc$ sudo dpkg-reconfigure postfix
/usr/sbin/dpkg-reconfigure: postfix is broken or not fully installed
===

Not great...

// Jonas

Bug#731656: shadow: pam_unix requires securetty

[Bálint Réczey]

Hi,

 ezt írta (időpont: 2019. júl. 15., H, 15:24):
>
> Package: login
> Version: 1:4.7-1
> Followup-For: Bug #731656
>
> Dear Maintainer,
>
> Today i installed a newer version of login on my debian bullseye. After 
> instalation
> i noticed a error message in /var/log/auth.log stating that pam_unix.so 
> cannot find
> file /etc/securetty. I think this is relevant to this package in some way, 
> because
> this bug report started the removal of file /etc/securetty. Also the code of 
> pam_unix.so
> should be modified to not expect existence of /etc/securetty. Currently im 
> not sure
> how this may affect the pam_unix.so module and services using it.

The complaint is tracked at the pam package:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674857#25

Thanks,
Balint

>
> Thank you
>
> Have a nice day
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
> Kernel taint flags: TAINT_CRAP
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages login depends on:
> ii  libaudit1   1:2.8.4-3
> ii  libc6   2.28-10
> ii  libpam-modules  1.3.1-5
> ii  libpam-runtime  1.3.1-5
> ii  libpam0g1.3.1-5
>
> login recommends no packages.
>
> login suggests no packages.
>
> -- no debconf information
>

Bug#932130: Package: Debian-installer

[Mmobilea a]

Package: Debian-installer
Version: 20190702
Severity: high
I tried to install debian buster, from the accessibility mode, and it shows
"No sound card detected." I add, that in stretch all works fine.

Bug#932128: lintian: fails to identify that tea is using dh

[Lucas Nussbaum]

Package: lintian
Version: 2.15.0
Severity: normal

Hi,

$ lintian --no-cfg --color never -E -I -L "+=pedantic" -L "+=classification" 
--show-overrides tea_47.0.1-1.dsc
[...]
> C: tea source: debian-build-system other
> P: tea source: package-does-not-use-debhelper-or-cdbs
[...]

While the content of tea's debian/rules is:
-
#!/usr/bin/make -f

# Use Qt5
export QT_SELECT=qt5
# Reduce unneeded linked libraries
export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
# Use all hardening options
export DEB_BUILD_MAINT_OPTIONS = hardening=+all

%:
LC_ALL=C.UTF-8 dh $@ --buildsystem=qmake

override_dh_auto_configure:
LC_ALL=C.UTF-8 dh_auto_configure -O--buildsystem=qmake -- 
CONFIG+=usepoppler CONFIG+=usedjvu

override_dh_auto_install:
LC_ALL=C.UTF-8 $(MAKE) INSTALL_ROOT=$(CURDIR)/debian/tea install
-

Thanks!

Lucas

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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 lintian depends on:
ii  binutils   2.31.1-16
ii  bzip2  1.0.6-9.1
ii  diffstat   1.62-1
ii  dpkg   1.19.7
ii  dpkg-dev   1.19.7
ii  file   1:5.35-4
ii  gettext0.19.8.1-9
ii  gpg2.2.12-1
ii  intltool-debian0.35.0+20060710.5
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcapture-tiny-perl   0.48-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
pn  libdigest-sha-perl 
ii  libdpkg-perl   1.19.7
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libio-async-perl   0.72-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libpath-tiny-perl  0.108-1
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  libtry-tiny-perl   0.30-1
ii  liburi-perl1.76-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.76+repack-1
ii  man-db 2.8.5-2
ii  patchutils 0.3.4-2
ii  perl   5.28.1-6
ii  t1utils1.41-3
ii  xz-utils   5.2.4-1

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

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.55-1

-- no debconf information

Bug#932126: RM: libreadonly-xs-perl -- ROM; obsolete

[gregor herrmann]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please remove libreadonly-xs-perl (source + binaries) from the
archive.

libreadonly-xs-perl was an optional addition to libreadonly-perl
which is not needed anymore since libreadonly-perl 1.500.0 (uploaded
2014).

Currently there are some reverse-dependencies of libreadonly-xs-perl
but I am fixing or having fixed them, and I've alreay added
"Provides: libreadonly-xs-perl" to libreadonly-perl, so there
shouldn't be any problems.

Thanks in advance,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl0skr1fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgY6LRAAlWSuvGCVgmLFWsRjN/NVrraSRuaGczwK1i2sLHt3SCIZ2DGtauzCQPmf
umsS3pz5OIHQWtNDjHgaPWhdN3XoGbUoehwka5Uuh7QZ59/W3k2uj+qUM1cvpzcb
aPvaOtrNcWcSubW2BRvxFvTsl90vcuL3Rnjg3VQ2Xu9NsSHex7cnv7wDbv89cEOj
WFgivc3YcD2PwIEZU7UxSRhVcDAv4PbPuMBuzbZwNYs30D19IawobfdfRVGHMFIP
UVEVZhTxwj5c8gaDXsjX2mhUQEgzTBw5gU42u/Ob4s1VGWOZMY7aVFpMvImVaTH1
LWQVd6Ag0vhIBj32is5lcrogXTFCI/381IkavT9LHKc3+nIlla4fqsJKy0QYDEkp
raS7XM6+X22CKVdNUUiSmdLBrtd2zFv5Ln+DMO+uqkVCPyotTJHAkksw13zFXAo8
hJFnZxkKQFtQEAXEHtbYChtJRfvsdOGexuhuhjTQJhymUvyHCfIqKxk1rWTz/yoX
YovUijtqLQtc2IqX0kMiIRlsybkS4i4imS+NuMfBf/z4poelS43HLb1MfyynCHpd
t8HHC/gAf28IBTBxpOgfoQrutrkVPuXPpzobkJee+K+wQj/nNV1piIYfMR6rhjEr
1i3mQZfOG4sXqD5O0OsTCD64GeLA/1bbKPZUTlTAE9Ry8Cwh5M8=
=kAci
-END PGP SIGNATURE-

Bug#924505: bash: set shell to /bin/sh on removal

[Dmitry Bogatov]

[2019-03-13 17:17] Dmitry Bogatov 
> Package: bash
> Version: 5.0-2
> Severity: wishlist
>
> Dear Maintainer,
>
> To contribute to efford of of making bash non-essential, I propose
> following patch, that should resolve issue with login #620898 (in CC).
> [...]

Any progress?
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#664610: ignore overrides/myscript, if init.d/myscript is not available

[Dmitry Bogatov]

control: tags -1 +moreinfo

[2012-03-19 11:52] Harald Dunkel 
> Package: insserv
> Version: 1.14.0-2.2
> Severity: wishlist
>
> insserv should ignore /etc/insserv/overrides/myscript, if
> /etc/init.d/myscript is not available.
>
> In my case "insserv -r somescript" refused to proceed, just
> because some long forgotten override file for myscript mentioned
> a dependency to somescript.

Seems things changed. I tried to reproduce this bug with following:

$ cat /etc/insserv/overrides/foo
### BEGIN INIT INFO
# Provides:  foo
# Required-Start:xdm $local_fs $remote_fs
# Required-Stop: xdm $local_fs $remote_fs
# Should-Start:  xfs $named slapd
# Should-Stop:   xfs $named slapd
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: The X Display Manager
### END INIT INFO
$ sudo insserv -v -r xdm
insserv: remove service /etc/init.d/../rc0.d/K01xdm
insserv: remove service /etc/init.d/../rc1.d/K01xdm
insserv: remove service /etc/init.d/../rc2.d/S04xdm
insserv: remove service /etc/init.d/../rc3.d/S04xdm
insserv: remove service /etc/init.d/../rc4.d/S04xdm
insserv: remove service /etc/init.d/../rc5.d/S04xdm
insserv: remove service /etc/init.d/../rc6.d/K01xdm
insserv: creating .depend.boot
insserv: creating .depend.start
insserv: creating .depend.stop
$ sudo insserv -v xdm
insserv: enable service ../init.d/xdm -> /etc/init.d/../rc0.d/K01xdm
insserv: enable service ../init.d/xdm -> /etc/init.d/../rc1.d/K01xdm
insserv: enable service ../init.d/xdm -> /etc/init.d/../rc2.d/S04xdm
insserv: enable service ../init.d/xdm -> /etc/init.d/../rc3.d/S04xdm
insserv: enable service ../init.d/xdm -> /etc/init.d/../rc4.d/S04xdm
insserv: enable service ../init.d/xdm -> /etc/init.d/../rc5.d/S04xdm
insserv: enable service ../init.d/xdm -> /etc/init.d/../rc6.d/K01xdm
insserv: creating .depend.boot
insserv: creating .depend.start
insserv: creating .depend.stop

Did I misunderstood something?
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#633858: -v not as safe as it sounds

[Dmitry Bogatov]

control: tags -1 +patch

[2019-01-31 17:25] Jesse Smith 
> I think the manual page is correct and the flag is documented as
> expected. The -v command only turns on verbose messages, it doesn't do
> anything else, as documented in the man page. This bug can probably be
> closed as there doesn't seem to be anything here to fix.

What about this patch?

 * Patch makes it clear that option only about regular operation of
   insserv(8).

   To my reading (non-native), "currently going on" is about things that
   are happening, whether I am involved or not.

 * Provides information on where these messages are going to.

diff --git a/insserv.8.in b/insserv.8.in
index f405cfd..cc84da9 100644
--- a/insserv.8.in
+++ b/insserv.8.in
@@ -262,7 +262,7 @@ grouped into one starting or stopping order.
 Currently the following options are recognized by insserv:
 .TP
 .BR \-v ,\  \-\-verbose
-Write out what is currently going on.
+Perform operation with more diagnotic messages printed on stderr.
 .TP
 .BR \-c\  ,\  \-\-config\ 
 Specify path to the insserv.conf file and the insserv.conf.d


-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#545174: insserv: Please add simple "if" conditionals to disable scripts

[Dmitry Bogatov]

control: close -1
control: tags -1 +wontfix

Sorry for late response.

[2009-09-05 06:46] Josh Triplett 
> Package: insserv
> Version: 1.12.0-10
> Severity: wishlist
>
> Some scripts only need to run if some other subsystem does not.  For
> example, hwclock and hwclockfirst should only run if udev does not.
> Currently, they must do so by always running, and checking the condition
> they need.  However, the condition only changes when the set of init
> scripts changes; thus, ideally the script could just have no start/stop
> links when it need not run.  I'd propose something like this:
>
> X-Ignore-If: udev

Please do not, keep it simple.

Checking this condition /inside/ initscript has neglectable cost (like
several /bin/sh processes) and gives you flexibility to check for
conditions of arbitrary complexity.

Closing. You still can try to convince upstream maintainer.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#932125: tor: missing dependency on procps

[Dmitry Bogatov]

Package: tor
Version: 0.4.0.5-1
Severity: normal

Dear Maintainer,

init.d script contains following code (line 239):

if ps "$pid" >/dev/null 2>&1; then
log_success_msg "$NAME is running"
exit 0
else
log_failure_msg "$NAME is not running"
exit 1
fi

Note, that /bin/ps is provided by bin:procps, which is not Essential.
If bin:procps is not installed, quoted snipped reports that Tor server
is not running.

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

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


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.utf8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.utf8)
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages tor depends on:
ii  adduser 3.118
ii  libc6   2.28-10
ii  libcap2 1:2.25-2
ii  libevent-2.1-6  2.1.8-stable-4
ii  liblzma55.2.4-1
ii  libseccomp2 2.3.3-4
ii  libssl1.1   1.1.1c-1
ii  libsystemd0 241-6+b1
ii  libzstd11.3.8+dfsg-3
ii  lsb-base10.2019051400
ii  runit-helper2.8.13.2
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages tor recommends:
ii  logrotate3.14.0-4
ii  tor-geoipdb  0.4.0.5-1
ii  torsocks 2.3.0-2

Versions of packages tor suggests:
pn  apparmor-utils   
pn  mixmaster
pn  obfs4proxy   
ii  socat1.7.3.2-2
pn  tor-arm  
ii  torbrowser-launcher  0.3.1-2

-- Configuration Files:
/etc/tor/torrc [Errno 13] Permission denied: '/etc/tor/torrc'

-- no debconf information


pgpTKf03vvp6s.pgp
Description: PGP signature

Bug#932124: insserv: test suite does not work with installed binary

[Dmitry Bogatov]

Package: insserv
Severity: normal

Dear Maintainer,

in tests/suite there is following line:

: ${insserv:=${PWD}/../insserv}

I assume, that shy assignment (${foo:=defval}) means that I can override
this value via environment variable. But I try, I get following error:

$ make check insserv=/sbin/insserv
rm -rf tests/root/
cd tests && ./common
/home/iu/devel/salsa/debian/insserv/tests

info: test simple script ordering.

/sbin/insserv: invalid option -- 'i'
insserv: For help use: insserv -h
/sbin/insserv: invalid option -- 'i'
insserv: For help use: insserv -h
/sbin/insserv: invalid option -- 'i'
insserv: For help use: insserv -h
insserv.conf

init.d:
firstscript
lastscript
middlescript
error: script firstscript not present in runlevel 2
error: 1 test executed, 1 fatal tests failed, 0 nonfatal test failed.
make: *** [Makefile:147: check] Error 1


pgptsMsw8xuxD.pgp
Description: PGP signature

Bug#545311: insserv: provide a way to ignore a script when a file is not installed

[Dmitry Bogatov]

control: tags -1 +wontfix
control: close -1

[2009-09-06 13:46] Michael Schutte 
> Package: insserv
> Version: 1.12.0-11
> Severity: wishlist
>
> Hi,

Hi. Sorry for late response.

> Most init scripts in Debian start with a line like
>
>   [ -x /usr/sbin/some-daemon ] || exit 0
>
> to handle the common situation when a package has been removed, but not
> purged.  It would be nice if insserv could provide a way to ignore a
> script altogether when a file isn’t there, for example via a new header
> in the INIT INFO block:
>
>   # X-If-Exists: /usr/sbin/some-daemon

Currently, this line in hidden inside init-d-script(5), so repetition is
gone.

> This line usually isn’t needed because the scripts exit gracefully
> anyway.  Still, such a header would make it possible for mutually
> exclusive init scripts from conflicting packages to provide the same
> facility name.  For example, /etc/init.d/some-daemon from the
> some-daemon package could say
>
>   # Provides: some-daemon
>   # X-If-Exists: /usr/sbin/some-daemon
>
> while /etc/init.d/better-daemon states
>
>   # Provides: some-daemon
>   # X-If-Exists: /usr/sbin/better-daemon

This is handled by virtual facilities (/etc/insserv.conf), like:

  $named   +named +dnsmasq +lwresd +bind9 +unbound $network
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#929473: Targetted fix for crash in schedule_fd_processing

[Sam Morris]

I've been running sssd with the patch from
 applied for
a couple of weeks. Could this please be considered for proposed-
updates?

Thanks

-- 
Sam Morris 

Bug#932080: sssd fails to start: #886483 raises from the dead

[Sam Morris]

Control: tag -1 + patch upstream
Control: forward -1 

On Sun, 14 Jul 2019 20:19:40 +0100 =?utf-8?b?SnVoYSBKw6R5a2vDpA==?= 
 wrote:
> Second failure mode is triggered by trying the obvious: commenting out
> the whole "service" line from sssd.conf. However, now sssd fails both
> from command line and from systemd because
> 
> "sssd: SSSD couldn't load the configuration database [22]: Invalid argument."
> 
> There does not seem to be any way of disabling all non-socket services
> but if at least one non-socket service is active, systemd will time out
> trying to load the corresponding socket.

This is because 'services' is mandatory if sssd is built without
HAVE_SYSTEMD. A typo in src/external/systemd.m4 prevents HAVE_SYSTEMD
being set, which removes the code allowing 'services' to be optional.
It also removes the code that notifies systemd that sssd is ready,
which is why systemd kills it after 90 seconds and marks the unit as
failed.

If you run 'journalctl -u sssd-nss.service', you should see the
following error:

Invalid option --socket-activated: unknown option

This is the reason that the socket-activated services that _aren't_
explicitly listed in 'services' fail to start.

I have fixed this in
<
https://salsa.debian.org/sssd-team/sssd/merge_requests/5>.

I also removed 'services' from sssd.conf to allow nss and pam to be
socket-activated by default (their corresponding socket units check
sssd.conf and fail to start if they are mentioned in 'services').

While debugging this I made a few observations:

Duplicate sssd_pac process: I've noticed that sssd always starts and
babysits an sssd_pac process even though it's not configured to do so.
systemd starts its own instance under sssd-pac.service; I presume
there's a race here over which instance is invoked when I finally log
in. Both processes hold open the database and the log file. I don't
know if there's potential for corruption here, but I don't like it!
According to the add_implicit_services function, this happens because I
have a domain using the IPA provider; I guess this code needs to be
updated to take into account the possibility of a socket-activated pac
responder process. I'll raise this upstream.

sssd resiliance: without sssd running, it's impossible to log into the
system or use sudo to fix it. Shouldn't sssd use Restart=always to
ensure that it comes back if it crashes?

dbus crash: while upgrading sssd to version 2, and later on while I was
installing my patched package with dpkg, dbus-daemon logged the message
"unable to reload configuration: (null)" and then segfaulted ("segfault
at 0 ip 55a507dfd700 sp 7ffeed3d3638 error 6 in dbus-
daemon[55a507de7000+22000]" according to the kernel). Sadly systemd-
coredump didn't record a core file. Did dbus-daemon perhaps tried to
reload the config while dpkg was still writing it out?

sssd_pac crash: sssd_pac dies after about five minutes with the "The
last reference on a connection was dropped without closing the
connection. This is a bug in an application. [...] Most likely, the
application called unref() too many times and removed a reference
belonging to libdbus, since this is a shared connection." If this
persists after a reboot I'll file a separate bug for it.

-- 
Sam Morris 

Bug#930648: exim4-daemon-heavy: Weird leakage of unrelated data like /etc/aliases into /var/spool/exim4/input/*-H

[Bjoern Buerger]

Hi, 

short update:

* Bjoern Buerger (b.buer...@pengutronix.de) [190625 12:08]:
> * Andreas Metzler (ametz...@bebt.de) [190621 09:58]:
> > On 2019-06-19 Bjoern Buerger  wrote:
> > > * Andreas Metzler (ametz...@bebt.de) [190618 19:15]:
> > [...] 
> > > > Could you try
> > > > a) disabling BDAT (set chunking_advertise_hosts = )
> > > > b) try a backport of sa-exim 4.2.1-17?
> > 
> > > > See #879687.
> 
> chunking_advertise_hosts is now disabled, 
> sa-exim is 4.2.1-17. 

We haven't seen any problem since upgrading to sa-exim 4.2.1-17
and disabling chunking_advertise_hosts. 

Cheers, 
Bjørn

-- 
Pengutronix e.K.  | Bjørn Bürger|
Industrial Linux Solutions| https://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim | Phone: +49-5121-206917-5002 |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917- |

Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found

[Diederik de Haas]

On maandag 15 juli 2019 11:22:55 CEST Colin Watson wrote:
> output of "sudo debconf-show grub-pc | grep install_devices:". 

Ohhh, that is an interesting command :)

> You certainly do need to run "dpkg-reconfigure grub-pc" to match what
> your BIOS is configured to boot from.  However, once you do that,
> removing the old drive shouldn't be a problem.

Did that and selected my NVMe drive and set that also up as boot device in my 
BIOS (i.e. like it was before), and now it did work.
Now that it looks like I (finally) get it, I may play around with it a bit more 
to get a better understanding of debconf. Which in turn may increase my 
understanding (and thereby use of) preseeding :)
 
Thanks for your responses and info.

Cheers,
  Diederik

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

Bug#930846: partman-auto-lvm: debconf show guided_size during auto install

[Laura Arjona Reina]

Hi all

El 15/7/19 a las 12:36, Holger Wansing escribió:

Hi,

Steve McIntyre  wrote:

On Sat, Jun 22, 2019 at 01:05:01PM +0200, Baptiste BEAUPLAT wrote:

Tags: patch

Added patch:
https://salsa.debian.org/installer-team/installation-guide/merge_requests/7


Merged, thanks for your contribution!


This has been fixed in the installation-guide package, version 20190622
(currently in stable) has the fix.
However, https://www.debian.org/releases/buster/example-preseed.txt
still does not have it.

So CC'ing debian-www for assistance



I've had a look at the www-master.debian.org
I see that the installation guide has been generated on 20190623 but the 
example-preseed.txt file has date 20190324.


I guess something went wrong with that file, and since there has not been 
changes in the installation guide since then, the build has not been retried.


In our cron job, I've temporarily removed the part where it checks if we need to 
build or not the guide, to force a rebuild today, and thus have logs to see what 
happens to that file.


I'll have a look later today to the logs and will update the bug.

Kind regards,
--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#873073: [Pkg-samba-maint] Bug#873073: Other ways to disable IPv6 ?

[Mathieu Parent]

Le dim. 14 juil. 2019 à 15:09, Dark Penguin  a écrit :
>
> This particular case could be less of a problem (at least to me) if
> adding "bind interfaces only = yes" was not the only way to disable IPv6
> in samba.
>
> Would it make sense to change the priority of an error message on
> startup about missing IPv6 support? If samba sees that IPv6 is not
> supported on this system, shouldn't it deduce that it is therefore not
> required, and output an "info" message like "Not binding to IPv6 -
> protocol not supported" instead of an error?

Have you tried overriding with:

cat /etc/systemd/system/smbd.service
[Service]
RestrictAddressFamilies=AF_UNIX AF_INET

(then systemctl daemon-reload and systemctl restart smbd)

(Not tested...)

Regards
-- 
Mathieu Parent

Bug#931290: general: Asrock A300 Deskmini AMD Athlon 200GE ends in black screen Monitor has no Signal

[Tomas Pospisek]

Am 12.07.19 um 19:11 schrieb Joe Lobeck:

> in the meantime I found that the most things work form kernel 5.0 or higher.
> Unfortunately so I will have to choose an other linux distribution as such a 
> kernel
> is for debian only from the experimantal repository avaiable.
> If you have any other idea how to make debian stable or testing run with this 
> hardware please let me know.

The kernel that was reported in your bug report was:

>> Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores)

That's a kernel from Debian stretch aka oldstable [1] AFAI can see. Did
you test with current Debian stable (buster) as well? Would it be
possible for you to test with Debian buster?

Greetings,
*t

Bug#873073: [Pkg-samba-maint] Bug#873073: Still present in Buster

[Mathieu Parent]

Le dim. 14 juil. 2019 à 14:51, Dark Penguin  a écrit :
>
> This issue is still present in Buster.
>
> Changing the interface name to its IP address in smb.conf does not make
> sense because we're talking about a situation when your IP address is
> managed by DHCP.
>
> Tweaking the systemd service files does not help according to the OP,
> and even if it did, this is not a solution - network-online.target
> apparently still does not work.
>
> Mathieu, is there a bug report with more details about the
> network-online.target problem? It looks pretty serious since it can
> potentially break all network-based daemons, and is still not fixed in
> Buster.

Have you considered tuning /etc/default/networking ?

For example:
WAIT_ONLINE_METHOD="ifup"
WAIT_ONLINE_IFACE="enp2s0"
WAIT_ONLINE_ADDRESS=""
WAIT_ONLINE_TIMEOUT=300

or:
WAIT_ONLINE_METHOD="ping"
WAIT_ONLINE_IFACE=""
WAIT_ONLINE_ADDRESS="128.31.0.62"
WAIT_ONLINE_TIMEOUT=300

See also /lib/ifupdown/wait-online.sh

What is the content of /etc/network/interfaces?

Regards

-- 
Mathieu Parent

Bug#731656: shadow: pam_unix requires securetty

[m . alfaeko]

Package: login
Version: 1:4.7-1
Followup-For: Bug #731656

Dear Maintainer,

Today i installed a newer version of login on my debian bullseye. After 
instalation
i noticed a error message in /var/log/auth.log stating that pam_unix.so cannot 
find
file /etc/securetty. I think this is relevant to this package in some way, 
because
this bug report started the removal of file /etc/securetty. Also the code of 
pam_unix.so
should be modified to not expect existence of /etc/securetty. Currently im not 
sure
how this may affect the pam_unix.so module and services using it.

Thank you

Have a nice day

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

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

Versions of packages login depends on:
ii  libaudit1   1:2.8.4-3
ii  libc6   2.28-10
ii  libpam-modules  1.3.1-5
ii  libpam-runtime  1.3.1-5
ii  libpam0g1.3.1-5

login recommends no packages.

login suggests no packages.

-- no debconf information