Bug#829275: Ubuntu

[Harlan Lieberman-Berg]

severity 829275 normal
thanks

After a conversation with the reporter, we believe this bug is only
present in certain versions of Ubuntu -- potentially as a result of the
(Debian experimental) 2.x series of python-mock.

Further testing is required; will coordinate with the reporter and our
counterparts downstream.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#829371: transition: ntl

[Julien Puydt]

Hi,

On 04/07/2016 14:13, Jonathan Wiltshire wrote:

On 2016-07-03 10:30, Jonathan Wiltshire wrote:

Control: tag -1 confirmed

On 2016-07-02 21:58, Julien Puydt wrote:

I checked that these new ntl packages make it possible to build eclib,
flint, linbox, singular and flint-arb on an amd64 debian box, so I
don't expect any new problem.


Please go ahead.


Seems to have happened, so rebuilds scheduled.



The eclib failure on amd64 is pretty annoying -- I tried on my amd64 
box, and got illegal instruction too.


Then I compiled libntl27 from apt-get source and installed the obtained 
libntl27 package, and ran make check again : gone!


I don't know what is amiss with the package yet -- and even more 
worrying: I don't know how I didn't detect the matter when I checked the 
deps!


I'll try to find more about it as soon as possible,

Snark on #debian-science

Bug#829642: marked as done (pulseaudio 9 breaks SPDIF/iec958 and Intel HDMI audio on ASUS B85-Pro motherboard)

[Mike Hommey]

On Wed, Jul 06, 2016 at 02:21:04AM +, Debian Bug Tracking System wrote:
> On Tue, 2016-07-05 at 09:48 -0400, Felipe Sateler wrote:
> > Hi,
> > 
> > On 4 July 2016 at 22:38, Adam Warner  wrote:
> > > The logs are attached.
> > > 
> > 
> > 
> > (   0.146|   0.000) D: [pulseaudio] module.c: Checking for existence
> > of '/usr/lib/pulse-9.0/modules/module-udev-detect.so': failure
> > (   0.146|   0.000) W: [pulseaudio] module.c: module-detect is
> > deprecated: Please use module-udev-detect instead of module-detect!
> > 
> > Did you install pulseaudio-module-udev ? It appears you did not.
> > Please install it and try again.
> 
> PEBKAC error has been resolved. There is a newly recommended package
> for udev to discover available sinks in Pulseaudio 9 and I didn't have
> the package installed.

Should it only be recommended, though?

Mike

Bug#829897: hydra: Uses deprecated gnome-common macros/variables

[Daniel Echeverry]

forwarded 829897 https://github.com/vanhauser-thc/thc-hydra/issues/139
thanks

-- 
Daniel Echeverry
http://wiki.debian.org/DanielEcheverry
http://rinconinformatico.net
Linux user: #477840
Debian user

Bug#830102: sitesummary: autopkgtest failure

[Petter Reinholdtsen]

Control: retitle -1 sitesummary: cgi script not accepting requests after 
installation (autopkgtest failure)
Control: found -1 0.1.20

[Jeremy Bicha]
> Ubuntu uses autopkgtest before pushing updated packages to the regular
> repositories from -proposed. Because sitesummary's autopkgtest passed
> previously, new sitesummary versions won't land in Ubuntu (without
> manual intervention) until the autopkgtest passes again.

Thank you for the heads up.  Note, this failure is not really new, what
is new is the detection of the failure.  I had a look at the test
results on
https://ci.debian.net/packages/s/sitesummary/unstable/amd64/ > and
the failure also happen in version 0.1.20, but is not detected there.
It might have been present earlier too, but then the test did not really
work and we can't tell from the logs.

The problem is that installing sitesummary no longer set up apache
automatically to run the cgi script.   Not quite sure why.

--
Happy hacking
Petter Reinholdtsen

Bug#829969: guake: Uses deprecated gnome-common macros/variables

[Daniel Echeverry]

tags forwarded 829969 https://github.com/Guake/guake/issues/764
thanks


-- 
Daniel Echeverry
http://wiki.debian.org/DanielEcheverry
http://rinconinformatico.net
Linux user: #477840
Debian user

Bug#829744: Add new-package-should-not-package-python2-module tag

[Scott Kitterman]

On Wed, 06 Jul 2016 01:06:57 +0200 Chris Lamb  wrote:
> Mattias Klose wrote:
> 
> > Please only trigger this warning if no corresponding
> > python3 module is uploaded (at least until after the
> > stretch release).
> 
> Are we sure? The idea is to dissuade the Python 2 module from being
> packaged in the first place (on the principle that it is one less to
> remove later) rather than to promote that the Python 3 module is
> also packaged.
> 
> Otherwise this tag's semantics are really along the lines of "don't
> forget to package the Python 3 version!" which is already somewhat
> implicit in the ecosystem and causes us more work down the road.

If that's the case, then it's premature before the freeze. Python2.7 is 
'supported' through the expected stretch lifetime, so I don't see it being 
anything other than a maintainer call.  For the next release, it'll maybe be 
different.

Scott K

Bug#829026: assword: dropdown list passwords ordered randomly

[Daniel Kahn Gillmor]

On Thu 2016-06-30 01:30:22 -0400, Jameson Graef Rollins wrote:
> On Wed, Jun 29 2016, Daniel Kahn Gillmor  wrote:
>> if i type a substring in "assword gui"'s dialog box, i get a list of
>> matching other strings.  however, those strings appear to be ordered
>> differently each time.  I think it would be nicer to have a stable,
>> predictable ordering.
>
> That's funny; as far as I've been able to tell the entries are in fact
> sorted in 0.9.  The upstream git commit id for the patch that adds the
> alphabetical sorting is:
>
>   9d01b66056a0d365b5f8d35e439c4231cbf6df4e
>
> which is part of 0.9 release.
>
> How do we determine why it's not sorting for you?

hm, after an "apt install --reinstall assword", i agree that it is now
sorted for me :/ i don't know what version i was running!  possibly some
sort of demo/test installation from previous development which didn't
have 9d01b66056a0d365b5f8d35e439c4231cbf6df4e included.

I'm closing this bug because it seems to be resolved for me.

sorry for the noise,

--dkg

Bug#742429: isenkram: Please use PackageKit

[Petter Reinholdtsen]

[Jeremy Bicha]
> isenkram still has Recommends: aptdaemon but I don't think that's
> wanted any more.

Ah, I missed that one.  Thank you for noticing. I've removed it in git,
and it will be gone in the next upload.

-- 
Happy hacking
Petter Reinholdtsen

Bug#796674: Please enable CONFIG_SCHEDSTATS

[Michael Biebl]

Am 06.07.2016 um 01:39 schrieb Roger Shimizu:
> On Sun, Jul 3, 2016 at 2:58 PM, Michael Biebl  wrote:
>> This topic came up today on #pkg-systemd (again).
>> Do you have any concerns regarding enabling CONFIG_SCHEDSTATS and if
> 
> see: https://bugs.debian.org/600935#10
> 
> The main concern is performance side effect.
> Does thing get better?

See
https://bugzilla.redhat.com/show_bug.cgi?id=1013225#c28

for a related bug report.

Afaics, Fedora and Ubuntu enable CONFIG_SCHEDSTATS in their release kernels.

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#830106: Feature Request: lrzip compression support

[Jeff Bai]

Package: dpkg
Version: 1.18.7

lrzip, upstream https://github.com/ckolivas/lrzip has quite good
compression ratio (better than xz at times) with little compromise in
compression time, but at a cost for memory consumption, as seen in
benchmark data provided here:
http://ck.kolivas.org/apps/lrzip/README.benchmarks.

Is there a possibility for dpkg to gain support for lrzip compressed
packages?

Bug#830107: glabels: Scaling of 101% required to match templates

[David Griffith]

Package: glabels
Version: 3.4.0
Severity: normal

Dear Maintainer,

When printing to various Avery templates the result is undersized such 
that the edges in the cards are misaligned vertically by about 2.5mm. 
This is enough to make the resulting look very sloppy. This can be 
remedied, kindasorta, by changing the scale to 101%.

Tested with templates 5871 (business card) and 5163 (4x2 sticker).


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

Kernel: Linux 4.5.5-x86_64-linode69 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#830105: librostlab-blast: autopkgtest is failing

[Jeremy Bicha]

svn revision 22370 didn't go quite far enough for the autopkgtest used by debci.

Here's a patch:

Index: debian/changelog
===
--- debian/changelog (revision 22394)
+++ debian/changelog (working copy)
@@ -1,8 +1,13 @@
 librostlab-blast (1.0.1-7) UNRELEASED; urgency=medium

+  [ Tatiana Malygina ]
   * Team upload.
   * add debian/README.test, debian/librostlab-blast0-dev.docs, fix testsuite

+  [ Jeremy Bicha ]
+  * Have librostlab-blast0-dev depend on librostlab-dev (Closes: #830105)
+  * Have autopkgtest depend on build-essential for compile test
+
  -- Tatiana Malygina   Tue, 05 Jul 2016 14:12:46 +0300

 librostlab-blast (1.0.1-6) unstable; urgency=medium
Index: debian/control
===
--- debian/control (revision 22394)
+++ debian/control (working copy)
@@ -42,6 +42,7 @@
 Architecture: any
 Section: libdevel
 Depends: librostlab-blast0v5 (= ${binary:Version}),
+ librostlab-dev,
  ${misc:Depends}
 Suggests: librostlab-blast-doc
 Conflicts: librostlab-blast-dev
Index: debian/tests/control
===
--- debian/tests/control (revision 22394)
+++ debian/tests/control (working copy)
@@ -1,2 +1,2 @@
 Tests: installation-test
-Depends: @, librostlab-dev
+Depends: @, build-essential

Bug#830105: librostlab-blast: autopkgtest is failing

[Jeremy Bicha]

Package: librostlab-blast
Version: 1.0.1-6
Tags: patch

librostlab-blast's new autopkgtest is failing.

https://ci.debian.net/packages/libr/librostlab-blast/unstable/amd64/

Thanks,
Jeremy Bicha

Bug#830104: screenfetch makes my terminal can not be opened again after closing

[susu]

Package: screenfetch
Version: 3.7.0-1
Severity: important

Dear Maintainer,

*** First, I need to explain my desktop environment is Gnome,
when I open screenfatch in the terminal,
it is working, but when I close the terminal, 
I will not be able to restart my terminal work.


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

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

Bug#828094: python3-coverage: Missing JavaScript dependency: jquery.debounce.min.js

[Ben Finney]

On Tue, 2016-07-05 09:49 -0400, Barry Warsaw  wrote:
> On Jul 03, 2016, at 09:04 PM, Ben Finney wrote:
> 
> >I can work to package the library dependency; would you be interested
> >in sponsoring it into the archive?
> 
> Yes, for sure!

Great! Please go to the RFS bug report
.

-- 
 \
  `\
_o__) Ben Finney 

Bug#829454: RFS: xkcdpass/1.6.3-1

[Ben Finney]

On Tue, 2016-07-05 18:14 +, Gianfranco Costamagna
 wrote:
> your package doesn't support arch:all builds...

I'm not sure what you mean. The ‘debian/control’ file declares
, in
the only binary package, that it is “Architecture: all”.

What are you seeing that convinces you the package does not support
“Architecture: all”?

-- 
 \
  `\
_o__) Ben Finney 

Bug#830103: breathe: autopkgtest is failing

[Jeremy Bicha]

Patch attached.


0001-Add-texlive-generic-extra-to-autopkgtest-Depends.patch
Description: Binary data

Bug#830103: breathe: autopkgtest is failing

[Jeremy Bicha]

Source: breathe
Version: 4.2.0-2
Tags: patch

breathe's autopkgtest is failing:

https://ci.debian.net/packages/b/breathe/unstable/amd64/

! LaTeX Error: File `iftex.sty' not found.

To fix that, I think we just have to add the same
texlive-generic-extra dependency to debian/tests/control

Thanks,
Jeremy Bicha

Bug#829205: RFS: btrfs-progs/4.5.3-0.1

[Adam Borowski]

Hi!

On Fri, Jul 01, 2016 at 08:16:14AM -0400, Nicholas D Steeves wrote:
> I am looking for a sponsor for this update of "btrfs-progs".

Have you coordinated with Dimitri?  When the regular maintainer is active,
NMUs are appropriate for urgent changes, not for regular work.  Ie, instead
of random sponsors, I'd suggest letting him do uploads.

As you've helped with this package before, perhaps it might be good to
consider co-maintenance?


>   * Fix serious errors in debian/copyright.  This is not a GPL2+ package.
> Cme was used to generate a machine-readable copyright file, then

I'm afraid the new debian/copyright is a good deal _worse_ than before.

For example, you claim there's a file under GPL3, which would make the
package undistributable.  That file's license would be GPL3+ (not =3),
still bad, if not for an exception "... you may include it under the same
distribution terms that you use for the rest of that program".  Ie, GPL2.

Except for some specific projects with tightly controlled copyright notices,
Cme produces output indistinguishable from noise.  And knowingly providing
obviously incorrect copyright data is bad.  This Cme-produced output claims
every file has a single copyright holder who last touched the file years
ago -- easily disproven by "git log" on any file I looked at.

And btrfs-progs is a massively cooperative project, with a core gang each of
whom holds copyright to most of files (or rather, their companies do -- but
those change) and a gaggle of minor contributors (including you and me).

Thus, I see two alternatives:
* you do a massive work of archeology on every file to find the set of
  copyright holders.  Every file will have a long list.
* a blanket statement, listing maybe some major holders but with a stress on
  "and others".

I'd say the important points to convey are "1. many contributors, 2. GPL2".


Meow!
-- 
An imaginary friend squared is a real enemy.

Bug#829151: RFS: setcolortemperature/1.1-1 ITP

[Jacob Adams]

On 07/05/2016 07:46 PM, Sean Whitton wrote:
> Hello Peter and Jacob,
> 
> On Tue, Jul 05, 2016 at 11:19:55PM +0300, Peter Pentchev wrote:
>> Actually I don't see a problem with the machine-readable copyright
>> specification here; if you're referring to the fact that the contents
>> of the "Copyright" field is not in the usual "list of  "
>> format, this is perfectly fine: the Copyright field is free-form text as
>> described in:
>>
>>   
>> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field
>>
>> It is true that the examples in the copyright-format specification also
>> follow the "list of  " format, but it is not codified in
>> the text.
> 
> You're right -- thanks for your input.  I was wrong to say that it
> doesn't satisfy DEP-5.  However, I still think that the text could be
> more clearly laid out so the division of sct.c is obvious.  You could
> write something like "remainder of C code copyright Ted Unangst".

I've phrased it that way for now. Not sure I'm a huge fan of that
wording, but I can't think of anything else that doesn't lose clarity.
(I tried "everything else copyright..." but that seems too vague)

> 
> On Tue, Jul 05, 2016 at 04:51:51PM -0400, Jacob Adams wrote:
>>> 1. Could you explain why you are packaging your fork rather then the
>>>original?  (This kind of thing should go in the ITP.)
>>
>> The original was released in a blog post as a sort of code dump
>> (http://www.tedunangst.com/flak/post/sct-set-color-temperature )
>> I thought it would improve long term maintainability if there was a real
>> build system and active upstream. It's pretty hard to package software
>> without a tarball or VCS. If this is discouraged, I'd be happy to email
>> the real upstream about it, but I simply thought this would be easier
>> for everyone.
>> If I need to send a mail explaining this to the ITP I can do that.
> 
> This is perfectly reasonable :) It would be good to append it to the ITP
> in case anyone else is wondering.

Done.

> 
>>>
>>> 2. Could you put your Debian packaging in git, please?  It makes
>>> reviewing easier.  Perhaps as a 'debian' branch of your repo.
>>
>> Whoops. Actually I already do this in a different git repo and I just
>> filled out the relevant fields of d/control incorrectly. Thanks for
>> catching that!
> 
> Great.  Since you are the upstream maintainer and the (prospective)
> Debian package maintainer, is there any reason you're using two seprate
> git repos?  You could just add a debian/ directory to your main repo.
> 
> What you are doing is completely acceptable (and there are some Debian
> Developers who think that that is the way it should be done) but as
> someone who is the upstream maintainer and Debian maintainer (of
> git-remote-gcrypt), I find it a lot easier just to have one repo.  Or
> you can have a debian branch containing the debian/ subdir and you can
> merge master into that branch periodically.

I separated the two because that's what the upstream guide in the debian
wiki recommends. I can see the benefits of having it all in the same
repo but for this package I think I will keep them separate for now. I
might try the combined approach later if the separated one becomes too
much of a burden.

> 
>>>
>>> 3. The formatting of the long description in debian/control is a bit
>>> strange.  Please separate paragraphs using a line with the string "
>>> .".  Probably best to wrap at 70 chars, too.
>>
>> I think I fixed this now.
> 
> Sorry for the pedantry but you're missing a period at the end of line 19 :)

Fixed.
> 
>>> 4. The wording of the long description could be improved.  The first
>>> sentence isn't really a sentence -- it would be better to write "sct
>>> is a small C program to change the screen color temperature.  It can
>>> be used to reduce or increase the amount of blue light produced by
>>> the screen."  Please take another look at your wording :)
>>
>> Wow that description was a mess. I've fixed it up now and I think it's
>> much clearer.
> 
> I agree.  Good job.
> 
>>>
>>> 6. 'sct' is a very short command name for /usr/bin ... have you
>>>confirmed that it doesn't clash with any other packages in Debian?
>>>You might have to set the priority to 'extra'.
>>
>> Is there any way to check if other packages have binaries called sct? A
>> quick search of packages.d.o would seem to indicate there is not but is
>> there a better way to check?
> 
> There are several different ways, but the most convenient is probably
> the apt-file(1) tool.

That's pretty useful thanks! According to apt-file there are no
conflicts with /usr/bin/sct

>>> 10. You're missing at least one build dependency.  Please try building
>>> in a clean sid chroot (see the pbuilder or sbuild tools).
>>
>> Yep. Was missing libx11-dev and libxrandr-dev (dpkg -S is the best :) ).
>> I've fixed it now. Thanks for finding that.
> 
> It builds now, and I also confirmed that it installs and works.
> 


Thanks for all your help!

-- 

Bug#826161: Bug#826568: jessie-pu: package sendmail/8.14.4-8+deb8u1

[Guillem Jover]

Hi!

On Tue, 2016-07-05 at 14:41:26 +0200, Andreas Beckmann wrote:
> On 2016-07-05 11:51, Adam D. Barratt wrote:
> > On a related note, which has been mentioned before (on dda at least) -
> > please don't name your .changes file _amd64.changes if the package
> > builds amd64 binaries and they're not included in the upload. dak keeps
> 
> That's dpkg-buildpackage -g in stable. It is fixed in sid. (#826161)
> 
> Guillem, could #826161 be fixed in stable, too?

Ah certainly! I didn't mark it as a stable candidate because I was
afraid it could cause unintended problems, but if it is already
causing problems now I don't see why not. I've added a git-notes to
that commit to queue it for the next stable update.

Thanks,
Guillem

Bug#830102: sitesummary: autopkgtest failure

[Jeremy Bicha]

Source: sitesummary
Version: 0.1.22

sitesummary's updated autopkgtest fails on Debian's and Ubuntu's
continuous integration servers.

Ubuntu uses autopkgtest before pushing updated packages to the regular
repositories from -proposed. Because sitesummary's autopkgtest passed
previously, new sitesummary versions won't land in Ubuntu (without
manual intervention) until the autopkgtest passes again.

https://ci.debian.net/packages/s/sitesummary/

adt-run [01:19:28]: test test-server-client: [---
Failed to upload, answer 'HTTP/1.1 404 Not Found
Date: Wed, 06 Jul 2016 01:19:28 GMT
Server: Apache/2.4.23 (Debian)
Content-Length: 306
Content-Type: text/html; charset=iso-8859-1



404 Not Found

Not Found
The requested URL /cgi-bin/sitesummary-collector.cgi was not found
on this server.

Apache/2.4.23 (Debian) Server at localhost Port 80

'
error: unable to submit to 'http://localhost/cgi-bin/sitesummary-collector.cgi'
/var/lib/sitesummary
/var/lib/sitesummary/tmpstorage
/var/lib/sitesummary/entries
/var/lib/sitesummary/www
/var/lib/sitesummary/www/index.html
error: did not find entry

Thanks,
Jeremy Bicha

Bug#828028: Reasons for packaging my own fork of sct versus the real upstream

[Jacob Adams]

It was suggested in the RFS (#829151) that I should clarify why I am
packaging my fork of this instead of the original.

The original was released in a blog post as a sort of code dump
(http://www.tedunangst.com/flak/post/sct-set-color-temperature )
I thought it would improve long term maintainability if there was a real
build system and active upstream. It's pretty hard to package software
without a tarball or VCS. If this is discouraged, I'd be happy to email
the real upstream about it, but I simply thought this would be easier
for everyone.

Jacob Adams
GPG Key: AF6B 1C26 E2D0 A988 432B  94F4 24C0 2B85 B59F E5A9



signature.asc
Description: OpenPGP digital signature

Bug#829764: [pkg-php-pear] Bug#829764: php-monolog: add stage1 and nocheck build profiles

[David Prévot]

Control: tag -1 pending

Le 05/07/2016 à 20:13, Nish Aravamudan a écrit :
> On 05.07.2016 [16:51:48 -0400], David Prévot wrote:
>> Le 05/07/2016 à 16:19, Nishanth Aravamudan a écrit :
>>> Package: php-monolog
>> […]
>>>   *  Add nocheck and stage1 build profiles.
>>
>> Thanks for your patch. Please, do commit it directly:

> Done, looking at master's history, I believe you'll take care of the
> corresponding changelog entry?

Thanks! Indeed, “gbp dch” will take care of the changelog.

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#818201: kodi: Jasper removal

[Bálint Réczey]

Hi Mattia,

2016-06-27 15:51 GMT+02:00 Mattia Rizzolo :
> Hi Balint,
>
> On Tue, Mar 15, 2016 at 02:45:43PM +0100, Bálint Réczey wrote:
>> > Hi, jasper will be removed from Debian for the stretch release (and
>> > following that, the archive in general).
>> Kodi 17 wil not use jasper [1] and is expected to be release before
>> Stretch's freeze.
>> I plan fixing this bug with the 17.0 upstream release.
>
> Can you please fix it before?
> I see there is an alpha release avaialbe that should already contain
> that fix, or maybe backport the patch.
>
> In a few days kodi is going to be the very last blocker for jasper
> removal (as today I NMUed a bunch, and paved the way for the others).

The new alpha releases are fixed indeed, but the fix is not simple and I'm
not comfortable with either back-porting it either with uploading 17.0
alphas to unstable. There are many add-on packages depending on Kodi's
API and they need to be updated as well with each major Kodi update
and I'm not sure if all the addon upstreams are ready for Kodi 17 already.

I'm uploading a fixed kodi 17 to experimental soon, but please keep jasper in
testing for kodi for a few short months.

Thanks,
Balint

Bug#695547: sprint/bof @ Debconf to fix fpc bugs #695547 and #826300

[Peter Green]

Tags 695547 +patch
Thanks

On 05/07/16 23:37, Steve McIntyre wrote:

So Peter and I were talking a little earlier on #debian-arm,
Specifically we were talking about the arm tag/flag stuff. I haven't 
looked into the powerpc issue.  Freepascal has a chunk of platform/cpu 
specific assembler code that is used for mixed pascal/c programs to 
initialise both the freepascal runtime library and libc. The powerpc 
linux version of this file is located at rtl/linux/powerpc/cprt0.as . It 
would not surprise me if it was something to do with this init code.


It would be good to try and get a backtrace ("access violation" 
generally means that the freepascal runtime library trapped a segfault 
and turned it into an exception).


The remainder of this mail is about the arm tag/flag stuff.

  and he
was making good progress on fixing stuff. He may have stuff all done
shortly, I guess... :-)
   
I think i've fixed the arm tag/flag stuff. With the small patch attached 
I get the following.


root@odroidu2:/# readelf --file-header /usr/bin/fpc
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class: ELF32
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  EXEC (Executable file)
  Machine:   ARM
  Version:   0x1
  Entry point address:   0x100ec
  Start of program headers:  52 (bytes into file)
  Start of section headers:  410616 (bytes into file)
  Flags: 0x5000400, Version5 EABI, hard-float ABI
  Size of this header:   52 (bytes)
  Size of program headers:   32 (bytes)
  Number of program headers: 4
  Size of section headers:   40 (bytes)
  Number of section headers: 8
  Section header string table index: 7
root@odroidu2:/#

root@odroidu2:/# readelf -a /usr/bin/fpc
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class: ELF32
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  EXEC (Executable file)
  Machine:   ARM
  Version:   0x1
  Entry point address:   0x100ec
  Start of program headers:  52 (bytes into file)
  Start of section headers:  410616 (bytes into file)
  Flags: 0x5000400, Version5 EABI, hard-float ABI
  Size of this header:   52 (bytes)
  Size of program headers:   32 (bytes)
  Number of program headers: 4
  Size of section headers:   40 (bytes)
  Number of section headers: 8
  Section header string table index: 7


Section Headers:
  [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf Al
  [ 0]   NULL 00 00 00  0   0  0
  [ 1] .note.ABI-tag NOTE000100c0 c0 20 00   A  0   0 16
  [ 2] .text PROGBITS000100e0 e0 0501a4 00  AX  0   0  4
  [ 3] .rodata   PROGBITS00060288 050288 010828 00   A  0   0  8
  [ 4] .data PROGBITS00081000 061000 003395 00  WA  0   0  8
  [ 5] .bss  NOBITS  00084398 064395 00237c 00  WA  0   0  4
  [ 6] .ARM.attributes   ARM_ATTRIBUTES   064395 21 00  0   0  1
  [ 7] .shstrtab STRTAB   0643b6 42 00  0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD   0x00 0x0001 0x0001 0x60ab0 0x60ab0 R E 0x1
  LOAD   0x061000 0x00081000 0x00081000 0x03395 0x05714 RW  0x1
  NOTE   0xc0 0x000100c0 0x000100c0 0x00020 0x00020 R   0x10
  GNU_STACK  0x00 0x 0x 0x0 0x0 RW  0x10

 Section to Segment mapping:
  Segment Sections...
   00 .note.ABI-tag .text .rodata
   01 .data .bss
   02 .note.ABI-tag
   03

There is no dynamic section in this file.

There are no relocations in this file.

There are no unwind sections in this file.

No version information found in this file.

Displaying notes found at file offset 0x00c0 with length 0x0020:
  Owner Data size   Description
  GNU  0x0010   NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 2.0.0
Attribute 

Bug#742429: isenkram: Please use PackageKit

[Jeremy Bicha]

Hi,

isenkram still has Recommends: aptdaemon but I don't think that's
wanted any more.

Thanks,
Jeremy Bicha

Bug#829623: libcoap: FTBFS on non-Linux: unsupported operating system

[Aaron M. Ucko]

Carsten Schoenert  writes:

> as kfreebsd* is not a RC platform I won't implement any support in a near
> time. If you can came up the patches that would be fine.

That's fair.  I tried your suggested patch on the porterbox
falla.debian.org, but found that the build still failed because
src/coap_io.c relies on IP_PKTINFO, which isn't available on kFreeBSD
(or the Hurd, for that matter).  As such, it looks like specifying
Architecture: linux-any is the way to go after all.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#812103: Patch

[Trent Lloyd]

I fixed this issue in Ubuntu Precise (
https://bugs.launchpad.net/ubuntu/+source/passenger/+bug/1575220), sharing
the fix here however this fix was uploaded under the Squeeze LTS project
that concluded in February so I am guessing this may never be uploaded in
Debian.

The current patch modifies the addHeader() function itself to perform the
check, this is invalid because this function is used internally to setup
many headers from the environment such as the standard CGI HTTP_HOST,
REQUEST_URI, etc.

The correct patch should only abort adding headers from the HTTP request.

The upstream patch/source for Passenger 5 was quite different to v2 here,
however the upstream patch for Passenger 4 (
https://github.com/phusion/passenger/commit/c04590871ca0878d4d3ac1220c5a554b049056b4)
was very similar and I have backported this fix to precise in the attached
debdiff. I have not backported the nginx part, it was not done originally.

Attaching two versions of my diff against precise, one is against the
current broken version and the other is against the original version which
makes it easier to see what the complete content of the fix now is.

Patch Testing:
 ** No Patch **
lathiat@ubuntu:~/src/lp1575220$ curl -s -H "X-Test-Dash-Header: Yes" -H
"X_TEST_UNDERSCORE_HEADER: Yes" http://10.48.134.78/|grep -i test
   "HTTP_X_TEST_UNDERSCORE_HEADER"=>"Yes",
   "HTTP_X_TEST_DASH_HEADER"=>"Yes",

 ** Broken Patch **
lathiat@ubuntu:~/src/lp1575220$ curl -s -H "X-Test-Dash-Header: Yes" -H
"X_Test_Underscore_header: Yes" http://10.48.134.78/|grep -i test

 ** New Proposed Patch **
lathiat@ubuntu:~/src/lp1575220$ curl -s -H "X-Test-Dash-Header: Yes" -H
"X_Test_Underscore_header: Yes" http://10.48.134.78/|grep -i test
   "HTTP_X_TEST_DASH_HEADER"=>"Yes",

Cheers,
Trent
diff -u passenger-2.2.11debian/debian/control 
passenger-2.2.11debian/debian/control
--- passenger-2.2.11debian/debian/control
+++ passenger-2.2.11debian/debian/control
@@ -1,7 +1,8 @@
 Source: passenger
 Section: web
 Priority: optional
-Maintainer: Debian Ruby Extras Maintainers 

+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Debian Ruby Extras Maintainers 

 Uploaders: Filipe Lautert , Micah Anderson 
, David Moreno 
 Build-Depends: debhelper (>= 7), apache2-mpm-worker | apache2-mpm, 
apache2-threaded-dev, libapr1-dev,
  rubygems (>= 1.2), debhelper (>= 5.0.44), ruby-dev, doxygen, asciidoc (>= 
8.2), graphviz, rake,
diff -u passenger-2.2.11debian/debian/changelog 
passenger-2.2.11debian/debian/changelog
--- passenger-2.2.11debian/debian/changelog
+++ passenger-2.2.11debian/debian/changelog
@@ -1,3 +1,33 @@
+passenger (2.2.11debian-2+deb6u1ubuntu12.04.2) precise-security; urgency=medium
+
+  * Fix for regression introduced in previous CVE-2015-7519
+fix.  All HTTP headers were dropped from the request
+which broke all applications.  Backport the upstream
+fix from commit c04590871ca0878d4d3ac1220c5a554b049056b4
+for Apache2 only (LP: #1575220)
+
+ -- Trent Lloyd   Tue, 05 Jul 2016 00:42:47 +0800
+
+passenger (2.2.11debian-2+deb6u1ubuntu12.04.1) precise-security; urgency=medium
+
+  * fake sync from Debian
+
+ -- Steve Beattie   Mon, 25 Apr 2016 16:38:03 -0700
+
+passenger (2.2.11debian-2+deb6u1) squeeze-lts; urgency=high
+
+  * Non-maintainer upload by the Squeeze LTS Team.
+  * CVE-2015-7519
+agent/Core/Controller/SendRequest.cpp in Phusion Passenger
+before 4.0.60 and 5.0.x before 5.0.22, when used in Apache
+integration mode or in standalone mode without a filtering
+proxy, allows remote attackers to spoof headers passed to
+applications by using an _ (underscore) character instead
+of a - (dash) character in an HTTP header, as demonstrated
+by an X_User header.
+ 
+ -- Thorsten Alteholz   Mon, 28 Jan 2016 18:03:02 +0100
+
 passenger (2.2.11debian-2) unstable; urgency=low
 
   [Laurent Arnoud]
only in patch2:
unchanged:
--- passenger-2.2.11debian.orig/ext/apache2/Hooks.cpp
+++ passenger-2.2.11debian/ext/apache2/Hooks.cpp
@@ -786,6 +786,18 @@
}
}

+   // Renamed upstream function contains_non_alphanumdash from commit 
c04590871ca0878d4d3ac1220c5a554b049056b4
+   // because the return values were confusingly opposite to what the name 
suggested.  Used for CVE-2015-7519 fix.
+   bool contains_alphanumdash_only(const char *current) {
+   while (*current != '\0') {
+   if (!apr_isalnum(*current) && *current != '-') {
+   return false;
+   }
+   current++;
+   }
+   return true;
+   }
+
apr_status_t sendHeaders(request_rec *r, DirConfig *config, 
Application::SessionPtr 

Bug#829764: [pkg-php-pear] Bug#829764: php-monolog: add stage1 and nocheck build profiles

[Nish Aravamudan]

On 05.07.2016 [16:51:48 -0400], David Prévot wrote:
> Hi Nishanth,
> 
> Le 05/07/2016 à 16:19, Nishanth Aravamudan a écrit :
> > Package: php-monolog
> […]
> >   *  Add nocheck and stage1 build profiles.
> 
> Thanks for your patch. Please, do commit it directly: I have no way to
> test it nor any setup to maintain it anyway, besides being able to
> revert it in case it breaks (broken) expectations in Debian infrastructure.

Done, looking at master's history, I believe you'll take care of the
corresponding changelog entry?

Thanks,
Nish

Bug#829742: dpkg-maintscript-helper fails to convert directory to symlink on upgrade

[Tobias Hansen]

Hi Jerome,

ok, if you think it does not need to be fixed, you can close the bug.

I should mention that a workaround to get the package configured is to
just delete the folder /usr/share/doc/libmpfi-dev.

Best,
Tobias

On 07/05/2016 07:42 PM, Jerome BENOIT wrote:
> Hi Tobias, thanks for the report.
> 
> 
> 
> On 05/07/16 18:46, Tobias Hansen wrote:
>> Source: mpfi
>> Version: 1.5.1+ds-4
>> Severity: grave
>> Justification: prevents package upgrade
> 
>> Hi Jerome,
> 
>> When upgrading from version 1.5.1+ds-2, I get the following error:
> 
>> Preparing to unpack .../libmpfi-dev_1.5.1+ds-4_amd64.deb ...
>> dpkg-query: no packages found matching libmpfi-dev:amd64
>> dpkg-query: package 'libmpfi-dev' is not installed
>> Use dpkg --info (= dpkg-deb --info) to examine archive files,
>> and dpkg --contents (= dpkg-deb --contents) to list their contents.
>> dpkg-maintscript-helper: error: directory '/usr/share/doc/libmpfi-dev'
>> contains files not owned by package libmpfi-dev:amd64, cannot switch to
>> symlink
>> dpkg: error processing archive
>> /var/cache/apt/archives/libmpfi-dev_1.5.1+ds-4_amd64.deb (--unpack):
>>  subprocess new pre-installation script returned error exit status 1
>> Errors were encountered while processing:
>>  /var/cache/apt/archives/libmpfi-dev_1.5.1+ds-4_amd64.deb
>> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
>> The directory contains the following files
> 
>> ls /usr/share/doc/libmpfi-dev
>> changelog.Debian.gz  changelog.gz  copyright
> 
> Indeed the migration part of the story had been messed up for a while:
> a couple of fixes has been done to fix it. Tests via piuparts and the absence
> of any piuparts bugreport let me think that is now working with the current
> distributed versions:  1.5.1-1, 1.5.1-3, and 1.5.1+ds-4 .
> Your former version, according to the report is 1.5.1+ds-2, a buggy one
> that was for a short while in testing or unstable: my guess is that we
> can consider it as over. Otherwise, I am not sure if it is relevant
> to fix this very migration as it is quite unlikely while I am not sure
> how to reproduce it.
> 
> Thanks,
> Jerome
> 
> 
> 
>> Best,
>> Tobias
> 
> 
> 

Bug#829692: RFS: libu2f-host/1.1.2-0.1 [NMU] -- library for Universal 2nd Factor

[Adam Borowski]

On Tue, Jul 05, 2016 at 01:59:59PM +0200, Nicolas Braud-Santoni wrote:
> 
> I am looking for a sponsor for a NMU to the package libu2f-host.
> 
>  * Package name: libu2f-host
>Version : 1.1.2-0.1

> The proper maintainer of the package seems unresponsive, and 2 RC bugs
> (FTBFS) were previously fixed by codehelp and myself after sitting
> without acknowledgment for a month.

Appears to be good, uploaded.
Thanks for your work!

-- 
An imaginary friend squared is a real enemy.

Bug#830100: RFS: shadowsocks-libev/2.4.7+20160630+ds-2 [RC]

[Roger Shimizu]

package: sponsorship-requests
severity: important
X-Debbugs-Cc: rogershim...@gmail.com, max.c...@gmail.com, 073p...@gmail.com

Dear mentors,

I am looking for a sponsor for my package "shadowsocks-libev"

 * Package name: shadowsocks-libev
   Version : 2.4.7+20160630+ds-2
   Upstream Author : Max Lv 
 * URL : https://www.shadowsocks.org
 * License : GPL-3+
   Section : net

It builds those binary packages:

 libshadowsocks-dev - lightweight and secure socks5 proxy (development files)
 libshadowsocks1 - lightweight and secure socks5 proxy (shared library)
 shadowsocks-libev - lightweight and secure socks5 proxy

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

https://mentors.debian.net/package/shadowsocks-libev

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/shadowsocks-libev/shadowsocks-libev_2.4.7+20160630+ds-2.dsc

Changes since the last upload:

  * debian/control
- Move to git repo to collab-maint on alioth
  * Change way to handle config file
Install config.json file to /usr/share/, instead of /etc, and then
generate a config file under /etc, because conffile (under /etc) cannot
be modified by maintainer script according to Debian Policy.
Thanks help from Andreas Beckmann. (Closes: #829478)

Cheers,
-- 
Roger Shimizu, GMT +2 Cape Town (in DebConf16)
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#829151: RFS: setcolortemperature/1.1-1 ITP

[Sean Whitton]

Hello Peter and Jacob,

On Tue, Jul 05, 2016 at 11:19:55PM +0300, Peter Pentchev wrote:
> Actually I don't see a problem with the machine-readable copyright
> specification here; if you're referring to the fact that the contents
> of the "Copyright" field is not in the usual "list of  "
> format, this is perfectly fine: the Copyright field is free-form text as
> described in:
> 
>   
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field
> 
> It is true that the examples in the copyright-format specification also
> follow the "list of  " format, but it is not codified in
> the text.

You're right -- thanks for your input.  I was wrong to say that it
doesn't satisfy DEP-5.  However, I still think that the text could be
more clearly laid out so the division of sct.c is obvious.  You could
write something like "remainder of C code copyright Ted Unangst".

On Tue, Jul 05, 2016 at 04:51:51PM -0400, Jacob Adams wrote:
> > 1. Could you explain why you are packaging your fork rather then the
> >original?  (This kind of thing should go in the ITP.)
> 
> The original was released in a blog post as a sort of code dump
> (http://www.tedunangst.com/flak/post/sct-set-color-temperature )
> I thought it would improve long term maintainability if there was a real
> build system and active upstream. It's pretty hard to package software
> without a tarball or VCS. If this is discouraged, I'd be happy to email
> the real upstream about it, but I simply thought this would be easier
> for everyone.
> If I need to send a mail explaining this to the ITP I can do that.

This is perfectly reasonable :) It would be good to append it to the ITP
in case anyone else is wondering.

> > 
> > 2. Could you put your Debian packaging in git, please?  It makes
> > reviewing easier.  Perhaps as a 'debian' branch of your repo.
> 
> Whoops. Actually I already do this in a different git repo and I just
> filled out the relevant fields of d/control incorrectly. Thanks for
> catching that!

Great.  Since you are the upstream maintainer and the (prospective)
Debian package maintainer, is there any reason you're using two seprate
git repos?  You could just add a debian/ directory to your main repo.

What you are doing is completely acceptable (and there are some Debian
Developers who think that that is the way it should be done) but as
someone who is the upstream maintainer and Debian maintainer (of
git-remote-gcrypt), I find it a lot easier just to have one repo.  Or
you can have a debian branch containing the debian/ subdir and you can
merge master into that branch periodically.

> > 
> > 3. The formatting of the long description in debian/control is a bit
> > strange.  Please separate paragraphs using a line with the string "
> > .".  Probably best to wrap at 70 chars, too.
> 
> I think I fixed this now.

Sorry for the pedantry but you're missing a period at the end of line 19 :)

> > 4. The wording of the long description could be improved.  The first
> > sentence isn't really a sentence -- it would be better to write "sct
> > is a small C program to change the screen color temperature.  It can
> > be used to reduce or increase the amount of blue light produced by
> > the screen."  Please take another look at your wording :)
> 
> Wow that description was a mess. I've fixed it up now and I think it's
> much clearer.

I agree.  Good job.

> > 
> > 6. 'sct' is a very short command name for /usr/bin ... have you
> >confirmed that it doesn't clash with any other packages in Debian?
> >You might have to set the priority to 'extra'.
> 
> Is there any way to check if other packages have binaries called sct? A
> quick search of packages.d.o would seem to indicate there is not but is
> there a better way to check?

There are several different ways, but the most convenient is probably
the apt-file(1) tool.

> > 7. The language in d/copyright ("I doubt if it's copyrightable"
> > etc.)  isn't appropriate.  You need to determine whether or not it
> > is copyrightable and make a clear statement of that.
> 
> That wording is not mine, but written by Ingo Thies, who would have
> copyright over the whitepoints data if it is copyrightable. Putting it
> there was the advice I got from debian-legal (see below).

Thanks for the link to the debian-legal thread.  That was useful for me
to read.  I think you are good if you re-organise the Copyright: for
sct.c as suggested above.

> > 10. You're missing at least one build dependency.  Please try building
> > in a clean sid chroot (see the pbuilder or sbuild tools).
> 
> Yep. Was missing libx11-dev and libxrandr-dev (dpkg -S is the best :) ).
> I've fixed it now. Thanks for finding that.

It builds now, and I also confirmed that it installs and works.

-- 
Sean Whitton

Bug#796674: Please enable CONFIG_SCHEDSTATS

[Roger Shimizu]

On Sun, Jul 3, 2016 at 2:58 PM, Michael Biebl  wrote:
> This topic came up today on #pkg-systemd (again).
> Do you have any concerns regarding enabling CONFIG_SCHEDSTATS and if

see: https://bugs.debian.org/600935#10

The main concern is performance side effect.
Does thing get better?

Cheers,
-- 
Roger Shimizu, GMT +2 Cape Town (in DebConf16)
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#797389: calligra: FTBFS, multiple issues.

[Peter Green]

On 03/07/16 16:55, Peter Green wrote:

On 14/06/16 07:10, Scott Kitterman wrote:

On Tuesday, June 14, 2016 01:21:26 AM peter green wrote:
I am reluctant to NMU this In Debian myself because I don't use 
calligra

personally and I have not had any feedback from anyone on the patched
package.
Considering it doesn't build at all and the binaries have been 
removed from
Testing and Unstable, I think the chance of you making it worse is 
nil.  If

you can get it building again, then I wouldn't wait.
Ok, I just set up a sid VM, built calligra with my, installed it and 
did a quick smoke test and it seemed to run (I was able to start the 
writer tool and create a blank document). So i've uploaded it. Debdiff 
attatched (which is the same as what I had in raspbian except for 
changelog changes)



Well I tried to upload it. Unfortunately I was unsuccessful.

The first attempt was rejected because I screwed up the target distribution.

The second attempt was rejected because source only uploads to new are 
not allowed.


The third attempt went into the new queue where it was rejected with the 
following

unfortunately I have to reject the package.

As 
calligra-2.8.5+dfsg/kexi/webforms/webroot/default/media/javascripts/lightbox.js
is licensed under CC 2.5, please remove it from the source tarball.

As well, lintian complains about the lena picture, which is non-free.

While you are at it, please take also care of all those lintian warnings
related to debian/copyright.

   

Bug#829744: Add new-package-should-not-package-python2-module tag

[Chris Lamb]

Mattias Klose wrote:

> Please only trigger this warning if no corresponding
> python3 module is uploaded (at least until after the
> stretch release).

Are we sure? The idea is to dissuade the Python 2 module from being
packaged in the first place (on the principle that it is one less to
remove later) rather than to promote that the Python 3 module is
also packaged.

Otherwise this tag's semantics are really along the lines of "don't
forget to package the Python 3 version!" which is already somewhat
implicit in the ecosystem and causes us more work down the road.


Regards,

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

Bug#830089: powerpc-utils: Fix for bashism in update_flash_nv

[Steve Langasek]

Package: powerpc-utils
Version: 1.3.1-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Hi Adam,

A bug report has been submitted against powerpc-utils in Ubuntu, that
update_flash_nv contains a bashism, causing wrong behavior when /bin/sh is
dash.

Attached is a straightforward patch for this issue.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru powerpc-utils-1.3.1/debian/patches/bashisms.patch powerpc-utils-1.3.1/debian/patches/bashisms.patch
--- powerpc-utils-1.3.1/debian/patches/bashisms.patch	1969-12-31 16:00:00.0 -0800
+++ powerpc-utils-1.3.1/debian/patches/bashisms.patch	2016-07-05 15:51:53.0 -0700
@@ -0,0 +1,18 @@
+Author: Steve Langasek 
+Description: Fix bashism in update_flash_nv
+ update_flash_nv uses a == operator, which is a bashism.  Replace with =.
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1599191
+
+Index: powerpc-utils-1.3.1/scripts/update_flash_nv
+===
+--- powerpc-utils-1.3.1.orig/scripts/update_flash_nv
 powerpc-utils-1.3.1/scripts/update_flash_nv
+@@ -592,7 +592,7 @@
+ 
+ 	echo
+ 	id=`ipmitool -I usb fru 2>/dev/null |grep "System Firmware" | cut -d " " -f8 | cut -d ")" -f1`
+-	if [ "x$id" == "x" ]; then
++	if [ "x$id" = "x" ]; then
+ 		error $E_IPMI "Failed to get firmware version."
+ 	fi
+ 
diff -Nru powerpc-utils-1.3.1/debian/patches/series powerpc-utils-1.3.1/debian/patches/series
--- powerpc-utils-1.3.1/debian/patches/series	2016-04-10 23:22:12.0 -0700
+++ powerpc-utils-1.3.1/debian/patches/series	2016-07-05 15:50:34.0 -0700
@@ -1,2 +1,3 @@
 01_ipmitool_check.patch
 02_systool_check.patch
+bashisms.patch

Bug#830087: https://qa.debian.org/bls/bytag/ RRD graphs should standardize axis

[Daniel Kahn Gillmor]

Package: qa.debian.org

--- Begin Message ---
I'm looking at the graphs in:

https://qa.debian.org/bls/bytag/W-dpkg-buildflags-missing.html

they seem to have an arbitrarily-placed vertical axis.  The bottom of
the graph should be 0, so that we can clearly see what proportion of
packages are lacking these build flags.

thanks for maintaining these charts!

   --dkg
--- End Message ---

Bug#820822:

[Bob Bib]

control: severity -1 serious
control: affects -1 vlc

IMHO, it's a serious memory leak.

--
Best wishes,
Bob

Bug#809194: ITP: golang-github-docopt-docopt-go -- An implementation of docopt in the Go programming language.

[Alessandro Ghedini]

On Mon, Jul 04, 2016 at 09:52:50AM +0200, gustavo panizzo wrote:
> On Mon, Jul 04, 2016 at 12:57:47AM +0100, Alessandro Ghedini wrote:
> > 
> > Any news about this? I'd be interested in using such package :)
> > 
> > Cheers
> 
> Packaging is ready waiting for review and sponsorship
> git://anonscm.debian.org/pkg-go/packages/golang-github-docopt-docopt-go.git
> 
> This package is a dependency of asciinema, please consider to sponsor
> them both, together with golang-github-creack-termios (another asciinema
> dependency).
> 
> git://anonscm.debian.org/pkg-go/packages/asciinema.git
> git://anonscm.debian.org/pkg-go/packages/golang-github-creack-termios.git

TBH I don't really care about the other packages and I don't have enough time
to review something I don't care about, sorry :/

As for golang-github-docopt-docopt-go, I looked at your repo and it looks good
except for a few small nits:

 * You remove bith binaries and examples from the target directory, but it
   seems you missed a couple of files that should also be removed:

-rw-r--r-- root/root 42954 2016-07-03 05:04 
./usr/share/gocode/src/github.com/docopt/docopt-go/docopt_test.go
-rw-r--r-- root/root   891 2016-07-03 05:04 
./usr/share/gocode/src/github.com/docopt/docopt-go/example_test.go

 * I think the examples/ directory should be included in the package but
   installed as examples files. See dh_installexamples(1) for more information,
   but basically you'd need to create an *.examples file under debian/ listing
   which file / directory to install as example.

 * The git repo doesn't have an upstream/ tag. You also probably want to wait
   to create the debian/ one until after the package is uploaded. Otherwise
   you'll need to delete it and recreate it if you need to do some changes.
   In general when sponsoring a package, I prefer to create the tag myself
   just before uploading (so you don't need to generate it yourself).

Thanks for your work :)

Cheers


signature.asc
Description: PGP signature

Bug#829597: [Pkg-clamav-devel] Bug#829597: clamav-daemon: LocalSocket not created.

[Gordon Dickens]

  
  
I have solved the problem.  I don't know what
  went wrong on all three servers with the upgrade from 0.99 to
  0.99.2 but the following fixes everything:
  
  apt-get purge clamav clamav-base clamav-daemon clamav-freshclam
  clamdscan libclamav7
  apt-get install clamav clamav-daemon
  
  So, by just totally uninstalling clamav, including its
  configuration files, and then doing a reinstall from scratch
  solves the problem.
  
  FYI,
  
  Gordon Dickens
  

  

Bug#829667: License headers

[Jonas Smedegaard]

Quoting Sandro Mani (2016-07-05 23:22:25)
> 
> 
> On 05.07.2016 21:35, Jonas Smedegaard wrote:
> >
> > Quite interesting - assuming you did in fact check the --help option.
> >
> > What does "licensecheck --version | head -n 1" say?
> Never mind, I was using licensecheck from devscripts-2.16.5. So all 
> good, thanks for your responsiveness!

No problem.  Happy the mystery got solved :-)

Please do not hesitate to report any other issues you stumble across, or 
suggestions for improvements.  And good luck with your package!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#829555: libgmime-2.6-dev: GMime-2.6.gir is not included

[Daniel Kahn Gillmor]

Hi M.--

On Mon 2016-07-04 04:54:16 -0400, M. Dietrich wrote:
> Package: libgmime-2.6-dev
> Version: 2.6.20-1+b1

> the girepository file is not built (probably a similar case as
> in https://bugs.archlinux.org/task/40438 with the same
> solution).

So there are two things that i think get created by
gobject-introspection:

 /usr/share/gir-1.0/GMime-2.6.gir

and

 /usr/lib/${ARCHITECTURE_TRIPLET}/girepository-1.0/GMime-2.6.typelib


I think the .gir file (an XML file) belongs pretty clearly in
libgmime-2.6-dev.  But all the other .typelib files on my system seem to
be shipped in their own gir1.2-* package, like:

 gir1.2-gcr-3

(and it looks like the associated *-dev package will Depend: on the
gir1.2-* package).

It'll need a round trip through the NEW queue because of the new
package, but that way people who want to use gir (e.g. on a multiarch
system) without choosing a full -dev package can use it cleanly.

Does this sound right to you?

Thanks for the report,

 --dkg


signature.asc
Description: PGP signature

Bug#830074: iodine: Provide a systemd service file

[gregor herrmann]

On Tue, 05 Jul 2016 17:52:07 -0400, Lizhou Sha wrote:

> Please find attached a systemd service file for iodined. This should
> serve as a drop-in replacement for the existing sysvinit script.

Thank you, much appreciated.

One question I (as a systemd noob) have is:
Shouldn't iodined use systemd's socket activation feature? What I
understand from upstream CHANGES and the manpage, and grepping over
the code, this should be possible but we need an appropriate unit
file for it (examples already exist in the upstream tarball's doc/
directory, and also installed as examples in the Debian package; they
probably just need to be adjusted to Debian systems for paths and
filenames, and tested ...)


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#830079: RM: prepaid-manager-applet -- ROM; Doesn't work with recent modem-manager, currently unmaintained upstream (myself)

[Guido Günther]

Package: ftp.debian.org
Severity: normal

Bug#827530: [pkg-cinnamon] Bug#827507: cinnamon-settings segfaults on entering power settings applet

[Michael Biebl]

Control: reassign -1 cinnamon-settings.

On Thu, 23 Jun 2016 02:33:45 +0200 Michael Biebl  wrote:

> This was a deliberate change afaics:
> https://cgit.freedesktop.org/upower/commit/?id=29c5c85f6bf2a163c8713641dba634910ee3cf49
> 
> Using UPowerGlib.Client.new() seems indeed to be the way to go.
> 
> Maxy, should we reassign the bug back to cinnamon-settings?


Going to do so, given the above.


-- 
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#829666: dash: diff for NMU version 0.5.8-2.3

[Mattia Rizzolo]

Control: tags 829666 + pending

Dear maintainer,

I've prepared an NMU for dash (versioned as 0.5.8-2.3) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
regards,
Mattia Rizzolo

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

 changelog |9 +
 rules |6 --
 2 files changed, 13 insertions(+), 2 deletions(-)

diff -u dash-0.5.8/debian/changelog dash-0.5.8/debian/changelog
--- dash-0.5.8/debian/changelog
+++ dash-0.5.8/debian/changelog
@@ -1,3 +1,12 @@
+dash (0.5.8-2.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS by adding build-arch and build-indep targets to debian/rules.
+Thanks to Sven Joachim  for the initial patch.
+Closes: #829666
+
+ -- Mattia Rizzolo   Tue, 05 Jul 2016 21:59:04 +
+
 dash (0.5.8-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u dash-0.5.8/debian/rules dash-0.5.8/debian/rules
--- dash-0.5.8/debian/rules
+++ dash-0.5.8/debian/rules
@@ -50,7 +50,9 @@
 	--host='$(DEB_HOST_GNU_TYPE)')
 	touch configure-stamp
 
-build: deb-checkdir build-stamp
+build: build-arch build-indep
+build-arch: deb-checkdir build-stamp
+build-indep:
 build-stamp: configure-stamp
 	-$(CC) -v
 	(cd build-tmp && exec $(MAKE) CFLAGS='$(CFLAGS)' CPPFLAGS='$(CPPFLAGS)' LDFLAGS='$(LDFLAGS)') || \
@@ -110,7 +112,7 @@
 		xargs -0r touch --no-dereference --date='$(BUILD_DATE)'
 	dpkg -b '$(DIR)' ..
 
-.PHONY: configure build po-templates clean patch install install-indep \
+.PHONY: configure build build-arch build-indep po-templates clean patch install install-indep \
 	  install-arch binary binary-indep binary-arch
 
 include debian/implicit


signature.asc
Description: PGP signature

Bug#830075: golang-github-kr-binarydist: please make the build reproducible

[Dhole]

Source: golang-github-kr-binarydist
Version: 0.0~git20120828.0.9955b0a-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

While working on the "reproducible builds" effort [1], we have noticed
that golang-github-kr-binarydist could not be built reproducibly.

When building the package, some test functions are run that generate
random test files.  The randomness for those test files is provided by
the kernel (through the crypto/rand go package).

The attached patch fixes this by generating deterministic pseudorandom
test files instead (by means of the rand go package and setting a fixed
seed).  The function that creates this test files is only used for
testing purposes, and as such, I believe there's no security concern.
But I'm not familiar with the package, so please, double check it.
Also, consider sending this patch upstream :)

Once applied, golang-github-kr-binarydist can be built reproducibly in
our current experimental framework.

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

Regards,
-- 
Dhole
diff -Nru 
golang-github-kr-binarydist-0.0~git20120828.0.9955b0a/debian/changelog 
golang-github-kr-binarydist-0.0~git20120828.0.9955b0a/debian/changelog
--- golang-github-kr-binarydist-0.0~git20120828.0.9955b0a/debian/changelog  
2016-06-29 22:09:09.0 +0200
+++ golang-github-kr-binarydist-0.0~git20120828.0.9955b0a/debian/changelog  
2016-07-04 01:21:45.0 +0200
@@ -1,3 +1,10 @@
+golang-github-kr-binarydist (0.0~git20120828.0.9955b0a-1.1) UNRELEASED; 
urgency=medium
+
+  * Non-maintainer upload.
+  * Make test files deterministic to make the package build reproducible. 
+
+ -- Eduard Sanou   Mon, 04 Jul 2016 01:21:16 +0200
+
 golang-github-kr-binarydist (0.0~git20120828.0.9955b0a-1) unstable; 
urgency=medium
 
   * Initial release (Closes: 823342)
diff -Nru 
golang-github-kr-binarydist-0.0~git20120828.0.9955b0a/debian/patches/deterministic-test-files.patch
 
golang-github-kr-binarydist-0.0~git20120828.0.9955b0a/debian/patches/deterministic-test-files.patch
--- 
golang-github-kr-binarydist-0.0~git20120828.0.9955b0a/debian/patches/deterministic-test-files.patch
 1970-01-01 01:00:00.0 +0100
+++ 
golang-github-kr-binarydist-0.0~git20120828.0.9955b0a/debian/patches/deterministic-test-files.patch
 2016-07-04 01:23:15.0 +0200
@@ -0,0 +1,56 @@
+Description: Deterministic test files
+ Make the files written during tests deterministic to make this package build
+ reproducible.
+Author: Eduard Sanou 
+
+--- golang-github-kr-binarydist-0.0~git20120828.0.9955b0a.orig/common_test.go
 golang-github-kr-binarydist-0.0~git20120828.0.9955b0a/common_test.go
+@@ -1,10 +1,10 @@
+ package binarydist
+ 
+ import (
+-  "crypto/rand"
+   "io"
+   "io/ioutil"
+   "os"
++  "rand"
+ )
+ 
+ func mustOpen(path string) *os.File {
+@@ -67,8 +67,9 @@ func fileCmp(a, b *os.File) int64 {
+   return -1
+ }
+ 
+-func mustWriteRandFile(path string, size int) *os.File {
++func mustWriteRandFile(path string, size int, seed int64) *os.File {
+   p := make([]byte, size)
++  rand.Seed(seed)
+   _, err := rand.Read(p)
+   if err != nil {
+   panic(err)
+--- golang-github-kr-binarydist-0.0~git20120828.0.9955b0a.orig/diff_test.go
 golang-github-kr-binarydist-0.0~git20120828.0.9955b0a/diff_test.go
+@@ -13,8 +13,8 @@ var diffT = []struct {
+   new *os.File
+ }{
+   {
+-  old: mustWriteRandFile("test.old", 1e3),
+-  new: mustWriteRandFile("test.new", 1e3),
++  old: mustWriteRandFile("test.old", 1e3, 1),
++  new: mustWriteRandFile("test.new", 1e3, 2),
+   },
+   {
+   old: mustOpen("testdata/sample.old"),
+--- golang-github-kr-binarydist-0.0~git20120828.0.9955b0a.orig/patch_test.go
 golang-github-kr-binarydist-0.0~git20120828.0.9955b0a/patch_test.go
+@@ -8,8 +8,8 @@ import (
+ )
+ 
+ func TestPatch(t *testing.T) {
+-  mustWriteRandFile("test.old", 1e3)
+-  mustWriteRandFile("test.new", 1e3)
++  mustWriteRandFile("test.old", 1e3, 1)
++  mustWriteRandFile("test.new", 1e3, 2)
+ 
+   got, err := ioutil.TempFile("/tmp", "bspatch.")
+   if err != nil {
diff -Nru 
golang-github-kr-binarydist-0.0~git20120828.0.9955b0a/debian/patches/series 
golang-github-kr-binarydist-0.0~git20120828.0.9955b0a/debian/patches/series
--- golang-github-kr-binarydist-0.0~git20120828.0.9955b0a/debian/patches/series 
1970-01-01 01:00:00.0 +0100
+++ golang-github-kr-binarydist-0.0~git20120828.0.9955b0a/debian/patches/series 
2016-07-04 01:22:10.0 +0200
@@ -0,0 +1 @@
+deterministic-test-files.patch


signature.asc
Description: PGP signature

Bug#830074: iodine: Provide a systemd service file

[Lizhou Sha]

Package: iodine
Version: 0.7.0-4
Severity: wishlist

Dear Maintainer,

Please find attached a systemd service file for iodined. This should
serve as a drop-in replacement for the existing sysvinit script.

A couple things to note:

- The original init script depends on $remote_fs, $named, and $syslog.
  It seems that it is sufficient to use Wants=network.service in the
  systemd service file, but you might want to verify that this is the
  case.
- The sysvinit script allows iodined to fork into a daemon, but under
  systemd it is probably easier to have iodined not fork. Therefore, I
  added the -f option to the command line and used Type=simple instead
  of Type=forking.

Best,
Lizhou

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-28-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
# Author: Lizhou Sha 

[Unit]
Description=A daemon for tunneling traffic over DNS queries
After=network.target

[Service]
EnvironmentFile=/etc/default/iodine
ExecStartPre=/bin/sh -xc "test ${START_IODINED} = true"
ExecStart=/usr/sbin/iodined -f -u iodine $IODINED_ARGS -P ${IODINED_PASSWORD}
Restart=on-failure
Type=simple

[Install]
WantedBy=multi-user.target

Bug#830069: Which copyright status?

[Elliott Mitchell]

Package: src:mailutils
Version: 1:2.99.98-2

At the top of debian/rules:

# This file is PUBLIC DOMAIN.
#
# Copyright ?? 2001,2003, 2009, 2010 Jeff Bailey, Jordi Mallach.

So, what is the actual copyright on the files for building the Debian
packages?  Are they in the public domain (as stated)?  Are they under
some flavor of copyright?

Things *cannot* be both in the public domain and under copyright.  They
can only be in one situation or the other.  I'm guessing Jeff Bailey
created the packaging files and put them into the public domain.
Subsequently Jordi Mallach took over maintaining the package and may or
may not wish to own copyright on the files.  In this situation it could
say "Created by Jeff Bailey in 2001", but it certainly appears Jeff
Bailey relinquished all copyright.

Does Jordi Mallach actually wish to own the copyright on the files?  Do
you instead wish to emulate Jeff Bailey and put them FULLY in the public
domain?


-- 
(\___(\___(\__  --=> 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#821985: ganglia: Build arch:all+arch:any but is missing build-{arch, indep} targets

[Steve Langasek]

Package: ganglia
Version: 3.6.0-6.1
Followup-For: Bug #821985
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Control: severity -1 serious

Hi folks,

With the upload of dpkg 1.18.8 to unstable, this bug now causes ganglia to
FTBFS, so I'm raising the severity.

I've applied the attached patch in Ubuntu which fixes the build failure. 
Please consider including it in Debian as well.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ganglia-3.6.0/debian/rules ganglia-3.6.0/debian/rules
--- ganglia-3.6.0/debian/rules	2016-07-01 21:11:41.0 -0700
+++ ganglia-3.6.0/debian/rules	2016-07-05 13:54:49.0 -0700
@@ -41,7 +41,7 @@
 		--sysconfdir=/etc/ganglia \
 		--infodir=\$${prefix}/share/info --enable-shared \
 		--with-gmetad
-build: build-stamp
+build build-arch build-indep: build-stamp
 
 build-stamp:  config.status
 	dh_testdir
@@ -143,4 +143,4 @@
 	dh_builddeb -s
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#806331: [xz-devel] Re: xz-utils: make the selected POSIX shell stable accross build environments

[Ximin Luo]

Lasse Collin:
> posix-shell.m4 comes from gnulib
> 
> [..]
> 
> One can force the POSIX shell to a specific value on the configure
> command line by passing, for example, "gl_cv_posix_shell=/bin/sh" as an
> argument. It's not documented in the --help output but it's mentioned
> in INSTALL section 3.1. That is an alternative to patching to get
> reproducible builds.
> 

Hi Lasse,

Looks like the gnulib guys weren't willing to accept my patch so I'll go the 
gl_cv_posix_shell route. This is Debian-specific, so xz-utils won't need to 
make any changes.

Thanks for your time and your pointers!

@Debian maintainer, please see the attached patch.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
diff -Nru xz-utils-5.1.1alpha+20120614/debian/changelog 
xz-utils-5.1.1alpha+20120614/debian/changelog
--- xz-utils-5.1.1alpha+20120614/debian/changelog   2015-06-18 
20:27:36.0 +0200
+++ xz-utils-5.1.1alpha+20120614/debian/changelog   2016-07-05 
23:35:36.0 +0200
@@ -1,3 +1,11 @@
+xz-utils (5.1.1alpha+20120614-2.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Force a constant /bin/sh for installed scripts. This helps the build
+be reproducible; /bin/sh on Debian is always POSIX. (Closes: #806331)
+
+ -- Ximin Luo   Sun, 03 Jul 2016 10:42:33 +0200
+
 xz-utils (5.1.1alpha+20120614-2.1) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff -Nru xz-utils-5.1.1alpha+20120614/debian/rules 
xz-utils-5.1.1alpha+20120614/debian/rules
--- xz-utils-5.1.1alpha+20120614/debian/rules   2012-10-12 00:38:38.0 
+0200
+++ xz-utils-5.1.1alpha+20120614/debian/rules   2016-07-03 11:01:15.0 
+0200
@@ -66,12 +66,14 @@
 
 debian/normal-build/Makefile debian/normal-build/Doxyfile: $(configure_input)
dh_auto_configure --builddirectory debian/normal-build -- \
+   $(opt_reproduce) \
--disable-threads --disable-static \
$(opt_optimize) $(opt_quiet) \
--disable-xzdec --disable-lzmadec
 
 debian/static-build/Makefile: $(configure_input)
dh_auto_configure --builddirectory debian/static-build -- \
+   $(opt_reproduce) \
--disable-threads --disable-shared \
--enable-liblzma2-compat \
$(opt_optimize) $(opt_quiet) \
@@ -81,6 +83,7 @@
 
 debian/xzdec-build/Makefile: $(configure_input)
dh_auto_configure --builddirectory debian/xzdec-build -- \
+   $(opt_reproduce) \
--disable-shared --disable-nls --disable-encoders \
--enable-small --disable-threads \
--disable-liblzma2-compat \
@@ -97,6 +100,7 @@
 flags_cmd = dpkg-buildflags --export=configure
 opt_optimize = $(shell $(flags_cmd))
 opt_optimize_small = $(shell $(small_flags_env) $(flags_cmd))
+opt_reproduce = gl_cv_posix_shell=/bin/sh
 
 opt_no_act =
 opt_quiet =

Bug#830066: tidy: fails to use ~/.tidy.conf , unless HTML_TIDY is appropriately set

[Francesco Poli (wintermute)]

Package: tidy
Version: 1:5.2.0-1.1
Severity: normal

Hello and thanks for maintaining tidy-html5 in Debian!

Unfortunately, after the upgrade:

  [UPGRADE] tidy:amd64 20091223cvs-1.5 -> 1:5.2.0-1.1

I noticed that tidy was completely misbehaving. None of my usual settings
was complied with.

My settings were in ~/.tidyrc and /usr/share/doc/tidy/README.Debian
still claims that this is the configuration file!
On the other hand, the online help tells a different story:

  $ tidy --help
  [...]
  On some platforms Tidy will also attempt to use a configuration specified 
  in /etc/tidy.conf or ~/.tidy.conf.
  [...]

This is a first issue, please fix the apparently outdated information
in the README.Debian file.

However, after:

  $ mv ~/.tidyrc ~/.tidy.conf

tidy still seems to ignore the content of ~/.tidy.conf !
Only after setting the enviroment variable:

  $ export HTML_TIDY=~/.tidy.conf

I was able to finally see tidy behaving as it was supposed to.

I think this is a bug: the HTML_TIDY environment variable should
be used to change the configuration file name from its default
value to another custom path, but there should be a default
configuration file name (and the online help claims that this
is ~/.tidy.conf, which is however apparently ignored).

Please investigate and fix this bug and/or forward my bug report
upstream.

Thanks for your time.
Bye!


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

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

Versions of packages tidy depends on:
ii  libc6 2.22-13
ii  libtidy5  1:5.2.0-1.1

tidy recommends no packages.

tidy suggests no packages.

-- no debconf information

Bug#830065: check that init.d script does not alias reload to restart

[Marcin Owsiany]

Package: lintian
Version: 2.5.22ubuntu1
Severity: wishlist

The debian policy (9.3.2) states:

reload
  cause the configuration of the service to be reloaded without actually
  stopping and restarting the service

However I feel that a lot of packages have init scripts which contain something
like:

  case "$1" in
  reload|restart)
stop_service
start_service
;;
  
Disobeying this rule in the SysV-init days was harmless. But it turns
out that systemd is more strict. It makes sure that after
"/etc/init.d/something reload" exits, no processes spawned by it remain
alive. I just plain kills them off with a SIGKILL (see log below).

This behaviour is not very well documented, and it took me a while to track
down the cause of the service disappearing (systemtap is awesome).
It would be nice if lintian caught this early, even if a simple regex check
would not be 100% accurate.


lip 05 08:50:25 piec systemd[3179]: Executing: /etc/init.d/knockd reload
lip 05 08:50:25 piec knockd[3179]: Stopping Port-knock daemon: knockd.
lip 05 08:50:26 piec knockd[3184]: starting up, listening on eth0
lip 05 08:50:26 piec knockd[3179]: Starting Port-knock daemon: knockd.
lip 05 08:50:31 piec systemd[1]: Received SIGCHLD from PID 3179 (knockd).
lip 05 08:50:31 piec systemd[1]: Child 3179 (knockd) died (code=exited, 
status=0/SUCCESS)   <--- init script exits
lip 05 08:50:31 piec systemd[1]: Child 3179 belongs to knockd.service
lip 05 08:50:31 piec systemd[1]: knockd.service: control process exited, 
code=exited status=0
lip 05 08:50:31 piec systemd[1]: knockd.service got final SIGCHLD for state 
reload
lip 05 08:50:31 piec systemd[1]: knockd.service changed reload -> running
lip 05 08:50:31 piec systemd[1]: Job knockd.service/reload finished, result=done
lip 05 08:50:31 piec systemd[1]: Reloaded LSB: port-knock daemon.
lip 05 08:50:31 piec systemd[1]: Got disconnect on private connection.
lip 05 08:50:31 piec systemd[1]: Received SIGCHLD from PID 3184 (knockd).
lip 05 08:50:31 piec systemd[1]: Child 3184 (knockd) died (code=killed, 
status=9/KILL)<--- service killed off
lip 05 08:50:31 piec systemd[1]: Child 3184 belongs to knockd.service
lip 05 08:50:31 piec systemd[1]: knockd.service: cgroup is empty
lip 05 08:50:31 piec systemd[1]: knockd.service changed running -> exited





-- System Information:
Debian Release: jessie/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-35-generic (SMP w/4 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: upstart (via init_is_upstart())

Versions of packages lintian depends on:
ii  binutils   2.24-5ubuntu14.1
ii  bzip2  1.0.6-5
ii  diffstat   1.58-1
ii  file   1:5.14-2ubuntu3.3
ii  gettext0.18.3.1-1ubuntu3
ii  hardening-includes 2.5ubuntu2.1
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.29build1
ii  libarchive-zip-perl1.30-7
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.36-1
ii  libdpkg-perl   1.17.5ubuntu5.6
ii  libemail-valid-perl1.192-1
ii  libfile-basedir-perl   0.03-1fakesync1
ii  libipc-run-perl0.92-1
ii  liblist-moreutils-perl 0.33-1build3
ii  libparse-debianchangelog-perl  1.2.0-1ubuntu1
ii  libtext-levenshtein-perl   0.06~01-2
ii  libtimedate-perl   2.3000-1
ii  liburi-perl1.60-1
ii  man-db 2.6.7.1-1ubuntu1
ii  patchutils 0.3.2-3
ii  perl [libdigest-sha-perl]  5.18.2-2ubuntu1.1
ii  t1utils1.37-2ubuntu1.1

Versions of packages lintian recommends:
ii  libautodie-perl 2.23-1
ii  libperlio-gzip-perl 0.18-1build3
ii  perl-modules [libautodie-perl]  5.18.2-2ubuntu1.1

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.17.5ubuntu5.6
ii  libhtml-parser-perl3.71-1build1
ii  libtext-template-perl  1.46-1
pn  libyaml-perl   
ii  xz-utils   5.1.1alpha+20120614-2ubuntu2

-- no debconf information

Bug#759403: lintian: Please publish machine-readable report for all packages

[Niels Thykier]

intrigeri:
> Niels Thykier wrote (05 Jul 2016 20:21:03 GMT) :
>> Re: the memory usage; it may make sense to do the report as multiple
>> "documents" (e.g. one per source package or something).
> 
>> It would allow both generator and consumers to process it more
>> efficiently by processing a single source at the time.
> 

Hi,

I think we might be talking part each other.

YAML has a concept called a "document" and you can have multiple
documents per file[¡].  What I wanted was multiple documents in a single
file, which means ...

> [...]
> 
> First of all, for my use case retrieving all data in one single HTTP
> request simpler, [...]
> 

There would only be one HTTP request.

> Also, once published on https://lintian.d.o/, these per-package files
> will look very much like endpoints for a web API, that consumers might
> start using in the wild, and then:
> 

There would only be one endpoint.


The consumer would just have to "iterate" over all documents in the
file.  It would not be much different than have the "outer most" data
structure being a list. But as each document is "self-contained", they
do not have to load the entire file into memory to process it (depending
on their use case).

Thanks,
~Niels

[1] http://yaml.org/spec/1.0/#id2561718

Bug#829667: License headers

[Sandro Mani]

On 05.07.2016 21:35, Jonas Smedegaard wrote:


Quite interesting - assuming you did in fact check the --help option.

What does "licensecheck --version | head -n 1" say?
Never mind, I was using licensecheck from devscripts-2.16.5. So all 
good, thanks for your responsiveness!

Bug#759403: lintian: Please publish machine-readable report for all packages

[intrigeri]

Niels Thykier wrote (05 Jul 2016 20:21:03 GMT) :
> Re: the memory usage; it may make sense to do the report as multiple
> "documents" (e.g. one per source package or something).

> It would allow both generator and consumers to process it more
> efficiently by processing a single source at the time.

I'm open to discussing this option, and have just spent some time
thinking about it. I have a few worries about it, as far as this first
iteration is concerned.

First of all, for my use case retrieving all data in one single HTTP
request simpler, and I'm ready to take the performance hit since it
also makes my consumer code much simpler to write, review
and maintain.

Also, once published on https://lintian.d.o/, these per-package files
will look very much like endpoints for a web API, that consumers might
start using in the wild, and then:

1. The exact URIs matter a lot, as they become the API endoints; I'm
   not interested in designing that API at the moment personally,
   especially in a way that provides any kind of stability (and
   anyway, the API should be versioned so all URIs should start with
   a "/0.1" component or something).

2. I wonder if YAML is optimal for consumers that want to use
   a smaller subset of the data. E.g. for web tools it's easier to
   use JSON.

So right now, I'm leaning towards keeping the one-big-YAML-file design
since it matches my current needs very well, and leaving it to those
who want finer-grained machine-readable access to design how the data
could be made available (endpoints, format, etc.).

What do you think?

As a side note: I'd be totally fine with advertising the
one-big-YAML-file format as subject to change, and to adjust my
consumer code in the future if needed, e.g. if/when a better data
format and endpoints layout is designed.

Cheers,
-- 
intrigeri

Bug#829744: Add new-package-should-not-package-python2-module tag

[Matthias Klose]

Please only trigger this warning if no corresponding python3 module is uploaded
(at least until after the stretch release).

Bug#830059: ITP: r-cran-rlumshiny -- GNU R 'Shiny' Applications for the R Package 'Luminescence'

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-rlumshiny
  Version : 0.1.0
  Upstream Author : Christoph Burow 
* URL : https://cran.r-project.org/web/packages/RLumShiny
* License : GPL
  Programming Lang: GNU R
  Description : GNU R 'Shiny' Applications for the R Package 'Luminescence'
 A collection of 'shiny' applications for the R package 'Luminescence'.
 These mainly, but not exclusively, include applications for plotting
 chronometric data from e.g. luminescence or radiocarbon dating. It
 further provides access to bootstraps tooltip and popover
 functionality and contains the 'jscolor.js' library with a custom
 'shiny' output binding.


Remark: This is (hopefully) the last pre-dependency for r-cran-treescape.
It will be maintained by the Debian Med team at
   svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-rlumshiny/trunk/

Bug#829730: xchat-gnome: CVE-2013-7449

[Josselin Mouette]

Hi,

Le mardi 05 juillet 2016 à 22:15 +0200, Michael Biebl a écrit :
> We have a supported successor/alternative with hexchat, so I'm inclined
> to request the removal of the package.
> Joss et al, do you see any reason why we should keep the package?

I don’t think we should. Maybe replace it with a transitional package to
hexchat?

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-

Bug#829478: shadowsocks-libev: modifies conffiles (policy 10.7.3): /etc/shadowsocks-libev/config.json

[Andreas Beckmann]

On 2016-07-05 22:15, Roger Shimizu wrote:
> So I need to remove the config entry in .install file, and move it to
> .doc, so it will be installed to /usr/share/doc/
> just let the postinst script to generate a new config under /etc should be 
> fine.

Put the template into /usr/share/, not /usr/share/doc, since
/usr/share/doc may be excluded from installation.
Policy 12.3: "Packages must not require the existence of any files in
/usr/share/doc/ in order to function."

Andreas

Bug#813920: gnupod-tools: fails to initialize ipod

[Corey Nelson]

The issue is caused by the opening bracket on line 362 (as of 
05/04/2016) after "defined(@" in file 
"/usr/share/perl5/GNUpod/XMLhelper.pm".  Removing this opening bracket 
and one of the closing brackets after "plname" fixes the issue.


I think this has to do with changes in the perl5 standard.

To clarify, line 362 in /usr/share/perl5/GNUpod/XMLhelper.pm has to be 
changed from:
if (defined(@{$XDAT->{playlists}->{data}->{$current_plname}})) { #the 
playlist is not empty/

to:
if (defined(@$XDAT->{playlists}->{data}->{$current_plname})) { #the 
playlist is not empty/



Hope this helps,
Corey

Bug#829764: [pkg-php-pear] Bug#829764: php-monolog: add stage1 and nocheck build profiles

[David Prévot]

Hi Nishanth,

Le 05/07/2016 à 16:19, Nishanth Aravamudan a écrit :
> Package: php-monolog
[…]
>   *  Add nocheck and stage1 build profiles.

Thanks for your patch. Please, do commit it directly: I have no way to
test it nor any setup to maintain it anyway, besides being able to
revert it in case it breaks (broken) expectations in Debian infrastructure.

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#829151: RFS: setcolortemperature/1.1-1 ITP

[Jacob Adams]

On 07/05/2016 08:02 AM, Sean Whitton wrote:
> control: owner -1 !
> control: tag -1 +moreinfo
> 
> Dear Jacob,
> 
> This looks like a nice alternative to redshift-gtk.  Thanks for
> packaging it.  I can't sponsor the upload, but I hope this review is
> useful to you.

Thanks! The review definitely helped.
> 
> 1. Could you explain why you are packaging your fork rather then the
>original?  (This kind of thing should go in the ITP.)

The original was released in a blog post as a sort of code dump
(http://www.tedunangst.com/flak/post/sct-set-color-temperature )
I thought it would improve long term maintainability if there was a real
build system and active upstream. It's pretty hard to package software
without a tarball or VCS. If this is discouraged, I'd be happy to email
the real upstream about it, but I simply thought this would be easier
for everyone.
If I need to send a mail explaining this to the ITP I can do that.

> 
> 2. Could you put your Debian packaging in git, please?  It makes
>reviewing easier.  Perhaps as a 'debian' branch of your repo.

Whoops. Actually I already do this in a different git repo and I just
filled out the relevant fields of d/control incorrectly. Thanks for
catching that!

> 
> 3. The formatting of the long description in debian/control is a bit
>strange.  Please separate paragraphs using a line with the string
>" .".  Probably best to wrap at 70 chars, too.

I think I fixed this now.

> 
> 4. The wording of the long description could be improved.  The first
>sentence isn't really a sentence -- it would be better to write "sct
>is a small C program to change the screen color temperature.  It can
>be used to reduce or increase the amount of blue light produced by
>the screen."  Please take another look at your wording :)

Wow that description was a mess. I've fixed it up now and I think it's
much clearer.

> 5. Have you considered calling the binary package 'sct'?  That is what
>someone might guess when they want to install this with apt-get.

That's a good idea. I just changed it.

> 
> 6. 'sct' is a very short command name for /usr/bin ... have you
>confirmed that it doesn't clash with any other packages in Debian?
>You might have to set the priority to 'extra'.

Is there any way to check if other packages have binaries called sct? A
quick search of packages.d.o would seem to indicate there is not but is
there a better way to check?

> 
> 7. The language in d/copyright ("I doubt if it's copyrightable" etc.)
>isn't appropriate.  You need to determine whether or not it is
>copyrightable and make a clear statement of that.

That wording is not mine, but written by Ingo Thies, who would have
copyright over the whitepoints data if it is copyrightable. Putting it
there was the advice I got from debian-legal (see below).

> 
> 8. This doesn't make sense (doesn't follow DEP-5 machine-readable
>copyright file format) -- please check:
> 
> Files: sct.c
> Copyright: 2016 Ted Unangst 
>whitepoints data copyright 2013 Ingo Thies 
> 
> License: public-domain-sct and public-domain-colorramp

This was based off of a discussion in debian-legal (starts here:
https://lists.debian.org/debian-legal/2016/06/msg00018.html ). They did
not explain how to properly format this except to say I should
explicitly put the license grant from Ingo (the "I doubt if it's
copyrightable" stuff) into d/copyright. I have no idea how to properly
format this.Any ideas you have on how to write this up correctly are
welcome.
I've read DEP-5 but this is complicated because part of sct.c is
copyright Ingo Thies but the rest is copyright Ted Unangst.

> 
> 9. Please install the README into /usr/share/doc.

Done.

> 10. You're missing at least one build dependency.  Please try building
> in a clean sid chroot (see the pbuilder or sbuild tools).

Yep. Was missing libx11-dev and libxrandr-dev (dpkg -S is the best :) ).
I've fixed it now. Thanks for finding that.

Thanks again for the review! I've now uploaded a new package to mentors.



-- 
Jacob Adams
GPG Key: AF6B 1C26 E2D0 A988 432B  94F4 24C0 2B85 B59F E5A9



signature.asc
Description: OpenPGP digital signature

Bug#828967: horizon / CVE-2016-4428 #828967

[Moritz Mühlenhoff]

On Tue, Jul 05, 2016 at 09:58:58PM +0200, Thomas Goirand wrote:
> On 07/05/2016 07:37 PM, Moritz Mühlenhoff wrote:
> > On Wed, Jun 29, 2016 at 03:50:47PM +0200, Thomas Goirand wrote:
> >> On 06/29/2016 11:24 AM, Moritz Muehlenhoff wrote:
> >>> Hi Thomas,
> >>> https://bugs.launchpad.net/bugs/1567673 has been assigned CVE-2016-4428 
> >>> and I think we should fix
> >>> it in jessie-security. Can you please prepare an update? unstable also 
> >>> needs the patch.
> >>>
> >>> Cheers,
> >>> Moritz
> >>>
> >>
> >> Hi Moritz,
> >>
> >> I have uploaded fixes for both Sid and Experimental, and the fix for
> >> Stable is committed to Git in here:
> >>
> >> http://anonscm.debian.org/cgit/openstack/horizon.git/commit/?h=debian/icehouse=d74e751ce93f03240f3ad4206e93d6e7e05da55f
> >>
> >> Since you may prefer a diff to read from your mail client, I have
> >> attached it to this message.
> > 
> > Why do you upload something different than the debdiff you sent?
> > 
> > jessie has 2014.1.3-7, and what you uploaded includes an additional
> > fix which was never on security.debian.org:
> > 
> >> horizon (2014.1.3-7+deb8u1) jessie-security; urgency=high
> >>
> >>  * Fix CVE-2015-3219 with upstream patch (Closes: 788306).
> >>
> >> -- Thomas Goirand   Wed, 10 Jun 2015 16:18:34 +0200
> > 
> > Cheers,
> > Moritz
> 
> Moritz,
> 
> I would still like both fixes to be included in the update. I'm sorry if
> the first one didn't make it yet through proposed-updates, it's probably
> my fault if it didn't.
> 
> If you wish me to squash version 2014.1.3-7+deb8u1 and 2014.1.3-7+deb8u2
> into a single version, please let me know, but I don't think it's very
> useful to do so.

No, let's ship both fixes, then. No need for a new upload. I'll review
the changes tomorrow and deal with the DSA.

Cheers,
Moritz

Bug#829833: ITP: libdate-holidays-de-perl -- Determine German holidays

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl 

* Package name: libdate-holidays-de-perl
  Version : 1.7
  Upstream Author : Martin Schmitt 
* URL : http://search.cpan.org/dist/Date-Holidays-DE/
* License : ISC
  Programming Lang: Perl
  Description : Determine German holidays

This module provides a function to get a list of German holidays for a
given year. It also knows about different regulations throughout
Germany.

This package should by maintained by the pkg-perl team. I will also
need a sponsor but I doubt this will be a problem.

Christoph



signature.asc
Description: Digital signature

Bug#829769: netxx: please make the build reproducible

[Reiner Herrmann]

Source: netxx
Version: 0.3.2-2
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that netxx could not be built reproducibly.
It embeds a timestamps into a script.

The attached patch removes it.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/tools/genconfig b/tools/genconfig
index 1e8de23..a217627 100755
--- a/tools/genconfig
+++ b/tools/genconfig
@@ -128,7 +128,7 @@ print <

Bug#829029: [Debian-astro-maintainers] Bug#829029: gyoto: building on kfreebsd

[Jon Boden]

On Mon, Jul 04, 2016 at 02:15:26PM +0200, Thibaut Paumard wrote:
> 
> The changelog says:
> 
> gyoto (0.0.3-2) unstable; urgency=low
> 
>   * Bug fix: "FTBFS on kfreebsd-i386 and kfreebsd-amd64 (test suite)",
> (Closes: #679923). The previous "fix" did not work at all. The library
> and the Yorick interface work fine, but not the stand-alone application.
> Disable the "gyoto" binary package and the test suite on kfreebsd-*.
> 
>  -- Thibaut Paumard   Wed, 11 Jul 2012
> 11:20:09 +0200
> 
> Can you check whether the package now runs fine (i.e. is able to pass
> the test suite)?

Looks good to me! I'm attaching the test suite log.

Thanks

-- 
Jon Boden

ubuntuBSD -- The power of FreeBSD kernel with familiarity of Ubuntu OS!

http://www.ubuntubsd.org/ -- https://twitter.com/ubuntuBSD
I: [playground chroot] Running command: “LC_ALL=C.UTF-8 dh_auto_test”
make -j1 check
Making check in lib
make[1]: Entering directory '/root/playground/gyoto/gyoto-1.0.2/lib'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/root/playground/gyoto/gyoto-1.0.2/lib'
Making check in bin
make[1]: Entering directory '/root/playground/gyoto/gyoto-1.0.2/bin'
rm -f example-thin-disk.fits example-thin-disk-KS.fits 
example-thin-disk-minkowski-cartesian.fits 
example-thin-disk-minkowski-spherical.fits example-complex-astrobj.fits 
example-fixed-star.fits example-fixed-star-minkowski-cartesian.fits 
example-fixed-star-minkowski-spherical.fits example-startrace.fits 
example-moving-star.fits example-page-thorne-disk-BL.fits 
example-page-thorne-disk-KS.fits example-page-thorne-disk-BL-with-basis.fits 
example-torus.fits example-torus-KS.fits example-fixed-star-KS.fits 
example-polish-doughnut.fits
LD_LIBRARY_PATH=../lib/.libs/: ./gyoto -pstdplug -r32 -T8 -P0 
../doc/examples/example-thin-disk.xml \!example-thin-disk.fits
 Copyright (c) 2011-2015 Frederic Vincent & Thibaut Paumard
 GYOTO is distributed under the terms of the GPL v. 3 license.
 We request that use of Gyoto in scientific publications be  properly 
 acknowledged. Please cite:
  GYOTO: a new general relativistic ray-tracing code,
  F. H. Vincent, T. Paumard, E. Gourgoulhon & G. Perrin 2011,
  Classical and Quantum Gravity 28, 225011 (2011) [arXiv:1109.4769]

Reading parameter file: ../doc/examples/example-thin-disk.xml
j = 1/32
j = 2/32
j = 3/32
j = 4/32
j = 5/32
j = 6/32
j = 7/32
j = 8/32
j = 9/32
j = 10/32
j = 11/32
j = 12/32
j = 13/32
j = 14/32
j = 15/32
j = 16/32
j = 17/32
j = 18/32
j = 19/32
j = 20/32
j = 21/32
j = 22/32
j = 23/32
j = 24/32
j = 25/32
j = 26/32
j = 27/32
j = 28/32
j = 29/32
j = 30/32
j = 31/32
j = 32/32
Thread terminating after integrating 110 photons
Thread terminating after integrating 135 photons
Thread terminating after integrating 153 photons
Thread terminating after integrating 121 photons
Thread terminating after integrating 120 photons
Thread terminating after integrating 122 photons
Thread terminating after integrating 128 photons
Thread terminating after integrating 135 photons
Raytraced 1024 photons in 3.85936s using 8 thread(s)

Saving to file: !example-thin-disk.fits
LD_LIBRARY_PATH=../lib/.libs/: ./gyoto -pstdplug -r32 -T8 -P0 
../doc/examples/example-thin-disk-KS.xml \!example-thin-disk-KS.fits
 Copyright (c) 2011-2015 Frederic Vincent & Thibaut Paumard
 GYOTO is distributed under the terms of the GPL v. 3 license.
 We request that use of Gyoto in scientific publications be  properly 
 acknowledged. Please cite:
  GYOTO: a new general relativistic ray-tracing code,
  F. H. Vincent, T. Paumard, E. Gourgoulhon & G. Perrin 2011,
  Classical and Quantum Gravity 28, 225011 (2011) [arXiv:1109.4769]

Reading parameter file: ../doc/examples/example-thin-disk-KS.xml
j = 1/32
j = 2/32
j = 3/32
j = 4/32
j = 5/32
j = 6/32
j = 7/32
j = 8/32
j = 9/32
j = 10/32
j = 11/32
j = 12/32
j = 13/32
j = 14/32
j = 15/32
j = 16/32
j = 17/32
j = 18/32
j = 19/32
j = 20/32
j = 21/32
j = 22/32
j = 23/32
j = 24/32
j = 25/32
j = 26/32
j = 27/32
j = 28/32
j = 29/32
j = 30/32
j = 31/32
j = 32/32
Thread terminating after integrating 102 photons
Thread terminating after integrating 131 photons
Thread terminating after integrating 142 photons
Thread terminating after integrating 141 photons
Thread terminating after integrating 127 photons
Thread terminating after integrating 127 photons
Thread terminating after integrating 134 photons
Thread terminating after integrating 120 photons
Raytraced 1024 photons in 8.78365s using 8 thread(s)

Saving to file: !example-thin-disk-KS.fits
LD_LIBRARY_PATH=../lib/.libs/: ./gyoto -pstdplug -r32 -T8 -P0 
../doc/examples/example-thin-disk-minkowski-cartesian.xml 
\!example-thin-disk-minkowski-cartesian.fits
 Copyright (c) 2011-2015 Frederic Vincent & Thibaut Paumard
 GYOTO is distributed under the terms of the GPL v. 3 license.
 We request that use of Gyoto in scientific publications be  properly 
 acknowledged. Please cite:
  GYOTO: a new general relativistic ray-tracing code,

Bug#829750: [pkg-gnupg-maint] Bug#829750: gnupg2: 2.1.13 can't connect to dirmngr from 2.1.11

[Daniel Kahn Gillmor]

Version: 2.1.13-5

Hi James--

On Tue 2016-07-05 14:41:02 -0400, James Cowgill wrote:
> I just upgraded to the experimental version of gnupg2 to try it out,
> but immediately usage of --recv-keys stopped working. I found that this
> was because I was still using dirmngr 2.1.11-7 from unstable and in
> 2.1.13 the socket path used to connect to dirmngr was moved.
>
> Would it be a good idea to add a 'Breaks: dirmngr (<< 2.13)' to gnupg
> to ensure this doesn't happen?

With the change to the socket locations, I'm not convinced that gnupg
actually Breaks: dirmngr any more than dirmngr Breaks: gnupg.  And since
it's only a Recommends (not a stronger Depends) it's unclear what the
right thing to do is.

You'll note that 2.1.13-5 now has tighter versioned Recommends: between
both gnupg and dirmngr (which i plan to keep going forward), so
hopefully that's sufficient to point out that these things need to
grouped together.

--dkg

Bug#829731: Correct repository

[u]

Upstream has recently moved to Git, and the URL i've linked to earlier
points still to the old repository. The new one is here:
https://code.launchpad.net/~apparmor-dev/apparmor-profiles/+git/apparmor-profiles

And the direct link to the profile is:
https://git.launchpad.net/apparmor-profiles/tree/ubuntu/16.10/usr.bin.thunderbird

Cheers!

Bug#829765: mrd6: please make the build reproducible

[Reiner Herrmann]

Source: mrd6
Version: 0.9.6-12
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that mrd6 could not be built reproducibly.
It embeds the build date into the binary.

The attached patch strips this to enable reproducible building.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/0015-reproducible-build.patch b/debian/patches/0015-reproducible-build.patch
new file mode 100644
index 000..3e97034
--- /dev/null
+++ b/debian/patches/0015-reproducible-build.patch
@@ -0,0 +1,32 @@
+Author: Reiner Herrmann 
+Description: Strip build date to enable reproducible building
+
+--- a/src/Makefile
 b/src/Makefile
+@@ -179,7 +179,7 @@
+ $(MRD_VERSION_CPP): $(SOURCES) Makefile Makefile.options
+ 	@set -e; mkdir -p $(dir $@); \
+ 		echo '/* This file is automatically generated */' > $(MRD_VERSION_CPP); \
+-		echo 'const char *BuildDate = "$(NOW)";' >> $(MRD_VERSION_CPP)
++		echo 'const char *BuildDate = "unknown";' >> $(MRD_VERSION_CPP)
+ 
+ $(MODULES_CPP): Makefile Makefile.options
+ 	@set -e; mkdir -p $(dir $@); \
+--- a/src/mrd.cpp
 b/src/mrd.cpp
+@@ -74,7 +74,6 @@
+ 
+ mrd *g_mrd = 0;
+ 
+-extern const char *BuildDate;
+ static const char *VersionInfo = "mrd6 0.9.6 ($Rev: 1711 $)";
+ 
+ static const char *defaultconffiles[] = {
+@@ -2333,7 +2332,6 @@
+ 
+ void mrd::show_base_info(base_stream ) const {
+ 	out.xprintf("Version: %s\n", VersionInfo);
+-	out.xprintf("Build date: %s\n", BuildDate);
+ }
+ 
+ bool mrd::show_info(base_stream , const std::vector ) {
diff --git a/debian/patches/series b/debian/patches/series
index 0382f41..b9ad71b 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -12,3 +12,4 @@
 0012-Always-allow-flags-to-be-set-from-environment.patch
 0013-Interpret-syslog-buffer-string-as-string-only.patch
 0014-Correctly-detect-and-enable-new-interfaces.patch
+0015-reproducible-build.patch


signature.asc
Description: Digital signature

Bug#829764: php-monolog: add stage1 and nocheck build profiles

[Nishanth Aravamudan]

Package: php-monolog
Version: 1.19.0-2
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Dear Maintainer,

  *  Add nocheck and stage1 build profiles.

This allows for bootstrapping of monolog when PHP versions change (and
phpunit has not yet been rebuilt).

Thanks for considering the patch.

*** /tmp/tmpLf__kc/php-monolog_1.19.0-2ubuntu1.debdiff
diff -Nru php-monolog-1.19.0/debian/control php-monolog-1.19.0/debian/control
--- php-monolog-1.19.0/debian/control   2016-06-25 21:43:11.0 -0700
+++ php-monolog-1.19.0/debian/control   2016-07-05 13:18:59.0 -0700
@@ -9,7 +9,7 @@
php-psr-log (>= 1.0.0-2~),
php-swiftmailer,
phpab,
-   phpunit,
+   phpunit  ,
pkg-php-tools (>= 1.30~)
 Standards-Version: 3.9.8
 Homepage: https://github.com/Seldaek/monolog
diff -Nru php-monolog-1.19.0/debian/rules php-monolog-1.19.0/debian/rules
--- php-monolog-1.19.0/debian/rules 2016-04-12 14:22:36.0 -0700
+++ php-monolog-1.19.0/debian/rules 2016-07-05 13:17:58.0 -0700
@@ -12,7 +12,7 @@
tests/Monolog
 
 override_dh_auto_test:
-ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
+ifeq (,$(filter nocheck stage1, $(DEB_BUILD_OPTIONS) $(DEB_BUILD_PROFILES)))
phpunit --bootstrap autoload.php --include-path src
 else
@echo "** tests disabled"


-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

Bug#799352: file: mistakes text as bitmap

[Christoph Biedl]

# fixed in upstream commit FILE5_28-19-g496ae4c
tags 799352 pending
thanks

Vincent Lefevre wrote...

> "file" mistakes some text as bitmap:
> 
> $ echo P1788 | file -
> /dev/stdin: , bitmap, ASCII text
> 
> $ printf "P1788\n82541 2015\n" | file -
> /dev/stdin: Netpbm PPM image data, size = 82541 x 2015, bitmap, ASCII text
> 
> Such false positives prevent text files from being viewed by "less"
> when using a filter.

Upstream has hardened PNM detection to make such things much less
likely to happen. So your examples will no longer lead to a
mis-detection, however "P1 23 42" is a perfectly legal PNM header.

Your remark in #20 about lesspipe's behaviour ... I am sorry file's
output should not be considered stable. But I am just the bringer of
the news here.

Christoph


signature.asc
Description: Digital signature

Bug#829151: RFS: setcolortemperature/1.1-1 ITP

[Peter Pentchev]

On Tue, Jul 05, 2016 at 12:02:53PM +, Sean Whitton wrote:
[snip]
> 8. This doesn't make sense (doesn't follow DEP-5 machine-readable
>copyright file format) -- please check:
> 
> Files: sct.c
> Copyright: 2016 Ted Unangst 
>whitepoints data copyright 2013 Ingo Thies 
> 
> License: public-domain-sct and public-domain-colorramp

Actually I don't see a problem with the machine-readable copyright
specification here; if you're referring to the fact that the contents
of the "Copyright" field is not in the usual "list of  "
format, this is perfectly fine: the Copyright field is free-form text as
described in:

  
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field

It is true that the examples in the copyright-format specification also
follow the "list of  " format, but it is not codified in
the text.  I'm actually glad for that, and I'm actually glad that
Dominique Dumont's libconfig-model-dpkg-perl package (usually used as
"cme check dpkg") treats the Copyright field as such, because in one of
the packages that I'm working on right now I have to include something
like that:

Files: lib/*
Copyright:
  ...
 (c) 1998, 2001 The NetBSD Foundation, Inc.
 This code is derived from software contributed to The NetBSD Foundation
 by Charles M. Hannum.
 ...
License: BSD-2-clause

...and there is no way to express that (and not lose information) without
falling back on the free-form text idea.

Of course, my interpretation might be wrong, in which case I would be
glad for any advice on expressing the "derived from..." statement in
a stricter format.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#759403: lintian: Please publish machine-readable report for all packages

[Niels Thykier]

intrigeri:
> Hi,
> 
> intrigeri wrote (05 Jul 2016 11:50:03 GMT) :
>> Also, before we settle on this output format, I would like to quickly
>> validate it by drafting code for the use case I had in mind for that
>> machine-readable report.
> 
> I drafted that code in Python 3 and then in Perl (since the Python 3
> version needed 8GB of RAM to load the YAML file into a Python data
> structure in 135 seconds, while the Perl version needs 1.5GB of RAM
> and 15 seconds), and am happy with what I see, except I realize that
> I totally ignored the possibility that tags can be overridden.
> 
> Now I notice that I need this piece of info in the YAML report, and
> will thus resume working on my draft to add it (I didn't check yet if
> the current code makes this easy, or not — we'll see).
> 
> Cheers,
> --
> intrigeri
> 

Hi,

Thanks for working on this. :)

Re: the memory usage; it may make sense to do the report as multiple
"documents" (e.g. one per source package or something).

It would allow both generator and consumers to process it more
efficiently by processing a single source at the time.  (Disclaimer:
Haven't actually tried it before with the Perl interface).

Thanks,
~Niels

Bug#829730: xchat-gnome: CVE-2013-7449

[Michael Biebl]

Am 05.07.2016 um 17:53 schrieb Salvatore Bonaccorso:
> Source: xchat-gnome

> CVE-2013-7449[0]:
> | The ssl_do_connect function in common/server.c in HexChat before
> | 2.10.2, XChat, and XChat-GNOME does not verify that the server
> | hostname matches a domain name in the X.509 certificate, which allows
> | man-in-the-middle attackers to spoof SSL servers via an arbitrary
> | valid certificate.
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 

We have a supported successor/alternative with hexchat, so I'm inclined
to request the removal of the package.
Joss et al, do you see any reason why we should keep the package?

Regards,
Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#829557: lightdm 1.18.2-1 breaks D-BUS

[Tsu Jan]

Today I encountered the same issue but in a worse way. After the first 
log-in, everything was OK. But once I logged out of LXQt and logged in 
again, not only PCManFM-Qt didn't start, but also it couldn't be started 
in terminal, the notification area didn't run, Pidgin crashed and 
Firefox said "No D-BUS daemon running". I think Firefox's message 
explains everything.


Downgrading to lightdm-1.18.1-1 fixed all issues.

Bug#829763: linphone-nogtk: manpage in unknown language

[Félix Sipma]

Package: linphone-nogtk
Version: 3.6.1-2.6
Severity: normal

The manpage seems to be of an unknown language:

   linphonec - Øádkové rozhraní k linphone, internetový telefon podporující 
SIP.


Here is my locale settings (note that I have no problem with other
manpages):

$ locale
LANG=en_US.UTF-8
LANGUAGE=en
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=C
LC_TIME=en_DK.UTF-8
LC_COLLATE=fr_FR.UTF-8
LC_MONETARY=fr_FR.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=fr_FR.UTF-8
LC_NAME=fr_FR.UTF-8
LC_ADDRESS=fr_FR.UTF-8
LC_TELEPHONE=fr_FR.UTF-8
LC_MEASUREMENT=fr_FR.UTF-8
LC_IDENTIFICATION=fr_FR.UTF-8
LC_ALL=



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

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

Versions of packages linphone-nogtk depends on:
ii  bind9-host [host] 1:9.10.3.dfsg.P4-10
ii  libasound21.1.1-2
ii  libavcodec57  7:3.0.2-4
ii  libavutil55   7:3.0.2-4
ii  libc6 2.23-1
ii  libexosip2-11 4.1.0-2+b1
ii  libgl1-mesa-glx [libgl1]  11.2.2-1
ii  libglew1.13   1.13.0-2
ii  libglib2.0-0  2.48.1-1
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  liblinphone5  3.6.1-2.6
ii  libmediastreamer-base33.6.1-2.6
ii  libogg0   1.3.2-1
ii  libopus0  1.1.2-1
ii  libortp9  3.6.1-2.6
ii  libosip2-11   4.1.0-2
ii  libpulse0 9.0-1.1
ii  libreadline6  6.3-8+b4
ii  libsoup2.4-1  2.54.1-1
ii  libspandsp2   0.0.6+dfsg-0.1
ii  libspeex1 1.2~rc1.2-1
ii  libspeexdsp1  1.2~rc1.2-1
ii  libsqlite3-0  3.13.0-1
ii  libswscale4   7:3.0.2-4
ii  libtheora01.1.1+dfsg.1-14
ii  libudev1  230-5
ii  libupnp6  1:1.6.19+git20160116-1
ii  libv4l-0  1.10.1-1
ii  libvpx3   1.5.0-3
ii  libx11-6  2:1.6.3-1
ii  libxv12:1.0.10-1+b1
ii  linphone-common   3.6.1-2.6

linphone-nogtk recommends no packages.

linphone-nogtk suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#829478: shadowsocks-libev: modifies conffiles (policy 10.7.3): /etc/shadowsocks-libev/config.json

[Roger Shimizu]

Dear Andreas,

Thanks for helping on this package!

On Mon, Jul 4, 2016 at 11:35 AM, Andreas Beckmann  wrote:
> On 2016-07-04 09:31, Roger Shimizu wrote:
>> The fix may be one of the following:
>> - move the config from /etc/ to somewhere else, such as /var/cache
>> - use debconf to get the password from user when install, as Andreas
>> said in previous email
>
> Ship a config file template in /usr/share/$PACKAGE/...
> The file (whereever you place it) created by the maintainer scripts is
> *not* shipped by the package but only managed by the maintainer scripts.
>
> Maybe look into using ucf to manage it.

I find the docs:
https://www.debian.org/doc/manuals/maint-guide/dother.en.html#conffiles
it mentioned one solution is: "Create a file generated by the
maintainer scripts under the /etc directory"

So I need to remove the config entry in .install file, and move it to
.doc, so it will be installed to /usr/share/doc/
just let the postinst script to generate a new config under /etc should be fine.

Cheers,
-- 
Roger Shimizu, GMT +2 Cape Town (in DebConf16)
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#829740: [Pkg-privacy-maintainers] Bug#829740: RFP: corridor - a Tor traffic whitelisting gateway

[u]

Hi,

Patrick Schleizer:
> Is someone from the PkgPrivacyMaintainers team interested / willing to
> help get corridor [4] [5] [6] into Debian?

I'm not sure how useful this is exactly. It's still beta?

> I got a working prototype of a Debian package which is almost free of
> lintian warnings. [1] [2] [3] There are just some remaining --pedantic
> lintian warnings that are fixable. First questions...
> 
> 1)
> 
> I: corridor source: unused-file-paragraph-in-dep5-copyright paragraph at
> line 3
> 
> https://github.com/adrelanos/corridor/blob/debian_new/debian/copyright
> 
> Any idea what is wrong in the debian/copyright file?

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#files-paragraph

Multiple Files paragraphs are allowed. The last paragraph that matches a
particular file applies to it. More general paragraphs should therefore
be given first, followed by more specific overrides.

So I suppose the problem is that you declare * after Files/* and that
overrides the first paragraph.

> 2)
> 
> Would a combined manpage, i.e. 'man corridor', symlinked to the
> individual command names (corridor-init-forwarding, corridor-init-snat,
> ...) be acceptable by Debian policy and otherwise or should a separate
> man page per binary be provided?

https://www.debian.org/doc/debian-policy/ch-docs.html

"Each program, utility, and function should have an associated manual
page included in the same package. [..] Manual pages for protocols and
other auxiliary things are optional."

Symlinking man pages is allowed, as described in this policy, but I do
not have an example in mind where this has been done.

Cheers!
u.

Bug#828251: Fixed in upstream 1.0.4

[Fabio Pedretti]

https://github.com/borgbackup/borg/issues/1187

--
ing. Pedretti Fabio
Responsabile U.O.C. "Reti e Sistemi"
http://www.unibs.it/organizzazione/amministrazione-centrale/servizio-servizi-ict/uoc-reti-e-sistemi
Università degli Studi di Brescia
Via Valotti, 9 - 25121 Brescia
E-mail: fabio.pedre...@unibs.it

-- 

Informativa sulla Privacy: http://www.unibs.it/node/8155

Bug#826987: gcc-6: __builtin_cpu_supports() doesn't work on powerpc

[Adam Borowski]

On Tue, Jul 05, 2016 at 08:31:24AM +0200, Mathieu Malaterre wrote:
> I cannot see the builtin mentionned anywhere other than on the X86 page:
> 
> X86 (ok):
> https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/x86-Built-in-Functions.html#index-g_t_005f_005fbuiltin_005fcpu_005finit-4335
> 
> PowerPC (nothing found):
> https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/PowerPC-Built-in-Functions.html#PowerPC-Built-in-Functions

It's in the third dash point:

# — Built-in Function: int __builtin_cpu_supports (const char *feature)
#
#This function returns a value of 1 if the run-time CPU supports the
#HWCAP feature feature and returns 0 otherwise.  The following features
#can be detected:
#
#‘4xxmac’
#4xx CPU has a Multiply Accumulator.
#‘altivec’
#CPU has a SIMD/Vector Unit. 
...
#‘ppc32’
#CPU supports 32-bit mode execution. 


> There is an equivalent issue with -march=native on PowerPC, which is
> also not mentioned (and does not work):
> https://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html#RS_002f6000-and-PowerPC-Options

Programs that use detection specifically don't want -mfoo, as those options
either require or optimize for such a subtarget only.  On the other hand,
using __builtin_cpu_supports() means you have two code paths, one optimized
for the given feature and one without.

> I suspect this is instead a minor formatting issue in the gcc
> documentation as shipped in Debian (could not double check):
> # reassign -1 gcc-6-doc

It's not only in the documentation (both on the webpage and gcc-6-doc), but
also in the code:

./gcc/config/rs6000/rs6000.c line 320 lists available arguments to
__builtin_cpu_supports().
./gcc/testsuite/gcc.target/powerpc/cpu-builtin-1.c runs it.

I'm afraid I'm terribad about debugging gcc, so I couldn't tell more.


At least, the amount of documentation for this and related functions is big
enough that it's something more than a "minor formatting issue".  If indeed
this function is not supposed to be working in gcc-6, then it needs to be
clarified and removed from the documentation.

Should I try asking upstream?

 
Meow!
-- 
An imaginary friend squared is a real enemy.

Bug#827733: BusyBox Init + OpenRC

[Jon Boden]

I forgot to add a rule for shutdown -> openrc off. Here's a new patch!

-- 
Jon Boden

ubuntuBSD -- The power of FreeBSD kernel with familiarity of Ubuntu OS!

http://www.ubuntubsd.org/ -- https://twitter.com/ubuntuBSD
diff -Nur -x '*~' -x changelog ../debian/control debian/control
--- ../debian/control	2016-06-23 05:25:51.0 +0200
+++ debian/control	2016-07-05 20:50:45.0 +0200
@@ -16,7 +16,7 @@
 Conflicts: file-rc, sysv-rc
 Replaces: sysv-rc
 Provides: sysv-rc
-Depends: insserv, ${misc:Depends}, ${shlibs:Depends}
+Depends: insserv, ${misc:Depends}, ${shlibs:Depends}, sysvinit-core | openrc-busybox
 Recommends: init-system-helpers (>=1.29)
 Suggests: policycoreutils [linux-any] 
 Description: dependency based init system (runlevel change mechanism)
@@ -32,6 +32,24 @@
  .
  This package provides the runlevel change mechanism.
 
+Package: openrc-busybox
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}, busybox, openrc
+Conflicts: sysvinit (<< 2.88dsf-44), sysvinit-core, upstart [linux-any], systemd-sysv [linux-any]
+Description: dependency based init system (runlevel change mechanism)
+ OpenRC is a dependency based init system. It provides support for System V
+ init, for booting, changing runlevels, starting and stopping services, and
+ shutting down.
+ .
+ Originally written as a Gentoo project, OpenRC aims at being
+ platform-agnostic.  It works equally well on Linux, BSD and Hurd.
+ It supports the traditional init system in Debian in addition to many
+ alternatives.  OpenRC is implemented in C in a small, simple and
+ efficient way, making it easy to understand, extend and reuse.
+ .
+ This package sets up the BusyBox implementation of /sbin/init for use with
+ OpenRC.
+
 Package: librc1
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
diff -Nur -x '*~' -x changelog ../debian/init/hurd/inittab debian/init/hurd/inittab
--- ../debian/init/hurd/inittab	1970-01-01 01:00:00.0 +0100
+++ debian/init/hurd/inittab	2016-07-05 20:51:16.0 +0200
@@ -0,0 +1,29 @@
+# /etc/inittab: init(8) configuration.
+
+# Launch OpenRC for system initialization
+::sysinit:/sbin/openrc sysinit
+::wait:/sbin/openrc boot
+::wait:/sbin/openrc default
+::shutdown:/sbin/openrc off
+
+# What to do when CTRL-ALT-DEL is pressed.
+::ctrlaltdel:/sbin/reboot
+
+# /sbin/getty invocations for the runlevels.
+#
+::respawn:/sbin/getty 38400 tty1
+::respawn:/sbin/getty 38400 tty2
+::respawn:/sbin/getty 38400 tty3
+::respawn:/sbin/getty 38400 tty4
+::respawn:/sbin/getty 38400 tty5
+::respawn:/sbin/getty 38400 tty6
+::respawn:/sbin/getty 38400 console
+
+# Example how to put a getty on a serial line (for a terminal)
+#
+#::respawn:/sbin/getty -L ttyS0 9600 vt100
+#::respawn:/sbin/getty -L ttyS1 9600 vt100
+
+# Example how to put a getty on a modem line.
+#
+#::respawn:/sbin/mgetty -x0 -s 57600 ttyS3
diff -Nur -x '*~' -x changelog ../debian/init/kfreebsd/inittab debian/init/kfreebsd/inittab
--- ../debian/init/kfreebsd/inittab	1970-01-01 01:00:00.0 +0100
+++ debian/init/kfreebsd/inittab	2016-07-05 20:51:01.0 +0200
@@ -0,0 +1,28 @@
+# /etc/inittab: init(8) configuration.
+
+# Launch OpenRC for system initialization
+::sysinit:/sbin/openrc sysinit
+::wait:/sbin/openrc boot
+::wait:/sbin/openrc default
+::shutdown:/sbin/openrc off
+
+# What to do when CTRL-ALT-DEL is pressed.
+::ctrlaltdel:/sbin/reboot
+
+# /sbin/getty invocations for the runlevels.
+#
+::respawn:/sbin/getty 38400 ttyv0 xterm
+::respawn:/sbin/getty 38400 ttyv1 xterm
+::respawn:/sbin/getty 38400 ttyv2 xterm
+::respawn:/sbin/getty 38400 ttyv3 xterm
+::respawn:/sbin/getty 38400 ttyv4 xterm
+::respawn:/sbin/getty 38400 ttyv5 xterm
+
+# Example how to put a getty on a serial line (for a terminal)
+#
+#::respawn:/sbin/getty -L cuau0 9600 vt100
+#::respawn:/sbin/getty -L cuau1 9600 vt100
+
+# Example how to put a getty on a modem line.
+#
+#::respawn:/sbin/mgetty -x0 -s 57600 ttyd3
diff -Nur -x '*~' -x changelog ../debian/init/linux/inittab debian/init/linux/inittab
--- ../debian/init/linux/inittab	1970-01-01 01:00:00.0 +0100
+++ debian/init/linux/inittab	2016-07-05 20:51:09.0 +0200
@@ -0,0 +1,28 @@
+# /etc/inittab: init(8) configuration.
+
+# Launch OpenRC for system initialization
+::sysinit:/sbin/openrc sysinit
+::wait:/sbin/openrc boot
+::wait:/sbin/openrc default
+::shutdown:/sbin/openrc off
+
+# What to do when CTRL-ALT-DEL is pressed.
+::ctrlaltdel:/sbin/reboot
+
+# /sbin/getty invocations for the runlevels.
+#
+::respawn:/sbin/getty 38400 tty1
+::respawn:/sbin/getty 38400 tty2
+::respawn:/sbin/getty 38400 tty3
+::respawn:/sbin/getty 38400 tty4
+::respawn:/sbin/getty 38400 tty5
+::respawn:/sbin/getty 38400 tty6
+
+# Example how to put a getty on a serial line (for a terminal)
+#
+#::respawn:/sbin/getty -L ttyS0 9600 vt100
+#::respawn:/sbin/getty -L ttyS1 9600 vt100
+
+# Example how to put a getty on a modem line.
+#
+#::respawn:/sbin/mgetty -x0 -s 57600 ttyS3
diff -Nur -x '*~' -x changelog 

Bug#829762: modglue: please make the build reproducible

[Reiner Herrmann]

Source: modglue
Version: 1.17-2.4
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps hostname
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that modglue could not be built reproducibly.
It embeds the build date into the binary.

The attached patch strips this to enable reproducible building.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/02_reproducible_build.patch b/debian/patches/02_reproducible_build.patch
new file mode 100644
index 000..31b491a
--- /dev/null
+++ b/debian/patches/02_reproducible_build.patch
@@ -0,0 +1,32 @@
+Author: Reiner Herrmann 
+Description: Strip build date and hostname to enable reproducible building
+
+--- a/src/Makefile.in
 b/src/Makefile.in
+@@ -21,8 +21,6 @@
+ IPHASE = ${LIBTOOL} --mode=install @INSTALL@
+ FPHASE = ${LIBTOOL} --mode=finish @prefix@/@libdir@
+ 
+-TIMESTAMP = -D"DATETIME=\"`date | sed -e 's/  / /'`\"" -DHOSTNAME=\"`hostname`\"
+-
+ all: library tests tools
+ 
+ TOOLS  = ptywrap isatty prompt
+--- a/src/prompt.cc
 b/src/prompt.cc
+@@ -392,12 +392,11 @@
+ int main(int argc, char **argv)
+ 	{
+ 	if(argc==1) {
+-		cerr << "prompt (";
++		cerr << "prompt";
+ #ifdef STATICBUILD
+-		cerr << "static, ";
++		cerr << " (static)";
+ #endif
+-		cerr << "built on " << DATETIME << /* " on " << HOSTNAME << */ ")" << std::endl
+-			  << "Copyright (C) 2001-2006  Kasper Peeters " << endl << endl
++		cerr  << "Copyright (C) 2001-2006  Kasper Peeters " << endl << endl
+ 			  << "Usage: prompt [program] [args]" << endl;
+ 		exit(-1);
+ 		}
diff --git a/debian/patches/series b/debian/patches/series
index 69e2c3e..839ab18 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 01_fix_libs_in_linking_tests
+02_reproducible_build.patch


signature.asc
Description: Digital signature

Bug#826250: goobox: diff for NMU version 3.4.1-6.1

[Laurent Bigonville]

Control: tags 826250 + patch

Dear maintainer,

I've prepared an NMU for goobox (versioned as 3.4.1-6.1). The diff
is attached to this message.

Regards.
diff -Nru goobox-3.4.1/debian/changelog goobox-3.4.1/debian/changelog
--- goobox-3.4.1/debian/changelog   2016-03-20 16:20:40.0 +0100
+++ goobox-3.4.1/debian/changelog   2016-07-05 17:37:01.0 +0200
@@ -1,3 +1,15 @@
+goobox (3.4.1-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop the dependency against gnome-icon-theme-symbolic package, goobox uses
+gtk3 that uses adwaita-icon-theme which is pulled by default (Closes:
+#826250)
+  * d/p/0001-Let-s-GTK-automatically-load-rtl-icon-variants.patch: GTK3 should
+now load the RTL version of the icons when needed, this makes the icons
+from the adwaita icons theme display properly in that case.
+
+ -- Laurent Bigonville   Tue, 05 Jul 2016 17:37:00 +0200
+
 goobox (3.4.1-6) unstable; urgency=medium
 
   * po/tr.po added from upstream git.
diff -Nru goobox-3.4.1/debian/control goobox-3.4.1/debian/control
--- goobox-3.4.1/debian/control 2016-02-09 18:05:22.0 +0100
+++ goobox-3.4.1/debian/control 2016-07-05 17:34:46.0 +0200
@@ -14,7 +14,7 @@
 Package: goobox
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, 
-gstreamer1.0-plugins-base, gstreamer1.0-plugins-good, 
gnome-icon-theme-symbolic
+gstreamer1.0-plugins-base, gstreamer1.0-plugins-good
 Recommends: dbus-x11, yelp
 Suggests: gstreamer1.0-plugins-ugly
 Description: CD player and ripper with GNOME 3 integration
diff -Nru 
goobox-3.4.1/debian/patches/0001-Let-s-GTK-automatically-load-rtl-icon-variants.patch
 
goobox-3.4.1/debian/patches/0001-Let-s-GTK-automatically-load-rtl-icon-variants.patch
--- 
goobox-3.4.1/debian/patches/0001-Let-s-GTK-automatically-load-rtl-icon-variants.patch
   1970-01-01 01:00:00.0 +0100
+++ 
goobox-3.4.1/debian/patches/0001-Let-s-GTK-automatically-load-rtl-icon-variants.patch
   2016-07-05 17:24:48.0 +0200
@@ -0,0 +1,200 @@
+From f8290c3f1f4e3da4fcdf4f789d187020896bd403 Mon Sep 17 00:00:00 2001
+From: Laurent Bigonville 
+Date: Tue, 5 Jul 2016 17:20:55 +0200
+Subject: [PATCH] Let's GTK+ automatically load rtl icon variants
+
+Since GTK 3.13.2, it will automatically load the RTL variant of the
+icons when needed.
+
+https://bugzilla.gnome.org/show_bug.cgi?id=768451
+---
+ configure.ac |  2 +-
+ src/dlg-properties.c |  7 ++-
+ src/goo-player-bar.c | 11 ---
+ src/goo-window.c |  8 ++--
+ src/gtk-utils.h  |  3 ---
+ src/main.c   |  7 ++-
+ 6 files changed, 11 insertions(+), 27 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 9cadce8..94694c9 100644
+--- a/configure.ac
 b/configure.ac
+@@ -16,7 +16,7 @@ GNOME_MAINTAINER_MODE_DEFINES
+ GLIB_GSETTINGS
+ 
+ GLIB_REQUIRED=2.36
+-GTK_REQUIRED=3.10.0
++GTK_REQUIRED=3.13.2
+ GSTREAMER_REQUIRED=1.0.0
+ LIBNOTIFY_REQUIRED=0.4.3
+ LIBMUSICBRAINZ5_REQUIRED=5.0.0
+diff --git a/src/dlg-properties.c b/src/dlg-properties.c
+index 2e05511..5e84180 100644
+--- a/src/dlg-properties.c
 b/src/dlg-properties.c
+@@ -484,15 +484,12 @@ dlg_properties (GooWindow *window)
+ {
+   DialogData *data;
+   GtkWidget *image;
+-  gboolean rtl;
+ 
+ if (window->properties_dialog != NULL) {
+   gtk_window_present (GTK_WINDOW (window->properties_dialog));
+   return;
+ }
+ 
+-rtl = gtk_widget_get_direction (GTK_WIDGET (window)) == 
GTK_TEXT_DIR_RTL;
+-
+   data = g_new0 (DialogData, 1);
+   data->window = window;
+   data->builder = _gtk_builder_new_from_resource ("properties.ui");
+@@ -507,11 +504,11 @@ dlg_properties (GooWindow *window)
+ 
+   image = GET_WIDGET ("prev_album_image");
+   gtk_image_set_from_icon_name (GTK_IMAGE (image),
+-rtl ? "go-previous-rtl-symbolic" : 
"go-previous-symbolic",
++"go-previous-symbolic",
+ GTK_ICON_SIZE_MENU);
+   image = GET_WIDGET ("next_album_image");
+   gtk_image_set_from_icon_name (GTK_IMAGE (image),
+-rtl ? "go-next-rtl-symbolic" : 
"go-next-symbolic",
++"go-next-symbolic",
+ GTK_ICON_SIZE_MENU);
+ 
+   /* Set widgets data. */
+diff --git a/src/goo-player-bar.c b/src/goo-player-bar.c
+index 8734c27..9776d43 100644
+--- a/src/goo-player-bar.c
 b/src/goo-player-bar.c
+@@ -219,9 +219,6 @@ goo_player_bar_construct (GooPlayerBar *self,
+   GtkWidget *main_box;
+   GtkWidget *button_box;
+   GtkWidget *button;
+-  gboolean   rtl;
+-
+-  rtl = gtk_widget_get_default_direction () == GTK_TEXT_DIR_RTL;
+ 
+   frame = gtk_event_box_new ();
+   gtk_style_context_add_class (gtk_widget_get_style_context (frame), 
GTK_STYLE_CLASS_BACKGROUND);

Bug#828967: horizon / CVE-2016-4428 #828967

[Thomas Goirand]

On 07/05/2016 07:37 PM, Moritz Mühlenhoff wrote:
> On Wed, Jun 29, 2016 at 03:50:47PM +0200, Thomas Goirand wrote:
>> On 06/29/2016 11:24 AM, Moritz Muehlenhoff wrote:
>>> Hi Thomas,
>>> https://bugs.launchpad.net/bugs/1567673 has been assigned CVE-2016-4428 and 
>>> I think we should fix
>>> it in jessie-security. Can you please prepare an update? unstable also 
>>> needs the patch.
>>>
>>> Cheers,
>>> Moritz
>>>
>>
>> Hi Moritz,
>>
>> I have uploaded fixes for both Sid and Experimental, and the fix for
>> Stable is committed to Git in here:
>>
>> http://anonscm.debian.org/cgit/openstack/horizon.git/commit/?h=debian/icehouse=d74e751ce93f03240f3ad4206e93d6e7e05da55f
>>
>> Since you may prefer a diff to read from your mail client, I have
>> attached it to this message.
> 
> Why do you upload something different than the debdiff you sent?
> 
> jessie has 2014.1.3-7, and what you uploaded includes an additional
> fix which was never on security.debian.org:
> 
>> horizon (2014.1.3-7+deb8u1) jessie-security; urgency=high
>>
>>  * Fix CVE-2015-3219 with upstream patch (Closes: 788306).
>>
>> -- Thomas Goirand   Wed, 10 Jun 2015 16:18:34 +0200
> 
> Cheers,
> Moritz

Attached the output of:
git diff -u -r debian/2014.1.3-7 \
>horizon_2014.1.3-7_to_2014.1.3-7+deb8u2.diff

Can you review that instead of previous diff?

Cheers,

Thomas Goirand (zigo)

diff --git a/MANIFEST.in b/MANIFEST.in
index 5f29627..c10ab94 100644
--- a/MANIFEST.in
+++ b/MANIFEST.in
@@ -1,6 +1,6 @@
 recursive-include doc *.py *.rst *.css *.js *.html *.conf *.jpg *.gif *.png *.css_t
-recursive-include horizon *.html *.css *.js *.csv *.template *.tmpl *.mo *.po
-recursive-include openstack_dashboard *.html *.js *.less *.mo *.po *.example *.eot *.svg *.ttf *.woff *.png *.ico *.wsgi *.gif *.csv *.template
+recursive-include horizon *.html *.css *.js *.csv *.template *.tmpl *.mo *.po *.py
+recursive-include openstack_dashboard *.html *.js *.less *.mo *.po *.example *.eot *.svg *.ttf *.woff *.png *.ico *.wsgi *.gif *.csv *.template *.py
 recursive-include tools *.py *.sh
 
 include AUTHORS
diff --git a/debian/changelog b/debian/changelog
index 9d004c1..276e48e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+horizon (2014.1.3-7+deb8u2) jessie-security; urgency=medium
+
+  * CVE-2016-4428: Possible client side template injection in horizon. Applied
+upstream patch: "Escape angularjs templating in unsafe HTML" after rebasing
+it for Icehouse (Closes: #828967).
+
+ -- Thomas Goirand   Wed, 29 Jun 2016 15:24:16 +0200
+
+horizon (2014.1.3-7+deb8u1) jessie-security; urgency=high
+
+  * Fix CVE-2015-3219 with upstream patch (Closes: 788306).
+
+ -- Thomas Goirand   Wed, 10 Jun 2015 16:18:34 +0200
+
 horizon (2014.1.3-7) unstable; urgency=medium
 
   * Fix Moscow timezone check and avoid FTBFS (Closes: #775636).
diff --git a/debian/patches/CVE-2015-3219_XSS_in_Horizon_Heat_stack_creation.patch b/debian/patches/CVE-2015-3219_XSS_in_Horizon_Heat_stack_creation.patch
new file mode 100644
index 000..58a39fc
--- /dev/null
+++ b/debian/patches/CVE-2015-3219_XSS_in_Horizon_Heat_stack_creation.patch
@@ -0,0 +1,36 @@
+Description: Escape the description param from heat template
+ The heat template allows user to define custom parameters,
+ the fields are then converted to input fields. The description
+ param maps to the help_text attribute of the field.
+ .
+ Since the value comes from the user, the value must be escaped
+ before rendering.
+Origin: upstream, https://review.openstack.org/#/c/189821/
+Bug: https://bugs.launchpad.net/horizon/+bug/1453074
+Bug-Debian: https://bugs.debian.org/788306
+Forwarded: not-needed
+Author: Lin Hua Cheng 
+Reviewed-By: David Lyle 
+Last-Update: 2015-06-09
+
+---
+
+--- horizon-2014.1.3.orig/openstack_dashboard/dashboards/project/stacks/forms.py
 horizon-2014.1.3/openstack_dashboard/dashboards/project/stacks/forms.py
+@@ -15,6 +15,7 @@
+ import json
+ import logging
+ 
++from django.utils import html
+ from django.utils.translation import ugettext_lazy as _
+ from django.views.decorators.debug import sensitive_variables  # noqa
+ 
+@@ -307,7 +308,7 @@ class CreateStackForm(forms.SelfHandling
+ field_args = {
+ 'initial': param.get('Default', None),
+ 'label': param_key,
+-'help_text': param.get('Description', ''),
++'help_text': html.escape(param.get('Description', '')),
+ 'required': param.get('Default', None) is None
+ }
+ 
diff --git a/debian/patches/CVE-2016-4428_Escape_angularjs_templating_in_unsafe_HTML.patc b/debian/patches/CVE-2016-4428_Escape_angularjs_templating_in_unsafe_HTML.patc
new file mode 100644
index 000..f626e46
--- /dev/null
+++ b/debian/patches/CVE-2016-4428_Escape_angularjs_templating_in_unsafe_HTML.patc
@@ -0,0 +1,74 @@
+Description: CVE-2016-4428: 

Bug#828967: horizon / CVE-2016-4428 #828967

[Thomas Goirand]

On 07/05/2016 07:37 PM, Moritz Mühlenhoff wrote:
> On Wed, Jun 29, 2016 at 03:50:47PM +0200, Thomas Goirand wrote:
>> On 06/29/2016 11:24 AM, Moritz Muehlenhoff wrote:
>>> Hi Thomas,
>>> https://bugs.launchpad.net/bugs/1567673 has been assigned CVE-2016-4428 and 
>>> I think we should fix
>>> it in jessie-security. Can you please prepare an update? unstable also 
>>> needs the patch.
>>>
>>> Cheers,
>>> Moritz
>>>
>>
>> Hi Moritz,
>>
>> I have uploaded fixes for both Sid and Experimental, and the fix for
>> Stable is committed to Git in here:
>>
>> http://anonscm.debian.org/cgit/openstack/horizon.git/commit/?h=debian/icehouse=d74e751ce93f03240f3ad4206e93d6e7e05da55f
>>
>> Since you may prefer a diff to read from your mail client, I have
>> attached it to this message.
> 
> Why do you upload something different than the debdiff you sent?
> 
> jessie has 2014.1.3-7, and what you uploaded includes an additional
> fix which was never on security.debian.org:
> 
>> horizon (2014.1.3-7+deb8u1) jessie-security; urgency=high
>>
>>  * Fix CVE-2015-3219 with upstream patch (Closes: 788306).
>>
>> -- Thomas Goirand   Wed, 10 Jun 2015 16:18:34 +0200
> 
> Cheers,
> Moritz

Moritz,

I would still like both fixes to be included in the update. I'm sorry if
the first one didn't make it yet through proposed-updates, it's probably
my fault if it didn't.

If you wish me to squash version 2014.1.3-7+deb8u1 and 2014.1.3-7+deb8u2
into a single version, please let me know, but I don't think it's very
useful to do so.

Cheers,

Thomas Goirand (zigo)

Bug#811610: FTBFS with GCC 6: nonnull argument compared to NULL

[Mike Gerow]

Hmm... So the reason gcc is complaining is because of this line in
/usr/include/x86_64-linux-gnu/sys/stat.h (on amd64 at least):

extern int __xstat (int __ver, const char *__filename,
struct stat *__stat_buf) __THROW __nonnull ((2, 3));

I'm still not sure if this is common amongst libcs or not, but this seems like a
situation where disabling the warning might be the right move.

-- 
Mike Gerow
ge...@mgerow.com


signature.asc
Description: PGP signature

Bug#829761: epic5: please make the build reproducible

[Reiner Herrmann]

Source: epic5
Version: 1.1.11-1
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps username hostname
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that epic5 could not be built reproducibly.
It embeds the build date/time, username and hostname into the binary.

The attached patch strips this to enable reproducible building.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible-build.patch b/debian/patches/reproducible-build.patch
new file mode 100644
index 000..41960c9
--- /dev/null
+++ b/debian/patches/reproducible-build.patch
@@ -0,0 +1,17 @@
+Author: Reiner Herrmann 
+Description: Strip non-deterministic data to make build reproducible
+
+--- a/source/info.c.sh.in
 b/source/info.c.sh.in
+@@ -25,10 +25,7 @@
+ #define USER "$comp_user"
+ #endif
+ 
+-const char *compile_user = "$comp_user";
+-const char *compile_host = "$comp_host";
+-const char *compile_time = "$comp_time";
+ const char *info_c_sum   = "$info_c_sum";
+-const char *compile_info = "Compiled by " USER "@$comp_host on $comp_time";
++const char *compile_info = "Compiled by Debian";
+ 
+ __E__O__F__
diff --git a/debian/patches/series b/debian/patches/series
index 212dec7..59cb0a3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 config.patch
 manual.patch
 path.patch
+reproducible-build.patch


signature.asc
Description: Digital signature

Bug#759403: lintian: Please publish machine-readable report for all packages

[intrigeri]

Hi,

intrigeri wrote (05 Jul 2016 11:50:03 GMT) :
> Also, before we settle on this output format, I would like to quickly
> validate it by drafting code for the use case I had in mind for that
> machine-readable report.

I drafted that code in Python 3 and then in Perl (since the Python 3
version needed 8GB of RAM to load the YAML file into a Python data
structure in 135 seconds, while the Perl version needs 1.5GB of RAM
and 15 seconds), and am happy with what I see, except I realize that
I totally ignored the possibility that tags can be overridden.

Now I notice that I need this piece of info in the YAML report, and
will thus resume working on my draft to add it (I didn't check yet if
the current code makes this easy, or not — we'll see).

Cheers,
--
intrigeri

Bug#829760: fish: update debian/watch to be more release reactive

[Patrice Duroux]

Package: fish
Version: 2.3.0-1
Severity: wishlist

Dear Maintainer,

I am not sure about the following patch as a suggestion to be more upstream 
reactive
by checking the GitHub repository.

'man uscan' on my current sid suggests me the patch (version=4) but without 
specifying
signature check and https://wiki.debian.org/debian/watch suggests another 
(version=3)
but then the signature check doesn't work.
I would have help more.

Regards,
Patrice
 
diff --git a/debian/watch b/debian/watch
index 8ffc860..0b076e5 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,4 +1,4 @@
-version=3
-opts=dversionmangle=s/\+dfsg\d*$//,repacksuffix=+dfsg1 \
-http://fishshell.com/ \
-(?:|.*/)fish(?:[_\-]v?|)(\d[^\s/]*)\.(?:tar\.xz|txz|tar\.bz2|tbz2|tar\.gz|tgz)
+version=4
+opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%fish-shell-$1.tar.gz%" \
+   https://github.com/fish-shell/fish-shell/tags \
+   (?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate



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

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

Versions of packages fish depends on:
ii  bc  1.06.95-9+b1
ii  chromium [www-browser]  51.0.2704.79-1
ii  dpkg1.18.9
ii  firefox [www-browser]   47.0.1-1
ii  fish-common 2.3.0-1
ii  libc6   2.23-1
ii  libgcc1 1:6.1.1-8
ii  libncurses5 6.0+20160319-2+b1
ii  libpcre2-32-0   10.21-1
ii  libstdc++6  6.1.1-8
ii  libtinfo5   6.0+20160319-2+b1
ii  vivaldi-snapshot [www-browser]  1.3.519.23-1

Versions of packages fish recommends:
ii  xsel  1.2.0-2

Versions of packages fish suggests:
pn  doc-base  

-- no debconf information

Bug#829759: xfce4-volumed missing from testing

[beefreak]

Package: xfce4-volumed

Version: testing

dear maintainer, please reanimate the xfce4-volumed package, as it is in
ubuntu.

The ubuntu package  xfce4-volumed_0.2.0-0ubuntu2_amd64.deb work for
testing without trouble.

Or  please suggest one alternative for xfce4 and volume buttons.


Thank You

Bug#829750: [pkg-gnupg-maint] Bug#829750: gnupg2: 2.1.13 can't connect to dirmngr from 2.1.11

[Werner Koch]

On Tue,  5 Jul 2016 20:41, jcowg...@debian.org said:

> Would it be a good idea to add a 'Breaks: dirmngr (<< 2.13)' to gnupg
> to ensure this doesn't happen?

Most thinks keep on working with a running old dirmngr or gpg-agent.
But it is not a good idea to do this.  gpg prints a warning if it
connects to an older dirmngr or gpg-agent (also with a --status-fd
line).


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf   */

Bug#829758: epic4: please make the build reproducible

[Reiner Herrmann]

Source: epic4
Version: 1:2.10.5-2
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps username hostname
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that epic4 could not be built reproducibly.
It embeds the build time, username and hostname into the binary.

The attached patch strips this to enable reproducible building.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/03_reproducible_build.patch b/debian/patches/03_reproducible_build.patch
new file mode 100644
index 000..41960c9
--- /dev/null
+++ b/debian/patches/03_reproducible_build.patch
@@ -0,0 +1,17 @@
+Author: Reiner Herrmann 
+Description: Strip non-deterministic data to make build reproducible
+
+--- a/source/info.c.sh.in
 b/source/info.c.sh.in
+@@ -25,10 +25,7 @@
+ #define USER "$comp_user"
+ #endif
+ 
+-const char *compile_user = "$comp_user";
+-const char *compile_host = "$comp_host";
+-const char *compile_time = "$comp_time";
+ const char *info_c_sum   = "$info_c_sum";
+-const char *compile_info = "Compiled by " USER "@$comp_host on $comp_time";
++const char *compile_info = "Compiled by Debian";
+ 
+ __E__O__F__
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..c7a15ff
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+03_reproducible_build.patch


signature.asc
Description: Digital signature

Bug#810301: merged /usr support for debootstrap

[Marco d'Itri]

On Jul 05, Cyril Brulebois  wrote:

> > +   case $ARCH in
> > +   hurd-*) return 0 ;;
> > +   amd64)  link_dir="lib32 lib64 libx32" ;;
[...]

> I don't think having to play catch up with src:glibc is a good idea.
> Can't that be determined automatically instead of hardcoding this
> mapping?
I double checked with the glibc people: this could be done with gcc 
-print-multi-lib, but I do not think that depending on gcc is an option 
(also: foreign deboostrap).

> Besides, this code means an unknown architecture doesn't get merged
> /usr support. Is that intended/reasonable?
This would be a (small) problem only for new architectures with multilib 
libraries, and I do not expect that we will have any more of these.
E.g. you can see that arm64 is not in the list since it does not use 
/lib64 for multilib, but only multiarch.

Also, this would not be a big deal anyway because these extra links are 
only needed to install multilib libraries, so if they will be needed at 
development time for a new architecture they can easily be created 
manually before installing the multilib libc package.

Also again, these links are only an interim workaround to support 
merged-/usr systems without rebuilding the library packages: I expect 
that in the future nobody would bother installing non-merged systems, so 
if we can drop support for that then we can just build the multilib libc 
packages to create the /lib64 symlinks themselves when installed.

> >  first_stage_install () {
> > +   case $SUITE in
> > +   etch|etch-m68k|jessie|lenny|squeeze|wheezy) ;;
> > +   oldstable|stable) ;;
> > +   *) setup_merged_usr ;;
> This means “debootstrap stable” on stretch once it's released is going
> to lead to different results compared to “debootstrap stretch”.
I know, but I expected that at some point close to the next release the 
"stable" keyword would be moved. Or is there a better approach?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#810301: merged /usr support for debootstrap

[Cyril Brulebois]

[ Adding kfreebsd and hurd porters to the loop. ]

Cyril Brulebois  (2016-07-05):
> Marco d'Itri  (2016-01-08):
> > +# Find out where the runtime dynamic linker and the shared libraries
> > +# can be installed on each architecture: native, multilib and multiarch.
> > +# This data can be verified by checking the files in the debian/sysdeps/
> > +# directory of the glibc package.
> > +#
> > +# This function must be updated to support any new architecture which
> > +# either installs the RTLD in a directory different from /lib or builds
> > +# multilib library packages.
> > +setup_merged_usr() {
> > +   if [ "$MERGED_USR" = "no" ]; then return 0; fi
> > +
> > +   local link_dir
> > +   case $ARCH in
> > +   hurd-*) return 0 ;;

hurd porters, is that OK?

kfreebsd porters, what should we have here for your archs?

For those wondering (and AFAICT) it seems the only issue here is how to
handle multilib, since multiarch is “hidden” below usr/lib (in
usr/lib/ subdirectories).

> > +   amd64)  link_dir="lib32 lib64 libx32" ;;
> > +   i386)   link_dir="lib64 libx32" ;;
> > +   mips|mipsel)
> > +   link_dir="lib32 lib64" ;;
> > +   mips64*|mipsn32*)
> > +   link_dir="lib32 lib64 libo32" ;;
> > +   powerpc)link_dir="lib64" ;;
> > +   ppc64)  link_dir="lib32 lib64" ;;
> > +   ppc64el)link_dir="lib64" ;;
> > +   s390x)  link_dir="lib32" ;;
> > +   sparc)  link_dir="lib64" ;;
> > +   sparc64)link_dir="lib32 lib64" ;;
> > +   x32)link_dir="lib32 lib64 libx32" ;;
> > +   esac
> > +   link_dir="bin sbin lib $link_dir"
> > +
> > +   local dir
> > +   for dir in $link_dir; do
> > +   ln -s usr/$dir $TARGET/$dir
> > +   mkdir -p $TARGET/usr/$dir
> > +   done
> > +}
> > +
> 
> I don't think having to play catch up with src:glibc is a good idea.
> Can't that be determined automatically instead of hardcoding this
> mapping?

Just checked with a regular porter, it doesn't seem crazy to expect
porters to come up with an extra patch for d-i/debootstrap support once
they're done bootstrapping their port. So, that addresses my initial
concern.

> Besides, this code means an unknown architecture doesn't get merged
> /usr support. Is that intended/reasonable?

Actually, this means an architecture which isn't listed doesn't get
extra paths, and /lib might be enough for some ports, e.g. arm64.

It would seem a better idea to list all ports explicitly though.

> >  first_stage_install () {
> > +   case $SUITE in
> > +   etch|etch-m68k|jessie|lenny|squeeze|wheezy) ;;
> > +   oldstable|stable) ;;
> > +   *) setup_merged_usr ;;
> 
> This means “debootstrap stable” on stretch once it's released is going
> to lead to different results compared to “debootstrap stretch”.

That part remains to be fixed.


KiBi.


signature.asc
Description: Digital signature

Bug#696414: git-buildpackage: new option --symlink-orig-name [PATCH]

[Guido Günther]

On Thu, Dec 20, 2012 at 03:51:22PM +0100, Piotr Roszatycki wrote:
> Package: git-buildpackage
> Version: 0.6.0~git20121124
> Severity: wishlist
> Tags: patch
> 
> I would like to use git-import-orig tools to import upstream tarballs
> for non-Debian packages. I missed an option which would allow me to
> import tarballs with other naming schema than the default
> ../%s_%s.orig.tar%s
> 
> This is a patch
> (https://github.com/dex4er/git-buildpackage/commit/633f809b730e64f485a0f62776e9ccfb6d2f6138)
> which implements a new option --symlink-orig-name. It allows me to
> import CPAN packages into Git repository (attached cpan-import.sh). I
> found a git-buildpackage as a more universal tool.

Sorry for the delay! In case you're still interested in this:

Do I understand it correctly that You want to keep the symlink but give
it another name? If so, this looks o.k. but it would be really nice to
have a test for this since otherwise it might get broken quickly due to
few people using it. Could you add that?

Cheers,
 -- Guido

Bug#829757: RM: iceowl-l10n/experimental -- ROM; Package part of icedove now

[Guido Günther]

Package: ftp.debian.org
Severity: normal