Bug#882140: python3-django-captcha: Django 2.0 support

[Brian May]

On Sun, Nov 19, 2017 at 10:25:49AM -0500, James Valleroy wrote:
> Package: python3-django-captcha
> Version: 0.5.5-1
> Severity: normal

I believe 0.5.6 should fix this, now in git.

Unfortunately, it depends on django-ranged-response, which isn't yet in
Debian.

https://pypi.python.org/pypi/django-ranged-response/0.2.0
-- 
Brian May 

Bug#884043: obfsproxy: Ship an AppArmor profile again

[intrigeri]

Hi pkg-privacy-tools & fteproxy maintainers!

Nicolas Braud-Santoni:
> On Mon, Dec 11, 2017 at 07:21:50AM +0100, intrigeri wrote:
>> I suggest first checking why we're still including obfsproxy:
>> I suspect most of the reverse-dependency relationships might be
>> obsolete nowadays (the last upstream version was released 3 years ago,
>> and AFAIK obfs4proxy is the future).

> Thanks, that's a great point:
> - tor and ooniprobe suggest obfsproxy, and that should be dropped;
>   ooniprobe should suggest obfs4proxy instead.

Indeed since upstream commit e6035577f33b8d34a10117bf30bffda45719896a
(first included in v2.1.0), ooniprobe's README.rst recommends
installing obfs4proxy instead of obfsproxy.

Nicolas, do you want to file bugs recommending these two changes?

> - fteproxy hard-depends on obfsproxy, but uses it as a library so
>   AppArmor confinement doesn't matter there.

OK, so I've tagged #884043 wontfix.

> Regarding fteproxy, it was listed at 0 recent uses (and 3 installs
> in total).

Dear fteproxy maintainers, if you ever decide that fteproxy should not
be in the next Debian stable release, please let us know: this would
allow us to also drop obfsproxy which is mostly dead upstream. In the
meantime, let's keep obfsproxy in the archive as long as it's
maintainable and fteproxy wants it :)

Cheers,
-- 
intrigeri

Bug#883938: linux-image-3.16.0-4-amd64: Kernel panic on boot after upgrading to debian 8.10 kernel 3.16.51

[Salvatore Bonaccorso]

On Mon, Dec 11, 2017 at 11:10:42PM +0100, Salvatore Bonaccorso wrote:
> Hi Ben,
> 
> On Mon, Dec 11, 2017 at 09:47:49PM +, Ben Hutchings wrote:
> > On Mon, 2017-12-11 at 21:29 +, Ben Hutchings wrote:
> > > There were several commits interspersed with sched/topology fixes
> > > upstream that I thought were cleanup and therefore didn't backport to
> > > the 3.16 stable branch.  Now I suspect that at least some of them are
> > > needed.
> > > 
> > > I'm attaching backports of 3 of the commits that I left out.  Can you
> > > test whether they fix the regression for you?
> 
> I built v3.16.51 with the three patches on top, and looks good I have
> no  seen any further problems with those.

To confirm, I now as well bootet two affected systems with you
testkernel containg the patches and they boot now.

Regards,
Salvatore

Bug#884094: register_key_type symbol missing, ABI counter not incremented

[Sergio Gelato]

* Ben Hutchings [2017-12-11 15:59:38 +]:
> I don't think there's any good way to deal with this
> now, other than to force a rebuild of the module.

Was afraid of that. It's what I did, of course, but it complicates the rollout.
(I ran "dkms remove openafs/1.6.20 -k $(uname -r); dkms install 
openafs/1.6.20".)

Will there be a jessie backport of that kernel, to replace 4.9.51-1~bpo8+1 ?

Bug#884115: Ioslides inside rmarkdown has no license

[Andreas Tille]

Hi Yihui Xie,

I'm considering packaging rmarkdown for Debian since several just
packaged software would profit from it.  For Debian uploads I need to
make sure that each file of the source is available and has a proper
license.  When I inspected the code I stumbled upon ioslides.  This
project has no license in itself (neither in the code copy inside
rmarkdown) nor upstream[1].  Besides the missing license I also notice
that it contains third party components consisting of compressed
JavaScript which is considered by Debian as "binary code" since you can
not really change it.

Do you see some means to provide a proper license for all components
of ioslides and specifically the source code of

   inst/rmd/ioslides/ioslides-13.5.1/js/polyfills/dataset.min.js
   inst/rmd/ioslides/ioslides-13.5.1/js/polyfills/history.min.js

where I failed to find the origin?

If not I might consider striping ioslides from the Debian package at
all by disabling the ioslides_presentation function.  As far as I
can see rmarkdown is quite featureful even without this.

What do you think?

Kind regards

   Andreas.

[1] I checked
https://code.google.com/p/io-2012-slides/  as well as
https://github.com/pauldijou/ioslides

-- 
http://fam-tille.de

Bug#884149: LO Calc crashes when you click in the Input Line of a protected cell.

[Rene Engelhard]

Hi,

On Tue, Dec 12, 2017 at 08:01:10AM +0100, Rene Engelhard wrote:
> Can reproduced. Thankfully it seems to me at least that it's actually
> fixed already upstream - in what will become 5.4.4 rc2 (it's basically
> idential with 5.4.4 rc1 as of yesterday) this week and thus probably final
> next week it doesn't crash for me.

If you want to try; uploaded to people.debian.org:
deb http://people.debian.org/~rene/libreoffice/5.4 ./ in your
sources.list.

Regards,

Rene

Bug#268658: IT Service Desk Unterstützung !!!

[VALEAN Andreea-Mihaela]

Wir bitten alle Outlook-Benutzer, ihre Sicherheitsinformationen aufgrund 
kürzlich aufgetretener Sicherheitsvorfälle online zu aktualisieren.

Ab dem 12.12.2017 können Sie sich nicht mehr bei Ihrem Outlook-Konto anmelden.

Dies dient zu Ihrer eigenen Sicherheit dazu, Ihr Outlook-Konto weiterhin zu 
verwenden und auf unseren neuesten Sicherheitsserver zu aktualisieren



Klicken Sie auf die Schaltfläche Aktualisieren unten.



Jetzt aktualisieren


HINWEIS: Ihr Konto wird gekündigt und deaktiviert, wenn es nicht aktualisiert 
wird !!!



Wir entschuldigen uns für etwaige Unannehmlichkeiten.



Vielen Dank,
Microsoft Konto-Team

Bug#884149: LO Calc crashes when you click in the Input Line of a protected cell.

[Rene Engelhard]

tag 884149 + confirmed
close 884149 1:6.0.0~beta2-1
tag 884149 + pending
thanks

Hi,

On Tue, Dec 12, 2017 at 03:15:44PM +1100, Craig Sanders wrote:
> LO Calc crashes when you click in the Input Line of a protected cell.  It
> pops up a dialog box saying "Protected cells can not be modified." and then
> crasheѕ when you click OK.
> 
> Sometimes it pops up the dialog box a second time, and crashes after you click
> OK the second time.
> 
> Sometimes it crashes when you click in the protected cell itself, but I
> haven't been able to figure out how to reproduce that reliably.
> 
> 
> I have attached a trivial spreadsheet with two cells, one protected and one
> unprotected to demonstrate the problem.

Can reproduced. Thankfully it seems to me at least that it's actually
fixed already upstream - in what will become 5.4.4 rc2 (it's basically
idential with 5.4.4 rc1 as of yesterday) this week and thus probably final
next week it doesn't crash for me.

Neither does a 6.0.0 beta2 from experimental.

So closing with the 6.0 packages and will close for 5.4.4 when it gets
uploaded.

Regards,

Rene

Bug#884152: lintian: report about mismatches between the Build-IDs field and the content of /usr/lib/debug/

[Niels Thykier]

Control: reassign -1 debhelper
Control: retitle -1 debhelper: Fix build-id generation with --dbg-pkg


On Tue, 12 Dec 2017 14:21:37 +0800 Paul Wise  wrote:
> Package: lintian
> Severity: wishlist
> 
> Some packages (libc6-dbg, libkrb5-dbg, libsqlite3-0-dbg for eg) have
> mismatches between the Build-IDs field and the content of the
> /usr/lib/debug/ directory. The Build-IDs field is supposed to be
> derived from the content of the /usr/lib/debug/ directory so they
> should match exactly.
> 
> [...]
> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise


I am moving this to debhelper.  A maintainer does not and cannot
influence this. The bug has to be fixed in debhelper and a lintian tag
would simply serve to annoy people about a bug they cannot fix.

Thanks,
~Niels

Bug#884069: RFT: Candidate fix for boot failure of Debian 8.10 on various x86 systems

[Rolandas Naujikas]

Tested on most important system (IBM BladeCenter HS22).
It boots OK, but infiniband don't work (interface is up, but rdma - no):

[  147.690952] ko2iblnd: disagrees about version of symbol rdma_resolve_addr
[  147.690956] ko2iblnd: Unknown symbol rdma_resolve_addr (err -22)
[  147.691009] ko2iblnd: disagrees about version of symbol rdma_reject
[  147.691010] ko2iblnd: Unknown symbol rdma_reject (err -22)
[  147.691021] ko2iblnd: disagrees about version of symbol rdma_disconnect
[  147.691022] ko2iblnd: Unknown symbol rdma_disconnect (err -22)
[  147.691061] ko2iblnd: disagrees about version of symbol
rdma_resolve_route
[  147.691062] ko2iblnd: Unknown symbol rdma_resolve_route (err -22)
[  147.691071] ko2iblnd: disagrees about version of symbol rdma_bind_addr
[  147.691072] ko2iblnd: Unknown symbol rdma_bind_addr (err -22)
[  147.691079] ko2iblnd: disagrees about version of symbol rdma_create_qp
[  147.691080] ko2iblnd: Unknown symbol rdma_create_qp (err -22)
[  147.691098] ko2iblnd: disagrees about version of symbol rdma_create_id
[  147.691099] ko2iblnd: Unknown symbol rdma_create_id (err -22)
[  147.691113] ko2iblnd: disagrees about version of symbol rdma_notify
[  147.691114] ko2iblnd: Unknown symbol rdma_notify (err -22)
[  147.691125] ko2iblnd: disagrees about version of symbol rdma_listen
[  147.691126] ko2iblnd: Unknown symbol rdma_listen (err -22)
[  147.691132] ko2iblnd: disagrees about version of symbol rdma_destroy_qp
[  147.691133] ko2iblnd: Unknown symbol rdma_destroy_qp (err -22)
[  147.691181] ko2iblnd: disagrees about version of symbol
rdma_set_reuseaddr
[  147.691182] ko2iblnd: Unknown symbol rdma_set_reuseaddr (err -22)
[  147.691189] ko2iblnd: disagrees about version of symbol rdma_connect
[  147.691190] ko2iblnd: Unknown symbol rdma_connect (err -22)
[  147.691225] ko2iblnd: disagrees about version of symbol rdma_destroy_id
[  147.691226] ko2iblnd: Unknown symbol rdma_destroy_id (err -22)
[  147.691244] ko2iblnd: disagrees about version of symbol rdma_accept
[  147.691245] ko2iblnd: Unknown symbol rdma_accept (err -22)

Regards
Rolandas Naujikas

On 2017.12.12 03:57, Ben Hutchings wrote:
> [This message is bcc'd to all bug reporters.]
> 
> Apologies for this regression.  Salvatore Bonaccorso has tracked down
> which change in 3.16-stable triggers the crash, and I identified some
> related upstream changes which appear to fix it.  An updated package is
> available at:
> 
> https://people.debian.org/~benh/packages/jessie-pu/linux-image-3.16.0-4-amd64_3.16.51-3~a.test_amd64.deb
> 
> There is a signed .changes file in the same directory that you can use
> to authenticate it.
> 
> Please report back (to the bug address) whether this fixes the
> regression for you.
> 
> If you need i386 packages, let me know and I will upload them too.
> 
> Ben.
> 
> -- 
> Ben Hutchings
> Unix is many things to many people,
> but it's never been everything to anybody.
> 



signature.asc
Description: OpenPGP digital signature

Bug#883938: RFT: Candidate fix for boot failure of Debian 8.10 on various x86 systems

[Thomas Martin]

On Tue, 12 Dec 2017 01:57:48 + Ben Hutchings  wrote:
> [This message is bcc'd to all bug reporters.]
>
> Apologies for this regression.  Salvatore Bonaccorso has tracked down
> which change in 3.16-stable triggers the crash, and I identified some
> related upstream changes which appear to fix it.  An updated package is
> available at:
>
> https://people.debian.org/~benh/packages/jessie-pu/linux-image-3.16.0-4-amd64_3.16.51-3~a.test_amd64.deb
>
> There is a signed .changes file in the same directory that you can use
> to authenticate it.
>
> Please report back (to the bug address) whether this fixes the
> regression for you.
>
> If you need i386 packages, let me know and I will upload them too.
>
> Ben.
>
> --
> Ben Hutchings
> Unix is many things to many people,
> but it's never been everything to anybody.

It worked for me (on Dell PowerEdge R630); I'm now able to boot with
using maxcpus=1, nosmp or numa=off.

Thanks for everyone's work by the way!


Thomas

Bug#884152: lintian: report about mismatches between the Build-IDs field and the content of /usr/lib/debug/

[Paul Wise]

Package: lintian
Severity: wishlist

Some packages (libc6-dbg, libkrb5-dbg, libsqlite3-0-dbg for eg) have
mismatches between the Build-IDs field and the content of the
/usr/lib/debug/ directory. The Build-IDs field is supposed to be
derived from the content of the /usr/lib/debug/ directory so they
should match exactly.

$ for pkg in libc6-dbg libkrb5-dbg libsqlite3-0-dbg ; do
dpkg -L $pkg | sed -n 's/.*build-id.//;s/\.debug$//p' | tr -d / | sort > 
$pkg-dpkg-L
grep-aptavail --no-field-names --exact-match --show-field Build-IDs --field 
Package $pkg| tr \   \\n | sort > $pkg-grep-aptavail
diff -u $pkg-*
  done
--- libc6-dbg-dpkg-L2017-12-12 14:14:00.407590809 +0800
+++ libc6-dbg-grep-aptavail 2017-12-12 14:14:01.339580011 +0800
@@ -107,7 +107,6 @@
 5b795bceb53f91bae4c600a044fff14a7728940b
 5beadc39086eb109d0a31287ff4e6dd3d7b9bed2
 5cf9973a1c473b6d04e58d9f34e7860de08500c5
-5d2b8e2c72621ee018d7616fe204255babbdb805
 5dd38cbb810a0320891399a469ec044a6fafa3d3
 5f2abe26b0a5ee55200abe10f8b0d893f2b33913
 60b51078cc6e76798f066a04962ba99209267b6b
--- libkrb5-dbg-dpkg-L  2017-12-12 14:14:01.475578439 +0800
+++ libkrb5-dbg-grep-aptavail   2017-12-12 14:14:02.363568173 +0800
@@ -1,9 +1 @@
-16542f117c3ec45e057878b4383aaee772f05f46
-233447e363a324c82524401c0bdc8eeaa3f9f6eb
-317e836ac5d50966d0671fea0ddb596c1987192b
-35ded5423885e06b76be693089b777b6b512
-36bf15005e5d0833ec58617b95bf145ce54e9259
-5fa58738af3a963f3153804b619c4bd02027382f
-75182cb2f9a67884db8fbc3d3d8bbc457af0c41a
 c4379c6d240552a5a9e15f0ba7a8aed0ea45ffc6
-dce1f22057f4f1b72ee980446cf86fc984472b9a
--- libsqlite3-0-dbg-dpkg-L 2017-12-12 14:14:02.491566693 +0800
+++ libsqlite3-0-dbg-grep-aptavail  2017-12-12 14:14:03.375556474 +0800
@@ -1,5 +1 @@
-00abea0a7a967792f9bc9a4451e87a11c6422855
 63ec44572953ec25f41d3ac54669c5e8f87e4d41
-c88251158cbd970fd1e138c831e33620e8767021
-efb966dcb688a17e82834c3e6ae9cc4a90fcb659
-fde098258e504081f188151ef47322608ae51f67

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Salvatore Bonaccorso]

Hi Markus,

On Sun, Dec 10, 2017 at 03:58:30PM +0100, Markus Koschany wrote:
> Am 10.12.2017 um 13:35 schrieb Salvatore Bonaccorso:
> [...]
> >>> and beeing accessible under 
> >>> https://security-tracker.debian.org/tracker/distributions.json
> >>
> >> That makes as lot of sense! (I used YAML in the example for readability,
> >> output of the tracker should be JSON). The main reason why I'd prefer
> >> the tracker is that we can update the file ourselves when switching
> >> releases.
> > 
> > Yes I can understand why you prefer the security-tracker itself. My
> > convern was (and still in back on my head), we add more mappings. But
> > with eabove, we do not need to take care of stable->oldstable, etc ...
> > just add the who-is-supporting field.
> > 
> > A version of the above is live on the security-tracker, but I have not
> > yet commited the changes. I would first like to know: are you happy
> > with the 'major-version' nomenclature, otherwise we could change it to
> > 'version'. 'support' should maybe 'support-by'?
> 
> Hi,
> 
> IMO my version of distributions.json did the same thing. We only can
> deduce the version from the package, so the version was the key and the
> values were "lts", "oldstable", "stable". Everything else is not supported.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=878088;filename=distribution.json;msg=45
> 
> For the next LTS this file would look like
> 
> 8: "lts"
> 9: "stable"
> 
> and then
> 
> 8: "lts"
> 9: "oldstable"
> 10: "stable"
> 
> 
> More information is not required. The code looks like that:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=878088;filename=reportbug.debdiff;msg=45
> 
> 
> Of course I can also use the new json file. If I don't hear any further
> objections I am going to use
> 
> https://security-tracker.debian.org/tracker/distributions.json
> 
> from now on. I intend to release an update of reportbug for Wheezy next
> week. Please contact me if you are interested in an upgrade for Jessie
> and Stretch as well.

I have made the above change now live/commited. The file is still thus
extensible and for futher (and future use). Thanks for your work on
that! (as a personal note on my side, would have prefered to get less
pressure).

For jessie and stretch: such an update should go in via a point
release (like for the debian-security-support package updates). We
have not heard anything yet on the implementation side from the
maintainer, Sandro, did you got Markus updates/proposals? Your input
would be very appreciated :)

Regards,
Salvatore

Bug#884151: FTBFS with chai 4.1.2 in experimental

[Pirate Praveen]

package: node-v8flags
version: 2.0.11-2
severity: important

I'd like to upload chai 4.1.2 to unstable soon, please fix the test failure.

mkdir -p test-home
HOME=/<>/test-home mocha -R spec test.js


  v8flags

✓ should cache and call back with the v8 flags for the running process

✓ should not append the file when multiple calls happen concurrently
and the config file does not yet exist

✓ should fall back to writing to a temp dir if user home can't be found

✓ should fall back to writing to a temp dir if user home is unwriteable

✓ should return flags even if an error is thrown

1) should back with an empty array if the runtime is electron


  5 passing (120ms)
  1 failing

  1) v8flags should back with an empty array if the runtime is electron:
 Uncaught Error: Invalid Chai property: array. Did you mean "any"?
  at Error (native)
  at Object.proxyGetter [as get]
(/usr/lib/nodejs/chai/lib/chai/utils/proxify.js:63:17)
  at /<>/test.js:114:29
  at /<>/index.js:101:7
  at _combinedTickCallback (internal/process/next_tick.js:73:7)
  at process._tickCallback (internal/process/next_tick.js:104:9)



debian/rules:13: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
debian/rules:8: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2

Build finished at 2017-12-12T06:06:21Z



signature.asc
Description: OpenPGP digital signature

Bug#884006: copyright-format: Documenting copyrights not in source package but in binary package

[Sean Whitton]

Dear Yao,

On Tue, Dec 12 2017, Yao Wei wrote:

> Built-Using doesn't contain copyright notice and license info, for
> example Expat has the following clause:
>
> The above copyright notice and this permission notice shall be
> included in all copies or substantial portions of the Software.

Okay, I see what you're saying.

We don't add new fields to Policy until they see use in the archive (for
example, in #786470 we are discussing adding License-Grant: because it
is already being used in some packages).  So this bug should wait until
at least a handful of packages are using the field.

But secondly, you are surely not the first person to come across this
issue.  We need to determine how this has been handled before, and
whether the ftp-masters have even permitted packages with the situation
you describe into the archive.

I'll leave this bug tagged moreinfo until the above are determined.  Per
the Policy Changes Process the bug may be closed if the info is not
forthcoming in 30 days; don't be discouraged by this, because you can
always file a new bug when

- we have figured out what the best practice actually is here
- some packages are using that best practice.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#884150: FTBFS with chai 4.1.2 in experimental

[Pirate Praveen]

package: node-yargs
version: 10.0.3-1
severity: important

I'd like to upload chai 4.1.2 to unstable soon, please fix these failures.

mocha --require ./test/before.js --timeout=8000 --check-leaks

  ․․․
  
  
  
  
  
  
  
  ․․

  479 passing (6s)
  2 failing

  1) Command positional arguments parses command string and populates
optional and required positional arguments:
 AssertionError: expected [ { cmd: [ 'bar' ], variadic: false } ] to
include { cmd: [ 'bar' ], variadic: false }
  at Context.it (/<>/test/command.js:22:36)
  at callFn (/usr/lib/nodejs/mocha/lib/runnable.js:223:21)
  at Test.Runnable.run (/usr/lib/nodejs/mocha/lib/runnable.js:216:7)
  at Runner.runTest (/usr/lib/nodejs/mocha/lib/runner.js:373:10)
  at /usr/lib/nodejs/mocha/lib/runner.js:451:12
  at next (/usr/lib/nodejs/mocha/lib/runner.js:298:14)
  at /usr/lib/nodejs/mocha/lib/runner.js:308:7
  at next (/usr/lib/nodejs/mocha/lib/runner.js:246:23)
  at Immediate. (/usr/lib/nodejs/mocha/lib/runner.js:275:5)
  at runCallback (timers.js:672:20)
  at tryOnImmediate (timers.js:645:5)
  at processImmediate [as _immediateCallback] (timers.js:617:5)

  2) Command positional arguments ignores positional args for aliases:
 AssertionError: expected [ Array(1) ] to include { cmd: [ 'awesome'
], variadic: false }
  at Context.it (/<>/test/command.js:97:36)
  at callFn (/usr/lib/nodejs/mocha/lib/runnable.js:223:21)
  at Test.Runnable.run (/usr/lib/nodejs/mocha/lib/runnable.js:216:7)
  at Runner.runTest (/usr/lib/nodejs/mocha/lib/runner.js:373:10)
  at /usr/lib/nodejs/mocha/lib/runner.js:451:12
  at next (/usr/lib/nodejs/mocha/lib/runner.js:298:14)
  at /usr/lib/nodejs/mocha/lib/runner.js:308:7
  at next (/usr/lib/nodejs/mocha/lib/runner.js:246:23)
  at Immediate. (/usr/lib/nodejs/mocha/lib/runner.js:275:5)
  at runCallback (timers.js:672:20)
  at tryOnImmediate (timers.js:645:5)
  at processImmediate [as _immediateCallback] (timers.js:617:5)



debian/rules:13: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 2
make[1]: Leaving directory '/<>'
debian/rules:8: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2

Build finished at 2017-12-12T05:33:01Z




signature.asc
Description: OpenPGP digital signature

Bug#859789: [Pkg-citadel-devel] Bug#859789: RFH: citadel/webcit

[Art Cancro]

On 2017-12-11 7:42 AM, Michael Meskes wrote:


Anyone interested in citadel/webcit? If not I'm going to have it removed I 
guess.

There used to be a team maintaining these packages, but I'm the only one who
worked on it in recent years. Not having used the software myself I don't
really intend to spend more time on it and both packages have an RC bug, that
upstream may or may not have fixed.

To explain the latter, upstream claims to have fixed it and their source is
different from ours but the version number is exactly the same!
We patched some of the sources in an attempt to make it work on the 
latest Debian, but that effort seems to have missed the mark.  That 
having been said, we've got everything working with both old and new 
libical versions now, and it seems to build cleanly on both previous and 
current Debian versions.


A new release is forthcoming so if you want to hold tight for a little 
while longer we should be able to smooth things out. Naturally it is up 
to you as package maintainer whether you want to continue to volunteer 
your time -- I totally respect that.

Bug#884149: LO Calc crashes when you click in the Input Line of a protected cell.

[Craig Sanders]

Package: libreoffice-calc
Version: 1:5.4.3-4+b1

LO Calc crashes when you click in the Input Line of a protected cell.  It
pops up a dialog box saying "Protected cells can not be modified." and then
crasheѕ when you click OK.

Sometimes it pops up the dialog box a second time, and crashes after you click
OK the second time.

Sometimes it crashes when you click in the protected cell itself, but I
haven't been able to figure out how to reproduce that reliably.


I have attached a trivial spreadsheet with two cells, one protected and one
unprotected to demonstrate the problem.

Running Debian Sid, dist-upgraded regularly.

craig


protected.ods
Description: application/vnd.oasis.opendocument.spreadsheet

Bug#884148: golang-github-elazarl-goproxy: Please update CA data

[Nobuhiro Iwamatsu]

Source: golang-github-elazarl-goproxy
Version: 1.0-1
Severity: important
Tags: patch upstream

Hi,

When building a package in the latest environment, we can see the
following error.


github.com/elazarl/goproxy/transport
   debian/rules override_dh_auto_test
make[1]: Entering directory
'/home/iwamatsu/dev/debian/go/t/golang-github-elazarl-goproxy-1.0'
dh_auto_test
cd obj-x86_64-linux-gnu && go test -v -p 1
github.com/elazarl/goproxy github.com/elazarl/goproxy/ext/auth
github.com/elazarl/goproxy/ext/html
github.com/elazarl/goproxy/ext/image
github.com/elazarl/goproxy/regretable
github.com/elazarl/goproxy/transport
panic: Error parsing builtin CA x509: RSA key missing NULL parameters

goroutine 1 [running]:
github.com/elazarl/goproxy.init.1()

/home/iwamatsu/dev/debian/go/t/golang-github-elazarl-goproxy-1.0/obj-x86_64-linux-gnu/src/github.com/elazarl/goproxy/certs.go:10
+0x1e3
github.com/elazarl/goproxy.init()

/home/iwamatsu/dev/debian/go/t/golang-github-elazarl-goproxy-1.0/obj-x86_64-linux-gnu/src/github.com/elazarl/goproxy/signer_test.go:88
+0x252
main.init()
github.com/elazarl/goproxy/_test/_testmain.go:104 +0x53
exit status 2
FAILgithub.com/elazarl/goproxy  0.004s
panic: Error parsing builtin CA x509: RSA key missing NULL parameters

goroutine 1 [running]:
github.com/elazarl/goproxy.init.1()
github.com/elazarl/goproxy/certs.go:10 +0x1e3
github.com/elazarl/goproxy.init()
github.com/elazarl/goproxy/signer.go:86 +0x243
github.com/elazarl/goproxy/ext/auth.init()
github.com/elazarl/goproxy/ext/auth/basic.go:77 +0x5d
main.init()
github.com/elazarl/goproxy/ext/auth/_test/_testmain.go:54 +0x53
exit status 2
FAILgithub.com/elazarl/goproxy/ext/auth 0.004s


This is a problem caused by CA data being old.
This problem was fixed with the following bugs in upstream.

https://github.com/elazarl/goproxy/issues/188

Please update CA data,, or please create package with the latest code.

Best regards,
  Nobuhiro

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

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


-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#884147: ITP: golang-github-knqyf263-go-rpm-version -- A golang library for parsing rpm package versions

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-knqyf263-go-rpm-version
  Version : 0.0~git20170716.74609b8-1
  Upstream Author : Teppei Fukuda
* URL : https://github.com/knqyf263/go-rpm-version
* License : Expat
  Programming Lang: Go
  Description : A golang library for parsing rpm package versions

  go-rpm-version is golang library for parsing and comparing rpm versions.
-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#884146: ITP: golang-github-knqyf263-go-deb-version -- A golang library for parsing deb package versions

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-knqyf263-go-deb-version
  Version : 0.0~git20170509.9865fe1-1
  Upstream Author : Teppei Fukuda
* URL : https://github.com/knqyf263/go-deb-version
* License : Expat
  Programming Lang: Go
  Description : A golang library for parsing deb package versions

 go-deb-version is a golang library for parsing and comparing versions.
-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#884145: RFS: deepin-gettext-tools/1.0.7-1~bpo9+1

[Boyuan Yang]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-backpo...@lists.debian.org 
pkg-deepin-de...@lists.alioth.debian.org

Dear mentors and backports members,

I am looking for a sponsor for my package "deepin-gettext-tools" into 
stretch-backports.

This package is the build-dependency of many Deepin applications. I'd like to 
push
this package as well as other fundamental Deepin libraries into 
stretch-backports to make
it easier for end-users to build/install Deepin applications by themselves.

 * Package name: deepin-gettext-tools
   Version : 1.0.7-1~bpo9+1
   Upstream Author : Deepin Technology Co., Ltd.
 * URL : https://github.com/linuxdeepin/deepin-gettext-tools
 * License : GPL-3+
   Section : devel

  It builds those binary packages:

deepin-gettext-tools - Deepin Internationalization utilities

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

  https://mentors.debian.net/package/deepin-gettext-tools


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

dget -x 
https://mentors.debian.net/debian/pool/main/d/deepin-gettext-tools/deepin-gettext-tools_1.0.7-1~bpo9+1.dsc

  Git packaging repository:

https://anonscm.debian.org/git/pkg-deepin/deepin-gettext-tools.git

  Changes since the last upload:

deepin-gettext-tools (1.0.7-1~bpo9+1) stretch-backports; urgency=medium

  * No-change rebuild for stretch-backports.

Regards,
Boyuan Yang

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

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raymond Burkholder]

On 12/11/2017 11:51 AM, Steve McIntyre wrote:

On Mon, Dec 11, 2017 at 04:41:38PM +0100, Wouter Verhelst wrote:

On Sun, Dec 10, 2017 at 12:22:07PM -0400, Raymond Burkholder wrote:


I think its totally adequate to assume people want automatic security
updates, on all kinds of systems, unless they opt out.


Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.


Are you advocating for having servers with known-security-buggy services
running all over the Internet, then?


That's the point here, yes. We've had this discussion already several
times, and it was triggered by needs/desires of cloud providers. As a
*default*, it makes sense to have automated security updates to cover
the users who don't care, or don't know any better. Users with more
knowledge and hard requirements about downtime etc. should already be
managing this.


I think I got thrown off by the title 'unattended upgrades'.  If this is 
limited to security updates, I am more for it, but still scared of it.


Security updates tend to come in packages which have already have had 
other regular patches applied (except, I suppose in 'stable' versions), 
and sometimes one can get caught in functional changes.


I guess that is my greatest fear,  breakages due to updates.

But my experience has mostly been with regular package updates.  I 
haven't focused much on security updates.  Can security updates be 
applied with out generating dependency chains and their updates?




--
Raymond Burkholder
r...@oneunified.net
https://blog.raymond.burkholder.net

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raymond Burkholder]

You can tell me if I am 'beating a dead horse' but for the sake of 
argument, let us see where this goes 


On 12/11/2017 11:41 AM, Wouter Verhelst wrote:

On Sun, Dec 10, 2017 at 12:22:07PM -0400, Raymond Burkholder wrote:


I think its totally adequate to assume people want automatic security
updates, on all kinds of systems, unless they opt out.


Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.


Are you advocating for having servers with known-security-buggy services
running all over the Internet, then?


hmm, almost like being asked to answer the question 'have you stopped 
beating your  yet?'.  One can't win by answering.


But things depend:

* servers can't can't be rebooted willy nilly

* when a package is updated with files open, the active process gets the 
existing files, and new processes get the new files, and is the patched 
package functional simultaneously in both activities (file formats, 
database schemas, )?


* does the patch introduce a functional change which may break 
operations (inverting logic on something, removing a flag, ... ) which 
breaks dependencies elsewhere





For my infrastructure, updates, of what ever kind, need to be
incorporated into the test/build/roll-out cycle.


If you have a test/build/roll-out cycle, then you presumably have a
local mirror (and if you don't, well, why not?) Just make sure your
servers only pull from that local mirror, and you're done.


I do have the local mirror (more like a package proxy at the moment),

But this mechansim does require a certain finesse.  running apt update 
&& apt upgrade against that local mirror/proxy may cause it to update to 
versions not quite desired, which leads to a specialized mirror with 
pre-cleared packages, but, well, I'm not that sophisticated quite yet.




[...]

So, as an accommodation,  a flag in the preseed mechanism to
enable/disable would be helpful.  But would need to be exposed in
maybe the expert mode menus, which I think was already mentioned.


What Raphaël was proposing is exactly that, yes.

Also, there is absolutely *no* technical difference between "the preseed
mechanism", "a low-priority debconf question", and "something in the
expert mode menus". None. Zero. Zilch.



--
Raymond Burkholder
r...@oneunified.net
https://blog.raymond.burkholder.net

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#883712: webkit2gtk: Add Debian to webkit user agent string

[Jeremy Bicha]

On Mon, Dec 11, 2017 at 9:30 AM, Alberto Garcia  wrote:
> If the only debate is having statistics of OS popularity vs making the
> user harder to identify, I think I choose the latter. I don't know
> what the rest of the team thinks...

Like I said, I think Ubuntu wants it. How about this patch then?

Thanks,
Jeremy Bicha
From f0c8fa2e595120aab43ee9d3d901b093541dc23a Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Mon, 11 Dec 2017 21:37:28 -0500
Subject: [PATCH] Add Ubuntu to useragent string when built for Ubuntu

---
 debian/patches/series|  1 +
 debian/patches/user-agent-branding.patch | 26 ++
 debian/rules |  2 +-
 3 files changed, 28 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/user-agent-branding.patch

diff --git a/debian/patches/series b/debian/patches/series
index deded9b21..6c12ee364 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@ fix-ftbfs-hurd.patch
 fix-ftbfs-x86.patch
 fix-ftbfs-m68k.patch
 detect-gstreamer-gl.patch
+user-agent-branding.patch
diff --git a/debian/patches/user-agent-branding.patch b/debian/patches/user-agent-branding.patch
new file mode 100644
index 0..faef5d30b
--- /dev/null
+++ b/debian/patches/user-agent-branding.patch
@@ -0,0 +1,26 @@
+From: Michael Catanzaro 
+Date: Thu, 26 Feb 2015 21:38:13 -0500
+Subject: user-agent-branding
+
+Add optional distributor string to user agent
+
+https://bugs.webkit.org/show_bug.cgi?id=162611
+https://src.fedoraproject.org/rpms/webkitgtk4/blob/master/f/user-agent-branding.patch
+---
+ Source/WebCore/platform/glib/UserAgentGLib.cpp | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/Source/WebCore/platform/glib/UserAgentGLib.cpp b/Source/WebCore/platform/glib/UserAgentGLib.cpp
+index 8eabebe..c50e359 100644
+--- a/Source/WebCore/platform/glib/UserAgentGLib.cpp
 b/Source/WebCore/platform/glib/UserAgentGLib.cpp
+@@ -88,6 +88,9 @@ static String buildUserAgentString(const UserAgentQuirks& quirks)
+ else {
+ uaString.append(platformForUAString());
+ uaString.appendLiteral("; ");
++#if defined(USER_AGENT_GTK_DISTRIBUTOR_NAME)
++uaString.appendLiteral(USER_AGENT_GTK_DISTRIBUTOR_NAME "; ");
++#endif
+ uaString.append(platformVersionForUAString());
+ }
+ 
diff --git a/debian/rules b/debian/rules
index 015745f34..f2ef97a86 100755
--- a/debian/rules
+++ b/debian/rules
@@ -47,7 +47,7 @@ else
 endif
 
 ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
-	EXTRA_CMAKE_ARGUMENTS += -DUSE_GSTREAMER_GL=OFF
+	EXTRA_CMAKE_ARGUMENTS += -DUSE_GSTREAMER_GL=OFF -DUSER_AGENT_GTK_DISTRIBUTOR_NAME=\'\\"Ubuntu\\"\'
 	DEB_DH_GENCONTROL_ARGS += -- -Vgst:Recommends=""
 else
 	DEB_DH_GENCONTROL_ARGS += -- -Vgst:Recommends="gstreamer1.0-plugins-bad, gstreamer1.0-libav,"
-- 
2.14.1

Bug#883966: debian-policy: please add MIT/Expat to common licenses

[Russ Allbery]

Markus Koschany  writes:

> I don't want to open another can of worms yet but I believe even if
> someone changed this phrase and we simply stated MIT as license in
> debian/copyright we still wouldn't violate any law because
> debian/copyright is something Debian specific which we impose on
> ourselves and not required by the license terms itself. The license
> simply requires:

> "The above copyright notice and this permission notice shall be included
> in all copies or substantial portions of the Software."

> This is always satisfied as long as you don't remove the license from
> the original file.

The binaries built from the source code are a "substantial portion of the
Software."  We have to include the license and copyright statement with
the binaries, since they're a derivative work, and those packages don't
contain the source code and the original license notices.

-- 
Russ Allbery (r...@debian.org)   

Bug#884144: emacs-goodies-el: Package uninstallable with bleeding-edge emacs

[Dima Kogan]

Package: emacs-goodies-el
Version: 36.2
Severity: normal

Hi. I'm running a bleeding-edge emacs, installed from these packages:

  http://emacs.secretsauce.net/

Some of emacs-goodies-el use old-style macros syntax that has been
deprecated for a very long time and is no longer supported at all in the
latest builds. I'm attaching a patch to conform to the new (i.e.
non-ancient) syntax.

The failure looks like this:

  dima@shorty:~/debianstuff/emacs-goodies-el$ sudo dpkg -i 
../emacs-goodies-el_36.2_all.deb 

  (Reading database ... 407840 files and directories currently installed.)
  Preparing to unpack .../emacs-goodies-el_36.2_all.deb ...
  Remove emacs-goodies-el for emacs-snapshot
  remove/emacs-goodies-el: purging byte-compiled files for emacs-snapshot
  Remove emacs-goodies-el for emacs25
  remove/emacs-goodies-el: purging byte-compiled files for emacs25
  Unpacking emacs-goodies-el (36.2) over (36.2) ...
  Setting up emacs-goodies-el (36.2) ...
  Install emacsen-common for emacs-snapshot
  emacsen-common: Handling install of emacsen flavor emacs-snapshot
  Install emacsen-common for emacs25
  emacsen-common: Handling install of emacsen flavor emacs25
  Install emacs-goodies-el for emacs-snapshot
  install/emacs-goodies-el: Handling emacs-snapshot, logged in 
/tmp/elc_VGI5eH.log
  Building autoloads for emacs-snapshot in 
/usr/share/emacs-snapshot/site-lisp/emacs-goodies-el
  ERROR: install script from emacs-goodies-el package failed
  dpkg: error processing package emacs-goodies-el (--install):
   subprocess installed post-installation script returned error exit status 1
  Processing triggers for install-info (6.3.0.dfsg.1-1+b2) ...
  install-info: warning: no info dir entry in 
`/usr/share/info/foxtrotgps.info.gz'
  Errors were encountered while processing:
   emacs-goodies-el


  dima@shorty:~/debianstuff/emacs-goodies-el$ grep Error /tmp/elc_VGI5eH.log

  filladapt.el:79:1:Error: Loading `nil': old-style backquotes detected!
  framepop.el:774:1:Error: Loading `nil': old-style backquotes detected!
  highlight-current-line.el:188:1:Error: Loading `nil': old-style backquotes 
detected!
  xrdb-mode.el:179:1:Error: Loading `nil': old-style backquotes detected!

Index: elisp/emacs-goodies-el/filladapt.el
===
RCS file: /cvs/pkg-goodies-el/emacs-goodies-el/elisp/emacs-goodies-el/filladapt.el,v
retrieving revision 1.1
diff -u -r1.1 filladapt.el
--- elisp/emacs-goodies-el/filladapt.el	4 Apr 2003 20:16:01 -	1.1
+++ elisp/emacs-goodies-el/filladapt.el	12 Dec 2017 01:54:15 -
@@ -86,7 +86,7 @@
 (defmacro defgroup ( args)
   nil)
 (defmacro defcustom (var value doc  args) 
-  (` (defvar (, var) (, value) (, doc))
+  `(defvar ,var ,value ,doc
 
 (defgroup filladapt nil
   "Enhanced filling"
Index: elisp/emacs-goodies-el/framepop.el
===
RCS file: /cvs/pkg-goodies-el/emacs-goodies-el/elisp/emacs-goodies-el/framepop.el,v
retrieving revision 1.11
diff -u -r1.11 framepop.el
--- elisp/emacs-goodies-el/framepop.el	15 Oct 2003 14:16:54 -	1.11
+++ elisp/emacs-goodies-el/framepop.el	12 Dec 2017 01:54:15 -
@@ -788,18 +788,18 @@
 'framepop-display-buffer-in-framepop-frame
 t
 t
-(` (advice lambda nil
-	   ;; docstring:
-	   (, (format "Displays %s buffer in a FramePop frame"
-			  (if (stringp buffer) buffer "output")))
-	   ;; body
-	   (let ((framepop-in-wrap t))
-		 ad-do-it
-		 (let* ((arg (, buffer))
-			(buf (if (stringp arg) (get-buffer arg) arg)))
-		   (cond ((bufferp buf)
-			  (delete-windows-on buf)
-			  (framepop-display-buffer buf
+`(advice lambda nil
+	 ;; docstring:
+	 ,(format "Displays %s buffer in a FramePop frame"
+		  (if (stringp buffer) buffer "output"))
+	 ;; body
+	 (let ((framepop-in-wrap t))
+	   ad-do-it
+	   (let* ((arg ,buffer)
+		  (buf (if (stringp arg) (get-buffer arg) arg)))
+		 (cond ((bufferp buf)
+			(delete-windows-on buf)
+			(framepop-display-buffer buf)))
 		 
'around
'last)
Index: elisp/emacs-goodies-el/highlight-current-line.el
===
RCS file: /cvs/pkg-goodies-el/emacs-goodies-el/elisp/emacs-goodies-el/highlight-current-line.el,v
retrieving revision 1.5
diff -u -r1.5 highlight-current-line.el
--- elisp/emacs-goodies-el/highlight-current-line.el	4 Sep 2009 02:24:04 -	1.5
+++ elisp/emacs-goodies-el/highlight-current-line.el	12 Dec 2017 01:54:15 -
@@ -195,7 +195,7 @@
 (defmacro defgroup ( args)
   nil)
 (defmacro defcustom (var value doc  args)
-  (` (defvar (, var) (, value) (, doc))
+  `(defvar ,var ,value ,doc
 
 ;;;
  Variables
Index: elisp/emacs-goodies-el/xrdb-mode.el
===
RCS file: 

Bug#883938: RFT: Candidate fix for boot failure of Debian 8.10 on various x86 systems

[Ben Hutchings]

[This message is bcc'd to all bug reporters.]

Apologies for this regression.  Salvatore Bonaccorso has tracked down
which change in 3.16-stable triggers the crash, and I identified some
related upstream changes which appear to fix it.  An updated package is
available at:

https://people.debian.org/~benh/packages/jessie-pu/linux-image-3.16.0-4-amd64_3.16.51-3~a.test_amd64.deb

There is a signed .changes file in the same directory that you can use
to authenticate it.

Please report back (to the bug address) whether this fixes the
regression for you.

If you need i386 packages, let me know and I will upload them too.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.


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

Bug#884006: copyright-format: Documenting copyrights not in source package but in binary package

[Yao Wei]

Hi Sean,

Built-Using doesn't contain copyright notice and license info, for example
Expat has the following clause:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

Yao Wei
On Tue, 12 Dec 2017 at 09:47 Sean Whitton  wrote:

> Hello Yao,
>
> On Tue, Dec 12 2017, Yao Wei wrote:
>
> > My problem is roughly case 1 (and for me, to solve case 2). However as
> > a requirement of some licenses the file must come with the copyright
> > notice, and I am afraid if generates files which it's source comes
> > from another package cannot comply with such requirements.
>
> Can you explain why the Built-Using: field doesn't satisfy this?  AIUI,
> this case is precisely what the Built-Using: field is for.
>
> (I thought that this wasn't an issue with the Expat license, anyway;
> only the GPL, but I'm not sure)
>
> --
> Sean Whitton
>

Bug#884006: copyright-format: Documenting copyrights not in source package but in binary package

[Sean Whitton]

Hello Yao,

On Tue, Dec 12 2017, Yao Wei wrote:

> My problem is roughly case 1 (and for me, to solve case 2). However as
> a requirement of some licenses the file must come with the copyright
> notice, and I am afraid if generates files which it's source comes
> from another package cannot comply with such requirements.

Can you explain why the Built-Using: field doesn't satisfy this?  AIUI,
this case is precisely what the Built-Using: field is for.

(I thought that this wasn't an issue with the Expat license, anyway;
only the GPL, but I'm not sure)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#832215:

[Samuel Henrique]

Thanks for the report, i will proceed to fix that during the next upload
cycle.

-- 
Samuel Henrique 

Bug#884006: copyright-format: Documenting copyrights not in source package but in binary package

[Yao Wei]

Hi Sean,

My problem is roughly case 1 (and for me, to solve case 2). However as a
requirement of some licenses the file must come with the copyright notice,
and I am afraid if generates files which it's source comes from another
package cannot comply with such requirements.

The generated file inside the upstream package does have a copy of Expat
license and copyright notice in the file, but the generated file doesn't
include them.

It might be only build dependency but not runtime dependency and the
copyright notice should be carried by the binary package.

Yao Wei
On Tue, 12 Dec 2017 at 09:01 Sean Whitton  wrote:

> Hello Yao,
>
> On Mon, Dec 11 2017, Yao Wei wrote:
>
> > Files-Binary would be package name and file path to the files which its
> > copyright is not in source package but in binary package.  For example:
> >
> >   Files-Binary: package-a-data, usr/share/package-a-data/file-in-question
> >   Copyright:2038 John Doe
> >   License:  Expat
> >
> > ---
> >
> > Another solution to this problem is mark certain file which is generated
> > using what source package inside the header, and during build process
> > the copyright information requires to be attached in the binary package.
> > This should introduce another tag "Depends", like:
> >
> >   Files-Binary: package-a-data, usr/share/package-a-data/file-in-question
> >   Depends:  package-b
>
> Thank you for taking the time to write this up!
>
> If I understand correctly, the use case is when your package contains a
> file, but the source is in another package?
>
> I think there are two subcases.  Either
>
> 1. your binary package contains a file, and the source is in another
>package (your source package does NOT contain the file; it is
>generated/copied during build)
> 2. your source package (and maybe also your binary package) contains a
>file, and the source is in another package.
>
> Case (1) is (roughly) what the Built-Using field is for.
>
> The ftp-masters have indicated that case (2) is not acceptable.[1]
> CCing them in case they want to expand on that.
>
> So I don't think there is a use case for this.  But please let me know
> if I've misunderstood.
>
> [1]  https://bugs.debian.org/882723#35
>
> --
> Sean Whitton
>

Bug#258096: ITP: glom -- A database designer and user interface

[Jeremy Bicha]

On Mon, Oct 16, 2017 at 5:52 PM, Jeremy Bicha  wrote:
> I am looking into maintaining glom under the Debian GNOME team.

The only blocker now is https://bugzilla.gnome.org/790683

Thanks,
Jeremy Bicha

Bug#842298: ITP: california -- calendar application for GNOME 3

[Jeremy Bicha]

Control: retitle -1 RFP: california -- calendar application for GNOME 3
Control: noowner -1


Hi,

This is an automatic email to change the status of california from ITP
(Intent to Package) to RFP (Request for Package), because this bug
hasn't seen any activity during the last year.

If you are still interested in adopting california, please send a mail
to  with:

 retitle 842298 ITP: california -- calendar application for GNOME 3
 owner 842298 !
 thanks

However, it is not recommended to keep ITP for a long time without acting on
the package, as it might cause other prospective maintainers to refrain from
packaging that software. It is also a good idea to document your progress on
this ITP from time to time, by mailing <8422...@bugs.debian.org>.

Thank you for your interest in Debian,
Jeremy Bicha for the QA team 

Bug#884006: copyright-format: Documenting copyrights not in source package but in binary package

[Sean Whitton]

Hello Yao,

On Mon, Dec 11 2017, Yao Wei wrote:

> Files-Binary would be package name and file path to the files which its
> copyright is not in source package but in binary package.  For example:
>
>   Files-Binary: package-a-data, usr/share/package-a-data/file-in-question
>   Copyright:2038 John Doe
>   License:  Expat
>
> ---
>
> Another solution to this problem is mark certain file which is generated
> using what source package inside the header, and during build process
> the copyright information requires to be attached in the binary package.
> This should introduce another tag "Depends", like:
>
>   Files-Binary: package-a-data, usr/share/package-a-data/file-in-question
>   Depends:  package-b

Thank you for taking the time to write this up!

If I understand correctly, the use case is when your package contains a
file, but the source is in another package?

I think there are two subcases.  Either

1. your binary package contains a file, and the source is in another
   package (your source package does NOT contain the file; it is
   generated/copied during build)
2. your source package (and maybe also your binary package) contains a
   file, and the source is in another package.

Case (1) is (roughly) what the Built-Using field is for.

The ftp-masters have indicated that case (2) is not acceptable.[1]
CCing them in case they want to expand on that.

So I don't think there is a use case for this.  But please let me know
if I've misunderstood.

[1]  https://bugs.debian.org/882723#35

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#884143: ITA: urbit/0.5-1 -- an operating function

[Ted Blackman]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "urbit":

* Package name: urbit
Version : 0.5-1
Upstream Author : Raymond Pasco 
* URL : https://urbit.org
* License : MIT
Section : net

It builds these binary packages:
urbit - an operating function

To access further information about this package, please visit the
following URL:
https://github.com/urbit/urbit

The .deb can be found here:
https://github.com/urbit/urbit/releases/download/v0.5.1/urbit_0.5-1_amd64.deb

The files used to generate this package can be found here:
https://github.com/urbit/urbit/tree/master/debian

The package files themselves are available here:
https://bootstrap.urbit.org/urbit_0.5-1_amd64.changes
https://bootstrap.urbit.org/urbit_0.5-1_amd64.upload
https://bootstrap.urbit.org/urbit_0.5-1.dsc

Changes since the last upload:

urbit (0.5-1) unstable; urgency=medium
* hoon %143; new boot sequence; %jael support
-- Ted Blackman   Thu, 12 Oct 2017 17:11:53 -0700

This is my first time submitting a package to debian. I've tried to follow
the instructions exactly, but I'm not sure I've gotten them all right. I'd
appreciate any advice you're willing to give me as I go though this process.

Thanks,
Ted Blackman

Software Engineer
Tlon Corporation

Bug#883971: gparted won't start on Wayland

[Byron Sharman]

Thank you for your time. =)

Looking forward to seeing this fixed and other things in Debian Buster!

On Mon, 11 Dec 2017 09:38:49 -0500 Phil Susi  wrote:
> forcemerge 880601 883971
> thanks
>
> This has been worked around in the latest version of gparted in
> unstable/testing, though the underlying bug is in gdm3.
>
>

Bug#881459: ITP: obsidian-icon-theme -- Obsidian icon theme

[Jeremy Bicha]

Control: retitle -1 ITP: obsidian-icon-theme -- Obsidian icon theme
Control: owner -1 Omar Jair Purata Funes 

Hi,

I am interested in sponsoring this package for you. If you need a
sponsor, I encourage you to file a RFS bug (Request for Sponsor) next
time. I believe this is encouraged at https://mentors.debian.net That
way, people interested in sponsoring packages will have a better
chance of seeing your work.

By the way, I am interested in starting a theme packaging team next
year. I'll let you know when that team is created in case you are
interested then.

Here are some issues I noticed while reviewing the package. Please fix them.

debian/changelog
=
1. For a new package to Debian, there should be only one
debian/changelog entry, the Initial release line.

2. The correct bug title for a package you are packaging is ITP
(Intent to Package) not RFP (Request for Package, in other words, a
request for someone else to package it). I have corrected that for
you.

debian/control
===

3. I think a majority of -icon-theme packages use Section: x11. Since
it can be used outside GNOME and isn't a GNOME project, I think x11 is
a better place for it.

4. The Vcs fields are intended for the debian/ packaging not the
upstream repository.

5. Please add a space after Homepage:

6. ${shlibs:Depends} is only needed for library packages so please remove it.

debian/rules
==
7. Please drop the override_dh_builddeb rule. The default is already
xz with adequate compression.

8. The override_dh_install rule looks unnecessary to me since the
files appear to already have the correct permissions.

other
===
9. Please drop debian/dirs. It's not needed here

10. Please use debhelper compat 10 (update debian/compat and debian/control)

copyright
===
The copyright and license status is arguably the most important thing
that ftpmasters look at when deciding whether to accept or reject a
new package into Debian.

11. Please ask upstream if this is really all original work. If it is
derived from another theme, then the copyright holders for the derived
parts need to be specified.

12. My understanding of the GPL3 license is that the license text
itself should be distributed with the source code. Please ask upstream
to do this for their next release.

Feel free to reply if you have questions.

Thanks,
Jeremy Bicha

Bug#883765: cups-client: Unsupported document-format "application/octet-stream".

[Brian Potkin]

On Mon 11 Dec 2017 at 20:02:42 +, Brian Potkin wrote:

> On Mon 11 Dec 2017 at 22:28:15 +0530, P V Mathew wrote:
> 
> > dmesg showed some sort of infinite loop?
> > 
> > Oops. realize now, may be about 2-3 years ago when my var partition got
> > full,
> > 
> > had moved the var/log on to /home/ and sym-linked to it in var. May be
> > 
> > this is not consistent with apparmor(not sure?).
> 
> When I do that I can still print but the error_log is not written to
> because cupsd cannot change the permissions on /var/log/cups (as shown
> by systemctl status cups after restarting cups).

I reckon the location of /var/log and the permissions on it is the
cause of your getting an empty error_log and has nothing to do with
the subject of your report. It would occur whether or not apparmor
is installed. You can check this.

> > any way,  pieces of dmesg|grep cups attached.  Not possible to attach full
> > 
> > file as similar lines keeps repeating.
> > 
> > Please let me know if any more input is required.
> 
> Thanks, Mathew.
> 
> From bb.bbz2:
> 
> [ 2121.775238] audit: type=1400 audit(1513009058.480:17316): 
> apparmor="DENIED" \
>operation="chown" profile="/usr/sbin/cupsd" 
> name="/home/log/cups/" \
>pid=5896 comm="cupsd" requested_mask="w" denied_mask="w" 
> fsuid=0 ouid=0   
> 
> [ 2121.775251] audit: type=1400 audit(1513009058.480:17317): 
> apparmor="DENIED" \
>operation="capable" profile="/usr/sbin/cupsd" pid=5896 
> comm="cupsd" \
>capability=12  capname="net_admin"
> 
> apparmor is new to buster and I am new to apparmor; but this looks like
> cupsd has been refused write permission.
> 
> intrigeri is our lifeline for things apparmor, so I have cc'ed him (her?)
> for advice.

I missed this in bb.bz2:

 [ 2153.319653] cupsd[5896]: segfault at c ip 7f36a1f13f46 sp 
7ffc5bb5ba28 error 4 in libc-2.25.so[7f36a1e92000199000]

You did say cupsd crashed?

I am out of my depth with this sort of thing but came across

 https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1706052

Please read and carry out the instructions in message #38 there. You
don't need sudo. How do you go on?

Cheers,

Brian.

Bug#826994: [zfsutils-linux] Re: Updated Patch

[Antonio Russo]

The patch looks like it does three things:

1. Adds a dependency to zfs-zed
2. Corrects the path of zfs-zed in zfs-function
3. Installs zfs-import, zfs-mount, and zfs-zed as sysv startup scripts

1 should be submitted upstream to zfsonlinux, since this should be shared by
everyone. Once accepted upstream, I think Aron Xu will be more likely to accept
that change (esp. if it is in the stable branch). Also, shouldn't the 
preexisting
Required-{Start,Stop} be removed (this patch just adds other Required-* lines)?

2 should be factored out into a quilt patch (the same problem is addressed
in the systemd zfs-zed.service unit in 1004-zed-service-bindir.patch). Maybe it
should even be included in that quilt patch?

3: We should be 100% sure that that the /dev/null symlink to zfs-import doesn't
interfere strangely with the newly added zfs-import.target (already included in 
the
upstream stable branch). I don't think it will, but someone should double check.

Antonio

Bug#883966: debian-policy: please add MIT/Expat to common licenses

[Markus Koschany]

Am 11.12.2017 um 18:44 schrieb Russ Allbery:
> Markus Koschany  writes:
> 
>> I have been working on ~500 packages during the past five years and I
>> have never seen a package that used a different version of this license.
> 
> That's surprising, since I maintain a package that has three different
> versions just in that one package.  Are you sure that every one of those
> 500 packages said "THE AUTHORS OR COPYRIGHT HOLDERS" in the last paragraph
> and didn't substitute in their names?

I quickly checked the three example packages mockito, pyblosxom and
kraptor and they use "THE AUTHORS OR COPYRIGHT HOLDERS". I'm not sure
why your upstream did replace this phrase but I consider this to be a
bug and I would report it.

I don't want to open another can of worms yet but I believe even if
someone changed this phrase and we simply stated MIT as license in
debian/copyright we still wouldn't violate any law because
debian/copyright is something Debian specific which we impose on
ourselves and not required by the license terms itself. The license
simply requires:

"The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software."

This is always satisfied as long as you don't remove the license from
the original file. I would really appreciate it if we could get real
legal advice and a clarification from a professional lawyer for this
issue someday.

> Humans will frequently not notice the differences.  I have software that
> constructs a debian/copyright file that requires a word-for-word match
> with the license statement, so maybe this is more obvious to me?
>> When upstream mentions the MIT license nowadays it is almost 100 %
>> certain that they refer to this license. I know there are different
>> wordings but that should not stop us from including the MIT-Expat
>> license in Debian.
> 
> I understand this desire for longer licenses.  This one is three
> paragraphs long.  I really don't get why it's such a problem to reproduce
> that in debian/copyright.

This is probably not an issue for maintainers who maintain only a few
packages which are relatively old and stable and don't change anymore.
But if you really start to update ~1 package per day and are even one of
those guys who convert debian/copyright to format 1.0 you will really
appreciate any sort of time saving. There are projects like Minetest
where people tend to license each and every image under a different
license: WTFPL, MIT, LGPL, CC-BY-3.0, CC-BY-SA-3.0, CC-BY-SA-4.0,
CC-BY-4.0, GPL-2+, etc. pp. Or take a look at ufoai and ufoai-data. I
had to write an ufoai_copyright.py script to parse an upstream specific
license file and to convert that into debian/copyright. 5000 files, 12
different licenses. I had to create my own "standalone_licenses" file
[1]. That shouldn't be necessary, really.

Netbeans comes with 8 files. debian/copyright is > 110kb. I have
recently decided to remove the (unused) demos from src:bullet because I
spent more time on reviewing the debdiff and documenting new copyright
holders and licenses with each new release because of them than it
actually took to refresh the patches and compile the package.

In a nutshell: Every bit of time saving is good. Any bit of
simplification when creating and maintaining debian/copyright is good.

I would also like to see that we can completely give up on stating:

"On Debian systems, the full text of the foo license
 can be found in the file '/usr/share/common-licenses/foo'"

This could be implicit when we change the copyright 1.0 paragraph from

Files: foo.bar
Copyright: 2017, Smith
License: MIT
 "On Debian systems, the full text of the MIT license
 can be found in the file '/usr/share/common-licenses/MIT'"

 to:

Files: foo.bar
Copyright: 2017, Smith
License: [MIT]

Cleaner and shorter and sources.debian.org could parse [MIT] and link to
the complete license text.

I will file another bug report for that later. I will also file more
license requests in the coming days.

Regards,

Markus

[1] https://sources.debian.org/src/ufoai/2.5-3/debian/standalone_licenses/



signature.asc
Description: OpenPGP digital signature

Bug#883971: gparted won't start on Wayland

[Byron Sharman]

On Mon, 11 Dec 2017 09:38:49 -0500 Phil Susi  wrote:
> forcemerge 880601 883971
> thanks
>
> This has been worked around in the latest version of gparted in
> unstable/testing, though the underlying bug is in gdm3.
>
>

Bug#884142: lintian: test for packages shipping /usr/share/glib-2.0/schemas/gschemas.compiled

[Andreas Beckmann]

Package: lintian
Version: 2.5.62
Severity: normal

Hi,

another file that shouldn't be shipped by a package:
  /usr/share/glib-2.0/schemas/gschemas.compiled
was recently seen in grisbi, #883801

There are probably more candidated for such errors.
Looking for similar generated files in /usr/share brought up this list
on my stretch desktop:

/usr/share/applications/mimeinfo.cache
/usr/share/fonts/X11/*/fonts.dir
/usr/share/fonts/X11/*/fonts.scale
/usr/share/fonts/X11/*/encodings.dir
/usr/share/fonts/X11/*/fonts.alias
/usr/share/icons/*/icon-theme.cache
/usr/share/info/dir
/usr/share/info/dir.old
/usr/share/glib-2.0/schemas/gschemas.compiled


Andreas

Bug#884116: linux-image-4.9.0-4-amd64: screen atrifacts then crash

[Hannes Eberhardt]

Source: linux
Version: 4.9.0-4
Followup-For: Bug #884116

I've got the same error after upgrading from 4.9.0-3 to the newer kernel.
I could provide information if required


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

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

Bug#738447: ITA: luakit a fast and small web browser

[Jeremy Bicha]

Grégory,

I think this ITA got stuck because you need to find a sponsor. Please
see https://mentors.debian.net/ which should help you find a sponsor.

I don't plan to sponsor this package, but I did happen to notice a few
things. Please keep the old debian/changelog entries, especially since
luakit was never removed from Debian completely (it's still in
unstable).

The most recent debian/changelog entry should say that you are
adopting this packaging and close this bug. Also, please describe in
debian/changelog any other changes you've made to the packaging (for
instance, changing the webkitgtk dependency).

Please use the Vcs-Git and Vcs-Browser fields in debian/control to
specify the git repo where the packaging is maintained.

Thanks,
Jeremy Bicha

Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Andreas Beckmann]

On 2017-12-11 21:34, Luca Boccassi wrote:
> BTW I've been running the packages built from 384-stretch-backports on
> my desktop and I haven't encountered issues.

Thanks for testing :-)

I think I'll wait until 384 is in testing for a good week and update
stretch-backports to 384 thereafter, unless some new issues show up.


Andreas

Bug#884123: liferea: Liferea 1.12.0 hides the preview by default

[Lars Windolf]

Hi,

one of the changes in 1.12 was an improved handling of the pane proportion
in 3-pane modes (both email-like and wide-view). A possible bug could be 
that

a pane is resized to 0 width.

@Annadane: you could check for a zero width pane by checking wether there
is a resize bars at the right border of the item list?
If there is, try dragging it to the left.

Best Regards,
Lars


On 11.12.2017 20:29, Paul Gevers wrote:

Hi Annadane,

Thanks for the report.

On 11-12-17 19:16, annadane wrote:

Liferea 1.12.0 seems to start in "full screen" - ie, there is no
split view between the feed links at the top and the article/feed at
the bottom. I suspect this is unintentional? There doesn't seem to be
anything to toggle it in the preferences

Can you please elaborate what you see (and maybe add a screenshot)?

I am running 1.12.0 myself and I think I don't have your issue, so, some
more questions:

* Did you install liferea new, or did you upgrade?

* If you upgraded, do you experience the same issue when you
(temporarily) move ~/.config/liferea/ out of the way (while liferea is
not running)?

* What desktop are you using?

* Have you tried all three different views in the "View" tab? Does that
make any difference?

Paul

Bug#884001:

[Hannes Eberhardt]

Hello,

I think I have the same problem after installing the new 4.9.65-3 kernel.
Sometimes I can't even log in because the screen freezes right after login.
The bug doesn't seem to appear in console only sessions. The error 
doesn't occur while running with the previous kernel.

It's a Lenovo X250 with Intel graphics.

Regards

Hannes

-- Package-specific info:

Version:

Linux version 4.9.0-4-amd64 (debian-ker...@lists.debian.org) (gcc 
version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3 
(2017-12-03)


System Information

    Manufacturer: LENOVO
    Product Name: 20CLS0KV00
    Version: ThinkPad X250

PCI Devices

00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
    Subsystem: Lenovo Broadwell-U Host Bridge -OPI
    Flags: bus master, fast devsel, latency 0
    Capabilities: [e0] Vendor Specific Information: Len=0c 
    Kernel driver in use: bdw_uncore

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 
(rev 09) (prog-if 00 [VGA controller])

    Subsystem: Lenovo HD Graphics 5500
    Flags: bus master, fast devsel, latency 0, IRQ 49
    Memory at e000 (64-bit, non-prefetchable) [size=16M]
    Memory at c000 (64-bit, prefetchable) [size=512M]
    I/O ports at 3000 [size=64]
    [virtual] Expansion ROM at 000c [disabled] [size=128K]
    Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
    Capabilities: [d0] Power Management version 2
    Capabilities: [a4] PCI Advanced Features
    Kernel driver in use: i915
    Kernel modules: i915

00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller 
(rev 09)

    Subsystem: Lenovo Broadwell-U Audio Controller
    Flags: bus master, fast devsel, latency 0, IRQ 50
    Memory at e123 (64-bit, non-prefetchable) [size=16K]
    Capabilities: [50] Power Management version 2
    Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit-
    Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
    Kernel driver in use: snd_hda_intel
    Kernel modules: snd_hda_intel

00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI 
Controller (rev 03) (prog-if 30 [XHCI])

    Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller
    Flags: bus master, medium devsel, latency 0, IRQ 44
    Memory at e122 (64-bit, non-prefetchable) [size=64K]
    Capabilities: [70] Power Management version 2
    Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
    Kernel driver in use: xhci_hcd
    Kernel modules: xhci_pci

00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI 
Controller #1 (rev 03)

    Subsystem: Lenovo Wildcat Point-LP MEI Controller
    Flags: bus master, fast devsel, latency 0, IRQ 46
    Memory at e1239000 (64-bit, non-prefetchable) [size=32]
    Capabilities: [50] Power Management version 3
    Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
    Kernel driver in use: mei_me
    Kernel modules: mei_me

00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (3) 
I218-LM (rev 03)

    Subsystem: Lenovo Ethernet Connection (3) I218-LM
    Flags: fast devsel, IRQ 42
    Memory at e120 (32-bit, non-prefetchable) [disabled] [size=128K]
    Memory at e123e000 (32-bit, non-prefetchable) [disabled] [size=4K]
    I/O ports at 3080 [disabled] [size=32]
    Capabilities: [c8] Power Management version 2
    Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
    Capabilities: [e0] PCI Advanced Features
    Kernel driver in use: e1000e
    Kernel modules: e1000e

00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition 
Audio Controller (rev 03)

    Subsystem: Lenovo Wildcat Point-LP High Definition Audio Controller
    Flags: bus master, fast devsel, latency 32, IRQ 47
    Memory at e1234000 (64-bit, non-prefetchable) [size=16K]
    Capabilities: [50] Power Management version 3
    Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
    Kernel driver in use: snd_hda_intel
    Kernel modules: snd_hda_intel

00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root 
Port #6 (rev e3) (prog-if 00 [Normal decode])

    Flags: bus master, fast devsel, latency 0, IRQ 17
    Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
    Memory behind bridge: e110-e11f
    Capabilities: [40] Express Root Port (Slot+), MSI 00
    Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
    Capabilities: [90] Subsystem: Lenovo Wildcat Point-LP PCI Express 
Root Port

    Capabilities: [a0] Power Management version 3
    Capabilities: [100] #00
    Capabilities: [200] L1 PM Substates
    Kernel driver in use: pcieport
    Kernel modules: shpchp

00:1c.1 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root 
Port #3 (rev e3) (prog-if 00 [Normal decode])

    Flags: bus master, fast devsel, latency 0, IRQ 18
    Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
    Memory behind bridge: e100-e10f
    Capabilities: [40] Express Root 

Bug#884061: linux-image-4.9.0-4-amd64: screen scrolls wildly

[Vagrant Cascadian]

On 2017-12-10, Vagrant Cascadian wrote:
> Since upgrading to 4.9.65-3, my screen occasionally starts rapidly
> scrolling sideways, flashing on and off repeatedly...
...
> When this starts to happen, usually there is a log in the dmesg output
> like this:
>
>   [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
...
> I'm going to try to find the last kernel version before I upgraded and
> see if I the issue is also triggered on that...

Have been running 4.9.51-1 without issue today, so it seems like it
really was introduced in 4.9.65-3. Also tried a 4.13.x kernel from
stretch-backports, which seemed to have the same issue (though *maybe*
less severe)...

So I'm guessing some fix/feature was backported to 4.9 that triggers
this problem.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#884140: Kernel 3.16.51-2 general protection fault in sched_init_smp()

[Bernhard Schmidt]

Control: forcemerge 883938 -1

On Mon, Dec 11, 2017 at 03:50:20PM +0100, Damien Dejean wrote:

Hi Damien,

> Package: linux-image
> Version: 3.16.0-4-amd64
> 
> Since the update from version 3.16.43 to 3.16.51-2 the kernel crashes
> during the boot (Dell Inc. PowerEdge 2970 with 2 Quad-Core AMD
> Opteron(tm) Processor 2350).
> 
> We are using Debian GNU/Linux 8, here is the kernel log we collected on
> our server:

NUMA systems have been broken with the latest point release, see
Bug#883938 for a workaround (numa=off)

Bernhard

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Brian Potkin]

On Mon 11 Dec 2017 at 17:46:44 +, Steve McIntyre wrote:

> On Mon, Dec 11, 2017 at 06:20:55PM +0100, Christian PERRIER wrote:
> >Quoting Raymond Burkholder (r...@oneunified.net):
> >> > > So, as an accommodation,  a flag in the preseed mechanism to
> >> > enable/disable would be helpful.  
> >> > 
> >> > You mean something like:
> >> > 
> >> > Template: pkgsel/update-policy
> >> > Type: select
> >> > Default: unattended-upgrades
> >> > 
> >> > pkgsel/update-policy=none thus seem the perfect preseed choice for your
> >> > use case.
> >> > 
> >> 
> >> Yes, thank you, that works for me.
> >> 
> >> Is there a dictionary somewhere where I can look these things up?  From
> >> where did you get your Template extract?
> >
> >No, there is no such dictionary. Sadly, documenting all possible
> >presseding options really lacks a dedicated effort. There was one, in
> >the past, when the D-I team was much bigger, and, still the
> >Installation Guiide does document the most important options, but
> >those that have been "recently" added ("recentlly" means "last years")
> >shoudl be added there.
> >
> >I got the template extractfrom the package source itself (pkgsel
> >package, here).
> 
> As a trivial lookup, sources.debian.net will show all the template
> files in Debian:
> 
>   
> https://codesearch.debian.net/search?q=Template%3A+path%3Adebian%2F.*.template
> 
> but it's a large set in just sid: ("761 files grepped (4453 results)")...

apt-extracttemplates is a useful utility in apt-utils. For a set of
udebs

  apt-extracttemplates -t $PWD *.udeb

will extract any templates files in the udebs.

  rm *.config.*

deletes unneeded files.

All that is needed for a "dictionary" is to tidy up the templates files.
Perhaps

  
https://wiki.debian.org/DebianInstaller/Preseed#Preseeding_and_the_installer.27s_debconf_templates

helps?

-- 
Brian.

Bug#884138: ffmpeg: scientific notation used for speed in progress bar

[James Cowgill]

Hi,

On 11/12/17 21:24, Thorsten Glaser wrote:
> Package: ffmpeg
> Version: 7:3.4-4+b2
> Severity: wishlist
> 
> size=   71457kB time=01:10:25.91 bitrate= 138.5kbits/s speed=1.4e+03x 
> 
> I guess my computer is just too fast for that task ☺ Command was:
> for x in *.mp4; do ffmpeg -i "$x" -vn -sn -c:a copy ./"${x%.mp4}.wma"; done
> So basically just switching containers (WMA is the only one that is
> streamable by “ssh otherbox cat foo | mplayer -”, neither M4A nor
> MPEG-TS are) and ditching all but the audio track.

I can also get this by piping silence into the null sink. It goes really
fast if you sent the sample rate stupidly low :)
$ ffmpeg -f lavfi -i anullsrc -f null -
size=N/A time=00:32:47.49 bitrate=N/A speed=1.34e+03x
$ ffmpeg -f lavfi -i anullsrc=r=1 -f null -
size=N/A time=18250:48:32.00 bitrate=N/A speed=5.45e+07x

The speed output is controlled by a printf format specifier here:
https://anonscm.debian.org/cgit/pkg-multimedia/ffmpeg.git/tree/fftools/ffmpeg.c?h=debian/7%253.4.1-1#n1806

I guess you want to change it to "%5.4gx" or something else? The point
where we change from normal to scientific notation is fairly arbitrary.

James



signature.asc
Description: OpenPGP digital signature

Bug#660718: [lintian] 01/01: Update description of python-script-but-no-python-dep to refer to pybuild. (Closes: #660718)

[Chris Lamb]

retitle 660718 Update description of python-script-but-no-python-dep to refer 
to Python 3.
thanks

Mattia Rizzolo wrote:

> > - Depends field and ensuring dh_python2 or dh_python3 are run during
> > - the build should take care of adding the correct dependency.
> > + Depends field and ensuring dh-python, dh_python2 or dh_python3 are run
>^
> dh-python (as in, the dh_python program) has been obsolated ages ago.
> Whilst it's true that dh_python3 is in the dh-python binary package, I
> wouldn't mention such technicality here, and instead only mention
> dh_python

[…]

> pybuild is a totally orthogonal tool that has nothing to do with
> dependency generation.

[…]

> Looking at the bug, the subject was about removing mentions of pycentral
> and pysupport in favour of dh_python[23], which was apparently already
> done at some point in the past.

Indeed, thank you for the explanation which I quote in full to the
corresponding bug.

> I recommend to just revert this commit and manually close the bug as
> "done at some point in the past already".
[…]
> I'd suggest to also mention ${python3:Depends} here if this tag also
> applies to py3.

I've done these in one go, retitling this bug to match in:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=332101d298b9a72fdb2da6e70daa4cd6d6e8a1ed


Regards,

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

Bug#880467: jasperreports: CVE-2017-14941, CVE-2017-5528, CVE-2017-5529

[Emmanuel Bourg]

Le 11/12/2017 à 19:49, Markus Koschany a écrit :

> You can refuse to
> work on it but please do not block other people from doing the right
> thing which is either to fix bugs or remove bit-rotting and broken
> software from Debian.

Huh?? I'm certainly not blocking anyone from fixing jasperreports or
libpam4j. I'm just putting the issues into perspective and trying to
convince you that there are more important things to do with our limited
resources. I failed, well, so be it. But please don't see that as
negative, I hold absolutely no grudge against your position, I'm
sincerely grateful that you invest so much time into the Debian Java
ecosystem and the security support. I'm just someone pragmatic that
likes doing things that make sense, and I feel concerned when someone is
about to spend a significant amount of time on something unnecessary
(not by the rules, but by the impact it'll have on actual users).


> If we can't even support the status quo then introducing new features
> and packages will only increase the burden. The reason why we struggle
> with big changes like Maven2->Maven3, Java8->Java9 is foremost the lack
> of manpower, lack of communication and lack of a strategy to minimize
> the brokenness in unstable. It has simply become too hard for
> contributors to keep up with the changes. When only a select few know
> why something is suddenly broken, chances are very slim that someone
> else will fix it.

Do you mean that I'm holding important information and that's why we
don't see more contributors joining the party? I don't think this is a
fair assessment. Look at the Java 9 transition, Chris posted the bug
list months ago and no new contributor showed since, we are just a
handful of regular contributors slowly fixing the bugs. For the Maven 3
transition I requested some help with plexus-utils2 last month and I got
absolutely nothing.


> A build-dependency is still a supported package by default and binary
> packages of libspring-java are also used as runtime dependencies. That
> also doesn't change the fact that it is mainly a web framework and no it
> is not silly to use software as such if it is provided in Debian.

I respectfully disagree. Depending on a Java library provided by the
operating system for someone doing cross-platform Java development is a
bad idea for many reasons :
- The application becomes non portable across operating systems.
- In addition to package formats, the developer has to deal with even
more OS specific details (Debian has version X, Ubuntu has Y, and Fedora
doesn't have it, dealing with that in a standard Maven build is not
trivial).
- It becomes more difficult to develop on another OS (for example
Windows) and deploy on Debian.
- More differences between platforms means even more QA work.
- For a given OS, it might be necessary to have version specific
packages (i.e. one for Debian 8 and another one for Debian 9). A
corollary is that the same package may not be used for both Debian and
Ubuntu.
- The application is tied to the version of the library in Debian which
can't be upgraded at will.
- Security support is nice but meaningless, since the developer has to
support other operating systems and upgrade its dependencies everywhere
anyway.

I can see some notable exceptions though:
- libraries intended to interact with a specific version of an
application in Debian. For example mysql-connector-java which is aligned
with the version of MySQL/MariaDB in Debian.
- libraries with a native part (like JNA or tomcat-native) since Debian
supports more architectures.


> We already have something like that in place.

Yes but nothing formalized, like a dedicated field at the package level
in debian/control, or another medium detached from the package that
could be queried and displayed to the users.


> There is also Jessie..and Wheezy and we need version > 6.4.1.
> Reverse-dependencies are not broken? I'm still not keen to backport
> jasperreports and given the current situation and this conversation I am
> not going to work on it.

The upgrade beyond 6.3.1 looks a bit more involved dependency wise. I'll
give it a try.

Emmanuel Bourg

Bug#769365: lintian: test for packages shipping dist-packages/tests/__init__.py

[Chris Lamb]

tags 769365 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=5e04193b2a92640c5e41616625df62103381938f


Regards,

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

Bug#831835: Workaround in progress: Browser Add-On

[nullius]

On 2017-11-18, 24...@secmail.pro wrote:

CloudFlare's MITM activity is widely discussed in the Tor Project ticket.
This bug is mentioned on this webpage:
https://trac.torproject.org/projects/tor/ticket/24351


I am the reporter of that bug, titled "Block Global Active Adversary 
Cloudflare".  Though this is an issue which has concerned me for years, 
I thank the anonymous reporter of this Debian bug for part of my 
inspiration.


An anonymous cypherpunk created a Firefox add-on to block Cloudflare:

https://addons.mozilla.org/en-US/firefox/addon/block-cloudflare-mitm-attack/

I lifted out the code into a Github repository:

https://github.com/nym-zone/block_cloudflare_mitm_fx

Commits are signed with the same PGP key as this e-mail, fingerprint:
0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C

Please note that I have not yet actually tested the code.  a.m.o. marks 
it as Firefox 53+ only; whereas I exclusively use Tor Browser, based on 
Firefox 52.  I did glance over the code to see if it looked sane, and 
normalize the PNG icons to fix some CRC errors.  Beyond that, I deemed 
it most important to get the ball rolling with a public repository so 
people can hack on it.


Contributions will be much appreciated.  As I indicated in the Tor bug 
tracker, I hope to see the beginnings of a grassroots community response 
to the Cloudflare mass-MITM threat.


null...@nym.zone


signature.asc
Description: PGP signature

Bug#884141: gdm3 fails to start, no log info

[Jan Medlock]

Package: gdm3
Version: 3.26.2.1-2
Severity: normal

Dear Maintainer,
gdm3 fails to start.  It worked fine until several weeks ago, when
some update broke things.  (I've tried rolling back a few packages
with no success.)  There is very little information in the logs.  Any
suggestions for debugging this would be appreciated.


$ systemctl status gdm
● gdm.service - GNOME Display Manager
   Loaded: loaded (/lib/systemd/system/gdm.service; static; vendor preset: enabl
   Active: inactive (dead) since Mon 2017-12-11 13:43:28 PST; 26min ago
 Main PID: 3610 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 6144)
   CGroup: /system.slice/gdm.service

Dec 11 13:05:38 barney systemd[1]: Starting GNOME Display Manager...
Dec 11 13:05:38 barney systemd[1]: Started GNOME Display Manager.
Dec 11 13:43:28 barney systemd[1]: Stopping GNOME Display Manager...
Dec 11 13:43:28 barney gdm3[3610]: GLib: g_variant_new_string: assertion 'string
Dec 11 13:43:28 barney gdm3[3610]: GLib: g_hash_table_find: assertion 'version =
Dec 11 13:43:28 barney systemd[1]: Stopped GNOME Display Manager.


No log is created in /var/lib/gdm3.


Thanks,
Jan Medlock


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

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

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.45-1
ii  adduser   3.116
ii  dconf-cli 0.26.1-1
ii  dconf-gsettings-backend   0.26.1-1
ii  debconf [debconf-2.0] 1.5.65
ii  gir1.2-gdm-1.03.26.2.1-2
ii  gnome-session [x-session-manager] 3.26.1-1
ii  gnome-session-bin 3.26.1-1
ii  gnome-settings-daemon 3.26.2-1
ii  gnome-shell   3.26.2-1
ii  gnome-terminal [x-terminal-emulator]  3.26.2-1
ii  gsettings-desktop-schemas 3.24.1-1
ii  libaccountsservice0   0.6.45-1
ii  libaudit1 1:2.8.1-2
ii  libc6 2.25-3
ii  libcanberra-gtk3-00.30-5
ii  libcanberra0  0.30-5
ii  libgdk-pixbuf2.0-02.36.11-1
ii  libgdm1   3.26.2.1-2
ii  libglib2.0-0  2.54.2-1
ii  libglib2.0-bin2.54.2-1
ii  libgtk-3-03.22.26-2
ii  libkeyutils1  1.5.9-9.2
ii  libpam-modules1.1.8-3.6
ii  libpam-runtime1.1.8-3.6
ii  libpam-systemd235-3
ii  libpam0g  1.1.8-3.6
ii  librsvg2-common   2.40.18-2
ii  libselinux1   2.7-2
ii  libsystemd0   235-3
ii  libwrap0  7.6.q-27
ii  libx11-6  2:1.6.4-3
ii  libxau6   1:1.0.8-1+b2
ii  libxcb1   1.12-1
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  9.20170808
ii  metacity [x-window-manager]   1:3.26.0-1
ii  mutter [x-window-manager] 3.26.2-1
ii  policykit-1   0.105-18
ii  ucf   3.0036
ii  x11-common1:7.7+19
ii  x11-xserver-utils 7.7+7+b1
ii  xterm [x-terminal-emulator]   330-1

Versions of packages gdm3 recommends:
ii  at-spi2-core2.26.2-2
ii  desktop-base9.0.5
ii  x11-xkb-utils   7.7+3+b1
ii  xserver-xephyr  2:1.19.5-1
ii  xserver-xorg1:7.7+19
ii  zenity  3.26.0-1

Versions of packages gdm3 suggests:
ii  gnome-orca3.26.0-2
pn  libpam-fprintd
ii  libpam-gnome-keyring  3.20.1-1

-- debconf information:
  gdm3/daemon_name: /usr/sbin/gdm3
* shared/default-x-display-manager: sddm

Bug#884127: Fails to sign modules for CONFIG_MODULES_SIG_FORCE

[Elliott Mitchell]

On Mon, Dec 11, 2017 at 08:42:12PM +0100, Andreas Beckmann wrote:
> Control: tag -1 help
> 
> On 2017-12-11 19:17, Elliott Mitchell wrote:
> > If CONFIG_MODULES_SIG_FORCE=y is set, then kernel modules are required
> > to be signed.  The nvidia-kernel-source package fails to implement this
> > step and as such cannot be made to work with a kernel configured that
> > way.  This is normally done in the modules_install target, or can be done
> > according to the instructions in Documentation/module-signing.txt.
> 
> Patches welcome.
> 
> I wont have the time to dig into this and come up with a solution. But
> if someone can provie an initial patch, I'll look how to integrate it.

Documentation/module-signing.txt is pretty narrow focused and thus easy
to spot the key point.

Most likely you simply run:
scripts/sign-file $(CONFIG_MODULE_SIG_HASH) $(O)/signing_key.priv
$(O)/signing_key.x509 nvidia.ko

During building the package if $(CONFIG_MODULE_SIG) is true.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#883977: *** stack smashing detected ***: evolution terminated

[Michael Biebl]

On Sat, 09 Dec 2017 18:01:35 -0500 Joachim Breitner 
wrote:
> Hi,
> 
> rebuilding evolution fixes the problem for me.
> 
> Maybe re-assign to evolution?


That's most likely a result of the uncoordinated libical3 transition /
NMU of evolution-data-server.

Jeremy did sourceful uploads of evo and eds and other rdeps of libical
were binNMUed, so I guess this should be fixed after the next update.

-- 
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#883938: Bug #883938: linux-image-3.16.0-4-amd64: Kernel panic on boot after upgrading to debian 8.10 kernel 3.16.51

[Heiko Schlittermann]

The provided work-around (setting numa=off) worked here.
Do you need further information about the system in use?

BTW: Thank you for the NUMA advice, it was about 21.00 CET when
I started a search engine and found the bug entry and the suggested
work-around, so, your advice came just in time.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
-- 
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -
 ! key id 7CBF764A and 972EAC9F are revoked since 2015-01  -


signature.asc
Description: PGP signature

Bug#883938: linux-image-3.16.0-4-amd64: Kernel panic on boot after upgrading to debian 8.10 kernel 3.16.51

[Salvatore Bonaccorso]

Hi Ben,

On Mon, Dec 11, 2017 at 09:47:49PM +, Ben Hutchings wrote:
> On Mon, 2017-12-11 at 21:29 +, Ben Hutchings wrote:
> > There were several commits interspersed with sched/topology fixes
> > upstream that I thought were cleanup and therefore didn't backport to
> > the 3.16 stable branch.  Now I suspect that at least some of them are
> > needed.
> > 
> > I'm attaching backports of 3 of the commits that I left out.  Can you
> > test whether they fix the regression for you?

I built v3.16.51 with the three patches on top, and looks good I have
not seen any further problems with those.

Regards,
Salvatore

Bug#884140: Kernel 3.16.51-2 general protection fault in sched_init_smp()

[Damien Dejean]

Package: linux-image
Version: 3.16.0-4-amd64

Since the update from version 3.16.43 to 3.16.51-2 the kernel crashes
during the boot (Dell Inc. PowerEdge 2970 with 2 Quad-Core AMD
Opteron(tm) Processor 2350).

We are using Debian GNU/Linux 8, here is the kernel log we collected on
our server:

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.16.0-4-amd64
(debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) )
#1 SMP Debian 3.16.51-2 (2017-12-03)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64
root=UUID=eb8d5ccd-a904-458a-9b58-1555dbd03c95 ro console=tty0
console=ttyS0,115800
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009] usable
[0.00] BIOS-e820: [mem 0x0010-0xbfab] usable
[0.00] BIOS-e820: [mem 0xbfac-0xbfad5fff]
reserved
[0.00] BIOS-e820: [mem 0xbfad6000-0xbfaf5bff]
ACPI data
[0.00] BIOS-e820: [mem 0xbfaf5c00-0xbfff]
reserved
[0.00] BIOS-e820: [mem 0xf000-0xf7ff]
reserved
[0.00] BIOS-e820: [mem 0xfe00-0x]
reserved
[0.00] BIOS-e820: [mem 0x0001-0x00043fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] AGP: No AGP bridge found
[0.00] e820: last_pfn = 0x44 max_arch_pfn = 0x4
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new
0x7010600070106
[0.00] e820: last_pfn = 0xbfac0 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000fe710-0x000fe71f] mapped
at [880fe710]
[0.00] Using GB pages for direct mapping
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00] init_memory_mapping: [mem 0x43fe0-0x43fff]
[0.00] init_memory_mapping: [mem 0x43c00-0x43fdf]
[0.00] init_memory_mapping: [mem 0x4-0x43bff]
[0.00] init_memory_mapping: [mem 0x0010-0xbfab]
[0.00] init_memory_mapping: [mem 0x1-0x3]
[0.00] RAMDISK: [mem 0x36198000-0x370c3fff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F22A0 24 (v02 DELL  )
[0.00] ACPI: XSDT 0x000F231C 8C (v01 DELL   PE_SC3
0001 DELL 0001)
[0.00] ACPI: FACP 0xBFAF1BD8 F4 (v03 DELL   PE_SC3
0001 DELL 0001)
[0.00] ACPI: DSDT 0xBFAD6000 00476A (v01 DELL   PE_SC3
0001 INTL 20050624)
[0.00] ACPI: FACS 0xBFAF4400 40
[0.00] ACPI: FACS 0xBFAF4400 40
[0.00] ACPI: APIC 0xBFAF1878 A0 (v01 DELL   PE_SC3
0001 DELL 0001)
[0.00] ACPI: SPCR 0xBFAF191C 50 (v01 DELL   PE_SC3
0001 DELL 0001)
[0.00] ACPI: HPET 0xBFAF1970 38 (v01 DELL   PE_SC3
0001 DELL 0001)
[0.00] ACPI: MCFG 0xBFAF19AC 3C (v01 DELL   PE_SC3
0001 DELL 0001)
[0.00] ACPI: SLIC 0xBFAF19EC 24 (v01 DELL   PE_SC3
0001 DELL 0001)
[0.00] ACPI: ERST 0xBFADA8EC 000210 (v01 DELL   PE_SC3
0001 DELL 0001)
[0.00] ACPI: HEST 0xBFADAAFC 00027C (v01 DELL   PE_SC3
0001 DELL 0001)
[0.00] ACPI: BERT 0xBFADA76C 30 (v01 DELL   PE_SC3
0001 DELL 0001)
[0.00] ACPI: EINJ 0xBFADA79C 000150 (v01 DELL   PE_SC3
0001 DELL 0001)
[0.00] ACPI: SRAT 0x000FC144 000150 (v01 DELL   PE_SC3
0001 DELL 0001)
[0.00] ACPI: SSDT 0xBFAF4800 30 (v01 DELL   PE_SC3
0001 DELL 0001)
[0.00] ACPI: TCPA 0xBFAF1B70 64 (v01 DELL   PE_SC3
0001 DELL 0001)
[0.00] SRAT: PXM 0 -> APIC 0x00 -> Node 0
[0.00] SRAT: PXM 0 -> APIC 0x01 -> Node 0
[0.00] SRAT: PXM 0 -> APIC 0x02 -> Node 0
[0.00] SRAT: PXM 0 -> APIC 0x03 -> Node 0
[0.00] SRAT: PXM 1 -> APIC 0x04 -> Node 1
[0.00] SRAT: PXM 1 -> APIC 0x05 -> Node 1
[0.00] SRAT: PXM 1 -> APIC 0x06 -> Node 1
[0.00] SRAT: PXM 1 -> APIC 0x07 -> Node 1
[0.00] SRAT: Node 0 PXM 0 [mem 0x-0x0009]
[0.00] SRAT: Node 0 PXM 0 [mem 0x0010-0xbfff]
[0.00] SRAT: Node 0 PXM 0 [mem 0x1-0x23fff]
[0.00] SRAT: Node 1 PXM 1 [mem 0x24000-0x43fff]
[0.00] NUMA: Node 0 [mem 0x-0x0009] + [mem
0x0010-0xbfff] -> [mem 0x-0xbfff]
[0.00] NUMA: Node 0 [mem 0x-0xbfff] + [mem
0x1-0x23fff] -> [mem 0x-0x23fff]
[0.00] Initmem setup node 0 [mem 0x-0x23fff]
[0.00]   NODE_DATA 

Bug#629161: lintian: Outdated groff version used on lintian.debian.org

[Chris Lamb]

Hi,

> lintian: Outdated groff version used on lintian.debian.org

Given that the corresponding bug (#717608) was fixed in groff 1.22.2-4
and even (!) jessie ships with 1.22.2-8 (stretch has 1.22.3-9), I
believe this bug can now be closed.


Regards,

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

Bug#660718: lintian: update information in python-script-but-no-python-dep

[Chris Lamb]

tags 660718 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=887e615f41d590ff6352896805e6744df3656611


Regards,

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

Bug#875572: unifont FTCBFS: many reasons

[Manuel A. Fernandez Montecelo]

Hi Paul,

2017-12-11 4:11 GMT+01:00 Paul Hardy :
> On Tue, Oct 31, 2017 at 1:52 PM, Manuel A. Fernandez Montecelo
>  wrote:
>> Control: tags -1 + pending
>
> I just want to note that this has not fallen off my radar.  I have
> already applied the patch in the upcoming version.
>
> I am hoping to provide a resolution to over 40 bug reports that
> someone has made against Unifont over the past few months on Savannah:
>
> https://savannah.gnu.org/bugs/?group=unifont
>
> I hope to get through most of those over the next month, and then
> provide an updated version for Debian.  I had worked through many more
> for the current Unifont release.
>
> This Debian bug was mentioned as being low priority, so I would like
> to submit the next release with as many updates as possible versus a
> "micro-release".
>
> I also recently helped the HarfBuzz maintainer identify a HarfBuzz
> bug.  HarfBuzz renders glyphs for Pango, which in turn renders text
> for GNOME.  I was not sure if there was something deep down in
> Unifont's structure that I would have to update, but that turns out
> not to be the case:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=787284
>
> If anyone does need this patch applied urgently, let me know and I
> will be able to fix it the following weekend.  Otherwise, I am
> planning for a Unifont update with a lot of glyph fixes.

If it was me I'd prefer micro-releases rather than macro-releases,
specially if they touch different aspects (upstream vs packaging), but
in any case, it's fine for me that you choose what you're more
comfortable with :)

On our side, the bug should low-ish priority, unless it's annoying and
prevenging ot difficulting the job of Helmut to build other rev-deps.

Lastly, thanks for the feedback!

-- 
Manuel A. Fernandez Montecelo 

Bug#884139: rsyslog-czmq: SIGSEGV in zcert_destroy() at rsyslogd exit

[Nachiketa Prachanda]

Package: rsyslog-czmq
Version: 8.24.0-1
Severity: important
Tags: patch


Dear Maintainer,

This crash at rsyslogd exit is fixed upstream and is included in 8.31.0

Upstream fix is in commit 666d2e1ce90c24448ec7319fe1ac90a37872fd6b
at https://github.com/rsyslog/rsyslog 

Please consider backporting this fix as the underlying issue is
critical. An inline patch is included.

Thanks,
Nachiketa Prachanda

Versions of packages rsyslog-czmq depends on:
ii  libc6 2.24-11+deb9u1
ii  libczmq4  4.0.2-7
ii  libzmq5   4.2.1-4
ii  rsyslog   8.24.0-1

rsyslog-czmq recommends no packages.


>From 666d2e1ce90c24448ec7319fe1ac90a37872fd6b Mon Sep 17 00:00:00 2001
From: Nachiketa Prachanda 
Date: Tue, 31 Oct 2017 13:48:49 -0700
Subject: [PATCH] imczmq: remove unallocated and unused pointer

Fix a SIGSEGV in a call to
371: zcert_destroy() called from rcvData().

- remove serverCert as it is only used uninitialized in a call
to zcert_destroy() - this causes a core dump at rsyslogd exit.
- also initialize authActor at definition.

Signed-off-by: Nachiketa Prachanda 
---
 contrib/imczmq/imczmq.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/contrib/imczmq/imczmq.c
+++ b/contrib/imczmq/imczmq.c
@@ -269,8 +269,7 @@ static rsRetVal rcvData(){
}
}
 
-   zactor_t *authActor;
-   zcert_t *serverCert;
+   zactor_t *authActor = NULL;
 
if(runModConf->authenticator == 1) {
authActor = zactor_new(zauth, NULL);
@@ -359,7 +358,6 @@ finalize_it:
}
zlist_destroy();
zactor_destroy();
-   zcert_destroy();
RETiRet;
 }
 

Bug#872339: libgda-5.0-4: Can't rebuild package with --with-ui

[Jeremy Bicha]

> ok, I was able to compile the package with ui support. Could you please
explain why this option was turned off?

Let me ask the question the other way around. Could you explain why
you want the ui option turned on now?

Thanks,
Jeremy Bicha

Bug#882684: lintian should complain about more abuses of Multi-Arch: foreign (cmake, pkg-config, static libraries)

[Chris Lamb]

Hi,

I made the certainty change of multiarch-foreign-shared-library from
"wild guess" to "possible" in a separate commit:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=f1954d20d665412bd3594da1e1319740bdf04a0d


Regards,

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

Bug#882684: lintian should complain about more abuses of Multi-Arch: foreign (cmake, pkg-config, static libraries)

[Chris Lamb]

tags 882684 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=942bdc0e1c6a38e12198a89d1f5278a8bd06a30f


Regards,

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

Bug#826069: [Debichem-devel] Bug#826069: Adding avogadro to med-bio or replacing ghemical by avogadro in med-bio task

[Michael Banck]

Hi,

On Thu, Dec 07, 2017 at 07:37:29PM +0100, Andreas Tille wrote:
> Consequently this triggers my next question:  Would you mind if I
> convert avogadro to Git as I have done with garlic and ghemical?

Fine with me.


Michael

Bug#881380: Adoption

[Filip Pytloun]

Hello,

I would like to adopt this package under DPMT.
Prepared repository and required changes:
ssh://git.debian.org/git/python-modules/packages/gerritlib.git

Waiting for review and initial upload.

Filip


signature.asc
Description: PGP signature

Bug#878498: snakemake FTBFS with Python 3.6 as default

[chrysn]

On Mon, Dec 11, 2017 at 03:45:50PM +0100, Andreas Tille wrote:
> > Will let you know when I'm through with those and all is pushed to
> > alioth again.

The current master passes build in a cowbuilder that has access to
python3-ratelimiter, and lintian's only serious complaints are the
privacy violations (JavsScript and badges in the documentation and some
web application templates -- Snakemake has a web application?) that have
been there in the old release too and I don't have a plan on how to fix
them yet.

The new test suite system patch-outs are for

* r-cran-rmarkdown (filed as #884115, thanks Andreas for ITP-ing), and
* google-cloud-sdk (quoting the patch description: Whether this needs
  a Debian RFP or should be forwarded is undecided yet given I have no
  clue about what those Google Cloud SDK actually does).

IMO that package state is an enhancement over the last one in the
archive and can be considered for upload, if one is willing to accept
the abovementioned lintian warnings.

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#884136: lilypond: CVE-2017-17523

[Don Armstrong]

Control: forward -1 https://sourceforge.net/p/testlilyissues/issues/5243/

On Mon, 11 Dec 2017, Salvatore Bonaccorso wrote:
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

Thanks! This is being addressed upstream in
https://sourceforge.net/p/testlilyissues/issues/5243/; as soon as there
is a fix there with review, we'll backport it.

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

What prison taught me was that some people are born into a life where
they're going to be subjected to intense life experiences and personal
tragedy on an almost daily basis. [...] I don't think you get
enlightenment after something like that. I think all anyone really
wants, if they're honest with themselves, is a quiet, easy life
surrounded by people that love them. Anything else is a conceit.
 -- OP from 99chan

Bug#883938: linux-image-3.16.0-4-amd64: Kernel panic on boot after upgrading to debian 8.10 kernel 3.16.51

[Ben Hutchings]

On Mon, 2017-12-11 at 21:29 +, Ben Hutchings wrote:
> There were several commits interspersed with sched/topology fixes
> upstream that I thought were cleanup and therefore didn't backport to
> the 3.16 stable branch.  Now I suspect that at least some of them are
> needed.
> 
> I'm attaching backports of 3 of the commits that I left out.  Can you
> test whether they fix the regression for you?
> 
> If this doesn't help, I think we may just have to revert the
> sched/topology fixes.

Sorry, the first patch should be this one and not
0001-sched-topology-Simplify-build_overlap_sched_groups.patch.

Ben.

-- 
Ben Hutchings
A free society is one where it is safe to be unpopular. - Adlai
Stevenson
From aae254d8033b9d41e7915dcb3fe3642336408171 Mon Sep 17 00:00:00 2001
From: Peter Zijlstra 
Date: Wed, 26 Apr 2017 17:36:41 +0200
Subject: [PATCH 1/3] sched/topology: Remove FORCE_SD_OVERLAP

commit af85596c74de2fd9abb87501ae280038ac28a3f4 upstream.

Its an obsolete debug mechanism and future code wants to rely on
properties this undermines.

Namely, it would be good to assume that SD_OVERLAP domains have
children, but if we build the entire hierarchy with SD_OVERLAP this is
obviously false.

Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings 
---
 kernel/sched/core.c | 2 +-
 kernel/sched/features.h | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 0940ee9603ae..0692ee2dd889 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6631,7 +6631,7 @@ static int build_sched_domains(const struct cpumask *cpu_map,
 			sd = build_sched_domain(tl, cpu_map, attr, sd, i);
 			if (tl == sched_domain_topology)
 *per_cpu_ptr(d.sd, i) = sd;
-			if (tl->flags & SDTL_OVERLAP || sched_feat(FORCE_SD_OVERLAP))
+			if (tl->flags & SDTL_OVERLAP)
 sd->flags |= SD_OVERLAP;
 			if (cpumask_equal(cpu_map, sched_domain_span(sd)))
 break;
diff --git a/kernel/sched/features.h b/kernel/sched/features.h
index 90284d117fe6..79bad00ea840 100644
--- a/kernel/sched/features.h
+++ b/kernel/sched/features.h
@@ -56,7 +56,6 @@ SCHED_FEAT(NONTASK_CAPACITY, true)
  */
 SCHED_FEAT(TTWU_QUEUE, true)
 
-SCHED_FEAT(FORCE_SD_OVERLAP, false)
 SCHED_FEAT(RT_RUNTIME_SHARE, true)
 SCHED_FEAT(LB_MIN, false)
 


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

Bug#884115: RFP: r-cran-rmarkdown -- GNU R tool to convert R Markdown documents into a variety of formats

[Andreas Tille]

control: retitle -1 ITP: r-cran-rmarkdown -- GNU R tool to convert R Markdown 
documents into a variety of formats

Hi,

I confirm that I retitled (now with correct spelling the bug to ITP and
pushed the preliminary packaging to

   https://anonscm.debian.org/git/debian-med/r-cran-rmarkdown.git

I admit this one is a really hard package not because of the R part but
rather due to lots of compressed JavaScript files without source.  I was
able to get rid of most of these by either using packaged versions or
providing the uncompressed source in debian/js.  Unfortunately I have no
idea where these two might come from:

E: r-cran-rmarkdown source: source-is-missing 
inst/rmd/ioslides/ioslides-13.5.1/js/polyfills/dataset.min.js
E: r-cran-rmarkdown source: source-is-missing 
inst/rmd/ioslides/ioslides-13.5.1/js/polyfills/history.min.js

I opened an issue at Github from where this code seems to be obtained

   https://github.com/pauldijou/ioslides/issues/2

but I have less hope that some response will come from there.
Admittedly my motivation to continue here is a bit burned for the next
couple of days - so if someone wants to do some websearch that would
be very welcome.

BTW, according to the original target snakemake:  I've pinged
ftpmaster on IRC and python-ratelimiter was accepted very soon
after this.  It seems we can upload the new version of snakemake
tomorrow. :-)

Chrysn, thanks for your work on this - please ping me if you
consider your work on snakemake as "finished and read for
sponsoring".

Kind regards

Andreas.


On Mon, Dec 11, 2017 at 04:14:46PM +0100, chrysn wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: r-cran-rmarkdown
>   Version : 1.8
>   Upstream Author : JJ Allaire, Yihui Xie et al
> * URL : http://rmarkdown.rstudio.com,
> 
> https://cran.r-project.org/web/packages/rmarkdown/index.html
> * License : GPL-3
>   Programming Lang: GNU R
>   Description : GNU R tool to convert R Markdown documents into a variety 
> of formats
> 
> R Markdown is a framework for creating documents that mix R code with
> markdown to produce visually pleasing, high quality and reproducible
> reports. It supports various output formats, including HTML, PDF,
> Microsoft Word and Beamer.
> 
> ---
> 
> The package is a soft reverse build dependency of Snakemake (which is
> currently patched to not execute the test in its test suite that depends
> on rmarkdown), and a quick search shows that other R packages in the
> archive could interact with it as well (eg. r-cran-fitbitscraper
> suggests it).
> 
> There is already the r-cran-markdown package whose description
> acknowledges rmarkdown as a "newer and enhanced version of this markdown
> package".



-- 
http://fam-tille.de

Bug#812682: w3m FTCBFS: uses build architecture compiler

[Manuel A. Fernandez Montecelo]

Hi,

2017-10-31 20:43 Manuel A. Fernandez Montecelo:

Hi

2016-01-25 22:02 Helmut Grohne:

Source: w3m
Version: 0.5.3-26
User: heml...@debian.org


Helmut: wrong user...



Usertags: rebootstrap

Hi,

w3m fails to cross build from source for a number of reasons. Most
immediately, configure is run without --host and thus configures for the
build architecture. Even though configure has code for detecting the
name of pkg-config, it still falls back to calling it directly causing
it to miss libraries such as imlib2. I am attaching a patch for these
issues. Even after applying it, the build fails due to executing
./mknames. Since mknames is executed during build and not installed into
any package, it should be compiled with the build architecture compiler.
For this to work, it needs to stop #including things such as config.h
however. Also object files such as Str.o need to be built for both
architectures. I haven't figured out the details yet, so my patch is
only a partial solution. Hope it helps whomever is looking into cross
compiling w3m at a later time.


Tatsuya, what do you think about applying this fix?

Lots of packages build-depent on w3m (x11proto* and basic X libraries,
mutt...), it would be nice to be able to cross-build it from other
systems, for bootstrapping new architectures and similar scenarios.

Cheers.


I just uploaded an NMU with the patch applied, to delayed/15.  I pushed
the changes to the repository.

If you disagree, please tell me and I can cancel the NMU, and can revert
the changes as well; or you can do it yourself if you prefer.

If it's OK for you, I can re-schedule it to happen sooner.

Let's hope that this push helps to move things forward to make possible
to cross-compile this important package :)


Cheers and thanks for maintaining this package!

--
Manuel A. Fernandez Montecelo 

Bug#883938: linux-image-3.16.0-4-amd64: Kernel panic on boot after upgrading to debian 8.10 kernel 3.16.51

[Ben Hutchings]

There were several commits interspersed with sched/topology fixes
upstream that I thought were cleanup and therefore didn't backport to
the 3.16 stable branch.  Now I suspect that at least some of them are
needed.

I'm attaching backports of 3 of the commits that I left out.  Can you
test whether they fix the regression for you?

If this doesn't help, I think we may just have to revert the
sched/topology fixes.

Ben.

-- 
Ben Hutchings
A free society is one where it is safe to be unpopular. - Adlai
Stevenson

From: Peter Zijlstra 
Date: Fri, 14 Apr 2017 17:32:07 +0200
Subject: sched/topology: Simplify build_overlap_sched_groups()
Origin: https://git.kernel.org/linus/91eaed0d61319f58a9f8e43d41a8cbb069b4f73d

Now that the first group will always be the previous domain of this
@cpu this can be simplified.

In fact, writing the code now removed should've been a big clue I was
doing it wrong :/

Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.16: adjust filename, context]
---
 kernel/sched/topology.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 921dedde2ee1..6b10e0a956c7 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -557,7 +557,7 @@ static void init_overlap_sched_group(struct sched_domain *sd,
 static int
 build_overlap_sched_groups(struct sched_domain *sd, int cpu)
 {
-	struct sched_group *first = NULL, *last = NULL, *groups = NULL, *sg;
+	struct sched_group *first = NULL, *last = NULL, *sg;
 	const struct cpumask *span = sched_domain_span(sd);
 	struct cpumask *covered = sched_domains_tmpmask;
 	struct sd_data *sdd = sd->private;
@@ -587,15 +587,6 @@ build_overlap_sched_groups(struct sched_domain *sd, int cpu)
 
 		init_overlap_sched_group(sd, sg);
 
-		/*
-		 * Make sure the first group of this domain contains the
-		 * canonical balance cpu. Otherwise the sched_domain iteration
-		 * breaks. See update_sg_lb_stats().
-		 */
-		if ((!groups && cpumask_test_cpu(cpu, sg_span)) ||
-		group_balance_cpu(sg) == cpu)
-			groups = sg;
-
 		if (!first)
 			first = sg;
 		if (last)
@@ -603,7 +594,7 @@ build_overlap_sched_groups(struct sched_domain *sd, int cpu)
 		last = sg;
 		last->next = first;
 	}
-	sd->groups = groups;
+	sd->groups = first;
 
 	return 0;
 
From 5727151be2afd55868244c2621ce0e350eecdc8d Mon Sep 17 00:00:00 2001
From: Peter Zijlstra 
Date: Fri, 14 Apr 2017 17:32:07 +0200
Subject: [PATCH 2/3] sched/topology: Simplify build_overlap_sched_groups()

commit 91eaed0d61319f58a9f8e43d41a8cbb069b4f73d upstream.

Now that the first group will always be the previous domain of this
@cpu this can be simplified.

In fact, writing the code now removed should've been a big clue I was
doing it wrong :/

Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings 
---
 kernel/sched/core.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 0692ee2dd889..68bc1bf9f5ab 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5869,7 +5869,7 @@ static void init_overlap_sched_group(struct sched_domain *sd,
 static int
 build_overlap_sched_groups(struct sched_domain *sd, int cpu)
 {
-	struct sched_group *first = NULL, *last = NULL, *groups = NULL, *sg;
+	struct sched_group *first = NULL, *last = NULL, *sg;
 	const struct cpumask *span = sched_domain_span(sd);
 	struct cpumask *covered = sched_domains_tmpmask;
 	struct sd_data *sdd = sd->private;
@@ -5899,15 +5899,6 @@ build_overlap_sched_groups(struct sched_domain *sd, int cpu)
 
 		init_overlap_sched_group(sd, sg);
 
-		/*
-		 * Make sure the first group of this domain contains the
-		 * canonical balance cpu. Otherwise the sched_domain iteration
-		 * breaks. See update_sg_lb_stats().
-		 */
-		if ((!groups && cpumask_test_cpu(cpu, sg_span)) ||
-		group_balance_cpu(sg) == cpu)
-			groups = sg;
-
 		if (!first)
 			first = sg;
 		if (last)
@@ -5915,7 +5906,7 @@ build_overlap_sched_groups(struct sched_domain *sd, int cpu)
 		last = sg;
 		last->next = first;
 	}
-	sd->groups = groups;
+	sd->groups = first;
 
 	return 0;
 
From 10f83418ab83f5d4ff5f7bc53cbd3f9455981186 Mon Sep 17 00:00:00 2001
From: Lauro Ramos Venancio 
Date: Thu, 20 Apr 2017 16:51:40 -0300
Subject: [PATCH 3/3] sched/topology: 

Bug#884138: ffmpeg: scientific notation used for speed in progress bar

[Thorsten Glaser]

Package: ffmpeg
Version: 7:3.4-4+b2
Severity: wishlist

size=   71457kB time=01:10:25.91 bitrate= 138.5kbits/s speed=1.4e+03x 

I guess my computer is just too fast for that task ☺ Command was:
for x in *.mp4; do ffmpeg -i "$x" -vn -sn -c:a copy ./"${x%.mp4}.wma"; done
So basically just switching containers (WMA is the only one that is
streamable by “ssh otherbox cat foo | mplayer -”, neither M4A nor
MPEG-TS are) and ditching all but the audio track.


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

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages ffmpeg depends on:
ii  libavcodec577:3.4-4
ii  libavdevice57   7:3.4-4+b2
ii  libavfilter67:3.4-4
ii  libavformat57   7:3.4-4
ii  libavresample3  7:3.4-4
ii  libavutil55 7:3.4-4
ii  libc6   2.25-3
ii  libpostproc54   7:3.4-4
ii  libsdl2-2.0-0   2.0.7+dfsg1-3
ii  libswresample2  7:3.4-4
ii  libswscale4 7:3.4-4

ffmpeg recommends no packages.

Versions of packages ffmpeg suggests:
pn  ffmpeg-doc  

-- no debconf information

Bug#884020: python3-sphinx: versioned dependency on jinja2 is too loose

[Dmitry Shachnev]

Hi Sandro!

On Sun, Dec 10, 2017 at 09:59:27AM -0500, Sandro Tosi wrote:
> Hello,
> i had an outdated version on jinja2 on my machine (2.9.5-1) and when building 
> a
> package i got the error:
>
>   Error: The 'jinja2.asyncsupport' module cannot be found. Did you install
>   Sphinx and its dependencies correctly?
>
> after upgrading python3-jinja2 to 2.10-1, the error went away.
>
> Python3-sphinx declare this dep on jinja2: 'python3-jinja2 (>= 2.3)', probably
> you need a tigher one

Sphinx does not use jinja2.asyncsupport, and it should work fine with older
versions of Jinja2. What you are experiencing looks like bug #862699, which
was fixed in Jinja2 2.9.6-1.

If you agree with me, please close this bug.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#884137: telegram-desktop: new upstream version

[Rogério Brito]

Package: telegram-desktop
Severity: wishlist

Hi.

Version 1.2 has been released:

https://github.com/telegramdesktop/tdesktop/releases/tag/v1.2.0

Please, consider packaging it.


Thanks,

Rogério.


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

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

Versions of packages telegram-desktop depends on:
ii  libavcodec-extra57   7:3.4-4
ii  libavformat577:3.4-4
ii  libavutil55  7:3.4-4
ii  libc62.25-3
ii  libgcc1  1:7.2.0-16
ii  libglib2.0-0 2.54.1-1
ii  libminizip1  1.1-8+b1
ii  libopenal1   1:1.17.2-4+b2
ii  libqt5core5a [qtbase-abi-5-9-2]  5.9.2+dfsg-6
ii  libqt5gui5   5.9.2+dfsg-6
ii  libqt5network5   5.9.2+dfsg-6
ii  libqt5widgets5   5.9.2+dfsg-6
ii  libssl1.11.1.0g-2
ii  libstdc++6   7.2.0-16
ii  libswresample2   7:3.4-4
ii  libswscale4  7:3.4-4
ii  libtgvoip1.0 1.0~git20170704.445433f-4
ii  libx11-6 2:1.6.4-3
ii  qt5-image-formats-plugins5.9.2-2
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages telegram-desktop recommends:
ii  libappindicator10.4.92-5
ii  libappindicator3-1  0.4.92-5

telegram-desktop suggests no packages.

-- no debconf information

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#883938: linux-image-3.16.0-4-amd64: Kernel panic on boot after upgrading to debian 8.10 kernel 3.16.51

[Salvatore Bonaccorso]

Hi

here the bisect log (unless overseen something with the last good commit):

git bisect start
# good: [3717265153a66c2ecbd745ea8eef213289b4a55e] Linux 3.16.48
git bisect good 3717265153a66c2ecbd745ea8eef213289b4a55e
# bad: [c45c05f42d5d3baf5d18e648c064788381fcfa1c] Linux 3.16.51
git bisect bad c45c05f42d5d3baf5d18e648c064788381fcfa1c
# bad: [36284647e2096b8bcc238772b644151967a5189b] parisc: pci memory bar 
assignment fails with 64bit kernels on dino/cujo
git bisect bad 36284647e2096b8bcc238772b644151967a5189b
# bad: [bfc20d54acae250fde0c8d56fc57fd41ea6dbe99] Revert "ACPI / EC: Add 
support to disallow QR_EC to be issued before completing previous QR_EC"
git bisect bad bfc20d54acae250fde0c8d56fc57fd41ea6dbe99
# bad: [b657f2742871a071a015328ec45c26679998096c] PCI/PM: Restore the status of 
PCI devices across hibernation
git bisect bad b657f2742871a071a015328ec45c26679998096c
# bad: [6d8c76588c1b03d63c8b76eaabac7a537e2d6714] drm/msm/hdmi: Use bitwise 
operators when building register values
git bisect bad 6d8c76588c1b03d63c8b76eaabac7a537e2d6714
# bad: [95ac78eafd026fb38c38a8f312acdd6fd8aee747] kvm: x86: Guest BNDCFGS 
requires guest MPX support
git bisect bad 95ac78eafd026fb38c38a8f312acdd6fd8aee747
# bad: [54749559969963ea435013122941643a90f1c6b3] f2fs: load inode's flag from 
disk
git bisect bad 54749559969963ea435013122941643a90f1c6b3
# good: [49d4283d847987fccbd7c7ce8f59f0fd765702ff] sched/topology: Fix building 
of overlapping sched-groups
git bisect good 49d4283d847987fccbd7c7ce8f59f0fd765702ff
# bad: [5a7aba3f27f7262cc5fad1b85804ea0ad9f4275c] sched/topology: Fix 
overlapping sched_group_capacity
git bisect bad 5a7aba3f27f7262cc5fad1b85804ea0ad9f4275c
# bad: [00c978eada13e2cd1bc7da485e99ab5fb7c3418c] sched/topology: Fix 
overlapping sched_group_mask
git bisect bad 00c978eada13e2cd1bc7da485e99ab5fb7c3418c
# first bad commit: [00c978eada13e2cd1bc7da485e99ab5fb7c3418c] sched/topology: 
Fix overlapping sched_group_mask

With 00c978eada13e2cd1bc7da485e99ab5fb7c3418c the systems boots, but warns
once:

cut-cut-cut-cut-cut-cut-
[...]
[1.958685] smpboot: CPU0: Quad-Core AMD Opteron(tm) Processor 2356 (fam: 
10, model: 02, steppi
ng: 03)
[2.176232] Performance Events: AMD PMU driver.
[2.230503] ... version:0
[2.278424] ... bit width:  48
[2.327396] ... generic registers:  4
[2.375308] ... value mask: 
[2.438837] ... max period: 7fff
[2.502353] ... fixed-purpose events:   0
[2.550271] ... event mask: 000f
[2.615975] NMI watchdog: enabled on all CPUs, permanently consumes one 
hw-PMU counter.
[2.711926] x86: Booting SMP configuration:
[2.761931]  node  #0, CPUs:#1  #2  #3
[2.859347]  node  #1, CPUs:#4  #5  #6  #7
[3.064352] x86: Booted up 2 nodes, 8 CPUs
[3.115572] smpboot: Total of 8 processors activated (36803.45 BogoMIPS)
[3.200017] [ cut here ]
[3.255328] WARNING: CPU: 0 PID: 1 at kernel/sched/core.c:5807 
build_sched_domains+0x7da/0xc80()
[3.360528] Modules linked in:
[3.397169] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.48+ #10
[3.471097] Hardware name: Sun Microsystems Sun Fire X4140/Sun Fire 
X4140, BIOS 0ABMN068 10/26/2009
[3.583508]   81514999  
0009
[3.672426]  810699f7 88021d699598 88021d69ab40 
88021d69ab58
[3.761306]   88041db520c0 8109bb0a 

[3.850185] Call Trace:
[3.879420]  [] ? dump_stack+0x5d/0x78
[3.942942]  [] ? warn_slowpath_common+0x77/0x90
[4.016855]  [] ? build_sched_domains+0x7da/0xc80
[4.091806]  [] ? sched_init_smp+0x38b/0x444
[4.161558]  [] ? mutex_lock+0xe/0x30
[4.224020]  [] ? put_online_cpus+0x23/0x90
[4.292744]  [] ? stop_machine+0x2c/0x40
[4.358340]  [] ? kernel_init_freeable+0x106/0x207
[4.434331]  [] ? rest_init+0x80/0x80
[4.496793]  [] ? kernel_init+0xa/0xf0
[4.560319]  [] ? ret_from_fork+0x58/0x90
[4.626955]  [] ? rest_init+0x80/0x80
[4.689436] ---[ end trace 4340fcfda5f7e5a6 ]---
[4.745076] devtmpfs: initialized
[4.791668] PM: Registering ACPI NVS region [mem 0xd7fbe000-0xd7fe] 
(204800 bytes)
[4.886661] futex hash table entries: 8192 (order: 7, 524288 bytes)
[...]
cut-cut-cut-cut-cut-cut-

With the subsequent commit:

cut-cut-cut-cut-cut-cut-
[...]
[1.958675] smpboot: CPU0: Quad-Core AMD Opteron(tm) Processor 2356 (fam: 
10, model: 02, stepping: 03)
[2.176232] Performance Events: AMD PMU driver.
[2.230510] ... version:0
[2.278440] ... bit width:  48
[2.327401] ... generic registers:  4
[2.375315] ... value mask: 
[ 

Bug#883419: python3-requests: RequestsDependencyWarning urllib3 (1.21.1) or chardet (2.3.0) doesn't match a supported version

[xiscu]

Hi Daniele,

> 
> As far I can see from the warning, it seems that you are using a local 
> installed version of requests. Are you mixing system packages with local 
> installed one? This use case is not supported on Debian, can you use a 
> virtualenv instead?
thanks for the hint: it got mixed; I'll go with virtualenv. After fixing
the issue locally, the warning is gone, so please feel free to close the
bug report.

Regards,
xiscu

Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)

[Luca Boccassi]

On Wed, 2017-12-06 at 11:37 +0100, Andreas Beckmann wrote:
> On 2017-12-06 10:53, Julien Aubin wrote:
> > Okay I will try it. Could you please provide me the build guide and
> > install
> > guide ?
> 
> From README.source:
> 
> Building "bleeding edge" from SVN for users
> 
> As new upstream versions of the proprietary driver are released,
> upload
> might not happen immediately. This might be for various reasons,
> including
> waiting for new binary packages to clear the NEW queue.
> Users wishing to try to build new version locally can follow the
> instructions on the Debian wiki:
> 
> https://wiki.debian.org/NvidiaGraphicsDrivers#Building_newer_rele
> ases_from_SVN
> 
> WARNING: these will most likely be work in progress, and the
> final upload
> may be different and may not support clean upgrades from/to the
> versions
> uploaded in the archive.
> 
> 
> In your case, it is branches/384-stretch-backports.
> 
> Please let us know about any issues you encounter with these
> instructions.
> 
> 
> Andreas

BTW I've been running the packages built from 384-stretch-backports on
my desktop and I haven't encountered issues.

-- 
Kind regards,
Luca Boccassi

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

Bug#883156: version 1.1

[Samuel Thibault]

Hello,

Paolo Greppi, on lun. 11 déc. 2017 06:48:34 +0100, wrote:
> Il 10/12/2017 21:16, Samuel Thibault ha scritto:
> > Paolo Greppi, on lun. 04 déc. 2017 18:24:46 +0100, wrote:
> >> P.S. IMHO it would make sense to separate the libttspico-utils binary 
> >> package from the svox source package.
> >> In this way it would have its own version number, plus the code would not 
> >> be in a patch 
> >> but in plaintext.
> > 
> > Indeed, it makes a lot of sense, it "just needs" to be done, any taker ? :)
> > (it means: submitting the ITP, setting up a repo on alioth for the
> > debian packaging, writing the packaging bits, and upload. I can quickly
> > do the last step if all the previous steps are done).
> 
> I can do the ITP and the packaging.

Cool :)

> I propose to name the new source pico2wave.
> It would produce a new binary pico2wave and a transitional libttspico-utils 
> as per:
> https://wiki.debian.org/RenamingPackages

Yep, sure!

> Re. the repo on alioth, as a DM I can not write in 
> git.debian.org:/git/collab-maint
> so somebody should create the pico2wave.git directory in there and assign the 
> owner to paolog-guest.
> Or we place the repo somewhere else.

I have added you to the tts alioth project, so you should be able to put
it in /git/tts/

Thanks for your future work ;)
Samuel

Bug#884134: python-rpy: Incompatible with the version of R in stretch

[Dirk Eddelbuettel]

On 11 December 2017 at 19:37, Matthew Woodcraft wrote:
| Package: python-rpy
| Version: 1.0.3-30
| Severity: grave
| 
| Installing and importing the stretch version of python-rpy fails with the
| stretch version of R:
| 
| «
| apt install python-rpy
| python
| Python 2.7.13 (default, Nov 24 2017, 17:33:09)
| [GCC 6.3.0 20170516] on linux2
| Type "help", "copyright", "credits" or "license" for more information.
| >>> import rpy
| Traceback (most recent call last):
|   File "", line 1, in 
|   File "/usr/lib/python2.7/dist-packages/rpy.py", line 134, in 
| """ % RVERSION)
| RuntimeError: No module named _rpy3033
| 
|   RPy module can not be imported. Please check if your rpy
|   installation supports R 3.3.3. If you have multiple R versions
|   installed, you may need to set RHOME before importing rpy. For
|   example:
| 
|   >>> from rpy_options import set_options
|   >>> set_options(RHOME='c:/progra~1/r/rw2011/')
|   >>> from rpy import *
| »
| 
| I see python-rpy is providing _rpy3011.so, not _rpy3033.so .

It's probably been time to retire rpy a few times over by now. It has been
unmaintained upstream for a decade or longer.

I also maitain rpy2, which recently switched to support python3 only so a
"maintained fork" of rpy2 for python2, frozen at the last such version, also
exists.

Dirk


| 
| 
| -- System Information:
| Debian Release: 9.3
|   APT prefers stable-updates
|   APT policy: (500, 'stable-updates'), (500, 'stable')
| Architecture: amd64 (x86_64)
| 
| Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
| Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
| Shell: /bin/sh linked to /bin/dash
| Init: systemd (via /run/systemd/system)
| 
| Versions of packages python-rpy depends on:
| ii  libc6 2.24-11+deb9u1
| ii  python2.7.13-2
| ii  python-numpy [python-numpy-abi9]  1:1.12.1-3
| ii  r-base-core   3.3.3-1
| 
| python-rpy recommends no packages.
| 
| Versions of packages python-rpy suggests:
| pn  python-rpy-docs  
| 
| -- no debconf information

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#884136: lilypond: CVE-2017-17523

[Salvatore Bonaccorso]

Source: lilypond
Version: 2.18.2-4
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for lilypond.

For a description of the issue see [1], in the "Similar
vulnerabilities in other packages" section.

CVE-2017-17523[0]:
| lilypond-invoke-editor in LilyPond 2.19.80 does not validate strings
| before launching the program specified by the BROWSER environment
| variable, which allows remote attackers to conduct argument-injection
| attacks via a crafted URL, as demonstrated by a --proxy-pac-file
| argument.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-17523
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17523
[1] https://bugs.debian.org/881767

Regards,
Salvatore

Bug#882761: ITP: opencascade -- Open CASCADE Technology is a suite for 3D surface and solid modeling

[Tobias Frost]

Hi Kurt,

many thanks for this ITP! I guess now I understand why FreeCAD is
sometime chokes on some models Debian :-/ 

As I use FreeCAD a lot, I also offer to lend a helping hand if desired
or if you need a sponsor for uploading when ready.
I can certanly also help on the topics brought by Anton..

Cheers,

--
tobi

On Sat, 2 Dec 2017 10:10:40 +0100 Anton Gladky 
wrote:
> Hi,
> 
> from my point of view it is OK to switch to the original opencascade
> implementation.
> But one need:
> 
> - be sure that the all oce-dependent packages can be built against
opencascade
> - double check the licenses of all files.
> 
> It is a good time right now to do such large package transition
because
> we have about 1 year to finish it before the Debian will be frozen
before
> the next release.
> 
> There is even an old git-repo [1] which you can use for opencascade.
> Feel free to join Debian science team to get an access to it.
> 
> PS Also I am looking for a freecad co-maintainer or somebody who can
> take over this and dependent package.
> 
> [1] https://anonscm.debian.org/cgit/debian-science/packages/opencasca
de.git
> 
> Best regards
> 
> Anton
> 
> 
> 2017-11-30 19:57 GMT+01:00  :
> > Hello Anton & Debian Science Team:
> >
> >
> > On Mon, 2017-11-27 at 19:36 +0100, Anton Gladky wrote:
> >> Hi,
> >>
> >> thanks for intending to package opencascade! I would though
recommend
> >> not
> >> to have both versions (original and the fork) in Debian at the
same
> >> time.
> >>
> >> If you have good reasons to bring back original version, please
> >> contact Debian
> >> Science Team, which is maintaining oce (and actually FreeCAD) at
the
> >> moment.
> >> We will try to find a solution for that.
> >>
> >> Best regards
> >>
> >> Anton
> >>
> >
> > There is certainly good reason to bring back OpenCASCADE
(OCCT).  As I
> > mentioned, development of OCE has stalled considerably.  Take a
look at
> > both the contribution graph and current release of OCE [1].  The
> > current  OCE version, 0.18.2, released Aug 2017, is based upon OCCT
> > 6.9.1 which was released 2015-09-28. You can also take a look at
the
> > OCCT changelog for versions 7.0.0, 7.1.0, and 7.2.0 (which actually
is
> > released, this is not totally up-to-date) [2].  There are 196
upstream
> > tickets closed between OCE and OCCT (whether bugs fixed or features
> > added.)  There are at least 15 FreeCAD bugs resolved by OCCT > 7.
> >
> > Since OpenCASCADE acts as FreeCAD's geometry/topology kernel, good

Bug#883765: cups-client: Unsupported document-format "application/octet-stream".

[Brian Potkin]

For the attention of intrigeri:

Mathew's mail is in reply to

https://lists.debian.org/debian-printing/2017/12/msg00032.html

He and I have spent some time is looking at a number of issues he has
experienced with the printing system when upgrading from jessie to
buster. It looks like apparmor is involved. I do not experience them.


On Mon 11 Dec 2017 at 22:28:15 +0530, P V Mathew wrote:

> as requested have reinstalled apparmor
> 
> The following programs are not working
> 
> man(from command line) but man2html ok
> 
> icedove - (double free error} ---bizarre? Using standalone download of
> thunderbird for this mail.
> 
> cups started on reboot but by the time logged in, it had stopped.
> 
> cups was restarted and command
> 
> lp -d PDF a.ps was used
> 
> the subject error returned.
> 
> but eventually cups stopped again.
> 
> dmesg showed some sort of infinite loop?
> 
> Oops. realize now, may be about 2-3 years ago when my var partition got
> full,
> 
> had moved the var/log on to /home/ and sym-linked to it in var. May be
> 
> this is not consistent with apparmor(not sure?).

When I do that I can still print but the error_log is not written to
because cupsd cannot change the permissions on /var/log/cups (as shown
by systemctl status cups after restarting cups).

> any way,  pieces of dmesg|grep cups attached.  Not possible to attach full
> 
> file as similar lines keeps repeating.
> 
> Please let me know if any more input is required.

Thanks, Mathew.

>From bb.bbz2:

[ 2121.775238] audit: type=1400 audit(1513009058.480:17316): apparmor="DENIED" \
   operation="chown" profile="/usr/sbin/cupsd" 
name="/home/log/cups/" \
   pid=5896 comm="cupsd" requested_mask="w" denied_mask="w" fsuid=0 
ouid=0   

[ 2121.775251] audit: type=1400 audit(1513009058.480:17317): apparmor="DENIED" \
   operation="capable" profile="/usr/sbin/cupsd" pid=5896 
comm="cupsd" \
   capability=12  capname="net_admin"

apparmor is new to buster and I am new to apparmor; but this looks like
cupsd has been refused write permission.

intrigeri is our lifeline for things apparmor, so I have cc'ed him (her?)
for advice.

Cheers,

Brian.

Bug#884135: qa.debian.org: UDD should honor comment-only watch file

[Paul Gevers]

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Multiple of my packages do not have a proper URL to watch. Lintian suggest to
add a watch file with comments, and uscan handles those gracefully. UDD
turns them into an error on line 106 in rimporters/upstream.rb.

Please improve UDD to treat "empty" watch files as they are meant to be by
people that follow Lintian's advice.


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

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlou47sACgkQnFyZ6wW9
dQpmGwgAqDPl9V5CxORey5p9hXS8BJUCZ4yxHbpcH9MrGSHL/bfDc5tdIpM3SIP9
bgaimPNL/IZ3LA2UCFAlJwTWnVDUH7PzmLu3GJ9Pay5wOK5t2jvt09Pp0+kVZNh7
LwUs0Uy4rNt821917mXQaVD3P7kOiYjrNbUmWSwNzKCgx06pqD7G9IBnrN6UDI2y
hrlWiI1O2kpAf7CKZO64Yj8yNSYU2GC1TqIJpCxxhj4gcGaye5NDjTv6k7EtzW1N
k3SpjK16AMceZ+PHeVPAdhlU/qcNq4M0jSXAdyvSCiKWHtREMNhx1gSnAXqmNU0G
LNSE+g030r6aN6fgrXIUL4ssOKmkeg==
=YFZE
-END PGP SIGNATURE-

Bug#884134: python-rpy: Incompatible with the version of R in stretch

[Matthew Woodcraft]

Package: python-rpy
Version: 1.0.3-30
Severity: grave

Installing and importing the stretch version of python-rpy fails with the
stretch version of R:

«
apt install python-rpy
python
Python 2.7.13 (default, Nov 24 2017, 17:33:09)
[GCC 6.3.0 20170516] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import rpy
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/rpy.py", line 134, in 
""" % RVERSION)
RuntimeError: No module named _rpy3033

  RPy module can not be imported. Please check if your rpy
  installation supports R 3.3.3. If you have multiple R versions
  installed, you may need to set RHOME before importing rpy. For
  example:

  >>> from rpy_options import set_options
  >>> set_options(RHOME='c:/progra~1/r/rw2011/')
  >>> from rpy import *
»

I see python-rpy is providing _rpy3011.so, not _rpy3033.so .


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

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

Versions of packages python-rpy depends on:
ii  libc6 2.24-11+deb9u1
ii  python2.7.13-2
ii  python-numpy [python-numpy-abi9]  1:1.12.1-3
ii  r-base-core   3.3.3-1

python-rpy recommends no packages.

Versions of packages python-rpy suggests:
pn  python-rpy-docs  

-- no debconf information

Bug#884127: Fails to sign modules for CONFIG_MODULES_SIG_FORCE

[Andreas Beckmann]

Control: tag -1 help

On 2017-12-11 19:17, Elliott Mitchell wrote:
> If CONFIG_MODULES_SIG_FORCE=y is set, then kernel modules are required
> to be signed.  The nvidia-kernel-source package fails to implement this
> step and as such cannot be made to work with a kernel configured that
> way.  This is normally done in the modules_install target, or can be done
> according to the instructions in Documentation/module-signing.txt.

Patches welcome.

I wont have the time to dig into this and come up with a solution. But
if someone can provie an initial patch, I'll look how to integrate it.


Andreas

Bug#868030: qemu-user-static: Please enable "F - fix binary" flag for binfmt entries

[Dan Nicholson]

On Mon, 17 Jul 2017 13:54:55 -0500 Dan Nicholson  wrote:
> Attached debdiff makes use of the --fix-binary option added in
> binfmt-support 2.1.7, which sets the "F" flag in the binfmt entry. I
> tested this on amd64 stretch (with binfmt-support-2.1.7-1 from sid). I
> created a chroot with debootstrap --arch=armhf and then chrooted into
> it. It worked correctly and I was able to run the armhf binaries with
> no changes besides installing qemu-user-static.
> 
> I left qemu-user-binfmt without the --fix-binary flag since it seems
> unlikely that would work as well with dynamic linking and shared
> libraries. It can easily be changed to require binfmt-support 2.1.7 in
> both cases and pass --fix-binary unconditionally.

Ping. Anything needed here? It would be really nice to have this in as
it would make qemu-user-static much more usable out of the box.

--
Dan

Bug#884133: glibc: CVE-2017-1000409

[Salvatore Bonaccorso]

Source: glibc
Version: 2.19-18
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for glibc, this is just to
track the issue. A DSA is not warranted for this issue only and can be
addressed in a point release. The issues are already not-exploitable
as describedin [1].

CVE-2017-1000409[0]:
buffer overflow

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-1000409
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000409
[1] http://www.openwall.com/lists/oss-security/2017/12/11/4

Regards,
Salvatore

Bug#884132: glibc: CVE-2017-1000408

[Salvatore Bonaccorso]

Source: glibc
Version: 2.19-18
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for glibc, this is just to
track the issue. A DSA is not warranted for this issue only and can be
addressed in a point release. The issues are already not-exploitable
as describedin [1].

CVE-2017-1000408[0]:
memory leak

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-1000408
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000408
[1] http://www.openwall.com/lists/oss-security/2017/12/11/4

Regards,
Salvatore

Bug#884123: liferea: Liferea 1.12.0 hides the preview by default

[Paul Gevers]

Hi Annadane,

Thanks for the report.

On 11-12-17 19:16, annadane wrote:
> Liferea 1.12.0 seems to start in "full screen" - ie, there is no
> split view between the feed links at the top and the article/feed at
> the bottom. I suspect this is unintentional? There doesn't seem to be
> anything to toggle it in the preferences
Can you please elaborate what you see (and maybe add a screenshot)?

I am running 1.12.0 myself and I think I don't have your issue, so, some
more questions:

* Did you install liferea new, or did you upgrade?

* If you upgraded, do you experience the same issue when you
(temporarily) move ~/.config/liferea/ out of the way (while liferea is
not running)?

* What desktop are you using?

* Have you tried all three different views in the "View" tab? Does that
make any difference?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#876695: Fixed upstream

[Leonardo Zide]

I'm thinking January, there's usually a new Parts Library at the end of the
year so I'm thinking about updating both at the same time.

Is there a way I can cross compile to test if the patch fixes this error?

On Sun, Dec 10, 2017 at 12:37 PM, Nicolas Guilbert  wrote:

> Hi Leo,
>
> that sounds great - are you planning a release soon?
>
> Cheers
>
>
>  Nicolas
>
>
> On 12/10/2017 09:01 PM, Leonardo Zide wrote:
>
>> I believe part of this change https://github.com/leozide/leo
>> cad/commit/33f33af0aaca49bd4b02a1596e2c677dbd1c4063 will fix the
>> problem. Right now upstream compiles for iOS, which also only has GL ES.
>>
>
>

Bug#884106: (fwd) Bug#884106: lists.debian.org: Mail not accepted on debian-l10n-german

[Peter Palfrader]

It seems to me that mail.helgefjell.de is very very picky when it comes
to TLS.

In particular, this disonnects me immediately:
 openssl s_client -connect mail.helgefjell.de:25 -starttls smtp
instead of putting me into a TLS'ed smtp session.

I'm tempted to think the problem is helgefjell.de's.

On Mon, 11 Dec 2017, Hanno 'Rince' Wagner wrote:

> Hi everybody,
> 
> this bug is assigned to the listmasters, but the postfix in question
> is maintained (as far as I know) by you. I don't know wether there is
> a package for you, but could you please help helge here?
> 
> Thank you,
> 
> Hanno Wagner, Listmaster of the day.
> 
> - Forwarded message from Helge Kreutzmann  -
> 
> From: Helge Kreutzmann 
> Subject: Bug#884106: lists.debian.org: Mail not accepted on debian-l10n-german
> To: sub...@bugs.debian.org
> Date: Mon, 11 Dec 2017 14:29:51 +0100
> User-Agent: Mutt/1.5.23 (2014-03-12)
> 
> 
> Subject: lists.debian.org: Mail not accepted on debian-l10n-german
> Package: lists.debian.org
> Severity: important
> 
> 
> I tried to send an E-Mail yesterday afternoon to
> debian-l10n-ger...@lists.debian.org, and it is still not published. I
> just got a delay message which indicates some TLS problem. (see below)
> 
> 
> - Forwarded message from mailer-daemon@213.239.213.133 -
> 
> > Date: Sun, 10 Dec 2017 22:50:52 +0100
> > From: mailer-daemon@213.239.213.133
> > To: he...@helgefjell.de
> > Subject: WARNING: delayed mail.
> > 
> > 
> > This is a delivery status notification from 
> > static.213-239-213-133.clients.your-server.de,
> > running the Courier mail server, version 0.73.1.
> > 
> > The original message was received on Sun, 10 Dec 2017 18:50:10 +0100
> > from localhost (localhost [127.0.0.1])
> > 
> > ---
> > 
> >  DELAYS IN DELIVERING YOUR MESSAGE
> > 
> > The delivery of the following E-mail message has been delayed.  This is an
> > advisory notice only; it is sent only to notify you about a temporary delay
> > in delivering your message.  You DO NOT need to do anything at this time.
> > Additional attempts to deliver your message will be made.  Some possible
> > reasons for this delay:
> > 
> >* Network congestion or failure.
> > 
> >* The destination mail server is temporarily off-line.
> > 
> > Diagnostic information is provided below for each recipient.  If copies of
> > this message were sent to additional recipients, deliveries to those
> > addresses are not included in this notice.  This is an advisory notice for
> > the following addresses only:
> > 
> >  :
> >  bendel.debian.org [82.195.75.100]:
> >  >>> RCPT TO:
> >  <<< 450 4.1.7 : Sender address rejected: unverified 
> > address: Cannot start TLS: handshake failure
> > 
> > ---
> > 
> > If your message was also sent to additional recipients, their delivery
> > status is not included in this report.  You may or may not receive
> > other delivery status notifications for additional recipients.
> > 
> > The original message follows as a separate attachment.
> > 
> 
> > Reporting-MTA: dns; static.213-239-213-133.clients.your-server.de
> > Arrival-Date: Sun, 10 Dec 2017 18:50:10 +0100
> > Received-From-MTA: dns; localhost (localhost [127.0.0.1])
> > 
> > Final-Recipient: rfc822; debian-l10n-ger...@lists.debian.org
> > Action: delayed
> > Status: 4.0.0
> > Will-Retry-Until: Sun, 17 Dec 2017 18:50:10 +0100
> 
> > Received: from localhost (localhost [127.0.0.1])
> >   (uid 502)
> >   by static.213-239-213-133.clients.your-server.de with local; Sun, 10 Dec 
> > 2017 18:50:10 +0100
> >   id 00E50007.5A2D73D2.5180
> > Date: Sun, 10 Dec 2017 18:50:10 +0100
> > From: Helge Kreutzmann 
> > To: debian-l10n-ger...@lists.debian.org
> > Subject: Re: [RFR] po4a://debhelper/man/po4a/po/de.po
> > Message-ID: <20171210175010.GA20648@Debian-50-lenny-64-minimal>
> > Mail-Followup-To: debian-l10n-ger...@lists.debian.org
> > References: 
> >  
> > Mime-Version: 1.0
> > Content-Type: multipart/signed; micalg=pgp-sha1; 
> > protocol="application/pgp-signature"; 
> > boundary="=_luckmann.name-20864-1512928210-0001-2"
> > Content-Disposition: inline
> > In-Reply-To: 
> > X-Public-Key-URL: http://www.helgefjell.de/data/helge.asc
> > X-homepage: http://www.helgefjell.de/
> > User-Agent: Mutt/1.5.23 (2014-03-12)
> 
> 
> - End forwarded message -
> 
> -- 
>   Dr. Helge Kreutzmann  he...@helgefjell.de
> Dipl.-Phys.   http://www.helgefjell.de
> 64bit GNU powered gpg signed mail preferred
>   

Bug#884131: jasperreports: CVE-2017-14941, CVE-2017-5533, CVE-2017-5532

[Markus Koschany]

Package: libjasperreports-java
Version: 6.3.1-1
Severity: important
Tags: security

The recent update of jasperreports apparently fixed CVE-2017-5528 and
CVE-2017-5529. There are still three CVE which are not addressed yet. The
advisory for CVE-2017-5532 mentions that the solution is to upgrade to
version 6.3.3 or 6.4.2. It is not clear to me whether the Debian
package is actually affected by CVE-2017-5533 or CVE-2017-14941 due to
lack of information.

Markus

Bug#880467: jasperreports: CVE-2017-14941, CVE-2017-5528, CVE-2017-5529

[Markus Koschany]

Am 11.12.2017 um 12:11 schrieb Emmanuel Bourg:
> Le 10/12/2017 à 15:38, Markus Koschany a écrit :
> 
>> We usually do support this use case. Take for example the recent
>> libpam4j update. No package in Debian is using it at the moment. The
>> whole purpose of this piece of software is authentication with PAM and
>> if you can circumvent the PAM auth mechanism, then it is obviously
>> broken, in a very bad way.
> 
> IMHO patching libpam4j in the stable releases was a waste of time (and
> sponsor money as far as Debian LTS is concerned) since it is totally
> unused (the popcon isn't above the noise level).

First of all let me point out that there are more CVE to fix which are
not resolved by the latest upgrade. According to the security advisory
for CVE-2017-5532 jasperreports 6.3.1 is still vulnerable. The issue
should be resolved by upgrading to > 6.4.1. Like I said before it is not
clear to me if this package is affected by the other CVE due to lack of
information. I will file a new bug report to track those issues properly.

I disagree with your assessment of libpam4j and I believe the general
reoccurring negativity does not help very much. In my opinion it is
completely OK if you refuse to work on a package because I know you have
put quite a lot on your plate already and I assume you are a volunteer
like myself. On the other hand there are rules and best practices how to
maintain a package in Debian. Let me quote the developers reference: [1]

"As the maintainer of the package, you have the responsibility to
maintain it, even in the stable release. You are in the best position to
evaluate patches and test updated packages,[...]"

I believe the sentence is very clear. For the first step of evaluation
it doesn't really matter how many installations the popcon project shows
(which is opt-in btw) but the severity and impact is important. The sole
purpose of libpam4j is to interact with PAM. If it does authentication
incorrectly, so that users can completely circumvent it, we call that a
grave bug. The next step is to evaluate how complicated a fix would be.
The fix was a one-liner and simple. Thus it would have been extremely
silly not to apply it in all distributions because the version is
identical. Even without the LTS project this should have been an
absolute no-brainer. Raphael was correct to file #879002 because the
package is unmaintained and unused. This is a fact. You can refuse to
work on it but please do not block other people from doing the right
thing which is either to fix bugs or remove bit-rotting and broken
software from Debian.

>> Yes, Java developers download their libraries from Maven Central and
>> bundle everything. But how can you be so sure that someone is not using
>> Debian libraries in production because they are stable and receive
>> security support?
> 
> We can never be sure someone isn't doing something silly with our
> packages, but that's not a reason for supporting them either. We already
> struggle to support the latest versions of Java, if we get distracted by
> fixing unused features in barely used packages we delay expected changes
> in more important packages, this is also a disservice to our users.

To be honest it takes more time to explain you my point of view than
fixing such a package. I consider a stable and secure system more
important than latest feature X. That is probably the reason why I'm in
the Debian now. If Debian can't keep up the high quality standards we
promise then there are usually two ways to resolve such a problem: Get
more people involved or decrease the number of packages, so that our
expectations match reality again. Nobody wants broken packages.

There is also nothing silly users can do with our packages because
Debian's security and QA policy applies to all packages. Of course we
want our users to use them. We don't want them to worry what packages
receive security support or not. By default every stable package in
Debian main receives security support. This is one of our selling
points, isn't it?

If we can't even support the status quo then introducing new features
and packages will only increase the burden. The reason why we struggle
with big changes like Maven2->Maven3, Java8->Java9 is foremost the lack
of manpower, lack of communication and lack of a strategy to minimize
the brokenness in unstable. It has simply become too hard for
contributors to keep up with the changes. When only a select few know
why something is suddenly broken, chances are very slim that someone
else will fix it.

>> Why do you package libspring-java in the first place?
> 
> Because we need it as a build dependency of quite of few other packages.

A build-dependency is still a supported package by default and binary
packages of libspring-java are also used as runtime dependencies. That
also doesn't change the fact that it is mainly a web framework and no it
is not silly to use software as such if it is provided in Debian.

>> I agree we have not enough human 

Bug#879031: rhn-client-tools: switch from python-gudev to gir1.2-gudev-1.0

[Bernd Zeimetz]

Control: tags - moreinfo

> # Broken Depends:
> apt-spacewalk: apt-transport-spacewalk
> rhnsd: rhnsd [amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc 
> ppc64el s390x]
> 
> Dependency problem found.
> 
> Depends need to be addressed first.  Please remove the moreinfo tag once they 
> are resolved.

I've filed removal bugs for them.

Bernd


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