Bug#841004: dahdi-source: Provide dkms setup to build kernel module automatically?

[Tzafrir Cohen]

On Sun, Oct 16, 2016 at 09:01:12PM +0200, Petter Reinholdtsen wrote:
> 
> Package: dahdi-source
> Version: 1:2.10.0.1~dfsg-1
> Severity: wishlist
> 
> Hi.  Looking at the dahdi-source package, it occured to me that perhaps
> it would be a good idea to use the dkms system to build the dahdi kernel
> module automatically?  Would it be possible?  Is it a good idea?

This is one of the changes in the Ubuntu package.

Personally for me I prefer d-i, as it allows producing stand-alone
packages, which better fit my use case. As long as this is not broken, I
have no objection.

One annoying aspect of dkms is that there's a template that needs to be
created. It is possible to create it manually. But it is annoying for a
package with so many modules such as DAHDI (and some are added on
patching). Automating it would be a bonus.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend

Bug#841153: eatmydata-udev: Use /etc/ld.so.preload instead of /etc/apt/apt.conf.d/95install-dpkg-eatmydata?

[Petter Reinholdtsen]

Package: eatmydata-udev
Version: 105-4
Severity: wishlist

 [03:43:07 PM]  do you really need a divert? can you not just 
add eatmydata to /etc/ld.so.preload?
 [03:43:13 PM]  then everything gets it for free
 pere: ↑ comment about the implementation

This is an excellent idea, which might even make the implementation of
debian/eatmydata-udeb.eatmydata-install easier as it only need to modify
one file instead of two.

-- 
Happy hacking
Petter Reinholdtsen

Bug#841152: ITP: node-pascalcase -- Convert a string to pascal-case

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-pascalcase
  Version : 0.1.1
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/pascalcase
* License : Expat
  Programming Lang: JavaScript
  Description : Convert a string to pascal-case

Bug#840929: failed to create proper watch file even though homepage is set in package.json and tags are present

[Pirate Praveen]

On Sun, 16 Oct 2016 14:36:16 +0530 Pirate Praveen 
wrote:
> 
> node module where this happened: repeat-string
> 
Also failed for
https://github.com/isaacs/isexe/releases



signature.asc
Description: OpenPGP digital signature

Bug#841151: ITP: node-isexe -- Minimal module to check if a file is executable

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-isexe
  Version : 1.1.2
  Upstream Author : Isaac Z. Schlueter  (http://blog.izs.me/)
* URL : https://github.com/isaacs/isexe#readme
* License : ISC
  Programming Lang: JavaScript
  Description : Minimal module to check if a file is executable.

Dependency for updating which to 1.2.11, which is in turn a dependency
of grunt-legacy-util and grunt.



signature.asc
Description: OpenPGP digital signature

Bug#840849: [pkg-gnupg-maint] Bug#840849: gnupg2: pubkeyring and secretkey unusable

[Daniel Kahn Gillmor]

Hi Mechtilde--

On Sat 2016-10-15 09:54:00 -0400, mechtilde wrote:
> since last update on Friday 2016-10-14 I can't use my key(ring). As I try to
> list the keys with 'gpg --list-public-keys' as using it with enigmail fails.
>
> So neither I can read crypted mails nor I can send cryted and/or signed mails
> from this machine.
>
> The keyfiles themselves are the same as at an stable machine where gnupg and
> enigmail works.

I think we managed to resolve this on IRC -- is this the same problem
that was resolved with a second "gpg --import ~/.gnupg/secring.gpg" ?
If so, do you have any more info about the differences between
private-keys-v1.d before and after the import?

  --dkg


signature.asc
Description: PGP signature

Bug#791944: My workaround

[Theppitak Karoonboonyanan]

On Sun, Oct 16, 2016 at 12:56 AM, Guilhem Moulin  wrote:
> On Sat, 15 Oct 2016 at 08:13:27 +0700, Theppitak Karoonboonyanan wrote:
>> Reassigning the bug to udev to hear its maintainer's opinion.
>
> I think this is a initscripts bug, not a udev bug.  Both the
> ‘cryptdisks-early’ and ‘cryptdisks’ LSB init scripts have had a
> “Should-Stop: udev” header.  Shouldn't this be enough to have udevd
> still running during cryptdisks shutdown?  If that's the case then the
> culprit is sendsigs as it violates shutdown dependencies.

Given its function to "killall5", how can sendsigs discriminate
between processes to be killed and those to be preserved?
How can it know which daemons were started by a named service
(udev in this case) so it can skip sending SIGTERM to them?

I think what sendsigs has provided for this purpose is the
/run/sendsigs.omit.d/ directory, as documented in
/usr/share/doc/initscripts/README.Debian.

And to add a process to the omission list, a most appropriate
place to do so is udev's init script itself, where the daemon was
started. That's why I reassign the bug to it.

Regards,
-- 
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/

Bug#841143: [pkg-gnupg-maint] Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup

[Daniel Kahn Gillmor]

On Mon 2016-10-17 20:50:02 -0400, Ian Jackson wrote:

> I have now, for the 2nd time, seen an unexplained failure while
> running the dgit test suite, looking like this:
>
> + gpg --detach-sign --armor -u 39B13D8A .git/dgit/tag.tmp
> gpg: WARNING: unsafe permissions on homedir 
> '/home/ian/things/Dgit/dgit/tests/tmp/distropatches-reject/gnupg'

Is it possible to create this homedir with mode 0700 ?  aiui, gpg-agent
doesn't want to create its sockets in a directory that other users have
read and write access to.

 --dkg


signature.asc
Description: PGP signature

Bug#840403: cinnamon: Unable to rebind ALT-F1 to something else than Toggle Expo

[Egon Kidmose]

Hey Marga,

Fair enough :)

And to install from backports, would I be doing something like this?

sudo apt-get -t jessie-backports install cinnamon

Thanks!

Mvh. / BR
Egon Kidmose

On Sun, Oct 16, 2016 at 6:48 PM, Margarita Manterola 
wrote:

> Control: fixed -1 3.0.4-2~bpo8+1
>
> Hi!
>
> We worked on this together with Maxy today.
>
> We were able to reproduce this problem in the version of Cinnamon that is
> in Jessie.  It seems that somehow the Alt-F1 keybinding was hardcoded in a
> way that didn't even appear in the list of keybindings and so it couldn't
> get
> removed.
>
> We also verified that the version in backports doesn't have this issue, so
> you
> could try with that one instead.
>
> Unfortunately, while we acknowledge that this is a bug, it's not feasible
> for us
> to fix a bug like this in the version in stable.
>
> --
> Regards,
> Marga
>
>

Bug#840295: Requesting RC exception for stretch for browserified javascript

[Pirate Praveen]

On Thursday 13 October 2016 03:47 AM, Julien Cristau wrote:
> IMO, it may be ok to request exceptions for specific packages/bugs (and
> then we may or may not grant that), but not such a broad "let's ignore
> the DFSG" exception.

This is specific case where code in question is human readable and
modifiable.

But lets not go there now, we'll talk about specific cases.

1. libjshandlebars/node-handlebars - #830986

It needed jison and grunt. jison is now packaged, we are working on
grunt (http://igg.me/at/debian-browserify).

Its a dependency for diaspora.

2. libjs-fuzzaldrin-plus - #814871

needs grunt.

Its a dependency for gitlab.

3. jquery plugins for pagure. (I have not looked at them, but counting
on the comment from Sergio
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829046#82)

#836406, #836407, #836408

They all need grunt.



signature.asc
Description: OpenPGP digital signature

Bug#840669: [pkg-gnupg-maint] Bug#840669: Bug#840669: Beware of leftover gpg-agent processes

[Daniel Kahn Gillmor]

On Sat 2016-10-15 11:21:29 -0400, Ian Jackson wrote:
> 1. gnupg1-compatible authorisation lifetime:

I believe this is a deliberate change in semantics from the upstream
GnuPG project.  In particular, authorization for the use of secret key
material is now the responsibility of the gpg-agent.  This is an overall
win, because it means that no process ever gets access to the secret key
in memory *except* for the gpg-agent.  The gpg-agent is where these
decisions are made.

If you want an agent that never caches any passphrase (and therefore has
a one-use-per-authorization), this is an easy thing to do by adjusting
max-cache-ttl in gpg-agent.conf.  you can also set this dynamically with
gpgconf (see the --runtime option in gpgconf(1)).

> 2. Explicit programmatic control of authorisation lifetime:

This is also present in some form with the current gpg, but there are a
couple different ways to do it -- you can still set up and tear down a
separate gpg-agent (though managing that independently from other
sessions can be tricky); you can set authorization cache times that
are bounded to the times you prefer; or you can explicitly tear down the
agent after a given run.

btw, upstream now has fixes to the inotify teardown approach, which i
hope to land in debian unstable in the next day or two.

Thanks for your engagement on this issue, Ian.

  --dkg


signature.asc
Description: PGP signature

Bug#838860: Version 32+ Flash (SWF) files detected as 'application/octet-stream' (data), not 'application/x-shockwave-flash' by file (libmagic1)

[Laurence Parry]

Perhaps, though the SWF format does not make it easy . . .

== FWS ==
https://www.adobe.com/content/dam/Adobe/en/devnet/swf/pdf/swf-file-format-spec.pdf
(See Appendix A for another walkthrough)

All integer values are little-endian byte order, but big-endian bit order 
within bytes. Signed integers have typical twos-complement arithmetic 
including sign-extension.


To start with, FrameSize is a RECT - a variable-length structure starting 
with an _unsigned_ five-bit value determining how many bits the other four 
_signed_ bit-values (Xmin, Xmax, Ymin, Ymax) each have. If it starts 01011 
in bitstream order, the next eleven bits are Xmin, and so on.


On the plus side, "FrameSize RECT always has Xmin and Ymin value of 0." So 
we could create 31 cases depending on the value of the ninth octet equating 
to a particular bitmask and then check for 0-values for Xmin and Xmax [which 
vary in length and, for Ymin, position, depending on their length].


In other words, in this particular case, we check in bitstream order for:
[01011|000|xxx|00]
[mask |   Xmin   |   Xmax   |   Ymin  ]

I foresee lots of & and ^, unfortunately. But it should be possible. Could 
short-cut it a bit, since for all but the 1- and 2-bit cases, the rest of 
the ninth octet must be 0 in order to match Xmin, so it's not necessary to 
mask the ninth octet to match the first five bits.


FrameRate and FrameCount might be useful, too. Note that as integers, they 
are byte-aligned, with zero-padding at the end of the preceding RECT if 
necessary.


--

There is another problem: those octets are only guaranteed to be available 
for FWS. In the case of CWS or ZWS, the files are compressed after Length 
with ZLIB (introduced in SWF 6) or LZMA (SWF 13) respectively.


The file in question was CWS, and I understand this to be the default option 
in current versions of Adobe software, which are also the ones most likely 
to be saving files in the latest versions. Reviewing an assortment of the 
latest SWF files uploaded to our website, the division is 60%/40% CWS/FWS.


The compressed length relates to the actual length of the file, but I don't 
think libmagic can use that. However, the files must be in the according 
compressed formats, which have their own headers that may be of use.


== ZLIB  (CWS) ==
https://www.ietf.org/rfc/rfc1950.txt
CM (compression method) nibble is always 8, and the CINFO (compression info) 
nibble which defines the base-2 logarithm of the LC77 window size, minus 
eight, must be 7 or below. In all the files I have examined, it is 7; 
however it could theoretically be something else. This means the ninth byte 
of a CWS file is 0xN8 , where N <= 7; and commonly it is 0x78 ('x'). [Note: 
it is perfectly possible for an uncompressed FWS file to have an 0x78 in the 
9th position.]


The flag octet after it, is commonly 0x9C ('Œ') but this is not guaranteed; 
I have also seen 0xDA ('Ú') and various items may be expected, so I would 
not rely on it. Beyond that is the possible dictionary ID and then 
compressed data.


== LZMA (ZWS) ==
http://www.7-zip.org/a/lzma-specification.7z
with a summary at
https://svn.python.org/projects/external/xz-5.0.3/doc/lzma-file-format.txt

I don't have any of these SWF files to hand, but the specification above 
notes that LZMA Utils only creates files with lz/lp/pb values 3/0/2. This 
would correspond to a properties byte of 0x5d (9th octet). There is also a 
little-endian dictionary size and a file length, which may be all FF if it 
is unknown. For comparison, one bare .lzma file looks like this:


  5d 00 00 80 00 ff ff ff  ff ff ff ff ff 00 16 e9 
|]...|


But it is technically possible to create a valid LZMA stream with other 
property bytes, and presumably these would be valid SWF files as well. 
Perhaps it's possible to delegate to the LZMA and ZLIB magic to test this?


--
Laurence "GreenReaper" Parry
http://greenreaper.co.uk - https://inkbunny.net 

Bug#840295: Requesting RC exception for stretch for browserified javascript

[Pirate Praveen]

On Tuesday 18 October 2016 12:32 AM, Emilio Pozuelo Monfort wrote:
> Hi Pirate,
> 
> On 10/10/16 11:57, Pirate Praveen wrote:
>> package: release.debian.org
>>
>> Dear Release Team,
>>
>> As discussed with FTP masters[1], I'd like to request an RC exception
>> for browserified javascript packages already in the archive.
> 
> Please correct me if I'm wrong, but I haven't seen any replies to the 
> questions
> you've got. I'm not sure what I'll think when you do that, but at the moment
> this is a nack from me. Packages can still go into contrib if the build tools
> can't get ready in time for the release, and then for buster (stretch+1) they
> could move to main.

I was waiting for jison packaging to complete, so the discussion can
focus on the browserify part. jison is not accepted in main. I'll reply
to those questions now.

> Another question is what build tools are we missing at this point? I have seen
> some mentioned in the tech-ctte thread. Mostly grunt, which is ITP #673727. 
> The
> main problem there seems to be that jshint is non-free, but it seems[1] that 
> it
> can be made optional. Is that not the case? Are there other blockers, aside 
> from
> packaging the rdeps[2]? It'd be good to know what we are missing to get these
> javascript packages buildable in main, and what is blocking those from 
> entering
> the archive.

jison was blocking libjs-handlebars, which is now packaged. Now only
grunt is blocking. The huge number of dependencies is the only issue
with grunt. We are crowd funding to work full time for a month to get
this packaged -> http://igg.me/at/debian-browserify. We have already
completed 30+ dependencies in last 3-4 days. If we cannot complete grunt
for jessie, then only we need to consider the exception.




signature.asc
Description: OpenPGP digital signature

Bug#841150: openclonk: Segfault while loading game

[Ben Longbons]

Package: openclonk
Version: 7.0-4
Severity: normal

Dear Maintainer,

Every time I load any savegame from the first mission (The Raid), the game
crashes.

I have a coredump in case further information is needed.

(gdb) bt
#0  0x558cacdc in (anonymous namespace)::CompileFloat(StdCompiler*, 
float&) (pComp=0x7fffc9f0, f=@0x1c: ) at 
./src/lib/StdMesh.cpp:190
#1  0x558d24f6 in 
StdMeshInstance::AnimationNode::CompileFunc(StdCompiler*, StdMesh const*) 
(pComp=0x7fffc9f0, this=) at ./src/lib/StdMesh.cpp:229
#2  0x558d24f6 in 
StdMeshInstance::AnimationNode::CompileFunc(StdCompiler*, StdMesh const*) 
(pComp=0x7fffc9f0, rStruct=) at ./src/lib/StdCompiler.h:319
#3  0x558d24f6 in 
StdMeshInstance::AnimationNode::CompileFunc(StdCompiler*, StdMesh const*) 
(rStruct=, this=0x7fffc9f0) at ./src/lib/StdCompiler.h:171
#4  0x558d24f6 in 
StdMeshInstance::AnimationNode::CompileFunc(StdCompiler*, StdMesh const*) 
(pComp=0x7fffc9f0, this=) at ./src/lib/StdAdaptors.h:80
#5  0x558d24f6 in 
StdMeshInstance::AnimationNode::CompileFunc(StdCompiler*, StdMesh const*) 
(rStruct=, this=0x7fffc9f0) at ./src/lib/StdCompiler.h:170
#6  0x558d24f6 in 
StdMeshInstance::AnimationNode::CompileFunc(StdCompiler*, StdMesh const*) 
(this=this@entry=0x622497c0, pComp=pComp@entry=0x7fffc9f0, 
Mesh=0x5ade45c0) at ./src/lib/StdMesh.cpp:889
#7  0x558d63c4 in 
StdPtrAdaptCompileFunc(StdCompiler*, StdPtrAdapt const&, 
StdMesh const* const&) (pComp=0x7fffc9f0, this=) at 
./src/lib/StdAdaptors.h:446
#8  0x558d63c4 in 
StdPtrAdaptCompileFunc(StdCompiler*, StdPtrAdapt const&, 
StdMesh const* const&) (rStruct=, this=0x7fffc9f0) at 
./src/lib/StdCompiler.h:170
#9  0x558d63c4 in 
StdPtrAdaptCompileFunc(StdCompiler*, StdPtrAdapt const&, 
StdMesh const* const&) (rPar=@0x7fffc728: 0x5ade45c0, 
pComp=0x7fffc9f0, pStruct=) at ./src/lib/StdCompiler.h:346
#10 0x558d63c4 in 
StdPtrAdaptCompileFunc(StdCompiler*, StdPtrAdapt const&, 
StdMesh const* const&) (adapt=@0x7fffc730: {
   = {
rpObj = @0x7fffc718, 
fAllowNull = true, 
szNaming = 0x55a7537e "AnimationNode"
  }, }, par=@0x7fffc728: 0x5ade45c0, 
pComp=0x7fffc9f0) at ./src/lib/StdAdaptors.h:622
#11 0x558d63c4 in 
StdPtrAdaptCompileFunc(StdCompiler*, StdPtrAdapt const&, 
StdMesh const* const&) (pComp=pComp@entry=0x7fffc9f0, 
adapt=@0x7fffc730: {
   = {
rpObj = @0x7fffc718, 
fAllowNull = true, 
szNaming = 0x55a7537e "AnimationNode"
  }, }, par=@0x7fffc728: 0x5ade45c0) at 
./src/lib/StdAdaptors.h:609
#12 0x558d33b6 in StdMeshInstance::CompileFunc(StdCompiler*, 
StdMeshInstance::AttachedMesh::Denumerator* (*)()) (p=@0x7fffc728: 
0x5ade45c0, pComp=0x7fffc9f0, this=0x7fffc730)
at ./src/lib/StdAdaptors.h:520
#13 0x558d33b6 in StdMeshInstance::CompileFunc(StdCompiler*, 
StdMeshInstance::AttachedMesh::Denumerator* (*)()) (pComp=0x7fffc9f0, 
this=0x7fffc720) at ./src/lib/StdAdaptors.h:446
#14 0x558d33b6 in StdMeshInstance::CompileFunc(StdCompiler*, 
StdMeshInstance::AttachedMesh::Denumerator* (*)()) (rStruct=@0x7fffc720: {
  rObj = @0x7fffc730, 
  Par = 0x5ade45c0
}, this=0x7fffc9f0) at ./src/lib/StdCompiler.h:170
#15 0x558d33b6 in StdMeshInstance::CompileFunc(StdCompiler*, 
StdMeshInstance::AttachedMesh::Denumerator* (*)()) 
(this=this@entry=0x61875370, pComp=pComp@entry=0x7fffc9f0, 
Factory=Factory@entry=0x5599c8c0 
) at 
./src/lib/StdMesh.cpp:1568
#16 0x5599b631 in C4Object::CompileFunc(StdCompiler*, C4ValueNumbers*) 
(pComp=0x7fffc9f0, this=) at ./src/lib/StdAdaptors.h:446
#17 0x5599b631 in C4Object::CompileFunc(StdCompiler*, C4ValueNumbers*) 
(pComp=0x7fffc9f0, rStruct=) at ./src/lib/StdCompiler.h:319
#18 0x5599b631 in C4Object::CompileFunc(StdCompiler*, C4ValueNumbers*) 
(rStruct=, this=0x7fffc9f0) at ./src/lib/StdCompiler.h:171
#19 0x5599b631 in C4Object::CompileFunc(StdCompiler*, C4ValueNumbers*) 
(pComp=0x7fffc9f0, this=) at ./src/lib/StdAdaptors.h:80
#20 0x5599b631 in C4Object::CompileFunc(StdCompiler*, C4ValueNumbers*) 
(rStruct=, this=0x7fffc9f0) at ./src/lib/StdCompiler.h:170
#21 0x5599b631 in C4Object::CompileFunc(StdCompiler*, C4ValueNumbers*) 
(this=this@entry=0x6226f7a0, pComp=pComp@entry=0x7fffc9f0, 
numbers=0x7fffcbe0) at ./src/object/C4Object.cpp:2340
#22 0x559a2334 in StdPtrAdaptCompileFunc(StdCompiler*, StdPtrAdapt const&, C4ValueNumbers* 
const&) (pComp=0x7fffc9f0, this=)
at ./src/lib/StdAdaptors.h:446
#23 0x559a2334 in 

Bug#840153: Should have various tutorial manpages

[Sean Whitton]

Hello Ian,

Would you accept a patch to your Makefile to compile manpages from
perl's POD format?  Or is there some other format you'd prefer?  I'd
like to confirm in advance of starting to write.

I'm impressed that you seem to have written the existing dgit.7 and
dgit.1 in troff, but I'd rather not.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#841149: devscripts: Improvements for debrepro script

[James McCoy]

Thanks for the patches!  I think the first patch is straight forward
enough.  I'll let Antonio comment on whether he wants to apply the other
two.  I just had one comment, inline.

> From 607b2b8f5c12377efe9b81e4bdf8105a3f2a6c0c Mon Sep 17 00:00:00 2001
> From: Guillem Jover 
> Date: Tue, 18 Oct 2016 03:54:21 +0200
> Subject: [PATCH 2/3] debrepro: Use dpkg-buildpackage instead of ad-hoc code
> 
> Part of the reproducible machinery is handled already by
> dpkg-buildpackage, so there's no need to duplicate it. We can also
> pass faketime+fakeroot as a normal gain-root-command.
> ---
>  scripts/debrepro.sh | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/scripts/debrepro.sh b/scripts/debrepro.sh
> index 38dd14f..0003d22 100755
> --- a/scripts/debrepro.sh
> +++ b/scripts/debrepro.sh
> @@ -56,8 +56,6 @@ create_build_script() {
>echo "# package"
>echo
>  
> -  echo 'export SOURCE_DATE_EPOCH=$(date -d "$(dpkg-parsechangelog -SDate)" 
> +%s)'
> -
>variation PATH
>vary '' 'export PATH="$PATH":/i/capture/the/path'
>  
> @@ -83,13 +81,9 @@ create_build_script() {
>  echo 'cd ../disorderfs'
>fi
>  
> -  echo
> -  echo 'dpkg-source --before-build .'
> -  echo 'fakeroot debian/rules clean'
> -
>variation date
> -  vary 'fakeroot debian/rules binary' \
> -'faketime "+213days +7hours +13minutes" fakeroot debian/rules binary'
> +  vary 'dpkg-buildpackage -b' \
> +'dpkg-buildpackage -b -r"faketime +213days+7hours+13minutes fakeroot"'

Shouldn't these use "-us -uc" too?  The intention of debrepro is just to
check for variance, not to produce something to upload, so I don't think
it should default to signing.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#840295: Requesting RC exception for stretch for browserified javascript

[Pirate Praveen]

On 2016, ഒക്‌ടോബർ 18 12:32:40 AM IST, Emilio Pozuelo Monfort  
wrote:
>Hi Pirate,
>
>On 10/10/16 11:57, Pirate Praveen wrote:
>> package: release.debian.org
>> 
>> Dear Release Team,
>> 
>> As discussed with FTP masters[1], I'd like to request an RC exception
>> for browserified javascript packages already in the archive.
>
>Please correct me if I'm wrong, but I haven't seen any replies to the
>questions
>you've got. I'm not sure what I'll think when you do that, but at the
>moment
>this is a nack from me. Packages can still go into contrib if the build
>tools
>can't get ready in time for the release, and then for buster
>(stretch+1) they
>could move to main.

Sorry, I was waiting to complete jison packaging (so the discussion can move to 
another stage). I'll add the packages, relevant bugs, missing tools for the 
libraries I want exception soon.

>Another question is what build tools are we missing at this point? I
>have seen
>some mentioned in the tech-ctte thread. Mostly grunt, which is ITP
>#673727. The
>main problem there seems to be that jshint is non-free, but it seems[1]
>that it
>can be made optional. Is that not the case? Are there other blockers,
>aside from
>packaging the rdeps[2]? It'd be good to know what we are missing to get
>these
>javascript packages buildable in main, and what is blocking those from
>entering
>the archive.

jison was a blocker for libjs-handlebars, I completed packaging it. For grunt, 
the issue is huge number of dependencies you need to package. We are crowd 
funding to work full time on grunt (http://igg.me/at/debian-browserify). We 
completed 30+ dependencies in 3-4 days. I also think jshint can be made 
optional.

>Cheers,
>Emilio
>
>[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673727#56
>[2] https://wiki.debian.org/Javascript/Nodejs/Tasks/grunt

Bug#840295: Requesting RC exception for stretch for browserified javascript

[Pirate Praveen]

On 2016, ഒക്‌ടോബർ 18 12:32:40 AM IST, Emilio Pozuelo Monfort  
wrote:
>Hi Pirate,
>
>On 10/10/16 11:57, Pirate Praveen wrote:
>> package: release.debian.org
>> 
>> Dear Release Team,
>> 
>> As discussed with FTP masters[1], I'd like to request an RC exception
>> for browserified javascript packages already in the archive.
>
>Please correct me if I'm wrong, but I haven't seen any replies to the
>questions
>you've got. I'm not sure what I'll think when you do that, but at the
>moment
>this is a nack from me. Packages can still go into contrib if the build
>tools
>can't get ready in time for the release, and then for buster
>(stretch+1) they
>could move to main.
>
>Another question is what build tools are we missing at this point? I
>have seen
>some mentioned in the tech-ctte thread. Mostly grunt, which is ITP
>#673727. The
>main problem there seems to be that jshint is non-free, but it seems[1]
>that it
>can be made optional. Is that not the case? Are there other blockers,
>aside from
>packaging the rdeps[2]? It'd be good to know what we are missing to get
>these
>javascript packages buildable in main, and what is blocking those from
>entering
>the archive.
>
>Cheers,
>Emilio
>
>[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673727#56
>[2] https://wiki.debian.org/Javascript/Nodejs/Tasks/grunt

Bug#841149: devscripts: Improvements for debrepro script

[Guillem Jover]

Package: devscripts
Version: 2.16.8
Severity: wishlist
Tags: patch

Hi!

This is a patch serie with some improvements to the debrepro script.
The main theme is that it switches to use dpkg-buildpackage as the
driver to reduce complexity, and compares .changes files instead of
individual .deb, and fallsback to debdiff which should be better
than cmp(1).

Thanks,
Guillem
From cdd89046859b7c3a36f37bac17179c13aba6eee6 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 18 Oct 2016 03:39:15 +0200
Subject: [PATCH 1/3] debrepro: Simplify and make the vary() function more
 clear

Always use two arguments, so that it's obvious from the call sites that
the first round contains an empty variation, instead of shuffling
arguments around.
---
 scripts/debrepro.sh | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/scripts/debrepro.sh b/scripts/debrepro.sh
index 400913b..38dd14f 100755
--- a/scripts/debrepro.sh
+++ b/scripts/debrepro.sh
@@ -38,11 +38,7 @@ variation() {
 
 vary() {
   local first="$1"
-  local second="${2:-}"
-  if [ -z "$second" ]; then
-second="$first"
-first=''
-  fi
+  local second="$2"
   if [ "$which_build" = 'first' ]; then
 if [ -n "$first" ]; then
   echo "$first"
@@ -63,7 +59,7 @@ create_build_script() {
   echo 'export SOURCE_DATE_EPOCH=$(date -d "$(dpkg-parsechangelog -SDate)" +%s)'
 
   variation PATH
-  vary 'export PATH="$PATH":/i/capture/the/path'
+  vary '' 'export PATH="$PATH":/i/capture/the/path'
 
   variation USER
   vary 'export USER=user1' 'export USER=user2'
-- 
2.9.3

From 607b2b8f5c12377efe9b81e4bdf8105a3f2a6c0c Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 18 Oct 2016 03:54:21 +0200
Subject: [PATCH 2/3] debrepro: Use dpkg-buildpackage instead of ad-hoc code

Part of the reproducible machinery is handled already by
dpkg-buildpackage, so there's no need to duplicate it. We can also
pass faketime+fakeroot as a normal gain-root-command.
---
 scripts/debrepro.sh | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/scripts/debrepro.sh b/scripts/debrepro.sh
index 38dd14f..0003d22 100755
--- a/scripts/debrepro.sh
+++ b/scripts/debrepro.sh
@@ -56,8 +56,6 @@ create_build_script() {
   echo "# package"
   echo
 
-  echo 'export SOURCE_DATE_EPOCH=$(date -d "$(dpkg-parsechangelog -SDate)" +%s)'
-
   variation PATH
   vary '' 'export PATH="$PATH":/i/capture/the/path'
 
@@ -83,13 +81,9 @@ create_build_script() {
 echo 'cd ../disorderfs'
   fi
 
-  echo
-  echo 'dpkg-source --before-build .'
-  echo 'fakeroot debian/rules clean'
-
   variation date
-  vary 'fakeroot debian/rules binary' \
-'faketime "+213days +7hours +13minutes" fakeroot debian/rules binary'
+  vary 'dpkg-buildpackage -b' \
+'dpkg-buildpackage -b -r"faketime +213days+7hours+13minutes fakeroot"'
 }
 
 
-- 
2.9.3

From 9a167da06f0c2b5aba0ae8012894334aa6c88bf4 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 18 Oct 2016 04:29:43 +0200
Subject: [PATCH 3/3] debrepro: Compare .changes files and fallback to use
 debdiff

We should be checking all artifacts generated not just .deb files,
this includes .udebs and by-hand artifacts. This will also allow
adding support for source comparison.

If diffoscope is not present fallback to debdiff which is better than
a simple cmp(1).
---
 scripts/debrepro.sh | 35 +++
 1 file changed, 15 insertions(+), 20 deletions(-)

diff --git a/scripts/debrepro.sh b/scripts/debrepro.sh
index 0003d22..50685f8 100755
--- a/scripts/debrepro.sh
+++ b/scripts/debrepro.sh
@@ -3,6 +3,7 @@
 # debrepro: a reproducibility tester for Debian packages
 #
 # © 2016 Antonio Terceiro 
+# Copyright © 2016 Guillem Jover 
 #
 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -100,28 +101,22 @@ build() {
   mv "$tmpdir/build" "$tmpdir/$which_build"
 }
 
-binmatch() {
-  cmp --silent "$1" "$2"
-}
-
 compare() {
   rc=0
-  for first_deb in "$tmpdir"/first/*.deb; do
-deb="$(basename "$first_deb")"
-second_deb="$tmpdir"/second/"$deb"
-if binmatch "$first_deb" "$second_deb"; then
-  echo "✓ $deb: binaries match"
-else
-  echo ""
-  rc=1
-  if which diffoscope >/dev/null; then
-diffoscope "$first_deb" "$second_deb" || true
-  else
-echo "✗ $deb: binaries don't match"
-  fi
-fi
-  done
-  if [ "$rc" -ne 0 ]; then
+  first_changes=$(echo "$tmpdir"/first/*.changes)
+  changes="$(basename "$first_changes")"
+  second_changes="$tmpdir/second/$changes"
+
+  if which diffoscope >/dev/null; then
+diffoscope "$first_changes" "$second_changes" || rc=1
+  else
+debdiff -q -d --control --controlfiles ALL \
+  "$first_changes" "$second_changes" || rc=1
+  fi
+  if [ "$rc" -eq 0 ]; then
+echo "✓ $changes: artifacts match"
+  else
+echo "✗ 

Bug#841148: dh-python: dh_python2 fs:322: renaming module.so to .x86_64-linux-gnu.so

[Ximin Luo]

Package: dh-python
Version: 2.20160818
Severity: important

Dear Maintainer,

Whilst packaging SageMath (#841136) I ran into the following bug:

dh_python2 fs:322: renaming module.so to .x86_64-linux-gnu.so

This causes the resulting package to be unusable and I have to apply the 
following workaround:

override_dh_python2:
dh_python2
mv 
debian/sagemath/usr/lib/python2.7/dist-packages/sage/modules/.x86_64-linux-gnu.so
 \
   
debian/sagemath/usr/lib/python2.7/dist-packages/sage/modules/module.x86_64-linux-gnu.so

After that my package works.

This appears to be caused by some logic around line 465 of interpreter.py. 
Please fix this.

X

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

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

Versions of packages dh-python depends on:
pn  python3:any  

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  libdpkg-perl  1.18.10

-- no debconf information

Bug#839897: rdesktop: Confirmed on testing/stretch

[Erik]

Package: rdesktop
Followup-For: Bug #839897

segfault occurs everytime with 1.8.3-2 to any server. Downgraded to 1.8.3-1 and 
no seqfault.

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

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

Versions of packages rdesktop depends on:
ii  libasound21.1.2-1
ii  libc6 2.24-3
ii  libgssglue1   0.4-2
ii  libpcsclite1  1.8.18-1
ii  libssl1.0.0   1.0.2d-1
ii  libx11-6  2:1.6.3-1
ii  libxrandr22:1.5.0-1

rdesktop recommends no packages.

Versions of packages rdesktop suggests:
pn  pcscd  

-- no debconf information

Bug#838720: mutt: pager segfaults when window is resized

[Peter Colberg]

On Mon, Oct 17, 2016 at 09:31:40PM -0400, Peter Colberg wrote:
> Hopefully I will send you a minimal muttrc at some point; it is not
> trivial since I cannot reproduce the segfault so far and have to wait
> for the next one.

I had another segfault just now and have a slightly better idea.

I was viewing the very message I had sent you roughly a minute ago.
After a few seconds I pressed a key to scroll the message, after which
mutt segfaulted with the same message “Sorting mailbox...”.

What had presumably happened between opening the message in the pager,
and trying to scroll a few seconds later, is mbsync synchronizing the
mailbox to the IMAP server every two minutes. When mbsync copies a new
sent message to the server, it also updates the local mail folder, which
appears to have triggered the segfault in this instance.

My muttrc begins with

set folder=~/Mail
set spoolfile=~/Mail/INBOX
set mbox_type=Maildir
set header_cache=~/.cache/mutt/headers

My mbsyncrc contains

MaildirStore local
Path ~/Mail/
Inbox ~/Mail/INBOX
Flatten .

IMAPStore remote
Host imap.example.org
User *
Pass *
UseIMAPS yes

Channel remote
Master :remote:
Slave :local:
Patterns % !Spam !Trash
Create Slave
Expunge Both

Peter

Bug#841147: samba: be more verbose about masking samba-ad-dc.service

[Roland Hieber]

Package: samba
Version: 2:4.4.6+dfsg-2
Severity: minor

Dear Maintainer,

While apt upgrading my system today, I saw that samba failed in the postinstall
stage:

> Setting up samba (2:4.4.6+dfsg-2) ...
> Failed to preset unit: Unit file /etc/systemd/system/samba-ad-dc.service is 
> masked.
> /usr/bin/deb-systemd-helper: error: systemctl preset failed on 
> samba-ad-dc.service: No such file or directory

... at least it looked like an error to me, so I started investigating.  It took
me 3 times systemctl-unmasking and reinstalling samba to notice that the service
is masked by the package itself in the postinstall script when samba is not
being run as a domain controller... :-)

The action which generates this message is produced by this debhelper section
in /var/lib/dpkg/info/samba.postinst:

> # Automatically added by dh_systemd_enable
> # This will only remove masks created by d-s-h on package removal.
> deb-systemd-helper unmask samba-ad-dc.service >/dev/null || true
> 
> # was-enabled defaults to true, so new installations run enable.
> if deb-systemd-helper --quiet was-enabled samba-ad-dc.service; then
>   # Enables the unit on first installation, creates new
>   # symlinks on upgrades if the unit file has changed.
>   deb-systemd-helper enable samba-ad-dc.service >/dev/null || true
> else
>   # Update the statefile to add new symlinks (if any), which need to be
>   # cleaned up on purge. Also remove old symlinks.
>   deb-systemd-helper update-state samba-ad-dc.service >/dev/null || true
> fi
> # End automatically added section

Since this is auto-generated, it cannot easily be overwritten. However, to mark 
false negatives as such and reduce workload for admins, I suggest to be a bit
more verbose when masking the service, like this:

-- 8< --
diff --git a/debian/samba.postinst b/debian/samba.postinst
index 35b476f..cfea921 100644
--- a/debian/samba.postinst
+++ b/debian/samba.postinst
@@ -86,6 +86,9 @@ if [ "$SERVER_ROLE" != "active directory domain controller" ] 
\
&& ( echo "$DCERPC_ENDPOINT_SERVERS" | grep -qv '\(^\|, 
\)mapiproxy\(,\|$\)' ) \
 ; then
 if [ ! -e /etc/systemd/system/samba-ad-dc.service ]; then
+echo "Samba is not being run as an AD Domain Controller, masking 
samba-ad-dc-service."
+echo "Please ignore the following error about deb-systemd-helper not 
finding samba-ad-dc-service."
+mkdir -p /etc/systemd/system
 mkdir -p /etc/systemd/system
 ln -s /dev/null /etc/systemd/system/samba-ad-dc.service
 # In case this system is running systemd, we make systemd reload the 
unit files
-- >8 --

As an alternative, try to patch deb-systemd-helper so it does correctly
determine that the service was masked, i.e. not enabled, when running
`deb-systemd-helper was-enabled`.  But since I don't quite understand what that
debhelper section is supposed to do, I don't know which one is the better
alternative.

Cheers, 
 - Roland



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

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

Versions of packages samba depends on:
ii  adduser  3.115
ii  dpkg 1.18.10
ii  init-system-helpers  1.45
ii  libbsd0  0.8.3-1
ii  libc62.24-3
ii  libldb1  2:1.1.27-1
ii  libpam-modules   1.1.8-3.3
ii  libpam-runtime   1.1.8-3.3
ii  libpopt0 1.16-10
ii  libpython2.7 2.7.12-3+b1
ii  libtalloc2   2.1.8-1
ii  libtdb1  1.3.11-2
ii  libtevent0   0.9.28-1
ii  libwbclient0 2:4.4.6+dfsg-2
ii  lsb-base 9.20160629
ii  procps   2:3.3.12-2
ii  python   2.7.11-2
ii  python-dnspython 1.14.0-3
ii  python-samba 2:4.4.6+dfsg-2
pn  python2.7:any
ii  samba-common 2:4.4.6+dfsg-2
ii  samba-common-bin 2:4.4.6+dfsg-2
ii  samba-libs   2:4.4.6+dfsg-2
ii  tdb-tools1.3.11-2
ii  update-inetd 4.43

Versions of packages samba recommends:
pn  attr
ii  logrotate   3.8.7-2
ii  samba-dsdb-modules  2:4.4.6+dfsg-2
pn  samba-vfs-modules   

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
ii  ntp1:4.2.8p8+dfsg-1
pn  smbldap-tools  
pn  ufw
pn  winbind

-- debconf information:
  samba-common/title:
  samba/run_mode: daemons

Bug#839982: axi-cache: xapian.FeatureUnavailableError: Flint backend no longer supported

[Paul Wise]

Control: severity -1 important

On Fri, 2016-10-07 at 11:15 +0800, Paul Wise wrote:

> axi-cache search no longer works because of the recent python-xapian upgrade:

This is easily worked around by just running an update as root:

$ sudo update-apt-xapian-index
Reading ...
...
Rebuilding Xapian index: done.
$ axi-cache search apt xapian index
6 results found.
Results 1-6:
100% apt-xapian-index - maintenance and search tools for a Xapian index of 
Debian packages
90% libept1.5.0 - High-level library for managing Debian package information
90% libept-dev - High-level library for managing Debian package information
81% debtags - Debian Package Tags support tools
72% muon - package manager for KDE
60% apprecommender - Application recommender for Debian (and derivatives)
Did you mean: api xapian index ?
More terms: debtags packages debian popcon information sources queried
More tags: suite::debian use::searching works-with::software:package 
implemented-in::c++ devel::debian admin::package-management 
interface::commandline

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#820036: No bug mentioning a Debian KEK and booting use it.

[Peter Dolding]

Yes it one thing to get shim signed by Microsoft.  Do remember
Microsoft is free to push out updates to the  The Forbidden Signatures
Database(dbx).

Sign a new shim in case of current one being black listed for some
reason could take weeks/months from Microsoft.

The process to replace PK(platform key) and replace the KEK can be
done faster than getting a new shim.


Its also a safe guard against Microsoft changing the rules how shims
are constructions.  Please be aware when Microsoft signing shims they
do not use the KEK that is used to sign the windows boot loader.

So windows bootloaders are signed with Microsoft Windows Production
PCA 2011 and debian shim will be signed with Microsoft Corporation
UEFI CA 2011.

https://technet.microsoft.com/en-au/library/dn747883.aspx
Now there is a line to OEM that should worry the heck out of us.

---On non-Windows RT PCs the OEM should consider including the
Microsoft Corporation UEFI CA 2011---

Key words "should consider" so making the "Microsoft Corporation UEFI
CA" key and everything signed by optional if it works or not.
Microsoft does not mandate OEM install "Microsoft Corporation UEFI CA"
only the "Microsoft Windows Production PCA" the one the debian shim
will not be signed with .So getting the shim signed by Microsoft
does not promise it works on every motherboard.

Manually installing Microsoft Corporation UEFI CA if OEM did not
include is replace PK(platform key) and upload new KEK set.   At this
point might has well have the set of processes to install own KEK and
will require to provide users with the complete instructions to
replace the PK anyhow.

Also there appears to be no bug saying to put a system in place to
check that the shim had not been added revocation list as Microsoft
publishes it here http://www.uefi.org/revocationlistfile to allow
early response in case for some reason shim gets blacklist.

Secureboot is a mess.   A single plan is not going to work.2 plans
are required.
1) A signed shim by Microsoft to reduce the number of people who have
to replace PK at first.
2) A plan to replace PK and use own KEK set containing the KEKs debian needs.

The interesting point from Microsoft OEM documentation is the
PK(platform key) rules.

Yes this is again
https://technet.microsoft.com/en-au/library/dn747883.aspx
1.3.3.3 PK generation
Two entries of very big interest.
--One per product line. If a key is compromised a whole product line
would be vulnerable--
And
--One per OEM. While this may be the simplest to set up, if the key is
compromised, every PC you manufacture would be vulnerable. To speed up
operation on the factory floor, the PK and potentially other keys
could be pre-generated and stored in a safe location. --

Debian is a product line or a OEM right so Debian install images can
ship with it own premade PK and KEK set/sets so user if required can
delete the PK and attempt an alternate  functional set particularly if
the motherboard lacks the KEK the shim needs .Of course this does
not stop users making their own PK and KEK set latter and it not
against the rules to-do this.

Peter Dolding

Bug#514857: zsh -c 'set -e; ! true; echo OK' fails

[Daniel Shahaf]

Control: tags -1 -wontfix +fixed-upstream

Fixed upstream as of commit ffa6c76253b9833379893e87e8504eb03b4e954e, to
be included in 5.3.

> On 2009-03-25 16:31:41 +, Peter Stephenson wrote:
> > Clint Adams wrote:
> > > A trio regarding set -e:
> > 
> > I am not going anywhere near this until the clarification in the
> > standard gets through.
> 
> New on the subject (a fix?):
> 
>   http://www.zsh.org/mla/workers/2016/msg02023.html
> 
> -- 
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> 

Bug#841146: diffoscope: Failure of test_superblock

[Leo Famulari]

Source: diffoscope

Dear Maintainer,

While building diffoscope 61 on GNU Guix's "core-updates" branch
(roughly analogous to Debian's testing branch), the test test_superblock
fails like this:

=== FAILURES ===
___ test_superblock 

differences = []

@skip_unless_tool_is_older_than('unsquashfs', unsquashfs_version, '4.3')
def test_superblock(differences):   
expected_diff = open(data('squashfs_superblock_expected_diff')).read()
>   assert differences[0].unified_diff == expected_diff
E   IndexError: list index out of range

tests/comparators/test_squashfs.py:59: IndexError
== 1 failed, 173 passed, 73 skipped in 12.80 seconds ===

We are using Python 3.5.2 and pytest 2.7.3. Please let me know what
other information I can provide.

What do you think? Does this test failure indicate a serious problem or
is it safe to skip the test in our packaging?

Bug#838720: mutt: pager segfaults when window is resized

[Peter Colberg]

Control: found -1 1.7.1-2

Hi Antonio,

On Fri, Sep 30, 2016 at 07:43:08AM +, Antonio Radici wrote:
> unfortunately I'm still unable to reproduce it, I believe it's due to the
> configuration. The problem itself might be due to the header cache or some 
> other
> reason, do you mind sending me the output of bt full on the corefile?

Please see the attached full stacktrace for the latest segfault with
the above version, which occurred right after sending a mail and mutt
outputting “Sorting mailbox...”, the same as with earlier segfaults.

> Additionally, if you could devise a minimum set of ocnfiguration (i.e.: a
> minimal .muttrc) that I can use to reproduce this bug, it will be great and it
> will ensure that I will be able to fix it quicker :)

Hopefully I will send you a minimal muttrc at some point; it is not
trivial since I cannot reproduce the segfault so far and have to wait
for the next one. Since you mentioned the header cache, I deleted the
cache file to make sure there was no accidental corruption, but then
the attached segfault occurred regardless.

Peter
#0  mutt_pager (banner=banner@entry=0x7ffe4882c6c0 "---Attachment: 
/tmp/mutt-alcyone-1000-3900-12427186522611139815: text/plain", 
fname=fname@entry=0x7ffe4882c4c0 
"/tmp/mutt-alcyone-1000-3900-17151246448925655235", flags=, 
flags@entry=256, extra=extra@entry=0x7ffe4882c390) at ../../pager.c:2034
searchbuf = '\000' 
buffer = "?:Help", '\000' , "\350\003", '\000' 
...
helpstr = "i:Exit  -:PrevPg  :NextPg ?:Help", '\000' 
tmphelp = "i:Exit  -:PrevPg  :NextPg", '\000' 
maxLine = 70
lastLine = 24
lineInfo = 0x55a6f6a63460
QuoteList = 0x0
i = 
j = 
ch = 150
rc = -1
hideQuoted = 
q_level = 0
force_redraw = 0
lines = 
curline = 
topline = 0
oldtopline = 
err = 
first = 
r = 
wrapped = 
searchctx = 
redraw = 0
fp = 0x55a6f6a63230
last_pos = 917
last_offset = 
old_smart_wrap = 
old_markers = 
sb = {st_dev = 36, st_ino = 116705, st_nlink = 1, st_mode = 33152, 
st_uid = 1000, st_gid = 1000, __pad0 = 0, st_rdev = 0, st_size = 917, 
st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1476752587, tv_nsec = 
907517935}, 
  st_mtim = {tv_sec = 1476752587, tv_nsec = 931517950}, st_ctim = 
{tv_sec = 1476752587, tv_nsec = 931517950}, __glibc_reserved = {0, 0, 0}}
SearchRE = {buffer = 0x736972702f736461 , allocated = 8241996531388803444, used = 
7364851246852158218, syntax = 3832899941293176676, 
  fastmap = 0x3238666430656530 , translate = 0x6165346535326335 , re_nsub = 3760850262121526374, 
  can_be_null = 1, regs_allocated = 1, fastmap_accurate = 0, no_sub = 
1, not_bol = 1, not_eol = 0, newline_anchor = 0}
SearchCompiled = 0
SearchFlag = 
SearchBack = 
has_types = 
index_status_window = 0x55a6f69eabb0
index_window = 0x55a6f66e46c0
pager_status_window = 0x55a6f66f56f0
pager_window = 0x55a6f69c1090
index = 0x0
indexlen = 
indicator = 
old_PagerIndexLines = 
index_hint = 0
oldcount = 
check = 3
followup_to = 
#1  0x55a6f574e889 in mutt_do_pager (banner=0x7ffe4882c6c0 "---Attachment: 
/tmp/mutt-alcyone-1000-3900-12427186522611139815: text/plain", 
tempfile=tempfile@entry=0x7ffe4882c4c0 
"/tmp/mutt-alcyone-1000-3900-17151246448925655235", 
do_color=do_color@entry=256, info=info@entry=0x7ffe4882c390) at 
../../curs_lib.c:784
rc = 
#2  0x55a6f573911b in mutt_view_attachment (fp=fp@entry=0x0, 
a=0x55a6f7dd2a40, flag=, flag@entry=1, hdr=hdr@entry=0x0, 
idx=idx@entry=0x55a6f66da5e0, idxlen=) at ../../attach.c:579
info = {ctx = 0x55a6f64f40b0, hdr = 0x0, bdy = 0x55a6f7dd2a40, fp = 
0x0, idx = 0x55a6f66da5e0, idxlen = 1}
tempfile = '\000' 
pagerfile = "/tmp/mutt-alcyone-1000-3900-17151246448925655235", '\000' 

is_message = 0
use_mailcap = 
use_pipe = 
use_pager = 
type = 
"text/plain\000\366\246U\000\000\000\062\246\366\246U\000\000X\300\064\226\023\177\000\000#\000\000\000\000\000\000\000\276$3\226\023\177\000\000\020\000\000\000\000\000\000\000(ǂH\376\177\000\000\000\000\000\000\000\000\000\000g",
 '\000' , 
"P0\246\366\246U\000\000\000\033Ue\267;\b\303\020\062\246\366\246U\000\000X\300\064\226\023\177\000\000w\000\000\000\000\000\000\000\016'3\226\023\177\000\000\316\024\022\226\023\177\000\000g",
 '\000' , " ", '\000' ...
command = "0ȂH\376\177\000\000\377\037\000\000g", '\000' , 
"\033Ue\267;\b\303`\366\246U\000\000p)\335\367\246U\000\000\060ȂH\376\177\000\000\001\000\000\000\000\000\000\000(ȂH\376\177\000\000\260\357\202H\376\177\000\000\001\000\000\000\000\000\000\000\223\204t\365\246U",
 '\000' , "\070\064\061\060\063\0...@bugs.debian.org", '\000' 
...
   

Bug#841145: dh-golang: Rewrite of dh_golang for a more robust and idiomatic perl

[Guillem Jover]

Package: dh-golang
Version: 1.19
Severity: wishlist
Tags: patch

Hi!

I was taking a look at dh_golang the other day, and thought the code
could do with some rewrite to make it more idiomatic, more robust,
generate command output on DH_VERBOSE, and avoid the need for so many
temporary files (which TBH was what first caught my eye). So I rewrote
it. :)

I've tested building acmetool, before and after the changes and it
produces bit-for-bit idential .deb packages.

Thanks,
Guillem
From ee2c88f79ee2946d69eb9205fdd925605bc6839b Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 18 Oct 2016 03:06:08 +0200
Subject: [PATCH] Rewrite dh_golang to be more idiomatic perl

The new code does not make use of temporary files anymore, is more
resilient against dpkg output, and should be a bit more idiomatic.
---
 script/dh_golang | 73 +---
 1 file changed, 43 insertions(+), 30 deletions(-)

diff --git a/script/dh_golang b/script/dh_golang
index 4c4e09d..097550b 100755
--- a/script/dh_golang
+++ b/script/dh_golang
@@ -10,8 +10,6 @@ use strict;
 use Cwd qw(realpath);
 use Debian::Debhelper::Dh_Lib; # not in core
 use Debian::Debhelper::Dh_Buildsystems; # not in core
-use File::Temp qw(tempdir);
-use File::Path qw(rmtree);
 
 =head1 SYNOPSIS
 
@@ -30,6 +28,39 @@ The best way to invoke B is by using B.
 
 =cut
 
+sub uniq {
+my %list = map { $_ => 1 } @_;
+
+return sort keys %list;
+}
+
+sub exec_single {
+my ($cmd, @args) = @_;
+
+verbose_print(escape_shell(@_));
+
+my @output = qx($cmd @args);
+error_exitcode($cmd) if $? != 0;
+chomp(@output);
+
+return @output;
+}
+
+# Amount of chunking we are going to use for dpkg commands, which should speed
+# up the execution by avoiding too many database loads.
+use constant CHUNKSIZE => 200;
+
+sub exec_chunked {
+my ($cmd, @list) = @_;
+
+my @result;
+for (my $i = 0; $i < @list; $i += CHUNKSIZE) {
+push @result, exec_single($cmd, @list[$i .. $i + CHUNKSIZE - 1]);
+}
+
+return @result;
+}
+
 
 # Generate misc:Built-Using substvar.
 
@@ -43,44 +74,26 @@ my @targets = $bs->get_targets();
 
 my $tmpl = '{{ range .Deps }}{{.}}
 {{ end }}';
-
-my $tmpdir = tempdir("dh_golang_XXX", TMPDIR => 1);
-
-system("go list -f \"$tmpl\" @targets > $tmpdir/godeps") == 0
-or die "go list of targets failed with code $?, $!";
+my @godeps = exec_single(qq{go list -f '$tmpl'}, @targets);
 
 my $gofiletmpl = '\
 {{ .Dir }}/{{ index (or .GoFiles .CgoFiles .TestGoFiles .XTestGoFiles .IgnoredGoFiles) 0 }}';
+my @gofiles = exec_chunked(qq{go list -f '$gofiletmpl'}, uniq(@godeps));
 
-system("sort -u $tmpdir/godeps | xargs go list -f '$gofiletmpl' > $tmpdir/gofiles") == 0
-or die "go list of dependencies failed with code $?, $!";
-
-open(my $inp, "<", "$tmpdir/gofiles");
-open(my $outp, ">", "$tmpdir/realgofiles");
-while (<$inp>) {
-chomp;
-my $realpath = realpath($_);
+my @realpath;
+foreach my $pathname (@gofiles) {
+my $realpath = realpath($pathname);
 # gofiles will include packages being built, so exclude those.
 if ($realpath !~ /^\Q$bs->{cwd}\E/) {
-printf $outp "%s\n", $realpath;
+push @realpath, $realpath;
 }
 }
-close($inp);
-close($outp);
-
-system("cat $tmpdir/realgofiles | xargs -r dpkg-query --search > $tmpdir/pkgs") == 0
-or die "dpkg-query --search failed with code $?, $!";
-
-system("cut -d: -f1 $tmpdir/pkgs | sort -u | xargs -r dpkg-query -f='\${source:Package} (= \${source:Version})\n' -W > $tmpdir/srcpkgs");
-if ($? != 0) {
-die "dpkg-query -W failed with code $?, $!";
-}
-
-my $built_using = `cat $tmpdir/srcpkgs | sort -u`;
 
-$built_using =~ s/\n/, /g;
+my @searchoutput = exec_chunked('dpkg-query --search', @realpath);
+my @gopkgs = split /, */, join ', ', map { s/: .+$//r } @searchoutput;
 
-rmtree($tmpdir);
+my @srcdeps = exec_chunked(q{dpkg-query -f='${source:Package} (= ${source:Version})\n' -W}, uniq(@gopkgs));
+my $built_using = join ', ', uniq(@srcdeps);
 
 # If there is an easier way to have a universal misc:Built-Using on all binary
 # packages, I am happy to merge your patch :).
-- 
2.9.3

Bug#841101: dgit push of --quilt=gbp package fails when package not yet uploaded with dgit

[Ian Jackson]

Sean Whitton writes ("Bug#841101: dgit push of --quilt=gbp package fails when 
package not yet uploaded with dgit"):
> I'm trying to push version 2.3.0-1 of my package.  No previous version
> has been uploaded with dgit.  dgit complains that it can't find
> the git tags archive/debian/2.2.1-1 or debian/2.2.1-1, but it shouldn't
> expect to find them, since there was no previous dgit push.

Sorry about this.  It looks like my tests didn't cover this case.
I have just uploaded 2.3 which ought to fix this.

FTR here is the diff to dgit, which is all you should need to get
unblocked.

Regards,
Ian.



dgit-2.2-2.3-dgit.diff
Description: Binary data

Bug#841032: RFS: golang-github-hlandau-dexlogconfig/0.0~git20160722.0.055e2e3-1 [ITP]

[Peter Colberg]

On Sun, Oct 16, 2016 at 11:55:48PM -0400, Peter Colberg wrote:
> Package: sponsorship-requests
> Severity: wishlist
> Control: block 839981 by -1
> 
> Dear mentors,
> 
> I am looking for a sponsor for the package 
> "golang-github-hlandau-dexlogconfig":
> 
>   git clone 
> https://anonscm.debian.org/git/pkg-go/packages/golang-github-hlandau-dexlogconfig.git
>   cd golang-github-hlandau-dexlogconfig && pristine-tar checkout 
> ../golang-github-hlandau-dexlogconfig_0.0~git20160722.0.055e2e3.orig.tar.gz
> 
> This package is a prerequisite for uploading a new version of
> acmetool, a client for the Let’s Encrypt certificate authority.

I changed Vcs-Browser from /cgit/ → /git/ (to make Mattia happy).

# git show-ref --heads
7391d2b223e1f3900f70180ccc1320baac1e6509 refs/heads/master
ff9363988d9a04af3c305da92601cefcfa34b995 refs/heads/pristine-tar
378055fd7ed02150ee0df825c25e4eaf407c9143 refs/heads/upstream

Peter

Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup [and 1 more messages]

[Ian Jackson]

Here's the log file.



distropatches-reject.log
Description: shell transcript (with set -x)


-- 
Ian Jackson    These opinions are my own.

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

Bug#840992: RFS: golang-github-hlandau-goutils/0.0~git20160722.0.0cdb66a-1

[Peter Colberg]

On Sun, Oct 16, 2016 at 01:22:26PM -0400, Peter Colberg wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for the package "golang-github-hlandau-goutils":
> 
>   git clone 
> https://anonscm.debian.org/git/pkg-go/packages/golang-github-hlandau-goutils.git
>   cd golang-github-hlandau-goutils && pristine-tar checkout 
> ../golang-github-hlandau-goutils_0.0~git20160722.0.0cdb66a.orig.tar.gz
> 
> This package is a prerequisite for uploading a new version of
> acmetool, a client for the Let’s Encrypt certificate authority.

I changed Vcs-Browser from /cgit/ → /git/ (to make Mattia happy).

# git show-ref --heads
d19e97dc5a22e8ef8108d9761e42bf35f6362beb refs/heads/master
9c73792e599f1b6afb485e19727e1f7ccf348f47 refs/heads/pristine-tar
616fb54cd951b282f7b6b383a7c5f9eaabb165bf refs/heads/upstream

Peter

Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup [and 1 more messages]

[Ian Jackson]

Ian Jackson writes ("Suspected race in gpg1 to gpg2 conversion or agent 
startup"):
> I have now, for the 2nd time, seen an unexplained failure while
> running the dgit test suite, looking like this:
> 
> + gpg --detach-sign --armor -u 39B13D8A .git/dgit/tag.tmp
> gpg: WARNING: unsafe permissions on homedir 
> '/home/ian/things/Dgit/dgit/tests/tmp/distropatches-reject/gnupg'
> gpg: starting migration from earlier GnuPG versions
> gpg: can't connect to the agent: IPC connect call failed
> gpg: error: GnuPG agent unusable. Please check that a GnuPG agent can be 
> started.

Perhaps this is due to me having updated my system and restarted my
session, with the result that now I seem to have a gpg-agent running.
At least, I have GPG_AGENT_INFO in my environment and I don't think I
did before.

I ran the whole test suite again and this time two tests failed the
same way.  I have added `unset GPG_AGENT_INFO' to the top of the test
suite library script just in case.  (Surely setting GNUPGHOME should
be enough to stop the test suite from using my actual gpg agent ?
With gnupg1, setting GNUPGHOME was sufficient to isolate a gnupg
instance.)  Sadly that seems not to have helped.

Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#841144: base: kernel BUG at linux-4.7.5/fs/ocfs2/alloc.c:1514!

[root]

Package: base
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

Two-host virtualization cluster with DRBD mirrored volume and OCFS2 filesystem.

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

Simply writing data to the volume exposed a kernel bug in OCFS2.

   * What was the outcome of this action?

Oct 17 09:57:38 vhost002 kernel: [ cut here ]
Oct 17 09:57:38 vhost002 kernel: kernel BUG at 
/build/linux-rAvIHq/linux-4.7.5/fs/ocfs2/alloc.c:1514!
Oct 17 09:57:38 vhost002 kernel: invalid opcode:  [#1] SMP
Oct 17 09:57:38 vhost002 kernel: Modules linked in: vhost_net vhost macvtap 
macvlan tun ocfs2 quota_tree cfg80211 rfkill iptable_filter ip_tables x_tables 
nfsd auth_rpcgss nfs_acl nfs lockd grace fscache ocfs2_dlmfs ocfs2_stack_o2cb 
sunrpc ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bridge stp llc 
bonding ipmi_watchdog intel_rapl sb_edac edac_core x86_pkg_temp_thermal 
intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul 
ghash_clmulni_intel hmac drbg ansi_cprng igb iTCO_wdt ast iTCO_vendor_support 
mxm_wmi ttm evdev drm_kms_helper aesni_intel drm aes_x86_64 lrw xhci_pci 
gf128mul glue_helper xhci_hcd ablk_helper cryptd ehci_pci dca ehci_hcd e1000e 
i2c_algo_bit pcspkr usbcore ptp mei_me lpc_ich i2c_i801 sg mei shpchp mfd_core 
usb_common pps_core fjes wmi ipmi_si ipmi_poweroff ipmi_devintf
Oct 17 09:57:38 vhost002 kernel:  ipmi_msghandler tpm_tis tpm acpi_power_meter 
acpi_pad button fuse drbd lru_cache libcrc32c crc32c_generic autofs4 ext4 crc16 
jbd2 mbcache dm_mod md_mod sd_mod ahci libahci libata crc32c_intel scsi_mod
Oct 17 09:57:38 vhost002 kernel: CPU: 7 PID: 17663 Comm: qemu-system-x86 Not 
tainted 4.7.0-0.bpo.1-amd64 #1 Debian 4.7.5-1~bpo8+2
Oct 17 09:57:38 vhost002 kernel: Hardware name: To Be Filled By O.E.M. To Be 
Filled By O.E.M./EPC612D4I, BIOS P2.10 03/31/2016
Oct 17 09:57:38 vhost002 kernel: task: 8802547d9040 ti: 88025764 
task.ti: 88025764
Oct 17 09:57:38 vhost002 kernel: RIP: 0010:[]  
[] ocfs2_grow_tree+0x6f1/0x770 [ocfs2]
Oct 17 09:57:38 vhost002 kernel: RSP: 0018:880257643618  EFLAGS: 00010246
Oct 17 09:57:38 vhost002 kernel: RAX:  RBX: 000d 
RCX: 880257643790
Oct 17 09:57:38 vhost002 kernel: RDX: 8802576436bc RSI: 880257643968 
RDI: 8801803473f0
Oct 17 09:57:38 vhost002 kernel: RBP: 880257643678 R08:  
R09: 00390ce8
Oct 17 09:57:38 vhost002 kernel: R10: 02a15008 R11: 880257d9a030 
R12: 0001
Oct 17 09:57:38 vhost002 kernel: R13: 880257643828 R14: 8802622020c0 
R15: 0002
Oct 17 09:57:38 vhost002 kernel: FS:  7f718f75d700() 
GS:88103f3c() knlGS:
Oct 17 09:57:38 vhost002 kernel: CS:  0010 DS:  ES:  CR0: 
80050033
Oct 17 09:57:38 vhost002 kernel: CR2: 7f7ba6591e4c CR3: 0002825db000 
CR4: 001426e0
Oct 17 09:57:38 vhost002 kernel: Stack:
Oct 17 09:57:38 vhost002 kernel:  880257643728 880257643728 
c0a612a5 88025da1a880
Oct 17 09:57:38 vhost002 kernel:  8801803fd340 b2c2fd37 
8a1a0f55 000d
Oct 17 09:57:38 vhost002 kernel:  0001 880257643828 
880257643968 88025da1a880
Oct 17 09:57:38 vhost002 kernel: Call Trace:
Oct 17 09:57:38 vhost002 kernel:  [] ? 
ocfs2_set_buffer_uptodate+0x35/0x4a0 [ocfs2]
Oct 17 09:57:38 vhost002 kernel:  [] ? 
__find_get_block+0xa7/0x110
Oct 17 09:57:38 vhost002 kernel:  [] ? 
ocfs2_split_and_insert+0x307/0x490 [ocfs2]
Oct 17 09:57:38 vhost002 kernel:  [] ? 
ocfs2_split_extent+0x3ed/0x560 [ocfs2]
Oct 17 09:57:38 vhost002 kernel:  [] ? 
ocfs2_change_extent_flag+0x273/0x450 [ocfs2]
Oct 17 09:57:38 vhost002 kernel:  [] ? 
ocfs2_mark_extent_written+0x110/0x1d0 [ocfs2]
Oct 17 09:57:38 vhost002 kernel:  [] ? 
ocfs2_dio_end_io_write+0x44d/0x600 [ocfs2]
Oct 17 09:57:38 vhost002 kernel:  [] ? 
ocfs2_allocate_extend_trans+0x180/0x180 [ocfs2]
Oct 17 09:57:38 vhost002 kernel:  [] ? 
ocfs2_dio_end_io+0x3b/0x60 [ocfs2]
Oct 17 09:57:38 vhost002 kernel:  [] ? dio_complete+0x64/0x160
Oct 17 09:57:38 vhost002 kernel:  [] ? 
do_blockdev_direct_IO+0x1f5a/0x2350
Oct 17 09:57:38 vhost002 kernel:  [] ? 
ocfs2_write_end_nolock+0x560/0x560 [ocfs2]
Oct 17 09:57:38 vhost002 kernel:  [] ? 
ocfs2_direct_IO+0x84/0x90 [ocfs2]
Oct 17 09:57:38 vhost002 kernel:  [] ? 
generic_file_direct_write+0xb3/0x180
Oct 17 09:57:38 vhost002 kernel:  [] ? 
__generic_file_write_iter+0xb6/0x1e0
Oct 17 09:57:38 vhost002 kernel:  [] ? 
ocfs2_file_write_iter+0x44d/0xae0 [ocfs2]
Oct 17 09:57:38 vhost002 kernel:  [] ? hrtimer_init+0xf0/0xf0
Oct 17 09:57:38 vhost002 kernel:  [] ? 
do_iter_readv_writev+0xb0/0x130
Oct 17 09:57:38 vhost002 kernel:  [] ? 
do_readv_writev+0x1a2/0x240
Oct 17 09:57:38 vhost002 kernel:  [] ? 
ocfs2_check_range_for_refcount+0x130/0x130 [ocfs2]
Oct 17 

Bug#841031: RFS: golang-github-hlandau-buildinfo/0.0~git20160722.0.b25d4b0-1 [ITP]

[Peter Colberg]

On Sun, Oct 16, 2016 at 11:55:08PM -0400, Peter Colberg wrote:
> Package: sponsorship-requests
> Severity: wishlist
> Control: block 839980 by -1
> 
> Dear mentors,
> 
> I am looking for a sponsor for the package "golang-github-hlandau-buildinfo":
> 
>   git clone 
> https://anonscm.debian.org/git/pkg-go/packages/golang-github-hlandau-buildinfo.git
>   cd golang-github-hlandau-buildinfo && pristine-tar checkout 
> ../golang-github-hlandau-buildinfo_0.0~git20160722.0.b25d4b0.orig.tar.gz
> 
> This package is a prerequisite for uploading a new version of
> acmetool, a client for the Let’s Encrypt certificate authority.

I changed Vcs-Browser from /cgit/ → /git/ (to make Mattia happy).

# git show-ref --heads
453f6993b7ddb0322ddf7213c57a8d7a019ddd0c refs/heads/master
f8cc00475abd68814db817c30cc7a65c3530b55a refs/heads/pristine-tar
d25114febd16c3709c4867007543e22dd622f0c5 refs/heads/upstream

Peter

Bug#833491: Pending fixes for bugs in the golang-github-hlandau-goutils package

[pkg-go-maintainers]

tag 833491 + pending
thanks

Some bugs in the golang-github-hlandau-goutils package are closed in
revision a04c6f3127f385b0521beb60b8581ceeecd9faaf in branch 'master'
by Peter Colberg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-hlandau-goutils.git/commit/?id=a04c6f3

Commit message:

Initial release

Closes: #833491

Bug#839980: Pending fixes for bugs in the golang-github-hlandau-buildinfo package

[pkg-go-maintainers]

tag 839980 + pending
thanks

Some bugs in the golang-github-hlandau-buildinfo package are closed
in revision 8ad38b0ed628e9a0976441469231e36044f1a085 in branch
'master' by Peter Colberg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-hlandau-buildinfo.git/commit/?id=8ad38b0

Commit message:

Initial release

Closes: #839980

Bug#839981: Pending fixes for bugs in the golang-github-hlandau-dexlogconfig package

[pkg-go-maintainers]

tag 839981 + pending
thanks

Some bugs in the golang-github-hlandau-dexlogconfig package are
closed in revision 7d4fc62927e187a3fd53a15850ed9acf2f796902 in branch
'master' by Peter Colberg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-hlandau-dexlogconfig.git/commit/?id=7d4fc62

Commit message:

Initial release

Closes: #839981

Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup

[Ian Jackson]

Package: gnupg
Version: 2.1.15-4

I have now, for the 2nd time, seen an unexplained failure while
running the dgit test suite, looking like this:

+ gpg --detach-sign --armor -u 39B13D8A .git/dgit/tag.tmp
gpg: WARNING: unsafe permissions on homedir 
'/home/ian/things/Dgit/dgit/tests/tmp/distropatches-reject/gnupg'
gpg: starting migration from earlier GnuPG versions
gpg: can't connect to the agent: IPC connect call failed
gpg: error: GnuPG agent unusable. Please check that a GnuPG agent can be 
started.
gpg: migration aborted
gpg: skipped "39B13D8A": No secret key
gpg: signing failed: No secret key
dgit: failed command: gpg --detach-sign --armor -u 39B13D8A .git/dgit/tag.tmp

This is with a private setting:
 GNUPGHOME=/home/ian/things/Dgit/dgit/tests/tmp/distropatches-reject/gnupg

I have attached a complete shell transcript from the particular dgit
test suite test.  (FTR the test failed with roughly but not exactly
dgit 2.2).  I will keep the tmp directory.  There doesn't seem, now,
to be an agent running.

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#841142: python 3.5 magic number

[曹忠]

Package: python3
  Version: 3.5.2

On debian 9 and python 3.5.2:
>>> imp.get_magic()
b'\x17\r\r\n'

On windows and python 3.5.2
>>> imp.get_magic()
b'\x16\r\r\n'

the same python version, magic number is the same, why not?

Bug#841141: /usr/bin/dh_sphinxdoc: dh_sphinxdoc doesn't recognise search pages with nonstandard paths

[Ximin Luo]

Package: sphinx-common
Version: 1.4.6-1
Severity: important
File: /usr/bin/dh_sphinxdoc
Tags: patch

Dear Maintainer,

SageMath generates docs with search indexes like this:

jQuery(function() { Search.loadIndex("../searchindex.js"); });

This is not recognised by dh_sphinxdoc. If you change

192: my $loads_searchindex = $search =~ m/\QjQuery(function() { 
Search.loadIndex("searchindex.js"); });\E/;

to 

192: my $loads_searchindex = $search =~ m/\QjQuery(function() { 
Search.loadIndex("\E([^\/]*\/)?\Qsearchindex.js"); });\E/;

it will fix the problem.

Thanks,
X

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

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

Versions of packages sphinx-common depends on:
ii  libjs-sphinxdoc  1.4.6-1

Versions of packages sphinx-common recommends:
ii  python-sphinx   1.4.6-1
ii  python3-sphinx  1.4.6-1

sphinx-common suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/dh_sphinxdoc (from sphinx-common package)

Bug#841140: dm-cache: cache corrupt after hibernate

[Ruben]

Package: lvm2
Version: 2.02.164-1
Severity: important

I use dm-cache to speed up a laptop that has a slow disk and a small ssd.
After shutting the laptop down using hibernate, it will no longer be
able to boot and will complain about a corrupted cache (manual repair
required).

I never succeeded in fixing the cache, and always remove it (lvconvert
--uncache) using a rescue memory stick and add it again afterwards.

I always assumed that it was just a problem with hibernate on this
laptop, but that is not the case: when the dm-cache is disabled,
hibernate is working just fine on this laptop. (I tested repeatedly to
be sure of this.)

The dm-cache is set up using the default policy (writethrough). The
problem does not seem specific to the latest kernel version, I noticed
the problem with the debian kernels 4.5.0, 4.6.0 and 4.7.0.

Laptop is suspended as follows:
echo disk > /sys/power/state


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

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

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.133-1
ii  dmsetup   2:1.02.133-1
ii  init-system-helpers   1.45
ii  libblkid1 2.28.2-1
ii  libc6 2.24-3
ii  libdevmapper-event1.02.1  2:1.02.133-1
ii  libdevmapper1.02.12:1.02.133-1
ii  liblvm2app2.2 2.02.164-1
ii  libreadline5  5.2+dfsg-3+b1
ii  libudev1  231-9
ii  lsb-base  9.20160629

lvm2 recommends no packages.

Versions of packages lvm2 suggests:
ii  thin-provisioning-tools  0.6.1-4

-- no debconf information

Bug#841139: ITP: gajim-triggers -- configure Gajim's behaviour for each contact

[W. Martin Borgert]

Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert" 

* Package name: gajim-triggers
  Version : 0.1
  Upstream Author : Yann Leboulanger 
* URL : http://trac-plugins.gajim.org/wiki/TriggersPlugin
* License : GPL3
  Programming Lang: Python
  Description : configure Gajim's behaviour for each contact

With this plugin you will be able to configure precisely Gajim's
behaviour when you receive a message or a presence from a given
contact.

Bug#841138: gjs: samll typo in package description

[Roland Hieber]

Package: gjs
Version: 1.46.0-1
Severity: minor
Tags: patch

Dear Maintainer,

there is a small typo in the package description ("introsepection"). While we're
at it, also correct "JavaScript" to the official spelling.

This patch is so trivial, I release it as CC-0.

Cheers,

 - Roland

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

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

Versions of packages gjs depends on:
ii  libc6 2.24-3
ii  libgcc1   1:6.1.1-11
ii  libgjs0e [libgjs0-libmozjs-24-0]  1.46.0-1
ii  libglib2.0-0  2.50.0-1
ii  libstdc++66.1.1-11

gjs recommends no packages.

gjs suggests no packages.

-- no debconf information
Index: debian/control.in
===
--- debian/control.in	(revision 51482)
+++ debian/control.in	(working copy)
@@ -30,8 +30,8 @@
  ${misc:Depends}
 Description: Mozilla-based javascript bindings for the GNOME platform
  Makes it possible for applications to use all of GNOME's platform
- libraries using the Javascript language. It's mainly based on the
- Mozilla javascript engine and the GObject introsepection framework.
+ libraries using the JavaScript language. It's mainly based on the
+ Mozilla JavaScript engine and the GObject introspection framework.
  .
  This package contains the interactive console application.
 
@@ -44,8 +44,8 @@
  at-spi2-core
 Description: Mozilla-based javascript bindings for the GNOME platform
  Makes it possible for applications to use all of GNOME's platform
- libraries using the Javascript language. It's mainly based on the
- Mozilla javascript engine and the GObject introsepection framework.
+ libraries using the JavaScript language. It's mainly based on the
+ Mozilla JavaScript engine and the GObject introspection framework.
  .
  This package contains test programs, designed to be run as part of a
  regression testsuite.
@@ -60,8 +60,8 @@
 Provides: ${gjs:Provides}
 Description: Mozilla-based javascript bindings for the GNOME platform
  Makes it possible for applications to use all of GNOME's platform
- libraries using the Javascript language. It's mainly based on the
- Mozilla javascript engine and the GObject introspection framework.
+ libraries using the JavaScript language. It's mainly based on the
+ Mozilla JavaScript engine and the GObject introspection framework.
  .
  This is the shared library applications link to.
 
@@ -75,8 +75,8 @@
  libmozjs-24-dev
 Description: Mozilla-based javascript bindings for the GNOME platform
  Makes it possible for applications to use all of GNOME's platform
- libraries using the Javascript language. It's mainly based on the
- Mozilla javascript engine and the GObject introspection framework.
+ libraries using the JavaScript language. It's mainly based on the
+ Mozilla JavaScript engine and the GObject introspection framework.
  .
  This package contains the development files applications need to
  build against.

Bug#809439: tentative fix

[Paolo Greppi]

It appears the package was generating manpages "on the fly" converting
HTML to groff with a manually-crafted script.

This is not necessary, as upstream provides manpages in groff format
built with xmlto (cd doc; make manpages).

I have attempted a fix for that with this upload to mentors:
https://mentors.debian.net/package/giflib

As a side-note, this bug was opened by an individual who casually
discovered it, but in my opinion the issue should have been clearly
highlighted by the automated QC tools.

It is true that it was possible to guess that something was wrong with
the manpages by the lintian warnings:

- W manpage-has-bad-whatis-entry x 16
- W manpage-has-errors-from-man x 2

... but probably these should have been outright errors.



signature.asc
Description: OpenPGP digital signature

Bug#841137: gnuplot5-qt: double free or corruption

[Vincent Lefevre]

Package: gnuplot5-qt
Version: 5.0.3+dfsg2-2
Severity: important

I got the following error when plotting a graph (the commands with data
are sent its standard input):

*** Error in `/usr/bin/gnuplot': double free or corruption (fasttop): 
0x7f369007f9d0 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f36aa990bcb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76fa6)[0x7f36aa996fa6]
/lib/x86_64-linux-gnu/libc.so.6(+0x7779e)[0x7f36aa99779e]
/usr/lib/x86_64-linux-gnu/libX11.so.6(XFree+0x9)[0x7f36ab9c08c9]
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(gdk_window_get_frame_extents+0x447)[0x7f36a89c1357]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_window_get_position+0xac)[0x7f36a8e6602c]
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0(_ZN19wxTopLevelWindowGTK17GTKConfigureEventEii+0x134)[0x7f36adb369a4]
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0(+0x29fa02)[0x7f36adb36a02]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x13184c)[0x7f36a8d3a84c]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x145)[0x7f36acd5af75]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x21f82)[0x7f36acd6cf82]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x8df)[0x7f36acd7566f]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f36acd75faf]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x24998c)[0x7f36a8e5298c]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_main_do_event+0x4a3)[0x7f36a8d395a3]
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(+0x5acec)[0x7f36a89aecec]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x2a7)[0x7f36aca817d7]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4aa40)[0x7f36aca81a40]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0xc2)[0x7f36aca81d62]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_main+0xb7)[0x7f36a8d38447]
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0(_ZN14wxGUIEventLoop5DoRunEv+0x25)[0x7f36adb159c5]
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN15wxEventLoopBase3RunEv+0xa3)[0x7f36ad4a56f3]
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN16wxAppConsoleBase8MainLoopEv+0x56)[0x7f36ad46aa06]
/usr/bin/gnuplot[0x50ef5f]
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN8wxThread9CallEntryEv+0xa2)[0x7f36ad5b7862]
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(+0x1c7253)[0x7f36ad5be253]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7464)[0x7f36aacc5464]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x5f)[0x7f36aaa089df]
=== Memory map: 
0040-0058b000 r-xp  fe:01 8519972
/usr/bin/gnuplot5-qt
0078a000-0078f000 r--p 0018a000 fe:01 8519972
/usr/bin/gnuplot5-qt
0078f000-0079f000 rw-p 0018f000 fe:01 8519972
/usr/bin/gnuplot5-qt
0079f000-007b rw-p  00:00 0 
0174d000-0276c000 rw-p  00:00 0  [heap]
7f368800-7f3688021000 rw-p  00:00 0 
7f3688021000-7f368c00 ---p  00:00 0 
7f369000-7f3690273000 rw-p  00:00 0 
7f3690273000-7f369400 ---p  00:00 0 
7f3696983000-7f3696984000 rw-p  00:00 0 
7f3696984000-7f36969e4000 rw-s  00:05 11862024   
/SYSV (deleted)
7f36969e4000-7f36969f4000 rw-p  00:00 0 
7f36969f4000-7f36969f7000 rw-s  00:05 11665415   
/SYSV (deleted)
7f36969f7000-7f3696a13000 r--p  fe:01 9306534
/usr/share/icons/gnome/icon-theme.cache
7f3696a13000-7f3696a16000 r--p  fe:01 8651749
/usr/share/icons/hicolor/icon-theme.cache
7f3696a16000-7f3696acf000 r--p  fe:01 8782732
/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
7f3696acf000-7f3696ad6000 r--s  fe:01 12740926   
/var/cache/fontconfig/4be9850f182b35c1350b6bbf2e42601c-le64.cache-4
7f3696ad6000-7f3696ad8000 r--s  fe:01 12753175   
/var/cache/fontconfig/30a99c4256905863f7aa12b5e873c27c-le64.cache-4
7f3696ad8000-7f3696ad9000 r--s  fe:01 12753174   
/var/cache/fontconfig/087e1975ba9a574b140bb1df193bf770-le64.cache-4
7f3696ad9000-7f3696adf000 r--s  fe:01 12753173   
/var/cache/fontconfig/6fe8b0d39a161d19087fe931545dda13-le64.cache-4
7f3696adf000-7f3696ae3000 r--s  fe:01 12753169   
/var/cache/fontconfig/6aa41aa22e18b8fa06a12da28ea9c28b-le64.cache-4
7f3696ae3000-7f3696aee000 r--s  fe:01 12738727   
/var/cache/fontconfig/945677eb7aeaf62f1d50efc3fb3ec7d8-le64.cache-4
7f3696aee000-7f3696aef000 r--s  fe:01 12753165   
/var/cache/fontconfig/b95bc8ffbebda2bbdae4265e45b8178d-le64.cache-4
7f3696aef000-7f3696af r--s  fe:01 12753162   
/var/cache/fontconfig/9c956a7723ca69a44b382d9179c9802f-le64.cache-4
7f3696af-7f3696af1000 r--s  fe:01 12753155   

Bug#800291: jade: Please migrate a supported debhelper compat level

[Neil Roeth]

Thanks, Tobias.

I have finished filing bugs against all packages with reverse
dependencies on jade and sp.  All are blockers on the tracking bugs.  I
will follow up and/or NMU as necessary.

On 10/16/2016 05:26 AM, Tobias Frost wrote:
> Hi Neil,
>
> sorry for the late reply... Been busy recenently.
>
> Am Sonntag, den 25.09.2016, 12:32 -0400 schrieb Neil Roeth:
>> Hi, Tobi,
>>
>> The removal of jade, sp and openjade1.3 is coming
>> along.   Openjade1.3
>> is done, it was actually removed from testing but there were no more
>> dependencies on it.  I was focusing recently on the sp binary
>> package,
>> and most of those dependencies have been switched to opensp.  Jade is
>> next.
>>
>> There are tracking bugs already, 811310 and 811312.
> ok
>
>> Aboot and iputils have bugs with patches open to change sp to opensp.
>>
>> Can you explain the output below?  I guess "dak rm jade" means remove
>> jade, while the -n means not to actually do it (no act).  What does
>> -R
>> mean?  Does the command apply to the jade source package or the
>> binary
>> package?  I'm guessing source since sp appears in the list and it is
>> a
>> binary package built from the jade source package.
> The command checks what would happen if you remove jade from the
> archives, a convenient way to check reverse dependencies you have on
> jade.
>
>> Thanks.
>>
>> On 09/25/2016 07:04 AM, Tobias Frost wrote:
>>> Hi Neil,
>>>
>>> how is the removal going?
>>> I was wondering if there should be a dedicated bug to track the
>>> status
>>> of the progess? What do you think? 
>>>
>>>
>>> A "dak rm -Rn jade" yields to:
>>>
>>>
>>> # Broken Depends:
>>> xmldiff: xmldiff-xmlrev
>>>
>>> # Broken Build-Depends:
>>> aboot: sp
>>> alex: jade
>>> datapacker: jade
>>> dejagnu: jade
>>> gnome-packagekit: sp
>>> gstreamer1.0: jade (>= 1.2.1)
>>> iputils: sp
>>> kannel: jade
>>> libetpan: jade
>>> lprng-doc: jade
>>> mozart: sp
>>> pyepl: jade
>>> scons-doc: jade
>>>
>>>
>>> --
>>> tobi 
>>>
>>> On Thu, 29 Oct 2015 21:00:50 -0400 Neil Roeth 
>>> wrote:
 I intend to remove this package from Debian rather than update
>>> it.  The
 Debian packages openjade/opensp can be used instead. I will file
 bugs
 against any packages that depend on jade and give them some time
 to
>>> be
 updated before I file the actual removal bug for jade.
  
 -- 
 Neil Roeth
  
  
  
>>
>>
>>


-- 
Neil Roeth

Bug#841136: ITP: sagemath -- Sage: Open Source Mathematical Software

[Ximin Luo]

Package: wnpp
Severity: wishlist
Owner: Ximin Luo 

* Package name: sagemath
  Version : 7.4
  Upstream Author : SageMath developers 
* URL : https://www.sagemath.org/
* License : GPL-2+
  Programming Lang: Python
  Description : Sage: Open Source Mathematical Software

SageMath is a free open-source mathematics software system licensed under the
GPL. It builds on top of many existing open-source packages: NumPy, SciPy,
matplotlib, Sympy, Maxima, GAP, FLINT, R and many more. Access their combined
power through a common, Python-based language or directly via interfaces or
wrappers.

Mission: Creating a viable free open source alternative to Magma, Maple,
Mathematica and Matlab.

Bug#839767: ncmpcpp fails to start due to undefined symbol in binary

[Matteo Cypriani]

Control: severity -1 important
Control: tag -1 + upstream
Control: forwarded -1 https://github.com/taglib/taglib/issues/757

Le mercredi 12 octobre 2016, 14:33:36 EDT Christoph Egger a écrit :
> Control: reopen -1
> Control: reassign -1 libtag1v5
> Control: found -1 1.11+dfsg.1-0.1
> 
> Christoph Egger  writes:
> > Which is exactly what happened in unstable ~1 day ago as part of the
> > transition. So this seems to be a totally normal unstable disturbance
> > and not a bug.
> 
> Actually missing symbol seems to indicate libtag missed a soname bump?
> (And the problem was hidden by an unrelated binnmu later).

Indeed, WCharByteOrder was removed between taglib 1.9 and 1.11, as well as 
several other symbols, but the so version was changed only from 1.14.0 to 
1.16.0. I reported the problem upstream, but this is not an easy matter, as we 
can't just decide to bump the soname in Debian without a green light from 
upstream.

Matteo

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

Bug#761713: kstars: Please build-depends on libcfitsio-dev instead of libcfitsio3-dev

[Aurelien Jarno]

On 2015-02-02 15:33, Adrien Grellier wrote:
> tag 761713 confirmed pending
> thanks

This has been done more than one year ago, and there has been a few
uploads since them, so I believe the commit has been lost somewhere.

Would it be possible to fix that soon, so that we can proceed with the
removal of the transitional package for Stretch? Thanks in advance.

Aurelien

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


signature.asc
Description: PGP signature

Bug#841135: iso-scan/filename ignored in Debian 8.6.0 => cannot put it on multiboot USB stick

[Alain Knaff]

Package: iso-scan
Version: 1.53

Hi,

I'm trying to set up a multiboot USB stick (containing bootable Debian,
Ubuntu, Redhat, etc. distributions on one media)

For this, I am following the instructions at
https://wiki.archlinux.org/index.php/Multiboot_USB_drive#Debian

However, despite all attempts to the contrary, iso-scan seems to
steadfastly ignore the iso-scan/filename parameter: it neither takes it
at face value (as the sole qualifying filename for an ISO), nor does it
prompt the user if multiple ISOs are on the stick.

With the result that it tries to install from an Ubuntu ISO that also
happens to be on the stick, and (predictably) fails.

However, modifying the /var/lib/dpkg/info/iso-scan.postinst script as
follows fixes the issue:

Before the "for dir in . ./*; do" loop, insert:

db_get iso-scan/filename
if [ -f "./$RET" ] ; then
iso=`echo "$RET" | sed 's;^/;;'`
log "Found ISO $iso on $dev"
ISO_COUNT=$(($ISO_COUNT + 1))
add_usable_iso $iso $dev
else

... and after it, insert:
fi


I'm also wondering why in Debian we have to download a special hd-media
initrd.gz from
https://mirrors.kernel.org/debian/dists/stable/main/installer-amd64/current/images/hd-media/
at all, rather than having the standard initrd.gz included in the ISO
itself be able to also boot from an USB stick (as is the case in Ubuntu,
and in many other distros)

Thanks for your attention,

Alain

Bug#841124: FTBFS on amd64

[Kurt Roeckx]

On Mon, Oct 17, 2016 at 11:20:07PM +0100, James Clarke wrote:
> This was fixed upstream by [1]. I intend to perform another NMU to fix
> this; please let me know if you disagree.

Go ahead. There is no need to upload this via delayed, I was
suprised your previous upload was.


Kurt

Bug#817372: bandwidthcalc: diff for NMU version 0.2-1.1

[fike]

Control: tags 817372 + patch
Control: tags 817372 + pending

Dear maintainer,

I've prepared an NMU for bandwidthcalc (versioned as 0.2-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u bandwidthcalc-0.2/debian/changelog bandwidthcalc-0.2/debian/changelog
--- bandwidthcalc-0.2/debian/changelog
+++ bandwidthcalc-0.2/debian/changelog
@@ -1,3 +1,15 @@
+bandwidthcalc (0.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Updated DH level to 10. (Closes: #817372)
+  * debian/control:
+- Bumped Standards-Version to 3.9.8
+  * debian/copyright:
+- Fixed license link.
+  * Run wrap-and-sort.
+
+ -- Fernando Ike   Sat, 15 Oct 2016 22:58:05 -0300
+
 bandwidthcalc (0.2-1) unstable; urgency=low
 
   * New Upstream Version
diff -u bandwidthcalc-0.2/debian/compat bandwidthcalc-0.2/debian/compat
--- bandwidthcalc-0.2/debian/compat
+++ bandwidthcalc-0.2/debian/compat
@@ -1 +1 @@
-4
+10
diff -u bandwidthcalc-0.2/debian/control bandwidthcalc-0.2/debian/control
--- bandwidthcalc-0.2/debian/control
+++ bandwidthcalc-0.2/debian/control
@@ -2,13 +2,21 @@
 Section: x11
 Priority: optional
 Maintainer: Christoph Goehre 
-Build-Depends: debhelper (>= 4.0.0), autotools-dev, libatk1.0-dev, 
libglib2.0-dev (>= 2.6), libgtk2.0-dev (>= 2.6), libpango1.0-dev
+Build-Depends:
+ autotools-dev,
+ debhelper (>= 10),
+ libatk1.0-dev,
+ libglib2.0-dev (>= 2.6),
+ libgtk2.0-dev (>= 2.6),
+ libpango1.0-dev,
 DM-Upload-Allowed: yes
-Standards-Version: 3.8.0
+Standards-Version: 3.9.8
 
 Package: bandwidthcalc
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
 Description: file transfer time calculator written in GTK+
  Given the available bandwidth, bandwidthcalc determines how long it will take
  to transfer a file of a given size. You can specify the available bandwidth in
diff -u bandwidthcalc-0.2/debian/copyright bandwidthcalc-0.2/debian/copyright
--- bandwidthcalc-0.2/debian/copyright
+++ bandwidthcalc-0.2/debian/copyright
@@ -25,2 +25 @@
-Public License can be found in `/usr/share/common-licenses/GPL'.
-
+Public License can be found in `/usr/share/common-licenses/GPL-2'.

Bug#793749: ITP: telegraf -- plugin-driven server agent for reporting metrics into InfluxDB

[Guillem Jover]

Control: tags -1 patch

Hi!

On Sun, 2015-07-26 at 23:32:17 -0400, Alexandre Viau wrote:
> Package: wnpp
> Severity: wishlist

> * Package name: telegraf
>   Upstream Author : InfluxDB inc.
> * URL : https://github.com/influxdb/telegraf
> * License : Expat
>   Programming Lang: Go

Ok, all necessary parts have either bugs filed against existing packages
in Debian, or RFP filed with packaging patches. And are blocking this
bug.

Attached is a working and tested packaging delta against
. The
missing part is updating that repo to version 1.0.1, which is the
latest upstream release, and what I've been working against. Please
let me know if something smells fishy.

For the patches needed for telegraf, I'll be submitting them upstream,
but only once I've internally cleared the situation with the CLA.

Thanks,
Guillem
From cc6f2ab1a4f25530c46418edfb3eb79de2c67ce9 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Mon, 17 Oct 2016 23:32:53 +0200
Subject: [PATCH] Update packaging to 1.0.1

---
 debian/.gitignore   |7 +
 debian/changelog|   35 +-
 debian/control  |   98 +-
 debian/copyright|   11 +-
 debian/patches/excise-unavailable-plugins.patch |   97 ++
 debian/patches/fix-snmp-plugin.patch|   33 +
 debian/patches/series   |4 +
 debian/patches/testsuite-no-network.patch   |  412 +++
 debian/patches/use-licenseful-module.patch  |   22 +
 debian/rules|   33 +-
 debian/telegraf-dev.install |1 +
 debian/telegraf.conf| 1456 +++
 debian/telegraf.dirs|3 +
 debian/telegraf.init|  121 ++
 debian/telegraf.install |2 +
 debian/telegraf.lintian-overrides   |3 +
 debian/telegraf.logrotate   |   10 +
 debian/telegraf.postinst|   42 +
 debian/telegraf.postrm  |   28 +
 19 files changed, 2387 insertions(+), 31 deletions(-)
 create mode 100644 debian/.gitignore
 create mode 100644 debian/patches/excise-unavailable-plugins.patch
 create mode 100644 debian/patches/fix-snmp-plugin.patch
 create mode 100644 debian/patches/series
 create mode 100644 debian/patches/testsuite-no-network.patch
 create mode 100644 debian/patches/use-licenseful-module.patch
 create mode 100644 debian/telegraf-dev.install
 create mode 100644 debian/telegraf.conf
 create mode 100644 debian/telegraf.dirs
 create mode 100755 debian/telegraf.init
 create mode 100644 debian/telegraf.install
 create mode 100644 debian/telegraf.lintian-overrides
 create mode 100644 debian/telegraf.logrotate
 create mode 100644 debian/telegraf.postinst
 create mode 100644 debian/telegraf.postrm

diff --git a/debian/.gitignore b/debian/.gitignore
new file mode 100644
index 000..30f7739
--- /dev/null
+++ b/debian/.gitignore
@@ -0,0 +1,7 @@
+*.debhelper
+*.substvars
+*.log
+files
+tmp
+telegraf
+telegraf-dev
diff --git a/debian/changelog b/debian/changelog
index f7377c4..dff214e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,38 @@
-telegraf (0.1.8~dfsg1-1) UNRELEASED; urgency=low
+telegraf (1.0.1-1) UNRELEASED; urgency=low
 
+  [ Alexandre Viau ]
   * Initial release. (Closes: #793749)
 
+  [ Guillem Jover ]
+  * New upstream release 1.0.1.
+- Update Build-Depends and telegraf-dev Depends.
+  * Fix SNMP plugin to build and pass the test suite.
+  * Fix test suite to avoid a flaky test, and to not assume service daemons
+are running by keying on a new environment variable TELEGRAF_SERVERS_TEST,
+which we do not set.
+  * Use the github.com/kballard/go-shellquote module instead of
+github.com/gonuts/go-shellquote, which has no license as is not in Debian.
+  * Use dpkg Makefile fragments to get the upstream version, and set
+main.version with it.
+  * Use current import path, and switch from DH_GOPKG to XS-Go-Import-Path.
+  * Wrap and sort (-ast) debian/control fields.
+  * Add a Built-Using field to the telegraf binary.
+  * Change the Architecture field for telegraf from all to any.
+  * Set the builddirectory to build.
+  * Set DH_GOLANG_INSTALL_EXTRA to the list of required testdata files.
+  * Set DH_GOLANG_EXCLUDES to the plugins that pull dependencies not present
+in Debian, and that are peripheral. And disable those plugins from the
+code with a patch. They can be re-enabled once the dependencies get
+packaged in Debian.
+  * Use https in the debian/copyright Format field.
+  * Install a default telegraf configuration file.
+  * Install a logrotate file for telegraf.
+  * Create postinst and prerm maintaner scripts to handle creation of user,
+groups and set 

Bug#841124: FTBFS on amd64

[James Clarke]

Control: tags -1 patch fixed-upstream

On Mon, Oct 17, 2016 at 08:40:21PM +0100, James Clarke wrote:
> Source: elfutils
> Version: 0.166-2.1
> Severity: serious
>
> Hi,
> My NMU (#832584) FTBFS on amd64[1]. However, the only changes were
> adding Build-Depends on sparc64, and 0.166-2 itself FTBFS in a clean
> amd64 chroot (log attached), so it seems the more recent dependencies
> are problematic.
>
> Important part of the (buildd) log:
>
> > FAIL: run-backtrace-native.sh
> > =
> >
> > 0x7fa73d9dc000  0x7fa73dd76000  /lib/x86_64-linux-gnu/libc-2.24.so
> > 0x7fa73dd7a000  0x7fa73df93000  /lib/x86_64-linux-gnu/libpthread-2.24.so
> > 0x7fa73df97000  0x7fa73e1bb000  /lib/x86_64-linux-gnu/ld-2.24.so
> > 0x7fa73e1bc000  0x7fa73e3bf000  / PKGBUILDDIR /tests/backtrace-child
> > 0x7ffe5aaf5000  0x7ffe5aaf7000  [vdso: 16415]
> > TID 16415:
> > # 0 0x7fa73dd8afdf  raise
> > # 1 0x7fa73e1bcad5 - 1  main
> > # 2 0x7fa73d9fc2b1 - 1  __libc_start_main
> > # 3 0x7fa73e1bcc0a - 1  _start
> > TID 16416:
> > # 0 0x7fa73dd8afdf  raise
> > # 1 0x7fa73e1bcd6b - 1  sigusr2
> > # 2 0x7fa73da0f040  (null)
> > # 3 0x7fa73e1bce70  jmp
> > # 4 0xa8428197 - 1  (null)
> > backtrace: backtrace.c:128: callback_verify: Assertion `symname != NULL
> > && strcmp (symname, "stdarg") == 0' failed.
> > ./test-subr.sh: line 84: 16412 Aborted
> > LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
> > $VALGRIND_CMD "$@"
> > # 1 0x7fa73e1bcad5 - 1  main
> > backtrace-child: neither empty nor just out of DWARF
> > FAIL run-backtrace-native.sh (exit status: 1)
>
> Regards,
> James
>
> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=elfutils=amd64=0.166-2.1=1476727320

This was fixed upstream by [1]. I intend to perform another NMU to fix
this; please let me know if you disagree.

Regards,
James

[1] 
https://git.fedorahosted.org/cgit/elfutils.git/commit/?id=9008499a5276c45b37bc0adb47e7ad227e6ba2a9


signature.asc
Description: PGP signature

Bug#837281: [PKG-Openstack-devel] Bug#837281: manila-ui: FTBFS: compressor.exceptions.OfflineGenerationError: No template loaders defined. You must set TEMPLATE_LOADERS in your settings or set 'loader

[Santiago Vila]

On Thu, 13 Oct 2016, Thomas Goirand wrote:

> On 10/12/2016 10:56 PM, Santiago Vila wrote:
> > found 837281 2.5.1-0
> > thanks
> > 
> > I can still reproduce the error reported by Lucas in this version.
> > 
> > I attach a build log for 2.5.1-0.
> > 
> > I think this could be a bug in openstack-dashboard, one of the
> > build-depends. If this is really the case, please use reassign and
> > affects so that we can see the bug in the page for src:manila-ui and
> > this way we avoid filing duplicate bugs.
> 
> [...]
>
> Though technically, I don't think this bug should stay open. There's no
> bug in manila-ui, only in Horizon 9, which was already filled in the BTS
> and fixed by the upload of version 10. If you know a way to express this
> in the BTS, let me know, [...]

I explained the way to express this in the BTS in my previous message.
(See the text I quoted above).

I will repeat it with a little bit more of detail:

If this is not a bug in manila-ui but in some other package, then please
reassign this bug to some-other-package and then send this to the
control address:

affects 837281 src:manila-ui

(You can "reassign" and "affects" in the same message, of course).

The "affects" command will make this bug to appear in the bug page for
manila-ui, because it's the real reason for the FTBFS. This should
help everybody to see that this is really a bug in some-other-package
and at the same time it will help people like me (who build packages
in testing) to avoid filing duplicate bugs against manila-ui.

Thanks.

Bug#841134: amarok: FTBFS (cmake error)

[Santiago Vila]

Package: src:amarok
Version: 2.8.0-5
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with kde --parallel
   dh_testdir -i -O--parallel
   dh_update_autotools_config -i -O--parallel
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -Skde -- -DCMAKE_USE_RELATIVE_PATHS=ON 
-DKDE4_BUILD_TESTS=false
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_BUILD_TYPE=Debian 
-DCMAKE_USE_RELATIVE_PATHS=ON -DKDE4_BUILD_TESTS=false
-- The C compiler identification is GNU 6.2.0
-- The CXX compiler identification is GNU 6.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info

[... snipped ...]

Feature record: CXX_FEATURE:0cxx_inline_namespaces
Feature record: CXX_FEATURE:0cxx_lambdas
Feature record: CXX_FEATURE:0cxx_lambda_init_captures
Feature record: CXX_FEATURE:0cxx_local_type_template_args
Feature record: CXX_FEATURE:0cxx_long_long_type
Feature record: CXX_FEATURE:0cxx_noexcept
Feature record: CXX_FEATURE:0cxx_nonstatic_member_init
Feature record: CXX_FEATURE:0cxx_nullptr
Feature record: CXX_FEATURE:0cxx_override
Feature record: CXX_FEATURE:0cxx_range_for
Feature record: CXX_FEATURE:0cxx_raw_string_literals
Feature record: CXX_FEATURE:0cxx_reference_qualified_functions
Feature record: CXX_FEATURE:0cxx_relaxed_constexpr
Feature record: CXX_FEATURE:0cxx_return_type_deduction
Feature record: CXX_FEATURE:0cxx_right_angle_brackets
Feature record: CXX_FEATURE:0cxx_rvalue_references
Feature record: CXX_FEATURE:0cxx_sizeof_member
Feature record: CXX_FEATURE:0cxx_static_assert
Feature record: CXX_FEATURE:0cxx_strong_enums
Feature record: CXX_FEATURE:1cxx_template_template_parameters
Feature record: CXX_FEATURE:0cxx_thread_local
Feature record: CXX_FEATURE:0cxx_trailing_return_types
Feature record: CXX_FEATURE:0cxx_unicode_literals
Feature record: CXX_FEATURE:0cxx_uniform_initialization
Feature record: CXX_FEATURE:0cxx_unrestricted_unions
Feature record: CXX_FEATURE:0cxx_user_literals
Feature record: CXX_FEATURE:0cxx_variable_templates
Feature record: CXX_FEATURE:0cxx_variadic_macros
Feature record: CXX_FEATURE:0cxx_variadic_templates
Determining if the function dlopen exists in the dl passed with the following 
output:
Change Dir: /<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_9bc6d/fast"
make[2]: Entering directory 
'/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_9bc6d.dir/build.make 
CMakeFiles/cmTC_9bc6d.dir/build
make[3]: Entering directory 
'/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_9bc6d.dir/CheckFunctionExists.c.o
/usr/bin/cc-g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -DCHECK_FUNCTION_EXISTS=dlopen   -o 
CMakeFiles/cmTC_9bc6d.dir/CheckFunctionExists.c.o   -c 
/usr/share/cmake-3.6/Modules/CheckFunctionExists.c
Linking C executable cmTC_9bc6d
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_9bc6d.dir/link.txt 
--verbose=1
/usr/bin/cc  -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -DCHECK_FUNCTION_EXISTS=dlopen   -Wl,-z,relro  
CMakeFiles/cmTC_9bc6d.dir/CheckFunctionExists.c.o  -o cmTC_9bc6d -rdynamic -ldl 
make[3]: Leaving directory 
'/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
make[2]: Leaving directory 
'/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'


dh_auto_configure: cmake .. -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_BUILD_TYPE=Debian -DCMAKE_USE_RELATIVE_PATHS=ON 
-DKDE4_BUILD_TESTS=false returned exit code 1
debian/rules:11: recipe for target 'override_dh_auto_configure' failed
make[1]: *** [override_dh_auto_configure] Error 2
make[1]: Leaving directory '/<>'
debian/rules:27: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


The relevant part of the build log is included above.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

Thanks.

Bug#818484: Renaming or moving files or dirs leads to segfault

[cruncher]

Package: thunar
Version: 1.6.10-4
Followup-For: Bug #818484

Thanks for the new version, but it still crashes.

Do you need maybe a backtrace?



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

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

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-1
ii  exo-utils   0.10.7-1
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-4
ii  libcairo2   1.14.6-1+b1
ii  libdbus-1-3 1.10.12-1
ii  libdbus-glib-1-20.108-1
ii  libexo-1-0  0.10.7-1
ii  libgdk-pixbuf2.0-0  2.36.0-1
ii  libglib2.0-02.50.1-1
ii  libgtk2.0-0 2.24.31-1
ii  libgudev-1.0-0  230-3
ii  libice6 2:1.0.9-1+b1
ii  libnotify4  0.7.7-1
ii  libpango-1.0-0  1.40.3-2
ii  libsm6  2:1.2.2-1+b1
ii  libthunarx-2-0  1.6.10-4
ii  libxfce4ui-1-0  4.12.1-2
ii  libxfce4util7   4.12.1-2
ii  libxfconf-0-2   4.12.0-3
ii  shared-mime-info1.7-1
ii  thunar-data 1.6.10-4

Versions of packages thunar recommends:
ii  dbus-x11 1.10.12-1
ii  gvfs 1.30.1-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libpangocairo-1.0-0  1.40.3-2
ii  libpangoft2-1.0-01.40.3-2
ii  thunar-volman0.8.1-2
ii  tumbler  0.1.31-2+b3
ii  xdg-user-dirs0.15-2
ii  xfce4-panel  4.12.0-4

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.3.1-4
ii  thunar-media-tags-plugin  0.2.1-1+b2

-- no debconf information

Bug#841133: ruby-gruff: FTBFS: Tests hang after segmentation fault

[Chris Lamb]

Source: ruby-gruff
Version: 0.6.0-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

ruby-gruff fails to build from source in unstable/amd64:

  […]

  /usr/lib/ruby/vendor_ruby/test/unit/ui/testrunnermediator.rb:65:in `run_suite'
  /usr/lib/ruby/vendor_ruby/test/unit/testsuite.rb:53:in `run'
  /usr/lib/ruby/vendor_ruby/test/unit/testsuite.rb:124:in `run_test'
  /usr/lib/ruby/vendor_ruby/test/unit/testsuite.rb:53:in `run'
  /usr/lib/ruby/vendor_ruby/test/unit/testsuite.rb:124:in `run_test'
  /usr/lib/ruby/vendor_ruby/test/unit/testsuite.rb:53:in `run'
  /usr/lib/ruby/vendor_ruby/test/unit/testsuite.rb:124:in `run_test'
  /usr/lib/ruby/vendor_ruby/test/unit/testcase.rb:467:in `run'
  /usr/lib/ruby/vendor_ruby/test/unit/testcase.rb:467:in `catch'
  /usr/lib/ruby/vendor_ruby/test/unit/testcase.rb:468:in `block in run'
  /usr/lib/ruby/vendor_ruby/test/unit/fixture.rb:283:in `run_setup'
  /usr/lib/ruby/vendor_ruby/test/unit/fixture.rb:248:in `run_fixture'
  /usr/lib/ruby/vendor_ruby/test/unit/fixture.rb:267:in `block in 
create_fixtures_runner'
  /usr/lib/ruby/vendor_ruby/test/unit/fixture.rb:267:in `block in 
create_fixtures_runner'
  /usr/lib/ruby/vendor_ruby/test/unit/testcase.rb:470:in `block (2 levels) in 
run'
  /usr/lib/ruby/vendor_ruby/test/unit/testcase.rb:744:in `run_test'
  
/home/lamby/temp/cdt.20161017230027.J3bkHcnItG.db.ruby-gruff/ruby-gruff-0.6.0/test/test_bezier.rb:14:in
 `test_bezier'
  
/home/lamby/temp/cdt.20161017230027.J3bkHcnItG.db.ruby-gruff/ruby-gruff-0.6.0/test/test_bezier.rb:14:in
 `new'
  
/home/lamby/temp/cdt.20161017230027.J3bkHcnItG.db.ruby-gruff/ruby-gruff-0.6.0/lib/gruff/base.rb:230:in
 `initialize'
  
/home/lamby/temp/cdt.20161017230027.J3bkHcnItG.db.ruby-gruff/ruby-gruff-0.6.0/lib/gruff/base.rb:968:in
 `reset_themes'
  
/home/lamby/temp/cdt.20161017230027.J3bkHcnItG.db.ruby-gruff/ruby-gruff-0.6.0/lib/gruff/base.rb:968:in
 `new'
  
/home/lamby/temp/cdt.20161017230027.J3bkHcnItG.db.ruby-gruff/ruby-gruff-0.6.0/lib/gruff/base.rb:968:in
 `initialize'
  
  -- Machine register context 
   RIP: 0x7f59938d0249 RBP: 0x RSP: 0x7ffd0ad90bd0
   RAX: 0x RBX: 0x01ee7510 RCX: 0x0021
   RDX: 0x RDI: 0x7f5993bf1b00 RSI: 0x
R8: 0x01ee7520  R9: 0x41a0 R10: 0x
   R11: 0x R12: 0x7f5993bf1b58 R13: 0x7f5993bf1b18
   R14: 0x01ee7510 R15: 0x7f5993bf1b00 EFL: 0x00010246
  

  […]

The full build log is attached.


Regards,

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


ruby-gruff.0.6.0-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#840691: libgs9: security update DSA-3691-1 breaks zathura, evince, ... in jessie

[Francesco Poli]

On Mon, 17 Oct 2016 06:52:25 +0200 Salvatore Bonaccorso wrote:

[...]
> Only a small status update. I worked on the very same patches for
> ghostscript as well for the unstable version, to confirm I did not any
> significant mistake in the backports. The problem starts there as well
> once the patches are applied, and I suspect it actually might have
> uncovered a bug in a library which is used by evince and zathura(-ps),
> libspectre came to my mind.

So, if I understand correctly, the same bug would appear in Debian
unstable, with the security patches applied.
Hence, finding a fix is even more important.

> 
> We go no reports for other clients so far, not using that.
> 
> If you want to give the packages as well for unstable a try, I have
> uploaded to https://people.debian.org/~carnil/tmp/ghostscript/ .

I hope other people will find the time to test the packages.
I am unfortunately swamped: I won't be able to follow the debugging
closely.   :-(

[...]
> Stay tuned, and any debugging help welcome.

Many thanks for the update.
Looking forward to seeing the issue solved for the best.

Thanks a lot for your time!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp02vorwCDLV.pgp
Description: PGP signature

Bug#841132: kid3: FTBFS: fatal error: chapterframe.h: No such file or directory

[Aurelien Jarno]

Package: kid3
Version: 3.4.2-1
Severity: serious

kid3 fails to build from source on all architectures with the following
error:

| /«PKGBUILDDIR»/src/plugins/taglibmetadata/taglibfile.cpp:119:26: fatal error: 
chapterframe.h: No such file or directory
|  #include 
|   ^
| compilation terminated.
| src/plugins/taglibmetadata/CMakeFiles/taglibmetadata.dir/build.make:93: 
recipe for target 
'src/plugins/taglibmetadata/CMakeFiles/taglibmetadata.dir/taglibfile.cpp.o' 
failed
| make[4]: *** 
[src/plugins/taglibmetadata/CMakeFiles/taglibmetadata.dir/taglibfile.cpp.o] 
Error 1

A full build log is available for example there:

https://buildd.debian.org/status/fetch.php?pkg=kid3=s390x=3.4.2-1%2Bb2=1476154044

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 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)

Bug#789010: Pending fixes for bugs in the libgps-point-perl package

[pkg-perl-maintainers]

tag 789010 + pending
thanks

Some bugs in the libgps-point-perl package are closed in revision
a7efd9aaba20926d941ee4bba161cb0a58832ee4 in branch 'master' by
Florian Schlichting

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

Commit message:

Recommend Geo::Inverse for distance calculations (closes: #789010)

Bug#698527: Already fixed in oldstable

[Francesco Poli]

On Sat, 15 Oct 2016 19:54:28 +0300 Adrian Bunk wrote:

> I am closing this bug since it is already fixed in oldstable.

ElmerGUI is included in the experimental package (elmerfem/7.0.svn.6034
+dfsg-2): it's not clear to me how the OpenSSL linking issue was solved.
I cannot find any explanation in the changelog: could someone please
clarify?

Please let me know.
Thanks for your time!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp4f6qlAHTIk.pgp
Description: PGP signature

Bug#841131: dump: FTBFS: aclocal-1.14: command not found

[Aurelien Jarno]

Package: dump
Version: 0.4b46-2
Severity: serious

dump fails to build from source on all architectures with the following
error:

| make[1]: Leaving directory '/«PKGBUILDDIR»'
|    dh_auto_build -a
|   make -j1
| make[1]: Entering directory '/«PKGBUILDDIR»'
| CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /«PKGBUILDDIR»/missing 
aclocal-1.14 -I m4
| /«PKGBUILDDIR»/missing: line 81: aclocal-1.14: command not found
| WARNING: 'aclocal-1.14' is missing on your system.
|  You should only need it if you modified 'acinclude.m4' or
|  'configure.ac' or m4 files included by 'configure.ac'.
|  The 'aclocal' program is part of the GNU Automake package:
|  
|  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
|  
|  
|  
| Makefile:405: recipe for target 'aclocal.m4' failed
| make[1]: *** [aclocal.m4] Error 127
| make[1]: Leaving directory '/«PKGBUILDDIR»'
| dh_auto_build: make -j1 returned exit code 2
| debian/rules:31: recipe for target 'build-arch' failed

You can get a full build log for example there:

https://buildd.debian.org/status/fetch.php?pkg=dump=s390x=0.4b46-2=1476009177

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 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)

Bug#839547: gnupg: unable to decrypt file

[Paul Rogé]

Hi Werner and Daniel, the upgrade to pinentry-gnome3 0.9.7-6 seems to 
have solved the problem. I suppose the bug entry can be marked as resolved.


thanks for the help!
Paul

Bug#841099: ITP: node-has-values -- Returns true if any values exist, false if empty

[Adrian Bunk]

On Mon, Oct 17, 2016 at 10:28:53PM +0200, Eduard Bloch wrote:
> Hallo,
> * Andrew Shadura [Mon, Oct 17 2016, 08:23:19PM]:
> > Hi,
> > 
> > On 17 October 2016 at 18:57, Sruthi Chandran  wrote:
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Sruthi Chandran 
> > > X-Debbugs-CC: debian-de...@lists.debian.org
> > >
> > > * Package name: node-has-values
> > >   Version : 0.1.4
> > >   Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
> > > * URL : https://github.com/jonschlinkert/has-values
> > > * License : Expat
> > >   Programming Lang: JavaScript
> > >   Description : Returns true if any values exist, false if empty
> > 
> > Honestly, I’d like to object to packaging a 31 line script in a
> > separate package. I’d rather see a package named
> > node-jonschlinkert-modules with all modules bundled, which would
> > Provides: node-has-values, node-copy-descriptor, …
> 
> +1
> 
> Seriously, can we please keep this nodejs stuff out of the main repository?
> 
> It's not like I don't trust APT guys in finding the right bullet to deal
> with thousands of trivial packages but do we really have to care about
> the costs of all that spam littering up our namespace?

I do not think insulting language like "spam" is helpful here.

In unstable there are around 3500 packages for perl modules,
and even more for python modules.

The whole JS ecosystem still being a bit immature is a real problem,
but the number of packages itself is not a problem.

I am not a fan of all that JS stuff, but I do not see any valid basis 
for rejecting such packages in general.

> Regards,
> Eduard.

cu
Adrian

-- 

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

Bug#841130: ITP: libgeo-inverse-perl -- module to calculate geographic distance from a lat & lon pair

[Florian Schlichting]

Package: wnpp
Owner: Florian Schlichting 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libgeo-inverse-perl
  Version : 0.05
  Upstream Author : Michael R. Davis 
* URL : https://metacpan.org/release/Geo-Inverse
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to calculate geographic distance from a lat & lon 
pair

Geo::Inverse is a pure Perl port of the NGS program in the public domain
"inverse" by Robert (Sid) Safford and Stephen J. Frakes. It can be used
to calculate the distance, forward and back azimuth from a latitude and
longitude pair.

The package will be maintained under the umbrella of the Debian Perl Group.

Bug#841129: src:libjpeg-turbo: FTBFS on mips*: jsimd_mips.c:82:3: error: 'env' undeclared

[Aurelien Jarno]

Package: src:libjpeg-turbo
Version: 1:1.5.1-1
Severity: serious
Tags: patch upstream

libjpeg-turbo fails to build from source on mips* with the following
error:

| libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic 
-ffloat-store -c jsimd_mips_dspr2.S -fPIE -o jsimd_mips_dspr2.o >/dev/null 2>&1
| jsimd_mips.c: In function 'init_simd':
| jsimd_mips.c:82:3: error: 'env' undeclared (first use in this function)
|env = getenv("JSIMD_FORCEDSPR2");
|^~~
| jsimd_mips.c:82:3: note: each undeclared identifier is reported only once for 
each function it appears in
| Makefile:596: recipe for target 'jsimd_mips.lo' failed

The problem is that the env variable is not declared in the MIPS
specific code. The following simple patch fixes the issue:

--- libjpeg-turbo-1.5.1.orig/simd/jsimd_mips.c
+++ libjpeg-turbo-1.5.1/simd/jsimd_mips.c
@@ -63,6 +63,8 @@ parse_proc_cpuinfo(const char* search_st
 LOCAL(void)
 init_simd (void)
 {
+  char *env = NULL;
+
   if (simd_support != ~0U)
 return;

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

Kernel: Linux 4.7.0-1-5kc-malta
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)

Bug#841128: aws-shell: FTBFS (ImportError: No module named 'setuptools')

[Santiago Vila]

Package: src:aws-shell
Version: 0.1.1-1
Severity: serious

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
dpkg-buildpackage: info: source package aws-shell
dpkg-buildpackage: info: source version 0.1.1-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by TANIGUCHI Takaki 
 dpkg-source --before-build aws-shell-0.1.1
 fakeroot debian/rules clean
dh clean --with python3 --buildsystem=pybuild
   dh_testdir -O--buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:184: python3.5 setup.py clean 
Traceback (most recent call last):
  File "setup.py", line 5, in 
from setuptools import setup, find_packages
ImportError: No module named 'setuptools'
E: pybuild pybuild:276: clean: plugin distutils failed with: exit code=1: 
python3.5 setup.py clean 
dh_auto_clean: pybuild --clean -i python{version} -p 3.5 returned exit code 13
debian/rules:7: recipe for target 'clean' failed
make: *** [clean] Error 25
dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2


[ Now that the package is in the archive, please consider uploading
  this package in source-only form. That should help avoid failures
  like this one ].

Thanks.

Bug#841127: ITP: libgeo-ellipsoids-perl -- standard Geo:: ellipsoid a, b, f and 1/f values

[Florian Schlichting]

Package: wnpp
Owner: Florian Schlichting 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libgeo-ellipsoids-perl
  Version : 0.16
  Upstream Author : Michael R. Davis 
* URL : https://metacpan.org/release/Geo-Ellipsoids
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : standard Geo:: ellipsoid a, b, f and 1/f values

Geo::Ellipsoids provides a large number of standard ellipsoid values
useful for calculations such as when determining the distance between
two points on a planet.

The package will be maintained under the umbrella of the Debian Perl Group.

Bug#837665: lsh-utils: FTBFS with bindnow and PIE enabled

[Niels Möller]

Magnus Holmgren  writes:

> The problem rather seems to be the missing #include "lsh_string.h". Implicit 
> declarations probably are extra bad with -fPIE.

Thanks!

I just tried compiling after ./configure --with-tcpwrappers. Which
results in an warning on lsh_get_cstring being undeclared. It compiles
without warnings after adding that missing include. (Apparently no
warnings about the incorrect UNUSED...).

Let me see if I can understand the way it fails (the fix, adding the
missing include, is the same either way, of course).

lsh_get_cstring returns a pointer, while an implicitly declared function
will be assumed to return int. And on x86_64, int is of a smaller size
than a pointer, so it's a very real difference. And the compiler is free
to ignore the high part, so it compiles it to something like

  call lsh_get_cstring
  mov %eax, %edx ;; pass 32-bit return value as argument for next call
  ... setup other args for the call ...
  call request_init

while with a correct declaration, it must generate

  mov %rax, %rdx ;; copy all 64 bits

The 32-bit mov above doesn't leave the high half of %rdx unchanged,
instead, it is always cleared. Which means that the above code will work
nonetheless in case all pointers occuring at runtime happen to have the
high 32-bits all zeros. In this case, memory for strings are always
allocated using malloc. 

So my guess is that traditionally, malloc returns small addresses if
possible, while -fPIE implies that memory returned by malloc is mapped
at randomized locations where the high 32 bits are almost never zero?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.

Bug#841126: python-ironic-inspector-client: openstackclient.common.utils is deprecated and will be removed after Jun 2017. Please use osc_lib.utils

[Turbo Fredriksson]

Package: python-ironic-inspector-client
Version: 1.7.0-2
Severity: minor

When running any 'openstack xxx yyy' command, I'm getting

  WARNING: openstackclient.common.utils is deprecated and will be removed after 
Jun 2017. Please use osc_lib.utils

Trying to track this done, I see:

  # rgrep openstackclient.common /usr/{lib/python2.7/dist-packages,bin,sbin} | 
grep utils
  /usr/lib/python2.7/dist-packages/osc_lib-1.1.0.egg-info/PKG-INFO:* 
openstackclient.common.utils -> osc_lib.utils
  Binary file /usr/lib/python2.7/dist-packages/openstackclient/common/utils.pyc 
matches
  /usr/lib/python2.7/dist-packages/ironic_inspector_client/shell.py:from 
openstackclient.common import utils

And the last file is in python-ironic-inspector-client...

According to #openstack-sdks, there is a newer version out.

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

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

Versions of packages python-ironic-inspector-client depends on:
ii  python-cliff1.15.0-5
ii  python-keystoneclient   1:3.2.0-2
ii  python-openstackclient  3.2.0-2
ii  python-oslo.i18n3.9.0-3
ii  python-oslo.utils   3.16.0-2
ii  python-pbr  1.10.0-1
ii  python-requests 2.11.1-1
ii  python-six  1.10.0-3
pn  python:any  

python-ironic-inspector-client recommends no packages.

python-ironic-inspector-client suggests no packages.

-- no debconf information

Bug#841099: ITP: node-has-values -- Returns true if any values exist, false if empty

[Eduard Bloch]

Hallo,
* Andrew Shadura [Mon, Oct 17 2016, 08:23:19PM]:
> Hi,
> 
> On 17 October 2016 at 18:57, Sruthi Chandran  wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Sruthi Chandran 
> > X-Debbugs-CC: debian-de...@lists.debian.org
> >
> > * Package name: node-has-values
> >   Version : 0.1.4
> >   Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
> > * URL : https://github.com/jonschlinkert/has-values
> > * License : Expat
> >   Programming Lang: JavaScript
> >   Description : Returns true if any values exist, false if empty
> 
> Honestly, I’d like to object to packaging a 31 line script in a
> separate package. I’d rather see a package named
> node-jonschlinkert-modules with all modules bundled, which would
> Provides: node-has-values, node-copy-descriptor, …

+1

Seriously, can we please keep this nodejs stuff out of the main repository?

It's not like I don't trust APT guys in finding the right bullet to deal
with thousands of trivial packages but do we really have to care about
the costs of all that spam littering up our namespace?

Regards,
Eduard.

Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid

[Ben Hutchings]

You've already commented the silent failure mode, so it's not that hard
to find.

As for 'is it problem?', why do you think I pointed these things out?
Perhaps you have good reasons to do things in an unusual way, but in
the absence of comments to explain them I infer that you either don't
know or have arbitrarily rejected conventional approaches.  Which you
seem to confirm by saying:

> I will NEVER use str* functions from libc in my code.

I'm ending this conversation here; ultimately it's for prospective
sponsors to decide whether it is a good idea to introduce this program
into Debian in its current shape.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.



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

Bug#834534: librep: please make the build reproducible

[Jose M Calhariz]

No worries, I will find out a solution. 

On October 17, 2016 9:06:49 PM GMT+01:00, Chris Lamb  wrote:
>Jose M Calhariz wrote:
>
>> And collab-maintainer?
>
>I would prefer .dsc if that's not too much trouble for you...? 
>
>
>Regards,
>
>-- 
>  ,''`.
> : :'  : Chris Lamb
> `. `'`  la...@debian.org / chris-lamb.co.uk
>   `-

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#834534: librep: please make the build reproducible

[Chris Lamb]

Jose M Calhariz wrote:

> And collab-maintainer?

I would prefer .dsc if that's not too much trouble for you...? 


Regards,

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

Bug#800032: pinentry-gnome3: Pinentry hangs for ~30s before asking for passphrase when invoked by Enigmail

[Simon McVittie]

On Mon, 17 Oct 2016 at 12:35:21 -0400, Daniel Kahn Gillmor wrote:
> On Mon 2016-10-17 09:27:14 -0400, Ondřej Kuzník wrote:
> > For all of the above I'd say yes, maybe apart from the query,
> > dbus-monitor doesn't say anything even though I can see dbus-daemon
> > starting new processes. It might be that I'm not passing it the options
> > to actually show that, do you know how to get it to display them?

Which dbus-daemon? In a correct configuration with a single login
session, you can usually have up to three:

* The system bus: runs as uid messagebus, is a system service like
  NetworkManager or logind, is how you communicate with such things
  (look for uid messagebus, or /proc/*/cmdline mentioning --system)

* The session bus: runs as your own uid, is part of your own
  personal environment like gnome-settings-daemon, gvfs or gpg-agent
  (look for /proc/*/cmdline mentioning --session)

* The accessibility bus: runs as your own uid, is a weird accessibility
  thing, 1 per X11 DISPLAY, every accessibility-enabled GUI talks to it
  (look for /proc/*/cmdline mentioning
  --config-file=/usr/share/defaults/at-spi2/accessibility.conf)

Confusingly, at-spi-bus-launcher is a session bus service (like gvfs or
gnome-keyring or whatever), and at-spi-bus-launcher is responsible
for starting the accessibility bus; so it's tied up with two separate
buses.

If you use systemd as pid 1, systemd-cgls is a nice way to get an overview
of how your processes relate to each other, which isn't fooled by the
"double-fork to daemonize" idiom.

All of the dbus-monitor commands below can be stopped by Ctrl+C:

To monitor the session bus: dbus-monitor --session

To monitor the system bus: sudo dbus-monitor --system (Debian >= stretch)

To monitor the accessibility bus:
* dbus-send --session --dest=org.a11y.Bus --print-reply /org/a11y/bus 
org.a11y.Bus.GetAddress
* it should promptly report something like
  string 
"unix:abstract=/tmp/dbus-11,guid="
* copy/paste it into a command like
  dbus-monitor --address 
unix:abstract=/tmp/dbus-11,guid=
* watch in despair as vast amounts of accessibility spam goes past,
  reporting every mouse movement, keypress, etc.
* wonder why the authors of AT-SPI thought D-Bus was the right hammer for
  this particular nail

> > Hmm, for some reason I have two dbus-daemons running and the one started
> > by ck-launch-session is the one where pinentry is having problems.

What is in their argv? (/proc/*/cmdline)

Is ck-launch-session something to do with ConsoleKit? If so, it's probably
a bad idea at this point.

Is there anything interesting in syslog (or equivalently the systemd
Journal)? Recent dbus versions log a lot more there than they used to.

I hope something here has pointed you in an informative direction.

Regards,
S

Bug#841125: ITP: libgeo-functions-perl -- standard functions for Geo perl modules

[Florian Schlichting]

Package: wnpp
Owner: Florian Schlichting 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libgeo-functions-perl
  Version : 0.07
  Upstream Author : Michael R. Davis 
* URL : https://metacpan.org/release/Geo-Functions
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : standard functions for Geo perl modules

The Geo::Functions module provides some standard functions for
conversions, for example between degrees, radians and degrees
minutes seconds, or between knots and meters per second.

The package will be maintained under the umbrella of the Debian Perl Group.

Bug#841124: FTBFS on amd64

[James Clarke]

Source: elfutils
Version: 0.166-2.1
Severity: serious

Hi,
My NMU (#832584) FTBFS on amd64[1]. However, the only changes were
adding Build-Depends on sparc64, and 0.166-2 itself FTBFS in a clean
amd64 chroot (log attached), so it seems the more recent dependencies
are problematic.

Important part of the (buildd) log:

> FAIL: run-backtrace-native.sh
> =
> 
> 0x7fa73d9dc000  0x7fa73dd76000  /lib/x86_64-linux-gnu/libc-2.24.so
> 0x7fa73dd7a000  0x7fa73df93000  /lib/x86_64-linux-gnu/libpthread-2.24.so
> 0x7fa73df97000  0x7fa73e1bb000  /lib/x86_64-linux-gnu/ld-2.24.so
> 0x7fa73e1bc000  0x7fa73e3bf000  / PKGBUILDDIR /tests/backtrace-child
> 0x7ffe5aaf5000  0x7ffe5aaf7000  [vdso: 16415]
> TID 16415:
> # 0 0x7fa73dd8afdf  raise
> # 1 0x7fa73e1bcad5 - 1  main
> # 2 0x7fa73d9fc2b1 - 1  __libc_start_main
> # 3 0x7fa73e1bcc0a - 1  _start
> TID 16416:
> # 0 0x7fa73dd8afdf  raise
> # 1 0x7fa73e1bcd6b - 1  sigusr2
> # 2 0x7fa73da0f040  (null)
> # 3 0x7fa73e1bce70  jmp
> # 4 0xa8428197 - 1  (null)
> backtrace: backtrace.c:128: callback_verify: Assertion `symname != NULL
> && strcmp (symname, "stdarg") == 0' failed.
> ./test-subr.sh: line 84: 16412 Aborted
> LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
> $VALGRIND_CMD "$@"
> # 1 0x7fa73e1bcad5 - 1  main
> backtrace-child: neither empty nor just out of DWARF
> FAIL run-backtrace-native.sh (exit status: 1)

Regards,
James

[1] 
https://buildd.debian.org/status/fetch.php?pkg=elfutils=amd64=0.166-2.1=1476727320
I: Copying COW directory
I: forking: rm -rf /var/cache/pbuilder/build/cow.17575
I: forking: cp -al /var/cache/pbuilder/base.cow 
/var/cache/pbuilder/build/cow.17575
I: removed stale ilistfile /var/cache/pbuilder/build/cow.17575/.ilist
I: forking: chroot /var/cache/pbuilder/build/cow.17575 
cowdancer-ilistcreate /.ilist 'find . -xdev -path ./home -prune -o \( \( -type 
l -o -type f \) -a -links +1 -print0 \) | xargs -0 stat --format '%d %i ''
I: Invoking pbuilder
I: forking: pbuilder build --binary-arch --buildplace 
/var/cache/pbuilder/build/cow.17575 --buildresult /var/cache/pbuilder/result/ 
--binary-arch --no-targz --internal-chrootexec 'chroot 
/var/cache/pbuilder/build/cow.17575 cow-shell' 
/home/james/src/elfutils/elfutils_0.166-2.dsc
I: Running in no-targz mode
I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: Mon Oct 17 20:16:01 BST 2016
I: pbuilder-time-stamp: 1476731761
I: copying local configuration
I: mounting /proc filesystem
I: mounting /sys filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: Mounting /pbuilder-repo
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Installing the build-deps
 -> Attempting to parse the build-deps
 -> Considering build-depdebhelper (>= 9)
   -> Trying to add debhelper
 -> Considering build-dep autotools-dev
   -> Trying to add autotools-dev
 -> Considering build-dep autoconf
   -> Trying to add autoconf
 -> Considering build-dep automake
   -> Trying to add automake
 -> Considering build-dep bzip2
   -> Trying to add bzip2
 -> Considering build-dep zlib1g-dev
   -> Trying to add zlib1g-dev
 -> Considering build-dep libbz2-dev
   -> Trying to add libbz2-dev
 -> Considering build-dep liblzma-dev
   -> Trying to add liblzma-dev
 -> Considering build-dep m4
   -> Trying to add m4
 -> Considering build-dep gettext
   -> Trying to add gettext
 -> Considering build-dep gawk
   -> Trying to add gawk
 -> Considering build-dep dpkg-dev (>= 1.16.1~)
   -> Trying to add dpkg-dev
 -> Considering build-dep gcc-multilib [any-amd64]
   -> Trying to add gcc-multilib
 -> Considering build-dep libc6-dbg [powerpc powerpcspe ppc64 ppc64el armel 
armhf arm64]
   -> This package is not for this architecture
 -> Considering build-dep flex
   -> Trying to add flex
 -> Considering build-dep bison
   -> Trying to add bison
 -> Installing  debhelper autotools-dev autoconf automake bzip2 zlib1g-dev 
libbz2-dev liblzma-dev m4 gettext gawk dpkg-dev gcc-multilib flex bison
Reading package lists...
Building dependency tree...
Reading state information...
bzip2 is already the newest version (1.0.6-8).
dpkg-dev is already the newest version (1.18.10).
The following additional packages will be installed:
  autopoint bsdmainutils dh-autoreconf dh-strip-nondeterminism file
  gcc-6-multilib gettext-base groff-base intltool-debian lib32asan3
  lib32atomic1 lib32cilkrts5 lib32gcc-6-dev lib32gcc1 lib32gomp1 lib32itm1
  lib32mpx2 lib32quadmath0 lib32stdc++6 lib32ubsan0 libarchive-zip-perl
  libbison-dev libbsd0 libc6-dev-i386 libc6-dev-x32 libc6-i386 libc6-x32
  libcroco3 libffi6 libfile-stripnondeterminism-perl libfl-dev libglib2.0-0
  libicu57 libmagic-mgc libmagic1 libpipeline1 libsigsegv2 libtimedate-perl
  

Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid

[Jan Mojzis]

On Monday 17 of October 2016 19:57:53 Ben Hutchings wrote:
> Jan Mojzis  wrote:
> [...]
> > I'm going to maintain the package using collab-maint.
> > I need sponsor.
> >
> > Debian package:
> >  - has autotest
> >  - is using debhelper
> >  - is using git-dpm https://anonscm.debian.org/cgit/collab-maint/extr
> emetools.git
> >  - lintian clean (no warnings)
> 
> However, the code:
> 
> - Has a silent failure mode
where?

> - Reinvents common C library functions like strtol(), getopt(),
> strerror()
I will NEVER use str* functions from libc in my code.

> - Defines many similar functions differing only in number of arguments,
> where a varargs function would be appropriate
Is it problem ?

> - Doesn't have a 'make install' rule
Is it problem ?

> - Has manually maintained dependencies on headers
Is it problem ?

> 
> I really think you should get a little more experience with C and
> makefiles, and a full code review, before packaging something that aims
> to be a security-critical tool.
> 
> Ben.

Bug#838860: Version 32+ Flash (SWF) files detected as 'application/octet-stream' (data), not 'application/x-shockwave-flash' by file (libmagic1)

[Christoph Biedl]

Laurence Parry wrote...

> It was assumed that the version number would remain below 32 "for the time
> being". This time has passed. Version 32 was published in May 2016, and it
> is already up to 34:
> http://www.adobe.com/devnet/articles/flashplayer-air-feature-list.html
> We detected this issue when our web application refused an SWF file created
> by an animator.

Thanks for the catch, although this is rather bad news for the file
program. As any value from 32 on is a printable character, there will
always be a risk of mis-detection.

> Alternatives which would preserve the fix for #745546 might be to permit
> versions below 48 ('0') or 65 ('A'), and/or to test for a sane length, e.g.
> 
> 0   string  CWS Macromedia Flash data (compressed),
> >3  bytex   version %d,
> >>4 lelong  <0x2000 length %d bytes
> !:mime  application/x-shockwave-flash
> 
> This refuses a 512MB compressed Flash file. I am not aware of anyone who's
> created such a file, but it is technically possible (e.g. Flash games with
> very large embedded flash videos).

I'm not really happy about this and could use more ideas. Assuming you
have a major collection to such files, is there anything in the
following header octets (FrameSize, FrameRate, FrameCount) that
somewhat certainly is not printable?

Christoph


signature.asc
Description: Digital signature

Bug#841123: auctex support for emacs25

[Dan Torop]

Subject: auctex support for emacs25
Package: auctex
Version: 11.88-1.2
Severity: wishlist
Tags: patch

Dear Maintainer,

When installing the new emacs25 package (which is currently in unstable)
configuration of auctex reports:

auctex/install: Ignoring unsupported Emacs flavor: emacs25

It does seem possible to install for emacs25 via manually adding the
emacs25 flavor to:

/etc/emacs/site-start.d/50auctex.el
/usr/lib/emacsen-common/packages/install/auctex
/usr/lib/emacsen-common/packages/remove/auctex

So far auctex is working well with emacs25. If there are no other
worries, it would be great if auctex could support emacs25.

I don't see a patch yet in
https://anonscm.debian.org/cgit/users/salve/auctex.git/log/. Attached is
a patch reminiscent of ccb8a09ed79360f92f0e1656790c31482a0d85f4 in that
repository to enable emacs25.

As a side note, as emacs23 is no longer in stable, I'm wondering how it
will disappear from the auctex packaging. I didn't make any such change
in the attached patch, though.

Thank you,
Dan Torop




-- Package-specific info:

Content of '/usr/share/emacs/site-lisp/auctex'

d41d8cd98f00b204e9800998ecf8427e  /usr/share/emacs/site-lisp/auctex/.nosearch
fc46c46f400a42af007fd42ce73395be  /usr/share/emacs/site-lisp/auctex/bib-cite.el
5ac2595246062777c61ed4104a93cf61  /usr/share/emacs/site-lisp/auctex/context-
en.el
f5ed983cd477814f04e4a63affd4f323  /usr/share/emacs/site-lisp/auctex/context-
nl.el
aaede47229785ee362c712c6887cc44f  /usr/share/emacs/site-lisp/auctex/context.el
f63e08bcef29eae9f56db5d404a0  /usr/share/emacs/site-lisp/auctex/font-
latex.el
f176261b5a5511cbe1401ee72ffb8947  /usr/share/emacs/site-
lisp/auctex/images/amstex.xpm
d33121019448617a3ad3bcafdeb8db40  /usr/share/emacs/site-
lisp/auctex/images/bibtex.xpm
1a43d6438010bceb374ab0a5f2bd05a8  /usr/share/emacs/site-
lisp/auctex/images/dropdown.xpm
41f1ae0341ae2e307d92a7b8b815f868  /usr/share/emacs/site-
lisp/auctex/images/dvipdf.xpm
2e4b8669b0168f32247411be3f999437  /usr/share/emacs/site-
lisp/auctex/images/dvips.xpm
55f7600cadc3a209e94bacf6bbc42a7c  /usr/share/emacs/site-
lisp/auctex/images/error.xpm
c29ad797273fd27201a40bd939a95fe0  /usr/share/emacs/site-
lisp/auctex/images/exec.xpm
79b958849511c67d6b13ef9f5b3673e8  /usr/share/emacs/site-
lisp/auctex/images/execbibtex.xpm
a8570e26e9f96b6f527cdbe218d6c55f  /usr/share/emacs/site-
lisp/auctex/images/execdvips.xpm
e647bc601aef2dc71b134a989df1adff  /usr/share/emacs/site-
lisp/auctex/images/execerror.xpm
4610ec6133f89ceb441c43dfee077361  /usr/share/emacs/site-
lisp/auctex/images/execpdftex.xpm
c9cd1fc9fe4fd122cbf900fae654a67b  /usr/share/emacs/site-
lisp/auctex/images/exectex.xpm
6a6b9af945d4735f048ea8e475f8d9b8  /usr/share/emacs/site-
lisp/auctex/images/execviewdvi.xpm
466466f6d1867510b058a9c184ffce5d  /usr/share/emacs/site-
lisp/auctex/images/execviewpdf.xpm
39d8ccaffb40b0c118e000f45272db05  /usr/share/emacs/site-
lisp/auctex/images/execviewps.xpm
6767e2583c668dcb47495197b9e8cb65  /usr/share/emacs/site-
lisp/auctex/images/gv.xpm
ff9c61ef5148a0cacd5422d7c0d99396  /usr/share/emacs/site-
lisp/auctex/images/jumpdvi.xpm
ece6608586b591f50f20d17cdb316a1c  /usr/share/emacs/site-lisp/auctex/images/ltx-
symb-turn-off.xpm
b1f10de33dcf1b5ca9ac6155c13683a3  /usr/share/emacs/site-lisp/auctex/images/ltx-
symb-turn-on.xpm
44e35faa18ab34f3c13ac3b0082bcc47  /usr/share/emacs/site-
lisp/auctex/images/pdftex.xpm
84673eb20ac3be7bf0eb4e84e23e828f  /usr/share/emacs/site-
lisp/auctex/images/prverr16.xpm
59e6a0dddb00ab16c4209a2e4c6e283d  /usr/share/emacs/site-
lisp/auctex/images/prverr20.xpm
30dc2ada41625cb24ea459bd62f7386c  /usr/share/emacs/site-
lisp/auctex/images/prverr24.xbm
225929f8131bdd7b9b8207494a59619a  /usr/share/emacs/site-
lisp/auctex/images/prverr24.xpm
0dac3d8eb00c902037cc5fa6a03e53e3  /usr/share/emacs/site-lisp/auctex/images
/prvtex-cap-up.xpm
40feb30f80d3606f32ba54b57ba18af5  /usr/share/emacs/site-
lisp/auctex/images/prvtex12.xbm
e1b3c9d6a6eb6fb6f096736cdfc059cf  /usr/share/emacs/site-
lisp/auctex/images/prvtex12.xpm
32406fc4b893b48d2996c424f61ea238  /usr/share/emacs/site-
lisp/auctex/images/prvtex16.xbm
cc4101ee6a3ab6a1f4e9991b91b3ff0b  /usr/share/emacs/site-
lisp/auctex/images/prvtex16.xpm
d4dbe057a8d3b2facd61cf7583c1e97c  /usr/share/emacs/site-
lisp/auctex/images/prvtex20.xpm
f25ba1b984b095c9c561e5443f3d77a3  /usr/share/emacs/site-
lisp/auctex/images/prvtex24.xbm
28ac0855d853f606dd91e3cfacaa8a14  /usr/share/emacs/site-
lisp/auctex/images/prvtex24.xpm
6ce704103821329336489e990bc6f267  /usr/share/emacs/site-
lisp/auctex/images/prvwrk12.xpm
5607f4e8bc0eb555206e6a3542205f45  /usr/share/emacs/site-
lisp/auctex/images/prvwrk14.xpm
878a72cde3bb6f0ea6d586cff56e619c  /usr/share/emacs/site-
lisp/auctex/images/prvwrk16.xpm
41811748a97673381115957d42a6529b  /usr/share/emacs/site-
lisp/auctex/images/prvwrk20.xpm
254fc07db6a03a8a24f762135a403433  

Bug#834534: librep: please make the build reproducible

[Jose M Calhariz]

On 17/10/16 19:08, Chris Lamb wrote:
> Jose M Calhariz wrote:
>
>> I need at least 2 weeks for finding a sponsor and upload it.
> I am happy to sponsor packages given HTTP-accessible links to .dsc
> files. :)

And collab-maintainer?

https://anonscm.debian.org/git/collab-maint/librep.git

It is not tagged and signed so it can be reviewed and corrected.

>
> Regards,
>
Kind regards

Jose M Calhariz





signature.asc
Description: OpenPGP digital signature

Bug#841122: ITP: libgeo-constants-perl -- standard constants used by Geo perl packages

[Florian Schlichting]

Package: wnpp
Owner: Florian Schlichting 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libgeo-constants-perl
  Version : 0.06
  Upstream Author : Michael R. Davis 
* URL : https://metacpan.org/release/Geo-Constants
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : standard constants used by Geo perl packages

Geo::Constant provides a number of standard constants used by the Geo::
family of modules, such as Pi, conversion from degrees to radians or
nautical miles to meters per second, and vice versa.

The package will be maintained under the umbrella of the Debian Perl Group.

Bug#841108: [Pkg-libvirt-maintainers] Bug#841108: gtk-vnc: please build Gtk+ 3 bindings

[Guido Günther]

Hi,
On Mon, Oct 17, 2016 at 01:51:34PM -0400, Chris Lawrence wrote:
> Source: gtk-vnc
> Version: 0.6.0-1
> 
> The Gtk+ 3 bindings to gtk-vnc are needed by some applications, such
> as "vncdesk"; accordingly, these bindings should be provided along
> with the Gtk+ 2 bindings in a future release.

We have GTK3 bindings via gir1.2-gtk-vnc-2.0. Thats all that should be
needed.

Cheers,
 -- Guido

Bug#837665: lsh-utils: FTBFS with bindnow and PIE enabled

[Magnus Holmgren]

tisdag 11 oktober 2016 kl. 15:53:34 CEST skrev  Niels Möller:
> I see one other odd thing when reading this code. The UNUSED declaration
> of the first argument is wrong; maybe recent gcc omits code related to
> that argument? You could try deleting that, and see if it makes a
> difference.

The problem rather seems to be the missing #include "lsh_string.h". Implicit 
declarations probably are extra bad with -fPIE.

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

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

Bug#834755: apt-cacher-ng: please make the build reproducible

[Eduard Bloch]

Hallo,
* Chris Lamb [Mon, Oct 17 2016, 10:54:53AM]:
> Dear Maintainer,
> 
> > Source: apt-cacher-ng
> > Version: 0.5.1-3
> > Tags: patch
> 
> There hasn't seem to be any update on this bug in 59 days, in which
> time the Reproducible Builds effort has come on a long way. :)

*g*

> Would you consider applying this patch and uploading?

I do, I am preparing a new upstream version RSN.

Regards,
Eduard.

Bug#839869: transition: poppler 0.48.0

[Emilio Pozuelo Monfort]

On 08/10/16 20:34, Pino Toscano wrote:
> In data giovedì 6 ottobre 2016 10:25:57 CEST, Rene Engelhard ha scritto:
>> Hi,
>>
>> On Wed, Oct 05, 2016 at 10:13:14PM +0200, Pino Toscano wrote:
>>> This transition impacts the existing poppler libraries in the following 
>>> ways:
>>> - libpoppler61 → libpoppler64
>> [...]
>>>   boomaga
>>>   calligra
>>>   cups-filters
>>>   emacs-pdf-tools
>>>   gambas3
>>>   gdal
>>>   gdcm
>>>   inkscape
>>>   ipe-tools
>>>   pdf2djvu
>>>   pdf2htmlex
>>>   popplerkit.framework
>>>   texlive-bin
>>>   texworks
>>>   xpdf
>>
>> I believe there's stuff missing there for whatever reason. E.g. libreoffice
>> (via libreoffice-pdfimport, 
>> https://packages.debian.org/sid/libreoffice-pdfimport).
>>
>> Was in your last transition bugs afaicr, so I wonder what went wrong this 
>> time ;)
> 
> Oh right, sorry, it was indeed missing.  In the above list there is also:
> 
>   libreoffice
>   openscenegraph
>   openscenegraph-3.4

I see the new poppler is now in experimental. Do the rdeps build against the new
version?

Emilio

Bug#841121: RFP: golang-github-influxdata-config -- unified configuration management package

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch
Control: block 793749 by -1

* Package name: golang-github-influxdata-config
  Version : 0.0~git20160309.0.8ec4638-1
  Upstream Author : InfluxData
* URL : https://github.com/influxdata/config
* License : NONE!? 
  Programming Lang: Go
  Description : A unified configuration management package

 The intention of this package is to unify existing patterns of interacting
 with configuration across the elements of the TICK+E stack. As such, it
 implements the superset of APIs from both github.com/influxdata/toml and
 github.com/BurntSushi/toml, while also providing a small API for the common
 case of loading and storing configuration from a particular file. It also
 provides wrapper types for formatting Durations and Sizes in TOML, which
 were previously held in a sub-package within InfluxDB. Also provided is the
 ability to document configuration fields using a "doc" struct tag. When the
 config struct is marshalled as TOML, any doc struct tags found will be
 inserted as TOML comments in an appropriate place to document the
 corresponding field.


This package is a dependency of telegraf latest upstream releases.

The lack of license situation needs to be resolved before this can be
uploaded (see the link in the License field above).

Attached a working and tested packaging, where only the ITP bug number
needs to be filled in the debian/changelog, Maintainer changed, and Vcs
fields added.

Thanks,
Guillem


golang-github-influxdata-config_0.0~git20160309.0.8ec4638-1.debian.tar.xz
Description: application/xz

Bug#840914:

[ZenWalker]

Control: close -1

Thanks a lot, it works

and yes, I experience the bug #840193

Bug#840295: Requesting RC exception for stretch for browserified javascript

[Emilio Pozuelo Monfort]

Hi Pirate,

On 10/10/16 11:57, Pirate Praveen wrote:
> package: release.debian.org
> 
> Dear Release Team,
> 
> As discussed with FTP masters[1], I'd like to request an RC exception
> for browserified javascript packages already in the archive.

Please correct me if I'm wrong, but I haven't seen any replies to the questions
you've got. I'm not sure what I'll think when you do that, but at the moment
this is a nack from me. Packages can still go into contrib if the build tools
can't get ready in time for the release, and then for buster (stretch+1) they
could move to main.

Another question is what build tools are we missing at this point? I have seen
some mentioned in the tech-ctte thread. Mostly grunt, which is ITP #673727. The
main problem there seems to be that jshint is non-free, but it seems[1] that it
can be made optional. Is that not the case? Are there other blockers, aside from
packaging the rdeps[2]? It'd be good to know what we are missing to get these
javascript packages buildable in main, and what is blocking those from entering
the archive.

Cheers,
Emilio

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673727#56
[2] https://wiki.debian.org/Javascript/Nodejs/Tasks/grunt

Bug#830175:

[DrSlony]

Hi Matthias

RawTherapee is optimized to make the most of your CPU and RAM. It is not 
optimized to freeze your system. What most likely happened is that you 
simply ran out of memory, having Firefox with all its tabs open while 
processing a raw photo, so your system started moving data to swap. Keep 
all RAM-hungry programs closed while processing raw files. Also, please 
use the latest snapshots Philip offers, because there have been a 
tremendous number of improvements since the two year old 4.2.0 you're 
still using.


Kind regards
Morgan

Bug#841120: RFP: golang-github-influxdata-toml -- TOML parser and encoder library for Golang

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch
Control: block 793749 by -1

* Package name: golang-github-influxdata-toml
  Version : 0.0~git20160905.0.ad49a5c-1
  Upstream Author : InfluxData
* URL : https://github.com/influxdata/toml
* License : Expat
  Programming Lang: Go
  Description : TOML parser and encoder library for Golang

 This is the Influxdata fork of the official TOML package. It supports
 additional data types, documenting TOML fields, and nicer output.


This package is a dependency of telegraf latest upstream releases.

There are two problems to be solved before this can be uploaded:

  * Uses a pre-built generated PEG output file, should be switched to
use the newly packaged peg-go.
  * Upstream has modified directly the pre-built generated PEG output
file, tracked at ,
but ITSM those changes could simply be dropped when the pre-generated
file gets dropped.

Attached a working and tested packaging, where in addition to the above,
only the ITP bug number needs to be filled in the debian/changelog,
Maintainer changed, and Vcs fields added.

Thanks,
Guillem


golang-github-influxdata-toml_0.0~git20160905.0.ad49a5c-1.debian.tar.xz
Description: application/xz

Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid

[Ben Hutchings]

Jan Mojzis  wrote:
[...]
> I'm going to maintain the package using collab-maint.
> I need sponsor.
>
> Debian package:
>  - has autotest
>  - is using debhelper
>  - is using git-dpm https://anonscm.debian.org/cgit/collab-maint/extr
emetools.git
>  - lintian clean (no warnings)

However, the code:

- Has a silent failure mode
- Reinvents common C library functions like strtol(), getopt(),
strerror()
- Defines many similar functions differing only in number of arguments,
where a varargs function would be appropriate
- Doesn't have a 'make install' rule
- Has manually maintained dependencies on headers

I really think you should get a little more experience with C and
makefiles, and a full code review, before packaging something that aims
to be a security-critical tool.

Ben.


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

Bug#827061: transition: openssl

[Emilio Pozuelo Monfort]

Hi Kurt,

On 12/10/16 22:47, Kurt Roeckx wrote:
> On Sun, Sep 18, 2016 at 09:33:43PM +0200, Kurt Roeckx wrote:
>> On Sat, Jun 11, 2016 at 09:42:59PM +0200, Kurt Roeckx wrote:
>>> On Sat, Jun 11, 2016 at 09:31:17PM +0200, Emilio Pozuelo Monfort wrote:
 On 11/06/16 20:59, Kurt Roeckx wrote:
> OpenSSL will soon release a new upstream version with a new
> soname.  This new version will break various packages, see:
> https://lists.debian.org/debian-devel/2016/06/msg00205.html
>
> I'm currently not sure when the release will be ready.  I would
> like to start this transition as soon as possible, but probably
> after it's actually released.  I don't expect this to take long.

 405 packages failed to build during your test rebuild AFAICS. That's going 
 to
 take some time to sort out...

> If I'm ready to upload it to unstable, can I start this
> transition?  Are there things you want me to do?

 Please upload to experimental first and let us know when that's happened.
>>>
>>> It's in experimental already.  The test suite only fails
>>> on hurd, for some reason it's not finding the engine.  I still
>>> need to look at that.
>>>
 We will also need bugs filed, with severity important for now.
>>>
>>> Sure, I'll start on that if I find the time.
>>>
 Also it may be useful if you can get us the intersection between the 
 packages
 that failed to build and the key packages[1] (see "Final list of 3302 key 
 source
 packages" in that file).
>>>
>>> That actually seem to be 3247 source package.  Anyway, the list is
>>> below.
>>
>> So OpenSSL 1.1.0 was released about 3 weeks ago.  Since then we've
>> been working on the key packages, to get them to build with
>> OpenSSL 1.1.0.  You can see that status of that at:
>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans-keypkg;users=pkg-openssl-devel-requ...@lists.alioth.debian.org
>>
>> Most of the packages are really trivial to fix, but some do
>> require that you fix the same issues in many different places and
>> it can take some time to fix it.
>>
>> I would like to motivate more people to work on this by either
>> marking those bugs as RC, or uploading it to unstable.
> 
> Ping.

I'm sorry but I'm going to have to nack this for Stretch, as much as I like to
approve transitions and get new stuff in. I have looked at the opened bugs and
I'm afraid this still is too disruptive. I have noticed that you have forwarded
some of them and sent patches, and I appreciate that. We can do this early in
the Buster cycle, so let's look at the status of this and prepare for the
transition when Stretch gets released.

Cheers,
Emilio

Bug#841119: apt-listchanges: [INTL:nl] Dutch po file for the apt-listchanges package

[Frans Spiesschaert]

 

Package: apt-listchanges 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the updated Dutch po file for the apt-listchanges package. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
=== 
 

-- 
Cheers,
Frans

===
http://home.base.be/vt6362833/



nl.po.gz
Description: application/gzip


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

Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid

[Konstantin Khomoutov]

On Mon, 17 Oct 2016 20:15:04 +0200
Jan Mojzis <jan.moj...@gmail.com> wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Jan Mojzis <jan.moj...@gmail.com>
> 
> * Package name: extremetools
>   Version : 20161017
>   Upstream Author : Jan Mojžíš <jan.moj...@gmail.com>
> * URL : https://github.com/janmojzis/extremetools
> * License : public-domain
>   Programming Lang: C
>   Description : tools for running processes under extreme uid and
> gid
> 
> Extremetools consists of 2 simple tools extremesetuidgid and
> extremeenvuidgid.
>  - extremesetuidgid runs program under unique (extreme) uid and gid
>  - extremeenvuidgid runs program with environment variables indicating
>unique (extreme) uid and gid
> 
> This is useful for running processes in the system under unique
> (extreme) uids/gids. So processes can't ptrace each other, can't send
> signal each other, etc ...

Could you please elaborate on that "extreme" bit?
I failed to get even a basic explanation of it both from this
description and the project files on Github.

I understand that you may be not a native English speaker so you may
well be putting a meaning into that word which is (slightly) different
from the conventional perception of what it should be. ;-)

Bug#836154: sbuild --no-arch-any --no-arch-all --source fails on all only dsc

[Sam Hartman]

I want consistency between the case where there is a binary build and
the case where there is a source build.
I want --source because I want the source package to be included in the
.changes.
I want to use one tool, (sbuildh) rather than having my scripts care
about how it is being called.

Bug#841116: aptitude: [INTL:nl] Dutch po file for the aptitude package

[Frans Spiesschaert]

 

Package: aptitude 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the updated Dutch po file for the aptitude package. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
=== 
 

-- 
Cheers,
Frans

===
http://home.base.be/vt6362833/



nl.po.gz
Description: application/gzip


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