Bug#898398: Fails with "incompatible character encodings: ASCII-8BIT and UTF-8"

[Stéphane Glondu]

Package: apt-listbugs
Version: 0.1.24
Severity: important

Dear Maintainer,

Since a few days, the cron.daily job of apt-listbugs fails with the following 
message:

/etc/cron.daily/apt-listbugs:
/usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:701:in `block (4 levels) in 
display_bugs': incompatible character encodings: ASCII-8BIT and UTF-8 
(Encoding::CompatibilityError)
from /usr/lib/ruby/vendor_ruby/aptlistbugs/debian/bug.rb:68:in `block 
in each_by_category'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/debian/bug.rb:67:in `each'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/debian/bug.rb:67:in 
`each_by_category'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:680:in `block (3 
levels) in display_bugs'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:676:in `each'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:676:in `block (2 
levels) in display_bugs'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:675:in `each'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:675:in `block in 
display_bugs'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:674:in `each'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:674:in 
`display_bugs'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:402:in `view'
from /usr/sbin/apt-listbugs:618:in `'

Cheers,

-- 
Stéphane

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

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

Versions of packages apt-listbugs depends on:
ii  apt 1.6.1
ii  ruby1:2.5.1
ii  ruby-debian 0.3.9+b8
ii  ruby-gettext3.2.9-1
ii  ruby-soap4r 2.0.5-4
ii  ruby-unicode0.4.4-2+b9
ii  ruby-xmlparser  0.7.3-3+b2

Versions of packages apt-listbugs recommends:
pn  ruby-httpclient  

Versions of packages apt-listbugs suggests:
ii  chromium [www-browser] 62.0.3202.89-1
ii  firefox-esr [www-browser]  52.7.3esr-1
ii  reportbug  7.1.10
ii  sensible-utils 0.0.12
ii  w3m [www-browser]  0.5.3-36+b1

-- no debconf information

Bug#898394: general: Network (Ethernet) icon not updating on connection

[Geert Stappers]

Control: tag -1 moreinfo

On Fri, May 11, 2018 at 09:53:43AM +0530, Keyikedalube Ndang wrote:
} on my notebook I'm noticing that
> the network icon does not update even the connection is successful. It usually
> keeps displaying that connecting status; the icon is grayed out.
> 
> Rarely, the icon is displayed correctly i.e., it's no longer grayed but shows
> white icon (successful connection)
> 

Please make a partial screenshot that contains the icon, white or grey.

Attached is an example.
It is the upper-right corner of a Debian XFCE installation.


Cheers
Geert Stappers

Bug#896684: fontconfig-config: Fontconfig error: Cannot load config file from /etc/fonts/fonts.conf, due to many errors

[Damien Couroussé]

Package: fontconfig-config
Version: 2.13.0-4
Followup-For: Bug #896684


I experience the same problem, with a similar setup -- albeit minor differences.
The problem appears for a lot of applications run from the terminal, e.g. gitk.

Following https://bbs.archlinux.org/viewtopic.php?id=235643, I suspect that
there is a dependency mismatch in fontconfig packages:

$ LANG=C dpkg -l '*fontconfig*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion  Architecture Description
+++-===---
ii  fontconfig  2.11.0-6.7+b1amd64generic font 
configuration library - support binarie
ii  fontconfig-config   2.13.0-4 all  generic font 
configuration library - configuration
un  libfontconfig (no description 
available)
un  libfontconfig-dev (no description 
available)
ii  libfontconfig1:amd642.12.6-0.1   amd64generic font 
configuration library - runtime
ii  libfontconfig1:i386 2.12.6-0.1   i386 generic font 
configuration library - runtime
ii  libfontconfig1-dev:amd6 2.12.6-0.1   amd64generic font 
configuration library - development


regards,
Damien

-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'stable-updates'), (300, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages fontconfig-config depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  fonts-dejavu-core  2.37-1
ii  fonts-liberation   1:1.07.4-2
ii  ttf-bitstream-vera 1.10-8
ii  ucf3.0036

fontconfig-config recommends no packages.

fontconfig-config suggests no packages.

-- debconf information:
  fontconfig/hinting_type: Native
  fontconfig/hinting_style: hintslight
  fontconfig/subpixel_rendering: Automatic
  fontconfig/enable_bitmaps: false

Bug#898397: dh-make-golang: allow authentication to github API to avoid hitting limits

[Paul Wise]

Package: dh-make-golang
Version: 0.0~git20180410.bcfd5bf-1
Severity: wishlist

I packaged a bunch of dependencies for git-lab and then I started
getting 403 errors from github URLs. It looks like dh-make-golang
easily hits the github API rate limit for anonymous users.

Allowing authenticated requests could help to avoid the limit.

$ dh-make-golang make github.com/avast/retry-go
2018/05/11 12:51:52 Downloading "github.com/avast/retry-go/..."
2018/05/11 12:51:53 Determining upstream version number
2018/05/11 12:51:53 Package version is "1.0.2"
2018/05/11 12:51:53 Determining dependencies
2018/05/11 12:51:57 Could not determine long description for 
"github.com/avast/retry-go": unexpected HTTP status: got 403, want 200
2018/05/11 12:51:58 Could not determine copyright for 
"github.com/avast/retry-go": parsing time "" as "2006-01-02T15:04:05Z": cannot 
parse "" as "2006"
2018/05/11 12:51:59 Could not determine author for "github.com/avast/retry-go": 
parsing time "" as "2006-01-02T15:04:05Z": cannot parse "" as "2006"
2018/05/11 12:51:59 Could not determine long description for 
"github.com/avast/retry-go": unexpected HTTP status: got 403, want 200
...

$ curl -s https://api.github.com/users/pabs3 | jq
{
  "message": "API rate limit exceeded for . (But here's the good news: 
Authenticated requests get a higher rate limit. Check out the documentation for 
more details.)",
  "documentation_url": "https://developer.github.com/v3/#rate-limiting;
}

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

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

Versions of packages dh-make-golang depends on:
ii  git   1:2.17.0-1
ii  git-buildpackage  0.9.8
ii  golang-any2:1.10~5
ii  libc6 2.27-3
ii  pristine-tar  1.42

Versions of packages dh-make-golang recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.91-3

dh-make-golang suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#898396: dh-make-golang estimate: order missing packages by packaging order based on dependency chains

[Paul Wise]

Package: dh-make-golang
Version: 0.0~git20180410.bcfd5bf-1
Severity: wishlist

I tried to estimate the work needed to bring git-lab (command-line
gitlab API client) to Debian. Since the git-lab repo was printed first
I assumed I should start at the bottom. When I started at the bottom I
got two warnings listing two of the other dependencies. It would be
nice if the missing packages were ordered by the order in which they
should be packaged in order to satisfy the dependencies of the missing
packages. This would avoid having to manually discover that order by
packaging each dependency in a random order.

$ dh-make-golang estimate github.com/zaquestion/lab
2018/05/11 12:34:00 found github.com/mattn/go-runewidth in Debian package 
golang-github-mattn-go-runewidth-dev
2018/05/11 12:34:00 found github.com/mitchellh/mapstructure in Debian package 
golang-github-mitchellh-mapstructure-dev
2018/05/11 12:34:00 found golang.org/x/crypto in Debian package 
golang-golang-x-crypto-dev
2018/05/11 12:34:00 found golang.org/x/text in Debian package golang-x-text-dev
2018/05/11 12:34:00 found github.com/stretchr/testify in Debian package 
golang-github-stretchr-testify-dev
2018/05/11 12:34:00 found github.com/google/go-querystring in Debian package 
golang-github-google-go-querystring-dev
2018/05/11 12:34:00 found github.com/smartystreets/goconvey in Debian package 
golang-github-smartystreets-goconvey-dev
2018/05/11 12:34:00 found github.com/pkg/errors in Debian package 
golang-github-pkg-errors-dev
2018/05/11 12:34:00 found github.com/russross/blackfriday in Debian package 
golang-github-russross-blackfriday-dev
2018/05/11 12:34:00 found github.com/spf13/pflag in Debian package 
golang-github-spf13-pflag-dev
2018/05/11 12:34:00 found github.com/hashicorp/hcl in Debian package 
golang-github-hashicorp-hcl-dev
2018/05/11 12:34:00 found github.com/fsnotify/fsnotify in Debian package 
golang-github-go-fsnotify-fsnotify-dev
2018/05/11 12:34:00 found gopkg.in/yaml.v2 in Debian package golang-yaml.v2-dev
2018/05/11 12:34:00 found github.com/spf13/afero in Debian package 
golang-github-spf13-afero-dev
2018/05/11 12:34:00 found github.com/onsi/gomega in Debian package 
golang-gomega-dev
2018/05/11 12:34:00 found github.com/spf13/cast in Debian package 
golang-github-spf13-cast-dev
2018/05/11 12:34:00 found golang.org/x/sys in Debian package 
golang-golang-x-sys-dev
2018/05/11 12:34:00 found github.com/davecgh/go-spew in Debian package 
golang-github-davecgh-go-spew-dev
2018/05/11 12:34:00 found github.com/pelletier/go-toml in Debian package 
golang-github-pelletier-go-toml-dev
2018/05/11 12:34:00 found github.com/spf13/cobra in Debian package 
golang-github-spf13-cobra-dev
2018/05/11 12:34:00 found github.com/mitchellh/go-homedir in Debian package 
golang-github-mitchellh-go-homedir-dev
2018/05/11 12:34:00 found github.com/magiconair/properties in Debian package 
golang-github-magiconair-properties-dev
2018/05/11 12:34:00 found github.com/pmezard/go-difflib in Debian package 
golang-github-pmezard-go-difflib-dev
2018/05/11 12:34:00 found github.com/spf13/viper in Debian package 
golang-github-spf13-viper-dev
2018/05/11 12:34:00 found github.com/BurntSushi/toml in Debian package 
golang-toml-dev
2018/05/11 12:34:00 found gopkg.in/check.v1 in Debian package 
golang-gopkg-check.v1-dev
2018/05/11 12:34:00 found github.com/cpuguy83/go-md2man in Debian package 
golang-github-cpuguy83-go-md2man-dev
2018/05/11 12:34:00 found github.com/spf13/jwalterweatherman in Debian package 
golang-github-spf13-jwalterweatherman-dev
2018/05/11 12:34:00 Bringing github.com/zaquestion/lab to Debian requires 
packaging the following Go packages:
github.com/zaquestion/lab
github.com/tcnksm/go-gitconfig
github.com/rivo/tview
github.com/gdamore/encoding
github.com/lucasb-eyer/go-colorful
gopkg.in/DATA-DOG/go-sqlmock.v1
github.com/avast/retry-go
github.com/xanzy/go-gitlab
github.com/gdamore/tcell

$ dh-make-golang make github.com/gdamore/tcell
2018/05/11 12:34:50 Downloading "github.com/gdamore/tcell/..."
2018/05/11 12:34:58 Determining upstream version number
2018/05/11 12:34:58 Package version is "1.0.0+git20180503.3d5f294"
2018/05/11 12:34:58 Determining dependencies
2018/05/11 12:35:12 Build-Dependency "github.com/lucasb-eyer/go-colorful" is 
not yet available in Debian, or has not yet been converted to use 
XS-Go-Import-Path in debian/control
2018/05/11 12:35:12 Build-Dependency "github.com/gdamore/encoding" is not yet 
available in Debian, or has not yet been converted to use XS-Go-Import-Path in 
debian/control
2018/05/11 12:35:17 
2018/05/11 12:35:17 Packaging successfully created in 
/home/pabs/work/frisk/pkg/golang-github-gdamore-tcell
2018/05/11 12:35:17 
2018/05/11 12:35:17 Resolve all TODOs in itp-golang-github-gdamore-tcell.txt, 
then email it out:
2018/05/11 12:35:17 sendmail -t < itp-golang-github-gdamore-tcell.txt
2018/05/11 12:35:17 
2018/05/11 12:35:17 Resolve all the TODOs in debian/, find them using:
2018/05/11 12:35:17 grep -r 

Bug#898395: dh-make-golang: missing dep on golang-golang-x-tools for digraph

[Paul Wise]

Package: dh-make-golang
Version: 0.0~git20180410.bcfd5bf-1
Severity: important

dh-make-golang is missing a Depends, Recommends or Suggests on
golang-golang-x-tools for the digraph tool used by estimate:

$ dh-make-golang estimate github.com/zaquestion/lab
/bin/sh: 1: digraph: not found
2018/05/11 12:23:28 [/bin/sh -c go list -f 
'{{.ImportPath}}{{.Imports}}{{.TestImports}}{{.XTestImports}}' ... | tr '[]' ' 
' | digraph forward $(go list github.com/zaquestion/lab/...)]: exit status 127

$ apt-file search /usr/bin/digraph
golang-golang-x-tools: /usr/bin/digraph

$ apt-cache show dh-make-golang | egrep 
'Recommend|Suggest|golang-golang-x-tools'
Recommends: mail-transport-agent
Built-Using: golang-1.10 (= 1.10.1-1), golang-blackfriday (= 1.5.1-1), 
golang-golang-x-net-dev (= 1:0.0+git20180124.0ed95ab+dfsg-1), 
golang-golang-x-sync (= 0.0~git20171101.fd80eb9-1), golang-golang-x-tools (= 
1:0.0~git20180222.0.f8f2f88+ds-1)

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

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

Versions of packages dh-make-golang depends on:
ii  git   1:2.17.0-1
ii  git-buildpackage  0.9.8
ii  golang-any2:1.10~5
ii  libc6 2.27-3
ii  pristine-tar  1.42

Versions of packages dh-make-golang recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.91-3

dh-make-golang suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#898373: lilypond: CVE-2017-17523 (again)

[Salvatore Bonaccorso]

Hi Don,

On Thu, May 10, 2018 at 04:15:23PM -0700, Don Armstrong wrote:
> Control: unarchive 884136
> Control: found 884136 2.18.2-12
> Control: found 884136 2.19.81-1~exp1
> Control: forcemerge 884136 898373
> Control: tag 884136 confirmed
> 
> On Thu, 10 May 2018, Gabriel Corona wrote:
> > lilypond-invoke-editor as shipped in Debian is still vulnerable to
> > shell command injection in URIs (CVE-2017-17523).
> 
> Thanks for the report; we're actually shipping the upstream code with
> their fix to 2017-17523, but clearly that fix doesn't fix the whole
> thing, because they're using system instead of system*.
> 
> I'm testing a quick patch which should fix this issue, and I'll send it
> upstream once I know it's working.

I will request a new CVE id for the "incomplete fix for
CVE-2017-17523" (but no need to wait for that assignment for fixing
the issue).

Regards,
Salvatore

Bug#898394: general: Network (Ethernet) icon not updating on connection

[Keyikedalube Ndang]

Package: general
Severity: normal

Dear Maintainer,

I tether my phone's internet connection on my notebook. But I'm noticing that
the network icon does not update even the connection is successful. It usually
keeps displaying that connecting status; the icon is grayed out.

Rarely, the icon is displayed correctly i.e., it's no longer grayed but shows
white icon (successful connection)



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

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

Bug#898393: request section change lisp->text for fountain-mode

[Nicholas D Steeves]

Package: ftp.debian.org
Severity: normal

Dear FTP Team,

I would humbly like to request a section change of lisp to text for
fountain-mode, and have uploaded 2.5.3-2 with this change.

Justification: while it is an emacs addon, this addon's purpose is to
act as a tool to write screenplays.  I believe that the target
audience is more likely to browse the text section than the lisp
section, and that this makes it more discoverable, similarly to how
magit is more discoverable within the vcs section.  For more
information on the multi-platform file-format please consult
https://fountain.io.

If you believe another section is more appropriate please let me know,
and I'll update the section declared in the package asap :-)

Sincerely,
Nicholas

P.S. apologies if "normal" is too high of a severity, this is my first
section change request.

Bug#898390: slick-greeter: /etc/lightdm/slick-greeter.conf does not recognize lower case Greeter

[David Mohammed]

This is not a specific Debian issue and as such I would strongly recommend
that an issue be raised upstream

https://github.com/linuxmint/slick-greeter/issues

On Fri, 11 May 2018, 03:09 Will Gnann,  wrote:

> Package: slick-greeter
> Version: 1.1.4-1
> Severity: normal
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
>* What led up to the situation?
>  I tried to configure /etc/lightdm/slick-greeter.conf, but it worked
> only when I used [Greeter] instead of [greeter].
>
> *** End of the template - remove these template lines ***
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
> LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages slick-greeter depends on:
> ii  dconf-gsettings-backend [gsettings-backend]  0.28.0-2
> ii  libatk1.0-0  2.28.1-1
> ii  libc62.27-3
> ii  libcairo21.15.10-3
> ii  libcanberra0 0.30-6
> ii  libgdk-pixbuf2.0-0   2.36.11-2
> ii  libglib2.0-0 2.56.1-2
> ii  libgtk-3-0   3.22.29-3
> ii  liblightdm-gobject-1-0   1.18.3-4
> ii  libpango-1.0-0   1.42.0-1
> ii  libpangocairo-1.0-0  1.42.0-1
> ii  libx11-6 2:1.6.5-1
> ii  libxext6 2:1.3.3-1+b2
> ii  lightdm  1.18.3-4
> ii  python3  3.6.4-1
>
> slick-greeter recommends no packages.
>
> slick-greeter suggests no packages.
>
> -- no debconf information
>

Bug#898370: devscripts: autopkgtest regularly times out

[Paul Gevers]

Hi Mattia,

On 11-05-18 00:15, Mattia Rizzolo wrote:
> On Thu, May 10, 2018 at 11:24:49PM +0200, Paul Gevers wrote:
>> Since the upload of version 2.18.1 of devscripts, the autopkgtests¹
>> are regularly (but also worryingly not always) timing out (~ 3 hours)
>> while previous runs tested in about 3 minute. Could you please
>> investigate how to get rid of the timeout? And please fix your test to
>> actually pass, but that is less important now.
> 
> I did notice it, and like I wrote on IRC, it seems the actual failures
> were due to distro-info-data being outdated (i.e. at some point there
> were no known ubuntu devel releases), the timeouts instead were more
> mysterious for me.

Did you wrote it on IRC somewhere where I should have noticed? In that
case I missed it or I didn't notice the connection.

> Though, looks like Adam Conrad figured it out but didn't bother
> notifying us…

That happened with more Ubuntu delta's. I assume that will be better now
we are *using* autopkgtests in Debian.

> OTOH, I'm bothered if a missing test-depends causes a stall like that,
> so I'd rather see somebody investigate the test script and figure why it
> doesn't just error out.

That is basically the real bug then. So, glad I filed this bug. If this
isn't obvious to figure out, I suggest to clone this bug and fix the
missing dependency such that this bug can be closed (see below).

>> I will blacklist devscripts on ci.debian.net for now.
> 
> Thanks, guess you'll unblacklist it once this bug is closed?

Obviously, although typically I wait until the package has migrated to
testing (to avoid the timeouts there). I want test cases that can be
used. Blacklisted tests aren't of any use ;).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#898392: fcitx: default cangjie package (fcitx-table-cangjie) does not add input method

[Ryan Lue]

Package: fcitx
Version: 1:4.2.9.6-2
Severity: normal
Tags: l10n

There are currently four variants of cangjie tables for fcitx:

* fcitx-table-cangjie
* fcitx-table-cangjie-big
* fcitx-table-cangjie-3
* fcitx-table-cangjie-5

While the latter three packages add new input methods to the fcitx menu,
the first one does not.

I am posting this bug at the suggestion of Boyuan Yang, a “de factor
contributor/maintainer of fcitx in Debian”.

https://groups.google.com/d/msg/fcitx/85q7fn-4kZg/5umJZnX7AgAJ

As a suggestion, perhaps all variants of cangjie could be unified under
a single fcitx-table-cangjie metapackage?

Also, it’s not clear to me what the difference between any of these
variants are. Perhaps some simple documentation belonging to the
metapackage could help in that regard.

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

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

Versions of packages fcitx depends on:
ii  fcitx-bin  1:4.2.9.6-2
ii  fcitx-data 1:4.2.9.6-2
ii  fcitx-modules  1:4.2.9.6-2

Versions of packages fcitx recommends:
ii  fcitx-config-gtk   0.4.10-1
ii  fcitx-frontend-fbterm  0.2.0-2+b2
ii  fcitx-ui-classic   1:4.2.9.6-2
ii  im-config [im-switch]  0.34-1

Versions of packages fcitx suggests:
pn  fcitx-m17n   
pn  fcitx-tools  

-- no debconf information

Bug#893578: [zfs-linux]

[Antonio Russo]

Control: retitle -1 [zfs-linux] Please package 0.7.9

0.7.9 has been released. I've build the packages, and dkms
builds fine, so very little additional should be needed,
besides importing upstream (and the earlier patch to install
enum-extract.pl).

Bug#675033: ITP: kgraphviewer -- KGraphViewer is a GraphViz dot graph viewer for KDE 5.

[Simon Quigley]

Control: retitle -1 ITP: kgraphviewer -- KGraphViewer is a GraphViz dot
graph viewer for KDE 5.
Control: owner -1 tsimo...@ubuntu.com

I would like to upstream the Ubuntu packaging and maintain this under
the Qt/KDE Team umbrella, specifically under KDE Extras.

Thanks!

-- 
Simon Quigley
tsimo...@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4



signature.asc
Description: OpenPGP digital signature

Bug#898376: quaternion: overly generic header name: /usr/include/util.h

[Hubert Chathi]

On Fri, 11 May 2018 00:09:26 +0200, Andreas Beckmann  said:

> during a test with piuparts I noticed your package uses a very generic
> header file name that now clashes with other packages:

> /usr/include/util.h

Indeed.  The package shouldn't be including the header files at all, so
thank you for bringing that to my attention.  I was already planning on
making another upload soon, so I will include the changes in my next
upload.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#898390: slick-greeter: /etc/lightdm/slick-greeter.conf does not recognize lower case Greeter

[Will Gnann]

Package: slick-greeter
Version: 1.1.4-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
 I tried to configure /etc/lightdm/slick-greeter.conf, but it worked only 
when I used [Greeter] instead of [greeter].

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


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

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

Versions of packages slick-greeter depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.28.0-2
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-3
ii  libcairo21.15.10-3
ii  libcanberra0 0.30-6
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libglib2.0-0 2.56.1-2
ii  libgtk-3-0   3.22.29-3
ii  liblightdm-gobject-1-0   1.18.3-4
ii  libpango-1.0-0   1.42.0-1
ii  libpangocairo-1.0-0  1.42.0-1
ii  libx11-6 2:1.6.5-1
ii  libxext6 2:1.3.3-1+b2
ii  lightdm  1.18.3-4
ii  python3  3.6.4-1

slick-greeter recommends no packages.

slick-greeter suggests no packages.

-- no debconf information

Bug#888095: [debian-mysql] Bug#888095:

[Andy Li]

> > On 10/05/18 20:24, Otto Kekäläinen wrote:
> >> MariaDB 10.3 needs to be finalized and imported into Debian. After
> >> that all the mess that are a fallout of a misfortunate upload of
> >> mariadb-10.2 to Debian unstable will start to become resolved.
>

What do you mean by finalized? Are we waiting upstream for something?
If it will still take an unknown number of months to stabilize, using
an epoch as suggested by Emilio seems to be a good immediate solution.

Best regards,
Andy

Bug#898389: RFS: proxychains-ng/4.12-2

[Boyuan Yang]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: proxycha...@packages.debian.org

  Dear mentors and proxychains maintainers,

  I am looking for a sponsor for my package "proxychains-ng". I am also looking
  for a DD to help migrate the packaging git repository onto Debian group on
  Salsa platform and grant Master role of that repo to me (hosiet-guest).

 * Package name: proxychains-ng
   Version : 4.12-2
   Upstream Author : rofl0r 
 * URL : https://github.com/rofl0r/proxychains-ng
 * License : GPL-2+
   Section : net

  It builds those binary packages:

libproxychains4 - runtime shared library for proxychains-ng
proxychains4 - redirect connections through socks/http proxies

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

  https://mentors.debian.net/package/proxychains-ng

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

dget -x 
https://mentors.debian.net/debian/pool/main/p/proxychains-ng/proxychains-ng_4.12-2.dsc

  Proposed git packaging repository:

https://salsa.debian.org/debian/proxychains-ng (not available yet)

  Temporary git packaging repository:

https://salsa.debian.org/hosiet-guest/proxychains-ng (should be removed 
after upload)


  Changes since the last upload:

 proxychains-ng (4.12-2) unstable; urgency=medium
 .
  * Backport more patches from upstream trunk.
  * Bump Standards-Version to 4.1.4 (no changes needed).
  * Bump debhelper compat to v11.
  * d/rules: Use "dh_missing --fail-missing".
  * d/control: Use Salsa repo in Vcs fields.
  * Use Alternatives system to provide /usr/bin/proxychains.

It is worthwhile to note that I propose to use the alternatives system (as
documented in Section 6 of Debian Policy) to handle the selection between
original proxychains project and the new proxychains-ng project.

An upload for proxychains project has been prepared [1] too and everyone are
welcome to help review it, especially the review from maintainers of the
original proxychains package. I have made it possible for those two packages
to be uploaded independently (by specifying Breaks: relationship) but it would
definitely be better if those two uploads could be made jointly.


[1] https://salsa.debian.org/hosiet-guest/proxychains

  Regards,
   Boyuan Yang



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

Bug#898388: systemd-sysv: shutdown command always fails

[Michael Biebl]

Control: tags -1 + moreinfo

On Fri, 11 May 2018 01:11:34 + Meeuwissen Olaf
 wrote:
> Package: systemd-sysv
> Version: 232-25+deb9u3
> Severity: important
> 
> Dear Maintainer,
> 
> I have set up unattended-upgrades to reboot my machine at 04:00 when
> necessary.  Internally, unattended-upgrades runs
> 
>   /sbin/shutdown -r 04:00
> 
> trying to achieve this.  This fails as evidenced by these (dated) log
> messages
> 
>   Apr 25 06:55:18 easy apt.systemd.daily[38369]: Found 
> /var/run/reboot-required, rebooting
>   Apr 25 06:55:18 easy apt.systemd.daily[38369]: Failed to connect to bus: No 
> such file or directory
> 

What's the output of
systemctl status dbus.socket dbus.service systemd-logind.service

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



signature.asc
Description: OpenPGP digital signature

Bug#898388: systemd-sysv: shutdown command always fails

[Meeuwissen Olaf]

Package: systemd-sysv
Version: 232-25+deb9u3
Severity: important

Dear Maintainer,

I have set up unattended-upgrades to reboot my machine at 04:00 when
necessary.  Internally, unattended-upgrades runs

  /sbin/shutdown -r 04:00

trying to achieve this.  This fails as evidenced by these (dated) log
messages

  Apr 25 06:55:18 easy apt.systemd.daily[38369]: Found 
/var/run/reboot-required, rebooting
  Apr 25 06:55:18 easy apt.systemd.daily[38369]: Failed to connect to bus: No 
such file or directory

I have tried running the shutdown directly from the commandline with
identical results

  root@debian:~$ shutdown -r 04:00
  Failed to connect to bus: No such file or directory
  root@debian:~$ shutdown -r
  Failed to connect to bus: No such file or directory
  root@debian:~$ shutdown
  Failed to connect to bus: No such file or directory

I had expected the shutdown to behave as documented.

I have searched the debian/changelog for 238-4 on the terms shutdown and
reboot but did not find any indication that this might have been fixed.

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd-sysv depends on:
ii  systemd  232-25+deb9u3

systemd-sysv recommends no packages.

systemd-sysv suggests no packages.

-- no debconf information

Hope this helps,
--
Olaf Meeuwissen, LPIC-2   FLOSS Engineer -- EPSON AVASYS CORPORATION
   Free Software Foundation Associate Member since 2004-01-27
Support Free Software  https://my.fsf.org/donate
Join the Free Software Foundationhttps://my.fsf.org/join

Bug#898387: Patch: Please port to python 3

[Unit 193]

Package: mini-dinstall
Severity: normal

Dear Maintainer,

As python 2 is nearing end of life, it's likely time to move on to python 3.  
To that end, we've ported mini-dinstall to python 3 (and I've been running it 
for a little bit now).

You're generally going to want to pick all 5 commits, or at least pick up 
sections from them and test.


[0]: 
https://loki.unit193.net/cgit/users/unit193/mini-dinstall.git/commit/?id=23ac25c0b388b5ffebf66154b12a3950b89b977a
[1]: 
https://loki.unit193.net/cgit/users/unit193/mini-dinstall.git/commit/?id=dc580be8f9ef38a1c0903820b04e1b5c7217da16
[2]: 
https://loki.unit193.net/cgit/users/unit193/mini-dinstall.git/commit/?id=11bda2c49979375ab7cdea5deac04f4bcb2a5dae
[3]: 
https://loki.unit193.net/cgit/users/unit193/mini-dinstall.git/commit/?id=1cd7d0f0248e2fe317b2e3da9f597059cf30b4d9
[4]: 
https://loki.unit193.net/cgit/users/unit193/mini-dinstall.git/commit/?id=946753d96692846ffe47487abf450251cad23538

~Unit 193
Unit193 @ OFTC
Unit193 @ freenode

Bug#897607: dbus: Please raise timeout for a few test cases (or disable) in riscv64

[Manuel A. Fernandez Montecelo]

Hi,

2018-05-11 1:53 GMT+02:00 Simon McVittie :
> On Wed, 09 May 2018 at 17:56:01 +0100, Simon McVittie wrote:
>> On Sat, 05 May 2018 at 01:46:19 +0200, Manuel A. Fernandez Montecelo wrote:
>> > So the build failed in other tests now.
>>
>> Based on these numbers I've tried a 20x multiplier for the timeouts on
>> __riscv in my recent upload to experimental. I've also added better
>> logging for buildd builds, so that I don't have to keep asking you
>> for logs.
>>
>> If these changes are successful in experimental then I'll land them
>> in unstable.
>
> Please could you try building dbus/1.13.4-2 from experimental, if you're
> keen to accelerate this process? The riscv64 buildds seem to be having
> trouble getting the source package, and I'd prefer not to upload this
> change to unstable until I can be more confident that it works.

Sorry, was travelling for a few days.

Only two of the buildds have "experimental" enabled, and large
transitions underway, thus the delay.

It's starting to build now in one if the buildds, I hope that tomorrow
we have the answer.

Thanks!
-- 
Manuel A. Fernandez Montecelo 

Bug#898386: Patch: Support installing upstream detached signatures.

[Unit 193]

Package: mini-dinstall
Severity: normal

Dear Maintainer,

For a while, now, dpkg has had support for including detached sigs with signed 
tarballs.  These are included in the dsc so if you dget them, they will 
complain about a missing file.  This patch[0] adds basic support for installing 
them.

[0]: 
https://loki.unit193.net/cgit/users/unit193/mini-dinstall.git/commit/?id=9883708468224628f9e0e577162fb5345fe20eb4


~Unit 193
Unit193 @ OFTC
Unit193 @ freenode

Bug#898385: Patch: sign-release.sh: Add support for gpg2.

[Unit 193]

Package: mini-dinstall
Severity: normal

Dear Maintainer,

The provided example script for signing releases currently supports gpg1, 
though this is on the way out in Debian.  Thusly, I have added support for 
gpg2[0].

I would greatly appreciate if I could share this benefit with others.


[0]: 
https://loki.unit193.net/cgit/users/unit193/mini-dinstall.git/commit/?id=8ba508e724e9e02675c3673b5bed725ef9bf3b85


~Unit 193
Unit193 @ OFTC
Unit193 @ freenode

Bug#897607: dbus: Please raise timeout for a few test cases (or disable) in riscv64

[Simon McVittie]

On Wed, 09 May 2018 at 17:56:01 +0100, Simon McVittie wrote:
> On Sat, 05 May 2018 at 01:46:19 +0200, Manuel A. Fernandez Montecelo wrote:
> > So the build failed in other tests now.
> 
> Based on these numbers I've tried a 20x multiplier for the timeouts on
> __riscv in my recent upload to experimental. I've also added better
> logging for buildd builds, so that I don't have to keep asking you
> for logs.
> 
> If these changes are successful in experimental then I'll land them
> in unstable.

Please could you try building dbus/1.13.4-2 from experimental, if you're
keen to accelerate this process? The riscv64 buildds seem to be having
trouble getting the source package, and I'd prefer not to upload this
change to unstable until I can be more confident that it works.

Thanks,
smcv

Bug#898323: g++-8 -m32 do not find bits/c++config.h

[Matthias Klose]

On 10.05.2018 11:24, Bill Allombert wrote:
> Package: g++-8
> Version: 8.1.0-1
> Severity: normal
> 
> Hello GCC maintainers,
> 
> trying to the attached dummy file with g++-8 fails:
> 
> g++-8 -m32 hello.c
> In file included from /usr/include/c++/8/stdlib.h:36,
>  from hello.c:1:
> /usr/include/c++/8/cstdlib:41:10: fatal error: bits/c++config.h: No such file 
> or directory
>  #include 
>   ^~
> compilation terminated.
> 
> g++-8-multilib is installed.
> This work with g++-7 and g++-6
> Maybe this is related to
>  "* Stop providing the 8.x.y symlinks in gcc_lib_dir and incluce/c++.  "

works for me.

Bug#898383: srs: /tmp/srsd socket schould not be in /tmp

[gregor herrmann]

On Fri, 11 May 2018 00:08:52 +0200, Martin Burmester wrote:

> /tmp is a bad place for the srsd socket. Unfortunately that pathname is
> hardcoded (/usr/bin/srsd, line 15). It is probably not an exploitable
> insecure tempfile creation, nonetheless it should not be there.

And in some other places, in case we want to add a patch:

% grep -r /tmp/srsd
eg/exim/srs.conf:   address_data = ${readsocket{/tmp/srsd}\
eg/exim/srs.conf:   address_data = ${readsocket{/tmp/srsd}\
eg/exim/srs.conf:#^(?i:srs0[-+=])   ${readsocket{/tmp/srsd}{REVERSE 
$0\n}{5s}{\n}\
eg/exim/srs.conf:#^(?i:srs1[-+=])   ${readsocket{/tmp/srsd}{REVERSE 
$0\n}{5s}{\n}\
eg/exim/srs.conf:#* ${readsocket{/tmp/srsd}{FORWARD 
$0 SRSDOMAIN}{5s}{\n}\
lib/Mail/SRS/Daemon.pm:$SRSSOCKET = '/tmp/srsd';
srsd:$PATH = '/tmp/srsd';


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Element of Crime: Finger weg von meiner Paranoia


signature.asc
Description: Digital Signature

Bug#898384: terminology: focus weirdness in 1.2.0

[Ross Vandegrift]

Package: terminology
Version: 1.2.0-1
Severity: serious

terminology 1.2.0 easily gets stuck in a state where it doesn't receive
keyboard events.  This is triggered by switching keyboard focus away from
terminology, and then back.

Upstream discussion:
 https://sourceforge.net/p/enlightenment/mailman/message/36314861/
 <20180510202714.ga10...@nabu.fau.re>

Ross

Bug#898373: lilypond: CVE-2017-17523 (again)

[Don Armstrong]

Control: unarchive 884136
Control: found 884136 2.18.2-12
Control: found 884136 2.19.81-1~exp1
Control: forcemerge 884136 898373
Control: tag 884136 confirmed

On Thu, 10 May 2018, Gabriel Corona wrote:
> lilypond-invoke-editor as shipped in Debian is still vulnerable to
> shell command injection in URIs (CVE-2017-17523).

Thanks for the report; we're actually shipping the upstream code with
their fix to 2017-17523, but clearly that fix doesn't fix the whole
thing, because they're using system instead of system*.

I'm testing a quick patch which should fix this issue, and I'll send it
upstream once I know it's working.

-- 
Don Armstrong  https://www.donarmstrong.com

6: If we are one, then we can defeat 2.
  -- "The Prisoner (2009 Miniseries)" _Schizoid_

Bug#898383: srs: /tmp/srsd socket schould not be in /tmp

[Martin Burmester]

Package: srs
Version: 0.31-5
Severity: normal

Dear Maintainer,

/tmp is a bad place for the srsd socket. Unfortunately that pathname is
hardcoded (/usr/bin/srsd, line 15). It is probably not an exploitable
insecure tempfile creation, nonetheless it should not be there.

Cheers,
Martin

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

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

Versions of packages srs depends on:
ii  libmail-srs-perl  0.31-5

srs recommends no packages.

srs suggests no packages.

-- no debconf information

Bug#721791: protobuf: please fix static initialization problem with dlopen

[Andres Salomon]

Hi,

As Gregor mentioned, the upstream bug report appears to refer to
something entirely different. Since there's no error messages in
this bug, I can't tell whether it's still a problem or not.  The patch
supplied in this bug report has not been applied in the latest
upstream release of protobuf.

I see other dlopen-related bugs upstream, but most are closed:
https://github.com/google/protobuf/issues?utf8=%E2%9C%93=is%3Aissue++dlopen+

Please let me know if this bug should still be open or not; and if
so, which upstream bug is relevant?

Thanks,
Andres

Bug#898382: deluge-gtk: Please add support for Ayatana indicators

[Unit 193]

Package: deluge-gtk
Severity: wishlist

Dear Maintainer,

Please add support for using  the supported Ayatana indicators, instead of the 
fairly unmaintained Ubuntu ones.

I've been using deluge with the Ayatana indicators by way of a couple of 
patches[0][1], though at this point I'd highly recommend enabling the 
indicators in Debian by default and not restricting it to Ubuntu.

Thanks for maintaining Deluge!


[0]: 
https://loki.unit193.net/cgit/users/unit193/deluge.git/commit/?id=358afd4b33125818f84c3d62bc3a3fe5d53ec67d
[1]: 
https://loki.unit193.net/cgit/users/unit193/deluge.git/commit/?id=8a5169b1021d021492ee4e4502f596bc71507b0f

~Unit 193
Unit193 @ OFTC
Unit193 @ freenode

Bug#898320: kdeconnect: 1.3.0 does not work with 1.8.2 android version

[Lisandro Damián Nicanor Pérez Meyer]

Control: severity -1 important

Hi Eric!

On 10 May 2018 at 05:47, valette  wrote:
> Package: kdeconnect
> Version: 1.3.0-1
> Severity: grave
> Justification: renders package unusable
>
> My phone and various pc do not connect to ecah other. This has been 
> previously working very well on same hardware.

Works perfectly for me, no changes whatsoever. Maybe you have a
problem in your network?

Bug#898381: python3-pypass: missing Breaks+Replaces: pypass (<< 0.2.1)

[Andreas Beckmann]

Package: python3-pypass
Version: 0.2.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package python3-pypass.
  Preparing to unpack .../python3-pypass_0.2.1-1_all.deb ...
  Unpacking python3-pypass (0.2.1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-pypass_0.2.1-1_all.deb (--unpack):
   trying to overwrite '/usr/lib/python3/dist-packages/pypass/__init__.py', 
which is also in package pypass 0.2.0-1


cheers,

Andreas


pypass=0.2.0-1_python3-pypass=0.2.1-1.log.gz
Description: application/gzip

Bug#898380: libreadline-java-doc: fails to upgrade from 'stretch' - trying to overwrite /usr/share/doc/libreadline-java/NEWS.gz

[Andreas Beckmann]

Package: libreadline-java-doc
Version: 0.8.0.1+dfsg-7
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package libreadline-java-doc.
  Preparing to unpack .../libreadline-java-doc_0.8.0.1+dfsg-7_all.deb ...
  Unpacking libreadline-java-doc (0.8.0.1+dfsg-7) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libreadline-java-doc_0.8.0.1+dfsg-7_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/libreadline-java/NEWS.gz', which is also 
in package libreadline-java 0.8.0.1+dfsg-5
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libreadline-java-doc_0.8.0.1+dfsg-7_all.deb

This is probably fallout from changed dh_installdocs behaviour in
debhelper compat level 11.

cheers,

Andreas


libreadline-java=0.8.0.1+dfsg-5_libreadline-java-doc=0.8.0.1+dfsg-7.log.gz
Description: application/gzip

Bug#898378: oidentd: Please switch to the new upstream and update to the latest version

[Unit 193]

Package: oidentd
Severity: normal

Dear Maintainer,

According to the homepage, oidentd has been handed off to a new maintainer.  
I've been running this for a little, and it has some bug fixes I'm certainly 
interested in.

I have uploaded a trimmed down version[0] of my package to mentors[1] in the 
hopes that my efforts will be of value to you.

Upstream also plans to re-write the manpage, to be able to get away from the 
current license.


[0]: https://mentors.debian.net/debian/pool/main/o/oidentd/oidentd_2.2.3-1.dsc
[1]: https://mentors.debian.net/package/oidentd

~Unit 193
Unit193 @ freenode
Unit193 @ OFTC

Bug#898379: pitivi: no longer responds as soon as I try to import an Ogg Vorbis audio file

[Francesco Poli (wintermute)]

Package: pitivi
Version: 0.99-3
Severity: important

Hello!
Thanks for maintaining pitivi in Debian.

I am trying to learn how to use it, but I am experiencing an
important bug.
Steps to reproduce the issue:

  0) start pitivi

 $ pitivi

  1) click on the New button in the welcome dialog window

  2) click on the Import button in the media library tab

  3) go to a directory where one or more Ogg Vorbis files are
 present

  4) select one .ogg file and click on the Add button

  5) pitivi stops responding, its windows are no longer repainted,
 and there's nothing I can do, apart from killing the process...

I have tried a number of .ogg files, without any success.
In some cases I get the following errors:

  ERROR 00:03:38 assetpipeline  
_async_done_not_received_cb: we didn't get async done, this is a bug 
(../../../../usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/utils/pipeline.py:299)
  ERROR 00:03:38 assetpipeline  _recover: 
Pipeline error detected during playback, resetting -- num tries: 0 
(../../../../usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/utils/pipeline.py:469)

but not always.

Is there anything I failed to understand?
Could you please investigate this bug and/or forward my bug report
upstream, as appropriate?

Thanks for your time.
Bye.


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

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

Versions of packages pitivi depends on:
ii  gir1.2-gdkpixbuf-2.02.36.11-2
ii  gir1.2-ges-1.0  1.14.0-1
ii  gir1.2-glib-2.0 1.56.1-1
ii  gir1.2-gst-plugins-base-1.0 1.14.0-2
ii  gir1.2-gstreamer-1.01.14.0-1
ii  gir1.2-gtk-3.0  3.22.29-3
ii  gir1.2-pango-1.01.42.0-1
ii  gstreamer1.0-alsa [gstreamer1.0-audiosink]  1.14.0-2
ii  gstreamer1.0-gl [gstreamer1.0-videosink]1.14.0-2
ii  gstreamer1.0-gtk3 [gstreamer1.0-videosink]  1.14.0-4
ii  gstreamer1.0-plugins-bad [gstreamer1.0-videosink]   1.14.0-1+b1
ii  gstreamer1.0-plugins-base   1.14.0-2
ii  gstreamer1.0-plugins-good [gstreamer1.0-videosink]  1.14.0-4
ii  gstreamer1.0-x [gstreamer1.0-videosink] 1.14.0-2
ii  libc6   2.27-3
ii  libcairo2   1.15.10-3
ii  libglib2.0-02.56.1-2
ii  libgstreamer-plugins-base1.0-0  1.14.0-2
ii  libgstreamer1.0-0   1.14.0-1
ii  libpython3.63.6.5~rc1-1
ii  python3 3.6.4-1
ii  python3-cairo   1.16.2-1
ii  python3-dbus1.2.6-1
ii  python3-gi  3.28.2-1
ii  python3-gi-cairo3.28.2-1
ii  python3-gst-1.0 1.14.0-2
ii  python3-matplotlib  2.1.1-2
ii  python3-numpy   1:1.13.3-2
ii  python3-xdg 0.25-4
ii  python3.6   3.6.5~rc1-1

pitivi recommends no packages.

Versions of packages pitivi suggests:
pn  frei0r-plugins 
pn  gir1.2-gnomedesktop-3.0
ii  gir1.2-notify-0.7  0.7.7-3
ii  gstreamer1.0-libav 1.14.0-1
pn  gstreamer1.0-plugins-ugly  

-- no debconf information

Bug#898370: devscripts: autopkgtest regularly times out

[Mattia Rizzolo]

Hi!

On Thu, May 10, 2018 at 11:24:49PM +0200, Paul Gevers wrote:
> Since the upload of version 2.18.1 of devscripts, the autopkgtests¹
> are regularly (but also worryingly not always) timing out (~ 3 hours)
> while previous runs tested in about 3 minute. Could you please
> investigate how to get rid of the timeout? And please fix your test to
> actually pass, but that is less important now.

I did notice it, and like I wrote on IRC, it seems the actual failures
were due to distro-info-data being outdated (i.e. at some point there
were no known ubuntu devel releases), the timeouts instead were more
mysterious for me.

Though, looks like Adam Conrad figured it out but didn't bother
notifying us…
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/d/devscripts/20180503_183840_2977e@/log.gz
https://launchpad.net/ubuntu/+source/devscripts/2.18.2ubuntu1
http://launchpadlibrarian.net/368504724/devscripts_2.18.2_2.18.2ubuntu1.diff.gz

OTOH, I'm bothered if a missing test-depends causes a stall like that,
so I'd rather see somebody investigate the test script and figure why it
doesn't just error out.
(CCing osamu as he wrote that test…)

> I will blacklist devscripts on ci.debian.net for now.

Thanks, guess you'll unblacklist it once this bug is closed?

-- 
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#898377: lintian: overly generic header name: /usr/include/util.h

[Andreas Beckmann]

Package: lintian
Severity: normal

Hi,

after the overly generic python module names, I now came across util.h
in two packages: libduo-dev, quaternion.

Maybe we need to start another list of generic names in Lintian ...


Andreas

Bug#898376: quaternion: overly generic header name: /usr/include/util.h

[Andreas Beckmann]

Package: quaternion
Version: 0.0.9-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package uses a very generic
header file name that now clashes with other packages:

/usr/include/util.h


Andreas

Bug#898375: libduo-dev: overly generic header name: /usr/include/util.h

[Andreas Beckmann]

Package: libduo-dev
Version: 1.9.21-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package uses a very generic
header file name that now clashes with other packages:

/usr/include/util.h


Andreas

Bug#895893: gqrx-sdr: Seg fault after startup configuration

[martin]

Package: gqrx-sdr
Version: 2.9-2+b2
Followup-For: Bug #895893

Hell Hans,
  I have the exact same issue with the same version. What exact package 
and what version was updated that fixed the issue for you? 
I am getting a seg fault on Buster aswell after configuration is set. It seg 
faults before GQRX has a configuration file


The GQRX version has not changed since December 2017

gqrx-sdr (2.9-2) unstable; urgency=medium

  * upstream Debian patches, update to v2.9-4-g4138038

I can not see any other version changes on the 18th of April.

thanks

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

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

Versions of packages gqrx-sdr depends on:
ii  libboost-program-options1.62.0  1.62.0+dfsg-5+b1
ii  libboost-system1.62.0   1.62.0+dfsg-5+b1
ii  libc6   2.27-3
ii  libgcc1 1:8-20180425-1
ii  libgnuradio-analog3.7.123.7.12.0-2
ii  libgnuradio-audio3.7.12 3.7.12.0-2
ii  libgnuradio-blocks3.7.123.7.12.0-2
ii  libgnuradio-digital3.7.12   3.7.12.0-2
ii  libgnuradio-fft3.7.12   3.7.12.0-2
ii  libgnuradio-filter3.7.123.7.12.0-2
ii  libgnuradio-osmosdr0.1.40.1.4-14+b5
ii  libgnuradio-pmt3.7.12   3.7.12.0-2
ii  libgnuradio-runtime3.7.12   3.7.12.0-2
ii  liblog4cpp5v5   1.1.1-3
ii  libpulse0   11.1-5
ii  libqt5core5a5.10.1+dfsg-5
ii  libqt5gui5  5.10.1+dfsg-5
ii  libqt5network5  5.10.1+dfsg-5
ii  libqt5svg5  5.10.1-2
ii  libqt5widgets5  5.10.1+dfsg-5
ii  libstdc++6  8-20180425-1
ii  libvolk1.4  1.4-2
ii  pulseaudio  11.1-5

gqrx-sdr recommends no packages.

gqrx-sdr suggests no packages.

-- no debconf information

Bug#898374: gcc-8-cross: file conflicts with {gcc,g++,...}-8 on /usr/bin/-*-8

[Andreas Beckmann]

Source: gcc-8-cross
Version: 12
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package gcc-8-x86-64-linux-gnu.
  Preparing to unpack .../16-gcc-8-x86-64-linux-gnu_8.1.0-1cross1_amd64.deb ...
  Unpacking gcc-8-x86-64-linux-gnu (8.1.0-1cross1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-GsQJpd/16-gcc-8-x86-64-linux-gnu_8.1.0-1cross1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/bin/x86_64-linux-gnu-gcc-8', which is also in 
package gcc-8 8.1.0-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   
/tmp/apt-dpkg-install-GsQJpd/01-cpp-8-x86-64-linux-gnu_8.1.0-1cross1_amd64.deb
   
/tmp/apt-dpkg-install-GsQJpd/16-gcc-8-x86-64-linux-gnu_8.1.0-1cross1_amd64.deb

Similar problems with cpp-8,g++-8,... as well as for gcc-7-cross and
{gcc,g++,...}-7.


cheers,

Andreas


gcc-8=8.1.0-1_gcc-8-x86-64-linux-gnu=8.1.0-1cross1.log.gz
Description: application/gzip

Bug#600261: protobuf: [patch] remove explicit #!/usr/bin/python2.4 usage

[Andres Salomon]

tags 600261 - fixed-upstream
found 600261 3.5.2-2
thanks

Note that this hasn't actually been fixed upstream; in the
upstream bug, the person who submitted a fix refused to sign
a CLA with Google. It was never fixed.

https://github.com/google/protobuf/pull/2009

It's still in the latest upstream release. That said, it's unused
in Debian so I'm tempted to tag this +wontfix.

Bug#887586: Fixed

[Bastien ROUCARIES]

control: affects -1 - src:node-connect-timeout

On Thu, May 10, 2018 at 11:34 PM, Bastien ROUCARIES
 wrote:
> control: affects -1 - src:node-connect
>
> On Thu, May 10, 2018 at 9:57 PM, Bastien ROUCARIES
>  wrote:
>> control: affects -1 - src:node-cookie-parser

Bug#898373: lilypond: CVE-2017-17523 (again)

[Gabriel Corona]

Package: lilypond
Version: 2.18.2-12
Severity: grave
Tags: security
Justification: user security hole

Hi,

lilypond-invoke-editor as shipped in Debian is still vulnerable to
shell command injection in URIs (CVE-2017-17523).

This is easily demonstrated by running this shell command using an
updated lilypond package which still spawns an xterm process:

BROWSER="firefox" lilypond-invoke-editor "http://www.example.com/;

The vulnerable code snippet is still present:

(define (run-browser uri)
  (system
   (if (getenv "BROWSER")
   (format #f "~a ~a" (getenv "BROWSER") uri)
   (format #f "firefox -remote 'OpenURL(~a,new-tab)'" uri

Upstream bug [1] is marked as fixed but it's actually not. It has ben
reported as Debian Bug 884136 which is marked as closed and archived.

[1] https://sourceforge.net/p/testlilyissues/issues/5243/

-- 
Gabriel


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

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

Versions of packages lilypond depends on:
ii  ghostscript9.22~dfsg-2.1
ii  libc6  2.27-3
ii  libfontconfig1 2.13.0-4
ii  libfreetype6   2.8.1-2
ii  libgcc11:8-20180425-1
ii  libglib2.0-0   2.56.1-2
ii  libgmp10   2:6.1.2+dfsg-3
ii  libltdl7   2.4.6-2.1
ii  libpango-1.0-0 1.42.0-1
ii  libpangoft2-1.0-0  1.42.0-1
ii  libstdc++6 8-20180425-1
ii  lilypond-data  2.18.2-12
ii  python 2.7.15~rc1-1

Versions of packages lilypond recommends:
ii  texlive-latex-base  2018.20180416-1

Versions of packages lilypond suggests:
pn  lilypond-doc  

-- no debconf information

Bug#895893: Which version?

[Martin Naughton]

Hell Hans,
I have the exact same issue with the same version. What
exact package and what version was updated that fixed the issue for you? I
am getting a seg fault on Buster aswell after configuration is set.


ii  gnuradio
3.7.12.0-2   amd64
ii  gqrx-sdr
2.9-2+b2 amd64

The GQRX version has not changed since December 2017

gqrx-sdr (2.9-2) unstable; urgency=medium

  * upstream Debian patches, update to v2.9-4-g4138038

 -- A. Maitland Bottoms   Sun, 10 Dec 2017 16:53:16
-0500




-- 
Regards
Martin Naughton

Bug#898338: plasma-workspace: Different components hang, high CPU load

[Maximiliano Curia]

¡Hola Dominik!

El 2018-05-10 a las 22:34 +0200, Dominik George escribió:

OK, I found something:



When I kill plasmashell and start it again, in a terminal, I get the
following several times per second:



KActivities: Database can not be opened in WAL mode. Check the SQLite version 
(required >3.7.0). And whether your filesystem supports shared memory
Closing SQL connection:  "kactivities_db_resources_139838218086080_readonly"
KActivities ERROR: There is no database. This probably means that you do not 
have the Activity Manager running, or that something else is broken on your 
system. Recent documents and alike will not work!
KActivities: FATAL ERROR: Failed to contact the activity manager daemon



The last message of these is also filling up mi .xsession-errors, so I
figure it's the same error that is causing the hangs.



-nik


I think that means that the kactivities database is broken, you might want to 
try moving ~/.local/share/kactivitymanagerd.


Happy hacking,
--
"When explaining a command, or language feature, or hardware widget, first 
describe the problem it is designed to solve."

-- David Martin
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#898372: ITP: play.it -- Installer for drm-free commercial games

[Phil Morrell]

Package: wnpp
Owner: Phil Morrell 
Severity: wishlist

* Package name: play.it
  Version : 2.7.5
  Upstream Author : Antoine Le Gonidec 
* URL : https://www.dotslashplay.it/
* License : BSD-2-Clause
  Programming Lang: Shell
  Section : contrib/games
  Description : Installer for drm-free commercial games

./play.it is a tool which builds .deb and .pkg packages from installers
for Windows or Linux, mainly those sold by GOG and Humble Bundle. Our
goal is that a game installed via ./play.it is indistinguishable from a
game installed via the official repositories of your favorite
distribution.

The games are installed globally on multi-user systems, avoiding
unnecessary duplication. The locations of save games, settings, mods,
temporary files and backups are standardized with XDG Base Directory
support.

Packaging the games simplifies future updates, uninstalls and handling
of any necessary dependencies, including integrated obsolete
dependencies if specific versions are needed.

---

Similar packages:
* game-data-packager - no original engines, fewer games
* playonlinux - only wine, single-user
* lutris - gui, game library manager, bigger scope

Initial packaging at https://salsa.debian.org/emorrp1-guest/play.it.
I plan to maintain it in Debian Games Team.


signature.asc
Description: PGP signature

Bug#887586: Fixed

[Bastien ROUCARIES]

control: affects -1 - src:node-connect

On Thu, May 10, 2018 at 9:57 PM, Bastien ROUCARIES
 wrote:
> control: affects -1 - src:node-cookie-parser

Bug#898371: octave-ltfat: autopkgtest times out since 25 April 2018

[Paul Gevers]

Source: octave-ltfat
Version: 2.2.0+dfsg-8
Severity: normal
User: debian...@lists.debian.org
Usertags: regression timeout

Since the run of 25 April 2018, the autopkgtests¹ are timing out (~ 3
hours) while previous runs tested in about 20 seconds (and failed).
Could you please investigate how to get rid of the timeout? And please
fix your test to actually pass, but that is less important now.

I will blacklist octave-ltfat on ci.debian.net for now.

Don't hesitate to ask for help for the Debian CI team² if you need help
solving this issue.

Paul

¹ https://ci.debian.net/packages/o/octave-ltfat/unstable/amd64/
² #debci on oftc or debian...@lists.debian.org


https://ci.debian.net/data/autopkgtest/unstable/amd64/o/octave-ltfat/271201/log.gz

autopkgtest [21:04:31]: test command1: [---
Checking package...
Checking m files ...
[octave_poly2mask]
> /usr/share/octave/packages/ltfat-2.2.0/mulaclab/octave_poly2mask.m
* demo
 s = [0:pi/4:2*pi];
 x = cos (s) * 90 + 101;
 y = sin (s) * 90 + 101;
 bw = octave_poly2mask(x, y, 200, 200);
 imshow (bw);
* demo
 s = [0:2*pi/5:pi*4];
 s = s ([1, 3, 5, 2, 4, 6]);
 x = cos (s) * 90 + 101;
 y = sin (s) * 90 + 101;
 bw = octave_poly2mask (x, y, 200, 200);
 imshow (bw);
* # Convex polygons
* shared xs, ys, Rs, xt, yt, Rt
 xs=[3,3,10,10];
 ys=[4,12,12,4];
 Rs=zeros(16,14);
 Rs(5:12,4:10)=1;
 Rs=logical(Rs);
 xt=[1,4,7];
 yt=[1,4,1];
 Rt=[0,0,0,0,0,0,0;
 0,0,1,1,1,1,0;
 0,0,0,1,1,0,0;
 0,0,0,1,0,0,0;
 0,0,0,0,0,0,0];
 Rt=logical(Rt);
* assert(octave_poly2mask(xs,ys,16,14),Rs);  # rectangle
* assert(octave_poly2mask(xs,ys,8,7),Rs(1:8,1:7));   # clipped
* assert(octave_poly2mask(xs-7,ys-8,8,7),Rs(9:16,8:14)); # more clipping
* assert(octave_poly2mask(xt,yt,5,7),Rt);# triangle
* assert(octave_poly2mask(xt,yt,3,3),Rt(1:3,1:3));   # clipped
* # Concave polygons
* test
 x=[3,3,5,5,8,8,10,10];
 y=[4,12,12,8,8,11,11,4];
 R=zeros(16,14);
 R(5:12,4:5)=1;
 R(5:8,6:8)=1;
 R(5:11,9:10)=1;
 R=logical(R);
 assert(octave_poly2mask(x,y,16,14), R);
* # Complex polygons
* test
 x=[1,5,1,5];
 y=[1,1,4,4];
 R=[0,0,0,0,0,0;
0,0,1,1,0,0;
0,0,1,1,0,0;
0,1,1,1,1,0;
0,0,0,0,0,0];
 R=logical(R);
 assert(octave_poly2mask(x,y,5,6), R);
7 tests, 7 passed, 0 known failure, 0 skipped
Checking C++ files ...
Run tests in debian/check.m
[running test_all_ltfat]
 ===  TEST_DGT 
 ===  TEST_DWILT 
 ===  TEST_WMDCT 
 ===  TEST_DGT_FB 
 ===  TEST_MULTIWIN 
 ===  TEST_GABFIRTIGHT 
 ===  TEST_PUREFREQ 
 ===  TEST_ZAK 
 ===  TEST_GABMULAPPR =
 ===  TEST_DGT2 
 ===  TEST_DWILT2 
 ===  TEST_WMDCT2 
 ===  TEST_FIRWIN 
 ===  TEST_SPREAD 
warning: matrix singular to machine precision, rcond = 4.87176e-18
warning: matrix singular to machine precision, rcond = 4.87176e-18
 ===  TEST_DSFT ==
 ===  TEST_THRESH 
 ===  TEST_PCONV ==
 ===  TEST_LCONV ==
 ===  TEST_INVOLUTE ===
 ===  TEST_SIGNALS ===
 ===  TEST_REALOUT 
 ===  TEST_WINDRIVERS 
 ===  TEST_NSDGT 
 ===  TEST_FILTERBANK 
 ===  TEST_PGAUSS 
 ===  TEST_PFILT ==
 ===  TEST_RANGECOMPRESS 
 ===  TEST_GABMULEIGS 
 ===  TEST_PHASELOCK 
= TEST FWT 
-TEST_BLOCKFWT--
= TEST UFWT 
= TEST WFBT 
= TEST UWPFBT 
= TEST WPFBT 
= TEST UWPFBT 
= TEST FWT2 
 ===  TEST_WFBT2FILTERBANK ===
TEST_FREQORDER--
 ===  TEST_GGA 
 ===  TEST_CHIRPZT 
 ===  TEST_FRAMES 
 ===  TEST_FRFT ===
-TEST_NONU2UFILTERBANK-
= TEST DTWFB 
= TEST DTWFB 
autopkgtest [23:51:11]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.010ighvh/downtmp/build.8rI/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.010ighvh/downtmp/command1-artifacts"; export

Bug#898370: devscripts: autopkgtest regularly times out

[Paul Gevers]

Source: devscripts
Version: 2.18.1
Severity: normal
User: debian...@lists.debian.org
Usertags: timeout

Since the upload of version 2.18.1 of devscripts, the autopkgtests¹
are regularly (but also worryingly not always) timing out (~ 3 hours)
while previous runs tested in about 3 minute. Could you please
investigate how to get rid of the timeout? And please fix your test to
actually pass, but that is less important now.

I will blacklist devscripts on ci.debian.net for now.

Don't hesitate to ask for help for the Debian CI team² if you need help
solving this issue.

Paul

¹ https://ci.debian.net/packages/d/devscripts/unstable/amd64/
² #debci on oftc or debian...@lists.debian.org




signature.asc
Description: OpenPGP digital signature

Bug#898369: breaks ncmpcpp

[Thadeu Lima de Souza Cascardo]

Source: boost1.62
Version: 1.62.0+dfsg-5+b2
Severity: serious

After upgrading boost1.62 to 1.62.0+dfsg-5+b2, ncmpcpp does not start
anymore.

$ ncmpcpp
ncmpcpp: symbol lookup error: ncmpcpp: undefined symbol: 
_ZNK5boost16re_detail_10620031icu_regex_traits_implementation12do_transformEPKiS3_PKN6icu_578CollatorE

$ dpkg -s ncmpcpp | grep Version
Version: 0.8.1-1

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

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

Bug#887586: Fixed

[Bastien ROUCARIES]

control: affects -1 - src:node-vhost

Bug#898356: git-buildpackage: Multiple --git-pbuilder-options do not stack

[Guido Günther]

On Thu, May 10, 2018 at 10:53:47PM +0200, Matthijs Kooijman wrote:
> Hi Guido,
> 
> > > When passing multiple options on the commandline, this is (for me)
> > > unexpected but easily fixed by passing all needed options into a single
> > > --git-pbuilder-options, but when a gbp.conf file also uses
> > > "pbuilder-options", these are also overriden by the commandline, which
> > > is harder to fix (which needs copying the options from the config file
> > > to the commandline).
> >
> > This in fact is intended since otherwise there'd be now way to override
> > what's in gbp.conf (or rather in the several gbp.conf's parsed).
> So you're suggesting to let multiple commandline options stack, but let
> any commandline options override the config file option? That would seem
> a bit confusing to me. Also, that would not allow using the commandline
> to add additional options.
> 
> My suggestion of adding a --git-append-pbuilder-option could solve both
> usecases:
>  - you can use --git-pbuilder-options on the commandline to override all
>previously set options, including in gbp.conf
>  - you can use --git-append-pbuilder-option to extend any previously set
>options.

You would also need to define how option stack over the various gbp.conf
files. I don't think we want to go down that road.
 -- Guido

> At the same time, it would also keep backward compatibility as a bonus.
> 
> (I used a singular, perhaps --git-append-pbuilder-options makes more
> sense, though I guess that depends on whether argument splitting is
> applied or not)
> 
> > There are several levels of quiting going on, gbp itself does not do
> > much but git-pbuilder and pbuilder do.
> Good call. I did a bit of digging, turns out it is cowbuilder that
> messes up, so this is entirely unrelated to this bug report. See
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898366
> 
> Gr.
> 
> Matthijs

Bug#851076: Merge

[Unit 193]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384

Howdy,

I filed a merge request a couple of months ago that should fix this (and
#887662) on salsa[0], Ubuntu seems to have picked it up and shipped it with
their last release.

[0]: https://salsa.debian.org/takaki/gvpe/merge_requests/1

~Unit 193
Unit193 @ OFTC
Unit193 @ freenode

-BEGIN PGP SIGNATURE-

iQIcBAEBCQAGBQJa9LJ/AAoJEFAB4bCao3RLrvUP/2H3DIbCTSMDcCuyUmTz08NT
oGjoApFOjVMYq1kpxOk1lryWUxZclmShWgeUsixJnv8XMDMcdzSVxmbZ6yR/C1wo
ZkoJhDuaHXlsqqcTiYo44UmuaeVbdTmJjLKRrSDE8LaFfOfX/RhvuyY/T8ebc0u9
zpUsQOnnzTYgFoRemg0nO4ITJv8uQVizjZNEAKvVrWCVOZiIWvWZszpesEn5O5eD
Pk+gjek1f5wBekvozjuTcN3P2skTIr+e1OAVD5/KOResIuvZGoHOYGTk75l3UpNj
bMP3mGolpSfTEcLCH7V+2gTrOVGnml5AHT3bJgaq0WTR642+nCw2VIVjwMLcTxjl
ilsOQXya51n5CwRtWmXulrvGcb9xzJjtxfFkoqKLwQtUB3YVePxAZ1t5w1RMmDmd
ximbQUCm/b1UcyA8PT0oQ0AIdTSh+F/9uKL9wIRa225Xwx0PD1z9M+G3hfjc/MJx
KczNF4Eg4DUie1VxOwB07vxBRlGA6vuYojMbiN+a/MZUfitWgiwFqyI/bnckxr0b
L554m77upIl60IEaNb+PqWigYT48snhxftrZ6XMaT8Sg5iroED4VvTyriVHqc7OL
nTJ8bhAWmH7PEXP9hd0OsgQk9d+EbgITMOoJ9Xvm2+WgCraqUzLVRfMJBOQRaw1Y
VEtWManoMQln6oI3+ZzT
=S31p
-END PGP SIGNATURE-

Bug#898368: openvas-manager-common: README.Debian mentions commands not existing in sid

[Frederik Himpe]

Package: openvas-manager-common
Version: 7.0.2-4
Severity: normal

Dear Maintainer,

The README.Debian says to execute these commands:
$ sudo openvas-nvt-sync
$ sudo openvas-scapdata-sync
$ sudo openvas-certdata-sync

However, they don't seem to be present any more in Debian Sid.

-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (600, 'stable'), (550, 'proposed-updates'), (500, 'oldstable'), 
(450, 'oldstable-proposed-updates'), (420, 'testing'), (200, 'unstable'), (160, 
'experimental'), (150, 'oldoldstable'), (140, 'oldoldstable-proposed-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages openvas-manager-common depends on:
ii  gnutls-bin  3.5.18-1

Versions of packages openvas-manager-common recommends:
ii  openvas-manager  7.0.2-4

Versions of packages openvas-manager-common suggests:
ii  gnupg 2.1.18-8~deb9u1
ii  python2.7.13-2
ii  wget  1.18-5+deb9u2
pn  xsltproc  

-- no debconf information

Bug#898273: [lintian] Detect conflict between package.json version and debian control version

[Chris Lamb]

Hi Bastien,

> - for every depends in package.json check debian control depends
  ^^^
Do you mean in the "devDependencies" key? Clarification on exactly
what "check" means here would be needed here too; whilst your bug
title says "detect conflict", that doesn't strictly include the
case of missing dependencies, just as one example..

> - for every optionnal depends on package.json check debian control
>
> suggest or recommand

Did you mean "*in* package.json" (not "on package.json")? If so, I was
not aware package.json have optional dependencies.

(Isn't this stuff autogenerated from the package.json by somen? Then
there could not be a conflict...)

Anyway, I'm sorry can't seem to prase what you are saying and there is
quite a bit of ambiguity.


Best wishes,

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

Bug#898356: git-buildpackage: Multiple --git-pbuilder-options do not stack

[Matthijs Kooijman]

Hi Guido,

> > When passing multiple options on the commandline, this is (for me)
> > unexpected but easily fixed by passing all needed options into a single
> > --git-pbuilder-options, but when a gbp.conf file also uses
> > "pbuilder-options", these are also overriden by the commandline, which
> > is harder to fix (which needs copying the options from the config file
> > to the commandline).
>
> This in fact is intended since otherwise there'd be now way to override
> what's in gbp.conf (or rather in the several gbp.conf's parsed).
So you're suggesting to let multiple commandline options stack, but let
any commandline options override the config file option? That would seem
a bit confusing to me. Also, that would not allow using the commandline
to add additional options.

My suggestion of adding a --git-append-pbuilder-option could solve both
usecases:
 - you can use --git-pbuilder-options on the commandline to override all
   previously set options, including in gbp.conf
 - you can use --git-append-pbuilder-option to extend any previously set
   options.

At the same time, it would also keep backward compatibility as a bonus.

(I used a singular, perhaps --git-append-pbuilder-options makes more
sense, though I guess that depends on whether argument splitting is
applied or not)

> There are several levels of quiting going on, gbp itself does not do
> much but git-pbuilder and pbuilder do.
Good call. I did a bit of digging, turns out it is cowbuilder that
messes up, so this is entirely unrelated to this bug report. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898366

Gr.

Matthijs


signature.asc
Description: PGP signature

Bug#898367: mariadb-server-core-10.1: mysql_install_db requires my_print_defaults, but my_print_defaults is in mariadb-server-10.1

[Alex Hvostov]

Package: mariadb-server-core-10.1
Version: 1:10.1.29-6
Severity: normal

The package mariadb-server-core-10.1 contains the script ‘mysql_install_db’.
That script calls the ‘my_print_defaults’ command, and fails if
my_print_defaults is not installed. The problem is that my_print_defaults is in
mariadb-server-10.1, not mariadb-server-core-10.1.

Please either move mysql_install_db into mariadb-server-10.1, or move
my_print_defaults into mariadb-server-core-10.1.



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

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

Versions of packages mariadb-server-core-10.1 depends on:
ii  libaio1 0.3.111-1
ii  libc6   2.27-3
ii  libjemalloc13.6.0-11
ii  libpcre32:8.39-9
ii  libstdc++6  8-20180402-1
ii  libsystemd0 238-4
ii  mariadb-common  1:10.1.29-6
ii  zlib1g  1:1.2.8.dfsg-5

mariadb-server-core-10.1 recommends no packages.

mariadb-server-core-10.1 suggests no packages.

-- no debconf information

Bug#898354: r-cran-dbi changed from arch=any to arch=all which makes it "unvisible" in unstable (Was: New version of r-bioc-genomicranges breaks autopkgtests of r-bioc-summarizedexperiment in testing)

[Paul Gevers]

Hi Andreas

On 10-05-18 22:08, Andreas Tille wrote:
> On Thu, May 10, 2018 at 12:57:54PM -0500, Dirk Eddelbuettel wrote:
>> | 
>> | ftp.debian.org is the right pseudo-package for removal (of the 0.8-1
>> | packages) from unstable.
>>
>> Ok, thanks, filed as #898354.
> 
> Seems that bug is somehow needed for this specific issue.  However, I
> think I had other packages moved from Arch=any to Arch=all without any
> trouble.  So my question is:  Did something changed in the software
> dealing with those uploads recently or is that package in some other
> aspect different which might cause the observed issue?

You may be right, or maybe somebody behind the scene took action. I now
looked up the cruft report, and r-cran-dbi is mentioned.

https://ftp-master.debian.org/cruft-report-daily.txt

Paul



signature.asc
Description: OpenPGP digital signature

Bug#898366: cowbuilder: Does not support multiple --extrapackages options

[Matthijs Kooijman]

Package: cowbuilder
Version: 0.87+b1
Severity: normal

Hi,

currently, cowbuilder seems to support only one occurance of the
--extrapackages option, where each subsequent occurance overrides the
previous one.

E.g.:

sudo -E cowbuilder --build --extrapackages=a.deb --extrapackages=b.deb some.dsc

results in:

I: forking: pbuilder build --buildplace
  /var/cache/pbuilder/build/cow.22054 --buildresult
  /var/cache/pbuilder/result/ --mirror http://ftp.nl.debian.org/debian
  --distribution sid --extrapackages b.deb --no-targz
  --internal-chrootexec 'chroot /var/cache/pbuilder/build/cow.22054
  cow-shell' some.dsc

Which only has the latter package.

The source code (0.87) seems to agree on this:

} else if (!strcmp(long_options[index_point].name,
 "extrapackages")) {
  /* this is for qemubuilder and cowbuilder (adds cowdancer) */
  pc.extrapackages = strdup(optarg);
}

However, pbuilder allows specifying this option multiple times:

--extrapackages [packages to add]
  Adds packages specified as an addition to the default, which is 
build-essential by default.  This is used in build and create (after success‐
  fully creating the initial chroot) and update.

  The packages should be specified as a space-delimited list, or by 
specifying --extrapackages multiple times.


It would make sense for cowbuilder to support this as well, or if not
at least raise an error when multiple --extra-packages options are
given.

Gr.

Matthijs

Bug#887586: Fixed

[Bastien ROUCARIES]

control: affects -1 - src:node-compression

Bug#898338: plasma-workspace: Different components hang, high CPU load

[Dominik George]

OK, I found something:

When I kill plasmashell and start it again, in a terminal, I get the
following several times per second:

KActivities: Database can not be opened in WAL mode. Check the SQLite version 
(required >3.7.0). And whether your filesystem supports shared memory
Closing SQL connection:  "kactivities_db_resources_139838218086080_readonly"
KActivities ERROR: There is no database. This probably means that you do not 
have the Activity Manager running, or that something else is broken on your 
system. Recent documents and alike will not work!
KActivities: FATAL ERROR: Failed to contact the activity manager daemon

The last message of these is also filling up mi .xsession-errors, so I
figure it's the same error that is causing the hangs.

-nik


signature.asc
Description: PGP signature

Bug#898365: nftables: autopkgtest fails with new version while succeeded in the past: ImportError: No module named nftables

[Paul Gevers]

Source: nftables
Version: 0.8.4-1
Severity: normal
User: debian...@lists.debian.org
Usertags: regression

With the upload of version 0.8.4-1 of nftables, the autopkgtest¹
started to fail with the error copied below.

Please fix your autopkgtest, your package currently needs 15 days
instead of 5 to migrate to testing².

Paul

¹ https://ci.debian.net/packages/n/nftables/testing/amd64/
² https://qa.debian.org/excuses.php?package=nftables

autopkgtest [15:48:57]: test internaltest-py.sh: [---
Traceback (most recent call last):
  File "./nft-test.py", line 1180, in 
main()
  File "./nft-test.py", line 1112, in main
from nftables import Nftables
ImportError: No module named nftables
autopkgtest [15:48:58]: test internaltest-py.sh: ---]




signature.asc
Description: OpenPGP digital signature

Bug#887586: Fixed

[Bastien ROUCARIES]

control: affects -1 - src:node-errorhandler

Bug#898268: Lookup strings

[Geert Stappers]

On Wed, May 09, 2018 at 10:27:53PM +0200, Frédéric BURLET wrote:
> libkcddb is invoked successfully.

Okay


> I have the impression that is the addition of the found item in the
> collection that fails this time.

I don't understand what you trying to say.



In the original report was:

} Reproducable with any Audio CD.
} 
} When running Tellico in console, the output is the following:
} 
} ~$ tellico
} libkcddb: Looking up  "61096f07"  in CDDB cache
 ^^^
} Cache files found:  0
} libkcddb: Found  0  hit(s)
} Should lookup  "Z_Cic1WDJdHRQv5t88WiUfU.Xs0-"
  ^^^
} ResourceNotFound Exception: ' Resource not found error: 404 Not Found '
} LastResult:  6
} LastHTTPCode:  404
} LastErrorMessage:  "404 Not Found"


The strings "61096f07" and "Z_Cic1WDJdHRQv5t88WiUfU.Xs0-"
are they the same for each Audio CD?



Groeten
Geert Stappers
Doesn't use Tellico, still cares somewhat about the bugreports ...
-- 
Leven en laten leven

Bug#861670: man page for sqldiff

[Kari Pahula]

tags 861670 + patch
thanks

I wrote a man page for sqldiff based on the html page.
.TH sqldiff 1 "2018-05-10"
.SH sqldiff
sqldiff - sqlite3 database difference utility
.SH SYNOPSIS
.B sqldiff
.RI [ options ]
.I database1.sqlite database2.sqlite
.SH DESCRIPTION
The
.B sqldiff
binary is a command-line utility program that displays the differences
between SQLite databases.  The usual output is an SQL script that will
transform
.I database1.sqlite
(the "source" database) into
.I database2.sqlite
(the "destination" database).

The
.B sqldiff
utility works by finding rows in the source and destination that are
logical "pairs". The default behavior is to treat two rows as pairs if
they are in tables with the same name and they have the same rowid, or
in the case of a WITHOUT ROWID table if they have the same PRIMARY
KEY. Any differences in the content of paired rows are output as
UPDATEs. Rows in the source database that could not be paired are
output as DELETEs. Rows in the destination database that could not be
paired are output as INSERTs.

The
.B --primarykey
flag changes the pairing algorithm slightly so that the
schema-declared PRIMARY KEY is always used for pairing, even on tables
that have a rowid. This is often a better choice for finding
differences, however it can lead to missed differences in the case of
rows that have one or more PRIMARY KEY columns set to NULL.
.SH OPTIONS
.TP
.BI \-\-changset\  FILE
Do not write changes to standard output. Instead, write a (binary)
changeset file into
.IR FILE .
The changeset can be interpreted using the sessions extension to
SQLite.
.TP
.BI \-\-lib\fR\  LIBRARY\fR,\  \-L\fR\  LIBRARY
Load the shared library or DLL file
.I LIBRARY
into SQLite prior to computing the differences. This can be used to
add application-defined collating sequences that are required by the
schema.
.TP
.B --primarykey
Use the schema-defined PRIMARY KEY instead of the rowid to pair rows
in the source and destination database. (See additional explanation
below.)
.TP
.B --schema
Show only differences in the schema not the table content
.TP
.B --summary
Show how many rows have changed on each table, but do not show the
actual changes
.TP
.BI --table\fR\  TABLE
Show only the differences in content for
.IR TABLE ,
not for the entire database
.TP
.B --transaction
Wrap SQL output in a single large transaction
.TP
.B --vtab
Add support for handling FTS3, FTS5 and rtree virtual tables. See
below for details.
.SH LIMITATIONS
The
.B sqldiff
utility is unable to compute differences for rowid tables for which
the rowid is inaccessible. An example of a table with an inaccessible
rowid is:

.nf
CREATE TABLE inaccessible_rowid(
   "rowid" TEXT,
   "oid" TEXT,
   "_rowid_" TEXT
);
.fi

The
.B sqldiff
utility does not (currently) display differences in TRIGGERs or VIEWs.

By default, differences in the schema or content of virtual tables are
not reported on.

However, if a virtual table implementation creates real tables
(sometimes referred to as "shadow" tables) within the database to
store its data in, then sqldiff.exe does calculate the difference
between these. This can have surprising effects if the resulting SQL
script is then run on a database that is not exactly the same as the
source database. For several of SQLite's bundled virtual tables (FTS3,
FTS5, rtree and others), the surprising effects may include corruption
of the virtual table content.

If the
.B --vtab
option is passed to
.BR  sqldiff ,
then it ignores all underlying shadow tables belonging to an FTS3,
FTS5 or rtree virtual table and instead includes the virtual table
differences directly.
.SH SEE ALSO
.BR sqlite3 (1).

Bug#898364: znc: Please consider enabling tests at build time

[Unit 193]

Package: znc
Severity: wishlist

Dear Maintainer,

While looking into updating the packaging for the alpha releases, I noticed 
that it'd be trivial to enable the tests.  If you're interested, the below 
patch would achieve said task.


diff --git a/debian/changelog b/debian/changelog
index 052197e..c60ab70 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+znc (1.7.0-2) unstable; urgency=medium
+
+  * d/control: Build-depend on google-mock and googletest.
+  * d/rules:
+- Drop DEB_BUILD_OPTIONS+=nocheck, enabling tests.
+- Update configure flags to find system gmock and gtest.
+
+ -- Unit 193   Thu, 10 May 2018 16:12:13 -0400
+
 znc (1.7.0-1) unstable; urgency=high
 
   * New upstream release.
diff --git a/debian/control b/debian/control
index a8dc9ed..22864a3 100644
--- a/debian/control
+++ b/debian/control
@@ -11,6 +11,8 @@ Build-Depends: debhelper (>= 11),
  libsasl2-dev,
  swig3.0,
  dh-python,
+ google-mock,
+ googletest,
  python3-dev
 Maintainer: Patrick Matthäi 
 Standards-Version: 4.1.4
diff --git a/debian/rules b/debian/rules
index e61e968..c1fba08 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,6 @@
 #!/usr/bin/make -f
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
-export DEB_BUILD_OPTIONS+=nocheck
 
 DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
@@ -15,7 +14,9 @@ DEB_CONFIGURE_EXTRA_FLAGS := \
--enable-tcl \
--enable-cyrus \
--enable-perl \
-   --enable-python
+   --enable-python \
+   --with-gtest=/usr/src/googletest/googletest \
+   --with-gmock=/usr/src/googletest/googlemock
 
 %:
dh $@ --with python3



~Unit 193
Unit193 @ OFTC
Unit193 @ freenode

Bug#898338: plasma-workspace: Different components hang, high CPU load

[Dominik George]

Interesting observation:

When the panel catches up and does something, it seems to still be stuck
somewhere back in time: It froze at 21:52, when I noticed, my wall clock
showed 22:12.  At 22:17, the panel clock jumped to 21:59, some task
switching requests got handled and my sound volume exploded (because some
5-6 minutes back, I used the volume up key).

All applications not linked directly to Plasma work absolutely flawlessly
and fast.


signature.asc
Description: PGP signature

Bug#796129: Beyond greyed out

[Geert Stappers]

On Wed, May 09, 2018 at 10:27:53PM +0200, Frédéric BURLET wrote:
> On Wednesday, May 9, 2018 5:15:10 PM CEST Geert Stappers wrote:
> > 
> > That might be related to
> >  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796129
> >  Build of tellico is missing support for cddb
> 
> I don't think so. Since in the bug 796129, the option was greyed out because 
> of the missing dependency. Now, the option is enabled and as you can see in 
> the output I pasted, libkcddb is invoked successfully.

Okay


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#898356: git-buildpackage: Multiple --git-pbuilder-options do not stack

[Guido Günther]

On Thu, May 10, 2018 at 09:29:57PM +0200, Matthijs Kooijman wrote:
> Hi Guido,
> 
> I noticed one more related thing, also possibly a bug. It seems that the
> arguments to --git-pbuilder-options are further processed. I tried
> running this command:
> 
> gbp buildpackage --git-pbuilder-options=--extrapackage=/foo/a.deb\ 
> --extrapackage=/foo/b.deb\ --bindmounts=/foo
> 
> Which resulted in this pbuilder command:
> 
> I: forking: pbuilder build --debbuildopts  --debbuildopts
>   --bindmounts /foo --buildplace /var/cache/pbuilder/build/cow.31796 
> --buildresult /tmp
>   --extrapackages /foo/b.deb --no-targz --internal-chrootexec
>   'chroot /var/cache/pbuilder/build/cow.31796 cow-shell'
>   /tmp/openttd-opengfx_0.5.4-2.dsc
> 
> 
> Interesting is that the --bindmounts and --extrapackages are no longer
> adjacent, and that only the second --extrapackages is present. This
> behaviour is even more surprising to me, and I'd think this would
> certainly constitute a bug (at least the latter).

There are several levels of quiting going on, gbp itself does not do
much but git-pbuilder and pbuilder do. You can set GIT_PBUILDER_DEBUG
env var to see how git-pbuilder passes arguments to pbuilder. Only then
can you tell who mixed up the arguments.
Cheers,
 -- Guido

Bug#898338: plasma-workspace: Different components hang, high CPU load

[Dominik George]

Heisann,

> You might want to try using a 4.15 kernel till:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898021
> gets fixed. If the issue solves itself using a 4.15 kernel please send
> a mail to this bug with line saying Control: block 898338 with 898021

Unfortunately, the issue persists, even with kernels as old as 4.13 (I did
not test older ones).

Cheers,
Nik


signature.asc
Description: PGP signature

Bug#898317: xdg-open: Argument injection in xdg-open open_envvar

[Salvatore Bonaccorso]

Control: found -1 1.1.0~rc1+git20111210-7.4

The issue seems present as well in earlier version, though in upstream
commit 3c2fe9f1ebbfdbffcc9e38a767641805cec3340b this part was
refactored.

Bug#897373: libc6: feof(file) always false when forking after read

[Florian Weimer]

* David Beniamine:

> On Thu, May 10, 2018 at 07:06:03PM +0200, Florian Weimer wrote:
>> * David Beniamine:
>> 
>> > int do_fork() {
>> > pid_t pid;
>> >
>> > switch (pid = fork()) {
>> > case -1:
>> > fprintf(stderr, "Fork failed\n");
>> > return -1;
>> > case 0:
>> > exit(-1);
>> 
>> Does the issue go away when you call _exit instead of exit?
>> 
> It goes away with _exit, indeed.

According to POSIX, exit is required to flush all streams, and fflush
is required to reset the position of the underlying file descriptor
(more precisely, the open file description) to the current read
position.  That affects the descriptor in the parent, too.  I'm not
sure if this is actually a glibc bug.

Bug#887586: Fixed

[Bastien ROUCARIES]

control: affects -1 - src:node-cookie-parser

Bug#887586: workarround

[Bastien ROUCARIES]

control: tags -1 + patch

problematic package should be updated or use mocha --exit

Bug#898273: [lintian] Detect conflict between package.json version and debian control version

[roucaries bastien]

On Wed, May 9, 2018 at 8:34 PM, Chris Lamb  wrote:
> Hi Bastien,
>
>> If package is section javascript search all file named package.json, parse it
>> and control against control depends (including optional that go to recommand
>   
>> or suggest).
>   ^^

Ok test will be run:
- unless section javascript bail out
- for every depends in package.json check debian control depends
- for every optionnal depends on package.json check debian control
suggest or recommand

bastien


>
> I can't parse this, sorry. Could you rephrase? :)
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Bug#898356: git-buildpackage: Multiple --git-pbuilder-options do not stack

[Matthijs Kooijman]

Hi Guido,

I noticed one more related thing, also possibly a bug. It seems that the
arguments to --git-pbuilder-options are further processed. I tried
running this command:

gbp buildpackage --git-pbuilder-options=--extrapackage=/foo/a.deb\ 
--extrapackage=/foo/b.deb\ --bindmounts=/foo

Which resulted in this pbuilder command:

I: forking: pbuilder build --debbuildopts  --debbuildopts
  --bindmounts /foo --buildplace /var/cache/pbuilder/build/cow.31796 
--buildresult /tmp
  --extrapackages /foo/b.deb --no-targz --internal-chrootexec
  'chroot /var/cache/pbuilder/build/cow.31796 cow-shell'
  /tmp/openttd-opengfx_0.5.4-2.dsc


Interesting is that the --bindmounts and --extrapackages are no longer
adjacent, and that only the second --extrapackages is present. This
behaviour is even more surprising to me, and I'd think this would
certainly constitute a bug (at least the latter).

Gr.

Matthijs


signature.asc
Description: PGP signature

Bug#898363: RFS: wrapperfactory.app/0.1.0-5

[Yavor Doganov]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "wrapperfactory.app".

 * Package name: wrapperfactory.app
   Version : 0.1.0-5
   Upstream Author : Raffael Herzog 
 * URL : N/A
 * License : GPL-2
   Section : gnustep

It builds this binary package:

wrapperfactory.app - Application wrappers configuration tool for GNUstep

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

  https://mentors.debian.net/package/wrapperfactory.app

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

  dget -x 
https://mentors.debian.net/debian/pool/main/w/wrapperfactory.app/wrapperfactory.app_0.1.0-5.dsc

Or clone the Git repository:

  https://salsa.debian.org/gnustep-team/wrapperfactory.app

Changes since the last upload:

  * debian/compat: Bump to 11.
  * debian/rules: Rewrite for modern dh.  Don't include dpatch.make.
Don't generate/install the .xpm icon.  Enable all hardening.  Move the
.gorm files to /usr/share as well.
  * debian/control: Run wrap-and-sort -ast.
(Build-Depends): Remove dpatch and imagemagick.  Bump debhelper to
>= 11.  Require gnustep-make >= 2.7.0-3 for noopt support.
(Depends): Remove ${gnustep:Depends}; obsolete.
(Vcs-Arch): Replace with Vcs-Git.
(Vcs-Browser): New field.
(Standards-Version): Claim compliance with 4.1.4 as of this release.
  * debian/source/format: Set to 3.0 (quilt).
  * debian/patches/00list: Rename as...
  * debian/patches/series: ...and update.
  * debian/patches/05_objdir.dpatch: Delete, no longer necessary.
  * debian/patches/10_libGSWrapper_libobjc.dpatch: Rename as...
  * debian/patches/link-libs.patch: ...and quiltify.
  * debian/patches/make-v2-strict.patch: New; fix FTBFS with gnustep-make
in strict v2 mode, adapt code to a v2 environment (Closes: #897620).
  * debian/patches/gcc-warnings.patch: New; fix some GCC warnings.
  * debian/README.source: Delete; useless.
  * debian/menu: Delete as per policy requirement.
  * debian/manpages: New file.
  * debian/WrapperFactory.desktop: Set Icon to the actual file in
/usr/share.  Add Keywords key.
  * debian/watch: Replace with a dummy one as upstream's site is gone.
  * debian/maintscript: New; handle the move from dir to symlink.
  * debian/copyright: Rewrite in format 1.0.

Bug#888095: [debian-mysql] Bug#888095:

[Otto Kekäläinen]

2018-05-10 21:59 GMT+03:00 Emilio Pozuelo Monfort :
> Hi Otto,
>
> On 10/05/18 20:24, Otto Kekäläinen wrote:
>> Hello!
>>
>> MariaDB 10.3 needs to be finalized and imported into Debian. After
>> that all the mess that are a fallout of a misfortunate upload of
>> mariadb-10.2 to Debian unstable will start to become resolved. Until
>> then we need to live with this, sorry.
>
> What's your plan? Remove src:mariadb-connector-c and ship libmariadb3 from
> src:mariadb-10.3?

The plan is to continue ship src:mariadb-connector-c like has been
done so far and no plans to change that.

The src:mariadb-10.2 unfortunately messed up with this.

Bug#671544: dh_compress: Optionally compress with bzip2 or xz

[Niels Thykier]

Control: tags -1 wontfix

On Sat,  5 May 2012 00:17:44 +0200 (CEST) Axel Beckert 
wrote:
> Package: debhelper
> Version: 9.20120419
> Severity: wishlist
> 
> Dear Joey,
> 
> it would be neat, if dh_compress would have command line options similar
> to dpkg-source to allow different compression methods and maybe also
> other compression levels than the hardcoded 9, e.g.
> 
>   dh_compress --compression-level=6 --compression=xz
>   dh_compress -z7 -Zbzip2
> 
> [...]

Hi,

Thanks for the suggestion.

I have decided to tag this bug as "wontfix".  While it seems attractive
at first glance to support this, a lot of files handled by dh_compress
must still use gzip (e.g. manpages and changelogs) so the option would
complicate dh_compress to support compressing parts with gzip and part
with the compression of choice from the maintainers.

Thanks,
~Niels

Bug#898356: git-buildpackage: Multiple --git-pbuilder-options do not stack

[Guido Günther]

control: severity -1 wishlist

Hi Matthijs,
On Thu, May 10, 2018 at 08:06:58PM +0200, Matthijs Kooijman wrote:
> Package: git-buildpackage
> Version: 0.9.8
> Severity: normal
> 
> Hi Guido,
> 
> I was using the --git-pbuilder-options option to gbp-buildpackage today,
> and was surprised that multiple options do not stack. Instead, each
> --git-pbuilder-options passed overrides the previous one, so only the
> last one is effective.

Yes that's the current behaviour. I agree that having all --git-pbuilder
option appended and not overwritten would be nicer. I wouldn't worry
about backward compatibility here.

> 
> When passing multiple options on the commandline, this is (for me)
> unexpected but easily fixed by passing all needed options into a single
> --git-pbuilder-options, but when a gbp.conf file also uses
> "pbuilder-options", these are also overriden by the commandline, which
> is harder to fix (which needs copying the options from the config file
> to the commandline).

This in fact is intended since otherwise there'd be now way to override
what's in gbp.conf (or rather in the several gbp.conf's parsed).

Cheers,
 -- Guido

Bug#898362: umbrello: Umbrello does not retain size and position of boxes and labels when reopening the xmi file

[Pr0metheus]

Package: umbrello
Version: 4:17.08.3-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

Create a class diagram. Resize class boxes and place labels in different
position than the default. Save project and close. Open again the project and
the class diagram and all custom resizing and placements are gone.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Cannot fix this.

   * What outcome did you expect instead?

Preserve after save the content size and place



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

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

Versions of packages umbrello depends on:
ii  kinit 5.45.0-1
ii  kio   5.45.0-1
ii  libc6 2.27-3
ii  libkf5archive55.45.0-1
ii  libkf5completion5 5.45.0-1
ii  libkf5configcore5 5.45.0-1
ii  libkf5configgui5  5.45.0-1
ii  libkf5configwidgets5  5.45.0-1
ii  libkf5coreaddons5 5.45.0-1
ii  libkf5crash5  5.45.0-1
ii  libkf5i18n5   5.45.0-1
ii  libkf5iconthemes5 5.45.0-1
ii  libkf5jobwidgets5 5.45.0-1
ii  libkf5kiocore55.45.0-1
ii  libkf5kiowidgets5 5.45.0-1
ii  libkf5texteditor5 5.45.0-1
ii  libkf5textwidgets55.45.0-1
ii  libkf5widgetsaddons5  5.45.0-1
ii  libkf5xmlgui5 5.45.0-1
ii  libqt5core5a  5.10.1+dfsg-6
ii  libqt5gui55.10.1+dfsg-6
ii  libqt5printsupport5   5.10.1+dfsg-6
ii  libqt5svg55.10.1-2
ii  libqt5webkit5 5.212.0~alpha2-9
ii  libqt5widgets55.10.1+dfsg-6
ii  libqt5xml55.10.1+dfsg-6
ii  libstdc++68.1.0-1
ii  libxml2   2.9.4+dfsg1-6.1+b1
ii  libxslt1.11.1.29-5

umbrello recommends no packages.

Versions of packages umbrello suggests:
pn  khelpcenter  

-- no debconf information

Bug#898022: diffoscope: Traceback when comparing paths with invalid unicode characters

[Mattia Rizzolo]

Control: clone -1 -2
Control: tag -2 - patch
Control: severity -2 wishlist
Control: retitle -2 diffoscope: should handle the filenames as bytes

On Thu, May 10, 2018 at 06:01:50PM +0200, Mattia Rizzolo wrote:
> I believe that, like that bug is showing, we should just specify
> type=os.fsencode# 
> https://docs.python.org/3/library/os.html#os.fsencode
> in the parser.add_argument() calls using a filename (to make sure
> argparse doesn't change output)

This indeed makes the filename be a .bytes through all the code, and
therefore requires a bunch of changes pretty much everywhere in the
comparators (str.endsiwth → bytes.endswith and with them all the
comparing strings needs to be become bytes as well).

I'm cloning this bug to keep track of this thing, as I'm not going to do
that now.
Initial patch to start (from there just try run it and it will crash)
  |--- a/diffoscope/main.py
  |+++ b/diffoscope/main.py
  |@@ -74,11 +74,13 @@ def create_parser():
  | parser = argparse.ArgumentParser(
  | description='Calculate differences between two files or 
directories',
  | add_help=False, formatter_class=HelpFormatter)
  |-parser.add_argument('path1', nargs='?', help='First file or directory 
to '
  |-'compare. If omitted, tries to read a diffoscope 
diff from stdin.')
  |-parser.add_argument('path2', nargs='?', help='Second file or directory 
to '
  |-'compare. If omitted, no comparison is done but 
instead we read a '
  |-'diffoscope diff from path1 and will output this in 
the formats '
  |+parser.add_argument('path1', nargs='?', type=os.fsencode,
  |+help='First file or directory to compare. If 
omitted, '
  |+'tries to read a diffoscope diff from stdin.')
  |+parser.add_argument('path2', nargs='?', type=os.fsencode,
  |+help='Second file or directory to compare. If 
omitted, '
  |+'no comparison is done but instead we read a 
diffoscope '
  |+'diff from path1 and will output this in the 
formats '
  | 'specified by the rest of the command line.')
  | parser.add_argument('--debug', action='store_true',
  | default=False, help='Display debug messages')
  |


Also, I believe doing that change also requires changing the handling of
the filenames in the Container objects, thanks to diffoscope's
recursivity.  So really, a quite big change.


In the meantime to fix #898022 I'll apply the patch I posted earlier.

-- 
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#897671: u-boot does not work on sheevaplug

[Markus Krebs]

Am 10.05.2018 um 20:10 schrieb Vagrant Cascadian:

On 2018-05-09, Markus Krebs wrote:

Am 09.05.2018 um 14:33 schrieb klaus.go...@theobroma-systems.com:

On 09.05.2018, at 10:19, Markus Krebs  wrote:
Am 08.05.2018 um 22:54 schrieb Vagrant Cascadian:

On 2018-05-08, Vagrant Cascadian wrote:

On 2018-05-05, Tom Rini wrote:

On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:

Markus Krebs discovered that the sheevaplug target has again grown and
installation overlaps where the u-boot env is saved since u-boot
~2017.09. Running saveenv overwrites u-boot, and installing u-boot
overwrites any prior environment settings.

...

And setting SYS_THUMB_BUILD=y as well as disabling EFI_LOADER gets it
down to 432k! Thanks to beeble for the suggestion.
Anyone who has a sheevaplug can test that it actually boots with
CONFIG_SYS_THUMB_BUILD=y enabled?


I could test it, but I don't know the config-file where I can change
those options (EFI_LOADER, CONFIG_SYS_THUMB_BUILD).


Both are Kconfig options. So just disable it via menuconfig or in your .config 
file


Thanks. The modified u-boot (size indeed 441592 bytes only) boots!


Can you try with CONFIG_SYS_THUMB_BUILD=y only (e.g. leave EFI_LOADER at
the default).


Yes, it works (size now 473740 bytes)!

Bug#898360: openjdk-10: broken link to src.zip (see #893134)

[Patrice Duroux]

Package: openjdk-10-source
Version: 10.0.1+10-4
Severity: normal
File: openjdk-10

Dear Maintainer,
It would help Eclipse to provide tooltip javadoc and be able to open source 
code of JRE classes.
Thanks,
Patrice

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

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

Versions of packages openjdk-10-source depends on:
ii  openjdk-10-jdk  10.0.1+10-4

openjdk-10-source recommends no packages.

openjdk-10-source suggests no packages.

-- no debconf information

Bug#898343: /lib/hdparm/hdparm-functions cause kernel ata errors

[Alex Mestiashvili]

On 05/10/2018 08:47 PM, Pali Rohár wrote:
> On Thursday 10 May 2018 20:39:26 Alex Mestiashvili wrote:
>> Thank you for reporting and providing the workaround, but this issue is
>> already fixed in hdparm version 9.54+ds-1.
>> See this bug for the details:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23891051
> 
> Ou, I have not know about it.
> 
> I just started again to workaround this bug about which I discussed 3
> years ago at lkml: https://lkml.org/lkml/2015/8/1/120
> 
> Anyway, that check for ID_ATA_FEATURE_SET_APM is working for me too, so
> I'm happy with it. Is there any chance to backport that fix into stable
> debian?
> 

I guess so, should be doable. The changes between stable and testing are
not really significant, mostly bug fixes from upstream and debian side.
I'll have a look on it.

Bug#898359: tiff: CVE-2018-10779: TIFFWriteScanline in tif_write.c has a heap-based buffer over-read

[Salvatore Bonaccorso]

Source: tiff
Version: 4.0.9-1
Severity: important
Tags: security upstream
Forwarded: http://bugzilla.maptools.org/show_bug.cgi?id=2788
Control: found -1 4.0.3-12.3

Hi,

The following vulnerability was published for tiff, basically filling
as tracking bug until upstream fixes know an affected versions can be
double checked again, but this should go back to 4.0.3-12.3.

CVE-2018-10779[0]:
| TIFFWriteScanline in tif_write.c in LibTIFF 3.8.2 has a heap-based
| buffer over-read, as demonstrated by bmp2tiff.

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-10779
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10779
[1] http://bugzilla.maptools.org/show_bug.cgi?id=2788

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#888095: [debian-mysql] Bug#888095:

[Emilio Pozuelo Monfort]

Hi Otto,

On 10/05/18 20:24, Otto Kekäläinen wrote:
> Hello!
> 
> MariaDB 10.3 needs to be finalized and imported into Debian. After
> that all the mess that are a fallout of a misfortunate upload of
> mariadb-10.2 to Debian unstable will start to become resolved. Until
> then we need to live with this, sorry.

What's your plan? Remove src:mariadb-connector-c and ship libmariadb3 from
src:mariadb-10.3?

Cheers,
Emilio

Bug#898358: sympa: dependency differences from upstream

[Matt Taggart]

Package: sympa
Version: 6.2.32~dfsg-1

I was reviewing upstream src/lib/Sympa/ModDef.pm, and comparing with the 
package Depends and found the following differences in dependencies in 
debian/control that I didn't understand. Maybe there are reasons for 
them or maybe they need to be added?


Missing Depends:
ModDef.pm   debian package name

Clone   libclone-perl (but pulled in via libdbd* ->
libdbi-perl -> libclone-perl)
Crypt::Eksblowfish  libcrypt-eksblowfish-perl
Data::Password  libdata-password-perl
DateTime::TimeZone  libdatetime-timezone-perl (but pulled in
 via libdatetime-format-mail-perl ->
 libdatetime-perl -> libdatetime-timezone-perl )
Encode::Locale  libencode-locale-perl
List::Util::XS  N/A, ModDef.pm says:
# The pure-perl version of Scalar::Util::looks_like_number() was unstable.
# To force using XS version, check existence of List::Util::XS.
URI::Escape liburi-perl

Depends but not in ModDef.pm:
libmsgcat-perl

libcrypt-ciphersaber-perl is in recommends, the text in ModDef.pm says:
Crypt::CipherSaber
this module provides reversible encryption of user passwords in the 
database.

Useful when updating from old version with password reversible encryption,
or if secure session cookies in non-SSL environments are required.

Is that always used or optional?

--
Matt Taggart
tagg...@debian.org

Bug#888095: [debian-mysql] Bug#888095:

[Otto Kekäläinen]

Hello!

MariaDB 10.3 needs to be finalized and imported into Debian. After
that all the mess that are a fallout of a misfortunate upload of
mariadb-10.2 to Debian unstable will start to become resolved. Until
then we need to live with this, sorry.

Bug#898343: /lib/hdparm/hdparm-functions cause kernel ata errors

[Pali Rohár]

On Thursday 10 May 2018 20:39:26 Alex Mestiashvili wrote:
> Thank you for reporting and providing the workaround, but this issue is
> already fixed in hdparm version 9.54+ds-1.
> See this bug for the details:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23891051

Ou, I have not know about it.

I just started again to workaround this bug about which I discussed 3
years ago at lkml: https://lkml.org/lkml/2015/8/1/120

Anyway, that check for ID_ATA_FEATURE_SET_APM is working for me too, so
I'm happy with it. Is there any chance to backport that fix into stable
debian?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#898343: /lib/hdparm/hdparm-functions cause kernel ata errors

[Alex Mestiashvili]

Thank you for reporting and providing the workaround, but this issue is
already fixed in hdparm version 9.54+ds-1.
See this bug for the details:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23891051

Bug#898224: Problems to recreate minimized JS in r-cran-jsonld

[David I. Lehn]

On Wed, May 9, 2018 at 5:35 AM, Andreas Tille  wrote:
> I was stumbling upon an issue with some minimized JS in the package
> r-cran-jsonld (ITPed in #898224).  I tried to recreate jsonld.min.js and
> have written a script[1] which calls webpack in a clone of the Github
> reporsitory.  Unfortunately the webpack call ends in:
>
> webpack-merge@4.1.2 node_modules/webpack-merge
> └── lodash@4.17.10
> ...
> ERROR in multi regenerator-runtime/runtime core-js/fn/array/includes 
> core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
> core-js/fn/symbol ./lib/index.js
> Module not found: Error: Can't resolve 'babel-loader' in 
> '/home/andreas/debian-maintain/salsa/r-pkg-team/0_prospective/r-cran-jsonld/debian/JS/jsonld.js'
>  @ multi regenerator-runtime/runtime core-js/fn/array/includes 
> core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
> core-js/fn/symbol ./lib/index.js
> ...
> Any idea how to get the minimized JS?  Simply taking the non-minimized
> jsonld.js does not work.  The file size of this uncompressed file is way
> smaller than the minimazion result and doese not work together with the
> R code.  Thus I really need to undergo the process to create the
> minimized JS.
>
> Any idea how to approach this?
> ...
> [1] 
> https://salsa.debian.org/r-pkg-team/r-cran-jsonld/blob/master/debian/JS/get-jsonld.min
>

Hi, I'm an upstream developer for jsonld.js and the one to blame for
the webpack config. ;-)  I'm getting 404 on that salsa repo so I'm not
sure what your script is doing.  In npm world you can build
jsonld.min.js with "npm install && npm run build-webpack".  That's how
it's published to npm.  I've never tried building with apt installed
modules.  If upstream changes would help make this all easier, let me
know.

-dave

Bug#898357: poppler: CVE-2017-18267: infinite loop in FoFiType1C::cvtGlyph in FoFiType1C.cc

[Salvatore Bonaccorso]

Source: poppler
Version: 0.63.0-2
Severity: important
Tags: patch security upstream
Forwarded: https://bugs.freedesktop.org/show_bug.cgi?id=103238

Hi,

The following vulnerability was published for poppler.

CVE-2017-18267[0]:
| The FoFiType1C::cvtGlyph function in fofi/FoFiType1C.cc in Poppler
| through 0.64.0 allows remote attackers to cause a denial of service
| (infinite recursion) via a crafted PDF file, as demonstrated by
| pdftops.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-18267
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-18267
[1] https://bugs.freedesktop.org/show_bug.cgi?id=103238

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#897238: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

[Sébastien Villemot]

On Sun, May 06, 2018 at 08:29:29AM +, Lumin wrote:

> > He put forward a simpler solution: Just don't provide libblas.so.3, such
> > that MKL will never be used to satisfy the dependency of libblas.so.3 .
> > Based on his idea, my new solution is the follows:
> > 
> >   libmkl-rt --
> >   Depends: libblas3 | libblas.so.3
> >   Provides: NOTHING  ... (4)
> > 
> > So it's totally safe now. If there is MKL, there must be a free
> > libblas.so.3 implementation with a priority definitely larger than 1,
> > overriding MKL in terms of auto-mode alternatives. On the other hand,
> > if that alternative is manually set, then there is nothing to worry
> > about. This solution is also able to resolve problems found in (1) and (3).
> 
> Now libmkl-rt doesn't provide libblas.so.3 and liblapack.so.3, and it
> pre-depends on libblas3 | libblas.so.3 and liblapack3 | liblapack.so.3 .
> Similar change was applied to libmkl-dev.

Using a Pre-Depends here is IMO wrong. Quoting Policy §7.2:

 Pre-Depends should be used sparingly, preferably only by packages whose
 premature upgrade or installation would hamper the ability of the system to
 continue with any upgrade that might be in progress.

 You should not specify a Pre-Depends entry for a package before this has been
 discussed on the debian-devel mailing list and a consensus about doing that
 has been reached. See Dependencies.

I also think that removing the Provides is not a good idea. The alternative is
provided by the package, and that should be made clear in the dependency
relationships.

I'm sorry but I don't have an ideal solution to the problems we previously
discussed. But IMO it's acceptable to not perfectly deal with the corner case
where only MKL is installed, as long as some warning is displayed.

> Previously Sébastien expressed his interest on benchmarking. I'm
> interested in that too. So apart from the debconf part, I wrote a simple
> benchmarker[4] in Julia[5] for comparing several BLAS implementations.
> Thanks to Julia's convenient FFI functionality, I can test all
> implementations within a single run, without any modification to environment
> variable or alternatives.
> 
> Test result on my laptop (CPU=i5-7440HQ) matches expectation:
> 
> dnrm2 Julia
>   0.33 seconds
> dnrm2 /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0
>   0.74 seconds (3 allocations: 48 bytes)
>   dnrm2 Error :1.1368683772161603e-13
> dnrm2 /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3.10.3
>   0.38 seconds (3 allocations: 48 bytes)
>   dnrm2 Error :0.0
> dnrm2 /usr/lib/x86_64-linux-gnu/libopenblas_haswellp-r0.2.20.so
>   0.31 seconds (3 allocations: 48 bytes)
>   dnrm2 Error :0.0
> dnrm2 /usr/lib/x86_64-linux-gnu/libmkl_rt.so
>   0.029561 seconds (3 allocations: 48 bytes)
>   dnrm2 Error :0.0
> dgemm Julia
>   4.362279 seconds (2 allocations: 128.000 MiB, 0.20% gc time)
> dgemm /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0
>  47.893710 seconds (10 allocations: 160 bytes)
>   dgemm Error :2.0735139719127268e-10
> dgemm /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3.10.3
>  10.412422 seconds (10 allocations: 160 bytes)
>   dgemm Error :2.4175670445887973e-11
> dgemm /usr/lib/x86_64-linux-gnu/libopenblas_haswellp-r0.2.20.so
>   1.211220 seconds (10 allocations: 160 bytes)
>   dgemm Error :2.770610675980814e-11
> dgemm /usr/lib/x86_64-linux-gnu/libmkl_rt.so
>   1.103356 seconds (10 allocations: 160 bytes)
>   dgemm Error :2.7982744719588258e-11
> 
> Netlib is always the slowest one. For small matrices OpenBLAS is
> very competitive. For large matrices MKL is the fastest.

Thanks, this is an interesting data point.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#871019: sshfs: Please update to 3.x

[bartosz]

Hey Nikolaus,

Nope. There's no other blockers for that. As soon as we get libfuse 3.x 
in Debian I will update sshfs to the most recent version.

For now I was just able to update sshfs to 2.10.

regards
Bartosz Fenski

On 2017-08-06 19:29, Nikolaus Rath wrote:

Package: sshfs
Version: 2.8-1
Severity: wishlist

Dear Maintainer,

Apart from the required libfuse 3.x not yet being in Debian, is there
anything that would prevent updating the package to the most recent
sshfs version?

Thanks!
-Nikolaus

Bug#897373: libc6: feof(file) always false when forking after read

[David Beniamine]

On Thu, May 10, 2018 at 07:06:03PM +0200, Florian Weimer wrote:
> * David Beniamine:
> 
> > int do_fork() {
> > pid_t pid;
> >
> > switch (pid = fork()) {
> > case -1:
> > fprintf(stderr, "Fork failed\n");
> > return -1;
> > case 0:
> > exit(-1);
> 
> Does the issue go away when you call _exit instead of exit?
> 
It goes away with _exit, indeed.

David


signature.asc
Description: PGP signature

Bug#897671: u-boot does not work on sheevaplug

[Vagrant Cascadian]

On 2018-05-09, Markus Krebs wrote:
> Am 09.05.2018 um 14:33 schrieb klaus.go...@theobroma-systems.com:
>>> On 09.05.2018, at 10:19, Markus Krebs  wrote:
>>> Am 08.05.2018 um 22:54 schrieb Vagrant Cascadian:
 On 2018-05-08, Vagrant Cascadian wrote:
> On 2018-05-05, Tom Rini wrote:
>> On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:
>>> Markus Krebs discovered that the sheevaplug target has again grown and
>>> installation overlaps where the u-boot env is saved since u-boot
>>> ~2017.09. Running saveenv overwrites u-boot, and installing u-boot
>>> overwrites any prior environment settings.
...
 And setting SYS_THUMB_BUILD=y as well as disabling EFI_LOADER gets it
 down to 432k! Thanks to beeble for the suggestion.
 Anyone who has a sheevaplug can test that it actually boots with
 CONFIG_SYS_THUMB_BUILD=y enabled?
>>>
>>> I could test it, but I don't know the config-file where I can change
>>> those options (EFI_LOADER, CONFIG_SYS_THUMB_BUILD).
>> 
>> Both are Kconfig options. So just disable it via menuconfig or in your 
>> .config file
>
> Thanks. The modified u-boot (size indeed 441592 bytes only) boots!

Can you try with CONFIG_SYS_THUMB_BUILD=y only (e.g. leave EFI_LOADER at
the default).


live well,
  vagrant


signature.asc
Description: PGP signature