Bug#906317: dgit: consider demoting git-buildpackage to recommends

[Héctor Orón Martínez]

Package: dgit
Version: 6.6
Severity: wishlist
User: debian-ad...@lists.debian.org
Usertags: needed-by-DSA-Team

Dear Maintainer,

  Please, consider demoting `git-buildpackage` to a recommends, since `dgit` 
does not "seem" to depend on it.

  For some background, I would like to enable Debian porterbox users to be able 
to run `dgit push`, however some of my colleagues on the Debian sysadmin team, 
consider installing `dgit` a concern, since they prefer users to push sources 
into porterboxes rather than pull them (being `apt source` the only exception). 
At the moment `dgit` is installed in porterboxes, however it drags in 
`git-buildpackage` which is very much a concern to have it installed there. 
Could you please consider demoting such dependency to a recommends? Or 
alternatively provide a separated binary package providing `dgit push` 
functionality? (Since porterboxes run on stable and you agree with the report, 
consider making available such feature via stable-backports)

  For reference, APT install log on stretch porterbox:
  Commandline: /usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold 
install dgit
  Install: libjson-perl:amd64 (2.90-1, automatic), dgit:amd64 (3.11~deb9u1), 
git-buildpackage:amd64 (0.8.12.2, automatic), libtext-glob-perl:amd64 (0.10-1, 
automatic), python-dateutil:amd64 (2.5.3-2, automatic)

  Regards

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

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

Versions of packages dgit depends on:
ii  apt1.6.3
ii  ca-certificates20180409
ii  coreutils  8.28-1
ii  curl   7.60.0-2
ii  devscripts 2.18.3
ii  dpkg-dev   1.19.0.5
ii  dput   1.0.2
ii  git [git-core] 1:2.18.0-1
ii  git-buildpackage   0.9.9
ii  libdpkg-perl   1.19.0.5
ii  libjson-perl   2.97001-1
ii  liblist-moreutils-perl 0.416-1+b3
ii  libtext-glob-perl  0.10-1
ii  libtext-iconv-perl 1.7-5+b6
ii  libwww-perl6.35-2
ii  perl [libdigest-sha-perl]  5.26.2-6

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:7.7p1-3

Versions of packages dgit suggests:
ii  cowbuilder  0.87+b1
ii  pbuilder0.229.3

-- no debconf information

Bug#906252: uscan: github user/project/tags page no longer works

[Lumin]

control: severity -1 important

This problem started affecting DDPO pages.
All watch files used similar web page will get a blank result.

Bug#906315: spice: CVE-2018-10873: Missing check in demarshal.py:write_validate_array_item() allows for buffer overflow and denial of service

[Salvatore Bonaccorso]

Source: spice
Version: 0.14.0-1
Severity: grave
Tags: patch security upstream
Control: clone -1 -2
Control: reassign -2 src:spice-gtk 0.34-1.1
Control: retitle -2 spice-gtk: CVE-2018-10873: Missing check in 
demarshal.py:write_validate_array_item() allows for buffer overflow and denial 
of service

Hi,

The following vulnerability was published for spice.

CVE-2018-10873[0]:
|Missing check in demarshal.py:write_validate_array_item() allows for
|buffer overflow and denial of service

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-10873
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10873
[1] http://www.openwall.com/lists/oss-security/2018/08/17/1
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1596008
[3] 
https://gitlab.freedesktop.org/spice/spice-common/commit/bb15d4815ab586b4c4a20f4a565970a44824c42c

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#906139: debian-policy: versioned depends on libjs-sphinxdoc unsatisfiable on stretch

[Sean Whitton]

control: retitle -1 Switch back to dh_sphinxdoc from dh_linktree
control: block -1 by 658238

Hello Vagrant,

On Tue 14 Aug 2018 at 11:59AM -0700, Vagrant Cascadian wrote:

> For many years, I've installed debian-policy from sid on a stable system
> to have it readily available, but recent versions of debian-policy have
> a versioned dependency that is unsatisfyable in stable:
>
>   Depends: libjs-sphinxdoc (<< 1.7.6.0~), libjs-sphinxdoc (>= 1.7.6)

Yes, this is annoying.  It affects me too.

> I'm not sure exactly what necessitates a dependency on these (html
> documentation?). The main files of interest to me are policy.txt.gz and
> upgrading-checklist.txt.gz, and find it hard to believe those require
> libjs-sphinxdoc to read. I imagine several of the other formats (.epub,
> .pdf) also shouldn't require libjs-sphinxdoc.
>
> If it is plausible to downgrade to a Recommends, or split out the
> libjs-sphinxdoc documentation into a separate package, or the text-only
> documentation into a separate package, or some other resolution, that
> would be much appreciated!

The problem is caused by the switch to dh_linktree from dh_sphinxdoc.

Unfortunately, that is necessary now that we have translations, which
dh_sphinxdoc is not yet able to handle.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#906265: RFH: julia -- ppc64el port of Julia language and LLVM-6.0

[Lumin]

On Thu, Aug 16, 2018 at 01:45:14PM +0100, Ian Jackson wrote:
> Mo Zhou writes ("Bug#906265: RFH: julia -- ppc64el port of Julia language and 
> LLVM-6.0"):
> > I tried to think of applying for the access to debian's ppc64el porterbox
> > but it appears to be impossible for a normal user to install the resulting
> > package and build another package. Although maybe I can do some hacks on
> > PATH and LD_LIBRARY_PATH but that's dirty.
> 
> This looks quite annoying.  The basic pattern here is that the porter
> may need to install modified build-deps.  This seems like it must come
> up all the time.  DSA, do you have any suggestions ?

Yes, sadly. However if DSA grant us the permission to install a
customized package, we can package e.g. a setuid program to obtain
the root shell within chroot.

BTW the schroot usage page (https://dsa.debian.org/doc/schroot/)
should really mention the tricks about env vars. I've submitted bug here
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906313
 
> I was going to suggest that if the llvm-toolchain maintainers agree,
> perhaps the package with the proposed patch could be uploaded to
> experimental.  But in my ad-hoc tests I couldn't get dd-schroot-cmd to
> even install the package from experimental.

Frédéric has just verified the proposed patch and it's working as
expected. Thank you again @Frédéric Bonnard !
 
> Ian.

Bug#906199: Do something about export-subst export-ignore

[Sean Whitton]

Hello,

On Wed 15 Aug 2018 at 01:04PM +0100, Ian Jackson wrote:

> Package: dgit
> Version: 6.6
>
> Xen upstream has this in its .gitattributes:
>   .gitarchive-info export-subst
> and this in .gitarchive-info:
>   Changeset: $Format:%H$
>   Commit date: $Format:%cD$
>
> dgit needs its Debian git trees to be identical to the source
> packages; so if the Debian git branch is derived from upstream, it has
> the unsubstituted version.  But if the user used git-archive
> (directly, or via some other tool like git-deborig) the orig will have
> the substitutions applied.

git-deborig always gets this right.  It forcefully overrides any
export-subst or export-ignore git attributes that may be present, runs
git-archive(1), and then puts the git attributes back.

> I think sensible options include some combination of:
>
> 1. Just add -export-subst -export-ignore to the set which we
>disable, and update the bug report against git to widen the
>scope of the requested do-all-these-things attribute.
>
> 2. When quilt fixup fails and the tree has a .gitattributes, print a
>warning.  This is probably a good idea anyway.
>
> 3. Provide a single command to disable these export ones too.
>
> In all cases there should be a new test which does git-archive.
>
> I am inclined to do (2), thus pushing more of the cost of this
> ill-advised git feature onto the users who care about it, and away
> from users who do not (and developers like me who are trying to
> support those latter users).

I would suggest (2), plus printing a recommendation to use git-deborig
rather than raw git-archive when you're generating orig tarballs.

git-deborig already has all the flexibility a package maintainer should
need, so it seems superfluous to add cleverness to dgit.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#906265: RFH: julia -- ppc64el port of Julia language and LLVM-6.0

[Lumin]

Hi Frédéric,

Thank you very much for your help!

I've filed the bug for LLVM
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906314
and had it blocking julia's ppc64el build failure.

And have requested for a ppc64el vm. Next time I should be able to
do the ppc64el build by myself :-)


On Thu, Aug 16, 2018 at 05:37:06PM +0200, Frédéric Bonnard wrote:
> Hi Mo Zhou,
> 
> On Thu, 16 Aug 2018 08:38:04 +, Mo Zhou  wrote:
> > Package: wnpp
> > Severity: normal
> > 
> > I request assistance with maintaining the julia package.
> > Specifically I need a ppc64el porter (or anyone who has root access to
> > a ppc64el box) to help me:
> > 
> >  1. Apply patch[1] to Debian's llvm-toolchain-6.0 (= 1:6.0.1-4) and build 
> > it.
> 
> I fetched this https://reviews.llvm.org/D43781
> 
> >  2. Install the resulting llvm-6.0-dev (= 1:6.0.1-5).
> > 
> >  3. dget julia 0.7.0-2 and build Julia for ppc64el.
> > 
> >  4. if (!llvm-ftbfs && !julia-ftbfs) {
> 
> I got there : both built fine.
> I just had to avoid building in a schroot because of this :
> 
> ---
> make[3]: Entering directory '/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0'
> Warning: git information unavailable; versioning information limited
>  cd /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/base && if ! 
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/bin/julia -O3 -C "native" 
> --output-o 
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/lib/powerpc64le-linux-gnu/julia/sys-o.a.tmp
>   --startup-file=no --warn-overwrite=yes --sysimage 
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/lib/powerpc64le-linux-gnu/julia/sys.ji
>  /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl 
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/lib/powerpc64le-linux-gnu/julia/sys.ji;
>  then echo '*** This error is usually fixed by running `make clean`. If the 
> error persists, try `make cleanall`. ***'; false; fi 
> Generating precompile statements...ERROR: LoadError: Failed to open PTY master
> Stacktrace:
>  [1] error(::String) at ./error.jl:33
>  [2] open_fake_pty at 
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/share/julia/test/testhelpers/FakePTYs.jl:14
>  [inlined]
>  [3] with_fake_pty(::getfield(Main.anonymous, 
> Symbol("##3#9")){String,Base.GenericIOBuffer{Array{UInt8,1}},Base.GenericIOBuffer{Array{UInt8,1}},String})
>  at 
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/share/julia/test/testhelpers/FakePTYs.jl:30
>  [4] (::getfield(Main.anonymous, 
> Symbol("##2#8")){Float64,Module,String})(::String, ::IOStream) at 
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:81
>  [5] mktemp(::getfield(Main.anonymous, 
> Symbol("##2#8")){Float64,Module,String}, ::String) at ./file.jl:576
>  [6] mktemp at ./file.jl:574 [inlined]
>  [7] generate_precompile_statements() at 
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:78
>  [8] top-level scope at 
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:144
> in expression starting at 
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:4
> ---
> 
> which is unrelated to the problem you had but to workaround I built in a
> fresh ppc64el unstable vm (probably due to bug #817236 and my schroot being 
> too old
> to be created with the fix)
> 
> > 
> >   1. clone #905807 for llvm-6.0 and remove the +moreinfo tag
> >   2. pull the experimental branch from
> >  https://salsa.debian.org/julia-team/julia
> >  and see if the patched llvm-6.0 is also able to build julia 1.0.0
> 
> this one builds fine as well.
> For now, I won't have time to re-assign the bug on llvm. I'll check that 
> tomorrow.
> 
> > } elif (!llvm-ftbfs && julia-ftbfs) {
> > 
> >   1. find out which patch actually fixes julia's build failure
> >  
> > https://github.com/JuliaLang/julia/blob/master/deps/llvm.mk#L482-L509
> > 
> > } else { .. }
> > 
> > I tried to setup a ppc64el chroot with qemu, and immediately find it
> > impractical for my laptop.
> > 
> > I tried to do it on launchpad (Ubuntu PPA/cosmic), and lauchpad told me
> > "Sorry, something just went wrong in Launchpad." during registration.
> > 
> > I tried to think of applying for the access to debian's ppc64el porterbox
> > but it appears to be impossible for a normal user to install the resulting
> > package and build another package. Although maybe I can do some hacks on
> > PATH and LD_LIBRARY_PATH but that's dirty.
> 
> Yes, that's a security related limitation of porter boxes which
> sometimes makes them unhelpful sadly.
> 
> FYI, you may request a ppc64el vm there :
> http://openpower.ic.unicamp.br/minicloud/
> 
> > So I gave up and wrote this RFH. That begin said, Julia's ppc64el port
> > is indeed supported by upstream, and it is worthwhile to keep Julia for
> > ppc64el such a powerful architecture.
> > 
> > Thanks in advance.
> 
> Thanks a bunch for this work :)
> 
> F.
> 
> > 
> > [1] 

Bug#906286: repository-format sub-policy

[Sean Whitton]

Hello,

On Thu 16 Aug 2018 at 05:50PM +0200, Julian Andres Klode wrote:

> Package: debian-policy
> Severity: wishlist
>
> (more of a discussion for now)
>
> 6 years ago we started working on documenting the repository format
> in the wiki[1] with the goal of making it a sub policy. I have not
> done any work on converting it.
>
> Should we move forward now with turning it into a policy? If so,
> what are the next steps to do?
>
> [1] https://wiki.debian.org/DebianRepository/Format

I had a quick look.  There is wordsmithing to be done, and the Overview
section will need to be rewritten or dropped, but otherwise I don't see
why we couldn't add this as a subpolicy as soon as someone has done the
conversion work.  It's not as though we expect there to be any
nonadditive changes to the repository format.

Additionally, I think it would be quite useful to have this as a
subpolicy.  I have learned quite a bit just from a quick scan through
the page.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#906314: llvm-6.0 unable to build julia 0.7/1.0

[Lumin]

Package: llvm-6.0-dev
Version: 1:6.0.1-4
Severity: important
Justification: blocking RC bug
Control: block 905807 by -1
Control: tag -1 +patch +confirmed

Debian's llvm should add this patch
https://reviews.llvm.org/D43781

And this patch has been verified by Frédéric
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906265#30

With this patch we can build Julia on ppc64el again.

Bug#905081: [Pkg-emacsen-addons] Bug#905081: Bug#905081: improve documentation for buster

[Sean Whitton]

Hello,

On Thu 16 Aug 2018 at 08:50AM -0400, David Bremner wrote:

> It sounds to me like what you are talking about might be more along the
> lines of an emacs addons team policy. I'd suggest writing such a
> document in rst / markdown / texinfo

This might be read as suggesting that we do not already have such a
policy[1]; it would be fine for it to move/change format, though.

[1]  https://wiki.debian.org/EmacsenTeam  "Addons packaging policy"

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#906281: lintian: Severity and Certainty of emacsen-common-without-dh-elpa are wrong / false positives despite "Certainty: certain"

[Sean Whitton]

Hello,

On Fri 17 Aug 2018 at 01:12AM +0200, Axel Beckert wrote:

> I disagree here, not by numbers, but generally. dh-elpa having
> flexibility issues should be a reason to introduce further tiny binary
> packages at all. It should be a reason to fix dh-elpa (IMHO). (Hence
> my original as well as this bug report.)

To be clear, I do not consider this to be a lack of flexibility, but a
sensible design choice (this is not to say that your feature request is
invalid, only that it is definitely a feature request, not a bug).

It is very useful to know that binary packages named elpa-* have a
certain structure and contain only Emacs lisp and perhaps some
documentation, just as it is useful to know that libghc-foo-dev is a
Haskell library, libghc-foo-doc is the Haddock documentation for that
library, etc.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#906313: improvement to the schroot usage doc on porterbox https://dsa.debian.org/doc/schroot/

[Lumin]

Package: www.debian.org
Severity: wishlist
X-Debbugs-CC: DSA 

According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906265#20 ,
the schroot should mention the env var tricks when the porter needs to
build a modified B-D and then build another package on top of it.

Bug#906281: [Pkg-emacsen-addons] Bug#905464: Bug#905464: dh-elpa: Expects .el file name to be based on package name (and does not consider "${pkg}-mode.el")

[Sean Whitton]

Hello,

On Thu 16 Aug 2018 at 04:29PM +0200, Axel Beckert wrote:

>> The assumption that the binary package is called elpa-foo (where is foo
>> is deduced from the package.el metadata) is baked into dh-elpa at a
>> pretty deep level. The assumption is that you will make a seperate
>> binary package for the emacs stuff.
>
> Yeah, that's what I feared and what I consider to be a bug.
>
>> So I guess this bug could be considered a feature request to support
>> a different use-case.
>
> That's another possible way to see it. But in that case, the lintian
> warning emacsen-common-without-dh-elpa
> (https://lintian.debian.org/tags/emacsen-common-without-dh-elpa.html)
> is definitely having the wrong Severity and Certainty.

I disagree that there is anything to be fixed in Lintian.  I am keen
that the severity and certainty remain such that Lintian emits this tag
at the level of a warning (i.e. I don't mind if the values of Severity
and Certainty get changed so long as the tag is still a warning).

There is a consensus on the Emacs team that all Emacs lisp in Debian,
outside of that included in Emacs itself, should eventually be shipped
in elpa-* binary packages that contain only Emacs lisp.  We do not
consider tiny binary packages to be a problem, and I do not believe that
the FTP Team does either, in 2018.  In the past few months we have
uploaded tens of tiny binary packages as part of breaking up
emacs-goodies-el, for example, and all have gone through NEW.

As such, the tag is correct: it reflects the Emacs team's consensus view
that all source packages that have Emacs lisp to install should install
it in its own binary package using dh_elpa.  The tag communicates that
consensus to package maintainers outside of the team.

Of course, a package maintainer can disagree with that consensus, and
override or ignore the tag.  This does not seem like sufficient reason
to downgrade the level at which the tag is emitted.  Overriding tags is
not particularly costly, but the cost of downgrading the tag might be
significant.  Using dh_elpa is not just "nice to have" -- the
maintainability advantages for Debian as a whole are significant.  We
need maintainers to be made aware of that.

> Given that your "baked into dh-elpa at a pretty deep level" sounds as
> if this is neither easy to fix nor will this come soonish, this
> lintian tag should be:
>
> [...]
>
> b) changed from "Certainty: certain" to "Certainty: wild-guess" as
>there are clearly multiple and common cases where the switch to
>dh-elpa is impossible as of now.

I do not know of any cases other than wanting to retain XEmacs support,
but XEmacs is unmaintained upstream, so such cases will disappear from
Debian in the next few years.  Do you perhaps refer to the "common case"
of not wanting a tiny binary package?  I am not sure it is so common :)
Please let me know the multiple and common cases you have in mind here.

> Alternatively, the tag should be changed to be only emitted if the
> binary package is named either elpa-*, *-el or *-mode, i.e. clearly
> being a package which only ships some Emacs plugin and nothing else.
> (Not sure if there are better criterias for the according whitelist.)

This would defeat a lot of the purpose of the tag.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#906312: debian-faq-zh-cn: Typo in ch-pkg_basics.zh-cn.html page

[Wang Gary]

Package: debian-faq-zh-cn
Version: 8.1
Severity: normal

There is a typo in /usr/share/doc/debian/FAQ/zh_CN/ch-pkg_basics.zh-cn.html
at line 474, which spell debian as debina, which should be fixed.

This page is also avaliable online at
https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.zh-cn.html .

Regards

Gary

Bug#906290: kde-full: several KDE applications hang shortly after start

[Lisandro Damián Nicanor Pérez Meyer]

El jue., 16 de ago. de 2018 22:53, Lisandro Damián Nicanor Pérez Meyer <
perezme...@gmail.com> escribió:

> Control: tag -1 moreinfo
>
> El jue., 16 de ago. de 2018 15:12, Tom Downing 
> escribió:
>
>> Package: kde-full
>> Version: 5:102
>> Followup-For: Bug #906290
>>
>> Dear Maintainer,
>>
>> Here are backtraces for three hung applications.  Look the same to me...
>>
>> KMail:
>>
>> (gdb) bt
>> #0  0x7f4fc412d06c in  () at /usr/lib/x86_64-linux-
>> gnu/qt5/plugins/styles/qtcurve.so
>>
>
> Please try not using qtcurve, other users have already stated issues with
> it.
>

That or update qtcurve, it seems to be fixed in the latest upload.

>

Bug#443340: noshell: /usr/sbin/runas Segfaults in amd64

[Bernhard Übelacker]

Hello,
just tried to reproduce this crash.


I got following call stack in gdb with original packages:
(gdb) bt
#0  0x2b57561a5c86 in strtouq () from /lib/libc.so.6
#1  0x2b57561a3712 in atoi () from /lib/libc.so.6
#2  0x0045f5fe in dgettext ()
#3  0x00405778 in __libc_start_main ()


When rebuilding just noshell:
(gdb) bt
#0  0x2ad26562fc86 in strtouq () from /lib/libc.so.6
#1  0x2ad26562d712 in atoi () from /lib/libc.so.6
#2  0x0045f67e in main (argc=5, argv=0x7fff456d13f8, 
envp=0x7fff456d1428) at runas.c:98


When even rebuilding glibc:

Program received signal SIGSEGV, Segmentation fault.
*__GI_strtol_l_internal (nptr=0x7fff0a04fee6 "1000", endptr=0x0, base=10, 
group=0, loc=0x0) at ../sysdeps/generic/strtol_l.c:239
239   struct locale_data *current = loc->__locales[LC_NUMERIC];

(gdb) bt
#0  *__GI_strtol_l_internal (nptr=0x7fff0a04fee6 "1000", endptr=0x0, 
base=10, group=0, loc=0x0) at ../sysdeps/generic/strtol_l.c:239
#1  0x2ac5a0cae712 in atoi (nptr=0x7fff0a04fee6 "1000") at 
../stdlib/stdlib.h:333
#2  0x0045f67e in main (argc=5, argv=0x7fff0a04dd78, 
envp=0x7fff0a04dda8) at runas.c:98


It might be related to the link command:
  gcc  -o runas /usr/lib/libc.a  -dn stubs.o runas.o


The link command seems to do dynamic linking but /usr/lib/libc.a seems
to be the static library judging from the size.

So either command produces an working executable:
gcc -static -o runas /usr/lib/libc.a-dn stubs.o runas.o
gcc -o runas /usr/lib/libc_nonshared.a  -dn stubs.o runas.o
gcc -o runas-dn stubs.o runas.o


At least Squeeze contains a Makefile.linux that got
the "/usr/lib/libc.a" commented out [1] [2].

So this bug can probably be marked as done.


Kind regards,
Bernhard


[1] https://sources.debian.org/src/titantools/4.0.11-4/Makefile.linux/
[2] https://sources.debian.org/src/titantools/4.0.11+notdfsg1-2/Makefile.linux/


PS.: Was fun, but is there no automatic bug closing when the
 release, the bug got reported against, is getting unsupported?


# cat /etc/apt/sources.list

deb http://snapshot.debian.org/archive/debian/20070920T00Z/ etch main 
non-free
deb-src http://snapshot.debian.org/archive/debian/20070920T00Z/ etch main 
non-free



apt-get install noshell gdb dpkg-dev libc6-dbg
apt-get build-dep titantools
apt-get build-dep glibc




# gdb -q --args runas 1000 1000 0022 /bin/bash
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /usr/sbin/runas 1000 1000 0022 /bin/bash
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
0x2b57561a5c86 in strtouq () from /lib/libc.so.6
(gdb) bt
#0  0x2b57561a5c86 in strtouq () from /lib/libc.so.6
#1  0x2b57561a3712 in atoi () from /lib/libc.so.6
#2  0x0045f5fe in dgettext ()
#3  0x00405778 in __libc_start_main ()
#4  0x0040551a in ?? ()
#5  0x7fff54b59878 in ?? ()
#6  0x in ?? ()




(gdb) display/i $pc
1: x/i $pc  0x2b57561a5c86 :mov0x8(%r8),%rdx

(gdb) disassemble strtouq
Dump of assembler code for function strtouq:
0x2b57561a5c50 : mov2114209(%rip),%rax# 
0x2b57563a9ef8 <_IO_file_jumps+2328>
0x2b57561a5c57 : xor%ecx,%ecx
0x2b57561a5c59 : mov%fs:(%rax),%r8
0x2b57561a5c5d :jmpq   0x2b57561a60a0 
0x2b57561a5c62 :nop
0x2b57561a5c63 :nop
0x2b57561a5c64 :nop
0x2b57561a5c65 :nop
0x2b57561a5c66 :nop
0x2b57561a5c67 :nop
0x2b57561a5c68 :nop
0x2b57561a5c69 :nop
0x2b57561a5c6a :nop
0x2b57561a5c6b :nop
0x2b57561a5c6c :nop
0x2b57561a5c6d :nop
0x2b57561a5c6e :nop
0x2b57561a5c6f :nop
0x2b57561a5c70 :push   %r15
0x2b57561a5c72 :push   %r14
0x2b57561a5c74 :mov%r8,%r14
0x2b57561a5c77 :push   %r13
0x2b57561a5c79 :mov%edx,%r13d
0x2b57561a5c7c :push   %r12
0x2b57561a5c7e :push   %rbp
0x2b57561a5c7f :push   %rbx
0x2b57561a5c80 :sub$0x28,%rsp
0x2b57561a5c84 :test   %ecx,%ecx
0x2b57561a5c86 :mov0x8(%r8),%rdx

(gdb) print/x $r8
$1 = 0x0





mkdir -p noshell/orig
cd   noshell/orig
apt-get source noshell
cd ..
cp orig/ try1 -a


cd try1/titantools-4.0.11/
DEB_BUILD_OPTIONS='nostrip' dpkg-buildpackage -b
cd ..
dpkg -i noshell_4.0.11-4_amd64.deb






# gdb -q --args runas 1000 1000 0022 /bin/bash
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /usr/sbin/runas 1000 1000 0022 /bin/bash

Program received signal SIGSEGV, Segmentation fault.
0x2afb25313c86 in strtouq () from 

Bug#906290: kde-full: several KDE applications hang shortly after start

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 moreinfo

El jue., 16 de ago. de 2018 15:12, Tom Downing 
escribió:

> Package: kde-full
> Version: 5:102
> Followup-For: Bug #906290
>
> Dear Maintainer,
>
> Here are backtraces for three hung applications.  Look the same to me...
>
> KMail:
>
> (gdb) bt
> #0  0x7f4fc412d06c in  () at /usr/lib/x86_64-linux-
> gnu/qt5/plugins/styles/qtcurve.so
>

Please try not using qtcurve, other users have already stated issues with
it.

Bug#901875: chromium: 2 non chrome extensions installed by default. crypto mining and pdf reader

[Michael Gilbert]

control: severity -1 minor
control: forwarded -1 http://crbug.com/473958
control: retitle -1 chromium: pdf and two factor extensions can't be removed

Upstream intentionally builds these extensions in by default.  In fact
upstream hides them by default.  If you don't want to see them in the
debian extensions list, you can remove
--show-component-extension-options from chromium's command line
options.

Best wishes,
Mike

Bug#897739: close bug

[Adrian Bunk]

Control: reopen -1

On Mon, Jul 30, 2018 at 10:11:25AM +0800, Yanhao Mo wrote:
>...
> I believe this bug was fixed in newer version.

It was fixed for 64bit architectures, but not completely fixed for 32bit 
architectures:
https://buildd.debian.org/status/package.php?p=deepin-movie-reborn

> Yanhao Mo

cu
Adrian

-- 

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

Bug#892275: redshift: Unable to connect to GeoClue.

[Martin Schwenke]

On Mon, 02 Jul 2018 14:23:31 +0530 Ritesh Raj Sarraf 
wrote:
> On Sat, 2018-06-23 at 22:26 +, byanbyanroryan wrote:
> > ryan@pocketwee:~$ systemctl --user status redshift
> > ● redshift.service - Redshift display colour temperature adjustment
> >Loaded: loaded (/usr/lib/systemd/user/redshift.service; disabled;
> > vendor preset: enabled)
> >Active: inactive (dead)
> >  Docs: http://jonls.dk/redshift/
> 
> 
> Please enable it. That should solve the problem.

I have enabled the service and started it via:

  systemctl --user enable redshift
  systemctl --user start redshift

However, redshift-gtk still refuses to start.  :-(

Will downgrade geoclue-2.0 as per other suggestion...

peace & happiness,
martin

Bug#906249: ,general: Long pause after lightdm login, gimp not starting except under strace

[Ben Caradoc-Davies]

Moritz,

Linux 4.16 fixed CVE-2018-1108 by making the getrandom system call 
(without GRND_NONBLOCK) block if insufficient entropy is available. This 
causes applications to hang, and explains why mouse wiggling helps. As 
Simon advised, we need individual reports for each application. I had to 
build a custom patched kernel and use ltrace to identify the culpable 
applications that affected me:


Bug#897572: getrandom hang in early boot
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572

Bug#899271: xfce4-terminal hangs in getrandom if crng not ready
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899271

Here are my kernel patches:
https://github.com/bencaradocdavies/linux/commit/f0dfb0b7b72e38093aeaa67fe1116b409c1db3dc
https://github.com/bencaradocdavies/linux/commit/19e47d7049c6ca94b98cf8c00bbeb2384a9c43b9
From branch:
https://github.com/bencaradocdavies/linux/commits/getrandom-printk-dump-stack

Kind regards,

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

Bug#906281: lintian: Severity and Certainty of emacsen-common-without-dh-elpa are wrong / false positives despite "Certainty: certain"

[Axel Beckert]

Hi David,

David Bremner wrote:
> > Please note that I'm not 100% sure if these wildcards would match all
> > relevant packages for now. Looking into the dh_elpa source code again
> > might reveal some better metrics. Maybe also David Bremner (reincluded
> > in Cc) might have some more insight with which packages dh-elpa works
> > and with which it doesn't.
> 
> dh-elpa works if you create a separate binary package and name it
> elpa-*. One could interpret the lintian message as suggesting that
> strategy.

Which would counteract FTP Masters' preference of avoiding unnecessary
tiny binary packages to avoid blowing up the package index more than
necessary.

> I'd imaging that wouldn't have a huge impact on the archive in terms
> of number of binary packages created, but I don't have numbers
> offhand.

I disagree here, not by numbers, but generally. dh-elpa having
flexibility issues should be a reason to introduce further tiny binary
packages at all. It should be a reason to fix dh-elpa (IMHO). (Hence
my original as well as this bug report.)

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

Bug#906311: bluez: Systemd fails on upgrade of bluez package -- cannot start bluetooth service

[Henning Koch]

Package: bluez
Version: 5.50-1
Severity: important
Tags: a11y

Dear Maintainer,

during a usual package update of my debian buster system, dpkg crashed while
upgrading bluez package with following stripped output:

Preparing to unpack .../bluez_5.50-1_amd64.deb ...
Unpacking bluez (5.50-1) over (5.50-1) ...
Processing triggers for systemd (239-7) ...
Processing triggers for man-db (2.8.4-2) ...
Processing triggers for dbus (1.12.10-1) ...
Setting up bluez (5.50-1) ...
Job for bluetooth.service failed because the control process exited with error
code.
See "systemctl status bluetooth.service" and "journalctl -xe" for details.
invoke-rc.d: initscript bluetooth, action "restart" failed.
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor
preset: enabled)
   Active: failed (Result: exit-code) since Fri 2018-08-17 00:23:18 CEST; 16ms
ago
 Docs: man:bluetoothd(8)
  Process: 28974 ExecStart=/usr/lib/bluetooth/bluetoothd (code=exited,
status=226/NAMESPACE)
 Main PID: 28974 (code=exited, status=226/NAMESPACE)

Aug 17 00:23:18  systemd[1]: Starting Bluetooth service...
Aug 17 00:23:18  systemd[28974]: bluetooth.service: Failed to set up mount
namespacing: Bad address
Aug 17 00:23:18  systemd[28974]: bluetooth.service: Failed at step
NAMESPACE spawning /usr/lib/bluetooth/bluetoothd: Bad address
Aug 17 00:23:18  systemd[1]: bluetooth.service: Main process exited,
code=exited, status=226/NAMESPACE
Aug 17 00:23:18  systemd[1]: bluetooth.service: Failed with result 'exit-
code'.
Aug 17 00:23:18  systemd[1]: Failed to start Bluetooth service.
dpkg: error processing package bluez (--configure):
 installed bluez package post-installation script subprocess returned error
exit status 1
Errors were encountered while processing:
 bluez

Deactivating Lennart Poetterings directives (ProtectHome= and ProtectSystem=)
for sandbox service inside systemd (see attached patch) seems to cure the
problem temporally. I can continue to use bluetooth normally. However, pulling
down security is generally the wrong direction to go, thus I consider this only
as a first quick fix. I am happy to provide further information upon request

Thanks in advance for assistance and support.



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

Kernel: Linux 4.17.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 bluez depends on:
ii  dbus  1.12.10-1
ii  kmod  25-1
ii  libasound21.1.6-1
ii  libc6 2.27-5
ii  libdbus-1-3   1.12.10-1
ii  libdw10.170-0.5
ii  libglib2.0-0  2.56.1-2
ii  libreadline7  7.0-5
ii  libudev1  239-7
ii  lsb-base  9.20170808
ii  udev  239-7

bluez recommends no packages.

Versions of packages bluez suggests:
ii  pulseaudio-module-bluetooth  11.1-5

-- no debconf information
*** /lib/systemd/system/bluetooth.service   2018-08-17 00:27:54.443067522 
+0200
--- /etc/systemd/system/bluetooth.target.wants/bluetooth.service.orig   
2018-08-16 23:58:13.668972473 +0200
***
*** 12,19 
  #Restart=on-failure
  CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
  LimitNPROC=1
! #ProtectHome=true
! #ProtectSystem=full
  
  [Install]
  WantedBy=bluetooth.target
--- 12,19 
  #Restart=on-failure
  CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
  LimitNPROC=1
! ProtectHome=true
! ProtectSystem=full
  
  [Install]
  WantedBy=bluetooth.target

Bug#904521: pypy-py: postinst uses /usr/share/doc content (Policy 12.3): /usr/share/doc/pypy-py/examples/genhtml.py

[Stefano Rivera]

Hi Niels (2018.08.16_15:03:27_-0700)

> > Any update on this bug?
> 
> Working on a solution. I'll filter /usr/share/doc in
> pypy{clean,compile}.

My thinking there is that it never makes sense to byte-compile things in
/usr/share/doc. (Unless specifically requested, not using the -p flag).

Piotr: The same bug exists in the fallback code that dh_pypy generates,
e.g.

# Automatically added by dh_pypy:
if which pypycompile >/dev/null 2>&1; then
pypycompile -p pypy-py
elif pypy -m py_compile >/dev/null 2>&1; then
dpkg -L pypy-py | grep '\.py$' | pypy -m py_compile - >/dev/null
fi

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#904521: pypy-py: postinst uses /usr/share/doc content (Policy 12.3): /usr/share/doc/pypy-py/examples/genhtml.py

[Stefano Rivera]

> Any update on this bug?

Working on a solution. I'll filter /usr/share/doc in
pypy{clean,compile}.

And I'll add a temporary cleanup task to pypyclean that runs on only .py
files in /usr/share/doc, and ignores errors. We'll have to carry that
for some years, I think.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#886291: src:pycryptodome: Building both pycryptodome and pycryptodomex: duplicate dbgsym package

[Alexis Murzeau]

Hi,

On 15/08/2018 16:29, Simon McVittie wrote:
> On Wed, 15 Aug 2018 at 14:30:17 +0200, Alexis Murzeau wrote:
>> I'm trying to find a way to build 2 times a python source package to
>> generate 2 binary packages which both contains .so libs and this cause 2
>>  duplicated dbgsym packages with same files.
> 
> The Linux kernel had this problem recently, and it seems to have been
> solved by adding the version number as a "salt" that will affect
> build IDs:
> https://sources.debian.org/src/linux/4.17.14-1/debian/patches/features/all/kbuild-add-build-salt-to-the-kernel-and-modules.patch/
> 
> Perhaps you could do similar by including a string in these shared
> libraries (a new, unused global variable or something) that mentions
> either Crypto or Cryptodome, as appropriate for the build, similar to
> the tricks that used to be used to include a RCS/CVS/svn "$Id$" string
> in binaries? (In the kernel implementation it's an ELF note, but a global
> constant string would be equally valid, as long as it doesn't get deleted
> by optimization.)
> 
> Or you could have a python{,3}-pycryptodome-common package containing the
> parts that are the same for both namespaces, if their size is significant;
> or you could make python{,3}-pycryptodome (the one that overrides the
> standard library's Crypto module) depend on python{,3}-pycryptodomex in
> order to share its copies of the parts that end up the same.
> 
> The kernel patch refers to something in RPM that incorporates the package
> name and version in the build ID, but this probably wouldn't work within
> a single source package.
> 
>> Maybe only some .so libraries change between both. I don't think it's
>> safe to assume upstream won't make a change causing some of these .so to
>> change between pycryptodome and pycrytodomex.
> 
> If you decide to share the libraries that are the same despite this,
> please add checks to the build to compare them, so that the build will
> fail if they start to be different. That would catch those upstream
> changes.
> 
>> I think the best would be to have only on dbgsym package for both
>> python{,3}-pycryptodome and python{,3}-pycryptodomex.
> 
> This is what I did in openarena, if it helps:
> https://salsa.debian.org/games-team/openarena/commit/deaa9fc3db68733bfcb6b5edd00c97a896c3aeac
> 
> If the shared libraries that are duplicated in openarena and
> openarena-server were large, I would have added an openarena-common
> package instead, but they're so small when compared with an entire game
> that it didn't seem worth going through NEW for that.
> 
Thanks for your input.

Binary .so libraries represent around 1MB out of 19MB.
I will try to either change the build id with a salt or make only one
dbgsym package, whichever is the easier (given a single dbgsym package
would also need a test to ensure there is no missing files).

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



signature.asc
Description: OpenPGP digital signature

Bug#805445: Info received (Bug#805445: More data points)

[Bernhard Schmidt]

And here is a journal log of the problem happening.

Aug 15 07:36:43 badwlrz-tljss1 ifup[575]: RTNETLINK answers: File exists
Aug 15 07:36:43 badwlrz-tljss1 ifup[575]: ifup: failed to bring up eth0
Aug 15 07:36:43 badwlrz-tljss1 systemd[1]: networking.service: Main
process exited, code=exited, status=1/FAILURE
Aug 15 07:36:43 badwlrz-tljss1 systemd[1]: Failed to start Raise network
interfaces.
Aug 15 07:36:43 badwlrz-tljss1 systemd[1]: networking.service: Unit
entered failed state.
Aug 15 07:36:43 badwlrz-tljss1 systemd[1]: networking.service: Failed
with result 'exit-code'.

The "File exists" comes from the already existing default route. It is
happening very seldomly and looks like a race condition.

I don't think any amount of working around this issue by flushing or
checking the RA routes is going to help. "ip -6 route replace" should
work though.

Bug#905878: notmuch: manuals use – option prefix in documentation instead of --

[David Bremner]

Paul Wise  writes:

> Package: notmuch
> Version: 0.27-2
> Severity: minor
> File: /usr/share/man/man1/notmuch-address.1.gz
> File: /usr/share/man/man1/notmuch-compact.1.gz
> File: /usr/share/man/man1/notmuch-dump.1.gz
> File: /usr/share/man/man1/notmuch-reply.1.gz
> File: /usr/share/man/man1/notmuch-restore.1.gz
> File: /usr/share/man/man1/notmuch-search.1.gz
> File: /usr/share/man/man1/notmuch-show.1.gz
>
> The notmuch manuals use the en dash (–) option prefix in documentation
> instead of the double dash (--). The former does not work when being
> copy-pasted to the command-line but the latter does. I'm guessing this
> is either a bug in rst2man or in the source files for the manual pages.
>
> $ dpkg -L notmuch | grep /usr/share/man/ | xargs zgrep –

Hi Paul;

Thanks for the report. A recent patch upstream from dkg has reduced
those matches to 7, but it's not really clear whether the remaining –
are formatting bugs, or sphinx bugs.

d

Bug#906281: lintian: Severity and Certainty of emacsen-common-without-dh-elpa are wrong / false positives despite "Certainty: certain"

[David Bremner]

Axel Beckert  writes:


> Please note that I'm not 100% sure if these wildcards would match all
> relevant packages for now. Looking into the dh_elpa source code again
> might reveal some better metrics. Maybe also David Bremner (reincluded
> in Cc) might have some more insight with which packages dh-elpa works
> and with which it doesn't.

dh-elpa works if you create a separate binary package and name it
elpa-*. One could interpret the lintian message as suggesting that
strategy.  I'd imaging that wouldn't have a huge impact on the archive
in terms of number of binary packages created, but I don't have numbers
offhand.

Bug#906310: Need xrandr in two steps, else: vblank wait timed out on crtc 0

[Dan Jacobson]

Package: src:linux
Version: 4.17.14-1

I discovered that the user needs to use xrandr in _two_ steps for
certain resolutions, else he will make his system unusable, needing to
be rebooted, probably after minutes of pressing sysrq...

# egrep initial\ m\|stride /var/log/Xorg.0.log
[20.183] (II) modeset(0): Using exact sizes for initial modes
[20.183] (II) modeset(0): Output LVDS-1 using initial mode 1366x768 +0+0
[45.128] (II) modeset(0): Allocate new frame buffer 1280x720 stride #NEEDED 
intermediary step, else disaster
[48.945] (II) modeset(0): Allocate new frame buffer 1024x576 stride

$ cat .xsession
xrandr --output LVDS-1 --mode 1280x720 #if this line is missing, he 
will cause the following drm problems
sleep 3; xrandr --output LVDS-1 --mode 1024x576


Aug 17 04:29:28 jidanni5 kernel: [   54.496059] 
[drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* 
[CRTC:39:pipe A] flip_do
ne timed out
Aug 17 04:29:38 jidanni5 kernel: [   64.736053] 
[drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* 
[CRTC:39:pipe A] flip
_done timed out
Aug 17 04:29:39 jidanni5 kernel: [   65.636025] [ cut here 
]
Aug 17 04:29:39 jidanni5 kernel: [   65.636034] vblank wait timed out on crtc 0
Aug 17 04:29:39 jidanni5 kernel: [   65.636127] WARNING: CPU: 1 PID: 614 at 
/build/linux-eHSiSv/linux-4.17.14/drivers/gpu/drm/drm_vblank.c:1
084 drm_wait_one_vblank+0x16e/0x180 [drm]
Aug 17 04:29:39 jidanni5 kernel: [   65.636132] Modules linked in: arc4 
brcmsmac cordic brcmutil b43 mac80211 cfg80211 ssb intel_rapl pcmcia
 pcmcia_core x86_pkg_temp_thermal intel_powerclamp rng_core coretemp kvm_intel 
kvm irqbypass btusb crct10dif_pclmul crc32_pclmul ghash_clmul
ni_intel btrtl btbcm btintel intel_cstate intel_uncore snd_hda_codec_hdmi 
snd_hda_codec_conexant intel_rapl_perf bluetooth snd_hda_codec_gen
eric uvcvideo jitterentropy_rng pcspkr videobuf2_vmalloc rtsx_usb_ms serio_raw 
videobuf2_memops videobuf2_v4l2 drbg ansi_cprng memstick vide
obuf2_common videodev ecdh_generic media joydev evdev snd_hda_intel sg 
snd_hda_codec i915 bcma iTCO_wdt iTCO_vendor_support snd_hda_core snd
_hwdep snd_pcm ideapad_laptop drm_kms_helper sparse_keymap rfkill snd_timer wmi 
drm mei_me i2c_algo_bit snd video mei shpchp ac soundcore bu
tton
Aug 17 04:29:39 jidanni5 kernel: [   65.636240]  battery pcc_cpufreq ip_tables 
x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscry
pto ecb crypto_simd cryptd glue_helper aes_x86_64 rtsx_usb_sdmmc mmc_core 
rtsx_usb hid_generic usbhid hid sd_mod sr_mod cdrom uas usb_storag
e ahci crc32c_intel libahci libata psmouse scsi_mod i2c_i801 xhci_pci lpc_ich 
xhci_hcd ehci_pci alx mdio ehci_hcd thermal usbcore usb_common
Aug 17 04:29:39 jidanni5 kernel: [   65.636311] CPU: 1 PID: 614 Comm: Xorg Not 
tainted 4.17.0-2-amd64 #1 Debian 4.17.14-1
Aug 17 04:29:39 jidanni5 kernel: [   65.636316] Hardware name: LENOVO 
20150/Product Name, BIOS 5ECN40WW(V3.06) 10/22/2012
Aug 17 04:29:39 jidanni5 kernel: [   65.636348] RIP: 
0010:drm_wait_one_vblank+0x16e/0x180 [drm]
Aug 17 04:29:39 jidanni5 kernel: [   65.636353] RSP: 0018:9a014140ba70 
EFLAGS: 00010286
Aug 17 04:29:39 jidanni5 kernel: [   65.636360] RAX:  RBX: 
8eada2978000 RCX: 0006
Aug 17 04:29:39 jidanni5 kernel: [   65.636365] RDX: 0007 RSI: 
0096 RDI: 8eadaf256730
Aug 17 04:29:39 jidanni5 kernel: [   65.636369] RBP:  R08: 
030f R09: 0007
Aug 17 04:29:39 jidanni5 kernel: [   65.636374] R10: 9a014140b928 R11: 
b79c3d6d R12: 
Aug 17 04:29:39 jidanni5 kernel: [   65.636379] R13: 0cec R14: 
8eada6040808 R15: 000f427e9cdf
Aug 17 04:29:39 jidanni5 kernel: [   65.636387] FS:  7f0b37e4ca40() 
GS:8eadaf24() knlGS:
Aug 17 04:29:39 jidanni5 kernel: [   65.636392] CS:  0010 DS:  ES:  
CR0: 80050033
Aug 17 04:29:39 jidanni5 kernel: [   65.636397] CR2: 561502652928 CR3: 
0001a5632006 CR4: 000606e0
Aug 17 04:29:39 jidanni5 kernel: [   65.636402] Call Trace:
Aug 17 04:29:39 jidanni5 kernel: [   65.636422]  ? finish_wait+0x80/0x80
Aug 17 04:29:39 jidanni5 kernel: [   65.636508]  
ironlake_crtc_enable+0x4bb/0xc80 [i915]
Aug 17 04:29:39 jidanni5 kernel: [   65.636580]  intel_update_crtc+0x39/0x90 
[i915]
Aug 17 04:29:39 jidanni5 kernel: [   65.636641]  intel_update_crtcs+0x47/0x60 
[i915]
Aug 17 04:29:39 jidanni5 kernel: [   65.636698]  
intel_atomic_commit_tail+0x1db/0xcc0 [i915]
Aug 17 04:29:39 jidanni5 kernel: [   65.636754]  
intel_atomic_commit+0x29a/0x2d0 [i915]
Aug 17 04:29:39 jidanni5 kernel: [   65.636791]  
drm_mode_atomic_ioctl+0x822/0x9a0 [drm]
Aug 17 04:29:39 jidanni5 kernel: [   65.636826]  ? 
drm_property_create_blob.part.2+0x10b/0x110 [drm]
Aug 17 04:29:39 jidanni5 kernel: [   65.636858]  ? 
drm_atomic_set_property+0x4f0/0x4f0 [drm]
Aug 17 04:29:39 jidanni5 kernel: [   

Bug#906309: ITP: tootle -- GTK3 client for Mastodon

[Federico Ceratto]

Package: wnpp
Severity: wishlist
Owner: Federico Ceratto 

* Package name: tootle
  Version : 0.1.5
  Upstream Author : Bleak Grey 
* URL : https://github.com/bleakgrey/tootle
* License : GPLv3
  Programming Lang: Vala
  Description : GTK3 client for Mastodon

A simple and lightweight desktop client for Mastodon

The packaging will be maintained at https://salsa.debian.org/debian/tootle
Co-maintainers are very welcome.

Bug#906308: CVE-2018-14348

[Moritz Muehlenhoff]

Source: libcgroup
Severity: grave
Tags: security

This was assigned CVE-2018-14348:
https://bugzilla.suse.com/show_bug.cgi?id=1100365
(cgred seems to be cgrulesengd in Debian)

Patch:
https://sourceforge.net/p/libcg/libcg/ci/0d88b73d189ea3440ccaab00418d6469f76fa590/

Cheers,
Moritz

Bug#905996: nmu: clsync_0.4.1-1

[Aurelien Jarno]

On 2018-08-15 05:45, Niels Thykier wrote:
> Aurelien Jarno:
> [...]
> >> then removing clsync from testing is also an option
> >> AFAICT.
> >>
> >> I am considering since clsync has had its FTBFS bug against sid for
> >> almost 2 years now with no reaction from its maintainers.
> > 
> > That solution has the same result than the binNMU, so that's also fine
> > for me. I would leave the decision about what is the best way to achieve
> > that to the release team.
> > 
> > Thanks,
> > Aurelien
> > 
> 
> Could you please file an RC bug against clsync that affects the
> *testing* version (tags sid + buster if that version is also in stable)
> about this issue?

I have just filled #906307 for that.

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

[Adrian Bunk]

Hi,

looking at something where I worked on the upstream implementation ages ago:
https://sources.debian.org/src/liferea/1.12.4-1/debian/patches/ubuntu-example-feeds.patch/

It is a common problem that users should be able to get started quickly 
after installing a program.

When liferea is started by a user for the first time, the default feedlist
in the locale of the user gets installed as feedlist for the user.

It is clear why a derivative, especially a brand-aware one like Ubuntu,
wants to change this feedlist.

And it is also clear why this change cannot be applied in Debian.

One obvious solution if vendor-specific series files get outlawed in 
Debian would be to switch from ubuntu.series to manual patching in
debian/rules based on dpkg-vendor(1).

There are two problems:

First, it replaces a working standard dpkg feature with an own 
package-specific implementation.
There are surprisingly many things a maintainer can get wrong,
like some other packages doing debian/rules patching where this
breaks building twice in a row.

Second, it hides the whole situation/problem.
Finding all packages that use vendor-specific patch series is simple
and has been done in this discussion here.
This makes it also simple to find bogus cases where the change should
actually be applied in Debian (or upstream).
How do you find all 3.0 (quilt) packages that have conditional patching
implemented in debian/rules?

On Mon, Jul 23, 2018 at 09:22:17AM +0800, Sean Whitton wrote:
> There is a broader question of whether source packages should be allowed
> to unpack differently on different systems through other means, such as
> patch systems implemented in debian/rules (this could be done using
> dpkg-vendor(1)).  But given that 3.0 (quilt) is now dominant, you might
> leave this broader question aside.

I could name a 3.0 (quilt) package where Sean Whitton has done a 
maintainer upload this year that has a patch applied conditionally
in debian/rules with a not completely correct patching mechanism.
The name of the package has not been mentioned in this bug so far.

On the more general point, there is no actual rationale given why the
TC should discuss outlawing vendor-specific patch series without also 
discussing manual debian/rules patching in 3.0 (quilt) packages based
on dpkg-vendor(1) or other mechanisms.


The whole underlying notion that there would be one source tree that 
gets built is also flawed. This is not true in all cases, and can
never be.

On Mon, Jul 23, 2018 at 09:22:17AM +0800, Sean Whitton wrote:
> For example, someone might want to use a Debian system to investigate a
> bug on an Ubuntu system.  They might begin by downloading some source
> packages from the Ubuntu mirrors.  Since they obtained them from Ubuntu,
> they will form the reasonable expectation that unpacking these source
> packages will get them the code running on the Ubuntu system they are
> debugging.

This is not a "reasonable expectation", this is a bogus assumption.
And users should be clearly told that investigating Ubuntu problems
on a Debian system is not a good idea - the supported way for that
is a chroot (or some more sophisticated virtualization solution).

I do not see how this could ever work for a package like src:gcc-8,
that is based on several upstream tarballs and then patches and
configures the code differently based on:
- distribution
- codename of the distribution
- architecture


It might be too complex and not worth the effort, but if anything should 
be changed it should actually be changed in the opposite direction:

Replace buggy patching systems implemented in individual packages 
with a standard non-buggy implementation in dpkg that supports
more ways of conditional patching.


cu
Adrian

-- 

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

Bug#762451: 762451 ITA: solfege -- Ear training software

[François Mazen]

retitle 762451 ITA: solfege -- Ear training software (duplicate)
owner 762451 !
stop


Hello,

I'm preparing a new package of solfege to fix the lintian error
missing-depends-on-sensible-utils, and I volunteer for maintaining this
package.

Should I do something else in addition to upload the new package to
mentors.debian.net?

Best Regards,
François







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

Bug#906307: clsync: pre-depends on multiarch-support in buster

[Aurelien Jarno]

Source: clsync
Version: 0.4.1-1
Severity: serious
Tags: buster

The multiarch-support package is scheduled for removal in buster.
clsync is one of the last package in buster that still depends on
it. The dependency is added by old versions of debhelper, so in theory
the package would just need to get rebuild and migrated to testing.
Unfortunately it's not something possible as the package doesn't build
on most architectures due to bug#844778 which is opened for more almost
two years now.

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

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

Bug#895657: [gcompris-qt] Fixed

[Adrien]

Package: gcompris-qt
Version: 0.91-1

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

It seems that this issue is fixed with the last update of Qt.

--- System information. ---
Architecture:
Kernel: Linux 4.17.0-2-amd64

Debian Release: buster/sid
500 unstable ftp.fr.debian.org
500 testing download.jitsi.org
1 experimental ftp.fr.debian.org

--- Package information. ---
Depends (Version) | Installed
=-+-
gcompris-qt-data (= 0.91-1) | 0.91-1
libqt5multimedia5-plugins | 5.11.1-2
qml-module-qtgraphicaleffects | 5.11.1-2
qml-module-qtmultimedia | 5.11.1-2
qml-module-qtquick-controls | 5.11.1-2
qml-module-qtquick-particles2 | 5.11.1-4
libc6 (>= 2.14) | 2.27-5
libgcc1 (>= 1:3.0) | 1:8.2.0-4
libqt5core5a (>= 5.10.0) | 5.11.1+dfsg-6
libqt5gui5 (>= 5.2.0) | 5.11.1+dfsg-6
libqt5network5 (>= 5.0.2) | 5.11.1+dfsg-6
libqt5qml5 (>= 5.1.0) | 5.11.1-4
libqt5quick5 (>= 5.9.0~beta) | 5.11.1-4
libqt5sensors5 (>= 5.6.0) | 5.11.1-3
libqt5widgets5 (>= 5.0.2) | 5.11.1+dfsg-6
libstdc++6 (>= 4.1.1) | 8.2.0-4


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#906302: gnome-control-center: Nextcloud connection is not working with self created certificate

[Jeremy Bicha]

On Thu, Aug 16, 2018 at 3:18 PM Michael Ott  wrote:
> After updating to 3.29.90 nextcloud does not work in online account. I remove
> that and try it again.

> ii  libglib2.0-0   2.57.2-1

You might need gnome-online-accounts 3.29.91 which was just released
and isn't available in Debian yet.

Thanks,
Jeremy Bicha

Bug#906306: freeciv: 2.6 "start scenario game" uses antique looking tileset

[Mark Van den Borre]

Package: freeciv
Version: 2.6.0-1
Severity: minor

Dear Maintainer,

   * What led up to the situation?
Upgrade to freeciv 2.6.0-1 (Debian buster, package came in 20180815).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Start the application. Try to load a predefined scenario.
   * What was the outcome of this action?
Rendering in game reverts to a very crude ancient looking "overhead" tileset.
No option to reenable the previous version's isometric/isohex sets.

   * What outcome did you expect instead?
Rendering in game using isometric/isohex tilesets, like in previous versions.

This is a known upstream bug that is being worked on. Just wanted to save
friendly Debian maintainers and upstream from unnecessary questions.

Relevant upstream tickets:
https://www.hostedredmine.com/issues/685235
https://www.hostedredmine.com/issues/765923

Thank you for your work on Debian!

Mark



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

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

Versions of packages freeciv depends on:
ii  freeciv-client-gtk3  2.6.0-1
ii  freeciv-data 2.6.0-1

freeciv recommends no packages.

freeciv suggests no packages.

-- no debconf information

Bug#906305: galera-3: FTBFS on hurd-i386

[Svante Signell]

Source: galera-3
Version: 25.3.23-1
Severity: important
Tags: ftbfs, patch
User: debian-h...@lists.debian.org
Usertags: hurd-i386

Hello,

Currently galera-3 FTBFS on GNU/Hurd due to that some functions are not
yet available: posix_fadvise, msync and pthread_setschedparam.
Attached are three patches to fix this:
galerautils_src_gu_mmap.cpp.diff
galerautils_src_gu_thread.cpp.diff
gcache_src_gcache_page.cpp.diff

Additionally one test fails due to a too short timeout:
galera_tests_saved_state_check.cpp.diff

and finally a comparison in a test corrected:
gcs_src_unit_tests_gcs_sm_test.cpp.diff
The reasoning behind that patch is:
Original source: fail_if (tmp <= paused_ns); paused_ns = tmp;
If tmp equals paused_ns the test fails, so why set paused_ns = tmp?
Therefore the equals sign should be removed:
fail_if (tmp < paused_ns); paused_ns = tmp;
as the patch does.

Together with the patch galerautils_src_gu_resolver.cpp.diff for
Hurd+kfreeBSD #906081 galera-3 builds fine.


Thanks!--- a/galerautils/src/gu_mmap.cpp	2018-02-06 11:47:00.0 +0100
+++ b/galerautils/src/gu_mmap.cpp	2018-08-13 17:09:02.0 +0200
@@ -90,12 +90,13 @@
  (uint64_t(addr) & PAGE_SIZE_MASK));
 size_t   const sync_length
 (length + (static_cast(addr) - sync_addr));
-
+#if !defined(__GNU__)
 if (::msync(sync_addr, sync_length, MS_SYNC) < 0)
 {
 gu_throw_error(errno) << "msync(" << sync_addr << ", "
   << sync_length << ") failed";
 }
+#endif
 }
 
 void
--- a/galerautils/src/gu_thread.cpp	2018-02-06 11:47:00.0 +0100
+++ b/galerautils/src/gu_thread.cpp	2018-08-13 17:13:16.0 +0200
@@ -85,9 +85,11 @@
 #else
 struct sched_param spstr = { sp.prio() };
 #endif
-int err;
+int err = 0;
+#if !defined(__GNU__)
 if ((err = pthread_setschedparam(thd, sp.policy(), )) != 0)
 {
 gu_throw_error(err) << "Failed to set thread schedparams " << sp;
 }
+#endif
 }
--- a/gcache/src/gcache_page.cpp	2018-02-06 11:47:00.0 +0100
+++ b/gcache/src/gcache_page.cpp	2018-08-13 12:52:03.0 +0200
@@ -35,7 +35,7 @@
 {
 mmap_.dont_need();
 
-#if !defined(__APPLE__)
+#if !defined(__APPLE__) && !defined(__GNU__)
 int const err (posix_fadvise (fd_.get(), 0, fd_.size(),
   POSIX_FADV_DONTNEED));
 if (err != 0)
Index: galera-3-25.3.23/galera/tests/saved_state_check.cpp
===
--- galera-3-25.3.23.orig/galera/tests/saved_state_check.cpp
+++ galera-3-25.3.23/galera/tests/saved_state_check.cpp
@@ -225,7 +225,7 @@ Suite* saved_state_suite()
 tcase_add_test  (tc, test_basic);
 tcase_add_test  (tc, test_unsafe);
 tcase_add_test  (tc, test_corrupt);
-tcase_set_timeout(tc, 120);
+tcase_set_timeout(tc, 240);
 suite_add_tcase (s, tc);
 
 return s;
--- a/gcs/src/unit_tests/gcs_sm_test.cpp	2018-02-06 11:47:00.0 +0100
+++ b/gsc/src/unit_tests/gcs_sm_test.cpp	2018-08-14 00:41:20.0 +0200
@@ -280,7 +280,7 @@ START_TEST (gcs_sm_test_pause)
 long long tmp;
 gcs_sm_stats_get (sm, _len, _len_max, _len_min, _len_avg,
   , _avg);
-fail_if (tmp <= paused_ns); paused_ns = tmp;
+fail_if (tmp < paused_ns); paused_ns = tmp;
 fail_if (paused_avg <= 0.0);
 fail_if (fabs(q_len_avg) > EPS,
  "q_len_avg: expected <= %e, got %e", EPS, fabs(q_len_avg));

Bug#906304: login: Failure to load desktop after login

[Cody Jackson]

Package: login
Version: 1:4.4-4.1
Severity: important

Dear Maintainer,

   * What led up to the situation?
Updating kernal from 4.9.0-6 to 4.9.0-7 using apt-get dist-upgrade

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
My once per month apt-get dist-upgrade



   * What was the outcome of this action?

When I started the OS with the new kernal. I was able to login, but then the 
screen went blank indefinitely. I tried shutting down and updating again. I 
also submitted a bug report to the kernal team, but it wasn't the right 
package. 
   * What outcome did you expect instead?

The new kernal version to let me log in and use the desktop. 


-- System Information:
Debian Release: 9.5
  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=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages login depends on:
ii  libaudit1   1:2.6.7-2
ii  libc6   2.24-11+deb9u3
ii  libpam-modules  1.1.8-3.6
ii  libpam-runtime  1.1.8-3.6
ii  libpam0g1.1.8-3.6

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#906303: xserver-xorg: Xserver will not start on standard boot, will start from rescue mode.

[thardman-TJH4]

Package: xserver-xorg
Version: 1:7.7+19
Severity: important

Dear Maintainer,

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

Related to bug #903851

Xserver will not start after standard boot. With "recovery mode" boot to single
user, after manual start of D-Bus service, Xserver will start. Very different
Xorg.0.log are produced. Additionally, Xorg.1.log is sometimes produced, and
even a single Xorg.2.log has been produced which seems to indicate success. Not
expected in a system with only one (1) Nvidia card (GTX 660)

Attempted boots to graphical.target go into a loop as X repeatedly fails. Boots
to multi-user.target are successful but X cannot be started from the user
prompt. Boots to single-user (recovery mode from GRUB prompt) allow X to be
started from command line if first we give the command 'service dbus start'.

When bug report is active I will send the various Xorg.*.log files which should
help experts solve these problems.



-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.7.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.7.0 by glx-diversions
diversion of 

Bug#906302: gnome-control-center: Nextcloud connection is not working with self created certificate

[Michael Ott]

Package: gnome-control-center
Version: 1:3.29.90-1
Severity: normal

Dear Maintainer,

After updating to 3.29.90 nextcloud does not work in online account. I remove
that and try it again.
On first click it told me invalid error and on the second click it tell me
code 6: unexpected response from server

Syslog show me that output:
gnome-control-c[5883]: goa_http_client_check() failed: 6 — Server did not
return a valid TLS certificate

It works with 3.28

CU
  Michael



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

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

Versions of packages gnome-control-center depends on:
ii  accountsservice0.6.45-1
ii  apg2.2.3.dfsg.1-5
ii  colord 1.3.3-2
ii  desktop-file-utils 0.23-3
ii  gnome-control-center-data  1:3.29.90-1
ii  gnome-desktop3-data3.29.90.1-1
ii  gnome-settings-daemon  3.29.90.1-1
ii  gsettings-desktop-schemas  3.28.0-1
ii  libaccountsservice00.6.45-1
ii  libatk1.0-02.28.1-1
ii  libc6  2.27-5
ii  libcairo-gobject2  1.15.10-3
ii  libcairo2  1.15.10-3
ii  libcanberra-gtk3-0 0.30-6
ii  libcanberra0   0.30-6
ii  libcheese-gtk253.28.0-1
ii  libcheese8 3.28.0-1
ii  libclutter-1.0-0   1.26.2+dfsg-4
ii  libclutter-gtk-1.0-0   1.8.4-3
ii  libcolord-gtk1 0.1.26-2
ii  libcolord2 1.3.3-2
ii  libcups2   2.3~b5-2
ii  libfontconfig1 2.13.0-5
ii  libgdk-pixbuf2.0-0 2.36.12-1
ii  libglib2.0-0   2.57.2-1
ii  libgnome-bluetooth13   3.28.2-1
ii  libgnome-desktop-3-17  3.29.90.1-1
ii  libgoa-1.0-0b  3.28.0-1
ii  libgoa-backend-1.0-1   3.28.0-1
ii  libgrilo-0.3-0 0.3.6-1
ii  libgtk-3-0 3.23.2-1
ii  libgtop-2.0-11 2.38.0-2
ii  libgudev-1.0-0 232-2
ii  libibus-1.0-5  1.5.18-1
ii  libkrb5-3  1.16-2
ii  libmm-glib01.7.990-1
ii  libnm0 1.12.2-2
ii  libnma01.8.16-1
ii  libpango-1.0-0 1.42.1-2
ii  libpangocairo-1.0-01.42.1-2
ii  libpolkit-gobject-1-0  0.115-1
ii  libpulse-mainloop-glib012.0-1
ii  libpulse0  12.0-1
ii  libpwquality1  1.4.0-2
ii  libsecret-1-0  0.18.6-2
ii  libsmbclient   2:4.8.2+dfsg-2
ii  libsoup2.4-1   2.63.90-1
ii  libupower-glib30.99.8-2
ii  libwacom2  0.30-1
ii  libwayland-server0 1.15.0-2
ii  libx11-6   2:1.6.5-1
ii  libxi6 2:1.7.9-1
ii  libxml22.9.7+dfsg-1

Versions of packages gnome-control-center recommends:
ii  cracklib-runtime  2.9.2-5.2+b1
ii  cups-pk-helper0.2.6-1+b1
ii  gkbd-capplet  3.26.0-3
ii  gnome-online-accounts 3.28.0-1
ii  gnome-user-docs   3.28.2-1
ii  gnome-user-share  3.18.3-3
ii  iso-codes 3.79-1
ii  libcanberra-pulse 0.30-6
ii  libnss-myhostname 239-7
ii  mousetweaks   3.12.0-4
ii  network-manager-gnome 1.8.16-1
ii  policykit-1   0.115-1
ii  pulseaudio-module-bluetooth   12.0-1
ii  realmd0.16.3-2
ii  rygel 0.36.1-1
ii  rygel-tracker 0.36.1-1
ii  system-config-printer-common  1.5.11-2

Versions of packages gnome-control-center suggests:
ii  gnome-packagekit 3.28.0-2
ii  gnome-software   3.28.2-1
ii  gstreamer1.0-pulseaudio  1.14.2-1
pn  libcanberra-gtk-module   
ii  libcanberra-gtk3-module  0.30-6
ii  x11-xserver-utils7.7+8

-- no debconf information

Bug#906209: lintian: bugs-field-does-not-refer-to-debian-infrastructure: cannot override

[Thorsten Glaser]

Hi Chris,

>I see your point for now. However, the idea is that eventually (!) the
>line number and filename will be included in all tags as a bit of
>semantic metadata that would not be a required part of an override.
>
>This will allow us to «inter alia» link to the exact line on
>sources.debian.org etc. or one's text editor.

that sounds like a good plan, indeed.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#906194: addendum

[G. Cabrele]

Following the alternative way of downloading from Oracle, as indicated 
in Debian Wiki guide,

the installation process ended with:
"vboxdrv.sh: failed: modprobe vboxdrv failed. Please use 'dmesg' to find 
out why."

and dmesg tells:
"[43186.988394] vboxdrv: Requires SSE2 (cpuid(0).EDX=0x383fbff)".

Effectively my CPU features SSE, but not SSE2. Could be that the problem ?
Do the recent releases of VBox require SSE2 ?
since I could install vers. 1.30 on Stretch 9.4, can I install that on 9.5 ?
That seems to be  the same problem that
prevents me from installing the most recent version of KDE desktop.
Which other package is requiring SSE2, and why that is not clearly 
indicated ?

Regards

Bug#906042: stretch-pu: package libxcursor/1:1.1.14-1+deb9u2

[Chris Lamb]

Dear Adam,

> > >  libxcursor (1:1.1.14-1+deb9u2) stretch; urgency=high
> > >  
> > >    * Fix a denial of service or potentially code execution via
> > >  a one-byte heap overflow. (CVE-2015-9262) Closes: #906012)
> > 
> > Would it be possible to get a "yay/nay" on this s-p-u request?
> 
> Please go ahead.

Thanks; uploaded.

> > I wouldn't normally press for a response but this is somewhat
> > affecting what my next moves are for oldstable and oldoldstable. 
> 
> Isn't oldoldstable an ex-release now?

Not in ELTS:

  https://wiki.debian.org/LTS/Extended

> FWIW, CCing both a p-u bug and debian-release is a little redundant.

Mea culpa…  I wasn't sure and my apologies for any duplicates or
implications that involved.

Thank you for your work on stable.


Regards,

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

Bug#906301: libcommons-compress-java: CVE-2018-11771: denial of service vulnerability

[Salvatore Bonaccorso]

Source: libcommons-compress-java
Version: 1.9-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for libcommons-compress-java.

CVE-2018-11771[0]:
| When reading a specially crafted ZIP archive, the read method of
| Apache Commons Compress 1.7 to 1.17's ZipArchiveInputStream can fail
| to return the correct EOF indication after the end of the stream has
| been reached. When combined with a java.io.InputStreamReader this can
| lead to an infinite stream, which can be used to mount a denial of
| service attack against services that use Compress' zip package.

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-11771
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11771
[1] http://www.openwall.com/lists/oss-security/2018/08/16/2

Regards,
Salvatore

Bug#906300: Enabled wpa_supplicant.service causes slow launching of libvte-based terminals (xfce4-terminal) on startup

[Wallace Tan]

Package: wpasupplicant
Version: 2:2.6-18

As title suggests, in the latest version (as of the date and time of
this email), libvte-based terminal like xfce4-terminal and
gnome-terminal experiencing slowness during startup.

Expectation: launching the terminal INSTANTLY when pressing the
shortcut Ctrl+Alt+t or lauching the terminal from an icon in the
xfce4-panel.

Experience: The launching speed varies across different laptops of
mine, on a laptop with I7-7700HQ with HDD, it's around 4 seconds,
whereas on a laptop with I5 450M with HDD, it could be 25 seconds to
more than 2 minutes.

However, if messing around the desktop or opening up Thunar File
Manager, the terminal will open up on the side normally.

Have been experience this issue since 1-2 months ago, I suspect that
It could be due to the June release, wpa (2:2.6-17)
  * Remove dbus changes to StaAuthorized/StaDeauthorized after discussions
with the upstream.

http://metadata.ftp-master.debian.org/changelogs//main/w/wpa/wpa_2.6-18_changelog

My 1st workaround currently is disabling wpa_supplicant.service. With
network-manager installed, I have to disable network-manager.service
as well to prevent it from calling wpa_supplicant.service. Hence, I
have to start network-manager manually during startup.

2nd workaround (this works or not has to depend on how early I unlock
the display manager) is to delay network-manager.service, as follows,

/lib/systemd/system/network-manager.service
...
#After=network-pre.target dbus.service
#Before=network.target
After=display-manager.service

[Service]
ExecStartPre=/bin/sleep 25
Type=dbus
...

end of file

I have tried googling for solutions but the results are related to
dbus-user-session or dbus-launch, which may link to network-manager as
dependencies.

On the other hand, what I have found out from by installing and
reinstalling packages, and a new minimal installation of debian
buster, is pointing to wpasupplicant instead of other packages.

example of googled results:
https://bbs.archlinux.org/viewtopic.php?id=219817

I am using Debian GNU/Linux buster, kernel 4.17.14-1 and libc6 2.27-5.

Bug#898998: [clementine] Cannot resume via Plasma media player widget

[Alexander Kernozhitsky]

Package: clementine
Version: 1.3.1+git542-gf00d9727c+dfsg-1+b1

Reopening this bug because now I can reproduce this.

Some additional information: this bug happens if Clementine is started after 
Plasma media widget. It happens after session start. After Plasma restart 
everything is OK. But when I restart Clementine after this, the bug is 
present.

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

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

--- Package information. ---
Depends(Version) | Installed
-+-==
libc6  (>= 2.14) | 
libcdio18 (>= 2.0.0) | 
libchromaprint1   (>= 1.3.2) | 
libcrypto++6 | 
libfftw3-double3  (>= 3.3.5) | 
libgcc1   (>= 1:3.0) | 
libgdk-pixbuf2.0-0   (>= 2.22.0) | 
libglib2.0-0 (>= 2.37.3) | 
libgpod4  (>= 0.6.0) | 
libgstreamer-plugins-base1.0-0(>= 1.0.0) | 
libgstreamer1.0-0 (>= 1.0.0) | 
libimobiledevice6 (>= 0.9.7) | 
libmtp9   (>= 1.1.0) | 
libmygpo-qt5-1(>= 1.0.9) | 
libplist3  (>= 1.11) | 
libprojectm2v5   | 
libprotobuf10| 
libpulse0(>= 0.99.1) | 
libqt5concurrent5  (>= 5.6.0~rc) | 
libqt5core5a (>= 5.10.0) | 
libqt5dbus5   (>= 5.0.2) | 
libqt5gui5(>= 5.7.0) | 
libqt5network5(>= 5.0.2) | 
libqt5opengl5 (>= 5.0.2) | 
libqt5sql5(>= 5.3.0) | 
libqt5widgets5(>= 5.7.0) | 
libqt5x11extras5  (>= 5.6.0) | 
libqt5xml5(>= 5.0.2) | 
libsqlite3-0 (>= 3.6.11) | 
libstdc++6  (>= 5.2) | 
libtag1v5  (>= 1.11) | 
libx11-6 | 
zlib1g  (>= 1:1.1.4) | 
gstreamer1.0-plugins-base| 
gstreamer1.0-plugins-good| 
gstreamer1.0-plugins-ugly| 
libqt4-sql-sqlite| 
projectm-data  (>= 2.0.1+dfsg-6) | 


Recommends   (Version) | Installed
==-+-===
gstreamer1.0-alsa  | 1.14.2-1
 OR gstreamer1.0-pulseaudio| 1.14.2-1


Suggests  (Version) | Installed
===-+-===
gstreamer1.0-plugins-bad| 1.14.2-1
-- 
Alexander Kernozhitsky

Bug#906209: lintian: bugs-field-does-not-refer-to-debian-infrastructure: cannot override

[Chris Lamb]

Hi Thorsten,

> >The lintian extra is: "mailto:t.gla...@tarent.de (line 23)"
[…]
> Is including the line number really helpful here? It’s bound to change.

I see your point for now. However, the idea is that eventually (!) the
line number and filename will be included in all tags as a bit of
semantic metadata that would not be a required part of an override.

This will allow us to «inter alia» link to the exact line on
sources.debian.org etc. or one's text editor.


Regards,

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

Bug#906296: jackd2: Jackd mysteriously uninstalled, libreadline6 disappears from repo?

[Klaumi Klingsporn]

Am / On Thu, 16 Aug 2018 12:33:53 -0500
schrieb / wrote dbrz :

> Package: jackd2
> Version: 2:1.9.12-1~kxstudio1
> Severity: important
> 
> Dear Maintainer,
> 
> Today, I tried to use my audio workstation (qtractor) to
> do some editing, only to discover that 

Dear dbrz (would be nice to have a real name to answer to),

the turbulences in your system that you described may be
caused by the fact that your jackd2 package (and maybe
others too?) is/are not from Debian but from kxstudio. 

Debian has 1.9.12~dfsg-2 in unstable and testing and
1.9.10+20150825git1ed50c92~dfsg-5 in stable. The
kxstudio-guys set an epoch 2 to their package version, which
makes their version always higher and preferred. But this
version depends on libreadline6 while in Debian since
stretch there's only libreadline7.

So the easiest way to fix this would be to downgrade to
jackd2 from stable if you are running stable. 

And you should consider to replace all packages from
kxstudio with the ones from Debian. In most cases it's not
the best idea to mix up distributions.

Klaumi

---
Klaus-Michael Klingsporn 
mail: klaumi...@gmx.de
web: www.klaumikli.de

Bug#906299: vim-conque: please update dependencies to include vim-python3

[Mike Miller]

Package: vim-conque
Version: 2.3-1
Severity: normal

Dear Maintainer,

The latest vim source package has changed from "Provides: vim-python" to
"Provides: vim-python3" to be more explicit. Please update the
corresponding dependencies in vim-conque to include both vim-python and
vim-python3.

Thank you for your work and attention.

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

Kernel: Linux 4.17.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.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 vim-conque depends on:
ii  python 2.7.15-3
ii  vim-gtk3 [vim-python]  2:8.1.0089-1

Versions of packages vim-conque recommends:
ii  vim-addon-manager  0.5.9

vim-conque suggests no packages.

-- no debconf information

Bug#906033: DMD is still failing for me

[Christophe Siraut]

Same issue.

(i just requested write access on salsa; otherwise please review and
apply my patch)

Christophe
>From 04202e85ea91ae3a5e5edbf9593a286e4f5dbd4f Mon Sep 17 00:00:00 2001
From: Christophe Siraut 
Date: Wed, 15 Aug 2018 09:17:37 +
Subject: [PATCH] do not fail on neutral ci status (closes: #906033)

---
 web/inc/dmd-data.rb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/web/inc/dmd-data.rb b/web/inc/dmd-data.rb
index 20d2ae3..f46b0ab 100755
--- a/web/inc/dmd-data.rb
+++ b/web/inc/dmd-data.rb
@@ -429,7 +429,7 @@ EOF
   else
 poold = r['source'][0]
   end
-  if r['status'] == 'pass'
+  if r['status'] == 'pass' or r['status'] == 'neutral'
 prio = ''
 eprio = ''
   elsif r['status'] == 'fail'
-- 
2.11.0

Bug#874370: mariadb-server-10.1: mariadb server does not write pid

[Faustin Lammler]

file on location specified in config
Reply-To: faus...@fala.red

Hi Stefan,
thank you for your help!

I have just installed mariadb-server on a fresh stable debian 9 (KVM
platform) and I can not reproduce this (I am able to change path of pid
file):

$ sudo apt install mariadb-server
$ sudo rep -r pid /etc/mysql/
/etc/mysql/mariadb.conf.d/50-server.cnf:pid-file
=/var/run/mysqld/mysqld.pid
$ ls -l /var/run/mysqld/mysqld.pid 
-rw-rw 1 mysql mysql 5 Aug 16 15:05 /var/run/mysqld/mysqld.pid

Change pid path for '/tmp/mysql.pid':
$ sudo grep -r pid /etc/mysql
/etc/mysql/mariadb.conf.d/50-server.cnf:pid-file=/tmp/mysqld.pid
$ sudo systemctl restart mysql
$ ls -l /tmp/mysqld.pid
-rw-rw 1 mysql mysql 5 Aug 16 15:07 /tmp/mysqld.pid

Some info on system:
$ uname -r
4.9.0-7-amd64
$ dpkg -l | grep mariadb
ii  libmariadbclient18:amd64  10.1.26-0+deb9u1 amd64
MariaDB database client library
ii  mariadb-client-10.1   10.1.26-0+deb9u1 amd64
MariaDB database client binaries
ii  mariadb-client-core-10.1  10.1.26-0+deb9u1 amd64
MariaDB database core client binaries
ii  mariadb-common10.1.26-0+deb9u1 all  
MariaDB common metapackage
ii  mariadb-server10.1.26-0+deb9u1 all  
MariaDB database server (metapackage depending on the latest version)
ii  mariadb-server-10.1   10.1.26-0+deb9u1 amd64
MariaDB database server binaries
ii  mariadb-server-core-10.1  10.1.26-0+deb9u1 amd64
MariaDB database core server files
$ cat /etc/debian_version
9.5

Could you verify again if the issue is still present on your system?
What command do you use to restart mysql?

Please also take a look at this open issue, I have just linked your bug
report there:
https://jira.mariadb.org/browse/MDEV-8168

Regards,
Faustin

Bug#580736: grub is not able to configure Fedora in a dual boot setup

[Nicholas Rhodes]

I managed to workaround the issue with the following change to
/usr/lib/linux-boot-prober/mounted/40grub2:


diff --git a/40grub2 b/41grub2-linux16
index 885614e..8b3e179 100755
--- a/40grub2
+++ b/41grub2-linux16
@@ -64,7 +64,7 @@ parse_grub_menu () {
ignore_item=1
fi
;;
-   linux)
+   linux|linux16)
# Hack alert: sed off any (hdn,n) but
# assume the kernel is on the same
# partition.
@@ -77,7 +77,7 @@ parse_grub_menu () {
kernel="/boot$kernel"
fi
;;
-   initrd)
+   initrd|initrd16)
initrd="$(echo "$2" | sed 's/(.*)//')"
# Initrd same.
if [ "$partition" != "$bootpart" ]; then

Bug#906298: xprobe FTCBFS: does not propagate the cross compiler from configure to make

[Helmut Grohne]

Source: xprobe
Version: 0.3-3
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

xprobe fails to cross build from source, because it does not propagate
the C++ cross compiler, that is correctedly detected by ./configure, to
the various sub Makefiles. The cause quite simply is a missing variable
substitution. Close to the end, it runs the build architecture strip.
Stripping is bad, because it also breaks generation of -dbgsym packages.
The attached patch adds the missing interpolations and removes the strip
call. It makes xprobe cross buildable. Please consider applying it.

Helmut
--- xprobe-0.3.orig/src/xpmodules/alive_probe/Makefile.in
+++ xprobe-0.3/src/xpmodules/alive_probe/Makefile.in
@@ -18,6 +18,7 @@
 
 
 CC=@CC@
+CXX=@CXX@
 INSTALL=@INSTALL@
 INSTALL_PROGRAM=@INSTALL_PROGRAM@
 INSTALL_DATA=@INSTALL_DATA@
--- xprobe-0.3.orig/src/xpmodules/os_probe/tcp_rst/Makefile.in
+++ xprobe-0.3/src/xpmodules/os_probe/tcp_rst/Makefile.in
@@ -18,6 +18,7 @@
 
 
 CC=@CC@
+CXX=@CXX@
 INSTALL=@INSTALL@
 INSTALL_PROGRAM=@INSTALL_PROGRAM@
 INSTALL_DATA=@INSTALL_DATA@
--- xprobe-0.3.orig/src/xpmodules/os_probe/tcp_handshake/Makefile.in
+++ xprobe-0.3/src/xpmodules/os_probe/tcp_handshake/Makefile.in
@@ -18,6 +18,7 @@
 
 
 CC=@CC@
+CXX=@CXX@
 INSTALL=@INSTALL@
 INSTALL_PROGRAM=@INSTALL_PROGRAM@
 INSTALL_DATA=@INSTALL_DATA@
--- xprobe-0.3.orig/src/xpmodules/os_probe/icmp_addrmask/Makefile.in
+++ xprobe-0.3/src/xpmodules/os_probe/icmp_addrmask/Makefile.in
@@ -18,6 +18,7 @@
 
 
 CC=@CC@
+CXX=@CXX@
 INSTALL=@INSTALL@
 INSTALL_PROGRAM=@INSTALL_PROGRAM@
 INSTALL_DATA=@INSTALL_DATA@
--- xprobe-0.3.orig/src/xpmodules/os_probe/icmp_echo_id/Makefile.in
+++ xprobe-0.3/src/xpmodules/os_probe/icmp_echo_id/Makefile.in
@@ -18,6 +18,7 @@
 
 
 CC=@CC@
+CXX=@CXX@
 INSTALL=@INSTALL@
 INSTALL_PROGRAM=@INSTALL_PROGRAM@
 INSTALL_DATA=@INSTALL_DATA@
--- xprobe-0.3.orig/src/xpmodules/os_probe/icmp_inforeq/Makefile.in
+++ xprobe-0.3/src/xpmodules/os_probe/icmp_inforeq/Makefile.in
@@ -18,6 +18,7 @@
 
 
 CC=@CC@
+CXX=@CXX@
 INSTALL=@INSTALL@
 INSTALL_PROGRAM=@INSTALL_PROGRAM@
 INSTALL_DATA=@INSTALL_DATA@
--- xprobe-0.3.orig/src/xpmodules/os_probe/icmp_timestamp/Makefile.in
+++ xprobe-0.3/src/xpmodules/os_probe/icmp_timestamp/Makefile.in
@@ -18,6 +18,7 @@
 
 
 CC=@CC@
+CXX=@CXX@
 INSTALL=@INSTALL@
 INSTALL_PROGRAM=@INSTALL_PROGRAM@
 INSTALL_DATA=@INSTALL_DATA@
--- xprobe-0.3.orig/src/Makefile.in
+++ xprobe-0.3/src/Makefile.in
@@ -49,7 +49,6 @@
 
 xprobe2: $(OBJS) modules
 	$(CXX) $(CFLAGS) $(OBJS) $(MODOBJS) -o $@ $(LDFLAGS) $(LIBS)
-	strip $@
 
 modules:
 	cd xpmodules; ${MAKE}

Bug#906290: kde-full: several KDE applications hang shortly after start

[Tom Downing]

Package: kde-full
Version: 5:102
Followup-For: Bug #906290

Dear Maintainer,

Here are backtraces for three hung applications.  Look the same to me...

KMail:

(gdb) bt
#0  0x7f4fc412d06c in  () at /usr/lib/x86_64-linux-
gnu/qt5/plugins/styles/qtcurve.so
#1  0x7f4fc4104deb in  () at /usr/lib/x86_64-linux-
gnu/qt5/plugins/styles/qtcurve.so
#2  0x7f4ff2f6f28b in
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () at
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#3  0x7f4ff38c8491 in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#4  0x7f4ff38cfd28 in QApplication::notify(QObject*, QEvent*) () at
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#5  0x7f4ff2f6f579 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7f4ff38cf029 in QApplicationPrivate::sendMouseEvent(QWidget*,
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool) () at
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#7  0x7f4ff3921304 in  () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x7f4ff3923e8e in  () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9  0x7f4ff38c84a1 in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#10 0x7f4ff38cfae0 in QApplication::notify(QObject*, QEvent*) () at
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#11 0x7f4ff2f6f579 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7f4ff330e53b in
QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*)
() at /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#13 0x7f4ff3310435 in
QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*)
() at /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#14 0x7f4ff32eab6b in
QWindowSystemInterface::sendWindowSystemEvents(QFlags)
() at /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#15 0x7f4fc9197e5b in  () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#16 0x7f4ff2f6e24b in
QEventLoop::exec(QFlags) () at
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x7f4ff2f763c2 in QCoreApplication::exec() () at /usr/lib/x86_64-linux-
gnu/libQt5Core.so.5
#18 0x55621cd177cd in  ()
#19 0x7f4ff29e6b17 in __libc_start_main (main=0x55621cd16840, argc=1,
argv=0x7fffc112a818, init=, fini=,
rtld_fini=, stack_end=0x7fffc112a808) at ../csu/libc-start.c:310
#20 0x55621cd178fa in _start ()
(gdb)

--

KPat:

(gdb) bt
#0  0x7fa27e1b0040 in ?? () from /usr/lib/x86_64-linux-
gnu/qt5/plugins/styles/qtcurve.so
#1  0x7fa27e187deb in ?? () from /usr/lib/x86_64-linux-
gnu/qt5/plugins/styles/qtcurve.so
#2  0x7fa292c9a28b in
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#3  0x7fa293ab0491 in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#4  0x7fa293ab7d28 in QApplication::notify(QObject*, QEvent*) () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#5  0x7fa292c9a579 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7fa293ab7029 in QApplicationPrivate::sendMouseEvent(QWidget*,
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool) () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#7  0x7fa293b09304 in ?? () from /usr/lib/x86_64-linux-
gnu/libQt5Widgets.so.5
#8  0x7fa293b0be8e in ?? () from /usr/lib/x86_64-linux-
gnu/libQt5Widgets.so.5
#9  0x7fa293ab04a1 in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#10 0x7fa293ab7ae0 in QApplication::notify(QObject*, QEvent*) () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#11 0x7fa292c9a579 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7fa29307853b in
QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*)
() from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#13 0x7fa29307a435 in
QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*)
() from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#14 0x7fa293054b6b in
QWindowSystemInterface::sendWindowSystemEvents(QFlags)
() from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#15 0x7fa2883aee5b in ?? () from /usr/lib/x86_64-linux-
gnu/libQt5XcbQpa.so.5
#16 0x7fa292c9924b in
QEventLoop::exec(QFlags) () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x7fa292ca13c2 in QCoreApplication::exec() () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x55a0a16a5086 in ?? ()
#19 0x7fa29257bb17 in __libc_start_main (main=0x55a0a16a33d0, argc=1,
argv=0x7ffdfbe91498, init=, fini=,
rtld_fini=, 

Bug#906297: libfabric1: psm2 provider documented as "not built"

[Brian T. Smith]

Package: libfabric1
Version: 1.6.1-5
Severity: minor
Tags: patch

d/README.Debian states that the psm2 provider for libfabric is
not built. When libfabric is built for amd64, the psm2 provider
is built and the package Build-Depends upon libpsm2.

fi_info verifies that the psm2 provider is part of libfabric1:

$ fi_info | grep ^provider | sort -u
provider: psm
provider: psm2
provider: shm
provider: sockets
provider: UDP
provider: verbs
provider: verbs;ofi_rxm

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

Kernel: Linux 4.15.0-2-amd64 (SMP w/44 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 libfabric1 depends on:
ii  libc6   2.27-3
ii  libibverbs1 18.1-1
ii  libpsm-infinipath1  3.3+20.604758e7-5
ii  libpsm2-2   10.3.58-1
ii  librdmacm1  18.1-1

libfabric1 recommends no packages.

libfabric1 suggests no packages.

-- no debconf information
diff --git a/debian/README.Debian b/debian/README.Debian
index 06dd3efb..d6ce46b8 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -7,6 +7,7 @@ The Debian version of libfabric currently supports the 
following providers:
 - verbs
 - udp
 - psm
+- psm2 - amd64 only
 - rxd
 - rxm
 
@@ -15,7 +16,6 @@ Other available providers, not built in the Debian package, 
are:
 - gni
 - mlx
 - usnic
-- psm2
 
 
 Fabtests

Bug#906296: jackd2: Jackd mysteriously uninstalled, libreadline6 disappears from repo?

[Sebastian Ramacher]

Control: tags -1 + moreinfo

Hi dbrz

On 2018-08-16 12:33:53, dbrz wrote:
> Package: jackd2
> Version: 2:1.9.12-1~kxstudio1

This is not jackd2 as provided by Debian in the current stable release. Please
install 1.9.10+20150825git1ed50c92~dfsg-5 and try again.

> Severity: important
> 
> Dear Maintainer,
> 
> Today, I tried to use my audio workstation (qtractor) to do some editing, 
> only to discover that Cadence had been uninstalled. I went to reinstall and 
> run it, and found that jackdbus was missing, and a cursory search revealed 
> that jackd2 was no longer on my system.
> Now, I had previously installed jackd2 as part of setting up my DAW, so this 
> seemed fishy. So I went to install it again, and found that it was missing 
> libreadline6.

libreadline6 was replaced by libreadline7 in stable. The issue is that the
version of jackd2 you've installed is not compatible with stable.

Cheers

> 
> To my utter shock, libreadline6 had packages for Sid, Jessie, and Wheezy--but 
> not for Stretch. I ended up installing an older version manually by 
> downloading the .deb from the website, which will no doubt make future 
> updates very fun.
> 
> My question is: how did this happen? Trying to install jackd2 on a fresh 
> Stretch install would have revealed this issue immediately. In fact, the 
> entire reason I'm using Debian right now is because this sort of thing is 
> actively prevented by Debian's package maintenance process. I've been 
> resisting the urge to channel the spirit of Torvalds into this email :P
> 
> Now, I *have* been installing some packages from external repos, and I've 
> been doing some fiddling with gdebi and such. But given that the required 
> dependency is literally missing from stretch's repos, something tells me 
> that's the problem.
> 
> -- System Information:
> Debian Release: 9.5
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.9.0-7-amd64 (SMP w/12 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages jackd2 depends on:
> ii  coreutils  8.26-3
> ii  debconf [debconf-2.0]  1.5.61
> ii  libasound2 1.1.3-5
> ii  libc6  2.24-11+deb9u3
> ii  libdbus-1-31.10.26-0+deb9u1
> ii  libexpat1  2.2.0-2+deb9u1
> ii  libgcc11:6.3.0-18+deb9u1
> ii  libjack-jackd2-0   2:1.9.12-1~kxstudio1
> ii  libreadline6   6.2+dfsg-0.1
> ii  libsamplerate0 0.1.8-8+b2
> ii  libsndfile11.0.27-3
> ii  libstdc++6 6.3.0-18+deb9u1
> ii  multiarch-support  2.24-11+deb9u3
> ii  python 2.7.13-2
> ii  python-dbus1.2.4-1+b1
> 
> Versions of packages jackd2 recommends:
> ii  jackd2-firewire  2:1.9.12-1~kxstudio1
> ii  libpam-modules   1.1.8-3.6
> 
> Versions of packages jackd2 suggests:
> pn  jack-tools   
> pn  meterbridge  
> 
> -- Configuration Files:
> /etc/security/limits.d/audio.conf changed:
> @audio   -  rtprio 95
> @audio   -  memlockunlimited
> 
> 
> -- debconf information:
> * jackd/tweak_rt_limits: true
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#906042: stretch-pu: package libxcursor/1:1.1.14-1+deb9u2

[Adam D. Barratt]

Control: tags -1 + confirmed

FWIW, CCing both a p-u bug and debian-release is a little redundant.

On Thu, 2018-08-16 at 09:44 +0100, Chris Lamb wrote:
> Chris Lamb wrote:
> 
> >  libxcursor (1:1.1.14-1+deb9u2) stretch; urgency=high
> >  
> >    * Fix a denial of service or potentially code execution via
> >  a one-byte heap overflow. (CVE-2015-9262) Closes: #906012)
> 
> Would it be possible to get a "yay/nay" on this s-p-u request?

Please go ahead.

> I wouldn't normally press for a response but this is somewhat
> affecting what my next moves are for oldstable and oldoldstable. 

Isn't oldoldstable an ex-release now?

Regards,

Adam

Bug#906296: jackd2: Jackd mysteriously uninstalled, libreadline6 disappears from repo?

[dbrz]

Package: jackd2
Version: 2:1.9.12-1~kxstudio1
Severity: important

Dear Maintainer,

Today, I tried to use my audio workstation (qtractor) to do some editing, only 
to discover that Cadence had been uninstalled. I went to reinstall and run it, 
and found that jackdbus was missing, and a cursory search revealed that jackd2 
was no longer on my system.
Now, I had previously installed jackd2 as part of setting up my DAW, so this 
seemed fishy. So I went to install it again, and found that it was missing 
libreadline6.

To my utter shock, libreadline6 had packages for Sid, Jessie, and Wheezy--but 
not for Stretch. I ended up installing an older version manually by downloading 
the .deb from the website, which will no doubt make future updates very fun.

My question is: how did this happen? Trying to install jackd2 on a fresh 
Stretch install would have revealed this issue immediately. In fact, the entire 
reason I'm using Debian right now is because this sort of thing is actively 
prevented by Debian's package maintenance process. I've been resisting the urge 
to channel the spirit of Torvalds into this email :P

Now, I *have* been installing some packages from external repos, and I've been 
doing some fiddling with gdebi and such. But given that the required dependency 
is literally missing from stretch's repos, something tells me that's the 
problem.

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

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

Versions of packages jackd2 depends on:
ii  coreutils  8.26-3
ii  debconf [debconf-2.0]  1.5.61
ii  libasound2 1.1.3-5
ii  libc6  2.24-11+deb9u3
ii  libdbus-1-31.10.26-0+deb9u1
ii  libexpat1  2.2.0-2+deb9u1
ii  libgcc11:6.3.0-18+deb9u1
ii  libjack-jackd2-0   2:1.9.12-1~kxstudio1
ii  libreadline6   6.2+dfsg-0.1
ii  libsamplerate0 0.1.8-8+b2
ii  libsndfile11.0.27-3
ii  libstdc++6 6.3.0-18+deb9u1
ii  multiarch-support  2.24-11+deb9u3
ii  python 2.7.13-2
ii  python-dbus1.2.4-1+b1

Versions of packages jackd2 recommends:
ii  jackd2-firewire  2:1.9.12-1~kxstudio1
ii  libpam-modules   1.1.8-3.6

Versions of packages jackd2 suggests:
pn  jack-tools   
pn  meterbridge  

-- Configuration Files:
/etc/security/limits.d/audio.conf changed:
@audio   -  rtprio 95
@audio   -  memlockunlimited


-- debconf information:
* jackd/tweak_rt_limits: true

Bug#906295: libyaml-cpp-dev: New version 0.6.2 available

[Benjamin Redelings]

Package: libyaml-cpp-dev
Version: 0.5.2-4
Severity: normal

Dear Maintainer,

Version 0.6.2 is available, as of Mar 6, 2018.  The current version is 0.5.2.
Would it be possible to upload a new version?  My package bali-phy might need
to use this, and having version 0.6.2 would make packaging a lot easier.  Thank
you!

-BenRI



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

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

Versions of packages libyaml-cpp-dev depends on:
ii  libboost-dev  1.62.0.1
ii  libyaml-cpp0.5v5  0.5.2-4

libyaml-cpp-dev recommends no packages.

libyaml-cpp-dev suggests no packages.

-- no debconf information

Bug#906294: haveged: New upstream version

[Steffen Moeller]

Package: haveged
Version: 1.9.1-6
Severity: wishlist

Dear Maintainer,

Version 1.9.6 is available. Please kindly inform me if you would appreciate to 
be helped out.

Many thanks

Steffen 

Bug#906292: ocserv build depends on the removed libprotobuf-c0-dev provides

[Adrian Bunk]

Source: ocserv
Version: 0.11.9-1
Severity: serious

The libprotobuf-c0-dev build dependency must be
updated to libprotobuf-c-dev.

Bug#906293: virtio-forwarder build depends on the removed libprotobuf-c0-dev provides

[Adrian Bunk]

Source: virtio-forwarder
Version: 1.1.99.13-1~unstable
Severity: serious

The libprotobuf-c0-dev build dependency must be
updated to libprotobuf-c-dev.

Bug#906209: lintian: bugs-field-does-not-refer-to-debian-infrastructure: cannot override

[Thorsten Glaser]

Hi Niels,

>The lintian extra is: "mailto:t.gla...@tarent.de (line 23)"
[…]
>This is not the first time this issue has appeared and I doubt it will
>be the last unless lintian gets some features to be more helpful.

thanks for this detailled explanation.

Is including the line number really helpful here? It’s bound to change.

But anyway, I managed to override it by not including the, what TIL is
called “lintian extra”, so I agree to closing the bug.

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Bug#893597: i965-va-driver: GPU hang on hardware encode

[Christian Schlüter]

Thanks, I know by now. Bug can be closed.

Pretty sure i965-va-driver-shaders didn't actually exist when I filed the
bug, or wasn't installable, or whatever.

Sven Arvidsson  schrieb am Do., 16. Aug. 2018 um 18:21 Uhr:

> On Tue, 2018-03-20 at 10:30 +0100, Christian Schlüter wrote:
> > hardware video encoding to h264, hevc, vp8 and vp9 leads to a GPU
> > hang
> > on KBL.
> > Mpeg2 encoding is possible.
> > Works with i965_drv_video.so built from git master.
>
> Hi,
>
> As mentioned in README.Debian,, modern Intel GPUs require non-free
> shaders. You need to to use the i965-va-driver-shaders package from
> non-free instead.
>
> It would be nice if using the wrong package lead to warnings instead of
> GPU hangs, but I don't know how easy that would be to implement.
>
> --
> Cheers,
> Sven Arvidsson
> http://www.whiz.se
>

Bug#906291: rhash FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: rhash
Version: 1.3.6-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

rhash fails to cross build from source, because it configures for the
build architecture. Usually, one has to pass the --host flag and
dh_auto_configure takes care of that. Not so here. The handcrafted
configure script does not recognize the flag. Instead, one is supposed
to set up a suitable CC variable. Once doing so, rhash cross builds
successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru rhash-1.3.6/debian/changelog rhash-1.3.6/debian/changelog
--- rhash-1.3.6/debian/changelog2018-03-22 23:40:09.0 +0100
+++ rhash-1.3.6/debian/changelog2018-08-16 18:52:15.0 +0200
@@ -1,3 +1,10 @@
+rhash (1.3.6-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: export a suitable compiler. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 16 Aug 2018 18:52:15 +0200
+
 rhash (1.3.6-2) unstable; urgency=low
 
   * Multi-arch support
diff --minimal -Nru rhash-1.3.6/debian/rules rhash-1.3.6/debian/rules
--- rhash-1.3.6/debian/rules2018-03-22 23:40:09.0 +0100
+++ rhash-1.3.6/debian/rules2018-08-16 18:52:11.0 +0200
@@ -4,6 +4,9 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+-include /usr/share/dpkg/buildtools.mk
+export CC
+
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_CFLAGS_MAINT_APPEND = -D_FILE_OFFSET_BITS=64
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)

Bug#906290: kde-full: several KDE applications hang shortly after start

[tdowning]

Package: kde-full
Version: 5:102
Severity: important

Dear Maintainer,

On 14 August 2018 I performed apt-get update; apt-get upgrade.  The last
date of update/upgrade was aprox 3-4 weeks earlier.

Before the 14 August upgrade I observed no bugs other than a minor, infrequent
plasma desktop issue.  After the upgrade, KDE applications no longer operate
normally. 

All KDE apps start, and function normally for a short time. They then cease
to be responsive to either user input, window manager operations, or network
driven input.  Clicking the title-bar 'quit' icon will eventually result in
the "not responding" dialog.

The time the app runs before hang is usually less than one minute, but sometimes
can be longer; rarely more than 15 minutes. Amount of user input does not seem
to correlate with how quickly the hung state occurs.

Not all KDE apps suffer the problem, notable Konsole has operated normally. 
Kmail,
Konqueror, KPat -), are notable apps that suffer the problem.

I have not seen any non-KDE applications have this problem.

FWIW, running KMail from console reveals the message:

QFont::setPixelSize: Pixel size <= 0 (0)

repeated 50-100 times rapidly, while the app is displayed by idle.  After this
KMail is hung.

Please feel free to contact me if I can be of any assistance. I haven't done any
KDE development in years, but I still do C++/linux development.

Thanks

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

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

Versions of packages kde-full depends on:
ii  kde-plasma-desktop   5:102
ii  kde-standard 5:102
ii  kdeadmin 4:17.08.3+5.102
ii  kdeedu   4:17.08.3+5.102
ii  kdegames 4:17.08.3+5.102
ii  kdegraphics  4:17.08.3+5.102
ii  kdemultimedia4:17.08.3+5.102
ii  kdenetwork   4:17.08.3+5.102
ii  kdepim   4:17.12.3+5.102
ii  kdeutils 4:17.08.3+5.102
ii  plasma-workspace-wallpapers  4:5.13.1-1

Versions of packages kde-full recommends:
ii  kdeaccessibility  4:17.08.3+5.102
ii  kdesdk4:17.08.3+5.102
ii  kdetoys   4:17.08.3+5.102
ii  kdewebdev 4:17.08.3+5.102

Versions of packages kde-full suggests:
pn  calligra  
ii  xorg  1:7.7+19

-- no debconf information

Bug#893597: i965-va-driver: GPU hang on hardware encode

[Sven Arvidsson]

On Tue, 2018-03-20 at 10:30 +0100, Christian Schlüter wrote:
> hardware video encoding to h264, hevc, vp8 and vp9 leads to a GPU
> hang
> on KBL.
> Mpeg2 encoding is possible.
> Works with i965_drv_video.so built from git master.

Hi,

As mentioned in README.Debian,, modern Intel GPUs require non-free
shaders. You need to to use the i965-va-driver-shaders package from
non-free instead.

It would be nice if using the wrong package lead to warnings instead of
GPU hangs, but I don't know how easy that would be to implement.

-- 
Cheers,
Sven Arvidsson
http://www.whiz.se


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

Bug#906289: ITP: ruby-aes-key-wrap -- Ruby implementation of AES Key Wrap

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-debbugs-cc: debian-r...@lists.debian.org
Control: block 902721 by -1

from rubygems.org/gems/aes_key_wrap

dependency of json-jwt 1.9.4 (security update)


























signature.asc
Description: OpenPGP digital signature

Bug#906288: openbox-lxde-session: /usr/bin/startlxde overrides XDG_DATA_DIRS making all local .desktop files unable to show on menu

[(Holloway), Chew Kean Ho]

Package: openbox-lxde-session
Version: 0.99.2-3
Severity: normal

Dear Maintainer,

   * What led up to the situation?
When I install snaps in a freshly installed Debian 9 with LXDE. The
snaps with .desktop should be populated automatically inside the menu,
but it didn't.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
After thorough investigation (logged in
https://forum.snapcraft.io/t/snaps-not-appearing-in-debian9-stretch-lxde-menu-not-wayland-bug/6866/14),

I discovered the /usr/bin/lxde has this line overrides all the
XDG_DATA_DIRS set by Xsession.d configuration files:
```
export
XDG_DATA_DIRS="/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-xdg/"
```

By replacing that line with a proper checking before overwriting, the
issue disappeared and all the custom paths appears in the menu properly.
```
xdg_path="/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-xdg/"
if [ -z "$XDG_DATA_DIRS" ]; then
export XDG_DATA_DIRS="$xdg_path"
else
if [ -z "$(echo "$XDG_DATA_DIRS" | grep "$xdg_path")" ]; then
export XDG_DATA_DIRS="${XDG_DATA_DIRS}:$xdg_path"
fi
fi
unset xdg_path
```

   * What was the outcome of this action?
All custom .desktop path are properly populated without manual
intervention.

   * What outcome did you expect instead?
I expect all the .desktop are populated properly, without monkey
patching anything created by the package.

Currently, those UI-based snaps are quite hard to access, but not
impossible.

   * p/s
I'm too new to debian mailing list and reportbug tool. In case of
silence, please reach me at kean.ho.c...@zoralab.com. I'm willing
to help.


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

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

Versions of packages openbox-lxde-session depends on:
ii  lxde-common  0.99.2-3
ii  lxsession0.5.3-2
ii  openbox  3.6.1-4

openbox-lxde-session recommends no packages.

openbox-lxde-session suggests no packages.

-- no debconf information

Bug#906265: RFH: julia -- ppc64el port of Julia language and LLVM-6.0

[Frédéric Bonnard]

Hi Mo Zhou,

On Thu, 16 Aug 2018 08:38:04 +, Mo Zhou  wrote:
> Package: wnpp
> Severity: normal
> 
> I request assistance with maintaining the julia package.
> Specifically I need a ppc64el porter (or anyone who has root access to
> a ppc64el box) to help me:
> 
>  1. Apply patch[1] to Debian's llvm-toolchain-6.0 (= 1:6.0.1-4) and build it.

I fetched this https://reviews.llvm.org/D43781

>  2. Install the resulting llvm-6.0-dev (= 1:6.0.1-5).
> 
>  3. dget julia 0.7.0-2 and build Julia for ppc64el.
> 
>  4. if (!llvm-ftbfs && !julia-ftbfs) {

I got there : both built fine.
I just had to avoid building in a schroot because of this :

---
make[3]: Entering directory '/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0'
Warning: git information unavailable; versioning information limited
 cd /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/base && if ! 
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/bin/julia -O3 -C "native" 
--output-o 
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/lib/powerpc64le-linux-gnu/julia/sys-o.a.tmp
  --startup-file=no --warn-overwrite=yes --sysimage 
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/lib/powerpc64le-linux-gnu/julia/sys.ji
 /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl 
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/lib/powerpc64le-linux-gnu/julia/sys.ji;
 then echo '*** This error is usually fixed by running `make clean`. If the 
error persists, try `make cleanall`. ***'; false; fi 
Generating precompile statements...ERROR: LoadError: Failed to open PTY master
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] open_fake_pty at 
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/share/julia/test/testhelpers/FakePTYs.jl:14
 [inlined]
 [3] with_fake_pty(::getfield(Main.anonymous, 
Symbol("##3#9")){String,Base.GenericIOBuffer{Array{UInt8,1}},Base.GenericIOBuffer{Array{UInt8,1}},String})
 at 
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/share/julia/test/testhelpers/FakePTYs.jl:30
 [4] (::getfield(Main.anonymous, 
Symbol("##2#8")){Float64,Module,String})(::String, ::IOStream) at 
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:81
 [5] mktemp(::getfield(Main.anonymous, Symbol("##2#8")){Float64,Module,String}, 
::String) at ./file.jl:576
 [6] mktemp at ./file.jl:574 [inlined]
 [7] generate_precompile_statements() at 
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:78
 [8] top-level scope at 
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:144
in expression starting at 
/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:4
---

which is unrelated to the problem you had but to workaround I built in a
fresh ppc64el unstable vm (probably due to bug #817236 and my schroot being too 
old
to be created with the fix)

> 
>   1. clone #905807 for llvm-6.0 and remove the +moreinfo tag
>   2. pull the experimental branch from
>  https://salsa.debian.org/julia-team/julia
>  and see if the patched llvm-6.0 is also able to build julia 1.0.0

this one builds fine as well.
For now, I won't have time to re-assign the bug on llvm. I'll check that 
tomorrow.

> } elif (!llvm-ftbfs && julia-ftbfs) {
> 
>   1. find out which patch actually fixes julia's build failure
>  https://github.com/JuliaLang/julia/blob/master/deps/llvm.mk#L482-L509
> 
> } else { .. }
> 
> I tried to setup a ppc64el chroot with qemu, and immediately find it
> impractical for my laptop.
> 
> I tried to do it on launchpad (Ubuntu PPA/cosmic), and lauchpad told me
> "Sorry, something just went wrong in Launchpad." during registration.
> 
> I tried to think of applying for the access to debian's ppc64el porterbox
> but it appears to be impossible for a normal user to install the resulting
> package and build another package. Although maybe I can do some hacks on
> PATH and LD_LIBRARY_PATH but that's dirty.

Yes, that's a security related limitation of porter boxes which
sometimes makes them unhelpful sadly.

FYI, you may request a ppc64el vm there :
http://openpower.ic.unicamp.br/minicloud/

> So I gave up and wrote this RFH. That begin said, Julia's ppc64el port
> is indeed supported by upstream, and it is worthwhile to keep Julia for
> ppc64el such a powerful architecture.
> 
> Thanks in advance.

Thanks a bunch for this work :)

F.

> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905807
> 
> Appendix
> 
> 
> The package description is:
>  Julia is a high-level, high-performance dynamic programming language for
>  technical computing, with syntax that is familiar to users of other technical
>  computing environments. It provides a sophisticated compiler, distributed
>  parallel execution, numerical accuracy, and an extensive mathematical 
> function
>  library. The library, mostly written in Julia itself, also integrates mature,
>  best-of-breed C and Fortran libraries for linear algebra, random number
>  

Bug#906287: gnome: Wacom tablet - switch monitor - has both monitors together

[Andrew Atkinson]

Package: gnome
Version: 1:3.22+9
Severity: normal

Dear Maintainer,

When a button is set up to switch the wacom tablet (Intuos 3) between the 2
screens it also goes through both screens at once rather than just switching
from one to another.



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

Kernel: Linux 4.16.0-2-amd64 (SMP w/12 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)
LSM: AppArmor: enabled

Versions of packages gnome depends on:
ii  avahi-daemon 0.7-4
ii  cheese   3.28.0-1
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 9.0.7
ii  evolution3.28.5-1
ii  evolution-plugins3.28.5-1
ii  file-roller  3.28.1-1
ii  gedit-plugins3.28.1-1
ii  gimp 2.10.2-1
ii  gnome-calendar   3.28.2-1
ii  gnome-clocks 3.28.0-1
ii  gnome-color-manager  3.28.0-1
ii  gnome-core   1:3.22+9
ii  gnome-documents  3.28.0-1
ii  gnome-getting-started-docs   3.28.2-1
ii  gnome-maps   3.28.2-1
ii  gnome-music  3.28.2.1-2
ii  gnome-screenshot 3.26.0-3
ii  gnome-sound-recorder 3.28.1-1
ii  gnome-todo   3.28.1-1
ii  gnome-tweaks 3.28.1-1
ii  gnome-weather3.26.0-4
ii  gstreamer1.0-libav   1.15.0.1+git20180723+db823502-1
ii  gstreamer1.0-plugins-ugly1.14.2-1
ii  inkscape 0.92.3-2+b1
ii  libgsf-bin   1.14.43-1
ii  libgtk2-perl 2:1.24992-1+b1
ii  libproxy1-plugin-networkmanager  0.4.15-1
ii  libreoffice-calc 1:6.1.0-1
ii  libreoffice-gnome1:6.1.0-1
ii  libreoffice-impress  1:6.1.0-1
ii  libreoffice-writer   1:6.1.0-1
ii  nautilus-sendto  3.8.6-2
ii  network-manager-gnome1.8.14-1
ii  orca 3.28.1-3
ii  rhythmbox3.4.2-4
ii  rhythmbox-plugin-cdrecorder  3.4.2-4
ii  rhythmbox-plugins3.4.2-4
ii  rygel-playbin0.36.1-1
ii  rygel-tracker0.36.1-1
ii  seahorse 3.20.0-5
ii  shotwell 0.28.4-1
ii  simple-scan  3.28.1-1
ii  totem-plugins3.26.1-1
ii  vinagre  3.22.0-5
ii  vino 3.22.0-3
ii  xdg-user-dirs-gtk0.10-2

Versions of packages gnome recommends:
ii  fonts-noto-color-emoji  0~20180424-2
ii  gnome-games 1:3.22+9
ii  nautilus-extension-brasero  3.12.2-4
ii  transmission-gtk2.94-1+b2

Versions of packages gnome suggests:
ii  alacarte 3.11.91-3
pn  empathy  
pn  firefox-esr-l10n-all | firefox-l10n-all  
pn  goobox | sound-juicer
pn  polari   
pn  xul-ext-ublock-origin

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme3.28.0-1
ii  at-spi2-core  2.28.0-3
ii  baobab3.28.0-2
ii  caribou   0.4.21-5
ii  dconf-cli 0.28.0-2
ii  dconf-gsettings-backend   0.28.0-2
ii  eog   3.28.3-1
ii  evince3.28.2-1
ii  evolution-data-server 3.28.5-3
ii  firefox-esr   52.9.0esr-1
ii  fonts-cantarell   0.0.25-4
ii  gdm3  3.28.2-4
ii  gedit 3.28.1-1
ii  gkbd-capplet  3.26.0-3
ii  glib-networking   2.56.1-1
ii  gnome-backgrounds 3.28.0-1
ii  gnome-bluetooth   3.28.2-1
ii  gnome-calculator  3.28.2-1
ii  gnome-characters  3.28.2-1
ii  gnome-contacts3.28.2-1
ii  gnome-control-center  1:3.28.2-1
ii  gnome-disk-utility3.28.3-1
ii  gnome-font-viewer 3.28.0-1
ii  gnome-keyring 3.28.0.2-1
ii  gnome-logs3.28.2-1
ii  gnome-menus   3.13.3-11
ii  gnome-online-accounts 3.28.0-1
ii  gnome-online-miners   3.26.0-3
ii  gnome-session 3.28.1-1
ii  gnome-settings-daemon 3.28.1-1
ii  gnome-shell   3.28.3-1
ii  gnome-shell-extensions3.29.3+really3.28.1-1
ii  gnome-software3.28.2-1
ii  gnome-sushi   3.28.3-1
ii  gnome-system-monitor  3.28.2-1
ii  gnome-terminal

Bug#906256: Bug#905379: anki: hangs after "'NoneType' object has no attribute 'installEventFilter'"

[Julian Gilbey]

severity 906256 minor
retitle 906256 libqt5webview5: stack_trace_posix.cc failed to open file
thanks

Dear Qt maintainers,

I spoke too soon, it turns out; I tried anki on another machine and it
didn't give this error, yet it still bombed out.  So it seems that
this is not the cause of the anki bug.

The message is still occurring, though, but it seems as if it's
probably mostly harmless.

Still got no idea about the cause of the anki bug, mind you!

Best wishes,

   Julian

Bug#906283: initramfs script expects file system on crypto device

[Guilhem Moulin]

Control: severity -1 wishlist

Hi Marc,

On Thu, 16 Aug 2018 at 16:50:55 +0200, Marc Haber wrote:
> Severity: normal

Lowering to ‘wishlist’ since AFAIK it's not the a regression; the check
is already place in 2:1.4.3-4 (stretch), 2:1.6.6-5 (jessie) and
2:1.7.3-4 (wheezy):


https://sources.debian.org/src/cryptsetup/2:1.7.3-4/debian/initramfs/cryptroot-script/#L352

https://sources.debian.org/src/cryptsetup/2:1.6.6-5/debian/initramfs/cryptroot-script/#L344

https://sources.debian.org/src/cryptsetup/2:1.4.3-4/debian/initramfs/cryptroot-script/#L319

> I am not sure how to solve this since the behavior of the new script
> seems in order in most regular cases.

Hmm we want that check for `--type=plain` indeed: unlocking a plain
dm-crypt device with a wrong key will happily succeed and yield a mapped
device full of noise; so the check avoids to inadvertently run `mkfs` or
perform other writes that would erase existing (but invisible due to the
key mismatch) non-volatile data.

However, for `--type=luks` (and I guess other header types for which
cryptsetup(8) can use the metadata to verify whether the passphrase is
correct) that check seems unnecessary.  I mean, if the user forgot to
run `mkfs` / `mkswap` for devices that are required at initramfs stage,
then subsequent scripts in the boot process will fail, and it's not
really the job of our own scripts to prevent that (the boot process
would also fail on plaintext devices with unknown file systems).

So I'd be in favor of removing that check for device types other than
‘plain’, without even introducing a new crypttab(5) option.  On top of
my head, the only thing we would stop protecting against, is if the
header is replaced (with `luksHeaderRestore`) with another one where 1/
the same passphrase can unlock both, and 2/ the master keys differ.  In
that case, if the corresponding crypttab(5) entry has the ‘tmp=’
or ‘swap’ options set, then existing non-volatile data might get lost.
Sounds quite an improbable scenario though.

Or did I miss something, Jonas? :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#906286: repository-format sub-policy

[Julian Andres Klode]

Package: debian-policy
Severity: wishlist

(more of a discussion for now)

6 years ago we started working on documenting the repository format
in the wiki[1] with the goal of making it a sub policy. I have not
done any work on converting it.

Should we move forward now with turning it into a policy? If so,
what are the next steps to do?

[1] https://wiki.debian.org/DebianRepository/Format

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

Kernel: Linux 4.17.0-6-generic (SMP w/8 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 debian-policy depends on:
ii  libjs-sphinxdoc  1.7.5-6

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
ii  doc-base  0.10.8

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#904261: changing a default behaviour in dh-golang for next compat level

[Clément Hermann]

Hi,

We (go team) are considering changing a default behaviour of dh-golang
in the next compat level (see #904261 for the specifics details). That
would be compat level 12, if I'm not mistaken.

How are we supposed to do this properly ? Not checking the compat level
and behaving accordingly, this is documented, but the communication
part: should we file a bug against debhelper too ?

Or should we just add the switch in the code and document it in
dh-golang, without coordinating with debhelper itself ?

Thanks for any insights!

Cheers,

-- 
nodens

Bug#906285: bugsquish FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: bugsquish
Version: 0.0.6-8
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

bugsquish fails to cross build from source, because it does not pass
cross tools (e.g. CC) to bugsquish. The easiest way of doing so is using
dh_auto_build. That is sufficient to make bugsquish cross buildable.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru bugsquish-0.0.6/debian/changelog 
bugsquish-0.0.6/debian/changelog
--- bugsquish-0.0.6/debian/changelog2014-10-23 21:48:44.0 +0200
+++ bugsquish-0.0.6/debian/changelog2018-08-16 17:37:44.0 +0200
@@ -1,3 +1,10 @@
+bugsquish (0.0.6-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 16 Aug 2018 17:37:44 +0200
+
 bugsquish (0.0.6-8) unstable; urgency=low
 
   * do not install upstream changeglog twice
diff --minimal -Nru bugsquish-0.0.6/debian/rules bugsquish-0.0.6/debian/rules
--- bugsquish-0.0.6/debian/rules2014-10-23 21:57:11.0 +0200
+++ bugsquish-0.0.6/debian/rules2018-08-16 17:37:43.0 +0200
@@ -30,7 +30,7 @@
dh_testdir
 
# Add here commands to compile the package.
-   $(MAKE) DEB_CFLAGS="$(DEB_CFLAGS)" \
+   dh_auto_build -- DEB_CFLAGS="$(DEB_CFLAGS)" \
DEB_LDFLAGS="$(DEB_LDFLAGS)" \
DATA_PREFIX=$(DESTDIR)/usr/share/games/$(TARGET)/
 

Bug#904261: [pkg-go] Bug#904261: Bug#904261: dh-golang: Don't install files listed in DH_GOLANG_EXCLUDES to dev pacakge

[Clément Hermann]

On 16/08/2018 17:13, Clément Hermann wrote:
> On 16/08/2018 16:26, Martín Ferrari wrote:

>> We could also change the default in the next debhelper compat mode;
>> dunno how this is normally handled, but it would be good to coordinate
>> so this change is documented.. In that case it might be even be sensible
>> to add the switch in the code now.
> That's a great idea. It looks easy enough to add the switch in the code,
> but I couldn't find how those things are usually handled for modules
> outside debhelper itself. I'll ask the perl team, apparently that's
> something they did in the past.

It's actually a bad example, as it's part of debhelper and not an
external module.

I'll send an email to the debhelper team and ask directly (CC-ing this BR).

Cheers,

-- 
nodens

Bug#904030: clipit: Copy/Paste is not working

[Andrew Atkinson]

Package: clipit
Version: 1.4.4-2
Followup-For: Bug #904030

Dear Maintainer,

I had to move to Gnome classic due to xfce4 not working, to find that copy was
not working. Both from the mouse and use of ctrl-c

ctrl-x seems to work but nothing is stored to past again either from the mouse
or ctrl-v.

Unistalling clipit and the fuctions return to normal.

Trying to run clipit from the terminal gives the attached error (sorry it is a
screen shot as copy and paste do not work)

Andrew



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

Kernel: Linux 4.16.0-2-amd64 (SMP w/12 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)
LSM: AppArmor: enabled

Versions of packages clipit depends on:
ii  libappindicator3-1  0.4.92-6
ii  libc6   2.27-5
ii  libglib2.0-02.56.1-2
ii  libgtk-3-0  3.22.30-2
ii  libpango-1.0-0  1.42.1-2
ii  libx11-62:1.6.5-1
ii  xdotool 1:3.20160805.1-4

clipit recommends no packages.

clipit suggests no packages.

-- no debconf information

Bug#906284: lintian: check for incomplete-creative-commons-license gives false positives: the "not a law firm" is a preamble, not a license

[Chris Lamb]

Hi Julian,

> The test for the human-readable rather than legal text of the Creative
> Commons licenses seems to fail, because the preamble about Creative
> Commons not being a law firm is not part of the license text, and
> neither is the postamble about Creative Commons not being a party to
> the license agreement; they are instead form the terms and conditions
> between Creative Commons and the person using a CC license.  So I
> cannot see why these parts should necessarily be included in the
> Debian copyright file.  Has there been a policy decision to require
> this, perhaps?
> 
> Also, it seems that this check would be better in the parse_license
> function when checking each license block rather than the run
> function, as there might be more than one CC license in a copyright
> file, and it is feasible that one is correct and one not.

CC'ing Jonathan Dowland who filed the original request for this
in #903470. Could you folks come to some agreement on a good/reliable
check?


Regards,

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

Bug#905687: snapshot.debian.org: openssl 1.0.1t-1+deb8u9 not indexed?

[Peter Palfrader]

Peter Palfrader schrieb am Thursday, dem 16. August 2018:
> srcpkg_id also matter.  So slightly less bad:
> 
> snapshot=> select * from (select count(*) as c, name, version, srcpkg_id from 
> binpkg group by name, version, srcpkg_id) as s where s.c > 1 order by s.c, 
> s.name, s.version;
>  c |  name   | version | srcpkg_id 
> ---+-+-+---
>  2 | nomacs  | 3.10.2+dfsg-1   |534441
>  2 | puredata-core   | 0.48.1-7|534442
>  2 | puredata-extra  | 0.48.1-7|534442
>  2 | puredata-utils  | 0.48.1-7|534442
>  2 | r-cran-rggobi   | 2.1.22-1|53
>  2 | r-cran-rgl  | 0.99.16-3   |534445
>  2 | r-cran-survival | 2.42-6-1|534447
>  2 | squeak-vm   | 1:4.10.2.2614-5 |534446
> (8 rows)

I have cleaned them up manually, added a constraint also on binpkgs
(there was one for srcpkgs already), ensured we run no more than one
indexer at any time.

Will soon start on having the backlog processed.
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#906281: lintian: Severity and Certainty of emacsen-common-without-dh-elpa are wrong / false positives despite "Certainty: certain"

[Axel Beckert]

Hi Chris,

Chris Lamb wrote:
> > This lintian tag should be:
> >
> > a) downgraded from "Severity: normal" level to either "Severity:
> >wishlist" or even "Severity: pedantic", and
> >
> > b) changed from "Certainty: certain" to "Certainty: wild-guess" as
> >there are clearly multiple and common cases where the switch to
> >dh-elpa is impossible as of now.
> >
> > Alternatively, the tag should be changed to be only emitted if the
> > binary package is named either elpa-*, *-el or *-mode
> 
> This sounds the most sensible way forward, ie. fixing most of the false-
> positives, rather than just making Lintian very slightly less noisy.

Please note that I'm not 100% sure if these wildcards would match all
relevant packages for now. Looking into the dh_elpa source code again
might reveal some better metrics. Maybe also David Bremner (reincluded
in Cc) might have some more insight with which packages dh-elpa works
and with which it doesn't.

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

Bug#906284: lintian: check for incomplete-creative-commons-license gives false positives: the "not a law firm" is a preamble, not a license

[Julian Gilbey]

Package: lintian
Version: 2.5.96
Severity: normal

The test for the human-readable rather than legal text of the Creative
Commons licenses seems to fail, because the preamble about Creative
Commons not being a law firm is not part of the license text, and
neither is the postamble about Creative Commons not being a party to
the license agreement; they are instead form the terms and conditions
between Creative Commons and the person using a CC license.  So I
cannot see why these parts should necessarily be included in the
Debian copyright file.  Has there been a policy decision to require
this, perhaps?

Also, it seems that this check would be better in the parse_license
function when checking each license block rather than the run
function, as there might be more than one CC license in a copyright
file, and it is feasible that one is correct and one not.

Best wishes,

   Julian

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

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-2
ii  bzip2  1.0.6-8.1
ii  diffstat   1.61-1+b1
ii  dpkg   1.19.0.5+b1
ii  file   1:5.34-2
ii  gettext0.19.8.1-6+b1
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34
ii  libarchive-zip-perl1.60-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.39-1
ii  libdpkg-perl   1.19.0.5
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b3
ii  libparse-debianchangelog-perl  1.2.0-12
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.72+repack-1
ii  man-db 2.8.4-2
ii  patchutils 0.3.4-2
ii  perl [libdigest-sha-perl]  5.26.2-7
ii  t1utils1.41-2
ii  xz-utils   5.2.2-1.3

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

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

-- no debconf information

Bug#865504: php-horde-image 2.3.6-1+deb9u1 (CVE-2017-9773, CVE-2017-9774 & CVE-2017-14650)

[Chris Lamb]

Dear Sébastien,

> > I've prepared an upload to fix the following:
> > 
> >  php-horde-image (2.3.6-1+deb9u1) stretch-security; urgency=high
> >   
> >   * CVE-2017-9773: [...]
> >   * CVE-2017-9774: [...]
> >   * CVE-2017-14650: [...]
[…]
> it looks OK to me, please upload to security-master.

Uploaded to security-master.


Regards,

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

Bug#904261: [pkg-go] Bug#904261: Bug#904261: dh-golang: Don't install files listed in DH_GOLANG_EXCLUDES to dev pacakge

[Clément Hermann]

On 16/08/2018 16:26, Martín Ferrari wrote:
> Hi Clément,
> 
> On 13/08/18 11:01, Clément Hermann wrote:
> 
>> It happened after Debcamp, but here is the MR:
>> https://salsa.debian.org/go-team/packages/dh-golang/merge_requests/3
> 
> I just took a look. I left a small comment, but otherwise looks like a
> good solution, and I'd merge it.


Thanks! I have my doubts as well regarding the verbosity. My approach
while testing this was that I rather wanted to much information that not
enough.

That said, the original command didn't print anything for file
installation. It's probably only relevant to debug dh-golang itself, so
I'd be okay with removing that.

> We could also change the default in the next debhelper compat mode;
> dunno how this is normally handled, but it would be good to coordinate
> so this change is documented.. In that case it might be even be sensible
> to add the switch in the code now.
That's a great idea. It looks easy enough to add the switch in the code,
but I couldn't find how those things are usually handled for modules
outside debhelper itself. I'll ask the perl team, apparently that's
something they did in the past.

Cheers,


nodens

Bug#906281: lintian: Severity and Certainty of emacsen-common-without-dh-elpa are wrong / false positives despite "Certainty: certain"

[Chris Lamb]

Axel Beckert wrote:

> This lintian tag should be:
>
> a) downgraded from "Severity: normal" level to either "Severity:
>wishlist" or even "Severity: pedantic", and
>
> b) changed from "Certainty: certain" to "Certainty: wild-guess" as
>there are clearly multiple and common cases where the switch to
>dh-elpa is impossible as of now.
>
> Alternatively, the tag should be changed to be only emitted if the
> binary package is named either elpa-*, *-el or *-mode

This sounds the most sensible way forward, ie. fixing most of the false-
positives, rather than just making Lintian very slightly less noisy.

(As an aside, I'm always curious when people put a lot of weight behind
the Certainty that Lintian reports; the various levels have no "real"
meaning and accordingly get very little attention from the Lintian
maintainers.)


Regards,

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

Bug#906276: chrony: System startup is blocked for minutes long

[Vincent Blut]

Hi Gustavo,

On Thu, Aug 16, 2018 at 01:09:39PM +, Gustavo Scalet wrote:

Package: chrony
Version: 3.3-2
Severity: important
Tags: patch

Dear Maintainer,

When trying out buster using fai-cloud-image scripts on Google cloud I
noticed that system took around 180 seconds to boot rather than 15
seconds (stretch).


By the way, in the systemd world, the default timeout for starting a 
unit is 90s. So I assume that chrony just fail to start before enough 
entropy has been gathered‽


After investigating, I detected it was a lack of entropy early on 
system startup that caused chrony to be blocked when calling 
getrandom(). That is an issue being reported on different 
projects[1][2] but I didn't see anyone reporting it for chrony at the 
moment. (Maybe the lack of entropy was not spotted when using buster 
outside of cloud providers?)


Sure, generating entropy on a VM can be quite problematic. To prevent 
entropy starvation in guests, I make use of VirtIO RNG which is probably 
the reason why I’m not affected by this issue.



The upstream project is patched already[3], but there is no new release
for the moment. I contacted the maintainer[4] and there should be a new
release in the following month that would contain that fix[5]. I chose
to report this bug and provide a patch in order to avoid others facing
this issue which is not so trivial to understand what is going on.


I was aware of this issue but I refrained from backporting 7c5bd948bb7e 
(util: fall back to reading /dev/urandom when getrandom() blocks) as 
like you said, nobody sent me a bug report, neither publicly nor 
privately, about this issue. However your bug report clearly shows that 
this problem has to be taken seriously. I’ll work on this on the 
weekend, hope that’s ok?


Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#906283: initramfs script expects file system on crypto device

[Marc Haber]

Package: cryptsetup-initramfs
Version: 2:2.0.4-2
Severity: normal

Hi,

since I am using a keyscript to unlock my crypto devices, I need to use
the initramfs option on all my crypto devices. That includes the virtual
disks for the virtual machines running on the box. Naturally, those
crypto devices don't contain a file system that is recognized by the
get_fstype function sourced from /usr/share/initramfs-tools/scripts/functions

get_fstype ()
{
local FS FSTYPE FSSIZE RET
FS="${1}"

# blkid has a more complete list of file systems,
# but fstype is more robust
FSTYPE="unknown"
eval $(fstype "${FS}" 2> /dev/null)
if [ "$FSTYPE" = "unknown" ]; then
FSTYPE=$(blkid -o value -s TYPE "${FS}")
fi
RET=$?

if [ -z "${FSTYPE}" ]; then
FSTYPE="unknown"
fi

echo "${FSTYPE}"
return ${RET}
}

[30/5020]mh@fan:~ $ sudo /usr/lib/klibc/bin/fstype /dev/mapper/salida
FSTYPE=unknown
FSSIZE=0
[31/5021]mh@fan:~ $ sudo blkid -o value -s TYPE /dev/mapper/salida
[32/5022]mh@fan:~ $

This, in turn, causes
/usr/share/initramfs-tools/scripts/local-top/cryptroot to wrongly assume
that device unlocking was unsuccessful, removes the unlocked device and
starts over.

I am not sure how to solve this since the behavior of the new script
seems in order in most regular cases. Maybe there should be another
crypttab option like "dont-expect-fs" that disables this sanity check
for insane setups like mine.

Greetings
Marc


-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.17.14-zgws1 root=/dev/mapper/root ro splash 
console=ttyS0,57600n8 quiet

-- /etc/crypttab
# this line to avoid accidental commenting of the root line

#fanbtr /dev/disk/by-id/dm-name-fan-c_fanbtr none 
luks,keyscript=/etc/fan/keyscript_fan_root
root /dev/disk/by-id/dm-name-fan-c_root none 
luks,keyscript=/etc/fan/keyscript_fan_root
#root /dev/disk/by-id/dm-name-fan-c_root none 
luks,keyscript=/etc/fan/keyscript_fan_root
#usr /dev/disk/by-id/dm-name-fan-c_usr none 
luks,keyscript=/etc/fan/keyscript_fan

swap0   /dev/disk/by-id/dm-name-fan-c_swap0 none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
boot/dev/disk/by-id/dm-name-fan-c_boot none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
fanbtr_r/dev/disk/by-id/dm-name-fan_r-c_fanbtr_r none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
kernel64/dev/disk/by-id/dm-name-fan-c_kernel64 none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
kernel32/dev/disk/by-id/dm-name-fan-c_kernel32 none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
kernelhome  /dev/disk/by-id/dm-name-fan-c_kernelhome none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan

salida  /dev/disk/by-id/dm-name-fan-c_salida none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
#salida_home/dev/disk/by-id/dm-name-fan-c_salida_home none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
#nechayev   /dev/disk/by-id/dm-name-fan-c_nechayev none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
#spinturn   /dev/disk/by-id/dm-name-fan-c_spinturn none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
#spinturn_home  /dev/disk/by-id/dm-name-fan-c_spinturn_home none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
#spinturn_mbd   /dev/disk/by-id/dm-name-fan-c_spinturn_mbd none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
tmpfs   /tmptmpfs   defaults0   0
/dev/mapper/root /  ext4 noatime,nodiratime 0   1
#/dev/mapper/fanbtr /  btrfs 
subvol=fan-root,ssd,noatime,nodiratime,clear_cache,enospc_debug,skip_balance 0  
 1
#/dev/mapper/fanbtr /mnt/snapshots/fanbtr btrfs 
subvol=snapshots,ssd,noatime,nodiratime,enospc_debug 0   1
/dev/mapper/fanbtr_r /mnt/snapshots/fanbtr_r btrfs 
subvol=snapshots,noauto,nofail,noatime,nodiratime 0   1
/dev/mapper/fanbtr_r /home/mh/bigstuff btrfs 
subvol=mhbig,nofail,noatime,nodiratime 0   1
/dev/mapper/fanbtr_r /home/mh/noback btrfs 
subvol=mhnoback,nofail,noatime,nodiratime 0   1
/dev/mapper/fanbtr_r /home/mh/music btrfs 
subvol=music,nofail,noatime,nodiratime 0   1
proc/proc   procdefaults0   0
#/dev/mapper/root /  ext4errors=remount-ro 0   1
/dev/mapper/swap0 swap  swapnofail  0   0
/dev/mapper/boot /boot  ext4nofail0   2
#/dev/mapper/usr /usr   ext4defaults0   2
#/dev/mapper/var /var   ext4defaults0   2
#/dev/mapper/home /home  ext4defaults0   2
#/dev/mapper/mhbig /home/mh/bigstuff ext4 

Bug#905960: amdgpu: After login the screen is corrupted, it is unusable in this state

[Julien Cristau]

Control: reassign -1 xserver-xorg-video-ati 1:18.0.1-1
Control: severity -1 important
Control: forwarded -1 https://bugs.freedesktop.org/105381
Control: tag -1 + upstream fixed-upstream

On 08/15/2018 11:07 AM, Michel Dänzer wrote:
> On 2018-08-12 02:01 PM, Andrew Goodbody wrote:
>> Package: xserver-xorg-video-amdgpu
>> Version: 18.0.1-1+b1
>> Severity: critical
>> File: amdgpu
>> Justification: breaks the whole system
> 
> No it doesn't, so the severity is inflated. The package is wrong as
> well, should be xserver-xorg-video-radeon.
> 
> 
> Anyway, this looks like another instance of
> https://bugs.freedesktop.org/105381 , fixed in upstream xf86-video-ati
> Git master. Meanwhile, you can avoid the problem with
> 
>   Option  "AccelMethod" "EXA"
> 
> or the modesetting driver.
> 
> 
Updating bug metadata.  Thanks Michel!

Cheers,
Julien

Bug#865505: php-horde-image 2.3.6-1+deb9u1 (CVE-2017-9773, CVE-2017-9774 & CVE-2017-14650)

[Sébastien Delafond]

On Jun/23, Chris Lamb wrote:
> I've prepared an upload to fix the following:
> 
>  php-horde-image (2.3.6-1+deb9u1) stretch-security; urgency=high
>   
>   * CVE-2017-9773: [...]
> 
>   * CVE-2017-9774: [...]
> 
>   * CVE-2017-14650: [...]
>   
> The full debdiff is attached. Please let me know if it is okay to
> upload.

Hi Chris,

it looks OK to me, please upload to security-master.

Cheers,

--Seb

Bug#904261: [pkg-go] Bug#904261: Bug#904261: dh-golang: Don't install files listed in DH_GOLANG_EXCLUDES to dev pacakge

[Martín Ferrari]

Hi Clément,

On 13/08/18 11:01, Clément Hermann wrote:

> It happened after Debcamp, but here is the MR:
> https://salsa.debian.org/go-team/packages/dh-golang/merge_requests/3

I just took a look. I left a small comment, but otherwise looks like a
good solution, and I'd merge it.

We could also change the default in the next debhelper compat mode;
dunno how this is normally handled, but it would be good to coordinate
so this change is documented.. In that case it might be even be sensible
to add the switch in the code now.

-- 
Martín Ferrari (Tincho)

Bug#905687: snapshot.debian.org: openssl 1.0.1t-1+deb8u9 not indexed?

[Peter Palfrader]

Peter Palfrader schrieb am Thursday, dem 16. August 2018:

> Peter Palfrader schrieb am Thursday, dem 16. August 2018:
> 
> > Peter Palfrader schrieb am Thursday, dem 16. August 2018:
> > 
> > > Apparently we haven't done indexing in a while.  It's possible that we
> > > forgot to re-enable this after the move of master from sibelius to
> > > sallinen.
> > 
> > Update.
> > 
> > We are running the indexing jobs.  But they are failing.
> > 
> > /srv/snapshot.debian.org/bin/snapshot:228:in `query_row': More than one 
> > result when querying for SELECT binpkg_id AS id FROM binpkg WHERE name=? 
> > AND version=? AND srcpkg_id=?. (RuntimeError)
> > from /srv/snapshot.debian.org/bin/snapshot:806:in `add_pkg'
> > from /srv/snapshot.debian.org/bin/snapshot:825:in `add_binpkg'
> > from /srv/snapshot.debian.org/bin/snapshot:1058:in 
> > `index_binary_package'
> > from /srv/snapshot.debian.org/bin/snapshot:1199:in `block in 
> > index_mirrorrun_from_parsing'
> > from /srv/snapshot.debian.org/bin/snapshot:214:in `query'
> > from /srv/snapshot.debian.org/bin/snapshot:1196:in 
> > `index_mirrorrun_from_parsing'
> > from /srv/snapshot.debian.org/bin/snapshot:1222:in `index_mirrorrun'
> > from /srv/snapshot.debian.org/bin/snapshot:1245:in `block in index'
> > from /srv/snapshot.debian.org/bin/snapshot:214:in `query'
> > from /srv/snapshot.debian.org/bin/snapshot:1241:in `index'
> > from /srv/snapshot.debian.org/bin/snapshot:1371:in `index'
> > from /srv/snapshot.debian.org/bin/snapshot:1480:in `'
> 
> 
> Hm.
> 
> snapshot=> select * from (select count(*) as c, name, version from binpkg 
> group by name, version) as s where s.c > 1 order by s.c, s.name, s.version 
> limit 3;
>  c | name | version 
> ---+--+-
>  2 | affs-modules-4.10.0-rc6-powerpc64-di | 4.10~rc6-1~exp2
>  2 | affs-modules-4.7.0-1-powerpc64-di| 4.7.2-1
>  2 | affs-modules-4.7.0-1-powerpc64-di| 4.7.4-2
> (3 rows)
> 
> snapshot=> select count(*) from (select count(*) as c, name, version from 
> binpkg group by name, version) as s where s.c > 1 ;
>  count 
> ---
>   3235
> (1 row)
> 
> Probably the result of a race while inserting.  But I thought we had a unique
> constraint there..

srcpkg_id also matter.  So slightly less bad:

snapshot=> select * from (select count(*) as c, name, version, srcpkg_id from 
binpkg group by name, version, srcpkg_id) as s where s.c > 1 order by s.c, 
s.name, s.version;
 c |  name   | version | srcpkg_id 
---+-+-+---
 2 | nomacs  | 3.10.2+dfsg-1   |534441
 2 | puredata-core   | 0.48.1-7|534442
 2 | puredata-extra  | 0.48.1-7|534442
 2 | puredata-utils  | 0.48.1-7|534442
 2 | r-cran-rggobi   | 2.1.22-1|53
 2 | r-cran-rgl  | 0.99.16-3   |534445
 2 | r-cran-survival | 2.42-6-1|534447
 2 | squeak-vm   | 1:4.10.2.2614-5 |534446
(8 rows)

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

Bug#905464: [Pkg-emacsen-addons] Bug#905464: dh-elpa: Expects .el file name to be based on package name (and does not consider "${pkg}-mode.el")

[Axel Beckert]

Control: clone -1 -2
Control: reassign -2 lintian 2.5.96
Control: retitle -2 lintian: Severity and Certainty of 
emacsen-common-without-dh-elpa are wrong / false positives despite "Certainty: 
certain"

Hi,

David Bremner wrote:
> > Since this is not primarily an emacs mode package but only ships an
> > emacs mode as an add-on, the package is not named elpa-tpp-mode or
> > tpp-mode but just tpp.
> 
> The assumption that the binary package is called elpa-foo (where is foo
> is deduced from the package.el metadata) is baked into dh-elpa at a
> pretty deep level. The assumption is that you will make a seperate
> binary package for the emacs stuff.

Yeah, that's what I feared and what I consider to be a bug.

> So I guess this bug could be considered a feature request to support
> a different use-case.

That's another possible way to see it. But in that case, the lintian
warning emacsen-common-without-dh-elpa
(https://lintian.debian.org/tags/emacsen-common-without-dh-elpa.html)
is definitely having the wrong Severity and Certainty.

Given that your "baked into dh-elpa at a pretty deep level" sounds as
if this is neither easy to fix nor will this come soonish, this
lintian tag should be:

a) downgraded from "Severity: normal" level to either "Severity:
   wishlist" or even "Severity: pedantic", and

b) changed from "Certainty: certain" to "Certainty: wild-guess" as
   there are clearly multiple and common cases where the switch to
   dh-elpa is impossible as of now.

Alternatively, the tag should be changed to be only emitted if the
binary package is named either elpa-*, *-el or *-mode, i.e. clearly
being a package which only ships some Emacs plugin and nothing else.
(Not sure if there are better criterias for the according whitelist.)

Cloning the bug report accordingly to get at least lintian fixed until
this is fixed in dh-elpa.

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

Bug#892539: Bug

[Ivo Blöchliger]

>
>   $ java -jar /usr/share/pdftk/pdftk.jar mypdf.pdf burst
>   Unhandled Java Exception in create_output():
>   java.lang.NoClassDefFoundError:
org/apache/commons/lang3/StringEscapeUtils

Same problem here, solved it by calling pdftk with the following wrapper
script (which might need editing to suit your needs, further missing
jar-files might be needed):

#!/bin/bash
/usr/bin/java -cp
/usr/share/java/commons-lang3.jar:/usr/local/bin/pdftk.jar pdftk "$@"

For reasons I did not follow or verify any further, the classpath (-cp)
option seems to have no effect when running the application with java -jar

Regards

Ivo

Bug#905687: snapshot.debian.org: openssl 1.0.1t-1+deb8u9 not indexed?

[Peter Palfrader]

Peter Palfrader schrieb am Thursday, dem 16. August 2018:

> Peter Palfrader schrieb am Thursday, dem 16. August 2018:
> 
> > Apparently we haven't done indexing in a while.  It's possible that we
> > forgot to re-enable this after the move of master from sibelius to
> > sallinen.
> 
> Update.
> 
> We are running the indexing jobs.  But they are failing.
> 
> /srv/snapshot.debian.org/bin/snapshot:228:in `query_row': More than one 
> result when querying for SELECT binpkg_id AS id FROM binpkg WHERE name=? AND 
> version=? AND srcpkg_id=?. (RuntimeError)
> from /srv/snapshot.debian.org/bin/snapshot:806:in `add_pkg'
> from /srv/snapshot.debian.org/bin/snapshot:825:in `add_binpkg'
> from /srv/snapshot.debian.org/bin/snapshot:1058:in 
> `index_binary_package'
> from /srv/snapshot.debian.org/bin/snapshot:1199:in `block in 
> index_mirrorrun_from_parsing'
> from /srv/snapshot.debian.org/bin/snapshot:214:in `query'
> from /srv/snapshot.debian.org/bin/snapshot:1196:in 
> `index_mirrorrun_from_parsing'
> from /srv/snapshot.debian.org/bin/snapshot:1222:in `index_mirrorrun'
> from /srv/snapshot.debian.org/bin/snapshot:1245:in `block in index'
> from /srv/snapshot.debian.org/bin/snapshot:214:in `query'
> from /srv/snapshot.debian.org/bin/snapshot:1241:in `index'
> from /srv/snapshot.debian.org/bin/snapshot:1371:in `index'
> from /srv/snapshot.debian.org/bin/snapshot:1480:in `'


Hm.

snapshot=> select * from (select count(*) as c, name, version from binpkg group 
by name, version) as s where s.c > 1 order by s.c, s.name, s.version limit 3;
 c | name | version 
---+--+-
 2 | affs-modules-4.10.0-rc6-powerpc64-di | 4.10~rc6-1~exp2
 2 | affs-modules-4.7.0-1-powerpc64-di| 4.7.2-1
 2 | affs-modules-4.7.0-1-powerpc64-di| 4.7.4-2
(3 rows)

snapshot=> select count(*) from (select count(*) as c, name, version from 
binpkg group by name, version) as s where s.c > 1 ;
 count 
---
  3235
(1 row)

Probably the result of a race while inserting.  But I thought we had a unique
constraint there..

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

Bug#905687: snapshot.debian.org: openssl 1.0.1t-1+deb8u9 not indexed?

[Peter Palfrader]

Peter Palfrader schrieb am Thursday, dem 16. August 2018:

> Apparently we haven't done indexing in a while.  It's possible that we
> forgot to re-enable this after the move of master from sibelius to
> sallinen.

Update.

We are running the indexing jobs.  But they are failing.

/srv/snapshot.debian.org/bin/snapshot:228:in `query_row': More than one result 
when querying for SELECT binpkg_id AS id FROM binpkg WHERE name=? AND version=? 
AND srcpkg_id=?. (RuntimeError)
from /srv/snapshot.debian.org/bin/snapshot:806:in `add_pkg'
from /srv/snapshot.debian.org/bin/snapshot:825:in `add_binpkg'
from /srv/snapshot.debian.org/bin/snapshot:1058:in 
`index_binary_package'
from /srv/snapshot.debian.org/bin/snapshot:1199:in `block in 
index_mirrorrun_from_parsing'
from /srv/snapshot.debian.org/bin/snapshot:214:in `query'
from /srv/snapshot.debian.org/bin/snapshot:1196:in 
`index_mirrorrun_from_parsing'
from /srv/snapshot.debian.org/bin/snapshot:1222:in `index_mirrorrun'
from /srv/snapshot.debian.org/bin/snapshot:1245:in `block in index'
from /srv/snapshot.debian.org/bin/snapshot:214:in `query'
from /srv/snapshot.debian.org/bin/snapshot:1241:in `index'
from /srv/snapshot.debian.org/bin/snapshot:1371:in `index'
from /srv/snapshot.debian.org/bin/snapshot:1480:in `'

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

Bug#905687: snapshot.debian.org: openssl 1.0.1t-1+deb8u9 not indexed?

[Peter Palfrader]

Marc Lehmann schrieb am Wednesday, dem 08. August 2018:

> Package: snapshot.debian.org
> Severity: normal
> 
> Dear Maintainer,
> 
> thanks for the having this wonderful service, and providing a stable (over
> years) machine readable interface to it. I am using it for a while now to
> fetch packages and package metadata, but recently run into a problem with
> a security update that is available on snapshot.debian.org, but seemingly
> not indexed.
> 
> Specifically, I see openssl 1.0.1t-1-deb8u9, apparently accepted
> 2018-07-28:
> 
>
> http://snapshot.debian.org/archive/debian-security/20180806T184500Z/pool/updates/main/o/openssl/

Apparently we haven't done indexing in a while.  It's possible that we
forgot to re-enable this after the move of master from sibelius to
sallinen.

snapshot=> select * from file where name='openssl_1.0.1t-1+deb8u9.dsc';
 file_id  |name | size |   hash 
  | node_id
--+-+--+--+--
 52592898 | openssl_1.0.1t-1+deb8u9.dsc | 2423 | 
5accd20beb57cdd4867aef2dce6bea04cd2067f1 | 54016625
(1 row)

snapshot=> select * from  node where node_id=54016625;
 node_id  | parent | first | last
--++---+---
 54016625 |  18993 | 57150 | 57463
(1 row)

snapshot=> select * from mirrorrun where mirrorrun_id = 57150;
 mirrorrun_id | archive_id | run |mirrorrun_uuid
|   importing_host
--++-+--+-
57150 |  2 | 2018-07-28 03:05:28 | 
13764e16-87a4-40de-afa5-4a25ddd9ddb0 | sallinen.debian.org
(1 row)



snapshot=> select * from indexed_mirrorrun order by mirrorrun_id desc limit 4;
 mirrorrun_id |   source
--+
56938 | recurse(Q)
56937 | index(Q)
56936 | index(Q)
56935 | index(Q)
(4 rows)

snapshot=> select * from mirrorrun order by mirrorrun_id desc limit 4;
 mirrorrun_id | archive_id | run |mirrorrun_uuid
|   importing_host
--++-+--+-
57471 |  1 | 2018-08-16 09:15:38 | 
af2f35e4-027f-4efe-b940-3706e1efc91a | sallinen.debian.org
57470 |  6 | 2018-08-16 09:07:20 | 
a306ca7d-ca3a-4ac1-bcf7-419e957b47b1 | sallinen.debian.org
57469 |  7 | 2018-08-16 09:01:00 | 
e34deae0-ea47-4c3c-a176-087256d87f39 | sallinen.debian.org
57468 |  6 | 2018-08-16 04:12:05 | 
ec1c210c-f868-45dd-9078-9d8c3a765d6b | sallinen.debian.org
(4 rows)

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

Bug#906280: ITP: ionit -- Render configuration files from Jinja templates

[Benjamin Drung]

Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: ionit
  Version : 0.1
  Upstream Author : Benjamin Drung 
* URL : https://github.com/bdrung/ionit
* License : ISC
  Programming Lang: Python 3
  Description : Render configuration files from Jinja templates

ionit is a simple and small configuration templating tool. It collects a
context and renders Jinja templates in a given directory. The context
can be either static JSON or YAML files or dynamic Python files. Python
files can also define functions passed through to the rendering.

ionit comes with an early boot one shot service that is executed before
the networking service which allows one to generate configurations files
for the networking and other services before they are started. In this
regard, ionit can act as tiny stepbrother of cloud-init.

I developed this tool since we found nothing similar. We will use ionit
in our company. I will maintain the package on my own.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
10405 Berlin

Email: benjamin.dr...@profitbricks.com
URL: https://www.profitbricks.de

Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B
Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens