Bug#892552: ITP: libgradle-plugin-markdown-java -- Markdown Gradle Plugin

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 

* Package name: libgradle-plugin-markdown-java
  Version : 1.1.0
  Upstream Author : Andres Almiray 
* URL : https://github.com/aalmiray/markdown-gradle-plugin
* License : Apache 2.0
  Programming Lang: Java
  Description : Markdown Gradle Plugin

This plugin provides a facility for converting markdown into HTML, as well as 
converting HTML back into markdown. It is based on the grails-markdown plugin 
by Ted Naleid.

It's a dependency for Smack (ITP: #892551).

I plan to maintain it myself.

Bug#890097: src:django-anymail: New, minor WEBHOOK_AUTHORIZATION security issue

[Salvatore Bonaccorso]

Hi,

On Sun, Feb 11, 2018 at 01:08:01AM -0500, Scott Kitterman wrote:
> Given that the fix for this is problematic from a backward compatility
> perspective and that it requires a misconfigured django app before it is a
> problem, recommend No DSA for the security team.

Scott, sorry we did not respond earlier. Yes agree, and marked it as
no-dsa.

Regards,
Salvatore

Bug#892551: ITP: libsmack-java -- XMPP (Jabber) client library for instant messaging and presence

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 

* Package name: libsmack-java
  Version : 4.2.3
  Upstream Author : Florian Schmaus  and others
* URL : https://github.com/igniterealtime/Smack
* License : Apache 2.0
  Programming Lang: Java
  Description : XMPP (Jabber) client library for instant messaging and 
presence

Smack is an open source, highly modular, easy to use, XMPP client library 
written in Java for Java SE compatible JVMs and Android.

A pure Java library, it can be embedded into your applications to create 
anything from a full XMPP instant messaging client to simple XMPP integrations 
such as sending notification messages and presence-enabling devices. Smack and 
XMPP allows you to easily exchange data, in various ways e.g. fire-and-forget, 
publish-subscribe, between human and non-human endpoints (M2M, IoT, …).

This package has been RFP: #779110, #640873. It's also in the dependecy chain 
of VASSAL Engine I'm up to packaging.

I plan to maintain is myself.

Bug#892505: transition: openexr

[Matteo F. Vescovi]

Hi Emilio!

On 2018-03-10 at 10:27 (+0100), Emilio Pozuelo Monfort wrote:

[...]

>> ### Dependency level 3 ###
>>  * gmic_1.7.9+zart-4 => FTBFS (not openexr related)
>>  * gst-plugins-bad1.0_1.8.3-1 => FTBFS (not openexr related)
>
> unstable has gst-plugins-bad1.0 1.12.4-2.
> Did you really check with 1.8.3-1?

Gosh, reverse-depends from ubuntu-dev-tools package brought that version
in my list, no idea why. Anyway, I've checked gst-plugins-bad1.0
1.12.4-2 and:

 * gst-plugins-bad1.0 1.12.4-2 => OK

> Can you also check the other packages that failed to build (gmic and
> vips)?

Unfortunately, both were built on the right versions and they fail; gmic
with:

= = = = = = = >8 = = = = = =
dh_install: Cannot find (any matches for) "etc/bash_completion.d/gmic"
(tried in ., debian/tmp)

dh_install: gmic missing files: etc/bash_completion.d/gmic
dh_install: missing files, aborting
= = = = = = = >8 = = = = = =

while vips on some weird missing dependencies where openexr is not
involved, it seems.

Hope this helps.

Cheers.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#892063: cpputest: FTBFS on hppa - __canonicalize_funcptr_for_compare (0xdeadbeef)

[John David Anglin]

On 2018-03-10 3:39 AM, Raphael Hertzog wrote:

Given your work on the compiler, does it really make sense to try to fix
something in cpputest?

The only clean fix I can think of is to modify the tests to use a real
function pointer instead of 0xdeadbeef. I don't think that an architecture
specific work-around or fix is desirable here.
0xdeadbeef isn't a valid function pointer on hppa.  I would say using a 
real function pointer is correct:


Pointers to objects or functions of the same type (after pointer 
conversions) can be compared for equality.
Two pointers of the same type compare equal if and only if they are both 
null, both point to the same function,

or both represent the same address (3.9.2).

On systems that use function descriptors, it can be tricky to determine 
where a function pointer points due

to lazy binding, etc.

Dave

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

Bug#890043: wcc: diff for NMU version 0.0.2+dfsg-2.1

[Adrian Bunk]

On Sat, Mar 10, 2018 at 12:48:43AM +0100, Raphael Hertzog wrote:
> On Fri, 09 Mar 2018, Adrian Bunk wrote:
> > I've prepared an NMU for wcc (versioned as 0.0.2+dfsg-2.1) and uploaded 
> > it to DELAYED/3. Please feel free to tell me if I should cancel it.
> 
> Thanks for this, but I just uploaded a new version with this change and
> other cleanups too.

Thanks, that's much better than an NMU.

I've cancelled my upload.

> Cheers,

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#823624: tgz etc. in @ARCHIVE_EXT@

[Pierre-Elliott Bécue]

Le samedi 10 mars 2018 à 23:29:31+0900, Osamu Aoki a écrit :
> On Fri, Mar 09, 2018 at 05:55:38PM +0100, Pierre-Elliott Bécue wrote:
> ...
> > > This piece of code is just designed to replace @ARCHIVE_EXT@ and
> > > @SIGNATURE_EXT@ by a regexp. These are never used in the remaining 
> > > portions
> > > of uscan.pl or mk-origtargz.pl.
> > > 
> > > Could you help me at seeing how these changes might introduce any issue?
> > > 
> > > Cheers. :)
> > 
> > To be more specific, I reviewed your changes introducing these lines of code
> > before applying the patch. The commit that introduced the @ARCHIVE_EXT@
> > feature is
> > https://salsa.debian.org/debian/devscripts/commit/8ebab1c2bfa97830ca670d6830444297910282c7
> 
> Yes, I am aware.
> 
> Please read manpage and manpage is still correct after your change.
> 
> For example, is this correct?
> | =head2 HTTP site (pgpsigurlmangle)
> | 
> | Here is an example for the basic single upstream tarball with the matching
> | signature file in the same file path.
> | 
> |   version=4
> |   opts="pgpsigurlmangle=s%$%.asc%" 
> http://example.com/release/@PACKAGE@.html \
> |   files/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ debian uupdate
> 
> 
> For example, is this correct?
> |   version=4
> |   opts="pgpsigurlmangle=s%@ARCHIVE_EXT@$%.asc%,decompress" \
> |   http://example.com/release/@PACKAGE@.html \
> |   files/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ debian uupdate
> 
> My memory is vague but the above cases are now broken ... that's why I
> didn't add such a trivial feature addition.  I also felt over
> engineering to address such a complicated case.  So I left such case to
> user's manual configuration.  You are welcomed to fix all these.  It was
> getting too messy to do so.  If you can refactor nicely, that's great!

Hi,

example cases with example.com url are not testable trivially. Do you have
a specific example of a case that is now broken because of the changes I
committed?

Cheers,

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


signature.asc
Description: PGP signature

Bug#823624: tgz etc. in @ARCHIVE_EXT@

[Osamu Aoki]

On Fri, Mar 09, 2018 at 05:55:38PM +0100, Pierre-Elliott Bécue wrote:
...
> > This piece of code is just designed to replace @ARCHIVE_EXT@ and
> > @SIGNATURE_EXT@ by a regexp. These are never used in the remaining portions
> > of uscan.pl or mk-origtargz.pl.
> > 
> > Could you help me at seeing how these changes might introduce any issue?
> > 
> > Cheers. :)
> 
> To be more specific, I reviewed your changes introducing these lines of code
> before applying the patch. The commit that introduced the @ARCHIVE_EXT@
> feature is
> https://salsa.debian.org/debian/devscripts/commit/8ebab1c2bfa97830ca670d6830444297910282c7

Yes, I am aware.

Please read manpage and manpage is still correct after your change.

For example, is this correct?
| =head2 HTTP site (pgpsigurlmangle)
| 
| Here is an example for the basic single upstream tarball with the matching
| signature file in the same file path.
| 
|   version=4
|   opts="pgpsigurlmangle=s%$%.asc%" http://example.com/release/@PACKAGE@.html \
|   files/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ debian uupdate


For example, is this correct?
|   version=4
|   opts="pgpsigurlmangle=s%@ARCHIVE_EXT@$%.asc%,decompress" \
|   http://example.com/release/@PACKAGE@.html \
|   files/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ debian uupdate

My memory is vague but the above cases are now broken ... that's why I
didn't add such a trivial feature addition.  I also felt over
engineering to address such a complicated case.  So I left such case to
user's manual configuration.  You are welcomed to fix all these.  It was
getting too messy to do so.  If you can refactor nicely, that's great!

Osamu

Bug#891068: im-config: Failed to setup fcitx when zsh used as login shell

[Osamu Aoki]

Hi,

> Not sure whether im-config or display manager (SDDM) should be blamed.
> Personally I think that system-wide  Xsession scripts should be called
> with system default shell (/bin/sh) instead of user login shell.

 Xsession scripts should be called with system default shell (/bin/sh)
 --- I agree.

I have /bin/sh = dash.  So this is OK.

 If you replace system default shell (/bin/sh) with zsh, it may break
 things.  Zsh is mostly /bin/sh compatible but not 100%.

Hmmm SDDM change shell parsing Xsession, then things may break.

Are you sure im-config is the problem?

Osamu

Bug#892547: closed by Guillem Jover <guil...@debian.org> (Re: Bug#892547: [Feature Request] Add architecture dependent keywords to dpkg-buildpackage --build=)

[jean-christophe manciot]

>
> No, dpkg-buildpackage or debian/rules, just build the packages
> matching the host architecture, not for all architectures.



In most cases, you're right.
But for instance, for binutils, the "--build=binary" option builds the
packages for all architectures: cf. the battached .buildinfo.

If you want to build for several architectures then you'd do something
> like this instead:
>
>   $ dpkg-buildpackage --arch=amd64 --build=any
>   $ dpkg-buildpackage --arch=arm64 --build=any
>
>
Thanks for the info: the --arch option is not listed in the official
sid dpkg-buildpackage
documentation
.


On Sat, Mar 10, 2018 at 2:09 PM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the dpkg package:
>
> #892547: [Feature Request] Add architecture dependent keywords to
> dpkg-buildpackage --build=
>
> It has been closed by Guillem Jover .
>
> 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 Guillem Jover <
> guil...@debian.org> by
> replying to this email.
>
>
> --
> 892547: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892547
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> From: Guillem Jover 
> To: jean-christophe manciot ,
> 892547-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sat, 10 Mar 2018 14:06:10 +0100
> Subject: Re: Bug#892547: [Feature Request] Add architecture dependent
> keywords to dpkg-buildpackage --build=
> Hi!
>
> On Sat, 2018-03-10 at 13:13:21 +0100, jean-christophe manciot wrote:
> > Package: dpkg
> > Version: 1.19.0.5
>
> > Right now, running dpkg-buildpackage --build=any builds all architecture
> > dependent packages, such as:
> > - amd64
> > - arm64
> > - m68k
> > - mips
> > - ...
>
> No, dpkg-buildpackage or debian/rules, just build the packages
> matching the host architecture, not for all architectures.
>
> > My proposal offers a way to build a specific or list of specific
> > architecture dependent packages through:
> > --build=[arch1],[arch2],...[archn]
> >
> > For instance:
> > - --build=amd64
> > - --build=amd64,arm64
> > ...
>
> > It must be possible to combine those architecture keywords with other
> > existing build keywords such as:
> > - all
> > - source
> >
> > For instance:
> > - --build=amd64,all
> > - --build=amd64,arm64,all
>
> If you want to build for several architectures then you'd do something
> like this instead:
>
>   $ dpkg-buildpackage --arch=amd64 --build=any
>   $ dpkg-buildpackage --arch=arm64 --build=any
>
> while having the appropriate cross-compilers and similar.
>
> Closing.
>
> Thanks,
> Guillem
>
> -- Forwarded message --
> From: jean-christophe manciot 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sat, 10 Mar 2018 13:13:21 +0100
> Subject: [Feature Request] Add architecture dependent keywords to
> dpkg-buildpackage --build=
> Package: dpkg
> Version: 1.19.0.5
>
> Right now, running dpkg-buildpackage --build=any builds all architecture
> dependent packages, such as:
> - amd64
> - arm64
> - m68k
> - mips
> - ...
>
> My proposal offers a way to build a specific or list of specific
> architecture dependent packages through:
> --build=[arch1],[arch2],...[archn]
>
> For instance:
> - --build=amd64
> - --build=amd64,arm64
> ...
>
> It must be possible to combine those architecture keywords with other
> existing build keywords such as:
> - all
> - source
>
> For instance:
> - --build=amd64,all
> - --build=amd64,arm64,all
> ...
> --
> Jean-Christophe Manciot
>
>


-- 
Jean-Christophe


binutils_2.30-7_amd64.buildinfo
Description: Binary data

Bug#892290: [Pkg-xfce-devel] Bug#892290: light-locker: at unlock, crash with: arguments to dbus_message_new_method_call() were incorrect

[Yves-Alexis Perez]

On Sat, 2018-03-10 at 10:20 +0100, Stuart Pook wrote:
> On 10/03/18 10:10, Yves-Alexis Perez wrote:
> > In any case, I really can't reproduce here, and you still didn't indicate
> > what
> > you changed to make it crash reliably, so I'm afraid I can't help.
> 
> light-locker crashes at unlock every time I run it from the command line.

And did it work before or is it the first time you tried?
> 
> What happens when you run light-locker from the command line?

It works just fine:

light-locker --lock-after-screensaver=3600 --debug
[gs_debug_init] gs-debug.c:106 (15:24:33):   Debugging enabled
[main] light-locker.c:142 (15:24:33):initializing light-locker 1.8.0
[main] light-locker.c:164 (15:24:33):Platform:
gtk:3
systemd:yes
ConsoleKit: yes
UPower: yes
[main] light-locker.c:196 (15:24:33):Features:
lock-after-screensaver: yes
late-locking:   yes
lock-on-suspend:yes
lock-on-lid:yes
settings backend:   GSETTINGS
[main] light-locker.c:198 (15:24:33):lock after screensaver 3600
[main] light-locker.c:199 (15:24:33):late locking 0
[main] light-locker.c:200 (15:24:33):lock on suspend 1
[main] light-locker.c:201 (15:24:33):lock on lid 0
[main] light-locker.c:202 (15:24:33):idle hint 1
[init_session_id] gs-listener-dbus.c:2193 (15:24:33):Got session-id: 
/org/freedesktop/login1/session/_32
[init_session_id] gs-listener-dbus.c:2198 (15:24:33):Got sd-session-id: 2
[init_seat_path] gs-listener-dbus.c:2279 (15:24:33): Got seat: 
/org/freedesktop/DisplayManager/Seat0
[gs_listener_delay_suspend] gs-listener-dbus.c:449 (15:24:33):   Delay suspend
[gs_listener_x11_acquire] gs-listener-x11.c:172 (15:24:33):  ScreenSaver 
Registered
[listener_dbus_handle_system_message] gs-listener-dbus.c:1343 (15:24:33):   
 obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus 
method=NameAcquired destination=:1.75
> 
> I agree that it should not normally be run from the command line.  I wanted
> to run lightlocker with different options and the running it from the
> command line was faster than logging on and off.

You can also edit the configuration (using dconf-editor for example) and I
think it should refresh it dynamically.

Regards,
-- 
Yves-Alexis

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

Bug#892382: devscripts: FTBFS in mipsel/mips64el: uscan_ftp test timeouts

[Mattia Rizzolo]

On Sat, Mar 10, 2018 at 11:09:51PM +0900, Osamu Aoki wrote:
> I am a bit confused...

Yes, this is getting confusing indeed!

> On Fri, Mar 09, 2018 at 05:51:42PM +0100, Mattia Rizzolo wrote:
> > I'm not _testing_ anything, this is with commit
> 
> Where can I find this commit? Alith or salsa?  URL, please.
> 
> > 77ecff2e9b18c74e8391aa0c8dccdd86a50544d5 that contains your changes
> 
> I don't see this in salsa.

https://salsa.debian.org/debian/devscripts/commit/77ecff2e9b18c74e8391aa0c8dccdd86a50544d5

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#892382: devscripts: FTBFS in mipsel/mips64el: uscan_ftp test timeouts

[Osamu Aoki]

Hi,

I am a bit confused...

On Fri, Mar 09, 2018 at 05:51:42PM +0100, Mattia Rizzolo wrote:
> On Sat, Mar 10, 2018 at 01:30:20AM +0900, Osamu Aoki wrote:
> > I don't see my patchies applied on salsa git repo.
> 
> Yes they are.
> 
> > I guess you are testing my old commit to alioth.
> 
> I'm not _testing_ anything, this is with commit

Where can I find this commit? Alith or salsa?  URL, please.

> 77ecff2e9b18c74e8391aa0c8dccdd86a50544d5 that contains your changes

I don't see this in salsa.

> below.
> 
> > I found out that using fixed port was problematic.  So I fixed this
> > bug.
> > If you squish my changes to a single patch, this should make a clean commit.
> > 
> > commit af4594ec380d78ebf2586e8d22299800be2bf06f (HEAD -> master, 
> > origin/master, origin/HEAD)
> > commit 363144086f16db9a9f944ee71012efd09a737126
> > commit 50844c1ba710eebfb7645e07416e7377a5dbd495 (wip)
> > commit 656c66fcfe41da0e5851e4e7e1c6e8caa2c535e8
> 
> All these 4 commits were included in the release, and it's failing with
> them.

Is this your private repo?

Let's see the same thing first ;-)

Osamu

Bug#892550: lintian: mail-transport-agent-dependency-does-not-specify-default-mta should not be triggered for Conflicts/Breaks/Replaces

[Andreas Metzler]

Package: lintian
Version: 2.5.79
Severity: normal

Hello,

lintian's newly introduced tag
mail-transport-agent-dependency-does-not-specify-default-mta warns not
only only about "Wants" relationships (i.e.
Depends/Recommends/Suggests/Build-Depends) but also about other "Keep
Out" relationships (Conflicts/Breaks/Replaces). That does not make
sense because the package providing default-mta also must provide
mail-transport-agent.

In fact it looks like the tag is even triggerd for Provides

W: exim4-daemon-heavy: 
mail-transport-agent-dependency-does-not-specify-default-mta provides: 
exim4-localscanapi-2.0, mail-transport-agent

which is always a false positive.

cu Andreas

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

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

Versions of packages lintian depends on:
ii  binutils  2.30-5
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.5
ii  file  1:5.32-2
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.60-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdpkg-perl  1.19.0.5
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-5
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.73-1
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.69+repack-1
ii  man-db2.8.2-1
ii  patchutils0.3.4-2
ii  perl  5.26.1-5
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

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

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

-- no debconf information
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#892481: r-cran-testthat: autopkgtest failure

[Dylan Aïssi]

Hi Graham,

On Fri, 9 Mar 2018 15:24:45 +0200 Graham Inggs  wrote:
>
> By changing the locale from C to C.UTF-8, similar to what I did in
> r-cran-urltools [3], there is only one test failure remaining:

Thanks. Done.

>
>  > test_check("testthat")
> ── 1. Error: returns local path when called from
> tools::testInstalledPackages (@
> cannot change working directory
> 1: setwd("test-path-installed/testthat-tests/testthat") at
> testthat/test-test-path.R:11
>
> ══ testthat results
> ═══
> OK: 449 SKIPPED: 2 FAILED: 1
> 1. Error: returns local path when called from
> tools::testInstalledPackages (@test-test-path.R#11)
>
> It is a new test, not a regression, so skipping it may be a valid option.
>

I am not sure how to proceed here. Is there a simple way to skip this
test except to patch the relevant file and to use the skip function?

Best,
Dylan

Bug#892472: please refer to nftables

[Arturo Borrero Gonzalez]

On 10 March 2018 at 14:29, Yaroslav Halchenko  wrote:
> I guess I have missed up with inability to version recommended packages... 
> Yeah, then we should provide as an alternative. Will do
>

Thanks!

BTW, yes, we can have versioned recommends as well. If not, that's a
bug that requires fixing.

Bug#892549: lintian: unnecessary-source-date-epoch-assignment should only be thrown for packages with strict enough build-dependencies

[Andreas Metzler]

Package: lintian
Version: 2.5.79
Severity: normal

Hello,

unnecessary-source-date-epoch-assignment is thrown for exim4, however

a) SOURCE_DATE_EPOCH is exported by pkg-info.mk since dpkg-dev 1.18.8
b) exim4 only build-depends on debhelper (>= 10), without an additional
   build-dependency on dpkg-dev ( >= 1.18.8)
c) debhelper 10 depends on dpkg (>= 1.16.2), dpkg-dev (>= 1.18.2~)

and therefore the build-depencies do not guarantee that dpkg-dev ( >=
1.18.8) is installed and the SOURCE_DATE_EPOCH assignment in
debian/rules is not superfluous.

Please only trigger the warning for packages with b-d on either
dpkg-dev ( >= 1.18.8) or debhelper (>= 10.10).

TIA, cu Andreas

cu Andreas

Bug#892548: dhelp: /usr/sbin/dhelp_parse broken with ruby 2.5

[gregor herrmann]

Package: dhelp
Version: 0.6.24
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

After the upgrade from ruby 2.3 to 2.5, /usr/sbin/dhelp_parse fails:


# sh -x /etc/cron.weekly/dhelp
+ '[' -d /var/lib/dhelp ']'
+ '[' -x /usr/sbin/dhelp_parse ']'
+ '[' -x /usr/bin/index++ ']'
+ rm --force /var/lib/dhelp/documents.index
+ /usr/sbin/dhelp_parse -r
Traceback (most recent call last):
5: from /usr/sbin/dhelp_parse:32:in `'
4: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
3: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
2: from /usr/lib/ruby/vendor_ruby/dhelp.rb:21:in `'
1: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot 
load such file -- dbm (LoadError)
+ /usr/sbin/dhelp_parse -i
Traceback (most recent call last):
5: from /usr/sbin/dhelp_parse:32:in `'
4: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
3: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
2: from /usr/lib/ruby/vendor_ruby/dhelp.rb:21:in `'
1: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot 
load such file -- dbm (LoadError)



Cheers,
gregor



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

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages dhelp depends on:
ii  doc-base0.10.8
ii  libcgi-pm-perl  4.38-1
ii  libdata-page-perl   2.02-1
ii  libhtml-parser-perl 3.72-3+b2
ii  liblocale-gettext-perl  1.07-3+b3
ii  libtemplate-perl2.24-1.2+b5
ii  liburi-perl 1.73-1
ii  perl5.26.1-5
ii  poppler-utils   0.62.0-2
ii  pstotext1.9-6+b2
ii  ruby1:2.5.0
ii  ruby-debian 0.3.9+b7
ii  ruby-gettext3.2.4-1
ii  swish++ 6.1.5-5
ii  ucf 3.0038

dhelp recommends no packages.

Versions of packages dhelp suggests:
pn  catdvi  
ii  chromium [www-browser]  64.0.3282.119-2+b2
ii  elinks [www-browser]0.12~pre6-13
ii  firefox [www-browser]   58.0.1-1+b1
ii  html2text   1.3.2a-21
pn  httpd-cgi   
pn  info2www
ii  lynx [www-browser]  2.8.9dev16-3
pn  man2html
ii  w3m [www-browser]   0.5.3-36

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlqj3qpfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgaXmA//UUbajGicQrfaab3ELRpxO33bif0LRxP6Zlps9CHvKQa0D4I8d6EwsoUo
ENTmHDhKBiwG05q+374BGXbekdOD+HlMAHN1qVcQVQiLuavzock7uescLmJTkNZV
l48sFXrJpEAtr6BlXSmQ4vMa9bKUPYkE9oxjmVpQ3j+5/XuCxc1PnviZDymW1g4Q
SsEoJZ3WhJrh0PmbtXIH5eKeiofUvGGC0cIrZ2Ppv+ogd2fzzTfuy6XHqFnGS+ix
eEpD6ZEjiSFq7EMzKM0Apenxgg4qtZ+fmSIbkEORPUvQUdm3p3Y73WyDPYNmEJX0
qSPJ6dwTpaEIrFe1xpOJx9RXnDEUWou1fdSqrv7GRE3yQprRynl6MsHltAdLH1PI
a5KzCXjv48Stij2y/2OVUbmHJ3/2mu7k3KWXaIbx4SoaQUUrH3ebKNRap7+Of3vw
eJBmy1JiysVVuUrvdrAsbHYGpSj3/7hUhm5R383yqp1//RKrZxH/iJ3Q2RDSVV/H
Rq+klpYT4A7Xkfgum7AD7CVnhu/Vz6bge3b1tCf1trAtpjCNcRYiX/qoU6x7Dgya
Q4QeqyhsExRzoHdU9a9EZd9McN40Bc3fFA6QMnITTyrIUvAVUV5PUvDEBjW/GcJU
yxeS6GIDwnEODvuIosOrN23VLVsuMSqdqDEgEX5WOQINDOAhjNg=
=JTAF
-END PGP SIGNATURE-

Bug#812929: Hi dear

[Jack]

Hello beautiful, Please can I get to know you? I will be happy if we can 
be close friends. Please say hi to me, it will be an honor.

An admirer.

Bug#892472: please refer to nftables

[Yaroslav Halchenko]

I guess I have missed up with inability to version recommended packages... 
Yeah, then we should provide as an alternative. Will do

On March 10, 2018 8:10:07 AM EST, Arturo Borrero Gonzalez  
wrote:
>On 10 March 2018 at 14:04, Yaroslav Halchenko 
>wrote:
>> There is no | for recommends afaik
>>
>
>Of course there is [0]. This is Debian :-)
>
>[0]
>https://www.debian.org/doc/debian-policy/#syntax-of-relationship-fields

-- 
Sent from a phone which beats iPhone.

Bug#892472: please refer to nftables

[Ervin Hegedüs]

Hi,

Debian Policy allows to use the | (pipe) symbol in case of some fields:

https://www.debian.org/doc/debian-policy/#syntax-of-relationship-fields



a.

On Sat, Mar 10, 2018 at 2:04 PM, Yaroslav Halchenko 
wrote:

> There is no | for recommends afaik
>
> On March 10, 2018 7:54:01 AM EST, Arturo Borrero Gonzalez <
> art...@debian.org> wrote:
> >On 9 March 2018 at 16:26, Yaroslav Halchenko  wrote:
> >> THANKS!  but...
> >>
> >> On Fri, 09 Mar 2018, Arturo Borrero Gonzalez wrote:
> >>
> >>> Also, no need to `Recommends: iptables`, since is installed by
> >default in every
> >>> Debian system.
> >>
> >> indeed it is (triple checked with debootstrap)  but it could also as
> >> easily be uninstalled.  And that is what I guess is done by docker
> >and
> >> may be other environments removing it (so docker images come without
> >> iptables preinstalled since it is of no sense for them).  So I still
> >> wonder if we should retain iptables in Recommends since it doesn't
> >hurt.
> >>
> >> Also, until nftables is the strongly encouraged default we should
> >> not place it into Recommends but keep it in Suggests to not install
> >it
> >> when people who already have the "default" iptables, apt-get install
> >> fail2ban (and thus its recommends)
> >>
> >> what do you think?
> >
> >then perhaps we could Recommends: nftables | iptables
>
> --
> Sent from a phone which beats iPhone.
>
>

Bug#892356: fslint: findutils on testing breaks fslint recursive search

[Pádraig Brady]

On 08/03/18 04:37, jEsuSdA wrote:
> Package: fslint
> Version: 2.44-2
> Severity: important
> 
> Dear Maintainer,
> 
> Upgrading findutils from stable to testing breaks the fslint-gui recursive
> function to search duplicate files.
> 
> I tried to downgrade fslint from 2.44 to 2.42 and the bug persists.
> 
> When downgrading findutils from 4.6.0+git+20170828-2 to 4.6.0+git+20161106-2,
> both fslint version still working again.

I just tried find from git (not a debian package)
and I don't see the issue.
Perhaps it's already fixed in find upstream?
Can you give more details of the breakage?

Note there was a fix to cater for a find change wrt permissions,
though that should have been available in 2.44
https://github.com/pixelb/fslint/commit/d68ee1c

thanks,
Pádraig.

Bug#844788: 4.16-rc3 fails to resume on MacBookPro10,1 -

[Pavel Machek]

Hi!

> > Ok, I've just tested linux-next, and it works ok for me on thinkpad
> > x60. (But that's probably rather different configuration from the
> > macbook).
> >
> > Unfortunately, I could not deduce anything useful from the
> > backtraces. Andrew, could you try v4.15 with KPTI disabled ?
> >
> > Thanks,
> > 
> > Pavel
> 
> This is 4.15 kernel with KPTI disabled:
> % grep PAGE_TABLE .config
> # CONFIG_PAGE_TABLE_ISOLATION is not set
> 
> As I expected it appears no more infomative to me.
> 
> What I really need is some clue as to what is supposed to be happening
> at this point.

You may want to add some printks to see where it hangs.

But maybe before that, you may want to test CPU hotplug, and make sure
s2ram works, etc...

Perhaps basic-pm-debugging.txt is good place to start?

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Bug#892472: please refer to nftables

[Arturo Borrero Gonzalez]

On 10 March 2018 at 14:04, Yaroslav Halchenko  wrote:
> There is no | for recommends afaik
>

Of course there is [0]. This is Debian :-)

[0] https://www.debian.org/doc/debian-policy/#syntax-of-relationship-fields

Bug#892472: please refer to nftables

[Yaroslav Halchenko]

There is no | for recommends afaik

On March 10, 2018 7:54:01 AM EST, Arturo Borrero Gonzalez  
wrote:
>On 9 March 2018 at 16:26, Yaroslav Halchenko  wrote:
>> THANKS!  but...
>>
>> On Fri, 09 Mar 2018, Arturo Borrero Gonzalez wrote:
>>
>>> Also, no need to `Recommends: iptables`, since is installed by
>default in every
>>> Debian system.
>>
>> indeed it is (triple checked with debootstrap)  but it could also as
>> easily be uninstalled.  And that is what I guess is done by docker
>and
>> may be other environments removing it (so docker images come without
>> iptables preinstalled since it is of no sense for them).  So I still
>> wonder if we should retain iptables in Recommends since it doesn't
>hurt.
>>
>> Also, until nftables is the strongly encouraged default we should
>> not place it into Recommends but keep it in Suggests to not install
>it
>> when people who already have the "default" iptables, apt-get install
>> fail2ban (and thus its recommends)
>>
>> what do you think?
>
>then perhaps we could Recommends: nftables | iptables

-- 
Sent from a phone which beats iPhone.

Bug#892545: --build=any,all and --build=binary are not entirely equivalent: the former does not generate a .changes whereas the latter does

[Guillem Jover]

Control: reassign -1 devscripts

[ Leaving context for the reassignment. ]

Hi!

On Sat, 2018-03-10 at 13:01:46 +0100, jean-christophe manciot wrote:
> Package: dpkg
> Version: 1.19.0.5

> binary is supposed to be an alias for any,all as described by the
> dpkg-buildpackage documentation
> .
> It is not completely the case.
> For instance:
> 1) *Building libixion 0.13.0-2 with --build=any,all*:
> debuild -i -I --no-sign *--build=any,all* -j1 -m'Jean-Christophe Manciot <
> manciot.jeanchristo...@gmail.com>
> 
> leads to an issue with a missing .changes file which is a fatal error for
> debuild:
> ...
> dpkg-deb: building package 'libixion-dev' in
> '../libixion-dev_0.13.0-2_amd64.deb'.
> dpkg-deb: building package 'libixion-0.13-0' in
> '../libixion-0.13-0_0.13.0-2_amd64.deb'.
> dpkg-deb: building package 'libixion-0.13-0-dbgsym' in
> '../libixion-0.13-0-dbgsym_0.13.0-2_amd64.deb'.
> dpkg-deb: building package 'python3-ixion' in
> '../python3-ixion_0.13.0-2_amd64.deb'.
> dpkg-deb: building package 'python3-ixion-dbgsym' in
> '../python3-ixion-dbgsym_0.13.0-2_amd64.deb'.
> dpkg-deb: building package 'libixion-doc' in
> '../libixion-doc_0.13.0-2_all.deb'.
>  dpkg-genbuildinfo --build=binary
>  dpkg-genchanges --build=binary -mJean-Christophe Manciot <
> manciot.jeanchristo...@gmail.com> >../libixion_0.13.0-2_amd64.changes
> dpkg-genchanges: info: binary-only upload (no source code included)
>  dpkg-source -i -I --after-build libixion-0.13.0-2
> dpkg-buildpackage: info: binary-only upload (no source included)
> debuild: fatal error at line 1039:
> can't open libixion_0.13.0-2_all.changes for reading: No such file or
> directory

As can be seen here, the error comes from debuild. Reassigning.

> 2) *Building the exact same sources libixion 0.13.0-2 with --build=binary*:
> debuild -i -I --no-sign *--build=binary* -j1 -m'Jean-Christophe Manciot <
> manciot.jeanchristo...@gmail.com>
> 
> leads to a correct build:
> ...
> dpkg-deb: building package 'libixion-dev' in
> '../libixion-dev_0.13.0-2_amd64.deb'.
> dpkg-deb: building package 'libixion-0.13-0' in
> '../libixion-0.13-0_0.13.0-2_amd64.deb'.
> dpkg-deb: building package 'libixion-0.13-0-dbgsym' in
> '../libixion-0.13-0-dbgsym_0.13.0-2_amd64.deb'.
> dpkg-deb: building package 'python3-ixion' in
> '../python3-ixion_0.13.0-2_amd64.deb'.
> dpkg-deb: building package 'python3-ixion-dbgsym' in
> '../python3-ixion-dbgsym_0.13.0-2_amd64.deb'.
> dpkg-deb: building package 'libixion-doc' in
> '../libixion-doc_0.13.0-2_all.deb'.
>  dpkg-genbuildinfo --build=binary
>  dpkg-genchanges --build=binary -mJean-Christophe Manciot <
> manciot.jeanchristo...@gmail.com> >../libixion_0.13.0-2_amd64.changes
> dpkg-genchanges: info: binary-only upload (no source code included)
>  dpkg-source -i -I --after-build libixion-0.13.0-2
> dpkg-buildpackage: info: binary-only upload (no source included)
> Now running lintian libixion_0.13.0-2_amd64.changes ...
> 
> This strange behaviour be applied to any other source package.
> The following full build logs are attached:
> 1) *-**-build=any,all: libixion_0.13.0-2_all.build*
> 2) *--build=binary: *libixion_0.13.0-2_amd64.build

Thanks,
Guillem

Bug#889302: Acknowledgement (ghostscript failes to render a ttf font embedded in pdf)

[Pelzi]

Any more information required?

Bug#854679: Clarify license for Beneath a Steel Sky

[Javier Serrano Polo]

El ds 10 de 03 de 2018 a les 05:38 +0800, James 'Ender' Brown va
escriure:
>  I'm not really sure what outcome you are looking for here...

DFSG #6 warrants use in any field of endeavor. The outcome is either
software can be sold, both modified and unmodified, or it is non-free.

> Yes. It was pretty obvious to all parties that the license was "weak,
> and there are certainly ways to break the spirit legally. By design.

I take your word that Revolution was aware. It would help if you could
state the same for Flight of the Amazon Queen, Lure of the Temptress,
and Drascula.

> Without allowing that freedom, we couldn't honor the spirit of the
> DFSG.

DFSG allows to sell individual software, but the spirit of DFSG does not
encourage to break the spirit of licenses.

>   *  "We've decided to trust you and permit re-distribute it
> as freeware"
>   *  ".. oh, but we don't want people to sell the game
> individually for $$$"

This is my concern. You were entrusted with finding a way to effectively
forbid the sale of the game.

> (very very paraphrased) "Looks good, ship it!"

Then you seemed to have found the solution. Section 3 is clear: you may
not charge a fee for the game itself.

> To be perfectly honest - Debian-legal provided more input on the
> wording than Revolution.

Let me make this clear: you did nothing wrong by writing a custom
license; you asked for help, which is sensible. I do not find related
discussions in debian-legal, so I cannot judge what they told you.

> This is the same sort of exception already implemented in other
> DFSG-approved licenses,

They suffer from the same problem; Artistic License 1.0 is not
DFSG-compliant.[1] Propagating the error was not the right way. Again,
you asked for help, so I do not blame you.

>  * Honor Revolutions request to limit individual resale
>  * Satisfy the "fields of endeavor" clause of the DFSG to encourage
> Linux Distros able to ship

These are incompatible, limiting individual resale breaks the "fields of
endeavor" clause. Anyway, Debian can ship games under the non-free
component.

Debian accepts your license because section 3 is ineffective by using
tricks. If you know it, then you deceive by writing a non-binding
preamble describing author's intent and a binding section that you
present as enforceable. Conflict arises when a Debian user believes
section 3 does not really apply, but author believes it does.

I thank engine developers and game creators for all your efforts. You
provide culture and some freedoms. Now I ask for the right to use for
any commercial purpose.

Although this report is to clarify a license, I would like to convince
authors that individual resale is not a problem. I defend "scammy"
behavior because of these reasons:

 1. Selling unmodified games encourages conveyance to users unaware
of these games.
 2. Selling free games, modified or not, propagates free software to
users that otherwise are presented with non-free software.
 3. Selling modified versions allows to reach more users. E.g.,
"Bajo un cielo de acero" could be easier to sell in South
America.
 4. It demonstrates that anyone can make a living out of free
software. This reason may not appeal to authors, but it does to
free software defenders.

Furthermore, while discouraging "scammy" behavior, you also discourage
other possibilities which are more likely to happen if the effort can be
paid. Examples are full internationalization, source restoration, and
game editor.

In short, either copyright holders effectively allow to charge a fee for
the game itself or they do not. According to your answer, they do.

--
[1] https://bugs.debian.org/854825


smime.p7s
Description: S/MIME cryptographic signature

Bug#888531: transition: ruby2.5 - binNMU round #5, and next steps

[Antonio Terceiro]

On Sat, Mar 10, 2018 at 04:26:03AM +0100, Andreas Beckmann wrote:
> On Fri, 9 Mar 2018 11:53:17 -0300 Antonio Terceiro 
> wrote:
> > ruby-pgplot: it's in contrib and has a dependency on a non-free package,
> > so it can't be built on buildds. I could do binary uploads myself now,
> > or ask someone who cares about it to do that, but then when it's time to
> > drop ruby2.3 I would need to do that again, and I would prefer to do it
> > just once. I just reported a serious bugs about this.
> 
> If you have the infrastructure ready to do contrib/non-free binNMUs (and
> some experience with it), this is not really much work. Uploaded a +b1
> binNMU. Please ping me once you need the ruby2.5-only binNMU.

I have neither the infra ready nor the experience, so thank you lot for
your help with this! :-)


signature.asc
Description: PGP signature

Bug#892472: please refer to nftables

[Arturo Borrero Gonzalez]

On 9 March 2018 at 16:26, Yaroslav Halchenko  wrote:
> THANKS!  but...
>
> On Fri, 09 Mar 2018, Arturo Borrero Gonzalez wrote:
>
>> Also, no need to `Recommends: iptables`, since is installed by default in 
>> every
>> Debian system.
>
> indeed it is (triple checked with debootstrap)  but it could also as
> easily be uninstalled.  And that is what I guess is done by docker and
> may be other environments removing it (so docker images come without
> iptables preinstalled since it is of no sense for them).  So I still
> wonder if we should retain iptables in Recommends since it doesn't hurt.
>
> Also, until nftables is the strongly encouraged default we should
> not place it into Recommends but keep it in Suggests to not install it
> when people who already have the "default" iptables, apt-get install
> fail2ban (and thus its recommends)
>
> what do you think?

then perhaps we could Recommends: nftables | iptables

Bug#892280: libcdk5: library package needs to be renamed for libncurses6 transition

[Herbert Fortes]

Em 09-03-2018 17:03, Sven Joachim escreveu:
> On 2018-03-09 15:18 -0300, Herbert Fortes wrote:
> 
>> Hi Sven Joachim,
>>
 My conclusion is that it is very risky to allow such combinations, and
 to rule them out I propose to change the package name of the cdk
 library, say to libcdk5a.  It would then have to build-depend on
 libncurses-dev (>= 6.1+20180210) to ensure that it is linked against
 libncurses6 and not libncurses5.  Of course this can only be uploaded
 to experimental for now, but should go to unstable when the ncurses
 transition starts there.
>>
>>
>> I am OK with changing the name. But libcdk5a does not say 
>> much about why the change.
>>
>> Since the package name will change because of SONAME of 
>> libncurses, I thought to follow the SONAME of the library.
> 
> Well, the SONAME of the cdk library does not change with my proposal.
> 
>> libcdk5-6
> 
> If you like that better than libcdk5a, choose it.  Or any other name,
> it's rather arbitrary anyway.
> 
>> But maybe this will cause misunderstanding. The change is
>> on version 6.1+20180210.
> 
> That's why the build-dependency on libncurses-dev (>= 6.1+20180210) is
> needed.
> 
> I am not sure we understand each other yet, but I'm happy to answer
> questions.
> 

Good! I am searching for a name. And talk about it could
help.

cdk library had problems before (about name), and I belive
the number "5" (cdk SONAME) was the choice to differ from the
other package. That's what I remember.

 - libcdk-java
 - libcdk-perl
 - libcdk5

The "5" was accepted because the SONAME does not change much.

The number "6" is from libncurses. If the two projects have
a strong link, it could be used. But seeing the two numbers,
which of them refers to what. I can put an explanation on 
debian/README.Debian file. But maybe the name will be changed
more than expected.

cdk stands for "Curses Development Kit". A C-based curses widget 
library. Curses/ncurses can be used.

Bug#789247: di-netboot-assistant: broken deb.d.o urls

[Andreas B. Mundt]

Hi,

On Fri, Mar 09, 2018 at 01:20:14PM -0800, Matt Taggart wrote:
> It looks like the deb.debian.org URLs in di-sources.list need to be updated
>
> E: Can't download 'stretch' for 'amd64' 
> (http://deb.debian.org/dists/stretch/main/installer-amd64/current/images/MD5SUMS).
>
> The URL should have a leading 'debian/' in the path, ie
>
> http://deb.debian.org/dists/stretch/main/installer...
>
> I don't know if this is just some mirrors or everywhere, but not having it
> resulted in an error for me (it resolved to cdn-aws.deb.debian.org)


Hm, the /debian/ should be inserted by the following in
'/etc/di-netboot-assistant/di-netboot-assistant.conf' [1]:

   #Download Mirror
   # The variable MIRROR_REGEXPS contain a list of space separated sed
   # regular expression, to rewrite di-sources.list URLs, to match your
   # prefered mirror.  For example:
   MIRROR_REGEXPS="s=://deb.debian.org/=://deb.debian.org/debian/="

I was already wondering why not to use the correct URL in
'di-sources.list', but kept that as it works fine for me.  Can you
check if you have the line in 'di-netboot-assistant.conf'?  Perhaps
it's there for historical reasons and we can/should remove it.

Best regards,

  Andi


[1] 
https://anonscm.debian.org/cgit/d-i/netboot-assistant.git/tree/config/di-netboot-assistant.conf

Bug#892547: [Feature Request] Add architecture dependent keywords to dpkg-buildpackage --build=

[jean-christophe manciot]

Package: dpkg
Version: 1.19.0.5

Right now, running dpkg-buildpackage --build=any builds all architecture
dependent packages, such as:
- amd64
- arm64
- m68k
- mips
- ...

My proposal offers a way to build a specific or list of specific
architecture dependent packages through:
--build=[arch1],[arch2],...[archn]

For instance:
- --build=amd64
- --build=amd64,arm64
...

It must be possible to combine those architecture keywords with other
existing build keywords such as:
- all
- source

For instance:
- --build=amd64,all
- --build=amd64,arm64,all
...
-- 
Jean-Christophe Manciot

Bug#892546: gosa: fails to decrypt openssl encrypted password

[Wolfgang Schweer]

Package: gosa
Version: 2.7.4+reloaded3-3
Severity: important

After a fresh Debian Edu main server installation, GOsa² is unable to 
connect to LDAP; this error message is shown:

Fatal error

Error while connecting to LDAP: Could not bind to 
cn=gosa-admin,ou=ldap-access,dc=skole,dc=skolelinux,dc=no 
(unauthenticated bind (DN with no password) disallowed, while operating 
on using LDAP server ldap://ldap.intern)

It seems that the decryption via GOSAKEY in gosa.secrets is broken.

To be able to test other things, I got LDAP access working w/o 
encryption after running:

(1) cp /etc/gosa/gosa.conf.orig /etc/gosa/gosa.conf
(2) cat /dev/null > /etc/gosa/gosa.secrets
(3) service apache2 reload

Please check.

There are a few other issues with this release (setup gosa from scratch 
is broken w/ Apache in use, gosa postinst fails w/ DE GNOME and Lighttpd 
in use, using Lighttpd instead of Apache is broken due to missing 
D on php-cgi).

I'll file separate bugs once time allows. 

Wolfgang


signature.asc
Description: PGP signature

Bug#892544: RFS: lmms/1.1.3-7.1 [RC, NMU]

[Boyuan Yang]

Package: sponsorship-requests
Severity: important

Dear mentors and lmms maintainers,

I have prepared an NMU for package lmms with some of its uploaders'
acknowledgment [1] and am looking for a sponsor to upload it into
DELAYED/7 queue. Feel free to tell me if I should wait any longer.

The NMU mainly fixes some FTBFS bugs, patches of which are taken from
original packaging repository of lmms.

 * Package name: lmms
   Version : 1.1.3-7.1
   Upstream Author : Lmms developers
 * URL :  lmms.io
 * License : GPL-2+
   Section : sound

  It builds those binary packages:

 calf-ladspa - Linux Multimedia Studio - Calf LADSPA plugins
 lmms  - Linux Multimedia Studio
 lmms-common - Linux Multimedia Studio - common files
 lmms-vst-server - Linux Multimedia Studio - VST server

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/l/lmms/lmms_1.1.3-7.1.dsc

  Git packaging repository:

https://anonscm.debian.org/cgit/debian-edu/pkg-team/lmms.git
(this is the team's repository, not updated for this upload because I
don't have write permission to it)

https://salsa.debian.org/hosiet-guest/lmms
(The temporary repo with commits of this upload)


  Changes since the last upload:

 lmms (1.1.3-7.1) unstable; urgency=high
 .
   * Non-maintainer upload.
 .
   [ Javier Serrano Polo ]
   * Fix build with Clang.
   * Fix build with GCC 7 (Closes: #853527).
 .
   [ Boyuan Yang ]
   * Remove Patrick Winnertz from uploaders list. (Closes: #867759)
 Thank you for your previous contributions!

--
Regards,
Boyuan Yang


[1] https://bugs.debian.org/853527

Bug#892504: [PATCH] nspr: Please add support for the RISC-V architecture

[Luke Kenneth Casson Leighton]

On Fri, Mar 9, 2018 at 8:31 PM, Karsten Merker  wrote:

> There is one thing that I am a bit unsure about, though, and that
> is Mozilla's use of WORD and DWORD in their size definitions as I
> haven't found any documentation about that.

hiya karsten,

ok so someone from mozilla is really going to have to double-check
this, or perhaps todd from activestate would know, or brendan eitch
may know (i don't have an active email address for him).

my understanding is that the mozilla team copied microsoft's DCE/RPC
implementation (which microsoft called MSRPC) and also wrote something
that was "inspired" by COM, called XPCOM: they screwed it up royally
by leaving out the absolutely critical critical part, which is
co-classes (a run-time version of c++ multiple inheritance:
unnnbelievably important, and because they didn't implement it, the
problems kept compounding, and eventually they ripped XPCOM out).

now, because the decision and "inspiration" was such a long time ago,
they cut over the *win32* code, and hence some of the win32
code-conventions.  WORD in win32 is *specifically* defined as 16-bit,
and DWORD *specifically* as 32-bit.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx?f=255=-2147217396

now, what i don't know is: did they keep those conventions during the
f***-up known as "ripping out XPCOM"?  the purpose of XPCOM was to
provide a stable standard / API for their own developers  and for 3rd
party developers.  they failed on both counts... so may no longer care
and may have changed the definition of WORD and DWORD... but this is a
bit of a stretch.

honestly, this is something that really needs an answer and
clarification from mozilla, or someone like todd (hi todd) who knows
more about it.

l.

Bug#888193: ruby-rmagick: FTBFS on ruby2.5: <FrozenError(<can't modify frozen Magick::Image>)>

[Hector Oron]

On Tue, Jan 23, 2018 at 08:38:43PM +, Chris West (Faux) wrote:
> Source: ruby-rmagick
> Version: 2.16.0-2
> Severity: important
> User: debian-r...@lists.debian.org
> Usertags: ruby2.5
> 
> Dear Maintainer,
> 
> This package fails to build against ruby2.5. Soon, there will
> be a transition to ruby2.5, and this package will FTBFS in sid.
> 
> There may be some details on the wiki about common problems:
> https://wiki.debian.org/Teams/Ruby/Ruby25Transition
> 
> Super confusing build log excerpt:
> 
> 
> Pending: (Failures listed here are expected and do not affect your suite's 
> status)
> 
>   1) Magick::Draw#marshal_dump #marshal_load marshals without an error
>  # this spec fails on some versions of ImageMagick
>  # ./spec/rmagick/draw_spec.rb:82
> 
> Finished in 0.27725 seconds (files took 0.12424 seconds to load)
> 36 examples, 0 failures, 1 pending
> 
> /usr/bin/ruby2.5 -w  "/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" 
> "test/test_all_basic.rb" -v
> /build/ruby-rmagick-2.16.0/test/Image2.rb:80: warning: assigned but unused 
> variable - img
> /build/ruby-rmagick-2.16.0/test/Image2.rb:305: warning: assigned but unused 
> variable - format
> /build/ruby-rmagick-2.16.0/test/Image2.rb:306: warning: assigned but unused 
> variable - size
> /build/ruby-rmagick-2.16.0/test/Image2.rb:307: warning: assigned but unused 
> variable - geometry
> /build/ruby-rmagick-2.16.0/test/Image2.rb:308: warning: assigned but unused 
> variable - image_class
> /build/ruby-rmagick-2.16.0/test/Image2.rb:401: warning: `-' after local 
> variable or literal is interpreted as binary operator
> /build/ruby-rmagick-2.16.0/test/Image2.rb:401: warning: even though it seems 
> like unary operator
> /build/ruby-rmagick-2.16.0/test/Image2.rb:536: warning: assigned but unused 
> variable - res
> /build/ruby-rmagick-2.16.0/test/Image2.rb:537: warning: assigned but unused 
> variable - res
> /build/ruby-rmagick-2.16.0/test/Image2.rb:538: warning: assigned but unused 
> variable - res
> /build/ruby-rmagick-2.16.0/test/Image2.rb:539: warning: assigned but unused 
> variable - res
> /build/ruby-rmagick-2.16.0/test/Image3.rb:683: warning: assigned but unused 
> variable - img
> /build/ruby-rmagick-2.16.0/test/ImageList1.rb:295: warning: assigned but 
> unused variable - cur
> /build/ruby-rmagick-2.16.0/test/ImageList1.rb:332: warning: assigned but 
> unused variable - res
> /build/ruby-rmagick-2.16.0/test/ImageList1.rb:333: warning: assigned but 
> unused variable - res
> /build/ruby-rmagick-2.16.0/test/Import_Export.rb:12: warning: assigned but 
> unused variable - res
> /build/ruby-rmagick-2.16.0/test/Magick.rb:312: warning: assigned but unused 
> variable - img
> 2.5.0
> String
> Loaded suite /usr/lib/ruby/vendor_ruby/rake/rake_test_loader
> Started
> Image1_UT: 
>   test_adaptive_blur: .: (0.002072)
>   test_adaptive_blur_channel: .: (0.002713)
>   test_adaptive_resize:   .: (0.000529)
>   test_adaptive_sharpen:  .: (0.000895)
>   test_adaptive_sharpen_channel:  .: (0.001748)
>   test_adaptive_threshold:.: (0.000333)
>   test_add_compose_mask:  .: (0.000255)
>   test_add_noise: .: (0.008137)
>   test_add_noise_channel: .: (0.007935)
>   test_affine_matrix: .: (0.001704)
>   test_alpha: F
> ===
> Failure: test_alpha(Image1_UT)
> /build/ruby-rmagick-2.16.0/test/Image1.rb:172:in `test_alpha'
>  169: assert_nothing_raised { @img.alpha Magick::ResetAlphaChannel }
>  170: assert_nothing_raised { @img.alpha Magick::SetAlphaChannel }
>  171: @img.freeze
>   => 172: assert_raise(FreezeError) { @img.alpha Magick::SetAlphaChannel }
>  173:   end
>  174: 
>  175:   def test_auto_gamma
> 
>  expected but was
> )>
> 
> diff:
> ? Ru   ntimeError 
> ? Froze  ()
> ===
> : (0.052752)
>   test_alpha_compat:  .: (0.000186)
>   test_auto_gamma:.: (0.012168)
>   test_auto_level:.: (0.000255)
>   test_auto_orient:   .: (0.000143)
>   test_bilevel_channel:   .: (0.000527)
>   test_black_threshold:   .: (0.000445)
> 
> 
> 
> ...
> 
> 
> 
> Finished in 42.696937665 seconds.
> --
> 385 tests, 232948 assertions, 15 failures, 0 errors, 0 pendings, 0 omissions, 
> 0 notifications
> 96.1039% passed
> 

Bug#888196: ruby-sexp-processor: FTBFS on ruby2.5: BOOM GOES THE STACK

[Hector Oron]

On Tue, Jan 23, 2018 at 08:43:02PM +, Chris West (Faux) wrote:
> Source: ruby-sexp-processor
> Version: 4.7.0-1
> Severity: important
> User: debian-r...@lists.debian.org
> Usertags: ruby2.5
> 
> Dear Maintainer,
> 
> This package fails to build against ruby2.5. Soon, there will
> be a transition to ruby2.5, and this package will FTBFS in sid.

Find patch attached that fixes the build.

Regards
diff -Nru ruby-sexp-processor-4.7.0/debian/changelog ruby-sexp-processor-4.7.0/debian/changelog
--- ruby-sexp-processor-4.7.0/debian/changelog	2016-07-21 06:11:59.0 +0200
+++ ruby-sexp-processor-4.7.0/debian/changelog	2018-03-10 11:59:35.0 +0100
@@ -1,3 +1,10 @@
+ruby-sexp-processor (4.7.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with Ruby2.5 (Closes: #888196)
+
+ -- Héctor Orón Martínez   Sat, 10 Mar 2018 11:59:35 +0100
+
 ruby-sexp-processor (4.7.0-1) unstable; urgency=medium
 
   * Imported Upstream version 4.7.0
diff -Nru ruby-sexp-processor-4.7.0/debian/patches/series ruby-sexp-processor-4.7.0/debian/patches/series
--- ruby-sexp-processor-4.7.0/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ ruby-sexp-processor-4.7.0/debian/patches/series	2018-03-10 11:59:21.0 +0100
@@ -0,0 +1 @@
+update-tests-to-use-sexps-not-raw-arrays.patch
diff -Nru ruby-sexp-processor-4.7.0/debian/patches/update-tests-to-use-sexps-not-raw-arrays.patch ruby-sexp-processor-4.7.0/debian/patches/update-tests-to-use-sexps-not-raw-arrays.patch
--- ruby-sexp-processor-4.7.0/debian/patches/update-tests-to-use-sexps-not-raw-arrays.patch	1970-01-01 01:00:00.0 +0100
+++ ruby-sexp-processor-4.7.0/debian/patches/update-tests-to-use-sexps-not-raw-arrays.patch	2018-03-10 11:59:35.0 +0100
@@ -0,0 +1,96 @@
+commit 05838e8658872f71a7c01cc66333ca76bea2a1bd
+Author: Ryan Davis 
+Date:   Sat May 20 02:35:03 2017 -0800
+
+Updated tests to use sexps, not raw arrays
+[git-p4: depot-paths = "//src/sexp_processor/dev/": change = 11326]
+
+Index: ruby-sexp-processor-4.7.0/test/test_sexp_processor.rb
+===
+--- ruby-sexp-processor-4.7.0.orig/test/test_sexp_processor.rb	2016-03-31 01:14:48.0 +0200
 ruby-sexp-processor-4.7.0/test/test_sexp_processor.rb	2018-03-10 12:03:31.687705413 +0100
+@@ -72,7 +72,7 @@
+   end
+ 
+   def rewrite_major_rewrite(exp)
+-exp[0] = :rewritable
++exp.sexp_type = :rewritable
+ exp
+   end
+ end
+@@ -98,13 +98,13 @@
+   end
+ 
+   def test_process_specific
+-a = [:specific, [:x, 1], [:y, 2], [:z, 3]]
+-expected = [:blah, [:x, 1], [:y, 2], [:z, 3]]
++a = s(:specific, s(:x, 1), s(:y, 2), s(:z, 3))
++expected = s(:blah, s(:x, 1), s(:y, 2), s(:z, 3))
+ assert_equal(expected, @processor.process(a))
+   end
+ 
+   def test_process_generic
+-a = [:blah, 1, 2, 3]
++a = s(:blah, 1, 2, 3)
+ expected = a.deep_clone
+ assert_equal(expected, @processor.process(a))
+   end
+@@ -131,7 +131,7 @@
+ @processor.unsupported << :strip
+ 
+ assert_raises UnsupportedNodeError do
+-  @processor.process([:whatever])
++  @processor.process(s(:whatever))
+ end
+   end
+ 
+@@ -139,14 +139,14 @@
+ @processor.strict = true
+ @processor.unsupported = [ :unsupported ]
+ assert_raises UnsupportedNodeError do
+-  @processor.process([:unsupported, 42])
++  @processor.process(s(:unsupported, 42))
+ end
+   end
+ 
+   def test_strict
+ @processor.strict = true
+ assert_raises UnknownNodeError do
+-  @processor.process([:blah, 1, 2, 3])
++  @processor.process(s(:blah, 1, 2, 3))
+ end
+   end
+   def test_strict=; skip; end #Handled
+@@ -154,12 +154,12 @@
+   def test_require_empty_false
+ @processor.require_empty = false
+ 
+-assert_equal s(:nonempty, 1, 2, 3), @processor.process([:nonempty, 1, 2, 3])
++assert_equal s(:nonempty, 1, 2, 3), @processor.process(s(:nonempty, 1, 2, 3))
+   end
+ 
+   def test_require_empty_true
+ assert_raises NotEmptyError do
+-  @processor.process([:nonempty, 1, 2, 3])
++  @processor.process(s(:nonempty, 1, 2, 3))
+ end
+   end
+   def test_require_empty=; skip; end # handled
+@@ -175,7 +175,7 @@
+   end
+ 
+   def test_rewrite_different_type
+-assert_equal(s(:rewritable, :b, :a),
++assert_equal(s(:major_rewrite, :a, :b),
+  @processor.rewrite(s(:major_rewrite, :a, :b)))
+   end
+ 
+@@ -282,7 +282,7 @@
+   @processor.process(s(:string, "string")) # should raise
+ end
+ 
+-@processor.process([:expected])# shouldn't raise
++@processor.process(s(:expected))# shouldn't raise
+   end
+   def test_expected=; skip; end # handled
+ 


signature.asc
Description: PGP signature

Bug#865013: network-manager-gnome: Consistent segfault when connecting to WPA2 network

[Roland Hieber]

Ohai,

On Fri, 9 Mar 2018 20:27:01 +0100 "BenWiederhake.GitHub" 
 wrote:

it seems like this is going to take a while to update.
Meanwhile, I sent in a patch [1], and it got "applied, with a small 
change" [2].


[1] https://bugzilla.gnome.org/show_bug.cgi?id=785674#c5
[2] 
https://git.gnome.org/browse/network-manager-applet/commit/?id=a37483c1a364ef3cc1cfa29e7ad51ca108d75674
I was just stumbling over these bugs on a newly installed system and it 
went away when I installed gnome-keyring. (Seems to be the same as 
#883965 from the looks of the backtrace.) So when the patch doesn't get 
applied in time, another possibility is to promote the "Recommends: 
gnome-keyring" in network-manager-gnome to a "Depends:".


 - Roland

Bug#892543: network-manager-gnome: nm-applet in xfce4 notification area is active but has no icon

[Arjen Balfoort]

Package: network-manager-gnome
Version: 1.8.10-2
Severity: important
Tags: a11y

Dear Maintainer,

   * What led up to the situation?
   Setting up Network Manager on Xfce4 (aarch64) resulted in having an 
invisible Network Manger applet in the notification area.
   On boot the icon flashes just before disappearing.
   Left and right actions do function properly (I let the notification area 
show its borders to make it easier to find the nm-applet).

   Other icons show correctly in the notification area.

   * What exactly did you do (or not do) that was effective (or ineffective)?
   I found these similar reports but I decided to report this issue because 
this issue was found on aarch64 and the other reports did not describe exactly 
this issue (nm-applet is functional but just not showing in the notification 
area):
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549541 > 4 Oct 2009, no 
solution
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572714 > 5 March 2010, no 
solution

   I tested with several styles and icon themes (Gnome, Breeze, etc.) and tried 
to change icon size for the notification area but the icon still did not show.
   Although the icon flashes on boot I still checked that nm-applet* icons 
existed in the icon themes (all svg).

   * What was the outcome of this action?
   There was no change.

   * What outcome did you expect instead?
   Network Manager applet would show the correct icon in the notification area.

   If you want I can provide an image for the RPi3.


-- System Information:
Distributor ID: SolydXK
Description:SolydX 10 ARM 64-bit
Release:10
Codename:   solydxk-10
Architecture: aarch64

Kernel: Linux 4.14.0-3-arm64 (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)
LSM: AppArmor: enabled

Versions of packages network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.6-2
ii  dbus-x11 [dbus-session-bus]   1.12.6-2
ii  dconf-gsettings-backend [gsettings-backend]   0.26.1-3
ii  libatk1.0-0   2.26.1-3
ii  libc6 2.27-1
ii  libcairo2 1.15.10-1
ii  libgdk-pixbuf2.0-02.36.11-1
ii  libglib2.0-0  2.54.3-2
ii  libgtk-3-03.22.28-1
ii  libjansson4   2.11-1
ii  libmm-glib0   1.6.8-2
ii  libnm01.10.4-1+b1
ii  libnma0   1.8.10-2
ii  libnotify40.7.7-3
ii  libpango-1.0-01.40.14-1
ii  libpangocairo-1.0-0   1.40.14-1
ii  libsecret-1-0 0.18.5-6
ii  libselinux1   2.7-2+b1
ii  network-manager   1.10.4-1+b1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-6

Versions of packages network-manager-gnome recommends:
ii  gnome-keyring3.20.1-2
ii  iso-codes3.79-1
pn  mobile-broadband-provider-info   
ii  xfce4-notifyd [notification-daemon]  0.4.1-1

Versions of packages network-manager-gnome suggests:
ii  network-manager-openconnect-gnome  1.2.4-1
ii  network-manager-openvpn-gnome  1.8.0-2
ii  network-manager-pptp-gnome 1.2.4-5+b1
ii  network-manager-vpnc-gnome 1.2.4-6

-- no debconf information

Bug#892532: libxerces2-java: Depends on GCJ which is going away

[Emmanuel Bourg]

Le 10/03/2018 à 10:42, Emilio Pozuelo Monfort a écrit :

> Yes, this is not listed in the cruft report, so needed a bug report and manual
> action. I have filed the bug, #892542.

Thank you for the help.

Emmanuel Bourg

Bug#892290: [Pkg-xfce-devel] Bug#892290: light-locker: at unlock, crash with: arguments to dbus_message_new_method_call() were incorrect

[Stuart Pook]

On 10/03/18 10:10, Yves-Alexis Perez wrote:

In any case, I really can't reproduce here, and you still didn't indicate what
you changed to make it crash reliably, so I'm afraid I can't help.


light-locker crashes at unlock every time I run it from the command line.

What happens when you run light-locker from the command line?

I agree that it should not normally be run from the command line.  I wanted to 
run lightlocker with different options and the running it from the command line 
was faster than logging on and off.

I tried running light-locker in gdb but that hung my session and I had to login 
on another console and kill gdb to recover.

I think that light-locker should either run correctly from the command line or 
announce that it cannot be used that way.

thanks, Stuart

:; light-locker --debug
[gs_debug_init] gs-debug.c:106 (00:05:14):   Debugging enabled
[main] light-locker.c:142 (00:05:14):initializing light-locker 1.8.0
[main] light-locker.c:164 (00:05:14):Platform:
gtk:3
systemd:yes
ConsoleKit: yes
UPower: yes
[main] light-locker.c:196 (00:05:14):Features:
lock-after-screensaver: yes
late-locking:   yes
lock-on-suspend:yes
lock-on-lid:yes
settings backend:   GSETTINGS
[main] light-locker.c:198 (00:05:14):lock after screensaver 3600
[main] light-locker.c:199 (00:05:14):late locking 0
[main] light-locker.c:200 (00:05:14):lock on suspend 1
[main] light-locker.c:201 (00:05:14):lock on lid 0
[main] light-locker.c:202 (00:05:14):idle hint 0
[query_session_id] gs-listener-dbus.c:2101 (00:05:14):   
org.freedesktop.login1.NoSessionForPID raised:
 PID 32104 does not belong to any known session


[init_session_id] gs-listener-dbus.c:2193 (00:05:14):Got session-id: (null)
[query_sd_session_id] gs-listener-dbus.c:2177 (00:05:14):Couldn't 
determine our own sd session id: No data available
[init_session_id] gs-listener-dbus.c:2198 (00:05:14):Got sd-session-id: 
(null)
[init_seat_path] gs-listener-dbus.c:2279 (00:05:14): Got seat: 
/org/freedesktop/DisplayManager/Seat0
[gs_listener_delay_suspend] gs-listener-dbus.c:449 (00:05:14):   Delay suspend
[gs_listener_x11_acquire] gs-listener-x11.c:172 (00:05:14):  ScreenSaver 
Registered
[listener_dbus_handle_system_message] gs-listener-dbus.c:1343 (00:05:14):   
 obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus 
method=NameAcquired destination=:1.1851
[listener_dbus_handle_session_message] gs-listener-dbus.c:1010 (00:14:00):  
 Received Lock request
[gs_grab_grab_root] gs-grab-x11.c:647 (00:14:00):Grabbing the root 
window
[gs_grab_get_keyboard] gs-grab-x11.c:153 (00:14:00): Grabbing keyboard 
widget=DF
[gs_grab_get_mouse] gs-grab-x11.c:213 (00:14:00):Grabbing mouse 
widget=DF
[gs_manager_create_windows_for_screen] gs-manager.c:548 (00:14:00):  
Creating 1 windows for screen 0
[gs_manager_create_window_for_monitor] gs-manager.c:324 (00:14:00):  
Creating window for monitor 0 [0,0] (1920x1200)
[update_geometry] gs-window-x11.c:197 (00:14:00):got geometry for 
monitor 0: x=0 y=0 w=1920 h=1200
[update_geometry] gs-window-x11.c:210 (00:14:00):using geometry for 
monitor 0: x=0 y=0 w=1920 h=1200
[update_geometry] gs-window-x11.c:197 (00:14:00):got geometry for 
monitor 0: x=0 y=0 w=1920 h=1200
[update_geometry] gs-window-x11.c:210 (00:14:00):using geometry for 
monitor 0: x=0 y=0 w=1920 h=1200
[gs_window_move_resize_window] gs-window-x11.c:243 (00:14:00):   Move and/or 
resize window on monitor 0: x=0 y=0 w=1920 h=1200
[update_geometry] gs-window-x11.c:197 (00:14:00):got geometry for 
monitor 0: x=0 y=0 w=1920 h=1200
[update_geometry] gs-window-x11.c:210 (00:14:00):using geometry for 
monitor 0: x=0 y=0 w=1920 h=1200
[gs_window_move_resize_window] gs-window-x11.c:243 (00:14:00):   Move and/or 
resize window on monitor 0: x=0 y=0 w=1920 h=1200
[update_geometry] gs-window-x11.c:197 (00:14:00):got geometry for 
monitor 0: x=0 y=0 w=1920 h=1200
[update_geometry] gs-window-x11.c:210 (00:14:00):using geometry for 
monitor 0: x=0 y=0 w=1920 h=1200
[gs_window_move_resize_window] gs-window-x11.c:243 (00:14:00):   Move and/or 
resize window on monitor 0: x=0 y=0 w=1920 h=1200
[gs_manager_timed_switch] gs-manager.c:445 (00:14:00):   Start switch to 
greeter timer
[gs_window_xevent] gs-window-x11.c:369 (00:14:00):   not raising our windows
[window_map_event_cb] gs-manager.c:233 (00:14:00):   Handling window 
map_event event
[gs_listener_resume_suspend] gs-listener-dbus.c:513 (00:14:00):  Resume 
suspend: fd=14
[manager_maybe_grab_window] gs-manager.c:204 (00:14:00): Moving grab to 
0x5587c72364d0
[gs_grab_move_keyboard] gs-grab-x11.c:450 (00:14:00):Moving keyboard grab 
from DF to 32C
[gs_grab_move_keyboard] gs-grab-x11.c:457 (00:14:00):*** doing X server grab
[gs_grab_release_keyboard] gs-grab-x11.c:279 (00:14:00): 

Bug#892074: uwsgi: FTBFS with ruby2.5 as default

[Emilio Pozuelo Monfort]

On Sat, 10 Mar 2018 10:36:56 +0100 Emilio Pozuelo Monfort  
wrote:
> On Sun, 4 Mar 2018 20:02:30 -0300 Antonio Terceiro  
> wrote:
> > Source: uwsgi
> > Version: 2.0.15-10.2
> > Severity: serious
> > Justification: fails to build from source
> > 
> > I am about to upload ruby-defaults to unstable, switching the default
> > Ruby to ruby2.5. With that in place, uwsgi fails to build from source
> > like this:
> > 
> > [...]
> >  CFLAGS="-g -O2 -fdebug-prefix-map=/<>=. 
> > -fstack-protector-strong -Wformat -Werror=format-security" 
> > CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,relro" python 
> > uwsgiconfig.py -v --plugin plugins/rack_ruby23 
> > debian/buildconf/uwsgi-plugin.ini rack_ruby23
> > using profile: debian/buildconf/uwsgi-plugin.ini
> > detected include path: ['/usr/lib/gcc/x86_64-linux-gnu/7/include', 
> > '/usr/local/include', '/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed', 
> > '/usr/include/x86_64-linux-gnu', '/usr/include']
> > *** uWSGI building and linking plugin plugins/rack_ruby23 ***
> > Error: unable to find directory 'plugins/rack_ruby23'
> > make: *** [debian/rules:450: debian/stamp-uwsgi-plugin-rack-ruby2.3] Error 1
> > dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
> > status 2
> 
> This may just need a `./debian/rules debian/control DEB_MAINTAINER_MODE=y` to
> update debian/control for ruby2.5. With that I get:
> 
> --- debian/control.orig   2018-03-10 10:32:37.349224886 +0100
> +++ debian/control2018-03-10 10:34:51.746009920 +0100
> @@ -5,7 +5,6 @@
>  Uploaders: Jonas Smedegaard 
>  Build-Depends-Indep: shellcheck
>  Build-Depends:
> - 2to3,
>   cdbs (>= 0.4.145),
>   python,
>   python3,
> @@ -693,7 +692,7 @@
>   This package provides Python 3 WSGI plugin for uWSGI
>   (linked with Python 3 runtime).
> 
> -Package: uwsgi-plugin-rack-ruby2.3
> +Package: uwsgi-plugin-rack-ruby2.5
>  Architecture: any
>  Depends: ${shlibs:Depends}, ${misc:Depends}, uwsgi-core (= ${binary:Version})
>  Description: Rack plugin for uWSGI (${uwsgi:RubyKind})

Indeed with that I get uwsgi to build, so this just needs a sourceful
upload with an updated debian/control.

uwsgi-plugin-rack-ruby2.5_2.0.15-10.2_amd64.deb
---
 new Debian package, version 2.0.
 size 70744 bytes: control archive=1828 bytes.
 805 bytes,19 lines  control  
 593 bytes, 7 lines  md5sums  
2226 bytes,80 lines   *  postinst #!/bin/sh
1440 bytes,57 lines   *  prerm#!/bin/sh
 Package: uwsgi-plugin-rack-ruby2.5
 Source: uwsgi
 Version: 2.0.15-10.2
 Architecture: amd64
 Maintainer: uWSGI packaging team 
 Installed-Size: 132
 Depends: libc6 (>= 2.14), libgmp10, libruby2.5 (>= 2.5.0~preview1), uwsgi-core 
(= 2.0.15-10.2)
 Section: httpd
 Priority: optional
 Homepage: http://projects.unbit.it/uwsgi/
 Description: Rack plugin for uWSGI (ruby2.5)
  uWSGI presents a complete stack for networked/clustered web applications,
  implementing message/object passing, caching, RPC and process management.
  It is designed to be fully modular. This means that different plugins can be
  used in order to add compatibility with tons of different technology on top of
  the same core.
  .
  This package provides Rack plugin for uWSGI
  (linked with ruby2.5 runtime).
drwxr-xr-x root/root 0 2018-02-09 21:35 ./
drwxr-xr-x root/root 0 2018-02-09 21:35 ./usr/
drwxr-xr-x root/root 0 2018-02-09 21:35 ./usr/bin/
drwxr-xr-x root/root 0 2018-02-09 21:35 ./usr/lib/
drwxr-xr-x root/root 0 2018-02-09 21:35 ./usr/lib/uwsgi/
drwxr-xr-x root/root 0 2018-02-09 21:35 ./usr/lib/uwsgi/plugins/
-rw-r--r-- root/root 64792 2018-02-09 21:35 
./usr/lib/uwsgi/plugins/rack_ruby25_plugin.so
drwxr-xr-x root/root 0 2018-02-09 21:35 ./usr/share/
drwxr-xr-x root/root 0 2018-02-09 21:35 ./usr/share/doc/
drwxr-xr-x root/root 0 2018-02-09 21:35 
./usr/share/doc/uwsgi-plugin-rack-ruby2.5/
-rw-r--r-- root/root   749 2017-03-31 00:11 
./usr/share/doc/uwsgi-plugin-rack-ruby2.5/CONTRIBUTORS
-rw-r--r-- root/root   148 2017-03-31 00:11 
./usr/share/doc/uwsgi-plugin-rack-ruby2.5/README
-rw-r--r-- root/root 11730 2018-02-09 21:35 
./usr/share/doc/uwsgi-plugin-rack-ruby2.5/buildinfo_amd64.gz
-rw-r--r-- root/root 20055 2018-02-09 21:35 
./usr/share/doc/uwsgi-plugin-rack-ruby2.5/changelog.Debian.gz
-rw-r--r-- root/root  2090 2018-02-09 21:35 
./usr/share/doc/uwsgi-plugin-rack-ruby2.5/copyright
drwxr-xr-x root/root 0 2018-02-09 21:35 ./usr/share/man/
drwxr-xr-x root/root 0 2018-02-09 21:35 ./usr/share/man/man1/
-rw-r--r-- root/root 12938 2018-02-09 21:35 
./usr/share/man/man1/uwsgi_rack_ruby25.1.gz
lrwxrwxrwx root/root 0 2018-02-09 21:35 ./usr/bin/uwsgi_rack_ruby25 -> 
uwsgi-core

Cheers,
Emilio

Bug#890606: src:kopete: FTBFS against libmediastreamer 2.16

[Pino Toscano]

Hi,

(not sure why the bug email did not reach the team ML...)

In data venerdì 16 febbraio 2018 17:28:12 CET, Bernhard Schmidt ha scritto:
> src:kopete in unstable FTBFSs against libmediastreamer-dev 1:2.16.1-2
> currently in experimental.
> [...]
> https://bugs.kde.org/show_bug.cgi?id=368340 is an upstream bug about this
> error which has not seen activity for about a year.

In comment 8 of that bug, upstream (Pali Rohár) basically asked for help
about the changed mediastreamer API.  Since nobody followed up on this,
that explains why the bug has not been fixed so far.

> We would like to do this transition ASAP and kopete currently is the only
> hard blocker.

If so, my suggestion is to help kopete upstream regarding the changed
mediastreamer API.  Otherwise, with no documentation available, kopete
upstream is basically stalled on this issue.

Thanks,
-- 
Pino Toscano

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

Bug#890947: lightdm-gtk-greeter-settings: l-g-g-settings truncate /etc/lightdm/lightdm-gtk-greeter.conf

[Yves-Alexis Perez]

On Sat, 2018-03-10 at 01:23 -0800, James Lu wrote:
> 
> It might be helpful to include the contents of
> /etc/lightdm/lightdm-gtk-greeter.conf.d/*, as well as the
> lightdm-gtk-greeter.conf before and after attempting to modify it using
> l-g-g-s.

/etc/lightdm/lightdm-gtk-greeter.conf is all-commented except [greeter]
/etc/lightdm/lightdm-gtk-greeter.conf.d/10_user.conf has:

[greeter]
hide-user-image=true
theme-name=Adwaita
font-name=Sans 8
clock-format = %a %d %b, %R
> 
> Toggling the "Redefine indicators" option seems to work fine here with a
> single conf file and with a split setup: I tested briefly by copying my
> background entry from lightdm-gtk-greeter.conf into a new file under
> /etc/lightdm/lightdm-gtk-greeter.conf.d/. That said, I haven't tried the
> external indicators feature as I'm honestly not sure how to set it up -
> I don't know if there even are relevant indicator libs on my system.

Here I don't even touch what's inside the indicators box, only the toggle. I/m
running l-g-g-settings through pkexec, in case that matters.

Regards,
-- 
Yves-Alexis

Bug#784524: [Pkg-kde-extras] Bug#784524: [robojournal] Qt4's WebKit removal

[Pino Toscano]

Hi,

In data sabato 10 marzo 2018 10:21:16 CET, Boyuan Yang ha scritto:
> We really want to remove Qt4 Webkit from the archive in Debian Buster.

"we" who? I don't see you as part of the Qt/KDE team, nor I don't see
any email from you about this on the team mailing list.

> [1] As a result, I'm wondering if we could remove package robojournal
> from Debian Archive soon.

Because of this bug, robojournal is already out of testing, so a
QtWebKit removal is not blocked by this bug.

> Please feel free to tell me about your idea torwards this package.

Unless Ritesh says otherwise, leave this package as it is.
Also, for what it matters, please leave also QtWebKit as it is, since
it is under the Qt/KDE team wing, and removing it requires more work
than occasional people (like this email) think about.

Thanks,
-- 
Pino Toscano

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

Bug#892074: uwsgi: FTBFS with ruby2.5 as default

[Emilio Pozuelo Monfort]

On Sun, 4 Mar 2018 20:02:30 -0300 Antonio Terceiro  wrote:
> Source: uwsgi
> Version: 2.0.15-10.2
> Severity: serious
> Justification: fails to build from source
> 
> I am about to upload ruby-defaults to unstable, switching the default
> Ruby to ruby2.5. With that in place, uwsgi fails to build from source
> like this:
> 
> [...]
>  CFLAGS="-g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security" 
> CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,relro" python 
> uwsgiconfig.py -v --plugin plugins/rack_ruby23 
> debian/buildconf/uwsgi-plugin.ini rack_ruby23
> using profile: debian/buildconf/uwsgi-plugin.ini
> detected include path: ['/usr/lib/gcc/x86_64-linux-gnu/7/include', 
> '/usr/local/include', '/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed', 
> '/usr/include/x86_64-linux-gnu', '/usr/include']
> *** uWSGI building and linking plugin plugins/rack_ruby23 ***
> Error: unable to find directory 'plugins/rack_ruby23'
> make: *** [debian/rules:450: debian/stamp-uwsgi-plugin-rack-ruby2.3] Error 1
> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
> status 2

This may just need a `./debian/rules debian/control DEB_MAINTAINER_MODE=y` to
update debian/control for ruby2.5. With that I get:

--- debian/control.orig 2018-03-10 10:32:37.349224886 +0100
+++ debian/control  2018-03-10 10:34:51.746009920 +0100
@@ -5,7 +5,6 @@
 Uploaders: Jonas Smedegaard 
 Build-Depends-Indep: shellcheck
 Build-Depends:
- 2to3,
  cdbs (>= 0.4.145),
  python,
  python3,
@@ -693,7 +692,7 @@
  This package provides Python 3 WSGI plugin for uWSGI
  (linked with Python 3 runtime).

-Package: uwsgi-plugin-rack-ruby2.3
+Package: uwsgi-plugin-rack-ruby2.5
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, uwsgi-core (= ${binary:Version})
 Description: Rack plugin for uWSGI (${uwsgi:RubyKind})

Cheers,
Emilio

Bug#892542: RM: libxerces2-java-gcj -- NBS; GCJ is being dropped

[Emilio Pozuelo Monfort]

Package: ftp.debian.org
Severity: normal

Hi,

libxerces2-java-gcj was removed a while ago, but it being the only arch:any
package from src:libxerces2-java has caused the autoremovals to not notice
it.

Thus please remove this binary so libxerces2-java can migrate to testing.

Thanks,
Emilio

Bug#892505: transition: openexr

[Emilio Pozuelo Monfort]

On 09/03/18 21:43, Matteo F. Vescovi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-CC: pkg-phototools-de...@lists.alioth.debian.org, ma...@debian.org
> 
> Dear Release Team,
> 
> I'm filing this bug for a new transition of openexr package.
> 
> On March 8, 2018 a fixed testing-purpose package (2.2.1-2) has been
> uploaded to experimental.
> 
> So, following the auto-openexr checklist[1], here is the list of source
> packages depending on openexr and the results of the test builds
> (honoring the dependency levels as reported in the checklist, as
> relevant for the correct order):
> 
> ### Dependency level 2 ###
>  * aqsis_1.8.2-8 => OK
>  * darktable_2.4.0-1 => OK
>  * exactimage_1.0.1-1 => OK
>  * freeimage_3.17.0+ds1-5 => OK
>  * gegl_0.3.28-2 => OK
>  * imagemagick_8:6.9.9.34+dfsg-3 => OK
>  * kde-runtime_4:17.08.3-1 => OK
>  * kimageformats_5.42.0-2 => OK
>  * kio-extras_4:17.08.3-2 => OK
>  * krita_1:3.3.3+dfsg-1 => OK
>  * libvigraimpex_1.10.0+git20160211.167be93+dfsg-5 => OK
>  * luminance-hdr_2.5.1+dfsg-3 => OK
>  * mia_2.4.6-2 => OK
>  * nvidia-texture-tools_2.0.8-1+dfsg-8.1 => OK
>  * opencv_3.2.0+dfsg-4 => OK
>  * openexr-viewers_1.0.1-6 => OK
>  * openvdb_5.0.0-1 => OK
>  * povray_1:3.7.0.4-2 => OK
> 
> ### Dependency level 3 ###
>  * gmic_1.7.9+zart-4 => FTBFS (not openexr related)
>  * gst-plugins-bad1.0_1.8.3-1 => FTBFS (not openexr related)

unstable has gst-plugins-bad1.0 1.12.4-2. Did you really check with 1.8.3-1? Can
you also check the other packages that failed to build (gmic and vips)?

Cheers,
Emilio

>  * hugin_2018.0.0+dfsg-1 => OK
>  * k3d_0.8.0.6-6 => OK
>  * openimageio_1.8.9~dfsg0-1 => OK
>  * pfstools_2.1.0-3 => OK
>  * synfig_1.0.2-1 => OK
>  * vips_8.4.5-1 => FTBFS (not openexr related)
> 
> ### Dependency level 4 ###
>   blender_2.79+dfsg0-3 => OK
> 
> Thanks for your time and patience.
> 
> mfv

Bug#888909: stretch-pu: package nvidia-graphics-drivers/384.111-4~deb9u1

[Adam D. Barratt]

Control: reopen -1

On Sat, 2018-03-03 at 21:27 +, Adam D. Barratt wrote:
> On Sat, 2018-03-03 at 21:36 +0100, Andreas Beckmann wrote:
> > On 2018-03-03 11:51, Adam D. Barratt wrote:
> > > Uploaded and flagged for acceptance.

Actually, it wasn't. I can only assume that I got confused while
processing the pile of nvidia uploads. :-(

> > Thanks. Please don't forget to decruft stretch during the point
> > release
> > to remove the old packages that have been renamed and are no longer
> > built.
> > 
> 
> ftp-master's point release script usually includes a decruft run near
> the end, so that shouldn't be a problem.

In fact, that's why I spotted the problem.

The new packages mean it ended up in NEW and no-one noticed; apologies
for the confusion / inconvenience.

Regards,

Adam

Bug#890947: lightdm-gtk-greeter-settings: l-g-g-settings truncate /etc/lightdm/lightdm-gtk-greeter.conf

[James Lu]

Hi Yves-Alexis,

It might be helpful to include the contents of
/etc/lightdm/lightdm-gtk-greeter.conf.d/*, as well as the
lightdm-gtk-greeter.conf before and after attempting to modify it using
l-g-g-s.

Toggling the "Redefine indicators" option seems to work fine here with a
single conf file and with a split setup: I tested briefly by copying my
background entry from lightdm-gtk-greeter.conf into a new file under
/etc/lightdm/lightdm-gtk-greeter.conf.d/. That said, I haven't tried the
external indicators feature as I'm honestly not sure how to set it up -
I don't know if there even are relevant indicator libs on my system.

Best,
James



signature.asc
Description: OpenPGP digital signature

Bug#784524: [robojournal] Qt4's WebKit removal

[Boyuan Yang]

Dear robojournal maintainers,

I have been examining the status of packages using Qt4 Webkit in
Debian. It seems that package robojournal has low popcon, dead
upstream and no packaing activity in the last 3 years.

We really want to remove Qt4 Webkit from the archive in Debian Buster.
[1] As a result, I'm wondering if we could remove package robojournal
from Debian Archive soon.

Please feel free to tell me about your idea torwards this package. I
will wait for two or three weeks before trying to file a RM bug to FTP
Masters.

--
Regards,
Boyuan Yang

[1] https://wiki.debian.org/Qt4WebKitRemoval

Bug#892360: Bug #892360 in systemd marked as pending

[Eric Valette]

On Sat, 10 Mar 2018 00:14:40 + aga...@siduction.org wrote:


Bug #892360 in systemd reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:


Confirmed fixed on my two machines. Thanks for the support.

--eric

Bug#892072: weechat: build against ruby2.5

[Emilio Pozuelo Monfort]

On Tue, 6 Mar 2018 13:58:02 +0100 =?utf-8?Q?S=C3=A9bastien?= Helleu
 wrote:
> On Sun, Mar 04, 2018 at 07:57:11PM -0300, Antonio Terceiro wrote:
> > Source: weechat
> > Version: 1.9.1-1
> > Severity: serious
> > Justification: will FTBFS soon
> > Tags: patch
> > 
> > Hi,
> > 
> > I am about to upload ruby-defaults to unstable, switching the default
> > Ruby to ruby2.5, and ruby2.3 support will be removed right after that.
> > Please consider applying the attached patch, obtained from upstream.
> > 
> > Even better: please work with upstream to be able to build against the
> > default ruby, instead of hardcoding a list of ruby versions. Otherwise,
> > every time there is a Ruby transition, weechat will be a blocker.
> > Hunting down these issues is quite time consuming.
> > 
> 
> Hi Antonio,
> 
> I agree with the need to detect Ruby and other libraries in WeeChat without
> hardcoding a list of supported versions in the CMake and configure files.
> 
> I opened an issue, so this will be implemented as soon as possible:
> 
>   https://github.com/weechat/weechat/issues/1156

Great, thanks! In the meantime, could you upload the patch Antonio attached, so
that this doesn't block the transition?

Thanks,
Emilio

Bug#892532: libxerces2-java: Depends on GCJ which is going away

[Emmanuel Bourg]

Le 10/03/2018 à 09:58, po...@debian.org a écrit :

> libxerces2-java depends or build-depends on GCJ. GCJ has been dropped
> upstream since GCC 7, so we are dropping it from Debian. Thus please
> either drop support for GCJ if you are just building an alternative
> package with GCJ support (e.g. ant-gcj, ecj-gcj) or switch to
> default-jdk / default-jre as appropriate.

libxerces2-java no longer depends on GCJ in unstable, but the package
didn't transition to testing. I guess some help from a FTP master is
needed here.

Bug#892290: [Pkg-xfce-devel] Bug#892290: light-locker: at unlock, crash with: arguments to dbus_message_new_method_call() were incorrect

[Yves-Alexis Perez]

On Fri, 2018-03-09 at 22:36 +0100, Stuart Pook wrote:
> > > Light-locker crashes when I unlock my session. This means that my
> > > session
> > > is not locked the next time it should be,
> 
> hi  Yves-Alexis
> 
> > there was no recent update to light-locker. What did change on your
> > system?
> > Unlock works fine here so I'll need more information in order to
> > reproduce.
> 
> I guess I don't normally run it from the command line.

I don't think it's supposed to be run that way anyway (see the message about
the session, for example). I think it'd be best to let it run from desktop
startup, then attach with gdb.

It might be worth looking at the backtrace.

In any case, I really can't reproduce here, and you still didn't indicate what
you changed to make it crash reliably, so I'm afraid I can't help.

Regards,
-- 
Yves-Alexis

Bug#892373: [INFO] Bug#892373: proftpd-mod-fsync FTBFS with proftpd 1.3.6-1

[Francesco Paolo Lovergine]

Nave a look onto  Castaglia's github repo

Il 09 marzo 2018 23:11:56 CET, "Hilmar Preuße"  ha scritto:
>On 09.03.2018 16:28, Francesco P. Lovergine wrote:
>
>Hi,
>
>> Here the fix is trivial as suggested. Even in this case it is better 
>> upgrading to current upstream version.
>> 
>Where did you get a later version from? According to
>http://www.castaglia.org/proftpd/ the 0.2 is the latest version.
>
>H.
>-- 
>#206401 http://counter.li.org

-- 
Francesco P. Lovergine

Bug#892063: cpputest: FTBFS on hppa - __canonicalize_funcptr_for_compare (0xdeadbeef)

[Raphael Hertzog]

Hi,

On Fri, 09 Mar 2018, John David Anglin wrote:
> Yes.  Function pointers on hppa differ from all other architectures. 
[...]
> I applied a patch to gcc-8 to fix the "0xdeadbeef" problem.  It adds a
> check to ensure that the pointer points to read accessible memory.  It
> also checks that the address in the descriptor is read accessible.  Will
> backport to 7 and 6 when I get a chance.

Given your work on the compiler, does it really make sense to try to fix
something in cpputest?

The only clean fix I can think of is to modify the tests to use a real
function pointer instead of 0xdeadbeef. I don't think that an architecture
specific work-around or fix is desirable here.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#888955: open-vm-tools.service 10.2.0 does not start on boot on jessie/stretch/etc

[Bernd Zeimetz]

> Why does it need to run before cloud-init i.e. why does cloud-init need
> open-vm-tools?

because cloud-init pulls the configuration it should apply from vmtoolsd.

But that is not the bug here and nothing that needs to be changed.

If you would finally read
https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1750780

you would learn that there is a race condition that when PrivateTmp is
being used the necessary mounts are not always available.

The workaround for now is After=local-fs.target - which will result in a
dependency loop at some point, which is discussed in

https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1750780/comments/11

basically all information is in that bug. Please read it.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#892488: pcre2: FTBFS on mips* - test failures

[Matthew Vernon]

Hi,

On 10/03/18 00:51, Jonathan Nieder wrote:


Thanks.  This FTBFS bug is still serious, but even better, you can
close it.


I was going to keep this bug open for the underlying JIT-on-mips issue :)


I don't see the new version at
https://salsa.debian.org/debian/pcre2/commits/master. Is it on a
different branch?


It should be there now.

Regards,

Matthew

Bug#873758: stretch-pu: package memcached/1.4.33-1

[Salvatore Bonaccorso]

Hi Guillaume,

On Thu, Mar 08, 2018 at 02:10:10PM +0100, Guillaume Delacour wrote:
> Hi,
> 
> I'm sorry i haven't find a sponsor to upload the security fix for
> CVE-2017-9951 yet.  There is another fix that need to be uploaded to
> security: CVE-2018-1000115:

I'm sorry to hear that was blocked on not finding a sponsor. If you
get an ack from SRM for the updated change and you cannot do the
upload via your regular sponsors please ping me directly.

It's now to late for 9.4 but preferably we should have it updated for
the next point release.

Regards,
Salvatore

Bug#892527: Installation of Debian Buster was successfully at AMD Desktop PC

[Bernhard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: installation-reports

Boot method: USB-Drive
Image version: Self-made installer image with Daily build of Debian buster
Date: 2018-03-10

Machine: Self-made Desktop PC
Processor: AMD A10-5700 APU with Radeon(tm) HD Graphics
Memory: 4GB
Partitions: 

> DateisystemTyp  1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
> udev   devtmpfs   1592660   0   15926600% /dev
> tmpfs  tmpfs   32127648443164322% /run
> /dev/sda1  ext4 111556948 4620032 1012270925% /
> tmpfs  tmpfs  1606372   28156   15782162% /dev/shm
> tmpfs  tmpfs 5120   4  51161% /run/lock
> tmpfs  tmpfs  1606372   0   16063720% /sys/fs/cgroup
> tmpfs  tmpfs   321272  763211961% /run/user/1000

Output of lspci -knn (or lspci -nn):

> 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
> (Models 10h-1fh) Processor Root Complex [1022:1410]
>   Subsystem: ASUSTeK Computer Inc. Family 15h (Models 10h-1fh) Processor 
> Root Complex [1043:8526]
> 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
> [AMD/ATI] Trinity [Radeon HD 7660D] [1002:9901]
>   Subsystem: ASUSTeK Computer Inc. Trinity [Radeon HD 7660D] [1043:8526]
>   Kernel driver in use: radeon
>   Kernel modules: radeon
> 00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Trinity 
> HDMI Audio Controller [1002:9902]
>   Subsystem: ASUSTeK Computer Inc. Trinity HDMI Audio Controller 
> [1043:8526]
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
> 00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> XHCI Controller [1022:7812] (rev 03)
>   Subsystem: ASUSTeK Computer Inc. FCH USB XHCI Controller [1043:8527]
>   Kernel driver in use: xhci_hcd
>   Kernel modules: xhci_pci
> 00:10.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> XHCI Controller [1022:7812] (rev 03)
>   Subsystem: ASUSTeK Computer Inc. FCH USB XHCI Controller [1043:8527]
>   Kernel driver in use: xhci_hcd
>   Kernel modules: xhci_pci
> 00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA 
> Controller [AHCI mode] [1022:7801] (rev 40)
>   Subsystem: ASUSTeK Computer Inc. FCH SATA Controller [AHCI mode] 
> [1043:8527]
>   Kernel driver in use: ahci
>   Kernel modules: ahci
> 00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> OHCI Controller [1022:7807] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB OHCI Controller [1043:8527]
>   Kernel driver in use: ohci-pci
>   Kernel modules: ohci_pci
> 00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> EHCI Controller [1022:7808] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB EHCI Controller [1043:8527]
>   Kernel driver in use: ehci-pci
>   Kernel modules: ehci_pci
> 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> OHCI Controller [1022:7807] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB OHCI Controller [1043:8527]
>   Kernel driver in use: ohci-pci
>   Kernel modules: ohci_pci
> 00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> EHCI Controller [1022:7808] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB EHCI Controller [1043:8527]
>   Kernel driver in use: ehci-pci
>   Kernel modules: ehci_pci
> 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
> [1022:780b] (rev 14)
>   Subsystem: ASUSTeK Computer Inc. FCH SMBus Controller [1043:8527]
>   Kernel driver in use: piix4_smbus
>   Kernel modules: i2c_piix4, sp5100_tco
> 00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] FCH Azalia 
> Controller [1022:780d] (rev 01)
>   Subsystem: ASUSTeK Computer Inc. F2A85-M Series [1043:8444]
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
> 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge 
> [1022:780e] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH LPC Bridge [1043:8527]
> 00:14.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] FCH PCI Bridge 
> [1022:780f] (rev 40)
> 00:15.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Hudson PCI to 
> PCI bridge (PCIE port 0) [1022:43a0]
>   Kernel driver in use: pcieport
>   Kernel modules: shpchp
> 00:15.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Hudson PCI to 
> PCI bridge (PCIE port 1) [1022:43a1]
>   Kernel driver in use: pcieport
>   Kernel modules: shpchp
> 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
> (Models 10h-1fh) Processor Function 0 [1022:1400]
> 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
> (Models 10h-1fh) Processor Function 1 [1022:1401]

Bug#875336: FTBFS with Java 9: _ as identifier

[Emmanuel Bourg]

Le 10/03/2018 à 08:16, 殷啟聰 | Kai-Chung Yan a écrit :
> I recently updated the package to 3.5.0 just to find out the current Groovy 
> (2.4.8) does not support Java 9 [1]. Groovy was used by the bootstrapping 
> script. Setting source & target to Java 8 doesn't solve the problem either.

I'll upgrade Groovy, we'll see if that helps.

Bug#892526: gpac: CVE-2018-7752: Stack buffer overflow in av_parsers.c

[Salvatore Bonaccorso]

Source: gpac
Version: 0.5.2-426-gc5ad4e4+dfsg5-3
Severity: important
Tags: patch security upstream
Forwarded: https://github.com/gpac/gpac/issues/997

Hi,

the following vulnerability was published for gpac.

CVE-2018-7752[0]:
| GPAC through 0.7.1 has a Buffer Overflow in the gf_media_avc_read_sps
| function in media_tools/av_parsers.c, a different vulnerability than
| CVE-2018-1000100.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-7752
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7752
[1] https://github.com/gpac/gpac/issues/997
[2] https://github.com/gpac/gpac/commit/90dc7f853d31b0a4e9441cba97feccf36d8b69a4

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore