Bug#833510: ITP: ruby-tzinfo-data -- timezone data for tzinfo

[Paul Wise]

On Fri, Aug 5, 2016 at 5:33 PM, Andrew Lee wrote:

>   Description : timezone data for tzinfo
>
>This tzinfo-data contains data from the IANA Time Zone database
>packaged as Ruby modules for use with TZInfo.

Folks have been trying to get embedded copies of the tzdata removed
from Debian for a long time. I would suggest that whatever uses this
should instead just directly use the data from the tzdata package.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#828248: bitcoin: FTBFS with openssl 1.1.0

[Anthony Towns]

Source: bitcoin
Followup-For: Bug #828248

> OpenSSL 1.1.0 is about to released.  During a rebuild of all packages
> using OpenSSL this package fail to build.  A log of that build can be found
> at:
> https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/bitcoin_0.11.2-1_amd64-20160529-1408

>From that url:

> checking for RAND_egd in -lcrypto... no
> configure: error: Detected LibreSSL: This is NOT supported, and may
> break consensus compatibility!

This check has been removed upstream for some time now:

https://github.com/bitcoin/bitcoin/commit/59783884766d00866e190ba5ae761916e932df10

Building 0.12.1 fails due to the new gcc-6 default in unstable (see bug
812275), but 0.13.0rc2 builds okay and the tests pass.

Cheers,
aj

Bug#833433: jessie-pu: package flashplugin-nonfree/1:3.6.1+deb8u1

[Bart Martens]

Control: tag -1 - moreinfo

On Fri, Aug 05, 2016 at 11:02:40PM +0200, Julien Cristau wrote:
> Control: tag -1 moreinfo
> 
> The current code is not a guarantee for the future.  The function is
> named "human_time".  That makes it IMO wrong to use in a script.  It's
> also not stable across timezones.

Using %Y now, see attached debdiff. Permission to upload?

Regards,

Bart Martens
diff -Nru flashplugin-nonfree-3.6.1/debian/changelog 
flashplugin-nonfree-3.6.1+deb8u1/debian/changelog
--- flashplugin-nonfree-3.6.1/debian/changelog  2014-12-21 10:03:31.0 
+0100
+++ flashplugin-nonfree-3.6.1+deb8u1/debian/changelog   2016-08-04 
11:01:28.0 +0200
@@ -1,3 +1,10 @@
+flashplugin-nonfree (1:3.6.1+deb8u1) jessie; urgency=medium
+
+  * update-flashplugin-nonfree: Delete old get-upstream-version.pl from cache.
+Closes: #833413.
+
+ -- Bart Martens   Thu, 04 Aug 2016 10:59:38 +0200
+
 flashplugin-nonfree (1:3.6.1) unstable; urgency=medium
 
   * debian/control: Pre-Depends: ca-certificates.  Closes: #773633.
diff -Nru flashplugin-nonfree-3.6.1/update-flashplugin-nonfree 
flashplugin-nonfree-3.6.1+deb8u1/update-flashplugin-nonfree
--- flashplugin-nonfree-3.6.1/update-flashplugin-nonfree2014-09-15 
17:33:57.0 +0200
+++ flashplugin-nonfree-3.6.1+deb8u1/update-flashplugin-nonfree 2016-08-06 
07:09:30.0 +0200
@@ -183,6 +183,15 @@
 
if [ -f $cachedir/get-upstream-version.pl ]
then
+   if [ "`stat --format=%Y $cachedir/get-upstream-version.pl`" -lt 
"1470296100" ] # 2016-08-04 09:35:00.0 +0200
+   then
+   [ "$verbose" != "yes" ] || echo "deleting old 
$cachedir/get-upstream-version.pl"
+   rm $cachedir/get-upstream-version.pl
+   fi
+   fi
+
+   if [ -f $cachedir/get-upstream-version.pl ]
+   then
cp $cachedir/get-upstream-version.pl .
upstream=`perl get-upstream-version.pl $arch_wget 2> /dev/null` 
|| true
 

Bug#782904: python-debian test failures with gnupg-2.1.3

[Stuart Prescott]

Control: severity -1 serious

The test suite failures reported in this bug still exist with gpgv 2.1.14-3 
from experimental.

Once gpgv is provided by gnupg2, this will cause a FTBFS; since this is now 
imminent [0], raising the severity seems appropriate.

[0] https://lists.debian.org/debian-devel-announce/2016/08/msg0.html

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#809611: d-i fails to boot on HP mv2120

[Mike Thompson]

Hi Martin,

I attempted a network installation on an MV1220 currently running Jessie
following your instructions regarding setting the load address of 0x60
and the netboot.img from the following location from the daily builds:

https://d-i.debian.org/daily-images/armel/daily/orion5x/network-console/hp/mv2120/

The good news is that given the load address change from 0x40 to
0x60 allowed the MV2120 to boot into the ssh based installer.

The bad news is the installed failed from what looked like some sort of
segmentation faults in the installer from the looks of the logs which I
included below.

Below is the error I received:


 lu [!!] Debian installer main menu tk
 x   x
 x Installation step failed  x
 x An installation step failed. You can try to run the failing item  x
 x again from the menu, or skip it and choose something else. Thex
 x failing step is: Choose mirror to install from (menu item)x
 x   x
 x x
 x   x
 mqqqj

Using the expert installation fails in just the same manner.

Attached below are the debug hardware summary and syslog which I hope are
useful:

Hardware Summary
-
uname -a: Linux backup 4.6.0-1-marvell #1 Debian 4.6.4-1 (2016-07-18)
armv5tel GNU/Linux
lsmod: Module  Size  Used by
lsmod: ext4  495393  0
lsmod: crc16   1229  1 ext4
lsmod: jbd2   82552  1 ext4
lsmod: crc32c_generic  1561  0
lsmod: mbcache 3990  1 ext4
lsmod: sd_mod 30069  0
lsmod: sata_mv25273  0
lsmod: libata162527  1 sata_mv
lsmod: scsi_mod  176204  2 libata,sd_mod
lsmod: mvmdio  3004  1
lsmod: mv643xx_eth26419  0
lsmod: of_mdio 5511  2 mvmdio,mv643xx_eth
lsmod: libphy 27187  3 mvmdio,of_mdio,mv643xx_eth
df: Filesystem   1K-blocks  Used Available Use% Mounted on
df: none 1240420 12384   0% /run
df: devtmpfs 57312 0 57312   0% /dev
free:  total used free   shared  buffers
free: Mem:1240203818885832217200
free: -/+ buffers:  3818885832
free: Swap:000
/proc/cmdline: console=ttyS0,115200
/proc/cpuinfo: processor : 0
/proc/cpuinfo: model name : Feroceon rev 0 (v5l)
/proc/cpuinfo: BogoMIPS : 333.33
/proc/cpuinfo: Features : swp half thumb fastmult edsp
/proc/cpuinfo: CPU implementer : 0x41
/proc/cpuinfo: CPU architecture: 5TEJ
/proc/cpuinfo: CPU variant : 0x0
/proc/cpuinfo: CPU part : 0x926
/proc/cpuinfo: CPU revision : 0
/proc/cpuinfo:
/proc/cpuinfo: Hardware : HP Media Vault mv2120
/proc/cpuinfo: Revision : 
/proc/cpuinfo: Serial : 
/proc/iomem: -07ff : System RAM
/proc/iomem:   8000-00519923 : Kernel code
/proc/iomem:   00562000-0060648f : Kernel data
/proc/iomem: f1011000-f101101f : mv64xxx_i2c.0
/proc/iomem:   f1011000-f101101f : mv64xxx_i2c.0
/proc/iomem: f1012000-f10120ff : serial8250.0
/proc/iomem:   f1012000-f101201f : serial
/proc/iomem: f1020108-f102010b : orion_wdt
/proc/iomem: f1020300-f1020303 : orion_wdt
/proc/iomem: f105-f1050fff : orion-ehci.0
/proc/iomem: f1060900-f10609ff : xor 0 low
/proc/iomem: f1060b00-f1060bff : xor 0 high
/proc/iomem: f1072000-f1075fff : ge00 base
/proc/iomem:   f1072004-f1072087 : ge00 mvmdio base
/proc/iomem: f108-f1084fff : sata base
/proc/iomem: f109-f109 : regs
/proc/iomem: f10a-f10a0fff : orion-ehci.1
/proc/iomem: f220-f2201fff : sram
/proc/iomem: f400-f407 : physmap-flash.0
/proc/iomem:   f400-f407 : physmap-flash.0
/proc/interrupts:CPU0
/proc/interrupts:   1:  14414  orion_irq Level orion_tick
/proc/interrupts:   4:745  orion_irq Level serial
/proc/interrupts:   6: 97  orion_irq Level mv64xxx_i2c
/proc/interrupts:  22:284  orion_irq Level eth0
/proc/interrupts:  23:   1180  orion_irq Level orion-mdio
/proc/interrupts:  30: 67  orion_irq Level sata_mv[sata_mv.0]
/proc/interrupts:  31:  2  orion_irq Level mv_xor.0
/proc/interrupts:  36:  0  orion_gpio0  36 Edge  rtc-pcf8563
/proc/interrupts: Err:  0
/proc/meminfo: MemTotal: 124020 kB
/proc/meminfo: MemFree:   85804 kB
/proc/meminfo: MemAvailable:  84756 kB
/proc/meminfo: Buffers:   0 kB

Bug#833482: [Aptitude-devel] Bug#833482: aptitude: doesn't detect obsolete candidate package (versions)

[Manuel A. Fernandez Montecelo]

Hi,

2016-08-06 2:13 GMT+01:00 Christoph Anton Mitterer :
> Mhh... a bit further below in the text, aside from all the discussion
> about whether this is supported or not,... I might have found some way
> to go how aptitude could easily (at least semantically) identify
> packages which are obsolete in the sense of: will this package (in the
> current apt_preferences/sources.list config) still receive updates
> (assuming that the repos themselves are still maintained) or not.

I can only guess, but I think that the original motivation is that
when you use stable or unstable, if some package is classified as
Obsolete, is a reason to take special care about it, and so you can
freely delete it if you don't care; or if you care, add it again to
the archive (if was orphaned and deleted because it was an old version
with low popularity but it's OK otherwise).

This probably predates auto-installed, so it must have been a big deal
back then to clear cruft.  This doesn't mean that you don't have to
take an eye on other packages that you mix and match from different
sources.

So Obsolete/Local doesn't have any relation to "how secure is to use a
package or not".  It's "whether it's still downloadable from
somewhere" or "I could not find this package in any repo, but it's
installed in this system".  This maps quite direcly to other
functionalities, like "the changelogs are only available locally" or
"there are new changelogs in the server that the user might want to
see before installing".

Also, there's the peculiarity of testing, when packages are
auto-removed and then pop back again into life, in the last few years.
Each suite has its own peculiarities.  Obsolete is pretty useless for
this case of auto-removed packages.


On the topic of security, you can have installed v1.3.1~rc1 of a
package from experimental with dangerous bugs or security issues, and
v1.2.1 from unstable will not be installed (in most common
configurations), despite the risk for your system.  Obsolete in
aptitude and security don't have much to do with each other, it's only
an artifact of mixing distros and only one of a myriad ways in which
things can go obfuscated in terms of security when playing with
different distros, pinning, etc.


>> (there are similar warnings about mixing different Debian
>> distributions/suites except in completely compatible overlays, e.g.
>> "security")
>
> Well than why not hardcoding all these repos, and no longer allowing
> people to configure them? Why not dropping apt_preferences if it's
> anyway "not supported" and can just cause insecure situations?

Beause in Debian we really like to give the option of shooting
themselves in the foot if they really insist on it.  Freedom and all
that.

We're not so keen on babysitting the users and monitor them with
twelve drones and raise an alarm in the police every time that they
step into a pond, which might be small pothole in the roadside or
might be a big lake.

Basically the contributors of Debian strive to support the most common
use cases, and it's hard enough, and a good enough gift to society, if
you ask me.

If people want to go playing around with our tools it's fine, but we
don't want to be healing them or paying the healthcare after hurting
themselves for using our tools in a way that we explicitly say that we
don't want to support, even if they go handwaving all around.


> In the end, what's really interesting about obsolete packages is:
> package foo won't get any further security updates. If you continue to
> use it, you're on your own.
>
> This information is currently not available to aptitude users, when
> they do *anything* that uses multiple repos, except those which are
> fully aligned (e.g. stable + security updates).

Since stable is the only suite that has guaranteed security updates,
all of your considerations before are not relevant.  unstable doesn't
have security support, testing doesn't either, external repos can
interfere with debian repos in ways that they take over, etc.

So your only relevant use-case for security is when using
stable+security, and there Obsoletes works well.


> And as I've said just above... if one doesn't care about security
> updates, than having the information whether something is obsolete or
> not is pretty pointless. Either one hasn't installed it and then it's
> simply gone... or one has it installed and can just happily continue to
> use it.

Actually, the way in which I have seen people to use Obsolete is
mainly to remove cruft, of packages that are no longer needed but are
marked as manually installed for some reason (bugs in aptitude/apt/etc
or not).

I never heard of people worried about obsolete packages in terms of
security, unless they are daemons or something special (often after
stable updated to next-stable).


Also, there's the peculiarity of testing, when packages are
auto-removed and then pop back again into life, in the last few years.
Each suite has its own 

Bug#789886: linux-image-3.2.0-4-kirkwood: Couldn't find /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb

[Martin Michlmayr]

* Jesse Adelman  [2015-06-20 20:35]:
> When I upgrade this package on my Debian Wheezy Sheevaplug, I get this error:
> 
> Couldn't find /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb

> Full log:
> 
> flash-kernel: installing version 3.2.0-4-kirkwood
> Generating kernel u-boot image... done.
> Taking backup of uImage.
> Installing new uImage.
> Generating initramfs u-boot image... done.
> Taking backup of uInitrd.
> Installing new uInitrd.
> Couldn't find /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb
> dpkg: error processing package flash-kernel (--configure):
>  subprocess installed post-installation script returned error exit status 1

Sorry for the delay in responding to this bug.  I believe I know what
the issue is.  I've copied Ian Campbell who knows the code best.

Ian, I've attached a proposed patch below.  Do you agree with the
logic described or am I missing something?

The log also shows:

> update-initramfs: Generating /boot/initrd.img-3.2.0-4-kirkwood
> /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb not found
> /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb not found

I'm not sure where this is from but it seems isn't not causing an
actual error.


Only create DTB boot file on kernels that require DTB

Boot-DTB-Path can be specified to install the DTB to a file.  Some
machines, such as the SheevaPlug, contain both a DTB-Append-From and
a Boot-DTB-Path.

If DTB-Append-From is set, a verson check is performed to see if the
DTB is required and dtb_append is set to "yes" or "no" accordingly.
However, there is no version check for Boot-DTB-Path.  This can lead
to errors that the DTB couldn't be found on older kernels (i.e. older
than the version specified in DTB-Append-From).

Arguably, DTB-Append-From and Boot-DTB-Path together don't make sense
(why would you append the DTB _and_ install it to /boot), but it's
possible that users rely on this behaviour.

Therefore, only honour Boot-DTB-Path if $dtb_append is not "no".  If
it's "yes" or empty, we want to install the DTB to Boot-DTB-Path.
But if $dtb_append is "no", it means we're on an old kernel without
DTBs.

diff --git a/functions b/functions
index 368cbf2..c4ef6a3 100644
--- a/functions
+++ b/functions
@@ -939,7 +939,7 @@ case "$method" in
boot_script="$tmpdir/boot.scr"
backup_and_install "$boot_script" "$boot_script_path"
fi
-   if [ -n "$boot_dtb_path" ]; then
+   if [ -n "$boot_dtb_path" ] && [ "$dtb_append" != "no" ]; then
boot_dtb_path="$boot_mnt_dir/$boot_dtb_path"
boot_dtb=$(find_dtb_file)
if [ ! -f "$boot_dtb" ]; then

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#806045: heimdal: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Brian May]

Santiago Vila  writes:

> Hope this helps.

Hopefully the fix I just applied to git is correct and will solve this.

Not going to upload however, as I can't build due to some of the tests
failing (I think this is an unrelated issue).
-- 
Brian May 

Bug#421043: [Aptitude-devel] Bug#707320: marked as done (aptitude: implement partially forgetting new packages)

[Manuel A. Fernandez Montecelo]

2016-08-05 17:52 GMT+01:00 Christoph Anton Mitterer :
> Hey...
>
>
> On Sun, 2016-07-24 at 15:41 +0100, Manuel A. Fernandez Montecelo wrote:
>> Given that it's an improvement over the previous functionality (all
>> or
>> nothing), in any case, it's more flexible than before...  but I
>> disagree
>> that it's more unflexible than your proposal (read on).
>
> Hmm I tried it now for a few days, and while in principle it allows for
> more things to do, my original view hasn't changed and I'd still
> consider unfortunate for practical use. :-(
>
> The major use case I'd have seen in the selective forgetting is that
> one can keep those packages one wants to have a look at later on.
> This use case typically means that only a small subset of the new
> packages is wanted to be kept (otherwise one could just keep all).
>
> This in turn however makes the matching based solution rather
> impractical for day to day use:
> - new packages turn up in many sections, and often not all of those in
>   one section are interesting enough to be kept
>   thus filtering out based on the section doesn't really seem to work
>   in many cases, and even if it would one would still have to type in
>   all those sections one wants to discard (which can be quite some)
> - filtering out single packages is unhandy either
>   As I've said before, it's typically the minority one wants to select
>   but the filtering works vice-versa (i.e. selecting all those one
>   wants to discard). Even without fast growing sections like dbg[sym]
>   this end up being unusable.
>   Inverting the filter wouldn't help IMO either, one would still need
>   to write up all those packages that are to be kept, and since one
>   needs to navigate through the package view and often all interesting
>   packages wouldn't fit on one screen, I'd alrady need another editor
>   or so, where I write up the interesting things.

I didn't implement this new functionality with section names in mind,
etc for this particular use case.  I just reused patterns, which is
how many other aptitude functionalities work.

I don't know why you focus the discussion in sections only.  One might
discard by any pattern, including "forget all new but those from
section games", "forget all without that debtag", "forget all not from
this source package", "forget all which are not part of kde", "forget
all which don't contain this word in it's description: GPG", "forget
all which are not called php* or gnome*".

This is vastly more powerful and quick than forgetting packages one by
one, when there are many.  If there are 140 new packages every time
that one upgrades/looks into the list, forgetting it one by one it
would be vastly more tedious in comparison to filter out those 140
packages by using 1 to 10 patterns.

Also, one can use user-tags for this.  In your case it might not work,
but again it's a vast improvement over the previous case when it was
only all-or-none.


You have a tendency to generalise problems as if all people used
aptitude in the same way as you and experienced the same frustrations.
But frankly, many of the things that you describe look quite strange
to me and I never heard of anybody needing to keep more than a
screenful of packages marked as new because they are very interesting,
in every update.  Most of the "new packages" coming every day are
actually -dbgsym or renames of libraries, so they're not even "new" in
a sense.

So, well, I am sorry if it doesn't work well for you, but it's a vast
improvement over the previous situation for many use cases, it's not
worse than before for the rest, I am happy with it and I am not going
to undo it even if you don't find it useful.  Even if yours was
implemented, this one would stay.

And your suggestion had the problems that I described, mostly a
headache in terms of implementation, so I'm not contemplating it at
the moment.


>> Had the "F" shortcut not been taken for a completely different
>> purpose,
> Doesn't F anyway make just sense on already installed packages?
> While there can be packages in the New section which are installed (but
> just not forgotten yet),... I'm sure no one would bother if F would get
> another meaning when one is in the New tree.

Yes, packages can be Installed and New, I have plenty of them in my system.

"overloading" the meaning of F would be a bad idea IMO, if nothing
else because it would confusing in the documentation, but also because
the implementation doesn't permit to do this cleanly.


>> One of the problems that I found with your suggestions is that if
>> people
>> don't know about the feature and press "f" expecting that everything
>> is
>> forgotten as before, and only one package or a small section is
>> forgotten, they might think that forgetting-new is not working at
>> all,
>> or not working properly, or at least it will be puzzling for a while
>> until they learn that it's a "new feature" and how to use it.
> Well but that's a general problem with 

Bug#833562: mumble: Looses settings at crash

[Jean-Philippe MENGUAL]

Package: mumble
Version: 1.2.16-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

Well, various crashes, cf bug 793340

Mumble crashed trying joining a server, changing settings, etc. 

It also happens I close the session, letting mumble be stopped by Systemd.

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

After crash, restart. It's not systematic, but very often: audio settings have
disappear. I need to set them again.

Besides, today, I lost my certificate! It needed to be renewed fully on mumble,
and I couldn't connect to my server.

   * What was the outcome of this action?

Settings should be saved. Loosing privacy is really a problem I think, beyond
loss of audio settings (which is boring).

   * What outcome did you expect instead?

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

Regards,


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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=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 mumble depends on:
ii  libasound2 1.1.1-2
ii  libavahi-client3   0.6.32-1
ii  libavahi-common3   0.6.32-1
ii  libavahi-compat-libdnssd1  0.6.32-1
ii  libc6  2.23-4
ii  libg15daemon-client1   1.9.5.3-8.3
ii  libgcc11:6.1.1-10
ii  libopus0   1.1.2-1
ii  libprotobuf9v5 2.6.1-2
ii  libpulse0  9.0-1.1
ii  libqt4-dbus4:4.8.7+dfsg-8
ii  libqt4-network 4:4.8.7+dfsg-8
ii  libqt4-sql 4:4.8.7+dfsg-8
ii  libqt4-sql-sqlite  4:4.8.7+dfsg-8
ii  libqt4-svg 4:4.8.7+dfsg-8
ii  libqt4-xml 4:4.8.7+dfsg-8
ii  libqtcore4 4:4.8.7+dfsg-8
ii  libqtgui4  4:4.8.7+dfsg-8
ii  libsndfile11.0.25-10
ii  libspeechd20.8.4-2
ii  libspeex1  1.2~rc1.2-1
ii  libspeexdsp1   1.2~rc1.2-1
ii  libssl1.0.21.0.2h-1
ii  libstdc++6 6.1.1-10
ii  libx11-6   2:1.6.3-1
ii  libxi6 2:1.7.6-1
ii  lsb-release9.20160629

mumble recommends no packages.

Versions of packages mumble suggests:
pn  mumble-server  
ii  speech-dispatcher  0.8.4-2

-- no debconf information

Bug#833561: arm64: dtbs no longer installed in vendor subdir

[Martin Michlmayr]

Package: linux
Version: 4.7~rc7-1~exp1
Severity: important

DTBs on arm64 are normally installed in vendor subdirectories, e.g.:

./usr/lib/linux-image-4.6.0-1-arm64/nvidia/tegra210-p2371-2180.dtb

But this is no longer true in 4.7:

./usr/lib/linux-image-4.7.0-rc7-arm64/tegra210-p2371-2180.dtb

I am not sure why.  It seems scripts/Makefile.dtbinst and arch/arm64/Makefile
weren't modified upstream and we use dtbs_install.

I didn't have much time to investigate but I hope someone can look into this.


I ran dtbs_install manually to verify:

ARCH=arm64 make  -n -C debian/build/build_arm64_none_arm64 dtbs_install 
INSTALL_DTBS_PATH=/home/tbm/debian/linux-4.7~rc7/x
echo '  INSTALL arch/arm64/boot/dts/amd/amd-overdrive.dtb'; mkdir -p 
/home/tbm/debian/linux-4.7~rc7/x; cp arch/arm64/boot/dts/amd/amd-overdrive.dtb 
/home/tbm/d ebian/linux-4.7~rc7/x

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#833549: [buildd-tools-devel] Bug#833549: sbuild: autopkgtest fails when sbuild obtains the .dsc with apt-get source

[Sean Whitton]

Hello,

On Sat, Aug 06, 2016 at 01:02:59AM +0200, Johannes Schauer wrote:
> > Doesn't sbuild have a mechanism to get files out of the chroot?  How else
> > does it extract the .deb files that are built?
> 
> It does. But it would be unexpected behaviour if sbuild would also produce the
> source package if you just tell it `sbuild package`. The expected behaviour in
> this case would be for sbuild to just create the binary packages. Unless you
> add the --source flag of course, which would be a workaround as described
> above.
> 
> Do you see a solution to this problem?

What I had in mind was that sbuild would extract the .dsc just to run
autopkgtest.  It could put it in /tmp, pass that on the autopkgtest
command line, and then delete it afterwards.  Would that be hard to
implement?

-- 
Sean Whitton

Bug#833482: [Aptitude-devel] Bug#833482: aptitude: doesn't detect obsolete candidate package (versions)

[Christoph Anton Mitterer]

Mhh... a bit further below in the text, aside from all the discussion
about whether this is supported or not,... I might have found some way
to go how aptitude could easily (at least semantically) identify
packages which are obsolete in the sense of: will this package (in the
current apt_preferences/sources.list config) still receive updates
(assuming that the repos themselves are still maintained) or not.

Not sure how difficult it would be to implement the abstract criterion
into actual code, though ;)

Anyway, if you're as tired about the political discussion whether
things is de jure / de facto supported or not, just skip on to (*).

If it would be easy to implement, you could either replace the current
"obsolete packages with it" (as I try to motivate below, it doesn't
make that much sense in the current form), or perhaps add it as a new
category, "packages that don't receive updates in the current config".



On Sat, 2016-08-06 at 01:12 +0100, Manuel A. Fernandez Montecelo wrote:
> The underlying problem is that you think that using Debian + external
> repositories which don't play well with Debian is a supported
> scenario.

Well "supported" is always a relative thing. It may not be supported in
the sense that someone from Debian feels officially responsible, but
it's actively and actually quite powerfully supported on the technical
side starting with sources.list allowing for multiple repos up to e.g.
the mechanisms of apt_preferences.

So why not making these situations safe, simply by properly telling
users when their packages won't receive anymore updates?

It's a bit cheeky to have all these mechanisms in Debian, actually
advertising them in the documentation, for quite a while even depending
on them (e.g. when DMO was the only resort to get usable multimedia
capabilities into Debian),... and on the same time saying: "nope, don't
want to properly (technically) support these functionalities).

At least I found no reference in the sources.list, apt_preferences or
aptitude manpages that things will be insecure in certain situations,
when multiple repos are used.



> "In most situations if you stick with one distribution you should use
> that and not mix packages from other distributions. Many common
> breakages arise due to people running a distribution and trying to
> install Debian packages from other distributions. The fact that they
> use the same formatting and name (.deb) does not make them
> inmediately
> compatible."

This quite clearly refers rather to the problems resulting from
dependencies than to package management software not properly detecting
situations in which software is really obsolete.


> (there are similar warnings about mixing different Debian
> distributions/suites except in completely compatible overlays, e.g.
> "security")

Well than why not hardcoding all these repos, and no longer allowing
people to configure them? Why not dropping apt_preferences if it's
anyway "not supported" and can just cause insecure situations?


> If DMO had transcode as a well supported package (perhaps packaging a
> maintained fork while keeping the same name, for example), it
> wouldn't
> be a security problem at all, you could switch to it instead.
Not if one has pinned it down via apt_preferences before.
Again, I really think that the question of whether DMO is well
[security]supported or not is completely out of question here.
And there are so many security questionable things in Debian, that it's
probably not appropriate to point at other "projects", either.


>   From
> aptitude's POV, it's not "obsolete", because it's present in other
> repo.
And as I've said, that's the problem.


Think about it this way:

What is the motivation behind having the knowledge "whether a package
is obsolete or not"?

If one hasn't installed it in the first place, then knowing that
package foo is now obsolete is pretty much useless from the package
management PoV.
Sure one can see: Debian has had this in the past, but not longer.
So what?

If one has it installed, what's the use of seeing that it's now
obsolete? I'd say either:
- To see that one can remove it safely in case of dependencies cannot
longer be fulfilled because of it.
- To notice that this is basically out-of-Debian-warranty (i.e no more
  updates - whether security or not).

The former case is probably largely irrelevant, either other packages
Conflict/Break/Replace/etc. the obsolete package already (and then I
don't need the info that's is obsolete) or they don't (and then I could
just keep the obsolete package if I don't care for security/new
versions).

So IMO the important case if the 2nd. Now just not getting new upstream
versions (with new features) is perhaps nice to know, but not knowing
it doesn't hurt one much either. If new features are missed people will
search and find out whether package foo is upstream-dead or just gone
from Debian.

In the end, what's really interesting about obsolete packages is:
package foo won't get any 

Bug#812165: pinot: patch to fix FTBFS

[Olly Betts]

Control: tags 812165 + patch

While checking rdeps of xapian-core in preparation for the upcoming
transition to xapian-core 1.4.0, I hit the current FTBFS of pinot with
GCC6.  The attached patch fixes that FTBFS.

However, the resulting build segfaults when the pinot binary is run.
A brief investigation suggests it's some sort of symbol mangling issue
as this log entry appears:

$ more ~/.pinot/pinot.log
FilterFactory::loadFilters: /usr/lib/pinot/filters/libexternalfilter.so: 
undefined symbol: _Z16get_filter_typesRSt3setISsSt4lessISsESaISsEE

I'm not an active user of pinot, so didn't have a .pinot before trying
to fix this FTBFS.

Incidentally, I notice there's also a newer release of pinot: 1.08.  The
current watch file isn't showing this, I suspect due to google code
going read-only.

Cheers,
Olly
diff -Nru pinot-1.05/debian/changelog pinot-1.05/debian/changelog
--- pinot-1.05/debian/changelog	2015-09-07 17:59:39.0 +1200
+++ pinot-1.05/debian/changelog	2016-08-06 12:13:24.0 +1200
@@ -1,3 +1,11 @@
+pinot (1.05-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix to build with GCC6, new patch: fix-ftbfs-with-gcc6.patch
+(Closes: #812165)
+
+ -- Olly Betts   Sat, 06 Aug 2016 12:12:06 +1200
+
 pinot (1.05-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru pinot-1.05/debian/patches/fix-ftbfs-with-gcc6.patch pinot-1.05/debian/patches/fix-ftbfs-with-gcc6.patch
--- pinot-1.05/debian/patches/fix-ftbfs-with-gcc6.patch	1970-01-01 12:00:00.0 +1200
+++ pinot-1.05/debian/patches/fix-ftbfs-with-gcc6.patch	2016-08-06 12:02:50.0 +1200
@@ -0,0 +1,17 @@
+Description: Fix to build with GCC6
+Author: Olly Betts 
+Bug-Debian: https://bugs.debian.org/812165
+Forwarded: no
+Last-Update: 2016-08-06
+
+--- pinot-1.05.orig/IndexSearch/ModuleFactory.cpp
 pinot-1.05/IndexSearch/ModuleFactory.cpp
+@@ -132,7 +132,7 @@ IndexInterface *ModuleFactory::getLibrar
+ 		(typeIter->second.m_canIndex == false))
+ 	{
+ 		// We don't know about this type, or doesn't support indexes
+-		return false;
++		return NULL;
+ 	}
+ 
+ 	void *pHandle = typeIter->second.m_pHandle;
diff -Nru pinot-1.05/debian/patches/series pinot-1.05/debian/patches/series
--- pinot-1.05/debian/patches/series	2012-06-23 15:36:32.0 +1200
+++ pinot-1.05/debian/patches/series	2016-08-06 12:02:22.0 +1200
@@ -1 +1,2 @@
 boost1.48.patch
+fix-ftbfs-with-gcc6.patch


signature.asc
Description: PGP signature

Bug#833482: [Aptitude-devel] Bug#833482: aptitude: doesn't detect obsolete candidate package (versions)

[Manuel A. Fernandez Montecelo]

Control: tags -1 - security
Control: close -1


2016-08-05 23:06 GMT+01:00 Christoph Anton Mitterer :
> Control: reopen -1
> Control: tags -1 + security
>
> On Fri, 2016-08-05 at 22:49 +0100, Manuel A. Fernandez Montecelo wrote:
>> This effect is an interference caused by the repositories that you
>> use.
>> Debian doesn't sanction the use of any unofficial repositories, and
>> DMO
>> is well known in the community for causing all sorts of problems when
>> using along with the main Debian repositories, such as this one.
>
> So? The underlying problem exists whether or not DMO is well
> maintained.
> If any non-Debian repo is configured that uses the same package names
> (and I don't think that Debian claims namespace authority of all names)
> than it wouldn't be detected if the candidate versions are obsolete.

The underlying problem is that you think that using Debian + external
repositories which don't play well with Debian is a supported
scenario.

From: http://www.debian.org/doc/manuals/debian-faq/ch-choosing.en.html

"In most situations if you stick with one distribution you should use
that and not mix packages from other distributions. Many common
breakages arise due to people running a distribution and trying to
install Debian packages from other distributions. The fact that they
use the same formatting and name (.deb) does not make them inmediately
compatible."

(there are similar warnings about mixing different Debian
distributions/suites except in completely compatible overlays, e.g.
"security")


Using repos which cause namespace clashes and the "overlay" doesn't
have the "base" into account is prone to this kind of situation.  It
also happens with backports sometimes (see below).

If DMO had transcode as a well supported package (perhaps packaging a
maintained fork while keeping the same name, for example), it wouldn't
be a security problem at all, you could switch to it instead.  From
aptitude's POV, it's not "obsolete", because it's present in other
repo.  It doesn't even know where it came from, you could have
installed that package/version locally with dpkg.

The fact that it was removed from unstable is not an indication that
it's a security problem either.  It's only "obsolete" or a "security
problem" from your POV, because you know extra information that
aptitude cannot know.

The only solution for this particular problem is DMO stopping to ship
this package, if it indeed has security problems; and for this and the
more general problem of packages dropping from repositories while
present in others is you to monitor such packages, with the tools that
aptitude gives to you (and Obsolete is the wrong tool in this case).


It's not a security problem related to Debian or aptitude in any case,
and neither aptitude maintainers or the security team will be able to
do anything about this, so it's not actionable as a security issue.


>> If the example was with another repository which is well maintained
>> and
>> co-operative, e.g. "mozilla.debian.net" containing a package
>> "iceweasel"
>> for compatibility (which was removed from Debian), the package
>> shouldn't
>> be considered obsolete.
>
> The problem happens with these as well:
> Consider I have had transcode installed from sid (where it's been gone
> in the meantime) and also enabled stable (where it's still in), I'd
> expect the same as I've seen it with DMO.

Mixing stable and unstable is not supported either, precisely because
it leads to this kind of problem.


>> Obsolete from aptitude is "installed locally but not found in any
>> repo",
>> which works well for the main intended uses of aptitude.
> Well and that's the problem here, the definition of obsolete is kinda
> wrong.
> Or perhaps not wrong, but it doesn't tell you when a package no longer
> will get updates (which is however the interesting thing about
> obsolete/non-obsolete).

We already discussed this in previous bugs.

aptitude, as many other Debian tools, is designed with the main idea
in mind that users will have supported versions, e.g. only stable,
unstable, and so on.  In these cases, "obsoletes" works well and
always as expected.

Anything else, you're on your own.


>> So it's not an important bug, and aptitude is not the cause of the
>> security issue -- using DMO is.
> I don't think DMO has anything to do with...

Well, yes, to be fair DMO hasn't anything to do with it... again, the
actual problem is that you think that you can use both unstable and
DMO and report bugs as if it was a supported scenario ;)


> The "bug" or let's call it "deficiency" or "missing feature" in
> aptitude is:
> It doesn't show when packages will no longer get updates via the
> configured repos and as per configured apt_preferences.
>
> This is however quite important, as it also happens when just mixing
> Debian repos.
> Take backports... if one adds jessie-backports, and e.g. installs
> icinga2 from there, perhaps pinned via apt_preferences(8).
> It's still 

Bug#828653: Fix committed to Git

[Brian May]

Thomas Goirand  writes:

> I have sent a (one liner) fix to the Git. Can you please review it, and
> allow me to upload it (or upload it yourself)?

Please go ahead and upload.

Thanks
-- 
Brian May 

Bug#639907: Status of Ensime in Debian

[Juan Mendez]

What is the status of the RFP and ITP for this?

I intent to provide support for having ensime on Debian.

-- 
http://vejeta.com
Fidonet: 2:345/432.2
I'm an FSF member -- Help us support software freedom!
http://www.fsf.org/jf?referrer=10232

Bug#833536: pkg-haskell-tools: dht should allow uploading by FTP

[Joachim Breitner]

Hi,

Am Freitag, den 05.08.2016, 15:47 -0700 schrieb Sean Whitton:
> Hello,
> 
> On Fri, Aug 05, 2016 at 03:04:06PM -0400, Joachim Breitner wrote:
> > 
> > the reason is that I have had many FTP uploads fail and partial files
> > blocking further uploaing, which is a PITA. With ssh, partial uploads
> > do not happen (I think).
> > 
> > Anyways, "dht upload" should simply allow passing a parameter to dput
> > as HOST. Any maybe anyone who wants a non-default HOST should figure
> > out how to change dput’s defaults…
> 
> It seems wrong that I should define ssh-upload to actually upload to FTP
> in my ~/.dput.cf.  Anyway, yes, passing a parameter to override the
> default seems like the right solution.

With "someone" I meant me, not you: "dht upload" should just call dput,
and I should be able to tell dput to use ssh-upload by default.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
Debian Developer
  nome...@debian.org • https://people.debian.org/~nomeata
  XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
  https://www.joachim-breitner.de/

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

Bug#832320: aptitude: -t download broken?

[Manuel A. Fernandez Montecelo]

Control: tags -1 - moreinfo + pending


Hi,

2016-07-25 19:15 Jörg-Volker Peetz:

Manuel A. Fernandez Montecelo wrote on 07/24/16 23:53:


Basically, aptitude now calls "apt download" on your behalf.  I did this
because it seems a bit unneeded to reimplement every bit of apt
functionality instead of reusing, and specially when reimplementing it
badly -- in this case, aptitude was downloading without check for valid
signatures or anything, or other sensible things that apt probably does.


Yes, this makes sense. And from the man-page I see that apt-get knows "-t
" as well as "/".
I thought the problem I reported was just a bug in the handover to apt-get. But
I didn't take a look into the source code.


I naively thought that people wouldn't use the command much, so didn't
put a lot of effort into passing all parameters given to aptitude
through to apt.

I changed that now (so marking it as +pending), hopefully it will not
cause any problem if there's some command line argument from aptitude
that causes troubles when used in apt... let's see.



I mainly use aptitude in CLI mode an value especially the search pattern
abilities. Maybe apt-get inherits this functionality sometimes in the future ;-)


Maybe it will be implemented there, but not at the moment.

aptitude command line will continue to be there, just trying to not
reimplement the full solution already in apt for these cases when the
solution in aptitude needed to change anyway.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#833547: [buildd-tools-devel] Bug#833547: sbuild: with gpg2, sbuild-update --keygen prompts the user for a passphrase

[Johannes Schauer]

Hi,

Quoting Sean Whitton (2016-08-06 01:05:01)
> On Sat, Aug 06, 2016 at 12:58:45AM +0200, Johannes Schauer wrote:
> > Is anybody actually using that feature anymore?
> 
> The LTS guys probably are.

nope, squeeze LTS support was dropped February 2016:

https://wiki.debian.org/DebianSqueeze#Release_and_updates

> > I want to kick out everything gpg related after the squeeze release.
> > Everything that is fixed now is just to make things work until then.
> 
> I assume you mean after the stretch release? :)

Yes.

cheers, josch


signature.asc
Description: signature

Bug#833547: [buildd-tools-devel] Bug#833547: sbuild: with gpg2, sbuild-update --keygen prompts the user for a passphrase

[Sean Whitton]

On Sat, Aug 06, 2016 at 12:58:45AM +0200, Johannes Schauer wrote:
> Quoting Sean Whitton (2016-08-06 00:51:48)
> > You might also want to look into the new --quick-gen-key flag.
> 
> no sorry, but thanks.
> 
> The only reason that gpg is still around is to build stuff for squeeze.

Right, makes sense.

> Is anybody actually using that feature anymore?

The LTS guys probably are.

> I want to kick out everything gpg related after the squeeze
> release. Everything that is fixed now is just to make things work
> until then.

I assume you mean after the stretch release? :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#833549: [buildd-tools-devel] Bug#833549: sbuild: autopkgtest fails when sbuild obtains the .dsc with apt-get source

[Johannes Schauer]

Hi,

Quoting Sean Whitton (2016-08-06 00:50:56)
> On Sat, Aug 06, 2016 at 12:07:44AM +0200, Johannes Schauer wrote:
> > this is because autopkgtest is run *outside* the chroot and unless sbuild 
> > was
> > instructed to recreated the source package, the system outside will never 
> > see
> > the .dsc.
> > 
> > I suggest to fix this by automatically skipping the autopkgtest in cases 
> > where
> > sbuild downloads the source package itself to resolve this bug.
> 
> I suppose that would count as fixing the bug, but it would be nice to be
> able to run a package's autopkgtest just by typing `sbuild package`.

the thing is, that autopkgtest is run *outside* the chroot. If it were run
inside, the problem would not exist. There are already ways to do this right
now. For example you could instruct sbuild to rebuild the source package using
the --source flag. Or you could use "apt-get source" yourself and then run
sbuild on it.

> Doesn't sbuild have a mechanism to get files out of the chroot?  How else
> does it extract the .deb files that are built?

It does. But it would be unexpected behaviour if sbuild would also produce the
source package if you just tell it `sbuild package`. The expected behaviour in
this case would be for sbuild to just create the binary packages. Unless you
add the --source flag of course, which would be a workaround as described
above.

Do you see a solution to this problem?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#833547: [buildd-tools-devel] Bug#833547: sbuild: with gpg2, sbuild-update --keygen prompts the user for a passphrase

[Johannes Schauer]

Quoting Sean Whitton (2016-08-06 00:51:48)
> You might also want to look into the new --quick-gen-key flag.

no sorry, but thanks.

The only reason that gpg is still around is to build stuff for squeeze.

Is anybody actually using that feature anymore?

I want to kick out everything gpg related after the squeeze release. Everything
that is fixed now is just to make things work until then.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#833560: queued: temporary rsync files are immediately removed as stray files

[Aurelien Jarno]

Package: ftp.debian.org
Severity: important

We use rsync to upload files from the build daemons to coccia as it
happens the FTP protocol is relatively unreliable when used across
continents. rsync uses temporary files, commits 28903fa31f and
9f6be43eff added support for them in queued so that they are not deleted
as stray file immediately, but only after $stray_remove_timeout.

The recent commit 0da0b72371 reverted the change done in 9f6be43eff,
causing a lot of upload failures, which are most of the case recovered
thanks to the rsync protocol after a few tries. However for big files
(e.g. dbgsym packages) the upload takes more time than the interval
between two queued runs, so it makes impossible to upload them through
rsync. This require manual upload through FTP from the build daemons.

Therefore can you please re-allow files starting with a dot in
re_file_safe_prefix?

Thanks in advance,
Aurelien

Bug#833549: [buildd-tools-devel] Bug#833549: sbuild: autopkgtest fails when sbuild obtains the .dsc with apt-get source

[Sean Whitton]

Hello,

On Sat, Aug 06, 2016 at 12:07:44AM +0200, Johannes Schauer wrote:
> this is because autopkgtest is run *outside* the chroot and unless sbuild was
> instructed to recreated the source package, the system outside will never see
> the .dsc.
> 
> I suggest to fix this by automatically skipping the autopkgtest in cases where
> sbuild downloads the source package itself to resolve this bug.

I suppose that would count as fixing the bug, but it would be nice to be
able to run a package's autopkgtest just by typing `sbuild package`.

Doesn't sbuild have a mechanism to get files out of the chroot?  How
else does it extract the .deb files that are built?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#833547: [buildd-tools-devel] Bug#833547: sbuild: with gpg2, sbuild-update --keygen prompts the user for a passphrase

[Sean Whitton]

Hello,

On Sat, Aug 06, 2016 at 12:15:55AM +0200, Johannes Schauer wrote:
> wow... This is really unexpected given that gpg is run with the --batch
> argument. Why would gpg prompt for any user interaction if I even pass the
> --batch flag?? But at this point I should not be surprised anymore about gpg
> weirdness...

You might also want to look into the new --quick-gen-key flag.

> Thanks for testing this and providing the patch. It's in my git
> branch.

Cool :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#833536: pkg-haskell-tools: dht should allow uploading by FTP

[Sean Whitton]

Hello,

On Fri, Aug 05, 2016 at 03:04:06PM -0400, Joachim Breitner wrote:
> the reason is that I have had many FTP uploads fail and partial files
> blocking further uploaing, which is a PITA. With ssh, partial uploads
> do not happen (I think).
> 
> Anyways, "dht upload" should simply allow passing a parameter to dput
> as HOST. Any maybe anyone who wants a non-default HOST should figure
> out how to change dput’s defaults…

It seems wrong that I should define ssh-upload to actually upload to FTP
in my ~/.dput.cf.  Anyway, yes, passing a parameter to override the
default seems like the right solution.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#833559: systemd user service standard output is not line-buffered

[Felipe Sateler]

Control: tags -1 moreinfo

On 5 August 2016 at 18:22, Daniel Kahn Gillmor  wrote:
> Package: systemd
> Version: 230-7
> Severity: normal
>
> I've tested the following short-lived "daemon" as a systemd user service:
>
> ---
> #include 
> #include 
>
> int main(int argc, char **argv)
> {
>   sleep(5);
>   printf("a test\n");
>   sleep(10);
>   return 0;
> }
> ---
>
> the "a test" line doesn't show up in the user journal when i would
> expect it to.  it appears that stdout is not line-buffered.

Does it appear in the journal at all (ie, without any filters)? What
do you mean by "when I would expect it to"?

> stderr, on the other hand, does appear to be line-buffered --
> newline-terminated strings written to stderr show up immediately in
> the journal.
>
> i'd expect both stdout and stderr to be line-buffered.


I'm not fully sure of what you mean, but this looks like
https://github.com/systemd/systemd/issues/2913.

-- 

Saludos,
Felipe Sateler

Bug#833559: systemd user service standard output is not line-buffered

[Daniel Kahn Gillmor]

Package: systemd
Version: 230-7
Severity: normal

I've tested the following short-lived "daemon" as a systemd user service:

---
#include 
#include 

int main(int argc, char **argv)
{
  sleep(5);
  printf("a test\n");
  sleep(10);
  return 0;
}
---

the "a test" line doesn't show up in the user journal when i would
expect it to.  it appears that stdout is not line-buffered.

stderr, on the other hand, does appear to be line-buffered --
newline-terminated strings written to stderr show up immediately in
the journal.

i'd expect both stdout and stderr to be line-buffered.

--dkg

-- Package-specific info:

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

Kernel: Linux 4.7.0-rc7-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 systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3
ii  libapparmor12.10.95-4
ii  libaudit1   1:2.6.5-1
ii  libblkid1   2.28-6
ii  libc6   2.23-4
ii  libcap2 1:2.25-1
ii  libcap2-bin 1:2.25-1
ii  libcryptsetup4  2:1.7.0-2
ii  libgcrypt20 1.7.2-2
ii  libgpg-error0   1.24-1
ii  libidn111.33-1
ii  libkmod222-1.1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.28-6
ii  libpam0g1.1.8-3.3
ii  libseccomp2 2.3.1-2
ii  libselinux1 2.5-3
ii  libsystemd0 230-7
ii  mount   2.28-6
ii  util-linux  2.28-6

Versions of packages systemd recommends:
ii  dbus1.10.8-1
ii  libpam-systemd  230-7

Versions of packages systemd suggests:
ii  policykit-10.105-16
ii  systemd-container  230-7
pn  systemd-ui 

Versions of packages systemd is related to:
ii  udev  230-7

-- no debconf information

Bug#833558: libc0.3: [hurd] recvmsg: PF_LOCAL sockets and msg_name lead to SIGLOST

[Christian Seiler]

Package: libc0.3
Version: 2.23-4
Severity: normal
Tags: patch upstream
Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=20444

Dear Maintainer,

When using recvmsg on a PF_LOCAL socket, if msg_name and msg_namelen
are set, the process receives SIGLOST. This is due to glibc's recvmsg
implementation assuming that the peer address returned by __socket_recv
is always valid, when in fact that function returns MACH_PORT_NULL when
used in combination with PF_LOCAL sockets. Passing that to
__socket_whatis_address will generate SIGLOST.

recvfrom is not affected, that already checks for MACH_PORT_NULL.

I've attached a patch that fixes that issue for me, adding a check in
the same way recvfrom does it currently.

I've also reported this issue upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=20444

I've also forwarded this patch to the bug-hurd and debian-hurd mailing
lists:
https://lists.debian.org/debian-hurd/2016/08/msg00010.html
https://lists.gnu.org/archive/html/bug-hurd/2016-08/msg00012.html

Regards,
Christian

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: hurd-i386 (i686-AT386)

Kernel: GNU-Mach 1.7+git20160607-486/Hurd-0.8
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libc0.3 depends on:
ii  hurd-libs0.3  1:0.8.git20160522-4+b1
ii  libgcc1   1:6.1.1-9

libc0.3 recommends no packages.

Versions of packages libc0.3 suggests:
ii  debconf [debconf-2.0]  1.5.59
pn  glibc-doc  
pn  libc-l10n  

-- debconf information excluded
Description: [hurd] recvmsg: don't try to resolve invalid address
 Hurd's PF_LOCAL implementation doesn't return an address when calling
 __recv. recvmsg wasn't catching that and tried to call
 __socket_whatis_address on MACH_PORT_NULL, causing Hurd to send
 SIGLOST to the process. Properly handle this, analogously to how
 recvfrom does it.
Author: Christian Seiler 
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20444
Last-Update: 2016-08-05
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/sysdeps/mach/hurd/recvmsg.c
+++ b/sysdeps/mach/hurd/recvmsg.c
@@ -202,7 +202,7 @@ __libc_recvmsg (int fd, struct msghdr *m
 	   >msg_flags, amount)))
 return __hurd_sockfail (fd, flags, err);
 
-  if (message->msg_name != NULL)
+  if (message->msg_name != NULL && aport != MACH_PORT_NULL)
 {
   char *buf = message->msg_name;
   mach_msg_type_number_t buflen = message->msg_namelen;
@@ -236,6 +236,8 @@ __libc_recvmsg (int fd, struct msghdr *m
   if (buflen > 0)
 	((struct sockaddr *) message->msg_name)->sa_family = type;
 }
+  else if (message->msg_name != NULL)
+message->msg_namelen = 0;
 
   __mach_port_deallocate (__mach_task_self (), aport);
 

Bug#833496: Prevents gbp from building after change to onsglms

[Neil Roeth]

On 08/05/2016 02:55 AM, Guido Günther wrote:
> Package: docbook-utils
> Version: 0.6.14-3.2
> Severity: important
>
> Hi,
> since the above version git-buildpackage fails to build it's
> documentation with:
>
>   docbook2man -o buildxref man.gbp.sgml
>   Using catalogs: /etc/sgml/catalog
>   Using stylesheet: /usr/share/docbook-utils/docbook-utils.dsl#print
>   Working on: /build/git-buildpackage-0.8.2/docs/man.gbp.sgml
>   /usr/share/docbook-utils/backends/man: 10: 
> /usr/share/docbook-utils/backends/man: nsgmls: not found
>   Done.
>
> This is due to nsglms not being found. I see in the changelog:
>
>   * doc/man/Makefile.am: Change nsgmls -> onsgmls
>
> Why was that done? Do users of docbook-utils need to change something?
> If so does this need a NEWS entry? Or is docbook2man just not invoking
> osgmlns correctly?
>
> Cheers,
>  -- Guido
>
>

Thanks, it appears I missed occurrences where I needed to change nsgmls
to onsgmls.  Working on this now.


-- 
Neil Roeth

Bug#833547: [buildd-tools-devel] Bug#833547: sbuild: with gpg2, sbuild-update --keygen prompts the user for a passphrase

[Johannes Schauer]

Control: tag -1 + pending

Hi,

Quoting Sean Whitton (2016-08-05 22:17:27)
> With gnupg 2.1, which will soon be the default in unstable,
> `sbuild-update --keygen` prompts the user for a passphrase for the
> generated keys.  This is confusing, and will probably break things if
> the user actually enters a passphrase.
> 
> The attached patch fixes the problem.

wow... This is really unexpected given that gpg is run with the --batch
argument. Why would gpg prompt for any user interaction if I even pass the
--batch flag?? But at this point I should not be surprised anymore about gpg
weirdness...

Thanks for testing this and providing the patch. It's in my git branch.

cheers, josch


signature.asc
Description: signature

Bug#833390: [buildd-tools-devel] Bug#833390: sbuild: cannot set *_root_args so as to not try to run the command as root

[Johannes Schauer]

Control: tag -1 + pending

Quoting Sean Whitton (2016-08-05 04:16:03)
> On Thu, Aug 04, 2016 at 09:06:52AM +0200, Johannes Schauer wrote:
> > What do you think?
> 
> Yes, that fits the bill :)

thanks, committed!

cheers, josch


signature.asc
Description: signature

Bug#803456: Digikam 5.0.0 uploaded

[Simon Frei]

Hi again,

Point 2 is now addressed in current master upstream. My patch adds 
information about the non-migrated configuration to the welcome page. 
This will be in the 5.1.0 release due tomorrow. So is there now nothing 
left in the way to release digikam in unstable?


Cheers,
Simon

Bug#833557: hurd: PF_LOCAL send/recv don't honor MSG_DONTWAIT

[Christian Seiler]

Package: hurd
Version: 1:0.8.git20160522-4
Severity: normal
Tags: patch upstream

Dear Maintainer,

send/sendto/sendmsg/recv/recvfrom/recvmsg in combination with PF_LOCAL
sockets don't honor MSG_DONTWAIT. If specified, the operation will
block anyway. This is really bad if one has code that relies on the
fact that a recv* returns EAGAIN once all data has been read.

I've reported this to the debian-hurd and bug-hurd mailing lists, and
also provided a reproducer for this issue:
https://lists.gnu.org/archive/html/bug-hurd/2016-08/msg0.html
https://lists.debian.org/debian-hurd/2016/08/msg0.html

I've investigated further and found the culprit in hurd's
pflocal/socket.c. I've attached a patch that fixes the issue for me.
I've also sent the patch to both mailing lists:
https://lists.gnu.org/archive/html/bug-hurd/2016-08/msg00011.html
https://lists.debian.org/debian-hurd/2016/08/msg8.html

Regards,
Christian

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: hurd-i386 (i686-AT386)

Kernel: GNU-Mach 1.7+git20160607-486/Hurd-0.8
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages hurd depends on:
ii  hurd-libs0.3  1:0.8.git20160522-4+b1
ii  libblkid1 2.28-6
ii  libbz2-1.01.0.6-8
ii  libc0.3   2.23-4
ii  libdaemon00.14-6
ii  libncursesw5  6.0+20160625-1+b1
ii  libtinfo5 6.0+20160625-1+b1
ii  libx11-6  2:1.6.3-1
ii  netdde0.0.20150828-3
ii  sysv-rc   2.88dsf-59.8
ii  xkb-data  2.17-1
ii  zlib1g1:1.2.8.dfsg-2

Versions of packages hurd recommends:
ii  bf-utf-source  0.07

Versions of packages hurd suggests:
pn  hurd-doc  

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

-- no debconf information
Description: Support MSG_DONTWAIT in pflocal send/recv
Author: Christian Seiler 
Bug: https://lists.gnu.org/archive/html/bug-hurd/2016-08/msg0.html
Last-Update: 2016-08-05
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/pflocal/socket.c
+++ b/pflocal/socket.c
@@ -282,6 +282,7 @@ S_socket_send (struct sock_user *user, s
 	   size_t *amount)
 {
   error_t err = 0;
+  int noblock;
   struct pipe *pipe;
   struct sock *sock, *dest_sock;
   struct addr *source_addr;
@@ -333,8 +334,9 @@ S_socket_send (struct sock_user *user, s
 	
   if (!err)
 	{
-	  err = pipe_send (pipe, sock->flags & PFLOCAL_SOCK_NONBLOCK,
-			   source_addr, data, data_len,
+	  noblock = (user->sock->flags & PFLOCAL_SOCK_NONBLOCK)
+		|| (flags & MSG_DONTWAIT);
+	  err = pipe_send (pipe, noblock, source_addr, data, data_len,
 			   control, control_len, ports, num_ports,
 			   amount);
 	  if (dest_sock)
@@ -373,6 +375,7 @@ S_socket_recv (struct sock_user *user,
 {
   error_t err;
   unsigned flags;
+  int noblock;
   struct pipe *pipe;
   void *source_addr = NULL;
 
@@ -398,10 +401,11 @@ S_socket_recv (struct sock_user *user,
 }
   else if (!err)
 {
+  noblock = (user->sock->flags & PFLOCAL_SOCK_NONBLOCK)
+		|| (in_flags & MSG_DONTWAIT);
   err =
-	pipe_recv (pipe, user->sock->flags & PFLOCAL_SOCK_NONBLOCK, ,
-		   _addr, data, data_len, amount,
-		   control, control_len, ports, num_ports);
+	pipe_recv (pipe, noblock, , _addr, data, data_len,
+		   amount, control, control_len, ports, num_ports);
   pipe_release_reader (pipe);
 }
 

Bug#833552: [buildd-tools-devel] Bug#833552: sbuild: use colour to report success or failure of autopkgtest & piuparts

[Johannes Schauer]

Control: tag -1 + pending

Hi Sean,

Quoting Sean Whitton (2016-08-05 23:21:47)
> In its final build summary, sbuild highlights "Lintian: pass" in green and
> "Lintian: fail" in red.  This is useful for seeing at a glance whether there
> is anything to fix.
> 
> The attached patch extends this behaviour to autopkgtest & piuparts.

sorry, that I didn't push it, but I had already fixed this in my local git.

Thanks anyways, for the patch! Looking forward to more. :)

cheers, josch


signature.asc
Description: signature

Bug#833549: [buildd-tools-devel] Bug#833549: sbuild: autopkgtest fails when sbuild obtains the .dsc with apt-get source

[Johannes Schauer]

Hi,

Quoting Sean Whitton (2016-08-05 22:29:29)
> When sbuild obtains the .dsc to build from the archive with `apt-get
> source`, autopkgtest fails.  It seems that sbuild is not passing the
> .dsc to autopkgtest in this case.
> 
> For example, if I run
> 
> $ sbuild y-u-no-validate
> 
> autopkgtest fails like this:
> 
> autopkgtest
> ---
> 
> usage: autopkgtest [options] [testbinary ...] testsrc -- virt-server 
> [options]
> autopkgtest: error: y-u-no-validate_2013052407-3.dsc is not a valid test 
> package
> 
> E: Autopkgtest run failed.

this is because autopkgtest is run *outside* the chroot and unless sbuild was
instructed to recreated the source package, the system outside will never see
the .dsc.

I suggest to fix this by automatically skipping the autopkgtest in cases where
sbuild downloads the source package itself to resolve this bug.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#831529: libavcodec57: broken option parsing with LANGs with decimal mark different from .

[Mark Thompson]

This is now fixed with the same patch from Carl in ffmpeg master 

 and the 3.1 release branch 
.
  3.1.2 should be released soon.

Thank you for the report, and apologies for the breakage.

- Mark

PS:  It is probably worth noting that there may be other issues (though less 
fatal than this one) when lav* is used with a non-C locale, due to use of 
strtod() and related locale-dependent functions.  Making use of different 
properties of a non-C locale (such as a non-'.' decimal_point in LC_NUMERIC) 
should probably be considered an unsupported configuration with ffmpeg (the 
utility) at least, and there may be steps taken in future to make the behaviour 
more consistent.

Bug#833482: [Aptitude-devel] Bug#833482: aptitude: doesn't detect obsolete candidate package (versions)

[Christoph Anton Mitterer]

Control: reopen -1
Control: tags -1 + security

On Fri, 2016-08-05 at 22:49 +0100, Manuel A. Fernandez Montecelo wrote:
> This effect is an interference caused by the repositories that you
> use.
> Debian doesn't sanction the use of any unofficial repositories, and
> DMO
> is well known in the community for causing all sorts of problems when
> using along with the main Debian repositories, such as this one.

So? The underlying problem exists whether or not DMO is well
maintained.
If any non-Debian repo is configured that uses the same package names
(and I don't think that Debian claims namespace authority of all names)
than it wouldn't be detected if the candidate versions are obsolete.


> If the example was with another repository which is well maintained
> and
> co-operative, e.g. "mozilla.debian.net" containing a package
> "iceweasel"
> for compatibility (which was removed from Debian), the package
> shouldn't
> be considered obsolete.

The problem happens with these as well:
Consider I have had transcode installed from sid (where it's been gone
in the meantime) and also enabled stable (where it's still in), I'd
expect the same as I've seen it with DMO.



> Obsolete from aptitude is "installed locally but not found in any
> repo",
> which works well for the main intended uses of aptitude.
Well and that's the problem here, the definition of obsolete is kinda
wrong.
Or perhaps not wrong, but it doesn't tell you when a package no longer
will get updates (which is however the interesting thing about
obsolete/non-obsolete).


> So it's not an important bug, and aptitude is not the cause of the
> security issue -- using DMO is.
I don't think DMO has anything to do with...

> In a deeper sense, the package is dead upstream, thus not maintained,
> thus obsolete and a potential security liability, and that's the
> reason
> why it was removed from Debian.
But the problem will happen with any other package, whether it's
maintained or not,...


The "bug" or let's call it "deficiency" or "missing feature" in
aptitude is:
It doesn't show when packages will no longer get updates via the
configured repos and as per configured apt_preferences.

This is however quite important, as it also happens when just mixing
Debian repos.
Take backports... if one adds jessie-backports, and e.g. installs
icinga2 from there, perhaps pinned via apt_preferences(8).
It's still contained in jessie (at a much lower version), if it would
now be removed from backports, because lack of manpower or whatever,
users wouldn't notice that their installed version is obsolete in the
sense that it won't get any further security updates.

Since this has nothing to with DMO, reopening.

Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#821656: Bumping severity of PHP 7.0 transition bugs to serious

[Petter Reinholdtsen]

Hi.

Any news on migrating shaarli to PHP7?  This package is used by the FreedomBox,
and it would be a shame to have to drop shaarli support because the package
did not make it into testing / Stretch.

-- 
Happy hacking
Petter Reinholdtsen

Bug#833532: Iceowl works, calendar-google-provider is cause of my problem

[RD Beck]

I disabled all extensions, removed iceowl and calendar-google-provider 
(purged it).  Installed iceowl, and icedove starts fine.  Reinstalled 
calendar-google-provider and get the segmentation fault.

Bug#812275: bitcoin: FTBFS with GCC 6: test suite failures

[Anthony Towns]

Source: bitcoin
Followup-For: Bug #812275

> This package fails to build with GCC 6.

FWIW, this bug seems to be fixed upstream somewhere between 0.12.1 and
0.13.0rc2. I ran a git bisect, and the commit that fixes the issue seems
to be:

https://github.com/bitcoin/bitcoin/commit/89f71c68c0fecf63059f6055ebdd25f1eba4c982

Cheers,
aj

Bug#833310: option to make "forget new" non-interactive as before

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi,

2016-08-02 19:51 Harald Dunkel:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: aptitude
Version: 0.8.2-1
Severity: wishlist

Since "forget new" became interactive the new aptitude behaves
differently than aptitude in older versions. This makes managing
a set of hosts in parallel via tools like "cssh" pretty painful.
Some host require an additional confirmation step (for a trivial
operation).


You'll have to be more precise... is this the command line?  What does
it mean to become interactive?  Which command exactly, and what happens?



Would it be possible to switch this feature off by default, to
make aptitude work as for previous Debian releases?


If it's the command line there's an option to turn interactivity off or
confirming by default if it bothers you.  Perhaps you can use it in this
case.

If it's the curses interface, instead of 'f' you just have to press
(inject?) 'f+Enter', so for me it's quite trivial and I don't think that
you mean this case.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#833554: RFS: golang-github-odeke-em-command/0.0~git20151021.0.91ca5ec-1

[Fernando Ike]

Package: sponsorship-requests
Severity: normal 

Dear mentors,

I am looking for a sponsor for my package
"golang-github-odeke-em-command"

 * Package name: golang-github-odeke-em-command
   Version : 0.0~git20151021.0.91ca5ec-1
   Upstream Author : 2013 Google Inc. All Rights Reserved
 * URL : https://github.com/odeke-em/command
 * License : Apache-2.0
   Section : devel

It builds those binary packages:

 golang-github-odeke-em-command-dev - cli subcommands for Go

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

  https://mentors.debian.net/package/golang-github-odeke-em-command


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

  dget -x
https://mentors.debian.net/debian/pool/main/g/golang-github-odeke-em-command/golang-github-odeke-em-command_0.0~git20151021.0.91ca5ec-1.dsc


  Changes since the last upload:

  [ Paul Tagliamonte ]
  * Team upload.
  * Use a secure transport for the Vcs-Git and Vcs-Browser URL

  [ Fernando Ike ]
  * New upstream snapshot.
  * debian/control:
- Bump Standards-Version to 3.9.8.
  * debian/watch:
- Updated to version 4.

Regards,

Bug#833482: [Aptitude-devel] Bug#833482: aptitude: doesn't detect obsolete candidate package (versions)

[Manuel A. Fernandez Montecelo]

Control: severity -1 wishlist
Control: tags -1 - security + wontfix
Control: close -1


Hi,

2016-08-02 15:00 Christoph Anton Mitterer:

Package: aptitude
Version: 0.8.2-1
Severity: important
Tags: security


Hi.

I've just stumbled over the following:
Aptitude doesn't seem to tell people when the candidate and/or installed version
of a package is obsolete.

Example:
- Debian seems to have removed the transcode package already back in March.
- DMO still ships it however.
- I do have the transcode package from Debian installed.
- Via apt_preferences, all but a few packages from the DMO repos are "disabled".

Thus I'd never get any candidate version from DMO, while aptitude still shows
me the package not being obsolete.
In a way, of course, it is not fully obsolete, but it will never get any updates
thus no security updates either.

This is also what I think makes this issue important/security:
One ends up in a situation where the use will neither get updates (cause it's no
longer in Debian), nor will he even notice that this is the case (not being
showed as obsolete).


This effect is an interference caused by the repositories that you use.
Debian doesn't sanction the use of any unofficial repositories, and DMO
is well known in the community for causing all sorts of problems when
using along with the main Debian repositories, such as this one.

Among others, it uses packages with a higher epoch so they always take
precedence over Debian's, even if it's 4:1.2.0 versus 3:1.2.1 or
1:1.4.0.

So it's not aptitude's fault if it's fed with bogus data/information for
the repo, really, and the repository tries actively to screw with the
official Debian packages and play with the versioning system in ways
that cause this kind of problems.

If the example was with another repository which is well maintained and
co-operative, e.g. "mozilla.debian.net" containing a package "iceweasel"
for compatibility (which was removed from Debian), the package shouldn't
be considered obsolete.

Obsolete from aptitude is "installed locally but not found in any repo",
which works well for the main intended uses of aptitude.


So it's not an important bug, and aptitude is not the cause of the
security issue -- using DMO is.

If it's for a matter of security, that repository shouldn't be used at
all, so merely installing stuff from it is a big security liability
compared to Debian and many other well maintained repos.

In a deeper sense, the package is dead upstream, thus not maintained,
thus obsolete and a potential security liability, and that's the reason
why it was removed from Debian.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#833555: RFS: golang-github-odeke-em-ripper/0.0~git20150415.0.bd1a682-2

[Fernando Ike]

Package: sponsorship-requests
Severity: normal 

Dear mentors,

I am looking for a sponsor for my package
"golang-github-odeke-em-ripper"

 * Package name: golang-github-odeke-em-ripper
   Version : 0.0~git20150415.0.bd1a682-2
   Upstream Author : 2015 Emmanuel Odeke 
 * URL : https://github.com/odeke-em/ripper
 * License : Apache-2.0
   Section : devel

It builds those binary packages:

 golang-github-odeke-em-ripper-dev - scrape licenses out of files --
 library

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

  https://mentors.debian.net/package/golang-github-odeke-em-ripper

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

dget -x
  
https://mentors.debian.net/debian/pool/main/g/golang-github-odeke-em-ripper/golang-github-odeke-em-ripper_0.0~git20150415.0.bd1a682-2.dsc


  Changes since the last upload:

  [ Paul Tagliamonte ]
  * Team upload.
  * Use a secure transport for the Vcs-Git and Vcs-Browser URL

  [ Fernando Ike ]
  * debian/control:
- Bump Standards-Version to 3.9.8
  * debian/watch:
- Updated version to 4.

Regards,
-- 
Fernando Ike
http://www.fernandoike.com

Bug#833556: RFS: golang-github-skratchdot-open-golang/0.0~git20160302.0.75fb7ed-1

[Fernando Ike]

Package: sponsorship-requests
Severity: normal 

Dear mentors,

I am looking for a sponsor for my package
"golang-github-skratchdot-open-golang"

 * Package name: golang-github-skratchdot-open-golang
   Version : 0.0~git20160302.0.75fb7ed-1
   Upstream Author : Jeff Switzer 

Bug#833553: RFS: golang-github-odeke-em-cache/0.0~git20151107.0.baf8e436-1

[Fernando Ike]

Package: sponsorship-requests
Severity: normal 

Dear mentors,

I am looking for a sponsor for my package
"golang-github-odeke-em-cache"

 * Package name: golang-github-odeke-em-cache
   Version : 0.0~git20151107.0.baf8e436-1
   Upstream Author : 2015, Emmanuel Odeke 
 * URL : https://github.com/odeke-em/cache
 * License : Expat
   Section : devel

It builds those binary packages:

 golang-github-odeke-em-cache-dev - Simple cache with expirable values

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

  https://mentors.debian.net/package/golang-github-odeke-em-cache


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

  dget -x
https://mentors.debian.net/debian/pool/main/g/golang-github-odeke-em-cache/golang-github-odeke-em-cache_0.0~git20151107.0.baf8e436-1.dsc


  Changes since the last upload:

  [ Paul Tagliamonte ]
  * Team upload.
  * Use a secure transport for the Vcs-Git and Vcs-Browser URL

  [ Fernando Ike ]
  * New upstream snapshot.
  * debian/control:
- Bump Standards-Version to 3.9.8.
  * debian/copyright:
- Added new author.
  * debian/watch:
- Updated to version 4.


Regards,
-- 
Fernando Ike
http://www.fernandoike.com

Bug#833524: chromium: Aw Snap! after update to new in sid / even when purged and installed as clean

[Daniel Serpell]

Package: chromium
Version: 52.0.2743.116-1
Followup-For: Bug #833524


Hi,

This is a backtrace of the crash. I can reproduce it by visiting the
site www.latercera.com


Thread 37 "Chrome_InProcRe" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff3f3aa700 (LWP 8381)]
0x58666f85 in blink::LayoutObject::isDescendantOf(blink::LayoutObject 
const*) const ()
(gdb) bt
#0  0x58666f85 in 
blink::LayoutObject::isDescendantOf(blink::LayoutObject const*) const ()
#1  0x586e753c in 
blink::CompositedLayerMapping::containingSquashedLayer(blink::LayoutObject 
const*, WTF::Vector const&, unsigned int) ()
#2  0x587638ab in 
blink::CompositingLayerAssigner::getReasonsPreventingSquashing(blink::PaintLayer
 const*, blink::CompositingLayerAssigner::SquashingState const&) 
[clone.part.22] ()
#3  0x5876480e in 
blink::CompositingLayerAssigner::assignLayersToBackingsInternal(blink::PaintLayer*,
 blink::CompositingLayerAssigner::SquashingState&, 
WTF::Vector&) ()
#4  0x58764511 in
blink::CompositingLayerAssigner::assignLayersToBackingsInternal(blink::PaintLayer*,
blink::CompositingLayerAssigner::SquashingState&,
WTF::Vector&) ()
#5  0x58764511 in
blink::CompositingLayerAssigner::assignLayersToBackingsInternal(blink::PaintLayer*,
blink::CompositingLayerAssigner::SquashingState&,
WTF::Vector&) ()
#6  0x587648f1 in
blink::CompositingLayerAssigner::assign(blink::PaintLayer*,
WTF::Vector&) ()
#7  0x586edc79 in blink::PaintLayerCompositor::updateIfNeeded()
()
#8  0x586ef0d6 in
blink::PaintLayerCompositor::updateIfNeededRecursiveInternal() ()
#9  0x586ef31c in
blink::PaintLayerCompositor::updateIfNeededRecursive() ()
#10 0x5825a532 in
blink::FrameView::updateLifecyclePhasesInternal(blink::FrameView::LifeCycleUpdateOption)
()
#11 0x583955bd in
blink::PageAnimator::updateAllLifecyclePhases(blink::LocalFrame&) ()
#12 0x577efaaa in blink::WebViewImpl::updateAllLifecyclePhases()
()
#13 0x598cb813 in
content::RenderWidgetCompositor::UpdateLayerTreeHost() ()
#14 0x5a4843a6 in
cc::ProxyMain::BeginMainFrame(std::unique_ptr) ()
#15 0x5a48d280 in
base::internal::Invoker,
base::internal::BindState)>, void
(cc::ProxyMain*, std::unique_ptr),
base::WeakPtr&,
base::internal::PassedWrapper > >,
base::internal::InvokeHelper)> >, void
()>::Run(base::internal::BindStateBase*) ()
#16 0x564edbed in base::debug::TaskAnnotator::RunTask(char
const*, base::PendingTask const&) ()
#17 0x5adf4a3f in
scheduler::TaskQueueManager::ProcessTaskFromWorkQueue(scheduler::internal::WorkQueue*,
scheduler::internal::TaskQueueImpl::Task*) ()
#18 0x5adf5044 in
scheduler::TaskQueueManager::DoWork(base::TimeTicks, bool) ()
#19 0x5adf297b in
base::internal::Invoker,
base::internal::BindState,
base::internal::InvokeHelper, void
()>::Run(base::internal::BindStateBase*) ()
#20 0x564edbed in base::debug::TaskAnnotator::RunTask(char
const*, base::PendingTask const&) ()
#21 0x564a140e in base::MessageLoop::RunTask(base::PendingTask
const&) ()
#22 0x564a1f7d in
base::MessageLoop::DeferOrRunPendingTask(base::PendingTask const&) ()
#23 0x564a2f2c in
base::MessageLoop::DoDelayedWork(base::TimeTicks*) ()


Hope it helps,



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

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

Versions of packages chromium depends on:
ii  libasound2   1.1.2-1
ii  libatk1.0-0  2.20.0-1
ii  libavcodec-extra57   7:3.1.1-4
ii  libavformat577:3.1.1-4
ii  libavutil55  7:3.1.1-4
ii  libc62.23-4
ii  libcairo21.14.6-1+b1
ii  libcups2 2.1.4-4
ii  libdbus-1-3  1.10.8-1
ii  libexpat12.2.0-1
ii  libfontconfig1   2.11.0-6.4
ii  libfreetype6 2.6.3-3+b1
ii  libgcc1  1:6.1.1-11
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  

Bug#769899: Next dpkg release will be dropping the dpkg-statoverride compat symlinks

[Guillem Jover]

Hi!

With dpkg 1.18.11, I'll be dropping again the compat symlinks, which
means these bugs will become serious and I'll bump their severities
to reflect that. Please include the patches provided for the
non-wontfixed ones.

I'll be adding versioned Breaks on the earlier versions using the
hardcoded paths, once these have been fixed, to get a smooth upgrade.

Thanks,
Guillem

Bug#831922: libjs-swfupload: FTBFS with dpkg-buildpackage -A: dh_install: missing files, aborting

[Santiago Vila]

On Fri, Aug 05, 2016 at 10:43:43PM +0200, Christian Welzel wrote:
> Am 23.07.2016 um 12:26 schrieb Santiago Vila:
> 
> > The "build-indep" target is missing.
> 
> I prepared a new version of the package with new upstream.
> I cannot upload myself, so please take a look into
> https://mentors.debian.net/debian/pool/main/libj/libjs-swfupload/libjs-swfupload_2.2.0.1+ds2-1.dsc
> and upload for me, if all is good.

If this is a new upstream, why is this still 2.2.0.1?

Thanks.

Bug#833551: firmware-ipw2x00 in stretch contains the wrong firmware for ipw2200 in kernel 4.6

[Gregor Riepl]

Package: firmware-ipw2x00
Version: 20160110-1
Severity: important
Tags: newcomer

Dear Maintainer,

The firmware-ipw2x00 package in Debian stretch contains firmware for
Intel Wireless Pro 2100/2200 devices, but the firmware does not match
what the driver in kernel 4.6 requires.

The package has version 3.0 from upstream, but version 3.1 is required.

Without the the correct firmware, the driver will report lots of

 ipw2200: Firmware error detected.  Restarting.

errors, and the wireless card is barely usable, if at all.

Manually installing the firmware from upstream resolves this problem.

Please update the package so it has the correct firmware.

Thank you.

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

Kernel: Linux 4.6.0-1-686-pae (SMP w/1 CPU core)
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 firmware-ipw2x00 depends on:
ii  debconf [debconf-2.0]  1.5.59

firmware-ipw2x00 recommends no packages.

Versions of packages firmware-ipw2x00 suggests:
ii  initramfs-tools  0.125

-- debconf information:
  firmware-ipw2x00/license/error:
* firmware-ipw2x00/license/accepted: true

Bug#833552: sbuild: use colour to report success or failure of autopkgtest & piuparts

[Sean Whitton]

Package: sbuild
Version: 0.70.0-1
Severity: wishlist
Tags: patch

Dear maintainer,

In its final build summary, sbuild highlights "Lintian: pass" in green
and "Lintian: fail" in red.  This is useful for seeing at a glance
whether there is anything to fix.

The attached patch extends this behaviour to autopkgtest & piuparts.

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

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

Versions of packages sbuild depends on:
ii  adduser 3.115
ii  apt-utils   1.3~pre2
ii  gnupg   2.1.14-2
ii  libsbuild-perl  0.70.0-1
ii  perl5.22.2-3

Versions of packages sbuild recommends:
ii  debootstrap  1.0.81
ii  fakeroot 1.21-1

Versions of packages sbuild suggests:
pn  deborphan  
ii  wget   1.18-2

-- no debconf information

-- 
Sean Whitton
From 658e0d3314eff0817ad856aad2214028aaad599e Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Fri, 5 Aug 2016 14:19:17 -0700
Subject: [PATCH] colour for piuparts & autopkgtest success/failure

---
 lib/Sbuild/Build.pm | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/Sbuild/Build.pm b/lib/Sbuild/Build.pm
index e37867d..efca137 100644
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -471,6 +471,10 @@ END
 	$self->build_log_colour('yellow', '^Keeping session: ');
 	$self->build_log_colour('red', '^Lintian:');
 	$self->build_log_colour('green', '^Lintian: pass$');
+	$self->build_log_colour('red', '^Piuparts:');
+	$self->build_log_colour('green', '^Piuparts: pass$');
+	$self->build_log_colour('red', '^Autopkgtest:');
+	$self->build_log_colour('green', '^Autopkgtest: pass$');
 
 	# Log filtering
 	my $filter;
-- 
2.8.1



signature.asc
Description: PGP signature

Bug#833433: jessie-pu: package flashplugin-nonfree/1:3.6.1+deb8u1

[Julien Cristau]

Control: tag -1 moreinfo

On Fri, Aug  5, 2016 at 18:18:01 +, Bart Martens wrote:

> On Fri, Aug 05, 2016 at 03:19:59PM +0200, Julien Cristau wrote:
> > 
> > On Thu, Aug  4, 2016 at 11:38:34 +0200, Bart Martens wrote:
> > 
> > > + if [ "`stat --format=%y $cachedir/get-upstream-version.pl`" \< 
> > > "2016-08-04 09:35" ]
> > 
> > Not sure about using string comparison for comparing dates.  And is stat
> > --format=%y's output stable across locales etc?
> 
> Yes, see function human_time in src/stat.c in coreutils.
> 
The current code is not a guarantee for the future.  The function is
named "human_time".  That makes it IMO wrong to use in a script.  It's
also not stable across timezones.

Cheers,
Julien

Bug#833022: darkice: diff for NMU version 1.3-0.1

[Nicolas Boulenguez]

Control: tags 833022 + patch
Control: tags 833022 + pending

Dear maintainer,

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

To spare your time, I have removed all autoconf generated files from
the attached diff. They are ignored during the build.

Regards.
diff -Nru darkice-1.2/acinclude.m4 darkice-1.3/acinclude.m4
--- darkice-1.2/acinclude.m4	2013-07-15 07:50:42.0 +0200
+++ darkice-1.3/acinclude.m4	2015-05-18 19:38:07.0 +0200
@@ -99,7 +99,7 @@
 dnl macros posted by AFC to the autoconf macro repository.  We are also
 dnl grateful for the helpful feedback of numerous users.
 dnl
-dnl @version $Id: acinclude.m4 553 2013-07-15 05:50:56Z raf...@riseup.net $
+dnl @version $Id$
 dnl @author Steven G. Johnson  and Alejandro Forero Cuervo 
 
 AC_DEFUN([ACX_PTHREAD], [
diff -Nru darkice-1.2/ChangeLog darkice-1.3/ChangeLog
--- darkice-1.2/ChangeLog	2013-07-15 07:52:57.0 +0200
+++ darkice-1.3/ChangeLog	2016-08-04 15:40:12.0 +0200
@@ -1,3 +1,8 @@
+04-08-2016 Darkice 1.3 released
+o Small bugs fixed by Nicolas Boulenguez .
+o Bugs related to streaming to remote servers fixed. Patch by Kalle Kulonen
+	 and Mark Turner .
+
 15-07-2013 Darkice 1.2 released
 o Issue #75: Added Ogg/Opus support. Patch by Doug Kelly
 	dougk@gmail.com
diff -Nru darkice-1.2/configure.in darkice-1.3/configure.in
--- darkice-1.2/configure.in	2013-07-15 07:50:01.0 +0200
+++ darkice-1.3/configure.in	2016-08-04 15:41:01.0 +0200
@@ -1,5 +1,5 @@
 dnl Process this file with autoconf to produce a configure script.
-AC_INIT(darkice, 1.2)
+AC_INIT(darkice, 1.3)
 AC_CONFIG_SRCDIR(src/DarkIce.cpp)
 AM_CONFIG_HEADER(src/config.h)
 
@@ -9,6 +9,8 @@
 AC_PROG_CXX
 AC_PROG_INSTALL
 
+PKG_PROG_PKG_CONFIG
+
 dnl AC_STDC_HEADERS
 AC_HAVE_HEADERS(errno.h fcntl.h stdio.h stdlib.h string.h unistd.h limits.h)
 AC_HAVE_HEADERS(signal.h time.h sys/time.h sys/types.h sys/wait.h math.h)
@@ -41,29 +43,32 @@
 dnl-
 dnl link the lame library if requested
 dnl-
-AC_SUBST(LAME_INCFLAGS)
-AC_SUBST(LAME_LDFLAGS)
+AC_SUBST(LAME_CFLAGS)
+AC_SUBST(LAME_LIBS)
 
 AC_ARG_WITH(lame,
-[  --with-lame use lame for encoding mp3 streams [yes] ],
-USE_LAME=${withval}, USE_LAME="yes" )
+AS_HELP_STRING([--with-lame], [use lame for encoding mp3 streams @<:@check@:>@]),
+[], with_lame=check)
 AC_ARG_WITH(lame-prefix,
-[  --with-lame-prefix=DIR  alternate location for lame [/usr]
-  look for libraries in LAME-PREFIX/lib,
-  for headers in LAME-PREFIX/include],
+AS_HELP_STRING([--with-lame-prefix=DIR],
+[alternate location for lame @<:@/usr@:>@.
+Look for libraries in LAME-PREFIX/lib,
+for headers in LAME-PREFIX/include]),
 CONFIG_LAME_PREFIX="${withval}", CONFIG_LAME_PREFIX="/usr")
 
-if test "x${USE_LAME}" = "xyes" ; then
+if test "x$with_lame" != xno ; then
 AC_MSG_CHECKING( [for lame library at ${CONFIG_LAME_PREFIX}] )
 LA_SEARCH_LIB( LAME_LIB_LOC, LAME_INC_LOC, libmp3lame.a libmp3lame.so, lame/lame.h,
${CONFIG_LAME_PREFIX})
 if test "x${LAME_LIB_LOC}" != "x" ; then
 AC_DEFINE( HAVE_LAME_LIB, 1, [build with lame library] )
 if test "x${LAME_INC_LOC}" != "x${SYSTEM_INCLUDE}" ; then
-LAME_INCFLAGS="-I${LAME_INC_LOC}"
+LAME_CFLAGS="-I${LAME_INC_LOC}"
 fi
-LAME_LDFLAGS="-L${LAME_LIB_LOC} -lmp3lame"
+LAME_LIBS="-L${LAME_LIB_LOC} -lmp3lame"
 AC_MSG_RESULT( [found at ${CONFIG_LAME_PREFIX}] )
+elif test "x$with_lame" = xyes ; then
+AC_MSG_ERROR([unable to find lame library])
 else
 AC_MSG_WARN( [not found, building without lame])
 fi
@@ -75,110 +80,58 @@
 dnl-
 dnl link the ogg vorbis libraries if requested
 dnl-
-AC_SUBST(VORBIS_INCFLAGS)
-AC_SUBST(VORBIS_LDFLAGS)
-
 AC_ARG_WITH(vorbis,
-[  --with-vorbis   use Ogg Vorbis for encoding vorbis streams [yes] ],
-USE_VORBIS=${withval}, USE_VORBIS="yes" )
-AC_ARG_WITH(vorbis-prefix,
-[  --with-vorbis-prefix=DIRalternate location for vorbis [/usr]
-  look for libraries in VORBIS-PREFIX/lib,
-  for headers in VORBIS-PREFIX/include],
-CONFIG_VORBIS_PREFIX="${withval}", CONFIG_VORBIS_PREFIX="/usr")
-
-if test "x${USE_VORBIS}" = "xyes" ; then
-AC_MSG_CHECKING( [for vorbis libraries at ${CONFIG_VORBIS_PREFIX}] )
-LA_SEARCH_LIB( OGG_LIB_LOC, OGG_INC_LOC, libogg.a libogg.so, 

Bug#831922: libjs-swfupload: FTBFS with dpkg-buildpackage -A: dh_install: missing files, aborting

[Christian Welzel]

Am 23.07.2016 um 12:26 schrieb Santiago Vila:


The "build-indep" target is missing.


I prepared a new version of the package with new upstream.
I cannot upload myself, so please take a look into
https://mentors.debian.net/debian/pool/main/libj/libjs-swfupload/libjs-swfupload_2.2.0.1+ds2-1.dsc
and upload for me, if all is good.


--
 MfG, Christian Welzel

  GPG-Key: pub 4096R/5117E119 2011-09-19
  Fingerprint: 3688 337C 0D3E 3725 94EC  E401 8D52 CDE9 5117 E119

Bug#833549: sbuild: autopkgtest fails when sbuild obtains the .dsc with apt-get source

[Sean Whitton]

Package: sbuild
Version: 0.70.0-1
Severity: normal

Dear maintainer,

When sbuild obtains the .dsc to build from the archive with `apt-get
source`, autopkgtest fails.  It seems that sbuild is not passing the
.dsc to autopkgtest in this case.

For example, if I run

$ sbuild y-u-no-validate

autopkgtest fails like this:

autopkgtest
---

usage: autopkgtest [options] [testbinary ...] testsrc -- virt-server 
[options]
autopkgtest: error: y-u-no-validate_2013052407-3.dsc is not a valid test 
package

E: Autopkgtest run failed.

Thanks.

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

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

Versions of packages sbuild depends on:
ii  adduser 3.115
ii  apt-utils   1.3~pre2
ii  gnupg   2.1.14-2
ii  libsbuild-perl  0.70.0-1
ii  perl5.22.2-3

Versions of packages sbuild recommends:
ii  debootstrap  1.0.81
ii  fakeroot 1.21-1

Versions of packages sbuild suggests:
pn  deborphan  
ii  wget   1.18-2

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#833494: [Letsencrypt-devel] Bug#833494: acmetool: Does not correctly respond to changes in an ACME server's preferred agreement

[Peter Colberg]

Control: severity -1 serious
Control: tag -1 fixed-upstream

Hi Uwe, Hugo,

On Fri, Aug 05, 2016 at 08:35:42AM +0200, Uwe Steinmann wrote:
> Fixes #191, whereby acmetool did not correctly respond to changes in an
> ACME server's preferred agreement. This is an important update and should
> be applied promptly, as it causes autorenewal to fail (though by design,
> acmetool requires intervention to agree to new agreements anyway).

I am fully aware of the severity of this bug, since I am affected
the same as every other Debian user with an existing LE registration.

Unfortunately the versions of acmetool that contain this fix depend on
three new golang packages that do not contain any mention of their
license in the source tree, and would therefore be rejected by Debian
ftp-masters if I attempted to upload them (with the help of sponsors).

Uwe, if you like, please let the author of acmetool know how important
this issue is to Debian users by supporting the requests [1-3] for
adding the license information to these golang packages.

[1] https://github.com/hlandau/goutils/issues/1
[3] https://github.com/hlandau/buildinfo/issues/1
[2] https://github.com/hlandau/dexlogconfig/issues/1

Hugo, I would be grateful if you could address the three issues by
appending a license declaration to each README.md. acmetool is a
well-written client that would be dearly missed by users of Debian
and Debian derivatives.

Regards,
Peter

Bug#734005: error: git-svn died of signal 11 (at least doing git svn fetch/rebase)

[Eric Wong]

Jason Briggs  wrote:
> [ 1463.669888] git-svn[3270]: segfault at 7fab78a3a178 ip 7fab7f80da31 sp 
> 7ffc8c6d7280 error 6 in _Delta.so[7fab7f7fa000+2a000]
> [ 2701.760387] git-svn[29940]: segfault at 7fa6f896d370 ip 7fa6ff5a1a31 
> sp 7fff96961620 error 6 in _Delta.so[7fa6ff58e000+2a000]

Hi, this is possibly related to #780246 
https://bugs.debian.org/780246
https://public-inbox.org/git/0bca1e695085c645b9cd4a27dd59f6fa39aad...@gbwgceuhubd0101.rbsres07.net/T/

In any case, can you get a backtrace to confirm if you see the
same thing in the other reports?  Thanks.

Bug#833547: sbuild: with gpg2, sbuild-update --keygen prompts the user for a passphrase

[Sean Whitton]

Package: sbuild
Version: 0.70.0-1
Severity: normal
Tags: patch

Dear maintainers,

With gnupg 2.1, which will soon be the default in unstable,
`sbuild-update --keygen` prompts the user for a passphrase for the
generated keys.  This is confusing, and will probably break things if
the user actually enters a passphrase.

The attached patch fixes the problem.

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

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

Versions of packages sbuild depends on:
ii  adduser 3.115
ii  apt-utils   1.3~pre2
ii  gnupg   2.1.14-2
ii  libsbuild-perl  0.70.0-1
ii  perl5.22.2-3

Versions of packages sbuild recommends:
ii  debootstrap  1.0.81
ii  fakeroot 1.21-1

Versions of packages sbuild suggests:
pn  deborphan  
ii  wget   1.18-2

-- no debconf information

-- 
Sean Whitton
From dd166466e75015a0ebc39f6a0533c98649a7a504 Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Fri, 5 Aug 2016 13:14:52 -0700
Subject: [PATCH] don't prompt the user during --keygen

---
 debian/control| 3 ++-
 lib/Sbuild/ChrootSetup.pm | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 98f061f..40b8b61 100644
--- a/debian/control
+++ b/debian/control
@@ -56,7 +56,8 @@ Depends: adduser,
  libsbuild-perl (= ${source:Version}),
  ${misc:Depends},
  ${perl:Depends},
- ${shlibs:Depends}
+ ${shlibs:Depends},
+ gnupg (>= 2)
 Recommends: debootstrap, fakeroot
 Suggests: deborphan, wget
 Description: Tool for building Debian binary packages from Debian sources
diff --git a/lib/Sbuild/ChrootSetup.pm b/lib/Sbuild/ChrootSetup.pm
index d45ef68..53dd75b 100644
--- a/lib/Sbuild/ChrootSetup.pm
+++ b/lib/Sbuild/ChrootSetup.pm
@@ -274,7 +274,7 @@ EOF
 	return $?
 }
 
-my @command = ('gpg', '--no-options', '--no-default-keyring', '--batch', '--gen-key',
+my @command = ('gpg', '--no-options', '--pinentry-mode', 'loopback', '--passphrase-file', '/dev/null', '--no-default-keyring', '--batch', '--gen-key',
$tmpfilename);
 $host->run_command(
 { COMMAND => \@command,
-- 
2.8.1



signature.asc
Description: PGP signature

Bug#833548: ITP: liblemon -- Library for Efficient Modeling and Optimization in Networks

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: liblemon
  Version : 1.3.1
  Upstream Author : Egerváry Jenő Kombinatorikus Optimalizálási Kutatócsoport
* URL : https://lemon.cs.elte.hu/trac/lemon/wiki
* License : Boost-1.0
  Programming Lang: C++
  Description : Library for Efficient Modeling and Optimization in Networks
 LEMON stands for Library for Efficient Modeling and Optimization in
 Networks. It is a C++ template library providing efficient
 implementations of common data structures and algorithms with focus
 on combinatorial optimization tasks connected mainly with graphs
 and networks.
 .
 LEMON is a member of the COIN-OR initiative, a collection of OR related
 open source projects.


Remark: This library was packaged to remove an outdated code copy inside
the package cufflinks (see #833493).  The bad news is that cufflink does
not simply build against this library.  However, since the packaging of
liblemon is finished now I'll upload and may be some more gifted C++
programmer might be able to adapt the code or we could ask upstream
about this.

The package is maintained by the Debian Med team at
https://anonscm.debian.org/git/debian-med/liblemon.git

Bug#766794: radare2: new upstream version available

[random . numbers]

On Sat, Oct 25, 2014 at 11:13:52PM +0200, random.numb...@gmx.com wrote:
> Package: radare2
> Version: 0.9.6-3.1
> Severity: wishlist
> 
> upstream has version 0.9.7:
> https://github.com/radare/radare2/releases


version 0.10.4 was released on July 7th.

Please update radare2. It is outdated.

Bug#833546: oracle doesn't know GOROOT

[Vincent Bernat]

Package: golang-golang-x-tools
Version: 1:0.0~git20160315.0.f42ec61-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

oracle doesn't know the correct GOROOT:

/home/bernat/code/.gopath/src/jura/cmd/daemon.go:4:2: could not import fmt 
(cannot find package "fmt" in any of:
/home/bernat/code/.gopath/src/jura/vendor/fmt (vendor tree)
/usr/lib/go/src/fmt (from $GOROOT)
/home/bernat/code/.gopath/src/fmt (from $GOPATH))

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

Kernel: Linux 4.6.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 golang-golang-x-tools depends on:
ii  golang-golang-x-tools-dev  1:0.0~git20160315.0.f42ec61-2
ii  libc6  2.23-4

golang-golang-x-tools recommends no packages.

golang-golang-x-tools suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJXpO5QAAoJEJWkL+g1NSX5NjEQAIZaYq9LdEEdj8GFDsP//MVZ
X7THAEYn7XYkgX/gvfnAQutueSHHtrqoBu8Z8KWqEmeX2S4Kb+snGUyT92q4ZZ54
dWgOR5BucXvNZAuARlQaUUA8q47Oh2DApcd8+G1upHoyHbfIrNm1EMt5oV1ws5vk
rgEiMoYj42++Ekxtn9a5nAjzf79nER+8kr3Zyqlu3oU2Oe2G4Y394LBEjzzA1bZ1
tX0woFNRegpFv12pOdkBCgUVLEGXSfoq0NDAgBYY30t/8G6PHCC0Aiziy4YRX1k5
RwLaiW4ufUiyb0d1BQH7DI46Mp1gXvZX7uJTIm8/XmGL9u9pB8ye7bLsW1mq509S
c9sGhj3+ErJALt4uqVCwmdlZJc4ATJNsl0nwv3xQYK0NcopUg/DPg+hqlHgSI+87
7yAXTRe8ebZC9udUY5LscpnfbeoM+G0a2PmB8LLdHWry6PUB7RwDwBf11NeZbLHc
3+VYtWS4A9W4bXbrqdUc7qjrCHlpPMh5AiUqpBAmtzafU8WxsF00jBXJaohiWZ4y
77ZkJNd7OYP1+ryZ7BUS0t0oAmtWlMrwEisbGnLtwDRJembPlypX/FVa4/XgsiUR
EYpMYh/eYj9o9MpJiu9QmRmP+Ez/GXUhKYmU7tWgRdFtzDnJSYiQBgMf9wyvf7Kv
v7xx6/AOcTuYSAvtZenn
=CQuB
-END PGP SIGNATURE-

Bug#833536: pkg-haskell-tools: dht should allow uploading by FTP

[Jonas Smedegaard]

Quoting Joachim Breitner (2016-08-05 21:04:06)
> Am Freitag, den 05.08.2016, 09:47 -0700 schrieb Sean Whitton:
> > Is there some reason that dht's upload subcommand uploads to ftp- 
> > master with SSH rather than FTP?  This prevents Debian Maintainers 
> > from using the command to upload.
> > 
> > If there is no good reason, we could change it to use FTP.
> > Alternatively, we could add a command line flag to select FTP or SSH
> > --
> > not sure what the default should be.
> 
> the reason is that I have had many FTP uploads fail and partial files 
> blocking further uploaing, which is a PITA. With ssh, partial uploads 
> do not happen (I think).
> 
> Anyways, "dht upload" should simply allow passing a parameter to dput 
> as HOST. Any maybe anyone who wants a non-default HOST should figure 
> out how to change dput’s defaults…

I have experienced (generally in Debian, not specifically for Haskell), 
some cases of ftp uploads failing where I receiving no information about 
it, and when I - after discovering many weeks later - asked ftpmasters I 
was told that since ftp is anonymous there is no way to inform either.

Since then I have used ssh for uploads.  I am not sure if there are any 
automated warning mechanisms in place when things go wrong, but at least 
if there is a larger fallout (as I can imagine might happen for mass 
uploads due to the maintenance style of Haskell packages) ftpmasters has 
a chance of noticing manually in log files whom to contact when using 
ssh.

So I'd recommend favoring ssh - and support ftp only as fallback for 
situations where ssh is not possible.


 - Jonas

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

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


signature.asc
Description: signature

Bug#833340: mini-buildd: please make the build reproducible

[Chris Lamb]

> This does work alright, but I actually like Chris' patch better, so I
> have swapped them.

:) 


Regards,

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

Bug#833536: pkg-haskell-tools: dht should allow uploading by FTP

[Joachim Breitner]

Hi,

Am Freitag, den 05.08.2016, 09:47 -0700 schrieb Sean Whitton:
> Package: pkg-haskell-tools
> Version: 0.10.3
> Severity: normal
> 
> Hello,
> 
> Is there some reason that dht's upload subcommand uploads to ftp-
> master
> with SSH rather than FTP?  This prevents Debian Maintainers from
> using
> the command to upload.
> 
> If there is no good reason, we could change it to use FTP.
> Alternatively, we could add a command line flag to select FTP or SSH
> --
> not sure what the default should be.

the reason is that I have had many FTP uploads fail and partial files
blocking further uploaing, which is a PITA. With ssh, partial uploads
do not happen (I think).

Anyways, "dht upload" should simply allow passing a parameter to dput
as HOST. Any maybe anyone who wants a non-default HOST should figure
out how to change dput’s defaults…

Greetings,
Joachim


-- 
Joachim “nomeata” Breitner
Debian Developer
  nome...@debian.org • https://people.debian.org/~nomeata
  XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
  https://www.joachim-breitner.de/

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

Bug#833340: mini-buildd: please make the build reproducible

[Stephan Sürken]

Chris, Boyang,

On Fr, 2016-08-05 at 17:09 +0200, Stephan Sürken wrote:
(...)
> > > 
> > > (Did you see my patch?)
> > Really sorry I overlook the last several lines. It is a good
> > solution.
> hmm thanks ;). However, I already did a patch (actually before the
> bug
> popped up). It's already pushed (1.0.x branch), so maybe someone may
> check if that still has a flaw ;).

fwiw, which would have been

https://anonscm.debian.org/git/collab-maint/mini-buildd.git/commit/?h=1.0.x=b513a9e398f2c05ec9265a627171eb2281c4d974

This does work alright, but I actually like Chris' patch better, so I
have swapped them.

Still pending, so hopefully the next upload will actually be
reproducible ;).

Thx,

S

Bug#833545: Hexter - new upstream version

[trebmuh]

Package: hexter
Version: 1.0.2-3

Dear debian maintainers,

There is a 1.0.3 version on sourceforge : 
https://sourceforge.net/projects/dssi/files/hexter/1.0.3/ which fix a 
possible crash in host. It would be great to get it package for stretch.


Hope that helps,
Olivier

Bug#533715:

[Grace Bunyan]

Greeting, Did you receive the fund letter i send you last? from Grace Bunyan

Bug#833544: ITP: libtest-timer-perl -- Perl module to test/assert code response times

[Nick Morrott]

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

* Package name: libtest-timer-perl
  Version : 0.12
  Upstream Author : Jonas B. Nielsen 
* URL : https://metacpan.org/release/Test-Timer
* License : Artistic-2.0
  Programming Lang: Perl
  Description : Perl module to test/assert code response times

Test::Timer implements a set of test primitives to test and assert test times
from bodies of code.

The key features are subroutines to test/assert the following:

  - that execution of a given piece of code does not exceed a specified time
limit

  - that execution of a given piece of code takes longer than a specified time
limit and does not exceed another

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

Bug#833543: Error in package dependencies results in regular cron email alerts

[deb]

Package: php5-common
Version: 5.6.24+dfsg-0+deb8u1

After uninstalling apache and most php packages from an installation, I
get an email every 30 minutes from cron:


From: root@[...] (Cron Daemon)
To: root@[...]
Subject: Cron    [ -x /usr/lib/php5/sessionclean ] &&
/usr/lib/php5/sessionclean

/usr/lib/php5/sessionclean: 34: /usr/lib/php5/sessionclean: php5: not found


The leftover php packages are:
$ dpkg -l *php* | grep ^ii
ii  php5-apcu 4.0.7-1  amd64APC User
Cache for PHP 5
ii  php5-common   5.6.24+dfsg-0+deb8u1 amd64Common
files for packages built from the php5 source

The installation has never had any package conflicts.

This looks to me like the php5-common debian package requires an
executable php5 to be present, but neither provides this executable nor
depends on another package that provides it.

Of course my personal solution is to also uninstall php5-common, but I
think the missing dependency here should be addressed.

Bug#833542: chromium: Crashes all the time after last update

[Salvo Tomaselli]

Package: chromium
Version: 52.0.2743.116-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,
after the last update, I am getting the "aw snap!" page all
the time.

I see on the changelog that security fixes were made, but
at the moment it became rather unusable for me.

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

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

Versions of packages chromium depends on:
ii  libasound2   1.1.2-1
ii  libatk1.0-0  2.20.0-1
ii  libavcodec57 7:3.1.1-4
ii  libavformat577:3.1.1-4
ii  libavutil55  7:3.1.1-4
ii  libc62.23-4
ii  libcairo21.14.6-1+b1
ii  libcups2 2.1.4-4
ii  libdbus-1-3  1.10.8-1
ii  libexpat12.2.0-1
ii  libfontconfig1   2.11.0-6.4
ii  libfreetype6 2.6.3-3+b1
ii  libgcc1  1:6.1.1-11
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-2
ii  libgnome-keyring03.12.0-1+b1
ii  libgtk-3-0   3.20.7-1
ii  libharfbuzz0b1.2.7-1+b1
ii  libjpeg62-turbo  1:1.5.0-1
ii  libnettle6   3.2-1
ii  libnspr4 2:4.12-2
ii  libnss3  2:3.25-1
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libpci3  1:3.3.1-1.1
ii  libpulse09.0-1.1
ii  libspeechd2  0.8.4-2
ii  libstdc++6   6.1.1-11
ii  libx11-6 2:1.6.3-1
ii  libxcomposite1   1:0.4.4-1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.2-1
ii  libxi6   2:1.7.6-1
ii  libxml2  2.9.4+dfsg1-1+b1
ii  libxrandr2   2:1.5.0-1
ii  libxrender1  1:0.9.9-2
ii  libxslt1.1   1.1.28-4
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.2-1+b1
ii  x11-utils7.7+3
ii  xdg-utils1.1.1-1

Versions of packages chromium recommends:
pn  fonts-liberation  

Versions of packages chromium suggests:
pn  chromium-l10n  

-- no debconf information

Bug#833129: usage with sudo

[John Goerzen]

I don't believe this is a bug with simplesnapwrap.  If all of these
commands require root anyway, why not run simplesnapwrap as root? 
(That's what it's designed to do.)

John

On 08/01/2016 03:35 AM, helix84 wrote:
> Package: simplesnap
> Version: 1.0.3
>
>
> Hello, first of all I'd like to apologize that I'm reporting here
> while I tried the package on Ubuntu where things may be set up
> differently. Secondly, thank you for this package, I just set it up
> for the first time along with zfSnap and it is very convenient, it
> exactly fills the niche I had.
>
> The problem on Ubuntu 16.04 (which may not be the case in Debian)
> stems from the fact that zfs is set up to be used via sudo whereas
> simplesnapwrap on activehost calls zfs without sudo (which is
> hardcoded in simplesnapwrap).
>
> My workaround was to add the simplesnap user on activehost to sudoers
> and allow the required subset of zfs commands:
>
> sudo visudo -f /etc/sudoers.d/zfs
>
> Cmnd_Alias C_ZFS_SIMPLESNAP = \
>   /sbin/zfs list *, \
>   /sbin/zfs send *, \
>   /sbin/zfs snapshot *, \
>   /sbin/zfs destroy tank@__simplesnap_*, \
>   /sbin/zfs destroy tank/root@__simplesnap_*
>
> simplesnapuser ALL = (root) NOPASSWD: C_ZFS_SIMPLESNAP
>
> But unfortunately I had to do a modification to
> /usr/sbin/simplesnapwrap on activehost:
> #ZFSCMD=/sbin/zfs
> ZFSCMD="sudo /sbin/zfs"
>
> Then as usual, I run simplesnap on backuphost from cron:
> 6-56/10 *   * * *   rootPATH=/usr/sbin:/usr/bin:/sbin:/bin
> /usr/sbin/simplesnap --host matrix --setname mainset --store
> backup/simplesnap --sshcmd "ssh -i /home/ivan/.ssh/id_rsa_simplesnap
> -l simplesnapuser"
>
> Of course, I hate to do changes to files owned by the package which
> can be overwritten in case of package upgrade, ergo this bug report.
>
> The solution I suggest is to allow the user to specify ZFSCMD as an
> environment variable, thus enabling creation of a "simplesnapwrap
> wrapper" (calling simplesnapwrap with ZFSCMD="sudo /sbin/zfs") which
> can be called from backuphost via --wrapcmd.
>
> If you see another way around it, I'll be happy to hear your thoughts.
> Thanks again.
>
>
> Regards,
> ~~helix84

Bug#833433: jessie-pu: package flashplugin-nonfree/1:3.6.1+deb8u1

[Bart Martens]

Control: tag -1 - moreinfo

On Fri, Aug 05, 2016 at 03:19:59PM +0200, Julien Cristau wrote:
> Control: tag -1 moreinfo
> 
> On Thu, Aug  4, 2016 at 11:38:34 +0200, Bart Martens wrote:
> 
> > +   if [ "`stat --format=%y $cachedir/get-upstream-version.pl`" \< 
> > "2016-08-04 09:35" ]
> 
> Not sure about using string comparison for comparing dates.  And is stat
> --format=%y's output stable across locales etc?

Yes, see function human_time in src/stat.c in coreutils.

> Wouldn't stat --format=%Y and test -lt make this easier?

That would be, in my opinion, less readable.

Regards,

Bart Martens

Bug#833541: ncbi-blast+: FTBFS on x32: bad assembly constraints

[Aaron M. Ucko]

Source: ncbi-blast+
Version: 2.4.0-2
Severity: important
Justification: fails to build from source (but built successfully in the past)

Builds of BLAST+ 2.4.0 (and 2.3.0, oops) have been failing on x32:

  /.../ncbi-blast+-2.4.0/c++/include/corelib/ncbicntr.hpp:237: Error: incorrect 
register `%esi' used with `q' suffix
  /.../ncbi-blast+-2.4.0/c++/include/corelib/ncbicntr.hpp:237: Error: incorrect 
register `%esi' used with `q' suffix
  /.../ncbi-blast+-2.4.0/c++/include/corelib/ncbicntr.hpp:237: Error: incorrect 
register `%eax' used with `q' suffix
  /.../ncbi-blast+-2.4.0/c++/include/corelib/ncbicntr.hpp:237: Error: incorrect 
register `%edx' used with `q' suffix

We should either adapt the inline assembly to handle x32 or do without
it altogether here (as already done on most architectures).

Bug#833539: ncbi-blast+: FTBFS on hurd-i386: PATH_MAX undefined

[Aaron M. Ucko]

Source: ncbi-blast+
Version: 2.4.0-2
Severity: important
Justification: fails to build from source (but built successfully in the past)

The Hurd builds of BLAST+ 2.4.0-2 failed:

  /.../ncbi-blast+-2.4.0/c++/src/connect/ncbi_socket_cxx.cpp: In member 
function 'std::__cxx11::string 
ncbi::CSocket::GetPeerAddress(ESOCK_AddressFormat) const':
  /.../ncbi-blast+-2.4.0/c++/src/connect/ncbi_socket_cxx.cpp:339:14: error: 
'PATH_MAX' was not declared in this scope
   char buf[PATH_MAX + 1];
^~~~
  /.../ncbi-blast+-2.4.0/c++/src/connect/ncbi_socket_cxx.cpp:341:47: error: 
'buf' was not declared in this scope
   SOCK_GetPeerAddressStringEx(m_Socket, buf, sizeof(buf), format) != 
0) {
 ^~~

This file (and any others that rely on PATH_MAX) should either honor
sysconf(_SC_PATH_MAX) dynamically or at minimum gain a conditional
definition of PATH_MAX; IIRC, 4096 is traditional.

Bug#833540: ITP: arasan -- chess engine for use with xboard

[Michael Knoop]

Package: wnpp
Severity: wishlist
Owner: Michael Knoop 

* Package name: arasan
  Version : 19.0.1
  Upstream Author : Jon Dart 
* URL : http://www.arasanchess.org//
* License : MIT, ZLIB, GPLv2
  Programming Lang: C++
  Description : chess engine for use with xboard



Arasan is a chess program for Windows, Linux and Mac OS.

Arasan has both a native user interface (for Windows only) and a console-based
chess engine for use with Winboard or xboard. Arasan also works with Arena,
another free chess interface, and with UCI-compatible programs like Fritz and
Chessbase.

Arasan includes an opening "book" with over 600,000 moves.

Since version 14.0, the Arasan chess engine has been licensed under the MIT
License.

This package includes the code for accessing the Gaviota endgame tablebases,
which the upstream developer has packaged separately.  It also includes his
large opening book, which he has likewise packaged separately.  The simple
3-man tablebases are available in the debian package gaviotatb.  More
tablebases can be provided by the user and linked to the program.  Arasan also
accepts the Syzygy tablebases, which the user will need to supply if desired.
This package does not include the code for accessing the Nalimov tablebases
because the license is not compatible with debian.

-

This is a strong chess engine in the same ranks as Crafty and Stockfish.  It is
a familiar and old adversary of mine from Windows.

This version depends on Xboard for its GUI interface.

I have received permission from Jon Dart to create a Debian package.  When I
contacted him about an issue with the program, his response was very quick and
helpful.

I plan to maintain it by dealing with packaging issues myself.  I plan on
investigating reported program bugs myself, but will probably need to refer
them to Jon Dart for solution.

Bug#833188: RFS: pam-u2f/1.0.4-0.3 [NMU]

[Gianfranco Costamagna]

Hi,



>However, I will wait for an answer from the Yubico people before adding
>myself as an Uploader and making the Vcs-* links point to Alioth.


wonderful, thanks for the nice work!

G.


On Tue, Aug 02, 2016 at 04:44:43PM +, Gianfranco Costamagna wrote:
> Hi,
> 
> >Updated on mentor.
> 
> >It might take a few monutes for it to show up on the web interface, though.
> 
> I usually *don't* like to sponsor stuff, specially NMU fixing no bugs on BTS,
> and moreover on non-release architectures.
> 
> In this very particular case upstream seems to be blessing every NMU you do, 
> and
> considering adding you as comaintainer, other than merging your patches.
> 
> So, I did sponsor it, but yeah, please take the comaintainership, because NMUs
> can be seen from the outside as "the maintainer is not caring", while in this
> case the maintainer is just "giving the packaging to you" :)
> 
> thanks once again for the fix!
> 
> G.
> 

Bug#833538: ncbi-blast+: FTBFS on s390x and sparc64: run_with_lock crashes

[Aaron M. Ucko]

Source: ncbi-blast+
Version: 2.4.0-2
Severity: serious
Justification: fails to build from source

The s390x and sparc64 builds of BLAST+ 2.4.0 have been failing:

  make[2]: Entering directory '/.../ncbi-blast+-2.4.0/c++/BUILD/build/corelib'
  /.../ncbi-blast+-2.4.0/c++/src/build-system/Makefile.meta_l:260: recipe for 
target 'sources.usr.locked' failed
  make[2]: *** [sources.usr.locked] Segmentation fault
  make[2]: Leaving directory '/.../ncbi-blast+-2.4.0/c++/BUILD/build/corelib'

The problem turned out to be that the build system, as patched by
Debian, winds up linking an optional helper tool named run_with_lock
with -pie but not compiling it with -fPIE.  On most platforms, this
inconsistency results in a linker error, and the build system proceeds
to fall back on a shell script.  However, on these two architectures,
the linker nominally succeeds but produces an executable that
immediately segfaults.

It should be possible to address the problem by supplying hardened
CFLAGS and LDFLAGS to configure as {C,LD}FLAGS_FOR_BUILD respectively;
we will then also want to add run_with_lock to the blacklist in
override_dh_install-arch.  I'll take care of these changes when I get
a chance, but am looking at a busy weekend.

Bug#518002: [Pkg-dns-devel] Bug#518002: Add apparmor profile for unbound

[Simon Deziel]

Hi Nicolas,

Thanks for integrating the profile. The addition of a local include
makes sense but there is a little typo:

-  #include 
+  #include 

Regards,
Simon

Bug#833537: pam-abl: Block login when the disk is full?

[Petter Reinholdtsen]

Package: libpam-abl
Version: 0.6.0-3

Hi.  I discovered this probelm when trying to log into a long negleted
FreedomBox.  I am unable to log in on the console, and these lines show
up after I enter the user name:

  pam-abl: BDB1546 unable to join the environment
  pam-abl: BDB0137 write: 07fd282048091, 25: No space left on device

This make me suspect pam-abl do not handle well a full disk.  What is
expected to happen with libpam-abl enabled when the disk is full?

I'm unable to provide more details, as I am unable to get into the
machine. :(

-- 
Happy hacking
Petter Reinholdtsen

Bug#831335: jessie-pu: package publicsuffix/20160703-1

[Adam D. Barratt]

On Fri, 2016-08-05 at 13:05 -0400, Daniel Kahn Gillmor wrote:
> ping!  I haven't heard back about this.  maybe my earlier reply was
> filtered out of some mailbox because of the size of the debdiff as
> described above?

It made it, I've just been suffering from a lack of sufficient tuits in
the meantime, I'm afraid.

Regards,

Adam

Bug#833009: linux-image-4.6.0-1-amd64: Hibernation does not work on Asus E200HA because of i915 and i2c_designware

[Jose M Calhariz]

Hi,

I have tried the vanilla kernel 4.7.  Now the hibernation almost works. 
When I select hibernation after some minutes I need to turn off the
laptop.  But when I turn on it awakes and return to the previous state. 
I still see the same error messages, but this time the keyboard works.

Kind regards
Jose M Calhariz




signature.asc
Description: OpenPGP digital signature

Bug#518002: [Pkg-dns-devel] Bug#518002: Add apparmor profile for unbound

[Nicolas Braud-Santoni]

Control: tag -1 + patch

Hi,

Here is your patch, along with patches for a few minor things that
lintian picked up.


Best,

  nicoo

On Mon, Jul 04, 2016 at 04:27:39PM -0400, Robert Edmonds wrote:
> 
> Hi, nicoo:
> 
> I'd be happy to ship an apparmor profile for unbound in the Debian
> package. Can you please send a patch that applies to the master branch
> of the packaging repository?
> 
> https://anonscm.debian.org/cgit/pkg-dns/unbound.git/
> 
> -- 
> Robert Edmonds
> edmo...@debian.org
> 
From 9813632bbf8a7200c8a162025a560a6cf9f62687 Mon Sep 17 00:00:00 2001
From: Nicolas Braud-Santoni 
Date: Fri, 5 Aug 2016 21:02:57 +0200
Subject: [PATCH 1/4] Ship AppArmor profile

Closes #518002
---
 debian/apparmor-profile | 45 +
 debian/control  |  2 ++
 debian/rules|  5 +
 3 files changed, 52 insertions(+)
 create mode 100644 debian/apparmor-profile

diff --git a/debian/apparmor-profile b/debian/apparmor-profile
new file mode 100644
index 000..a351c5c
--- /dev/null
+++ b/debian/apparmor-profile
@@ -0,0 +1,45 @@
+# Author: Simon Deziel
+# vim:syntax=apparmor
+#include 
+
+/usr/sbin/unbound {
+  #include 
+  #include 
+  #include 
+
+  # needlessly chown'ing the PID
+  deny capability chown,
+
+  capability net_bind_service,
+  capability setgid,
+  capability setuid,
+  capability sys_chroot,
+  capability sys_resource,
+
+  # root trust anchor
+  owner /var/lib/unbound/root.key* rw,
+
+  # root hints from dns-data-root
+  /usr/share/dns/root.* r,
+
+  # non-chrooted paths
+  /etc/unbound/** r,
+  owner /etc/unbound/*.key* rw,
+  audit deny /etc/unbound/unbound_control.{key,pem} rw,
+  audit deny /etc/unbound/unbound_server.key w,
+
+  # chrooted paths
+  /var/lib/unbound/** r,
+  owner /var/lib/unbound/**/*.key* rw,
+  audit deny /var/lib/unbound/**/unbound_control.{key,pem} rw,
+  audit deny /var/lib/unbound/**/unbound_server.key w,
+
+  /usr/sbin/unbound mr,
+
+  /{,var/}run/{unbound/,}unbound.pid rw,
+
+  # Unix control socket
+  /{,var/}run/unbound.ctl rw,
+
+  #include 
+}
diff --git a/debian/control b/debian/control
index be935c8..c39f5b2 100644
--- a/debian/control
+++ b/debian/control
@@ -9,6 +9,7 @@ Build-Depends:
  autotools-dev,
  bison,
  debhelper (>= 9~),
+ dh-apparmor,
  dh-autoreconf,
  dh-python,
  dh-systemd,
@@ -82,6 +83,7 @@ Depends:
  ${shlibs:Depends},
 Enhances:
  munin-node,
+Suggests: apparmor
 Description: validating, recursive, caching DNS resolver
  Unbound is a recursive-only caching DNS server which can perform DNSSEC
  validation of results. It implements only a minimal amount of authoritative
diff --git a/debian/rules b/debian/rules
index 3aa274d..cef57e7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -105,6 +105,11 @@ binary-arch: build
 	dh_python2 --no-guessing-versions
 	dh_strip
 	dh_compress -Xusr/share/doc/unbound/examples/unbound.conf
+
+	mkdir -p debian/unbound/etc/apparmor.d
+	cp debian/apparmor-profile debian/unbound/etc/apparmor.d/usr.sbin.unbound
+	dh_apparmor --profile-name=usr.sbin.unbound -punbound
+
 	dh_fixperms
 	dh_makeshlibs
 	dh_installdeb
-- 
2.8.1

From 520b0b1a0ce651a6e64a0ecd7607120bf3832c11 Mon Sep 17 00:00:00 2001
From: Nicolas Braud-Santoni 
Date: Fri, 5 Aug 2016 21:07:55 +0200
Subject: [PATCH 2/4] debian/control: Use HTTPS for Vcs-Git link

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index c39f5b2..bac3cf3 100644
--- a/debian/control
+++ b/debian/control
@@ -28,7 +28,7 @@ Build-Depends:
 Standards-Version: 3.9.6
 Homepage: https://www.unbound.net/
 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-dns/unbound.git
-Vcs-Git: git://anonscm.debian.org/pkg-dns/unbound.git
+Vcs-Git: https://anonscm.debian.org/git/pkg-dns/unbound.git
 
 Package: libunbound-dev
 Section: libdevel
-- 
2.8.1

From 091b55a6c0f1ab3621618ec85f9ee23aff9f0326 Mon Sep 17 00:00:00 2001
From: Nicolas Braud-Santoni 
Date: Fri, 5 Aug 2016 21:13:39 +0200
Subject: [PATCH 3/4] Add documentation to the systemd unit file

---
 debian/unbound.service | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/unbound.service b/debian/unbound.service
index 549c8fe..7c1210a 100644
--- a/debian/unbound.service
+++ b/debian/unbound.service
@@ -1,5 +1,6 @@
 [Unit]
 Description=Unbound DNS server
+Documentation=man:unbound(8)
 After=network.target
 Before=nss-lookup.target
 Wants=nss-lookup.target
-- 
2.8.1

From d486dedc3077053fe80f5186d1a210c6c984c54d Mon Sep 17 00:00:00 2001
From: Nicolas Braud-Santoni 
Date: Fri, 5 Aug 2016 21:15:18 +0200
Subject: [PATCH 4/4] Bump Standards-Version to 3.9.8

No change required
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index bac3cf3..9ab7b6a 100644
--- a/debian/control
+++ b/debian/control
@@ -25,7 +25,7 @@ Build-Depends:
  

Bug#831335: jessie-pu: package publicsuffix/20160703-1

[Daniel Kahn Gillmor]

On Thu 2016-07-14 18:25:00 -0400, Daniel Kahn Gillmor wrote:
> On Thu 2016-07-14 20:06:27 +0200, Adam D. Barratt wrote:
>> Please could we have a debdiff, relative to the current package in
>> jessie, in this bug log? (We prefer p-u bugs to be self-contained, and
>> not have to rely on your git tree existing for arbitrary periods in the
>> future, or on it not changing after we give an ack.)
>
> sure.  the debdiff is quite large, primarily due to upstream renaming
> effective_tld_names.dat to public_suffix_list.dat (and adding a
> python-based "linter", and changing how they produce their upstream
> changelog), but i've attached the gzip'ed debdiff below.
>
> The git tree's jessie branch which i'm proposing is at commit ID
> 6520ee81d3e2d73192e67685652ef6bccdb2e637, fwiw, so you don't have to
> worry about it changing.

ping!  I haven't heard back about this.  maybe my earlier reply was
filtered out of some mailbox because of the size of the debdiff as
described above?

 --dkg


signature.asc
Description: PGP signature

Bug#833016: linux-image-4.7.0-rc7-amd64-unsigned: Shutdown when pressed any key of the keyboard

[Jose M Calhariz]

Hi,

I have just tried a vanilla kernel 4.7 and it just works.

Kind regards
Jose M Calhariz




signature.asc
Description: OpenPGP digital signature

Bug#830658: [pkg-gnupg-maint] Bug#830658: gpg-agent: cannot talk to libsecret when started from systemd

[Daniel Kahn Gillmor]

Control: retitle 830658 gpg-agent: cannot talk to libsecret when used as 
ssh-agent and not started from the same session
Control: tags 830658 + help upstream

Hi Brian--

On Sat 2016-07-09 18:58:43 -0400, brian m. carlson wrote:
> The recommended way to use gpg-agent, according to README.Debian, is to
> use systemd to start it automatically in the session.  However, when
> doing that, the agent does not inherit $DISPLAY.  This prevents dbus,
> and hence the libsecret integration in pinentry-gnome3, from working.
> Since my passphrases are stored in my desktop's keyring integration, I
> can't use my SSH keys:
>
> genre ok % ssh -oGSSAPIAuthentication=no castro
> sign_and_send_pubkey: signing failed: agent refused operation
> sign_and_send_pubkey: signing failed: agent refused operation
> Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
>
> A dump of the environment from such a gpg-agent process follows:
>
> HOME=/home/bmc\0LANG=en_US.UTF-8\0LOGNAME=bmc\0PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin\0SHELL=/bin/zsh\0TEMP=/tmp/user/1000\0TEMPDIR=/tmp/user/1000\0TMP=/tmp/user/1000\0TMPDIR=/tmp/user/1000\0USER=bmc\0XDG_RUNTIME_DIR=/run/user/1000\0MANAGERPID=2813\0
>
> As you'll notice, it's lacking the most rudimentary X environment
> variables.

Thanks for this report (and sorry for the delay in response).

This isn't a problem for the normal uses of gpg-agent (whether started
in-session, via systemd, or even in a separate session), because gpg
knows to send gpg-agent X11 and dbus session credentials on each use.

It's a problem when gpg-agent is used as ssh-agent, because the
ssh-agent protocol doesn't have any way to transmit these configuration
preferences.  This isn't just true for systemd-managed services, it's
also true for a gpg-agent used across concurrent sessions (i.e. started
in session A and then accessed from session B).

So i'm not sure what the right approach is here; there's something of an
impedence mismatch between OpenSSH's agent and GnuPG's agent, and having
one pretend to be the other ends up with this sort of friction.

By "impedence mismatch" i mean things like the following:

 * ssh-agent expects to be run ephemerally, with basically no access to
   the filesystem other than to launch ssh-askpass when needed, and gets
   its keys after each initialization by explicit handoff from the user.
   gpg-agent expects to read and manage its ~/.gnupg/private-keys-v1.d
   directory (where its secret key material is stored) and spawns
   scdaemon (if needed/installed) in addition to spawning pinentry.

 * ssh-agent is configured at process initialization about how and where
   to prompt for confirmation, and is configured at key-load about
   whether to prompt for the use of a given key.  gpg-agent is
   configured at *use* time about how and where and whether to prompt
   for the use of a given key.

Their associated non-daemonized tools (at least gpg and ssh) make some
assumptions about these patterns.

I'd welcome help in resolving this, but i'm not sure what the right
thing to do is.

  --dkg


signature.asc
Description: PGP signature

Bug#707320: [Aptitude-devel] Bug#707320: marked as done (aptitude: implement partially forgetting new packages)

[Christoph Anton Mitterer]

Hey...


On Sun, 2016-07-24 at 15:41 +0100, Manuel A. Fernandez Montecelo wrote:
> Given that it's an improvement over the previous functionality (all
> or
> nothing), in any case, it's more flexible than before...  but I
> disagree
> that it's more unflexible than your proposal (read on).

Hmm I tried it now for a few days, and while in principle it allows for
more things to do, my original view hasn't changed and I'd still
consider unfortunate for practical use. :-(

The major use case I'd have seen in the selective forgetting is that
one can keep those packages one wants to have a look at later on.
This use case typically means that only a small subset of the new
packages is wanted to be kept (otherwise one could just keep all).

This in turn however makes the matching based solution rather
impractical for day to day use:
- new packages turn up in many sections, and often not all of those in
  one section are interesting enough to be kept
  thus filtering out based on the section doesn't really seem to work
  in many cases, and even if it would one would still have to type in
  all those sections one wants to discard (which can be quite some)
- filtering out single packages is unhandy either
  As I've said before, it's typically the minority one wants to select
  but the filtering works vice-versa (i.e. selecting all those one
  wants to discard). Even without fast growing sections like dbg[sym]
  this end up being unusable.
  Inverting the filter wouldn't help IMO either, one would still need
  to write up all those packages that are to be kept, and since one
  needs to navigate through the package view and often all interesting
  packages wouldn't fit on one screen, I'd alrady need another editor
  or so, where I write up the interesting things.


> Had the "F" shortcut not been taken for a completely different
> purpose,
Doesn't F anyway make just sense on already installed packages?
While there can be packages in the New section which are installed (but
just not forgotten yet),... I'm sure no one would bother if F would get
another meaning when one is in the New tree.

> I would have let "f" behave as before or perhaps implement your
> suggestions (context-based, forgetting depending on where you
> are).  But
> I didn't want to add a completely different shortcut, or have the new
> feature only accessible through a menu, that perhaps people would not
> discover for a long while.
hmm..


> One of the problems that I found with your suggestions is that if
> people
> don't know about the feature and press "f" expecting that everything
> is
> forgotten as before, and only one package or a small section is
> forgotten, they might think that forgetting-new is not working at
> all,
> or not working properly, or at least it will be puzzling for a while
> until they learn that it's a "new feature" and how to use it.
Well but that's a general problem with evolution of software... you add
new features, and when people don't read the changelogs, they won't
know about it.
With that argument one could more or less never change anything.

I'd have expected that some NEWS.Debian entry about any new behaviour
would fix any such conernts..



> In the new implementation, the pop-up might be surprising the first
> time, but it's pretty obvious what it needs to happen: just press
> "enter" for the old behaviour, or use package names for patterns, as
> suggested in the dialog.  I think that it introduces nicely the new
> feature to the users, while only being minimally disruptive for the
> ones
> used to the old behaviour.
But it still "breaks" user "experience".
I for example end up basically every 2nd time, pressing f then g
(because usually I do the upgrades afterwards), but now the "g" goes
into the popup.



> Added bonus is that at least it needs an extra key stroke to have the
> old behaviour clear all new ("f + Enter"), so it's likely to trigger
> by
> mistake than before (which happens from time to time, and a case for
> which your suggestions in that bug report don't improve when people
> press the key by mistake).

Maybe one could have also "completely" changed f's behaviour, i.e. not
immediately forget the package (and refresh the view), but just mark it
dark grey or so (i.e. scheduled to be forgotton)... and when people
exit aptitude, and/or perhaps on "g", and/or on some "save forgotten
status function"... it would have been actually saved.

This would make the "need" for an extra key stroke go away and allow
people to undo their "f" without Ctrl-C aptitude.

btw: I don't think that f+Enter really solves the issue you try to
address above.
As soon as people will get used to the popup, the f+Enter will go into
flesh and blood for most, and the extra key stroke won't work as a
guard anymore.



> Also, it's easier to clear away all packages in ways that do not
> conform
> to the current visible hiearchy, e.g.:
> 
> - forgetting-new all packages from a source package
> 
> - or a pattern based on source 

Bug#764678: dh-systemd: Please support systemd user services

[Daniel Kahn Gillmor]

On Tue 2016-06-28 19:39:26 -0400, Michael Biebl wrote:
> Am 29.06.2016 um 00:11 schrieb Daniel Kahn Gillmor:
>> On Fri 2014-10-10 03:30:07 -0400, Michael Vogt  wrote:
>>> It would be very nice if dh-systemd would support systemd user
>>> units (both for detecting them during build time and to add
>>> something like "systemctl --global enable my-user-unit" to the
>>> debian/postinst).
>>>
>>> My use case is that the package installs a unit that
>>> should run at login time for all users. In the past this was 
>>> done via the upstart session support. 
>> 
>> fwiw, i'd like to see this capability for dh-systemd as well.
>> 
>> One alternative available now is to have the package manually ship a
>> symlink in /etc/systemd/user/default.target.wants/$PKGNAME.service
>> (pointing to /usr/lib/systemd/user/$PKGNAME.service, assuming the user
>
> Shipping a static symlink in /etc is ugly, I would recommend against
> doing that.
>
> Daniel, which service do you have in mind which already requires a
> systemd user session and systemd user services?

i'm looking at this for the gnupg-agent and dirmngr packages
(gpg-agent.service and dirmngr.service), which are currently generated
From the gnupg2 source package in experimental.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#831184: mumble: FTBFS with GCC 6, seems Ice related

[Chris Knadle]

Jose Gutierrez de la Concha:
> On Thu, Aug 4, 2016 at 7:03 PM, Chris Knadle 
> wrote:

[...]
> Can you try to put /usr/lib/x86_64-linux-gnu/c++11 before
> /usr/lib/x86_64-linux-gnu
> otherwise linker will pick the C++98 libs

Mmm... okay that information helps.  Though... unfortunately this isn't
simple to do.

I don't know what's adding -L/usr/lib/x86_64-linux-gnu at the moment, as
this doesn't appear anywhere in the source package.  It's probably being
added by debhelper or qmake.  Either way it's going to take some
investigation to figure out what's doing it and to change what it's doing.

Thanks

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#833536: pkg-haskell-tools: dht should allow uploading by FTP

[Sean Whitton]

Package: pkg-haskell-tools
Version: 0.10.3
Severity: normal

Hello,

Is there some reason that dht's upload subcommand uploads to ftp-master
with SSH rather than FTP?  This prevents Debian Maintainers from using
the command to upload.

If there is no good reason, we could change it to use FTP.
Alternatively, we could add a command line flag to select FTP or SSH --
not sure what the default should be.

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

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

Versions of packages pkg-haskell-tools depends on:
ii  cabal-debian4.32.5-1
ii  dctrl-tools 2.24-2
ii  devscripts  2.16.6
ii  libbz2-1.0  1.0.6-8
ii  libc6   2.23-4
ii  libffi6 3.2.1-4
ii  libfile-slurp-perl  .19-5
ii  libgmp102:6.1.1+dfsg-1
ii  perl5.22.2-3
ii  reprepro4.17.1-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages pkg-haskell-tools recommends:
ii  colordiff  1.0.16-1

pkg-haskell-tools suggests no packages.

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#833525: debootstrap: Deleted my entire /home partition using "mostly harmless" debootstrap --print-debs option

[Brian Drummond]

On Fri, 2016-08-05 at 17:15 +0200, Johannes Schauer wrote:
> Control: tag -1 + patch
> 
> On Fri, 05 Aug 2016 13:55:14 +0100 Brian Drummond  n.co.uk> wrote:
> > 
> > *** Reporter, please consider answering these questions, where
> > appropriate ***
> > 
> > 8) I said this was embarassing...
> > 
> >    * What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > debootstrap --print-debs /chroot/i386
> > 
> if I understand correctly, the problem is two-fold:
> 
>  - debootstrap removes everything in a directory even if there was
> stuff in it
>    beforehand (this should not happen)
> 
>  - debootstrap removes recursively across filesystem boundaries (how
> was this
>    not noticed earlier?)
> 
> The following patch should fix this:

Thank you! 

If I understand the patch, it should have the desired effect.

I find myself strangely reluctant to test it ... may I
be forgiven?

(I know ... why don't I just chroot into a safe place and test it
there? :-)

Hopefully it will be accepted into Debian and stop somebody else making
such a fool of themselves...

Thanks again!

-- Brian

Bug#833361: runit: Init files (/etc/runit/*) should be provided by runit-init not runit

[Dmitry Bogatov]

control: tags 833361 +wontfix
control: close 833361

> > But I find it ugly to separate them. WTDYT?
>
> Right, indeed. How about making runit-sysv and runit-systemd call
> runsvdir directly instead of calling /etc/runit/2?

Code duplication. And this code will evolve separately, which is
nighmare.

If you really want to get rid of this files, you can use 'dpkg
excludes' (be careful, it can be dangerous).

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#833188: RFS: pam-u2f/1.0.4-0.3 [NMU]

[Nicolas Braud-Santoni]

Hi Gianfranco,

Thanks a bunch for the sponsored upload.

I agree that the situation is not very comfortable, but I have great news:
I have been added to pkg-auth, so my next upload on those packages shall be
team uploads and not NMUs.  ;)

However, I will wait for an answer from the Yubico people before adding
myself as an Uploader and making the Vcs-* links point to Alioth.


Best,

  nicoo


On Tue, Aug 02, 2016 at 04:44:43PM +, Gianfranco Costamagna wrote:
> Hi,
> 
> >Updated on mentor.
> 
> >It might take a few monutes for it to show up on the web interface, though.
> 
> I usually *don't* like to sponsor stuff, specially NMU fixing no bugs on BTS,
> and moreover on non-release architectures.
> 
> In this very particular case upstream seems to be blessing every NMU you do, 
> and
> considering adding you as comaintainer, other than merging your patches.
> 
> So, I did sponsor it, but yeah, please take the comaintainership, because NMUs
> can be seen from the outside as "the maintainer is not caring", while in this
> case the maintainer is just "giving the packaging to you" :)
> 
> thanks once again for the fix!
> 
> G.
> 


signature.asc
Description: PGP signature

Bug#721751: dnsmasq-base: Always listens on all interfaces

[Clément Hermann]

Hi,

Just want to add my bit on this one.

The documentation states that when "interface" option is used, the
daemon binds on * but reject queries that come to interfaces not listed.

This does not work, so eitheir the documentation is misleading or there
is a bug (arguably a security one, since it leads to a false sense of
security when you think you're not enabling DNS service on a public
interface when in fact you are).

Cheers,

-- 

Clément Hermann
Senior Network System Engineer

VIRTUA.CH
T +41 21 544 28 00

FACEBOOK // http://l.virtua.ch/facebook
TWITTER  // http://l.virtua.ch/twitter
LINKEDIN // http://l.virtua.ch/linkedin

Bug#734005: error: git-svn died of signal 11 (at least doing git svn fetch/rebase)

[Jason Briggs]

The error was the same
error: git-svn died of signal 11
(no other information printed)

I try several month ago on Arch linux virtual machine guest on Debian Jessie 
host and had same, signal 11.

Some people have similar on Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/git/+bug/1252097

Bug#833534: ITP: rpyutils -- Flash and communicate with an RP6 robot

[Benedikt Wildenhain (BO)]

Package: wnpp
Severity: wishlist
Owner: "Benedikt Wildenhain" 

* Package name: rpyutils
  Version : 0.1
  Upstream Author : Maximilian Mühlbauer 
* URL : https://github.com/scirocco/rpyutils
* License : GNU GPL v3+
  Programming Lang: Python3
  Description : Flash and communicate with an RP6 robot

The Robby pyUtils allow to reprogramm Arexx' RP6 robot, control program
execution and exchange data with the program running on the robot.


There is no other program in Debian to program this type of robots. We
use those robots and software at the university I am working for in
class. I plan to do the packaging on my own, but would need a sponsor.

I am currently maintaining one other package inside Debian
(air-quality-sensor, written in C).

Bug#734005: error: git-svn died of signal 11 (at least doing git svn fetch/rebase)

[Jason Briggs]

I experience this heavily on Debian Jessie with

git-svn 1:2.1.4-2.1+deb8u2
libsvn-perl 1.8.10-6+deb8u4

to point where git-svn unusable.

[ 1463.669888] git-svn[3270]: segfault at 7fab78a3a178 ip 7fab7f80da31 sp 
7ffc8c6d7280 error 6 in _Delta.so[7fab7f7fa000+2a000]
[ 2701.760387] git-svn[29940]: segfault at 7fa6f896d370 ip 7fa6ff5a1a31 sp 
7fff96961620 error 6 in _Delta.so[7fa6ff58e000+2a000]

Bug#831382: closed by Sebastian Ramacher <sramac...@debian.org> (Re: Bug#831382: mplayer2: keyboard shortcuts fail for up/down/left/right arrows.. program hangs in "seek" (apparently))

[Sebastian Ramacher]

On 2016-07-17 08:20:15, Ralph Ronnquist wrote:
> I'll take this as an impolite way of aking "Does this happen on Debian 8
> Jessie as well?", and the answer is "Yes, it does indeed."

And the answer to that is: mplayer2 was removed from the archive, so this issue
is "fixed" in version 2.0-728-g2c378c7-4+rm.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#833525: debootstrap: Deleted my entire /home partition using "mostly harmless" debootstrap --print-debs option

[Johannes Schauer]

Control: tag -1 + patch

On Fri, 05 Aug 2016 13:55:14 +0100 Brian Drummond  
wrote:
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 0) Okay, this will be embarrassing...
> 1) Occasional need to work on i386 software on an x86-64 machine.
> 2) Previous experiment led to a marginally usable "minimal"  /chroot/i386 
> partition (without internet connection)
> 3) Desire to add internet connection to same, start by listing packages which 
> would be installed by "debootstrap --print-debs"
> 4) Failure to understand that "debootstrap --print-debs" operated by 
> performing the entire debootstrap operation, 
> listing packages, then deleting the created directory, despite a note in the 
> manfile to that effect.
> 5) Further failure to note that such deletion would apply recursively to any 
> automounted partitions in said created directory. 
> 6) Previous experiment involved automounting /proc, /sys, /var/tp, and /home 
> into said /chroot/i386 partition.
> 7) Re-using the /chroot/i386 directory name in the "debootstrap 
> --print-files" command. Without the --keep-bootstrop-dir option, since I was 
> about to replace it.
> 8) I said this was embarassing...
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Sadly, I no longer have my exact notes, as will become clear. But 
> approximately, the command was (possibly with sudo, or after su):
> debootstrap --print-debs /chroot/i386
> 
>* What was the outcome of this action?
> Well I briefly saw the list of packages flash past, before debootstrap got to 
> the "The TARGET directory will be deleted" part.
> At which point various strange things started happening, until it gradually 
> dawned on me that /home and /var/tmp were slowly disappearing before my 
> eyes...
> 
>* What outcome did you expect instead?
> 
> Somehow I expected to be left with a list of .deb packages and a functioning 
> computer. I now understand my expectations were unrealistic.
> 
> Perhaps I have been punished enough ... and perhaps it would be a good idea 
> to modify the bit of debootstrap that implements 
> "The TARGET directory will be deleted" and convince it to stop at 
> automounted partitions in /etc/fstab (and/or mtab)?
> 
> It is too late for me, but it might be very pleasing to some future unwary 
> operators to be left with their /home partition intact... 
> 
> (NB the packages/versions listed below apply to a reinstall, not the exact 
> formerly-running system, for reasons that are hopefully clear)

if I understand correctly, the problem is two-fold:

 - debootstrap removes everything in a directory even if there was stuff in it
   beforehand (this should not happen)

 - debootstrap removes recursively across filesystem boundaries (how was this
   not noticed earlier?)

The following patch should fix this:


@@ -409,6 +409,11 @@
fi
 fi
 
+TARGET_EMPTY=true
+if [ "$(ls -A "$TARGET")" ]; then
+   TARGET_EMPTY=false
+fi
+
 ###
 
 if in_path dpkg && \
@@ -698,8 +703,8 @@
 fi
 
 if am_doing_phase kill_target; then
-   if [ "$KEEP_DEBOOTSTRAP_DIR" != true ]; then
+   if [ "$KEEP_DEBOOTSTRAP_DIR" != true && "$TARGET_EMPTY" == true ]; then
info KILLTARGET "Deleting target directory"
-   rm -rf "$TARGET"
+   rm -rf --one-file-system "$TARGET"
fi
 fi


Thanks!

cheers, josch


signature.asc
Description: signature