Bug#851546: [Debichem-devel] Bug#851546: [libint2-dev] Please install a pkgconfig metadata file

[Michael Banck]

tags 851546 +pending
thanks

On Mon, Jan 16, 2017 at 01:55:32PM +0900, Katsuhiko Nishimra wrote:
> Could you include a pkg-config metadata file
> in this package to make builds convinient?
> 
> I'm attaching a tiny patch for this.

Thanks for the patch, I've applied it in svn and it will be included in
the next upload.


Michael

Bug#851539: Stretch RC1 netinst installer prompts for additional CDs

[Josh Triplett]

On Mon, Jan 16, 2017 at 01:13:13AM +, Steve McIntyre wrote:
> On Sun, Jan 15, 2017 at 04:53:26PM -0800, Josh Triplett wrote:
> >Package: installation-reports
> >Severity: normal
> >
> >I tried doing an install with a Stretch RC1 netinst CD.  Worked fine,
> >except that later in the install, right before asking about an apt
> >mirror, the installer asked about scaning additional CDs.  Previous
> >versions of the netinst installer haven't asked that question; normally
> >only the full-CD installers ask that.
> 
> This is a deliberate change, yes. It makes the firmware netinsts more
> useful now, for example...

I thought that firmware had a separate prompting mechanism, triggered by
the detection of missing firmware?  If the installer notices missing
firmware, it prompts for separate firmware media.

- Josh Triplett

Bug#846616: Re[2]: Bug#846616: Subj

[Sylvestre Ledru]

Le 16/01/2017 à 00:00, Askar Safin a écrit :
>> For 4.0, it is in NEW:
>> https://ftp-master.debian.org/new/llvm-toolchain-snapshot_1:4.0~svn291432-1.html
> Where can I download it?
http://apt.llvm.org/
they are the same packages
>  And why it is still not in sid? 
They need manual approval from the ftp team.
I added the support of lld, bringing a new package

S

Bug#832602: libxml2: diff for NMU version 2.9.4+dfsg1-2.2

[Aron Xu]

On Sat, Jan 14, 2017 at 10:50 PM, Mònica Ramírez Arceda
 wrote:
> Control: tags 832602 + patch
> Control: tags 832602 + pending
> Control: tags 832864 + patch
> Control: tags 832864 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for libxml2 (versioned as 2.9.4+dfsg1-2.2) and
> uploaded it to DELAYED/7. Please feel free to tell me if I
> should delay it longer.
>
> It would be great if you upload new version of libxml instead of this NMU,
> since this patch is already included.
>
> Regards.


Thanks for the help, please reschedule to 0 day, ;-)

Cheers,
Aron

Bug#851305: onboard doesn't show any information in mate-session-properties

[Mike Gabriel]

Hi shirish,

On  So 15 Jan 2017 20:01:32 CET, shirish शिरीष wrote:


In-line :-

On 15/01/2017, Mike Gabriel  wrote:

Hi shirish,



Hi Mike,


Please take some time and propose a patch please. Thanks!


I am no coder but I am open to doing that but need to know how to go
about doing that ?

I tried few things -

a. git clone https://anonscm.debian.org/git/pkg-mate/onboard.git

It gave me all debian-specific bits but nothing about onboard itself.

b. apt-get source onboard

I was able to get onboard-1.3.0  onboard_1.3.0-1.debian.tar.xz
onboard_1.3.0-1.dsc  onboard_1.3.0.orig.tar.gz

and was able to see where onboard-autostart.desktop is -

┌─[shirish@debian] - [~/onboard-debian/onboard-1.3.0/data] - [10148]
└─[$] ls

layoutstrings.py   onboard.desktop.in
org.onboard.gschema.xml

onboard-autostart.desktop  onboard-settings.desktop.in
org.onboard.Onboard.service

I have no idea whether it's just a case of simply flipping from
NoDisplay=true to NoDisplay=false in onboard-autostart.desktop or
would need more.

I did check https://github.com/mate-desktop to see if there was a
separate onboard repository mirroed there but there isn't/wasn't.

The only commands I know are -

git clone $something
cd $something
leafpad $something/$somefile
git commit $somefile
git format-patch -1

But have no idea how do I proceed further.

Any ideas anybody ?


Mike


The problem is that onboard-autostart.desktop (in /etc/xdg/autostart)  
does not have a (i18ned) Comment= key. The lack of it needs to be  
reported to onboard upstream.


Neither does /usr/share/applications/onboard.desktop have a Comment=  
field. This should also be added.


Please do the following things:

  o report the bug upstream
  o link this Debian bug to the upstream bug once it has been reported

Then we wait for the next upstream release and cherry-pick the  
.desktop files and try to upload for Debian 9.


Onboard upstream is here:
https://launchpad.net/onboard

For reporting bugs on Launchpad, you need need an account there IIRC.

Greets,
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpEJnmJSwsGF.pgp
Description: Digitale PGP-Signatur

Bug#561660: sleepd: Only one battery is checked with --battery

[Thomas Arendsen Hein]

* martin f krafft  [20170116 04:09]:
> I think it'd be best to compare against the average of the load
> level of all available batteries.

Sounds good enough.

One could argue that only the battery with the highest level should
be checked, but this might assume certain features in the hardware
that can't be guaranteed, so above will be safe.

If you change something here, I will no longer be able to easily
test it, because I no longer have an external battery for my laptop.

Regards,
Thomas

-- 
tho...@intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


pgpPu3_SkSCgR.pgp
Description: PGP signature

Bug#851102: unblock: petsc/3.7.5+dfsg1-2

[Drew Parsons]

Drew Parsons wrote:
> Please unblock package petsc
> 
> Upstream has just released patch version 3.7.5, fixing various bugs.
...
> 3.7.5+dfsg1-1 is already uploaded to experimental, ready to be
> dropped into unstable as petsc/3.7.5+dfsg1-2 with your agreement.
> 
> It would be a good service for the users of stretch if they had
> access
> to the bug fixes provided in this release.
> 
> unblock petsc/3.7.5+dfsg1-2

petsc 3.7.4+dfsg1-9 is now migrated to testing (fixing RC bug #850599
in stretch).  That clears the way for updating petsc to 3.7.5 for the
stretch release. 

I'll upload petsc 3.7.5+dfsg1-2 to unstable in the coming 24 hours once
the migration of 3.7.4+dfsg1-9 to testing has been pushed to servers.

Thanks,
Drew

Bug#851553: unblock: jabberd2/2.4.0-3

[Simon Josefsson]

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

Please consider unblocking jabberd2.

It fell out of testing in November due to an OpenSSL 1.1
incompatibility which caused a FTBFS.  The package in unstable that was
uploaded late December changed Build-Depends to resolve that bug, and
also fixed the default-libmysqlclient-dev concern.  The bug report
and entire patch that was applied is found here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828360#33

The changelog entry is:

jabberd2 (2.4.0-3) unstable; urgency=medium

  * Build-Depends on default-libmysqlclient-dev. Closes: #845857.
  * Build-Depends on libssl1.0-dev|libssl-dev until
jabberd2 builds with OpenSSL 1.1.  Closes: #828360.

 -- Simon Josefsson   Tue, 27 Dec 2016 11:06:52 +0100

Below is a debdiff output between 2.4.0-2 (that was in testing) and
2.4.0-3 (which is in unstable since late December).

unblock jabberd2/2.4.0-3

Thanks,
/Simon



jas@latte:~/src$ debdiff jabberd2_2.4.0-2_amd64.changes 
jabberd2_2.4.0-3_amd64.changes
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .changes but not in first
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/01/1c851143cbc59927438ca429356f4f8ff283bf.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/03/348f41420c94b2f6547a2c432a9a72576ad056.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/03/8cc2732d77cf9f942477a83b5e6926242cd7f2.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/0b/c8f8f502d00e91b6ea0d7ccf944bb1203180fa.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/0e/98c14e16ccd6b60fa76e12211f99727d495bca.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/13/f69db7535a9701c43ece7bfc60601cc92facdc.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/19/7598de9178f70c985cf38da0940c401c1edf3d.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/1a/d233f1efb87f565424c3ef91599f55bc78dfab.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/20/4836c2f55a9255399c8518f8e38020445f1c9f.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/22/f1d617952b6b0a5f9efad4a4718ed83b309c54.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/2d/cfaeea2d56cec7e15984d5e7882167f4e16a4b.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/2d/d7cc342bc13fc007e6f2ec1bf0de0dd77ebc2a.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/3a/db4421d15ab569f84b6b7992a7e2a9cb17659e.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/3c/f0507b963ffe26cd1f63324023c8f4b7be39fd.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/46/4bd4490e03e1308f0b15b47ce012a7385f1ef6.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/4a/864877850dd1aa326c34d74362805e007be5eb.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/57/57ef9c0a9a84ff2b85654bc1088f2f2cbd1866.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/57/ff726c1ea74150fee6ebd18c43f1644a9c4f6e.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/59/2cddf685686dcee5fba8ac1398b45fe7138dc2.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/5f/3aa7afc98e5d12d2437ba063667e28b33f7b15.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/69/ea7e0cf3605759f6d610abb7e47cedf74f5c09.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/6d/7292d9f23976ee6d6bd7678eab46d09d1fd871.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/89/006bb189c2bacf1069d96a875bc401023618fa.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/89/47fa0389c2160872d01cd7f61973f3637e59a0.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/8f/04c46bd7a6d55ebf5efbe84774d037a57f7ac9.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/91/b71f4a2197b48905d6e28949febbb8222e306f.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/97/810216dc3699c110de3d4147c6774f2a79a6d7.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/99/26e527f7e8be8d19f5535bf64d98b421b5fef8.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/a4/1ee8d286672b7f1c2a5d5a2b43029f86477af6.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/a4/c0198701db39f193c00338d93d962dee8b6f03.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/a5/8cf609d73396150da3fb18c2edf6649d83f691.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/a8/2a6821d8800f7beec736e377202e2cccf62f57.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/ad/fea286bfc9150b7d93a6469ca019707dc8dbd4.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/b6/01afdf6d822e9b74b5183180bd9c57e87ba1e5.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/c5/74e1ea9f63bee7580adba388ca67d4dd1f969c.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/c8/f87909f10bb643cd0879b172f481c6a070d289.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/ca/882d5f215bdbfd2292cb22644976fd9da467e5.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/cd/fb7140d65f6e0b31994ed2660f44487f9e86f5.debug
-

Bug#851552: cowsay-off: Replaces and Breaks must be updated to 3.03+dfsg2-1 was 3.03+dfsg1-13

[Christian Marillat]

Package: cowsay-off
Version: 3.03+dfsg2-2
Severity: normal

Dear Maintainer,

As you have moved files ( bong.cow and beavis.zen.cow) from cowsay to
cowsay-off you must update the Replaces and Breaks fileds to 3.03+dfsg2-1

Christian

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

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

Versions of packages cowsay-off depends on:
ii  cowsay  3.03+dfsg2-2

cowsay-off recommends no packages.

cowsay-off suggests no packages.

-- no debconf information

Bug#851551: FutureWarning: CTR mode needs counter parameter, not IV

[Antonis Christofides]

Package: duplicity
Version: 0.6.24-1
Severity: normal

Hello,

I'm not certain this problem is in duplicity or in python-crypto. Since
yesterday's update to Debian 8.7, all my servers (including the one from which
I'm reporting this) throw this message when running duplicity with -v2:

/usr/lib/python2.7/dist-packages/Crypto/Cipher/blockalgo.py:141: FutureWarning: 
CTR mode needs counter parameter, not IV
  self._cipher = factory.new(key, *args, **kwargs)

I use public key encryption with --encrypt-key=.

I have this python-crypto:

ii  python-crypto  2.6.1-5+deb8

This is more than a mere annoyance. If I receive emails every day I will stop
reading them, so I will miss important messages. This is clearly not an option.
Otherwise I might increase verbosity to error, in which case I'm worried about
missing any important warning messages. So if there is any other idea for a
workaround I'm all ears.

Thanks!

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

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

Versions of packages duplicity depends on:
ii  libc62.19-18+deb8u7
ii  librsync10.9.7-10
ii  python   2.7.9-1
ii  python-lockfile  1:0.8-2

Versions of packages duplicity recommends:
ii  python-oauthlib  0.6.3-1
pn  python-paramiko  
ii  python-urllib3   1.9.1-3
ii  rsync3.1.1-3

Versions of packages duplicity suggests:
pn  lftp
pn  ncftp   
pn  python-boto 
pn  python-cloudfiles   
pn  python-gdata
pn  python-swiftclient  
pn  tahoe-lafs  

-- no debconf information

Bug#851243: libpam-systemd: pam_systemd does not catch supplementary groups from pam_group

[Juha Erkkilä]

2017-01-13 18:10 GMT+02:00 Michael Biebl :
>
> gnome-terminal uses a systemd --user service which uses
> /etc/pam.d/systemd-user
> As you can see, this pam module does not include common-auth.
> If you add pam_group to /etc/pam.d/systemd-user I suspect it would work.


Thank you for your suggestion!  However, I thought this as well and I tried
it,
but this did not work for me. Here is my /etc/pam.d/systemd-user:

---
# This file is part of systemd.
#
# Used by systemd --user instances.

auth optional pam_group.so

@include common-account

session  required pam_selinux.so close
session  required pam_selinux.so nottys open
session  required pam_loginuid.so
session  required pam_limits.so
@include common-session-noninteractive
session optional pam_systemd.so
---

Using "auth" here because pam_group(8) says "Only the auth module type is
provided".
Probably this service does not do any authentication, though?

Juha

Bug#851423: closed by Jörg Frings-Fürst (reply to deb...@jff-webhosting.net) (Re: Bug#851423: remmina: Out of memory error. Only user programs running were desktop, remmina

[Jörg Frings-Fürst]

Hello Ducan,


Am Sonntag, den 15.01.2017, 17:39 + schrieb d...@synoia.com:
> Remmina was the only active app. Do you have a memory leak?
>  

No, the memory used by remmina is in approximately the same as here. 

I think that known bug since some years from the chromium browser[1]. 

> Duncan Hare
> 
> 714 931 7952
> [...]
> 

CU 
Jörg


[1] https://bugs.chromium.org/p/chromium/issues/detail?id=393395

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#849995: [Qa-jenkins-dev] Bug#849995: [j.d.n] Store coverage report of diffoscope builds

[Mattia Rizzolo]

On Mon, Jan 16, 2017 at 03:29:59AM +, Chris Lamb wrote:
> I believe this is possible with a Jenkins plugin that will annotate
> the files and even graph stuff over time.

Yes, this is possible and easy (we already have the plot plugin
installed for an eventual graphin of something, even if I believe
storing the .html files of the report is already a good start).

> One alternative and/or temporary hack would be to *not* delete the
> coverage files if we see the JENKINS_URL environment variable.

Something similar is needed anyway.  Remember that currently what
jenkins is building is the debian package; I think need to tweak the
packaging to copy the coverage files to WORKSPACE (or where were the
artifacts placed…?).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#829180: possible root cause identified

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 16/01/17 07:05, Michael Biebl wrote:
> Am 14.01.2017 um 15:49 schrieb Daniel Pocock:
> 
>> I've removed the file 99-btrfs.rules now and put the system in a
>> reboot loop for about 45 minutes, it rebooted about 18 times
>> without the mounts failing any more.
> 
> Glad you figured it out. I'm closing this bug report, see below.
> 
>> Therefore, I feel it is likely this udev file, combined with
>> systemd attempting mounts much earlier, was the reason the mounts
>> were intermittently failing.
>> 
>> While I understand that systemd may not be able to identify
>> every specific irregularity like this, some ideas for improvement
>> come to mind:
>> 
>> - when systemd finds the udev file (99-btrfs.rules was mentioned 
>> in the journalctl output), could it be more conservative by
>> default and delay trying to mount any devices that are associated
>> with udev rules like this?
>> 
> 
> I don't think it's systemd's business to clean up such a btrfs
> rules file. This should be done by the admin who created the file.
> After all, how are we supposed to decide whether the file is buggy
> or actually needed. Even then, a better package to handle such a
> clean up would be btrfs-tools.
> 


The file itself was not buggy.  The combination of that file+SysVinit
was a working environment.  The combination of that file+systemd was
an unstable environment.

It wouldn't be fair to expect systemd to know about every individual
case like this.

However, if systemd does know that a udev rule exists for a particular
device, whether it is this file or any other file that somebody has
created by hand, wouldn't it be reasonable to delay that mount?

I tested running "btrfs device scan" at the command line and the
command appears to complete synchronously.  If the command had started
a background operation then it would be harder for systemd to know the
device was not ready to mount.

Regards,

Daniel
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYfGjJAAoJEGxlgOd711bES1gQAIeUD3Ot4l5MuODPc/gHxDwM
ncXGxyBdjaNI7pJnaVO63A2HC5rxYSkEZ1qKZFYr7joNqpJOcZY9irzfMaB9kZ2l
4mSyBL/qEeSftK5F98mOG8lLT+a/KBTLMnAxiejAo3ddhsW5oy164a2DFKYooljs
hgTGbwkymSUGurftC2Ev6v7pzN3LgKuyDblVV1sH8k0ifOw49rRd8LLOt+KUgMq+
/1EE+gd42ASl82i+X3WznRPTKIXw6EUqSChgtSjg4OEBpf6yT4SSRgpPEWNv8xnv
O+G5N263RVLjdU6HXslAMn53eUrBQTFohPPrEiFoFlG8mPjQUb70iC547Trtqfml
cp1PWNzcntd5Viz56kPXiULygt4iNvgxHtx7pDB49Ucw3ZAXwOA2PoiiSRebg/ND
qCL4ZHps8DEnQRl6agKddAOuGAF1edUgemy6s4kLyWo02BJfkX4oDX+rtYrKsX7p
9JliSW+2MRE1TBi0FHHqcvWyp0iJlWNDjSpL/wsQ6gKssJJExBAIlHYHIU+pedkH
t22h30NMkrCR1HjuV0jiC3KPzp86vO8MAWKcFTF9E6yAQgGt2tu/N7wkb+xBFqf1
yYcP8mR7EKhqkiUxBWUXkq4jrgSUOtNzVKiKW7elGbMuUxJyVqnuFOzvZnyM/bzJ
0mMfEWFfaZWJel43Zk20
=1W+t
-END PGP SIGNATURE-

Bug#851170: libqt5webengine5: h.264 video does not seem to work

[Robert Cross]

Awesome, I can't wait to try it!

On 01/15, Sandro Knauß wrote:
> Control: tags -1 +pending
> Hey,
> 
> I also had a look and came to same comclusion than you, that  
> use_proprietary_codecs only activates the interface. I gave it alsoready a 
> try 
> on amd64 and it built successfully. I will activate it with the next upload.
> 
> Best Regards,
> 
> sandro
> 
> 
> --
> Am Donnerstag, 12. Januar 2017, 17:56:32 CET schrieb Robert Cross:
> > (sorry for the double mail Sandro, I am very bad at email!!!)
> > 
> > I'm trying to figure out what exactly use_system_ffmpeg and
> > use_proprietary_codecs does.
> > 
> > It seems to me that use_system_ffmpeg will do exactly as it sounds and will
> > use system libav* libraries.
> > 
> > I went and downloaded webengine 5.7 source:
> > git clone https://code.qt.io/qt/qtwebengine.git -b 5.7
> > 
> > and did some digging in there.
> > 
> > In src/core/renderer/content_renderer_client_qt.cpp I found:
> > 
> > #if defined(USE_PROPRIETARY_CODECS)
> > info.supported_init_data_types |= media::kInitDataTypeMaskCenc;
> > info.supported_codecs |= media::EME_CODEC_MP4_ALL;
> > #endif  // defined(USE_PROPRIETARY_CODECS)
> > 
> > After some searching around, I found that media::EME_CODEC_MP4_ALL is
> > defined in chromium, see:
> > https://chromium.googlesource.com/chromium/src.git/+/lkcr/media/base/eme_con
> > stants.h
> > 
> > So it looks like to me with my non-expert eyes, that use_proprietary_codecs
> > is just setting the bits that the underlying browser engine reports that
> > certain codecs are available to use.
> > 
> > It seems that if you have use_proprietary_codecs and use_system_ffmpeg both
> > on, it will still delegate the video to the system libraries.
> > 
> > I could be wrong, these are just the results of some preliminary digging!
> > 
> > On 01/12, Sandro Knauß wrote:
> > > Hey,
> > > 
> > > > please be gentle as this is my first bug report :)
> > > 
> > > feel welcome! I hope your first experience with Debian bug reporting is a
> > > good one.
> > > 
> > > > I'm excited that Qt WebEngine is being packaged, so I could use it with
> > > > qutebrowser.
> > > 
> > > that is great and we need packages using QtWebEngine to get an idea if we
> > > packaged it correctly.
> > > 
> > > > It seems to work beautifully, except that H.264 video is not working.
> > > > I've talked to the developer of qutebrowser and he said that qtwebengine
> > > > might not be configured to use proprietary codecs (see:
> > > > http://doc.qt.io/qt-5/qtwebengine-features.html#audio-and-video-codecs )
> > > 
> > > We were in a rush to get QtWebEngine ready for Debian, so we couldn't
> > > evaluate all the potentials of QtWebEngine. But on Debian we can't simply
> > > include proprietary codecs, because that would mean, that QtWebEngine
> > > will move from main to non-free and all software using it would endup in
> > > contrib. And I think must use cases are not include sing proprietary
> > > codecs.
> > > 
> > > The solution would be, that we would able to use ffmpeg/libh264 from the
> > > system, if available, like other media player do this. And we actually
> > > push
> > > this information into the build. So in theory it should be picked up and
> > > use the system ffmpeg libs:
> > > qmake WEBENGINE_CONFIG+="use_system_ffmpeg=1"
> > > 
> > > Did you try to just install the necessary libs?
> > > 
> > > Under [0] you find the complete build script for Debian.
> > > 
> > > >I know that multimedia codecs can be very hairy things in general, but
> > > >I'm
> > > 
> > > hoping that since H.264 is enabled in chromium, that the same can be done
> > > for Qt WebEngine.
> > > 
> > > I hope so too, but the build of QtWebEngine is another layer on top of the
> > > complex build of the internal chromium.
> > > 
> > > Any help how to push QtWebEngine to use system h264 is very welcomed!
> > > 
> > > Best Regards,
> > > 
> > > sandro
> > > 
> > > [0] 
> > > https://anonscm.debian.org/git/pkg-kde/qt/qtwebengine.git/tree/debian/
> > > rules
> 

Bug#839633: alabaster: please make the output reproducible

[Chris Lamb]

Hi,

> Friendly ping on this

Sorry, wrong package; it is not yet merged upstream. Please ignore...


Regards,

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

Bug#851550: imagemagick: cache resources exhausted while trying to crop big tiff, -limit option does not fix it

[Luc Deschenaux]

Package: imagemagick
Version: 8:6.9.7.0+dfsg-2
Severity: important
Tags: upstream

Dear Maintainer,

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

   * What led up to the situation?

   Trying to crop a large tiff with:
 wget 
http://goes.gsfc.nasa.gov/goeseast/fulldisk/fullres/vis/1701061445G13I01.tif -O 
input.tif && convert -crop 3120x1920+7757+7017 input.tif out.png

   For example this tiff is:
 $ identify 1701061445G13I01.tif 
 1701061445G13I01.tif TIFF 14400x12001 14400x12001+0+0 8-bit
 Grayscale Gray 63.38MB 0.000u 0:00.000

   If the mentionned tif is not available anymore try another big one in
   the same directory.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 - I tried to raise limits with "-limit [ Disk File Map Memory ]
 [ unlimited 0 10G 10GB 10GiB ]"
 - I added sid sources in apt source.list.d and to replaced the
 "stretch" version 8:6.9.6 with the "unstable" one 

   * What was the outcome of this action?
 Convert still exit with:
   convert-im6.q16: DistributedPixelCache '127.0.0.1' @
   error/distribute-cache.c/ConnectPixelCacheServer/244.
   convert-im6.q16: cache resources exhausted
   `/home/guest/.x3arth/goeseast/fulldisk/fullres/vis/1701061445G13I01.tif'
   @ error/cache.c/OpenPixelCache/3945.

   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
compare:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
convert:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
composite:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
conjure:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
display:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
identify:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
import:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
mogrify:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
montage:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
stream:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org

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

Kernel: Linux 4.8.0-2-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 imagemagick depends on:
ii  imagemagick-6.q16  8:6.9.7.0+dfsg-2

imagemagick recommends no packages.

imagemagick suggests no packages.

-- no debconf information

Bug#846095: Status of package 'ruby-useragent'

[Pirate Praveen]

> Note:  Debian already froze, so I guess NEW packages will not migrate to 
> testing.

We can upload it to experimental right now and reupload to
unstable after stretch release. Once it migrates to next testing
(buster), we can upload it to stretch-backports.

Bug#840155: xotcl: please make the build reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#834017: valknut: please make the build reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#835807: pygtksourceview: please make the build reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#834549: botan1.10: please make the build reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#777488: pyntor: please make the build reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#836004: python-gflags: please make the build reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#777365: ucspi-proxy: please make the build reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#835816: rt-extension-customfieldsonupdate: please make the build (mostly) reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#778971: plib-doc: please make the build reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#831742: wordgrinder: please make the build reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#839633: alabaster: please make the output reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#779595: plastex: please make the build reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#809152: glib2.0: please make the output of glib-mkenums Makefile snippets reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#776369: vimoutliner: please make the build reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#804249: python-setuptools: please make the generated requires.txt files reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#789804: libevocosm: please make the build reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#777505: psgml: please make the build reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#776973: integrit: please make the build reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#776399: dict-bouvier: please make the build reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#777726: joe: please make the build reproducible

[Chris Lamb]

> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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

Bug#851549: [Pkg-utopia-maintainers] Bug#851549: dbus: Segmentation fault in dbus.postinst on mips64el

[Michael Biebl]

Control: reassign -1 src:systemd
Control: forcemerge 851412 -1
Control: affects 851412 + dbus

Am 16.01.2017 um 06:58 schrieb Boyuan Yang:
> Package: dbus
> Version: 1.10.14-1
> Severity: grave
> Justification: renders package unusable
> 
> Current package on mips64el won't install. Segmentation fault will occur in
> postinst script.
> 
> I don't have a mips64el box so cannot reproduce it, but examples are *all
> around* official buildd.
> 

The bug is ttbomk in binutils, which creates a broken libsystemd0 on
mips*. Merging with existing bug report.
It's currently assigned to systemd but will eventually be re-assigned to
binutils once we have confirmation from the mips porters.

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



signature.asc
Description: OpenPGP digital signature

Bug#850648: Missing source of manual-031.pdf

[Doug Torrance]

Hi Andreas,

On 01/09/2017 06:26 AM, Andreas Tille wrote:

to my understanding manual-031.pdf will be considered as "binary without
source" and thus rejected by ftpmaster.  The best way to solve this
would be to ask upstream for the source files - the second best using
Files-Excluded to remove the PDF from the source tarball.


A new upstream version was just released which includes the manual source!

(Ironically, they decided to add another manual for an old Mathematica 
script *without* source.  Since it's not as important, I added this new 
one to Files-Excluded.)


I've packaged this latest version and it has been pushed git for review.

Thanks!
Doug

Bug#809152: glib2.0: please make the output of glib-mkenums Makefile snippets reproducible

[Chris Lamb]

Hiey,

> glib2.0: please make the output of glib-mkenums Makefile
> snippets reproducible

This seems to have stalled upstream; do we know anyone with
clout/interest who could "push" things there...? :)


Regards,

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

Bug#835805: dh-python: please make builds reproducible with "mismatched" kernel and userland

[Chris Lamb]

Hey

> Whilst working on the Reproducible Builds effort [0], I noticed
> that some packages on i386 are not reproducible as they embed
> debugging symbols that vary depending on whether a 32 or 64-bit
> kernel is being used.

Friendly ping on this? :)


Regards,

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

Bug#851549: dbus: Segmentation fault in dbus.postinst on mips64el

[Boyuan Yang]

Package: dbus
Version: 1.10.14-1
Severity: grave
Justification: renders package unusable

Current package on mips64el won't install. Segmentation fault will occur in
postinst script.

I don't have a mips64el box so cannot reproduce it, but examples are *all
around* official buildd.

This bug is preventing many packages from building and migrating to testing.

Examples: [1] [2]

[1] https://buildd.debian.org/status/fetch.php?pkg=kwallet-
kf5&arch=mips64el&ver=5.28.0-3&stamp=1484543446
[2]
https://buildd.debian.org/status/fetch.php?pkg=xfce4-terminal&ver=0.8.3-1&arch=mips64el&stamp=1484543729



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

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

Versions of packages dbus depends on:
ii  adduser  3.115
ii  init-system-helpers  1.46
ii  libapparmor1 2.11.0-1
ii  libaudit11:2.6.7-1
ii  libc62.24-8
ii  libcap-ng0   0.7.7-3
ii  libdbus-1-3  1.10.14-1
ii  libexpat12.2.0-2
ii  libselinux1  2.6-3
ii  libsystemd0  232-10
ii  lsb-base 9.20161125

dbus recommends no packages.

Versions of packages dbus suggests:
ii  dbus-user-session [default-dbus-session-bus]  1.10.14-1
ii  dbus-x11 [dbus-session-bus]   1.10.14-1

Versions of packages dbus is related to:
ii  dbus-x11  1.10.14-1
ii  systemd   232-10
ii  systemd-sysv  232-10

-- no debconf information

Bug#851548: error when installing Paje and Vite in the ubuntu subsystem in win10

[yao hu]

Package: Paje and Vite

I was trying to install visualization for simgrid. There was no problem
with Viva, but when I tried (on several machines) to install Paje or Vite
by *sudo apt-get install,* the error messages were as follows.
It seems something wrong with  gnustep-back-XXX thing, how should I do
then? Any help is appreciated!

I am using ubuntu subsystem in win10.

*--*
sudo apt-get install paje.app

*..*
Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
Processing triggers for fontconfig (2.11.0-0ubuntu4.2) ...
Processing triggers for ureadahead (0.100.0-16) ...
Processing triggers for mime-support (3.54ubuntu1.1) ...
Setting up imagemagick-common (8:6.7.7.10-6ubuntu3.3) ...
Setting up libao-common (1.1.0-2ubuntu2) ...
Setting up libao4:amd64 (1.1.0-2ubuntu2) ...
Setting up libart-2.0-2:amd64 (2.3.21-2) ...
Setting up libasound2-data (1.0.27.2-3ubuntu7) ...
Setting up libasound2:amd64 (1.0.27.2-3ubuntu7) ...
Setting up libcupsfilters1:amd64 (1.0.52-0ubuntu1.7) ...
Setting up libcupsimage2:amd64 (1.7.2-0ubuntu1.7) ...
Setting up libfftw3-double3:amd64 (3.3.3-7ubuntu3) ...
Setting up libogg0:amd64 (1.3.1-1ubuntu1) ...
Setting up libflac8:amd64 (1.3.0-2ubuntu0.14.04.1) ...
Setting up libgif4:amd64 (4.1.6-11) ...
Setting up liblcms2-2:amd64 (2.5-0ubuntu4.1) ...
Setting up liblqr-1-0:amd64 (0.4.1-2ubuntu1) ...
Setting up libmagickcore5:amd64 (8:6.7.7.10-6ubuntu3.3) ...
Setting up libobjc4:amd64 (4.8.4-2ubuntu1~14.04.3) ...
Setting up libpaper1:amd64 (1.1.24+nmu2ubuntu3) ...

Creating config file /etc/papersize with new version
Setting up libvorbis0a:amd64 (1.3.2-1.3ubuntu1) ...
Setting up libvorbisenc2:amd64 (1.3.2-1.3ubuntu1) ...
Setting up libsndfile1:amd64 (1.0.25-7ubuntu2.1) ...
Setting up libxmu6:amd64 (2:1.1.1-1) ...
Setting up poppler-data (0.4.6-4) ...
Setting up libflite1:amd64 (1.4-release-8ubuntu0.1) ...
Setting up libaspell15 (0.60.7~20110707-1ubuntu1) ...
Setting up dictionaries-common (1.20.5) ...
Setting up fonts-freefont-ttf (20120503-4) ...
Setting up libijs-0.35 (0.35-8build1) ...
Setting up libjbig2dec0 (0.11+20120125-1ubuntu1) ...
Setting up libgs9-common (9.10~dfsg-0ubuntu10.6) ...
update-alternatives: using /usr/share/ghostscript/9.10 to provide
/usr/share/ghostscript/current (ghostscript-current) in auto mode
Setting up libgs9 (9.10~dfsg-0ubuntu10.6) ...
Setting up gsfonts (1:8.11+urwcyr1.0.7~pre44-4.2ubuntu1) ...
Setting up ghostscript (9.10~dfsg-0ubuntu10.6) ...
Setting up gnustep-common (2.6.2-2.1ubuntu1) ...
Setting up gnustep-base-common (1.24.0-1ubuntu3) ...
Setting up libgnustep-base1.24 (1.24.0-1ubuntu3) ...
Setting up gnustep-base-runtime (1.24.0-1ubuntu3) ...
hostname: Name or service not known
initctl: Unable to connect to Upstart: Failed to connect to socket
/com/ubuntu/upstart: Connection refused
runlevel:/var/run/utmp: No such file or directory
invoke-rc.d: policy-rc.d denied execution of start.
Setting up gnustep-gui-common (0.22.0-1ubuntu2) ...
Setting up libpaper-utils (1.1.24+nmu2ubuntu3) ...
Processing triggers for ureadahead (0.100.0-16) ...
Setting up mknfonts.tool (0.5-11build3) ...
Setting up gnustep-back-common (0.22.0-1ubuntu1) ...
Generating GNUstep nfont descriptions...mv: cannot move ‘Century Schoolbook
L.nfont/’ to ‘CenturySchoolbookL.nfont/’: No such file or directory
dpkg: error processing package gnustep-back-common (--configure):
 subprocess installed post-installation script returned error exit status 1
dmesg: klogctl failed: Function not implemented
   Setting up
libgnustep-gui0.22 (0.22.0-1ubuntu2) ...
Setting up gnustep-gui-runtime (0.22.0-1ubuntu2) ...
dpkg: dependency problems prevent configuration of gnustep-back0.22-art:
 gnustep-back0.22-art depends on gnustep-back-common (>= 0.22); however:
  Package gnustep-back-common is not configured yet.

dpkg: error processing package gnustep-back0.22-art (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of gnustep-back0.22:
 gnustep-back0.22 depends on gnustep-back0.22-art | gnustep-back0.22-alt;
however:
  Package gnustep-back0.22-art is not configured yet.
  Package gnustep-back0.22-alt is not installed.
  Package gnustep-back0.22-art which provides gnustep-back0.22-alt is not
configured yet.
dpkg: error processing package gnustep-back0.22 (--configure):
 dependency problems - leaving unconfigured
Setting up gnustep-gpbs (0.22.0-1ubuntu1) ...
No apport report written because the error message indicates its a followup
error from a previous failure.
 No apport report written because the error message
indicates its a followup error from a previous failure.
  dpkg: dependency problems prevent
configuration of paje.app:
 paje.app depends on gnustep-back0.22 (>= 0.22.0); however:
  Package gnustep-back0.22 is not configured yet.

dpkg: error processing package paje.app (--configure):
 

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Nicholas D Steeves]

Dear Sean,

Thank you again for your patience and extra help!

On Sun, Jan 15, 2017 at 05:51:09PM -0700, Sean Whitton wrote:
> > Ah!  Yes, this is the spec that addresses my question to #3.  That
> > said, in the past some of my other work on d/copyright has been said
> > to be "worse than useless" even though it adhered to the spec, and
> > even though it seemed to reflect what I saw reading the packages
> > COPYING file, in addition to spending a while reading VCS commits for
> > stuff I wasn't sure about.  This has led me to wonder about the tribal
> > rules that are not in the spec...
> 
> Could you give me an example of a rule like that?

It'll take time to dig up examples from my backups, so I'll need to
defer concrete examples until something like mid February.  It might
be stuff like my failure to identify a package that is following DEP-5
vs SPDX, but because of comments like "worst than useless" I figured
there must have been some rule I didn't understand...because that's
way too strong of a reaction for something that is a question of
style. :-)  At this point, however, I don't think further discussion
fits into this thread, because it is too tangential to muse-el.

By the way, is one space indentation for copyright definition blocks
what should now be used (commit
5ba94789a7f35d5938d88226c6ea35fd98635a5b)?  I noticed the packaging
guide's example uses one space, but most of the copyright-format/1.0
packages I've looked at use four.  Just a convention?

> > Would you please check to see if my latest commit to d/copyright is
> > ok?  It's what makes the most sense to me.  As far as I can tell, it
> > might be problematic because it infers that Eric Marsden changed
> > cgi.el in 2003.  If it's problematic I'll revert it, then dch -r.
> 
> No, it doesn't actually imply that Marsden changed that file in 2004
> (the spec does explain this!).

Ah, from packaging-manuals/copyright-format/1.0 "Not all copyright
notices may apply to every individual file, and years of publication
for one copyright holder may be gathered together" [1].  So short form
rules I misunderstood are:

* Wildcards are hungry globs.
* Lists of files are white-space, tab, or newline separated strings.
* Years may be specified as either a comma-separated list of discrete
  years, or a year-to-year range.
* Refer to individual files or VCS for specific dates when multiple
  files are grouped, because [1].

I also wonder how many contributors there must be to justify a
"Primary copyright holder, and others" statement, and also if one
needs to do VCS archaeology to find and list all of the potential
one-off contributors.

> Go ahead and `dch -r`!

Done, finally! :-D

Cheers,
Nicholas


signature.asc
Description: Digital signature

Bug#851508: Russian translation for apt-listbugs/ru.po

[Sergey Alyoshin]

On Mon, Jan 16, 2017 at 1:20 AM, Francesco Poli
 wrote:
> On Sun, 15 Jan 2017 22:22:18 +0300 Sergey Alyoshin wrote:
>
>> Package: apt-listbugs
>> Version: 0.1.22
>> Priority: wishlist
>> Tags: l10n
>
> Hello Sergey,
> thanks for sending me a new translation!
> I'll take a look at it very soon (hopefully).


Thanks for quick reply and you work.

Bug#851489: Updated Russian debconf translation

[Sergey Alyoshin]

On Sun, Jan 15, 2017 at 10:59 PM, LaMont Jones  wrote:
> On Sun, Jan 15, 2017 at 06:09:35PM +0300, Sergey Alyoshin wrote:
>> Package: postfix
>> Version: 3.1.3-6
>> Priority: wishlist
>> Tags: l10n patch
>
> This file is unchanged from one that landed in the source tree on the 9th..
> Was that intentional?

Yes, I just want a bug number for statistic at
https://www.debian.org/international/l10n/po-debconf/ru

Bug#851547: gnome-shell: under Wayland, alt-tab switcher fails when using focus-follow-mouse

[Sean Whitton]

Package: gnome-shell
Version: 3.22.2-1
Severity: normal

Dear maintainers,

Bug #648841 reoccurs when running GNOME under Wayland.  The problem does
not appear under X11.

Steps to reproduce:

1. Set window focus mode to 'mouse' or 'sloppy' (e.g. under "Windows" in
   gnome-tweak-tool)
2. Focus window X, and place mouse cursor within borders of window X
3. Use alt-tab to switch to window Y.

Expected result: Focus is switched to window Y.

Actual result: Focus switches to window Y momentarily, before returning to X.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.8.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  evolution-data-server3.22.3-1
ii  gir1.2-accountsservice-1.0   0.6.43-1
ii  gir1.2-atspi-2.0 2.22.0-5
ii  gir1.2-caribou-1.0   0.4.21-1
ii  gir1.2-freedesktop   1.50.0-1
ii  gir1.2-gcr-3 3.20.0-3
ii  gir1.2-gdesktopenums-3.0 3.22.0-1
ii  gir1.2-gdm-1.0   3.22.1-1
ii  gir1.2-glib-2.0  1.50.0-1
ii  gir1.2-gnomebluetooth-1.03.20.0-1
ii  gir1.2-gnomedesktop-3.0  3.22.2-1
ii  gir1.2-gtk-3.0   3.22.5-1
ii  gir1.2-gweather-3.0  3.20.4-1
ii  gir1.2-ibus-1.0  1.5.14-2
ii  gir1.2-mutter-3.03.22.2-2
ii  gir1.2-networkmanager-1.01.4.4-1
ii  gir1.2-nmgtk-1.0 1.4.2-1
ii  gir1.2-pango-1.0 1.40.3-3
ii  gir1.2-polkit-1.00.105-17
ii  gir1.2-soup-2.4  2.56.0-2
ii  gir1.2-telepathyglib-0.120.24.1-1.1
ii  gir1.2-telepathylogger-0.2   0.8.2-2
ii  gir1.2-upowerglib-1.00.99.4-4
ii  gjs  1.46.0-1+b1
ii  gnome-backgrounds3.22.1-1
ii  gnome-settings-daemon3.22.1-1
ii  gnome-shell-common   3.22.2-1
ii  gsettings-desktop-schemas3.22.0-1
ii  libatk-bridge2.0-0   2.22.0-1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-8
ii  libcairo21.14.8-1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libcroco30.6.11-2
ii  libdbus-glib-1-2 0.108-1
ii  libecal-1.2-19   3.22.3-1
ii  libedataserver-1.2-223.22.3-1
ii  libgcr-base-3-1  3.20.0-3
ii  libgdk-pixbuf2.0-0   2.36.2-1
ii  libgirepository-1.0-11.50.0-1
ii  libgjs0e [libgjs0-libmozjs-24-0] 1.46.0-1+b1
ii  libglib2.0-0 2.50.2-2
ii  libglib2.0-bin   2.50.2-2
ii  libgstreamer1.0-01.10.2-1
ii  libgtk-3-0   3.22.5-1
ii  libical2 2.0.0-0.5+b1
ii  libicu57 57.1-5
ii  libjson-glib-1.0-0   1.2.2-1
ii  libmozjs-24-024.2.0-5
ii  libmutter0i  3.22.2-2
ii  libnm-glib4  1.4.4-1
ii  libnm-util2  1.4.4-1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpolkit-agent-1-0  0.105-17
ii  libpolkit-gobject-1-00.105-17
ii  libpulse-mainloop-glib0  9.0-5
ii  libpulse09.0-5
ii  libsecret-1-00.18.5-2
ii  libstartup-notification0 0.12-4
ii  libsystemd0  232-8
ii  libtelepathy-glib0   0.24.1-1.1
ii  libwayland-client0   1.12.0-1
ii  libx11-6 2:1.6.3-1
ii  libxfixes3   1:5.0.3-1
ii  mutter   3.22.2-2
ii  python3  3.5.1-4
ii  telepathy-mission-control-5  1:5.16.3-2

Versions of packages gnome-shell recommends:
ii  gdm3  

Bug#848236: Remaining issue with gbrowse - any help (Was: Urgent call to BioPerl users (Was: Bug#848236: src:gbrowse: ...)

[Andreas Tille]

Hi Lincoln,

On Sun, Jan 15, 2017 at 04:25:46PM -0500, Lincoln Stein wrote:
> The bug in the memory adaptor that Scott found turns out to have been from
> using the old perl 1.6.9 installed by the Debian package. Updating to 1.7.1
> (1.007001) fixes the problem.
> 
> I have merged all GBrowse changes into git version 2.56 and have made a
> CPAN release. I think you can go ahead and package it.

thanks a lot for your work on this.

For the Debian packaging[1] I imported the new version and tried to
adapt the patches[2] (BTW, I have no idea whether any previous
maintainer of the package pointed to it but some of these might be
interesting to integrate into the upstream code).

Since I learned from Perl team (in CC) that I can exclude tests via

   debian/tests/pkg-perl/smoke-skip

I tried to use this feature.  Unfortunately this does not work as
expected - at least in the build process.  Could anybody with better
Perl skills than me please have a look at the failed build time tests?

Thanks to all who provided help so far to finally fix gbrowse for the
next Debian stable release

 Andreas.

[1] https://anonscm.debian.org/git/debian-med/gbrowse.git
[2] https://anonscm.debian.org/cgit/debian-med/gbrowse.git/tree/debian/patches

-- 
http://fam-tille.de

Bug#851546: [libint2-dev] Please install a pkgconfig metadata file

[Katsuhiko Nishimra]

Package: libint2-dev
Version: 2.1.0-3
Severity: wishlist
Tags: patch

Dear maintainer,

Could you include a pkg-config metadata file
in this package to make builds convinient?

I'm attaching a tiny patch for this.

Thanks in advance.
diff -Nru libint2-2.1.0/debian/changelog libint2-2.1.0/debian/changelog
--- libint2-2.1.0/debian/changelog	2016-10-08 21:04:55.0 +0900
+++ libint2-2.1.0/debian/changelog	2017-01-16 13:37:58.0 +0900
@@ -1,3 +1,10 @@
+libint2 (2.1.0-3+pkgconfig0) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install a pkgconfig metadata file.
+
+ -- Katsuhiko Nishimra   Mon, 16 Jan 2017 12:56:57 +0900
+
 libint2 (2.1.0-3) unstable; urgency=medium
 
   * debian/patches/revert_GaussianGmEvalScratch_changes.patch: New patch,
diff -Nru libint2-2.1.0/debian/libint2-dev.install libint2-2.1.0/debian/libint2-dev.install
--- libint2-2.1.0/debian/libint2-dev.install	2015-09-02 21:30:13.0 +0900
+++ libint2-2.1.0/debian/libint2-dev.install	2017-01-16 12:57:53.0 +0900
@@ -1,3 +1,4 @@
+usr/lib/pkgconfig/*.pc
 usr/lib/*.a
 usr/lib/*.so
 usr/include

Bug#851524: Building armhf image fwith qemu fails at bootstrapping stage if firmware section enabled

[Jason Heeris]

On 16 January 2017 at 14:35, Jason Heeris  wrote:
> On 16 January 2017 at 14:20, Michael .  wrote:
> > If you are building a Raspbian image your initial config should work
> I will try again and see if removing the firmware section makes a
difference with a Raspbian build.

Turns out removing the "firmware" section doesn't change the failure for a
Raspbian build, so... no idea. Building a Raspbian live image used to work
under 1:20151215, now it doesn't, and I can't narrow it down.

- Jason

Bug#851545: libpam-modules: multiarch packages with differing files

[Ove Kaaven]

Package: libpam-modules
Version: 1.1.8-3.1+deb8u2
Severity: important

Upon trying to upgrade to the latest Debian stable:

Preparing to unpack .../libpam-modules_1.1.8-3.1+deb8u2_i386.deb ...
Unpacking libpam-modules:i386 (1.1.8-3.1+deb8u2) over (1.1.8-3.1+deb8u1+b1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libpam-modules_1.1.8-3.1+deb8u2_i386.deb (--unpack):
 trying to overwrite shared '/usr/share/man/man8/pam_unix.8.gz', which is 
different from other instances of package libpam-modules:i386

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

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

Bug#817042: A4 size paper

[juxinpaper10]

Dear Sir,

 

Glad to see you.

 

Here recommand our paper product-copy paper.

 

Type： A3 A4, Letter size, legal size

Basic weight: 70GSM 75GSM 80GSM

Packing：500sheets per ream,5reams per carton

 

Please select the type you are most interested in and we will send the 
quotations.

Waiting for your kind response.

Regards，

Emma

 




 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 

Bug#851524: Building armhf image fwith qemu fails at bootstrapping stage if firmware section enabled

[Jason Heeris]

On 16 January 2017 at 14:20, Michael .  wrote:
> If you are building a Raspbian image your initial config should work

But that's the problem, it doesn't. See:
https://gist.github.com/detly/109b8201e7c81417af3a8f455f415a6d

I will try again and see if removing the firmware section makes a
difference with a Raspbian build.

- Jason

Bug#848097: terminal.app: Provides x-terminal-emulator, but doesn't implement the requirements

[Ben Longbons]

It's a violation of Policy, so the severity is mandated.

On Sat, Jan 14, 2017 at 9:42 AM, John Paul Adrian Glaubitz
 wrote:
> Control: severity -1 important
>
> Hi Ben!
>
>> Until (or unless) this is implemented, the `Provides:` header and the
>> update-alternatives logic must be removed.
>
> Do you really think that this justifies the severity 'serious' for this bug
> report? With this severity, the package will be removed from testing and
> therefore not be shipping with Debian Stretch.
>
> I don't think this issue justifies such a radical measure, I'll therefore
> downgrade this bug report to 'important'.
>
> Thanks,
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#849995: [j.d.n] Store coverage report of diffoscope builds

[Chris Lamb]

Hi,

> [j.d.n] Store coverage report of diffoscope builds

I believe this is possible with a Jenkins plugin that will annotate
the files and even graph stuff over time.

One alternative and/or temporary hack would be to *not* delete the
coverage files if we see the JENKINS_URL environment variable.


Regards,

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

Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping

[Gunnar Wolf]

Scott Kitterman dijo [Sun, Jan 15, 2017 at 04:34:40PM +]:
> >> "freebayes" seems like a very generic name for something specific to
> >such a 
> >> narrow field.  Maybe freebayes-genetic-variance or some such instead.
> >
> >I fully agree with your generic name consideration.  The software is
> >well known in this work field anyway so I'm hesitating a bit to rename
> >it.  Would you consider this a strong issue that needs to be discussed
> >with upstream or is it in a "not nice but acceptable" status?
> 
> I think it should be discussed with upstream, but we have broader
> namespace considerations that they may not understand or care about.
> 
> As long as a package search for freebayes returns this in the result
> set, I don't think it's critical to have the package name match
> exactly the upstream name.
> 
> Not wearing my FTP team hat for this, consider it as a comment from
> another DD.

As Scott is not "officially" speaking from the FTP team but just as a
DD, I'll chime in here.

I think the package name should indicate the field for which it is
meant (freebayes-genetic-variance), but I don't think the program name
should deviate from upstream; we have had issues such as when node.js
was introduced (that 'node' was a name already taken by another
program), but I don't think 'freebayes' will be such a contentious
program name.

Bug#851405: [moodle-packaging] Bug#851405: CVE-2016-9186 CVE-2016-9187 CVE-2016-9188

[Marina Glancy]

Hello Salvatore,
apologies for not replying earlier, I was away on holidays.

I was told by the CVE team that I have to use the online form to update
information about the issues. On 10 November 2016 I have sent a request to
update an existing CVE for the CVE-2016-9186. I have received an automated
reply "CVE Request 260788 for Update Published CVE". I don't see any
changes on the page
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9186 following my
request to update though. I was not aware of 9187 and 9188, I can request
update again but now I'm not even sure this form works.

I also use this form to notify about publishing CVE. For example, the last
issue I notified about was CVE-2016-8644 on the 21 November 2016 (
https://moodle.org/mod/forum/discuss.php?d=343277 ) but the page
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8644 still does not
display any information about the issue.

Please advise me what is the correct way to update information on CVEs
and/or notify about the publishing. Below is the email that I have received
from c...@mitre.org in the end of October in reply to my request to update
information about CVE 2016-7919.

Regards,
Marina Glancy

Marina,
>
>
>
> The new CVE web form can be used to submit this request as listed in the
> notification below. Select the “Request an update to an existing CVE”
> option.
>
>
>
> **IMPORTANT NOTIFICATION***
>
>
>
> Please use the “CVE Request” web form to request CVE IDs from MITRE,
>
> request an update to a CVE, provide notification about a
>
> vulnerability publication, or submit comments:
>
> https://cveform.mitre.org/
>
>
>
> Learn more at:
>
> https://cve.mitre.org/news/archives/2016/news.html#
> august292016_FOCUS_ON:_New_Method_to_Request_CVE_IDs_
> Updates_and_More_from_MITRE_in_Effect
>
>
>
> ***
>
>
> The CVE Team
>


[image: Moodle] 
Marina Glancy
Development Process Manager
e: mar...@moodle.com
p: +61 8 9467 4167 w: moodle.com 
[image: Facebook] 
[image: Twitter] 
[image: Google+] 

On Sun, Jan 15, 2017 at 6:14 PM, Salvatore Bonaccorso 
wrote:

> Hi Dan, hi Marina,
>
> On Sun, Jan 15, 2017 at 09:31:05AM +, Dan Poltawski wrote:
> > Hi,
> >
> > > > please see https://packetstormsecurity.com/files/139466/Moodle-CMS-3
> .
> > 1.2-Cross-Site-Scripting-File-Upload.html
> > > JFTR, regarding this one: I tried some weeks ago to contact Marina
> > > Glancy to get more information abouth those CVEs from upstream point
> > > of view, but got not reply unfortunately. Cc'ing for this bug as well
> >
> > (Upstream here with Marina) we have not reported on these 'security
> issues'
> > because do not believe any are security concerns. We replied to the
> > original reporter explaining this/asking for clarification, they
> published
> > them as 'exploits' despite this and (as far as i'm aware) didn't respond
> to
> > our requests for clarification. This puts us in a difficult situation.
> >
> > The s_additionalhtmlhead setting is controlled with our RISK_XSS flag,
> the
> > 'add these tags' issue only seems to providing XSS to the user themselves
> > (in the same way as a web inspector would do) and the others we do not
> > understand the exploit. If there is something we are missing we would
> > appreciate the bug created on https://tracker.moodle.org
> >
> > Note that new security releases (and CVE's) have just been published and
> > will be published on https://moodle.org/security/ shortly.
>
> Thanks a lot for your feedback, this very much appreciated. According
> to the above I have added a note to our CVE entries in the
> security-tracker at
>
> https://security-tracker.debian.org/tracker/851405
>
> to mention the above. Maybe those CVE might need to be rejected then
> in case it turns out that the reports were invalid regarding beeing a
> security issue.
>
> I will look forward for the new CVEs and add them later to our
> tracking.
>
> > cheers and thanks for your work,
>
> Thanks, and the same 'thank you' to you!
>
> Regards,
> Salvatore
>

Bug#851524: Building armhf image fwith qemu fails at bootstrapping stage if firmware section enabled

[Michael .]

If you are building a Raspbian image your initial config should work, if
you are not building a Raspbian image it won't work and will fail simply
because it is unable to find something you are telling it to look for.

On 16 January 2017 at 14:08, Jason Heeris  wrote:

> Here's a command to try building from a Raspbian image.
>
> env 
> DEBOOTSTRAP_OPTIONS="--keyring=/usr/share/keyrings/raspbian-archive-keyring.gpg"
> lb config \
> --archive-areas 'main firmware non-free' \
> --distribution jessie \
> --chroot-filesystem squashfs \
> --architectures armhf \
> --bootstrap-qemu-arch armhf \
> --bootstrap-qemu-static /usr/bin/qemu-arm-static \
> --parent-mirror-bootstrap http://archive.raspbian.org/raspbian \
> --parent-mirror-chroot http://archive.raspbian.org/raspbian \
> --parent-mirror-chroot-security http://archive.raspbian.org/raspbian \
> --parent-mirror-binary http://archive.raspbian.org/raspbian \
> --parent-mirror-binary-security http://archive.raspbian.org/raspbian \
> --mirror-bootstrap http://archive.raspbian.org/raspbian \
> --mirror-chroot http://archive.raspbian.org/raspbian \
> --mirror-chroot-security http://archive.raspbian.org/raspbian \
> --mirror-binary http://archive.raspbian.org/raspbian \
> --mirror-binary-security http://archive.raspbian.org/raspbian \
> --mirror-debian-installer http://archive.raspbian.org/raspbian
>
> sudo 
> DEBOOTSTRAP_OPTIONS="--keyring=/usr/share/keyrings/raspbian-archive-keyring.gpg"
> lb build 2>&1 | tee build.log
>
> Note that you need the raspbian-archive-keyring package[1]. Alternatively,
> I think there's a different debootstrap option that just ignores the
> signatures altogether.
>
> Again, no hard feelings if you deem this out of scope, but... maybe it
> suggests there's a bug in the bootstrapping phase? Because the repos in the
> chroot seem to not be respecting what I've configured:
>
> $ grep -isr "deb\.debian\.org"
> build.log:I: Keyring file not available at 
> /usr/share/keyrings/debian-archive-keyring.gpg;
> switching to https mirror https://deb.debian.org/debian
> chroot/debootstrap/debootstrap:DEF_MIRROR="http://deb.debian.org/debian";
> chroot/debootstrap/debootstrap:DEF_HTTPS_MIRROR="
> https://deb.debian.org/debian";
>
> (Note that /usr/share/keyrings/debian-archive-keyring.gpg most certainly
> exists on the host, but maybe it's talking about the chroot.)
>
> I've also noticed that in my "real" project, the bootstrap phase seems to
> bypass my apt-cacher-ng instance (which is specified as a localhost:3142
> URL in those same options). Am I missing some option for making the
> bootstrapping phase aware of the different repositories?
>
> [1] http://archive.raspbian.org/raspbian/pool/main/r/raspbian-
> archive-keyring/
>
> - Jason
>

Bug#851524: Building armhf image fwith qemu fails at bootstrapping stage if firmware section enabled

[Jason Heeris]

On 16 January 2017 at 14:08, Jason Heeris  wrote:
> Here's a command to try building from a Raspbian image.

s/ from//

- Jason

Bug#851524: Building armhf image fwith qemu fails at bootstrapping stage if firmware section enabled

[Jason Heeris]

Here's a command to try building from a Raspbian image.

env
DEBOOTSTRAP_OPTIONS="--keyring=/usr/share/keyrings/raspbian-archive-keyring.gpg"
lb config \
--archive-areas 'main firmware non-free' \
--distribution jessie \
--chroot-filesystem squashfs \
--architectures armhf \
--bootstrap-qemu-arch armhf \
--bootstrap-qemu-static /usr/bin/qemu-arm-static \
--parent-mirror-bootstrap http://archive.raspbian.org/raspbian \
--parent-mirror-chroot http://archive.raspbian.org/raspbian \
--parent-mirror-chroot-security http://archive.raspbian.org/raspbian \
--parent-mirror-binary http://archive.raspbian.org/raspbian \
--parent-mirror-binary-security http://archive.raspbian.org/raspbian \
--mirror-bootstrap http://archive.raspbian.org/raspbian \
--mirror-chroot http://archive.raspbian.org/raspbian \
--mirror-chroot-security http://archive.raspbian.org/raspbian \
--mirror-binary http://archive.raspbian.org/raspbian \
--mirror-binary-security http://archive.raspbian.org/raspbian \
--mirror-debian-installer http://archive.raspbian.org/raspbian

sudo
DEBOOTSTRAP_OPTIONS="--keyring=/usr/share/keyrings/raspbian-archive-keyring.gpg"
lb build 2>&1 | tee build.log

Note that you need the raspbian-archive-keyring package[1]. Alternatively,
I think there's a different debootstrap option that just ignores the
signatures altogether.

Again, no hard feelings if you deem this out of scope, but... maybe it
suggests there's a bug in the bootstrapping phase? Because the repos in the
chroot seem to not be respecting what I've configured:

$ grep -isr "deb\.debian\.org"
build.log:I: Keyring file not available at
/usr/share/keyrings/debian-archive-keyring.gpg; switching to https mirror
https://deb.debian.org/debian
chroot/debootstrap/debootstrap:DEF_MIRROR="http://deb.debian.org/debian";
chroot/debootstrap/debootstrap:DEF_HTTPS_MIRROR="
https://deb.debian.org/debian";

(Note that /usr/share/keyrings/debian-archive-keyring.gpg most certainly
exists on the host, but maybe it's talking about the chroot.)

I've also noticed that in my "real" project, the bootstrap phase seems to
bypass my apt-cacher-ng instance (which is specified as a localhost:3142
URL in those same options). Am I missing some option for making the
bootstrapping phase aware of the different repositories?

[1]
http://archive.raspbian.org/raspbian/pool/main/r/raspbian-archive-keyring/

- Jason

Bug#851544: chromium: cannot make chromium my default browser

[y]

Package: chromium
Version: 55.0.2883.75-1~deb8u1
Severity: normal
Tags: d-i

Dear Maintainer,

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

   * What led up to the situation?

It keeps saying "chromium isn't your default browser",
each time I starts it up, though I have set it to
default more than once.

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

1. I tried the command "update-alternatives", and had already set
chromium to be my default browser:
qxu@debian:~$ sudo update-alternatives --config x-www-browser
[sudo] password for qxu: 
There are 2 choices for the alternative x-www-browser (providing 
/usr/bin/x-www-browser).

  SelectionPath  Priority   Status

  0/usr/bin/firefox-esr   70auto mode
* 1/usr/bin/chromium  40manual mode
  2/usr/bin/firefox-esr   70manual mode

Press enter to keep the current choice[*], or type selection number: 
qxu@debian:~$ 

2. I tried "System Settings" -> "Preferred Applications", and set the default
web browser to chromium over there.

   * What was the outcome of this action?

When I restarted chromium again, it still told me that chromium is not
my default browser, and if I want to set it to the default browser.

I clicked the button to make it the default browser, but it kept saying
it is not my default browser the next time it is started. 

   * What outcome did you expect instead?

By right, any one of the methods (update-alternatives, System Setting ->
Preferred Applications, or the prompt in the chromium itself) should have
worked.

*** End of the template - remove these template lines ***


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

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

Versions of packages chromium depends on:
ii  libasound2   1.0.28-1
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u7
ii  libcairo21.14.0-2.1+deb8u2
ii  libcups2 1.7.5-11+deb8u1
ii  libdbus-1-3  1.8.22-0+deb8u1
ii  libexpat12.1.0-6+deb8u3
ii  libfontconfig1   2.11.0-6.3+deb8u1
ii  libfreetype6 2.5.2-3+deb8u1
ii  libgcc1  1:4.9.2-10
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
ii  libglib2.0-0 2.42.1-1+b1
ii  libgtk2.0-0  2.24.25-3+deb8u1
ii  libjpeg62-turbo  1:1.3.1-12
ii  libnspr4 2:4.12-1+debu8u1
ii  libnss3  2:3.26-1+debu8u1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpng12-0   1.2.50-2+deb8u3
ii  libstdc++6   4.9.2-10
ii  libwebp5 0.4.1-1.2+b2
ii  libwebpdemux10.4.1-1.2+b2
ii  libx11-6 2:1.6.2-3
ii  libx11-xcb1  2:1.6.2-3
ii  libxcb1  1.10-3+b1
ii  libxcomposite1   1:0.4.4-1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.1-2+b2
ii  libxi6   2:1.7.4-1+b2
ii  libxml2  2.9.1+dfsg1-5+deb8u4
ii  libxrandr2   2:1.4.2-1+b1
ii  libxrender1  1:0.9.8-1+b1
ii  libxslt1.1   1.1.28-2+deb8u2
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.2-1+b1
ii  x11-utils7.7+2
ii  xdg-utils1.1.0~rc1+git20111210-7.4

chromium recommends no packages.

Versions of packages chromium suggests:
pn  chromium-inspector  
ii  chromium-l10n   55.0.2883.75-1~deb8u1

-- no debconf information

Bug#561660: sleepd: Only one battery is checked with --battery

[martin f krafft]

also sprach Thomas Arendsen Hein  [2009-12-19 22:04 
+1100]:
> Test with:
> # acpi
> Battery 0: Discharging, 94%, 02:51:28 remaining
> Battery 1: Unknown, 72%
> # sleepd -n -v -E --sleep-command=beep --battery 99
> sleepd[16422]: battery level 94% is below 99%; forcing hibernation

I think it'd be best to compare against the average of the load
level of all available batteries.

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#851372: [pkg-go] Bug#851372: Bug#851372: prometheus-alertmanager FTBFS on mipsel and mips64el: test failures

[Martín Ferrari]

OK, I've finally managed to reproduce the problem, by running the build
with low prioirty in a very CPU-starved environment. It is again a
timing issue when starting the test server.

Will produce a patch and upload ASAP.


-- 
Martín Ferrari (Tincho)

Bug#851533: NBD: exported files over something around 1 TiB get an insane device size on the client side and are actually empty

[Christoph Anton Mitterer]

On Mon, 2017-01-16 at 02:37 +, Ben Hutchings wrote:
> This should possibly go to 4.9-stable, but in any case I've queued it
> up for our next upload.

Could you ping the responsible people? Guess you have far better
contacts there than me ;-)


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#851542: ITP: jenkins-job-builder-pipelin -- pipeline job generation plugin for jenkins-job-builder

[Potter, Tim]

On 16 Jan 2017, at 1:32 PM, Andrew Lee  wrote:
> 
> Package: wnpp
> Severity: wishlist
> Owner: "Andrew Lee (李健秋)" 
> 
> * Package name: jenkins-job-builder-pipelin
>  Version : 20160912+bd1bae
>  Upstream Author : rusty 
> * URL : https://github.com/rusty-dev/jenkins-job-builder-pipeline
> * License : Same as jenkins-job-builder
>  Programming Lang: Python
>  Description : pipeline job generation plugin for jenkins-job-builder
> 
>  This is a plugin for jenkins-job-builder to support pipeline job
>  generation.

Is there any reason an 'e' is missing from the end of this package name?  
Perhaps just
a typo?


Tim.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#851543: Safety override

[martin f krafft]

Package: sleepd
Version: 2.09
Severity: wishlist

Could sleepd wait for a minute or two after resume? I've
accidentally put --battery=90 in the config and then had a really
hard time changing that and restarting the daemon before sleepd
would put the machine down again.

Thanks,

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

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

Versions of packages sleepd depends on:
ii  libc62.24-8
ii  libglib2.0-0 2.50.2-2
ii  libupower-glib3  0.99.4-4
ii  lsb-base 9.20161125

Versions of packages sleepd recommends:
ii  pm-utils  1.4.1-16
ii  upower0.99.4-4

sleepd suggests no packages.

-- Configuration Files:
/etc/default/sleepd changed [not included]

-- debconf-show failed


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#851533: NBD: exported files over something around 1 TiB get an insane device size on the client side and are actually empty

[Ben Hutchings]

Control: tag -1 pending

On Mon, 2017-01-16 at 00:35 +0100, Christoph Anton Mitterer wrote:
> Source: linux
> Version: 4.9.2-2
> Severity: normal
> Tags: patch upstream
> 
> 
> Hey.
> 
> There's an issue in NBD which prevents some larger images to be
> correctly "connected" on the client side (if done by the kernel),
> largely described here:
> https://github.com/NetworkBlockDevice/nbd/issues/44
> 
> Thers's a patch at:
> https://www.spinics.net/lists/linux-block/msg07060.html
> from Josef Bacik which seems to fix the issue (at least it does
> so for me) but this will only go into 4.10.
> 
> So if 4.9 is the version for stretch, you might want to cherry
> pick this, as suggested by Wouter Verhelst.

This should possibly go to 4.9-stable, but in any case I've queued it
up for our next upload.

Ben.

-- 
Ben Hutchings
Every program is either trivial or else contains at least one bug



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

Bug#851402: failed unmounting /var during shutdown

[Michael Biebl]

Control: tags -1 + moreinfo

Am 15.01.2017 um 22:20 schrieb Michael Biebl:

> /var should be unmounted later, after the final killing spree by
> systemd-shutdown (see man 8 systemd-shutdown). I don't suppose you
> actually had a dirty fs after shutdown?
> 
> As for /var being unmounted earlier during shutdown, this is most likely
> happening because of var.mount conflicting with umount.target and
> systemd-journald.service not having an explicit ordering against var.mount
> 
> 
> I suppose you have persistent journal enabled, i.e. journald is writing
> to /var/log/journal?


Would be good if you can provide a verbose debug log from the shutdown:

/usr/share/doc/systemd/README.Debian.gz → check how to generate a
shutdown-log.txt

That log should help answer the above questions.

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



signature.asc
Description: OpenPGP digital signature

Bug#851542: ITP: jenkins-job-builder-pipelin -- pipeline job generation plugin for jenkins-job-builder

[李健秋]

Package: wnpp
Severity: wishlist
Owner: "Andrew Lee (李健秋)" 

* Package name: jenkins-job-builder-pipelin
  Version : 20160912+bd1bae
  Upstream Author : rusty 
* URL : https://github.com/rusty-dev/jenkins-job-builder-pipeline
* License : Same as jenkins-job-builder
  Programming Lang: Python
  Description : pipeline job generation plugin for jenkins-job-builder

  This is a plugin for jenkins-job-builder to support pipeline job
  generation.

Bug#818875: konqueror: green SSL checkbox despite expired server certificate

[Lisandro Damián Nicanor Pérez Meyer]

Disclaimer: I normally just look at Qt stuff, so I don't have a broad view on 
the issue nor an authoritative say in this.

On domingo, 15 de enero de 2017 20:55:52 ART Didier 'OdyX' Raboud wrote:
> Le lundi, 21 mars 2016, 11.03:13 h CET Thorsten Glaser a écrit :
> > Package: konqueror
> > Version: 4:15.08.3-1
> > Severity: grave
> > Tags: security
> > Justification: user security hole
> > 
> > See attached screenshot – konqueror does not error out when the
> > certificate is expired and even shows a green checkbox. (I may
> > or may not have ACK’d the certificate in an earlier session, I
> > don’t know right now, but showing a green checkbox is still
> > wrong.)
> 
> https://expired.identrustssl.com/ is an online example to test that
> use-case, which I can reproduce.
> 
> konqueror is RC-buggy in stretch because of that (IMHO rightful) bug. It is
> also plagued by other bugs, I wonder if konqueror should really be shipped
> in stretch. How feasible is it to remove it ?

Well, konqueror is part of kde-baseapps. One could imagine not shipping the 
binary and maybe some desktop files, but that source package also provides 
konqueror-related libs, and removing them will definitely be hard. And I don't 
know for sure if those bugs are really related to the front end konqueror is 
or the libs themselves.

As far as I understand konqueror is not supported by Debian's security team 
since ages, and we have always been recommending it for local/safe stuff. 

Moreover, on the same grounds, I personally tried to remove Qt4's webkit:

  https://wiki.debian.org/Qt4WebKitRemoval

but when I asked the security team they simply say something along "we don't 
support it, we don't care" which is fairly understandable.

So, all in all, I don't think it will be easy and before getting konqueror out 
I'll prefer removing Qt4' webkit.

But then again, I should not be considerer an authoritative voice here. Maxy 
should probably know much better than I.

Kinds rgeards, Lisandro.

-- 
Los estadounidenses no tienen la culpa, la guerra tiene la culpa. La falta de
voluntad de la gente para comprender a aquellos que tienen valores diferentes,
eso es lo que tiene la culpa.
  Shinji Mikamo
  


Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#851526: Please provide command-line option to disable ipv6

[Ben Hutchings]

On Sun, 2017-01-15 at 17:06 -0700, Nicholas D Steeves wrote:
> On Sun, Jan 15, 2017 at 02:43:45PM -0800, Josh Triplett wrote:
> > Package: netcfg
> > Severity: wishlist
> > 
> > netcfg provides an option to completely disable all automatic
> > configuration, but no option to disable ipv6 autoconfig (SLAAC) while
> > leaving DHCP enabled.  Putting ipv6.disable=1 on the kernel command line
> > will cause netcfg to realize the network has no ipv6, but only after
> > waiting a similar timeout for a link-local address, defeating the
> > purpose.
> > 
> > Please either detect disabled ipv6 and skip those steps, or provide a
> > command-line option to disable ipv6 in netcfg.
> > 
> > (Context: repeatedly testing preseed installs in a virtual machine, and
> > I don't want to keep waiting on ipv6 autoconfig timing out.)
> > 
> 
> From what I've read, ipv6.disable=1 hasn't been sufficient for quite
> some time, and one requires something like the following in
> /etc/sysctl.d/:
> 
> 00-disable-ipv6.conf:
> net.ipv6.conf.all.disable_ipv6 = 1
> net.ipv6.conf.default.disable_ipv6 = 1
> net.ipv6.conf.lo.disable_ipv6 = 1

You read wrong.  ipv6.disable=1 does all that, and more.
(See https://kernel.org/doc/Documentation/networking/ipv6.txt)

Ben.

-- 
Ben Hutchings
Every program is either trivial or else contains at least one bug


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

Bug#851541: www.debian.org: CD/verify should include long key IDs

[Stuart Prescott]

Package: www.debian.org
Severity: normal

Having just talked a user through the gpg verification steps for the CDs,
I've got a few suggestions for the web page with the instructions on how
to verify the CD contents:

1/ long key IDs:
it would be good to include the long key id rather than the short key id. The
long key id is present in the fingerprint but not in a form that can be
copy/pasted into gpg --recv-keys for those not already on Debian systems. The
necessary gpg options are

  --keyid-format long --with-fingerprint

2/ sort the keys:
Putting the keys that are most needed at the top would be great. Something
like:

  # current stable release CD key, current testing CD key, historical CD key
  for keyid in DA87E80D6294BE9B 42468F4009EA8AC3 988021A964E6EA7D; do
  gpg --list-keys --keyring /usr/share/keyrings/debian-role-keys.gpg \
--keyid-format long --with-fingerprint $keyid
  done

Even better would be explanatory text in between each key describing *how*
it was used so that users know which one they are supposed to be importing
from the keyservers if they have to do that. The current text gives the
impression of "here are some random keys that we might once have used";
while the text is accurate, it doesn't really instill confidence or help
the user with concrete next steps.

3/ concerete examples
Everyone knows how 'fun' the gpg CLI is to work with. A couple of concrete
examples of how to verify the download using the debian-keyring and the key
servers would be good. Something like:

  1. Download the ISO image as well as the files SHA256SUM and SHA256SUM.sign
 files that are in the same directory.

  2. On a Debian system, you can use your existing trust in the Debian Archive
 signing keys (in apt) to obtain the keys.

 # apt install debian-keyring
 $ sha256sum -c SHA256SUMS
 $ gpg --keyring /usr/share/keyrings/debian-role-keys.gpg --verify 
SHA256SUMS.sign

 On non-Debian systems, you can first import the relevant key from the
 keyservers.

 $ gpg --recv-keys DA87E80D6294BE9B
 $ sha256sum -c SHA256SUMS
 $ gpg --verify SHA256SUMS.sign

 In both cases, gpg should show that this was a "Good signature" but gpg
 will also warn you that your keys do not have an explicit trust path
 to this signing key; this warning is normal and can be ignored since
 you have established a trust path to the key outside gpg that gpg doesn't
 know about (your trust is either via the debian-keyring package or thanks
 to manually checking the fingerprint of the key that is used against this
 web page).

  (Maybe these are already on the wiki somewhere... fragmenting the
  documentation across www.d.o and wiki.d.o doesn't help and there'salso
  no link to this informaiton; the use of the debian-keyring package might
  also be a problem since it doesn't tend to receive stable updates -- maybe
  it should?)

4/ where are the sums?
Users consistently fail to find the SHA256SUM and SHA256SUM.sign files. The
verify page could be more explicit about where to find the files.¹ (I've
tried to be more explicit in the text above, not sure if that's enough.)


cheers
Stuart



[1] the download pages have long vexed the www team and I have no great
ideas how to actually make this better and further discussion lives in
separate bugs. What we've seen is that if users actually use the download
pages on www.debian.org then there are no links to the *SUM files anywhere and
users must copy+paste URLs and then edit them. I'm loathe to suggest more
links be added to the download pages though.

Bug#851322: [reportbug/master] modify the bug script to cope with non-ascii characters; patch by Nis Martensen; Closes: #851322

[Sandro Tosi]

tag 851322 pending
tag 851322 pending
thanks

Date:   Sun Jan 15 15:24:09 2017 -0500
Author: Sandro Tosi 
Commit ID: 64367ea6cb72b24c25ec31740b4c5bb25c4fc564
Commit URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff;h=64367ea6cb72b24c25ec31740b4c5bb25c4fc564
Patch URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff_plain;h=64367ea6cb72b24c25ec31740b4c5bb25c4fc564

modify the bug script to cope with non-ascii characters; patch by Nis 
Martensen; Closes: #851322

  

Bug#850733: [reportbug/master] fixes and improvements to GTK2 interface from James Clarke and Simon McVittie, thanks a lot! Closes: #850733

[Sandro Tosi]

tag 850733 pending
tag 850733 pending
thanks

Date:   Sun Jan 15 19:03:18 2017 -0500
Author: Sandro Tosi 
Commit ID: 271adbfa9f4128c9016aa10e13d58f4d4a450b33
Commit URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff;h=271adbfa9f4128c9016aa10e13d58f4d4a450b33
Patch URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff_plain;h=271adbfa9f4128c9016aa10e13d58f4d4a450b33

fixes and improvements to GTK2 interface from James Clarke and Simon 
McVittie, thanks a lot! Closes: #850733

  

Bug#851055: [reportbug/master] unbreak 'Read bug' functionality in urwid UI; patch by Ryan Kavanagh; Closes: #851055

[Sandro Tosi]

tag 851055 pending
tag 851055 pending
thanks

Date:   Sun Jan 15 15:36:15 2017 -0500
Author: Sandro Tosi 
Commit ID: 82479c88d69b714da69135bcba556c2a032e2976
Commit URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff;h=82479c88d69b714da69135bcba556c2a032e2976
Patch URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff_plain;h=82479c88d69b714da69135bcba556c2a032e2976

unbreak 'Read bug' functionality in urwid UI; patch by Ryan Kavanagh; 
Closes: #851055

  

Bug#851355: [reportbug/master] fix order of email environment variables; patch by Nis Martensen; Closes: #851355

[Sandro Tosi]

tag 851355 pending
tag 851355 pending
thanks

Date:   Sun Jan 15 15:27:59 2017 -0500
Author: Sandro Tosi 
Commit ID: 6ddf13efb55151db5e0edc410eec4e3c419df49a
Commit URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff;h=6ddf13efb55151db5e0edc410eec4e3c419df49a
Patch URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff_plain;h=6ddf13efb55151db5e0edc410eec4e3c419df49a

fix order of email environment variables; patch by Nis Martensen; Closes: 
#851355

  

Bug#851055: [reportbug/master] Unbreak 'Read bug' functionality in urwid UI; Closes: #851055

[Ryan Kavanagh]

tag 851055 pending
thanks

Date:   Wed Jan 11 15:34:51 2017 -0500
Author: Ryan Kavanagh 
Commit ID: 329ba259001a31a2e714401009a8acab2923bc3a
Commit URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff;h=329ba259001a31a2e714401009a8acab2923bc3a
Patch URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff_plain;h=329ba259001a31a2e714401009a8acab2923bc3a

Unbreak 'Read bug' functionality in urwid UI; Closes: #851055

  

Bug#836253: [reportbug/master] improve to the file and no longer hardcode the debian-swirl file location; patch by Boyuan Yang; Closes; #836253

[Sandro Tosi]

tag 836253 pending
thanks

Date:   Sun Jan 15 15:54:10 2017 -0500
Author: Sandro Tosi 
Commit ID: a11073fd8464450427f1404e28dd190616667e84
Commit URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff;h=a11073fd8464450427f1404e28dd190616667e84
Patch URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff_plain;h=a11073fd8464450427f1404e28dd190616667e84

improve to the file and no longer hardcode the debian-swirl file location; 
patch by Boyuan Yang; Closes; #836253

  

Bug#851415: [reportbug/master] removed, now obsolete in favor of XDG desktop files; patch by Boyuan Yang; Closes: #851415

[Sandro Tosi]

tag 851415 pending
tag 851415 pending
thanks

Date:   Sun Jan 15 15:41:12 2017 -0500
Author: Sandro Tosi 
Commit ID: 7a220fd84864e88f227910de4fccd066333eadbc
Commit URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff;h=7a220fd84864e88f227910de4fccd066333eadbc
Patch URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff_plain;h=7a220fd84864e88f227910de4fccd066333eadbc

removed, now obsolete in favor of XDG desktop files; patch by Boyuan Yang; 
Closes: #851415

  

Bug#851540: visual-regexp: Missing basic documentation

[Karl Schmidt]

Package: visual-regexp
Version: 3.1-4
Severity: normal

The description tag should at least mention which type of regex this supports.

: BRE (Basic Regular Expressions), ERE (Extended Regular Expressions) or PCregex

If you press the help button you get:

expected integer but got "bold"
expected integer but got "bold"
(processing "-font" option)
invoked from within
".help.text.t tag configure bold -font "[.help.text.t cget -font] bold""
(procedure "regexp::help" line 26)
invoked from within
"regexp::help"
invoked from within
".#menubar.#menubar#help invoke active"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list $w invoke active]"
(procedure "tk::MenuInvoke" line 50)
invoked from within
"tk::MenuInvoke .#menubar.#menubar#help 1"
(command bound to event)

So help appears broken... missing man page ... no README - no trail
of bread-crumbs to http://laurent.riesterer.free.fr/regexp/

A help file that told which type and displayed this:
http://gmckinney.info/resources/regex.pdf

Would do wonders for this useful package..






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

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

Versions of packages visual-regexp depends on:
ii  tcl-vfs [tclvfs]  1.3-20080503-4
ii  tk8.5 8.5.17-1

visual-regexp recommends no packages.

visual-regexp suggests no packages.

-- no debconf information

Bug#851539: Stretch RC1 netinst installer prompts for additional CDs

[Steve McIntyre]

On Sun, Jan 15, 2017 at 04:53:26PM -0800, Josh Triplett wrote:
>Package: installation-reports
>Severity: normal
>
>I tried doing an install with a Stretch RC1 netinst CD.  Worked fine,
>except that later in the install, right before asking about an apt
>mirror, the installer asked about scaning additional CDs.  Previous
>versions of the netinst installer haven't asked that question; normally
>only the full-CD installers ask that.

This is a deliberate change, yes. It makes the firmware netinsts more
useful now, for example...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I used to be the first kid on the block wanting a cranial implant,
 now I want to be the first with a cranial firewall. " -- Charlie Stross

Bug#744165: '/usr/lib/i386-linux-gnu/libfakeroot' not empty so not removed

[Clint Adams]

On Sat, Jan 14, 2017 at 03:23:27PM +0100, Andreas Beckmann wrote:
> I'd really like to see this fixed for stretch, since it pops up in quite
> a number of piuparts tests.
> I could also NMU it if you need help.

Please feel free.

Bug#848236: Remaining issue with gbrowse - any help (Was: Urgent call to BioPerl users (Was: Bug#848236: src:gbrowse: ...)

[Fields, Christopher J]

That’s great news Lincoln, fantastic!

chris

From: Lincoln Stein mailto:lincoln.st...@gmail.com>>
Date: Sunday, January 15, 2017 at 3:25 PM
To: Andreas Tille mailto:andr...@fam-tille.de>>
Cc: Scott Cain mailto:sc...@scottcain.net>>, 
"848...@bugs.debian.org" 
<848...@bugs.debian.org>, Chris Fields 
mailto:cjfie...@illinois.edu>>, Debian Med Project List 
mailto:debian-...@lists.debian.org>>, Charles 
Plessy mailto:char...@plessy.org>>, Olivier Sallou 
mailto:olivier.sal...@irisa.fr>>, Sascha Steinbiss 
mailto:sa...@debian.org>>, Carnë Draug 
mailto:carandraug+...@gmail.com>>
Subject: Re: Remaining issue with gbrowse - any help (Was: Urgent call to 
BioPerl users (Was: Bug#848236: src:gbrowse: ...)

Hi,

The bug in the memory adaptor that Scott found turns out to have been from 
using the old perl 1.6.9 installed by the Debian package. Updating to 1.7.1 
(1.007001) fixes the problem.

I have merged all GBrowse changes into git version 2.56 and have made a CPAN 
release. I think you can go ahead and package it.

Lincoln

On Thu, Jan 12, 2017 at 11:37 PM, Andreas Tille 
mailto:andr...@fam-tille.de>> wrote:
Thanks to you both.  I think the only question targeted directly at my
was the "how much time question":  On Februrar 5 is full freeze.  You
need to cut 10 days from this since a package has a 10 day migration
time until it makes it from unstable to the release candidates in
testing.  So this would make 2017-01-25 - but if there is a single (even
unrelated to gbrowse) issue that might prevent the migration gbrowse is
doomed.  So I'd recommend to get something out until beginning of next
week.

Kind regards

  Andreas.

On Thu, Jan 12, 2017 at 02:23:42PM -0500, Scott Cain wrote:
> I made a few changes in a branch off that security-bug-fixes branch that
> quieted several warning messages, though I still need to sort out at least
> one problem (the memory adaptor doesn't seem to be reading fasta files, but
> also doesn't emit a warning about a problem).  Lincoln, if you want to look
> at this pull request, you could pull those changes into the security bug
> fix branch:
>
> https://github.com/GMOD/GBrowse/pull/59
>
> Scott
>
>
> On Thu, Jan 12, 2017 at 1:57 PM, Lincoln Stein 
> mailto:lincoln.st...@gmail.com>>
> wrote:
>
> > Hi Andreas,
> >
> > I was able to remove the vast majority of the warnings and other
> > incompatibility issues, but need to do more testing to identify areas of
> > the code that were not covered. How much time do I have? If you want to go
> > with a fully functional version that may issue warnings when the user takes
> > certain rare actions, it is the "security-bug-fixes" branch at
> > https://github.com/GMOD/GBrowse
> >
> > Lincoln
> >
> > On Thu, Jan 12, 2017 at 1:39 PM, Andreas Tille 
> > mailto:andr...@an3as.eu>> wrote:
> >
> >> Hi Lincoln,
> >>
> >> On Wed, Dec 21, 2016 at 06:25:46PM -0500, Lincoln Stein wrote:
> >> > I am devoting several days over the Christmas holidays to fixing the
> >> > various outstanding bugs in gbrowse. Stay tuned!
> >>
> >> Did you managed to managed to work on this?  If not we probably can not
> >> include gbrowse in the next Debian stable release which would be a
> >> shame.
> >>
> >> Kind regards
> >>
> >>Andreas.
> >>
> >> --
> >> http://fam-tille.de
> >>
> >
> >
> >
> > --
> > *Lincoln Stein*
> >
> > Scientific Director (Interim), Ontario Institute for Cancer Research
> > Director, Informatics and Bio-computing Program, OICR
> > Senior Principal Investigator, OICR
> > Professor, Department of Molecular Genetics, University of Toronto
> >
> > >
> > *Ontario Institute for Cancer Research*
> > MaRS Centre
> > 661 University Avenue
> > Suite 510
> > Toronto, Ontario
> > Canada M5G 0A3
> >
> > Tel: 416-673-8514 <(416)%20673-8514>
> > Mobile: 416-817-8240 <(416)%20817-8240>
> > Email: lincoln.st...@gmail.com
> > Toll-free: 1-866-678-6427 <(866)%

Bug#851539: Stretch RC1 netinst installer prompts for additional CDs

[Josh Triplett]

Package: installation-reports
Severity: normal

I tried doing an install with a Stretch RC1 netinst CD.  Worked fine,
except that later in the install, right before asking about an apt
mirror, the installer asked about scaning additional CDs.  Previous
versions of the netinst installer haven't asked that question; normally
only the full-CD installers ask that.

- Josh Triplett

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

Dear Nicholas,

On Sun, Jan 15, 2017 at 04:51:24PM -0700, Nicholas D Steeves wrote:
> On Sun, Jan 15, 2017 at 07:45:18AM -0700, Sean Whitton wrote:
> > I found some more errors in the copyright file.  Rather than go back and
> > forth once again, I fixed them in our team git repository.  I set the
> > changelog back to UNRELEASED: if you are okay with the changes, please
> > `dch -r`, commit and push, and I will upload.
> 
> Why did you remove 2001 from Eric Marsen's cgi.el copyright entry when
> the file is time stamped <2001-08-24 emarsden>?  

Ah, sorry.

> For httpd.el, I agree that "2001, 2003" is more accurate, but is it
> allowed?  In the past, when I've submitted patches to this effect the
> maintainer of the package changed the lines to something like
> "2001-2003", even though the VCS and copyright embedded in the file
> specified discreet years rather than a range...which led me to believe
> that a discreet range is unacceptable.

A discrete range is fine.

> Ah!  Yes, this is the spec that addresses my question to #3.  That
> said, in the past some of my other work on d/copyright has been said
> to be "worse than useless" even though it adhered to the spec, and
> even though it seemed to reflect what I saw reading the packages
> COPYING file, in addition to spending a while reading VCS commits for
> stuff I wasn't sure about.  This has led me to wonder about the tribal
> rules that are not in the spec...

Could you give me an example of a rule like that?

> Would you please check to see if my latest commit to d/copyright is
> ok?  It's what makes the most sense to me.  As far as I can tell, it
> might be problematic because it infers that Eric Marsden changed
> cgi.el in 2003.  If it's problematic I'll revert it, then dch -r.

No, it doesn't actually imply that Marsden changed that file in 2004
(the spec does explain this!).

Go ahead and `dch -r`!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#175064: DocBook XML conversion is read with this script

[Guillem Jover]

On Mon, 2017-01-16 at 00:53:43 +0100, gregor herrmann wrote:
> On Sun, 15 Jan 2017 20:51:07 +0100, Guillem Jover wrote:
> 
> > Subject: [PATCH 1/7] Use entities instead of literal <, > and &
> 
> It seems you've converted some '>' to '>' but not all?

Indeed, nice catch! The following two I think were part of a botched
patch split during a rebase. But there are several other I had missed
and for which the tools I've used did not complain. In any case, I've
now switching all of them, I think. Updated patch attached.

> > -if [ "$1" = start ] && which initctl >/dev/null && initctl version | grep 
> > -q upstart
> > +if [ "$1" = start ] && which initctl >/dev/null && initctl 
> > version | grep -q upstart
> ^
> 
> > -  if dpkg-statoverride --list $i >/dev/null 2>&1
> > +  if dpkg-statoverride --list $i >/dev/null 2>&1

Thanks,
Guillem
From 1586352346d4a007814ce1208f639711a977130a Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 10 Jan 2017 00:31:37 +0100
Subject: [PATCH v2 1/7] Use entities instead of literal <, > and &

This is required in DocBook, otherwise it makes XML toolchains trip over.
---
 policy.sgml | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index b0b2e09..02d74b8 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -4274,7 +4274,7 @@ Checksums-Sha256:
 	facility the postrm intends to call is
 	available before calling it.  For example:
 
-if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then
+if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then
 . /usr/share/debconf/confmodule
 db_purge
 fi
@@ -4836,7 +4836,7 @@ fi
 	  
 Package: mutt
 Version: 1.3.17-1
-Depends: libc6 (>= 2.2.1), exim | mail-transport-agent
+Depends: libc6 (>= 2.2.1), exim | mail-transport-agent
 	  
 	
 
@@ -6558,7 +6558,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
 	  main-dependency-template has the same syntax as a
 	  dependency field in a binary package control file, except
 	  that the string #MINVER# is replaced by a version
-	  restriction like (>= version) or by
+	  restriction like (>= version) or by
 	  nothing if an unversioned dependency is deemed sufficient.
 	  The version restriction will be based on which symbols from
 	  the shared library are referenced and the version at which
@@ -6614,9 +6614,9 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
 		compressBound@ZLIB_1.2.0 1:1.2.0
 	  
 	  Packages using only compress would then get a
-	  dependency on zlib1g (>= 1:1.1.4), but packages
+	  dependency on zlib1g (>= 1:1.1.4), but packages
 	  using compressBound would get a dependency
-	  on zlib1g (>= 1:1.2.0).
+	  on zlib1g (>= 1:1.2.0).
 	
 
 	
@@ -6648,7 +6648,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
 		on libgl1 (which may be provided by multiple
 		packages), but ones
 		using implementationSpecificSymbol would get a
-		dependency on libgl1-mesa-glx (>= 6.5.2-7)
+		dependency on libgl1-mesa-glx (>= 6.5.2-7)
 	  
 	
 
@@ -6897,7 +6897,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
 	  library was in version 1:1.2.3.3.dfsg-1, then
 	  the shlibs entry for this library could say:
 	  
-		libz 1 zlib1g (>= 1:1.2.3.3.dfsg)
+		libz 1 zlib1g (>= 1:1.2.3.3.dfsg)
 	  
 	  This version restriction must be new enough that any binary
 	  built against the current version of the library will work
@@ -6909,7 +6909,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
 	  As zlib1g also provides a udeb containing the shared
 	  library, there would also be a second line:
 	  
-		udeb: libz 1 zlib1g-udeb (>= 1:1.2.3.3.dfsg)
+		udeb: libz 1 zlib1g-udeb (>= 1:1.2.3.3.dfsg)
 	  
 	
 	  
@@ -7087,7 +7087,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
 		
 		  Packages must not assume the /run
 		  directory exists or is usable without a dependency
-		  on initscripts (>= 2.88dsf-13.3) until the
+		  on initscripts (>= 2.88dsf-13.3) until the
 		  stable release of Debian supports /run.
 		
 	  
@@ -7196,7 +7196,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
 	contain something like
 	
 if [ ! -e /usr/local/share/emacs ]; then
-  if mkdir /usr/local/share/emacs 2>/dev/null; then
+  if mkdir /usr/local/share/emacs 2>/dev/null; then
 if chown root:staff /usr/local/share/emacs; then
   chmod 2775 /usr/local/share/emacs || true
 fi
@@ -7205,8 +7205,8 @@ fi
 	
 	in its postinst script, and
 	
-rmdir /usr/local/share/emacs/site-lisp 2>/dev/null || true
-rmdir /usr/local/share/emacs 2>/dev/null || true
+rmdir /usr/local/share/emacs/site-lisp 2>/dev/null || true
+rmdir /usr/local/share/emacs 2>/dev/null || true
 	
 	in the prerm script.  (Note that this form is
 	used to ensure that if the script is interrupted, the
@@ -8593,7 +85

Bug#851524: Building armhf image fwith qemu fails at bootstrapping stage if firmware section enabled

[Jason Heeris]

On 16 January 2017 at 10:21, Ben Armstrong 
wrote:
>
> I can't see how --archive-areas 'main firmware' would've ever worked,
since 'firmware' is not valid.

Hmm. It was left over from my original project which was a Raspbian live
build, which suddenly started failing in the same way. I tried to reduce it
to a shorter example, not realising that 'firmware' was a valid area for
Raspbian but not Debian. So that explains my example.

Unfortunately I do need the 'firmware' area for the Raspbian project, and
while using it used to work (with the Raspbian repositories) under 1:20151215,
it seems to produce this error under 1:20161216. I can't expect you to help
with Raspbian issues, but if you have any ideas I'd welcome them. Otherwise
I guess this is invalid.

Cheers,
Jason

Bug#851372: [pkg-go] Bug#851372: prometheus-alertmanager FTBFS on mipsel and mips64el: test failures

[Martín Ferrari]

Adrian,

On 15/01/17 20:08, Adrian Bunk wrote:
> On Sun, Jan 15, 2017 at 07:40:57PM -0300, Martín Ferrari wrote:

> Looking at the error message "getsockopt: connection refused",
> it is possible that there might be different network related
> configuration or permissions on these buildds?

That would be weird. This is an end-to-end test that starts an instance
of the server and connects through localhost.

> A web search finds for example
>   
> https://buildd.raspbian.org/status/fetch.php?pkg=prometheus-alertmanager&arch=armhf&ver=0.3.0+ds-2&stamp=1469110396

That link does not work for me, but from the logs I find in that site,
the failures were unrelated, and the latest attempt to build succeeded:

https://buildd.raspbian.org/status/logs.php?pkg=prometheus-alertmanager&arch=armhf


-- 
Martín Ferrari (Tincho)

Bug#844785: "not authorised" doing various desktoppy things [and 1 more messages]

[Raphaël Halimi]

Le 15/01/2017 à 15:52, Ian Jackson a écrit :
> tl;dr
>   TYVM to Michael Biebl
>   I intend QA upload of systemd-shim with Michael's wrapper

Hi,

I just installed the updated systemd-shim from experimental, removed the
hold on systemd packages to update them to their latest version from
sid, and I can confirm that now everything works as expected (shutdown
entries in lightdm, polkit auth agent, and obsession menu logout entries).

Michael, Ian, thank you very much to both of you.

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#808654: Bug #808654 closed accidentally (it seems)

[Santiago Vila]

On Sun, Jan 15, 2017 at 11:24:12PM +0100, Piotr Ożarowski wrote:
> > Hello Piotr. For reasons I still don't understand, your commands
> > above made the bug to be closed.
> 
> the bug was actually not in fedmsg but in moksha.hub and I fixed it in 
> 1.4.1-2 
> (hence different source package/version that was closing bug).
> 
> I just checked (build logs you pointed me to are really old, before my
> fix) and this package still FTBFS but for a completely different reason
> (I guess it's OK to reopen this one as the final result is the same - it
> doesn't build)

There are actually several schools of thought about that :-). One of
them says that when the reason for the bug changes, we need another
bug report. I do not always agree with that [*], so if it's ok for you
to recycle this bug (because of the observed effect), it's also ok for
me.

[*] For example, for bugs of type "FTBFS with dpkg-buildpackage -A",
I usually reopen when the package still FTBFS with dpkg-buildpackage -A
after an incomplete fix, because at least in this case I was reporting
the "end effect" and not the cause.

Thanks.

Bug#851537: Please support preseeding an empty domain to prevent prompting

[Josh Triplett]

Package: netcfg
Severity: wishlist

netcfg supports preseeding the domain via netcfg/get_domain, but
providing an empty values results in the installer still prompting.
Please consider providing a way to preseed an empty domain name, to
completely suppress the prompt for one.

Thanks,
Josh Triplett

Bug#851538: RM: snap-confine -- ROM; has been merged into snapd

[Michael Hudson-Doyle]

Package: ftp.debian.org
Severity: normal

Hi masters,

The snap-confine source package has been merged upstream into the snapd
package, which now produces all the binaries that snap-confine used to
produce. snap-confine built on more architectures than snapd, which is why
snap-confine is not on the cruft report, but it's useless without snapd.

Cheers,
mwh

Bug#851499: cups-filters-core-drivers: Everywhere PPD content depends on queue creation method

[Till Kamppeter]

Fixed in cups-filters upstream, BZR rev. 7599.

Thank you for the bug report.

"lpadmin -m everywhere" uses the PPD generator in the CUPS library. The 
generator has no public API and so it cannot be used by other programs 
using the CUPS library.


Therefore I have copied the PPD generator from CUPS and put it into the 
libcupsfilters library, WITH public API, and keep it in sync with the 
original by overtaking any changes.


This version of the PPD generator is used

- When cups-browsed creates a local print queue and generates a queue
  for it (IPP network printers).

- When a queue is set up with a printer setup tool like system-config-
  printer or localhost:631. In this case the "driverless" utility of
  cups-filters is used to generate the PPD file.

The two PPD generators are not absolutely equal because I have added 
some features:


- The original PPD generator only supports PWG Raster, Apple Raster,
  PDF, and JPEG as printer PDL, my generator also accepts (with lower
  priority) PostScript, PCL-XL, and PCL 5c/e, for legacy printers.

- The original PPD generator requires all printer capability, option,
  and choice information from the printer attributes IPP request, my
  generator can in some cases fall back to info from the Bonjour record
  or even hard-coded default values. This adds support for some legacy
  printers.

The difference in the generation of *cupsFilter2 lines in the PPD 
generator is due to the support for the additional legacy PDLs. I had 
overlooked JPEG that time. Now I have added the JPEG support the same 
form as CUPS does. If input is JPEG and the printer understands JPEG, 
the JPEG input gets passed through without filtering.


As JPEG supports only one-page documents (pictures) and most common PDLs 
are multi-page (needed for typical print jobs), there should never be a 
filter rule turning PDF (or any other multi-page language) into JPEG.

Bug#850094: Please do not remove packages which FTBFS randomly yet

[Santiago Vila]

On Wed, 4 Jan 2017, Santiago Vila wrote:

> Please help me to ensure that we are not removing (yet!) any package
> from stretch because of any of such bugs (I think this mass-severity-setting
> should yield such effect, but I'm not 100% sure).
> 
> In particular, please let any such package propagate to testing again
> (temporarily!) if it was autoremoved because of any of such bugs.

I've checked and it seems there is only one package affected by this.

Could you please reallow "src:uncertainties" in stretch?

I downgraded #844571 to important in the mass-downgrading
but forgot to downgrade #844572 as well (which I have just done).

As a result, the package was autoremoved.

If the plan is to consider RC-ness based on probability of failure,
this package has a lot more reason to stay in stretch than some
packages which FTBFS a lot more often.

Thanks.

Bug#830863: [pkg-opensc-maint] Bug#830863: opensc-pkcs11: Unable to sign

[Eric Dorland]

Sorry I don't have your particular hardware to test with, but this
sounds similar to https://github.com/OpenSC/OpenSC/issues/942. Do you
think it could be the same issue?

* Stanimir Stoyanov (stani...@datacentrix.org) wrote:
> Package: opensc-pkcs11
> Version: 0.16.0-1
> Severity: important
> 
> Dear Maintainer,
> 
> It is about omnikey reader with CardOS smart card.
> 
> The output of OPENSC_DEBUG=2 pkcs11-tool --module /usr/lib/x86_64-linux-gnu
> /onepin-opensc-pkcs11.so -t -l:
> 
> Please enter User PIN:
> 0x7feae107d700 14:18:05.293 [onepin-opensc-pkcs11] sec.c:206:sc_pin_cmd:
> returning with: 0 (Success)
> C_SeedRandom() and C_GenerateRandom():
>   seeding (C_SeedRandom) not supported
>   seems to be OK
> Digests:
>   all 4 digest functions seem to work
>   MD5: OK
>   SHA-1: OK
>   RIPEMD160: OK
> Signatures (currently only RSA signatures)
>   testing key 0 (StampIT)
> 0x7feae107d700 14:18:10.557 [onepin-opensc-pkcs11] card-
> cardos.c:475:cardos_select_file: called
> 0x7feae107d700 14:18:10.582 [onepin-opensc-pkcs11]
> sec.c:72:sc_set_security_env: returning with: 0 (Success)
> 0x7feae107d700 14:18:10.621 [onepin-opensc-pkcs11] sec.c:44:sc_decipher:
> returning with: -1200 (Card command failed)
> 0x7feae107d700 14:18:10.630 [onepin-opensc-pkcs11] card-
> cardos.c:475:cardos_select_file: called
> 0x7feae107d700 14:18:10.723 [onepin-opensc-pkcs11]
> ctx.c:842:sc_release_context: called
> error: PKCS11 function C_SignFinal failed: rv = CKR_GENERAL_ERROR (0x5)
> 
> Aborting.
> 
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages opensc-pkcs11 depends on:
> ii  libc62.22-13
> ii  libssl1.0.2  1.0.2h-1
> ii  zlib1g   1:1.2.8.dfsg-2+b1
> 
> opensc-pkcs11 recommends no packages.
> 
> opensc-pkcs11 suggests no packages.
> 
> -- no debconf information
> 
> ___
> pkg-opensc-maint mailing list
> pkg-opensc-ma...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-opensc-maint

-- 
Eric Dorland 
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93


signature.asc
Description: PGP signature

Bug#445286: readline frontend for debconf and previous values

[GSR]

Hi:

Already possible to have the previous values typed in. See reports
635032 & 537870. Install libterm-readline-gnu-perl to make the values
appear ready to be edited.

So what probably should do is include the values in prompt text when
the package is not installed. Then allow pressing enter to accept, and
only edits would require retyping.

Cheers,
GSR
 

Bug#844572: uncertainties: FTBFS randomly (FAIL: Full comparison to a Monte-Carlo calculation)

[Santiago Vila]

severity 844572 important
thanks

Hello.

I'm setting the severity of this bug to "important" not because
I don't think it is not RC (as Release Policy still says that
packages must autobuild *without* failure), but because the
Release Managers are considering to decide about RC-ness
of this kind of bugs based on the probability of failure.

We don't know what kind of threshold there will be for stretch, so I
strongly recommend that you act as if this bug was serious and RC,
especially if the failures happen very often on any kind of
autobuilder which is not misconfigured.

Unfortunately this package was already autoremoved because of this bug.

This is probably not ok if we consider that other packages which FTBFS
a lot more often are still in stretch. I'm going to ask Release
Managers if it's possible to reallow this in stretch.

Thanks.

Bug#851526: Please provide command-line option to disable ipv6

[Nicholas D Steeves]

On Sun, Jan 15, 2017 at 02:43:45PM -0800, Josh Triplett wrote:
> Package: netcfg
> Severity: wishlist
> 
> netcfg provides an option to completely disable all automatic
> configuration, but no option to disable ipv6 autoconfig (SLAAC) while
> leaving DHCP enabled.  Putting ipv6.disable=1 on the kernel command line
> will cause netcfg to realize the network has no ipv6, but only after
> waiting a similar timeout for a link-local address, defeating the
> purpose.
> 
> Please either detect disabled ipv6 and skip those steps, or provide a
> command-line option to disable ipv6 in netcfg.
> 
> (Context: repeatedly testing preseed installs in a virtual machine, and
> I don't want to keep waiting on ipv6 autoconfig timing out.)
>

From what I've read, ipv6.disable=1 hasn't been sufficient for quite
some time, and one requires something like the following in
/etc/sysctl.d/:

00-disable-ipv6.conf:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Cheers,
Nicholas


signature.asc
Description: Digital signature

Bug#850733: [Reportbug-maint] Bug#850733: Crashes with "TypeError: GObject.__init__() takes exactly 0 arguments (1 given)"

[Sandro Tosi]

OMG guys, thanks a lot for all your patches! I've applied them all
(including the 0013 update) and fix .gitignore and
python3-gtkspellcheck as James suggested

On Sun, Jan 15, 2017 at 7:55 AM, Simon McVittie  wrote:
> On Sun, 15 Jan 2017 at 00:32:15 +, Simon McVittie wrote:
>> From f70c4dcc86afdc26f8e60c2a6c9d2829717db81e Mon Sep 17 00:00:00 2001
>> From: Simon McVittie 
>> Date: Sun, 15 Jan 2017 00:23:11 +
>> Subject: [PATCH 13/14] gtk2_ui: Reduce deprecation spam by using named
>>  constructors
>
> This one is wrong: the LinkButton parts are right, the MessageDialog parts
> crash. Please replace with the attached.
>
> Also available as the "gtk" branch in:
>
> ssh://git.debian.org/git/users/smcv/reportbug.git
>
> Regards,
> S



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