Bug#876789: [Freewx-maint] Bug#876789: python-wxgtk-webview3.0: Depends on libwxgtk-webview3.0-0v5 which depends on webkit1

[Olly Betts]

On Mon, Sep 25, 2017 at 10:37:34PM -0400, Scott Talbert wrote:
> On Tue, 26 Sep 2017, Olly Betts wrote:
> >If we revert the change which added this package apart from one hunk in
> >debian/rules then we get a package set which simply doesn't have
> >wx.html2 (rather than a broken one), which seems good so I've uploaded.
> 
> I would think the person who was trying to use wx.html2 might not agree with
> that.

"wx.html2" is actually how wxPython wraps webview:

| I have put the wxPython verison of them in the wx.html2 module
| because the wxWebKit project already produces a wx.webview module for
| wxPython.

So it's inevitable that wx.html2 is not going to work once webview is
disabled in wxWidgets.

Cheers,
Olly

Bug#876799: samba: new upstream version (4.7.0)

[Paul Wise]

Source: samba
Severity: wishlist

There is a new upstream version of samba (4.7.0) that switches to SMB3
by default for the client side, which is something we need at work.
I would like to see it unstable so that we can test it.

https://www.samba.org/samba/history/samba-4.7.0.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#876762: linux-image-3.16.0-4-amd64: tmpf file system sometimes has undeletable directories/files

[Dianne Skoll]

Hi,

I have not had time to reproduce this yet, but in the meantime, I think it's 
the same as this Red Hat bug: 
https://bugzilla.redhat.com/show_bug.cgi?id=1066751

I will use the script from that bug to try to reproduce the issue.

Regards,

Dianne.

Bug#850180: mdadm: systemd units do not obey /etc/default/mdadm, esp DAEMON_OPTIONS=--syslog

[Matthew Gabeler-Lee]

Package: mdadm
Version: 3.4-4+b1
Followup-For: Bug #850180

The DAEMON_OPTIONS bit of this is trivially corrected with this patch:

--- mdmonitor.service.orig  2017-09-26 00:54:25.491632797 -0400
+++ /lib/systemd/system/mdmonitor.service   2017-09-26 00:54:29.047611746 
-0400
@@ -10,4 +10,5 @@
 DefaultDependencies=no
 
 [Service]
-ExecStart=/sbin/mdadm --monitor --scan
+EnvironmentFile=-/etc/default/mdadm
+ExecStart=/sbin/mdadm --monitor --scan $DAEMON_OPTIONS


-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing'), (500, 'oldstable'), (490, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages mdadm depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u1
ii  lsb-base   9.20161125
ii  udev   232-25+deb9u1

Versions of packages mdadm recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.89-2+deb9u1
ii  kmod   23-2

mdadm suggests no packages.

-- Configuration Files:
/etc/cron.daily/mdadm changed [not included]

-- debconf information excluded

Bug#863734: unblock: gnupg2/2.1.18-8

[Daniel Kahn Gillmor]

On Sat 2017-09-23 19:46:42 +0100, Adam D. Barratt wrote:
> On Wed, 2017-09-20 at 23:07 -0400, Daniel Kahn Gillmor wrote:
>> I've built this against a stretch system and tested it on a stretch
>> system, and it still works.
>> 
>> Please advise me whether i should make an upload.
>
> With a slightly more definite changelog stanza, please go ahead. :-)

Thanks, I've uploaded.

 --dkg

Bug#876759: daisy-player: Broken autopkgtest

[Paul Gevers]

Hi Jeremy,

Would you have any idea what is going wrong? The test is extremely
simple, it calls the help option of daisy-player. On my terminal it
returns in milliseconds.

I think I either don't understand how autopkgtest works with the command
version, or this is a serious bug in autopkgtest.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#875882: bwm-ng FTCBFS: ./configure detects no input methods

[Helmut Grohne]

Hi Samuel,

On Tue, Sep 26, 2017 at 01:09:19AM -0300, Samuel Henrique wrote:
> Thanks for the bugreport and patch, but did you realized that there's a
> FTBFS on linux when this patch is applied?

Thanks for considering. I didn't see that coming, but a closer at
configure.in explains that behaviour.

> It results in configure being called with the "--with-diskstats" flag twice.

The flag is only passed once in fact. The disk input method is appended
to input methods and then it figures that since it isn't cross compiling
it checks for /proc/diskstats and adds it again.

I think this is a defect in the upstream build system: It has the
variable DISK_INPUT_FOUND to figure whether it already checked. Yet, it
doesn't check the variable and goes ahead anyway adding the input method
twice.

> I'll look further into these changes on the next days (i'll have to check
> if there's a doubled flag on kfreebsd with this patch too).

It very likely makes kfreebsd-any fail in the same way.

I see two (maybe three) ways forward:

 a)  Fix configure.in. It should be checking DISK_INPUT_FOUND and others
 to avoid adding input methods twice.

 a2) In theory it should also stop special casing $cross_compiling.
 AC_CHECK_FILE(/proc/diskstats) is perfectly fine during cross
 compilation. The check will fail, but the cross builder will
 supply the right cache variable to make it succeed.

 b)  Acknowledge that configure.in is weird and only pass these flags
 for cross compilation. Make them conditional to
 "ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))".

Do you have a preference?

Helmut

Bug#74295:

[Antonio Guerrero]

Hola

Bug#855215:

[Samuel Henrique]

severity 855215 important
thanks

I'm bumping the severity of this bug because it affects a major
functionality of the package and impacts everyone.

I'll also send a fix to oldstable very soon (it's already fixed on my local
machine).

I am sorry for taking so long to fix this, i took the package maintenance
with the bug already opened and didn't had the time to give enough
attention.

-- 
Samuel Henrique 

Bug#875882: bwm-ng FTCBFS: ./configure detects no input methods

[Samuel Henrique]

Hi Helmut,

Thanks for the bugreport and patch, but did you realized that there's a
FTBFS on linux when this patch is applied?

It results in configure being called with the "--with-diskstats" flag twice.

I'll look further into these changes on the next days (i'll have to check
if there's a doubled flag on kfreebsd with this patch too).

-- 
Samuel Henrique 

Bug#876798: RFS: nixnote2/2.0.2-1

[Boyuan Yang]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: nixnote2
   Version : 2.0.2-1
   Upstream Author : Randy Baumgarte 
 * URL : http://nixnote.org
 * License : GPL-2+
   Section : utils

  It builds those binary packages:

nixnote2   - Open Source Evernote client

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

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

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

dget -x https://mentors.debian.net/debian/pool/main/n/nixnote2/
nixnote2_2.0.2-1.dsc

  Git packaging repository:

https://anonscm.debian.org/git/collab-maint/nixnote2.git

Changes since last upload:

 nixnote2 (2.0.2-1) unstable; urgency=medium
 .
   * New upstream release.
 + Force UTF-8 encoding by default. (Closes: #864978)
   * Refresh patches.
   * Bump Standard-Version to 4.1.0.

Regards,
Boyuan Yang

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

Bug#876780: libvorbis: CVE-2017-14160

[Ron]

On Tue, Sep 26, 2017 at 12:24:14AM +0200, Petter Reinholdtsen wrote:
> [Salvatore Bonaccorso]
> > the following vulnerability was published for libvorbis.
> 
> Thank you for following up on this.  I hope a fix show up from upstream
> for this and other security issues. :)
> 
> I was just told on #xiph that this issue also might affect speex:
> 
>rillian: speex may also be affected by that
> bark_noise_hybridmp bug (CVE-2017-14160) since it includes that very
> same function, via vorbis_psy.c.
>see:
> 
> https://git.xiph.org/?p=speex.git;a=blob;f=libspeex/vorbis_psy.c;h=cb385b7a349486a09a3db20adf225100993111c5;hb=HEAD#l189
> 
> I have not verified that this is the case, but thought it best to
> mention it here until someone have time to check it out.

I think you'll find that's only included in speex if VORBIS_PSYCHO
is defined, which by default it isn't and there's no configure option
to enable it, you'd need to hand hack the source.

That was an experiment which never really proved its worth, but the
code was still around in case someone had other ideas for it.

In the case of the exported tarballs (which the current distro packages
are based on) vorbis_psy.c isn't one of the exported files.  So it's
there in git, but it's not in the Debian source, and I'd be surprised
if anyone is building binaries with it enabled anywhere.

  Cheers,
  Ron

Bug#876797: unattended-upgrades: list removed packages at the beginning of the report too

[Paul Wise]

Package: unattended-upgrades
Version: 0.97
Severity: wishlist

It would be useful to list removed packages at the beginning of the
report in addition to the existing information at the end of the
report. Sometimes unattended-upgrades removes packages that are needed and 
having them at the beginning of the report makes it easier to see if any of the 
removed packages are still wanted by the sysadmin.

Packages that are auto removed: 'libblas-common librados2 librbd1'

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

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

Versions of packages unattended-upgrades depends on:
ii  apt  1.5~rc4
ii  apt-utils1.5~rc4
ii  debconf  1.5.63
ii  init-system-helpers  1.49
ii  lsb-base 9.20170808
ii  lsb-release  9.20170808
ii  python3  3.5.3-3
ii  python3-apt  1.4.0~beta3+b1
ii  ucf  3.0036
ii  xz-utils 5.2.2-1.3

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

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20160123cvs-4
ii  exim4-daemon-light [mail-transport-agent]  4.89-6
ii  needrestart2.11-4

-- debconf information excluded

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#876796: unattended-upgrades: stop including Python syntax in the report

[Paul Wise]

Package: unattended-upgrades
Version: 0.97
Severity: minor

The report appears to contain some Python syntax, I would suggest using
a proper printer instead of using Python's default object printing
capabilities. Here are some examples of what I'm talking about:

Allowed origins are: ['origin=Debian', 'origin=Debian']
Writing dpkg log to '/var/log/unattended-upgrades/unattended-upgrades-dpkg.log'
Packages that are auto removed: 'libblas-common librados2 librbd1'

The first one should be de-duplicated and space-separated.

The second two should have the quotes removed.

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

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

Versions of packages unattended-upgrades depends on:
ii  apt  1.5~rc4
ii  apt-utils1.5~rc4
ii  debconf  1.5.63
ii  init-system-helpers  1.49
ii  lsb-base 9.20170808
ii  lsb-release  9.20170808
ii  python3  3.5.3-3
ii  python3-apt  1.4.0~beta3+b1
ii  ucf  3.0036
ii  xz-utils 5.2.2-1.3

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

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20160123cvs-4
ii  exim4-daemon-light [mail-transport-agent]  4.89-6
ii  needrestart2.11-4

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#876274: wordpress: 9 security bugs in wordpress 4.8.1 and earlier

[Craig Small]

On Tue, 26 Sep. 2017, 11:03 Ángel  wrote:

> What about the versions on wheezy/jessie/stretch? Should they be handled
> on this bug, get a new one for each, or will they simply be handled
> without one by the security team, now they have CVEs¹?
>
Stretch security release I am waiting for security team to approve the
upload.

Rodrigo has made a backport for Jessie. I'll try to upload it in the next
24 hours.

That's all the other versions I know of.

 - Craig
-- 
Craig Small https://dropbear.xyz/ csmall at : enc.com.au
Debian GNU/Linuxhttps://www.debian.org/   csmall at : debian.org
Mastodon: @smalls...@social.dropbear.xyz Twitter: @smallsees
GPG fingerprint:  5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Bug#790222: [boinc_dev] Bug#790222: wxwidgets3.0: depends on libwebkitgtk-1.0-0 which is deprecated

[Olly Betts]

On Mon, Sep 25, 2017 at 10:37:50PM -0400, Jeremy Bicha wrote:
> Ok, let me give a status update of the webkitgtk removal from Debian Testing:
> 
> $ reverse-depends -r testing src:webkitgtk
> Reverse-Depends
> ===
> * empathy   (for libwebkitgtk-3.0-0)
> * geary (for libwebkitgtk-3.0-0)
> * libwebkit1.1-cil  (for libwebkitgtk-1.0-0)
> * libwxgtk-webview3.0-0v5   (for libwebkitgtk-1.0-0)
> 
> empathy is fixed in unstable but it needs a new upload to probably
> revert to 3.12.14 so that's several days away from being fixed in
> testing.
> geary is fixed in unstable and I expect it to drop off the list in ~ 4 days.
> libwebkit1.1-cil's last reverse dependency is fixed in unstable so
> that can be removed from testing in ~4 days. src:webkit-sharp has no
> reverse-dependencies in testing.
> 
> That leaves wxwidgets3.0 and its 2 rdepends: boinc and
> python-wxgtk-webview3.0. python-wxgtk-webview3.0 has no reverse
> dependencies and I think it sounds like it's going to be dropped now:
> https://bugs.debian.org/876789

Yes, I uploaded to drop that binary package earlier today.

> Therefore, the way I see it, boinc/wxwidgets3.0 is the only remaining
> blocker for removing webkitgtk from Debian Testing.

Thanks for the update.

Gianfranco: Is there any progress on the boinc front?  If not, I think
we just need to do this rather than letting this removal drag on for
even longer.

Cheers,
Olly

Bug#876795: remove repeated lines from man page

[積丹尼 Dan Jacobson]

Package: libtext-charwidth-perl
Version: 0.04-7.1
Severity: wishlist
File: /usr/share/man/man3/Text::CharWidth.3pm.gz

These two lines

   mbwidth(string) returns the width of the first character of the string.
   mbswidth(string) returns the width of the whole string.

can be removed, because they are already mentioned above.

Bug#874580: stretch-pu: package waagent/2.2.14-1~deb9u1

[Martin Zobel-Helas]

Yes

Am 25. September 2017 22:35:33 MESZ schrieb "Adam D. Barratt" 
:
>On Wed, 2017-09-20 at 13:27 +0200, Martin Zobel-Helas wrote:
>> On Wed, Sep 20, 2017 at 11:43:56AM +0200, Bastian Blank wrote:
>> > > (Also, we prefer if the full diff is included in pu bugs
>> > > directly.)
>> > 
>> >  README.md  |  39 ++-
>> >  azurelinuxagent/agent.py   |  52 ++-
>> > 
>...
>> >  119 files changed, 5634 insertions(+), 1288 deletions(-)
>> 
>> 
>> Find attached the full diff gzip'd.
>
>Thanks.
>
>That appears to be missing a changelog stanza for the stable upload. Is
>that the only proposed difference from the 2.2.14-1 unstable upload?
>
>Regards,
>
>Adam

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#876794: ibus-hangul: Java causes ibus to not work correctly (spaces incorrectly placed)

[Hwan Woong Rhee]

Package: ibus-hangul
Version: 1.5.0-2
Severity: important

Dear Maintainer,

while i'm using java base program like OmegaT and Google2srt, the ibus input 
does not work correctly for the Korean language. When typing in Korean the 
space appears before the previous character rather than after it should. When 
i'm running program other than java base program, ibus-hangul works correctly, 
Issues only arise while running java base program.

1)Expected input: "가나다 "
4)Problem input: "가나 다" // Notice the position of the space

-- java version information
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) Server VM (build 25.144-b01, mixed mode)

-- System Information:
Debian Release: 9.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages ibus-hangul depends on:
ii  gir1.2-gtk-3.0   3.22.11-1
ii  gir1.2-ibus-1.0  1.5.14-3
ii  ibus 1.5.14-3
ii  libc62.24-11+deb9u1
ii  libglib2.0-0 2.50.3-2
ii  libhangul1   0.1.0-3
ii  libibus-1.0-51.5.14-3
ii  python3  3.5.3-1
ii  python3-gi   3.22.0-2

ibus-hangul recommends no packages.

ibus-hangul suggests no packages.

-- no debconf information

Bug#790222: [boinc_dev] Bug#790222: wxwidgets3.0: depends on libwebkitgtk-1.0-0 which is deprecated

[Jeremy Bicha]

On Sun, Aug 20, 2017 at 1:54 PM, Adrian Bunk  wrote:
> wxwidgets3.0 is a key package, so won't get autoremoved from testing.
>
> And since a removal from testing would imply a removal of all
> reverse dependencies, wxwidgets3.0 is not at risk of being
> removed from testing anytime soon.
>
> While fast removal of webkitgtk from testing would be desirable,
> there is IMHO no benefit for Debian from doing a substantial amount
> of additional work for achieving this quickly - real urgency would
> be in a year when the buster freeze will be approaching.

Ok, let me give a status update of the webkitgtk removal from Debian Testing:

$ reverse-depends -r testing src:webkitgtk
Reverse-Depends
===
* empathy   (for libwebkitgtk-3.0-0)
* geary (for libwebkitgtk-3.0-0)
* libwebkit1.1-cil  (for libwebkitgtk-1.0-0)
* libwxgtk-webview3.0-0v5   (for libwebkitgtk-1.0-0)

empathy is fixed in unstable but it needs a new upload to probably
revert to 3.12.14 so that's several days away from being fixed in
testing.
geary is fixed in unstable and I expect it to drop off the list in ~ 4 days.
libwebkit1.1-cil's last reverse dependency is fixed in unstable so
that can be removed from testing in ~4 days. src:webkit-sharp has no
reverse-dependencies in testing.

That leaves wxwidgets3.0 and its 2 rdepends: boinc and
python-wxgtk-webview3.0. python-wxgtk-webview3.0 has no reverse
dependencies and I think it sounds like it's going to be dropped now:
https://bugs.debian.org/876789

Therefore, the way I see it, boinc/wxwidgets3.0 is the only remaining
blocker for removing webkitgtk from Debian Testing.

Thanks,
Jeremy Bicha

Bug#852569: how to use initramfs-tools hook-function's copy-exec

[Scott Moser]

Hi,

In cloud-initramfs-tools, udevadm is referred to by /sbin/udevadm only in
growroot/hooks/growroot with 'copy_exec /sbin/udevadm /sbin'.

It appears that even in most recent version of initramfs-tools only
supports full paths to as copy_exec's first argument.

What is the recommended way to use 'copy_exec' without a full path?

I can make cloud-initramfs-tools do something to the extent of:
  udevadm=$(which udevadm) &&
  copy_exec $udevadm /sbin ||
   { echo "failed copy_exec udevadm"; exit 1 }

But this seems like a generic issue with 'copy_exec' that it requires
full paths to files.

What is the advised solution here?

Thanks,
Scott

Bug#876789: [Freewx-maint] Bug#876789: python-wxgtk-webview3.0: Depends on libwxgtk-webview3.0-0v5 which depends on webkit1

[Scott Talbert]

On Tue, 26 Sep 2017, Olly Betts wrote:


On Tue, 26 Sep 2017, Olly Betts wrote:

So it might not actually be as easy as you might think to disable
webview here before we disable it in wxwidgets3.0...

I'll kick off a build and see.  If it doesn't just work, I'm inclined
to disable this at the same time as we do wxwidgets3.0.


If we revert the change which added this package apart from one hunk in
debian/rules then we get a package set which simply doesn't have
wx.html2 (rather than a broken one), which seems good so I've uploaded.


I would think the person who was trying to use wx.html2 might not agree 
with that.



Yeah, I would say we should just do this when wxwidgets3.0 loses its webkit1
dependency (or preferably this problem just goes away when switching
wxwidgets to GTK+ 3).


I wouldn't rely on a switch to GTK+ 3 happening for buster - I did a bit
of work towards it, and upstream are responsive to reports of bugs under
GTK+ 3 (at least when they can reproduce them) but unfortunately I don't
really have the time to drive this forwards currently, and nobody else
seems to be actively working on it.


:(

Bug#876789: [Freewx-maint] Bug#876789: python-wxgtk-webview3.0: Depends on libwxgtk-webview3.0-0v5 which depends on webkit1

[Olly Betts]

On Mon, Sep 25, 2017 at 08:54:16PM -0400, Scott Talbert wrote:
> On Tue, 26 Sep 2017, Olly Betts wrote:
> >So it might not actually be as easy as you might think to disable
> >webview here before we disable it in wxwidgets3.0...
> >
> >I'll kick off a build and see.  If it doesn't just work, I'm inclined
> >to disable this at the same time as we do wxwidgets3.0.

If we revert the change which added this package apart from one hunk in
debian/rules then we get a package set which simply doesn't have
wx.html2 (rather than a broken one), which seems good so I've uploaded.

> Yeah, I would say we should just do this when wxwidgets3.0 loses its webkit1
> dependency (or preferably this problem just goes away when switching
> wxwidgets to GTK+ 3).

I wouldn't rely on a switch to GTK+ 3 happening for buster - I did a bit
of work towards it, and upstream are responsive to reports of bugs under
GTK+ 3 (at least when they can reproduce them) but unfortunately I don't
really have the time to drive this forwards currently, and nobody else
seems to be actively working on it.

Cheers,
Olly

Bug#689561: wiki: add support for checking status of bugs in bugzilla

[Paul Wise]

On Mon, 2017-09-25 at 12:31 -0400, James Montgomery wrote:

> This is interesting. For clarification, is your intent to have a tag
> similar to (DebianBug:nnn) for additional Bugzilla  installations?

That is one option, the other is to just recognise links to known
Bugzilla instances or all bugzilla.*.* or show_bug.cgi links.

For the Debian bugstatus stuff, we took both approaches;
check both DebianBug links and all bug links to bugs.debian.org.

Since there are a number of links to bugzilla instances,
I would suggest starting with detecting links to those:

https://wiki.debian.org/InterWikiMap?action=fullsearch=180=show_bug.cgi=Text

BTW, we do have a few interwiki link systems for bugs,
but none of them are for bugzilla instances AFAICT:

https://wiki.debian.org/InterWikiMap

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#876793: libopenshot-audio: FTBFS on m68k: EmptyString and StringHolder differ in size

[Aaron M. Ucko]

Source: libopenshot-audio
Version: 0.1.4+ds1-2
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-m...@lists.debian.org

Builds of libopenshot-audio for m68k (admittedly not a release
architecture) have been failing:

  ./../../modules/juce_core/text/juce_String.cpp: In member function 'void 
juce::StringHolder::compileTimeChecks()':
  ./../../modules/juce_core/system/juce_PlatformDefs.h:179:38: error: static 
assertion failed: sizeof (EmptyString) == sizeof (StringHolder)

Atomic<> evidently imposes a size overhead here. :-/

Could you please take a look?

Incidentally, you really ought to look into building against separately
packaged juce per Policy 4.13, but it also FTBFS on m68k (and on
non-Linux, as in #876792), so that wouldn't actually help here.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#876792: libopenshot-audio: FTBFS on non-Linux: multiple identifiers undeclared

[Aaron M. Ucko]

Source: libopenshot-audio
Version: 0.1.4+ds1-2
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org

Builds of libopenshot-audio for hurd-i386 (admittedly not a release
architecture) have been failing.  The (immediate) errors are

  
/<>/libopenshot-audio-0.1.4+ds1/JuceLibraryCode/modules/juce_core/native/juce_posix_SharedCode.h:906:6:
 error: 'pthread_setname_np' was not declared in this scope
  
/<>/libopenshot-audio-0.1.4+ds1/JuceLibraryCode/modules/juce_core/native/juce_posix_SharedCode.h:961:5:
 error: 'pthread_setaffinity_np' was not declared in this scope
  
/<>/libopenshot-audio-0.1.4+ds1/JuceLibraryCode/modules/juce_core/native/juce_linux_SystemStats.cpp:98:20:
 error: aggregate 'juce::SystemStats::getMemorySizeInMegabytes()::sysinfo sysi' 
has incomplete type and cannot be defined

Builds for kFreeBSD (not a release architecture either) have been failing
in a similar fashion, as most recently detailed at

https://buildd.debian.org/status/fetch.php?pkg=libopenshot-audio=kfreebsd-amd64=0.1.4%2Bds1-1=1498606847=0
https://buildd.debian.org/status/fetch.php?pkg=libopenshot-audio=kfreebsd-i386=0.1.4%2Bds1-1=1498005708=0

(The kFreeBSD autobuilders haven't covered 0.1.4+ds1-2 because cmake is
currently uninstallable there.)

Could you please take a look?  If making the code more portable is
infeasible, please consider restricting the package's architecture to
linux-any so that non-Linux autobuilders don't bother trying to cover it.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#876687: htpdate: Off by one hour

[Eddy Vervest]

Hi All,

It seems related to the timezone changes which Turkey had this year...
moving away from daylight saving to always +3.

In the bug report this line is interesting:

 Timezone: GMT+2 (+03,+03)

In brackets there should be a time zone in like TRT, CEST, WET... but it
tells +03... but at the same time GMT+2. Updating the TZ package
(https://packages.debian.org/stretch/tzdata) and setting the system time
to the correct timezone probably will solve the issue.

Regards, Eddy

PS. I will look into the code some more, because I don't remember why I
use time zone information in the first place... should be possible
without I guess.



On 25-09-17 03:27, Eriberto Mota wrote:
> 2017-09-24 21:29 GMT-03:00 Mert Dirik :
>> On Sun, 24 Sep 2017 18:44:55 -0300 Eriberto Mota 
>> wrote:
>>> Hi Mert,
>>>
>>> Thanks for your message.
>>>
>>> I can't reproduce it and I have a doubt about the results shown by
>>> you. Please, send me the results for the following 'date' commands:
>>>
>>> # ntpdate pool.ntp.org; date -u
>>>
>>> # htpdate -s www.google.com.tr www.facebook.com www.youtube.com; date -u
>>>
>> Hi Eriberto,
>>
>> Thanks for your prompt answer,
>>
>> Here is the output:
>>
>>> # ntpdate pool.ntp.org; date -u
>>> 25 Sep 03:21:25 ntpdate[10240]: adjust time server 194.27.222.5 offset
>>> 0.021160 sec
>>> Mon Sep 25 00:21:25 UTC 2017
>>> # htpdate -s www.google.com.tr www.facebook.com www.youtube.com; date -u
>>>
>>> Setting -3600.000 seconds
>>> Set: Mon Sep 25 02:21:44 2017
>>>
>>> Sun Sep 24 23:21:44 UTC 2017
>>> #
>
> Hum... In my machine is all right. Eddy, can you verify this issue?
> For a complete history, please, see here[1].
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876687
>
> Thanks in advance.
>
> Regards,
>
> Eriberto

Bug#876274: wordpress: 9 security bugs in wordpress 4.8.1 and earlier

[Ángel]

Rodrigo Campos wrote:
> It's already on sid and a backport is ready, will ask for BSA and craig will
> upload when the BSA is assigned.

What about the versions on wheezy/jessie/stretch? Should they be handled
on this bug, get a new one for each, or will they simply be handled
without one by the security team, now they have CVEs¹?


¹ These issues got assigned CVE-2017-14718 to CVE-2017-14726


Thanks!

Bug#876789: [Freewx-maint] Bug#876789: python-wxgtk-webview3.0: Depends on libwxgtk-webview3.0-0v5 which depends on webkit1

[Scott Talbert]

On Tue, 26 Sep 2017, Olly Betts wrote:


Looks like this package was partly enabled to fix a problem with the
build without it:

https://bugs.debian.org/821934

So it might not actually be as easy as you might think to disable
webview here before we disable it in wxwidgets3.0...

I'll kick off a build and see.  If it doesn't just work, I'm inclined
to disable this at the same time as we do wxwidgets3.0.


Yeah, I would say we should just do this when wxwidgets3.0 loses its 
webkit1 dependency (or preferably this problem just goes away when 
switching wxwidgets to GTK+ 3).


Scott

Bug#876624: RFS: qr-tools/1.4~bzr23-1 [QA]

[Ramiro Algozino]

El 25 sept. 2017 21:41, "Boyuan Yang" <073p...@gmail.com> escribió:

在 2017年9月25日星期一 CST 下午12:39:53，Ramiro Algozino 写道：
> Hello Boyuang,
>
> Thank you for CCing me and thank you for your work, specially migrating to
> Qt5, I've been trying to update qrtools for a while but never found the
> time to do it.
>
> I will try to test your contribution this week and push it to launchpad if
> you don't mind.
>
> Best regards,

Great, please go ahead.

There are still several bugs left, see [1]. I have requested to join the
Launchpad qr-tools-developers group. If you accept this request, I could try
my best to push fixes upstream.

[1] https://anonscm.debian.org/git/collab-maint/qr-tools.git/
tree/debian/BUGS

Regards,
Boyuan Yang


Unfortunately I am not the group administrator and can't accept your
request. We must wait for David Green to accept you, although I haven't
heard from him in years, let's hope for the best

Best regards,

Bug#876624: RFS: qr-tools/1.4~bzr23-1 [QA]

[Boyuan Yang]

在 2017年9月25日星期一 CST 下午12:39:53，Ramiro Algozino 写道：
> Hello Boyuang,
> 
> Thank you for CCing me and thank you for your work, specially migrating to
> Qt5, I've been trying to update qrtools for a while but never found the
> time to do it.
> 
> I will try to test your contribution this week and push it to launchpad if
> you don't mind.
> 
> Best regards,

Great, please go ahead.

There are still several bugs left, see [1]. I have requested to join the 
Launchpad qr-tools-developers group. If you accept this request, I could try 
my best to push fixes upstream.

[1] https://anonscm.debian.org/git/collab-maint/qr-tools.git/tree/debian/BUGS

Regards,
Boyuan Yang

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

Bug#876789: python-wxgtk-webview3.0: Depends on libwxgtk-webview3.0-0v5 which depends on webkit1

[Olly Betts]

On Mon, Sep 25, 2017 at 05:47:36PM -0400, Jeremy Bicha wrote:
> python-wxgtk-webview3.0 depends on libwxgtk-webview3.0-0v5 which
> depends on libwxgtk-webview3.0-0v5 which depends on
> libwebkitgtk-1.0-0. libwebkitgtk-1.0-0 is the old webkitgtk library
> that suffers from many reported CVEs that have been fixed in
> libwebkit2gtk-4.0-37 (src: webkit2gtk ). We do not intend to release
> Debian 10 "Buster" with libwebkitgtk-1.0-0.
> 
> python-wxgtk-webview3.0 has no reverse dependencies in Debian or
> Ubuntu so it seems easy to just stop building this package for now.

Looks like this package was partly enabled to fix a problem with the
build without it:

https://bugs.debian.org/821934

So it might not actually be as easy as you might think to disable
webview here before we disable it in wxwidgets3.0...

I'll kick off a build and see.  If it doesn't just work, I'm inclined
to disable this at the same time as we do wxwidgets3.0.

Cheers,
Olly

Bug#876743: flatpak: FTBFS on hppa: Creating new namespace failed: Invalid argument

[Simon McVittie]

On Mon, 25 Sep 2017 at 17:29:04 -0400, John David Anglin wrote:
> In the recent successful builds on panama, it seems bwrap fails and the
> tests were skipped.

That's normal on official buildds and machines that resemble them,
unfortunately. Flatpak uses bubblewrap (bwrap) for lightweight containers,
which is fine in a normal directory on a VM or real machine, but often
can't work when already inside a container or chroot, which is why
the Flatpak tests try a trivial bwrap run first to see whether they
can proceed.

I think the FTBFS that prompted this bug report was on a machine where
container syscalls work a bit better than on panama and on release
architectures' official buildds (so the tests aren't skipped completely),
but not as well as they do on my test VM (so the tests don't actually
*pass* either).

Official buildds are also locked-down for security reasons, and that
interferes with Flatpak's tests, causing some of them to be skipped
(kernel module loading isn't allowed, so no FUSE, for example).

> The bell and physik buildds have more memory (8 and 12 GB, respectively).

Flatpak doesn't need anywhere near that much RAM (I test it successfully
on an amd64 autopkgtest-virt-qemu VM with the default 1G RAM), so that's
unlikely to be relevant.

> I doubt the age of the kernels is the problem as current upstream kernels
> (e.g., v4.13.x) run on hppa.

OK, good to know. I thought I remembered some of the non-release
architectures needing very specific old kernels, but I'm glad to hear
hppa isn't one of those.

smcv

Bug#872174: Please install bash completion as part of the package

[Michael Biebl]

Control: tags -1 + patch

On Mon, 14 Aug 2017 22:47:53 +0200 Michael Biebl  wrote:
> Package: restic
> Version: 0.7.1-1
> Severity: wishlist
> 
> Trying to run "restic autocomplete" (as unprivileged user), I get
> $ restic autocomplete
> open /etc/bash_completion.d/restic.sh: permission denied
> 
> It would be much nicer if the restic package shipped the bash completion
> directly (as /usr/share/bash-completion/completions/restic) so it works
> ootb.
The attached patch should do the trick.
Let me know what you think.

Thanks for considering.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff -Nru restic-0.7.1/debian/changelog restic-0.7.1/debian/changelog
--- restic-0.7.1/debian/changelog	2017-07-27 08:55:09.0 +0200
+++ restic-0.7.1/debian/changelog	2017-09-26 01:35:00.0 +0200
@@ -1,3 +1,10 @@
+restic (0.7.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Generate and install bash-completion file. (Closes: #872174)
+
+ -- Michael Biebl   Tue, 26 Sep 2017 01:35:00 +0200
+
 restic (0.7.1-1) unstable; urgency=medium
 
   * New upstream version 0.7.1
diff -Nru restic-0.7.1/debian/rules restic-0.7.1/debian/rules
--- restic-0.7.1/debian/rules	2017-07-27 08:55:09.0 +0200
+++ restic-0.7.1/debian/rules	2017-09-26 01:33:49.0 +0200
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+
 export DH_OPTIONS
 # Install everything, for testdata/ directories:
 export DH_GOLANG_INSTALL_ALL := 1
@@ -21,3 +23,7 @@
 # it is not intended to be used as a library right now.
 override_dh_auto_install:
 	dh_auto_install -- --no-source
+ifeq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+	install -d debian/restic/usr/share/bash-completion/completions
+	debian/restic/usr/bin/restic autocomplete --completionfile debian/restic/usr/share/bash-completion/completions/restic
+endif


signature.asc
Description: OpenPGP digital signature

Bug#715470: RFP: cr3 -- Cool Reader 3, an e-book reader

[Axel Beckert]

Hi,

programmer11...@programist.ru wrote:
> URL   :   http://coolreader.org/

This website is a link spammer nowadays. Seems as if the project lost
its domain. :-/

The offical website seems to be
https://sourceforge.net/projects/crengine/ nowadays.

> Version   :3.0.59

But then again the latest download link there seems to have version
3.0.56. (It's even a .deb and upstream seems to have some some basic
debian-sih packaging at
https://sourceforge.net/p/crengine/crengine/ci/master/tree/packages/ —
last updated in 2012 though.)

https://f-droid.org/packages/org.coolreader/ lists version 3.1.2 from
2015 as the newest version.

Nevertheless the last commit in the git repository as of now is from
January 2017:
https://sourceforge.net/p/crengine/crengine/commit_browser

So there still seem to be a little bit of activity.

> License   :GPL

The F-Droid app page also states: "The default dictionary app is
non-free." — So anyone who's looking at packaging Cool Reader for
Debian proper should have a very close look at the licenses.

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

Bug#876762: linux-image-3.16.0-4-amd64: tmpf file system sometimes has undeletable directories/files

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 2017-09-25 at 11:43 -0400, Dianne Skoll wrote:
> Package: src:linux
> Version: 3.16.7-ckt25-2+deb8u3
> Severity: important
[...]

Please test using the current version (3.16.43-2+deb8u5).

Ben.

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


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

Bug#876787: afl: FTBFS /usr/bin/ld: unrecognized option '--no-keep-files-mapped'

[Adrian Bunk]

Control: reassign -1 clang-3.9 1:3.9.1-16
Control: affects -1 src:afl
Control: clone -1 -2 -3
Control: reassign -2 clang-4.0 1:4.0.1-5
Control: reassign -3 clang-5.0 1:5.0-2

On Mon, Sep 25, 2017 at 10:47:22PM +0200, Daniel Stender wrote:
> Package: src:afl
> Version: 2.50b-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> Control: block 873404 by -1
> 
> AFL begun to FTBFS recently with a clang error:
> 
> 
> [+] All set and ready to build.
> clang-3.9  -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign 
> -DAFL_PATH=\"/usr/lib/afl\" -DBIN_PATH=\"/usr/bin\" -DVERSION=\"2.50b\"  
> afl-clang-fast.c -o ../afl-clang-fast -Wl,-z,relro -Wl,-z,now
> ln -sf afl-clang-fast ../afl-clang-fast++
> clang++-3.9 `llvm-config-3.9 --cxxflags` -fno-rtti -fpic  -Wall 
> -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DVERSION=\"2.50b\" 
> -Wno-variadic-macros -shared afl-llvm-pass.so.cc -o ../afl-llvm-pass.so 
> `llvm-config-3.9 --ldflags` -Wl,-z,relro -Wl,-z,now
> warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean 
> '-Wno-uninitialized'? [-Wunknown-warning-option]
> 1 warning generated.
> /usr/bin/ld: unrecognized option '--no-keep-files-mapped'
> /usr/bin/ld: use the --help option for usage information
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> Makefile:83: recipe for target '../afl-llvm-pass.so' failed
> 
> 
> This seems to be a problem in the build toolchain (this is going to be
> reassigned). The same error appears also with clang-4.0 and clang-5.0, thus
> blocking the llvm-toolchain update of AFL.

The trigger is:

llvm-toolchain-3.9 (1:3.9.1-16) unstable; urgency=medium
...
  [ Matthias Klose ]
  * Link with --no-keep-files-mapped --no-map-whole-files when using gold.
...
 -- Sylvestre Ledru   Fri, 08 Sep 2017 11:57:07 +0200


But the actual bug is older:
CXXFLAGS_EXTRA += -Wl,-fuse-ld=gold -Wl,--no-keep-files-mapped 
-Wl,--no-map-whole-files

-Wl,-fuse-ld=gold is wrong, this should be -fuse-ld=gold
(it cannot work to tell the linker which linker to use).


> DS

cu
Adrian

-- 

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

Bug#876121: FTBFS: error: 'std::index_sequence' has not been declared

[Oliver Kurth]

It looks like this error went away on its own - can you confirm?


From: Bernd Zeimetz 
Sent: Monday, September 18, 2017 2:59:14 PM
To: Oliver Kurth; 876...@bugs.debian.org; Rene Engelhard
Subject: Re: Bug#876121: FTBFS: error: 'std::index_sequence' has not been 
declared

Hi,

On 09/18/2017 08:25 PM, Oliver Kurth wrote:
> We see the same issue in our internal tests at VMware. The solution
> seems to be to set CXXFLAGS=-std=c++14 for the configure command:
>
>
> CXXFLAGS=-std=c++14 ./configure --without-kernel-modules

good catch, I was actually building with
CXXFLAGS='-std=gnu++11'
before because some (other?) build-dependencies failed to build before.

Building right now:
https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_bzed_pkg-2Dopen-2Dvm-2Dtools=DwID-g=uilaK90D4TOVoH58JNXRgQ=oHeYwLSPkRE9YQPISb_awkWjWigW3oPkIDc-ePsrBjY=4lf0bElA6Fu5UXFqwpKfjSQnXAL5U99uQp5nqNtl24s=D9GR6YatOyeX6qC9C5uX-X-p_Xc2w_BA9AgePkPD1D0=

I'll test and upload it tomorrow or so if all changes work as expected.

Thanks,

Bernd

--
 Bernd ZeimetzDebian GNU/Linux Developer
 
https://urldefense.proofpoint.com/v2/url?u=http-3A__bzed.de=DwID-g=uilaK90D4TOVoH58JNXRgQ=oHeYwLSPkRE9YQPISb_awkWjWigW3oPkIDc-ePsrBjY=4lf0bElA6Fu5UXFqwpKfjSQnXAL5U99uQp5nqNtl24s=vNdNG_rVLgVZxZkIQB02h-dE5jXV-tnk9qrO_HWmfmo=
 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.debian.org=DwID-g=uilaK90D4TOVoH58JNXRgQ=oHeYwLSPkRE9YQPISb_awkWjWigW3oPkIDc-ePsrBjY=4lf0bElA6Fu5UXFqwpKfjSQnXAL5U99uQp5nqNtl24s=eIo1lI5BVFTRGcBcVAV-uFw8PVLTfXRtsFx8ZGzzTks=
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#836546: enchant FTCBFS: uses build architecture pkg-config

[Manuel A. Fernandez Montecelo]

2017-09-25 6:57 GMT+02:00 Prach Pongpanich :
> Hi,
>
> On Mon, Sep 25, 2017 at 01:25:17AM +0200, Manuel A. Fernandez Montecelo wrote:
>> Hi,
>>
>> I'd like to get this issue fixed, I could prepare an NMU in the next few
>> days.
>>
>> This package is under LowNMU clause, but still I though that it would be
>> nice to ask if it's OK with the maintainer,because the patch is slightly
>> intrusive with the upstream source.
>>
>
> Please go ahead, the repo is in collab-maint [0].
>
> [0] https://anonscm.debian.org/cgit/collab-maint/enchant.git


Done and pushed, thanks!

BTW, there's a lintian error about using "activate-noawait ldconfig",
I think that it's because of the triggers file:
debian/libenchant1c2a.triggers , it's probably implicit due to being a
package with libraries or something, thus appearing as duplicate even
if there's only one line in that file.

My advice is to remove the file and check that nothing breaks in the
local system.  I didn't fix it because I am not familiar with the
library and what uses it.

Cheers and thanks again!


-- 
Manuel A. Fernandez Montecelo 

Bug#876667: RFS: pragha/1.3.3-1

[Gabriel F. T. Gomes]

Hi, Lukas,

Thanks again for the explanations.  You are a good professor!  :)

On 25 Sep 2017, Lukas Schwaighofer wrote:

>If you want to keep using git-buildpackage, I'd suggest you do the
>following:
>
>Add a file debian/gbp.conf with the following contents and commit it:
>===
>[DEFAULT]
>pristine-tar = True
>upstream-tag = upstream/v%(version)s
>
>[buildpackage]
>ignore-branch = True
>===
>this allows you to use the gbp commands without specifying the same
>parameters over and over.  It also makes working with the repository
>easier for someone else.

That's very interesting.  I accepted your suggestion.  :)

>That's it (and it is only required once); if you build the package now
>using git-buildpackage, it will reconstruct the original tarball
>exactly as it is on github. :)

It did, indeed.

I uploaded a new version with your suggestions.
(I also updated the git repository)

Thanks again,
Gabriel

Bug#869363: Pending fixes for bugs in the gradle-debian-helper package

[pkg-java-maintainers]

tag 869363 + pending
thanks

Some bugs in the gradle-debian-helper package are closed in revision
89a13b28d91e86a14c95c2055f703f0990cf59f5 in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/gradle-debian-helper.git/commit/?id=89a13b2

Commit message:

Spawn a shell explicitly when necessary in the doit() calls of the DH 
buildsystem (Closes: #869363)

Bug#354709: screen corrupts my display when viewing certain spam mails (via mutt)

[Axel Beckert]

Control: tag -1 - moreinfo + confirmed
Control: found -1 4.1.0~20120320gitdb59704-7+deb7u1

Hi Cascardo,

Thadeu Lima de Souza Cascardo wrote:
> I have this same problem with what seems to be valid UTF-8. One possible
> reproduction test is running this on bash under screen.
> 
> echo -e '\xf0\x9f\x8d\x8c'
> 
> You will notice the extra space after that, which does not happen when
> not under screen.

Thanks for the feedback and giving me a way to reproduce and test that
(or at least a similar) issue. (And for the reminder that this bug
report is still open. :-)

Unfortunately I can't reproduce it with your example.

I tried it with bash as well as with zsh inside a screen 4.6.1
session, but everything looks fine.

I also tried

echo -e '\xf0\x9f\x8d\x8c'x

to see if there's a blank or similar directly behind that wide
character (which shows up as a question mark inside a filled circle).

On which terminal did you happen to run into that? I have uxterm here.
I also checked if any of my .screenrc settings could interfere, but
nothing changed when commenting out any charset or terminal emulation
related settings.

So I checked also gnome-terminal, but no luck there either.
gnome-terminal showed me a banana btw., so this indeed seems to be
valid UTF-8.

Then again, I ran into the original issue (spam displayed in mutt
inside screen) at least with the screen version in Wheezy, so that one
is definitely affected. (Your issue might or might not be the same
issue. I'm not yet sure.) 

Next time I see such a case on Wheezy, I'll save a copy and check, if
it's still present on Unstable.

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

Bug#876780: libvorbis: CVE-2017-14160

[Petter Reinholdtsen]

[Salvatore Bonaccorso]
> the following vulnerability was published for libvorbis.

Thank you for following up on this.  I hope a fix show up from upstream
for this and other security issues. :)

I was just told on #xiph that this issue also might affect speex:

   rillian: speex may also be affected by that
bark_noise_hybridmp bug (CVE-2017-14160) since it includes that very
same function, via vorbis_psy.c.
   see:

https://git.xiph.org/?p=speex.git;a=blob;f=libspeex/vorbis_psy.c;h=cb385b7a349486a09a3db20adf225100993111c5;hb=HEAD#l189

I have not verified that this is the case, but thought it best to
mention it here until someone have time to check it out.

-- 
Happy hacking
Petter Reinholdtsen

Bug#870831: Broken symbols file creates broken dependencies

[Tomasz Buchert]

On 05/08/17 18:04, Stefan Fritsch wrote:
> Package: libbrotli0.6.0
> Version: 0.6.0-2~exp0
> Severity: serious
>
> I have tried to build apache2's mod_brotli with libbrotli0.6.0 /
> libbrotli-dev from experimental  But the resulting packages gets a
> dependency on the non-existing libbrotli0 (>= 0.6.0). I think the reason
> for this is that /var/lib/dpkg/info/libbrotli0.6.0:amd64.symbols
> contains
>
> libbrotlidec.so.0.6.0 libbrotli0 #MINVER#
>
> This should be libbrotli0.6.0 instead of libbrotli0.

Thank you, Stefan, I've upload a new experimental package at version
1.0.0, and with you fix. I think it is correct now, however I think
that the upstream SOVERSION is too granular and asked them to rethink
this. I'm relatively confident that polished brotli packages will
enter unstable in 2-3 weeks.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#858440: mongodb-server: mongodb users primary group is nogroup instead of mongodb, which is allso available

[Apollon Oikonomopoulos]

Package: mongodb-server
Version: 1:2.6.11-1

Hi,

On 12:46 Wed 22 Mar , Micha Krause wrote:
> Package: mongodb-server
> Version: 1:2.4.10-5
> Severity: minor
> 
> This Problem results in a restart loop in combination with this puppet module:
> 
> https://github.com/puppetlabs/puppetlabs-mongodb
> 
> The Puppet module checks, and fixes permissions in /var/lib/mongodb.
> Because the puppet module detects changes, the mongodb process is reloaded.
> This resoults in a journal-file to be recreated with mongodb:nogroup.
> At the next Puppet run the cycle starts again.
> 
> I realise that my problem is very Puppet specific, however I think mongodb 
> should
> realy use the mongodb group.

Thanks for the report. This has already been fixed in 2.6.11-1. However, 
due to lack of time, I will consider fixing this in Jessie only if there 
are other more important issues to fix as well.

Regards,
Apollon

Bug#876789: python-wxgtk-webview3.0: Depends on libwxgtk-webview3.0-0v5 which depends on webkit1

[Jeremy Bicha]

Package: python-wxgtk-webview3.0
Version: 3.0.2.0+dfsg-4
Severity: serious
Tags: sid buster
User: pkg-webkit-maintain...@lists.alioth.debian.org
Usertags: oldlibs libwebkitgtk-1.0-0 webkit1

python-wxgtk-webview3.0 depends on libwxgtk-webview3.0-0v5 which
depends on libwxgtk-webview3.0-0v5 which depends on
libwebkitgtk-1.0-0. libwebkitgtk-1.0-0 is the old webkitgtk library
that suffers from many reported CVEs that have been fixed in
libwebkit2gtk-4.0-37 (src: webkit2gtk ). We do not intend to release
Debian 10 "Buster" with libwebkitgtk-1.0-0.

python-wxgtk-webview3.0 has no reverse dependencies in Debian or
Ubuntu so it seems easy to just stop building this package for now.

See also https://bugs.debian.org/790222 for the RC bug for wxwidgets3.0.

On behalf of the Debian WebKit maintainers,
Jeremy Bicha

Bug#876687: htpdate: Off by one hour

[Eriberto]

2017-09-25 16:12 GMT-03:00 Eddy Vervest :
> So incorrect/out-dated TZDATA (Version: 2017b-1) causes htpdate to
> calculate gmtoffset incorrectly.
>
> Debian needs an update and I will patch htpdate in the near future.
>
> Thanks


Thanks a lot Eddy!

Bug#876788: postgresql-q3c FTBFS with PostgreSQL 10

[Adrian Bunk]

Source: postgresql-q3c
Version: 1.5.0-2
Severity: serious

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

...
 fakeroot debian/rules clean
pg_buildext checkcontrol
--- debian/control  2017-09-05 19:02:30.0 -1200
+++ debian/control.chBILN   2017-09-23 12:16:00.910794389 -1200
@@ -11,17 +11,17 @@
 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-postgresql/postgresql-q3c.git
 Vcs-Git: https://anonscm.debian.org/cgit/pkg-postgresql/postgresql-q3c.git
 
-Package: postgresql-9.6-q3c
+Package: postgresql-10-q3c
 Architecture: any
-Depends: postgresql-9.6,
+Depends: postgresql-10,
  ${misc:Depends},
  ${shlibs:Depends}
-Description: PostgreSQL 9.6 extension used for indexing the sky
+Description: PostgreSQL 10 extension used for indexing the sky
  Q3C, an extension for PostgreSQL, is designed for the work with large
  astronomical catalogues or any catalogs of objects on the sphere.
  .
  This extension allows a user to perform fast circular, elliptical or
  polygonal searches on the sky as well as fast cross-matches.
  .
- This package provides a module for PostgreSQL 9.6.
+ This package provides a module for PostgreSQL 10.
 
Error: debian/control needs updating from debian/control.in. Run 'pg_buildext 
updatecontrol'.
If you are seeing this message in a buildd log, a sourceful upload is required.
/usr/share/postgresql-common/pgxs_debian_control.mk:9: recipe for target 
'debian/control' failed
make: *** [debian/control] Error 1

Bug#876743: flatpak: FTBFS on hppa: Creating new namespace failed: Invalid argument

[John David Anglin]

On 2017-09-25 3:20 PM, Simon McVittie wrote:

Control: retitle 876743 flatpak: FTBFS on hppa: Creating new namespace failed: 
Invalid argument

On Mon, 25 Sep 2017 at 09:40:39 -0400, Aaron M. Ucko wrote:

Source: flatpak
Version: 0.9.12-2
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)

The flatpak build for hppa (admittedly not a release architecture) has
started failing:

   ERROR: tests/test-run.sh - too few tests run (expected 12, got 0)

Unfortunately this part of the log is relatively useless. As with all recent
Automake packages, please scroll down to just after the summary

# TOTAL: 57
# PASS:  35
# SKIP:  12
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 10

where you will see full logs quoted for the skipped and failing tests,
with underlined headers like

ERROR: tests/test-run.sh


followed by logged output. Unfortunately, because stdout and stderr have
different levels of buffering, the logged output is not particularly
easy to read in this case :-(

I think the real error might be this:


++ bwrap --ro-bind / / /bin/true
(no error here)

... but then later

Creating new namespace failed: Invalid argument

This indicates that, unlike most Debian buildds, your hppa buildd allows
enough namespace creation that bwrap (bubblewrap) can work at all; but
then it does not allow enough namespace creation that Flatpak's more
complicated uses of bwrap also work.

This probably means the upstream test suite should have a better check for
whether bwrap works, so that these tests can be skipped on your buildd's
kernel (they can't pass there, and Flatpak won't work on that kernel).

Flatpak build summary is here:
https://buildd.debian.org/status/logs.php?pkg=flatpak=hppa

In the recent successful builds on panama, it seems bwrap fails and the 
tests were skipped.

The bell and physik buildds have more memory (8 and 12 GB, respectively).


Do hppa machines have recent enough kernels available that Flatpak is
of any practical use, for example able to install and run GNOME Recipes
from https://flathub.org/apps.html on a test machine? The jessie kernel
should work. If a recent enough kernel is available, please run it on
hppa buildds. If not, then IMO it's a positive thing that Flatpak FTBFS
on hppa, and the old (non-functional) binaries should probably be removed.
I doubt the age of the kernels is the problem as current upstream 
kernels (e.g., v4.13.x)

run on hppa.

Dave

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

Bug#876743: flatpak: FTBFS on hppa: Creating new namespace failed: Invalid argument

[Simon McVittie]

On Mon, 25 Sep 2017 at 22:00:51 +0200, Helge Deller wrote:
> We have stability problems with latest debian kernels.
> That's why I've compiled a 4.9.50 (stable series) kernel and run it now
> on our buildds.
> Flatpack did built successfully in the past:
>  https://buildd.debian.org/status/logs.php?pkg=flatpak=hppa
> So, I think in general there are no problems with flatpak on hppa.

Either that, or the build-time tests that would have indicated a problem
were skipped because the buildd environment didn't allow them to run
(which in fact they seem to have been in for example
,
which is functionally the same code as the failing 0.9.12-2 - so we can't
actually know whether flatpak works on hppa or on the majority of Debian
architectures until someone tries it).

Unfortunately, we can't rely on either buildds or autopkgtest having
an environment where container technologies like bubblewrap can be
tested meaningfully, and autopkgtests are only run for a couple of
architectures (and certainly not non-release architectures like hppa).

> I plan to rebuild a new 4.9.50 kernel with all kernel namespace features
> enabled soon, and then I can give-back flatpak.
> Maybe it will succeed then?

Either enable all the namespace features that Debian does, or disable
enough namespaces that bwrap just can't run. Both extremes are fine,
it's the middle that has caused this FTFBS :-)

Regards,
smcv

Bug#871906: mongodb FTBFS on arm64: test failure

[Apollon Oikonomopoulos]

On 23:17 Sun 13 Aug , Apollon Oikonomopoulos wrote:
> On 15:01 Sat 12 Aug , Adrian Bunk wrote:
> > [executor:db_test] 2017-08-12T00:40:01.112+ Summary: 11 test(s) 
> > ran in 40.28 seconds (10 succeeded, 48 were skipped, 1 failed, 0 
> > errored)
> > The following tests failed (with exit code):
> > ExtensionsCallbackRealTest (-11)
> 
> Se, at least the ExtensionsCallbackRealTest and js suites are 
> segfaulting on arm64. The relevant backtrace is:
> 
> (gdb) bt
> #0  0xabf92ae0 in js::gc::Cell::storeBuffer (this=) at 
> src/third_party/mozjs-38/extract/js/src/gc/Heap.h:1237

Apparently this is due to mozjs-38 not playing nice with ARM64's 48-bit 
VA mode. Fixed in mozilla upstream with the following commit:

https://hg.mozilla.org/mozilla-central/rev/dfaafbaaa291

Regards,
Apollon

Bug#876787: afl: FTBFS /usr/bin/ld: unrecognized option '--no-keep-files-mapped'

[Daniel Stender]

Package: src:afl
Version: 2.50b-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Control: block 873404 by -1

AFL begun to FTBFS recently with a clang error:


[+] All set and ready to build.
clang-3.9  -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign 
-DAFL_PATH=\"/usr/lib/afl\" -DBIN_PATH=\"/usr/bin\" -DVERSION=\"2.50b\"  
afl-clang-fast.c -o ../afl-clang-fast -Wl,-z,relro -Wl,-z,now
ln -sf afl-clang-fast ../afl-clang-fast++
clang++-3.9 `llvm-config-3.9 --cxxflags` -fno-rtti -fpic  -Wall 
-D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DVERSION=\"2.50b\" 
-Wno-variadic-macros -shared afl-llvm-pass.so.cc -o ../afl-llvm-pass.so 
`llvm-config-3.9 --ldflags` -Wl,-z,relro -Wl,-z,now
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean 
'-Wno-uninitialized'? [-Wunknown-warning-option]
1 warning generated.
/usr/bin/ld: unrecognized option '--no-keep-files-mapped'
/usr/bin/ld: use the --help option for usage information
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:83: recipe for target '../afl-llvm-pass.so' failed


This seems to be a problem in the build toolchain (this is going to be
reassigned). The same error appears also with clang-4.0 and clang-5.0, thus
blocking the llvm-toolchain update of AFL.

DS

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

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

Versions of packages afl depends on:
ii  build-essential  12.4
ii  libc62.24-17

Versions of packages afl recommends:
ii  afl-clang  2.50b-1
ii  afl-doc2.50b-1

Versions of packages afl suggests:
ii  gnuplot   5.0.7+dfsg1-1
ii  gnuplot-qt [gnuplot]  5.0.7+dfsg1-1

-- no debconf information

Bug#354709: screen corrupts my display when viewing certain spam mails (via mutt)

[Thadeu Lima de Souza Cascardo]

Package: screen
Version: 4.6.1-1
Followup-For: Bug #354709

Hi, Axel.

Thank you very much for your work maintaining screen.

I have this same problem with what seems to be valid UTF-8. One possible
reproduction test is running this on bash under screen.

echo -e '\xf0\x9f\x8d\x8c'

You will notice the extra space after that, which does not happen when
not under screen.

Thank you very much.
Cascardo.


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

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

Versions of packages screen depends on:
ii  libc6 2.24-17
ii  libpam0g  1.1.8-3.6
ii  libtinfo5 6.0+20170902-1
ii  libutempter0  1.1.6-3

screen recommends no packages.

Versions of packages screen suggests:
pn  byobu | screenie | iselect  
ii  ncurses-term6.0+20170902-1

-- no debconf information

Bug#876785: librarian-puppet is incompatible with git 2.14.0

[Russell Howe]

Package: librarian-puppet
Version: 2.2.3-2
Severity: normal

Dear Maintainer,

librarian-puppet throws an error with the version of git present in
unstable:

$ librarian-puppet install --verbose
[Librarian] Ruby Version: 2.3.3
[Librarian] Ruby Platform: x86_64-linux-gnu
[Librarian] Rubygems Version: 2.5.2
[Librarian] Librarian Version: 0.6.3
[Librarian] Librarian Adapter: puppet
[Librarian] Librarian Adapter Version: 2.2.3
[Librarian] Project: /home/rhowe/projects/siksai-puppet
[Librarian] Specfile: Puppetfile
[Librarian] Lockfile: Puppetfile.lock
[Librarian] Git: /usr/bin/git
error: unknown option `silent'
usage: git version []

--build-options   also print build options

/usr/lib/ruby/vendor_ruby/librarian/posix.rb:116:in `run!'
/usr/lib/ruby/vendor_ruby/librarian/source/git/repository.rb:25:in `git_version'
/usr/lib/ruby/vendor_ruby/librarian/cli.rb:193:in `block in write_debug_header'
/usr/lib/ruby/vendor_ruby/librarian/logger.rb:37:in `block in debug'
/usr/lib/ruby/vendor_ruby/librarian/ui.rb:32:in `debug'
/usr/lib/ruby/vendor_ruby/librarian/logger.rb:37:in `debug'
/usr/lib/ruby/vendor_ruby/librarian/puppet/util.rb:9:in `debug'
/usr/lib/ruby/vendor_ruby/librarian/cli.rb:193:in `write_debug_header'
/usr/lib/ruby/vendor_ruby/librarian/cli.rb:61:in `initialize'
/usr/lib/ruby/vendor_ruby/thor.rb:365:in `new'
/usr/lib/ruby/vendor_ruby/thor.rb:365:in `dispatch'
/usr/lib/ruby/vendor_ruby/thor/base.rb:444:in `start'
/usr/lib/ruby/vendor_ruby/librarian/cli.rb:26:in `block (2 levels) in bin!'
/usr/lib/ruby/vendor_ruby/librarian/cli.rb:31:in `returning_status'
/usr/lib/ruby/vendor_ruby/librarian/cli.rb:26:in `block in bin!'
/usr/lib/ruby/vendor_ruby/librarian/cli.rb:47:in `with_environment'
/usr/lib/ruby/vendor_ruby/librarian/cli.rb:26:in `bin!'
/usr/bin/librarian-puppet:7:in `'


Seems like git has dropped the --silent option

Looks like upstream has applied a fix which is not yet released:

https://github.com/voxpupuli/librarian/commit/08f97d21449a33de903902b3216143faf0a520ef

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

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

Versions of packages librarian-puppet depends on:
ii  puppet 4.10.4-2
ii  ruby   1:2.3.3
ii  ruby-json  2.1.0+dfsg-1
ii  ruby-librarian 0.6.3-1
ii  ruby-puppet-forge  2.2.7-2
ii  ruby-rsync 1.0.9-1

librarian-puppet recommends no packages.

librarian-puppet suggests no packages.

-- no debconf information

Bug#867263: dbus: /var/log/reboot-required.pgks not updated when /var/log/reboot-required is touched

[Simon McVittie]

On Wed, 05 Jul 2017 at 09:24:51 +, sam penny wrote:
> A message "A reboot is required to replace the running dbus-daemon." was shown
> and /var/run/reboot-required was touched, but /var/run/reboot-required.pgks
> remained unchanged (absent in this case)

Which package reads that file? Is its desired content documented
anywhere? I'm happy to change the postinst to append to it, but I need
to know what the "API" is.

I'm considering #867263 to refer to the feature request "please append
 to /var/run/reboot-required.pkgs".

> As a secondary issue, I would vote for a fix for 
> https://bugs.debian.org/805449
> but if we do need a reboot, it should be clear why to facilitate an informed
> decision about when the reboot should be scheduled

Sorry, you do not get a vote on this: everyone involved agrees that
#805449 is a bug, but there is no shortage of bug-fixing and other work
that people can spend their time on. The people who know the code well
enough that they could solve #805449 have assessed the cost/benefit
and decided to work on something else instead (you can tell this has
happened because otherwise, there would be a proposed change to fix it).

The only form of "vote" that is useful here would be to propose a tested
solution, or hire a consultant to do so. However, the upstream maintainers
of dbus would still need to review it and be confident that it was not a
net backward step, which is itself a significant investment of time.

Consensus among the upstream maintainers of dbus is that fixing
#805449 is too difficult to be feasible. It would be a large amount of
rarely-tested, error-prone code, and bugs in that code (which are more
or less inevitable) could easily result in the dbus-daemon crashing or
becoming non-functional, most likely requiring an immediate (unscheduled)
boot to recover. Requiring an immediate reboot because a bug brings down
the dbus-daemon seems considerably worse than requiring a reboot at a
time convenient to you, so #805449 is the lesser evil.

Of course, in an ideal world, there would be a bug-free solution to
#805449, but we are very far from that ideal world.

> As a tertiary issue, but I can't work out where to report it (pointers
> welcome!) the contents of the reboot-required.pkgs file in general could 
> really
> do with some more information about the package versions and the timing of the
> request

dbus cannot solve this. Please identify which package defines the
contents of this file and send any feature requests there, as a
separate report.

> (eg. if if the update fixes a typo in a rare error
> message but dbus can't be replaced without a reboot, that reboot is going to
> wait until I have a better reason to reboot - if it fixes a major security
> issue, that reboot will happen as soon as reasonably possible)

dbus provides approximately this information in
/usr/share/doc/dbus/changelog.Debian.gz, including the urgency field
(normally medium, sometimes low or high). The same is true for every
other Debian package. Doing something with that information is a feature
request for something involved in the package update process, rather
than for the package being updated.

If you are running testing/unstable, try apt-listchanges - perhaps it
already does what you need.

If you are running stable/oldstable, in addition to the availability of
apt-listchanges, updates are announced on the debian-security-announce
and debian-announce mailing lists, and every update is likely to be
important (because we wouldn't spend the time and take the regression
risk of doing a stable update if it wasn't important). If in doubt,
reboot as soon as is convenient anyway, whether dbus tells you to or not.

Regards,
smcv

Bug#842631: mark valac-0.34-vapi Multi-Arch: foreign

[Manuel A. Fernandez Montecelo]

Hello maintainers,

2016-10-30 22:56 Helmut Grohne:

Package: valac-0.34-vapi
Version: 0.34.2-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:birdfont src:colord src:colord-gtk src:corebird 
src:d-conf src:dconf-editor src:deja-dup src:folks src:four-in-a-row 
src:fso-audiod src:fso-datad src:fso-deviced src:fso-usaged src:gegl 
src:gmpc-plugins src:gnome-2048 src:gnome-chess src:gnome-clocks 
src:gnome-klotski src:gnome-mahjongg src:gnome-mines src:gnome-nibbles 
src:gnome-pie src:gnome-shell-mailnag src:gnome-sudoku src:gnome-taquin 
src:gnome-terminal src:gnome-tetravex src:gtk-theme-config src:gupnp 
src:gupnp-av src:gupnp-dlna src:iagno src:ibus-skk src:libdmapsharing src:libfm 
src:libfso-glib src:libfsoframework src:libgee-0.8 src:libgisi 
src:libgnome-games-support src:libisocodes src:libxmlbird src:lightsoff 
src:lxsession src:mdbus src:midori src:moonshot-ui src:obsession 
src:pdf-presenter-console src:plank src:quadrapassel src:seahorse src:spice-gtk 
src:swell-foop src:synapse src:systemd-ui src:telegnome src:tracker 
src:umockdev src:vala-dbus-binding-tool src:vala-terminal src:valabind 
src:valadoc src:vinagre

The affected packages cannot satisfy their cross Build-Depends, because
their (transitive) dependency on valac-0.34-vapi is not satisfiable. In
general, Architecture: all packages can never satisfy cross
Build-Depends unless marked Multi-Arch: foreign. In this case, such a
marking is correct as valac-0.34-vapi does not have any dependencies nor
maintainer scripts.

It is not clear whether fixing this bug actually makes any of those
packages cross buildable. Still we'll only see that after trying and
that necessitates having satisfiable cross Build-Depends. I guess that
for most of them valac is currently requested for the host architecture,
but will practically be needed for the build architecture.

Despite the apparent need for more work, please consider applying the
attached patch to make diagnosing the next issues easier.


How do you feel about applying the patch included along this bug report?

It affects packages needed when bootstrapping new architectures, and the
patch is quite straightforward and unlikely to cause harm.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#873211: lintian: does not warn about .class binaries

[Chris Lamb]

Hi Emmanuel!

> Thanks for improving the Java support in Lintian, I'd suggest CCing
> these topics to debian-j...@lists.debian.org to gather more feedback on
> the proposed changes.

Sure!

Indeed, once you think you have reached a consensus could you file new and
separte, wishlist bugs against Lintian? I ask because this bug (#873211) is
already closed and adding a laundry list of changes here is likely to some of
them being lost, etc. etc.

Besides, many of them can be worked on completely independent of each
other :)


Regards,

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

Bug#873211: lintian: does not warn about .class binaries

[Markus Koschany]

Hi,

A big +1 for everything what Emmanuel stated above with a special
emphasis on the following points:

* Thanks for improving Lintian!

* Please keep us in the loop about Java related Lintian changes. Perhaps
   we are not always able to provide code in a timely manner but we are
willing to provide feedback and assistance whenever possible.

* "modify source-contains-prebuilt-java-object to also detect .class
files": I believe this would be the appropriate Lintian tag for this
issue and severity info would be in order.

I stumbled about the this new Lintian tag a few days ago when I saw that
robocode emits 34 Lintian errors now. The class files are compiled from
source and just installed into a sample directory together with the
source files. Robocode is a Java programming game and working with
*.java and *.class files to understand the language makes sense.

In short there are too many false positives at the moment hence I would
like to suggest to lower the severity.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#876782: A diagnosis

[Peter Eckersley]

Looks like the issue is that installing this package didn't trigger a re-run
of texhash.  "sudo texhash" fixed the problem.

-- 
Peter Eckersleyp...@eff.org
Chief Computer Scientist  Tel  +1 415 436 9333 x131
Electronic Frontier FoundationFax  +1 415 436 9993

Bug#868086: RFS: beautify-bash/1.1-1 [ITP]

[Herbert Fortes]

Em 25-09-2017 17:16, Andrey Rahmatullin escreveu:
> On Mon, Sep 25, 2017 at 05:07:29PM -0300, Herbert Fortes wrote:
>> The debian/watch file is not working.
> It is working here.
> 

Ok. It is working on Sid.

I am sorry.



Regards,
Herbert

Bug#874580: stretch-pu: package waagent/2.2.14-1~deb9u1

[Adam D. Barratt]

On Wed, 2017-09-20 at 13:27 +0200, Martin Zobel-Helas wrote:
> On Wed, Sep 20, 2017 at 11:43:56AM +0200, Bastian Blank wrote:
> > > (Also, we prefer if the full diff is included in pu bugs
> > > directly.)
> > 
> >  README.md  |  39 ++-
> >  azurelinuxagent/agent.py   |  52 ++-
> > 
...
> >  119 files changed, 5634 insertions(+), 1288 deletions(-)
> 
> 
> Find attached the full diff gzip'd.

Thanks.

That appears to be missing a changelog stanza for the stable upload. Is
that the only proposed difference from the 2.2.14-1 unstable upload?

Regards,

Adam

Bug#876784: ITP: django-background-tasks -- databased-backed work queue for Django

[Hans-Christoph Steiner]

Package: wnpp
Severity: wishlist
Owner: "Hans-Christoph Steiner" 

* Package name: django-background-tasks
  Version : 1.1.11
  Upstream Author : John Montgomery and contributors
* URL : https://github.com/arteria/django-background-tasks
* License : BSD-3-clause
  Programming Lang: Python
  Package source  :
https://anonscm.debian.org/git/python-modules/packages/django-background-tasks.git
  Description: databased-backed work queue for Django

Django Background Task is a databased-backed work queue for Django,
loosely based around Ruby's DelayedJob library. This project was adopted
and adapted from lilspikey django-background-task.

To avoid conflicts on PyPI we renamed it to django-background-tasks
(plural). For an easy upgrade from django-background-task to
django-background-tasks, the internal module structure were left untouched.

In Django Background Task, all tasks are implemented as functions (or
any other callable).

There are two parts to using background tasks:

creating the task functions and registering them with the scheduler
setup a cron task (or long running process) to execute the tasks

Bug#831362: Bug#840848: libcap-ng FTCBFS: wrong python dependencies

[Manuel A. Fernandez Montecelo]

Hi Pierre,

2017-09-25 9:20 GMT+02:00 Pierre Chifflier :
> On 09/25/2017 01:00 AM, Manuel A. Fernandez Montecelo wrote:
>>
>> I am submitting an NMU to delayed/15, debdiff attached, with the
>> combined patches (please Helmut double-check if this is the final form
>> that it was intended).
>>
>> If you want me to cancel the NMU just ask.
>>
>> (BTW, I checked that there are no related lintian warnings that were
>> mentioned in #831362).
>>
>
>
> Hi Manuel,
>
> Thanks for the patch.
> I'm fine with the NMU, just tell me if you prefer me to upload it
> directly (so we do not wait the 15 days).

I could reschedule it to a shorter time, but sure, it's always better
if maintainers ack the change themselves, so please go ahead :)

Thanks and cheers.

-- 
Manuel A. Fernandez Montecelo 

Bug#876783: libsndfile: CVE-2017-14634

[Salvatore Bonaccorso]

Source: libsndfile
Version: 1.0.28-4
Severity: normal
Tags: upstream security
Forwarded: https://github.com/erikd/libsndfile/issues/318
Control: found -1 1.0.25-9.1

Hi,

the following vulnerability was published for libsndfile.

CVE-2017-14634[0]:
| In libsndfile 1.0.28, a divide-by-zero error exists in the function
| double64_init() in double64.c, which may lead to DoS when playing a
| crafted audio file.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-14634
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14634
[1] https://github.com/erikd/libsndfile/issues/318

Regards,
Salvatore

Bug#873592: Re: [DAViCal-devel] Bug#873592: libawl-php: PHP 7 deprecated constructor syntax

[Kim Brodowski]

Good afternoon,

sure. Thank you for your support.

Kim

Florian Schlichting  schrieb am Fr, 22.09.2017 11:45:
> Hi,
> 
> the Davical project is going to release a fixed version of AWL in the
> coming weeks, which I can make available in stretch-backports. Would
> that be sufficient for you?
> 
> Florian

Bug#868086: RFS: beautify-bash/1.1-1 [ITP]

[Andrey Rahmatullin]

On Mon, Sep 25, 2017 at 05:07:29PM -0300, Herbert Fortes wrote:
> The debian/watch file is not working.
It is working here.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#876782: texlive-plain-generic: ulem.sty not found

[Peter Eckersley]

Package: texlive-plain-generic
Version: 2017.20170818-1
Severity: normal

Dear Maintainer,

I'm getting errors where ulem.sty is not found (while running ipython
nbconvert --to pdf), despite texlive-plain-generic packaging it and being
installed.

https://paste.debian.net/987729/

"kpsewhich ulem.sty" also gives no output.

##
 List of ls-R files

-rw-r--r-- 1 root root 1225 Sep 25 12:40 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Feb 22  2016 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Aug 17 19:46 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Aug 17 19:46 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 May 11  2016 /etc/texmf/web2c/texmf.cnf
-rw-r--r-- 1 root root 3433 May 11  2016 /var/lib/texmf/web2c/fmtutil.cnf
lrwxrwxrwx 1 root root 32 Aug 17 19:46 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 2763 Sep 25 12:40 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jun 15  2013 mktex.cnf
-rw-r--r-- 1 root root 475 May 11  2016 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages texlive-plain-generic depends on:
ii  tex-common6.05
ii  texlive-base  2017.20170818-1
ii  texlive-binaries  2017.20170613.44572-6

texlive-plain-generic recommends no packages.

texlive-plain-generic suggests no packages.

Versions of packages tex-common depends on:
ii  dpkg  1.18.4
ii  ucf   3.0030

Versions of packages tex-common suggests:
ii  debhelper  10.2.2

Versions of packages texlive-plain-generic is related to:
ii  tex-common6.05
ii  texlive-binaries  2017.20170613.44572-6

-- debconf information:
  tex-common/check_texmf_wrong:
  tex-common/check_texmf_missing:

Bug#873211: lintian: does not warn about .class binaries

[Emmanuel Bourg]

On Wed, 20 Sep 2017 17:34:47 + Chris Lamb  wrote:
>  lintian (2.5.53) unstable; urgency=medium
>  .
>* Summary of tag changes:
>  + Added:
>- package-installs-java-bytecode

Hi,

Thanks for improving the Java support in Lintian, I'd suggest CCing
these topics to debian-j...@lists.debian.org to gather more feedback on
the proposed changes.

I got a look at the packages affected by the new
package-installs-java-bytecode tag [1], they mostly consist in
demos/examples, webapp classes or one-class programs not meant to be
re-used as libraries. For these cases installing .class files directly
in the binary package is legitimate I think. jar files are really
important for reusable libraries and large applications (since jar files
are more space efficient), but there is no harm shipping a few isolated
.class files. The Java Policy probably needs a clarification on this point.

As I understand Carnë was concerned about .class files in the upstream
tarballs not recompiled from source and installed as-is in the binary
packages. I was under the impression this case was already covered by
source-contains-prebuilt-java-object but it isn't. I agree it would be
nice to handle this.

So I suggest the following:
- modify source-contains-prebuilt-java-object to also detect .class files
- lower the severity of package-installs-java-bytecode to pendatic or info
- trigger package-installs-java-bytecode in non-library packages only
when the number of classes detected in the package exceeds 20.
- do not trigger package-installs-java-bytecode if the path contains
"WEB-INF", "demo", "doc", "example", "sample" or "test".
- strictly speaking a class file isn't raw bytecode instructions, so
maybe rename the tag to "package-installs-java-class-files".
- verify if the .class files are really Java class files (by checking
the 0xCAFEBABE header, this will avoid false positives like
apertium-eo-fr and grass-core).

Emmanuel Bourg

[1] https://lintian.debian.org/tags/package-installs-java-bytecode.html

Bug#876781: Since upgrade to Evolution 3.6.0-1 in Debian Buster caldav-events cannot been creted/edited/deleted

[Bernhard Hohensinn]

Package: evolution-data-server
Version: 3.26.0-1


Hello,

I am using Debian Buster and my calendars are on a Nextcloud-Server,
Version 12.0.3 on a Raspi. The calendars fo the Nextcloud are connected
to Evolution via Caldav. In Evolution 3.26.0-1 all events are shown
correctly, but when I want to create/edit/delete an event of one of
these calendars, I get the following message:

'Kalenderobjekt kann nicht verändert werden: Daten konnten nicht
gesendet werden: HTTP-Fehlercode 415 (Unsupported Media Type):
Sabre\DAV\Exception\UnsupportedMediaType
  This resource only supports valid iCalendar 2.0 data. Parse error:
End of document reached prematurely[exception][message]'

I can create/edit/delete events on these calendars on my Android
smartphone as well as when I use Thunderbird on Debian Buster.

regards,

Bernhard

Bug#876780: libvorbis: CVE-2017-14160

[Salvatore Bonaccorso]

Source: libvorbis
Version: 1.3.5-4
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for libvorbis.

CVE-2017-14160[0]:
| The bark_noise_hybridmp function in psy.c in Xiph.Org libvorbis 1.3.5
| allows remote attackers to cause a denial of service (out-of-bounds
| access and application crash) or possibly have unspecified other impact
| via a crafted mp4 file.

See [1].

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-14160
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14160
[1] http://www.openwall.com/lists/oss-security/2017/09/21/3

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#876760: unattended-upgrades.postinst script calls dpkg-vendor

[Alexandre Detiste]

Hi,

Maybe these call to dpkg-vendor could simply be replaced by

 test -f  /etc/dpkg/origins/ubuntu

?

An other way is to replace all the invocation of dpkg-vendor by a
single shell variable
which will be filled in the .postinst template at build time (dpkg-dev
is in build-essential).

Greets,

Alexandre

2017-09-25 17:42 GMT+02:00 Jean-Marc :
> Today's upgrade installed v 0.97.
> And post installation script called dpkg-vendor (see [1]).
> But dpkg-vendor is in dpkg-dev package.
> Which is not installed on my system.

Bug#852564: fix for this issue is now upstream.

[Scott Moser]

Hi,

This issue is fixed upstream now.  See attached.
The fix can be seen in upstream git commit ad099a53d120 [1]

As suggested in the Debian bug, the change was just to drop the hard
coded path.

Thanks

--
[1] 
https://git.launchpad.net/cloud-init/commit/?id=ad099a53d120e88719a5ad50f29d22e9f7a52bc7
From ad099a53d120e88719a5ad50f29d22e9f7a52bc7 Mon Sep 17 00:00:00 2001
From: Scott Moser 
Date: Mon, 25 Sep 2017 14:29:13 -0400
Subject: [PATCH] AltCloud: Trust PATH for udevadm and modprobe.

Previously we had hard coded paths in /sbin for the udevadm and modprobe
programs invoked by AltCloud.  Its more flexible to expect the PATH to
be set correctly.

Debian: #852564
---
 cloudinit/sources/DataSourceAltCloud.py  | 4 ++--
 tests/unittests/test_datasource/test_altcloud.py | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/cloudinit/sources/DataSourceAltCloud.py b/cloudinit/sources/DataSourceAltCloud.py
index ed1d691a..c78ad9eb 100644
--- a/cloudinit/sources/DataSourceAltCloud.py
+++ b/cloudinit/sources/DataSourceAltCloud.py
@@ -28,8 +28,8 @@ LOG = logging.getLogger(__name__)
 CLOUD_INFO_FILE = '/etc/sysconfig/cloud-info'
 
 # Shell command lists
-CMD_PROBE_FLOPPY = ['/sbin/modprobe', 'floppy']
-CMD_UDEVADM_SETTLE = ['/sbin/udevadm', 'settle', '--timeout=5']
+CMD_PROBE_FLOPPY = ['modprobe', 'floppy']
+CMD_UDEVADM_SETTLE = ['udevadm', 'settle', '--timeout=5']
 
 META_DATA_NOT_SUPPORTED = {
 'block-device-mapping': {},
diff --git a/tests/unittests/test_datasource/test_altcloud.py b/tests/unittests/test_datasource/test_altcloud.py
index 3b274d90..a4dfb540 100644
--- a/tests/unittests/test_datasource/test_altcloud.py
+++ b/tests/unittests/test_datasource/test_altcloud.py
@@ -280,8 +280,8 @@ class TestUserDataRhevm(TestCase):
 pass
 
 dsac.CLOUD_INFO_FILE = '/etc/sysconfig/cloud-info'
-dsac.CMD_PROBE_FLOPPY = ['/sbin/modprobe', 'floppy']
-dsac.CMD_UDEVADM_SETTLE = ['/sbin/udevadm', 'settle',
+dsac.CMD_PROBE_FLOPPY = ['modprobe', 'floppy']
+dsac.CMD_UDEVADM_SETTLE = ['udevadm', 'settle',
'--quiet', '--timeout=5']
 
 def test_mount_cb_fails(self):
-- 
2.14.1

Bug#864798: btrfs-convert: crashes when converting ext4 drive

[Nicholas D Steeves]

Dear Michael,

On Thu, Jun 15, 2017 at 09:12:28AM +0800, Michael Tsang wrote:
> Package: btrfs-progs
> Version: 4.7.3-1
> Severity: important
[...]
> -- System Information:
> Debian Release: 9.0
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores)
> Locale: LANG=en_HK.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_HK:en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

I'm not the maintainer of Debian's btrfs-progs, but I couldn't help
noticing that you were running linux-3.16.x (from Debian 8/jessie) at
the time of the attempted btrfs-convert operation.  It was only after
linux-4.4 that I found that anything btrfs-related became more likely
to succeed than to fail.

What happens if you try this after booting to Debian 9/stretch's 4.9.x
kernel?  Personally I wouldn't attempt to use btrfs-convert until late
2018, and only after upstream begins to recommended it as a viable
alternative to mkfs.btrfs.

That said, I'd love to be wrong, and to discover that stretch's
btrfs-progs and kernel will convert ext successfully--and more
importantly, will convert to a volume that won't self-destruct. :-)

Looking forward to hearing of your success,
Nicholas


signature.asc
Description: PGP signature

Bug#876776: fityk FTBFS: FAIL: tests/psvoigt

[Marcin Wojdyr]

FWIW I applied a blind fix upstream:
https://github.com/wojdyr/fityk/commit/9684b96e336ae7c926d70dbccf03f1618eee7433

Bug#868086: RFS: beautify-bash/1.1-1 [ITP]

[Herbert Fortes]

Hi Mike Mestnik,

> Package: sponsorship-requests
> Severity: wishlist
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Dear mentors,
>
> I am looking for a sponsor for my package "beautify-bash"

The debian/watch file is not working. And I assume that
you know where to look for information because the file
has an 'opts' line.

Can you please fix it ?



Regards,
Herbert


>
> * Package name : beautify-bash
> Version : 1.1-1
> Upstream Author : Paul Lutus, Shriram V 
> * URL : https://arachnoid.com/python/beautify_bash_program.html
> * License : GPL+
> Section : utils
>
> It builds those binary packages:
>
> beautify-bash - Beautifier for Bash shell scripts written in Python
>
> To access further information about this package, please visit the following 
> URL:
>
> https://mentors.debian.net/package/beautify-bash
>
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x 
> https://mentors.debian.net/debian/pool/main/b/beautify-bash/beautify-bash_1.1-1.dsc
>
> Changes since the last upload:
>
> beautify-bash (1.1-1) unstable; urgency=medium
>
> * Initial release (Closes: #867869)
>
> -- Mike Mestnik  Tue, 11 Jul 2017 13:21:00 
> -0500
>
> Regards,
> Mike Mestnik
>
> - --
> Debian Release: 9.0
> APT prefers stable
> APT policy: (500, 'stable'), (480, 'unstable'), (470, 'experimental')
> Architecture: i386 (x86_64)
>
> Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> -BEGIN PGP SIGNATURE-
>
> iQJLBAEBCAA1FiEE50YYYn+e/FujuFBs49GprY7cq4oFAlllSBIXHGNoZWFrb0Bt
> aWtlbWVzdG5pay5uZXQACgkQ49GprY7cq4qpnBAAgGmQqwcmjqfCsm65YXvKGexO
> O/3AntGsC68Mi1NMBxYWZVkTIdkGFgNkq+VnoXqXxepGrdoAi9HZtBjhcxHZ+KN9
> bOGCOjhZj+coOSOiJXkCvVqMfGdUBn9Qfw2EyaXQcq/o/Dym64u+Vihq4ElvwdJq
> LpzdPZp8nEPpayAX+n7U5BvKnr0B4rUwdMtOfDTeDtCA6+86bzNKJO0eUnAOKKP6
> c4fCVODHc58WwF8NcW7GPywznvU4WoR5QJ8repLSYfXrLBeFGcv1sWugbbo2+hhe

Bug#751465: Pending fixes for bugs in the libwww-mechanize-perl package

[pkg-perl-maintainers]

tag 751465 + pending
thanks

Some bugs in the libwww-mechanize-perl package are closed in revision
87315bd0e379b2ebef846a9aee47603670e6ca0f in branch 'master' by
Florian Schlichting

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libwww-mechanize-perl.git/commit/?id=87315bd

Commit message:

Explain where to find POD on HTML::Form::Input (closes: #751465)

Bug#876743: flatpak: FTBFS on hppa: Creating new namespace failed: Invalid argument

[Helge Deller]

On 25.09.2017 21:20, Simon McVittie wrote:

On Mon, 25 Sep 2017 at 09:40:39 -0400, Aaron M. Ucko wrote:

Source: flatpak
Version: 0.9.12-2
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)

The flatpak build for hppa (admittedly not a release architecture) has
started failing:

   ERROR: tests/test-run.sh - too few tests run (expected 12, got 0)



...


This indicates that, unlike most Debian buildds, your hppa buildd allows
enough namespace creation that bwrap (bubblewrap) can work at all; but
then it does not allow enough namespace creation that Flatpak's more
complicated uses of bwrap also work.

This probably means the upstream test suite should have a better check for
whether bwrap works, so that these tests can be skipped on your buildd's
kernel (they can't pass there, and Flatpak won't work on that kernel).

Do hppa machines have recent enough kernels available that Flatpak is
of any practical use, for example able to install and run GNOME Recipes
from https://flathub.org/apps.html on a test machine? The jessie kernel
should work. If a recent enough kernel is available, please run it on
hppa buildds. If not, then IMO it's a positive thing that Flatpak FTBFS
on hppa, and the old (non-functional) binaries should probably be removed.


We have stability problems with latest debian kernels.
That's why I've compiled a 4.9.50 (stable series) kernel and run it now
on our buildds.
Flatpack did built successfully in the past:
 https://buildd.debian.org/status/logs.php?pkg=flatpak=hppa
So, I think in general there are no problems with flatpak on hppa.

I plan to rebuild a new 4.9.50 kernel with all kernel namespace features
enabled soon, and then I can give-back flatpak.
Maybe it will succeed then?

Helge

Bug#870286: btrfs-progs: btrfs-convert is missing

[Nicholas D Steeves]

On Mon, Jul 31, 2017 at 05:50:44PM +0200, Adam Borowski wrote:
> > btrfs-progs (4.12-1) unstable; urgency=medium
> >   [ Nicholas D Steeves ]
> >   * Drop btrfs-convert (Closes: #824895, #854489)
> 
> Except that btrfs-convert has been rewritten from scratch recentlish, and
> bugs in the rewrite have been since ironed out.

I applaud your optimism ;-)  

> Yes, there are some caveats, but the man page discusses them at length.
> 
> I see no point in shipping an incomplete package.

Bugs like #864798 should never occur.  While Debian stable/stale is
filled with known bugs, crashes or potential data loss bugs should not
exist.  Given that btrfs-convert support was dropped for sid, and that
this propagated to testing it is now possible to advocate to
ftp-masters for dropping it from 4.7.3-1 in stable--which doesn't have
the latest rewrite.  Crashes and potential data loss bugs are a
greater deficiency than missing functionality.  Unless one of these
bugs exists during freeze, the deficient package propagates to
stable...not to mention that all of our downstreams can up end up
getting stuck with buggy software.

If by fall 2018 no rewrites of btrfs-convert have occurred, and if
upstream is willing to support it, then I will fully support reverting
my commit.  That much I'm sure of, but May 2018 might be reasonable :-)
Of course, it's ultimately up to Dmitri!

What do you think about the idea of having a variant of btrfs-progs in
experimental with any/all experimental functionality enabled?

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#876778: libvorbis: CVE-2017-14633

[Salvatore Bonaccorso]

Source: libvorbis
Version: 1.3.5-4
Severity: important
Tags: security upstream
Forwarded: https://gitlab.xiph.org/xiph/vorbis/issues/2329

Hi,

the following vulnerability was published for libvorbis.

CVE-2017-14633[0]:
| In Xiph.Org libvorbis 1.3.5, an out-of-bounds array read vulnerability
| exists in the function mapping0_forward() in mapping0.c, which may lead
| to DoS when operating on a crafted audio file with vorbis_analysis().

On upstream issue there is no reproducer attached, and no patch
available as per 2017-09-25 yet.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-14633
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14633
[1] https://gitlab.xiph.org/xiph/vorbis/issues/2329

Please adjust the affected versions in the BTS as needed, when known
more.

Regards,
Salvatore

Bug#495005: libdbus complaining unconditionally on stderr

[Simon McVittie]

Control: tags 495005 + wontfix

Sorry to resurrect an ancient bug report, but I'm trying to do some
triaging on src:dbus bugs.

On Sun, 29 Nov 2009 at 10:14:41 +0100, Julien BLACHE wrote:
> Michael Biebl  wrote:
> > Could you actually show me, where (lib)dbus is at fault here?
> 
> #516982 msg#35

which quotes a message from #20, further up the bug:

process 20186: arguments to dbus_connection_send() were incorrect,
assertion "connection != NULL" failed in file dbus-connection.c line 3099.
This is normally a bug in some application using the D-Bus library.

> Debug messages shouldn't be printed by the library unless it's a debug
> build or the application asked for (allowed) them.

This is not a debug message, it's a warning of undefined behaviour having
been reached. In the default upstream configuration of libdbus it would
immediately have been followed by abort() (although Debian's libdbus is
patched to make these "checks" non-fatal by default; it isn't entirely
clear to me why this was done, and one day I might take that patch out).
Think of it as analogous to how glibc writes to stderr when it detects
memory corruption.

Something in the process in question is calling
dbus_connection_send(NULL, ?, ?), which is considered to be invalid in
the same way as (for example) fprintf(NULL, "hello") (which segfaults,
at least on my system).

If users of libdbus don't want undefined behaviour (which could include
messages on stderr, abort(), NULL pointer dereferences or whatever) then
they should not pass NULL to a function that is conceptually a method on
a (non-NULL) connection.

>From comments on #516982 it seems that the cause is failure to connect to
the dbus-daemon, so dbus_bus_get() or dbus_bus_get_private() returned
NULL. The correct response to that happening is to stop trying to
interact with D-Bus, and either exit unsuccessfully (if interacting with
D-Bus is a required part of this program's functionality) or skip the
D-Bus bits (if interacting with D-Bus is not critical for this program).

Regards,
smcv

Bug#876779: libvorbis: CVE-2017-14632

[Salvatore Bonaccorso]

Source: libvorbis
Version: 1.3.5-4
Severity: important
Tags: security upstream
Forwarded: https://gitlab.xiph.org/xiph/vorbis/issues/2328

Hi,

the following vulnerability was published for libvorbis.

CVE-2017-14633[0]:
| In Xiph.Org libvorbis 1.3.5, an out-of-bounds array read vulnerability
| exists in the function mapping0_forward() in mapping0.c, which may lead
| to DoS when operating on a crafted audio file with vorbis_analysis().

The reproducer was not attached to the upstream issue, since looks was
not possible for the reporter to include it in the report.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-14633
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14633
[1] https://gitlab.xiph.org/xiph/vorbis/issues/2328

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#857770: [Pkg-postgresql-public] Bug#857770: src:postgresql-debversion: please provide a unversioned binary package

[Ole Streicher]

Hi Christoph,

On 23.09.2017 21:41, Christoph Berg wrote:
> Re: Ole Streicher 2017-09-22 
>> I would just do this for my own packages (pqsphere and q3c), which would
>> allow to collect experiences; but ofcourse I don't want to shoot into
>> your feet with the packaging at the postgresql site.
> 
> The plan seems sensible, so please go ahead, it will be an interesting
> experiment. The plethora of mini packages we have now isn't ideal.

I just uploaded q3c as a single binary package. pgsphere will follow
after some discussion with the main users (hi Markus :-) )

> My main concern is supporting upgrades cleanly. Imagine "your" package
> had already been around in jessie, and the user had postgresql-9.4 +
> postgresql-q3c installed where q3c provided the 9.4 extension. Now the
> user upgrades to stretch, gets postgresql-9.6 installed (e.g. via
> postgresql.deb), the 9.4 cluster will still work, but the upgraded
> postgresql-q3c package from stretch suddenly doesn't provide the 9.4
> anymore, but only 9.6, rendering q3c broken in the 9.4 cluster.

This can be addressed by introducing Postgresql-versioned Provides. If
the q3c package would support f.e. 9.6 and 10, it can have

Provides: postgresql-9.6-q3c, postgresql-10-q3c

If you then need q3c for a specific version, you can install/depend on
this specific version. This also allows a smooth transition between the
multi-binary-package approach and the single binary package.

This is already implemented in the uploaded version.

> Maybe we could just claim that the user should upgrade their database
> at the same time, and for many extensions this will not be a problem.
> But for extensions providing datatypes (I think that includes q3c),
> the .so module is needed for dumping the old data, so at least
> dump-restore upgrades are affected. pg_upgrade should still work,
> though. (Making pg_upgradecluster use that by default is another
> story.)

This may indeed need some work; however I need some advice here.

Best regards

Ole

Bug#820829: please drop transitional package libpcap-dev

[Manuel A. Fernandez Montecelo]

2017-09-12 07:47 Hugh McMaster:

Package: libpcap-dev
Version: 1.8.1-4
Followup-For: Bug #872265

If dropping the package is not desirable, please mark
the package Multi-Arch: foreign to satisfy other packages
that build-depend on libpcap-dev.

Alternatively, making libpcap-dev the primary development package would be
beneficial, avoiding this situation.


Yes please, bug #820829 also asks for the same thing.

Would it help if we prepare an NMU for this?


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#876701: rc-alert: a patch for ~/.boring-bugs to ignore

[Adam Borowski]

On Mon, Sep 25, 2017 at 09:03:08PM +0900, Osamu Aoki wrote:
> On Mon, Sep 25, 2017 at 12:37:57AM +0200, Adam Borowski wrote:
> ...
> > Here's a patch that implements "~/.boring-bugs".  If such a file exists, all
> > lines starting with a bug number make rc-alert and tools that use it filter
> > out those bugs.
> 
> Interesting idea.  I thought it needs to update manpage rc-alert.1 too.
> Maybe for clarity, something like the following may be a good idea.

I did not include documentation in the first stab because 1. a RFC patch is
likely to be changed (like, an option to show all bugs anyway, a different
location of the file, etc), and 2. the documentation is quite trivial.

>   The valid bug number should be listed by itself or followed by a
>   whitespace.  All other contents in the "~/.boring-bugs" are treated as
>   the comment.

So the full paragraph would be something like:
.
If the file $HOME/.boring-bugs exists, all bugs listed in it are ignored.
Bugs should be listed as numbers on a line by itself or followed by
whitespace and an optional comment.  All other lines are also treated as
comments.
`

> > +while ()
> > +{
> > +   next unless /^(\d+)\s/;
> > +   $boring{$1} = 1;
> > +}
> > +close BOR;


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.

Bug#876773: flash-kernel: Please add support for the original SolidRun CuBox (Dove)

[Vagrant Cascadian]

On 2017-09-25, Josua Mayer wrote:
> The SolidRun CuBox has very good support in Mainline Linux.
> Thus it is a great candidate for supporting it in Debian.
...
> I have come up with the database entry below, and this preliminary 
> boot-script:
> setenv loadaddr   0x0200
> setenv loadaddrrd 0x2000
> setenv bootargs console=ttyS0,115200n8
> ${fstype}load ${device_name} 0:${partition} ${loadaddr} /boot/uImage
> ${fstype}load ${device_name} 0:${partition} ${loadaddrrd} /boot/uInitrd
> bootm $loadaddr $loadaddrrd

loaddr is already set in your environment, no need to set it again.

If you use:

  setenv bootargs @@LINUX_KERNEL_CMDLINE_DEFAULTS@@ ${bootargs} ${console} 
@@LINUX_KERNEL_CMDLINE@@

Then flash-kernel can be configured with options from
/etc/default/flash-kernel.

And have this before the load/bootm parts:

  @@UBOOT_ENV_EXTRA@@

Then local environment overrides can be set from
/etc/flash-kerenel/ubootenv.d or /usr/share/flash-kernel/ubootenv.d.


> I am running U-Boot 2009.08-dirty (Mar 09 2013 - 18:15:45) Marvell version: 
> 5.4.4 NQ SR1.
> It comes with a prepopulated bootcmd environment variable that tries out:
> - usb sata(ide) mmc
> - partitions 1,2
> - directores / and /boot
> to find a boot.scr.
> At the time of loading it, these variables are set accordingly:
> device_name, partition, directory, fstype
> which can be used in our boot.scr.

You also *might* want to emulate upstream u-boot conventions and use the
variables consistant with other boot scripts, and set up a thin
compatibility layer:

  setenv kernel_addr_r $loadaddr
  setenv ramdisk_addr_r 0x2000
  setenv devtype $device_name
  setenv devnum 0
  setenv bootpart $partition
  setenv distro_bootpart $partition
  setenv prefix $directory

With that at the top of your file, you could probably copy the
uboot-generic script and make minor modifications to get it working
(change "load" to "${fstype}load" and "bootz" to "bootm", change "/boot"
to "${prefix}"), and it would be more similar to the standard boot
scripts, and it'd be easier to adapt if upstream u-boot support was
later added with distro_bootcmd support.


> One important thing that is missing, is bootargs!
> We need to set: console, root, rootfstype, rootwait

Your bootscript already sets the console in bootargs, so I'm not sure
what you mean...

> - rootfstype could be gathered from fstype

I would not assume that the / fs and /boot fs are the same. But, you
shouldn't need to set that if you're using an initrd that can detect the
filesystem on it's own (e.g. initramfs-tools).

> - any ideas how to generate the root= option?
>   Ideally we could use UUID= there!
>   Or does Bootloader-Sets-Incorrect-Root: yes help here?

Again, with initramfs-tools, flash-kernel adds a root= entry based on
fstab in the initrd, so that in that case, you don't need root= defined
in the u-boot environment.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#876777: octave-stk FTBFS on i386: test failure

[Adrian Bunk]

Source: octave-stk
Version: 2.4.2-1
Severity: serious

https://tests.reproducible-builds.org/debian/history/octave-stk.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/octave-stk.html

...
* test
 model = stk_model ('stk_materncov_iso');
 [param0, model.lognoisevariance] = stk_param_init (model, xi, zi, BOX);
 model.param = stk_param_estim (model, xi, zi, param0);
 zp = stk_predict (model, xi, zi, xt);
 assert (max ((zp.mean - zt) .^ 2) < 1e-3)
! test failed
operator *: nonconformant arguments (op1 is 2x2, op2 is 3x1)
shared variables 
  scalar structure containing the fields:
...
Summary: 1317 tests, 1316 passed, 0 known failures, 0 skipped
/usr/share/cdbs/1/class/octave-pkg.mk:108: recipe for target 'check-pkg' failed
make: *** [check-pkg] Error 1

Bug#876687: htpdate: Off by one hour

[Mert Dirik]

Thanks! Please let me know if you need further testing.

On Sep 25, 2017 22:12, "Eddy Vervest"  wrote:

So incorrect/out-dated TZDATA (Version: 2017b-1) causes htpdate to
calculate gmtoffset incorrectly.

Debian needs an update and I will patch htpdate in the near future.

Thanks

Bug#876750: [Pkg-lirc-maint] Bug#876750: lirc: Configuration loglevel

[Alec Leamas]

On 25/09/17 16:29, Arno None wrote:

When trying to get lirc running with an IguanaIR transceiver I came 
accross the followig:


Loglevel is not configured with 'loglevel' in lirc_options.conf but with 
'debug'.


Ack, this is a mess that needs to be rectified, keeping it backwards 
compatible. Filed upstream bug [1].


Thanks for reporting!

--alec


[1} https://sourceforge.net/p/lirc/tickets/310/

Bug#876776: fityk FTBFS: FAIL: tests/psvoigt

[Adrian Bunk]

Source: fityk
Version: 1.3.1-1
Severity: serious
Tags: patch

https://buildd.debian.org/status/fetch.php?pkg=fityk=i386=1.3.1-2=1506310354=0
https://tests.reproducible-builds.org/debian/rb-pkg/buster/i386/fityk.html

...
make  check-TESTS
make[3]: Entering directory '/<>'
make[4]: Entering directory '/<>'
PASS: tests/num
PASS: tests/guess
PASS: tests/gradient
PASS: tests/lua
FAIL: tests/psvoigt
===
   fityk 1.3.1: ./test-suite.log
===

# TOTAL: 5
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests/psvoigt
===


~~~
psvoigt is a Catch v1.10.0 host application.
Run with -? for options

---
pseudo-voigt
---
tests/psvoigt.cpp:25
...

tests/psvoigt.cpp:50: FAILED:
  REQUIRE( ib == area/height )
with expansion:
  8.2712875192 == 8.2712875192
with message:
  Testing PseudoVoigt

===
test cases:  6 |  5 passed | 1 failed
assertions: 34 | 33 passed | 1 failed

FAIL tests/psvoigt (exit status: 1)


Testsuite summary for fityk 1.3.1

# TOTAL: 5
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See ./test-suite.log

Makefile:1441: recipe for target 'test-suite.log' failed
make[4]: *** [test-suite.log] Error 1


Fix:

--- debian/rules.old2017-09-25 18:45:49.0 +
+++ debian/rules2017-09-25 18:50:19.0 +
@@ -2,6 +2,10 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+ifneq (,$(filter $(DEB_HOST_ARCH), i386))
+export DEB_CXXFLAGS_MAINT_APPEND=-ffloat-store
+endif
+
 %:
dh $@ --buildsystem=autoconf --parallel --with sphinxdoc
 

Bug#876743: flatpak: FTBFS on hppa: Creating new namespace failed: Invalid argument

[Simon McVittie]

Control: retitle 876743 flatpak: FTBFS on hppa: Creating new namespace failed: 
Invalid argument

On Mon, 25 Sep 2017 at 09:40:39 -0400, Aaron M. Ucko wrote:
> Source: flatpak
> Version: 0.9.12-2
> Severity: important
> Tags: upstream
> Justification: fails to build from source (but built successfully in the past)
> 
> The flatpak build for hppa (admittedly not a release architecture) has
> started failing:
> 
>   ERROR: tests/test-run.sh - too few tests run (expected 12, got 0)

Unfortunately this part of the log is relatively useless. As with all recent
Automake packages, please scroll down to just after the summary

# TOTAL: 57
# PASS:  35
# SKIP:  12
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 10

where you will see full logs quoted for the skipped and failing tests,
with underlined headers like

ERROR: tests/test-run.sh


followed by logged output. Unfortunately, because stdout and stderr have
different levels of buffering, the logged output is not particularly
easy to read in this case :-(

I think the real error might be this:

> ++ bwrap --ro-bind / / /bin/true
> (no error here)
... but then later
> Creating new namespace failed: Invalid argument

This indicates that, unlike most Debian buildds, your hppa buildd allows
enough namespace creation that bwrap (bubblewrap) can work at all; but
then it does not allow enough namespace creation that Flatpak's more
complicated uses of bwrap also work.

This probably means the upstream test suite should have a better check for
whether bwrap works, so that these tests can be skipped on your buildd's
kernel (they can't pass there, and Flatpak won't work on that kernel).

Do hppa machines have recent enough kernels available that Flatpak is
of any practical use, for example able to install and run GNOME Recipes
from https://flathub.org/apps.html on a test machine? The jessie kernel
should work. If a recent enough kernel is available, please run it on
hppa buildds. If not, then IMO it's a positive thing that Flatpak FTBFS
on hppa, and the old (non-functional) binaries should probably be removed.

Regards,
smcv

Bug#876535: openjpeg2: Incoorporate lost changelogs (and possibly changes) for NMUs 2.1.2-1.1, 2.1.2-1.2 and 2.1.2-1.3

[Salvatore Bonaccorso]

Hi Mathieu,

On Mon, Sep 25, 2017 at 10:12:31AM +0200, Mathieu Malaterre wrote:
> Control: tags -1 pending
> 
> Hi Salvatore,
> 
> On Sat, Sep 23, 2017 at 1:59 PM, Salvatore Bonaccorso  
> wrote:
> > Source: openjpeg2
> > Version: 2.2.0-1
> > Severity: normal
> >
> > Hi Mathieu,
> >
> > There was an update for openjpeg2 not incoorporating the NMU changelog
> > for 2.1.2-1.1, 2.1.2-1.2 and 2.1.2-1.3. Please consider incorporating
> > those again (and double check no change was lost, I guess not that all
> > should in meanwhile be included in 2.2.0, but for #851422 I'm unsure
> > if it was fully covered, see the respective upstream issues which only
> > partially landed in 2.2.0).
> >
> > Specifically there were some CVEs addressed, which are hopefully still
> > be fixed in 2.2.0-1, the FTBFS defintively seems so.
> >
> > cut-cut-cut-cut-cut-cut-
> > diff -Nru openjpeg2-2.1.2/debian/changelog openjpeg2-2.2.0/debian/changelog
> > --- openjpeg2-2.1.2/debian/changelog2017-08-12 15:54:38.0 +0200
> > +++ openjpeg2-2.2.0/debian/changelog2017-09-22 21:51:36.0 +0200
> > @@ -1,26 +1,13 @@
> > -openjpeg2 (2.1.2-1.3) unstable; urgency=medium
> > +openjpeg2 (2.2.0-1) unstable; urgency=medium
> >
> > -  * Fix FTFBS (Closes: #871905)
> > +  * New upstream release. Closes: #872041
> > +  * Fix CVE-2016-9113. Closes: #844552
> > +  * Fix CVE-2016-9114. Closes: #844553
> > +  * Fix CVE-2016-9115. Closes: #844554
> > +  * Fix CVE-2016-9116. Closes: #844555
> > +  * Fix CVE-2016-9117. Closes: #844556
> >
> > - -- Moritz Muehlenhoff   Sat, 12 Aug 2017 15:54:38 +0200
> > -
> > -openjpeg2 (2.1.2-1.2) unstable; urgency=medium
> > -
> > -  * Non-maintainer upload
> > -  * Fix CVE-2016-1626, CVE-2016-1628, CVE-2016-5152, CVE-2016-9112 and
> > -CVE-2016-9118.patch
> > -
> > - -- Moritz Muehlenhoff   Fri, 11 Aug 2017 22:17:07 +0200
> > -
> > -openjpeg2 (2.1.2-1.1) unstable; urgency=medium
> > -
> > -  * Non-maintainer upload.
> > -  * Add CVE-2016-9572_CVE-2016-9573.patch patch.
> > -CVE-2016-9572: NULL pointer dereference in input decoding
> > -CVE-2016-9573: Heap out-of-bounds read due to insufficient check in
> > -imagetopnm(). (Closes: #851422)
> > -
> > - -- Salvatore Bonaccorso   Sun, 22 Jan 2017 14:18:13 
> > +0100
> > + -- Mathieu Malaterre   Fri, 22 Sep 2017 21:51:36 +0200
> >
> >  openjpeg2 (2.1.2-1) unstable; urgency=medium
> > cut-cut-cut-cut-cut-cut-
> >
> > Thanks for your time, double-checking and working on openjpeg2!
> 
> Wow ! That was bad :( Thanks for catching my mistake.

Thanks a lot for looking that quickly into this!

And thanks for reopening the bugs regarding the 2.2.0-1 stanza, which
are still under investigation/not yet fixed.

Regards,
Salvatore

Bug#876623: RFS: yamcha/0.33-2 -- General purpose chunker annotator

[Adam Borowski]

On Sun, Sep 24, 2017 at 04:53:43AM +0200, Giulio Paci wrote:
> * Package name: yamcha
>   Version : 0.33

> It builds those binary packages:
> 
>  libyamcha1  - general purpose chunker annotator - runtime library
>  libyamcha-dev - general purpose chunker annotator - development files
>  yamcha - general purpose chunker annotator
> 
> The upload closes #875993.
> 
> You can find the source of the package at:
> 
>   https://anonscm.debian.org/cgit/collab-maint/yamcha.git

It seems like there are problems building docs:

.--[ build log ]
dh_installdocs -pyamcha 
dh_installdocs: Cannot find (any matches for) "html" (tried in .)

dh_installexamples -pyamcha 
dh_installman -pyamcha 
dh_installman: Cannot find (any matches for) "usr/share/man/man1/*.1" (tried in 
.)
`

.--[ debdiff yamcha_*deb ]
Files in first .deb but not in second
-
-rw-r--r--  root/root   /usr/share/doc/yamcha/html/feature.png
-rw-r--r--  root/root   /usr/share/doc/yamcha/html/feature2.png
-rw-r--r--  root/root   /usr/share/doc/yamcha/html/feature3.png
-rw-r--r--  root/root   /usr/share/doc/yamcha/html/feature4.png
-rw-r--r--  root/root   /usr/share/doc/yamcha/html/feature5.png
-rw-r--r--  root/root   /usr/share/doc/yamcha/html/index.html
-rw-r--r--  root/root   /usr/share/doc/yamcha/html/yamcha.css
-rw-r--r--  root/root   /usr/share/doc/yamcha/html/yamcha.html
-rw-r--r--  root/root   /usr/share/lintian/overrides/yamcha
-rw-r--r--  root/root   /usr/share/man/man1/yamcha.1.gz
`

.--[ lintian ]
W: yamcha: binary-without-manpage usr/bin/yamcha
E: yamcha: doc-base-file-references-missing-file yamcha:13 
/usr/share/doc/yamcha/html/index.html
E: yamcha: doc-base-file-references-missing-file yamcha:14 
/usr/share/doc/yamcha/html/*
`


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.

Bug#876687: htpdate: Off by one hour

[Mert Dirik]

On 09/25/2017 09:57 PM, Eddy Vervest wrote:

Hi Mert,

Thanks for your quick response. Can you try to set you system to EAT
time zone?  That timezone had GMT+3 already for long time... if that
works it is for sure the timezone database of debian.

Changing my code, so it will not use timezone info, isn't as
straightforward as I thought... will need some more investigation.

Regards, Eddy


That seems to do it:


$ sudo dpkg-reconfigure -plow tzdata
[sudo] password for mert:

Current default time zone: 'Africa/Djibouti'
Local time is now:  Mon Sep 25 21:02:10 EAT 2017.
Universal Time is now:  Mon Sep 25 18:02:10 UTC 2017.

$ sudo ntpdate pool.ntp.org; date -u
25 Sep 22:02:46 ntpdate[8432]: step time server 62.12.173.12 offset 
3601.195427 sec

Mon Sep 25 19:02:46 UTC 2017
$ sudo htpdate -s www.google.com.tr www.facebook.com www.youtube.com; 
date -u

No time correction needed
Mon Sep 25 19:03:01 UTC 2017

Bug#876687: htpdate: Off by one hour

[Eddy Vervest]

So incorrect/out-dated TZDATA (Version: 2017b-1) causes htpdate to
calculate gmtoffset incorrectly.

Debian needs an update and I will patch htpdate in the near future.

Thanks

Bug#876687: htpdate: Off by one hour

[Eddy Vervest]

Hi Mert,

Thanks for your quick response. Can you try to set you system to EAT
time zone?  That timezone had GMT+3 already for long time... if that
works it is for sure the timezone database of debian.

Changing my code, so it will not use timezone info, isn't as
straightforward as I thought... will need some more investigation.

Regards, Eddy


On 25-09-17 19:46, Mert Dirik wrote:
> On 09/25/2017 09:31 PM, Eddy Vervest wrote:
>>
>> Hi All,
>>
>> It seems related to the timezone changes which Turkey had this
>> year... moving away from daylight saving to always +3.
>>
>> In the bug report this line is interesting:
>>
>>   Timezone: GMT+2 (+03,+03)
>>
>> In brackets there should be a time zone in like TRT, CEST, WET... but
>> it tells +03... but at the same time GMT+2. Updating the TZ package
>> (https://packages.debian.org/stretch/tzdata) and setting the system
>> time to the correct timezone probably will solve the issue.
>>
>> Regards, Eddy
>>
>> PS. I will look into the code some more, because I don't remember why
>> I use time zone information in the first place... should be possible
>> without I guess.
>>
> Hi, Eddy
>
> Timezone was set correctly but I configured it again to make sure and
> result is same:
>
>> $ dpkg -s tzdata
>> Package: tzdata
>> Status: install ok installed
>> Priority: required
>> Section: localization
>> Installed-Size: 3010
>> Maintainer: GNU Libc Maintainers 
>> Architecture: all
>> Multi-Arch: foreign
>> Version: 2017b-1
>> Replaces: libc0.1, libc0.3, libc6, libc6.1
>> Provides: tzdata-stretch
>> Depends: debconf (>= 0.5) | debconf-2.0
>> Description: time zone and daylight-saving time data
>>  This package contains data required for the implementation of
>>  standard local time for many representative locations around the
>>  globe. It is updated periodically to reflect changes made by
>>  political bodies to time zone boundaries, UTC offsets, and
>>  daylight-saving rules.
>> Homepage: http://www.iana.org/time-zones
>>
>> $ cat /etc/timezone
>> Europe/Istanbul
>>
>> $ sudo dpkg-reconfigure -plow tzdata
>> Current default time zone: 'Europe/Istanbul'
>> Local time is now:  Mon Sep 25 21:40:52 +03 2017.
>> Universal Time is now:  Mon Sep 25 18:40:52 UTC 2017.
>>
>> $ sudo ntpdate pool.ntp.org; date -u
>> 25 Sep 21:41:33 ntpdate[5303]: adjust time server 192.36.143.130
>> offset 0.006932 sec
>> Mon Sep 25 18:41:33 UTC 2017
>> $ sudo htpdate -s www.google.com.tr www.facebook.com www.youtube.com;
>> date -u
>> Setting -3600.333 seconds
>> Set: Mon Sep 25 20:41:47 2017
>>
>> Mon Sep 25 17:41:47 UTC 2017
>> $
>
> Best regards,
> Mert
>
>

Bug#876033: primusrun doesn't find libGL.so.1

[Andreas Beckmann]

[ Cc:ing the libglvnd maintainer ]

On 09/25/2017 04:38 PM, Emilio J. Padrón wrote:
> I obtain the same error when trying primusrun (or optirun) in my system:
> 
> % primusrun glxinfo
> /usr/bin/primusrun: line 41: warning: command substitution: ignored null byte 
> in input
> primus: fatal: failed to load any of the libraries:
> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1:/usr/lib/i386-linux-gnu/nvidia/libGL.so.1:/usr/lib/nvidia/libGL.so.1
> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1: cannot open shared object file: 
> No such file or directory
> /usr/lib/i386-linux-gnu/nvidia/libGL.so.1: cannot open shared object file: No 
> such file or directory
> /usr/lib/nvidia/libGL.so.1: cannot open shared object file: No such file or 
> directory
> 
> The '__GLVND_DISALLOW_PATCHING=1' workaround did not work for me :-?
> (same error messages).

The question is: how should primusrun/optirun work in a GLVND
environment? There is no longer the "vendor" libGL.so.1 that has to be
loaded instead of the system libGL.so.1
As I understand it, GLVND is supposed to provide a better solution to
the underlying problem addressed by primusrun/optirun.

Note: if libgl1-nvidia-glvnd-glx is used (instead of libgl1-nvidia-glx)
and libgl1 (from src:libglvnd) is installed instead of
libgl1-glvnd-nvidia-glx, there is no longer a nvidia-provided
/usr/lib/*/nvidia/libGL.so.1

(Note for Timo: for the nvidia drivers we still need to divert the
system libGL.so.1 (and much more) since the legacy 304xx, 340xx drivers
don't support GLVND and we therefore still need to use the nested
alternatives, and we want to have them co-installable with the current
drivers)

> By the way, I suppose it is not really related, but I'm not able to install
> nvidia glvnd packages, libgl1-glvnd-nvidia-glx 375.82-4 and
> libglvnd0-nvidia 375.82-4, due to dependency problems. The metapackage
> libgl1-nvidia-glvnd-glx 375.82-4 is installed ok, since the libgl1
> dependency is provided by other packages. Is it also a bug? :-?

That is intentional to allow the nvidia packages into testing which
still has mesa 13.x and no libglvnd. You should be fine with the libgl1,
... packages from src:libglvnd in sid.


Andreas

Bug#876742: closed by Benjamin Drung <benjamin.dr...@profitbricks.com> (Re: Bug#876742: ImportError: No module named 'Redmine')

[Wim Bertels]

Hallo,

for documentation:
> from redminelib import Redmine

should be
> from redmine import Redmine
(in the debian package)

mvg,
Wim


Op 25-09-17 om 17:57 schreef Debian Bug Tracking System:
> This is an automatic notification regarding your Bug report
> which was filed against the python3-redmine package:
> 
> #876742: ImportError: No module named 'Redmine'
> 
> It has been closed by Benjamin Drung .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Benjamin Drung 
>  by
> replying to this email.
> 
> 

Bug#876687: htpdate: Off by one hour

[Mert Dirik]

On 09/25/2017 09:31 PM, Eddy Vervest wrote:


Hi All,

It seems related to the timezone changes which Turkey had this year... 
moving away from daylight saving to always +3.


In the bug report this line is interesting:

  Timezone: GMT+2 (+03,+03)

In brackets there should be a time zone in like TRT, CEST, WET... but 
it tells +03... but at the same time GMT+2. Updating the TZ package 
(https://packages.debian.org/stretch/tzdata) and setting the system 
time to the correct timezone probably will solve the issue.


Regards, Eddy

PS. I will look into the code some more, because I don't remember why 
I use time zone information in the first place... should be possible 
without I guess.



Hi, Eddy

Timezone was set correctly but I configured it again to make sure and 
result is same:



$ dpkg -s tzdata
Package: tzdata
Status: install ok installed
Priority: required
Section: localization
Installed-Size: 3010
Maintainer: GNU Libc Maintainers 
Architecture: all
Multi-Arch: foreign
Version: 2017b-1
Replaces: libc0.1, libc0.3, libc6, libc6.1
Provides: tzdata-stretch
Depends: debconf (>= 0.5) | debconf-2.0
Description: time zone and daylight-saving time data
 This package contains data required for the implementation of
 standard local time for many representative locations around the
 globe. It is updated periodically to reflect changes made by
 political bodies to time zone boundaries, UTC offsets, and
 daylight-saving rules.
Homepage: http://www.iana.org/time-zones

$ cat /etc/timezone
Europe/Istanbul

$ sudo dpkg-reconfigure -plow tzdata
Current default time zone: 'Europe/Istanbul'
Local time is now:  Mon Sep 25 21:40:52 +03 2017.
Universal Time is now:  Mon Sep 25 18:40:52 UTC 2017.

$ sudo ntpdate pool.ntp.org; date -u
25 Sep 21:41:33 ntpdate[5303]: adjust time server 192.36.143.130 
offset 0.006932 sec

Mon Sep 25 18:41:33 UTC 2017
$ sudo htpdate -s www.google.com.tr www.facebook.com www.youtube.com; 
date -u

Setting -3600.333 seconds
Set: Mon Sep 25 20:41:47 2017

Mon Sep 25 17:41:47 UTC 2017
$


Best regards,
Mert

Bug#876377: ruby2.3: Ruby process stuck on sched_yield busyloop

[Antonio Terceiro]

Hi,

thanks for your bug report

On Thu, Sep 21, 2017 at 04:37:17PM +0300, Gregory Potamianos wrote:
> Package: ruby2.3
> Version: 2.3.3-1+deb9u1
> Severity: important
> Tags: upstream patch
> Forwarded: https://bugs.ruby-lang.org/issues/13794
> 
> Hello,
> 
> After the upgrade to stretch we keep finding ruby processes (puppet
> agents in particular) stuck in a sched_yield busyloop. The stuck process
> is always a forked child of the main puppet agent running inside a
> timeout block.
> 
> The backtrace of the process is the following:
> 
> (gdb) thread apply all bt
> 
> Thread 2 (Thread 0x7f2dc7904700 (LWP 11226)):
> #0  0x7f2dc63bb6ad in poll () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x7f2dc73fba62 in timer_thread_sleep (gvl=0x5628917b3f28) at
> thread_pthread.c:1455
> #2  thread_timer (p=0x5628917b3f28) at thread_pthread.c:1563
> #3  0x7f2dc7045494 in start_thread () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> #4  0x7f2dc63c4aff in clone () from /lib/x86_64-linux-gnu/libc.so.6
> 
> Thread 1 (Thread 0x7f2dc78fc700 (LWP 11224)):
> #0  0x7f2dc63adca7 in sched_yield () from
> /lib/x86_64-linux-gnu/libc.so.6
> #1  0x7f2dc73fbac5 in native_stop_timer_thread () at
> thread_pthread.c:1664
> #2  rb_thread_stop_timer_thread () at thread.c:3902
> #3  0x7f2dc7341c42 in before_exec_non_async_signal_safe () at
> process.c:1175
> #4  before_exec () at process.c:1181
> #5  rb_f_exec (argc=, argv=) at
> process.c:2576
> 
> And the offending part of the code is this:
> 
> native_stop_timer_thread(void)
> {
> int stopped;
> stopped = --system_working <= 0;
> 
> if (TT_DEBUG) fprintf(stderr, "stop timer thread\n");
> #if USE_SLEEPY_TIMER_THREAD
> if (stopped) {
> /* prevent wakeups from signal handler ASAP */
> timer_thread_pipe.owner_process = 0;  
> 
> /*   
>  * however, the above was not enough: the FD may already be
>  * captured and in the middle of a write while we are running,
>  * so wait for that to finish:
>  */  
> while (ATOMIC_CAS(timer_thread_pipe.writing, (rb_atomic_t)0, 0)) {
> native_thread_yield();
> }   
> [..]
> }
> 
> Thread 1 is spinning around `timer_thread_pipe.writing` because someone has
>  erroneously bumped it to 1.
> 
> (gdb) print timer_thread_pipe
> $1 = {normal = {3, 4}, low = {5, 6}, owner_process = 0, writing = 1}
> 
> 
> Our case seems identical to this [1] bug report. We have applied the patch [2]
> by Eric Wong and the problem seems resolved without causing any other 
> problems.
> 
> [1] https://bugs.ruby-lang.org/issues/13794
> [2] https://80x24.org/spew/20170809232533.14932-...@80x24.org/raw

can you provide a minimal test case that can reproduce the issue that
does not take hours/days?

Also, it would be nice to have some feedback from upstream about whether
one of those patches is going to be applied. I would not like to to
carry such patch indefinitely.

Bug#876775: pdns-tools: /etc/init.d/pdns isrunning() broken

[neonknight]

Package: pdns-tools
Version: 4.0.3-1
Severity: important
Tags: patch

before any function in /etc/init.d/pdns is executed, the script checks
if pdns is running by calling the function isrunning(). This function
determines the status of pdns by sending pdns_control ping. however,
pdns_control does not support a command named "ping". the correct
command would be "rping". this renders the init script unusable. even on
a systemd enabled system, the init script might still be used e.g. for
generating statistics with mrtg.

here's my suggestion for a patch to fix the issue:

$ diff pdns.orig pdns
56c56
<   doPC ping > /dev/null
---
>   doPC rping > /dev/null

PS apologies, for whatever reason my reportbug insists filing this bug 
for pdns-tools. the affected package of course is pdns-server. some mod
please adjust this for me...

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 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 pdns-tools depends on:
pn  libboost-program-options1.62.0  
ii  libc6   2.24-11+deb9u1
ii  libgcc1 1:6.3.0-18
ii  libssl1.1   1.1.0f-3
ii  libstdc++6  6.3.0-18

pdns-tools recommends no packages.

pdns-tools suggests no packages.