Bug#843348: Network-console ssh session closes immediately

[Richard Huynh]

Package: installation-reports

Boot method: network-console
Image version: 
https://d-i.debian.org/daily-images/armel/20161105-01:20/kirkwood/network-console/buffalo/ls-qvl/
Date: 2016/11/05

Machine: Buffalo Linkstation LS-QVL
Processor:
Memory:
Partitions:

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

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[E]

Comments/Problems:

Boots and brings up network and ssh, however immediately closes the
ssh session upon correct entry of installer:install username and
password. Image from the 20161021 has the same issue, however one from
20160516 does not appear to be affected.

Bug#843347: python-migrate-doc: Section should be “doc”

[Ben Finney]

Package: python-migrate-doc
Version: 0.10.0-6
Severity: minor

Dear Maintainer,

The package ‘python-migrate-doc’ installs primarily documentation for
another package. It should not be in the “python” section.

By the section descriptions, this package may belong in section “doc”.

Please set the field “Section” appropriately on this package.


Since the package is already in Debian with a different section, you
will also need to submit a request to override the existing section
.

Then mark this bug report as blocked by that new one, and be sure not
to close this one until that new one is completed.

-- 
 \  “For my birthday I got a humidifier and a de-humidifier. I put |
  `\  them in the same room and let them fight it out.” —Steven Wright |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#843336: Pending fixes for bugs in the libproc-processtable-perl package

[pkg-perl-maintainers]

tag 843336 + pending
thanks

Some bugs in the libproc-processtable-perl package are closed in
revision b5a44b6a6443f4f93422a226cd8ff497e00fcbe3 in branch 'master'
by Salvatore Bonaccorso

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libproc-processtable-perl.git/commit/?id=b5a44b6

Commit message:

Adjust references to manpages in POD to not include .pm name ending

Closes: #843336

Bug#843346: dvidvi FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: dvidvi
Version: 1.0-8etch2.1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

dvidvi fails to cross build from source, because it uses the build
architecture compiler and thus fails stripping the wrong architecture
executable. Switching to triplet-prefixed tools fixes the cross build.
Please consider applying the attached patch.

Helmut
diff -u dvidvi-1.0/debian/changelog dvidvi-1.0/debian/changelog
--- dvidvi-1.0/debian/changelog
+++ dvidvi-1.0/debian/changelog
@@ -1,3 +1,10 @@
+dvidvi (1.0-8etch2.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use triplet-prefixed compiler (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 06 Nov 2016 06:21:17 +0100
+
 dvidvi (1.0-8etch2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u dvidvi-1.0/debian/rules dvidvi-1.0/debian/rules
--- dvidvi-1.0/debian/rules
+++ dvidvi-1.0/debian/rules
@@ -1,5 +1,9 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+ifeq ($(origin CC),default)
+CC := $(DEB_HOST_GNU_TYPE)-gcc
+endif
 CFLAGS := -Wall -g -O$(if $(findstring noopt,$(DEB_BUILD_OPTIONS)),0,2)
 
 build: build-arch build-indep

Bug#842555: QA upload

[Dmitry Bogatov]

[2016-11-03 09:37] "gustavo panizzo (gfa)" 
>
> I intend to do a QA upload for this package soon, if anybody wants to be
> the real maintainer, ping me I can handover my improvements to you

Hello! I am interested in tsocks maintainership and your improvements.

-- 
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.


pgpckq3apsWsj.pgp
Description: PGP signature

Bug#842941: Compraison with autoopts

[Dmitry Bogatov]

[I do not intent to adopt it]

FWITW, judging from description, it is superseded by AutoOpts (part of
autogen suite).

-- 
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.


pgpaHvtj759HL.pgp
Description: PGP signature

Bug#831848: [Reportbug-maint] Bug#831848: raising severity

[Sandro Tosi]

On Sat, Nov 5, 2016 at 10:19 PM, Ben Finney  wrote:
> Control: severity -1 wishlist

Ben, please stop playing the severity game - leave it to the reportbug
maintainers, thanks

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#841909: merging yet another bug about pinentry-gnome3

[Daniel Kahn Gillmor]

Control: reassign 842908 pinentry-gnome3 0.9.7-6
Control: fixed 842908 0.9.7-7
Control: forcemerge 841909 842908

https://bugs.debian.org/842908 is yet another instance of
pinentry-gnome3 (0.9.7-6) causing problems when DISPLAY is unset but
dbus is available.  It should be resolved in pinentry 0.9.7-7 as well.

 --dkg


signature.asc
Description: PGP signature

Bug#841222: Acknowledgement (RFS: patat)

[Sean Whitton]

control: tag -1 +confirmed
control: noowner -1

Hello Félix,

I'm tagging this as confirmed (commit
184eb7ba0dfb453cd5aa759a1a88fdbee6ed5367) because you've addressed
everything I brought up, but I've also written some comments below in
response to your most recent message.

On Mon, Oct 31, 2016 at 05:33:16PM +0100, Félix Sipma wrote:
> > On Tue, Oct 25, 2016 at 10:34:11PM +0200, Félix Sipma wrote:
> >> On 2016-10-23 11:51-0700, Sean Whitton wrote:
> >>> You should use "Forwarded: not-needed" (see DEP-3).
> >> 
> >> This does not seem to work with gbp-pq (see #785274), I propose to add 
> >> this as
> >> soon as gbp-pq supports DEP-3.
> > 
> > Indeed.  Dmitry Bogatov pointed out to me that you can put the
> > Forwarded: header at the end of the patch description (just before the
> > ---) and then gbp won't remove it.
> 
> It seems like gbp _does_ remove the Forwarded: header put just before the
> ---...

Not on my machine -- weird.

iris ~/rfs/patat % gbp pq import
gbp:info: Trying to apply patches at
'184eb7ba0dfb453cd5aa759a1a88fdbee6ed5367'
gbp:info: 1 patches listed in 'debian/patches/series' imported on
'patch-queue/master'
iris ~/rfs/patat % gbp pq export
gbp:info: On 'patch-queue/master', switching to 'master'
gbp:info: Generating patches from git (master..patch-queue/master)
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
gbp:info: Dropped branch 'patch-queue/master'.
iris ~/rfs/patat % git diff
[no output, and indeed your Forwarded: header is present]

> > I wanted to confirm that you'd forwarded your --version patch, but I
> > couldn't without this header :)
> 
> This particular patch is not needed anymore (fixed upstream). I pushed a new
> version to my repo, and will put this new version on mentors as soon as pandoc
> gets installable again.

Looks good.

> > I: patat: spelling-error-in-binary usr/bin/patat Nam Name
> > I: patat: spelling-error-in-binary usr/bin/patat isn't isn't
> > I: patat: spelling-error-in-binary usr/bin/patat forward forward
> > I: patat: spelling-error-in-binary usr/bin/patat upto up to
> > I: patat: spelling-error-in-binary usr/bin/patat discontigous 
> > discontiguous
> > I: patat: spelling-error-in-binary usr/bin/patat uncomplete incomplete
> > I: patat: spelling-error-in-binary usr/bin/patat The The
>
> [...]
> 
> I guess it is better to not override this warning, so that we don't forget 
> that
> the dependencies needs to be fixed.

Fair enough.  My reasoning was that you can't fix it within this
package, so the warning shouldn't be emitted here.

> > 2. Did you generate it with help2man, in the end?  If so, there should
> > be a rule in d/rules to allow someone to regenerate the manpage for a
> > new upstream version (see the ocrmypdf package's rules file).  If
> > upstream introduces a new upstream version it should be easy to update
> > the manpage.
> 
> No. I did it by hand, help2man generated something ugly :-).

Cool!

> > 3. It might be nice to add a reference to the file in
> > /usr/share/doc/patat/examples to the manpage.  If I wanted to learn
> > how to use patat, the manpage alone wouldn't be much use.
> 
> Upstream is working on a manpage (see
> https://github.com/jaspervdj/patat/issues/19 ). I'll add this manpage later,
> for now I would like to have patat in debian. This manpage stuff is not
> essential (and it takes time to work on it, that's why I didn't want to work 
> on
> this), so I'd like to keep it like this, and update it as soon as upstream
> release a manpage.

I understand why you wouldn't want to work on a manpage in parallel with
upstream's work, as you'll have to just throw yours away once they
release theirs.  It's good to hear that they've decided to work on
that -- thanks for prompting them.

General remarks in response to what you wrote:

Debian has a lot of unmaintained and low-quality packages because people
wanted to "have it in Debian", but weren't willing to put time into
making the package high-quality.  That's why, in the RFS review process,
we try to give new contributors opportunities to demonstrate that they
want to make their package high-quality.  DDs are generally reluctant to
sponsor packages where it is not clear that the packager is planning to
continue to put time into the package after it has been uploaded.

In this case you've amply demonstrated that you're willing to maintain
the package, but I just wanted to explain to you why I've been insisting
on these things that, as you say, aren't essential.

> patat is buildable again on sid.

I just built and installed the package and everything seems to work.

You could look into adding the hardening flags, now that the Haskell
transition is almost completely finished.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#842796: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

On Sat, 05 Nov 2016, Ian Jackson wrote:
> Looking at the code, I think that gs in jessie is plainly violating
> the rules about the use of pthread locks.  On my partner's machine,

Per logs from message #15 on bug #842796:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842796#15

SIGSEGV on __lll_unlock_elision is a signature (IME with very high
confidence) of an attempt to unlock an already unlocked lock while
running under hardware lock elision.


Well, unlocking an already unlocked lock is a pthreads API rule
violation, and it is going to crash the process on something that
implements hardware lock elision.

These would be Intel x86 processors with TSX enabled[1] for Debian
8/jessie.  For Debian 9/stretch and for unstable, I believe it also
includes IBM Power8, and s390x systems -- AFAIK they won't forgive an
attempt to unlock an unlocked lock any more than Intel TSX does.

[1] Broadwell-E, Skylake, and later processors, as well as Xeon *v5
processors.  I am not sure if we blacklisted any of the Xeon *v4
or not, and too tired to look their model numbers up right now.

Unfortunately, when hardware lock elision support was added to glibc
upstream, libpthreads was *not* changed to properly assert() this
forbidden condition on the non-hardware-elision codepaths.  Such an
assert() would have given us consistent behavior, thus flushing the bugs
out in the open... at the cost of a performance hit (I have no idea how
severe), and much screaming.

To be fair: it is likely nobody upstream had any idea of just how much
code got libpthreads usage wrong... and we certainly didn't know better
in Debian, either.  Well, now we're going to find out :-(

BTW, AFAIK libpthreads still doesn't have any such assert(), so there's
likely a lot of such buggy code in unstable still.  This is going to
cause trouble for Debian stretch, too.

> Has something changed in jessie's libc recently ?  I find it difficult
> to imagine that these bugs would have been missed earlier during the
> life of jessie.

The required hardware was not widely available at the time, the
knowledge of how hardware lock elision would really behave was sparse
outside of Intel and IBM -- so people either didn't know, or did not
grasp the importance of the fact that the hardware would be utterly
intolerant to something that the old code was too lenient about -- and
libpthreads was not instrumented to compensate for that.

I actually recommended that it would be safer to disable lock elision
for jessie[2]: the sharp corners nature of the code in glibc 2.19 scared
me, as well as just how messed up the implementation on Intel processors
were at the time.  Unfortunately, I didn't push for it at all: I didn't
know how correct I were at the time[3].

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195#50

The hard truth is that nobody in Debian knew how deep those murky waters
were at the time[3], and I don't think glibc upstream developers did
either.  So, we limited ourselves in Debian to blacklisting the
processors where Intel (either for sure, or highly likely) screwed it up
beyond repair.

[3] A number of subtle Intel TSX errata were fixed by Skylake and
Broadwell microcode updates, and the latest ones are quite recent.
The until-then latent (or subtle) broken locking bugs in
applications/libs becoming high-hitter crashers as more users get
newer computers, etc.

Anyway, any library or application that hits this issue has broken
locking, plain and simple.

A package crashing from this issue very likely requires a stable update
to fix the locking (which won't always be a trivial fix, either), even
if we changed libpthreads to disable lock elision support and it stopped
the crashes -- even if it wouldn't crash anymore, the locking would
still be broken and therefore suspect of not being as effective as it
would have to be to ensure correct operation at all times.

> I will try to make a patch to fix ghostscript, or at least file a
> proper bug.  But, if there was a libc change, would it be possible to
> revert it or make some kind of workaround ?

If the problem is too widespread and too hard to fix on a large number
of packages, I suppose we could ask the glibc maintainers to consider
disabling hardware lock elision support in stable through a stable
update.

Such a change to glibc would likely requires some patches to ensure it
*really* disabled Intel TSX opcode/instruction insertion, but I think we
already ship all of them as part of the Intel TSX blacklist.  The result
would need real-world testing on an up-to-date Skylake box as well as
objdump inspection to ensure *no* TSX-related instructions leaked into
the binaries.

And what should we do about Debian stretch, then?

Some references:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824191
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800574
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195

-- 
  Henrique Holschuh

Bug#843118: seabios: Unable to boot KVM guest with "-display none"

[Greg]

Le 2016-11-05 18:37, Michael Tokarev a écrit :


Control: tag -1 + moreinfo unreproducible

04.11.2016 03:26, Gregory Auzanneau wrote:


Package: seabios
Version: 1.9.3-2
Severity: normal

Dear Maintainer,

Since the latest update of seabios 1.9.3-2, a guest machine can't 
start with qemu parameter "-display none".

The guest hang immediatly at boot with all vCPU at 100%.

If I revert back to seabios 1.8.2-1, the problem is solved.
If I add a virtual graphic card, the is problem is also solved.


Please tell us which guest is that and how do you start it, and 
whenever

this is a generic problem (whith other guests too) or just this guest.

I can run several qemu guests with -display none here, including linux
and freebsd (with serial console), with either version of seabios.
On the contrary, with either version of seabios, running win7 guest
with this option results in 100% CPU consumption a few seconds after
the start, -- guess this is something to do with windows, but I'm
not sure. At any rate, this behavour does not seem to be seabios
version dependent.

Thanks,

/mjt


Hello M. Tokarev,

I've try on two different hosts (one server and one workstation) and 
different debian guests (jessie and stretch).
Next to your mail, I've also installed a W7 guest to test if this OS is 
also concerned, but W7 works correctly.

This seems to only involve Debian (Linux ?) guests.

The guest are launched with libvirt. You will find in attachement an my 
libvirt setup for on test guest.

Adding serial console don't solve the issue.


Best regards,
Gregory



  debian8
  1a5f3d88-cc89-4157-949f-60be92749a47
  1048576
  1048576
  2
  
hvm

  
  



  
  

  
  



  
  destroy
  restart
  restart
  


  
  
/usr/bin/kvm

  
  
  
  


  


  
  


  
  


  
  



  


  
  
  
  




  

  

Bug#831848: raising severity

[Ben Finney]

Control: severity -1 wishlist

On 04-Nov-2016, Noah Meyerhans wrote:

> Per discussion among the cloud team, I'm raising these bugs to
> important. We want to be sure we release stretch with at least basic
> support for the cloud.debian.org pseudopackage.

There is nothing about this request to Reportbug that meets the
“important” severity, IMO.

This is a valid request, at “wishlist” severity IMO.

-- 
 \“I was in Las Vegas, at the roulette table, having a furious |
  `\ argument over what I considered to be an odd number.” —Steven |
_o__)   Wright |
Ben Finney 


signature.asc
Description: PGP signature

Bug#807994: python-django-south: Incompatable with Django >= 1.7

[Brian May]

Sandro Tosi  writes:

> On Tue, 15 Dec 2015 16:40:34 +1100 Brian May  wrote:
>> Source: python-django-south
>> Version: 1.0.0-1
>> Severity: grave
>> Justification: renders package unusable
>>
>> Package is broken with Django 1.7+ in Debian and not fit for release. It
>> will not get fixed, as the functionality has been replaced by the Django
>> 1.7 migration mechanism.
>>
>> I was going to file a bug report to remove the package, however then I
>> noticed there are packages that still depend on this package.
>>
>> (sid-amd64)root@prune:/home/brian# apt-cache rdepends
>> python-django-south
>> python-django-south
>> Reverse Depends:
>>   bcfg2-web
>>   python-django-voting
>>   python-django-threadedcomments
>>   lava-server
>>   python-django-sitetree
>>   python-django-picklefield
>
> What is the plan here? Brian/David, maybe you could just file RC bugs
> on the rdepends to move away from django-south? thanks!

I think I did this already:

#807998 - bcfg2-web (possibly unfixed)
#807999 - lava-server (fixed)
#808000 - python-django-sitetree (fixed)

If there are any other packages - I haven't looked for some time now -
feel free to report bugs.
-- 
Brian May 

Bug#822522: reportbug: Crash when python-gtkspellcheck is installed

[Ben Finney]

Control: severity -1 normal
Control: tags -1 + moreinfo

On 24-Apr-2016, JWM wrote:

> While reporting a bug, the reportbug application suggests installing
> python-gtkspellcheck, but having that package installed actually
> makes reportbug crash with the following traceback:

I don't see that behaviour, with Reportbug version “6.6.6”:

=
$ reportbug --version
reportbug 6.6.6

$ grep ui ~/.reportbugrc | grep -v '^#'
ui gtk2

$ aptitude show python-gtkspellcheck | grep Version
Version: 3.0-1.1

$ LANGUAGE= LC_ALL= reportbug

=

The GUI appears correctly, with no crash.

What else is needed for someone else to reproduce the behaviour you
report?

-- 
 \  “People demand freedom of speech to make up for the freedom of |
  `\   thought which they avoid.” —Soren Aabye Kierkegaard (1813–1855) |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#843344: Additional package Information

[Bernhard Rieder]

I forgot to mention that I am using a custom version of the package with
the described bugfix in place. Therefore the package version number -2
instead of -1.

Bug#843345: python-gtkspellcheck: please add dependency “Suggests: python-gtkspellcheck-doc”

[Ben Finney]

Source: pygtkspellcheck
Version: 3.0-1.1
Severity: minor

Dear Maintainer,

Working with the ‘pygtkspellcheck’ packages requires understanding how
it works and what it does.

Please set a “Suggests: python-gtkspellcheck-doc” dependency to the
binary packages ‘python-gtkspellcheck’ and ‘python3-gtkspellcheck’, or
other binary packages for which it is appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \  “It's a good thing we have gravity or else when birds died |
  `\ they'd just stay right up there. Hunters would be all |
_o__)confused.” —Steven Wright |
Ben Finney 


signature.asc
Description: PGP signature

Bug#828665: FTBFS under Django 1.10

[Brian May]

Sandro Tosi  writes:

> Hey Brian it looks like 1.7.4 supports django 1.10 (inferred as
> https://github.com/django-extensions/django-extensions/commit/a0e6fb8619d90afe6a81a77059895ead3524707d
> is right after the tag to release 1.7.4) so could you try to package
> the latest version and verify it works with django 1.10? thanks!!

Done.
-- 
Brian May 

Bug#843344: pgadmin3 segfaults on start

[Bernhard Rieder]

Package: pgadmin3
Version: 1.22.1-2
Severity: grave
Justification: renders package unusable

pgadmin crashes in plugin.cc:383 when obj->GetConnection() returns 0


instead of:
if (!obj || !(obj->GetConnection()->GetStatus() == PGCONN_OK))

it should read:
if (!obj || !obj->GetConnection() || !(obj->GetConnection()->GetStatus() ==
PGCONN_OK))

maybe this is related to my recent upgrade from pg9.5 to pg9.6 (including all
libraries)
another reason could be that I enabled PG debugging of stored procedures
forpg9.5 but not yet for pg9.6

Since it will probably not be fixed on upstream please could you kindly fix it
for the debian package



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

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

Versions of packages pgadmin3 depends on:
ii  libc6 2.24-3
ii  libgcc1   1:6.2.0-1
ii  libpq59.6.1-2
ii  libssl1.0.2   1.0.2j-1
ii  libstdc++66.2.0-1
ii  libwxbase3.0-0v5  3.0.2+dfsg-2
ii  libwxgtk3.0-0v5   3.0.2+dfsg-2
ii  libxml2   2.9.4+dfsg1-1
ii  libxslt1.11.1.29-2
ii  pgadmin3-data 1.22.1-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages pgadmin3 recommends:
ii  pgagent3.4.1-3
ii  postgresql-client-9.6 [postgresql-client]  9.6.1-2

Versions of packages pgadmin3 suggests:
ii  postgresql-contrib  9.6+177

-- no debconf information

Bug#803675: [Reportbug-maint] Bug#803675: reportbug: unable to report bug on kernel

[Ben Finney]

Control: summary -1 10
Control: severity -1 normal

On 01-Nov-2015, Sandro Tosi wrote:
> it's a limitation of the GTK interface, please use the text
> interface

What is the limitation, specifically?

What improvement could be made in the Gtk interface, to resolve this
limitation?

-- 
 \ “I was trying to daydream, but my mind kept wandering.” —Steven |
  `\Wright |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#812220: reportbug: Bad Prompt Wording

[Ben Finney]

Control: severity -1 minor
Control: tags -1 + moreinfo

On 21-Jan-2016, Stirling Westrup wrote:

> I just lost a reportbug report on another issue, due to bad wording in a
> reportbug prompt.

Sorry to hear. That is frustrating.

> Due to a bad configuration, my report failed to send (reportbug
> couldn't find my MTA) and it gave me a prompt which said
> (paraphrasing)

As written, this bug report currently cannot be actioned.

What specific text (not a paraphrase) causes the confusion? What
specific change would resolve the problem?

-- 
 \“I took it easy today. I just pretty much layed around in my |
  `\underwear all day. … Got kicked out of quite a few places, |
_o__)  though.” —Bug-Eyed Earl, _Red Meat_ |
Ben Finney 


signature.asc
Description: PGP signature

Bug#717563: reportbug: web access thru proxy not available

[Ben Finney]

Control: tags -1 + moreinfo
Control: found -1 reportbug/6.6.3

On 31-Oct-2013, Nicolas Schier wrote:

> Running querybts with strace results in:
> 
>   nicolas@my-machine:~$ strace -e trace=connect querybts 
> --proxy=http://172.16.0.66:8080/ -b reportbug

I don't see the error you report, with Reportbug version “6.6.6”. The
connection succeeds and the ‘querybts’ command continues successfully.

> Does that help?  Do you need something more?

Do you still see the reported failure in the Reportbug from current Sid?


On 22-Jul-2013, Olaf Zaplinski wrote:

> when reportbug asks for a proxy server and I enter the apt.conf proxy
> setting
> http://user:p...@proxyhost.example.com:8080
> then internet access still fails.

Does this still occur in the latest Reportbug from Sid?


On 09-Jan-2015, Andrew Gallagher wrote:
> This bug is still present in testing.

With which version did you experience this? Do you still see the
reported failure in Reportbug from current Sid?


On 02-Apr-2016, Lasse Makholm wrote:
> This is a problem in Jessie (8.2) using reportbug 6.6.3

Thank you. Do you still see the reported failure in Reportbug 6.6.6
(or the latest from Sid when you read this)?

-- 
 \ “Religions have contrived to make it impossible to disagree |
  `\   with them critically, without being rude.” —Daniel Dennett, |
_o__)  _The Four Horsemen_, 2008-05-20 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#843343: rename package does not provide same functionality as deprecated "prename" despite the claim

[Matti Hamalainen]

Package: rename
Version: 0.20-4
Severity: normal

Dear Maintainer,

Latest version of /usr/bin/prename (which provides "rename") provided by
package "perl" warns that "Deprecated program in use: rename as shipped with
the Debian perl package will be removed after the release of stretch. Please
install the separate 'rename' package which will provide the same command."

However, the command provided by package "rename" is not the exact same
command. For example the "-n" option functions cosmetically differently:

$ touch AbcAbc DefAbc FoobazAbc

$ prename -n 's/Abc$//' *
Deprecated program in use: rename as shipped with the Debian perl package will
be removed after the release of stretch. Please install the separate 'rename'
package which will provide the same command.
AbcAbc renamed as Abc
DefAbc renamed as Def
FoobazAbc renamed as Foobaz

$ rename -n 's/Abc$//' *
rename(AbcAbc, Abc)
rename(DefAbc, Def)
rename(FoobazAbc, Foobaz)

While the difference is cosmetic, output of "prename" feels more readable.



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

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

Versions of packages rename depends on:
ii  perl  5.24.1~rc3-3

rename recommends no packages.

rename suggests no packages.

-- no debconf information

Bug#712415: reportbug: doesn't notice installed foreign-architecture packages

[Ben Finney]

Control: retitle -1 reportbug: doesn't notice installed foreign-architecture 
packages
Control: tags -1 + moreinfo
Control: severity -1 normal

On 15-Jun-2013, merlin wrote:
> Package: reportbug
> Version: 6.4.4
> Severity: important

I don't see a justification in the reported behaviour for a severity
higher than “normal”. I'm setting the metadata accordingly.

> When i want to write a reportbug for an packet it does not find the
> packet on my system Sid AMD64

Can you give a simple way to reproduce this? I am not able to install
i386 packages on an amd64 system; APT refuses to install the packages.

What is a simple recipe to follow, to see the behaviour you describe?

> for sample i want to report a bug on the packet libkrb5-3 it say
> that the packet is not on my system :

Please show the exact ‘reportbug’ command you run, and the exact error
output.

-- 
 \   “I believe in making the world safe for our children, but not |
  `\our children's children, because I don't think children should |
_o__) be having sex.” —Jack Handey |
Ben Finney 


signature.asc
Description: PGP signature

Bug#843219: reglookup-doc: Please don't depend on firefox-esr

[Giovani Ferreira]

On 05-11-2016 14:19, Tim wrote:
> I agree, it doesn't really make sense to depend on a specific browser.
> At most, "recommend" a generic browser virtual package, like
> www-browser, but even then I don't know that it is necessary

Actually, after the upload I noticed that it would be a problem, this 
was already on my to do list.

Fixing now!

cheers,

-- 
Giovani Ferreira
http://softwarelivre.org/jova2
0x78494EF72375A66C



signature.asc
Description: OpenPGP digital signature

Bug#842879: use uptime, not btime, else wrong start times on some systems

[積丹尼 Dan Jacobson]

Yup just like uptime, w.procps etc. don't bother with btime, you can't
lose! (At least on the handful of systems that I have encountered.)

Bug#564112: cloning 564112, reassign -1 to apt, retitle -1 to apt-cache can become very slow

[Ben Finney]

Control: tags -1 + moreinfo

On 07-Jan-2010, Ben Hutchings wrote:
> clone 564112 -1
> reassign -1 apt 0.7.25
> retitle 564112 Checking status of source packages with many binaries can be 
> slow
> retitle -1 apt-cache can become very slow

Is bug#564112 still relevant for ‘reportbug’, then? What needs to
change in ‘reportbug’ to resolve this bug?

Does the fact the later bug report, bug#564137, has long been
resolved as “fixed”, affect the status of this bug?

-- 
 \   “The surest way to corrupt a youth is to instruct him to hold |
  `\   in higher esteem those who think alike than those who think |
_o__) differently.” —Friedrich Nietzsche, _The Dawn_, 1881 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#819204: New release

[Michael Gerlach]

There is a new release fixing this bug..

https://github.com/iputils/iputils/releases/tag/s20161105

-- 
Please use PGP - https://en.wikipedia.org/wiki/Pretty_Good_Privacy



signature.asc
Description: Digital signature

Bug#843208: Reassigning to appropriate bug and updating metadata

[Diederik de Haas]

reassign 843208 qtdeclarative-opensource-src 5.7.1~20161021-4
affects 843208 plasma-workspace sddm
severity 843208 grave
forwarded 843208 https://bugreports.qt.io/browse/QTBUG-56932
thanks

Reassigning the bugs to the likely culprit and updating various metadata 
fields. For completeness sake I'll repost the message I sent to the debian-
k...@lists.debian.org ML regarding this issue:

> The current state is that it's highly likely that a bug in qtdeclarative-
> opensource-src (source package) version 5.7.1~20161021-4 is the cause for
> the
> issue various people are seeing.
> One of the Debian Qt maintainers filed the following bug for it:
> https://bugreports.qt.io/browse/QTBUG-56932
> 
> In Debian the following bugs have been reported which are likely all caused
> by this issue:
> https://bugs.debian.org/843250
> https://bugs.debian.org/843332
> 
> and probably more will follow ...
> 
> > I wonder if rebuilding some packages locally is easier than downgrading a
> > lot of packages? If yes, which ones?
> 
> No, that will not help you or anyone else, since the problem is in an
> (important) part of qt5 5.7.1 itself.
> As you (Andrey) already noticed and reported back, downgrading to the
> version
> in testing works and I think that it is the only solution for now.
> Aptitude's resolver should be able to help in downgrading all those
> packages.
> 
> HTH,
> 
>   Diederik

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

Bug#843341: lxde: installing lxde doesn't give me an LXDE session

[Andriy Grytsenko]

control: reassign -1 lxde-common

Thank you very much for reporting this. Apparently this issue is coming
from the fact there is no lxde-session package which is named lxde-common
and therefore many are confused because lxde package is just metapackage
with components but session files itself.

Bug#838347: ITP: jboss-jaxrs-2.0-api

[Emmanuel Bourg]

Control: tags -1 wontfix
Control: close -1

jboss-jaxrs-2.0-api duplicates the jaxrs-api package, Timo confirmed
Dogtag builds with the existing package and dogtag-pki has been
depending on it since the version 10.3.5-1.

So this new package can be safely rejected.

Emmanuel Bourg

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Uoti Urpala]

Note: this is written as an outsider who doesn't have any direct stake
in the issue.

On Sun, 6 Nov 2016 05:00:12 +1030 Ron  wrote:
> > And I think the latter is basically what the "just ship multiple
> versions and hope the future gets clearer" option boils down to.
> All it really does is take the pressure off of everyone but me
> to have any interest at all in actually trying to resolve the
> genuinely Hard part of this.  And it does that by making an even

I don't think the others have any obligation to try to resolve any
technical issues, and it is 100% reasonable of them to insist that
Debian just ship a new upstream version (as long as the packaging is
not otherwise unacceptably bad; but simply disabling any functionality
that is not secure or otherwise OK upstream is a valid answer).

Based on what I've seen in this thread, I think I can say you're
clearly in the wrong. And that does not require considering any of the
technical issues with the software. The software now shipped in Debian
as "global" is simply too outdated compared to upstream. That you have
technical objections to something in the newer versions could be a
reason for you to create a new fork. But you have not properly done
that, and abusing your Debian packager position to indefinitely hold
back the package is not an appropriate answer to any technical issues,
regardless of the validity of the technical objections.

To properly create a fork, you'd need to either pick a new name for
your fork, or contest whose version has the right to the name "GLOBAL".
You have obviously not chosen a new name. You don't seem to be claiming
to be the overall upstream maintainer of GLOBAL either, and claiming
that would be totally inappropriate if you're only shipping your
version in Debian. As such, you have no business shipping your version
under the "global" package name. Either ship the upstream version -
even if flawed and causing problems for some users - or use another
package name.

Bug#843208: Fwd: Bug#843332: /usr/bin/plasmashell: segmentation fault when attempting to start plasmashell after upgrade

[Diederik de Haas]

Forgot to CC bug 843208 and therefor it was missing the following information:

--  Forwarded Message  --

Subject: Bug#843332: /usr/bin/plasmashell: segmentation fault when attempting 
to start plasmashell after upgrade
Date: zondag 6 november 2016, 01:13:33 CET
From: Diederik de Haas 
To: 843...@bugs.debian.org

Control: merge -1 843208

On zondag 6 november 2016 08:09:33 CET Arthur Marsh wrote:
> Package: plasma-workspace
> Version: 4:5.8.2-1
> Severity: important
> ii  qml-module-qtquick2  5.7.1~20161021-4

I believe this is a more detailed version of https://bugs.debian.org/843208 
but really the same issue.
As I've detailed in https://lists.debian.org/debian-kde/2016/11/msg00011.html 
it looks like the problem is in qtdeclarative-
opensource-src (source package) version 5.7.1~20161021-X and there currently 
isn't a fix, thus waiting for rebuilding as described in 8243208 will not help.
You will need to downgrade all qt5 packages to the version in testing and 
aptitude is likely the best tool to accomplish that.
-

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

Bug#843342: plasma-workspace: plasmashell crashes after startup

[Diederik de Haas]

Control: severity -1 important
Control: merge -1 843208

On zondag 6 november 2016 11:07:19 CET Russell Coker wrote:
> Package: plasma-workspace
> Version: 4:5.8.2-1
> Severity: normal

You've run into the same problem as bug 843208 and 843332 and I've just send a 
reply to those bugs (when merging those) regarding the (likely) cause and the 
solution. 
TL;DR downgrade the qt5 packages to the version in testing

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

Bug#843332: /usr/bin/plasmashell: segmentation fault when attempting to start plasmashell after upgrade

[Diederik de Haas]

Control: merge -1 843208

On zondag 6 november 2016 08:09:33 CET Arthur Marsh wrote:
> Package: plasma-workspace
> Version: 4:5.8.2-1
> Severity: important
> ii  qml-module-qtquick2  5.7.1~20161021-4

I believe this is a more detailed version of https://bugs.debian.org/843208 
but really the same issue.
As I've detailed in https://lists.debian.org/debian-kde/2016/11/msg00011.html 
it looks like the problem is in qtdeclarative-
opensource-src (source package) version 5.7.1~20161021-X and there currently 
isn't a fix, thus waiting for rebuilding as described in 8243208 will not help.
You will need to downgrade all qt5 packages to the version in testing and 
aptitude is likely the best tool to accomplish that.

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

Bug#843157: zeromq3: please update to 4.2.0

[Luca Boccassi]

On Fri, 2016-11-04 at 12:48 +0100, László Böszörményi (GCS) wrote:
> Hi Luca,
> 
> On Fri, Nov 4, 2016 at 12:27 PM, Luca Boccassi  
> wrote:
> 
> > Thank you for your work!
>  This time the merit is yours. May you think that the architecture
> support (Hurd / kFreeBSD) will be merged by upstream somewhen?
> 
> Thanks for the heads-up,
> Laszlo/GCS

I've sent a PR for the kFreeBSD patch and it's been merged, so it can be
dropped after the next bugfix release.

The last ones, one disables a test so I can't merge it upstream, and the
other one sets 2 tests to XFAIL on Hurd. Any idea if it's due to
temporary failures or missing features from Hurd?

Kind regards,
Luca Boccassi

Bug#843342: plasma-workspace: plasmashell crashes after startup

[Russell Coker]

Package: plasma-workspace
Version: 4:5.8.2-1
Severity: normal

[ 1217.537000] plasmashell[9689]: segfault at 8 ip 7feaa766df37 sp 
7fff0864a440 error 4 in libQt5Core.so.5.7.1[7feaa73b+4cd000]

After upgrading a couple of systems to the latest Unstable I am seeing
plasmashell crash after startup.  Above is the log from one system and below is
the log from another.

[   83.970915] plasmashell[1996]: segfault at 8 ip 7f5565837f37 sp 
7ffed91e4950 error 4 in libQt5Core.so.5.7.1[7f556557a000+4cd000]

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

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

Versions of packages plasma-workspace depends on:
ii  dbus-x11 1.10.12-1
ii  frameworkintegration 5.27.0-1
ii  gdb  7.11.1-2
ii  iso-codes3.70-1
ii  kactivitymanagerd5.8.2-1
ii  kde-cli-tools4:5.8.2-1
ii  kded55.27.0-1
ii  kinit5.27.0-1
ii  kio  5.27.0-2
ii  kpackagetool55.27.0-1
ii  libc62.24-5
ii  libcln6  1.3.4-2
ii  libdbusmenu-qt5-20.9.3+16.04.20160218-1
ii  libgcc1  1:6.2.0-11
ii  libgps22 3.16-4
ii  libice6  2:1.0.9-1+b1
ii  libkf5activities55.27.0-1
ii  libkf5auth5  5.27.0-1
ii  libkf5baloo5 5.27.0-1
ii  libkf5bookmarks5 5.27.0-1
ii  libkf5calendarevents55.27.0-1+b1
ii  libkf5completion55.27.0-1
ii  libkf5configcore55.27.0-1
ii  libkf5configgui5 5.27.0-1
ii  libkf5configwidgets5 5.27.0-1
ii  libkf5coreaddons55.27.0-1
ii  libkf5crash5 5.27.0-1
ii  libkf5dbusaddons55.27.0-1
ii  libkf5declarative5   5.27.0-1+b1
ii  libkf5globalaccel-bin5.27.0-1
ii  libkf5globalaccel5   5.27.0-1
ii  libkf5guiaddons5 5.27.0-1
ii  libkf5holidays5  16.04.2-1
ii  libkf5i18n5  5.27.0-2
ii  libkf5iconthemes55.27.0-1
ii  libkf5idletime5  5.27.0-1
ii  libkf5itemviews5 5.27.0-1
ii  libkf5jobwidgets55.27.0-1
ii  libkf5js55.27.0-1
ii  libkf5jsembed5   5.27.0-1
ii  libkf5kdelibs4support5   5.27.0-1
ii  libkf5kiocore5   5.27.0-2
ii  libkf5kiofilewidgets55.27.0-2
ii  libkf5kiowidgets55.27.0-2
ii  libkf5networkmanagerqt6  5.27.0-1
ii  libkf5newstuff5  5.27.0-1
ii  libkf5notifications5 5.27.0-1
ii  libkf5notifyconfig5  5.27.0-1
ii  libkf5package5   5.27.0-1
ii  libkf5plasma55.27.0-1
ii  libkf5plasmaquick5   5.27.0-1
ii  libkf5quickaddons5   5.27.0-1+b1
ii  libkf5runner55.27.0-1
ii  libkf5service-bin5.27.0-1
ii  libkf5service5   5.27.0-1
ii  libkf5solid5 5.27.0-1
ii  libkf5texteditor55.27.0-1
ii  libkf5textwidgets5   5.27.0-1
ii  libkf5wallet-bin 5.27.0-1
ii  libkf5wallet55.27.0-1
ii  libkf5waylandclient5 4:5.27.0-1
ii  libkf5widgetsaddons5 5.27.0-1
ii  libkf5windowsystem5  5.27.0-1
ii  libkf5xmlgui55.27.0-1
ii  libkf5xmlrpcclient5  5.27.0-1
ii  libkscreenlocker55.8.2-1
ii  libksgrd74:5.8.2-1
ii  libkworkspace5-5 4:5.8.2-1
ii  libphonon4qt5-4  4:4.9.0-4
ii  libplasma-geolocation-interface5 4:5.8.2-1
ii  libprocesscore7  4:5.8.2-1
ii  libprocessui74:5.8.2-1
ii  libqalculate5v5  0.9.7-9.1+b1
ii  libqt5core5a 5.7.1~20161021+dfsg-5
ii  libqt5dbus5  

Bug#843341: lxde: installing lxde doesn't give me an LXDE session

[Mike Kupfer]

Package: lxde
Version: 7
Severity: normal

Dear Maintainer,

Using Synaptic in an XFCE session, I installed the "lxde" package.
After logging out, I expected to be able to select the LXDE session in
the lightdm controls, but LXDE was not listed.  I had to install
lxde-common as well to get an LXDE session.  Also, when installing
lxde-common, I noticed that it, not lxde, pulled in openbox.

I guess lxde-common was not pulled in because I already had a package
installed that provides x-session-manager.  I think that for most
users, this does not provide the right behavior.  And the current
behavior doesn't align with the documentation in
https://wiki.debian.org/LXDE.



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

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

Versions of packages lxde depends on:
ii  galculator 2.1.4-1
ii  gpicview   0.2.5-2
ii  leafpad0.8.18.1-5
ii  lxappearance   0.6.2-1
ii  lxappearance-obconf0.2.3-1
ii  lxde-common [x-session-manager]0.99.1-1
ii  lxde-core  7
ii  lxde-icon-theme0.5.1-1
ii  lxinput0.3.5-1
ii  lxrandr0.3.1-1
ii  lxsession [x-session-manager]  0.5.1-2
pn  lxsession-edit 
ii  lxterminal 0.2.0-1
ii  openbox [x-session-manager]3.6.1-3
ii  xarchiver  1:0.5.4-5
ii  xfce4-session [x-session-manager]  4.12.1-4

Versions of packages lxde recommends:
pn  alsamixergui 
pn  clipit   
pn  deluge | transmission-gtk
pn  evince-gtk | pdf-viewer  
pn  gnome-disk-utility   
pn  gnome-mplayer
pn  gnome-system-tools   
ii  gucharmap1:9.0.1-1
ii  i3-wm [x-window-manager] 4.12-2
ii  lightdm [x-display-manager]  1.18.2-2
pn  lxmusic | audacious  
ii  lxsession [lxpolkit] 0.5.1-2
pn  menu-xdg 
ii  network-manager-gnome1.4.2-1
ii  openbox [x-window-manager]   3.6.1-3
pn  usermode 
ii  w3m [www-browser]0.5.3-31
ii  xfwm4 [x-window-manager] 4.12.3-3
ii  xserver-xorg 1:7.7+16

Versions of packages lxde suggests:
pn  gimp
ii  gnome-packagekit [update-notifier]  3.20.0-1
pn  libreoffice 
pn  lxlauncher  
pn  lxtask  
pn  pidgin  
ii  xfce4-power-manager 1.4.4-4

-- no debconf information

Bug#841760: firejail: Network namespace disconnect

[Aidan Gauland]

On 05/11/16 23:10, Reiner Herrmann wrote:
> Okay, so the problem seems to be that some time after boot your
> resolv.conf is overwritten by rdnssd with only an IPv6 nameserver
> (which is not reachable in the sandbox, because of the device).
> 
> I would guess that directly after boot you still have an IPv4
> nameserver configured by your DHCP client. But shortly after, rdnssd
> auto-discovers an IPv6 nameserver and rewrites the file (did perhaps
> something on your router change, so that it know also provides DNS over
> IPv6?).

I think I know why this started happening suddenly: I used to have very
restrictive iptables rules set up (on this host, not the router) that
would have been blocking rdnssd.  The removal of netfilter-persistent
only coincided with unblocking rdnssd.

(For the record, I have attached /etc/resolv.conf *before* it is
overwritten by rdnssd.)

> If you are certain that you don't want to use auto-discovered IPv6
> nameservers you could remove rdnssd.
> Or it could also help to install the resolvconf package. rdnssd calls a
> script (/etc/rdnssd/merge-hook) when it finds IPv6 nameservers, and this
> hook either overwrites the resolv.conf file, or lets resolvconf handle
> it properly when it is installed.
> 
> You can also try firejail's --dns option to set fixed nameservers
> inside the sandbox.

So it seems I have a few options for solving the issue of DNS being
misconfigured within firejails, and which one I use depends upon how I
want to configure my LAN, which is beyond the scope of this "bug", so I
will end my investigation here.

Would this be worth forwarding to upstream to be recorded as a known
problem? 

Thank you very much for your assistance in troubleshooting this problem.
Best regards,
Aidan Gauland
domain lan
search lan
nameserver 192.168.1.1


signature.asc
Description: OpenPGP digital signature

Bug#843340: ITP: budgie-indicator-applet -- appindicator applet for the budgie-desktop

[foss.freedom]

Package: wnpp
Severity: wishlist

Owner: David Mohammed 

Package name: budgie-indicator-applet
Version: 0.1
Upstream Author : David Mohammed 
URL: https://github.com/budgie-remix/budgie-indicator-applet
License: GPL 3+
Programming Lang: C
Description: Application Indicator Applet for the budgie-desktop
 Package that installs an application indicator applet for the
 budgie-desktop. The applet is intended to be used instead of the
 X11 system tray.  It displays application icons corresponding to
 applications that support the AppIndicator API

Bug#843334: transition: czmq

[Luca Boccassi]

On Sat, 5 Nov 2016 22:43:46 + Luca Boccassi  wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> czmq 4.0.0 was released yesterday, and it breaks ABI, which was bumped
> from 3 to 4.
> 
> https://packages.qa.debian.org/c/czmq.html
> 
> Reverse dependencies source packages:
> 
> rsyslog
> 
> The reverse dependency rebuild cleanly without any patches. binNMU
> rebuilds should be all that's needed.
> 
> libczmq4 is in experimental and it has rebuilt most architectures,
> with the mips and armv7 queued. I built locally in qemu and it was all
> fine so I do not expect trouble.
> 
> I know it's a bit late, but given it's a very simple case I hope it
> can be authorized, to avoid having to maintain an old version for many
> years! Upstream will not release bug fixes for 3.0.x anymore.
> 
> Thank you!
> 
> Kind regards,
> Luca Boccassi

Transition tracker item has been autogenerated now, here's the link:

https://release.debian.org/transitions/html/auto-czmq.html

Kind regards,
Luca Boccassi

Bug#842879: use uptime, not btime, else wrong start times on some systems

[Craig Small]

On Sun, 6 Nov 2016, 10:18 AM 積丹尼 Dan Jacobson  wrote:

> Craig, it turns out ps is using the wrong file in the first place!
> If it used /proc/uptime it would surely never have this problem on any
> system


Thats a big call to say it won't have a problem on any system. The problem
is lots of systems do dumb things to timers. So to change something like
that it will need to be tested a lot first.

Things that suspend come to mind and systems that use stolen time are
another.
Ill try to find where btime was used and why. there may be a good reason
for it.

Thanks for looking into it more.

 - Craig

Bug#843332: /usr/bin/plasmashell: Re: /usr/bin/plasmashell: segmentation fault when attempting to start plasmashell after upgrade

[Arthur Marsh]

Package: plasma-workspace
Version: 4:5.8.2-1
Followup-For: Bug #843332

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

After doing the following downgrades, I was able to get plasmashell working:

[INSTALL, DEPENDENCIES] libdouble-conversion1:amd64 2.0.1-4
[DOWNGRADE] akonadi-backend-sqlite:amd64 4:16.04.3-3+b1 -> 4:16.04.3-2
[DOWNGRADE] akonadi-server:amd64 4:16.04.3-3+b1 -> 4:16.04.3-2
[DOWNGRADE] kpackagelauncherqml:amd64 5.27.0-1+b1 -> 5.27.0-1
[DOWNGRADE] kwin-common:amd64 4:5.8.2-1+b1 -> 4:5.8.2-1
[DOWNGRADE] kwin-x11:amd64 4:5.8.2-1+b1 -> 4:5.8.2-1
[DOWNGRADE] libkf5akonadiagentbase5:amd64 4:16.04.3-3+b1 -> 4:16.04.3-2
[DOWNGRADE] libkf5akonadicore-bin:amd64 4:16.04.3-3+b1 -> 4:16.04.3-2
[DOWNGRADE] libkf5akonadicore5:amd64 4:16.04.3-3+b1 -> 4:16.04.3-2
[DOWNGRADE] libkf5akonadiprivate5:amd64 4:16.04.3-3+b1 -> 4:16.04.3-2
[DOWNGRADE] libkf5akonadiwidgets5:amd64 4:16.04.3-3+b1 -> 4:16.04.3-2
[DOWNGRADE] libkf5calendarevents5:amd64 5.27.0-1+b1 -> 5.27.0-1
[DOWNGRADE] libkf5declarative5:amd64 5.27.0-1+b1 -> 5.27.0-1
[DOWNGRADE] libkf5quickaddons5:amd64 5.27.0-1+b1 -> 5.27.0-1
[DOWNGRADE] libkwin4-effect-builtins1:amd64 4:5.8.2-1+b1 -> 4:5.8.2-1
[DOWNGRADE] libkwineffects9:amd64 4:5.8.2-1+b1 -> 4:5.8.2-1
[DOWNGRADE] libkwinglutils9:amd64 4:5.8.2-1+b1 -> 4:5.8.2-1
[DOWNGRADE] libkwinxrenderutils9:amd64 4:5.8.2-1+b1 -> 4:5.8.2-1
[DOWNGRADE] libpoppler-qt5-1:amd64 0.48.0-2 -> 0.44.0-3
[DOWNGRADE] libqgsttools-p1:amd64 5.7.1~20161021-2 -> 5.6.1-2
[DOWNGRADE] libqt5clucene5:amd64 5.7.1~20161021-2 -> 5.6.1-4
[DOWNGRADE] libqt5concurrent5:amd64 5.7.1~20161021+dfsg-5 -> 5.6.1+dfsg-3+b1
[DOWNGRADE] libqt5core5a:amd64 5.7.1~20161021+dfsg-5 -> 5.6.1+dfsg-3+b1
[DOWNGRADE] libqt5dbus5:amd64 5.7.1~20161021+dfsg-5 -> 5.6.1+dfsg-3+b1
[DOWNGRADE] libqt5designer5:amd64 5.7.1~20161021-2 -> 5.6.1-4
[DOWNGRADE] libqt5designercomponents5:amd64 5.7.1~20161021-2 -> 5.6.1-4
[DOWNGRADE] libqt5gui5:amd64 5.7.1~20161021+dfsg-5 -> 5.6.1+dfsg-3+b1
[DOWNGRADE] libqt5help5:amd64 5.7.1~20161021-2 -> 5.6.1-4
[DOWNGRADE] libqt5multimedia5:amd64 5.7.1~20161021-2 -> 5.6.1-2
[DOWNGRADE] libqt5multimedia5-plugins:amd64 5.7.1~20161021-2 -> 5.6.1-2
[DOWNGRADE] libqt5multimediaquick-p5:amd64 5.7.1~20161021-2 -> 5.6.1-2
[DOWNGRADE] libqt5multimediawidgets5:amd64 5.7.1~20161021-2 -> 5.6.1-2
[DOWNGRADE] libqt5network5:amd64 5.7.1~20161021+dfsg-5 -> 5.6.1+dfsg-3+b1
[DOWNGRADE] libqt5opengl5:amd64 5.7.1~20161021+dfsg-5 -> 5.6.1+dfsg-3+b1
[DOWNGRADE] libqt5opengl5-dev:amd64 5.7.1~20161021+dfsg-5 -> 5.6.1+dfsg-3+b1
[DOWNGRADE] libqt5printsupport5:amd64 5.7.1~20161021+dfsg-5 -> 5.6.1+dfsg-3+b1
[DOWNGRADE] libqt5qml5:amd64 5.7.1~20161021-4 -> 5.6.1-11
[DOWNGRADE] libqt5quick5:amd64 5.7.1~20161021-4 -> 5.6.1-11
[DOWNGRADE] libqt5quickwidgets5:amd64 5.7.1~20161021-4 -> 5.6.1-11
[DOWNGRADE] libqt5script5:amd64 5.7.1~20161021+dfsg-2 -> 5.6.1+dfsg-2
[DOWNGRADE] libqt5scripttools5:amd64 5.7.1~20161021+dfsg-2 -> 5.6.1+dfsg-2
[DOWNGRADE] libqt5sql5:amd64 5.7.1~20161021+dfsg-5 -> 5.6.1+dfsg-3+b1
[DOWNGRADE] libqt5sql5-mysql:amd64 5.7.1~20161021+dfsg-5 -> 5.6.1+dfsg-3+b1
[DOWNGRADE] libqt5sql5-psql:amd64 5.7.1~20161021+dfsg-5 -> 5.6.1+dfsg-3+b1
[DOWNGRADE] libqt5sql5-sqlite:amd64 5.7.1~20161021+dfsg-5 -> 5.6.1+dfsg-3+b1
[DOWNGRADE] libqt5svg5:amd64 5.7.1~20161021-2 -> 5.6.1-2
[DOWNGRADE] libqt5test5:amd64 5.7.1~20161021+dfsg-5 -> 5.6.1+dfsg-3+b1
[DOWNGRADE] libqt5webkit5:amd64 5.7.1~20161021+dfsg-2 -> 5.6.1+dfsg-5
[DOWNGRADE] libqt5widgets5:amd64 5.7.1~20161021+dfsg-5 -> 5.6.1+dfsg-3+b1
[DOWNGRADE] libqt5x11extras5:amd64 5.7.1~20161021-2 -> 5.6.1-2
[DOWNGRADE] libqt5x11extras5-dev:amd64 5.7.1~20161021-2 -> 5.6.1-2
[DOWNGRADE] libqt5xdg2:amd64 2.0.0-5 -> 2.0.0-4
[DOWNGRADE] libqt5xdgiconloader2:amd64 2.0.0-5 -> 2.0.0-4
[DOWNGRADE] libqt5xml5:amd64 5.7.1~20161021+dfsg-5 -> 5.6.1+dfsg-3+b1
[DOWNGRADE] libqt5xmlpatterns5:amd64 5.7.1~20161021-3 -> 5.6.1-2
[DOWNGRADE] libvlc-bin:amd64 2.2.4-8 -> 2.2.4-7
[DOWNGRADE] libvlc5:amd64 2.2.4-8 -> 2.2.4-7
[DOWNGRADE] libvlccore8:amd64 2.2.4-8 -> 2.2.4-7
[DOWNGRADE] musescore:amd64 2.0.3+dfsg1-2+b1 -> 2.0.3+dfsg1-2
[DOWNGRADE] pinentry-qt:amd64 0.9.7-7 -> 0.9.7-6
[DOWNGRADE] qdbus-qt5:amd64 5.7.1~20161021-2 -> 5.6.1-4
[DOWNGRADE] qlipper:amd64 1:5.0.0-1 -> 5.0.0-1~40-g48754f2-1
[DOWNGRADE] qml-module-org-kde-draganddrop:amd64 5.27.0-1+b1 -> 5.27.0-1
[DOWNGRADE] qml-module-org-kde-kcoreaddons:amd64 5.27.0-1+b1 -> 5.27.0-1
[DOWNGRADE] qml-module-org-kde-kio:amd64 5.27.0-1+b1 -> 5.27.0-1
[DOWNGRADE] qml-module-org-kde-kquickcontrols:amd64 5.27.0-1+b1 -> 5.27.0-1
[DOWNGRADE] qml-module-org-kde-kquickcontrolsaddons:amd64 5.27.0-1+b1 -> 
5.27.0-1
[DOWNGRADE] qml-module-org-kde-kwindowsystem:amd64 5.27.0-1+b1 -> 5.27.0-1
[DOWNGRADE] qml-module-qt-labs-folderlistmodel:amd64 5.7.1~20161021-4 -> 
5.6.1-11
[DOWNGRADE] qml-module-qt-labs-settings:amd64 5.7.1~20161021-4 -> 

Bug#843330: Usage of OpenDMARC 1.3.2 beta0

[Jason Rhinelander]

On 05/11/16 06:53 PM, pkt...@users.sf.net wrote:

Hi,

I just saw your comment to ticket #185.
If you trying to use OpenDMARC 1.3.2 beta0 you will run into more
problems than just ticket 185. See my page at
http://batleth.sapienti-sat.org/projects/opendmarc/ for a collection of
patches this beta release.

If you are using MySQL 5.7 you will also experience problems with strict
mode - I have a patch pending.



Thanks for the comment and link.  I'm using the opendmarc package from 
Debian "testing", where this beta0 version landed in the last day or so. 
 The debian package has a few, but certainly not all of those patches 
applied.


I'm CC'ing this to the Debian bug report I submitted regarding including 
185 as some of these other patches would similarly be useful for the 
package in Debian.



Jason Rhinelander

Bug#842879: use uptime, not btime, else wrong start times on some systems

[積丹尼 Dan Jacobson]

severity 842879 normal
retitle 842879 use uptime, not btime, else wrong start times on some systems
thanks
Craig, it turns out ps is using the wrong file in the first place!
If it used /proc/uptime it would surely never have this problem on any system.

$ perl /tmp/misTime|head
(init):
b Tue Aug  9 06:05:54 2016
u Sun Oct 16 22:34:14 2016
(pickup):
b Mon Aug 29 12:39:39 2016
u Sun Nov  6 05:08:00 2016
(apache2-ps11007):
b Sun Aug 28 23:13:39 2016
u Sat Nov  5 15:42:00 2016

$ uptime
 07:15:40 up 20 days,  8:41,  1 user,  load average: 0.00, 0.00, 0.00
$ cat /tmp/misTime

#!/usr/bin/perl
# Author  : Dan Jacobson -- http://jidanni.org/
# Created On  : Sat Nov  5 18:11:17 2016
# Last Modified On: Sun Nov  6 05:52:38 2016
# Update Count: 71
# Reproduce wrong time effect
use strict;
use warnings FATAL => q(all);
open( my $fh, "<", "/proc/stat" ) or die;
my $btime;
while (<$fh>) {
if (/^btime/) { /\d+/; $btime = $&; last; }
}
close $fh;
open( my $fh1, "<", "/proc/uptime" ) or die;
my $uptime;
while (<$fh1>) {
/[\d.]+/ || die;
$uptime = $&;
}
close $fh1;
@ARGV = glob "/proc/[0-9]*/stat";
while (<>) {
my @F = split;
printf "%s:\n\tb %s\n\tu %s\n", $F[1],
  scalar localtime( $F[21] / 100 + $btime ),
  scalar localtime( $F[21] / 100 + time - $uptime );
}

#I'll also tell the  libproc-processtable-perl guys.

Bug#835380: This bug can probably be closed

[Ron Murray]

Since some of the efi-related packages have been updated in the last few
weeks, it seems that this bug is no longer present. I can perform a
grub-install with no error messages, and can boot Windows again (woohoo).

This bug can probably be closed, although you might want to check that
the return value from efibootmgr is tested, as I noted in the original
bug report.

 .Ron

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E  7B63 12F7 E865 B5E2 E761




signature.asc
Description: OpenPGP digital signature

Bug#842796: libc recently more aggressive about pthread locks in stable ?

[Aurelien Jarno]

On 2016-11-05 19:13, Ian Jackson wrote:
> I have just been debugging a ghostscript segfault on jessie amd64.
> 
> Looking at the code, I think that gs in jessie is plainly violating
> the rules about the use of pthread locks.  On my partner's machine,
> this makes it segfault on termination (with some input files, at
> least).  On my machine it works just fine.  The code in sid is better.
> 
> I recently encountered what seems to be a similar bug in ogg123 in
> stable.  #842796.
> 
> Has something changed in jessie's libc recently ?  I find it difficult
> to imagine that these bugs would have been missed earlier during the
> life of jessie.

I think you just got a new machine with a CPU supporting the TSX
instructions, which are more picky about following the pthreads
semantics.

Unfortunately given Intel fuck-up on TSX implementation in Haswell and
some Broadwell CPUs, they had to disable TSX instructions though firmware
updates, which in turns means we haven't got all packages in Jessie
tested by a wide set of people.

Aurelien

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

Bug#843338: gnome-shell: Launching the autostart files are delayed for about one minute when booting with kernel 4.8.0

[Sergio Costas]

Package: gnome-shell
Version: 3.22.1-1
Severity: important

Dear Maintainer,

After updating my Debian SID system to kernel 4.8.0, mysteriously gnome shell
delayed for a little more than one minute the launch of the autostart programs
and some extensions. Sometimes the right menu doesn't work until that minute
passes and everything gets loaded.

Applications work fine, except that Plank, Solaar (they are two programs that I
have to be launched on desktop startup) and Nautilus with the desktop icons
weren't launched until about one minute. Returning to kernel 4.7.0 made
everything boot fine again, launching everything instantaneously. Booting again
with 4.8.0 triggers again that big delay.

Checked the .config/autostart folder and found two .desktop files that pointed
to non-existent binaries, but removing them didn't fixed the problem.

The bug happens only after booting the computer. Closing the session and
opening again doesn't trigger it. Also tried to disable the autologin, but the
bug also happens in this case.



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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  evolution-data-server3.22.1-2
ii  gir1.2-accountsservice-1.0   0.6.40-3
ii  gir1.2-atspi-2.0 2.22.0-3
ii  gir1.2-caribou-1.0   0.4.21-1
ii  gir1.2-freedesktop   1.50.0-1
ii  gir1.2-gcr-3 3.20.0-3
ii  gir1.2-gdesktopenums-3.0 3.22.0-1
ii  gir1.2-gdm-1.0   3.22.1-1
ii  gir1.2-glib-2.0  1.50.0-1
ii  gir1.2-gnomebluetooth-1.03.20.0-1
ii  gir1.2-gnomedesktop-3.0  3.22.1-1
ii  gir1.2-gtk-3.0   3.22.2-1
ii  gir1.2-gweather-3.0  3.20.3-1
ii  gir1.2-ibus-1.0  1.5.14-1
ii  gir1.2-mutter-3.03.22.1-2
ii  gir1.2-networkmanager-1.01.4.2-2
ii  gir1.2-nmgtk-1.0 1.4.2-1
ii  gir1.2-pango-1.0 1.40.3-3
ii  gir1.2-polkit-1.00.105-17
ii  gir1.2-soup-2.4  2.56.0-1
ii  gir1.2-telepathyglib-0.120.24.1-1.1
ii  gir1.2-telepathylogger-0.2   0.8.2-1
ii  gir1.2-upowerglib-1.00.99.4-4
ii  gjs  1.46.0-1+b1
ii  gnome-backgrounds3.22.1-1
ii  gnome-settings-daemon3.22.1-1
ii  gnome-shell-common   3.22.1-1
ii  gsettings-desktop-schemas3.22.0-1
ii  libatk-bridge2.0-0   2.22.0-1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-5
ii  libcairo21.14.6-1.1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libcroco30.6.11-2
ii  libdbus-glib-1-2 0.108-1
ii  libecal-1.2-19   3.22.1-2
ii  libedataserver-1.2-223.22.1-2
ii  libgcr-base-3-1  3.20.0-3
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libgirepository-1.0-11.50.0-1
ii  libgjs0e [libgjs0-libmozjs-24-0] 1.46.0-1+b1
ii  libglib2.0-0 2.50.1-1
ii  libglib2.0-bin   2.50.1-1
ii  libgstreamer1.0-01.10.0-1
ii  libgtk-3-0   3.22.2-1
ii  libical2 2.0.0-0.5+b1
ii  libicu57 57.1-4
ii  libjson-glib-1.0-0   1.2.2-1
ii  libmozjs-24-024.2.0-3.1
ii  libmutter0i  3.22.1-2
ii  libnm-glib4  1.4.2-2
ii  libnm-util2  1.4.2-2
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpolkit-agent-1-0  0.105-17
ii  libpolkit-gobject-1-00.105-17
ii  libpulse-mainloop-glib0  9.0-5
ii  libpulse09.0-5
ii  libsecret-1-00.18.5-2
ii  libstartup-notification0  

Bug#841853: inkscape: Mouse cursor is a white outline on PowerPC

[Steven Gawroriski]

Taking a look at this myself. The issue is related to cursors and is
either an issue in:

 * Inkscape
 * GDK
 * XRender

Since the star cursor in Inkscape shows the color to be drawn,
including alpha. Using the color `FFDD8833` (which is kind of a tan
color) appears on the star cursor itself as a sky blue. The actual
color being shown on the cursor is `#3388DD` (or ARGB #FF3388DD).
Changing in Inkscape the `FF` (which should be red, but is alpha) makes
the blue in the cursor a bit transparent.

I am definitely certain that the issue is in Inkscape only. Other
programs such as GIMP and anything else do not have any cursor issues
at all from what I can tell. If GDK or XRender were at fault, likely
more than just a single program would be broken.

The only place in the Inkscape code which loads cursors is
`sp_cursor_pixbuf_from_xpm`. The `RGBA` struct has a static cast to a
`guint32` which bitshifts in values accordingly. However part of the
function `sp_cursor_pixbuf_from_xpm` contains the following:

guint32 *pixmap_buffer = new guint32[width * height];

However, before returning this buffer is `reinterpret_cast`ed such as
the following:

return
gdk_pixbuf_new_from_data(reinterpret_cast(pixmap_buffer),
GDK_COLORSPACE_RGB, TRUE, 8, width, height, width *
sizeof(guint32), free_cursor_data, NULL);

Looking at the documentation for `gdk_pixbuf_new_from_data`, the data
for this call is just specified as _Image data in 8-bit/sample packed
format_.

I wrote the attached patch which essentially byte swaps the value
before this function returns. The cursors are drawn correctly and
Inkscape can now be used much more easily. If a contributor agreement
is required then I would accept giving away my copyright for the code
contained in this patch.

Description: Swap before return sp_cursor_pixbuf_from_xpm on big endian.
 This byte swaps before the return in sp_cursor_pixbuf_from_xpm on big
 endian systems so that the cursor is made visible on these systems.
Author: Steven Gawroriski 

---

Origin: other
Bug-Debian: https://bugs.debian.org/841853

--- inkscape-0.91.orig/src/sp-cursor.cpp
+++ inkscape-0.91/src/sp-cursor.cpp
@@ -106,6 +106,14 @@ GdkPixbuf *sp_cursor_pixbuf_from_xpm(gch
 pixmap_buffer[y * width + x] = (it == colorMap.end()) ? 0u : it->second;
 }
 }
+
+#if G_BYTE_ORDER == G_BIG_ENDIAN
+for (int i = 0, n = width * height; i < n; i++)
+{
+guint32 v = pixmap_buffer[i];
+pixmap_buffer[i] = ((v & 0xFF) << 24) | (((v >> 8) & 0xFF) << 16) | (((v >> 16) & 0xFF) << 8) | ((v >> 24) & 0xFF);
+}
+#endif
 
 return gdk_pixbuf_new_from_data(reinterpret_cast(pixmap_buffer), GDK_COLORSPACE_RGB, TRUE, 8, width, height, width * sizeof(guint32), free_cursor_data, NULL);
 }

Bug#843337: reportbug: test suite fails when ‘mh’ command not available

[Ben Finney]

Package: reportbug
Version: 6.6.6
Severity: minor

I have installed all build dependencies (“Build-Depends” and
“Build-Depends-Indep”) for ‘reportbug’, so the test suite should pass.

Instead, the test suite fails in the absence of the ‘mh’ command,
which is not brought in by any dependency:

=
test_mua_exists (test.test_utils.TestMua) ... FAIL

==
FAIL: test_mua_exists (test.test_utils.TestMua)
--
Traceback (most recent call last):
  File "/home/bignose/Projects/debian/reportbug/devel/test/test_utils.py", line 
377, in test_mua_exists
self.fail("%s MUA program not available" % mua)
AssertionError: mh MUA program not available

--
=

One of these two resolutions is needed:

* If the ‘mh’ command is a strict dependency of the code base, then
  the build dependencies should be corrected to ensure that command is
  installed.

* If the ‘mh’ command is not a strict dependency of the code base,
  then the test suite should not fail when that command is absent.


-- Package-specific info:
** Environment settings:
EDITOR="emacsclient --alternate-editor=''"
PAGER="less"
VISUAL="emacsclient --alternate-editor=''"
DEBEMAIL="bign...@debian.org"
EMAIL="b...@benfinney.id.au"
DEBFULLNAME="Ben Finney"
INTERFACE="urwid"

** /home/bignose/.reportbugrc:
reportbug_version "6.4.4"
mode advanced
ui urwid
editor "ecw"
mua "mutt"
no-cc

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

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

Versions of packages reportbug depends on:
ii  apt   1.3.1
ii  python-reportbug  6.6.6
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail
ii  debconf-utils 1.5.59
ii  debsums   2.1.2
ii  dlocate   1.07
ii  emacs24-bin-common24.5+1-7
ii  file  1:5.29-1
ii  gnupg 2.1.15-4
ii  msmtp-mta [mail-transport-agent]  1.6.5-1
ii  python-gtk2   2.24.0-5.1
pn  python-gtkspellcheck  
ii  python-urwid  1.3.1-2+b1
pn  python-vte
ii  xdg-utils 1.1.1-1

Versions of packages python-reportbug depends on:
ii  apt   1.3.1
ii  file  1:5.29-1
ii  python-debian 0.1.29
ii  python-debianbts  2.6.1
pn  python:any

python-reportbug suggests no packages.

-- no debconf information

-- 
 \“If you go parachuting, and your parachute doesn't open, and |
  `\you friends are all watching you fall, I think a funny gag |
_o__) would be to pretend you were swimming.” —Jack Handey |
Ben Finney 


signature.asc
Description: PGP signature

Bug#843336: man pages have .pm appended in SEE ALSO

[積丹尼 Dan Jacobson]

X-Debbugs-Cc: dur...@frii.com
Package: libproc-processtable-perl
Version: 0.53-1+b2
Severity: minor

Please remove the ".pm" in the SEE ALSO in the man pages. (Else emacs
man mode can't recognize them.)

Bug#843173: libfaad-dev: Implicit SBR detection via AudioSpecificConfig fails when char is signed

[Stefan Pöschel]

Hi Fabian,

Am 05.11.2016 um 20:34 schrieb Fabian Greffrath:
> Did you mean to write "fails when char is unsigned" in the subject
> line?

This was indeed a typo - sorry!

> Am Freitag, den 04.11.2016, 16:18 +0100 schrieb Stefan Pöschel:
>> One way to fix this is to make the struct variable sbr_present_flag
>> signed.
>> Another way is to enforce signed char by compiling FAAD2 with
>> -fsigned-char.
>
> I see that the fix is rather trivial, but wouldn't it introduce an ABI
> (not API) break?

To be honest: I have no knowledge in terms of ABI and which changes
affect it. But I have a strong feeling that both of my proposals break
it :-/

Am 05.11.2016 um 21:13 schrieb Fabian Greffrath:
> will it help if we explicitely cast the (-1) to char in the two
> occasions where it is used for sbr_present_flag?

This seems to be an elegant way to me.

The first occasion also works without the cast as far as I can see. Or
do you think adding the cast there as well helps to clarify the issue?
The second cast should IMO be annoted with a respective comment, to
describe the issue.

BTW:
This problem of comparing to -1 also affects the API user:
The mentioned internal function AudioSpecificConfigFromBitfile is
exposed to the public API by the function NeAACDecAudioSpecificConfig
(not mentioned in the documentation but in the include header).
Furthermore the mentioned field sbr_present_flag of the
mp4AudioSpecificConfig struct could return the problematic value -1 to
the user (in case the _presence_ of SBR is not signalled; SBR itself may
nonetheless be present or not). So the user has to compare to "(char)
-1" as well for a proper result on all systems.

This behaviour is left unchanged by your proposed fix and IMO should be
left unchanged to not break the API (though the comparison the user has
to make of course remains to be more elaborated).

Regards,
Stefan

P.S.
An interesting blog post about the three possible types of "char":
http://blog.cdleary.com/2012/11/arm-chars-are-unsigned-by-default/

Bug#843335: ibus: I can't input any Japanese characters by some applications

[Tomoo Nomura]

Package: ibus
Version: 1.5.14-1
Severity: normal

Dear Maintainer,

After apt-get upgrade, I can't input any Japanese characters by iseweasel, 
icedove, gimp and gnucash, while I can do it by Gnome-terminal and Libreoffice.
I try to install the latest Firefox(50.0) and Thunderbird(50.0b3) by hand, both 
work good.
I use Anthy and Mozc, both behave samely.

environments:
tom-lin@nomura: env | grep ibus
CLUTTER_IM_MODULE=ibus
QT_IM_MODULE=ibus
XMODIFIERS=@im=ibus
GTK_IM_MODULE=ibus



-- Package-specific info:
default-display-manager: /usr/sbin/gdm3
ibus is /usr/bin/ibus
ibus-setup is /usr/bin/ibus-setup
im-config -l =>  ibus xim
im-config -m => default missing ibus ibus
XMODIFIERS=@im=ibus
GTK_IM_MODULE=ibus
QT4_IM_MODULE=xim
QT_IM_MODULE=ibus
XDG_DATA_DIRS=/usr/share/gnome:/usr/share/gnome:/usr/local/share/:/usr/share/
XDG_MENU_PREFIX=gnome-
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

ls -l /usr/lib/ibus/
total 408
-rwxr-xr-x 1 root root  18504 Oct 20 21:10 ibus-dconf
-rwxr-xr-x 1 root root   1214 Oct 15  2014 ibus-engine-anthy
-rwxr-xr-x 1 root root  35904 Oct 27  2014 ibus-engine-m17n
-rwxr-xr-x 1 root root  14408 Oct 20 21:10 ibus-engine-simple
-rwxr-xr-x 1 root root   1096 Oct 15  2014 ibus-setup-anthy
-rwxr-xr-x 1 root root  27568 Oct 27  2014 ibus-setup-m17n
-rwxr-xr-x 1 root root 211080 Oct 20 21:10 ibus-ui-gtk3
-rwxr-xr-x 1 root root  91848 Oct 20 21:10 ibus-x11

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

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

Versions of packages ibus depends on:
ii  adwaita-icon-theme   3.22.0-1
ii  dconf-cli0.26.0-2
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gir1.2-gtk-3.0   3.22.2-1
ii  gir1.2-ibus-1.0  1.5.14-1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-5
ii  libcairo21.14.6-1+b1
ii  libdconf10.26.0-2
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.1-1
ii  libgtk-3-0   3.22.2-1
ii  libibus-1.0-51.5.14-1
ii  libnotify4   0.7.7-1
ii  libpango-1.0-0   1.40.3-2
ii  libpangocairo-1.0-0  1.40.3-2
ii  librsvg2-common  2.40.16-1
ii  libx11-6 2:1.6.3-1
ii  libxi6   2:1.7.6-1
ii  python3-gi   3.22.0-1
pn  python3:any  

Versions of packages ibus recommends:
ii  ibus-gtk1.5.14-1
ii  ibus-gtk3   1.5.14-1
ii  im-config   0.29-1.4
ii  libqt5gui5  5.6.1+dfsg-3+b1

Versions of packages ibus suggests:
ii  ibus-clutter  0.0+git20090728.a936bacf-5.1+b1
pn  ibus-doc  
pn  ibus-qt4  
ii  libqt5gui55.6.1+dfsg-3+b1

-- no debconf information

Bug#843251: Job for systemd-udevd.service failed because a timeout was exceeded.

[Michael Biebl]

Am 05.11.2016 um 23:11 schrieb 積丹尼 Dan Jacobson:
> severity 843251 grave
> thanks
> Yes i386.
> And you know what?
> the user cannot ever boot his computer ever again, even from grub
> menus' "(recovery mode)".
> 
> ER> I can confirm this behaviour. Be care to reboot:
> ER> If booting with systemd you will be pulled in maintenance mode.
> 
> No you (I) will never get a prompt again, all one sees
> 
>>> 11月 05 22:03:39 jidanni2 systemd[1]: systemd-udevd.service: Failed with 
>>> result 'timeout'.
>>> 11月 05 22:03:39 jidanni2 systemd[1]: systemd-udevd.service: Service has no 
>>> hold-off time, scheduling restart.
> 
> is repeating every 90 seconds.
> 
> You see if **any** of these systemd processes have "no hold-off time" or
> something like that, they will loop over and over every 90 seconds.
> ***There should be a limit of one loop***. Else the user will never be
> able to boot his computer again, no matter how many choices there are in
> the grub menu.
> 
> Please tell me how to fix my computer to boot now. I am using a
> different one to write this message

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843160#100

Sorry for the inconvenience.

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



signature.asc
Description: OpenPGP digital signature

Bug#843334: transition: czmq

[Luca Boccassi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear release team,

czmq 4.0.0 was released yesterday, and it breaks ABI, which was bumped
from 3 to 4.

https://packages.qa.debian.org/c/czmq.html

Reverse dependencies source packages:

rsyslog

The reverse dependency rebuild cleanly without any patches. binNMU
rebuilds should be all that's needed.

libczmq4 is in experimental and it has rebuilt most architectures,
with the mips and armv7 queued. I built locally in qemu and it was all
fine so I do not expect trouble.

I know it's a bit late, but given it's a very simple case I hope it
can be authorized, to avoid having to maintain an old version for many
years! Upstream will not release bug fixes for 3.0.x anymore.

Thank you!

Kind regards,
Luca Boccassi

Bug#843333: [claws-mail] Error sending e-mail

[Marco Righi]

Package: claws-mail
Version: 3.8.1-2+deb7u1
Severity: normal

--- Please enter the report below this line. ---
Sending an e-mail Claws reports the following log:


* Account 'marco.ri...@gmail.com': Connecting to SMTP server: 
smtp.gmail.com ...

*** SSL handshake failed
*** Error occurred while sending the message.
[23:23:34] IMAP4> 10 UID STORE 10 +FLAGS.SILENT (\Deleted)
[23:23:34] IMAP4< * 2 EXPUNGE
[23:23:34] IMAP4< * 1 E
[23:23:34] IMAP4< XISTS
[23:23:34] IMAP4< 10 OK Success
[23:23:34] IMAP4> 11 EXPUNGE
[23:23:34] IMAP4< 11 OK Success
[23:23:34] IMAP4- [fetching UIDs...]
[23:23:34] IMAP4> 12 UID FETCH 1:* (UID)
[23:23:34] IMAP4< * 1 FETCH (UID 2)
[23:23:34] IMAP4< 12 OK Success
[23:23:34] IMAP4- [fetching flags...]
[23:23:34] IMAP4> 13 UID FETCH 1:* (FLAGS UID)
[23:23:34] IMAP4< * 1 FETCH (UID 2 F
[23:23:34] IMAP4< LAGS (\Seen))
[23:23:34] IMAP4< 13 OK Success

--- System information. ---
Architecture: i386
Kernel: Linux 3.4-9-rtai-686-pae

Debian Release: 7.11
500 wheezy linux.dropbox.com
500 oldstable-updates http.debian.net
500 oldstable security.debian.org
500 oldstable http.debian.net
500 linuxcnc linuxcnc.org

--- Package information. ---
Depends (Version) | Installed
=-+-===
libc6 (>= 2.11) | 2.13-38+deb7u11
libcairo2 (>= 1.2.4) | 1.12.2-3+deb7u1
libcompfaceg1 | 1:1.5.2-5
libdbus-glib-1-2 (>= 0.78) | 0.100.2-1
libenchant1c2a (>= 1.6) | 1.6.0-7
libetpan15 (>= 1.0) | 1.0-5
libgdk-pixbuf2.0-0 (>= 2.22.0) | 2.26.1-1+deb7u5
libglib2.0-0 (>= 2.31.8) | 2.33.12+really2.32.4-5
libgnutls26 (>= 2.12.17-0) | 2.12.20-8+deb7u5
libgtk2.0-0 (>= 2.24.0) | 2.24.10-2
libice6 (>= 1:1.0.0) | 2:1.0.8-2
libldap-2.4-2 (>= 2.4.7) | 2.4.31-2+deb7u2
libpango1.0-0 (>= 1.14.0) | 1.30.0-1
libpisock9 | 0.12.5-5
libsm6 | 2:1.2.1-2
xdg-utils | 1.1.0~rc1+git20111210-6+deb7u3


Recommends (Version) | Installed
===-+-===
claws-mail-i18n | 3.8.1-2+deb7u1
xfonts-100dpi | 1:1.0.3
OR xfonts-75dpi | 1:1.0.3
OR xfonts-100dpi-transcoded |
OR xfonts-75dpi-transcoded |
aspell-en | 7.1-0-1
OR aspell-dictionary |


Suggests (Version) | Installed
===-+-===
claws-mail-doc (= 3.8.1-2+deb7u1) |
www-browser |
gedit |
OR kwrite |
OR mousepad | 0.2.16-6
OR nedit | 1:5.6~cvs20081118-7
claws-mail-tools |

Bug#843196: Lack of aclocal --install

[Bastien ROUCARIES]

control: block -1 by 842928

Not really like a charm it is variation of 842928

On Sat, Nov 5, 2016 at 10:42 PM, Bastien ROUCARIES
 wrote:
> I do not understand hy autoreconf does not run aclocal --install...
>
> If done it work like a charm

Bug#843268: jessie-pu: package nettle/2.7.1-5+deb8u2

[Magnus Holmgren]

lördag 5 november 2016 kl. 20:17:40 CET skrev du:
> On Sat, 2016-11-05 at 18:07 +0100, Magnus Holmgren wrote:
> > Here is a debdiff for a proposed upload to address CVE-2016-6489 ("RSA
> > code is vulnerable to cache sharing related attacks") in jessie, which
> > the Security Team thinks should be done but which doesn't warrant a DSA.
> 
> It appears that you've uploaded already; it would have been appreciated
> if you'd waited for an ack.
> 
> For one thing, I'd have at least queried:

Oh, terribly sorry. I read your ack of gnutls28, which I was Cc:d to, too 
quickly.

> For one thing, I'd have at least queried:
> 
> - -- Magnus Holmgren   Sat, 06 Feb 2016 20:01:37 +0100
> + -- Magnus Holmgren   Tue, 09 Feb 2016 20:57:42 +0100

Right, I apparently failed to check in the previous update in SVN right after 
the upload and must have accidentally touched the changelog timestamp. I'm 
pretty sure nothing more important is messed up.

-- 
Magnus Holmgrenholmg...@debian.org
Debian Developer 

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

Bug#843251: Job for systemd-udevd.service failed because a timeout was exceeded.

[積丹尼 Dan Jacobson]

severity 843251 grave
thanks
Yes i386.
And you know what?
the user cannot ever boot his computer ever again, even from grub
menus' "(recovery mode)".

ER> I can confirm this behaviour. Be care to reboot:
ER> If booting with systemd you will be pulled in maintenance mode.

No you (I) will never get a prompt again, all one sees

>> 11月 05 22:03:39 jidanni2 systemd[1]: systemd-udevd.service: Failed with 
>> result 'timeout'.
>> 11月 05 22:03:39 jidanni2 systemd[1]: systemd-udevd.service: Service has no 
>> hold-off time, scheduling restart.

is repeating every 90 seconds.

You see if **any** of these systemd processes have "no hold-off time" or
something like that, they will loop over and over every 90 seconds.
***There should be a limit of one loop***. Else the user will never be
able to boot his computer again, no matter how many choices there are in
the grub menu.

Please tell me how to fix my computer to boot now. I am using a
different one to write this message.

Apparently I have to go to the grub command line, somehow mount the root file
system, and remove one of your /etc/ files.

Maybe it is /lib/systemd/system/systemd-journald.service . Will that fix
it? Thanks!!

Indeed my computer has separate /, /home, and /var .
However I can only tell you that because I kept a record of their
configuration on a different computer. Other users won't be able to
answer because they won't be able to boot to tell you.

Bug#842015: [PINENTRY PATCH v2] gnome3: Test if Gcr System Prompter is available at startup.

[Neal H. Walfield]

Hi Daniel,

Thanks for fixing this!  As discussed offline, I made a few minor
tweaks before comitting (2e17565).

:) Neal

At Thu,  3 Nov 2016 12:31:40 -0400,
Daniel Kahn Gillmor wrote:
> 
> * gnome3/pinentry-gnome3.c (gcr_system_prompt_available): New. Tests
> whether it is possible to create a GcrSystemPrompt.
> (main): Use gcr_system_prompt_available() to decide whether to fall
> back to curses or not.
> 
> Debian-bug-id: 842015
> Signed-off-by: Daniel Kahn Gillmor 
> ---
>  gnome3/pinentry-gnome3.c | 39 +++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c
> index d6d7d16..37c7a44 100644
> --- a/gnome3/pinentry-gnome3.c
> +++ b/gnome3/pinentry-gnome3.c
> @@ -258,6 +258,39 @@ gnome3_cmd_handler (pinentry_t pe)
>  
>  pinentry_cmd_handler_t pinentry_cmd_handler = gnome3_cmd_handler;
>  
> +
> +/* test whether we can create a system prompt or not.  This briefly
> +   does create a system prompt, which blocks other tools from making
> +   the same concurrent request, so we just create it to test if it is
> +   available, and quickly close it.
> +*/
> +int gcr_system_prompt_available ()
> +{
> +  GcrSystemPrompt *prompt;
> +  GError *error = NULL;
> +  int ret = 0;
> +  
> +  prompt = gcr_system_prompt_open (0, NULL, );
> +  if (prompt)
> +{
> +  ret = 1;
> +  if (!gcr_system_prompt_close (prompt, NULL, ))
> +  fprintf (stderr, "failed to close test Gcr System Prompt (%d): 
> %s\n",
> +   error ? error->code : -1, error ? error->message : " GError>");
> +  g_clear_object ();
> +}
> +  else
> +  /* This one particular failure is OK; we're clearly capable of
> + making a system prompt, even though someone else has the
> + system prompter right now: */
> +if (error && error->code == GCR_SYSTEM_PROMPT_IN_PROGRESS)
> +  ret = 1;
> +
> +  if (error)
> +g_error_free (error);
> +  return ret;
> +}
> +
>  int
>  main (int argc, char *argv[])
>  {
> @@ -270,6 +303,12 @@ main (int argc, char *argv[])
> " falling back to curses\n");
>pinentry_cmd_handler = curses_cmd_handler;
>  }
> +  else if (!gcr_system_prompt_available ())
> +{
> +  fprintf (stderr, "No Gcr System Prompter available,"
> +   " falling back to curses\n");
> +  pinentry_cmd_handler = curses_cmd_handler;
> +}  
>  #endif
>  
>pinentry_parse_opts (argc, argv);
> -- 
> 2.10.1
> 
> 
> ___
> Gnupg-devel mailing list
> gnupg-de...@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 

Bug#833457: hdf5: Please enable packaging of libhdf5-openmpi-dev on hppa arch

[Gilles Filippini]

Control: tags -1 confirmed

On Thu, 4 Aug 2016 17:33:58 +0200 Helge Deller  wrote:
> Package: hdf5
> Version: 1.8.16+docs-8
> Severity: normal
> 
> Can you please re-enable hppa as arch which builds libhdf5-openmpi-dev ?
> It breaks building other packages, and openmpi now builds on hppa (and m68k 
> and sh4).
> 
> The relevant lines in the debian/rules file are:
> ARCH_FLAG=-a
> # openmpi broken on archs hppa m68k sh4 (2016-02-24)
> OMPIARCHS?=any !hppa !m68k !sh4
> MPICHARCHS?=any

Will do after the upcoming hdf5-1.10 transition.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#843073: dpkg-shlibdeps: broken on i386 with merged /usr

[Marco d'Itri]

On Nov 03, Ross Vandegrift  wrote:

> debootstrap 1.0.85 began deploying with --merged-usr by default in
> response to #839046.  On i386, this causes dpkg-shlibdeps to fail on
> (some?) shared libraries.
This is a more complex issue, since it does not happen on my i386 
system.
It has been discussed in #810499 but I am not sure about the best way to 
fix this.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#843196: Lack of aclocal --install

[Bastien ROUCARIES]

I do not understand hy autoreconf does not run aclocal --install...

If done it work like a charm

Bug#843332: /usr/bin/plasmashell: segmentation fault when attempting to start plasmashell after upgrade

[Arthur Marsh]

Package: plasma-workspace
Version: 4:5.8.2-1
Severity: important
File: /usr/bin/plasmashell

Dear Maintainer,

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

   * What led up to the situation?

Upgrading plasma-workspace and related KDE/Qt packages

Plasma panel did not appear.

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

 gdb --args plasmashell --shut-up
GNU gdb (Debian 7.11.1-2) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from plasmashell...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/plasmashell --shut-up
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x77698700 (LWP 11844)]
[New Thread 0x76c65700 (LWP 11845)]
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-amarsh04'
[New Thread 0x7fffe700 (LWP 11847)]
[New Thread 0x7fffeec6c700 (LWP 11848)]
[New Thread 0x7fffed1c7700 (LWP 11849)]
last screen is < 0 so putting containment on screen  0
[New Thread 0x7fff5bfff700 (LWP 11850)]
file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Panel.qml:83:
 TypeError: Cannot read property 'Layout' of null
Connecting to deprecated signal 
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/ScrollView.qml:198: 
TypeError: Property 'hasOwnProperty' of object QQuickRow(0x14d8120) is not a 
function
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/Button.qml:99: 
TypeError: Cannot read property of null
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/Button.qml:99: 
TypeError: Cannot read property of null
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/Button.qml:99: 
TypeError: Cannot read property of null
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/Button.qml:99: 
TypeError: Cannot read property of null
file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/ToolTipDelegate.qml:131:
 TypeError: Type error
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/Styles/Plasma/ScrollViewStyle.qml:71:
 TypeError: Cannot read property 'atYBeginning' of null
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/Styles/Plasma/ScrollViewStyle.qml:90:
 TypeError: Cannot read property 'atYEnd' of null
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/Styles/Plasma/ScrollViewStyle.qml:108:
 TypeError: Cannot read property 'atXBeginning' of null
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/Styles/Plasma/ScrollViewStyle.qml:126:
 TypeError: Cannot read property 'atXEnd' of null
file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/main.qml:78:27:
 Unable to assign [undefined] to QStringList
file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/main.qml:37:
 TypeError: Cannot read property 'DateTime' of undefined
[New Thread 0x7fff56199700 (LWP 11851)]
qml: Reading townStrings from configuration: 
[{"placeAlias":"Adelaide","townString":"Australia/South_Australia/Adelaide"},{"placeAlias":"Adelaide_Hills","townString":"Australia/South_Australia/Adelaide_Hills"}]
qml: townStrings count 2 0
qml: townStringIndex now 0
qml: next town string is: Australia/South_Australia/Adelaide
qml: next xmlCacheKey is: xmlCache_-808759485
qml: init: plasmoid.configuration.lastReloadedMs = 1478381588534
qml: loading from cache, config key:  xmlCache_-808759485
qml: cache not available
[New Thread 0x7fff55998700 (LWP 11852)]
qml: reload called, xmlCacheKey is: xmlCache_-808759485
qml: reloading image
qml: Reading townStrings from configuration: 
[{"placeAlias":"Adelaide","townString":"Australia/South_Australia/Adelaide"},{"placeAlias":"Adelaide_Hills","townString":"Australia/South_Australia/Adelaide_Hills"}]
qml: townStrings count 2 0
qml: townStringIndex now 0
qml: next town string is: Australia/South_Australia/Adelaide
qml: next xmlCacheKey is: xmlCache_-808759485
qml: init: plasmoid.configuration.lastReloadedMs = 1478331786565
qml: loading from cache, config key:  xmlCache_-808759485
qml: reloading image
link XMLID_10_ hasn't been detected!
Could not resolve property : XMLID_29_

Bug#843331: lintian: check for embedded-pear-module needs to be more granular for unstable/testing/stretch

[Carsten Schoenert]

Package: lintian
Version: 2.5.49
Severity: normal

Dear Maintainer,

due the PHP7 transition at least the suggestion for using
php-mail-mimedecode for PEAR related code is wrong for testing/stretch
or above.

I discovered this issue while updating the d-push package which includes
modified files from PEAR. The following output is given for example:

  X: z-push-common: embedded-pear-module 
usr/share/z-push/include/mimeDecode.php please use php-mail-mimedecode

But php-mail-mimedecode was removed from testing on 02 May 2016

  https://tracker.debian.org/news/765539

This is due a ROM because of the PHP7 transition.

  https://tracker.debian.org/news/765438

I don't know if there is a aquivalent package available after the PHP7
transition. If not this warning needs to be otherwise solved.

Regards
Carsten

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (400, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

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

Versions of packages lintian depends on:
ii  binutils  2.27-9+b1
ii  bzip2 1.0.6-8
ii  diffstat  1.61-1
ii  file  1:5.29-1
ii  gettext   0.19.8.1-1
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.30
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b1
ii  libdpkg-perl  1.18.10
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libparse-debianchangelog-perl 1.2.0-11
ii  libperl5.22 [libdigest-sha-perl]  5.22.2-5
ii  libperl5.24 [libdigest-sha-perl]  5.24.1~rc3-3
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.63-1+b1
ii  man-db2.7.5-1
ii  patchutils0.3.4-2
ii  perl  5.24.1~rc3-3
ii  t1utils   1.39-2
ii  xz-utils  5.2.2-1.2

Versions of packages lintian recommends:
ii  dpkg 1.18.10
ii  libperlio-gzip-perl  0.19-1+b2
ii  perl 5.24.1~rc3-3
ii  perl-modules-5.22 [libautodie-perl]  5.22.2-5
ii  perl-modules-5.24 [libautodie-perl]  5.24.1~rc3-3

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.10
ii  libhtml-parser-perl3.72-2+b1
ii  libtext-template-perl  1.46-1

-- no debconf information

Bug#833905: dimbl will get removed from Debian (was: Re: Bug#833905: dimbl: FTBFS: include/dimbl/DimProcs.h:37:29: error: expected ')' before '&' token)

[Joost van Baal-Ilić]

See also Bug#843328: O: dimbl .

Chris and Adrian: thanks a lot for your investigations!

Bye,

Joost



signature.asc
Description: Digital signature

Bug#843310: systemd-journald: user service logs are not available to normal users unless persistent Storage is used.

[Felipe Sateler]

Control: forwarded -1 https://github.com/systemd/systemd/issues/2744

On 5 November 2016 at 16:46, Michael Biebl  wrote:
> Hi
>
> Am 05.11.2016 um 20:16 schrieb Daniel Kahn Gillmor:
>> Package: systemd
>> Version: 232-1
>> Severity: normal
>>
>> Dear systemd and journald maintainers,
>>
>> User services generate output and that output is logged by the user's
>> systemd session manager. journalctl(1) says:
>>
>>All users are granted access to their private per-user journals.
>>
>
>
> Please file that issue upstream. Either the documentation needs to be
> fixed or the software.
> In either case, it isn't a Debian specific issue.

There is already an issue upstream, but nobody has fixed it yet.

-- 

Saludos,
Felipe Sateler

Bug#843330: opendmarc segfaults when invoked for local/ignored hosts

[Jason Rhinelander]

Package: opendmarc
Version: 1.3.2~Beta0+dfsg-2
Severity: important
Tags: upstream patch

Dear Maintainer,

opendmarc segfaults when invoked (via milter) if the host is an ignored host
(e.g. localhost).

I manually fixed the .service generator script (#843327) to get opendmarc
started under systemd.  It started, but when postfix invokes it, I get
segfaults for some mail (and after seeing the below, the segfaults are
apparently for any mail from an ignored host/ip, such as mail originating from
the local system).

This was reported upstream in https://sourceforge.net/p/opendmarc/tickets/185/;
I applied the patch attached in that report, rebuilt the debian package, and
the package with that patch applied now works without segfaulting.

Please make a new release with that patch applied!

Jason Rhinelander


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

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

Versions of packages opendmarc depends on:
ii  adduser 3.115
ii  libbsd0 0.8.3-1
ii  libc6   2.24-5
ii  libmilter1.0.1  8.15.2-6
ii  libopendmarc2   1.3.2~Beta0+dfsg-2
ii  libspf2-2   1.2.10-7+b1
ii  lsb-base9.20161016
ii  publicsuffix20160826-1

Versions of packages opendmarc recommends:
ii  libdbd-mysql-perl 4.037-5
ii  libdbi-perl   1.636-1+b1
ii  libhttp-message-perl  6.11-1
ii  libopendbx1   1.4.6-11
pn  libopendbx1-mysql 
ii  libswitch-perl2.17-2
ii  perl  5.24.1~rc3-3
pn  perl:any  

opendmarc suggests no packages.

-- Configuration Files:
/etc/default/opendmarc changed:
RUNDIR=/var/spool/postfix/opendmarc
SOCKET=local:$RUNDIR/opendmarc.sock
USER=opendmarc
GROUP=postfix
PIDFILE=$RUNDIR/$NAME.pid
EXTRAAFTER=

/etc/opendmarc.conf changed:
PidFile /var/run/opendmarc.pid
RejectFailures false
Syslog true
IgnoreAuthenticatedClients true
UMask 
Socket local:/var/spool/postfix/opendmarc/opendmarc.sock
HistoryFile /var/lib/opendmarc/history.dat
UserID opendmarc:postfix
PublicSuffixList /usr/share/publicsuffix/


-- no debconf information

-- debsums errors found:
debsums: can't check opendmarc file /usr/share/doc/opendmarc/README.gz (Wide 
character in subroutine entry)
debsums: can't check opendmarc file 
/usr/share/doc/opendmarc/README.opendmarc.gz (Wide character in subroutine 
entry)
debsums: can't check opendmarc file 
/usr/share/doc/opendmarc/changelog.Debian.gz (Wide character in subroutine 
entry)
debsums: can't check opendmarc file /usr/share/doc/opendmarc/changelog.gz (Wide 
character in subroutine entry)
debsums: can't check opendmarc file 
/usr/share/doc/opendmarc/opendmarc.conf.sample.gz (Wide character in subroutine 
entry)
debsums: can't check opendmarc file /usr/share/man/man5/opendmarc.conf.5.gz 
(Wide character in subroutine entry)
debsums: can't check opendmarc file /usr/share/man/man8/opendmarc-check.8.gz 
(Wide character in subroutine entry)
debsums: can't check opendmarc file /usr/share/man/man8/opendmarc-expire.8.gz 
(Wide character in subroutine entry)
debsums: can't check opendmarc file /usr/share/man/man8/opendmarc-import.8.gz 
(Wide character in subroutine entry)
debsums: can't check opendmarc file 
/usr/share/man/man8/opendmarc-importstats.8.gz (Wide character in subroutine 
entry)
debsums: can't check opendmarc file /usr/share/man/man8/opendmarc-params.8.gz 
(Wide character in subroutine entry)
debsums: can't check opendmarc file /usr/share/man/man8/opendmarc-reports.8.gz 
(Wide character in subroutine entry)
debsums: can't check opendmarc file /usr/share/man/man8/opendmarc.8.gz (Wide 
character in subroutine entry)

Bug#843329: RFS: rhythmbox-plugin-alternative-toolbar/0.17.3-1

[foss.freedom]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package
"rhythmbox-plugin-alternative-toolbar"

 * Package name: rhythmbox-plugin-alternative-toolbar
   Version : 0.17.3-1
   Upstream Author : David Mohammed fossfree...@ubuntu.com
 * URL : github.com/fossfreedom/alternative-toolbar
 * License : GPLv3
   Section : misc

  It builds those binary packages:

rhythmbox-plugin-alternative-toolbar - Enhanced play controls and
interface for Rhythmbox

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

  https://mentors.debian.net/package/rhythmbox-plugin-alternative-toolbar


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

dget -x 
https://mentors.debian.net/debian/pool/main/r/rhythmbox-plugin-alternative-toolbar/rhythmbox-plugin-alternative-toolbar_0.17.3-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

 * New upstream release.
- latest zh_CN translation
  * Packaging Changes.
- debian/prerm and debian/postrm are shell scripts so start
  with #!/bin/sh (Closes: #843278)


  Regards,
   David Mohammed

Bug#843328: O: dimbl - Distributed Memory Based Learner for Natural Language Processing

[Joost van Baal-Ilić]

Package: wnpp
Severity: normal

Hi,

I am no longer interested in maintaining dimbl.  Upstream (Maarten van Gompel)
feels shipping dimbl with Debian is of very limited use: people interested in
dimbl likely are better served always using the very latest version of it.

I'll request for removal of dimbl from unstable and testing, soonish.

Unless someone else steps up RSN, that is.  Be aware there is serious/RC/FTBFS
Bug #833905 open (which is relatively easy to fix).)

(From the description: The Dimbl Distributed Memory Based Learner is a wrapper
around the k-nearest neighbor classifier in TiMBL, offering parallel
classification on multi-CPU machines. Dimbl splits the original training set,
builds separate TiMBL classifiers per training subset, and merges their
nearest-neighbor sets per classified instance.  If you do scientific research
in Natural Language Processing using the Memory-Based Learning technique, Dimbl
will likely be of use to you.)

Bye,

Joost



signature.asc
Description: Digital signature

Bug#810650: Two more months

[Geert Stappers]

Two more months.
Time will tell what was achieved in those precious nine weeks.

- Forwarded message from ni...@thykier.net -

Date: Sat, 05 Nov 2016 21:23:44 +0100
From: ni...@thykier.net
To: debian-devel-annou...@lists.debian.org
Subject: Release update: Transition freeze and other upcoming events

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Today is the transition freeze, as we announced in [1]. That means no
new library transitions or package transitions that involve a large
number of packages.

Please note that some transitions are ongoing or about to start in the
next couple of days. We will work hard to make those as smooth as
possible, so please bear with us while things finally settle.


Future milestone dates in the stretch freeze


This is the first of four milestones for the stretch freeze[2]. The
Release Team maintains a calendar of these at [3] along with other
important dates. The next milestones are (in order):

Dec 5: Forced 10-day migration delay
- 

All package migrations will have a mandatory 10-day migration delay by
default (i.e. Britney will ignore urgencies from the changelog).

 * Very urgent updates (security updates) can have their delay lowered.
 * Please file an unblock request where needed. (reportbug release.debian.org)

Jan 5: soft freeze
- --

Deadline for:
 
 * New (source) packages in stretch
 * Letting packages re-enter stretch (if they have been removed)

Updates to existing packages in stretch will continue as normal.

Remember:
 * New packages must be in testing before January 5th.
 * With the mandatory 10-day delay, the latest day for the upload is
   /at least/ 10 days earlier.
 * Delays caused by RC bugs (even in other packages), lazy FTP-masters or
   a long NEW queue (etc.) are *not* an excuse to be late.

Feb 5: Full freeze
- --

Freeze for stretch:

 * All changes to stretch will require approval.
 * Use "reportbug release.debian.org" for requesting unblocks.

Remember: 
 * Uploaded changes must be in testing before February 5th
 * With the mandatory 10-day delay, the latest day for the upload is
   /at least/ 10 days earlier.
 * Delays caused by RC bugs other packages, slow buildds,
   "C-x M-c M-butterfly" (etc.) are *not* an excuse to be late.


You can also find the dates and their descriptions in our calendar[3].

We will keep you updated as the freeze progresses.

For the Release Team,
 Emilio and Niels

[1] https://lists.debian.org/debian-devel-announce/2016/07/msg2.html
[2] https://release.debian.org/#release-dates
[3] https://release.debian.org/release-calendar.ics

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYHj6xAAoJEAVLu599gGRCWPsP/1MVYVbCImvLx+tAbdJsIMpA
jqKu3vuiCABj5aIqioA3OjeuFedGYVekDGYaqQZApxiTtQLg5fKXmT04NUYBku65
V1xax4fnLO3zxK/BQJIC1wVmfUQLjjw/LOLQMAUYOT0+w2WEhjsdb2XUqBv9Y0pj
aX2MGKx802ozn2Om3whS3YOySj8/w8AncN52GHaKJgF1D+kd7Yp+59zHaXJaqg1I
2Z7XegxZ3kE3XwrrXBjTrRCDlKUA//ALWE+EoACJdpxCmc4eEAHqz1497W/8kZxo
FXHqb7in/UDLp+a2Oqj2lnhXLGJ2mUpk/DtJx9hGMTCd4WcYk22RSLn6rorze1vs
9K5golm48MESmkvvDJvHpW7ASGAUMwj+WZ/BCAx/YC1sPaCAISpsaz9Dnfg0swzP
Priagzcau5bjcU8+jJU3yWPJXiU0Ah8rkPulYiAfvSvV6mWukyIfK33ek42V7lrK
8iIZrkyq+iyc77i+MAXYpJ6Y1Nm0lEwexgS6+849qabJ0Qn4svpwQtZQsF9MDdR9
+2zQcgRW1SKBsSww6zmPppgAkUc6GSm6c7tsIm4upga93+fCb6a9qDkMpxY1lTHP
jK2hgs7tKYNVMxCtQHkYGnJULy0L4COyhz2CmUHGWCk4U782dPT1jzJgIa72M3YW
gK9Bjb++/9778EA4VvZA
=ehk+
-END PGP SIGNATURE-


- End forwarded message -

-- 
Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#843327: opendmarc: generated systemd service file is completely non-functional

[Jason Rhinelander]

Package: opendmarc
Version: 1.3.2~Beta0+dfsg-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The opendmarc.service file generated by opendmarc ends up trying to invoke
/usr/sbin/opendkim rather than /usr/sbin/opendmarc to start the daemon.  This
is clearly wrong (luckily it doesn't actually start opendkim, because opendkim
barfs at being given a conf file with opendmarc options).

This is coming from the opendmarc.service.generate script's ExecStart line:

echo "ExecStart=/usr/sbin/opendkim -p $SOCKET $DAEMON_OPTS -x 
/etc/$NAME.conf -u $USER -P $PIDFILE" >> $SERVICEFILE.new

That has at least three problems that I ran into trying to fix this:

- /usr/sbin/opendkim should be /usr/sbin/opendmarc

- the -x flag should be -c

- the -p $SOCKET bit is sometimes wrong; /etc/default/opendmarc says SOCKET
  overrides the Socket setting in the config file, and the
  /etc/init.d/opendmarc script indeed handles this.  If I fix the above two
  issues but comment out SOCKET in /etc/default/opendmarc (because I have the
  Socket specified in /etc/opendmarc.conf), I get a failure to start with bad
  argument output because SOCKET isn't set, so there is no argument following
  the "-p".


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

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

Versions of packages opendmarc depends on:
ii  adduser 3.115
ii  libbsd0 0.8.3-1
ii  libc6   2.24-5
ii  libmilter1.0.1  8.15.2-6
ii  libopendmarc2   1.3.2~Beta0+dfsg-2
ii  libspf2-2   1.2.10-7+b1
ii  lsb-base9.20161016
ii  publicsuffix20160826-1

Versions of packages opendmarc recommends:
ii  libdbd-mysql-perl 4.037-5
ii  libdbi-perl   1.636-1+b1
ii  libhttp-message-perl  6.11-1
ii  libopendbx1   1.4.6-11
pn  libopendbx1-mysql 
ii  libswitch-perl2.17-2
ii  perl  5.24.1~rc3-3
pn  perl:any  

opendmarc suggests no packages.

-- Configuration Files:
/etc/opendmarc.conf changed:
PidFile /var/run/opendmarc.pid
RejectFailures false
Syslog true
IgnoreAuthenticatedClients true
UMask 
Socket local:/var/spool/postfix/opendmarc/opendmarc.sock
HistoryFile /var/lib/opendmarc/history.dat
UserID opendmarc:opendmarc
PublicSuffixList /usr/share/publicsuffix/


-- no debconf information

Bug#842961: add missing backtrace

[stefan esterer]

Hi Carsten,

I'm sorry to say that the crash isn't reproducable anymore since the
mail provider is working again (i.e. riseup's smtp server sending
mails). This hints for icedove having problems with error handling.

If the problem reoccurs, I will try to collect the full log and will
use the iedove-dbg package.

Btw. I'm using the current icedove version in testing. i.e.:
apt-cache policy icedove
icedove:
  Installiert:   1:45.4.0-1
  Installationskandidat: 1:45.4.0-1
  Versionstabelle:
 *** 1:45.4.0-1 900
900 http://ftp.at.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status

Regards,
Stefan

On 2016-11-04 08:47, Carsten Schoenert wrote:
> Hello Stefan,
> 
> On Thu, Nov 03, 2016 at 11:18:32PM +0100, stefan esterer wrote:
>> the attachement contains the backtrace collected via  (gdb) thread apply
>> all bt
> 
> please add the *full* log created as described in
> https://wiki.debian.org/Icedove#Starting_Debugging
> 
> We don't know which version you using nor were the segfault is happen.
> We "only" have now the backtrace. And it seams you don't have used
> icedove-dbg but a full log can say more.
> 
> Regrads
> Carsten
> 

Bug#827061: transition: openssl

[Sebastian Andrzej Siewior]

On 2016-10-26 10:55:19 [+0200], Emilio Pozuelo Monfort wrote:
> So let's do this. Let's try to get it finished and only ship openssl 1.1. We
> still have three months until the full freeze, and depending on how many
> packages (and which ones, for risk management etc) are left to be fixed after
> that, I may be happy to grant exceptions. But worst case we just ship both.

I've been playing with ben. I tried a few things and this is the best I
was able to achieve [0]:

title = "openssl 1.0";
is_affected = .build-depends ~ /libssl1.0-dev/;
is_good = .depends ~ /libssl1.0.2/;
is_bad = .depends ~ /libssl1.1/;

And

title = "openssl 1.1";
is_affected = .build-depends ~ /libssl-dev/;
is_good = .depends ~ /libssl1\.1/;
is_bad = .depends ~ /libssl1\.0\.2/;

The first one will keep a list of all packages that want to stay with
1.0.2. The bad state of the second tracker should keep track of
everything that needs action.
You might also want to add [1] if you think it is usefull here.

I noticed that people close the bug referenced in [1] and stay with
1.0.2. Shouldn't they just unblock this transition bug and downgrade
severity to important?

[0] it seems ben can't match something like ".build-depends ~
/libssl-dev/ & .depends ~ /libssl1.0.2/" but this would allow to
keep everything in one page.
[1] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans;users=pkg-openssl-devel-requ...@lists.alioth.debian.org

> Cheers,
> Emilio

Sebastian

Bug#843326: acpi: "Failed to start ACPI event daemon" "Got more than one socket." after apt-get update

[drcnjio908]

Package: acpi
Version: 1.7-1
Severity: normal

Dear Maintainer,

First after an 'apt-get update' and then also when trying 'apt-get install
--reinstall acpi', I got the following output:

sudo apt-get install --reinstall acpi
Setting up acpid (1:2.0.28-1) ...
Job for acpid.service failed because of unavailable resources or another
system error.
See "systemctl status acpid.service" and "journalctl -xe" for details.
invoke-rc.d: initscript acpid, action "start" failed.
● acpid.service - ACPI event daemon
   Loaded: loaded (/lib/systemd/system/acpid.service; disabled; vendor
preset: enabled)
   Active: failed (Result: resources) since Thu 2016-11-03 17:07:45 CET;
22h ago
 Main PID: 526 (code=exited, status=0/SUCCESS)

Nov 03 17:21:07 $USER-pc systemd[1]: Failed to start ACPI event daemon.
Nov 03 17:21:07 $USER-pc systemd[1]: acpid.service: Failed with result
'resources'.
Nov 03 17:23:30 $USER-pc systemd[1]: acpid.service: Got more than one
socket.
Nov 03 17:23:30 $USER-pc systemd[1]: acpid.service: Failed to run 'start'
task: Invalid argument
Nov 03 17:23:30 $USER-pc systemd[1]: Failed to start ACPI event daemon.
Nov 03 17:23:30 $USER-pc systemd[1]: acpid.service: Failed with result
'resources'.
Nov 04 15:25:36 $USER-pc systemd[1]: acpid.service: Got more than one
socket.
Nov 04 15:25:36 $USER-pc systemd[1]: acpid.service: Failed to run 'start'
task: Invalid argument
Nov 04 15:25:36 $USER-pc systemd[1]: Failed to start ACPI event daemon.
Nov 04 15:25:36 $USER-pc systemd[1]: acpid.service: Failed with result
'resources'.
dpkg: error processing package acpid (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for systemd (231-10) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for menu (2.1.47) ...
Errors were encountered while processing:
 acpid
E: Sub-process /usr/bin/dpkg returned an error code (1)
systemctl status acpid.service
● acpid.service - ACPI event daemon
   Loaded: loaded (/lib/systemd/system/acpid.service; disabled; vendor
preset: enabled)
   Active: failed (Result: resources) since Thu 2016-11-03 17:07:45 CET;
22h ago
 Main PID: 526 (code=exited, status=0/SUCCESS)
sudo journalctl -xe
Nov 04 15:31:45 $USER-pc audit[14127]: USER_START pid=14127 uid=0 auid=1000
ses=1 msg='op=PAM:session_open acct="root"
Nov 04 15:31:45 $USER-pc sudo[14127]: pam_unix(sudo:session): session
opened for user root by $USER(uid=0)
Nov 04 15:31:48 $USER-pc systemd[1]: Reloading.
Nov 04 15:31:48 $USER-pc systemd[1]: fancontrol.service: Supervising
process 679 which is not our child. We'll most li
Nov 04 15:31:48 $USER-pc systemd[1]: apt-daily.timer: Adding 6h 6min
36.758435s random time.
Nov 04 15:31:48 $USER-pc systemd[1]: Reloading.
Nov 04 15:31:48 $USER-pc systemd[1]: fancontrol.service: Supervising
process 679 which is not our child. We'll most li
Nov 04 15:31:48 $USER-pc systemd[1]: apt-daily.timer: Adding 8h 9min
13.182828s random time.
Nov 04 15:31:48 $USER-pc systemd[1]: acpid.service: Got more than one
socket.
Nov 04 15:31:48 $USER-pc systemd[1]: acpid.service: Failed to run 'start'
task: Invalid argument
Nov 04 15:31:48 $USER-pc systemd[1]: Failed to start ACPI event daemon.
-- Subject: Unit acpid.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit acpid.service has failed.
--
-- The result is failed.
Nov 04 15:31:48 $USER-pc systemd[1]: acpid.service: Failed with result
'resources'.
Nov 04 15:31:49 $USER-pc sudo[14127]: pam_unix(sudo:session): session
closed for user root
Nov 04 15:31:49 $USER-pc audit[14127]: USER_END pid=14127 uid=0 auid=1000
ses=1 msg='op=PAM:session_close acct="root"
Nov 04 15:31:49 $USER-pc audit[14127]: CRED_DISP pid=14127 uid=0 auid=1000
ses=1 msg='op=PAM:setcred acct="root" exe="
Nov 04 15:33:23 $USER-pc audit[14926]: USER_CMD pid=14926 uid=1000
auid=1000 ses=1 msg='cwd="/home/$USER" cmd=6A6F75
Nov 04 15:33:23 $USER-pc sudo[14926]:  $USER : TTY=pts/1 ; PWD=/home/$USER
; USER=root ; COMMAND=/bin/journalctl -
Nov 04 15:33:23 $USER-pc audit[14926]: CRED_REFR pid=14926 uid=0 auid=1000
ses=1 msg='op=PAM:setcred acct="root" exe="
Nov 04 15:33:23 $USER-pc audit[14926]: USER_START pid=14926 uid=0 auid=1000
ses=1 msg='op=PAM:session_open acct="root"
Nov 04 15:33:23 $USER-pc sudo[14926]: pam_unix(sudo:session): session
opened for user root by $USER(uid=0)

It turned out, that I had to kill fancontrol which was running in the
background. I found the error message unncessarily frightening, maybe the
update can somehow come to and give a more descriptive message like: "Close
programs associated with acpi (fancontrol, ...)".



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (950, 'testing'), (54, 'unstable')

Bug#843144: #843144 is a problem in ffmpeg

[Nelson A. de Oliveira]

reassign 843144 ffmpeg
found 843144 7:3.1.5-1
thanks

Hi!

I am hitting this same issue but from what I could inspect, it's
something related with ffmpeg (and not vokoscreen)

For example, directly calling ffmpeg like this, it fails:

ffmpeg -f x11grab -draw_mouse 1 -framerate 25 -video_size 1920x1080 -i
:0+0,0  -pix_fmt yuv420p -c:v libx264 -preset veryfast -q:v 1 -s
1920x1080 video.mkv

The above example is basically what vokoscreen is using.
We can see a lot of frames being dropped.

When using -report it's possible to see a lot of messages like this:

=
cur_dts is invalid (this is harmless if it occurs once at the start per stream)
[rawvideo @ 0x562345919700] PACKET SIZE: 8294400, STRIDE: 7680
Clipping frame in rate conversion by 0.08
cur_dts is invalid (this is harmless if it occurs once at the start per stream)
[rawvideo @ 0x562345919700] PACKET SIZE: 8294400, STRIDE: 7680
(...)
=

While this work:

ffmpeg -f x11grab -draw_mouse 1 -r 25 -s 1920x1080 -i :0.0+0 -vcodec
libx264 video.mkv

Tested with ffmpeg 7:3.1.5-1 and latest 7:3.2-2.
I am unsure if this could be a problem with some lib that ffmpeg uses
(and I don't know how to test this)

Thank you!

Best regards,
Nelson

Bug#828550: socat: FTBFS with openssl 1.1.0

[Gerhard Rieger]

Hello,

sorry for not replying so long, this was due to private issues I have.
I intend to test for the new functions in autoconf and have the
preprocessor conditionals check for these results instead of
OPENSSL_VERSION_NUMBER.

Regards
Gerhard


Am 03.11.2016 um 22:38 schrieb Sandro Tosi:
> On Thu, Nov 3, 2016 at 3:59 PM, László Böszörményi (GCS)  
> wrote:
>> On Thu, Nov 3, 2016 at 8:42 PM, Sandro Tosi  wrote:
>>> On Mon, 5 Sep 2016 10:53:05 +0200 Gerhard Rieger
>>>  wrote:
 Thank you, I will check!
>>>
>>> hey Gerhard, do you have a plan to look at this soon (now that openssl
>>> 1.1.0 bugs are RC)? thanks!
>>  Anything wrong with Sebastian Andrzej Siewior's patch? I plan to use
>> if no one objects.
> 
> not from me (but i dont know anything about it :) ) i was just
> checking if there was some problem that prevented Gerhard to update
> the pkg. László if you have time and can prepare an updated pkg that'd
> be great!
> 
> Thanks,
> 

Bug#734100: Fixed in VLC 3.0

[Forest]

Remi Denis-Courmont wrote:

>VLC upstream has not approved any patchset on top of VLC 2.2, 

Yes, I know.  Their failure to address this bug is responsible for vlc being
badly broken for a long time now.  I would think this an appropriate reason
to apply a downstream patch.

>the upstream solution is very far from trivial to backport.

Yes, I know.  I saw it.

>At least, all the patches for VLC 2.2 that I´ve seen proposed are all known 
>broken. That is to say that they do fix the symptoms, but they introduce even 
>worse problems that _will_ break VLC for other people.

I appreciate what you're saying, but have you examined my patchset?  It's
not quite the same as any other that I've seen, and I have yet to receive
any criticism of it at all.  If it will cause breakage, I'd like to know
specifically how, so I can either fix it or abandon the effort.  I'd hate to
think it was being prematurely dismissed.

Bug#840598: RFS: poppassd/1.8.7-1 [QA]

[Peter Colberg]

Hi,

In light of the recently announced forced 10-day migration delay after
Dec 5 and the soft freeze on Jan 5, I would like to move forward with
the proposed changes so the package is in shape for stretch.

Adam, I do not wish to take over poppassd. If you could sponsor one
or two uploads (the latter for work on a systemd unit), that would be
ideal. Otherwise, my offer to help as interim co-maintainer stands.

Regards,
Peter

Bug#843325: ITP: waf -- Tool for configuring, building, and installing projects

[Walter Landry]

Package: wnpp
Severity: wishlist
Owner: Walter Landry 

* Package name: waf
  Version : 1.9.5
  Upstream Author : Thomas Nagy
* URL : http://waf.io/
* License : BSD
  Programming Lang: Python
  Description : Tool for configuring, building, and installing projects

Waf provides functionality similar to autotools (autoconf, automake,
make).  Waf build scripts are also valid python, so build scripts can
easily use functionality from other python libraries to perform
complex actions.

---

I am trying to package waf because it is a build dependency for a few
other packages I would like to package.  I have a potential sponsor
lined up for these, but I have to figure out the waf package first.

There is a special note to packagers because waf tends to be included
in compiled form with software sources.

  https://wiki.debian.org/UpstreamGuide#waf

Doing a quick search

  curl -s https://codesearch.debian.net/results/22044ee2fe5c4350/packages.json 
| jq -r '.Packages[]' | wc -l

shows 39 packages might also benefit from a central installation of
waf.

---

I currently have a setup that creates two packages: waf and
python3-waflib.  That means that the build scripts must be valid
python 3.  If needed, I could also make a python2-waflib.  In that
case, we might want to have different executables for python2 and
python3.

---

Waf has had a somewhat contentious history in Debian.  It was packaged
and then removed upon request by upstream.

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580712

I have had a conversation with upstream (Thomas Nagy).  Nagy still
opposes a generic 'waf' package, but is fine with giving it a specific
version number (e.g. waf-1.9.5).

  https://groups.google.com/d/msg/waf-users/T8f_-HW9_Tw/tuRk0IpIAQAJ

I will defer to the consensus here on what to name the package and any
executables.

Bug#842177: transition: hdf5

[Gilles Filippini]

Control: block -1 by 843040 842815

Emilio Pozuelo Monfort a écrit le 05/11/2016 à 17:29 :
> Control: tags -1 confirmed
> 
> On 04/11/16 14:45, Gilles Filippini wrote:
>> Gilles Filippini a écrit le 02/11/2016 à 19:05 :
>>> Hi,
>>>
>>> Good news: every hdf5 reverse dependency but 8 is now 'binnmu OK'. The
>>> remainder is:
>>> * shogun  FTBFS unrelated to hdf5 - not in testing - #809290
>>> * tessa   FTBFS unrelated to hdf5 - not in testing - #817690
>>> * aster   FTBFS unrelated to hdf5 - not in testing - #837915
>>> * deal.ii BD uninstallable - not in testing
>>> * odinFTBFS unrelated to hdf5 - not in testing - #835746
>>> * libsis-jhdf5-java   #842815 - Very low popcon - No reverse depends
>>>   will need some more time because part of this java wrapper library
>>>   is now shipped with the HDF5 source tree
>>> * yorick-hdf5 #842817 - temporary fix uploaded to experimental
>>> * pytablesalmost done - FTBFS on big endian arches
>>>
>>> IMO the only showstopper is now pytables, which will hopefully resolve
>>> in the coming days.
>>
>> Update:
>> * yorick-hdf5 #842817 - final fix uploaded to experimental
>> * pytablesAffected by #843040 - Tested patch pending
>>
>> There isn't any blocker left but libsis-jhdf5-java which has a very low
>> popcon and no reverse dependencies. Can we agree for a transition slot
>> before the freeze?
> 
> Yes, this is looking very good, so I'm acking it. But please don't upload just
> yet, I'll give you the go in a few days when things are a bit calmer (there 
> are
> just too many transitions at the moment).
> 
> And please mark any remaining bugs as blocking this one.

Done, excepted for the 'not in testing' ones. Unless you'd want these
marked as well?

Thx,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#842939: I had done the RFP and some more analysis

[shirish शिरीष]

Hi all,

Blame me as I had done the RFP for the package but then I was
influenced by statements of FSF,  HTTPS Everywhere and I think even
the Guardian Project which had endorsed the add-on. When such big
hitters of FOSS and free software values endorse something, we are
bound to think it's alright. At least that is what my memory
tells/shares with me. Even on mozilla addons page it used be one of
the top ones in privacy category/section for privacy utilities.

Anyways, found this (thankfully in English this time)

https://gist.github.com/Rob--W/bda5f28a0ac3b877780c6665bbed2e1b

While I'm not a programmer and hence don't understand the
implications, I do understand the right thing is to purge the add-on
and I have done that for the moment.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#835070: vorbis-tools: ogg123 segfaults on playing ogg files

[Petter Reinholdtsen]

Hm, I was reminded of this issue when I read
http://www.bityard.org/blog/2016/08/05/debugging_segfaults_open-iscsi_iscsiuio_intel_broadwell
 >.
Could it be the same issue?

-- 
Happy hacking
Petter Reinholdtsen

Bug#843324: libc recently more aggressive about pthread locks in stable ?

[Ian Jackson]

Ian Jackson writes ("libc recently more aggressive about pthread locks in 
stable ?"):
> I have just been debugging a ghostscript segfault on jessie amd64.
...
> I recently encountered what seems to be a similar bug in ogg123 in
> stable.  #842796.
> 
> Has something changed in jessie's libc recently ?  I find it difficult
> to imagine that these bugs would have been missed earlier during the
> life of jessie.
> 
> I will try to make a patch to fix ghostscript, or at least file a
> proper bug.  But, if there was a libc change, would it be possible to
> revert it or make some kind of workaround ?

FYI, the ghostscript bug, with patch for jessie, is #843324.
sid's ghostscript is fine and I think stretch's is too.

Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#843268: jessie-pu: package nettle/2.7.1-5+deb8u2

[Adam D. Barratt]

On Sat, 2016-11-05 at 18:07 +0100, Magnus Holmgren wrote:
> Here is a debdiff for a proposed upload to address CVE-2016-6489 ("RSA code 
> is 
> vulnerable to cache sharing related attacks") in jessie, which the Security 
> Team thinks should be done but which doesn't warrant a DSA.

It appears that you've uploaded already; it would have been appreciated
if you'd waited for an ack.

For one thing, I'd have at least queried:

- -- Magnus Holmgren   Sat, 06 Feb 2016 20:01:37 +0100
+ -- Magnus Holmgren   Tue, 09 Feb 2016 20:57:42 +0100

Regards,

Adam

Bug#843324: ghostscript crashes on some machines, much of the time

[Ian Jackson]

Package: ghostscript
Version: 9.06~dfsg-2+deb8u4
Tags: patch
Severity: serious
Control: fixed -1 9.19~dfsg-3.1

On some machines, with recent jessie libcs, on amd64 Linux (at least),
ghostscript crashes because it unlocks an already-unlocked pthread
DEFAULT mutex.  (Well, actually, in my test case, it locks it twice,
and then unlocks it twice.)

This is the upstream bug:
  http://bugs.ghostscript.com/show_bug.cgi?id=695862

It can be fixed by cherry-picking the corresponding upstream patch,
  444e0bf9c43b "Bug 695862: use PTHREAD_MUTEX_RECURSIVE(_NP) if available"

Please find attached a suitable backport.  I threw away the changes to
the configure and build system.  We do not need these because we
always have recursive mutexes available: so instead, I just definen
the appropriate preprocessor symbol in the file which uses it.

Thanks.

Ian.

>From f96eb410d8c1b6f7660638c39c9add82be158d94 Mon Sep 17 00:00:00 2001
From: Chris Liddell 
Date: Mon, 16 Mar 2015 12:52:49 +
Subject: [PATCH] Bug 695862: use PTHREAD_MUTEX_RECURSIVE(_NP) if available

or properly emulate recursive mutexes ourselves.

No cluster differences

(cherry picked from commit 444e0bf9c43bae0261660e6318ba0e514c18d41e)

Conflicts:
config.mak.in
configure.ac
gs/Makefile.in
gs/configure.ac

[ Dropped all the buildsystem and configure changes.  Instead,
  we just hardcode GS_RECURSIVE_MUTEXATTR since it will
  always be available on Debian. -iwj ]
---
 base/gp_psync.c | 71 +++--
 1 file changed, 59 insertions(+), 12 deletions(-)

diff --git a/base/gp_psync.c b/base/gp_psync.c
index 60f6977..d09871b 100644
--- a/base/gp_psync.c
+++ b/base/gp_psync.c
@@ -13,6 +13,7 @@
CA  94903, U.S.A., +1(415)492-9861, for further information.
 */
 
+#define GS_RECURSIVE_MUTEXATTR 1 /* always, on Debian */
 
 /* POSIX pthreads threads / semaphore / monitor implementation */
 #include "std.h"
@@ -128,13 +129,20 @@ gp_semaphore_signal(gp_semaphore * sema)
 /* Monitor supports enter/leave semantics */
 
 /*
- * We need PTHREAD_MUTEX_RECURSIVE behavior, but this isn't totally portable
- * so we implement it in a more portable fashion, keeping track of the
- * owner thread using 'pthread_self()'
+ * We need PTHREAD_MUTEX_RECURSIVE behavior, but this isn't
+ * supported on all pthread platforms, so if it's available
+ * we'll use it, otherwise we'll emulate it.
+ * GS_RECURSIVE_MUTEXATTR is set by the configure script
+ * on Unix-like machines to the attribute setting for
+ * PTHREAD_MUTEX_RECURSIVE - on linux this is usually
+ * PTHREAD_MUTEX_RECURSIVE_NP
  */
 typedef struct gp_pthread_recursive_s {
 pthread_mutex_t mutex; /* actual mutex */
+#ifndef GS_RECURSIVE_MUTEXATTR
 pthread_t  self_id;/* owner */
+int lcount;
+#endif
 } gp_pthread_recursive_t;
 
 uint
@@ -148,12 +156,32 @@ gp_monitor_open(gp_monitor * mona)
 {
 pthread_mutex_t *mon;
 int scode;
+pthread_mutexattr_t attr;
+pthread_mutexattr_t *attrp = NULL;
 
 if (!mona)
 return -1; /* monitors are not movable */
-mon = &((gp_pthread_recursive_t *)mona)->mutex;
+
+
+#ifdef GS_RECURSIVE_MUTEXATTR
+attrp = 
+scode = pthread_mutexattr_init(attrp);
+if (scode < 0) goto done;
+
+scode = pthread_mutexattr_settype(attrp, GS_RECURSIVE_MUTEXATTR);
+if (scode < 0) {
+goto done;
+}
+#else 
 ((gp_pthread_recursive_t *)mona)->self_id = 0; /* Not valid unless 
mutex is locked */
-scode = pthread_mutex_init(mon, NULL);
+((gp_pthread_recursive_t *)mona)->lcount = 0;
+#endif
+
+mon = &((gp_pthread_recursive_t *)mona)->mutex;
+scode = pthread_mutex_init(mon, attrp);
+if (attrp)
+(void)pthread_mutexattr_destroy(attrp);
+done:
 return SEM_ERROR_CODE(scode);
 }
 
@@ -173,29 +201,48 @@ gp_monitor_enter(gp_monitor * mona)
 pthread_mutex_t * const mon = (pthread_mutex_t *)mona;
 int scode;
 
+#ifdef GS_RECURSIVE_MUTEXATTR
+scode = pthread_mutex_lock(mon);
+#else
 if ((scode = pthread_mutex_trylock(mon)) == 0) {
 ((gp_pthread_recursive_t *)mona)->self_id = pthread_self();
-return SEM_ERROR_CODE(scode);
+((gp_pthread_recursive_t *)mona)->lcount++;
 } else {
-if (pthread_equal(pthread_self(),((gp_pthread_recursive_t 
*)mona)->self_id))
-return 0;
+if (pthread_equal(pthread_self(),((gp_pthread_recursive_t 
*)mona)->self_id)) {
+((gp_pthread_recursive_t *)mona)->lcount++;
+scode = 0;
+}
 else {
 /* we were not the owner, wait */
 scode = pthread_mutex_lock(mon);
 ((gp_pthread_recursive_t *)mona)->self_id = pthread_self();
-return SEM_ERROR_CODE(scode);
+((gp_pthread_recursive_t *)mona)->lcount++;
 }
 }
+#endif
+return SEM_ERROR_CODE(scode);
 }
 
 int
 gp_monitor_leave(gp_monitor * mona)
 {
 

Bug#843173: libfaad-dev: Implicit SBR detection via AudioSpecificConfig fails when char is signed

[Fabian Greffrath]

Hi again,

will it help if we explicitely cast the (-1) to char in the two
occasions where it is used for sbr_present_flag?

 - Fabian
diff --git a/libfaad/mp4.c b/libfaad/mp4.c
index 72b2af6..14e607a 100644
--- a/libfaad/mp4.c
+++ b/libfaad/mp4.c
@@ -174,7 +174,7 @@ int8_t AudioSpecificConfigFromBitfile(bitfile *ld,
 #endif
 
 #ifdef SBR_DEC
-mp4ASC->sbr_present_flag = -1;
+mp4ASC->sbr_present_flag = (char)-1;
 if (mp4ASC->objectTypeIndex == 5)
 {
 uint8_t tmp;
@@ -276,7 +276,7 @@ int8_t AudioSpecificConfigFromBitfile(bitfile *ld,
 
 /* no SBR signalled, this could mean either implicit signalling or no SBR in this file */
 /* MPEG specification states: assume SBR on files with samplerate <= 24000 Hz */
-if (mp4ASC->sbr_present_flag == -1)
+if (mp4ASC->sbr_present_flag == (char)-1)
 {
 if (mp4ASC->samplingFrequency <= 24000)
 {


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

Bug#801498: rakudo: Native libraries and paths

[Tobias Leich]

Am 05.11.2016 um 20:20 schrieb Dominique Dumont:

On Thursday, 3 November 2016 10:07:34 CET Tobias Leich wrote:

It might want to look like this now:

MoarVM/build/setup.pm:128:ldrpath=> '-Wl,-rpath,"/@libdir@"
-Wl,-rpath,"@prefix@/share/perl6/site/lib"
-Wl,-rpath,"/home/gregoa/.perl6/2015.09/lib"',

That is not possible in Debian context. moar and rakudo are compiled on Debian
build server: a directory belonging to a user cannot be added in rpath (which
would also be a security hole and against debian policy)
Sure, this was just meant for the reporter here to try and workaround 
the issue. It was not meant as a solution at all.

The proper fix would be that Linenoise installs the liblinenoise.so in a
known directory. Though that might not be an easy one.

This would require to run the install phase as root to install linenoise.so in
a known directory (why not @prefix@/share/perl6/site/lib ?).
Yes, that's one solution, and probably *the* one that'll make it into 
panda/linenoise. I think the best way would be to open an issue in the 
linenoise perl module (github), and close this issue here since it is 
not directly moarvm's or rakudo's fault.

Bug#843246: git: unable to install due to missing deps

[Anders Kaseorg]

Control: tags -1 moreinfo

On Sat, 5 Nov 2016, vincent wrote:
>  The following packages have unmet dependencies:
>   git : Depends: git-man (< 1:2.9.3-.) but 1:2.10.2-1 is to be installed
>   N: Ignoring file '50unattended-upgrades.ucf-dist' in directory
>   '/etc/apt/apt.conf.d/' as it has an invalid filename extension
>   E: Unable to correct problems, you have held broken packages.

I cannot reproduce this; git installs fine for me on stretch amd64.  Your 
error suggests that you are installing git 1:2.9.3-1, but that has not 
been the current version in stretch for a week now.  Is your archive 
mirror out of sync?  What is the output of ‘apt-cache policy git git-man’?  
Can you retry the installation with aptitude, which often gives more 
useful error messages?

Anders

Bug#843073: dpkg-shlibdeps: broken on i386 with merged /usr

[Michael Biebl]

Control: severity -1 serious

On Thu, 03 Nov 2016 13:14:35 -0400 Ross Vandegrift  wrote:
> Package: dpkg-dev
> Version: 1.18.10
> Severity: normal
> 
> Dear Maintainer,
> 
> debootstrap 1.0.85 began deploying with --merged-usr by default in
> response to #839046.  On i386, this causes dpkg-shlibdeps to fail on
> (some?) shared libraries.
> 
> An example error:
> dpkg-shlibdeps: error: no dependency information found for 
> /usr/lib/ld-linux.so.2 (used by 
> debian/libevas1/usr/lib/i386-linux-gnu/libevas.so.1.18.2)
> Hint: check if the library actually comes from a package.
> 
> In this case:
> # ls -l /usr/lib/ld-linux.so.2
> lrwxrwxrwx 1 root root 25 Oct 18 21:10 /usr/lib/ld-linux.so.2 -> 
> i386-linux-gnu/ld-2.24.so
> 
> To workaround with a pbuilder chroot, when creating, supply:
>   --debootstrapopts --no-merged-usr.
> 
> I'm not sure if this is a debootstrap or dpkg-dev issue.  Apologies in
> advance if I'm incorrect.  The same underlying problem was reported
> against usrmerge in #810499.  For some reason, debootstrap does not
> create this symlink on amd64.
> 

As this breaks packages to build successfully, I'm bumping this to RC.
E.g. I'm unable to successfully build systemd in a freshly created
chroot on i386. I suspect once the buildds update their chroot, it will
affect a lot more packages.

Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#843153: [Pkg-samba-maint] Bug#843153: Provide a means to wake-up (reconnect) an existing share

[Mathieu Parent]

Control: reassign -1 src:linux 4.8.5-1
Control: affects -1 cifs-utils
Control: tags -1 + upstream

2016-11-04 12:13 GMT+01:00 martin f krafft :
> Package: cifs-utils
> Version: 2:6.6-1
> Severity: wishlist

hello Martin,

> After a laptop suspend, SMB sessions are usually disconnected on the
> server, and even the client will have a hard time just resuming.

This is most probably kernel-side.

> This will either lead to soft-errors or hard-blocks, until on the
> client, eventually, the kernel states

eventually? Meaning not always?

>   kernel: [27763.247021] CIFS VFS: Server samba.example.org has not
>   responded in 120 seconds. Reconnecting…
>
> and reconnects.
>
> One way around this is to lazy-umount the shares, and to remount
> them, but that's not easily done with e.g. libpam-mount, and it also
> doesn't solve the issue with open inodes.

Does mount -o remount $path works?

>
> I don't really want to shorten the 120 seconds (and I wouldn't know
> how, there seems to be no mount option),

120 comes from echo_interval [1] which looks undocumented.

[1] http://sources.debian.net/src/linux/4.8.5-1/fs/cifs/connect.c/?hl=496#L496

> but what would be great
> would be a way to prod the share and make it wake-up (i.e.
> reconnect), e.g.
>
>   mount.cifs --resume -a

Again, have you tried mount -o remount?

> which would immediately cause a reconnection, not only after 120
> seconds. This could then be executed by systemd for the resume
> target…

Looking at the NFS kernel code, I don't see any resume handling. I
don't know if it's affected too.

Regards

-- 
Mathieu

Bug#843310: systemd-journald: user service logs are not available to normal users unless persistent Storage is used.

[Michael Biebl]

Hi

Am 05.11.2016 um 20:16 schrieb Daniel Kahn Gillmor:
> Package: systemd
> Version: 232-1
> Severity: normal
> 
> Dear systemd and journald maintainers,
> 
> User services generate output and that output is logged by the user's
> systemd session manager. journalctl(1) says:
> 
>All users are granted access to their private per-user journals.
> 


Please file that issue upstream. Either the documentation needs to be
fixed or the software.
In either case, it isn't a Debian specific issue.

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



signature.asc
Description: OpenPGP digital signature

Bug#822337: upgrade from libfreeradius-client to radcli

[Jan Wagner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am 03.11.2016 um 00:51 schrieb Jan Wagner:
> monitoring-plugins configure tries to detect the radius library
> which can't be detected, with libradcli-dev (and libradcli4)
> installed:
> 
> configure: WARNING: Skipping radius plugin configure: WARNING:
> install radius libs to compile this plugin (see REQUIREMENTS).

After patching this issue
(https://github.com/waja/monitoring-plugins/commits/radcli) the
problem seems, it's not so compatible like it seems
(https://travis-ci.org/waja/monitoring-plugins/builds/173546204#L3533-L3
548):

check_radius.c:95:1: error: unknown type name ‘ENV’
 ENV *env = NULL;
 ^
check_radius.c: In function ‘main’:
check_radius.c:205:2: error: too few arguments to function
‘rc_send_server’
  result = my_rc_send_server (, msg);
  ^
In file included from check_radius.c:40:0:
/usr/include/radcli/radcli.h:651:5: note: declared here
 int rc_send_server (rc_handle *rh, SEND_DATA *data, char *msg,
 ^
Seems like radcli removed some API stuff:

https://github.com/radcli/radcli/commit/9f2da1ca9dade4bb6fb318d66f80badd
61ed1830

Cheers, Jan.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYHjY6AAoJEAxwVXtaBlE+LxgQALumm8oGIk6Jb4UQhBMf/913
0EW0L2RLn1qUsPCKEGC+Z7qPa/Qoc5wdSxX6sZ9CTpGofuei27L0AcdbDqy45aBD
xZu6yAnq7DHirs7GuCtmXUA1dajk9ZpXRwA82jV/9Hf7OWlxVqeAQMg8gagj/W8V
1tIwL+QMFX+4rwQuXVJb0fhQgurxMg/5P3/Dg0aaGePQQHv4L06i4z/aglYF2kqM
tctlEok5ju5g3a0nI4bSrQUxXe4WoUO3xR+12VyWoVBlSfuy2Z8LW0GoeFO0veWK
W0IGJCO26qpPWsRIzE+9EOxKTt4mRWPqkFR9WGi/p+z/xzxuW1mCb/yB07Sjhitn
XnlgloxpPgJcHx3Gk19qKBwu0TlzdxZpYukssNIAIwod9hCXbtnTXi39oiEO6DS6
0IaBhVI69yEwVS2RYZUeYiw9SKBJUxPLNQCyj2AJ7q00kiOWOA5OMDtM1MpwP3yQ
yst/M40jfOr90rfMzmXlky2SDVp0a0nzmfwBf3O0a5WAs5pHeBs9Vh7FW4FJXa32
PaZk7Yn57AQDxB2MuEj+WI9KAlr2OJb6yWc1oCrpaXGbChQwQIRi5d91yKUF223y
DSCXUp6Ets8KOZxFpV6jBscuP40usBe6x1TNLfYaJolOT55ettUQG9JyJProivbm
4SoRn0PNBEZHMMu+xwpB
=y7O8
-END PGP SIGNATURE-

Bug#843323: [linuxcnc] Crash using Mach3 imported configuration

[Marco Righi]

Package: linuxcnc
Version: 1:2.7.7
Severity: normal

--- Please enter the report below this line. ---
Print file information:
RUN_IN_PLACE=no
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/usr/bin
LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/usr/realtime-3.4-9-rtai-686-pae/modules/linuxcnc
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/usr/share/linuxcnc/tcl/msgs
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.5
LINUXCNC - 2.7.7
Machine configuration directory is
'/media/data/users/home/marco/linuxcnc/configs/Mach3Mill' Machine
configuration file is 'Mach3Mill.ini'
INIFILE=/media/data/users/home/marco/linuxcnc/configs/Mach3Mill/Mach3Mill.ini
PARAMETER_FILE=linuxcnc.var TASK=milltask
HALUI=
DISPLAY=axis
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
Found file(REL): ./Mach3Mill.hal
Shutting down and cleaning up LinuxCNC...
Killing task linuxcncsvr, PID=6238
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
sim_hardware.hal:30: parameter or pin
'parport.0.pin-02-out-invert-fake' not found 6238
  PID TTY  STAT   TIME COMMAND
Stopping realtime threads
Unloading hal components

Kernel message information:
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.4-9-rtai-686-pae (Debian
3.4.55-4linuxcnc) () (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP
PREEMPT Debian 3.4.55-4linuxcnc [0.00] Disabled fast string
operations [0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009fc00 (usable)
[0.00]  BIOS-e820: 0009fc00 - 000a
(reserved) [0.00]  BIOS-e820: 000e -
0010 (reserved) [0.00]  BIOS-e820: 0010
- 3ffd (usable) [0.00]  BIOS-e820: 3ffd
- 3fff0c00 (reserved) [0.00]  BIOS-e820:
3fff0c00 - 3fffc000 (ACPI NVS) [0.00]
BIOS-e820: 3fffc000 - 4000 (reserved)
[0.00] Notice: NX (Execute Disable) protection missing in CPU!
[0.00] SMBIOS 2.3 present. [0.00] DMI: Hewlett-Packard
Compaq nx7010 (DU394T#ABZ)  /0860, BIOS 68BAL Ver. F.55 07/14/2005
[0.00] e820 update range:  - 0001
(usable) ==> (reserved) [0.00] e820 remove range:
000a - 0010 (usable) [0.00] last_pfn =
0x3ffd0 max_arch_pfn = 0x10 [0.00] MTRR default type:
uncachable [0.00] MTRR fixed ranges enabled: [0.00]
0-9 write-back [0.00]   A-B uncachable
[0.00]   C-CDFFF write-protect [0.00]   CE000-E
uncachable [0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask FC000 write-back
[0.00]   1 disabled
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] PAT not supported by CPU.
[0.00] initial memory mapped : 0 - 0180
[0.00] Base memory trampoline at [c009b000] 9b000 size 16384
[0.00] init_memory_mapping: -377fe000
[0.00]  00 - 40 page 4k
[0.00]  40 - 003740 page 2M
[0.00]  003740 - 00377fe000 page 4k
[0.00] kernel direct mapping tables up to 0x377fdfff @ [mem
0x017f8000-0x017f] [0.00] RAMDISK: 3652c000 - 3728e000
[0.00] ACPI: RSDP 000f6560 00014 (v00 COMPAQ)
[0.00] ACPI: RSDT 3fff0c84 00028 (v01 HP CPQ0860  14070520
CPQ  0001) [0.00] ACPI: FACP 3fff0c00 00084 (v02 HP
CPQ0860  0002 CPQ  0001) [0.00] ACPI: DSDT 3fff0cac
04F8C (v01 HP   nx7000 0001 MSFT 010E) [0.00] ACPI:
FACS 3fffbe80 00040 [0.00] 135MB HIGHMEM available.
[0.00] 887MB LOWMEM available.
[0.00]   mapped low ram: 0 - 377fe000
[0.00]   low ram: 0 - 377fe000
[0.00] Zone PFN ranges:
[0.00]   DMA  0x0010 -> 0x1000
[0.00]   Normal   0x1000 -> 0x000377fe
[0.00]   HighMem  0x000377fe -> 0x0003ffd0
[0.00] Movable zone start PFN for each node
[0.00] Early memory PFN ranges
[0.00] 0: 0x0010 -> 0x009f
[0.00] 0: 0x0100 -> 0x0003ffd0
[0.00] On node 0 totalpages: 261983
[0.00] free_area_init_node: node 0, pgdat c1498a00,
node_mem_map f5d2c200 [0.00]   DMA zone: 32 pages used for
memmap [0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 3951 pages, LIFO batch:0
[0.00]   Normal zone: 1744 pages used for memmap
[0.00]   Normal zone: 221486 pages, LIFO batch:31
[

Bug#842796: libc recently more aggressive about pthread locks in stable ?

[Christian Seiler]

On 11/05/2016 08:13 PM, Ian Jackson wrote:
> I have just been debugging a ghostscript segfault on jessie amd64.
> 
> Looking at the code, I think that gs in jessie is plainly violating
> the rules about the use of pthread locks.  On my partner's machine,
> this makes it segfault on termination (with some input files, at
> least).  On my machine it works just fine.  The code in sid is better.
> 
> I recently encountered what seems to be a similar bug in ogg123 in
> stable.  #842796.
> 
> Has something changed in jessie's libc recently ?  I find it difficult
> to imagine that these bugs would have been missed earlier during the
> life of jessie.

Recently Frank Fegert discovered a problem with locking in open-iscsi
that only occurs on new hardware. The code previously was wrong, but
earlier CPUs were more forgiving when it came to this error and it
couldn't be triggered.

Frank wrote about the problem in his blog in great detail:
http://www.bityard.org/blog/2016/08/05/debugging_segfaults_open-iscsi_iscsiuio_intel_broadwell

I haven't looked in detail at your problem, but I could easily
imagine that the problem you're experiencing with other packages is
similar, especially since you mentioned migrating to new hardware.

Hope that helps.

Regards,
Christian

PS: In case someone was wondering: the specific problem with
open-iscsi is now fixed in sid, testing and jessie-backports; jessie
is not affected because we didn't yet build the component with the
issue there.

Bug#843173: libfaad-dev: Implicit SBR detection via AudioSpecificConfig fails when char is signed

[Fabian Greffrath]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Stefan,

thanks for the bug report!

Did you mean to write "fails when char is unsigned" in the subject
line?

Am Freitag, den 04.11.2016, 16:18 +0100 schrieb Stefan Pöschel:
> One way to fix this is to make the struct variable sbr_present_flag
> signed.
> Another way is to enforce signed char by compiling FAAD2 with
> -fsigned-char.

I see that the fix is rather trivial, but wouldn't it introduce an ABI
(not API) break?

 - Fabian
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYHjQrAAoJEMvqjpcMzVnfgkoQAOMWHhbkhl5QJ4c+O3EEmtBQ
Doyz8HezqGLWud0PmHf9YOO7EK+gQusqN/3M/T/Qpe0/xbRE35ZiDO1kxNmiZk0O
OPdrihKkSF5LWbYqJE3QgZ9gRcFtWx0OB4YeVkjoCTi+bhEPDwPrzxLQtAo2sqtB
Sf39DsK6++zQfQNAzyxRZyVw6oKg9B9XuDblFcNUD16MgOCxlVlTswVR2iCD0+Pd
299geikSfG292LrFGiZD8PBE9S961mt4QXDAtcEdiznKrI6oZRpyShOPWWQPyqqm
x6y/MlatAUeBEXfngRibdxyIT23edZUPAhyfvuhD0blgB5cYYYHZ/vKnXZjfEurA
lEpor/KZA9QueKt31nLN5cpFPOGN5DtQX9Sy7AG9Cthcqyky9BWK2FnEEd8YFsYL
NgJa4kbFEYbOl1UnBbSarQz8g69tXcfk2gshzJvU/+SaQKNEsyBrLoWNen9gkYEd
c+3z0TPBAXVNw/MNA8LASapRPU6SLT7liqnb+RkdNB8Qnj+HLkwtWQyq67o+O9de
UvU2jXkwCK4tTSjM++fMRKJFSAV7aCFQR4KeGrvfPDz9E89rkzPwPeI6uUnGSaND
hYnYBGAPLZ37eDYA2uUkSf0ShGJn/OGOcyIyGji9XJyeWBKfewBG3KGO/JpNsSHB
Aw1oAfQjVWnAoWuGfSal
=wauB
-END PGP SIGNATURE-

Bug#843322: libproxy-dev: libproxy development moved to github, new release

[François Revol]

Package: libproxy-dev
Version: 0.4.11-5
Severity: wishlist

Dear Maintainer,
when looking up libproxy, I noticed the debian package still refers to
the code.google homepage, while they seem to have moved to github:

https://github.com/libproxy/libproxy

There seems to be a 0.4.13 release already there:

https://github.com/libproxy/libproxy/releases

Thanks,
François.

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

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

Versions of packages libproxy-dev depends on:
ii  libproxy1v5  0.4.11-5

libproxy-dev recommends no packages.

libproxy-dev suggests no packages.

-- no debconf information

Bug#840492: sexplib310: no longer builds libsexplib-camlp4-dev

[Mehdi Dogguy]

Control: clone 840492 -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11
Control: notfound 840492 sexplib310/113.33.03-3
Control: reassign -1 pa-structural-sexp
Control: reassign -2 janest-core
Control: reassign -3 ocaml-ipaddr
Control: reassign -4 ocaml-re2
Control: reassign -5 janest-core-kernel
Control: reassign -6 pa-test
Control: reassign -7 custom-printf
Control: reassign -8 typerep
Control: reassign -9 otags
Control: reassign -10 janest-core-extended
Control: reassign -11 ocaml-textutils
Control: retitle -1 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -2 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -3 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -4 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -5 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -6 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -7 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -8 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -9 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -10 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -11 FTBFS: libsexplib-camlp4-dev is no longer available
Control: close 840492

On Wed, Oct 12, 2016 at 09:59:23AM +0200, Emilio Pozuelo Monfort 
 wrote:
> Please file bugs against those (or fix them directly if you maintain
> them) or make libsexplib-ocaml-dev provide libsexplib-camlp4-dev.
> 

libsexplib-camlp4-dev is gone for good. So, there is nothing to fix in sexplib
and reverse dependencies have to be fixed. Hence, closing this bugreport
and opening required new bugreports.

Regards,

-- 
Mehdi Dogguy

Bug#801498: rakudo: Native libraries and paths

[Dominique Dumont]

On Thursday, 3 November 2016 10:07:34 CET Tobias Leich wrote:
> It might want to look like this now:
> 
> MoarVM/build/setup.pm:128:ldrpath=> '-Wl,-rpath,"/@libdir@" 
> -Wl,-rpath,"@prefix@/share/perl6/site/lib" 
> -Wl,-rpath,"/home/gregoa/.perl6/2015.09/lib"',

That is not possible in Debian context. moar and rakudo are compiled on Debian 
build server: a directory belonging to a user cannot be added in rpath (which 
would also be a security hole and against debian policy)

> The proper fix would be that Linenoise installs the liblinenoise.so in a 
> known directory. Though that might not be an easy one.

This would require to run the install phase as root to install linenoise.so in
a known directory (why not @prefix@/share/perl6/site/lib ?).

All the best.

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#843310: systemd-journald: user service logs are not available to normal users unless persistent Storage is used.

[Daniel Kahn Gillmor]

Package: systemd
Version: 232-1
Severity: normal

Dear systemd and journald maintainers,

User services generate output and that output is logged by the user's
systemd session manager. journalctl(1) says:

   All users are granted access to their private per-user journals.

However, this isn't the case for volatile logs -- it's only true if
/var/log/journal exists and is used by the journal daemon
(journal.conf has Storage= set to either "persistent" or "auto").  As
noted in systemd-journald(8), access to files in /var/log/journal is
controlled by filesystem permissions, and per-user journal files are
given an ACL that allows reading by the user in question.

But the files in /run/log/journal (including .) are owned
root:systemd-journal, and only have an acl permitting group reading by
group "adm".

if /var/log/journal doesn't exist, then the files in /run/log/journal
are named like:


/run/log/journal/6051cddb073148558d78ef88b325d68c/system@69e51cd1f22d4569aee1f96c1219d41d-08cc-0005409149915123.journal

/run/log/journal/6051cddb073148558d78ef88b325d68c/system@69e51cd1f22d4569aee1f96c1219d41d-0434-000540908e2a4975.journal

but /run/log/journal is removed once /var/log/journal exists, and
/var/log/journal files are named like this:

/var/log/journal/6051cddb073148558d78ef88b325d68c/user-1000.journal
/var/log/journal/6051cddb073148558d78ef88b325d68c/system.journal

Without /var/log/journal existing, with a user with no special
membership in adm or systemd-journal, i see no log info:

---
dkg@sid:~$ groups
dkg
dkg@sid:~$ journalctl --user-unit gpg-agent | tail
Hint: You are currently not seeing messages from other users and the system.
  Users in the 'systemd-journal' group can see all messages. Pass -q to
  turn off this notice.
No journal files were opened due to insufficient permissions.
dkg@sid:~$ systemctl status --user gpg-agent | cat
● gpg-agent.service - GnuPG cryptographic agent and passphrase cache
   Loaded: loaded (/usr/lib/systemd/user/gpg-agent.service; static; vendor 
preset: enabled)
   Active: active (running) since Sat 2016-11-05 12:47:26 EDT; 18min ago
 Docs: man:gpg-agent(1)
 Main PID: 836 (gpg-agent)
   CGroup: /user.slice/user-1000.slice/user@1000.service/gpg-agent.service
   └─836 /usr/bin/gpg-agent --supervised
dkg@sid:~$ 
---

If you want to try to replicate, this is with the stock gpg-agent
user service from the gnupg-agent package, version 2.1.15-8, with the
following command run in bash as root before regular user login:

# systemctl --user --global enable gpg-agent{,-ssh,-extra,-browser}.socket

And the user has the following two lines in ~/.gnupg/gpg-agent.conf:

debug-level guru
debug-pinentry

---

fwiw, strace can see journalctl trying to access files in /run/log
before i tries to look in /var/log/journal, but gets EACCESS
(Permission denied) errors (as one would expect from the permissions
on it).

Shouldn't systemd-journald manage its files in /run/log/journal with
the same approach and permissions that it uses for files in
/var/log/journal?

Regards,

--dkg

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3
ii  libapparmor12.10.95-5
ii  libaudit1   1:2.6.7-1
ii  libblkid1   2.28.2-1
ii  libc6   2.24-5
ii  libcap2 1:2.25-1
ii  libcryptsetup4  2:1.7.3-1
ii  libgcrypt20 1.7.3-2
ii  libgpg-error0   1.24-1
ii  libidn111.33-1
ii  libip4tc0   1.6.0-4
ii  libkmod223-1
ii  liblzma55.2.2-1.2
ii  libmount1   2.28.2-1
ii  libpam0g1.1.8-3.3
ii  libseccomp2 2.3.1-2
ii  libselinux1 2.6-1
ii  libsystemd0 232-1
ii  mount   2.28.2-1
ii  util-linux  2.28.2-1

Versions of packages systemd recommends:
ii  dbus1.10.12-1
ii  libpam-systemd  232-1

Versions of packages systemd suggests:
ii  policykit-10.105-17
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.125
ii  udev 232-1

-- no debconf information

Bug#843245: distorm3: please make the build reproducible

[Eriberto]

Thanks a lot Reiner. And thanks for your effort about reproducible builds.

Cheers,

Eriberto


2016-11-05 11:12 GMT-02:00 Reiner Herrmann :
> Source: distorm3
> Version: 3.3.4-1
> Severity: wishlist
> Tags: patch upstream
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: fileordering
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>
> Hi!
>
> While working on the "reproducible builds" effort [1], we have noticed
> that distorm3 could not be built reproducibly.
> During build objects are linked in non-deterministic order.
>
> The attached patch fixes this by sorting the list of source files.
>
> Regards,
>  Reiner
>
> [1]: https://wiki.debian.org/ReproducibleBuilds