Bug#820818: partman is not able to resize nvme0n1p3 in d-i

[Philip Hands]

Ian Jackson  writes:

> Philip Hands writes ("Re: Bug#820818: partman is not able to resize nvme0n1p3 
> in d-i"):
>> BTW I just pushed Ben's alternative suggetion to the
>> pu/resize-nvme-820818-benh branch:
>> 
>>   
>> https://anonscm.debian.org/cgit/d-i/partman-partitioning.git/commit/?h=pu/resize-nvme-820818-benh=62c696450a206d7ee08d570fef4c2923a03042a8
>> 
>> (also untested)
>
> Is it easy for you to make an image to give to me to test that ?

I just tried it with this image:

  
http://cdimage.debian.org/cdimage/stretch_di_rc2/amd64/iso-cd/debian-stretch-DI-rc2-amd64-netinst.iso

adding this to the kernel command line (hit TAB at the boot menu):

  url=hands.com/d-i/bug/820818/preseed.cfg

and it drops the replacement resize.sh (now using Cyril's version) in
place.

BTW If you want to suggest somewhere to exit the script to avoid
touching your disks, I can add that to save you the effort.

Cheers, Phil.

P.S. This kludge is totally over-engineered, as the file is ready to be
replaced by the time the early command is run, so in this case the
checks and background loop are superfluous.

P.P.S. I think this is much less effort than building a new image, since a
newly built netinst would download the old partman-partition udeb from
the archive unless you start making more invasive changes.  You can
check that it's done the right thing by the time you get to the root
password prompts, flipping to a console and running:

  head -40 /lib/partman/lib/resize.sh
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#848574: Fwd: Re: [open-mpi/ompi] Failure on mips64el (#2922)

[YunQiang Su]

The package in experimental (2.0.2-1) seems having no this problem.

On Sun, 5 Feb 2017 19:11:04 + Alastair McKinstry
 wrote:
> This hints at a linker issue on stretch
>
>  Forwarded Message 
> Subject: Re: [open-mpi/ompi] Failure on mips64el (#2922)
> Date: Sun, 05 Feb 2017 09:18:36 -0800
> From: Paul H. Hargrove 
> Reply-To: open-mpi/ompi
> 
>
> To: open-mpi/ompi 
> CC: Alastair McKinstry , Author
> 
>
>
>
> @ggouaillardet 
> Yes, I have both mips64 and mips64el and test thee ABIs
> (|-mabi={32,n32,64}|) on each.
> All 6 passed my testing of 2.0.2rc4, which included running the ring
> examples (|ring_{c,mpih,usempi,usempif08}|) with two ranks on 1 node.
> My tests are on Octeon II systems running Debian Wheezy, and are not
> mine to upgrade.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> .
>

Bug#854337: unblock: git-buildpackage/0.8.12.1

[Guido Günther]

control: tag -1 moreinfo

Hi Jonathan,
On Mon, Feb 06, 2017 at 01:57:09PM +, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed moreinfo
> 
> Hi,
> 
> On 2017-02-06 07:43, Guido Günther wrote:
> > It would be great if gbp could be unblocked (and just handled as if it
> > would have been uploaded 1 day earlier). This would make it possible for
> > me to fix #854333 and other things coming up during the freeze as
> > targeted fixes (otherwise I'd have to somehow revert to 0.8.10 in sid).
> 
> I'll trade you it for the fix for #854333; then I can deal with only one
> unblock request and not another in a few days time.
> 
> Please upload a fix for that bug to unstable, as you would normally, and
> update this bug removing moreinfo. I'll unblock the whole lot.

Deal. Uploaded to unstable. Thanks a lot!
 -- Guido

Bug#596513: git-dch: Add --[no]mainttrailer option

[Guido Günther]

control: tags -1 +confirmed

On Fri, Jan 27, 2017 at 08:22:02PM +0100, gregor herrmann wrote:
> Package: git-buildpackage
> Version: 0.8.10
> Followup-For: Bug #596513
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> I just wanted to file a new bug report "gbb-dch hardcodes
> - --nomainttrailer' but we might as well re-use this old one, since it
> is maybe the answer to my issue.
> 
> 
> I was a bit surprised that gbp-dch recently started to always change
> the trailer line in d/changelog on an innocent `gbp dch -a'. After
> looking at the changelog and the git history it seems like this is a
> side effect of fixing #796913, i.e. of commit 42878ff.
> 
> What we see in gbp/scripts/dch.py in fixup_section() is:
> 
> 
> mainttrailer_opts = ['--nomainttrailer', '--mainttrailer', '-t']
> ...
> for opt in mainttrailer_opts:
> if opt in dch_options:
> break
> else:
> opts.append(mainttrailer_opts[0])
> 
> 
> which looks nice, except that I don't see how any of
> '--nomainttrailer', '--mainttrailer', '-t' would ever get into
> dch_options. (The only place where dch_options is set is in
> process_options() further down, and there only the command line
> options are used, and there's no trace of (no)mainttrailer anywhere.)
> 
> So in the end in fixup_section() we always end up in the else branch,
> which means that '--nomainttrailer' is appended and is therefore
> effectively hardcoded in a slightly complicated way :)
> 
> 
> If, as the piece of code above indicates, it should be possible to
> select between --nomainttrailer and --mainttrailer then gbp-dch
> probably either needs commandline options and config variables to
> allow it (hence adding to this old bug report) or it needs to read
> ~/.devscripts / use the dch settings. Or maybe there are other
> options.
> 
> (I guess hardcoding '--nomainttrailer' was not the plan as this could
> have been written in an easier way then it is currently done in
> fixup_section().)
> 
> I'd very much like to see the old behaviour of not touching the
> trailer (except for releases and new sections etc.) back one way or
> another.

(sorry for the delay, I'm not coming around with a fix yet but I wanted
at least comment that you hit a nail):

Agreed. This is clearly a regression. We only want to touch the trailer
in the cases you describe but also have #796913 fixed.
Cheers,
 -- Guido

Bug#854333: [git-buildpackage/master] GitRepository: shorten reflog message

[Guido Günther]

tag 854333 pending
thanks

Date:   Mon Feb 6 08:52:24 2017 +0100
Author: Guido Günther 
Commit ID: 80044e1655266ad30fe0e1c0f3ff4803a95d026e
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=80044e1655266ad30fe0e1c0f3ff4803a95d026e
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=80044e1655266ad30fe0e1c0f3ff4803a95d026e

GitRepository: shorten reflog message

Closes: #854333
Thanks: Chris Lamb for the report

  

Bug#766800: Accessibility: difficult movement with keyboard

[Vlad Orlov]

Control: tags -1 upstream fixed-upstream jessie
Control: forwarded -1 https://github.com/mate-desktop/mate-panel/issues/444
Control: fixed -1 1.14.1-1


Hi,

I guess this is what was reported upstream at [1]. If it's so, we have it
fixed - at least in Stretch (as it was fixed in version 1.14.1). So now
only Jessie is affected.


[1] https://github.com/mate-desktop/mate-panel/issues/444

Bug#854433: firebird3.0-server-core: Please document that this is the package needed to use the embedded mode

[Ben Longbons]

Package: firebird3.0-server-core
Version: 3.0.1.32609.ds4-13
Severity: normal

Dear Maintainer,

For people wanting to use firebird like sqlite3, they need this
"server" package, not just whatever client package. This should be
indicated in the various package descriptions.

Additionally, since most people will not be using *remote* servers, each
client package should have "Recommends: firebird3.0-server-core" and
"Suggests: firebird3.0-server". Note that not all clients necessarily
go through libfbclient2, but I don't know if any of those are in Debian,
or whether they support Embedded mode.

This is particularly important since all the documentation on the
internet only applies to firebird 2.5 and references a nonexistent
'libfbembed.so' (the equivalent is now 'libEngine12.so'), so
`apt-file search` isn't particularly helpful. Also, the error messages
if this package is missing are *very* unhelpful.

-Ben


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

Kernel: Linux 4.8.0-2-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 firebird3.0-server-core depends on:
ii  firebird3.0-common  3.0.1.32609.ds4-13
ii  firebird3.0-common-doc  3.0.1.32609.ds4-13
ii  libc6   2.24-9
ii  libfbclient23.0.1.32609.ds4-13
ii  libgcc1 1:7-20161201-1
ii  libib-util  3.0.1.32609.ds4-13
ii  libncurses5 6.0+20161126-1
ii  libstdc++6  7-20161201-1
ii  libtinfo5   6.0+20161126-1
ii  libtommath1 1.0-4

firebird3.0-server-core recommends no packages.

Versions of packages firebird3.0-server-core suggests:
pn  firebird3.0-server  

-- no debconf information

Bug#851287: [git-buildpackage/master] import_dsc: delay pristine-tar import to the very end

[Guido Günther]

tag 851287 pending
thanks

Date:   Tue Feb 7 07:27:43 2017 +0100
Author: Guido Günther 
Commit ID: ac343519d56c390c507528c01047b81be0e9
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=ac343519d56c390c507528c01047b81be0e9
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=ac343519d56c390c507528c01047b81be0e9

import_dsc: delay pristine-tar import to the very end

This makes sure we have a sane debian and upstream branch already so we
don't leave the repo in an inconsistent state in case of failure.

Closes: #851287

  

Bug#854432: [ntpdate] ntpdate-debian does not find pool entries exits with "no servers can be used"

[Dana Johnson]

Package: ntpdate
Version: 1:4.2.8p9+dfsg-2.1
Severity: normal
Tags: patch

--- Please enter the report below this line. ---
With ntp installed and /etc/default/ntpdate entry:
NTPDATE_USE_NTP_CONF=yes

The command: /usr/sbin/ntpdate-debian -v -q
gives:   no servers can be used, exiting

This is because ntpdate-debian is looking for server entries with:
sed -rne 's/^(servers?|peer)...

The attached patch adds pool to correctly pick up the pool entries
sed -rne 's/^(servers?|peer|pool)...

And a correct result from:
/usr/sbin/ntpdate-debian -v -q


--- System information. ---
Architecture: Kernel:   Linux 4.9.0-1-amd64

Debian Release: 9.0
  990 testing httpredir.debian.org   500 unstable
httpredir.debian.org   500 stable-updates  httpredir.debian.org   500
stable  security.debian.org   500 stable
httpredir.debian.org
--- Package information. ---
Depends(Version) | Installed
-+-===
netbase  | 5.4
libc6  (>= 2.17) | libssl1.1 (>= 1.1.0) |

Package's Recommends field is empty.

Package's Suggests field is empty.
diff --git a/debian/ntpdate-debian b/debian/ntpdate-debian
index e76d5ab..d9d1792 100644
--- a/debian/ntpdate-debian
+++ b/debian/ntpdate-debian
@@ -14,7 +14,7 @@ if [ "$NTPDATE_USE_NTP_CONF" = yes ]; then
 		fi
 	done
 	if [ -n "$file" ]; then
-		NTPSERVERS=$(sed -rne 's/^(servers?|peer)[[:space:]]+(-[46][[:space:]]+)?([-_.:[:alnum:]]+).*$/\3/p' "$file" | grep -v '^127\.127\.') || [ $? -le 1 ]
+		NTPSERVERS=$(sed -rne 's/^(servers?|peer|pool)[[:space:]]+(-[46][[:space:]]+)?([-_.:[:alnum:]]+).*$/\3/p' "$file" | grep -v '^127\.127\.') || [ $? -le 1 ]
 	fi
 fi
 

Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

[NIIBE Yutaka]

Hello,

Thank you very much for the discussion.  I appreciate the viewpoints
from users.  No, it's not frustrating at all.

Daniel Kahn Gillmor  wrote:
> Can we offer a user experience that doesn't involve them making a choice
> between two indistinguishable options?
>
> A few ideas (no idea how plausible they are to implement, or even
> whether they'd solve the problems people are having):
>
>  0) if pcscd is running and has claimed the smartcard, then by default
> disable ccid?
>
>  1) for each device that is detected by ccid, try to access it.  If it
> is not accessible because someone else has it locked, and pcscd
> appears to be running, and a similar-looking device is accessible
> through pcsc, then skip the device entirely without complaint.
>
>  2) revert whatever the change was in 2.1.18 (handling multiple cards?)
> that made things worse for people who had things working in 2.1.17
>
> Any other suggestions?

2) would be easy choice if any breaking is considered bad and that's the
highest priority.  I am sorry that I break this use case on GNU/Linux.
I thought I tested carefully, but my test coverage is apparently not
that large, I learned.

On GNU/Linux, use of PC/SC service is not recommended for OpenPGP card
(installing PC/SC is OK) and the use of different smartcards with PC/SC
(OpenPGP card together with other cards) requires struggle anyway, so, I
think that asking such users would be an option.

No, I don't say I won't fix this issue.  Surely, I will.

Currently, I am considering something like 1).



Some more information, from here.  Please skip.

> My only concern with this explanation is that most people (even those
> with smartcards!) have *no*idea* whether they "want to use PC/SC
> service."  They just bought a smartcard (or were given one by their
> employer or their government or their friend or whatever) and they know
> they're supposed to use it.

Yes.  This is an important point.

Unfortunately, I think that current situation of use of OpenPGP card is
somehow far from this.  Let me explain.

The situation is complicated becase only some limited card readers works
for OpenPGP card.  Since most users prefer longer key size of RSA these
days, the use of OpenPGP card requires tough condition to card reader.
Some workaround in the lower level of USB communcation for specific card
readers are implemented in the internal CCID driver, so, if the use if
for OpenPGP card, internal CCID driver is better option.

Please note that this is common:

A card reader itself works well on the machine, but OpenPGP card
with (common configuration of) RSA-4096 doesn't work with a reader.
While --card-status works, decryption fails.

I think that something like this is common problem in smartcard
industry.  Current industrial practice seems to be a smartcard requires
specific card reader and vendor's offering application specific driver
which doesn't use general purpose PC/SC service.  Ideally, such
fragmentation should be avoided and it would be better to put all
lower-level knowledge/workaround to PC/SC service, so that all
application can be share common ground.  But it seems going
another direction.

Perhaps, card + reader can not be abstracted well.


And I think that there are two distinct use cases.

(1) Smartcard is given by external entity to user.  He has a little
interest in detail.  The purpose is "just use it".

(2) User cares a lot on her privacy, and that is the reason why she
starts to use smartcard.

It would make sense to put priority to the use case of (1), because
there are more users in this situation.  And since PC/SC serivice tries
to support more card readers, which are listed in
/etc/libccid_Info.plist, it might be a natural choice for a user in this
situation to prefer PC/SC even if he only uses OpenPGP card.

I agree that it is best if we don't need to ask users of (1) to put
"disable-ccid" in his configuration file.  So, I will try, but I don't
have a good solution at hand, right now.

Please note that current default of scdaemon is for the use case of (2).
And I recommend use of the internal CCID driver, a dedicated card reader
access implementation specific to OpenPGP card.  For the readers which
are listed in /lib/udev/rules.d/60-scdaemon.rules, it is easy to use (I
mean, no other configuration needed).  But user needs her own udev rules
if her reader is not listed there.
-- 

Bug#851332: [Pkg-xfce-devel] Bug#851332: Bug#851332: xfce4-cpugraph-plugin: insane CPU use

[Adam Borowski]

On Sun, Jan 15, 2017 at 10:38:57PM +0100, Yves-Alexis Perez wrote:
> On Sun, 2017-01-15 at 17:12 +0100, Adam Borowski wrote:
> > Plasma Shock: https://www.xfce-look.org/p/1157147/
> > 
> > Somehow, the reproducibility is weird: right now I get around 1-2% when
> > idle, 8-14% when busy, but I've noticed this problem many times in the past.
> 
> Can you try with the default Xfce theme?

Indeed, theme seems to make a major difference:
xfce-*: 0.3% idle, 0.7% busy
Adwaita: 1.7% idle, 2.5% busy
Plasma Shock minutes ago, before testing: 7% idle, 23% busy
Plasma Shock right now: 1.7% idle, 2.5% busy

Although, as it dropped after changing themes, it's possible the above tests
are meaningless as they reflect the reduced usage.  I haven't yet managed to
find out how to trigger the problem on demand.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#852253: kryo-serializers: no longer FTBFS in stretch

[tony mancill]

Source: kryo-serializers
Followup-For: Bug #852253

I am not able to reproduce this bug and believe it can be closed.  As
Emmanuel suggests, it was addressed with the migration of libkryo-java
2.20-6 into testing on January 23rd [1].  Reproducible builds shows it
building successfully in unstable [2] now (although it was failing at
the time of the bug report).  And the most recent build in testing [3]
was on January 22nd, before the update of libkryo-java was available.

Thank you,
tony

[1] https://tracker.debian.org/news/834843
[2] 
https://tests.reproducible-builds.org/debian/rb-pkg/testing/amd64/kryo-serializers.html
[3] 
https://tests.reproducible-builds.org/debian/rb-pkg/testing/amd64/kryo-serializers.html

Bug#854431: dehydrated: please chown/chmod *.pem to root:ssl-cert

[Adam Borowski]

Package: dehydrated
Version: 0.3.1-2
Severity: wishlist

Hi!
Currently, dehydrated creates both the parent directories and certs/privkeys
it outputs with permissions for root only.  This works for daemons that load
everything as root (apache, etc) but not for those that drop privileges early
(exim, postgres, etc).

As far as I know, the recommended way to do so is adding the daemons to
group ssl-cert which is created by some (but not all) ssl key generating
packages; those which do make /etc/ssl/private/ readable by that group.

I think it'd be a good idea for dehydrated to support this group by default:
* directories as root:ssl-cert mode 710
* .pem files as root:ssl-cert mode 640


Meow!
-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: x32 (x86_64)

Kernel: Linux 3.14.77-vs2.3.6.15-x32 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dehydrated depends on:
ii  ca-certificates  20161130
ii  curl 7.52.1-2
ii  openssl  1.1.0d-2

dehydrated recommends no packages.

dehydrated suggests no packages.

-- no debconf information

Bug#854079: firefox-esr: firefox dies immediately on arm64

[Mike Hommey]

Control: severity -1 serious

On Mon, Feb 06, 2017 at 01:34:49PM +, Riku Voipio wrote:
> Mike Hommey wrote:
> > That's fixed in 47.5.0esr-3. Can you check if you still get crashes with
> > that version?
> 
> Thanks Mike for looking into this.
> 
> Indeed firefox-esr doesn't segfault in jemalloc anymore. However, I get a new
> crash - I assume Aaro will get the same.
> 
> Looking at 
> http://sources.debian.net/src/firefox-esr/45.7.0esr-1/js/src/jit/none/AtomicOperations-none.h/
> AtomicOperations-ppc.h appears to include correct and portable implementation
> (assuming gcc 4.6+). It's not clear to me what is the value of the *-none.h
> file that only crashes. Using the -ppc.h instead can't make things worse.

Okay, that one was fixed upstream in
https://bugzilla.mozilla.org/show_bug.cgi?id=1257055

Can you try applying the patch there and see how things go from there?
(I'd rather avoid doing multiple uploads if it turns out not to be
sufficient, which I suspect might be the case).

Bumping severity because this pretty much makes the package unusable on
a release architecture.

Mike

Bug#836786: diffoscope: Differences between long lines are missing in HTML format

[Daniel Shahaf]

Chris Lamb wrote on Tue, Feb 07, 2017 at 15:58:40 +1300:
> Version: 62
> 
> Emanuel Bronshtein wrote:
> 
> > The packages "python-hypothesis" & "cppformat" & "python-xmp-toolkit" &
> > "python-mne" from unstable/amd64 have long line that contain JavaScript
> > code, the HTML format don't contain the differences between the lines (it
> > cut the line by scissors symbol instead)
> >
> > searchindex.js:
> > 
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/python-hypothesis.html
> 
> I'm not actually seeing this anymore; I believe it was fixed by Daniel
> Shahaf in version 62. :)

I don't think so: my patch would have still shown the difference with
an "ordering differences only" comment in the output.

Cheers,

Daniel

Bug#851612: CVE-2017-0381

[Ron]

On Mon, Feb 06, 2017 at 08:45:01PM +0100, Julien Cristau wrote:
> On Tue, Jan 31, 2017 at 15:32:13 +1030, Ron wrote:
> 
> > I've CC'd -release, to see what they'd prefer we do for Jessie.
> > It might be that the best option here is to just put something later
> > in -bpo, and if people are paranoid, they can choose to use that?
> > 
> I'd prefer to review patches rather than walls of text that refer to
> changes in the abstract, since that makes it easier to know what you're
> talking about.  But based on what I've read it doesn't sound like jessie
> needs an update?

Unless there's a surprise reveal about the real severity, I think it
would be theatre to push just this patch and not the similar things
fixed without fanfare in 1.1.4 as an SPU - and I don't think 1.1.4 is
in the usual comfort zone for an SPU, or that any of these are known
to be serious enough to warrant making an uncomfortable exception.

Salvatore asked me to look at our options, so I gave enough context
for people to do their own detailed assessment if they feel they want
to disagree.  If someone is really worried about being exposed by 1.1
in Jessie, they'd be much better off with a -bpo of what's in Stretch,
or a -sloppy backport of 1.1.4, than with just this one issue patched.

If we later find any of them are more seriously exploitable, we can
put a targetted fix through -security or -p-u for just that, but we'd
have already done that if the upstream analysis thought they were.


It looks like the language and severity of the original CVE has been
toned down now based on the analysis given here anyway - so even the
"it would be good PR to show this as fixed in Jessie" argument isn't
as strong as it was a week ago when I originally replied.

  Thanks!
  Ron

Bug#854430: fritzing: Fritzing fails to find core parts

[Neil Roeth]

Package: fritzing
Version: 0.9.3b+dfsg-4
Severity: grave

Similar to 847655, while displaying a screen that says, "loading bin
'Core Parts'", Fritzing displays another screen that says, "Cannot read
file screw_terminal_2_3.5mm.fzp: No such file or directory.".  That file
exists in /usr/share/fritzing/parts/core/.  After clicking OK on that
screen, Fritzing displays a screen titled "Unable to find the following
143 parts:".  I randomly selected several and all were in
/usr/share/fritzing/parts/core.  After continuing from there, almost no
parts are displayed.

Directly calling /usr/bin/fritzing instead of the wrapper
/usr/bin/Fritzing generates an error that it cannot find the file
/usr/share/fritzing/parts/core/bins/core.fzb.  That file is actually in
/usr/share/fritzing/parts/bins/core.fzb.  Again, continuing results in
almost no parts displayed.

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

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

Versions of packages fritzing depends on:
ii  fritzing-data 0.9.3b+dfsg-4
ii  libc6 2.24-9
ii  libgcc1   1:6.3.0-6
ii  libgit2-240.24.5-1
ii  libgl1-mesa-glx [libgl1]  13.0.4-1
ii  libqt5concurrent5 5.7.1+dfsg-3+b1
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5network55.7.1+dfsg-3+b1
ii  libqt5printsupport5   5.7.1+dfsg-3+b1
ii  libqt5serialport5 5.7.1~20161021-2
ii  libqt5sql55.7.1+dfsg-3+b1
ii  libqt5sql5-sqlite 5.7.1+dfsg-3+b1
ii  libqt5svg55.7.1~20161021-2
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libqt5xml55.7.1+dfsg-3+b1
ii  libstdc++66.3.0-6
ii  zlib1g1:1.2.8.dfsg-5

fritzing recommends no packages.

Versions of packages fritzing suggests:
ii  fritzing-parts  0.9.3b-1

-- no debconf information


-- 
Neil Roeth

Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

[Daniel Kahn Gillmor]

On Mon 2017-02-06 19:55:58 -0500, Antoine Beaupré wrote:
> the daemon stopped working again - even with disable-ccid:
>
> $ LANG=C gpg --card-status
> gpg: selecting openpgp failed: No such device
> gpg: OpenPGP card not available: No such device
>
> i got a different error now:
>
> fév 06 19:45:29 curie gpg-agent[1643]: gpg-agent (GnuPG) 2.1.18 starting in 
> supervised mode. 
> fév 06 19:45:29 curie gpg-agent[1643]: using fd 3 for std socket 
> (/run/user/1000/gnupg/S.gpg-agent) 
> fév 06 19:45:29 curie gpg-agent[1643]: using fd 4 for ssh socket 
> (/run/user/1000/gnupg/S.gpg-agent.ssh) 
> fév 06 19:45:29 curie gpg-agent[1643]: using fd 5 for extra socket 
> (/run/user/1000/gnupg/S.gpg-agent.extra) 
> fév 06 19:45:29 curie gpg-agent[1643]: using fd 6 for browser socket 
> (/run/user/1000/gnupg/S.gpg-agent.browser) 
> fév 06 19:45:29 curie gpg-agent[1643]: listening on: std=3 extra=5 browser=6 
> ssh=4 
> fév 06 19:45:29 curie gpg-agent[1643]: scdaemon[1645] pcsc_establish_context 
> failed: no service (0x8010001d) 
>
> pcsc_establish_context failed: no service (0x8010001d) 
>
> This is strange, because there hasn't been a change in the gpg software
> since my last report, and I *thought* I had this fixed with the ccid
> workaround. But it seems that doesn't work anymore. :(
>
> I have tried uninstalling pcscd, running the command again, same result.
>
> Now the oddest thing is - installing pcscd again fixed the problem.
>
> No idea what's going on here.

This sounds to me like pcscd crashed or otherwise terminated.

afaict, the two options are:

 * pcsc
 * ccid

the workaround i've seen mooted here of "disable-ccid" means that all
your eggs are in the pcsc basket.  If pcscd fails or drops the card or
whatever, then scdaemon can't fall back to ccid.

did you have disable-ccid set in scdaemon.conf?

does this line of thinking make sense?

 --dkg


signature.asc
Description: PGP signature

Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

[Daniel Kahn Gillmor]

On Mon 2017-02-06 14:39:34 -0500, NIIBE Yutaka wrote:
> I think that an explanation like following is good.
>
>   If you want to use PC/SC service, please add 
>
>   disable-ccid
>
> in .gnupg/scdaemon.conf.  Or do:
>
>   echo disable-ccid:0:1 | gpgconf --change-options scdaemon


My only concern with this explanation is that most people (even those
with smartcards!) have *no*idea* whether they "want to use PC/SC
service."  They just bought a smartcard (or were given one by their
employer or their government or their friend or whatever) and they know
they're supposed to use it.

Can we offer a user experience that doesn't involve them making a choice
between two indistinguishable options?

A few ideas (no idea how plausible they are to implement, or even
whether they'd solve the problems people are having):

 0) if pcscd is running and has claimed the smartcard, then by default
disable ccid?

 1) for each device that is detected by ccid, try to access it.  If it
is not accessible because someone else has it locked, and pcscd
appears to be running, and a similar-looking device is accessible
through pcsc, then skip the device entirely without complaint.

 2) revert whatever the change was in 2.1.18 (handling multiple cards?)
that made things worse for people who had things working in 2.1.17

Any other suggestions?

Thanks for looking into this, gniibe!  Sorry if it's frustrating, but
your expertise in thinking through these issues is very much
appreciated.

 --dkg



signature.asc
Description: PGP signature

Bug#797525: diffoscope: provide a way to ignore all differences in control.tar

[Chris Lamb]

Hi Jakub,

> I want to use diffoscope to compare two "Multi-Arch: same" debs of the 
> same version but different architecture, to see differences that will 
> cause co-installation conflicts.

Could you provide (or link to) some example .debs for this? :)

The --fuzzy-threshold option landed in diffoscope 32 (Sep 2015) so it
would be nice to fix this last bit up for you.


Regards,

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

Bug#849425: diffoscope: test_openssh_pub_key.test_diff fails on jessie after ssh-keygen output format change

[Chris Lamb]

Version: 68

Brett Smith wrote:

> On jessie, test_openssh_pub_key.test_diff fails

I believe this was fixed by Mattia and was released in version 68.


Regards,

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

Bug#835641: diffoscope: tracebacks when comparing directories to non-directories

[Chris Lamb]

tags 835641 + pending
thanks

Fixed in Git:

  https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=db37e55


Regards,

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

Bug#842250: diffoscope: crashes on NetBSD's base.tgz

[Chris Lamb]

Chris Lamb wrote:

> tags 842250 + unreproducible
> [...]
> Thanks for that. However, I can't seem to reproduce any crash:
> 
> $ wget 
> https://tests.reproducible-builds.org/netbsd/artifacts/b{1,2}/amd64/binary/sets/base.tgz
>  

Holger, can you still reproduce? If not, I think we should close this
bug :)


Regards,

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

Bug#836786: diffoscope: Differences between long lines are missing in HTML format

[Chris Lamb]

Version: 62

Emanuel Bronshtein wrote:

> The packages "python-hypothesis" & "cppformat" & "python-xmp-toolkit" &
> "python-mne" from unstable/amd64 have long line that contain JavaScript
> code, the HTML format don't contain the differences between the lines (it
> cut the line by scissors symbol instead)
>
> searchindex.js:
>   
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/python-hypothesis.html

I'm not actually seeing this anymore; I believe it was fixed by Daniel
Shahaf in version 62. :)


Regards,

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

Bug#840482: diffoscope: error at startup: AttributeError: undefined symbol: archive_errno

[Chris Lamb]

Mihai - Catalin Stefan wrote:

> > AttributeError: /usr/bin/python3: undefined symbol: archive_errno

Are you still seeing this with recent versions? If so, I wonder if this
is related to conflicts between the pip and package-installed versions
of libarchive-c.


Regards,

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

Bug#854314: youtube-dl: 'Signature extraction failed' on some YouTube videos

[Rogério Brito]

Hi.

I'm using my phone to answer, so I will be brief.

I intend to upload a new version of youtube-dl this week.

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

On Feb 6, 2017 16:30, "Jack Henschel"  wrote:

> package youtube-dl
> severity 854314 grave
>
> I just had the same issue, looked at the upstream bug tracker and found
> the issue was already reported and even resolved:
> 11663: https://github.com/rg3/youtube-dl/issues/11663
> 11664: https://github.com/rg3/youtube-dl/issues/11664
>
> This commit fixes the issue:
> https://github.com/rg3/youtube-dl/commit/d1aeacd9bfe12bdf064df77ccf
> 8bd30f1723
> >  def extract_object(self, objname):
> > obj = {}
> > obj_m = re.search(
> > -(r'(?:var\s+)?%s\s*=\s*\{' % re.escape(objname)) +
> > +(r'(? >  r'\s*(?P([a-zA-Z$0-9]+
> \s*:\s*function\(.*?\)\s*\{.*?\}(?:,\s*)?)*)' +
> >  r'\}\s*;',
> >  self.code)
>
> I consider the severity of this bug to be grave ("makes the package in
> question unusable or mostly so"), because (as the name suggests) the main
> purpose of youtube-dl is downloading content from YouTube and this feature
> is currently only working on some videos. This is not acceptable for the
> release of Stretch.
> Due to the simple nature of the fix backporting should not be a problem.
>
> Greetings
> Jack
>
>
>

Bug#854289: newbiedoc: Too outdated for being useful

[Chris Lamb]

Adrian Bunk wrote:

> But as documentation for newbies (or anyone else) it is
> no longer suitable.

I agree. Any objection to removing this from Debian...?


Regards,

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

Bug#835641: diffoscope: traceback when comparing dangling symlink to directory

[Chris Lamb]

retitle 835641 diffoscope: tracebacks when comparing directories to 
non-directories
thanks

This is actually bigger than just dangling symlinks:

$ diffoscope /etc/cron.d/ /etc/fstab --no-progress
cmp: /etc/cron.d/: Is a directory
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 268, in main
sys.exit(run_diffoscope(parsed_args))
  File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 244, in 
run_diffoscope
parsed_args.path1, parsed_args.path2)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
61, in compare_root_paths
return compare_files(file1, file2)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
76, in compare_files
return file1.compare_bytes(file2, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
line 165, in compare_bytes
return compare_binary_files(self, other, source)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
99, in compare_binary_files
source=[file1.name, file2.name], has_internal_linenos=True)
  File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 120, in 
from_command
difference = Difference.from_feeder(feeder1, feeder2, path1, path2, *args, 
**kwargs)
  File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 70, in 
from_feeder
unified_diff = diff(feeder1, feeder2)
  File "/usr/lib/python3/dist-packages/diffoscope/diff.py", line 282, in diff
fd_from_feeder(feeder1, end_nl_q1, fifo1)
  File "/usr/lib/python3.5/contextlib.py", line 136, in helper
return _GeneratorContextManager(func, args, kwds)
  File "/usr/lib/python3.5/contextlib.py", line 38, in __init__
self.gen = func(*args, **kwds)
  File "/usr/lib/python3/dist-packages/diffoscope/diff.py", line 238, in 
fd_from_feeder
t.join()
  File "/usr/lib/python3/dist-packages/diffoscope/diff.py", line 227, in join
raise ex
  File "/usr/lib/python3/dist-packages/diffoscope/diff.py", line 213, in run
super().run(*args, **kwargs)
  File "/usr/lib/python3.5/threading.py", line 862, in run
self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3/dist-packages/diffoscope/diff.py", line 197, in feed
end_nl = feeder(f)
  File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 191, in 
feeder
raise subprocess.CalledProcessError(returncode, command.cmdline(), 
output=command.stderr.getvalue())
subprocess.CalledProcessError: Command '['xxd', '/etc/cron.d/']' returned 
non-zero exit status 2



Regards,

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

Bug#854429: task-desktop: Please allow Wayland systems without X.Org

[intrigeri]

Package: task-desktop
Version: 3.39
Severity: wishlist
User: tails-...@boum.org
Usertags: misc-reported

Hi,

I'm using Wayland, and I would like to remove X.Org from my system.
I don't care much really, for my own use case: I can live with the
disk space cost. But once GNOME switches to Wayland by default in
Debian (uninformed guess: in Buster), perhaps we can trim down a bit
the (default) desktop installation images by not including X.Org
in there. Removing xorg, xserver-xorg and the packages automatically
installed because of them saves 8 MB on my system, so granted that's
not much and may not be worth the effort.

I see:

  $ aptitude why xorg
  i   task-gnome-desktop Depends task-desktop
  i A task-desktop   Depends xorg   

What can possibly go wrong™ if we replaced:

  Depends: tasksel (= 3.39), xorg, xserver-xorg-video-all, 
xserver-xorg-input-all, desktop-base

with something like:

  Depends: tasksel (= 3.39), xorg | wayland, xserver-xorg-video-all | wayland, 
xserver-xorg-input-all | wayland, desktop-base

?

FWIW, task-desktop seems to have no reverse-build-deps, so this should
not affect buildds (that don't prefer the first alternative) for
existing packages.

Cheers,
-- 
intrigeri

Bug#848903: metastudent: autopkgtests fail since 2016-12-05

[merlettaia]

Hi Andreas,

I've managed to finish patch for metastudent (I've checked it several times
and tried to make it to be compatible with old version of blast as well,
although I didn't checked "studentC" part with legacy blast, only with
latest version).

Some details on how I checked: I've run metastudent with --keep-temp part,
after that looked at contents of temporary directory. If all goes fine,
this directory contains 3 directories - "groupA", "groupB" and "groupC".
They contain temporary files produced during stages A, B and C.
If all goes fine, they contain actual data (graph nodes with their names,
etc.), if not, these files are not empty, but contain just a template with
no data in it.
Results from patched metastudent and latest blast look similar to unpatched
metastudent+legacy blast with the same version of metastudent-data package.
Numeric results look similar, but I assumed that if they differ, the reason
must be a difference in blast and legacy-blast implementation and didn't
try to fix if some of numbers differ.

I assume that this patch makes metastudent work with blast+ correctly.

Tanya.

2016-12-20 22:14 GMT+03:00 Andreas Tille :

> Hi Graham,
>
> thanks for the bug reports.
>
> On Tue, Dec 20, 2016 at 06:58:23PM +0200, Graham Inggs wrote:
> > Metastudent 2.0.1-3 has been consistently failing its autopkgtests
> > since 2016-12-05 [1].
> >
> > This corresponds to the upload of ncbi-tools6 6.1.20160908-1.
> > Previous tests were successful with ncbi-tools6 6.1.20120620-12.
> > I'm not sure if this is relevant.
>
> That's most probably the very same issue as #848394.  Tanya intends to
> investigate into this and I guess she will come up with some solution.
> Tanya, feel free to ask here for further insigt if you might face any
> blockers.
>
> Kind regards
>
>   Andreas.
>
> --
> http://fam-tille.de
>



-- 
Best wishes,
Tanya.

Bug#854428: Package: installation-reports

[Alex Sitnik]

Package: installation-reports

Boot method: USB
Image version: 
http://cdimage.debian.org/cdimage/stretch_di_rc2/amd64/iso-cd/debian-stretch-DI-rc2-amd64-xfce-CD-1.iso
Date: 2017.02.06 (2017 Feb 06) around 16:00 UTC

Machine: ASUS G752VY
Processor: 8x Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
Memory: 16373MB (MB used)
Partitions:
Filesystem Type 1K-blocks    Used Available Use% Mounted on
udev   devtmpfs   8182040   0   8182040   0% /dev
tmpfs  tmpfs  1637380    9772   1627608   1% /run
/dev/nvme0n1p3 ext4  15314280 3659468  10857168  26% /
tmpfs  tmpfs  8186892   0   8186892   0% /dev/shm
tmpfs  tmpfs 5120   4  5116   1% /run/lock
tmpfs  tmpfs  8186892   0   8186892   0% /sys/fs/cgroup
/dev/nvme0n1p2 ext2    737776   23200    677100   4% /boot
/dev/nvme0n1p5 ext4 197961136  312956 187522612   1% /home
/dev/nvme0n1p1 vfat    244988 240    244748   1% /boot/efi
tmpfs  tmpfs  1637376   4   1637372   1% /run/user/111
tmpfs  tmpfs  1637376  20   1637356   1% /run/user/1000
Output of lspci -knn (or lspci -nn):

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

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

Comments/Problems:

(00) First of all thank you VERY MUCH for doing an AMAZING JOB with Debian 
Stretch RC02 installer. Now it loads/installs faster [than Jessie 8.5], 
supports NVMe 2.0 drives “out of the box” and the OS loads right after the 
installation without having to use `mount --rbind` and backports. General 
suggestion is to add support of the Nvidia graphics driver (as detailed below 
pp.02,02.b).

(01) WiFi Network card was detected, but requested an external drive for 
installation (no drivers were found). Therefore, no wifi was installed during 
initial setup

(02) In “graphical expert” mode there were absent modules for Nvidia card; 
therefore, during the first boot after installation the system hanged/freezed 
(it uses nouveau driver by default which is conflicting with Nvidia); after 2nd 
reboot after install at the GRUB screen, I had to (a) manually set `nomodeset 
3`, (b) boot, log in and install `nvidia-detect` package, (c) launch it 
(detected correctly! In Jessie 8.5-8.7 it has never detected the card correctly 
with its name) (d) install `nvidia-driver` (with boot partition `rw`) (e) 
reboot and… it worked right away on all 3 monitors!!!

(02.b) My suggestion is to do either of these: (a) add the `nvidia-detect` 
(`sudo apt-get install nvidia-detect`) package into the installer, if the 
nvidia is detected, prompt to install `nvidia-driver` (`sudo apt-get install 
nvidia-driver`) during setup; or (b) add `Nvidia` installation module to do all 
that if/when checked. There are plenty of Nvidia folks out there!!!

(03) During hard drive partitioning, it has detected all the pre-partitioned 
drives correctly; however, when I was clicking each drive to set the mount 
point, it was showing its file system of a previous partition, but not the 
seletected partition. i.e. it shows the fs correctly on the initial list, but 
when double click on it to actually modify it, the fs changes to the value of 
the element’s preceding/previous partition – as if the detailed editor starts 
from [0] but the list starts from [1], please check.

(04) Clock/time zone setup – after setting up the UTC clock, it has prompted 
about the clock setup again during the installation process, and asked if I 
have UTC. Yes, I have already had UTC enabled and provided with a default sync 
URL.

Thank you in advance for considering improvements and enjoy your day/night.

-
With best regards,Alex Sitnik
 UK: 483 Green Lanes, London, N13 4BS HK: 1104 11/F Crawford House, 70 Queen 's 
Rd. Central, Central
  W: http://www.sitnik.co.uk/
   E: a...@sitnik.co.uk
_Please consider the 
environment before printing this e-mail.
Note: The contents of this electronic mail (email) and any attachments are 
confidential and protected by law. It is directed only to the addressee; Third 
parties are not authorized to inspect this email and any attachments. If you 
are not the addressee of this email, it is prohibited and illegal to copy and / 
or to transmit the contents of this email, or take action with respect to the 
contents of this mail. If you are not the intended recipient or have received 
this email in error, please notify us immediately and destroy this e-mail with 
attachments. Thank you for your support.

Bug#852135: debdelta: installation leaves gpg-agent process running

[Paul Wise]

Control: fixed -1 debdelta/0.58exp

On Sat, 21 Jan 2017 21:41:02 +0100 Andreas Beckmann wrote:

> This agent is automatically started by the gpg command in the postinst script
> unfortunately there is no option to automatically terminate such a temporary
> agent. But you could add the following command to your postinst,
> directly after the gpg command, to terminate the agent:
> 
> gpgconf --homedir ${GPG_HOME} --kill gpg-agent || true

I noticed this is fixed in experimental (but there was a typo in the
changelog), do you intend to get this fixed in stretch too?
If not, it will cause debdelta to be removed from stretch soon.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#817193: diffoscope: failing tests: test_gzip.py::test_metadata, test_ipk.py::test_metadata, test_java.py::test_diff

[Chris Lamb]

Hi Zbigniew,

> diffoscope: failing tests: test_gzip.py::test_metadata, 
> test_ipk.py::test_metadata, test_java.py::test_diff

Are you still any of these test failures with a recent diffoscope
version? We have made a few locale changes recently so its likely
that at least some of these are fixed.

Please reply with exactly which you are seeing, preferably with an
updated traceback, etc.


Many thanks,

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

Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

[Antoine Beaupré]

the daemon stopped working again - even with disable-ccid:

$ LANG=C gpg --card-status
gpg: selecting openpgp failed: No such device
gpg: OpenPGP card not available: No such device

i got a different error now:

fév 06 19:45:29 curie gpg-agent[1643]: gpg-agent (GnuPG) 2.1.18 starting in 
supervised mode. 
fév 06 19:45:29 curie gpg-agent[1643]: using fd 3 for std socket 
(/run/user/1000/gnupg/S.gpg-agent) 
fév 06 19:45:29 curie gpg-agent[1643]: using fd 4 for ssh socket 
(/run/user/1000/gnupg/S.gpg-agent.ssh) 
fév 06 19:45:29 curie gpg-agent[1643]: using fd 5 for extra socket 
(/run/user/1000/gnupg/S.gpg-agent.extra) 
fév 06 19:45:29 curie gpg-agent[1643]: using fd 6 for browser socket 
(/run/user/1000/gnupg/S.gpg-agent.browser) 
fév 06 19:45:29 curie gpg-agent[1643]: listening on: std=3 extra=5 browser=6 
ssh=4 
fév 06 19:45:29 curie gpg-agent[1643]: scdaemon[1645] pcsc_establish_context 
failed: no service (0x8010001d) 

pcsc_establish_context failed: no service (0x8010001d) 

This is strange, because there hasn't been a change in the gpg software
since my last report, and I *thought* I had this fixed with the ccid
workaround. But it seems that doesn't work anymore. :(

I have tried uninstalling pcscd, running the command again, same result.

Now the oddest thing is - installing pcscd again fixed the problem.

No idea what's going on here.

A.
-- 
Il n'existe aucune limite sacrée ou non à l'action de l'homme dans
l'univers. Depuis nos origines nous avons le choix: être aveuglé par
la vérité ou coudre nos paupières.
- [no one is innocent]

Bug#827222: diffoscope: Support a timeout on the individual commands invoked by diffoscope

[Chris Lamb]

tags 827222 + wontfix
thanks

Hi Ed,

> diffoscope: Support a timeout on the individual commands invoked
> by diffoscope

Firstly, thanks for the report. I can certainly understand that it can
be frustrating when diffoscope times out. :/

However, having an individual timeout on the invoked commands means
that the generated reports will sometimes contain the extra diff data
and sometimes not.

This non-determinism is not a big problem from a pure reproducibility point
of view, but IMHO developer tools should contain as little "magic" as possible
and — above all — should produce entirely consistent output. For example. I can
imagine it being even more frustrating to be grepping for a particular string
in the output for it to sometimes appear and sometimes not depending on CPU
load, wasting precious time and cognitive load.

Thus, I am marking this as wontfix.

(If it helps, I notice that you reported this against diffoscope 54. In the
meantime, we have improved the performance of diffoscope quite considerably
so these timeouts are far less common.)


Regards,

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

Bug#850791: diff output in machine-readable format

[Chris Lamb]

tags 850791 + pending
thanks

Fixed in Git:

   
https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=c601f2d23450cf54dbe80af68700a449ba0e32a8


Regards,

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

Bug#854427: jdupes: Segmentation fault

[Joao Eriberto Mota Filho]

Package: jdupes
Version: 1.7-1
Severity: important
Tags: upstream

The jdupes produces segmentations faults when doing some operations.
This issue was verified and reported to upstream here[1][2].

[1] https://github.com/jbruchon/jdupes/issues/33
[2] https://github.com/jbruchon/jdupes/issues/34

The solution for this issue was fix string_malloc()'s free list
functionality[3].

[3] 
https://github.com/jbruchon/jdupes/commit/1498a04e2ad5ba6cef6e94c5f64408d35670f7b8

So, this bug was already fixed in upstream.

Eriberto

Bug#854426: python3-usb: Device.attach_kernel_driver should probably the release interfaces first

[Celelibi]

Package: python3-usb
Version: 1.0.0-1
Severity: minor

Dear Maintainer,

When trying to end properly a program, I try to reattach the kernel
driver to the device. However, this fails if one interface is still
claimed by the program.

Sice pyusb take care of claiming the interfaces, it should probably also
take care of releasing them. Otherwise, calling
device.attach_kernel_device always fail with a "busy" error.

Best regards,
Celelibi

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages python3-usb depends on:
ii  libusb-1.0-0  2:1.0.21-1
pn  python3:any   

python3-usb recommends no packages.

python3-usb suggests no packages.

-- no debconf information

Bug#854425: Some of the paths mentioned are wrong on the man page

[積丹尼 Dan Jacobson]

Package: file
Version: 1:5.29-3
Severity: wishlist
File: /usr/share/man/man1/file.1.gz

Some of the paths mentioned are wrong.
E.g.,

$ find /usr/share/*/magic* -type f -ls
   298977 28 -rw-r--r--   1 root root26353  2月  6 15:19 
/usr/share/mime/magic

is not mentioned.

Bug#854423: Does not work on IPv6-only networks

[Steve McIntyre]

On Tue, Feb 07, 2017 at 12:39:23AM +0100, Axel Beckert wrote:
>Control: retitle -1 wicd: Does not work on IPv6-only networks
>Control: forcemerge 854176 -1
>
>Hi Steve,
>
>Steve McIntyre wrote:
>> I found this over the weekend at FOSDEM.
>
>You're not the only one: https://bugs.debian.org/854176 :-)

ACK. When I first looked for an existing bug, that wasn't there... :-)

>Merging these two bug reports.
>
>> I've dug into this, and I can see why. If DHCP doesn't return a v4
>> lease on a connection attempt (dhcp_failed), it aborts the
>> connection.
>
>Same question to you as to the other reporter: Have you tried to
>configure a static IPv4 dummy address as workaround? (Just out of
>curiosity if that's a workaround which could be recommended until
>the issue is fixed properly.)

Ah, didn't think of that. That's a possible thing to try,
yes. As/when/if I get the time to play with this again (maybe on a
separate test network at home), I'll give that a try.

>> I've started to hack on this a little bit over the weekend to see if
>> there's an easy fix (if no v4 lease acquired, check to see if a
>> global v6 address has been assigned),
>
>Much appreciated!
>
>> but I ran out of time to test this properly.
>
>Understandable. FOSDEM is always too short and there's too much to
>see. :-)

*grin* Exactly.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
The two hard things in computing:
 * naming things
 * cache invalidation
 * off-by-one errors  -- Stig Sandbeck Mathisen

Bug#852639: [Pkg-tigervnc-devel] Bug#852639: tigervnc-standalone-server: mouse pointer stuck in upper left corner

[Joachim Falk]

Hi all,

Am 05.02.2017 um 23:27 schrieb Joachim Falk:
> Hi Ola,
> 
> Am 05.02.2017 um 22:39 schrieb Ola Lundqvist:
>> Hi
>>
> || For context:
>>> So, it seems to be a regression with the combination of Xorg 1.19 in stretch
>>> and the VNC patch to it. Ola, where did you get this patch? If I remember
>>> correctly, Xorg 1.19 is not officially supported for TigerVNC 1.7.
>> I think it was from this source:
>> https://lists.x.org/archives/xorg-devel/2016-October/051482.html
> I have just checked. We have the same patch as is provided by
> tigervnc master. We also seem to apply all patches from tigervnc
> master intending to get Xorg 1.19 going. Next, one should check
> if this is also a regression with tigervnc master concerning
> buggy remote cursor support with the Xorg 1.19 server.
I have just backported a relevant patch from master. This should
fix the problem. Please test the preview debs under the following URL:
  https://xamane.jfalk.de/dists/homebrew-stretch/selfmade/binary-amd64
The fix should be in tigervnc-standalone-server_1.7.0+dfsg-7_amd64.deb.

Regards,
Joachim Falk




signature.asc
Description: OpenPGP digital signature

Bug#848764: (no subject)

[Rebecca N. Palmer]

Control: tags -1 patch

Three patches because this is logically three bugs, though it's filed as 
two upstream:
https://github.com/Theano/Theano/issues/5494
https://github.com/Theano/Theano/issues/5396
First patch taken from upstream 
https://github.com/Theano/Theano/commit/e8e01f4e0da83d038b244cd5dcec4f0d3f6c0777
 
by chinnadhurai

(I've only tried these tests, not a full build; I can't reproduce the
other three failures reported in upstream 5396)

--- a/theano/sparse/tests/test_sp2.py
+++ b/theano/sparse/tests/test_sp2.py
@@ -61,7 +61,7 @@ class PoissonTester(utt.InferShapeTester):


 class BinomialTester(utt.InferShapeTester):
-n = tensor.scalar()
+n = tensor.scalar(dtype='int64')
 p = tensor.scalar()
 shape = tensor.lvector()
 _n = 5
--- a/theano/tensor/tests/test_elemwise.py
+++ b/theano/tensor/tests/test_elemwise.py
@@ -414,7 +414,11 @@ class test_CAReduce(unittest_tools.InferShapeTester):
 zv = numpy.bitwise_or.reduce(zv, axis)
 elif scalar_op == scalar.and_:
 for axis in reversed(sorted(tosum)):
-zv = numpy.bitwise_and.reduce(zv, axis)
+if zv.shape[axis] == 0:
+# Theano and old numpy use +1 as 'AND of no elements', 
new numpy uses -1
+zv = numpy.abs(numpy.bitwise_and.reduce(zv, 
axis).astype('int8'))
+else:
+zv = numpy.bitwise_and.reduce(zv, axis)
 elif scalar_op == scalar.xor:
 # There is no identity value for the xor function
 # So we can't support shape of dimensions 0.
--- a/theano/tensor/tests/test_extra_ops.py
+++ b/theano/tensor/tests/test_extra_ops.py
@@ -135,7 +135,7 @@ class TestBinCountOp(utt.InferShapeTester):
 def test_bincountFn(self):
 w = T.vector('w')
 def ref(data, w=None, minlength=None):
-size = data.max() + 1
+size = int(data.max()) + 1
 if minlength:
 size = max(size, minlength)
 if w is not None:

Bug#850791: diffoscope: diff output in xml format

[Chris Lamb]

retitle 850791 diff output in machine-readable format
thanks

Hi,

> diffoscope: diff output in xml format

Justified or not (!), there is enough of an instant "ew, XML" backlash in
the free software world that another format is probably more suitable.

Renaming bug title to match the underlying intention. 


Regards,

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

Bug#854423: Does not work on IPv6-only networks

[Axel Beckert]

Control: retitle -1 wicd: Does not work on IPv6-only networks
Control: forcemerge 854176 -1

Hi Steve,

Steve McIntyre wrote:
> I found this over the weekend at FOSDEM.

You're not the only one: https://bugs.debian.org/854176 :-)

Merging these two bug reports.

> I've dug into this, and I can see why. If DHCP doesn't return a v4
> lease on a connection attempt (dhcp_failed), it aborts the
> connection.

Same question to you as to the other reporter: Have you tried to
configure a static IPv4 dummy address as workaround? (Just out of
curiosity if that's a workaround which could be recommended until
the issue is fixed properly.)

> I've started to hack on this a little bit over the weekend to see if
> there's an easy fix (if no v4 lease acquired, check to see if a
> global v6 address has been assigned),

Much appreciated!

> but I ran out of time to test this properly.

Understandable. FOSDEM is always too short and there's too much to
see. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#854424: chrony: Smoothing offset missing from timestamp in interleaved mode

[Vincent Blut]

Package: chrony
Version: 3.0-3
Severity: important
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Chrony 3.0 introduced interleaved modes which provides better accuracy 
over the basic modes by timestamping in the driver (SW timestamping) or 
in the hardware (HW timestamping) rather than in the application layer 
code. 
However, when this feature is used with the smoothing process (allowing 
clients to keep their clocks close to the server even when large offset 
or frequency corrections are applied to the server’s clock), the 
server's transmit timestamp doesn’t include the time smoothing offset 
causing less accurate timestamps… which is precisely what the 
interleaved mode should prevent.

Cheers,
Vincent


- -- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages chrony depends on:
ii  adduser  3.115
ii  init-system-helpers  1.47
ii  iproute2 4.9.0-1
ii  libc62.24-9
ii  libcap2  1:2.25-1
ii  libedit2 3.1-20160903-3
ii  libseccomp2  2.3.1-2.1
ii  libtomcrypt0 1.17-9
ii  lsb-base 9.20161125
ii  ucf  3.0036
ii  util-linux   2.29.1-1

chrony recommends no packages.

chrony suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJLBAEBCgA1FiEE/VQBlxWoTJPh4vI5ipzudlpxp4AFAliZBzkXHHZpbmNlbnQu
ZGViaWFuQGZyZWUuZnIACgkQipzudlpxp4CYGRAApgyEd3WNNLAF42ekhCK+GQ+R
RLxaa2+hIodt5h/hOpYH1++G2bpV4dPDAoXp9NJiLRGNHhTgxmm+3UlpxxFOA3M5
9KmjpOTbiFEukNfXTvbtLYh0LA0ihffWOh6UantmdRJkNoxXFSEVLynjVLSiVT03
JIgpePvt4I07wJERRd8Hn2o/ItK8saXvmTqIqO37I/ifbN9vw666F2g02XXYc/kA
bYb4LJT6hBDhUVhcI6AxPecbkgAn9XWjphueQ6/guEkXLIGE4kKO7J3gkz8mXVrF
/KRCj2RLYuR8I9TkwDOR9o1Okts0ACJB+MSHGqnuRALqUixnl6xkaWsvu5IMUbNW
UpT4hTzqBOT+A9tfXRT8gIqLHWZlxwdh3HLScWujeumNIOp89SIeO87AyjIyS/xo
0C6nx7RaMr1VYMk+D0hjdCbrodhd4TNiJqqxpOv0sw7YgxFhP26lRd7TP49Z3giK
DN0yAqIh7A+DOGCtlNr7zz05pU1NQoSJE1ZRcgFNIUvFbBwX8pT9bPCAf0vc08Nf
hJyeUOE8P1aBVBqelbc0qUeo0Nd5EvmtqaaWSH+FNOq41mzrGDhKVHlIZw7kuHih
RqNM9kcj+W/cvQlFEDXlpXN5VTmVf0olBWrBS6icsHpBGRefSGTNONipq5peSIbN
vgTExez4RJCOYYEY31A=
=NkdI
-END PGP SIGNATURE-

Bug#831540: (no subject)

[Rebecca N. Palmer]

Control: forwarded -1 https://github.com/Theano/Theano/issues/5498
Control: tags -1 patch

I don't think this is a regression - it's Python 3 specific 
(numpy.array(list of longs, which this test uses on Python 2)=int64 
array, but numpy(list of Python 3 ints)=int_nativesize array; see above 
link for longer discussion) and 0.8.2-2 appears to be the first time the 
tests were run with Python 3.


Fix (though I've only tried these particular tests, not a full build):

--- a/theano/tensor/tests/test_basic.py
+++ b/theano/tensor/tests/test_basic.py
@@ -6672,11 +6672,11 @@ class T_long_tensor(unittest.TestCase):
 assert scalar_ct.value == val

 vector_ct = constant([val, val])
-assert vector_ct.dtype == 'int64'
+assert vector_ct.dtype in ('int32','int64')
 assert numpy.all(vector_ct.value == val)

 matrix_ct = constant([[val, val]])
-assert matrix_ct.dtype == 'int64'
+assert matrix_ct.dtype in ('int32','int64')
 assert numpy.all(matrix_ct.value == val)

 def test_too_big(self):

Bug#854423: Does not work on IPv6-only networks

[Steve McIntyre]

Package: wicd
Version: 1.7.4+tb2-2
Severity: important
Tags: upstream ipv6

Hi,

I found this over the weekend at FOSDEM. Their default wifi network is
v6 only, with no v4 config at all. This would be fine for me (all the
services I need are functional on v6), but wicd does not work on such
a network.

I've dug into this, and I can see why. If DHCP doesn't return a v4
lease on a connection attempt (dhcp_failed), it aborts the
connection. I've started to hack on this a little bit over the weekend
to see if there's an easy fix (if no v4 lease acquired, check to see
if a global v6 address has been assigned), but I ran out of time to
test this properly.

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

Kernel: Linux 4.8.0-0.bpo.2-amd64 (SMP w/4 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 wicd depends on:
ii  wicd-cli [wicd-client] 1.7.4+tb2-2
ii  wicd-curses [wicd-client]  1.7.4+tb2-2
ii  wicd-daemon1.7.4+tb2-2
ii  wicd-gtk [wicd-client] 1.7.4+tb2-2

wicd recommends no packages.

wicd suggests no packages.

Versions of packages wicd-cli depends on:
pn  python:any   
ii  wicd-daemon  1.7.4+tb2-2

Versions of packages wicd-cli recommends:
ii  sudo  1.8.10p3-1+deb8u3

Versions of packages wicd-gtk depends on:
ii  python-glade2  2.24.0-4
ii  python-gtk22.24.0-4
pn  python:any 
ii  wicd-daemon1.7.4+tb2-2

Versions of packages wicd-gtk recommends:
ii  gksu   2.0.2-9
ii  python-notify  0.1.1-4

Versions of packages wicd-curses depends on:
ii  python-urwid  1.2.1-2+b1
pn  python:any
ii  wicd-daemon   1.7.4+tb2-2

Versions of packages wicd-curses recommends:
ii  sudo  1.8.10p3-1+deb8u3

Versions of packages wicd-daemon depends on:
ii  adduser  3.113+nmu3
ii  dbus 1.8.22-0+deb8u1
ii  debconf  1.5.56
ii  ethtool  1:3.16-1
ii  iproute2 3.16.0-2
ii  iputils-ping 3:20121221-5+b2
ii  isc-dhcp-client  4.3.1-6+deb8u2
ii  lsb-base 4.1+Debian13+nmu1
ii  net-tools1.60-26+b1
ii  psmisc   22.21-2
ii  python-dbus  1.2.0-2+b3
ii  python-gobject   3.14.0-1
ii  python-wicd  1.7.4+tb2-2
pn  python:any   
ii  wireless-tools   30~pre9-8
ii  wpasupplicant2.3-1+deb8u4

Versions of packages wicd-daemon recommends:
ii  rfkill 0.5-1
ii  wicd-cli [wicd-client] 1.7.4+tb2-2
ii  wicd-curses [wicd-client]  1.7.4+tb2-2
ii  wicd-gtk [wicd-client] 1.7.4+tb2-2

Versions of packages wicd-daemon suggests:
ii  pm-utils  1.4.1-15

Versions of packages python-wicd depends on:
pn  python:any  

-- debconf information excluded

Bug#779789: mpv: free(): invalid pointer: 0xedf28020 ***

[James Cowgill]

Control: tags -1 = moreinfo

On Fri, 20 Mar 2015 17:39:05 +0100 Jakub Wilk  wrote:
> * Alessandro Ghedini , 2015-03-20, 10:50:
> >Upstream has committed a patch [0] that may or may not fix the issue 
> >(he can't reproduce either). Would it be possible for you to test it 
> >(e.g. by adding the patch to the Debian source package)?
> 
> I've tried the patch on top of mpv_0.8.3-1. Unfortunately, the problem 
> remains. :-(
> 
> >If that doesn't work, could you also try to build the git master [1] 
> >and see if the problem is still there?
> 
> I'll try that later.

Did you ever try this?

Does the bug still happen with the version in unstable? I also can't
reproduce it there.

Upstream ended up closing the bug report due to no-one replying to it.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#834022: mpv: load libsmbclient dynamically

[James Cowgill]

Hi,

On Thu, 11 Aug 2016 15:18:00 +0200 Jörg-Volker Peetz  wrote:
> Package: mpv
> Version: 0.18.1-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> would it be possible to load libsmbclient dynamically like libdvdread4 does 
> with
> libdvdcss? That would avoid installing samba-libs if there's no Samba network.
> vlc, for example, separates this functionality with a plugin.

Possibly, but something like this would need to be done upstream rather
in the Debian package. Please file an upstream bug.

Having said that, I'm not sure there's that much benefit in doing this.
On my system, installing libsmbclient added 30M which isn't a lot for
most people. libdvdcss is different - it's loaded dynamically for legal
reasons.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#820549: anarchism: Typo in section H1

[ju]

Hi,

>
> I'd like to, but the way anarchism 15 is being uploaded right now makes
> me really feel uncomfortable:

I think what really is missing is to change the Debian package README to
clarify some points.
Please, have a look to the just pushed README [0] in "upstream".
We thought it could be a good idea to have separated the script to
download automatically (and even in real time running it in a box) the
authors' original and the original html extracted from the script plus
conversions to other formats. The repository with the html would be the
Debian upstream and the repository with scraper should be also packaged
for Debian.

>
> - there's tons of trailing whitespaces (at least in debian/changelog and
>   some html files).
>   If I open my editor on a file, I end up changing tons of lines. Shall
>   I use sed to change a typo, or shall you fix your whitespaces first?
>

The trailing whitespaces come from the original HTML.
Personally, i would not modify the original HTML, but we could include a
patch in the Debian package to do so.

> - the .html is not anymore readable by a human, it's just a bunch of
>   parsed content.

Hmm, you mean the HTML code or what is rendered in a browser?.
Usually people do not read HTML code, i guess that is why the Debian
package generated txt, and for more readable formats we have Markdown,
that is why is generated by the scraper.
The HTML displayed in a browser should be readable as in the original
Website. If it is not, then maybe there is some bug in the scraper.

>   Do I really have to create a patch of (at least) 8K just to add a
>   letter?

This is a good question, the idea with the separate scraper and source
repositories was that people could fix the Markdown directly in that
repository, but then there should probably be other Markdown directory
or branch, to do not end up overwrotten by the conversion from the HTML
but possible to merge and use that one for the Debian package.

>
> - there's now multiple directories having the same content, instead of
>   just one html/ from where to get all other file formats.
>   How am I supposed to fix this typo? Do I have to fix it in all 3
>   places?

The scraper generate the markdown and txt directories. Having markdown,
txt should probably not exists, it comes from the previous Debian script.

>
>   Even if I wanted to fix the problem at the root, the script you used
>   to generate it's not in the package itself, and is *big*.

Yeah, sorry, it has not been packaged yet, but the idea is to package it
independently of the HTML.

>   I'm not even sure anymore where I am contributing now.
>
>   Before anarchism 15 was released I tried to help a bit myself, and
>   ended up with the attached relevant debian/ files.
>   My solution has clearly more little errors than yours, but at least
>   anybody can reprocude it.

You can not reproduce the HTML, Markdown and txt from the scraper?. It
should, that was the main idea.
The "source" HTML used to generated the older Debian versions, was never
in any repository nor there was an script to download it from the
original Website.

Maybe you can find something helpful from
>   there to help me fix this issue.
>

Ok, i will look those files. It would be great if you look at the new
README.
A process like the following seems good to me:
1. the scraper obtain the HTML from the original Website
2. the scraper push the HTML to other repository, together with the
generated Markdown
3. Debian package uses the generated "source" as upstream.

Probably what is missing, as said above, is to have a separated Markdown
directory where to push any content change that does not reflect the
original and specify clearly that that is the directory where to fix
typos and content. At least would be easy to see differences with the
original and new original versions.

Thanks for your comments,
ju.

[0] https://0xacab.org/ju/afaq/blob/master/README.md

Bug#854422: ITP: multitime -- an to time which runs a command multiple times and gives detailed stats

[Iustin Pop]

On 2017-02-06 16:46:55, Matt Zagrabelny wrote:
> Is the subject missing a word?
> 
> "an *extension* to time..." ?

Yes, for some reason my mailer ate the word, I corrected it in the body
of the email but forgot to fix the subject.

I also struggled to find a short short-description, suggestions welcome
(see below for the latest attempt).

thanks,
iustin

> On Mon, Feb 6, 2017 at 4:37 PM, Iustin Pop  wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Iustin Pop 
> >
> > * Package name: multitime
> >   Version : 1.3
> >   Upstream Author : Laurence Tratt 
> > * URL : http://tratt.net/laurie/src/multitime/
> > * License : BSD
> >   Programming Lang: C
> >   Description : a time-like tool which does multiple runs
> >
> > Unix's time utility is a simple and often effective way of measuring
> > how long a command takes to run ("wall time"). Unfortunately, running
> > a command once can give misleading timings: the process may create a
> > cache on its first execution, running faster subsequently; other
> > processes may cause the command to be starved of CPU or IO time;
> > etc. It is common to see people run time several times and take
> > whichever values they feel most comfortable with. Inevitably, this
> > causes problems.
> >
> > multitime is, in essence, a simple extension to time which runs a
> > command multiple times and prints the timing means, standard
> > deviations, mins, medians, and maxes having done so. This can give a
> > much better understanding of the command's performance.


signature.asc
Description: PGP signature

Bug#854422: ITP: multitime -- an to time which runs a command multiple times and gives detailed stats

[Matt Zagrabelny]

Is the subject missing a word?

"an *extension* to time..." ?

Thanks,

-m

On Mon, Feb 6, 2017 at 4:37 PM, Iustin Pop  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Iustin Pop 
>
> * Package name: multitime
>   Version : 1.3
>   Upstream Author : Laurence Tratt 
> * URL : http://tratt.net/laurie/src/multitime/
> * License : BSD
>   Programming Lang: C
>   Description : a time-like tool which does multiple runs
>
> Unix's time utility is a simple and often effective way of measuring
> how long a command takes to run ("wall time"). Unfortunately, running
> a command once can give misleading timings: the process may create a
> cache on its first execution, running faster subsequently; other
> processes may cause the command to be starved of CPU or IO time;
> etc. It is common to see people run time several times and take
> whichever values they feel most comfortable with. Inevitably, this
> causes problems.
>
> multitime is, in essence, a simple extension to time which runs a
> command multiple times and prints the timing means, standard
> deviations, mins, medians, and maxes having done so. This can give a
> much better understanding of the command's performance.
>

Bug#854420: bugs.debian.org: There needs to be a button or something to report spam on a bug/ticket

[Don Armstrong]

On Tue, 07 Feb 2017, shirish शिरीष wrote:
> While admittedly it has lesser spam than lists.debian.org sometimes
> gets, there doesn't seem to have a way to tell if a bug-report/ticket
> gets spam. For instance, I was looking at #2297 and saw it had got
> spam recently. Instead of one-off wipe it would be nice if there was a
> way to report spam and people could use it, similar to how its used in
> lists.debian.org.

There's a button at the bottom of the page for it.


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

Love is... a complex sequence of neurochemical reactions that makes
people behave like idiots. It's similar to intoxication, but the
hangover's even worse.
 -- J. Jacques _Questionable Content_ #1039
http://www.questionablecontent.net/view.php?comic=1039

Bug#853117: tightvnc FTBFS on mips*: PIE / stipmips.s problem

[Ola Lundqvist]

Thank you!

// Ola


On 4 February 2017 at 23:45, Adrian Bunk  wrote:

> Control: tags -1 patch
>
> On Mon, Jan 30, 2017 at 12:03:26PM +0100, Ola Lundqvist wrote:
> > Hi
> >
> > Thank you for this bug report. Do you have a proposed patch for this?
> >...
>
> Patch is attached.
>
> cu
> Adrian
>
> --
>
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
>
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#854421: systemd: "systemctl --user cat dirmngr.socket" produced garbage beyond # /dev/null

[Daniel Kahn Gillmor]

On Mon 2017-02-06 17:18:59 -0500, Daniel Kahn Gillmor wrote:
> I've masked the user service dirmngr.socket on one user.  Out of
> curiosity i tried to see what it looked like, and i got some crazy
> spew.
>
> then i tried unmasking and re-masking and it to try to capture the
> problem, and it didn't come back.
>
> Then i tried it multiple times.  it seems to be intermittent, but i
> finally got a dump of it into hd, so that it's representable.

I just tried again and got it to do the weird dump under strace.  here
are the system calls that lead to the garbage output:

11439 17:37:01.331923 ppoll([{fd=3, events=POLLIN}], 1, {tv_sec=24, 
tv_nsec=37000}, NULL, 8) = 1 ([{fd=3, revents=POLLIN}], left {tv_sec=24, 
tv_nsec=999880841}) <0.72>
11439 17:37:01.332055 recvmsg(3, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="l\2\1\1\10\0\0\0\4\0\0\0\17\0\0\0\5\1u\0\4\0\0\0", 
iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, 
MSG_DONTWAIT|MS
G_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24 <0.12>
11439 17:37:01.332109 recvmsg(3, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\10\1g\0\1v\0\0\1b\0\0\0\0\0\0", iov_len=16}], 
msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, 
MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMS
G_CLOEXEC) = 16 <0.12>
11439 17:37:01.332169 open("/dev/null", O_RDONLY|O_NOCTTY|O_CLOEXEC) = 4 
<0.20>
11439 17:37:01.332225 fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 
<0.11>
11439 17:37:01.332277 write(1, "# /dev/null\n", 12) = 12 <0.20>
11439 17:37:01.332330 copy_file_range(4, NULL, 1, NULL, 9223372036854775807, 0) 
= -1 EXDEV (Invalid cross-device link) <0.12>
11439 17:37:01.332373 sendfile(1, 4, NULL, 9223372036854775807) = -1 EINVAL 
(Invalid argument) <0.12>
11439 17:37:01.332413 splice(4, NULL, 1, NULL, 9223372036854775807, 0) = 0 
<0.26>
11439 17:37:01.332467 close(4)  = 0 <0.12>
11439 17:37:01.332509 close(3)  = 0 <0.20>
11439 17:37:01.332625 exit_group(0) = ?
11439 17:37:01.333091 +++ exited with 0 +++


  --dkg

Bug#854422: ITP: multitime -- an to time which runs a command multiple times and gives detailed stats

[Iustin Pop]

Package: wnpp
Severity: wishlist
Owner: Iustin Pop 

* Package name: multitime
  Version : 1.3
  Upstream Author : Laurence Tratt 
* URL : http://tratt.net/laurie/src/multitime/
* License : BSD
  Programming Lang: C
  Description : a time-like tool which does multiple runs

Unix's time utility is a simple and often effective way of measuring
how long a command takes to run ("wall time"). Unfortunately, running
a command once can give misleading timings: the process may create a
cache on its first execution, running faster subsequently; other
processes may cause the command to be starved of CPU or IO time;
etc. It is common to see people run time several times and take
whichever values they feel most comfortable with. Inevitably, this
causes problems.

multitime is, in essence, a simple extension to time which runs a
command multiple times and prints the timing means, standard
deviations, mins, medians, and maxes having done so. This can give a
much better understanding of the command's performance.

Bug#825601: Notification Area cuts off the rightmost notification image

[Matt Zagrabelny]

Hello,

I don't believe I've seen the issue in 1.16. Thanks for working on
MATE and Debian. :)

I would call this bug closed.

-m

On Mon, Feb 6, 2017 at 7:39 AM, Vlad Orlov  wrote:
> Control: tags -1 moreinfo
>
>
> Hi,
>
> It might be caused by some issues with GTK+3 at that time. In MATE 1.16
> most issues related to GTK+ had been fixed. Does this issue still happen?

Bug#853798: mpv: Segfaults on TV input

[James Cowgill]

Hi,

On 01/02/17 20:20, Frédéric Brière wrote:
> found 853798 0.21.0-1
> tag 853798 + upstream
> forwarded 853798 https://github.com/mpv-player/mpv/issues/4096
> thanks
> 
> Thanks for your quick (and detailed) reply!
> 
> On Wed, Feb 01, 2017 at 11:29:38AM +, James Cowgill wrote:
>> Unfortunately I can't reproduce this issue (I don't have any TV input
>> devices except a webcam which works OK)
> 
> Ah, right, it didn't occur to me that there was a hardware component
> involved.

Thanks for taking care of this!

Is the commit from your PR all that's needed to fix this bug?
https://github.com/mpv-player/mpv/commit/aaad2d847e60a5bbd8fbf9c89f100a9ef9abd008

Does it work when applied on top of 0.23? If so, I think it's simple
enough to be fixed for stretch.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#854400: systemd: FTBFS if /tmp is an overlayfs

[James Cowgill]

Hi,

On 06/02/17 17:36, Michael Biebl wrote:
> Am 06.02.2017 um 18:07 schrieb James Cowgill:
>> Source: systemd
>> Version: 232-15
>> Severity: important
>>
>> Hi,
>>
>> While testing #852811 I discovered that systemd does not build within an
>> overlayfs schroot (which all my mips chroots are setup as). Specifically
>> the "test-copy" test fails with:
>>
>>> FAIL: test-copy
>>> ===
>>>
>>> test_copy_file
>>> test_copy_file_fd
>>> test_copy_tree
>>> Assertion 'access(f, F_OK) == 0' failed at ../src/test/test-copy.c:136, 
>>> function test_copy_tree(). Aborting.
>>> FAIL test-copy (exit status: 134)
>>
>> The assertion is caused by a file not being copied by copy_tree and that
>> is in turn caused by this line:
>> https://sources.debian.net/src/systemd/232-15/src/basic/copy.c/#L342
>>
>> The above line does not copy files if the device of the file is not the
>> same as the device of the parent directory, however on an overlayfs
>> filesystem this is condition is always true for non-directories.
>>
>> From https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt:
>>> This approach is 'hybrid' because the objects that appear in the
>>> filesystem do not all appear to belong to that filesystem.  In many
>>> cases an object accessed in the union will be indistinguishable
>>> from accessing the corresponding object from the original filesystem.
>>> This is most obvious from the 'st_dev' field returned by stat(2).
>>>
>>> While directories will report an st_dev from the overlay-filesystem,
>>> all non-directory objects will report an st_dev from the lower or
>>> upper filesystem that is providing the object.  Similarly st_ino will
>>> only be unique when combined with st_dev, and both of these can change
>>> over the lifetime of a non-directory object.  Many applications and
>>> tools ignore these values and will not be affected.
>>
>> Note that this behavior is different from say 'cp -Rx'. cp only checks
>> the value of st_dev if the file is a directory. This allows it to work
>> correctly with overlayfs.
>> http://sources.debian.net/src/coreutils/8.26-2/src/copy.c/?hl=2547#L2547
> 
> I think this is a bug in overlayfs.

Well it's the documented behavior of overlayfs which others have
probably relied on, so I think it's very unlikely overlayfs will be
changed now.

James



signature.asc
Description: OpenPGP digital signature

Bug#854421: systemd: "systemctl --user cat dirmngr.socket" produced garbage beyond # /dev/null

[Daniel Kahn Gillmor]

Package: systemd
Version: 232-15
Severity: normal

I've masked the user service dirmngr.socket on one user.  Out of
curiosity i tried to see what it looked like, and i got some crazy
spew.

then i tried unmasking and re-masking and it to try to capture the
problem, and it didn't come back.

Then i tried it multiple times.  it seems to be intermittent, but i
finally got a dump of it into hd, so that it's representable.

transcript is below:


0 jj955@alice:~$ systemctl --user cat dirmngr.socket
# /dev/null
戀<83>^W }ѻ^Sf<98>_a^N^O&^\j<9F>~%><85>
-<9A>^Gկ<9C>^Q<96>U^N;2꜁]Ģ
rZJ!l^Z<88>^]_^E3i;kHH^U^Hp6<86>
<85>8|Bí¸°^^v2'{<94>a!`כ٥58^]5>
^Y-^O^T<83>Ȉ^?<9B>^E/1<9D>
k|^O{<91>a<8F>^Y4N7^V^CBi(溪~:ͦ42U<97>
#<93>J<84>C'2EHh@K  #<97>#D<<8B>6   
z<82>[/ng^_<9A><80>f^U_LE<93>^G9Z<9B>
u<96>Z^E<8D>^H5<8A>KM^F<85>b.^X^CL+n)<84><9B>90<92>M6?
5<9B>͇^N Zr<90><95><91>^hq[S<96>
<92>_^L~W'c^M1=*gY^^
^R$=.ߗ80>nx<8F>F<87>qLqK}yJMY+$`<97>
H@k=iS^<99>֋<9C>^k^P)
u!:^V=^LK<9C>^WS"^Q <8B>_<9B>^\V
^AJs^Y1<88>c^M
/慮цSio^G7<92>ZP0<8A>
^@^X^V-rIN [z^K;"xY^QW<80>><9D>^Og
?^U^SFf^W<98>^M<9B>R<92>}/
@8^A,"y^T   <97>vEb-:zMai^G^E^K^@
<87>^?<93><93><84><91>^D8;*=w<87>^^z^H2"E&
^Z!<9F>\<8E>D><93>(^A3<95><9F>5<82>^<81>^T6yHԇ<83><86><81>)
<96>^Na]q&<80>XI^R^^}sK$^Le&<9D>j
瀼Gri\od^R<9E>^W*w^Xѵ^E#H;ms
^T7]<97>^C^\H_"<95><9F>!F`J\$[7^R<8E>`
I`Fv=0=<8E><92>K<8B> <92>^@>^U<99>t^ZfC-
0 jj955@alice:~$ ls -la .config/systemd/user/dirmngr.socket 
lrwxrwxrwx 1 jj955 jj955 9 Jan 18 12:29 .config/systemd/user/dirmngr.socket -> 
/dev/null
0 jj955@alice:~$ systemctl --user unmask dirmngr.socket
Removed /home/jj955/.config/systemd/user/dirmngr.socket.
0 jj955@alice:~$ killall dirmngr
0 jj955@alice:~$ systemctl --user cat dirmngr.socket
# /usr/lib/systemd/user/dirmngr.socket
[Unit]
Description=GnuPG network certificate management daemon
Documentation=man:dirmngr(8)

[Socket]
ListenStream=%t/gnupg/S.dirmngr
SocketMode=0600
DirectoryMode=0700

[Install]
WantedBy=sockets.target
0 jj955@alice:~$ systemctl --user cat dirmngr.socket | hd
  23 20 2f 75 73 72 2f 6c  69 62 2f 73 79 73 74 65  |# /usr/lib/syste|
0010  6d 64 2f 75 73 65 72 2f  64 69 72 6d 6e 67 72 2e  |md/user/dirmngr.|
0020  73 6f 63 6b 65 74 0a 5b  55 6e 69 74 5d 0a 44 65  |socket.[Unit].De|
0030  73 63 72 69 70 74 69 6f  6e 3d 47 6e 75 50 47 20  |scription=GnuPG |
0040  6e 65 74 77 6f 72 6b 20  63 65 72 74 69 66 69 63  |network certific|
0050  61 74 65 20 6d 61 6e 61  67 65 6d 65 6e 74 20 64  |ate management d|
0060  61 65 6d 6f 6e 0a 44 6f  63 75 6d 65 6e 74 61 74  |aemon.Documentat|
0070  69 6f 6e 3d 6d 61 6e 3a  64 69 72 6d 6e 67 72 28  |ion=man:dirmngr(|
0080  38 29 0a 0a 5b 53 6f 63  6b 65 74 5d 0a 4c 69 73  |8)..[Socket].Lis|
0090  74 65 6e 53 74 72 65 61  6d 3d 25 74 2f 67 6e 75  |tenStream=%t/gnu|
00a0  70 67 2f 53 2e 64 69 72  6d 6e 67 72 0a 53 6f 63  |pg/S.dirmngr.Soc|
00b0  6b 65 74 4d 6f 64 65 3d  30 36 30 30 0a 44 69 72  |ketMode=0600.Dir|
00c0  65 63 74 6f 72 79 4d 6f  64 65 3d 30 37 30 30 0a  |ectoryMode=0700.|
00d0  0a 5b 49 6e 73 74 61 6c  6c 5d 0a 57 61 6e 74 65  |.[Install].Wante|
00e0  64 42 79 3d 73 6f 63 6b  65 74 73 2e 74 61 72 67  |dBy=sockets.targ|
00f0  65 74 0a  |et.|
00f3
0 jj955@alice:~$ systemctl --user mask dirmngr.socket 
Created symlink /home/jj955/.config/systemd/user/dirmngr.socket → /dev/null.
0 jj955@alice:~$ systemctl --user cat dirmngr.socket | hd
  23 20 2f 64 65 76 2f 6e  75 6c 6c 0a  |# /dev/null.|
000c
0 jj955@alice:~$ systemctl --user cat dirmngr.socket 
# /dev/null
0 jj955@alice:~$ systemctl --user cat dirmngr.socket 
# /dev/null
0 jj955@alice:~$ systemctl --user cat dirmngr.socket | hd
  23 20 2f 64 65 76 2f 6e  75 6c 6c 0a  |# /dev/null.|
000c
0 jj955@alice:~$ systemctl --user cat dirmngr.socket | hd
  23 20 2f 64 65 76 2f 6e  75 6c 6c 0a  |# /dev/null.|
000c
0 jj955@alice:~$ systemctl --user cat dirmngr.socket | hd
  23 20 2f 64 65 76 2f 6e  75 6c 6c 0a  |# /dev/null.|
000c
0 jj955@alice:~$ systemctl --user cat dirmngr.socket | hd
  23 20 2f 64 65 76 2f 6e  75 6c 6c 0a 00 10 df 19  |# /dev/null.|
0010  7f 95 ff ff 00 00 00 00  fe 01 00 00 40 c1 2a 48  |@.*H|
0020  ea f5 ff ff 00 51 22 48  ea f5 ff ff 80 45 2e 48  |.Q"H.E.H|
0030  ea f5 ff ff c0 5a 29 48  ea f5 ff ff 80 1c 77 48  |.Z)H..wH|
0040  ea f5 ff ff c0 6d 25 48  ea f5 ff ff 80 78 2e 48  |.m%H.x.H|
0050  ea f5 ff ff 00 dc 2e 48  ea f5 ff ff c0 3b 22 48  |...H.;"H|
0060  ea f5 ff ff 80 3b 22 48  ea f5 ff ff 40 3b 22 48  |.;"H@;"H|
0070  ea f5 ff ff 00 3b 22 48  ea f5 ff ff c0 3a 22 48  |.;"H.:"H|
0080  ea f5 ff ff 80 3a 22 48  ea f5 ff ff 40 3a 22 48  |.:"H@:"H|
0090  ea f5 ff ff 00 3a 22 48  ea f5 ff ff c0 1f 2e 48  |.:"H...H|
00a0  ea f5 ff ff 80 1f 2e 48  

Bug#854420: bugs.debian.org: There needs to be a button or something to report spam on a bug/ticket

[shirish शिरीष]

Package: bugs.debian.org
Severity: normal

Dear Maintainer,
While admittedly it has lesser spam than lists.debian.org sometimes
gets, there doesn't seem to have a way to tell if a bug-report/ticket
gets spam. For instance, I was looking at #2297 and saw it had got
spam recently. Instead of one-off wipe it would be nice if there was a
way to report spam and people could use it, similar to how its used in
lists.debian.org.


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

Kernel: Linux 4.9.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)


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

Bug#434464: the latest spam assassin version in Debian BTS as well as in mail server is 3.4.1-6

[shirish शिरीष]

Hi all,

Just saw the headers, it says -

X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on bendel.debian.org


[$] aptitude show spamassassin
 [3:39:27]
Package: spamassassin
Version: 3.4.1-6
State: Not installed

So it works.

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

Bug#812002: smokeqt: FTBFS with GCC 6: deleted function

[Gilles Filippini]

Control: tags -1 + patch

On Tue, 19 Jan 2016 20:25:00 -0800 Martin Michlmayr  wrote:
> Package: smokeqt
> Version: 4:4.14.3-1
> Severity: important
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-6
> 
> This package fails to build with GCC 6.  GCC 6 has not been released
> yet, but it's expected that GCC 6 will become the default compiler for
> stretch.
> 
> Note that only the first error is reported; there might be more.  You
> can find a snapshot of GCC 6 in experimental.  To build with GCC 6,
> you can set CC=gcc-6 CXX=g++-6 explicitly.
> 
> You may be able to find out more about this issue at
> https://gcc.gnu.org/gcc-6/changes.html
> 
> > sbuild (Debian sbuild) 0.67.0 (26 Dec 2015) on dl580gen9-02.hlinux
> ...
> > cd /<>/obj-x86_64-linux-gnu/qtscript && /usr/bin/cmake -E 
> > cmake_link_script CMakeFiles/smokeqtscript.dir/link.txt --verbose=1
> > /usr/bin/c++  -fPIC -g -O2 -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  
> > -Wno-deprecated-declarations  -Wl,-z,relro -shared 
> > -Wl,-soname,libsmokeqtscript.so.3 -o libsmokeqtscript.so.3.0.0 
> > CMakeFiles/smokeqtscript.dir/smokedata.cpp.o 
> > CMakeFiles/smokeqtscript.dir/x_1.cpp.o ../qtcore/libsmokeqtcore.so.3.0.0 
> > -lQtCore -lQtScript -lsmokebase 
> > -Wl,-rpath,/<>/obj-x86_64-linux-gnu/qtcore: 
> > cd /<>/obj-x86_64-linux-gnu/qtscript && /usr/bin/cmake -E 
> > cmake_symlink_library libsmokeqtscript.so.3.0.0 libsmokeqtscript.so.3 
> > libsmokeqtscript.so
> > make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> > [ 30%] Built target smokeqtscript
> > /<>/obj-x86_64-linux-gnu/qtdbus/x_1.cpp:1594:7: error: deleted 
> > function 'virtual 
> > __smokeqtdbus::x_QDBusConnectionInterface::~x_QDBusConnectionInterface()'
> >  class x_QDBusConnectionInterface : public QDBusConnectionInterface {
> >^~
> > 
> > In file included from /usr/include/qt4/QtDBus/QtDBus:8:0,
> >  from /<>/qtdbus/qtdbus_includes.h:2,
> >  from 
> > /<>/obj-x86_64-linux-gnu/qtdbus/x_1.cpp:2:
> > /usr/include/qt4/QtDBus/qdbusconnectioninterface.h:73:5: error: overriding 
> > non-deleted function 'virtual 
> > QDBusConnectionInterface::~QDBusConnectionInterface()'
> >  ~QDBusConnectionInterface();
> >  ^
> > 
> > /<>/obj-x86_64-linux-gnu/qtdbus/x_1.cpp:1594:7: note: 'virtual 
> > __smokeqtdbus::x_QDBusConnectionInterface::~x_QDBusConnectionInterface()' 
> > is implicitly deleted because the default definition would be ill-formed:
> >  class x_QDBusConnectionInterface : public QDBusConnectionInterface {
> >^~
> > 
> > /<>/obj-x86_64-linux-gnu/qtdbus/x_1.cpp:1594:7: error: 
> > 'virtual QDBusConnectionInterface::~QDBusConnectionInterface()' is private 
> > within this context
> > In file included from /usr/include/qt4/QtDBus/QtDBus:8:0,
> >  from /<>/qtdbus/qtdbus_includes.h:2,
> >  from 
> > /<>/obj-x86_64-linux-gnu/qtdbus/x_1.cpp:2:
> > /usr/include/qt4/QtDBus/qdbusconnectioninterface.h:73:5: note: declared 
> > private here
> >  ~QDBusConnectionInterface();
> >  ^
> > 
> > qtdbus/CMakeFiles/smokeqtdbus.dir/build.make:98: recipe for target 
> > 'qtdbus/CMakeFiles/smokeqtdbus.dir/x_1.cpp.o' failed
> > make[3]: *** [qtdbus/CMakeFiles/smokeqtdbus.dir/x_1.cpp.o] Error 1
> 
> ...
> 
> >  from 
> > /<>/obj-x86_64-linux-gnu/qtgui/x_13.cpp:2:
> > /usr/include/qt4/QtGui/qsessionmanager.h:65:5: error: overriding 
> > non-deleted function 'virtual QSessionManager::~QSessionManager()'
> >  ~QSessionManager();
> >  ^
> > 
> > /<>/obj-x86_64-linux-gnu/qtgui/x_13.cpp:3572:7: note: 'virtual 
> > __smokeqtgui::x_QSessionManager::~x_QSessionManager()' is implicitly 
> > deleted because the default definition would be ill-formed:
> >  class x_QSessionManager : public QSessionManager {
> >^

This is caused by g++ defaulting to -std=c++11 in GCC 6.
An easy workaround is to add:
 export DEB_CXXFLAGS_MAINT_APPEND = -std=c++98
to debian/rules.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#854416: Keep data for 24H for latest bugs in bugscan; fix time too

[Francesco Poli]

On Mon, 6 Feb 2017 15:42:08 -0600 Don Armstrong wrote:

> On Mon, 06 Feb 2017, Francesco Poli wrote:
> > On Mon, 6 Feb 2017 14:57:18 -0600 Don Armstrong wrote:
> > 
> > [...]
> > > On Mon, 06 Feb 2017, Francesco Poli wrote:
> > > > I mean: too many data gets similar to the absence of data.
> > > > It often says "NO release-critical bugs were closed and NONE were
> > > > opened." and many previous changes have already vanished from the
> > > > page.
> > > 
> > > Ah; that's a legitimate feature request. It should probably keep track
> > > of bugs which had been opened/closed in the previous 24H (or perhaps
> > > longer) time period.
> > 
> > Thanks for converting my considerations into a feature request.
> > I think 24 hours is fine, with a clear distinction among the various
> > updates.
> 
> I'll probably just indicate approximate times where the bugs were
> opened/closed.

I'd prefer to see the changes grouped by update, so that it would be
easy to take a look at the web page and see which are the updates I
have already examined and which are new to me (visited links are
colored differently from unvisited ones in the browser)...


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


pgpG6UISMLmOI.pgp
Description: PGP signature

Bug#854336: CVE-2016-9577 CVE-2016-9578

[Markus Koschany]

Control: tags -1 patch

Hi,

patches are available at

http://pkgs.fedoraproject.org/cgit/rpms/spice.git/commit/?id=d919d639ae5f83a9735a04d843eed675f9357c0d



signature.asc
Description: OpenPGP digital signature

Bug#854412: unblock: tpm-tools/1.3.9-0.1

[Niels Thykier]

Control: tags -1 confirmed moreinfo

Sebastian Andrzej Siewior:
> On 2017-02-06 21:18:53 [+0100], Sebastian Andrzej Siewior wrote:
>> Package: release.debian.org
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>> Severity: normal
>>
>> Please unblock package tpm-tools which is not yet uploaded. The debdiff
>> is against the version in unstable which was in testing but got removed
>> recently. It contains an update from 1.3.8 to 1.3.9 and the largest part
>> is the autotools update done by upstream. The update itself fixes one RC
>> bug (gcc-6 warnings which are turned into errors) and one openssl issue
>> by moving code to be 1.1 compatible. I added another patch from Philipp
>> Kern which fixes openssl 1.1 issues data_mgmt which seems to be
>> deprecated (according to someone saying to disable it instead fixing).
>>
>> If you say that this diff is way to big and nobody is looking at it,
>> then I would stick with 1.3.8 and cherry pick the required fixes plus
>> something that looks security related.
>>
>> unblock tpm-tools/1.3.9-0.1
> 
> forwarded, didn't hit the list due to attachment.
> 
> Sebastian
> 

Ok, please go ahead with the upload.

For the next time: Please consider providing a filtered debdiff leaving
out auto-generated noise (just remember to include information about
what exactly you have omitted / modified, so we are aware of it).


Thanks,
~Niels

Bug#826943: available patch to fix this bug

[Alan Guan]

Dear Maintainer,
As noted in the duplicated bug report #853995 for this same issue, a patch
to fix the problem is available here:
https://launchpadlibrarian.net/304927569/openscap-1.2.8.patch

Thanks,
Alan

Bug#854401: AW: Bug#854401: new upstream (1.5)

[Lennart Weller]

It's already in our alioth git. We are currently waiting on some 
clarifications. But if you want to you can build it from the git already

-Ursprüngliche Nachricht-
Von: Daniel Baumann [mailto:daniel.baum...@progress-linux.org] 
Gesendet: Montag, 6. Februar 2017 18:34
An: sub...@bugs.debian.org
Betreff: Bug#854401: new upstream (1.5)

Package: netdata
Severity: wishlist

Hi,

it would be nice if you could upgrade to the current upstream version
(1.5) in experimental.

Regards,
Daniel

Bug#854416: Keep data for 24H for latest bugs in bugscan; fix time too

[Don Armstrong]

On Mon, 06 Feb 2017, Francesco Poli wrote:
> On Mon, 6 Feb 2017 14:57:18 -0600 Don Armstrong wrote:
> 
> [...]
> > On Mon, 06 Feb 2017, Francesco Poli wrote:
> > > I mean: too many data gets similar to the absence of data.
> > > It often says "NO release-critical bugs were closed and NONE were
> > > opened." and many previous changes have already vanished from the
> > > page.
> > 
> > Ah; that's a legitimate feature request. It should probably keep track
> > of bugs which had been opened/closed in the previous 24H (or perhaps
> > longer) time period.
> 
> Thanks for converting my considerations into a feature request.
> I think 24 hours is fine, with a clear distinction among the various
> updates.

I'll probably just indicate approximate times where the bugs were
opened/closed.


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

Nothing is as inevitable as a mistake whose time has come.
 -- Tussman's Law

Bug#853995: this is a duplicate to 826943

[Alan Guan]

Dear Maintainer,

Just realized there is already a similar bug report 826943 about the same
issue. I will update that ticket with the patch information contained in
this bug report.

Thanks,
Alan Guan

Bug#852398: chromium: option --enable-remote-extensions does work: extensions cannot be enabled nor be installed

[Niels Elgaard Larsen]

På Mon, 6 Feb 2017 21:09:16 +0100
Michael Franzl  skrev:
> On Mon, 6 Feb 2017 11:27:55 +0100 Simon Ruderich 
 CHROMIUM_FLAGS='--enable-remote-extensions' chromium  
> 
> I put this into ~/.profile:
> 
> CHROMIUM_FLAGS='--enable-remote-extensions'
> 
> Confirmed working as a workaround.

Yeah, I now have.
 CHROMIUM_FLAGS='--enable-remote-extensions --disable-print-preview'
 
> I understand the security aspect, 

Me too. Great if we can avoid the Google store. But then we need
another source/repositry of essential extensions. Debian packages, a
local directory, github, or something else.

> but this setting really should be
> added as a package configuration option, and the user explicitly
> queried IMO.
> 
> Michael
> 

Bug#854419: ifscheme: Path to ifstate is incorrect

[Eric Lemoine]

Package: ifscheme
Version: 1.7-4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I just installed ifscheme on Debian Sid. ifscheme uses /etc/network/run/ifstate
as the path to the interface state. But that file does not exist in Debian Sid.
Debian Sid has /run/network/ifstate instead. The result is that ifscheme is
currently unusable on Debian Sid.

Also, the /etc/network/run directory not existing in Debian Sid the creation of
/etc/network/run/scheme will fail. /run/network/scheme should be probably used
on Debian Sid.

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

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

Versions of packages ifscheme depends on:
ii  ifupdown 0.8.18
ii  init-system-helpers  1.47

ifscheme recommends no packages.

ifscheme suggests no packages.

-- no debconf information

Bug#854416: Keep data for 24H for latest bugs in bugscan; fix time too

[Francesco Poli]

On Mon, 6 Feb 2017 14:57:18 -0600 Don Armstrong wrote:

[...]
> On Mon, 06 Feb 2017, Francesco Poli wrote:
> > I mean: too many data gets similar to the absence of data.
> > It often says "NO release-critical bugs were closed and NONE were
> > opened." and many previous changes have already vanished from the
> > page.
> 
> Ah; that's a legitimate feature request. It should probably keep track
> of bugs which had been opened/closed in the previous 24H (or perhaps
> longer) time period.

Thanks for converting my considerations into a feature request.
I think 24 hours is fine, with a clear distinction among the various
updates.
Something like:


  Recent changes

  Mon Feb 6 20:00:00 UTC 2017

  3 release-critical bugs were closed and 2 were opened.

  Closed:

  pkg1: #xx, #yy
  pkg2: #zz

  Opened:

  pkg3: #aa, #bb

  Mon Feb 6 19:00:00 UTC 2017

  NO release-critical bugs were closed and NONE were opened.

  Mon Feb 6 18:00:00 UTC 2017

  1 release-critical bugs were closed and NONE were opened.

  Closed:

  pkg4: #cc

  Mon Feb 6 17:00:00 UTC 2017

  [...]


and so forth...


Or maybe even better:


  Recent changes

  3 release-critical bugs were closed and 2 were opened.

  Closed:

  pkg1: #xx, #yy
  pkg2: #zz

  Opened:

  pkg3: #aa, #bb

  Previous changes

  Mon Feb 6 19:00:00 UTC 2017

  Mon Feb 6 18:00:00 UTC 2017

  Mon Feb 6 17:00:00 UTC 2017

  [...]


where each date is a link to a dedicated page where
the corresponding changes are listed (only the latest 23 such pages
are retained).


I hope this feature may be implemented soon.
Thank you very much for your time and patience!


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


pgpTsOJUD8EH5.pgp
Description: PGP signature

Bug#854418: ITP: gpiozero -- simple interface to everyday GPIO components used with Raspberry Pi

[Dominik George]

Package: wnpp
Severity: wishlist
Owner: Dominik George 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: gpiozero
  Version : 1.3.1
  Upstream Author : Ben Nuttall
* URL : https://pypi.python.org/pypi/gpiozero
* License : BSD
  Programming Lang: Python
  Description : simple interface to everyday GPIO components used with 
Raspberry Pi

gpiozero is a new, object-oriented interface to the Raspoberry Pi's GPIO
interface. It offers object wrappers for standard electronic components,
e.g. LED and buttons, and wrapper code to interact with them in a
calback-driven fashion.


Will be maintained within the Debian Raspi Packaging Team.

-BEGIN PGP SIGNATURE-

iQJ4BAEBCABiFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAliY6aYxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYxIcbmlrQG5h
dHVyYWxuZXQuZGUACgkQt5o8FqDE8pb45w//bC02k+jCthc2DP8kCYGDw6EMNgHE
5QDKbl5WDwlHzqKEuIn8nh0+DBfZnvubIPzsFA9edMlEnDKlV32YhDND5x2XiMkY
r5LoAGw6qtmO+Veek0S3EztPkpVS8BeZPG3aPaOAVsgnh6H3y7mZO0RlOrD+EQvC
3SuUDDFCl8FXhiWPCbbtANi6BRBe/fb2e4MaN5OnIWuskKrhnWfdGJJZPHgNERJI
7YbAxf7PAWsKBsIYKmFB1wG3otFxOjyaH6mHWofrssCN6DmYGs0MgeJD0DDfEcHP
r+WKlcc4k3CENuhqzeNbjGJP0C+oy1db86dLe5a+1WtgoyZPBSjdGREcxRvIeEBf
GewO1kUaHbWPF7Aes9DHKkj6DxasvsZp8XS9Z1yyuA/x3aHdrA1xNVt8PfgpE1xb
hEAXQvkeo1vqZ8s3r3iAf/XxZWCUQ+s6IKmU3p4O2q/c8v1Ej5EjPUzVScSQHleH
C1jx/70ebK/6SiBswKmUOfLSEQaIUosJxa+8lCTdhQnYSChr0go+L1tcLFILiFNK
6YQcd3Bfimwni+SBeRJ+fOubKAzq8XRghuHmn5gNEUmNF8IMjx5HQGQE+LeQ7CPx
dYzGceTUI2eGXnK5/rvQl+fC5CMWnbPsIs/DvFzLBKuykjaeYsK116G8h5WQqkxl
QHCTQO3WNbUYMes=
=c2I8
-END PGP SIGNATURE-

Bug#852048: pycodestyle >= 2.1.0 breaks prospector 0.12.4,,version graph

[Daniel Stender]

I've got deeper into it now. I think that was pinned by mistake, but pydocstyle 
was mend, the corresponding changelog
entry is on that. I've commented on the commit [1], waiting for a reaction ...

A simple patch for setup.py which removes the pinning would do it, because 
actually there are no API changes
in pycodestyle >= 2.1.0. I've tested that against pycodestyle 2.2.0-2 
(currently in the archive) and everything
works. I'll upload this shortly to catch the AUTORM.

DS

[1] 
https://github.com/landscapeio/prospector/commit/95e09816534853616d42877dcb8b9dc0f71a38e8

-- 
4096R/DF5182C8
Debian Developer (sten...@debian.org)
http://www.danielstender.com/

Bug#852798: fpc: Error: co-processor offset out of range on armhf

[Graham Inggs]

Control: tags -1 + patch

I've tested the attached patch and uploaded it to Ubuntu.
Mricron now builds successfully there.
Description: Offset of vstr/vld is limited to +/- 1020
 take care of this during spilling
Origin: upstream, http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision=35396
Bug: http://bugs.freepascal.org/view.php?id=31287
Bug-Debian: https://bugs.debian.org/852798
Author: Florian Klämpfl 
Last-Update: 2017-02-04
--- a/fpcsrc/compiler/arm/rgcpu.pas
+++ b/fpcsrc/compiler/arm/rgcpu.pas
@@ -189,7 +189,7 @@
 
   { Lets remove the bits we can fold in later and check if the result can be easily with an add or sub }
   a:=abs(spilltemp.offset);
-  if GenerateThumbCode then
+  if GenerateThumbCode or (getregtype(tempreg)=R_MMREGISTER) then
 begin
   {$ifdef DEBUG_SPILLING}
   helplist.concat(tai_comment.create(strpnew('Spilling: Use a_load_const_reg to fix spill offset')));
@@ -243,9 +243,10 @@
 end;
 
 
-   function fix_spilling_offset(offset : ASizeInt) : boolean;
+   function fix_spilling_offset(regtype : TRegisterType;offset : ASizeInt) : boolean;
  begin
result:=(abs(offset)>4095) or
+ ((regtype=R_MMREGISTER) and (abs(offset)>1020)) or
   ((GenerateThumbCode) and ((offset<0) or (offset>1020)));
  end;
 
@@ -255,7 +256,7 @@
 { don't load spilled register between
   mov lr,pc
   mov pc,r4
-  but befure the mov lr,pc
+  but before the mov lr,pc
 }
 if assigned(pos.previous) and
   (pos.typ=ait_instruction) and
@@ -266,7 +267,7 @@
   (taicpu(pos).oper[1]^.reg=NR_PC) then
   pos:=tai(pos.previous);
 
-if fix_spilling_offset(spilltemp.offset) then
+if fix_spilling_offset(getregtype(tempreg),spilltemp.offset) then
   spilling_create_load_store(list, pos, spilltemp, tempreg, false)
 else
   inherited do_spill_read(list,pos,spilltemp,tempreg);
@@ -275,7 +276,7 @@
 
 procedure trgcpu.do_spill_written(list:TAsmList;pos:tai;const spilltemp:treference;tempreg:tregister);
   begin
-if fix_spilling_offset(spilltemp.offset) then
+if fix_spilling_offset(getregtype(tempreg),spilltemp.offset) then
   spilling_create_load_store(list, pos, spilltemp, tempreg, true)
 else
   inherited do_spill_written(list,pos,spilltemp,tempreg);

Bug#846782: gobject-introspection randomly hangs liferea build

[Paul Gevers]

Hi,

On 02-02-17 19:16, Emilio Pozuelo Monfort wrote:
> It looks like you are missing glib, glibc and gobject-introspection debugging
> symbols (libglib2.0-0-dbg libgirepository-1.0-1-dbgsym libc6-dbg). It'd be 
> good
> to get a backtrace with those.
> 
> Also this looks like a deadlock in webkit. Maybe you can try with webkit 
> 2.15.4
> from experimental? If it still happens, I can forward this upstream.
> 
> BTW I'm downgrading this bug as this seems very rare (at least on buildds) and
> we shouldn't block the release on this.

I have run the command that is supposed to hang continuously for two
evenings now and it hasn't hung on me yet. I'll keep on trying, but on
my laptop it looks like the issue is fixed (in stretch).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#812127: login: wrong German error message

[Holger Wansing]

Hi,

Bálint Réczey  wrote:
> >> > As stated, I (rather firmly) believe
> >> >> Under no cirumstance work is possible without effective root.
> >>
> >> IMO this is the correct interpretation.
> >>
> >> The place where the message is emitted is here:
> >> http://sources.debian.net/src/shadow/1:4.4-3/src/login.c/?hl=567#L567
> >
> > So you should probably change the phrase in English too, to ensure it
> > is understood correctly? (Maybe other translators have misinterpreted it
> > too?)
> 
> The freeze is not a great time for making changes to the original strings. :-)
> Let's defer the resolution of this bug after Stretch is released.
> 
> Login may be provided by util-linux per #833256 and in that case I don't wan't
> to ask l10n teams to update a string in every language before that string goes
> away.

Attached is an updated po file for German.

I have applied the proposal by Helge, and updated the other fuzzies and
untranslated strings as well.


Probably you can still get it into Stretch ...

So long
Holger

-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/



de.po.gz
Description: application/gzip

Bug#821769: mirror.verbotene.zone unavailable

[Martin Bagge / brother]

Hi Oliver
It looks like the mirror went away. I'll mark this bug report for close
without action if you have no news on this the coming weeks.

Thanks.

-- 
brother

Bug#820549: anarchism: Typo in section H1

[Michele Orrù]

ju  writes:

> Or maybe they wanted to say <>?

No, that's not possible as the full sentence is:

« These critiques contain may important ideas and so are worth
summarising. »


>> I just thought it was a typo, and that it would have been nice to
>> report
>> it. I also downloaded the version proposed in #773529, and I can
>> confirm this
>> bug still applies.
>
> Now that #773529 is closed and the bug still applies, maybe is better a
> PR to the repository where the sources are now?.
>

I'd like to, but the way anarchism 15 is being uploaded right now makes
me really feel uncomfortable:

- there's tons of trailing whitespaces (at least in debian/changelog and
  some html files).
  If I open my editor on a file, I end up changing tons of lines. Shall
  I use sed to change a typo, or shall you fix your whitespaces first?

- the .html is not anymore readable by a human, it's just a bunch of
  parsed content.
  Do I really have to create a patch of (at least) 8K just to add a
  letter?  

- there's now multiple directories having the same content, instead of
  just one html/ from where to get all other file formats.
  How am I supposed to fix this typo? Do I have to fix it in all 3
  places?

  Even if I wanted to fix the problem at the root, the script you used
  to generate it's not in the package itself, and is *big*.
  I'm not even sure anymore where I am contributing now.
  
  Before anarchism 15 was released I tried to help a bit myself, and
  ended up with the attached relevant debian/ files.
  My solution has clearly more little errors than yours, but at least
  anybody can reprocude it. Maybe you can find something helpful from
  there to help me fix this issue.

Hasta la pasta,



rules
Description: Binary data


control
Description: Binary data
#!/usr/bin/env python2

import sys

from bs4 import BeautifulSoup as BS


html = BS(
'''




  
  
  

  
  

''', 'lxml')

def clean_html(inf, outf):
dirty = BS(inf, 'lxml', from_encoding='utf8')
content, = dirty.find_all('div', attrs={'class': 'content clear-block'})
html.head.append(dirty.title)
html.body.append(content)
outf.write(html.encode('utf8'))

if __name__ == '__main__':
if len(sys.argv) == 2:
with open(sys.argv[1], 'r') as inf:
clean_html(inf, sys.stdout)

elif len(sys.argv) == 1:
inf, outf = sys.stdin, sys.stdout
clean_html(inf, outf)

else:
sys.exit(1)

  
-- 
µ.

Bug#854417: dpkg-dev: improve deb-conffiles manpage

[Dieter Adriaenssens]

Package: dpkg-dev
Version: 1.18.22
Severity: minor

Dear Maintainer,

The section of Debian Policy where the handling of conffiles is
documented [0], gives more information than what is currently available
in deb-conffiles (5) man page :

'The filenames should be absolute pathnames, and the files referred to should 
actually exist in the package.'

Perhaps this sentence (or a rephrased version) can be added to the 
deb-conffiles man page.

[0] https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html#sE.1

Kind regards,
Dieter

Bug#854405: reportbug: Should handle missing optional runtime depencies more gracefully

[Jakob Haufe]

reopen 854405
retitle 854405 reportbug: Should handle missing optional runtime depencies more 
gracefully
severity 84405 normal
kthxbye

The issue is a little more complex. Reportbug behaves differently
depending on which packages are missing.

If python3-gi is missing, it falls back to text mode as documented.
If, however, python3-gi is install, but gir1.2-vte-2.91 is missing, it
fails to fall back and emits the reported traceback.

It would be nice if reportbug handled this the same way as if
python3-gi was missing.

Cheers,
sur5r

Bug#854416: Keep data for 24H for latest bugs in bugscan; fix time too

[Don Armstrong]

Package: bugs.debian.org
Severity: minor
Control: submitter -1 Francesco Poli 

On Mon, 06 Feb 2017, Francesco Poli wrote:
> I mean: too many data gets similar to the absence of data.
> It often says "NO release-critical bugs were closed and NONE were
> opened." and many previous changes have already vanished from the
> page.

Ah; that's a legitimate feature request. It should probably keep track
of bugs which had been opened/closed in the previous 24H (or perhaps
longer) time period.

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

Love is... a complex sequence of neurochemical reactions that makes
people behave like idiots. It's similar to intoxication, but the
hangover's even worse.
 -- J. Jacques _Questionable Content_ #1039
http://www.questionablecontent.net/view.php?comic=1039

Bug#854414: screen: after sshing, some commands give error "Error opening terminal: screen.xterm-256color."

[Axel Beckert]

Control: tag -1 + moreinfo

Hi,

csights wrote:
> After upgrading from Jessie to Stretch, when I ssh to another computer and 
> then try to use
> atop, nano, and others they fail to run with:
> Error opening terminal: screen.xterm-256color.
> 
> Running these programs locally within screen gives no problems

Is the package ncurses-term installed on both, local and remote system
or only on one of them?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#854369: ProFTPD: New upstream versions available in 1.3.5 branch

[Hilmar Preuße]

On 06.02.2017 13:19, Pavel Hirman wrote:

> Package: proftpd-basic
> Version: 1.3.5-1.1+deb8u1
> Severity: wishlist
> Tags: upstream

Hi Pavel,

> Could you upgrade proftpd deb to the latest upstream version 1.3.5d,
> it includes several bug fixes including memory leak and openssl 1.1.x
> support.
> https://github.com/proftpd/proftpd/blob/1.3.5/RELEASE_NOTES
> 
We are aware of this and the code is in our git repo yet. However it
was/is a
little to later for next Debain stable and we are already in deep
freeze. Uploading
the code to unstable will be one of our first steps after release.

Hilmar
-- 
http://www.hilmar-preusse.de.vu/   #206401 http://counter.li.org

Bug#854415: unblock: ndisc6/1.0.3-3

[Bernhard Schmidt]

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

Dear Release Team,

Please unblock package ndisc6

I have recently adopted ndisc6. One daemon in it (rdnssd) was affected
by an RC bug (Bug#767071) which I have fixed by updating to the hook
shipped in 1.0.3 upstream beginning of January.

Upstream has since committed a better fix for this and proposed to
include this in Stretch, since the current behaviour still has some
rough edges and is known to result in stray search lines in
/etc/resolv.conf (Bug#853281). I have cherry-picked this fix in 
ndisc6/1.0.3-3

The current version of the hook has only been in Debian for a month.
rdnssd gets pulled in by d-i since Jessie when RDNSS information is
found in an IPv6 router advertisement during installation. The hook only
affects operation when resolvconf is not installed though.

The package builds a udeb, but the hook is not part of it.

unblock ndisc6/1.0.3-3

I plan to fix this with a stable upload for the next Jessie point
release as well.

Thanks,
Bernhard
diff -Nru ndisc6-1.0.3/debian/changelog ndisc6-1.0.3/debian/changelog
--- ndisc6-1.0.3/debian/changelog   2017-01-01 20:33:46.0 +0100
+++ ndisc6-1.0.3/debian/changelog   2017-02-01 11:00:55.0 +0100
@@ -1,3 +1,9 @@
+ndisc6 (1.0.3-3) unstable; urgency=medium
+
+  * Import upstream fix to simplify rdnssd-merge-hook (Closes: #853281)
+
+ -- Bernhard Schmidt   Wed, 01 Feb 2017 11:00:55 +0100
+
 ndisc6 (1.0.3-2) unstable; urgency=medium
 
   [ Bernhard Schmidt ]
diff -Nru ndisc6-1.0.3/debian/patches/rdnssd-hook-drop-dnssl.patch 
ndisc6-1.0.3/debian/patches/rdnssd-hook-drop-dnssl.patch
--- ndisc6-1.0.3/debian/patches/rdnssd-hook-drop-dnssl.patch1970-01-01 
01:00:00.0 +0100
+++ ndisc6-1.0.3/debian/patches/rdnssd-hook-drop-dnssl.patch2017-02-01 
11:00:55.0 +0100
@@ -0,0 +1,56 @@
+From: Pierre Ynard 
+Date: Wed, 4 Jan 2017 01:45:35 + (+0100)
+Subject: rdnssd: properly handle search list entries in merge hook
+X-Git-Url: 
http://git.remlab.net/gitweb/?p=ndisc6.git;a=commitdiff_plain;h=d60853a5319bac0c3ec9a082bcaf850a5ab8d1d5
+
+rdnssd: properly handle search list entries in merge hook
+
+Basically, drop DNSSL entries because the hook is too basic to handle
+them correctly. Use something more sophisticated like resolvconf if you
+want this functionality. This fixes the following issues:
+
+ - inserting less IPv6 nameservers than calculated
+ - littering /etc/resolv.conf with stray search lines every time DNSSL
+   entries change
+ - clobbering existing (DHCPv4) search list entries
+ - overkill use of /usr/bin/awk, outside of PATH and reliant on /usr
+   availability
+
+Signed-off-by: Rémi Denis-Courmont 
+---
+
+diff --git a/rdnssd/merge-hook.in b/rdnssd/merge-hook.in
+index 2d202e8..383a57c 100644
+--- a/rdnssd/merge-hook.in
 b/rdnssd/merge-hook.in
+@@ -3,7 +3,7 @@
+ # resolv.conf merge hook for rdnssd
+ 
+ # *
+-# *  Copyright © 2007-2009 Pierre Ynard.  *
++# *  Copyright © 2007-2009, 2017 Pierre Ynard.*
+ # *  This program is free software: you can redistribute and/or modify*
+ # *  it under the terms of the GNU General Public License as published by *
+ # *  the Free Software Foundation, versions 2 or 3 of the license.*
+@@ -51,13 +51,18 @@ if [ $limit -lt $room ]; then
+   limit=$room
+ fi
+ 
+-# Merge and write the result
++# Merge and write the result. Let rdnssd assume ownership of all IPv6
++# nameservers, and remove extraneous IPv6 entries as expired. However
++# DHCPv4 most often sets up search list entries, and rdnssd cannot
++# clobber these lest it causes counterintuitive breakage. There is no
++# easy way to properly merge and manage DNSSL entries here, so just drop
++# them.
+ 
+ {
+   sed -e "/$RE_NSV4OR6/d" < $resolvconf
+-[ $limit -gt 0 ] && sed -e "${limit}q" < $myresolvconf
++  grep -m $limit "$RE_NSV4OR6" < $myresolvconf || [ $? -le 1 ]
+   sed -ne "/$RE_NSV4/p" < $resolvconf
+-} | awk '!a[$0]++' > $resolvconf.tmp
++} > $resolvconf.tmp
+ 
+ mv -f $resolvconf.tmp $resolvconf
+ 
diff -Nru ndisc6-1.0.3/debian/patches/resolvconf-rdnssd-hook.patch 
ndisc6-1.0.3/debian/patches/resolvconf-rdnssd-hook.patch
--- ndisc6-1.0.3/debian/patches/resolvconf-rdnssd-hook.patch2017-01-01 
20:33:46.0 +0100
+++ ndisc6-1.0.3/debian/patches/resolvconf-rdnssd-hook.patch2017-02-01 
11:00:55.0 +0100
@@ -10,8 +10,8 @@
 +# resolv.conf merge hook for Debian rdnssd
  
  # *
- # *  Copyright © 2007-2009 Pierre Ynard.  *
-@@ -19,7 +19,15 @@
+ # *  Copyright © 2007-2009, 2017 Pierre Ynard.*
+@@ -19,7 +19,12 @@
  
  set -e
  
@@ -22,9 +22,6 @@

Bug#854405: reportbug: Can't start reportbug from XFCE4 Menu

[mechtilde]

Package: reportbug
Version: 7.1.4
Followup-For: Bug #854405

It didn't fallback to command line.

For me the missing package was gir1.2-vte-2.91.

Regards

Mechtilde



-- Package-specific info:
** Environment settings:
INTERFACE="gtk2"

** /home/mechtilde/.reportbugrc:
reportbug_version "6.3.1"
mode advanced
ui text
email "mechti...@debian.org"
smtphost "mail.dasr.de:587"
smtpuser "stehmann"
smtptls

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (400, 'testing'), (300, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages reportbug depends on:
ii  apt1.4~beta4
ii  python3-reportbug  7.1.4
pn  python3:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs23-bin-common | emacs24-bin-common
ii  exim4  4.88-5
ii  exim4-daemon-light [mail-transport-agent]  4.88-5
ii  file   1:5.29-3
ii  gir1.2-gtk-3.0 3.22.7-2
ii  gir1.2-vte-2.910.46.1-1
ii  gnupg  2.1.18-3
ii  python3-gi 3.22.0-2
ii  python3-gi-cairo   3.22.0-2
pn  python3-gtkspellcheck  
ii  python3-urwid  1.3.1-2+b1
ii  xdg-utils  1.1.1-1

Versions of packages python3-reportbug depends on:
ii  apt1.4~beta4
ii  file   1:5.29-3
ii  python3-debian 0.1.30
ii  python3-debianbts  2.6.1
ii  python3-requests   2.12.4-1
pn  python3:any

python3-reportbug suggests no packages.

-- no debconf information

Bug#854414: screen: after sshing, some commands give error "Error opening terminal: screen.xterm-256color."

[csights]

Package: screen
Version: 4.5.0-3
Severity: important

Dear Maintainer,

After upgrading from Jessie to Stretch, when I ssh to another computer and then 
try to use
atop, nano, and others they fail to run with:
Error opening terminal: screen.xterm-256color.

Running these programs locally within screen gives no problems

A workaround is to do:
export TERM=xterm

Thanks for your help!
C.


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

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

Versions of packages screen depends on:
ii  libc6  2.24-9
ii  libpam0g   1.1.8-3.5
ii  libtinfo5  6.0+20161126-1

screen recommends no packages.

Versions of packages screen suggests:
pn  byobu | screenie | iselect  
ii  ncurses-term6.0+20161126-1

-- no debconf information

Bug#854333: git-buildpackage: fails to import native packages with large debian/changelog

[Guido Günther]

On Tue, Feb 07, 2017 at 09:29:56AM +1300, Chris Lamb wrote:
> Guido Günther wrote:
> 
> > We only shorten the reflog, not the changelog.
> 
> (My patch shortened the changelog). Am not fussed and will leave it with
> you. Thanks for maintaining gbp!

I picked a different approach since it allows us to keep the full
changelog in the commit message. Should anything get shortened that
shouldn't please reopen.
Cheers,
 -- Guido

Bug#854413: fgallery: Missing dependency: zip/7za

[Alexander Toresson]

Package: fgallery
Version: 1.8.2-1
Severity: important

Running after installing the package produces the following error:

$ fgallery important/photos/ /data/www/photos/
error: cannot run "zip" (check if 7za or zip is installed)

Probably one of these should be made dependencies. I downloaded and
installed the package on wheezy, but this part should be the same on
all debian versions. But, sorry in advance if this is an incorrect bug
report.

-- System Information:
Debian Release: 7.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: armhf (armv7l)
Foreign Architectures: armel

Kernel: Linux 4.4.35.rn102
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages fgallery depends on:
ii  exiftran2.07-10
ii  imagemagick 8:6.7.7.10-5+deb7u11
ii  libimage-exiftool-perl  8.60-2
ii  libjs-mootools  1.4.5~debian1-2.1
ii  libjson-perl2.53-1

Versions of packages fgallery recommends:
pn  liblcms2-utils  

Versions of packages fgallery suggests:
pn  facedetect  
pn  jpegoptim   
pn  pngcrush

-- no debconf information

Bug#854333: git-buildpackage: fails to import native packages with large debian/changelog

[Chris Lamb]

Guido Günther wrote:

> We only shorten the reflog, not the changelog.

(My patch shortened the changelog). Am not fussed and will leave it with
you. Thanks for maintaining gbp!


Regards,

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

Bug#853905: [pkg-gnupg-maint] Bug#853905: Ships incorrect /usr/lib/systemd/user/sockets.target.wants files, makes disabling impossible

[Daniel Kahn Gillmor]

On Mon 2017-02-06 11:32:06 -0500, Yuri D'Elia wrote:
> On Sat, Feb 04 2017, Daniel Kahn Gillmor wrote:
>> Can you give me the exact invocation?  If the agent is being
>> queried/auto-launched when it doesn't need to be, that'd be something
>> worth asking GnuPG upstream to take a look at.
>
> Nothing fancy. The command line is:
>
>   gpg --batch -qe -r keyid "$@"

sure, but what's the "$@" ?  Is it guaranteed to be a simple file name?
or could it be more gpg options?

You're saying that this command itself launches the agent, but i'm not
seeing that locally:

0 test@alice:~$ systemctl --user status
● alice
State: running
 Jobs: 0 queued
   Failed: 0 units
Since: Mon 2017-02-06 14:55:38 EST; 5min ago
   CGroup: /user.slice/user-1003.slice/user@1003.service
   └─init.scope
 ├─8163 /lib/systemd/systemd --user
 └─8164 (sd-pam)
0 test@alice:~$ gpg --batch -qe -r 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 
test.txt
0 test@alice:~$ systemctl --user status
● alice
State: running
 Jobs: 0 queued
   Failed: 0 units
Since: Mon 2017-02-06 14:55:38 EST; 5min ago
   CGroup: /user.slice/user-1003.slice/user@1003.service
   └─init.scope
 ├─8163 /lib/systemd/systemd --user
 └─8164 (sd-pam)
0 test@alice:~$ 

So i'm still unable to reproduce this :/

> simply a running agent that became older than the current release of
> gpg. from cron itself I also get:
>
> gpg: WARNING: server 'gpg-agent' is older than us (2.1.17 < 2.1.18)

hm, that's interesting.  I wonder whether it makes sense for a package
upgrade that includes user services to tell all systemd-managed user
services to reload.  I could see that being useful, but i don't know how
to do it.

> In the specific cron case, I do see the listening sockets being created
> (due to pam-systemd integration I guess) and removed at each job.

so in that case, when the listening sockets are removed, does the
gpg-agent process itself also get terminated properly?  or does the
process continue to survive even with all sockets removed?  gpg-agent
should notice that removal and shut itself down.

>> I/O contention?  Or is it a single process that sleeps in the
>> background, paged out until someone queries it?
>
> These are all single processes just waiting.
> So for gpg purposes, the agent is working as intended.
> However, I'm perplexed as of why I have so many running.

Me too! i'm unable to replicate the launching of the processes on the
basis of public key encryption, and i'm unclear on why they aren't being
shut down by default at the end of the cron session when the sockets are
removed.

--dkg


signature.asc
Description: PGP signature

Bug#854333: git-buildpackage: fails to import native packages with large debian/changelog

[Guido Günther]

On Tue, Feb 07, 2017 at 09:10:17AM +1300, Chris Lamb wrote:
> Guido Günther wrote:
> 
> 
> > Argh...we must not pass that long line to update-ref (as the message for
> > the reflog) we only want it in the commit message
> 
> Did you see my patch? We could still include part of the changelog...

We only shorten the reflog, not the changelog. It was a bug in the first
place that we leaked the whole changelog into the reflog. This was
o.k. as both were just the "imported " onelineers but now they
need to be different:

$ gbp-from-sourcetree import_dsc ../git-buildpackage_0.8.12.1.dsc

$ git reflog 
69c3697 HEAD@{0}: reset: moving to 69c369766e7b0fb5cc5c71e7510c7f858b62b1b3
69c3697 HEAD@{1}: gbp: Import Debian version 0.8.12.1

$ git log

commit 69c369766e7b0fb5cc5c71e7510c7f858b62b1b3
Author: Guido Günther 
Date:   Fri Jan 27 14:50:30 2017 +0100

Import Debian version 0.8.12.1

git-buildpackage (0.8.12.1) unstable; urgency=medium

  * Upload to unstable

git-buildpackage (0.8.12) experimental; urgency=medium


Cheers,
 -- Guido

Bug#853905: [pkg-gnupg-maint] Bug#853905: Ships incorrect /usr/lib/systemd/user/sockets.target.wants files, makes disabling impossible

[Daniel Kahn Gillmor]

On Mon 2017-02-06 12:34:36 -0500, Yuri D'Elia wrote:
> On Mon, Feb 06 2017, Michael Biebl wrote:
>>> These are all single processes just waiting.
>>> So for gpg purposes, the agent is working as intended.
>>> However, I'm perplexed as of why I have so many running.
>>
>> I guess all of this could be solved if gnupg-agent was using
>> exit-on-idle (with some sensible default for the timeout). Or is there a
>> reason why you want/need to keep gnupg-agent running all time?
>
> To do the right thing, you'd need to consider the current timeout
> settings for each key currently in the agent.

Right, the right thing to do there would be to have gpg-agent itself
just terminate quietly and cleanly when all of its caches expire, if
it's not keeping any state.  It'll get re-launched anyway when needed.

I've just raised this upstream at:

https://bugs.gnupg.org/gnupg/issue2946

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#854411: libsane-common: adequate reports obsolete conffile for libsane-common

[shirish शिरीष]

Package: libsane-common
Version: 1.0.25-3
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

Dear Maintainer,
Adequate reports libsane-common having an obsolete conffile. See

[$] adequate libsane-common  [1:42:15]

libsane-common: obsolete-conffile /etc/sane.d/kvs1025.conf

Maybe you could use what pabs (Paul Wise) did in #815563, in that the
proper thing to do would be -

Use the dpkg-maintscript-helper support provided by dh_installdeb to
remove such similar obsolete conffiles on upgrade

Also https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files

You can also see manpage of dh_installdeb vid debhelper package which
is the same thing.

I ran the same command as he did -

[$] pkg=libsane-common ; adequate $pkg ; dpkg-query -W
-f='${Conffiles}\n' $pkg | grep obsolete   [1:47:57]
libsane-common: obsolete-conffile /etc/sane.d/kvs1025.conf
 /etc/sane.d/kvs1025.conf 1e499dabfb5bbbf7439a06b08f7e2af3 obsolete

Please fix the above.

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

Kernel: Linux 4.9.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 libsane-common depends on:
ii  dpkg  1.18.18

libsane-common recommends no packages.

libsane-common suggests no packages.

-- no debconf information


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

Bug#803504: dovecot pam authentication broken

[Apollon Oikonomopoulos]

On 21:08 Mon 06 Feb , Herbert Schmid wrote:
> Please reopen, at least while discussing with upstream.

Don't worry, I'm not closing the bug. I'm just marking it as 
non-actionable for the time being.

Bug#854410: RFP: clevis -- A plugable framework for automated decryption.

[Guido Günther]

Package: wnpp
Severity: wishlist

* Package name: clevis
  Version : 2
  Upstream Author : Nathaniel McCallum
* URL : http://www.example.org/
* License : GPL
  Programming Lang: C
  Description : A plugable framework for automated decryption.

>From the README:

Clevis is a plugable framework for automated decryption. It can be used
to provide automated decryption of data or even automated unlocking of
LUKS volumes.

It support tang, shamir secret sharing, escrow using HTTP.

Bug#854358: unblock: dgit/3.10

[Ian Jackson]

Control: tag -1 - moreinfo

Jonathan Wiltshire writes ("Re: Bug#854358: unblock: dgit/3.10"):
> On 2017-02-06 11:30, Ian Jackson wrote:
> > I would like fix some bugs by providing a new dgit in stretch.  I have
> > not yet uploaded this package to sid, in case you dislike some of my
> > changes and want an even more minimal update.  (If that is the case, I
> > can strip them out and retest, since I have them as individual git
> > commits.)
> 
> They look fine. Please go ahead and update this bug when the package is 
> in sid.

Thanks.  Now uploaded.

FTR, I attach the debdiff, which as promised is identical to the
previous diff apart from the changelog timestamp (and diff formatting
differences; git diff produces some more decoration).

Regards,
Ian.

diff -Nru dgit-3.9/debian/changelog dgit-3.10/debian/changelog
--- dgit-3.9/debian/changelog   2017-01-25 16:21:53.0 +
+++ dgit-3.10/debian/changelog  2017-02-06 17:49:39.0 +
@@ -1,3 +1,25 @@
+dgit (3.10) unstable; urgency=medium
+
+  Bugfixes:
+  * dgit: Copy several user.* settings from main tree git local config
+to dgit private workarea.  Closes:#853085.
+  * dgit: Strip initial newline from Changes line from dpkg-parsechangelog
+so as to avoid blank line in commit messages.  Closes:#853093.
+  * dgit: Do not fail when run with detached HEAD.  Closes:#853022.
+  * dgit: Be much better about commas in maintainer changelog names.
+Closes:#852661.
+
+  Test suite:
+  * quilt-useremail: New test for user config copying (#853085).
+  * lib-import-chk: Test that commits have smae authorship as appears in
+the changelog.  (Or, at least, the same authorship set.)
+  * import-maintmangle: New test for changelog Maintainer mangling.
+
+  Documentation:
+  * Fix typos.  Closes:#853125.  [Nicholas D Steeves]
+
+ -- Ian Jackson   Mon, 06 Feb 2017 17:49:39 
+
+
 dgit (3.9) unstable; urgency=medium
 
   Improvements:
diff -Nru dgit-3.9/debian/tests/control dgit-3.10/debian/tests/control
--- dgit-3.9/debian/tests/control   2017-01-23 16:20:07.0 +
+++ dgit-3.10/debian/tests/control  2017-02-06 17:49:31.0 +
@@ -29,7 +29,7 @@
 Depends: dgit, dgit-infrastructure, devscripts, debhelper (>=8), fakeroot, 
build-essential
 Restrictions: x-dgit-git-only
 
-Tests: absurd-gitapply badcommit-rewrite build-modes build-modes-asplit 
build-modes-gbp-asplit clone-clogsigpipe clone-gitnosuite clone-nogit 
debpolicy-dbretry debpolicy-newreject debpolicy-quilt-gbp defdistro-rpush 
defdistro-setup distropatches-reject drs-clone-nogit drs-push-masterupdate 
drs-push-rejects dsd-clone-nogit dsd-divert fetch-localgitonly 
fetch-somegit-notlast gbp-orig gitconfig import-dsc import-native 
import-nonnative import-tarbomb inarchivecopy mismatches-contents 
mismatches-dscchanges multisuite newtag-clone-nogit oldnewtagalt 
oldtag-clone-nogit orig-include-exclude orig-include-exclude-chkquery 
overwrite-chkclog overwrite-junk overwrite-splitbrains overwrite-version 
protocol-compat push-buildproductsdir push-newpackage push-nextdgit quilt 
quilt-gbp quilt-gbp-build-modes quilt-singlepatch quilt-splitbrains rpush 
tag-updates test-list-uptodate trustingpolicy-replay unrepresentable version-opt
+Tests: absurd-gitapply badcommit-rewrite build-modes build-modes-asplit 
build-modes-gbp-asplit clone-clogsigpipe clone-gitnosuite clone-nogit 
debpolicy-dbretry debpolicy-newreject debpolicy-quilt-gbp defdistro-rpush 
defdistro-setup distropatches-reject drs-clone-nogit drs-push-masterupdate 
drs-push-rejects dsd-clone-nogit dsd-divert fetch-localgitonly 
fetch-somegit-notlast gbp-orig gitconfig import-dsc import-maintmangle 
import-native import-nonnative import-tarbomb inarchivecopy mismatches-contents 
mismatches-dscchanges multisuite newtag-clone-nogit oldnewtagalt 
oldtag-clone-nogit orig-include-exclude orig-include-exclude-chkquery 
overwrite-chkclog overwrite-junk overwrite-splitbrains overwrite-version 
protocol-compat push-buildproductsdir push-newpackage push-nextdgit quilt 
quilt-gbp quilt-gbp-build-modes quilt-singlepatch quilt-splitbrains 
quilt-useremail rpush tag-updates test-list-uptodate trustingpolicy-replay 
unrepresentable version-opt
 Tests-Directory: tests/tests
 Depends: dgit, dgit-infrastructure, devscripts, debhelper (>=8), fakeroot, 
build-essential
 
diff -Nru dgit-3.9/dgit dgit-3.10/dgit
--- dgit-3.9/dgit   2017-01-25 15:43:50.0 +
+++ dgit-3.10/dgit  2017-02-06 17:49:31.0 +
@@ -1699,6 +1699,11 @@
 sub mktree_in_ud_here () {
 runcmd qw(git init -q);
 runcmd qw(git config gc.auto 0);
+foreach my $copy (qw(user.email user.name user.useConfigOnly)) {
+   my $v = $gitcfgs{local}{$copy};
+   next unless $v;
+   runcmd qw(git config), $copy, $_ foreach @$v;
+}
 rmtree('.git/objects');
 symlink '../../../../objects','.git/objects' or die $!;
 setup_gitattrs(1);
@@ -1990,7 +1995,14 @@
 sub clogp_authline ($) {
 

Bug#852398: chromium: option --enable-remote-extensions does work: extensions cannot be enabled nor be installed

[Michael Franzl]

On Mon, 6 Feb 2017 11:27:55 +0100 Simon Ruderich  wrote:
> Setting the option in a environment variables seems to work as
> workaround for me:
> 
> CHROMIUM_FLAGS='--enable-remote-extensions' chromium

I put this into ~/.profile:

CHROMIUM_FLAGS='--enable-remote-extensions'

Confirmed working as a workaround.

I understand the security aspect, but this setting really should be
added as a package configuration option, and the user explicitly queried
IMO.

Michael

Bug#854333: git-buildpackage: fails to import native packages with large debian/changelog

[Chris Lamb]

Guido Günther wrote:


> Argh...we must not pass that long line to update-ref (as the message for
> the reflog) we only want it in the commit message

Did you see my patch? We could still include part of the changelog...


Regards,

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