Bug#908291: developers-reference, section 5.11.4: Add a note on versioning scheme when reverting an NMU

[Joseph Herlant]

Source: developers-reference
Severity: wishlist
Tags: patch

Dear Maintainer,

The Developer's reference explains a lot about NMUs and corresponding version
scheme but it does not explain the naming convention to use when you have to
revert an NMU that brings a new upstream version.
Lintian has a check about it (https://lintian.debian.org/tags/epoch-changed-
but-upstream-version-did-not-go-backwards.html), so it seems the format is
wildly accepted.
So maybe a not about it here would be a good thing.

I took the liberty to provide a patch via a MR:
https://salsa.debian.org/debian/developers-reference/merge_requests/4

Let me know if adding that paragraph would be ok and if the wording is correct.
I'm not sure on how to handle the po files. Let me know if I can help on that
too.

Thanks
Joseph

Bug#903319: closed by Kan-Ru Chen (陳侃如) (Bug#903319: fixed in mupdf 1.13.0+ds1-3)

[Helmut Grohne]

Control: reopen -1

On Mon, Sep 03, 2018 at 01:09:08AM +, Debian Bug Tracking System wrote:
>* More FTCBFS patches.
>  Thanks to Helmut Grohne for the patches. (Closes: 903319)

Thank you for applying the patch, but without setting CC_FOR_BUILD it
does nothing (intentionally).

I wrote:
> Then it fails running hexdump.exe. That's due to building hexdump.exe
> with the host architecture compiler (called $(CC)) rather than the build
> architecture compiler (often called $(CC_FOR_BUILD) or $(BUILD_CC)). The
> next patch ccforbuild.patch adds a new variable CC_FOR_BUILD and
> defaults it to $(CC). It then makes hexdump.exe and namedump.exe use
> $(CC_FOR_BUILD). In order to properly support it from Debian you also
> need to set up this variable as the $(CC) default is again the host
> architecture compiler. Exporting CC_FOR_BUILD=cc is enough.
> Alternatively, letting /usr/share/dpkg/buildtools.mk supply it works as
> well. This patch also looks like something upstream could reasonably
> maintain, but they may have a preference on the variable name.

You have a number of options here:

export CC_FOR_BUILD=cc

or

include /usr/share/dpkg/buildtools.mk
export CC_FOR_BUILD ?= cc

or

set CC_FOR_BUILD=CC via your BUILD_FLAGS

but without any setting, the patch does nothing.

Helmut

Bug#907493: [SECURITY] [DSA 4288-1] ghostscript security update

[Paul Gevers]

Dear security team,

On 09/07/18 23:23, Moritz Muehlenhoff wrote:
> Package: ghostscript
> CVE ID : CVE-2018-15908 CVE-2018-15910 CVE-2018-15911
>  CVE-2018-16511 CVE-2018-16513 CVE-2018-16539
>CVE-2018-16540 CVE-2018-16541 CVE-2018-16542
>CVE-2018-16543 CVE-2018-16585

The latest upload of ghostscript to unstable, which as far as I know
only tried to fix some of these CVE's, caused the autopkgtest of
multiple packages to start timing out (bug 907493). Were you aware of
that and have you done any testing to verify that this isn't an issue
for the stable upload?

If so, that would be an interesting data point for the bug. If not, you
may be facing the same regression in stretch. I have the wild hunch that
this is related to the openssl upstream bump in unstable, but nobody has
verified that yet. If stretch is no not seeing this regression that
would mean there may also be a path to fix testing/buster until we
figure out what needs fixing in ghostscript.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#908088: xfce4-panel: systray icon background corrupt after upgrade to GTK 3.24 if display compositing disabled

[Michael Biebl]

Am 08.09.18 um 04:54 schrieb Ben Caradoc-Davies:
> On 07/09/2018 11:33, Michael Biebl wrote:
>> I can't reproduce the problem (using openbox+wmdocker)
>> So I suspect this might be related to the XFCE tray.
> 
> Michael, does your window manager use display compositing? Are you able
> to test with display compositing disabled?
> 
> I saw the corruption under Xfce xfwm4 with display compositing disabled.
> Workaround is to enable display compositing with Xfce Settings / Window
> Manager Tweaks / Compositor / Enable display compositing. The nm-applet,
> Remmina, and Skype icons are then displayed as they were before the GTK
> 3.24 upgrade: uncorrupted with correct theme background colour.

This was indeed tested with compositing enabled.
So a GTK 3.24 / compositing related problem?

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



signature.asc
Description: OpenPGP digital signature

Bug#908290: [zfs-linux] Please package 0.7.10

[Antonio Russo]

Package: zfs-linux
Severity: important
Tags: patch

--- Please enter the report below this line. ---

The recent release of zfsonlinux 0.7.10 adds support for Linux kernel 4.18. 
There
are some slight changes in upstream that can simplify the Debian packaging, and
have been incorporated into [1] (it uses the upstream version of the dkms
configuration file). It also ships upstream's bash completion
file, instead of a second copy that looks to have fallen out of maintenance,
in addition to several other cleanups.

The release of 0.7.10 should (I believe) supersede [2].


[1] https://salsa.debian.org/zfsonlinux-team/zfs/merge_requests/9
[2] https://salsa.debian.org/zfsonlinux-team/zfs/merge_requests/10

Bug#908289: redshift: new redshift 1.12

[Jonatan Nyberg]

package: redshift
severity: normal

Dear Maintainer,

Please consider to upgrade to the current upstream version of redshift
(1.12).

Kind regards,
Jonatan Nyberg

Bug#908288: chromium: minimize/maximize window buttons can be missing

[Michael Gilbert]

package: chromium
severity: minor
version: 68.0.3440.75-1~deb9u1
tag: upstream

This is a regression introduced upstream.  Seen in this version and
possibly introduced earlier.  It only affects the stretch package.

Best wishes,
Mike

Bug#908142: chromium crashes when changing domain name in Selenium tests

[Michael Gilbert]

control: tag -1 moreinfo
control: severity -1 minor

On Thu, Sep 6, 2018 at 11:03 AM Nicolas Rodriguez wrote:
> I use ArchLinux on my laptop with Chromium 68.0.3440.106 and it works
> very well.
>
> I suggest to update Chromium to 68.0.3440.106.

69.0.3497.81-1~deb9u1 has just been uploaded.  Does it fix this problem?

Best wishes,
Mike

Bug#908220: [pkg-cryptsetup-devel] Bug#908220: cryptsetup-initramfs: Need a clean way to force cryptsetup in initramfs

[Guilhem Moulin]

Control: tag -1 - moreinfo

On Fri, 07 Sep 2018 at 23:22:45 +0200, Raphael Hertzog wrote:
> On Fri, 07 Sep 2018, Guilhem Moulin wrote:
>>> update-initramfs: Generating /boot/initrd.img-4.17.0-kali3-amd64
>>> cryptsetup: WARNING: Couldn't determine root device
>>> cryptsetup: ERROR: Couldn't resolve device /dev/sdb4
>>> cryptsetup: WARNING: The initramfs image may not contain cryptsetup 
>>> binaries 
>>> nor crypto modules. If that's on purpose, you may want to uninstall the 
>>> 'cryptsetup-initramfs' package in order to disable the cryptsetup 
>>> initramfs 
>>> integration and avoid this warning.
>> 
>> Do you have the proc(5) and sysfs(5) pseudo-filesystems respectively
>> mounted to /proc and /sys?  The “WARNING: Couldn't determine root
>> device” suggests it's either not the case, or that the file system
>> holding / is not backed up by a block device (eg, ZFS).  Can you share
>> what /proc/mounts contains before you type `update-initramfs -u`?
> 
> I don't think this is relevant, at this point live-build is just
> installing packages in a chroot. The end result is an ISO image...
> there's no associated device. It can be copied on a DVD or burnt
> on an USB key.

It might be related to #902123 though.  Since 2:2.0.3-2 our initramfs
hook needs proc(5) and sysfs(5) resp. mounted to /proc and /sys.  I'm
not sure about live-build, but d-i currently doesn't do that at
finish-install stage.

>> How do you unlock that disk at initramfs stage?  Using a custom boot
>> script, or by typing a `cryptsetup open --type=luks` command manually?
>> Or do you rely on our own (‘cryptroot’) initramfs boot script?
> 
> live-boot rebuilds the initramfs image and hooks itself in the process,
> it does manually open all luks containers:
> 
> open_luks_container() is the way to open the luks partitition:
> https://salsa.debian.org/live-team/live-boot/blob/master/components/9990-misc-helpers.sh#L830
> 
> find_persistence_media() is the place where all partititions
> are scanned for luks:
> https://salsa.debian.org/live-team/live-boot/blob/master/components/9990-misc-helpers.sh#L1043

Hmm, so you don't really need the integration provided by
cryptsetup-initramfs then; you want the cryptsetup binary and its shared
library to be included to the initramfs image, but aren't using any of
our boot scripts?  If that's indeed the case then you could as well
bypass our hooks and write your own to add said binaries and modules :-)

>> Adding the cryptsetup binaries to the initramfs image might not be
>> sufficient, especially if the initramfs image isn't compiled with
>> MODULES="most".  That's why we warn the user that modules might me
>> missing if auto detection fails to determine which device(s) need to be
>> unlocked at initramfs stage and/or which modules are required to map the
>> crypt devices.  Failure to unlock the root device is arguably worse than
>> false positives.
> 
> This is not so much a problem for us because the use case is always to add
> an encrypted partition after the ISO image copied onto an USB key. We
> don't need any special driver.

I think you do, but probably rely on the initramfs image to contain all
modules users might encounter in real life scenarios.

At initramfs stage one doesn't have access to the modules of the main
system; any module required for a device to be present at this stage
(USB devices, SATA devices, crypt devices, whatever) *has to* be added
to the image.  MODULES="most" is often enough but not always, and
sometimes extra modules need to be added, either manually or imported by
another hook.

>> Before the package split (cf. #783297 and #813220) users could add
>> CRYPTSETUP=n to disable initramfs integration.  As the warning suggests
>> we're deprecating this; we'll remove the warning once buster is
>> released, instead installing cryptsetup-initramfs will silently trigger
>> execution of our initramfs hook scripts.
> 
> Can't you just trigger the warning only when CRYPTSETUP=n? If it's set to "y",
> it doesn't match the old use case... it just means that we want to enable
> it.

It makes sense indeed, we can do that.

> We just want that cryptsetup continues to use the sane defaults that
> it has been using up to now and we want to be able to force its
> installation into the initrd.

That sounds like quite a brittle assumption IMHO.  cryptsetup's default
cipher/mode for LUKS changed over time, and they will keep doing so.
For instance upstream changed from cbc-essiv:sha256 to aes-xts-plain64
with 1.6.0; these ciphers require different sets of modules, and on a
CPU without AES-NI one can't unlock a volume formatted with 1.6.0's new
default options from an initramfs lacking the ‘xts’ module.

Similarly when luks2 and AEAD become the default, to unlock such volumes
one will need libgcc and dm-integrity to be included in the initramfs
image.  The latter is currently not included by default, even when the
image is generated with MODULES="most"…

While our hook adds a basic 

Bug#908088: xfce4-panel: systray icon background corrupt after upgrade to GTK 3.24 if display compositing disabled

[Ben Caradoc-Davies]

On 07/09/2018 11:33, Michael Biebl wrote:
> I can't reproduce the problem (using openbox+wmdocker)
> So I suspect this might be related to the XFCE tray.

Michael, does your window manager use display compositing? Are you able 
to test with display compositing disabled?


I saw the corruption under Xfce xfwm4 with display compositing disabled. 
Workaround is to enable display compositing with Xfce Settings / Window 
Manager Tweaks / Compositor / Enable display compositing. The nm-applet, 
Remmina, and Skype icons are then displayed as they were before the GTK 
3.24 upgrade: uncorrupted with correct theme background colour.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#908287: /usr/bin/mc: Custom hide/show panel keybind doesn't work for "show"

[Helen Koike]

Package: mc
Version: 3:4.8.21-1
Severity: normal
File: /usr/bin/mc

Dear Maintainer,

I am trying to modify the Shell keybind from midnight commander.

So I did the following:

cp /etc/mc/mc.keymap ~/.config/mc/

And edited all occurrences of "Shell = ctrl-o" to another keybiding (I
tested with several others), e.g. "Shell = alt-q"

Now, when I open mc and I type alt-q, it hides the panel and go to the
prompt shell, but if I hit alt-q again nothing happens, I need to hit ctrl-o to
make the panel to appear again, but I removed all occurrences of ctrl-o
from ~/.config/mc/mc.keymap, so it seems that ctrl-o is hardcoded
somewhere else.

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

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

Versions of packages mc depends on:
ii  libc6 2.27-5
ii  libext2fs21.44.4-2
ii  libglib2.0-0  2.58.0-1
ii  libgpm2   1.20.7-5
ii  libslang2 2.3.2-1+b1
ii  libssh2-1 1.8.0-2
ii  mc-data   3:4.8.21-1

Versions of packages mc recommends:
ii  mime-support  3.61
ii  perl  5.26.2-7
ii  unzip 6.0-21

Versions of packages mc suggests:
pn  arj  
ii  bzip21.0.6-9
pn  dbview   
pn  djvulibre-bin
ii  evince [pdf-viewer]  3.30.0-1
ii  file 1:5.34-2
ii  genisoimage  9:1.1.11-3+b2
pn  gv   
ii  imagemagick  8:6.9.10.8+dfsg-1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.8+dfsg-1
pn  libaspell-dev
ii  lynx 2.8.9rel.1-2
pn  odt2txt  
ii  poppler-utils0.63.0-2
ii  python   2.7.15-3
pn  python-boto  
ii  python-tz2018.5-1
ii  texlive-binaries 2018.20180824.48463-1
ii  zip  3.0-11+b1

-- no debconf information

Bug#908088: xfce4-panel: nm-applet icon corrupt after upgrade to GTK 3.24

[Ben Caradoc-Davies]

Remmina and Skype have the same problem. The black square is the black 
remmina systray icon on a black background (since upgrade to GTK 3.24).


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#908219: libhinawa: please make the build reproducible

[Takashi Sakamoto]

Hi Chris,

Thank you for the patch to achieve reproducible build of libhinawa. I
commit the patch with enough comments into my remote repository[1]. Hash
of the commit is 7ecd1d6dd1398ca54b9e62201f60e3e8330d628e[2]. Would I
request your confirmation of content of the commit?

> Kentaro

I have a plan to release v1.0.1 with some bug fixes soon. I'd ask you
to prepare for RFS of the new release.

[1] https://github.com/takaswie/libhinawa/commits/topic/reproducible-build
[1] 
https://github.com/takaswie/libhinawa/commit/7ecd1d6dd1398ca54b9e62201f60e3e8330d628e


Thanks

Takashi Sakamoto

On Sep 7 2018 22:38, Chris Lamb wrote:

Source: libhinawa
Version: 1.0.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that libhinawa could not be built reproducibly.

This is because it uses the absolute @filename@ template variable to
generate a comment in a header files. Patch attached that uses
@basename@ instead.

  [0] https://reproducible-builds.org

Bug#908176: jhead: Buffer Overflow while running jhead

[Hanfang Zhang]

Hello,

Done. Thanks a lot.

Regards,
Hanfang

Ludovic Rousseau  于2018年9月8日周六 上午1:05写道：

> Hello,
>
> Please request a new CVE ID.
> As Salvatore Bonaccorso wrote in http://bugs.debian.org/907925
>
> " Can you please request a CVE via the webform at
> https://cveform.mitre.org/ and once the CVE assigned loop it back here?"
>
> Thanks
>
> Le 07/09/2018 à 05:54, Hanfang Zhang a écrit :
> > Package: jhead
> > Version: 1:3.00-7
> > Vulerability type: Buffer Overflow
> >
> > An buffer overflow bug was found in jhead, which allows attackers to
> casue a denial of service via a crafted JPEG file.
> >
> > Components: gpsinfo.c -> ProcessGpsInfo() ->line 164
> > ```
> > case TAG_GPS_ALT://BUG
> >  sprintf(ImageInfo.GpsAlt + 1, "%.2fm",
> >  ConvertAnyFormat(ValuePtr, Format));
> >  break;
> > ```
> > Output:
> > ```
> > gdb-peda$ bt
> > #0  0x77739428 in __GI_raise (sig=sig@entry=0x6) at
> ../sysdeps/unix/sysv/linux/raise.c:54
> > #1  0x7773b02a in __GI_abort () at abort.c:89
> > #2  0x7777b7ea in __libc_message (do_abort=do_abort@entry=0x2,
> >  fmt=fmt@entry=0x7789349f "*** %s ***: %s terminated\n") at
> ../sysdeps/posix/libc_fatal.c:175
> > #3  0x7781d15c in __GI___fortify_fail (msg=,
> msg@entry=0x77893430 "buffer overflow detected")
> >  at fortify_fail.c:37
> > #4  0x7781b160 in __GI___chk_fail () at chk_fail.c:28
> > #5  0x7781a6c9 in _IO_str_chk_overflow (fp=,
> c=) at vsprintf_chk.c:31
> > #6  0x7777f6b0 in __GI__IO_default_xsputn (f=0x7fff79b0,
> data=, n=0x19) at genops.c:455
> > #7  0x7775625a in __GI___printf_fp_l (fp=fp@entry=0x7fff79b0,
> loc=, info=info@entry=0x7fff7530,
> >  args=args@entry=0x7fff7510) at printf_fp.c:1236
> > #8  0x77756bd9 in ___printf_fp (fp=fp@entry=0x7fff79b0,
> info=info@entry=0x7fff7530,
> >  args=args@entry=0x7fff7510) at printf_fp.c:1257
> > #9  0x777530b9 in _IO_vfprintf_internal (s=s@entry=0x7fff79b0,
> format=,
> >  format@entry=0x40f640 "%.2fm", ap=ap@entry=0x7fff7ae8) at
> vfprintf.c:1631
> > #10 0x7781a754 in ___vsprintf_chk (s=0x61659f 
> "944473296573929042", flags=0x1, slen=0x13,
> >  format=0x40f640 "%.2fm", args=args@entry=0x7fff7ae8) at
> vsprintf_chk.c:82
> > #11 0x7781a6ad in ___sprintf_chk (s=,
> flags=flags@entry=0x1, slen=slen@entry=0x13,
> >  format=format@entry=0x40f640 "%.2fm") at sprintf_chk.c:31
> > #12 0x00409649 in sprintf (__fmt=0x40f640 "%.2fm",
> __s=) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:33
> > #13 ProcessGpsInfo (DirStart=, 
> > OffsetBase=OffsetBase@entry=0x6182d8
> "MM", ExifLength=ExifLength@entry=0x13e)
> >  at gpsinfo.c:164
> > #14 0x00407980 in ProcessExifDir (DirStart=DirStart@entry=0x6182e0
> "", OffsetBase=OffsetBase@entry=0x6182d8 "MM",
> >  ExifLength=ExifLength@entry=0x13e, NestingLevel=NestingLevel@entry=0x0)
> at exif.c:867
> > #15 0x00407b86 in process_EXIF 
> > (ExifSection=ExifSection@entry=0x6182d0
> "\001FExif", length=length@entry=0x146)
> >  at exif.c:1035
> > #16 0x00404ab3 in ReadJpegSections (infile=infile@entry=0x617070,
> ReadMode=ReadMode@entry=READ_METADATA) at jpgfile.c:287
> > #17 0x00404dce in ReadJpegSections (ReadMode=READ_METADATA,
> infile=0x617070) at jpgfile.c:126
> > #18 ReadJpegFile (FileName=FileName@entry=0x7fffe376 "poc",
> ReadMode=READ_METADATA) at jpgfile.c:375
> > #19 0x00402ac1 in ProcessFile (FileName=0x7fffe376 "poc") at
> jhead.c:896
> > #20 0x0040183c in main (argc=argc@entry=0x2, 
> > argv=argv@entry=0x7fffdff8)
> at jhead.c:1729
> > #21 0x77724830 in __libc_start_main (main=0x4016b0 ,
> argc=0x2, argv=0x7fffdff8, init=,
> >  fini=, rtld_fini=,
> stack_end=0x7fffdfe8) at ../csu/libc-start.c:291
> > #22 0x00402219 in _start ()
> >
> > ```
> > ConvertAnyFormat function converts ValuePtr to another data type by
> using Format value. When Format value equals to 11, the ValuePtr should be
> convert to double type. There is no type checking in the parameters in
> sprintf function. In this case, “%.2fm” corresponds to the float type data,
> ConvertAnyFormat() corresponds to the double type data. So it causes
> undesirable behavior including buffer overflow.  Replacing sprintf with
> snprintf may fix this bug.
>
>
> --
>   Dr. Ludovic Rousseau
>

Bug#906115: [gnucash] no ibus installed, crashes with any key

[Sylvain L. Sauvage]

Package: gnucash
Version: 1:3.2-1

ibus is not installed here and Gnucash crashes with any key.
I can only navigate with the mouse and read, no edition possible.
It even crashes with modifier keys (e.g. Shift or Meta).


--- System information. ---
Architecture: 
Kernel:   Linux 4.18.0-1-amd64

Debian Release: buster/sid
  500 unstableftp.fr.debian.org 
  500 testing ftp.fr.debian.org 

--- Package information. ---
Depends(Version) | Installed
-+-=
gnucash-common   (= 1:3.2-1) | 1:3.2-1
guile-2.2-libs   | 2.2.4+1-1
libaqbanking35(>= 5.3.1beta) | 5.7.8-2
libatk1.0-0  (>= 1.12.4) | 2.28.1-1
libboost-date-time1.62.0 | 1.62.0+dfsg-8
libboost-filesystem1.62.0| 1.62.0+dfsg-8
libboost-locale1.62.0| 1.62.0+dfsg-8
libboost-regex1.62.0(>= 1.62.0+dfsg-5.1) | 1.62.0+dfsg-8
libboost-system1.62.0| 1.62.0+dfsg-8
libc6  (>= 2.14) | 
libcairo-gobject2(>= 1.10.0) | 
libcairo2 (>= 1.2.4) | 
libdbi1   (>= 0.9.0) | 
libgc1c2 (>= 1:7.2d) | 
libgcc1   (>= 1:3.0) | 
libgdk-pixbuf2.0-0   (>= 2.22.0) | 
libglib2.0-0 (>= 2.45.3) | 
libgtk-3-0   (>= 3.21.5) | 
libgwenhywfar60 (>= 3.99.16) | 
libicu60(>= 60.1-1~) | 
libjavascriptcoregtk-4.0-18  | 
libktoblzcheck1v5| 
libofx7  | 
libpango-1.0-0   (>= 1.14.0) | 
libpangocairo-1.0-0  (>= 1.14.0) | 
libsecret-1-0   (>= 0.7) | 
libsoup2.4-1  (>= 2.4.0) | 
libstdc++6  (>= 5.2) | 
libwebkit2gtk-4.0-37 (>= 2.15.1) | 
libxml2   (>= 2.7.4) | 
libxslt1.1   (>= 1.1.25) | 
zlib1g  (>= 1:1.1.4) | 
libaqbanking35-plugins   | 
perl:any | 
guile-2.2| 
libfinance-quote-perl| 
libwww-perl  | 
libhtml-tree-perl| 
libhtml-tableextract-perl| 
libcrypt-ssleay-perl | 
libdate-manip-perl   | 


Recommends   (Version) | Installed
==-+-===
gnucash-docs   | 
python3-gnucash| 
yelp   | 


Suggests(Version) | Installed
=-+-===
libdbd-mysql  | 
libdbd-pgsql  | 
libdbd-sqlite3| 


-- 
 Sylvain L. Sauvage

Bug#875850: opam fails to build ocamlfind.

[Nicolas Braud-Santoni]

Control: tag -1 + moreinfo unreproducible

Hi Pietro !

On Fri, Sep 15, 2017 at 10:56:58AM +0200, Pietro Abate wrote:
> On 15/09/17 07:38, Ximin Luo wrote:
> > opam is indeed out-of-date on Debian but are you sure that is your problem? 
> > This error makes it look like your download was faulty.
> > I have been using Debian's opam fine for quite a while, but with the 4.05.0 
> > ocaml from Debian experimental.
> 
> I don't think it's a download problem. I compiled opam from git and
> executed exactly the same operations on the same machine and
> everything worked as expected. I'll try out the packages from
> experimental.

Did ocaml 4.05.0 (now in sid and testing) solve your issue?

Also, can you still reproduct it on the new version of opam (2.0.0)?
I tried to do so and couldn't.


Best regards,

  nicoo


signature.asc
Description: PGP signature

Bug#907636: opam: "opam init" calls gringo that requires 3GB of memory

[Nicolas Braud-Santoni]

Control: tag -1 + moreinfo

Hi Samuel !

On Thu, Aug 30, 2018 at 03:30:14PM +0200, Samuel Hym wrote:
> Dear Maintainer,
> 
> I ran "opam init" on my little machine that has only 2GB of RAM and
> had to kill it after gringo had gobbled all the available memory.
> I just tried on a bigger computer to see that it peaks at 3 or 4GB,
> making it unusable on small machines.
> 
> I wondered why, and how to mitigate this: maybe gringo is not the best
> default choice for the chain of dependencies (opam -> aspcud ->
> gringo) in opam's case? Is it a bug in opam 2 (I had not noticed a
> problem with the previous version), giving a terrible problem to solve

Can you try giving the flag --use-internal-solver to opam ?

This is a bit surprising, as (according to Ralf) opam now defaults to its
internal solver, see bug #908203.


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#906258: stretch-pu: package yubico-piv-tool/1.4.2-2

[Nicolas Braud-Santoni]

Control: tag -1 - moreinfo

Hi Adam,

Sorry for getting back to you this late.


On Wed, Aug 29, 2018 at 08:21:18AM +0100, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> Why does the diff contain (and not mention):
> 
>  upstream-signing-key.pgp
> 1451 ---
>  upstream-signing-key.pgp.backup
> 1451 +++
>  upstream/signing-key.asc
> 1966 ++
> 
> ?

It seems the tags in the packaging repo do not actually match the uploads
to the archive, and I do not know why: this is a team-maintained package,
and the Yubico folks who did the original packaging (and are part of the
team) seem to have lost interest in maintaining their packages, so I have
no idea which process they were using.


It looks like something was uploaded, though:

> $ rmadison -s stable,stable-new yubico-piv-tool
> yubico-piv-tool | 1.4.2-2| stable | source, amd64, arm64, armel, 
> armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> yubico-piv-tool | 1.4.2-2+deb9u1 | stable-new | source, amd64

I assume you removed the bogus upstream-signing-key.pgp change?


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#892738: consolekit: consolekit removal causes a regression

[Michael Biebl]

On Sat,  7 Apr 2018 12:13:03 +0200 (CEST) har...@a-little-linux-box.at
wrote:
> Dear Robert, Steve and Michael,
> 
> how do you think about adding https://github.com/ConsoleKit2/ConsoleKit2 to 
> the archive as a maintained alternative to consolekit?

Looking into packaging elogind might be a more promising approach.

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



signature.asc
Description: OpenPGP digital signature

Bug#908172: switched to using fpm... help sought on next steps

[Laurent Demailly]

So I can now generate .deb package from "make release"
https://github.com/fortio/fortio/pull/302/files#diff-2842cdb8584a7666b48c3f3b225b835c

How do I get this into standard apt repositories ?

(right now it is downloadable from
https://github.com/fortio/fortio/releases
)

Thanks
Laurent

Bug#823533: allow to skip ntpdate on ifup

[Bernhard Schmidt]

Hi Christian,

>> I'm therefor proposing a complete rewrite
>>
>> - new package sntp-hooks
>>   - depends on sntp, ships hooks for ifupdown and possibly others (like
>> NetworkManager or systemd-network or whatever Ubuntu is doing now)
>>   - executes the actual sntp synchronisation non-blocking, possibly with
>> a one-shot systemd unit using --no-block when systemd is running
>> - make ntpdate depend on sntp-hooks and rm_conffile all installed hooks
>>
>> So if you don't want hooks you just don't install sntp-hooks.
>>
>> The package sntp-hooks could additionally ship an /etc/default file to
>> change behaviour.
>>
>> I have attempted to spin up some patches for this lately, but ran out of
>> time. Is this something you could agree on Ubuntu-side?
> 
> Hi Bernhard,
> first of all thanks for your participation and help!
> 
> Yes - on the isolated view to ntp* I think the proposed changes make sense.
> Now that we have sntp (back) I think it makes sense to use it instead, but as
> you already outlined that needs some extra work to behave mostly "like
> people are used from ntpdate".
> 
> I like the suggestion to make the hooks an extra package.
> And yes in Ubuntu (and any system dropping ifup/down down the road I
> guess) it will be as in [1] "How can I add pre-up, post-up, etc. hook 
> scripts?"
> Doing that in a new and non enforced package sounds great, for there
> always will be >0 people who don't want hooks to run.
> 
> I said "on the isolated view to ntp*" since most of what the ntpdate hooks
> provided is covered by systemd-timesyncd these days it is also way less
> important in most usual setups. But OTOH that provides some freedom
> not being forced to make those new sntp/hooks the total generic swiss
> army knife.
> 
> [1]: https://wiki.ubuntu.com/Netplan#Frequently-asked_questions

Sorry, I completely dropped the ball on this.

I have again looked through all the open bugs and I've come to the
conclusion that ntpdate in it's current form is probably impossible to
fix. Also I think that >90% of the current ntpdate users have it
installed for /usr/bin/ntpdate and run a real ntp daemon for timekeeping
purposes.

I've therefor proposed in Bug#908286 to just drop the hooks from ntpdate
and document this in the release notes for Buster. If we build a new
package containing sntp-hooks it should not be pulled in automatically,
even for the current ntpdate users.

IMO with systemd-timesyncd available and ntpd dealing quite well with
changing interfaces and temporarily broken connectivity on startup these
days we don't need these triggers anymore.

What do you think?

Bernhard

Bug#242629: still occurs

[Vincent Lefevre]

Control: reopen -1
Control: found -1 1:4.2.8p12+dfsg-1

For instance:

$ ntptrace -v
ntptrace - Trace peers of an NTP server - Ver. 4.2.8p12
USAGE: ntptrace [ - [] | --[{=| }] ]... [host]

-n, --numericPrint IP addresses instead of hostnames
-m, --max-hosts=num  Maximum number of peers to trace
-r, --host=str   Single remote host
-?, --help   Display usage information and exit
--more-help  Pass the extended usage text through a pager

Options are specified by doubled hyphens and their name or by a single
hyphen and the flag character.

while the man page says:

 -v [{v|c|n --version [{v|c|n}]}]
 Output version of program and exit.  The default mode
 is `v', a simple version.  The `c' mode will print
 copyright information and `n' will print the full
 copyright notice.

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

Bug#908286: Buster: Drop ifupdown-hooks from ntpdate?

[Bernhard Schmidt]

Package: ntpdate
Severity: normal

Hi Kurt (and everyone else in the BTS),

I've been going through the open bugs in the BTS again and have come to the
conclusion that the whole ifupdown triggering mechanism included in the ntpdate
package is a bug mess we're unlikely to get sorted out. It needs to be
converted to sntp. Doing that inside the ntpdate package will still have
everyone who had ntpdate installed for manual purposes run these triggered
one-shot clock synchronisations, with unknown consequences to a running sync
daemon.

Therefor I'd like to propose to

- drop all ifupdown hooks from ntpdate
- document this in ntpdate.NEWS and the Buster release notes
- if we get to it, create a new sntp-trigger (or similar) package that
  does include a very very simple one-shot sntp call only if no other
  time sync daemon is installed/running
- drop ntpdate completely from Buster+1

Comments?

Bernhard

Bug#908120: gnome-terminal: Cursor disappears when changing or moving window

[Simon McVittie]

Control: reassign -1 libgtk-3-0 3.24.0-1
Control: forwarded -1 https://gitlab.gnome.org/GNOME/gtk/issues/1316
Control: severity -1 important

On Fri, 07 Sep 2018 at 07:25:13 -0500, Ron Lovell wrote:
> Yeah, me too. Issue appeared evening of 05 Sep 2018 in Sid after a number of
> possibly relevant updates:
> GLib 2.58.0-2
> GTK 3.24.0
> GNOME Shell 3.30
> Wayland libs 1.16.0
> Mutter 3.30

This appears to be a GTK regression. Downgrading to 3.22.x from testing
brings back my cursor.

smcv

Bug#908237: libnumbertext-tools: "spellout" is not in $PATH and looks for data in the wrong places

[Stephane Chazelas]

2018-09-07 23:44:08 +0200, Rene Engelhard:
[...]
> I don't buy this: The autopkgtest of exactly the version you report it
> against:
[...]

Hi Rene,

I can reproduce on a different system. The evidences can also be
found in the source:

See 
https://sources.debian.org/src/libnumbertext/1.0-2/debian/libnumbertext-tools.install/
moving spellout from bin to lib

https://sources.debian.org/src/libnumbertext/1.0-2/debian/libnumbertext-data.install/
putting data files in usr/share/libnumbertext while
https://sources.debian.org/src/libnumbertext/1.0-2/src/spellout.cxx/#L13
expects them /usr/share/numbertext

Also https://sources.debian.org/src/libnumbertext/1.0-2/src/spellout.cxx/#L40
for the current directory being searched first (the security vulnerability).

I suppose the test tests at build time, (and may be why the tool also looks in
a "data" subdirectory of the current directory as there's one such directory in
the source tree), so doesn't try and look for the data file in their final
destination (/usr/share/numbertext != /usr/share/libnumbertext).

-- 
Stephane

Bug#907736: smartmontools: smartd starts on every boot, ignoring /etc/default/smartmontools

[Bob Bib]

Workaround:

you can comment out all uncommented lines in '/etc/smartd.conf',
and smartd will exit after starting,
without even touching any drives.

--- syslog ---
Sep  7 12:34:56 Computer1 systemd[1]: Started Self Monitoring and Reporting 
Technology (SMART) Daemon.
Sep  7 12:34:56 Computer1 smartd[2345]: smartd 6.6 2016-05-31 r4324 
[x86_64-linux-4.15.0-3-amd64] (local build)
Sep  7 12:34:56 Computer1 smartd[2345]: Copyright (C) 2002-16, Bruce Allen, 
Christian Franke, www.smartmontools.org
Sep  7 12:34:56 Computer1 smartd[2345]: Opened configuration file 
/etc/smartd.conf
Sep  7 12:34:56 Computer1 smartd[2345]: Configuration file /etc/smartd.conf 
parsed but has no entries
Sep  7 12:34:56 Computer1 smartd[2345]: Unable to monitor any SMART enabled 
devices. Try debug (-d) option. Exiting...
Sep  7 12:34:56 Computer1 systemd[1]: smartd.service: Main process exited, 
code=exited, status=17/n/a
Sep  7 12:34:56 Computer1 systemd[1]: smartd.service: Failed with result 
'exit-code'.
---

--
Best wishes,
Bob

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

[Alexis Murzeau]

Hi,

On 07/09/2018 16:57, Sébastien Villemot wrote:
> 
> I have just uploaded openblas 0.3.3+ds-1, which has TLS disabled.
> 
> I think this should fix the original issue, i.e. the gimp+openblas
> deadlock. Please let me know if this is not the case.
> 
> Best,
> 

Thanks for your update.

I tried to start gimp with this openblas version installed and it did
not crashed or hanged.

But there's still a possible crash that can occur, when I do a test that
does dl_open followed by dl_close of libopenblas, I get a segfault when
stopping the thread that does the dl_open/dl_close.

This crash doesn't seem to cause issues to gimp but might on some
machines (maybe no threads are used by gimp when indirectly loading
openblas and so the crash doesn't occur, but not sure at all).

More extensive information here: [0].

If no one object that gimp doesn't crash anymore with that 3.3 version,
maybe this bug can be closed (letting the crash of the dl_open/dl_close
test be handled by upstream only [0]).

[0] https://github.com/xianyi/OpenBLAS/issues/1720#issuecomment-418538099

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



signature.asc
Description: OpenPGP digital signature

Bug#882845: thunderbird: Thunderbird don’t want send email

[Anne C. Hanna]

On Thu, 26 Jul 2018 18:15:21 +0800 Carsten Schoenert 
wrote:

> If not already happen please disable the Thunderbird AA profile.
> 
>  $ sudo aa-disable /etc/apparmor.d/usr.bin.thunderbird
> 
> Did this "solve" your issues?
> If yes we would like to see the messages are provoked by apparmor.
> 
> https://wiki.debian.org/AppArmor/Debug

Apologies for not responding sooner.  For some reason I cannot seem to
subscribe by email to thunderbird bugs, even though I have no problem with
other packages.

In any case, yes, this problem (along with one or two others) has been
"solved" for a while now by disabling the thunderbird apparmor profile.
Unfortunately, I disabled it long enough ago that I don't have any of the
error messages available in my logs any more.

 - Anne



signature.asc
Description: OpenPGP digital signature

Bug#907940: gnome-boxes FTBFS with vala 0.42.0-1

[Michael Biebl]

Am 08.09.18 um 00:08 schrieb Andreas Henriksson:
> Control: tags -1 + pending
> 
> Hello,
> 
> The new 3.30.0 upstream release has been (mostly) perpared in git
> which should fix this issue. It is however blocked by needing a
> couple of new components packaged first (as the new version depends
> on these):
> 
> https://gitlab.gnome.org/GNOME/gtk-frdp
> 
> libovf-glib
> 
> (Posting this mostly as a status update to the bug report. Maybe jbicha
> already has a plan for these.)
> 

You can use the bundled subprojects, but currently this is broken due to
https://github.com/mesonbuild/meson/issues/4136


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



signature.asc
Description: OpenPGP digital signature

Bug#908285: RFP: cookie-autodelete -- delete cookies not used by any open tab

[Sean Whitton]

Package: wnpp
Severity: wishlist

* Package name: cookie-autodelete
  Version : 2.2.0
  Upstream Author : Name 
* URL : https://github.com/Cookie-AutoDelete/Cookie-AutoDelete
* License : MIT
  Programming Lang: JavaScript webext
  Description : delete cookies not used by any open tab

This is a useful replacement for xul-ext-self-destructing-cookies, which
doesn't work with the new Firefox ESR 60.0.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#907940: gnome-boxes FTBFS with vala 0.42.0-1

[Andreas Henriksson]

Control: tags -1 + pending

Hello,

The new 3.30.0 upstream release has been (mostly) perpared in git
which should fix this issue. It is however blocked by needing a
couple of new components packaged first (as the new version depends
on these):

https://gitlab.gnome.org/GNOME/gtk-frdp

libovf-glib

(Posting this mostly as a status update to the bug report. Maybe jbicha
already has a plan for these.)

Regards,
Andreas Henriksson

Bug#908284: thunderbird: Drag-and-drop of emails from the listings pane has become nearly unusable due to changed "drag icon" style

[Anne C. Hanna]

Package: thunderbird
Version: 1:60.0-3
Severity: normal

Dear Maintainer,

In recent versions of Thunderbird (I'm not exactly certain when this started),
there has been a change in the style of the "drag icon" that appears when
attempting to select individual email messages from the listings pane.  This
change has made it very difficult to use drag-and-drop to move messages
between folders, e.g., when sorting and filing the contents of my inbox.

It used to be that if I wished to take several messages from one folder and
move them to another, I could select the desired messages in the email
listings pane, then click and drag to the desired folder in the folder pane.
While I was doing this, the cursor changed (if I remember correctly) to a
closed fist or something like that, but it was still only cursor-sized, so it
was possible to see which folder name I was hovering over and confirm that the
correct one was highlighted before I "dropped" the messages into that folder.

Now, when I click and drag, my little closed fist cursor floats in the middle
of a huge rectangle containing slightly miniaturized images of the subject
lines and to/from information and so forth (everything visible in the email
listings pane) for all the emails that I've selected.  If, when I click to
begin my click-and-drag, the cursor is centered in the middle of the desired
block of emails, the cursor will be in the center of this huge rectangle as
well.  Thus, when I hover over the folder pane to attempt a drop, the giant
block completely obscures the folder names and I cannot tell whether I am
dropping the emails into the correct folder.

I can sort of work around this by very carefully beginning my click-and-drag
from one of the corners of the desired block of emails, but it's still very
hard to see what I'm doing.  The only alternative is to right-click, choose
"Move To", and page through the folder tree in the right-click menu.  This
works, but it is irritating to have to change my workflow.

Please revert the click-and-drag icon for this case to a simple closed-fist
cursor or something similarly cursor-sized, so that it will be usable again.
If this is not desired, an alternative would be to force the giant rectangle
showing what's being dragged to snap to a specific fixed position relative to
the cursor point, so that the cursor point will always be slightly outside of
one of the corners of the rectangle and what it is hovering over can be
clearly seen.  As a last resort, some level of transparency applied to the
drag icon might at least mitigate the issue.

 - Anne


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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6
ii  fontconfig2.13.0-5
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-6
ii  libcairo-gobject2 1.15.12-1
ii  libcairo2 1.15.12-1
ii  libdbus-1-3   1.12.10-1
ii  libdbus-glib-1-2  0.110-3
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.13.0-5
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.2.0-5
ii  libgdk-pixbuf2.0-02.36.12-2
ii  libglib2.0-0  2.58.0-2
ii  libgtk-3-03.24.0-1
ii  libgtk2.0-0   2.24.32-3
ii  libhunspell-1.6-0 1.6.2-1+b1
ii  libicu60  60.2-6
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.19-3
ii  libnss3   2:3.38-1
ii  libpango-1.0-01.42.4-3
ii  libpangocairo-1.0-0   1.42.4-3
ii  libpangoft2-1.0-0 1.42.4-3
ii  libsqlite3-0  3.24.0-1
ii  libstartup-notification0  0.12-5
ii  libstdc++68.2.0-5
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.6-1
ii  libx11-xcb1   2:1.6.6-1
ii  libxcb-shm0   1.13-3
ii  libxcb1   1.13-3
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc23.1-1+b1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  lightning   1:60.0-3
ii  myspell-en-us [myspell-dictionary]  1:3.3.0-4

Versions of packages thunderbird suggests:
ii  apparmor  2.13-8
ii  fonts-lyx 2.3.0-2
ii  libgssapi-krb5-2  1.16-2

-- no debconf information

Bug#908237: libnumbertext-tools: "spellout" is not in $PATH and looks for data in the wrong places

[Rene Engelhard]

tag 908237 + moreinfo
tag 908237 + unreproducible
thanks

Hi,

On Fri, Sep 07, 2018 at 11:44:08PM +0200, Rene Engelhard wrote:
> > Also:
> > 
> > $ /usr/lib/libnumbertext/spellout -l en 101
> > spellout: missing language module
> [...]
> 
> I don't buy this: The autopkgtest of exactly the version you report it
> against:
> 
> autopkgtest [16:42:00]: test command1: if [
> "`/usr/lib/libnumbertext/spellout -l en 123`" != "one hundred
> twenty-three" ]; then echo "Invalid spellout of 123 for en." >&2; exit
> 1; else exit 0; fi
> autopkgtest [16:42:00]: test command1: [---
> autopkgtest [16:42:01]: test command1: ---]
> autopkgtest [16:42:01]: test command1:  - - - - - - - - - - results - -
> - - - - - - - -
> command1 PASS
> 
> I've no idea what you did, but you apparently did it wrong.

$ sudo chroot /data/pbuilder/build/sid /usr/lib/libnumbertext/spellout
-l en 123
[sudo] Passwort für rene: 
spellout: missing language module

Hmm. Interesting.

Regards,
 
Rene

Bug#908202: tryton-server: Install fails during configuration

[Mathias Behrle]

control: severity -1 normal

* Alexander Senger: " Bug#908202: tryton-server: Install fails during
  configuration" (Fri, 07 Sep 2018 12:31:30 +0200):

Hello Alexander,

> Package: tryton-server
> Version: 4.6.7-1+dto~9stretch+1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> I attempt to install a newer version of tryton-server from debian.tryton.org
> which seems to be maintained by Debian maintainer yangoon.
> 
> After adding the appropriate sources.list, issuing a
> 
> $ apt-get install tryton-server
> 
> works smoothly until tryton-server is about to be configured. The
> configuration fails with:
> 
> > tryton-server (4.6.7-1+dto~9stretch+1) wird eingerichtet ...
> > update-rc.d: error: no runlevel symlinks to modify, aborting!
> > dpkg: Fehler beim Bearbeiten des Paketes tryton-server (--configure):
> > Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1
> > zurück Fehler traten auf beim Bearbeiten von:
> > tryton-server
> > E: Sub-process /usr/bin/dpkg returned an error code (1)  
> 
> Subsequent attempts to install necessary modules (tryton-modules) fails due
> to the unfinished configuration of tryton-server, rendering tryton
> unusablyt

Thanks for your interest in Tryton. 

Did I understand correctly, that you tried to upgrade a previous version of
tryton-server?

Cheers,
Mathias

PS: Downgrading the severity of the issue, because packages from
debian.tryton.org are neither official nor does this issue make the whole
package unusuable.

-- 

Mathias Behrle ✧ Debian Developer
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6


pgpH2V9eUufZ3.pgp
Description: Digitale Signatur von OpenPGP

Bug#908237: libnumbertext-tools: "spellout" is not in $PATH and looks for data in the wrong places

[Rene Engelhard]

tag 908237 + moreinfo
tag 908237 + unreproducible
thanks

Hi,

On Fri, Sep 07, 2018 at 05:47:54PM +0100, Stephane Chazelas wrote:
> The tool is meant to be invoked by the end user, but is not
> located in a directory in $PATH. I would expect it to go in
> /usr/bin (and have a corresponding man page in
> /usr/share/man/man1).

Fair point,

> Also:
> 
> $ /usr/lib/libnumbertext/spellout -l en 101
> spellout: missing language module
[...]

I don't buy this: The autopkgtest of exactly the version you report it
against:

autopkgtest [16:42:00]: test command1: if [
"`/usr/lib/libnumbertext/spellout -l en 123`" != "one hundred
twenty-three" ]; then echo "Invalid spellout of 123 for en." >&2; exit
1; else exit 0; fi
autopkgtest [16:42:00]: test command1: [---
autopkgtest [16:42:01]: test command1: ---]
autopkgtest [16:42:01]: test command1:  - - - - - - - - - - results - -
- - - - - - - -
command1 PASS

I've no idea what you did, but you apparently did it wrong.

Regards,

Rene

Bug#908087: Bug#908131: forcibly merging 908087 908131

[Vincent Lefevre]

On 2018-09-07 19:08:10 +0200, Salvatore Bonaccorso wrote:
> Hi Thorsten,
> 
> On Fri, Sep 07, 2018 at 04:44:54PM +0200, Thorsten Glaser wrote:
> > Hi Salvatore,
> > 
> > > forcemerge 908087 908131
> > 
> > I don’t think these are the same bug.
> 
> Ah right, so let's unmerge thos again. Sorry for the wrong merge then.

I disagree. Both behaviors are caused by the same issue in
python3-pysimplesoap. These behaviors are different just because the
users chose different interfaces in their reportbug configuration.

With "ui text": One gets a failure, but one can report the bug.

With "ui gtk2": One gets a failure, and reportbug terminates.
Workaround: switch to "ui text" in the ~/.reportbugrc file.

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

Bug#907906: stretch-pu: package openssl/1.1.0f-3+deb9u2

[Kurt Roeckx]

On Tue, Sep 04, 2018 at 04:41:32PM +0200, Moritz Mühlenhoff wrote:
> 
> (I've been deploying customs debs of the 1.0.2x and 1.1.0x openssl releases
> at work and I haven't run into any compatibility issues/API issues during
> that).

We should really do upload all the latest point releases to all
supported branches.


Kurt

Bug#908283: [debian-reference-en] Command requires root privileges

[Sergiy Kolesnikov]

Package: debian-reference-en
Version: 2.68
Severity: minor
Tags: patch

--- debian-reference.en.txt2018-09-07 20:44:10.995972631 +0200
+++ debian-reference.en.txt.patched2018-09-07 20:44:48.933054004 +0200
@@ -7044,7 +7044,7 @@
# apt-get update
 # apt-get dist-upgrade
 # apt-get install fakeroot devscripts build-essential
-$ apt-get build-dep foo
+# apt-get build-dep foo
 $ apt-get source foo
 $ cd foo*

--- System information. ---
Architecture:
Kernel:   Linux 4.9.0-8-amd64

Debian Release: 9.5
  700 stable  security.debian.org
  700 stable  ftp.de.debian.org
  500 stretch download.docker.com
  500 stable-updates  ftp.de.debian.org
  500 proposed-updates ftp.de.debian.org
  100 stretch-backports ftp.de.debian.org

--- Package information. ---
Depends  (Version) | Installed
==-+-===
debian-reference-common  (>= 2.51) | 2.68


Package's Recommends field is empty.

Suggests  (Version) | Installed
===-+-===
doc-base|

Bug#908220: [pkg-cryptsetup-devel] Bug#908220: cryptsetup-initramfs: Need a clean way to force cryptsetup in initramfs

[Raphael Hertzog]

Hi,

On Fri, 07 Sep 2018, Guilhem Moulin wrote:
> >   update-initramfs: Generating /boot/initrd.img-4.17.0-kali3-amd64
> >   cryptsetup: WARNING: Couldn't determine root device
> >   cryptsetup: ERROR: Couldn't resolve device /dev/sdb4
> >   cryptsetup: WARNING: The initramfs image may not contain cryptsetup 
> > binaries 
> > nor crypto modules. If that's on purpose, you may want to uninstall the 
> > 'cryptsetup-initramfs' package in order to disable the cryptsetup 
> > initramfs 
> > integration and avoid this warning.
> 
> Do you have the proc(5) and sysfs(5) pseudo-filesystems respectively
> mounted to /proc and /sys?  The “WARNING: Couldn't determine root
> device” suggests it's either not the case, or that the file system
> holding / is not backed up by a block device (eg, ZFS).  Can you share
> what /proc/mounts contains before you type `update-initramfs -u`?

I don't think this is relevant, at this point live-build is just
installing packages in a chroot. The end result is an ISO image...
there's no associated device. It can be copied on a DVD or burnt
on an USB key.

> How do you unlock that disk at initramfs stage?  Using a custom boot
> script, or by typing a `cryptsetup open --type=luks` command manually?
> Or do you rely on our own (‘cryptroot’) initramfs boot script?

live-boot rebuilds the initramfs image and hooks itself in the process,
it does manually open all luks containers:

open_luks_container() is the way to open the luks partitition:
https://salsa.debian.org/live-team/live-boot/blob/master/components/9990-misc-helpers.sh#L830

find_persistence_media() is the place where all partititions
are scanned for luks:
https://salsa.debian.org/live-team/live-boot/blob/master/components/9990-misc-helpers.sh#L1043

> Adding the cryptsetup binaries to the initramfs image might not be
> sufficient, especially if the initramfs image isn't compiled with
> MODULES="most".  That's why we warn the user that modules might me
> missing if auto detection fails to determine which device(s) need to be
> unlocked at initramfs stage and/or which modules are required to map the
> crypt devices.  Failure to unlock the root device is arguably worse than
> false positives.

This is not so much a problem for us because the use case is always to add
an encrypted partition after the ISO image copied onto an USB key. We
don't need any special driver.

> Before the package split (cf. #783297 and #813220) users could add
> CRYPTSETUP=n to disable initramfs integration.  As the warning suggests
> we're deprecating this; we'll remove the warning once buster is
> released, instead installing cryptsetup-initramfs will silently trigger
> execution of our initramfs hook scripts.

Can't you just trigger the warning only when CRYPTSETUP=n? If it's set to "y",
it doesn't match the old use case... it just means that we want to enable
it.

> 
> But for said hook scripts to work reliably, the device needs to present
> and mapped (unlocked) when the initramfs image is built.  Otherwise, as
> I wrote above, the hook doesn't know which crypto modules need to be
> present in the image.  Moreover, the device needs to have an entry in
> the crypttab(5) to pass suitable options (--type, --header, etc.) to
> `cryptsetup open`.  In order to force a device to be considered at
> initramfs stage, you can add the ‘initramfs’ to its crypttab(5) entry.

We don't have any crypttab in our case, we just scan all partitions and
try opening them with default options (just passing the key). We can't
have any device present when the initramfs is generated... because the
encrypted partition gets added later by the user, not by us who are
generating the ISO image. We just want that cryptsetup continues to use
the sane defaults that it has been using up to now and we want to be able
to force its installation into the initrd.

If options were one day really needed, we would alter live-boot to
forward options supplied by the user on the kernel command line, but we
never had the case up to now.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#908280: procps: [free] conversion wrong for metric prefixes bigger than kilo

[Henryk Iwaniuk]

Package: procps
Version: 2:3.3.12-3+deb9u1
Severity: normal
Tags: upstream patch

Dear Maintainer,
The output of free --mega, --giga and up are erroneous. I could reproduce this
error on stretch and jessie.
Free takes the values in /proc/meminfo, where the units are wrongly labled. 
They 
are in KiB, so you have to multiply by 1024 to get the bytes amount. For some 
reason
this was done for -b and --kilo, but not for other units.
To calculate --mega, free takes the value in KiB and divides by 1000, which 
makes 
little sense. This error carried over to the dejagnu tests.
Attached you will find a patch for both free.c and the dejagnu tests, which I 
have
taken from upstream. This problem is fixed in upstream version 3.3.15 as far as 
I can tell.

Have a nice day.

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

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

Versions of packages procps depends on:
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u3
ii  libncurses5  6.0+20161126-1+deb9u2
ii  libncursesw5 6.0+20161126-1+deb9u2
ii  libprocps6   2:3.3.12-3+deb9u1
ii  libtinfo56.0+20161126-1+deb9u2
ii  lsb-base 9.20161125

Versions of packages procps recommends:
ii  psmisc  22.21-2.1+b2

procps suggests no packages.

-- no debconf information
--- a/free.c
+++ b/free.c
@@ -130,18 +130,12 @@
snprintf(buf, sizeof(buf), "%lld", ((long long 
int)size) * 1024);
return buf;
}
-   if (args.exponent == 2) {
-   if (!(flags & FREE_SI))
-   snprintf(buf, sizeof(buf), "%ld", size);
-   else
-   snprintf(buf, sizeof(buf), "%ld", (long 
int)(size / 0.9765625));
-   return buf;
-   }
-   if (args.exponent > 2) {
+   if (args.exponent > 1) {
/* In desired scale. */
snprintf(buf, sizeof(buf), "%ld",
-(long int)(size / power(base, args.exponent - 
2))
+(long int)(size * 1024.0 / power(base, 
args.exponent - 1))
);
+
return buf;
}
}
@@ -172,11 +166,11 @@
case 6:
if (4 >=
snprintf(buf, sizeof(buf), "%.1f%c",
-(float)(size / power(base, i - 2)), *up))
+(float)(size * 1024 / power(base, i - 1)), 
*up))
return buf;
if (4 >=
snprintf(buf, sizeof(buf), "%ld%c",
-(long)(size / power(base, i - 2)), *up))
+(long)(size * 1024 / power(base, i - 1)), 
*up))
return buf;
break;
case 7:
--- a/testsuite/free.test/free.exp
+++ b/testsuite/free.test/free.exp
@@ -19,12 +19,12 @@
 spawn $free -b
 expect_pass "$test" 
"^${free_header}Mem:\\s+${memtotal}\\s+\\d+\\s+\\d+\\s+\\d+\\s+\\d+\\s+\\d+\\s*Swap:\\s+${swaptotal}\\s+\\d+\\s+\\d+\\s*"
 
-foreach {arg divisor } {-k 1 -m 1024 -g 1048576 --mega 1000 --giga 100 } {
+foreach {arg divisor } {-k 1024 -m 1048576 -g 1073741824 --kilo 1000 --mega 
100 --giga 10 } {
 set test "free with $arg argument"
-set memtotal [ expr { $memtotal_kb / $divisor } ]
-set swaptotal [ expr { $swaptotal_kb / $divisor } ]
+set memtest [ expr { $memtotal / $divisor } ]
+set swaptest [ expr { $swaptotal / $divisor } ]
 spawn $free $arg
-expect_pass "$test"  
"^${free_header}Mem:\\s+$memtotal\\s+\\d+\\s+\\d+\\s+\\d+\\s+\\d+\\s+\\d+\\s*Swap:\\s+${swaptotal}\\s+\\d+\\s+\\d+\\s*"
+expect_pass "$test"  
"^${free_header}Mem:\\s+$memtest\\s+\\d+\\s+\\d+\\s+\\d+\\s+\\d+\\s+\\d+\\s*Swap:\\s+${swaptest}\\s+\\d+\\s+\\d+\\s*"
 }
 
 #set test "free with human readable output"

Bug#826994: new release

[Chris Zubrzycki]

ZFS 0.7.10 was just released. Could we please get sysvinit scripts into this 
one?

https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.7.10

Bug#908279: lua-torch-image: FTBFS (TH.h: No such file or directory)

[Santiago Vila]

Package: src:lua-torch-image
Version: 0~20170420-g5aa1881-6
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-arch
dh build-arch --buildsystem=lua --with lua
   dh_update_autotools_config -a -O--buildsystem=lua
   dh_autoreconf -a -O--buildsystem=lua
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
ln -s . image
dh_auto_configure
make --no-print-directory -f 
/usr/share/dh-lua/make/dh-lua.Makefile.multiple configure

Making target configure for debian/lua5.1.dh-lua.conf
# .install
Filling in debian/lua-torch-image.install using 
/usr/share/dh-lua/template/lib.install.in
Adding new line: usr/lib/x86_64-linux-gnu/lua/5.1/libimage.so
Adding new line: usr/lib/x86_64-linux-gnu/liblua5.1-torch-image.so.*
Adding new line: usr/share/lua/5.1/image/init.lua
Adding new line: usr/share/lua/5.1/image//test.lua
Filling in debian/lua-torch-image-dev.install using 
/usr/share/dh-lua/template/dev.install.in
Adding new line: usr/lib/x86_64-linux-gnu/liblua5.1-torch-image.so
Adding new line: usr/lib/x86_64-linux-gnu/liblua5.1-torch-image.a
Adding new line: usr/lib/x86_64-linux-gnu/pkgconfig/lua5.1-torch-image.pc
Adding new line: usr/include/lua5.1/lua-torch-image.h
# lua_versions
Filling in debian/lua_versions
Adding new line: 5.1
Target configure made

make[1]: Leaving directory '/<>'
   dh_auto_build -a -O--buildsystem=lua
make --no-print-directory -f 
/usr/share/dh-lua/make/dh-lua.Makefile.multiple build

Making target build for debian/lua5.1.dh-lua.conf
libtool --silent --tag=CC --mode=compile cc -c -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr//include/lua5.1 -I/<> -I/<>/generic 
-I/usr/include/TH/ -DHAVE_JPEG_MEM_SRC -DHAVE_JPEG_MEM_DEST -Wall -Wextra -o 
/<>/5.1-torch-image/ppm.lo ppm.c 
X/<>/5.1-torch-image/ppm.lo
libtool: warning: libobj name '/<>/5.1-torch-image/ppm.lo' may not 
contain shell special characters.
ppm.c:2:10: fatal error: TH.h: No such file or directory
 #include 
  ^~
compilation terminated.
make[2]: *** [/usr/share/dh-lua/make/dh-lua.Makefile.single:436: 
/<>/5.1-torch-image/ppm.lo] Error 1
make[1]: *** [/usr/share/dh-lua/make/dh-lua.Makefile.multiple:12: build] Error 1
dh_auto_build: make --no-print-directory -f 
/usr/share/dh-lua/make/dh-lua.Makefile.multiple build returned exit code 2
make: *** [debian/rules:7: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


That's from my autobuilder, but it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/lua-torch-image.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#908068: Attempted fix 2

[Boris Bobrov]

Pull request https://github.com/micahflee/torbrowser-launcher/pull/343
is required to make it run. After i applied the change, everything
worked for me.

Bug#908278: ITP: libimagequant -- palette quantization library (development files)

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: libimagequant
  Version : 2.12.1
  Upstream Author : Kornel Lesiński 
* URL : https://github.com/ImageOptim/libimagequant
* License : GPL-3.0+
  Programming Lang: C
  Description : palette quantization library (development files)
 Small, portable C library for high-quality conversion of RGBA
 images to 8-bit indexed-color (palette) images.
 .
 This library powers pngquant and other PNG optimizers.

Remark: This package is maintained by Debian PhotoTools Maintainers at
   https://salsa.debian.org/debian-phototools-team/libimagequant

This package was originally prepared by Herbert Parentes Fortes Neto
 in Git but there was no ITP for the package.  Since
I intend to upgrade pngquant which needs this library I polished the
package and send the ITP.  Herbert, please let me know if I missed
something.

Bug#908277: wtforms: FTBFS (failing tests)

[Santiago Vila]

Package: src:wtforms
Version: 2.1-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --with sphinxdoc,python2,python3 --buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python2.7 setup.py config 
running config
I: pybuild base:217: python3.6 setup.py config 
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build
I: pybuild base:217: /usr/bin/python setup.py build 
running build
running build_py

[... snipped ...]

make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
python-coverage run tests/runtests.py
### Disabled test 'ext_django.tests', dependency not found
..FF.
==
FAIL: test_formatting (locale_babel.TestLocaleDecimal)
--
Traceback (most recent call last):
  File "/<>/tests/locale_babel.py", line 49, in test_formatting
self._format_test("-12'345.2", '-12345.2', ['de_CH'])
  File "/<>/tests/locale_babel.py", line 23, in _format_test
self.assertEqual(form.a._value(), expected)
AssertionError: u'-12\u2019345.2' != u"-12'345.2"
- -12\u2019345.2
?^
+ -12'345.2
?^


==
FAIL: test_parsing (locale_babel.TestLocaleDecimal)
--
Traceback (most recent call last):
  File "/<>/tests/locale_babel.py", line 77, in test_parsing
self._parse_test("1'23'456.789", expected, ['de_CH'])
  File "/<>/tests/locale_babel.py", line 59, in _parse_test
raw_val, form.a.errors,
AssertionError: Expected value u"1'23'456.789" to parse as a decimal, instead 
got [u'Keine g\xfcltige Dezimalzahl']

--
Ran 177 tests in 0.379s

FAILED (failures=2)
make[1]: *** [debian/rules:12: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:9: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


That's from my autobuilder, but it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/wtforms.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#908177: evince: Rename of desktop file from evince.desktop to org.gnome.Evince.desktop breaks MIME/mailcap ordering (PDFs open with gimp)

[Josh Triplett]

On Fri, Sep 07, 2018 at 10:07:08AM +0200, Michael Biebl wrote:
> Am 07.09.18 um 09:07 schrieb Josh Triplett:
> > On Fri, Sep 07, 2018 at 06:22:06AM +0200, Michael Biebl wrote:
> >> Am 07.09.18 um 05:49 schrieb Josh Triplett:
> >>> Package: evince
> >>> Version: 3.30.0-1
> >>> Severity: important
> >>>
> >>> evince 3.30 renamed the desktop file from evince.desktop to
> >>> org.gnome.Evince.desktop. update-mime, the tool to generate
> >>> /etc/mailcap, processes desktop files in order by name. Because of this
> >>> rename, GIMP now has a higher priority for PDF and PostScript files than
> >>> Evince does, causing mutt and similar to open PDF and PostScript files
> >>> with GIMP by default.
> >>
> >> What would you suggest should be done about this?
> >> Renaming the desktop file back to evince.desktop is not really an option.
> > 
> > I'm not proposing that (though I'm curious what makes that particularly
> > painful). We need *some* solution though. That this happened to work
> > out of the box before was effectively a coincidence based on "evince"
> > sorting before "gimp".
> > 
> > I don't know what the *ideal* solution looks like.
> > 
> > One short-term approach would be to introduce some kind of simplistic 
> > priority
> > scheme in desktop files via an X- header that update-mime reads, and
> > have evince and/or GIMP use that (and perhaps declare a Breaks for older
> > mime-support).  Effectively, this would introduce a concept of "this
> > application supports this MIME type but should never end up as the
> > primary tool a user wants to use to open it", versus "it's plausible
> > that this could be the primary tool a user uses to open this MIME type".
> > That would solve the problem of ending up with something like GIMP as
> > the primary PDF opener, though it doesn't solve the long-term issue of
> > ending up with the wrong tool for your preferred environment (e.g.
> > evince vs okular).
> 
> /etc/mailcap is very unflexible in that regard and I'm not sure it's
> fixable.

All we need is a way to control the order or priority of entries in
mailcap.

> Maybe a better solution would be if tools moved away from using
> /etc/mailcap. Could mutt be taught to use xdg-open?

Perhaps; mutt certainly seems like the most prominent remaining user of
mailcap. xdg-open wouldn't handle everything mutt uses mailcap for (it
also uses mailcap to turn some formats to text and view them inline),
but it couldn't hurt.

But meanwhile, anything depending on mailcap via mime-support (which
does currently include mutt) won't handle PDFs correctly.

Bug#908276: gitlab-runner: Depends: or Recommends: xz-utils is missing

[Birger Schacht]

Package: gitlab-runner
Version: 11.0.0+dfsg-2
Severity: normal

Dear Maintainers,

the shipped script /usr/lib/gitlab-runner/mk-prebuilt-images.sh uses the
`xz` binary, which is part of xz-utils. gitlab-runner should thus depend
on or at least recommend the package xz-utils.
If xz-utils is not installed, the script errors out:
> I: Generating GitLab Runner Docker image. This may take a while...
> I: cdebootstrap; saving build log to
/var/cache/gitlab-runner/cdebootstrap.log |
> /bin/sh: 1: xz: not found
> tar: stable.tar.xz: Wrote only 4096 of 10240 bytes
> tar: Child returned status 127
> tar: Error is not recoverable: exiting now

cheers,
bisco



signature.asc
Description: OpenPGP digital signature

Bug#908079: Buster: No window title bars in KDE?

[Martin Steigerwald]

local10 - 07.09.18, 16:12:
> Sep 7, 2018, 8:18 AM by mar...@lichtvoll.de:
> > It does recommend kwin-x11 by depending on kde-plasma-desktop which
> > depends on plasma-desktop which recommends kwin-x11 (>= 4:5.13) |
> > kwin
> I do not install recommended packages, only what's necessary. However,
> if the system cannot function properly without a package it's a
> requirement, not a recommendation.

local10, a bug report is really not the right place to discuss Debian 
packaging policy:

> Recommends
> 
> This declares a strong, but not absolute, dependency.
> 
> The Recommends field should list packages that would be found
> together with this one in all but unusual installations.

https://www.debian.org/doc/debian-policy/ch-relationships.html

If you choose not to install recommends which is perfectly your choice 
you get to deal with the consequences. Installing them is default for a 
reason.

If you really want to challenge this policy, then I suggest you post to 
debian-devel, but then you better have a very good explanation for using 
a depends on packages like kwin-x11 while systems can and do work 
perfectly fine without them.

Thanks,
-- 
Martin

Bug#908195: openssh-server: agent forwarding broken in incoming ssh connections

[Timo Weingärtner]

Hallo Giacomo Mulas,

07.09.18 11:09 Giacomo Mulas:
> Package: openssh-server
> Version: 1:7.8p1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> with the recent updates of openssh, agent forwarding is broken in incoming
> connections.  It still works properly in outgoing connections, which I
> tested by logging in on several computers running e.g.  debian stable or
> other distros or even another os altogether.  However, when I try to connect
> from other machines to my computer, or even upon using locah ssh to
> localhost, no credentials are forwarded.
> E.g., on the session from which I use ssh:
> 
> gmulas@spitzer:~$ ssh-add -l
> 2048 SHA256:1EiqSAb6gUEpa27SrPhpx2lbj0I2yjz6TWO6HgUuFO4
> /homes/spitzer/gmulas/.ssh/id_rsa (RSA) 1024
> SHA256:bcMLBbvPfsCMMYUkXJYLljsNsBhpkC3N//38mnObjIw
> /homes/spitzer/gmulas/.ssh/id_dsa (DSA) 256
> SHA256:GdCSZj0SYfo3XgnGAEfaFVJSjqzGuHAq01oYpG5HNEA
> /homes/spitzer/gmulas/.ssh/id_ecdsa (ECDSA)
> 
> then I successfully login to my laptop using one of those keys, with
> 
> ssh -A capitanata
> 
> but if I then ask which credentials are available I get:
> 
> gmulas@capitanata:~$ ssh-add -l
> The agent has no identities.

So the connection to some ssh-agent is working. Please check which process 
owns the socket pointed to by $SSH_AUTH_SOCK. If it is not sshd you have 
another problem; perhaps something like libpam-ssh is starting a new ssh-agent 
for your ssh session?


Grüße
Timo

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

Bug#908179: pkgsel: [INTL:fr] French debconf translation update

[Holger Wansing]

Control: tags -1 + pending

Alban Vidal  wrote:
> Package: pkgsel
> Version: 0.58
> Severity: wishlist
> Tags: patch l10n
> 
> 
> Dear Maintainer,
> 
> Please find attached the French debconf templates update, proofread by the
> debian-l10n-french mailing list contributors.

Committed to git. Thanks


Tagging this bug as pending


-- 

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

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

Bug#908178: tasksel: [INTL:fr] French debconf translation update

[Holger Wansing]

Control: tags -1 + pending

Alban Vidal  wrote:
> Package: tasksel
> Version: 3.45
> Severity: wishlist
> Tags: patch l10n
> 
> Dear Maintainer,
> 
> Please find attached the French debconf templates update, proofread by the
> debian-l10n-french mailing list contributors.

Committed to git. Thanks


Tagging this bug as pending


-- 

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

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

Bug#908275: dbus-test-runner FTBFS with glib 2.58

[Adrian Bunk]

Source: dbus-test-runner
Version: 16.10.0~bzr100+repack1-3
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dbus-test-runner.html

...
bustle.c: In function 'dbus_test_bustle_class_init':
bustle.c:61:2: error: 'g_type_class_add_private' is deprecated 
[-Werror=deprecated-declarations]
  g_type_class_add_private (klass, sizeof (DbusTestBustlePrivate));
  ^~~~
In file included from /usr/include/glib-2.0/gobject/gobject.h:24,
 from /usr/include/glib-2.0/gobject/gbinding.h:29,
 from /usr/include/glib-2.0/glib-object.h:23,
 from ../libdbustest/task.h:28,
 from dbus-test.h:29,
 from bustle.c:26:
/usr/include/glib-2.0/gobject/gtype.h:1303:10: note: declared here
 void g_type_class_add_private   (gpointerg_class,
  ^~~~
...

Bug#908158: [Pkg-mozext-maintainers] Bug#908158: webext-ublock-origin: xul-ext-ublock-origin and webext-ublock-origin should co-exist

[Markus Koschany]

Am 07.09.2018 um 21:38 schrieb Mykola Nikishov:
> Carsten Schoenert  writes:
[...]

> What am I missing?

At least

/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/ublo...@raymondhill.net

exists in both packages. That means if you try to install both packages
at the same time dpkg would refuse. Your system would be left in an
inconsistent state and that is a serious bug in Debian.

The xul-* packages will be useless as soon as the new Firefox ESR
version enters stable. It is absolutely correct how it is implemented at
the moment. We simply do not support a use case where you can have a
version of Firefox installed that supports xul extensions and another
Firefox version that supports webext extensions at the same time.

I may backport the ublock-origin webextension to stable but xul- and web
extensions will never be co-installable in Debian.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#908092: dbus: skip autopkgtest ulimit test when in a container

[Steve Langasek]

On Fri, Sep 07, 2018 at 08:46:23PM +0100, Simon McVittie wrote:
> On Wed, 05 Sep 2018 at 22:02:01 -0700, Steve Langasek wrote:
> > This is because armhf is the single architecture on which Ubuntu runs its
> > autopkgtests in containers rather than in VMs, and these are unprivileged
> > containers, which means "root" processes don't actually have the
> > capabilities necessary to re-raise limits after they've been lowered.

> I'm not sure whether such a container should be considered to satisfy the
> needs-root restriction. How much root does/should needs-root guarantee?

FWIW this particular capability restriction hasn't been a problem for any
other needs-root packages before now, that I've seen.

> Perhaps there should be separate restrictions for "needs fully privileged
> root" and "needs unprivileged-container root"? (But I'm not sure which
> one needs-root should be.)

> > I've uploaded the attached patch to Ubuntu in order to have passing tests
> > again on armhf.  I'm not sure if you would consider it sufficiently correct
> > for Debian, since this means we're also skipping this test on privileged
> > containers, but I guess it should be a starting point for discussion.
> 
> Can we probe for the required capability, perhaps with

> capsh | grep '^Current:.*\'

> or something?

Not sure about that syntax, but anyway here's what I see:

# capsh --print | grep ^Current:.*\\bcap_sys_resource\\b
Current: = 
cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read+ep
# ulimit -n 1024
# ulimit -n 4096
bash: ulimit: open files: cannot modify limit: Operation not permitted
#

So it looks like the kernel lies about the capability as well.

You could do a probe with sh before running the actual test, e.g.:

  sh -c ulimit -n 1024; ulimit -n 4096' || skip_ulimits

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#908153: gnome-shell: [regression] frequent crashes on g-s 3.30

[Simon McVittie]

Control: tags -1 + moreinfo

On Thu, 06 Sep 2018 at 12:41:38 -0500, Andreas Kloeckner wrote:
> This is the stack trace I get:
...
>  #6  0x7f1c8866938a 
> g_assertion_message_expr (libglib-2.0.so.0)

You should see an assertion failure in the systemd journal just before
gnome-shell aborts. What is it?

Is there any correlation with what you are doing, like an action that
sometimes or always triggers the crash?

Would it be possible to install systemd-coredump and some relevant-looking
-dbgsym packages (at least mutter, gtk and GLib), reproduce this crash,
and use coredumpctl to get a more complete backtrace?

Thanks,
smcv

Bug#908155: Coordination with upstream developers not universally applied

[Wouter Verhelst]

On Fri, Sep 07, 2018 at 02:14:15PM +0100, Ian Jackson wrote:
> Wouter Verhelst writes ("Bug#908155: Coordination with upstream developers 
> not universally applied"):
> > To me, the core message of the current text is that you should ensure
> > that bug reports which are not Debian-specific end up with upstream,
> > *somehow*, whether by the maintainers forwarding it to upstream
> > themselves or by them asking the reporter to do so. Your proposed new
> > text weakens that, and I think that's not a good idea.
> 
> How about this
> 
>These bug reports should be forwarded to the upstream developers so
>that they can be fixed in a future upstream release.  Usually it is
>best if you can do this, but alternatively, you may ask the bug
>submitter to do it.

I think that's better, yes.

It doesn't incorporate my other suggestion about bts-link, though. How about 
this:

   In cases where a bug report is forwarded upstream, it may be helpful
   to remember that the bts-link service can help with synchronizing
   states between the upstream bug tracker and the Debian one.

?

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#541642: Bug#541621: man-db: man fails if IFS exists and doesn't contain a white space

[Sven Joachim]

Control: tags -1 fixed-upstream

On 2009-08-15 08:12 +0100, Colin Watson wrote:

> clone 541621 -1
> reassign -1 dash
> retitle -1 dash: ignore value of IFS from environment?
> severity -1 wishlist
> tags 541621 pending
> thanks
>
> On Fri, Aug 14, 2009 at 06:42:19PM -0500, Raphael Geissert wrote:
>> When the IFS env var exists man doesn't show anything at all if it doesn't 
>> contain a white space. Examples follow:
>> 
>> $ PAGER=wc man man
>> 5264401   39336
>> $ PAGER=wc IFS= man man
>>   0   0   0
>> $ PAGER=wc IFS=' ' man man
>> 5264401   39336
>> 
>> As mentioned during DC9, an easy way to fix the problem is by unsetting IFS 
>> in 
>> nroff.
>
> I'll work around this in nroff, but I wonder if this is really something
> we should change in dash. It'll be a right pain to have to go around
> changing every shell script in Debian to cope with a silly value of IFS
> in the environment!
>
> POSIX says (IEEE Std 1003.1, 2004 Edition; 2.5.3 Shell Variables):
>
>   Implementations may ignore the value of IFS in the environment at the
>   time the shell is invoked, treating IFS as if it were not set.
>
> It seems to me that it would be most convenient for Debian's default
> /bin/sh to behave this way.

Looks like this has finally been implemented[1], although there is no
released version of dash with the fix yet.

Cheers,
   Sven


1. 
https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=6458796c79e643503d14e18c611cfbf68c4a8cce

Bug#905240: RFS: golang-github-rivo-tview

[Jongmin Kim]

On Fri, Sep 07, 2018 at 10:05:45AM -0400, Alexandre Viau wrote:
> What did you use to choose the branch names?
> 
> I don't see a "master" branch, so this is probably the new workflow?
> 
> However, the new workflow does not use the "debian" branch:
>  - https://go-team.pages.debian.net/workflow-changes.html
> 
> Please either use a repository as created by dh-make-golang or use the
> new workflow according to the spec on the team's website.

I will follow the new workflow for this package. Thank you!


On Fri, Sep 07, 2018 at 10:07:48AM -0400, Alexandre Viau wrote:
> I'd like to avoid repeating the same comments twice, maybe you should
> focus on one ITP and then proceed to the next?

Great! I will focus on 'tview' first.


On Fri, Sep 07, 2018 at 11:29:27AM -0700, Felix Lechner wrote:
> On Fri, Sep 7, 2018 at 11:26 AM Alexandre Viau  wrote:
> > On 2018-09-07 01:48 PM, Jongmin Kim wrote:
> > > 'master' is the default for pristine-tar branches, right?
> > > How do you think about renaming to 'debian/sid'?
> > >
> > > As Alexandre commented, 1.4 in our team's workflow change proposal
> > > suggests new workflow to adopt DEP-14, which recommends 'debian/master'
> > > or 'debian/'. And our team's proposal suggests that the default
> > > branch should be named 'debian/sid'.
> > >
> > > I think I have to rename it to 'debian/sid'.
> >
> > Yes, I agree. This is what the document suggests.
> >
> > Note that, technically, debian/master would also work, but I think
> > debian/sid or debian/unstable is clearer in the case of Debian.
> >
> > See DEP14: https://dep-team.pages.debian.net/deps/dep14/
>
> Yes, 'debian/sid' makes the most sense. I agree with Alex. Thank you!

Thanks a lot for all!


To Alexandre,

Would you review my namespace [1] first? A bunch of mistakes might be
came out, including which need controlling the protected branches. After
your careful review, I will push all the things into our team's repository.
Sorry for taking back what I said.

Or, could you please remove the 'debian' branch from our team's repo?
I don't have a right for removing it. I will push 'debian/sid' there.

Thank you!


[1] https://salsa.debian.org/jmkim-guest/golang-github-rivo-tview


-- 
Jongmin Kim

OpenPGP key located at
https://jmkim-pgp.github.io/keys/pubkey.D39D8D29BAF36DF8.Jongmin_Kim.asc
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


signature.asc
Description: PGP signature

Bug#908068: Attempted fix

[Boris Bobrov]

I managed to launch torbrowser by applying intigeri's patch
https://github.com/micahflee/torbrowser-launcher/commit/a67f026cc14c0a52decda0250890ee776a35f8a1
to /etc/apparmor.d/torbrowser.Browser.firefox and restarting apparmor,
but it is still broken - i cannot open any page and view/change any
settings. Screen size is not 1024x768 (which was the default version for
my system) either.

I wonder if there is a way to install version <8.0 until things get fixed.

Here are the first errors:

[Parent 29833, Gecko_IOThread] WARNING: pipe error (47): Connection
reset by peer: file
/var/tmp/build/firefox-124fa904c4b2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc,
line 353

###!!! [Parent][MessageChannel] Error:
(msgtype=0x2C0056,name=PContent::Msg_RefreshScreens) Channel error:
cannot send/recv


###!!! [Parent][MessageChannel] Error:
(msgtype=0x2C0036,name=PContent::Msg_SetXPCOMProcessAttributes) Channel
error: cannot send/recv


###!!! [Parent][MessageChannel] Error:
(msgtype=0x2C0018,name=PContent::Msg_RegisterChrome) Channel error:
cannot send/recv

Bug#908092: dbus: skip autopkgtest ulimit test when in a container

[Simon McVittie]

On Wed, 05 Sep 2018 at 22:02:01 -0700, Steve Langasek wrote:
> This is because armhf is the single architecture on which Ubuntu runs its
> autopkgtests in containers rather than in VMs, and these are unprivileged
> containers, which means "root" processes don't actually have the
> capabilities necessary to re-raise limits after they've been lowered.

I'm not sure whether such a container should be considered to satisfy the
needs-root restriction. How much root does/should needs-root guarantee?

Perhaps there should be separate restrictions for "needs fully privileged
root" and "needs unprivileged-container root"? (But I'm not sure which
one needs-root should be.)

> I've uploaded the attached patch to Ubuntu in order to have passing tests
> again on armhf.  I'm not sure if you would consider it sufficiently correct
> for Debian, since this means we're also skipping this test on privileged
> containers, but I guess it should be a starting point for discussion.

Can we probe for the required capability, perhaps with

capsh | grep '^Current:.*\'

or something?

Thanks,
smcv

Bug#907805: syslinux.efi uses the TFTP server IP for the HTTP domain

[Marco d'Itri]

On Sep 03, Lukas Schwaighofer  wrote:

> This still seems to be the case, since the pxe_dns function in efi/pxe.c
> in the current HEAD
> (http://repo.or.cz/syslinux.git/blob/HEAD:/efi/pxe.c, lines 38-49) will
> `return 0` in all cases.
Yes, it is even worse than this: even if I pass to syslinux in option 67 
a numeric URL like http://10.0.0.1/file it will request that URL from 
the "10.0.0.1" virtual host of the TFTP server IP.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#887345: BIRD should be part of "network.target"

[Maurizio Cimaschi]

Hello,
I've found today another bug, which is related to this one so I'm not
going to open a new bug.

What I've found is that the embedded RA in bird6 fails sistematically at
boot, while it always works correctly if restarted by hand. In the logs
it complaints about not being able to figure out the link-local address.
I think that this my be related to a "too early" startup. So maybe using
"network-online" could solve this, but so far I've not tried it.

Hope this may helps.

Regards.

@Vincent: sorry for the re-send, but the bug server bounced the first
one.

On Mon, Jan 15, 2018 at 11:28:17AM +0100, Vincent Bernat wrote:
> Package: bird
> Version: 1.6.3-3
> Severity: normal
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hey!
> 
> On shutdown, BIRD is stopped early due to "After=network.target". This
> is troublesome when other services need the network to correctly
> stop. I am unsure of the right fix. Maybe:
> 
> [Unit]
> Before=network.target
> 
> [Install]
> WantedBy=network-online.target
> 
> The "network.target" is mostly used on shutdown and BIRD would start
> correctly even when no interface is correctly configured (but the
> router ID may be guessed incorrectly in this case). The
> "network-online.target" is mostly used on startup and would ensure
> routing is correctly setup on boot.
> 
> - -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 
> 'experimental-debug'), (101, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
> LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages bird depends on:
> ii  adduser  3.116
> ii  init-system-helpers  1.51
> ii  libc62.26-4
> ii  libreadline7 7.0-3
> ii  libtinfo56.0+20171125-1
> ii  ucf  3.0036
> 
> bird recommends no packages.
> 
> Versions of packages bird suggests:
> ii  bird-doc  1.6.3-3
> 
> - -- Configuration Files:
> /etc/bird/bird.conf [Errno 13] Permission denied: '/etc/bird/bird.conf'
> /etc/bird/bird6.conf [Errno 13] Permission denied: '/etc/bird/bird6.conf'
> /etc/bird/envvars [Errno 13] Permission denied: '/etc/bird/envvars'
> 
> - -- no debconf information
> 
> -BEGIN PGP SIGNATURE-
> 
> iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAlpcgkESHGJlcm5hdEBk
> ZWJpYW4ub3JnAAoJEJWkL+g1NSX5GosP/0qPrIocW3tJblDkHdFpyFuOIHGeFEzp
> gadD2lkJ0QB44i1ic8TPF44o8KI+509s/4gYnX44q6xEAfNiIZ4j4SQUZn4r80WP
> 4Cbax06WpIiao9aCJ/vasGtpExW2JGBpnSqxDGOies6am/nss8X4scHti1CoXWDI
> pkpflTwMvX8gqYowHApQOmWMn1F4qIWmk0a3hwc1HyFfeH0ITXzKnsVF4DElAm0B
> f39w81HmavrVjJdspOp62GT/UtUEpiLh9gleno4zW+26HaGhT1ntM/FqHOLT+NlV
> nSp5WpAFYVXJXYSDFZlUzydVNeP9hLamfeLora0Lf+JWc+zBv/6ES67rTsztVbIp
> DXExnU8AUPq+MkK2w2TLD4xG6umaGhSwmInwJ2uy76ZMHv7kG19ibGmjj9KkIE4z
> tERW07N8rWfOOQtWU3zg35uMlvTcGx/zf9Xd9ltHVqKGEovdDjyYrFV5NZtPtL1l
> jDaT3VObjyWFd+hFzFjXRXtFA+7Z/EnY5MiwOwY8wXDFs59wX1VAjKfaEzgCBfZm
> pDBtO3XQf4sZ9Ytg0nZJxc00q6teC4/E6AD+H+W+hsSleaQ/hqNSFAJgqyN0OetD
> 2tAiaT/uur83VUrhrYbZ6PnKm0j4diPk/yzSeQ5josPoqaUdRl3jRfjjMvG+AJSD
> v4xojzPJbDvb
> =jEqF
> -END PGP SIGNATURE-

Bug#908158: [Pkg-mozext-maintainers] Bug#908158: webext-ublock-origin: xul-ext-ublock-origin and webext-ublock-origin should co-exist

[Mykola Nikishov]

Carsten Schoenert  writes:

>> ... and I'm trying to make use of such flexibility. For smooth migration
>> I'd like to use current firefox-esr/stable and
>> xul-ext-ublock-origin/stable while moving to firefox/unstable with
>> webext-ublock-origin/unstable (whatever unstable might be at the
>> moment).
>
> You seems to forget that xul-ext-* packages will not get updated in the
> stable distribution! They will stay there until the end of the stretch
> release. And they are only relevant until FF 52esr. Also the content of
> the packages would be same.

Looks like I was using 'stable' instead of 'stretch' which may be
confusing: right now stable is stretch and I mean stretch when talking
about stable:

- firefox-esr/stretch and xul-ext-ublock-origin/stretch
- firefox/unstable and webext-ublock-origin/unstable (whatever unstable
  might be at the moment)

>> Having said that, I think Breaks: constraint could be relaxed.

Now I see that it is not only Breaks:, but Replaces:
xul-ext-ublock-origin too.

> No, we win nothing on this. It's more packaging work for no real gain
> given the real short span of time FF 52esr will alive.

(If not because of stable = stretch confusion) Sorry, but I don't
understand that - actively preventing two packages to coexist for no
real reason. I'm not an expert in Debian packaging, but 7.4. Conflicting
binary packages - Conflicts [1] seems as a perfect fit:

Neither Breaks nor Conflicts should be used unless two packages
cannot be installed at the same time or installing them both causes
one of them to be broken or unusable. Having similar functionality
or performing the same tasks as another package is not sufficient
reason to declare Breaks or Conflicts with that package.

- webext-ublock-origin's files do not overlap with
  xul-ext-ublock-origin/stretch ones
- they do not break each other
- both firefox packages would ignore unsupported extension anyway

firefox/unstable does not Breaks: or Replaces: firefox-esr/stretch. At
the same time, webext-ublock-origin/unstable forces user to remove
xul-ext-ublock-origin/stretch.

webext-ublock-origin/unstable, as a new package since stretch, could
just not Breaks: and Replaces: xul-ext-ublock-origin.

What am I missing?

NB: keep in mind, non-native English speaker here ;-)

[1] 
https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts

-- 
Mykola
https://manandbytes.git{lab,hub}.io/

Bug#908274: Please add the capability to run tests that require a server

[Wouter Verhelst]

Package: autopkgtest
Version: 5.5
Severity: wishlist

Hi,

I'm thinking of adding autopkgtests to src:nbd.

One thing which the nbd-client package adds is initramfs hooks for
supporting root-on-NBD. To do that, you need:

- A machine on the network running nbd-server
- A machine running the initramfs hooks, with kernel command-line
  parameters like "nbdroot=1.2.3.4:nbexport root=/dev/nbd0"

The second machine can then run diskless.

This is not possible with the current architecture of autopkgtest. I've
given this some thought, and came up with the following, which I think
strikes a balance between "little work needed to make basic usage of
this possible", and "flexible enough to allow for future extensibility".
The following demonstrates the idea I have in mind:

---8<---
Test-Skeleton:
  create testbed1
  create testbed2
  start-test testbed1 test1
  start-test testbed2 test2
  end-test testbed2
  set testbed1 VAR=$(ip ad sh | ...)
  start-test testbed2 test3 $VAR
  end-test testbed2
  end-test testbed1
  kill testbed1
  kill testbed2
Restrictions: multihost

Tests: test1
Restrictions: multihost-guest, breaks-testbed

Tests: test2

Tests: test3
Features: takes-variable
--->8---

This adds two restrictions and a variable, and creates a DSL that is
meant to be run by way of the "Test-Skeleton" header:

- The "multihost" restriction means to say that it isn't actually a test
  which is run directly, but that it's a "meta" test in the test suite.
  It requires the "Test-Skeleton" thing to mark that we're using the DSL
  here (but I guess we can do without that if that would make sense).
  The DSL would know the following things:
  - "create": creates a testbed. If multiple testbeds are created in
this manner, they must be connected to eachother on a (virtual or
physical) network. Probably we might want to extend this command
later on to specify the layout of the network etc, but for now that
probably shouldn't be required.
  - "start-test": starts a "guest" test in a given testbed, but does not
wait for it to end (probably shouldn't be allowed to recurse).
  - "end-test": waits for the test that was started earlier in a given
testbed to end. If that test returned failure, fail the whole test
(and abort, probably). If it succeeded, we move on. If no test was
running there, should probably error?
  - "set": runs an arbitrary command in a given testbed, captures the
output (probably stdout only), and assigns it to a variable.
  - "kill": destroys a testbed. If a test is still running, the result
of that test is ignored.
- The "multihost-guest" restriction means to say that this particular
  test makes no sense at all unless it's run as part of the multihost
  test defined elsewhere.
- The "takes-variable" feature, to say that it optionally takes a
  parameter.

There are no loops or conditionals here; that is on purpose. I don't
think this needs to be a Turing-complete language; if a test needs to
loop or test a condition, then that should be done in one of the tests
that is actually being run on one of the testbeds.

With that, in the above example, the "test1" test could configure the
system so that a server is running there, which can then be used by the
other tests that run in the other testbed. To discover on which address
the other testbed is running, the "host" test can run commands there
which assign variables, and then "guest" tests can use that output to do
"something useful" with them. This can be used for passing on network
configuration things, but it could also be used for other things; e.g.,
randomly-generated credentials could be passed from one testbed to the
other.

Thoughts?

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   1.6.4
ii  libdpkg-perl1.19.0.5
ii  procps  2:3.3.15-2
ii  python3 3.6.6-1
ii  python3-debian  0.1.33

Versions of packages autopkgtest recommends:
ii  autodep8  0.14

Versions of packages autopkgtest suggests:
pn  lxc   
pn  lxd-client
ii  ovmf  0~20180812.cb5f4f45-1
ii  qemu-efi-aarch64  0~20180812.cb5f4f45-1
pn  qemu-efi-arm  
ii  qemu-system   1:2.12+dfsg-3
ii  qemu-utils1:2.12+dfsg-3
ii  schroot   1.6.10-5

-- no debconf information

Bug#827573: dash: Sourcing empty files might break execution when running under -e

[Sven Joachim]

Control: forcemerge 777262 -1

Am 18.06.2016 um 01:09 schrieb Christoph Biedl:

> Package: dash
> Version: 0.5.8-2.2
> Severity: normal
>
> Dear Maintainer,
>
> There's a surprising behaviour in dash when sourcing an empty file
> after a failed (non-zero) if statement. Although I'm reluctant to use
> the "bug" word, it's at least very weird and does not happen in bash
> or zsh.
>
> Take that "main.sh" script, it sources an empty "source.sh", unless
> it's not there:
>
> ,--
> #!/bin/sh
> set -e
> S=./source.sh
> if [ ! -f "$S" ] ; then
> echo 'No file to source'
> else
> . "$S"
> fi
> echo 'Here we go'
> `--
>
> where source.sh:
> ,--
> # no op
> `--
>
> Now running "sh -x main.sh" results in
>
> | + set -e
> | + S=source.sh
> | + [ ! -f source.sh ]
> | + . source.sh
>
> and $? is set to 1.
>
> In other words, the "." statement is considered failing, hence aborting
> script execution.
>
> Using bash the execution continues:
>
> | (...)
> | + . source.sh
> | + echo 'Here we go'
> | Here we go
>
> and $? is zero. Same for zsh.

This has been fixed in dash 0.5.9.1.  See #777262 and [1] for details.

Cheers,
   Sven


1. 
https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=17a5f24e0a8ec22f74399764db30d97ae310f3c6

Bug#908273: Mourse cursor stops on visual effects

[Stefan Frings]

Package: libwayland-bin
Version: 1.15.0-2

1) Movements of my mouse cursor is not smooth. The cursor often sticks
for a half second and then jumps to the correct position. 

The problem happens when I hold the mouse still for >5 seconds followed
by a movement over any GUI element that reacts with any visual effect.
When I constantly move the mouse, then the problem does not occur.

Related "visual effects" are for example color change of text, emphasis
of buttons, scrolling of window content, change of cursor shape.

The USB mouse is affected as well as the touch pad of my laptop. Using
another mouse, disconnecting the mouse or disabling the touch pad
does not make any difference. I also tried to change my CPU speed
governor from "powersave" to "performance" but that also did not help.

All programs are affected.

2) In addition I noticed that video playback (e.g. on youtube.com)
often starts with 1 second of jerking image and sound.

3) When I create screenshot by pressing the Print key, the screen
sometimes freezes and shows about 50% of all pixels across the whole
surface with random data (noise).

Disabling Wayland in /etc/gdm3/daemon.conf solves all 3 problems.

I wrote 3 issues in one ticket because I assume that they are related.
If not then please lets concentrate on the first issue with the mouse
cursor because that is more important to me.

My laptop is a HP Omen with 8 cores, 8GB RAM, SSD and an Intel graphic
chip plus an additional nvidia GPU. However I did not install the
Nvidia driver because I am not interested in the 3D acceleration.

Output from lspci:

00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM
Registers (rev 07)
00:01.0 PCI bridge: Intel Corporation Skylake PCIe Controller (x16)
(rev 07)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530
(rev 06)
00:04.0 Signal processing controller: Intel Corporation Skylake
Processor Thermal Subsystem (rev 07)
00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI
Controller (rev 31)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-H 
Thermal subsystem (rev 31)
00:16.0 Communication controller: Intel Corporation Sunrise Point-H
CSME HECI #1 (rev 31)
00:17.0 SATA controller: Intel Corporation Sunrise Point-H SATA
Controller [AHCI mode] (rev 31)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root
Port #5 (rev f1)
00:1c.5 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root
Port #6 (rev f1)
00:1c.6 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root
Port #7 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller
(rev 31)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev
31)
00:1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio (rev
31)
00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31)
01:00.0 3D controller: NVIDIA Corporation GM107M [GeForce GTX 960M]
(rev a2)
07:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd.
RTS522A PCI Express Card Reader (rev 01)
08:00.0 Network controller: Intel Corporation Wireless 7265 (rev 61)
09:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)

Bug#904776: /usr/bin/dpkg-source: please parse d/t/control.autodep8 like d/t/control

[Paul Gevers]

Control: tags -1 - moreinfo
Control: clone -1 -2
Control: reassign -1 autopkgtest
Control: retitle -1 autopkgtest: smarter autodep8 i.c.m. d/t/control
Control: reassign -2 autodep8
Control: retitle -2 autodep8: append d/t/control if it exists

Hi Guillem,

Thank you for carefully thinking about this.

On 06-09-18 00:20, Guillem Jover wrote:
> I guess, the logic proposed above could be changed a bit to support
> something closer to the current logic, and not introduce such a
> global semantic change, so perhaps:
> 
>   * change autopkgtest to check the Testsuite field in debian/control:
> - if it contains say an autopkgtest-autogen value then call autodep8,
>   even if debian/tests/control exists.

autodep8 has already fieldnames like autopkgtest-pkg-python. I think
those suffice.

> - otherwise call autodep8 only if debian/tests/control does not
>   exist.
>   * change autodep8 to always cat debian/tests/control if present.
>   * then autodep8 would cat the autogenerated tests like now based on
> the Testsuite field, and for backwards compat also the
> control.autodep8 file if present.

I think this looks sane indeed. Let me try to implement it.

> I'm just still not convinced this should be handled in dpkg. :)

Unless I get back at you, I think I agree.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#900146: prosody fails to write pid file

[Tobias Frost]

On Sat, 26 May 2018 19:52:26 + cl...@jhcloos.com wrote:
> Package: prosody
> Version: 0.10.1-1~bpo9+2
> Severity: important
> 
> ** I'm reporting this from a different box than where it occurrs. **
> 
> My xmpp box runs stretch.  After I added stretch-backports, which
> upgraded prosody to 0.10.1-1~bpo9+2, it would not run.
> 
> The systemd file tried to use /var/run/prosody/prosody.pid for the
pid.
> That matched what the cfg file specified.
> 
> But the directory /var/run/prosody does not exist.
> 
> The systemd file has:
> 
>   RuntimeDirectory=prosody
> 
> but that did not create a usable directory.
> 
> I had to switch both files to put the pid elsewhere (in a permanent
> directory to which the prosody uid has write permission) in order to
> get prosody to start.
> 
> This did not occur with stretch's 0.9.12-2.

As I had the same issue: The cause at my side was that after update I
did not merge the configuration files, as prosody.cfg.lua refers to the
pid file location as well. So the lua file wanted /var/run, while the
init.d file created /run/prosody. 

The fix is to "merge" prosody.cfg.lua.dpkg-dist with prosody.cfg.lua..

--
tobi



> 

Bug#905989: python3-enet: missing python3 dependency

[Markus Koschany]

Control: tags -1 pending

Dear maintainer,

I've uploaded a new revision of python-enet versioned as
0.0~vcs.2017.05.26.git-2.1 to fix Debian bug #905989.

Please find attached the debdiff.

Regards,

Markus
diff -Nru python-enet-0.0~vcs.2017.05.26.git/debian/changelog 
python-enet-0.0~vcs.2017.05.26.git/debian/changelog
--- python-enet-0.0~vcs.2017.05.26.git/debian/changelog 2017-10-31 
13:55:02.0 +0100
+++ python-enet-0.0~vcs.2017.05.26.git/debian/changelog 2018-09-07 
20:49:16.0 +0200
@@ -1,3 +1,11 @@
+python-enet (0.0~vcs.2017.05.26.git-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add missing Python3 dependencies to python3-enet.
+Thanks to Adrian Bunk for the report and patch. (Closes: #905989)
+
+ -- Markus Koschany   Fri, 07 Sep 2018 20:49:16 +0200
+
 python-enet (0.0~vcs.2017.05.26.git-2) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru python-enet-0.0~vcs.2017.05.26.git/debian/control 
python-enet-0.0~vcs.2017.05.26.git/debian/control
--- python-enet-0.0~vcs.2017.05.26.git/debian/control   2017-10-31 
13:54:51.0 +0100
+++ python-enet-0.0~vcs.2017.05.26.git/debian/control   2018-09-07 
20:49:16.0 +0200
@@ -33,10 +33,10 @@
 Architecture: any
 Depends:
  ${misc:Depends},
- ${python:Depends},
+ ${python3:Depends},
  ${shlibs:Depends}
 Breaks:
- ${python:Breaks}
+ ${python3:Breaks}
 Description: Python3 wrapper for the ENet library
  python-enet provides a thin wrapper around the enet networking
  library. ENet is a thin layer to provide reliable communication over


signature.asc
Description: OpenPGP digital signature

Bug#886358: chromium: Enable Hangouts screensharing extension

[Eloston]

On Thu, 6 Sep 2018 19:50:24 -0700 Josh Triplett  wrote:
> 
> This is not in any way an explanation. "users have stated concern" -
> *what* concern?
> 
> At the very least, this needs an explanation commensurate with "why is
> it important to break people's ability to do screen sharing by default
> in a way they won't easily discover and can't easily fix". If there's a
> reason that outweighs that, it needs to be documented. And if there
> *isn't* a reason that outweighs that, then please enable this extension.
> 

It may be a potential security concern.

The code for the Hangout Services component extension lives in 
chrome/browser/resources/hangout_services/. All 
"enable_hangout_services_extension=true" does is include this code in Chromium.

In essence, the extension allows "https://*.google.com/*; with access to do the 
following:

* Get browser process CPU, network, and memory usage (chrome.processes, in 
function onProcessCpu)
* Initiate desktop capture UI (chrome.desktopCapture and 
chrome.webrtcDesktopCapturePrivate, in function onChooseDesktopMediaPort)
* Get CPU info (chrome.system.cpu, in callback for 
chrome.runtime.onMessageExternal)
* Get and set WebRTC audio sinks and audio experiments 
(chrome.webrtcAudioPrivate, in onSinksChangedPort and in callback for 
chrome.runtime.onMessageExternal)
* Stop, start, and upload WebRTC logs, RTP logs, and audio debug recordings 
(chrome.webrtcLoggingPrivate, in callback for chrome.runtime.onMessageExternal)

The greatest unknowns here are the chrome.*Private APIs, since they're exposed 
only to component extensions (and thus not documented well). I don't know how 
they're implemented, so I cannot speak for
the security of these APIs.

Overall, this extension seems to be filling a small gap that the standards 
haven't provided yet. IMO, this isn't really that much of a security risk.

Alternatively, this extension could be a privacy concern for Google (in light 
of reports of Google's data practices). The inclusion of a patch to disable 
signing-in (in the source at
debian/patches/disable/signin.patch) seems to support this idea, but then why 
are Google API keys included in the browser (installed to 
/etc/chromium.d/apikeys)?

Bug#908271: plasma-nm: Plasmashell crashes on startup while loading plasma-nm

[Diane Trout]

Package: plasma-nm
Version: 4:5.13.5-1
Severity: important

Dear Maintainer,

When attempting to log into a wayland plasma desktop, plasmashell crashes when
loading "Network" I assumed that was provided by the plasma-nm component.

If I uninstall plasma-nm, plasmashell will then load and run.

I tried both 4:5.13.5-1 and 4:5.13.4-1

when I do a single threaded backtrace I it ends witht this:

#53 QV4::Runtime::method_storeProperty (engine=engine@entry=0x556c4850,
object=...,
nameIndex=, value=...) at jsruntime/qv4runtime.cpp:549
#54 0x771722b9 in storePropertyHelper (f=0x56757240, base=...,
name=, value=...) at jit/qv4jit.cpp:368
#55 0x7fff55cd91ec in ?? ()
#56 0x7fffe9d78328 in ?? ()
#57 0x7fffe9d78338 in ?? ()
#58 0x556c4850 in ?? ()
#59 0x in ?? ()

Any guesses of what to try?



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

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

Thread 16 (Thread 0x7fff31296700 (LWP 25752)):
#0  0x754f1e6c in futex_wait_cancelable (private=, 
expected=0, 
futex_word=0x56fc1a24) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x56fc19d0, 
cond=0x56fc19f8)
at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x56fc19f8, mutex=0x56fc19d0)
at pthread_cond_wait.c:655
#3  0x759524fb in QWaitConditionPrivate::wait 
(time=18446744073709551615, 
this=0x56fc19d0) at thread/qwaitcondition_unix.cpp:143
#4  QWaitCondition::wait(QMutex*, unsigned long) () at 
thread/qwaitcondition_unix.cpp:215
#5  0x7753a279 in QSGRenderThreadEventQueue::takeEvent (wait=true, 
this=0x56d4a6e8) at scenegraph/qsgthreadedrenderloop.cpp:245
#6  QSGRenderThread::processEventsAndWaitForMore 
(this=this@entry=0x56d4a670)
at scenegraph/qsgthreadedrenderloop.cpp:709
#7  0x7753a4da in QSGRenderThread::run() ()
at scenegraph/qsgthreadedrenderloop.cpp:738
#8  0x75951d47 in QThreadPrivate::start(void*) () at 
thread/qthread_unix.cpp:367
#9  0x754ebf2a in start_thread (arg=0x7fff31296700) at 
pthread_create.c:463
#10 0x75646edf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 14 (Thread 0x7fff31d61700 (LWP 25736)):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7262af2a in g_cond_wait_until ()
   from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x725b84f1 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x725b8aac in g_async_queue_timeout_pop ()
   from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7260d8ae in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7260ce05 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x754ebf2a in start_thread (arg=0x7fff31d61700) at 
pthread_create.c:463
#7  0x75646edf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 12 (Thread 0x7fff337fe700 (LWP 25734)):
#0  0x754f219a in futex_reltimed_wait_cancelable (private=, 
reltime=0x7fff337fdc10, expected=0, futex_word=0x56d923a4)
at ../sysdeps/unix/sysv/linux/futex-internal.h:142
#1  __pthread_cond_wait_common (abstime=0x7fff337fdcd0, mutex=0x56d92350, 
cond=0x56d92378) at pthread_cond_wait.c:533
#2  __pthread_cond_timedwait (cond=0x56d92378, mutex=0x56d92350, 
abstime=0x7fff337fdcd0) at pthread_cond_wait.c:667
#3  0x759523dc in QWaitConditionPrivate::wait_relative (time=3, 
this=0x56d92350) at thread/qwaitcondition_unix.cpp:133
#4  QWaitConditionPrivate::wait (time=3, this=0x56d92350)
at thread/qwaitcondition_unix.cpp:141
#5  QWaitCondition::wait(QMutex*, unsigned long) () at 
thread/qwaitcondition_unix.cpp:215
#6  0x7594a242 in QThreadPoolThread::run() ()
at ../../include/QtCore/../../src/corelib/thread/qmutex.h:240
#7  0x75951d47 in QThreadPrivate::start(void*) () at 
thread/qthread_unix.cpp:367
#8  0x754ebf2a in start_thread (arg=0x7fff337fe700) at 
pthread_create.c:463
#9  0x75646edf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 11 (Thread 0x7fff33fff700 (LWP 25733)):
#0  0x7563c739 in __GI___poll (fds=0x56d79bd0, nfds=2, timeout=-1)
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x725e5439 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x725e57d2 in g_main_loop_run ()
   from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fff4d9c6e26 in ?? () from 

Bug#908270: baloo-widgets: autopkgtest regression

[Paul Gevers]

Source: baloo-widgets
Version: 4:18.08.0-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of baloo-widgets the autopkgtest of baloo-widgets
fails in testing when that autopkgtest is run with the binary packages
of baloo-widgets from unstable. It passes when run with only packages
from testing. I copied some of the output at the bottom of this report.

Currently this regression is contributing to the delay of the migration
to testing [1]. Can you please investigate the situation and fix it? If
needed, please change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=baloo-widgets

https://ci.debian.net/data/autopkgtest/testing/amd64/b/baloo-widgets/952039/log.gz

1/4 Test #2: filemetadatawidgettest ...***Failed0.03 sec
qt.qpa.screen: QXcbConnection: Could not connect to display
Could not connect to any X display.

Start 3: filemetadataitemcounttest
2/4 Test #3: filemetadataitemcounttest ***Failed0.02 sec
qt.qpa.screen: QXcbConnection: Could not connect to display
Could not connect to any X display.

Start 4: filemetadatadatedisplaytest
3/4 Test #4: filemetadatadatedisplaytest ..***Failed0.02 sec
qt.qpa.screen: QXcbConnection: Could not connect to display
Could not connect to any X display.

4/4 Test #1: extractortest    Passed0.08 sec

25% tests passed, 3 tests failed out of 4

Total Test time (real) =   0.08 sec

The following tests FAILED:
  2 - filemetadatawidgettest (Failed)
  3 - filemetadataitemcounttest (Failed)
  4 - filemetadatadatedisplaytest (Failed)



signature.asc
Description: OpenPGP digital signature

Bug#908269: pbbam: autopkgtest regression

[Paul Gevers]

Source: pbbam
Version: 0.18.0+dfsg-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of pbbam the autopkgtest of pbbam fails in testing
when that autopkgtest is run with the binary packages of pbbam from
unstable. It passes when run with only packages from testing. I copied
some of the output at the bottom of this report.

Currently this regression is contributing to the delay of the migration
to testing [1]. Can you please investigate the situation and fix it? If
needed, please change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=pbbam

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pbbam/954327/log.gz

tests/src/cram/pbbamify.deb.t: failed
--- tests/src/cram/pbbamify.deb.t
+++ tests/src/cram/pbbamify.deb.t.err
@@ -90,42 +90,12 @@
 Test on a dataset, input contains alignments from all subread sets.

   $ $PBBAMIFY --input=$DATADIR/pbbamify/input-aligned-all.bam
$DATADIR/pbbamify/synthetic-ref-1.fa  | samtools view -h
-  [Warning] No records found for query 'synthetic_movie_1/10/0_100'.
Skipping.
-  [Warning] Sequence 'synthetic_movie_1/1/0_100' (length 90) is not of
the same length as the PacBio BAM sequence (length 100)! Skipping.
-  [Warning] Found 1 alignments without a seq field which were not
converted (most likely secondary alignments).
-  [INFO] Done processing 25 alignments in 0 min.
-  @HD\tVN:1.5\tSO:unknown\tpb:3.0.3 (esc)
-  @SQ\tSN:synthetic_ref_1\tLN:150\tM5:e1e940d621d949c9617566ddf3055922
(esc)
-
@RG\tID:67e06f58\tPL:PACBIO\tDS:READTYPE=CCS;BINDINGKIT=100-862-200;SEQUENCINGKIT=101-093-700;BASECALLERVERSION=5.0.0.5049;FRAMERATEHZ=80.00\tPU:synthetic_movie_3\tPM:SEQUEL
(esc)
-
@RG\tID:7a515ee0\tPL:PACBIO\tDS:READTYPE=SUBREAD;Ipd:CodecV1=ip;PulseWidth:CodecV1=pw;BINDINGKIT=100-862-200;SEQUENCINGKIT=100-861-800;BASECALLERVERSION=5.0.0.5552;FRAMERATEHZ=80.00\tPU:synthetic_movie_2\tPM:SEQUEL
(esc)
-
@RG\tID:8d2370c0\tPL:PACBIO\tDS:READTYPE=SUBREAD;Ipd:CodecV1=ip;PulseWidth:CodecV1=pw;BINDINGKIT=100-862-200;SEQUENCINGKIT=100-861-800;BASECALLERVERSION=5.0.0.5552;FRAMERATEHZ=80.00\tPU:synthetic_movie_1\tPM:SEQUEL
(esc)
-  @PG\tID:Handmade\tPN:Handmade (esc)
-
@PG\tID:baz2bam\tPN:baz2bam\tVN:5.0.0.5552\tCL:/opt/pacbio/ppa-5.0.0/bin/baz2bam
/data/pb/synthetic_movie_1.baz -o /data/pb/synthetic_movie_1 --metadata
/data/pb/.synthetic_movie_1.metadata.xml -j 12 -b 12 --progress --silent
--minSubLength 50 --minSnr 3.75 --adapters
/data/pb/synthetic_movie_1.adapters.fasta (esc)
-  @PG\tID:bazFormat\tPN:bazformat\tVN:1.3.0 (esc)
-  @PG\tID:bazwriter\tPN:bazwriter\tVN:5.0.0.5552 (esc)
-  @PG\tID:ccs-3.0.0\tPN:ccs\tVN:3.0.0\tDS:Generate circular consensus
sequences (ccs) from subreads.\tCL:ccs (esc)
-
synthetic_movie_1/1/0_100\t0\tsynthetic_ref_1\t23\t60\t100=\t*\t0\t0\tCGCTATTTATGCCGGTTTAAGGCGTTTCCGTTCTTCTTCGTCATAACTTAATGTATTTTACCCTCTGGAAAGGAAACGAC\t\tRG:Z:8d2370c0\tcx:i:3\tip:B:C,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100\tnp:i:1\tpw:B:C,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100\tqe:i:100\tqs:i:0\trq:f:0.8\tsn:B:f,8.34462,15.7107,6.3469,10.3163\tzm:i:1
(esc)
-
synthetic_movie_1/1/0_100\t256\tsynthetic_ref_1\t23\t254\t100=\t*\t0\t0\tCGCTATTTATGCCGGTTTAAGGCGTTTCCGTTCTTCTTCGTCATAACTTAATGTATTTTACCCTCTGGAAAGGAAACGAC\t\tRG:Z:8d2370c0\tcx:i:3\tip:B:C,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100\tnp:i:1\tpw:B:C,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100\tqe:i:100\tqs:i:0\trq:f:0.8\tsn:B:f,8.34462,15.7107,6.3469,10.3163\tzm:i:1
(esc)
-

Bug#908236: RFS: faba-icon-theme/4.3-1

[David Mohammed]

Ah - I forgot to push - have now!

That bug was raised with upstream a while back here -
https://github.com/snwh/faba-icon-theme/issues/61

Hasn't yet been resolved.  I'll have a go myself at some point soon
(hopefully) and will through a PR towards upstream.

David
On Fri, 7 Sep 2018 at 18:58, Juhani Numminen  wrote:
>
> Hi,
>
> David Mohammed kirjoitti 07.09.2018 klo 19:46:
>
> >   Dear mentors,> >   I am looking for a sponsor for my package 
> > "faba-icon-theme"
> Just some friendly reminders:
>
> - What about the open bug https://bugs.debian.org/857212?
> - Are you still using the repository that's in Vcs-Git? There's nothing
>   recent there.
>
>
> Cheers,
> Juhani

Bug#908236: RFS: faba-icon-theme/4.3-1

[Juhani Numminen]

Hi,

David Mohammed kirjoitti 07.09.2018 klo 19:46:

>   Dear mentors,> >   I am looking for a sponsor for my package 
> "faba-icon-theme"
Just some friendly reminders:

- What about the open bug https://bugs.debian.org/857212?
- Are you still using the repository that's in Vcs-Git? There's nothing
  recent there.


Cheers,
Juhani

Bug#582630: piuparts doesnt show many errors..

[Holger Levsen]

hi,

so I've enabled the logrotate test for piuparts.d.o for sid and buster
again (see #604807) and so far there were three failed packages found,
see
https://piuparts.debian.org/sid/logrotate_error_after_removal_error.html
and
https://piuparts.debian.org/buster/logrotate_error_after_removal_error.html

These three failures to me seem to be legit.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#908258: ruby-sentry-raven: FTBFS with ruby-rspec 3.8

[Cédric Boutillier]

Source: ruby-sentry-raven
Version: 2.7.2-2
Severity: serious
Justification: ftbfs

Dear Maintainer,

The package fails to build from source after the upload of
ruby-rspec 3.8 (was fine with 3.7), because of a failing test:

Failures:

  1) Integration tests hitting quota limit shouldn't swallow exception
 Failure/Error: expect(@logger).not_to receive(:error).twice

 RuntimeError:
   `count` is not supported with negative message expectations
 # ./spec/raven/integration_spec.rb:38:in `block (2 levels) in '

Finished in 1.01 seconds (files took 0.73133 seconds to load)
256 examples, 1 failure, 2 pending

Failed examples:

rspec ./spec/raven/integration_spec.rb:34 # Integration tests hitting quota 
limit shouldn't swallow exception


This failure is also experienced upstream, as Jenkins instance reports
the same test failure with rspec 3.8 gem from Github repository.


Cheers,

Cédric


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

Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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

Bug#908250: hugo: please package new upstream version 0.48

[Tobias Frost]

Source: hugo
Severity: wishlist

Hi Tobias, packaging team

It would be great to have 0.48 in the archives!
(It would be also cool to have a backport of the new version, as I have
hugo on a server running stretch)

Thanks!

tobi

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

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

Bug#908005: nvidia-driver: When initializing vulkan, driver opens default XDisplay

[Felix Dörre]

On 9/7/18 12:27 PM, Luca Boccassi wrote:

Control: reassign -1 bumblebee
Control: forcemerge 892646 -1

On Wed, 2018-09-05 at 06:52 +0200, Felix Dörre wrote:

Package: nvidia-driver
Version: 390.77-1
Severity: important

Dear Maintainer,

I have an Nvidia-Optimus setup and use bumblebee to activate the
Nvidia GPU on demand.

When I use libvulkan.so.1 to run a Vulkan application the ICD from
Nvidia (installed in /usr/share/vulkan/icd.d/nvidia_icd.json,
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1) opens a connection to
the
default X Display (as specified by the DISPLAY environment variable).
When using bumblebee to activate the Nvidia GPU, the driver must
connect to Display :8, where bumblebee runs the secondary
X Server. However I want to run my application with the DISPLAY
environment variable set to :0 (as I want it displayed on :0).

I generally would expect the Vulkan-Nvidia driver not to require an
X-connection when doing headless rendering and for 'normal' rendering
use the X-connection/display that is indicated by the surface-
creation functions, and not choose one by itself on startup.
If that is hard to achieve, I would at least expext the Nvidia-Driver
to have some override environment variable (like e.g. NV_DISPLAY)
that, when set, is passed by the Nvidia-Driver to XOpenDisplay, that
"normal" applications would ignore.

Hi, Vulkan is not supported on Optimus, see #892646.

:-) Yes, that's exactly what I am currently trying to implement when I 
encountered this problem. The misbehavior I am describing is a problem 
in the nvidia driver that obstructs me from implementing a primus-like 
solution for vulkan. For this I only use bumblebee to activate the GPU 
and don't use/need primus for the GL-bridge.


Additionally I believe that also non-Optimus users can encounter this 
problem in non-standard usage scenarios, when the environment variable 
DISPLAY is wrong and the application uses another way to determine the 
correct display to call XOpenDisplay upon. The driver will then fail to 
load, however it should not depend on $DISPLAY at all.

Bug#791944: /etc/init.d/sendsigs kills systemd-udevd upon shutdown, causing dmsetup to hang

[Michael Biebl]

Am 03.09.18 um 22:08 schrieb Trek:
> I'll try to do it

I made an upload today which incorporates that patch (with a small fix
as udev needs a aproper ordering on shutdown against umountroot).

So it's no longer necessary that you create a MR.
Just wanted to let you know to avoid unnecessary work.

Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#908249: lightning: requests with malformed URLs sent to CalDAV-server (adding new events works, changing events not)

[Ferdinand Rau]

Package: lightning
Version: 1:52.9.1-1~deb9u1
Severity: important

Dear Maintainer,

with the current stable thunderbird/lightning, it is impossible for me to 
modify events in any CalDAV calendar. Adding and deleting items works just fine.

How to reproduce: With thunderbird 52.9.1 (64-bit) and lightning 5.4.9.1, try 
to modify an existing event in any CalDAV calendar. Any modification triggers 
this error (label, time, attendee, description, ...).

The URL of the CalDAV account must follow a certain pattern, however, for this 
error to happen:
Everything works just fine for calendars like this: 
https://calendar.example.com/calendar/caldav.php/username/calendar
But not for calendars like this: https://calendar.example.com/username/calendar
Sounds weird, but I did confirm this serveral times with several different 
calendars.

What is expected: The item should be modified on the server and the 
modification should be displayed in lightning.

What actually happens: The modification is ignored. There is no error or info 
message; all changes are simply "reverted". (Note: This does also apply to 
dismissing reminders.)

Explanation:
The obvious reason for this issue is a malformed http request sent by lightning 
when events are modified (additions and deletions work just fine). In the 
Thunderbird Error Console, I can see the following:
> PUT 
> https://calendar.example.com/username/calendar/.php/username/calendar/778d0468-e6c3-456e-8bcc-ec92adffc15f.ics
>  [HTTP/1.1 405 Method Not Allowed 1904ms]

The correct URL should be: 
https://calendar.example.com/username/calendar/778d0468-e6c3-456e-8bcc-ec92adffc15f.ics

This behavior is 100% reproducible and happens to all my accounts (following 
the abovementioned calendar URL pattern). With the wrong URL, there is no way 
the modification can suceed, of course. It would be nice to see an informative 
error message here, but the main issu


Background:
There is a long-standing bug in lightning (upstream) that also affected me 
years ago:
[Updating an event results in a PUT to the wrong CalDav URL] 
https://bugzilla.mozilla.org/show_bug.cgi?id=605201

This issue is certainly related somehow, but it is not the same, since the 
abovementioned bug affects the function addTargetCalendarItem in 
calDavCalendar.js, but this function is not used for modifying events in my 
case. Instead, this is the call stack, as far as I can see:
> authSuccess file:///usr/lib/lightning/components/calDavCalendar.js:381:13
> calDavCalendar.prototype.sendHttpRequest 
> file:///usr/lib/lightning/components/calDavCalendar.js:398:13
> calDavCalendar.prototype.doModifyItem 
> file:///usr/lib/lightning/components/calDavCalendar.js:842:9
> calDavCalendar.prototype.modifyItem 
> file:///usr/lib/lightning/components/calDavCalendar.js:740:16
> calCachedCalendar.prototype.modifyItem/flagListener.onOperationComplete 
> file:///usr/lib/lightning/calendar-js/calCachedCalendar.js:719:21
> calStorageCalendar.prototype.getItemOfflineFlag/listener.handleCompletion 
> file:///usr/lib/lightning/components/calStorageCalendar.js:959:21


Please let me know if you need any additional information or want me to test a 
patch or another version of thunderbird/lightning.

Should I also report this bug upstream at bugzilla.mozilla.org ?


Kind regards,
Ferdninad Rau


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

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

Versions of packages lightning depends on:
ii  thunderbird  1:52.9.1-1~deb9u1

lightning recommends no packages.

Versions of packages lightning suggests:
pn  calendar-google-provider  
ii  fonts-lyx 2.2.2-1

-- no debconf information

Bug#908005: nvidia-driver: When initializing vulkan, driver opens default XDisplay

[Luca Boccassi]

On Fri, 2018-09-07 at 19:13 +0200, Felix Dörre wrote:
> On 9/7/18 12:27 PM, Luca Boccassi wrote:
> > Control: reassign -1 bumblebee
> > Control: forcemerge 892646 -1
> > 
> > On Wed, 2018-09-05 at 06:52 +0200, Felix Dörre wrote:
> > > Package: nvidia-driver
> > > Version: 390.77-1
> > > Severity: important
> > > 
> > > Dear Maintainer,
> > > 
> > > I have an Nvidia-Optimus setup and use bumblebee to activate the
> > > Nvidia GPU on demand.
> > > 
> > > When I use libvulkan.so.1 to run a Vulkan application the ICD
> > > from
> > > Nvidia (installed in /usr/share/vulkan/icd.d/nvidia_icd.json,
> > > /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1) opens a connection
> > > to
> > > the
> > > default X Display (as specified by the DISPLAY environment
> > > variable).
> > > When using bumblebee to activate the Nvidia GPU, the driver must
> > > connect to Display :8, where bumblebee runs the secondary
> > > X Server. However I want to run my application with the DISPLAY
> > > environment variable set to :0 (as I want it displayed on :0).
> > > 
> > > I generally would expect the Vulkan-Nvidia driver not to require
> > > an
> > > X-connection when doing headless rendering and for 'normal'
> > > rendering
> > > use the X-connection/display that is indicated by the surface-
> > > creation functions, and not choose one by itself on startup.
> > > If that is hard to achieve, I would at least expext the Nvidia-
> > > Driver
> > > to have some override environment variable (like e.g. NV_DISPLAY)
> > > that, when set, is passed by the Nvidia-Driver to XOpenDisplay,
> > > that
> > > "normal" applications would ignore.
> > 
> > Hi, Vulkan is not supported on Optimus, see #892646.
> > 
> 
> :-) Yes, that's exactly what I am currently trying to implement when
> I 
> encountered this problem. The misbehavior I am describing is a
> problem 
> in the nvidia driver that obstructs me from implementing a primus-
> like 
> solution for vulkan. For this I only use bumblebee to activate the
> GPU 
> and don't use/need primus for the GL-bridge.
> 
> Additionally I believe that also non-Optimus users can encounter
> this 
> problem in non-standard usage scenarios, when the environment
> variable 
> DISPLAY is wrong and the application uses another way to determine
> the 
> correct display to call XOpenDisplay upon. The driver will then fail
> to 
> load, however it should not depend on $DISPLAY at all.

That's why I wrote Optimus, as far as I'm aware I don't believe there
is any support from Nvidia in the proprietary drivers to do that at the
moment, you'll need to report it to Nvidia, but I wouldn't hold my
breath...

-- 
Kind regards,
Luca Boccassi

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

Bug#908248: linux-image-amd64: udev hung due to CCP, long shutdown due to process stuck

[Tomas Lacher]

Package: linux-image-amd64
Version: 4.18+98
Severity: important

Issue apply to testing kernel 4.17.*, kernel 4.18 installed to proof the issue 
was not solved in newer kernel release.
Due to the process hung the shutdown of the system takes 5 - 10 minutes where 
message about "dead" udev process is printed into terminal.
No other issues currently visible.

[  242.542652] INFO: task systemd-udevd:644 blocked for more than 120 seconds.
[  242.542658]   Not tainted 4.18.0-1-amd64 #1 Debian 4.18.6-1
[  242.542660] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  242.542662] systemd-udevd   D0   644619 0x8124
[  242.542665] Call Trace:
[  242.542674]  ? __schedule+0x2b7/0x880
[  242.542678]  ? __wake_up_common_lock+0x89/0xc0
[  242.542680]  schedule+0x28/0x80
[  242.542691]  __sev_do_cmd_locked+0x1f0/0x270 [ccp]
[  242.542694]  ? finish_wait+0x80/0x80
[  242.542700]  sev_do_cmd+0x2a/0x40 [ccp]
[  242.542702]  ? 0xc088
[  242.542707]  sev_get_api_version+0x34/0xa0 [ccp]
[  242.542713]  ? sp_get_psp_master_device+0x63/0x80 [ccp]
[  242.542717]  psp_pci_init+0x43/0x220 [ccp]
[  242.542719]  ? 0xc088
[  242.542724]  sp_mod_init+0x16/0x1000 [ccp]
[  242.542728]  do_one_initcall+0x46/0x1c8
[  242.542731]  ? free_unref_page_commit+0x95/0x120
[  242.542733]  ? _cond_resched+0x15/0x40
[  242.542736]  ? kmem_cache_alloc_trace+0x15d/0x1c0
[  242.542739]  ? do_init_module+0x22/0x201
[  242.542741]  do_init_module+0x5b/0x201
[  242.542743]  load_module.constprop.56+0x1649/0x1d80
[  242.542746]  ? vfs_read+0x113/0x130
[  242.542748]  ? vfs_read+0x113/0x130
[  242.542750]  ? __do_sys_finit_module+0xe9/0x110
[  242.542752]  __do_sys_finit_module+0xe9/0x110
[  242.542755]  do_syscall_64+0x55/0x110
[  242.542758]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  242.542761] RIP: 0033:0x7f45ce4f6a79
[  242.542761] Code: Bad RIP value.
[  242.542768] RSP: 002b:7fff05345988 EFLAGS: 0246 ORIG_RAX: 
0139
[  242.542770] RAX: ffda RBX: 562209a42c80 RCX: 7f45ce4f6a79
[  242.542771] RDX:  RSI: 7f45ce1fe0ed RDI: 0007
[  242.542772] RBP: 7f45ce1fe0ed R08:  R09: 
[  242.542773] R10: 0007 R11: 0246 R12: 
[  242.542774] R13: 562209a40300 R14: 0002 R15: 562209a5a6e0

HW info:
MSI X370 XPOWER GAMING TITANIUM (MS-7A31)
CPU: Ryzen 1700x
BIOS setting: default
BIOS release: 1.G0 / 07/12/2018 (tested with N-1 version)

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

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

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.18.0-1-amd64  4.18.6-1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#908155: Coordination with upstream developers not universally applied

[Ian Jackson]

Thorsten Glaser writes ("Re: Bug#908155: Coordination with upstream developers 
not universally applied"):
> Yes, but that does not mean we should make it permitted by the rules
> to slack in that \u201Cduty\u201D.

I find this rhetoric, that overwhelmed maintainers who are not able to
deal individually with every bug report, are "slacking" in their
"duty", quite objectionable, I'm afraid.

> Ian Jackson ,
> > What did you think of the text I proposed just over <- there, that
> > Moritz was happy with ?
> 
> Just answering because of this: I think it way too lax still.

You should perhaps propose a countertext, but given what you say above
I doubt it would find consensus.

Ian.

Bug#907734: package-contains-documentation-outside-usr-share-doc false positive

[Chris Lamb]

tags 907734 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/f6941026e6c08a86e1c2d037ae43373bcb7c4e08

  checks/files.pm| 1 +
  debian/changelog   | 3 +++
  t/tests/files-package-contains-foo/debian/debian/rules | 3 ++-
  3 files changed, 6 insertions(+), 1 deletion(-)


Regards,

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

Bug#908170: texlive-latex-extra: \documentclass[italian]{europecv} causes "File ended while scanning definition of \ecv@cvofkey"

[Francesco Poli]

On Fri, 7 Sep 2018 10:12:14 +0900 Norbert Preining wrote:

[...]
> Hi Francesco,
> 
> (btw, wintermute is also the name of an episode in The Long Dark, one of
> my favorite games ;-)

I don't know whether the authors of _The Long Dark_ got inspiration
from there, but Wintermute (Invernomuto in the Italian translation)
is one of the main [characters] of the novel _Neuromancer_ by William
Gibson...
[characters]: 

> 
> > By trial and error, I found out that the attached patch fixes (or works
> > around) the issue.
> > 
> > Is there a better fix, by chance?
> 
> No, this is the correct fix, it is a typo to have the \ there.

Wow, that's a relief!   :-)

> 
> It is already fixed upstream at
>   https://github.com/gsilano/EuropeCV/
> see commit
>   
> https://github.com/gsilano/EuropeCV/commit/b168ca441b2aa7cd8b289f71fd2a67185085f21a
> and will be in the next release.

Wonderful, thanks a lot for searching and for replying so promptly!
That's much appreciated.

> 
> Best

Bye and thanks again.


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


pgpMrY4CGgN1s.pgp
Description: PGP signature

Bug#908247: long descriptions are empty

[s3v]

Source: haskell-yi-frontend-vty
Version: 0.17.1-1
Severity: minor


Dear maintainer,
 Please fix long descriptions for libghc-yi-frontend-vty-{dev,prof,doc} packages
as the current ones are almost empty.

  [...]
  Vcs-Git: https://salsa.debian.org/haskell-team/DHG_packages.git
  X-Description: Vty frontend for Yi editor
<- empty
  [...]

Regards

Bug#908155: Coordination with upstream developers not universally applied

[Adam D. Barratt]

On Fri, 2018-09-07 at 18:42 +0200, Thorsten Glaser wrote:
> Short answer (slightly drunk and short on time), more later:
> 
> On Fri, 7 Sep 2018, Ian Jackson wrote:
> 
> > In some packages this will not be possible at least for some bug
> > reports.  You've seen the poor quality and hard-to-follow-up bug
> 
> […]
> 
> Yes, but that does not mean we should make it permitted by the rules
> to slack in that “duty”.

An arguably small point, but the Developer's Reference is explicitly
*not* "the rules".

Its own scope statement makes this clear:


Furthermore, this document is not an expression of formal policy. It
contains documentation for the Debian system and generally agreed-upon
best practices. Thus, it is not what is called a ``normative''
document.


Regards,

Adam

Bug#908176: jhead: Buffer Overflow while running jhead

[Ludovic Rousseau]

Hello,

Please request a new CVE ID.
As Salvatore Bonaccorso wrote in http://bugs.debian.org/907925

" Can you please request a CVE via the webform at https://cveform.mitre.org/ and 
once the CVE assigned loop it back here?"

Thanks

Le 07/09/2018 à 05:54, Hanfang Zhang a écrit :

Package: jhead
Version: 1:3.00-7
Vulerability type: Buffer Overflow

An buffer overflow bug was found in jhead, which allows attackers to casue a 
denial of service via a crafted JPEG file.

Components: gpsinfo.c -> ProcessGpsInfo() ->line 164
```
case TAG_GPS_ALT://BUG
     sprintf(ImageInfo.GpsAlt + 1, "%.2fm",
         ConvertAnyFormat(ValuePtr, Format));
     break;
```
Output:
```
gdb-peda$ bt
#0  0x77739428 in __GI_raise (sig=sig@entry=0x6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7773b02a in __GI_abort () at abort.c:89
#2  0x7777b7ea in __libc_message (do_abort=do_abort@entry=0x2,
     fmt=fmt@entry=0x7789349f "*** %s ***: %s terminated\n") at 
../sysdeps/posix/libc_fatal.c:175
#3  0x7781d15c in __GI___fortify_fail (msg=, 
msg@entry=0x77893430 "buffer overflow detected")
     at fortify_fail.c:37
#4  0x7781b160 in __GI___chk_fail () at chk_fail.c:28
#5  0x7781a6c9 in _IO_str_chk_overflow (fp=, c=) at vsprintf_chk.c:31
#6  0x7777f6b0 in __GI__IO_default_xsputn (f=0x7fff79b0, 
data=, n=0x19) at genops.c:455
#7  0x7775625a in __GI___printf_fp_l (fp=fp@entry=0x7fff79b0, 
loc=, info=info@entry=0x7fff7530,
     args=args@entry=0x7fff7510) at printf_fp.c:1236
#8  0x77756bd9 in ___printf_fp (fp=fp@entry=0x7fff79b0, 
info=info@entry=0x7fff7530,
     args=args@entry=0x7fff7510) at printf_fp.c:1257
#9  0x777530b9 in _IO_vfprintf_internal (s=s@entry=0x7fff79b0, 
format=,
     format@entry=0x40f640 "%.2fm", ap=ap@entry=0x7fff7ae8) at 
vfprintf.c:1631
#10 0x7781a754 in ___vsprintf_chk (s=0x61659f  
"944473296573929042", flags=0x1, slen=0x13,
     format=0x40f640 "%.2fm", args=args@entry=0x7fff7ae8) at 
vsprintf_chk.c:82
#11 0x7781a6ad in ___sprintf_chk (s=, 
flags=flags@entry=0x1, slen=slen@entry=0x13,
     format=format@entry=0x40f640 "%.2fm") at sprintf_chk.c:31
#12 0x00409649 in sprintf (__fmt=0x40f640 "%.2fm", __s=) 
at /usr/include/x86_64-linux-gnu/bits/stdio2.h:33
#13 ProcessGpsInfo (DirStart=, OffsetBase=OffsetBase@entry=0x6182d8 
"MM", ExifLength=ExifLength@entry=0x13e)
     at gpsinfo.c:164
#14 0x00407980 in ProcessExifDir (DirStart=DirStart@entry=0x6182e0 "", 
OffsetBase=OffsetBase@entry=0x6182d8 "MM",
     ExifLength=ExifLength@entry=0x13e, NestingLevel=NestingLevel@entry=0x0) at 
exif.c:867
#15 0x00407b86 in process_EXIF (ExifSection=ExifSection@entry=0x6182d0 
"\001FExif", length=length@entry=0x146)
     at exif.c:1035
#16 0x00404ab3 in ReadJpegSections (infile=infile@entry=0x617070, 
ReadMode=ReadMode@entry=READ_METADATA) at jpgfile.c:287
#17 0x00404dce in ReadJpegSections (ReadMode=READ_METADATA, 
infile=0x617070) at jpgfile.c:126
#18 ReadJpegFile (FileName=FileName@entry=0x7fffe376 "poc", 
ReadMode=READ_METADATA) at jpgfile.c:375
#19 0x00402ac1 in ProcessFile (FileName=0x7fffe376 "poc") at 
jhead.c:896
#20 0x0040183c in main (argc=argc@entry=0x2, 
argv=argv@entry=0x7fffdff8) at jhead.c:1729
#21 0x77724830 in __libc_start_main (main=0x4016b0 , argc=0x2, 
argv=0x7fffdff8, init=,
     fini=, rtld_fini=, stack_end=0x7fffdfe8) 
at ../csu/libc-start.c:291
#22 0x00402219 in _start ()

```
ConvertAnyFormat function converts ValuePtr to another data type by using 
Format value. When Format value equals to 11, the ValuePtr should be convert to 
double type. There is no type checking in the parameters in sprintf function. 
In this case, “%.2fm” corresponds to the float type data, ConvertAnyFormat() 
corresponds to the double type data. So it causes undesirable behavior 
including buffer overflow.  Replacing sprintf with snprintf may fix this bug.



--
 Dr. Ludovic Rousseau

Bug#908131: forcibly merging 908087 908131

[Salvatore Bonaccorso]

Hi Thorsten,

On Fri, Sep 07, 2018 at 04:44:54PM +0200, Thorsten Glaser wrote:
> Hi Salvatore,
> 
> > forcemerge 908087 908131
> 
> I don’t think these are the same bug.

Ah right, so let's unmerge thos again. Sorry for the wrong merge then.

Salvatore

Bug#908246: r-cran-shazam: FTBFS (missing build-dependencies)

[Santiago Vila]

Package: src:r-cran-shazam
Version: 0.1.9-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem R
   dh_testdir -i -O--buildsystem=R
   dh_update_autotools_config -i -O--buildsystem=R
   dh_autoreconf -i -O--buildsystem=R
   dh_auto_configure -i -O--buildsystem=R
   dh_auto_build -i -O--buildsystem=R
   dh_auto_test -i -O--buildsystem=R
   create-stamp debian/debhelper-build-stamp
 fakeroot debian/rules binary-indep
dh binary-indep --buildsystem R
   dh_testroot -i -O--buildsystem=R
   dh_prep -i -O--buildsystem=R
   dh_installdirs -i -O--buildsystem=R
   dh_auto_install -i -O--buildsystem=R
I: R Package: shazam Version: 0.1.9
I: Building using R version 3.5.1-1
I: R API version: r-api-3.5
I: Using built-time from d/changelog: Sat, 16 Jun 2018 18:29:24 +0200
mkdir -p /<>/debian/r-cran-shazam/usr/lib/R/site-library
R CMD INSTALL -l 
/<>/debian/r-cran-shazam/usr/lib/R/site-library --clean . 
"--built-timestamp='Sat, 16 Jun 2018 18:29:24 +0200'"
ERROR: dependencies 'alakazam', 'diptest', 'kedd', 'SDMTools' are not available 
for package 'shazam'
* removing '/<>/debian/r-cran-shazam/usr/lib/R/site-library/shazam'
dh_auto_install: R CMD INSTALL -l 
/<>/debian/r-cran-shazam/usr/lib/R/site-library --clean . 
"--built-timestamp='Sat, 16 Jun 2018 18:29:24 +0200'" returned exit code 1
make: *** [debian/rules:4: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


The build was made in my autobuilder with "dpkg-buildpackage -A",
but it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/r-cran-shazam.html

Thanks.

Bug#908236: RFS: faba-icon-theme/4.3-1

[David Mohammed]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "faba-icon-theme"

 * Package name: faba-icon-theme
   Version : 4.3-1
  Upstream Author : Sam Hewitt 
 * URL : github.com/moka-project/faba-icon-theme
 * License : GPL-3 or CC-BY-SA-4.0
   Section : misc

  It builds those binary packages:

faba-icon-theme - Tango influenced icon theme called Faba

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

  https://mentors.debian.net/package/faba-icon-theme


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

dget -x 
https://mentors.debian.net/debian/pool/main/f/faba-icon-theme/faba-icon-theme_4.3-1.dsc

Notes:
1. lintian -i -I --pedantic run on the build changes
 Information testsuite-autopkgtest-missing --> I don't think an
autopkgtest is required for an icon theme
 pedantic debian-watch-does-not-check-gpg-signature --> upstream does
not sign their tarballs
2. check-all-the-things run and where necessary actioned
3. 4. May I request that this package be added to my debian maintainers list
of packages I'm allowed to look after (dak fossfree...@ubuntu.com) ?

  Changes since the last upload:

  * New upstream release
  * Packaging changes:
- control: Bump Standards-Version; rules build made more verbose
- control: VCS fields update for debian repo name change
- control: debhelper (and compat) updated
- control: updated build-dependencies for new meson build
- rules: removed autoreconf since now a meson build
- control: Maintainer email address change
- copyright: year, package & source maintainer license updates
- upstream/metadata: source maintainer updates

  Regards,
   David Mohammed

Bug#908237: libnumbertext-tools: "spellout" is not in $PATH and looks for data in the wrong places

[Stephane Chazelas]

Package: libnumbertext-tools
Version: 1.0-2
Severity: normal

$ dpkg -L libnumbertext-tools
[...]
/usr/lib/libnumbertext/spellout

The tool is meant to be invoked by the end user, but is not
located in a directory in $PATH. I would expect it to go in
/usr/bin (and have a corresponding man page in
/usr/share/man/man1).

Also:

$ /usr/lib/libnumbertext/spellout -l en 101
spellout: missing language module

Using "strace", we see:

$ strace -e file /usr/lib/libnumbertext/spellout -l en 101
[...]
openat(AT_FDCWD, "en.sor", O_RDONLY)= -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "en.sor", O_RDONLY)= -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/numbertext/en.sor", O_RDONLY) = -1 ENOENT (No such 
file or directory)
openat(AT_FDCWD, "/usr/share/numbertext/en.sor", O_RDONLY) = -1 ENOENT (No such 
file or directory)
openat(AT_FDCWD, "data/en.sor", O_RDONLY) = -1 ENOENT (No such file or 
directory)
openat(AT_FDCWD, "data/en.sor", O_RDONLY) = -1 ENOENT (No such file or 
directory)
openat(AT_FDCWD, "data/en.sor", O_RDONLY) = -1 ENOENT (No such file or 
directory)
openat(AT_FDCWD, "data/en.sor", O_RDONLY) = -1 ENOENT (No such file or 
directory)

It looks first in "en.sor" in the current directory, which is a
security vulnerability (for instance when run in /tmp where some
attacker could have planted a malicious "en.sor" file).

And then in "/usr/share/numbertext" while "libnumbertext-data"
installs those files in "/usr/share/libnumbertext" instead.

A work around is to run:

$ /usr/lib/libnumbertext/spellout -l /usr/share/libnumbertext/en 101
one hundred one

Though it doesn't work for en-GB for which you'd need:

$ (cd /usr/share/libnumbertext && /usr/lib/libnumbertext/spellout -l en-GB 101)
one hundred and one

(but again looking in the current directory is a bad idea, so I'd expect that
one to stop working in a future version).

$ /usr/lib/libnumbertext/spellout -l /usr/share/libnumbertext/en-GB 101
one hundred one

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

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

Versions of packages libnumbertext-tools depends on:
ii  libc62.27-5
ii  libgcc1  1:8.2.0-4
ii  libnumbertext-1.0-0  1.0-2
ii  libstdc++6   8.2.0-4

libnumbertext-tools recommends no packages.

libnumbertext-tools suggests no packages.

-- debconf-show failed

Bug#907423: lintian should give an error when both foo-dbg and foo-dbgsym are built

[Chris Lamb]

tags 907423 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/2e52f1aaf612b03701502b6503a300cb87fb520f

  checks/changes-file.desc   | 11 +++
  checks/changes-file.pm |  8 +
  debian/changelog   |  3 ++
  .../debian/debian/control.in   | 36 ++
  .../desc   |  7 +
  .../tags   |  3 ++
  t/tests/control-file-general/tags  |  1 +
  7 files changed, 69 insertions(+)


Regards,

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

Bug#908155: Coordination with upstream developers not universally applied

[Thorsten Glaser]

Short answer (slightly drunk and short on time), more later:

On Fri, 7 Sep 2018, Ian Jackson wrote:

> In some packages this will not be possible at least for some bug
> reports.  You've seen the poor quality and hard-to-follow-up bug
[…]

Yes, but that does not mean we should make it permitted by the rules
to slack in that “duty”.

A “should” may be violated within reason, so keep it that.

> […]
Not commenting on the text in between for now.

> What did you think of the text I proposed just over <- there, that
> Moritz was happy with ?

Just answering because of this: I think it way too lax still.

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

*

**Besuchen Sie uns auf der dmexco 2018!**

12**. **& 13. September 2018, Koelnmesse / **Halle 7,** **Stand A-031**

Digital Business, Marketing und Innovation

[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

*

**Visit us at dmexco 2018!**

12th & 13th September, 2018, Koelnmesse / **Hall 7,** **Booth A-031**

Digital business, marketing and innovation

[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

*

Bug#908235: O: wnpp - Work-Needing and Prospective Packages

[Sebastian Tobie]

Package: eggdrop
Severity: normal

since 2011 the package eggdrop was not updated and bugs were not fixed. 2016 
the upstream developer released a new minor Version where many issues which 
where reported to Debian were fixed.

Bug#908234: cjs: Please switch to mozjs60

[Jeremy Bicha]

Source: cjs
Version: 3.8.0-4
Severity: important
Forwarded: https://github.com/linuxmint/cjs/issues/69

Firefox 52 ESR is no longer supported by Mozilla so neither is mozjs52.

Ideally, cjs would switch to using mozjs60. I understand this will
require coordination with the Cinnamon developers.

mozjs60 is currently in the NEW queue.

Thanks,
Jeremy Bicha

Bug#908120: gnome-terminal: Cursor disappears when changing or moving windows

[Ron Lovell]

I just noticed that none of our messages mention that this is an issue only
for Wayland GNOME sessions. So starting an Xorg GNOME session is a
temporary workaround.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#908233: ITP: mview -- biological sequence alignment conversion

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: mview
  Version : 1.64
* URL : https://desmid.github.io/mview/
* License : GPL
  Programming Lang: Perl
  Description : biological sequence alignment conversion

Team-maintained on https://salsa.debian.org/med-team/mview.

Bug#908155: Coordination with upstream developers not universally applied

[Ian Jackson]

Thorsten Glaser writes ("Re: Bug#908155: Coordination with upstream developers 
not universally applied"):
> As long as it\u2019s a \u201Cshould\u201D in the same sense as
> \u201Cshould fix bugs in their packages\u201D, and package
> maintainers keep an eye on users\u2019 bug reports and, when
> necessary, help them (providing infos to upstream, packages to test
> to users who can\u2019t (easily) build themselves, and, yes,
> definitely *also* forward bugs upstream, occasionally.
> 
> Does this sound like an option?

In some packages this will not be possible at least for some bug
reports.  You've seen the poor quality and hard-to-follow-up bug
reports that some packages get in large numbers.  And it is precisely
the bug reporters who would need the most help to deal with upstream,
where doing the work for them is the most difficult.

We will just have to accept that not all bug reports will be properly
investigated.  We should focus our effort on the bug reports that are
most likely to lead to improvements in the software, given available
levels of effort.  And we should therefore not write things in our
documents that discourage maintainers from prioritising appropriately.


I get the impression that you are looking at this from the point of
view of the user, who wants their bug fixed, and is perhaps not able
or willing to report it upstream.  Such a user does have a problem,
and when one is such a user, it is frustrating.

But, the main point of bug reports, from Debian's point of view, is
not to help users.  As the Information for GNU maintainers has it:

  The main purpose of bug reports is to help you contribute to the
  community by improving the next version of the program. Many of the
  people who report bugs don't realize this - they think that the
  point is for you to help them individually.  Some will ask you to
  focus on that instead of on making the program better.  If you
  comply with their wishes, you will have been distracted from the job
  of maintaining the program.

This means that many users will go un-helped.  That is, sadly,
inevitable.  We in Debian cannot possibly be the support desk for all
our users.  The more successful we become, the less possible that is.

Our responsibility is to enable others, nearer the users, to help
them, by making our software Free and accessible, by providing
appropriate documentation, by (scaleable) outreach activities, and so
on.


What did you think of the text I proposed just over <- there, that
Moritz was happy with ?

Ian.

-- 
Ian JacksonThese opinions are my own.

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