Bug#828907: plymouth external firmware error

[Laurent Bigonville]

Le 29/06/16 à 07:34, Cédric Brandenbourger a écrit :

Yes firmware-misc-non-free is installed

when i type:

plymouth-set-default-theme -R details, i don't get any message


with all the other templates i get the error


This is because the initramfs hook copy the drm (and other kernel 
modules) in that case, see /usr/share/initramfs-tools/hooks/plymouth:


copy_modules_dir kernel/drivers/gpu/drm mga r128 savage sis tdfx via

TBH I don't think this is a plymouth issue, if initramfs-update is not 
copying the needed firmware in the initramfs it's either a bug there or 
the firmwares are not placed on disk at the correct location

Bug#828889: RFS: elisp-slime-nav-el/0.9-1 ITP

[Sean Whitton]

control: owner -1 !
control: tag -1 +moreinfo

Hello Dmitry,

I thought you were finished after evil and its dependencies :)  Glad to
see more ELPA packages.  Here's a review for you.

1. The "-el" suffix on the source package name is pointless because the
   name already contains "elisp" so it's clear that it's an Emacs
   package.  Please consider dropping the suffix.  On the Emacsen team
   we use upstream names where possible.

2. Have you forwarded 0001-Fix-Package-Version-header.patch upstream?

3. Please patch README.md to remove the installation instructions (might
   be confusing to someone who has already installed the package) and
   remove the MELPA badges from the top (useless in plain text).

4. No pristine-tar branch is available.  For the sake of the sponsorship
   process it might be worth adding one.

I installed the package and it seems to work well!

On Tue, Jun 28, 2016 at 10:50:00PM -0400, Sergio Durigan Junior wrote:
> 1) The links listed on the Vcs-* fields are not valid, so perhaps you
> may want to (a) push your git repo temporarily at another URL, or (b)
> create the repo under collab-maint/ and push your things there.

They seem to work now!

> 3) Any reason why you're using debhelper version 10?  It's still
> experimental, so you probably should be using version 9.

My guess is that he generated the packaging with dh-make-elpa.  It sets
compat 10 in order to enable dh_elpa_test.  In this case, it's not
necessary since there is no test suite.

-- 
Sean Whitton

Bug#828940: ITP: python-dropbox -- Official Dropbox API Client

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-dropbox
  Version : 6.5.0
  Upstream Author : Dropbox Inc. 
* URL : https://github.com/dropbox/dropbox-sdk-python
* License : Expat
  Programming Lang: Python
  Description : Official Dropbox API Client


 A Python SDK for integrating with the Dropbox API v2. It offers a comprehensive
 set of features to interact with the Dropbox cloud service:
 .
  * OAuth2 authentication
  * File and folder manipulation
  * Managing shared links and folders

I will maintain this package as part of the DPMT and it is a dependency for the
dropbox backend in django-storages which I also plan to package.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJXc3QfAAoJEGlMre9Rx7W25SEQAKze5trg3WFdOPeLnq93rq7e
vKMntVzlx+TfhlBW1N0ygthEMNscoJ7Pxwqa1z3pVqDgFSOOEi1ERLjZvUUO5ih1
la9Fp343cafcw3OzTKdsFkRawVwsph/Nl9VH+sfjjfJmbH4xusLflbKfBKqYMLsS
vstboaM4WzE5uvo8c8AaiLj1Y9HZp/riiE99hhIGD82v+y4J/M7i5sf0rX61lquP
A2og0zKmA18BlLkOvy1cmqbhGEXNoKuBnxN/0P3BPHcB75d6OTbDmRZvlPovMRRC
bDzVjkCFb6zO3r+6wteRFjQ3g+m6nFqqGAyH/bsEUz4lZApBz62zY76cmdF5Kdu9
YfIT/+JiZVIaludTVJNxCKum6nNtvrvj96hQRDcV6MhIAcqEO5JDJZ7/FfFuzNkb
imBHalGmVzHkQWSPi29iJWtS6xmNZFhnsixS2OXLhj0l1FYAy+ag1oJcWeA+koaX
7a21QNAtJZ7YSgX0XTThpxSZEKO1ZEqRWWsx6Es3998nyCTf61cFQnhfbjU8tvcj
fGwnIAKlJEw14vjg3VDGWbHs5uRV2U2ykgiQolHbEhxRiiS1m8jhMj7xqfrv6l+T
EQ2aTXcMyEhlfcJE/JpnRQBf35MKXu3n4jXGPJESrRAOmFDKrzlGVmZp2XYos1xo
L2QA99UwY512jVRgJKUp
=knTh
-END PGP SIGNATURE-

Bug#827907: RFS: evil/1.2.12-1 ITP

[Sean Whitton]

Hello,

Try removing the call to dh_auto_build from your override_dh_auto_build.
It's doing a bunch of byte compilation that is unnecessary because
dh-elpa will do that later on.

On Tue, Jun 28, 2016 at 02:01:41PM +0300, Dmitry Bogatov wrote:
> In general, do we have any script, that automates process of writing
> watch files? Every time I need to write watch file for github, I
> copy-and-paste from comments in /usr/bin/uscan.

There is the uscan manpage, rather than looking at the code, which you
might consider slightly better.

On Tue, Jun 28, 2016 at 04:49:33PM +0300, Dmitry Bogatov wrote:
> Do not understand. I alread have tarball content, as I downloaded
> it at 'upstream/1.2.12'. What more we need?

It just means that your tarball will be different from the one that
actually gets uploaded by the DD who sponsors the RFS.  Hopefully it is
not materially different (just timestamps etc.) but I think that
settings in ~/.gbp.conf could mean a materially different tarball gets
generated on the DD's machine.  It's a nice safety check if we can check
out your tarball from the pristine-tar branch.  But not a big deal and
certainly doesn't block sponsorship.

> Here is script, that does same as dh_elpa_test:
> 
>   emacs -batch -Q -L . --eval "(require 'evil)" -l package \
> --eval "(add-to-list 'package-directory-list 
> \"/usr/share/emacs/site-lisp/elpa\")" \
> --eval "(add-to-list 'package-directory-list 
> \"/usr/share/emacs/site-lisp/elpa-src\")" \
> -f package-initialize \
> -L . \
> -l evil-tests.el \
> -l lib/ert.el \
> -L lib \
> -f evil-tests-initialize
> 
> It reports 22 failures. If I replace -batch with -nw, all tests
> passes. So seems tty is really needed, but I do not understand why.

This is not what dh_elpa_test is actually running ;)  It's calling
`ert-batch-run-tests-and-exit' instead of `evil-tests-initialize'.  Before
we can debug this properly, we need to make dh_elpa_test do the same
thing that upstream's makefile does (except the -nw/-batch).  Please
investigate DH_ELPA_TEST_ERT_RUNNER (hint: add debian/run-tests.el).

In the worst case, if we can confirm that some of tests really do
require a tty (it would be good to figure out why -- maybe ask
upstream?), you can add a patch disabling those tests in particular.

> > It seems it wasn't enough.  If I move my .emacs.d out of the way and
> > then run it, and M-x evil-mode, I get this:
> >
> > Error in post-command-hook (evil-repeat-post-hook): (void-function 
> > evil-repeat-post-hook)
> > Error in pre-command-hook (evil-repeat-pre-hook): (void-function 
> > evil-repeat-pre-hook)
> 
> Patched it. Check again.

Nice work.  Have you forwarded the fix upstream?

-- 
Sean Whitton

Bug#828889: RFS: elisp-slime-nav-el/0.9-1 ITP

[Gianfranco Costamagna]

Hi,

>3) Any reason why you're using debhelper version 10?  It's still

>experimental, so you probably should be using version 9.


I'm not sure about this, some days ago debhelper 11 implementation started, so 
I think compat
level 10 is somewhat considered stable?
https://anonscm.debian.org/git/debhelper/debhelper.git/commit/?id=d52c3364f9518e021be31f350204fe8e4a24619b

Gianfranco

Bug#802702: CVE-2011-5325: busybox: Directory traversal via crafted tar file which contains a symlink pointing outside of the current directory

[Chris Lamb]

> Any idea why the resolution of this issue did not move any further?  I notice 
> from
> the upstream tracker that hardlinks might be a problem too.

Indeed, the hardlink part was blocking it.

IIRC it was deemed to be low-priority from an LTS point of view so/and I could 
not justify spending more time on it then. Happy to look again if there is a 
more urgent requirement.


Regards,

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

Bug#827907: RFS: evil/1.2.12-1 ITP

[Gianfranco Costamagna]

Hi,


>> > Unfortunately, upstream maintains only list of contributors. So seems

>> > best thing we can do is to count 60 years from last debian upload.
>> 
>> I'm not sure whether this is likely to be acceptable to the ftp-masters
>> or not.  Perhaps someone more experienced on debian-mentors can chime
>> in.
>
>Gianfranco, your opinion?


I'm far from being expert here, but I think ftpmasters care more about
licenses and dfsg-freeness instead of copyrights.
As long as the license is dfsg they are fine, specially because in the
*worst case* the license will be dfsg, in the best case it *might* be public
domain.

So, in every case we have a "good" license (Debian-wise, I don't personally
like GPL-3+ and I prefer GPL-2+)

Gianfranco

Bug#828939: RM: cyrus-imapd-2.4 -- ROM; superseded by src:cyrus-imapd

[Scott Kitterman]

The only tool we have closes them, so I'd suggest you go and reassign those 
that should be reassigned.

Scott K

On June 29, 2016 2:36:45 AM EDT, "Ondřej Surý"  wrote:
>Package: ftp.debian.org
>Severity: normal
>
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>Dear ftp-masters,
>
>please remove the leftovers from src:cyrus-imapd-2.4 that got
>superseded by src:cyrus-imapd.
>
>The bugs can be reassigned to src:cyrus-imapd package (if you have a
>tool that does this automatically - if not, please let me know, I will
>handle this by hand).
>
>Thank you very much,
>Ondřej
>
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v2
>
>iQJ8BAEBCgBmBQJXc2x9XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
>ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMEI5MzNEODBGQ0UzRDk4MUEyRDM4RkIw
>Qzk5QjcwRUY0RkNCQjA3AAoJEAyZtw70/LsHdFoP/iGT6FarAh/jBZXS042c6KJh
>K/y1SFQCl15bMgJLlSa4679Ktgawv5YSV9m8ebNVQlji0TSO1su6GA2jlA6qFhHI
>XNC3aBeeiJPCPbUNOsd7eBvAERlFM5H3RrvOGwBYh5AlqKtoSkSiRKrJpaisYq3o
>b0/5n/KCOVREizbxxHkZZf29FcZdSMSiMTJVzi+atehFiGDLUujUPevG7WxJqcLI
>yzs8UpGnwx3KXSOvQ3kY/1BAhwCIzHu4Z3BnQI3DkIE8olMgKXHSodNLfomcIMUJ
>JQZDyWt5T5CGXHJSqOQkuVkpImfUaXRQHb5H/4U4TrOmOPOM3dJYRqJvfJT5rJyW
>xJaU0+cTp4dy+e+CA3ZfAzDpTRwh2TY3thPtX8xKAfS/zFvxfr3U4ffo3YKKe3Hz
>BZQXy/OvLcOLjNfg6FhWspA+T6NxCc3Niru/6wez7bpSiGPoyyle4qcaa455xGfK
>ewnEzFkiSskF3nEjO4Mac0iQt4OVjSCsGjnpD5XW1NNi8LfHKKTu8LXfiJy2kzhI
>9+M7BN0tYTXPP1/ZZrCoigDY0Cku9EU/H0Lz7zQSdLWgpyBIG//evTxVaAfY4qza
>8FJTj3L96sAcS0fPvN90dZszE8wgXBATz+uptL934ohnt/JWu6Y/Pu8if0EIStue
>5VznxbGnCROIAWqGcimX
>=/tkL
>-END PGP SIGNATURE-

Bug#828904: FTBFS on GNU/Hurd

[James Clarke]

Control: forwarded -1 
http://lists.gnu.org/archive/html/bug-mailutils/2016-06/msg5.html

Here's an alternative patch which I submitted upstream. I had to change
it since gint is an external project that is pulled in as a submodule,
and thus cannot be patched upstream to refer to ../lib/gnu outside its
tree. Also tested on hurd-i386 (as well as no regressions on amd64).
This patch is against upstream's master, and is thus offset slightly
when applied, so it should be refreshed before being added to the
package.

Regards,
James
From 7a60e7c449ce46c4820ebe0c26f4d11bef66193a Mon Sep 17 00:00:00 2001
From: James Clarke 
Date: Tue, 28 Jun 2016 23:23:54 +0100
Subject: [PATCH] Add libgnu.la to GINT_LDADD if replacing strerror

If REPLACE_STRERROR is 1, clexer.l will try to use rpl_strerror, but
since it is not linked against gnulib, this gives an unresolved symbol
error.

* configure.ac: When building gint and strerror is to be replaced with
rpl_strerror, add libgnu.la to GINT_LDADD.
---
 configure.ac | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configure.ac b/configure.ac
index d473f80..7d7e4fa 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1174,6 +1174,9 @@ GINT_INIT([gint],[1.8 with-guile],
LIBMU_SCM_DEPS='${MU_LIB_MBOX} ${MU_LIB_IMAP} ${MU_LIB_POP} ${MU_LIB_MH} ${MU_LIB_MAILDIR} ${MU_LIB_MAILER}'
MU_GUILE_SIEVE_MOD_DIR='$(GUILE_SITE)/$(PACKAGE)/sieve-modules'
GINT_INCLUDES='${MU_APP_COMMON_INCLUDES}'
+   if test $REPLACE_STRERROR = 1; then
+ GINT_LDADD='${top_builddir}/lib/gnu/libgnu.la'
+   fi
   ],[useguile=no])
 
 AM_CONDITIONAL([MU_COND_LIBMU_SCM],[test "$useguile" = "yes"])
-- 
2.8.1



signature.asc
Description: PGP signature

Bug#828941: licensecheck: use binwalk to parse binary blobs?

[Gianfranco Costamagna]

Source: licensecheck
Severity: wishlist
Version: 3.0.0-1

Hi, as discussed on irc, it might be useful to use binwalk (now with a Python 
library/binding),
to spot what is hidden/embedded into binary blobs, and then use the correct 
tool to search
for copyrights/licenses.

Or, as Jonas suggested on irc, use it when in --strict mode, and the parse 
failed, to let
the user know what was containing the blob, to better understand why 
licensecheck failed to parse it.

Pabs suggested hachoir tool


cheers,

Gianfranco

Bug#828087: Bug #828087

[Julien Aubin]

Hi

I tested with jessie-backports (they suggested from the ML to file a bug).

When kernel 4.6 is combined with package xserver-xorg-video-intel version
2.99.917 the bug occurs. Now if it is combined with driver 2.21 from stable
it does not happen.

So we have two options :
- either the xorg driver is buggy
- either the xorg driver version 2.99.917 calls a buggy code in kernel
which causes the freeze.

Unfortunately I cannot use a non bpo kernel on that hardware as it is too
recent.
Here's the complete trace I got :

[  136.822571] [drm] stuck on blitter ring
[  136.828874] [drm] GPU HANG: ecode 8:0:0xfffe, in kwin [2022],
reason: Ring hung, action: reset
[  136.828879] [drm] GPU hangs can indicate a bug anywhere in the entire
gfx stack, including userspace.
[  136.828881] [drm] Please file a _new_ bug report on bugs.freedesktop.org
against DRI -> DRM/Intel
[  136.828882] [drm] drm/i915 developers can then reassign to the right
component if it's not a kernel issue.
[  136.828884] [drm] The gpu crash dump is required to analyze gpu hangs,
so please always attach it.
[  136.828885] [drm] GPU crash dump saved to /sys/class/drm/card0/error
[  136.830980] drm/i915: Resetting chip after gpu hang
[  144.822723] [drm] stuck on render ring
[  144.828797] [drm] GPU HANG: ecode 8:0:0xfffe, in Xorg [1803],
reason: Ring hung, action: reset
[  144.828828] [ cut here ]
[  144.828877] WARNING: CPU: 0 PID: 43 at
/build/linux-9LouV5/linux-4.6.1/drivers/gpu/drm/i915/intel_display.c:11384
intel_mmio_flip_work_func+0x464/0x490 [i915]
[  144.828883] WARN_ON(__i915_wait_request(mmio_flip->req,
mmio_flip->crtc->reset_counter, false, ((void *)0),
&mmio_flip->i915->rps.mmioflips))
[  144.828883] Modules linked in: bnep(E) act_police(E) cls_basic(E)
cls_flow(E) cls_fw(E) cls_u32(E) sch_fq_codel(E) sch_tbf(E) sch_prio(E)
sch_htb(E) sch_hfsc(E) sch_ingress(E) sch_sfq(E) xt_CHECKSUM(E)
xt_nfacct(E) nfnetlink_acct(E) ipt_rpfilter(E) xt_statistic(E) xt_CT(E)
nf_log_ipv4(E) nf_log_common(E) xt_connlimit(E) xt_realm(E) xt_addrtype(E)
xt_comment(E) xt_recent(E) xt_nat(E) ipt_REJECT(E) nf_reject_ipv4(E)
ipt_MASQUERADE(E) nf_nat_masquerade_ipv4(E) ipt_ECN(E) ipt_CLUSTERIP(E)
ipt_ah(E) xt_set(E) ip_set(E) xt_LOG(E) nf_nat_tftp(E) nf_nat_snmp_basic(E)
nf_conntrack_snmp(E) nf_nat_sip(E) nf_nat_pptp(E) nf_nat_proto_gre(E)
nf_nat_irc(E) nf_nat_h323(E) nf_nat_ftp(E) nf_nat_amanda(E) ts_kmp(E)
nf_conntrack_amanda(E) nf_conntrack_sane(E) nf_conntrack_tftp(E)
nf_conntrack_sip(E) nf_conntrack_proto_udplite(E)
[  144.828934]  nf_conntrack_proto_sctp(E) nf_conntrack_pptp(E)
nf_conntrack_proto_gre(E) nf_conntrack_netlink(E)
nf_conntrack_netbios_ns(E) nf_conntrack_broadcast(E) nf_conntrack_irc(E)
nf_conntrack_h323(E) nf_conntrack_ftp(E) xt_TPROXY(E) nf_defrag_ipv6(E)
xt_time(E) xt_TCPMSS(E) xt_tcpmss(E) xt_sctp(E) xt_policy(E) xt_pkttype(E)
xt_physdev(E) br_netfilter(E) bridge(E) stp(E) llc(E) xt_owner(E)
xt_NFQUEUE(E) xt_NFLOG(E) nfnetlink_log(E) xt_multiport(E) xt_mark(E)
xt_mac(E) xt_limit(E) xt_length(E) xt_iprange(E) xt_helper(E)
xt_hashlimit(E) xt_DSCP(E) xt_dscp(E) xt_dccp(E) xt_conntrack(E)
xt_connmark(E) xt_CLASSIFY(E) xt_AUDIT(E) xt_tcpudp(E) xt_state(E)
iptable_raw(E) iptable_nat(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack_ipv4(E)
nf_defrag_ipv4(E) nf_conntrack(E) iptable_mangle(E) nfnetlink(E) nfsd(E)
[  144.828977]  auth_rpcgss(E) nfs_acl(E) nfs(E) lockd(E) grace(E)
fscache(E) sunrpc(E) iptable_filter(E) ip_tables(E) x_tables(E) nls_utf8(E)
snd_hda_codec_hdmi(E) nls_cp437(E) vfat(E) fat(E) snd_hda_codec_realtek(E)
snd_hda_codec_generic(E) joydev(E) intel_rapl(E) btusb(E)
intel_powerclamp(E) btrtl(E) i915(E) coretemp(E) kvm_intel(E) arc4(E)
kvm(E) evdev(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) iwlmvm(E)
mac80211(E)
[  144.829038] [drm:i915_set_reset_status [i915]] *ERROR* gpu hanging too
fast, banning!
[  144.829041]  iTCO_wdt(E) iTCO_vendor_support(E) ir_lirc_codec(E)
drm_kms_helper(E) iwlwifi(E) ghash_clmulni_intel(E) lirc_dev(E) drm(E)
dw_dmac(E) hmac(E) drbg(E) ansi_cprng(E) battery(E) snd_intel_sst_acpi(E)
aesni_intel(E) snd_intel_sst_core(E) aes_x86_64(E) lrw(E) gf128mul(E)
glue_helper(E) ablk_helper(E) cryptd(E) snd_soc_sst_mfld_platform(E)
snd_soc_rt5670(E) snd_soc_sst_match(E) snd_hda_intel(E) snd_soc_rl6231(E)
pcspkr(E) snd_hda_codec(E) serio_raw(E) snd_soc_core(E) snd_hda_core(E)
cfg80211(E) rc_rc6_mce(E) ite_cir(E) rc_core(E) hci_uart(E) snd_hwdep(E)
snd_compress(E) dw_dmac_core(E) btbcm(E) btqca(E) btintel(E) video(E)
snd_pcm(E) acpi_pad(E) i2c_designware_platform(E) bluetooth(E) i2c_i801(E)
i2c_designware_pci(E) i2c_designware_core(E) soc_button_array(E) shpchp(E)
lpc_ich(E) mfd_core(E)
[  144.829088]  tpm_tis(E) tpm(E) rfkill(E) snd_timer(E) snd(E)
soundcore(E) i2c_algo_bit(E) button(E) processor(E) fuse(E) parport_pc(E)
ppdev(E) lp(E) parport(E) autofs4(E) ext4(E) crc16(E) jbd2(E) mbcache(E)
hid_microsoft(E) hid_generic(E) usbhid(E) sg(E) sd_mod(E) crc32c_intel(E)
psmouse(E) ahci(E) libah

Bug#828942: new version available (6.0.2)

[Trent W. Buck]

Source: cherrypy3
Version: 3.5.0-2
Severity: wishlist

The current version described by upstream cherrypy.org as "stable" is v6.0.2, 
commit ca684b38.

Is there a good reason for Debian to only ship 3.5.0 ?

There are a lot of changes:

$ git clone --bare https://github.com/cherrypy/cherrypy
$ cd cherrypy.git
$ git diff -w -M -C --stat 3.5.0 v6.0.2 | tail -1
 112 files changed, 2614 insertions(+), 1695 deletions(-)

Bug#828943: O: aspell-hu -- Hungarian dictionary for aspell

[Christoph Berg]

Package: wnpp
Severity: normal

The maintainer of aspell-hu, Balint Kozman, is not active anymore. The
package is up for adoption.

Package: aspell-hu
Version: 0.99.4.2-0-3
Installed-Size: 1144
Maintainer: Balint Kozman 
Architecture: all
Provides: aspell-dictionary
Depends: aspell (>= 0.60.3-3), dictionaries-common (>= 0.9.1)
Description-en: Hungarian dictionary for aspell
 This package contains Hungarian dictionaries for the aspell spell checker.
Description-md5: 31c2fc6bfb4afa2c78eca607d0c9c87e
Tag: culture::hungarian, made-of::dictionary, role::app-data, suite::gnu,
 use::checking
Section: text
Priority: optional
Filename: pool/main/a/aspell-hu/aspell-hu_0.99.4.2-0-3_all.deb
Size: 530214
MD5sum: 26e609ad89ebd8c93957d70e258e4601
SHA1: bc4c2cbfa896d4683b73276f11995b8b6f63c78d
SHA256: 4d4214fab53f236fb59daadc6d72910282a129f5dee9ade1fc3d8a073e744b54

Christoph


signature.asc
Description: PGP signature

Bug#828833: python3-magic: magic file type double encoded

[Christoph Biedl]

Mattia Rizzolo wrote...

> Can I ask you to quickly upload the fix as soon as there is a working
> py2/py3 patch?

Will do as soon as I'm confident there's a fix that does not create
new hazzle, read: I still wasn't able to reproduce the original
regression when using python2 (PR/511).

As there's some python knowledge around here this should not take
longer than a few hours.

Christoph


signature.asc
Description: Digital signature

Bug#828830: ITP: licensecheck -- simple license checker for source files

[Jonas Smedegaard]

Quoting Adam D. Barratt (2016-06-29 07:13:27)
> On Tue, 2016-06-28 at 21:21 +0200, Jonas Smedegaard wrote:
> > ...speaking of previous authoring: April 20th, 2007, you changed 
> > comments from
> > 
> >   "originally [...] from the KDE SDK"
> > 
> > to
> > 
> >   "originally [...] from the KDE SDK (by dfa...@kde.org)"
> > 
> > ...but it seems from my resurrecting old SVN commits that a) the 
> > person referenced is David Faure  (no "d" in email 
> > address), and that b) the script was not introduced by David Faure 
> > but instead by Stefan Westerfeld  (on Jan 28 
> > 2000).
> > 
> > Does it seem likely that you made a typo in the email?
> 
> It's possible. It's been rather a long time and I no longer have any 
> record of where I extracted the address from.
> 
> > Would you agree that it makes better sense to emphasize the 
> > _original_ author than the (I guess) later maintainer?
> 
> If that's the case, sure. I don't recall seeing any name other than 
> Faure's at the time however.

Thanks for your input.  And your past work, obviously. :-)

 - 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#805711: Keyboard unresponsive

[Sean Whitton]

Hello,

On Tue, Jun 28, 2016 at 12:25:29PM +0200, Amir wrote:
> Both.

Okay, so a different problem to the one I saw.  So we can't exclude the
ATI drivers.

> Hasn't xscreensaver become a security risk?

What makes you think this?

-- 
Sean Whitton

Bug#802702: CVE-2011-5325: busybox: Directory traversal via crafted tar file which contains a symlink pointing outside of the current directory

[Petter Reinholdtsen]

[Chris Lamb]
> IIRC it was deemed to be low-priority from an LTS point of view so/and
> I could not justify spending more time on it then. Happy to look again
> if there is a more urgent requirement.

Right.  It is still unsolved in stable, testing, unstable and upstream,
and the second oldest open CVE on my stable laptop (the oldest is in
ruby, and pending a stable update), so I would like to see it fixed to
reduce the number of known security problems on my machine. :)

Can not say much about the priority or urgency related to other issues,
though. :)

I've poked upstream too, and hope some solution will materialise.

-- 
Happy hacking
Petter Reinholdtsen

Bug#806591: qscintilla2: FTBFS on sparc64 due to mismatched symbols files

[John Paul Adrian Glaubitz]

Hi Scott!

On 06/29/2016 06:59 AM, Scott Kitterman wrote:
> I just looked at fixing this, but I see that the build log for the current 
> version, qscintilla2_2.9.2+dfsg-2, is not on buildd.d.o. 

This can happen if the buildd itself has trouble sending email. I have now
rescheduled the qscintilla2 package, it should be picked up by the buildds
again soonish.

> If you can provide a log with at least the symbols changes for 
> qscintilla2_2.9.2+dfsg-2, I should be able to include this in the next upload 
> in the next days.

Great. Let me know if the build log still remains inaccessible after the next
build attempt, then I'll have another look.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#828944: linux-base: [l10n:cs] Updated Czech PO debconf template translation

[Michal Simunek]

Package: linux-base
Version: 3.5
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

In attachment there is updated Czech translation of PO debconf template (cs.po)
for package linux-base, please include it.



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

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

Versions of packages linux-base depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  libuuid-perl   0.05-1+b1
ii  udev   215-17+deb8u4
ii  util-linux 2.25.2-6

linux-base recommends no packages.

linux-base suggests no packages.

-- debconf information excluded
# Czech PO debconf template translation of linux-base.
# Copyright (C) 2010 Michal Simunek 
# This file is distributed under the same license as the linux-base package.
# Michal Simunek , 2010 - 2016.
#
msgid ""
msgstr ""
"Project-Id-Version: linux-base 4.4\n"
"Report-Msgid-Bugs-To: linux-b...@packages.debian.org\n"
"POT-Creation-Date: 2016-06-06 16:37+0100\n"
"PO-Revision-Date: 2016-06-27 11:02+0200\n"
"Last-Translator: Michal Simunek \n"
"Language-Team: Czech \n"
"Language: cs\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: title
#. Description
#: ../linux-base.templates:2001
msgid "Removing ${package}"
msgstr "Odstraňuje se ${package}"

#. Type: boolean
#. Description
#: ../linux-base.templates:3001
msgid "Abort kernel removal?"
msgstr "Přerušit odstraňování jádra?"

#. Type: boolean
#. Description
#: ../linux-base.templates:3001
msgid ""
"You are running a kernel (version ${running}) and attempting to remove the "
"same version."
msgstr ""
"Pokoušíte se odstranit verzi jádra (version ${running}), která nyní běží."

#. Type: boolean
#. Description
#: ../linux-base.templates:3001
msgid ""
"This can make the system unbootable as it will remove /boot/vmlinuz-"
"${running} and all modules under the directory /lib/modules/${running}. This "
"can only be fixed with a copy of the kernel image and the corresponding "
"modules."
msgstr ""
"To může způsobit, že se nepodaří zavést systém, jelikož bude odstraněno /boot/"
"vmlinuz-${running} a všechny moduly v adresáři /lib/modules/${running}. Toto "
"je možné opravit pouze nakopírováním obrazu jádra a příslušných modulů."

#. Type: boolean
#. Description
#: ../linux-base.templates:3001
msgid ""
"It is highly recommended to abort the kernel removal unless you are prepared "
"to fix the system after removal."
msgstr ""
"Je silně doporučeno přerušit odstraňování jádra, pokud nejste připraveni "
"opravovat systém po jeho odstranění."

Bug#792787: Problem is with requested language

[Frédéric Marchal]

I just found out about this problem too.

The page is rendered correctly with Firefox 47 on Linux. It fails with 
Chromium and Konqueror on Linux. It fails with Firefox, Chrome and Opera on 
Windows.

The buffer overflow occurs when status.cgi tries to display the status message 
returned by NTP:
NTP OK: Décalage -0,01155954599 secs 

The message obviously contains an accent.

How does Firefox on Linux succeed when all the others fail?

It is due to the Accepted-Language header. Firefox send: "en-US,en;q=0.8,fr-
BE;q=0.5,fr;q=0.3" when Chromium, for instance, send "en-
US,en;q=0.8,fr;q=0.6".

If I replace "fr" by "fr-BE" in the Chromium header, it succeeds. If I replace 
it with "fr-FR" (the locale is not defined on the nagios server), the buffer 
overflow occurs and the status page is truncated.

The problem is not with an accent I inserted in a configuration file. I can't 
apply the suggestion from Christian Erpelding 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792787#10) as I have no 
control over the string returned 
by the NTP plugin.

It occurs with nagios3 3.5.1.dfsg-2+b1.

Bug#796633: Progress

[Wouter Verhelst]

Hi,

I did some work on this at debcamp, and Tollef helped me out a bit, but
it looks like we stumbled into some missing functionality in systemd.
Issue request filed at https://github.com/systemd/systemd/issues/3627;
waiting for systemd upstream now.

Regards,

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#828945: strongswan: FTBFS in testing (configure fails)

[Santiago Vila]

Package: src:strongswan
Version: 5.4.0-2
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious

Dear maintainer:

This package currently fails to build in stretch:


[...]
configure: exit 1
dh_auto_configure: ./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=${prefix}/include --mandir
=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc 
--localstatedir=/var --disable-silent-r
ules --libdir=${prefix}/lib/x86_64-linux-gnu 
--libexecdir=${prefix}/lib/x86_64-linux-gnu --disable-maintainer
-mode --disable-dependency-tracking --libdir=/usr/lib --libexecdir=/usr/lib 
--enable-ldap --enable-curl --ena
ble-pkcs11 --enable-openssl --enable-agent --enable-ctr --enable-ccm 
--enable-gcm --enable-addrblock --enable
-eap-radius --enable-eap-identity --enable-eap-md5 --enable-eap-gtc 
--enable-eap-aka --enable-eap-mschapv2 --
enable-eap-tls --enable-eap-ttls --enable-eap-tnc --enable-ha --enable-led 
--enable-gcrypt --enable-test-vect
ors --enable-xauth-eap --enable-xauth-pam --enable-cmd --enable-certexpire 
--enable-lookip --enable-error-not
ify --enable-unity --disable-blowfish --disable-des --enable-rdrand 
--enable-aesni --enable-nm --with-capabil
ities=libcap --enable-farp --enable-dhcp --enable-af-alg --enable-connmark 
--enable-systemd --enable-swanctl 
returned exit code 1
debian/rules:68: recipe for target 'override_dh_auto_configure' failed


A full build log is available here:

https://tests.reproducible-builds.org/debian/rbuild/testing/amd64/strongswan_5.4.0-2.rbuild.log

Thanks.

Bug#828946: krb5: FTBFS in testing (LaTeX Error: File `iftex.sty' not found)

[Santiago Vila]

Package: src:krb5
Version: 1.14.2+dfsg-1
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious

Dear maintainer:

This package currently fails to build in stretch:


[...]
sphinx-build  -t pathsubs -b latex -q rst_composite pdf_subst
mv pdf_subst/Makefile pdf_subst/GMakefile
(cd pdf_subst && \
 for i in admin appdev basic build plugindev user; do \
texfile=`echo ${i}.tex` && \
idxfile=`echo ${i}.idx` && \
pdflatex  $texfile && \
pdflatex  $texfile && \
makeindex -s python.ist $idxfile || true; \
pdflatex  $texfile && \
pdflatex  $texfile; done && \
 rm -f *.dvi *.log *.ind *.aux *.toc *.syn *.idx *.out *.ilg *.pla \
)
This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) 
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./admin.tex
LaTeX2e <2016/03/31> patch level 1
Babel <3.9r> and hyphenation patterns for 3 language(s) loaded.
(./sphinxmanual.cls
Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual)
(/usr/share/texlive/texmf-dist/tex/latex/base/report.cls
Document Class: report 2014/09/29 v1.4h Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)))

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


A full build log is available here:

https://tests.reproducible-builds.org/debian/rbuild/testing/amd64/krb5_1.14.2+dfsg-1.rbuild.log

Thanks.

Bug#828947: Openbox doesn't properly manage Calibre main window

[Jeffrey H. Ingber]

Package: Openbox
Version: 3.6.1-2

Running Calibre 2.55.0+dfsg-1+b2 under Openbox 3.6.1-2 under Debian Stretch 
results in a Calibre window with no borders or title bar - ie. essentially 
"unmanaged" by Openbox.  There is no obvious way to exit the application or 
move it's main window around the screen.

I have tried Calibre 2.60 from the official Calibre site with the same results.

Sometimes, if ~/.config/calibre is removed, the next execution of Calibre will 
result in an application that is properly handled by the window manager.  On 
subsequent executions (usually one or two) it will revert back to an 
"unmanaged" state - ie. no title bar or window borders.

I am using Debian GNU/Linux Stretch, with a custom 4.5.7 kernel (to address 
Baytrail issues) and libc6 2.22-11 amd64.

Bug#828944: linux-base: [l10n:cs] Updated Czech PO debconf template translation

[Salvatore Bonaccorso]

Hi Michal,

On Wed, Jun 29, 2016 at 10:53:52AM +0200, Michal Simunek wrote:
> Package: linux-base
> Version: 3.5
> Severity: wishlist
> Tags: l10n patch
> 
> Dear Maintainer,
> 
> In attachment there is updated Czech translation of PO debconf
> template (cs.po) for package linux-base, please include it.

Thanks for your update, it is commited to git.

Regards,
Salvatore

Bug#828828: libfiu0: broken symlink /usr/lib/libfiu.so

[Jakub Wilk]

Control: found -1 0.94-6

It's still broken:

$ dpkg -L libfiu0 | xargs -n1 file | grep broken
/usr/lib/libfiu.so: broken symbolic link to 
/build/libfiu-wc7kxU/libfiu-0.94/debian/tmp/usr/lib/libfiu.so.0.94

--
Jakub Wilk

Bug#828939: RM: cyrus-imapd-2.4 -- ROM; superseded by src:cyrus-imapd

[Ondřej Surý]

I already did. Thanks.


On 29 June 2016 10:47:28 Scott Kitterman  wrote:

The only tool we have closes them, so I'd suggest you go and reassign those 
that should be reassigned.


Scott K

On June 29, 2016 2:36:45 AM EDT, "Ondřej Surý"  wrote:

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear ftp-masters,

please remove the leftovers from src:cyrus-imapd-2.4 that got
superseded by src:cyrus-imapd.

The bugs can be reassigned to src:cyrus-imapd package (if you have a
tool that does this automatically - if not, please let me know, I will
handle this by hand).

Thank you very much,
Ondřej

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJXc2x9XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMEI5MzNEODBGQ0UzRDk4MUEyRDM4RkIw
Qzk5QjcwRUY0RkNCQjA3AAoJEAyZtw70/LsHdFoP/iGT6FarAh/jBZXS042c6KJh
K/y1SFQCl15bMgJLlSa4679Ktgawv5YSV9m8ebNVQlji0TSO1su6GA2jlA6qFhHI
XNC3aBeeiJPCPbUNOsd7eBvAERlFM5H3RrvOGwBYh5AlqKtoSkSiRKrJpaisYq3o
b0/5n/KCOVREizbxxHkZZf29FcZdSMSiMTJVzi+atehFiGDLUujUPevG7WxJqcLI
yzs8UpGnwx3KXSOvQ3kY/1BAhwCIzHu4Z3BnQI3DkIE8olMgKXHSodNLfomcIMUJ
JQZDyWt5T5CGXHJSqOQkuVkpImfUaXRQHb5H/4U4TrOmOPOM3dJYRqJvfJT5rJyW
xJaU0+cTp4dy+e+CA3ZfAzDpTRwh2TY3thPtX8xKAfS/zFvxfr3U4ffo3YKKe3Hz
BZQXy/OvLcOLjNfg6FhWspA+T6NxCc3Niru/6wez7bpSiGPoyyle4qcaa455xGfK
ewnEzFkiSskF3nEjO4Mac0iQt4OVjSCsGjnpD5XW1NNi8LfHKKTu8LXfiJy2kzhI
9+M7BN0tYTXPP1/ZZrCoigDY0Cku9EU/H0Lz7zQSdLWgpyBIG//evTxVaAfY4qza
8FJTj3L96sAcS0fPvN90dZszE8wgXBATz+uptL934ohnt/JWu6Y/Pu8if0EIStue
5VznxbGnCROIAWqGcimX
=/tkL
-END PGP SIGNATURE-

Bug#826027: (no subject)

[Anatoly A. Kazantsev]

This was fixed in the recent commit:
https://github.com/wummel/linkchecker/commit/c2ce810c3fb00b895a841a7be6b2e78c64e7b042

Current version in testing is unusable, so it needs some attention.

-- 
Regards,
Anatoly

Bug#828948: licensecheck: use binwalk to parse binary blobs?

[Gianfranco Costamagna]

Source: licensecheck
Severity: wishlist
Version: 3.0.0-1

Hi, as discussed on irc, it might be useful to use binwalk (now with a Python 
library/binding),
to spot what is hidden/embedded into binary blobs, and then use the correct 
tool to search
for copyrights/licenses.

Or, as Jonas suggested on irc, use it when in --strict mode, and the parse 
failed, to let
the user know what was containing the blob, to better understand why 
licensecheck failed to parse it.

Pabs suggested hachoir tool


cheers,

Gianfranco

Bug#828945: [Pkg-swan-devel] Bug#828945: strongswan: FTBFS in testing (configure fails)

[Yves-Alexis Perez]

On mer., 2016-06-29 at 09:00 +, Santiago Vila wrote:
> This package currently fails to build in stretch:

Did you try a manual build? It builds fine in sid, and the log shows:

checking for systemd system unit directory... configure: error: not found (try
--with-systemdsystemunitdir)

which puzzles me, actually.

Regards,
-- 

Yves-Alexis

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

Bug#828949: orthanc-webviewer: "better" suggestion for cache location

[Karsten Hilbert]

Package: orthanc-webviewer
Version: 2.1-1+b1
Severity: minor

Hi,

the (commented out) default provided for the cache path is

"CachePath" : "/tmp/WebViewerCache",

Howevever, "WebViewerCache" is quite generic and might clash with other
packages. I suggest setting the (commented out) default to

"CachePath" : "/tmp/OrthancWebViewerCache",

(or some such) instead.

Thanks,
Karsten

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

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

Versions of packages orthanc-webviewer depends on:
ii  libboost-filesystem1.58.0  1.58.0+dfsg-5+b1
ii  libboost-locale1.58.0  1.58.0+dfsg-5+b1
ii  libboost-regex1.58.0   1.58.0+dfsg-5+b1
ii  libboost-system1.58.0  1.58.0+dfsg-5+b1
ii  libboost-thread1.58.0  1.58.0+dfsg-5+b1
ii  libc6  2.22-11
ii  libgcc11:6.1.1-7
ii  libgdcm2.6 2.6.3-6
ii  libjsoncpp11.7.2-1
ii  libsqlite3-0   3.13.0-1
ii  libstdc++6 6.1.1-7
ii  libuuid1   2.28-5
ii  orthanc1.1.0+dfsg-1

orthanc-webviewer recommends no packages.

orthanc-webviewer suggests no packages.

-- Configuration Files:
/etc/orthanc/webviewer.json changed:
{
  /**
   * The following options control the configuration of the Orthanc
   * Web Viewer plugin.
   **/
  "WebViewer" : {
  /**
   * The location of the cache of the Web viewer. By default, the
   * cache is located inside the storage directory of Orthanc.
   **/
  // "CachePath" : "/tmp/WebViewerCache",
  "CachePath" : "/tmp/OrthancWebViewerCache",
  
  /**
   * The maximum size for the cached images, in megabytes. By
   * default, a cache of 100 MB is used.
   **/
  // "CacheSize" : 10,
  /**
   * The number of threads that are used by the plugin to decode
   * the DICOM images.
   **/
  // "Threads" : 4
  "Threads" : 2
  }
}


-- no debconf information

Bug#828952: mlt: FTBFS with rtaudio 4.1.2

[Jaromír Mikeš]

Package: mlt
Version: 6.2.0
Severity: important
User: pkg-multimedia-maintain...@lists.alioth.debian.org
Usertags: rtaudio 4.1.2

Dear Maintainer,

your package fails to build with the upcoming rtaudio 4.1.2

Location of header files changed from include to include/rtaudio so some easy 
patching will be needed.
Otherwise it builds fine.


Best regards,
mira

Bug#828951: jacktrip: FTBFS with rtaudio 4.1.2

[Jaromír Mikeš]

Package: jacktrip
Version: 4.5.2+dfsg0-2
Severity: important
User: pkg-multimedia-maintain...@lists.alioth.debian.org
Usertags: rtaudio 4.1.2

Dear Maintainer,

your package fails to build with the upcoming rtaudio 4.1.2

Location of header files changed from include to include/rtaudio so some easy 
patching will be needed.
Otherwise it builds fine.


Best regards,
mira

Bug#828950: stk: FTBFS with rtaudio 4.1.2

[Jaromír Mikeš]

Package: stk
Version: 4.5.2+dfsg0-2
Severity: important
User: pkg-multimedia-maintain...@lists.alioth.debian.org
Usertags: rtaudio 4.1.2

Dear Maintainer,

your package fails to build with the upcoming rtaudio 4.1.2

Location of header files changed from include to include/rtaudio so some easy 
patching will be needed.
Otherwise it builds fine.


Best regards,
mira

Bug#828953: mxt-app FTBFS on 32bit architectures (i386, mips) on testing

[Daniel Knezevic]

Package: mxt-app
Version: 1.27-1
Severity: serious
Tags: sid + patch
Justification: FTBFS
User: debian-m...@lists.debian.org
Usertags: mips-patch

Hi,

Package mxt-app FTBFS on 32bit architectures with following error:
make --no-print-directory check-TESTS
FAIL: run-unit-tests

   mxt-app 1.27: ./test-suite.log


# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: run-unit-tests


[==] Running 1 test(s).
[ RUN  ] mxt_convert_hex_test
0x1a != 0
src/test/test_utilfuncs.c:65: error: Failure!

[  FAILED  ] mxt_convert_hex_test
[==] 1 test(s) run.
[  PASSED  ] 0 test(s).
[  FAILED  ] 1 test(s), listed below:
[  FAILED  ] mxt_convert_hex_test

 1 FAILED TEST(S)
FAIL run-unit-tests (exit status: 1)

build logs:
https://buildd.debian.org/status/fetch.php?pkg=mxt-app&arch=mips&ver=1.27-1&stamp=1465527085
https://buildd.debian.org/status/fetch.php?pkg=mxt-app&arch=mipsel&ver=1.27-1&stamp=1465521348
https://buildd.debian.org/status/fetch.php?pkg=mxt-app&arch=i386&ver=1.27-1&stamp=1464327106

The test is failing because of the undefined behaviour of strcpy() when dest 
buffer is smaller than src buffer.
Bug is in mxt_convert_hex_test function in /src/test/test_utilfuncs.c file.
Destination buffer (hex) is 4 bytes, and on strcpy(hex, "0FAB"); there is no 
space left to copy the null terminator.

The attached patch resolves buffer owerflow.
Patch is tested on i386, amd64, mips, mipsel, mips64el.

Earlier version was successfully built on 32bit architectures because there 
were no tests.

Thank you!

Regards,
Daniel
--- mxt-app-1.27.orig/src/test/test_utilfuncs.c
+++ mxt-app-1.27/src/test/test_utilfuncs.c
@@ -43,7 +43,7 @@ void mxt_convert_hex_test(void **state)
 {
   /* test setup */
   uint8_t databuf[5] = {0};
-  char hex[4];
+  char hex[5];
   uint16_t count;
   int ret;

Bug#828954: stk: FTBFS with rtmidi 2.1.1

[Jaromír Mikeš]

Package: stk
Version: 4.5.2+dfsg0-2
Severity: important
User: pkg-multimedia-maintain...@lists.alioth.debian.org
Usertags: rtmidi 2.1.1

Dear Maintainer,

your package fails to build with the upcoming rtmidi2.1.1

Location of header files changed from include to include/rtmidi so some easy 
patching will be needed.
Otherwise it builds fine.


Best regards,
mira

Bug#824967: RFS: budgie-desktop/10.2.5-1 [ITP]

[Gianfranco Costamagna]

control: owner -1 !
control: tags-1 moreinfo

Hi,

control:

description should be extended a lot
some build-dependencies might be useless, did you check that? e.g. dh-buildinfo
intltool (note: I'm not checking the above)

"python2.7" <-- what?

I don't see any Python script here, and I see only
./panel/manager.vala:engine.enable_loader("python3");



rules:
please use the new dh sequencer.

install files:
usr/lib/libbudgietheme*.0

this might be something like:
usr/lib/libbudgietheme*.so.*

maybe?

lintian overrides? please remove and fix bugs, or comment about why

you think lintian is wrong

this is all for a first review.

G.

Bug#828955: giada: FTBFS with rtmidi 2.1.1

[Jaromír Mikeš]

Package: giada
Version: 0.12.2~dfsg1-1
Severity: important
User: pkg-multimedia-maintain...@lists.alioth.debian.org
Usertags: rtmidi 2.1.1

Dear Maintainer,

your package fails to build with the upcoming rtmidi2.1.1

Location of header files changed from include to include/rtmidi so some easy 
patching will be needed.
Otherwise it builds fine.


Best regards,
mira

Bug#828956: midisnoop: FTBFS with rtmidi 2.1.1

[Jaromír Mikeš]

Package: midisnoop
Version: 0.1.2~repack0-3
Severity: important
User: pkg-multimedia-maintain...@lists.alioth.debian.org
Usertags: rtmidi 2.1.1

Dear Maintainer,

your package fails to build with the upcoming rtmidi2.1.1

Location of header files changed from include to include/rtmidi so some easy 
patching will be needed.
Otherwise it builds fine.


Best regards,
mira

Bug#828957: milkytracker: FTBFS with rtmidi 2.1.1

[Jaromír Mikeš]

Package: milkytracker
Version: 0.90.86+dfsg-1
Severity: important
User: pkg-multimedia-maintain...@lists.alioth.debian.org
Usertags: rtmidi 2.1.1

Dear Maintainer,

your package fails to build with the upcoming rtmidi2.1.1

Location of header files changed from include to include/rtmidi so some easy 
patching will be needed.
Otherwise it builds fine.


Best regards,
mira

Bug#828959: assertj-core: FTBFS: Could not resolve dependencies for project org.assertj:assertj-core:bundle:2.3.0

[Chris Lamb]

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

Dear Maintainer,

assertj-core fails to build from source in unstable/amd64:

  [..]

  Adding debian:CA_Disig_Root_R1.pem
  Adding debian:CA_Disig_Root_R2.pem
  Adding debian:CA_WoSign_ECC_Root.pem
  Adding debian:CFCA_EV_ROOT.pem
  Adding debian:CNNIC_ROOT.pem
  Adding debian:COMODO_Certification_Authority.pem
  Adding debian:COMODO_ECC_Certification_Authority.pem
  Adding debian:COMODO_RSA_Certification_Authority.pem
  Adding debian:Camerfirma_Chambers_of_Commerce_Root.pem
  Adding debian:Camerfirma_Global_Chambersign_Root.pem
  Adding debian:Certification_Authority_of_WoSign_G2.pem
  Adding debian:Certigna.pem
  Adding debian:Certinomis_-_Autorité_Racine.pem
  Adding debian:Certinomis_-_Root_CA.pem
  Adding debian:Certplus_Class_2_Primary_CA.pem
  Adding debian:Certum_Root_CA.pem
  Adding debian:Certum_Trusted_Network_CA.pem
  Adding debian:Chambers_of_Commerce_Root_-_2008.pem
  Adding 
debian:China_Internet_Network_Information_Center_EV_Certificates_Root.pem
  Adding debian:ComSign_CA.pem
  Adding debian:Comodo_AAA_Services_root.pem
  Adding debian:Comodo_Secure_Services_root.pem
  Adding debian:Comodo_Trusted_Services_root.pem
  Adding debian:Cybertrust_Global_Root.pem
  Adding debian:D-TRUST_Root_Class_3_CA_2_2009.pem
  Adding debian:D-TRUST_Root_Class_3_CA_2_EV_2009.pem
  Adding debian:DST_ACES_CA_X6.pem
  Adding debian:DST_Root_CA_X3.pem
  Adding debian:Deutsche_Telekom_Root_CA_2.pem
  Adding debian:DigiCert_Assured_ID_Root_CA.pem
  Adding debian:DigiCert_Assured_ID_Root_G2.pem
  Adding debian:DigiCert_Assured_ID_Root_G3.pem
  Adding debian:DigiCert_Global_Root_CA.pem
  Adding debian:DigiCert_Global_Root_G2.pem
  Adding debian:DigiCert_Global_Root_G3.pem
  Adding debian:DigiCert_High_Assurance_EV_Root_CA.pem
  Adding debian:DigiCert_Trusted_Root_G4.pem
  Adding debian:E-Tugra_Certification_Authority.pem
  Adding debian:EBG_Elektronik_Sertifika_Hizmet_Sağlayıcısı.pem
  Adding debian:EC-ACC.pem
  Adding debian:EE_Certification_Centre_Root_CA.pem
  Adding debian:Entrust.net_Premium_2048_Secure_Server_CA.pem
  Adding debian:Entrust_Root_Certification_Authority.pem
  Adding debian:Entrust_Root_Certification_Authority_-_EC1.pem
  Adding debian:Entrust_Root_Certification_Authority_-_G2.pem
  Adding debian:Equifax_Secure_CA.pem
  Adding debian:Equifax_Secure_Global_eBusiness_CA.pem
  Adding debian:Equifax_Secure_eBusiness_CA_1.pem
  Adding debian:GeoTrust_Global_CA.pem
  Adding debian:GeoTrust_Global_CA_2.pem
  Adding debian:GeoTrust_Primary_Certification_Authority.pem
  Adding debian:GeoTrust_Primary_Certification_Authority_-_G2.pem
  Adding debian:GeoTrust_Primary_Certification_Authority_-_G3.pem
  Adding debian:GeoTrust_Universal_CA.pem
  Adding debian:GeoTrust_Universal_CA_2.pem
  Adding debian:GlobalSign_ECC_Root_CA_-_R4.pem
  Adding debian:GlobalSign_ECC_Root_CA_-_R5.pem
  Adding debian:GlobalSign_Root_CA.pem
  Adding debian:GlobalSign_Root_CA_-_R2.pem
  Adding debian:GlobalSign_Root_CA_-_R3.pem
  Adding debian:Global_Chambersign_Root_-_2008.pem
  Adding debian:Go_Daddy_Class_2_CA.pem
  Adding debian:Go_Daddy_Root_Certificate_Authority_-_G2.pem
  Adding debian:Hellenic_Academic_and_Research_Institutions_RootCA_2011.pem
  Adding debian:Hongkong_Post_Root_CA_1.pem
  Adding debian:IGC_A.pem
  Adding debian:IdenTrust_Commercial_Root_CA_1.pem
  Adding debian:IdenTrust_Public_Sector_Root_CA_1.pem
  Adding debian:Izenpe.com.pem
  Adding debian:Juur-SK.pem
  Adding debian:Microsec_e-Szigno_Root_CA.pem
  Adding debian:Microsec_e-Szigno_Root_CA_2009.pem
  Adding debian:NetLock_Arany_=Class_Gold=_Főtanúsítvány.pem
  Adding debian:NetLock_Business_=Class_B=_Root.pem
  Adding debian:NetLock_Express_=Class_C=_Root.pem
  Adding debian:NetLock_Notary_=Class_A=_Root.pem
  Adding debian:NetLock_Qualified_=Class_QA=_Root.pem
  Adding debian:Network_Solutions_Certificate_Authority.pem
  Adding debian:OISTE_WISeKey_Global_Root_GA_CA.pem
  Adding debian:OISTE_WISeKey_Global_Root_GB_CA.pem
  Adding debian:PSCProcert.pem
  Adding debian:QuoVadis_Root_CA.pem
  Adding debian:QuoVadis_Root_CA_1_G3.pem
  Adding debian:QuoVadis_Root_CA_2.pem
  Adding debian:QuoVadis_Root_CA_2_G3.pem
  Adding debian:QuoVadis_Root_CA_3.pem
  Adding debian:QuoVadis_Root_CA_3_G3.pem
  Adding debian:RSA_Security_2048_v3.pem
  Adding debian:Root_CA_Generalitat_Valenciana.pem
  Adding debian:S-TRUST_Authentication_and_Encryption_Root_CA_2005_PN.pem
  Adding debian:S-TRUST_Universal_Root_CA.pem
  Adding debian:SecureSign_RootCA11.pem
  Adding debian:SecureTrust_CA.pem
  Adding debian:Secure_Global_CA.pem
  Adding debian:Security_Communication_EV_RootCA1.pem
  Adding debian:Security_Communication_RootCA2.pem
  Adding debian:Security_Communication_Root_CA.pem
  Adding debian:Sonera_Class_1_Root_CA.pem
  Adding debian:Sonera_Class_2_Roo

Bug#828958: android-platform-dalvik: FTBFS: /usr/bin/ld: cannot find -llog

[Chris Lamb]

Source: android-platform-dalvik
Version: 6.0.1+r16-4
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

android-platform-dalvik fails to build from source in unstable/amd64:

  [..]

  Adding debian:Staat_der_Nederlanden_EV_Root_CA.pem
  Adding debian:Staat_der_Nederlanden_Root_CA.pem
  Adding debian:Staat_der_Nederlanden_Root_CA_-_G2.pem
  Adding debian:Staat_der_Nederlanden_Root_CA_-_G3.pem
  Adding debian:Starfield_Class_2_CA.pem
  Adding debian:Starfield_Root_Certificate_Authority_-_G2.pem
  Adding debian:Starfield_Services_Root_Certificate_Authority_-_G2.pem
  Adding debian:StartCom_Certification_Authority.pem
  Adding debian:StartCom_Certification_Authority_2.pem
  Adding debian:StartCom_Certification_Authority_G2.pem
  Adding debian:SwissSign_Gold_CA_-_G2.pem
  Adding debian:SwissSign_Platinum_CA_-_G2.pem
  Adding debian:SwissSign_Silver_CA_-_G2.pem
  Adding debian:Swisscom_Root_CA_1.pem
  Adding debian:Swisscom_Root_CA_2.pem
  Adding debian:Swisscom_Root_EV_CA_2.pem
  Adding debian:T-TeleSec_GlobalRoot_Class_2.pem
  Adding debian:T-TeleSec_GlobalRoot_Class_3.pem
  Adding debian:TC_TrustCenter_Class_3_CA_II.pem
  Adding debian:TURKTRUST_Certificate_Services_Provider_Root_2007.pem
  Adding debian:TWCA_Global_Root_CA.pem
  Adding debian:TWCA_Root_Certification_Authority.pem
  Adding debian:Taiwan_GRCA.pem
  Adding debian:TeliaSonera_Root_CA_v1.pem
  Adding debian:Trustis_FPS_Root_CA.pem
  Adding debian:TÜBİTAK_UEKAE_Kök_Sertifika_Hizmet_Sağlayıcısı_-_Sürüm_3.pem
  Adding debian:TÜRKTRUST_Elektronik_Sertifika_Hizmet_Sağlayıcısı_H5.pem
  Adding debian:TÜRKTRUST_Elektronik_Sertifika_Hizmet_Sağlayıcısı_H6.pem
  Adding debian:USERTrust_ECC_Certification_Authority.pem
  Adding debian:USERTrust_RSA_Certification_Authority.pem
  Adding debian:UTN_USERFirst_Email_Root_CA.pem
  Adding debian:UTN_USERFirst_Hardware_Root_CA.pem
  Adding debian:VeriSign_Class_3_Public_Primary_Certification_Authority_-_G4.pem
  Adding debian:VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.pem
  Adding debian:VeriSign_Universal_Root_Certification_Authority.pem
  Adding debian:Verisign_Class_1_Public_Primary_Certification_Authority.pem
  Adding debian:Verisign_Class_1_Public_Primary_Certification_Authority_-_G2.pem
  Adding debian:Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem
  Adding debian:Verisign_Class_2_Public_Primary_Certification_Authority_-_G2.pem
  Adding debian:Verisign_Class_2_Public_Primary_Certification_Authority_-_G3.pem
  Adding debian:Verisign_Class_3_Public_Primary_Certification_Authority.pem
  Adding debian:Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.pem
  Adding debian:Verisign_Class_3_Public_Primary_Certification_Authority_-_G3.pem
  Adding debian:Verisign_Class_3_Public_Primary_Certification_Authority_2.pem
  Adding debian:Visa_eCommerce_Root.pem
  Adding debian:WellsSecure_Public_Root_Certificate_Authority.pem
  Adding debian:WoSign.pem
  Adding debian:WoSign_China.pem
  Adding debian:XRamp_Global_CA_Root.pem
  Adding debian:certSIGN_ROOT_CA.pem
  Adding debian:ePKI_Root_Certification_Authority.pem
  Adding debian:thawte_Primary_Root_CA.pem
  Adding debian:thawte_Primary_Root_CA_-_G2.pem
  Adding debian:thawte_Primary_Root_CA_-_G3.pem
  done.
  done.
  Setting up openjdk-8-jre-headless:amd64 (8u91-b14-3) ...
  update-alternatives: using /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/rmid to 
provide /usr/bin/rmid (rmid) in auto mode
  update-alternatives: using /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java to 
provide /usr/bin/java (java) in auto mode
  update-alternatives: using /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/keytool 
to provide /usr/bin/keytool (keytool) in auto mode
  update-alternatives: using /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/jjs to 
provide /usr/bin/jjs (jjs) in auto mode
  update-alternatives: using /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/pack200 
to provide /usr/bin/pack200 (pack200) in auto mode
  update-alternatives: using 
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/rmiregistry to provide 
/usr/bin/rmiregistry (rmiregistry) in auto mode
  update-alternatives: using 
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/unpack200 to provide 
/usr/bin/unpack200 (unpack200) in auto mode
  update-alternatives: using /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/orbd to 
provide /usr/bin/orbd (orbd) in auto mode
  update-alternatives: using 
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/servertool to provide 
/usr/bin/servertool (servertool) in auto mode
  update-alternatives: using 
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/tnameserv to provide 
/usr/bin/tnameserv (tnameserv) in auto mode
  update-alternatives: using /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/jexec to 
provide /usr/bin/jexec (jexec) in auto mode
  Setting up default-jre-headless (2:1.8-57) ...
  Setting up openjdk-8-jre:amd64 (8u91-b14-3) ...
  up

Bug#828187: transition: rtmidi

[Jaromír Mikeš]

-- Původní zpráva --
Od: Emilio Pozuelo Monfort 
Komu: Jaromír Mikeš , 828...@bugs.debian.org
Datum: 28. 6. 2016 10:52:18
Předmět: Re: Bug#828187: transition: rtmidi

"Control: tags -1 confirmed

On 27/06/16 18:44, Jaromír Mikeš wrote:
> On 25/06/16 23:49, Jaromír Mikeš wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>> Hi,
>> new upstream rtmidi bumps SONAME, so we need to transition.
>>
>> Direct reverse dependencies are:
>>
>> stk
>> giada
>> midisnoop
>> milkytracker
>>
>> Did you test build them?
> 
> Hi,
> 
> I just did test build of packages above.
> Location of header files changed from include to include/rtmidi so some 
easy patching will be needed.
> I just get some trouble to build midisnoop but not because of rtmidi 
package. 
> I am also maintainer of midisnoop and I don't see it as stopper for 
transition. 

Alright, go ahead. Please file bugs for the rdeps that need patches and let 
me
know which ones don't need any changes and can be rebuilt."



Ok bugs for r-deps filled ... unfortunately all of them need patches.




best regards



mira
 
"
"

Bug#828186: transition: rtaudio

[Jaromír Mikeš]

-- Původní zpráva --
Od: Emilio Pozuelo Monfort 
Komu: Jaromír Mikeš , 828...@bugs.debian.org
Datum: 28. 6. 2016 10:52:58
Předmět: Re: Bug#828186: transition: rtaudio

"Control: tags -1 confirmed

On 27/06/16 18:46, Jaromír Mikeš wrote:
>> Did you test build them?
> 
> Hi,
> 
> I just did test build of packages above.
> Location of header files changed from include to include/rtaudio so some 
easy patching will be needed.
> Otherwise they build fine.

Alright, go ahead. Please file bugs for the rdeps that need patches and let 
me
know which ones don't need any changes and can be rebuilt."



Ok bugs for r-deps filled ... unfortunately all of them need patches.




best regards




mira

Bug#828960: gnumeric: missing-pkgconfig-dependency libspreadsheet-1.12 => libgsf-1

[Antonio Ospite]

Package: gnumeric
Version: 1.12.30-1
Severity: normal

Dear Maintainer,

the QA tool adequate[1] reports the issue mentioned in the subject:

  $ adequate gnumeric
  gnumeric: missing-pkgconfig-dependency libspreadsheet-1.12 => libgsf-1

this is because gnumeric ships libspreadsheet-1.12.pc but does not
depend on the package containing libgsf-1.pc (libgsf-1-dev).

This also results in this error when running pkg-config:

  $ pkg-config --libs libspreadsheet-1.12 
  Package libgsf-1 was not found in the pkg-config search path.
  Perhaps you should add the directory containing `libgsf-1.pc'
  to the PKG_CONFIG_PATH environment variable
  Package 'libgsf-1', required by 'libspreadsheet-1.12', not found

The latter problem is solved by installing libgsf-1-dev, but having
gnumeric depend on it does not seems appropriate.

IMHO a possible clean solution would be to move libspreadsheet-1.12.pc
and the files in /usr/include/libspreadsheet-1.12 to a new package, say
gnumeric-dev or libspreadsheet-dev and have this new package depend on
libgsf-1-dev.

Just an idea.

Thanks,
   Antonio

[1] https://packages.debian.org/sid/adequate

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

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

Versions of packages gnumeric depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  gnumeric-common1.12.30-1
ii  gsfonts1:8.11+urwcyr1.0.7~pre44-4.2
ii  libatk1.0-02.20.0-1
ii  libc6  2.22-13
ii  libcairo2  1.14.6-1+b1
ii  libgdk-pixbuf2.0-0 2.34.0-1
ii  libglib2.0-0   2.48.1-1
ii  libgoffice-0.10-10 0.10.30-1
ii  libgsf-1-114   1.14.38-1
ii  libgtk-3-0 3.20.6-2
ii  libpango-1.0-0 1.40.1-1
ii  libpangocairo-1.0-01.40.1-1
ii  libxml22.9.3+dfsg1-1.2
ii  procps 2:3.3.11-3
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages gnumeric recommends:
ii  evince3.20.1-1
ii  gnumeric-doc  1.12.30-1
ii  lp-solve  5.5.0.15-4

Versions of packages gnumeric suggests:
ii  fonts-liberation   1.07.4-1
pn  gnumeric-plugins-extra 
ii  ttf-mscorefonts-installer  3.6

-- debconf information excluded
-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#801247: pinentry-gnome3: No PIN dialog

[Tim Small]

Package: pinentry-gnome3
Followup-For: Bug #801247

In my case, it looks like:

gpg-agent is started, and inherits the DBUS_SESSION_BUS_ADDRESS env
varible.  The gpg-agent persists across login sessions, so that when it
starts the gnome3 pinentry the dbus session doesn't correspond with the
current desktop session.

The practical result of this is that when I log to X first, it works,
but if I subsequently logout of my X session and then login again, I see
this bug.

People who start gpg-agent (or their X server) in different ways are
likely to see this problem without session restarts I suppose.

To confirm, I get different results from:

grep -z -i dbus  < /proc/`pidof gpg-agent`/environ

vs. 

grep -z -i dbus  < /proc/$$/environ

The gpg-agent manual page documents the use of:

gpg-connect-agent updatestartuptty /bye

to change the TTY and/or X display used for pin entry prompts.

I suppose the fix would involve either pinentry-gnome3 getting the
dbus session from the X session in some way (if that's possible),
or extending the functionality of "updatestartuptty" to also update dbus
session used by gpg-agent when starting the pinentry command.

Cheers,

Tim.

-- 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=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)

Bug#828961: gretl: FTBFS on hurd-i386

[Svante Signell]

Source: gretl
Version: 2016b-3
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

gretl fails to build on GNU/Hurd due to a name clash with OSX/Apple, both
defining the __MACH__ keyword. The intended usage is for OSX-based systems,
including , which does not exist on GNU/Hurd. This package
has built before, latest successful build was 2016a-1. The attached patch fixes
the build problems for version 2016b-3.

Thanks!Index: gretl-2016b/lib/src/gretl_utils.c
===
--- gretl-2016b.orig/lib/src/gretl_utils.c
+++ gretl-2016b/lib/src/gretl_utils.c
@@ -2877,7 +2877,7 @@ const char *blas_variant_string (void)
 }
 }
 
-#ifdef __MACH__
+#if defined(__MACH__) && defined(__APPLE__)
 # include 
 #elif GLIB_MAJOR_VERSION == 2 && GLIB_MINOR_VERSION < 28
 
@@ -2909,7 +2909,7 @@ static gint64 posix_monotonic_time (void
 
 gint64 gretl_monotonic_time (void)
 {
-#ifdef __MACH__
+#if defined(__MACH__) && defined(__APPLE__)
 return (gint64) mach_absolute_time();
 #elif GLIB_MAJOR_VERSION == 2 && GLIB_MINOR_VERSION < 28
 return posix_monotonic_time();

Bug#828962: ITP: r-cran-adephylo -- GNU R exploratory analyses for the phylogenetic comparative method

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-adephylo
  Version : 1.1-6
  Upstream Author : Thibaut Jombart 
* URL : https://cran.r-project.org/web/packages/adegenet/
* License : GPL
  Programming Lang: GNU R
  Description : GNU R exploratory analyses for the phylogenetic comparative 
method
 This GNU R package provides multivariate tools to analyze comparative
 data, i.e. a phylogeny and some traits measured for each taxa.


Remark: This package belongs to a pyramid of dependencies for the package
r-cran-treescape and will be maintained by the Debian Med team at
   svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-adephylo/trunk/

Bug#796633: Progress

[Wouter Verhelst]

On Wed, Jun 29, 2016 at 11:14:36AM +0200, Wouter Verhelst wrote:
> Hi,
> 
> I did some work on this at debcamp, and Tollef helped me out a bit, but
> it looks like we stumbled into some missing functionality in systemd.
> Issue request filed at https://github.com/systemd/systemd/issues/3627;
> waiting for systemd upstream now.

So, this turned out to be not true, we managed to come up with a working
systemd unit in the end \o/

There's still some work to be done before this can be uploaded (mostly
for backcompat), but I have reason to believe that it should be ready by
the end of debconf now.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#805972: xmlstarlet: cannot select by element name when xmlns is given

[Emmanuel Bourg]

I stumbled on the same issue when playing with Maven pom files and it
seems to be a feature of xmlstarlet:

   http://xmlstar.sourceforge.net/doc/UG/ch05s01.html

If the document has a default namespace it has to be specified
explicitly with the -N option and then prefixed to the name of the
elements in the XPath expression:

xmlstarlet sel -N xhtml=http://www.w3.org/1999/xhtml -T -t -c
'//xhtml:h3[@id="baz"]' -n test2.xml

This is rather annoying and the default namespace should probably be
ignored, but at least there is a workaround.

Emmanuel Bourg

Bug#828870: nvidia-driver: Incorrect amount of graphics memory detected

[Luca Boccassi]

On Wed, 2016-06-29 at 13:52 +0200, Lucas Serrano wrote:
> On 28/06/2016 21:20, Luca Boccassi wrote:
> > Control: tags -1 upstream
> > 
> > On Tue, 2016-06-28 at 19:23 +0200, Lucas Serrano wrote:
> >> Package: nvidia-driver
> >> Version: 352.79-8
> >> Severity: normal
> >>
> >> Dear Maintainer,
> >> I own a Clevo W255EG with an integrated GT 645M. Both nvidia-settings
> >> and nvidia-smi report 1GB as the total amount of graphics memory
> >> available. But there is at least 3x1GB graphical memory chips soldered
> >> on the laptop motherboard, which is consistent with amount of graphics
> >> memory reported on other laptops using this graphic card.
> > 
> > Hi,
> > 
> > Sorry but this really looks like an upstream problem, there is nothing
> > in the drivers packaging that could be causing this issue AFAIK.
> > 
> > Have you tried reporting this to Nvidia?
> > 
> 
> Hi,
> Thank you for confirming that this is an upstream problem. Yesterday I
> filled a bugreport to https://nvidia.custhelp.com but since I'm not
> familiar with bugreporting to Nvidia I don't know if this is the correct
> place.

For Linux stuff it's very common to create a new thread on the forum:

https://devtalk.nvidia.com/default/board/98/linux/

I would encourage you to do so and add all details regarding your
hardware there. If you then report back the link to the thread, I can
add it to this bug metadata.

> Also I found an interesting paragraph on the nvidia customer care website:
> "However, if you have a notebook computer, you must typically get driver
> updates directly from the manufacturer of your notebook. Notebook
> graphics cards are highly specialized and the reference drivers provided
> on the www.nvidia.com website may not work unless indicated"
> 
> So I suppose that the driver is somehow customized for laptop,
> explaining maybe why I have less enabled memory than available. Sadly
> it's unlikely that Clevo provides up-to-date linux driver for my laptop.

That would be very unusual, I've not seen such a problem before, but
anything can happen with proprietary drivers I suppose.

Kind regards,
Luca Boccassi


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

Bug#821888: proselint: --demo option is broken

[Víctor Cuadrado Juan]

A little debugging found the culprit, you cannot open
read-only files with proselint, even if proselint doesn't need to (nor
should) edit the files.

I will make a patch for this, and I have reported it upstream to get it
fixed [1].


Cheers,

[1]: https://github.com/amperser/proselint/issues/502


-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.

Bug#828833: python3-magic: magic file type double encoded

[Christoph Biedl]

Orestis Ioannou wrote...

> So many tests failed with this stacktrace http://paste.debian.net/770211/

What I'd really like to see is the actual code and the circumstances
that triggered the stacktrace, probably a certain file. Still I failed
to create that, and this is important to fix the issue.

> If this is causing a mess in other projects then don't wait for me :).
> At debsources the issue was happening only in travis since we pull the
> master branch of python magic. In other words you won't break
> debsources, at least right now, if you upload.

No, the library should support python2 to the full extent as long as
python2 is part of Debian. Which will be for stretch and perhaps even
for buster.

> Sorry for the trouble i caused :/

Don't worry, you're just the bringer of the news.

Christoph


signature.asc
Description: Digital signature

Bug#828933: Improve check to determine if the package installs a new interpreter

[Jakub Wilk]

Control: tags -1 + pending

* Sergio Durigan Junior , 2016-06-29, 01:18:
the current check to see if there is a new interpreter being installed 
is incomplete, because it assumes that the executable file will be in 
the toplevel directory.


Not quite. The code worked in the usual case when full interpreter path 
was specified, i.e. "#!/usr/bin/foo", but not for "#!/usr/bin/env foo".


I've committed a different fix for the latter case.

Thanks for the bug report.

--
Jakub Wilk

Bug#813436: How to specify a generic architecture to GCC (Was: SSE3 issue with iqtree when trying to enable i386)

[Andreas Tille]

Hi Tung,

thanks to the very helpful and detailed response of Christian Seiler
which I would like you to read below in detail since it explains the
patches applied in the Debian packaging I was able to build the latest
iqtree version.  You can find all patches that are applied to iqtree
here:

https://anonscm.debian.org/cgit/debian-med/iqtree.git/tree/debian/patches

Please also note that I have updated the spelling patch with some
spelling mistakes (in code and comments).

Kind regards and thanks for your cooperation

 Andreas.

On Tue, Jun 28, 2016 at 08:09:15PM +0200, Christian Seiler wrote:
> On 06/28/2016 11:01 AM, Andreas Tille wrote:
> > I admit I can not answer the question asked by upstream.  The package in
> > question is iqtree[1] and they said that they have different
> > computational kernels implemented to respect different hardware.
> > Current Git[1] does not even build - may be due to some fine tuning of
> > gcc options needed???
> 
> I've looked at this, and there are a couple of things going on here:
> 
> 0. Debian's build flags by default assume a generic architecture, so
> you don't have to do anything by yourself.
> 
> 1. Upstream's build system supports multiple options for the entirety
> of the code. So you can compile the entire code with the AVX or FMA
> instruction set. You patch that out completely from the CMakeLists.txt
> in sse.patch, but that isn't actually required. (IQTREE_FLAGS would
> have to be explicitly set to enable this.)
> 
> 2. Furthermore, upstream's build system provides SSE and AVX kernels
> for regardless of the build flags of the rest of the code, and they are
> always compiled. (Well, you can disable compilation of the AVX kernel
> if you add "novx" to IQTREE_FLAGS, but there's no reason to.) This
> should work out of the box.
> 
> That said, the code doesn't support non-SSE at all, because it hard-
> codes at least SSE2 intrinsics in a lot of platces (and the one part
> where it hardcodes SSE3, you already have a patch for). The code can
> therefore not be compiled without SSE support enabled, unfortunately,
> even on i386. If you want to support non-SSE at all on i386, upstream
> (or yourself) needs to implement the routines in the vectorclass/
> directory (and possibly others) for non-SSE systems. (The kernel that
> optionally uses AVX also exists in a non-SSE variant, so upstream is
> not completely wrong about that, but there's a lot of _other_ code that
> forces at least SSE2.
> 
> 3. pll/ has a bug that it calls posix_memalign with PLL_BYTE_ALIGNMENT.
> However, according to the manpage, the alignment must be a multiple of
> sizeof(void *) for posix_memalign to work (and a power of 2), but
> PLL_BYTE_ALIGNMENT is 1 if SSE3 is not used. If you explicitly set it
> to 8 (to catch both 32bit and 64bit), posix_memalign will not fail and
> the program won't segfault anymore. (posix_memalign with wrong align
> argument will just return without a possibility to check for an error,
> but also not allocating a buffer, leaving it empty.)
> 
> Note though that if you don't compile with sse3 flags enabled, pll will
> not use SSE code at all (other than that which the compiler generates),
> which is probably slower. But it does work, though. (A grep for __SSE3
> shows though that porting this would be a LOT of work.)
> 
> Irrespective of the SSE-stuff, two things:
> 
> 1. Your debian/rules calls dh_auto_clean/configure/build in
>override_dh_auto_build to build two variants. This can be done in a
>more elegant way, because CMake does support out of tree builds, and
>you can have debhelper use a specific build directory by specifying
>-Bdirname to dh_auto_*.
> 
> 2. You might want to add --parallel to your dh call in debian/rules.
>CMake-based projects tend to support paralle builds, and iqtest is
>no exception to that rule. Would speed up build times quite a bit.
> 
> 3. If you want to test the -omp binary as you do in debian/rules
>currently, you have to pass -redo, otherwise the second call will
>simply fail.
> 
> I've update your sse.patch to include the SSE-related fixes, and have
> updated debian/rules to incorporate the two other things. Attached both
> to this email. The package now builds on amd64 and i386 (and probably
> will build on the kfreebsd and hurd variants thereof, though I haven't
> checked) and the test suite runs. The AVX/FMA checks in CMakeLists.txt
> are now not removed, because debian/rules never sets IQTEST_FLAGS to
> fma or avx. (On amd64 the avx kernel is built with -mavx regardless
> separately by the build system, so that's also OK; and on my Haswell
> system the AVX detection works. On i386 the AVX kernel is never built,
> as per what the upstream build system decided.) However, even on i386,
> SSE2 support is required for this to work, otherwise the program will
> crash with either illegal instruction or a segfault at start. (I can
> provide you with a preinst script that checks for SSE2 support 

Bug#828963: squirrel3: FTBFS: Makefile:66: recipe for target 'stdlib.pdf' failed

[Chris Lamb]

Source: squirrel3
Version: 3.1-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

squirrel3 fails to build from source in unstable/amd64:

  [..]

  dh clean
 dh_testdir
 dh_auto_clean
 dh_clean
   debian/rules build
  dh build
 dh_testdir
 dh_update_autotools_config
 debian/rules override_dh_auto_configure
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1'
  dh_auto_configure --buildsystem=cmake -- \
-DINSTALL_LIB_DIR=lib/x86_64-linux-gnu \
-DINSTALL_INC_DIR=include/squirrel3 \
-DDISABLE_STATIC="" -DLONG_OUTPUT_NAMES=""
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DINSTALL_LIB_DIR=lib/x86_64-linux-gnu 
-DINSTALL_INC_DIR=include/squirrel3 -DDISABLE_STATIC= -DLONG_OUTPUT_NAMES=
  -- The C compiler identification is GNU 5.4.0
  -- The CXX compiler identification is GNU 5.4.0
  -- Check for working C compiler: /usr/bin/cc
  -- Check for working C compiler: /usr/bin/cc -- works
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Detecting C compile features
  -- Detecting C compile features - done
  -- Check for working CXX compiler: /usr/bin/c++
  -- Check for working CXX compiler: /usr/bin/c++ -- works
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- Configuring done
  -- Generating done
  CMake Warning:
Manually-specified variables were not used by the project:
  
  CMAKE_INSTALL_LOCALSTATEDIR
  CMAKE_INSTALL_SYSCONFDIR
  DISABLE_STATIC
  LONG_OUTPUT_NAMES
  
  
  -- Build files have been written to: 
/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1/obj-x86_64-linux-gnu
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1'
 dh_auto_build
make -j1
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1/obj-x86_64-linux-gnu'
  /usr/bin/cmake 
-H/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1 
-B/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1/obj-x86_64-linux-gnu
 --check-build-system CMakeFiles/Makefile.cmake 0
  /usr/bin/cmake -E cmake_progress_start 
/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1/obj-x86_64-linux-gnu/CMakeFiles
 
/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1/obj-x86_64-linux-gnu/CMakeFiles/progress.marks
  make -f CMakeFiles/Makefile2 all
  make[2]: Entering directory 
'/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1/obj-x86_64-linux-gnu'
  make -f squirrel/CMakeFiles/squirrel.dir/build.make 
squirrel/CMakeFiles/squirrel.dir/depend
  make[3]: Entering directory 
'/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1/obj-x86_64-linux-gnu'
  cd 
/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1/obj-x86_64-linux-gnu
 && /usr/bin/cmake -E cmake_depends "Unix Makefiles" 
/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1 
/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1/squirrel 
/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1/obj-x86_64-linux-gnu
 
/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1/obj-x86_64-linux-gnu/squirrel
 
/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1/obj-x86_64-linux-gnu/squirrel/CMakeFiles/squirrel.dir/DependInfo.cmake
 --color=
  Scanning dependencies of target squirrel
  make[3]: Leaving directory 
'/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1/obj-x86_64-linux-gnu'
  make -f squirrel/CMakeFiles/squirrel.dir/build.make 
squirrel/CMakeFiles/squirrel.dir/build
  make[3]: Entering directory 
'/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1/obj-x86_64-linux-gnu'
  [  4%] Building CXX object squirrel/CMakeFiles/squirrel.dir/sqapi.cpp.o
  cd 
/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1/obj-x86_64-linux-gnu/squirrel
 && /usr/bin/c++   -D_SQ64 -Dsquirrel_EXPORTS 
-I/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1/include
  -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wall 
-pedantic -fno-exceptions -fno-strict-aliasing -fno-rtti -std=c++11 -Wdate-time 
-D_FORTIFY_SOURCE=2  -fno-rtti -std=c++0x -fPIC   -fno-exceptions 
-fno-strict-aliasing -Wall -Wextra -pedantic -Wcast-qual -o 
CMakeFiles/squirrel.dir/sqapi.cpp.o -c 
/home/lamby/temp/cdt.20160629140947.K29HDt9qCU.squirrel3/squirrel3-3.1/squirrel/sqapi.cpp
  [  8%] Building CXX objec

Bug#828964: opj_stream_get_number_byte_left: Assertion `p_stream->m_user_data_length >= (OPJ_UINT64)p_stream->m_byte_offset' failed.

[Mathieu Malaterre]

Package: libgdcm2.6
Version: 2.6.3-6
Severity: important
Forwarded: -1 https://sourceforge.net/p/gdcm/bugs/389/

This appears to be a regression from 2.6.1 at least. The bug was
introduced when we switch from OPJ 1.x to OPJ 2.x.

Warning: In 
/build/gdcm-ot2Kab/gdcm-2.6.3/Source/MediaStorageAndFileFormat/gdcmBitmap.cxx,
line 735, function bool gdcm::Bitmap::TryJPEG2000Codec(char*, bool&)
const
Encapsulated stream has fewer bits actually stored on disk. correcting.

Warning: In 
/build/gdcm-ot2Kab/gdcm-2.6.3/Source/MediaStorageAndFileFormat/gdcmPixmapReader.cxx,
line 1081, function bool gdcm::PixmapReader::ReadImageInternal(const
gdcm::MediaStorage&, bool)
DataSet set LossyFlag to 0, while Codec made the stream lossy

python: /build/openjpeg2-JSn56b/openjpeg2-2.1.0/src/lib/openjp2/cio.c:553:
opj_stream_get_number_byte_left: Assertion
`p_stream->m_user_data_length >= (OPJ_UINT64)p_stream->m_byte_offset'
failed.
Aborted

Bug#828965: konsole: Application not responding when launching root profile.

[r.ductor]

Package: konsole
Version: 4:16.04.2-1
Severity: normal

Dear Maintainer,

Launching a root profile involving /bin/su --login (see below),
opens a new shell window but no password is asked and konsole gets stuck
(Closing the window on has "Application not responding").

This happens starting the konsole profile from cli
as well as from the Konsole Profiles plasma widget.

Other profiles that do not use /bin/su works correctly.
Invoking su from a user profile shell works fine.

My profile:
$ cat .kde/share/apps/konsole/Root-Large-BRL.profile 
[Appearance]
ColorScheme=BlackOnRandomLight
Font=DejaVu Sans Mono,18,-1,2,50,0,0,0,0,0

[General]
Command=/bin/su --login
Directory=/root
Name=Root-Large-BRL
Parent=FALLBACK/
StartInCurrentSessionDir=false
TerminalColumns=135
TerminalRows=17

Thanks for your time
ric

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

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

Versions of packages konsole depends on:
ii  konsole-kpart   4:16.04.2-1
ii  libc6   2.22-11
ii  libkf5completion5   5.23.0-1
ii  libkf5configcore5   5.23.0-1
ii  libkf5configgui55.23.0-1
ii  libkf5configwidgets55.22.0-1
ii  libkf5coreaddons5   5.23.0-1
ii  libkf5i18n5 5.22.1-1
ii  libkf5iconthemes5   5.22.0-1
ii  libkf5kdelibs4support5  5.22.0-2
ii  libkf5kiowidgets5   5.22.0-1
ii  libkf5notifyconfig5 5.22.0-1
ii  libkf5widgetsaddons55.23.0-1
ii  libkf5windowsystem5 5.23.0-1
ii  libkf5xmlgui5   5.22.0-1
ii  libqt5core5a5.6.1+dfsg-2
ii  libqt5gui5  5.6.1+dfsg-2
ii  libqt5widgets5  5.6.1+dfsg-2
ii  libstdc++6  6.1.1-7

konsole recommends no packages.

konsole suggests no packages.

-- no debconf information

Bug#828933: Improve check to determine if the package installs a new interpreter

[Sergio Durigan Junior]

On Wednesday, June 29 2016, Jakub Wilk wrote:

> Control: tags -1 + pending
>
> * Sergio Durigan Junior , 2016-06-29, 01:18:
>> the current check to see if there is a new interpreter being
>> installed is incomplete, because it assumes that the executable file
>> will be in the toplevel directory.
>
> Not quite. The code worked in the usual case when full interpreter
> path was specified, i.e. "#!/usr/bin/foo", but not for "#!/usr/bin/env
> foo".

Hm, alright.  Indeed, the case that was failing with me was exactly the
"#!/usr/bin/env foo".

> I've committed a different fix for the latter case.

Thanks!

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#828889: RFS: elisp-slime-nav-el/0.9-1 ITP

[Sergio Durigan Junior]

On Wednesday, June 29 2016, Gianfranco Costamagna wrote:

>>3) Any reason why you're using debhelper version 10?  It's still
>
>>experimental, so you probably should be using version 9.
>
>
> I'm not sure about this, some days ago debhelper 11 implementation started, 
> so I think compat
> level 10 is somewhat considered stable?
> https://anonscm.debian.org/git/debhelper/debhelper.git/commit/?id=d52c3364f9518e021be31f350204fe8e4a24619b

According to:

  

It's ready for public testing, but that doesn't necessarily mean that
it's stable.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#828946: krb5: FTBFS in testing (LaTeX Error: File `iftex.sty' not found)

[Sam Hartman]

For my notes, iftex.sty is in texlive-generic-extra on my system.
I did the most recent build for sid in a chroot including the arch all
packages, so it's more likely to be something changing than a
then-missing-build-dep-indep, but I'll take a look while at Debconf.

Bug#828220: dblatex: Make generated PDFs reproducable?

[Petter Reinholdtsen]

[Andreas Hoenen]
> @Petter: Does this satisfy your needs?

I'm not sure.  I do not know how to test this with xmlto, and got the
impression that inaddition to the PDF document date, there is something
about the images in the generated FreedomBox documentation

-- 
Happy hacking
Petter Reinholdtsen

Bug#813436: How to specify a generic architecture to GCC (Was: SSE3 issue with iqtree when trying to enable i386)

[Tung Nguyen]

Dear Andreas and others,

Thanks a lot for your help in fixing the compatibility issues in IQ-TREE.
We will apply the patches to our GIT repository.

Cheers
Tung

On Wed, Jun 29, 2016 at 2:16 PM, Andreas Tille  wrote:

> Hi Tung,
>
> thanks to the very helpful and detailed response of Christian Seiler
> which I would like you to read below in detail since it explains the
> patches applied in the Debian packaging I was able to build the latest
> iqtree version.  You can find all patches that are applied to iqtree
> here:
>
>
> https://anonscm.debian.org/cgit/debian-med/iqtree.git/tree/debian/patches
>
> Please also note that I have updated the spelling patch with some
> spelling mistakes (in code and comments).
>
> Kind regards and thanks for your cooperation
>
>  Andreas.
>
> On Tue, Jun 28, 2016 at 08:09:15PM +0200, Christian Seiler wrote:
> > On 06/28/2016 11:01 AM, Andreas Tille wrote:
> > > I admit I can not answer the question asked by upstream.  The package
> in
> > > question is iqtree[1] and they said that they have different
> > > computational kernels implemented to respect different hardware.
> > > Current Git[1] does not even build - may be due to some fine tuning of
> > > gcc options needed???
> >
> > I've looked at this, and there are a couple of things going on here:
> >
> > 0. Debian's build flags by default assume a generic architecture, so
> > you don't have to do anything by yourself.
> >
> > 1. Upstream's build system supports multiple options for the entirety
> > of the code. So you can compile the entire code with the AVX or FMA
> > instruction set. You patch that out completely from the CMakeLists.txt
> > in sse.patch, but that isn't actually required. (IQTREE_FLAGS would
> > have to be explicitly set to enable this.)
> >
> > 2. Furthermore, upstream's build system provides SSE and AVX kernels
> > for regardless of the build flags of the rest of the code, and they are
> > always compiled. (Well, you can disable compilation of the AVX kernel
> > if you add "novx" to IQTREE_FLAGS, but there's no reason to.) This
> > should work out of the box.
> >
> > That said, the code doesn't support non-SSE at all, because it hard-
> > codes at least SSE2 intrinsics in a lot of platces (and the one part
> > where it hardcodes SSE3, you already have a patch for). The code can
> > therefore not be compiled without SSE support enabled, unfortunately,
> > even on i386. If you want to support non-SSE at all on i386, upstream
> > (or yourself) needs to implement the routines in the vectorclass/
> > directory (and possibly others) for non-SSE systems. (The kernel that
> > optionally uses AVX also exists in a non-SSE variant, so upstream is
> > not completely wrong about that, but there's a lot of _other_ code that
> > forces at least SSE2.
> >
> > 3. pll/ has a bug that it calls posix_memalign with PLL_BYTE_ALIGNMENT.
> > However, according to the manpage, the alignment must be a multiple of
> > sizeof(void *) for posix_memalign to work (and a power of 2), but
> > PLL_BYTE_ALIGNMENT is 1 if SSE3 is not used. If you explicitly set it
> > to 8 (to catch both 32bit and 64bit), posix_memalign will not fail and
> > the program won't segfault anymore. (posix_memalign with wrong align
> > argument will just return without a possibility to check for an error,
> > but also not allocating a buffer, leaving it empty.)
> >
> > Note though that if you don't compile with sse3 flags enabled, pll will
> > not use SSE code at all (other than that which the compiler generates),
> > which is probably slower. But it does work, though. (A grep for __SSE3
> > shows though that porting this would be a LOT of work.)
> >
> > Irrespective of the SSE-stuff, two things:
> >
> > 1. Your debian/rules calls dh_auto_clean/configure/build in
> >override_dh_auto_build to build two variants. This can be done in a
> >more elegant way, because CMake does support out of tree builds, and
> >you can have debhelper use a specific build directory by specifying
> >-Bdirname to dh_auto_*.
> >
> > 2. You might want to add --parallel to your dh call in debian/rules.
> >CMake-based projects tend to support paralle builds, and iqtest is
> >no exception to that rule. Would speed up build times quite a bit.
> >
> > 3. If you want to test the -omp binary as you do in debian/rules
> >currently, you have to pass -redo, otherwise the second call will
> >simply fail.
> >
> > I've update your sse.patch to include the SSE-related fixes, and have
> > updated debian/rules to incorporate the two other things. Attached both
> > to this email. The package now builds on amd64 and i386 (and probably
> > will build on the kfreebsd and hurd variants thereof, though I haven't
> > checked) and the test suite runs. The AVX/FMA checks in CMakeLists.txt
> > are now not removed, because debian/rules never sets IQTEST_FLAGS to
> > fma or avx. (On amd64 the avx kernel is built with -mavx regardless
> > separately by the build system, so that'

Bug#823139: closed by Sebastien Jodogne (Bug#823139: fixed in orthanc 1.1.0+dfsg-1)

[Karsten Hilbert]

On Mon, Jun 27, 2016 at 10:30:08PM +, Debian Bug Tracking System wrote:

> please compile and provide
>   Samples/Tools/RecoverCompressedFile.cpp
> as
>   /usr/sbin/orthanc-recover_compressed_file
...
> If /usr/sbin/orthanc-recover_compressed_file were available I
> could provide helper scripts upgrading the database.

For the time being attached find a shell script which makes
using /usr/bin/OrthancCompressedFile a lot more convenient
(given exiftool and dicom3tools are installed).

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
#!/bin/bash

DCMFILE="$1"
LOG=${DCMFILE}.log

OrthancRecoverCompressedFile ${DCMFILE} ${DCMFILE}.uncompressed &> ${LOG}
RESULT=$?

if [ $RESULT -ne 0 ] ; then
echo "cannot uncompress ${DCMFILE}"
echo "--- file" &>> ${LOG}
file ${DCMFILE} &>> ${LOG}
echo "--- dciodvfy" &>> ${LOG}
dciodvfy -filename ${DCMFILE} &>> ${LOG}
echo "--- dcentvfy" &>> ${LOG}
dcentvfy -veryverbose ${DCMFILE} &>> ${LOG}
echo "--- exiftool" &>> ${LOG}
exiftool ${DCMFILE} &>> ${LOG}
echo 
"--"
less ${LOG}
fi

exit ${RESULT}

Bug#828966: transition: ros-ros-comm

[Leopold Palomo-Avellaneda]

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

Dear Release Team,

I'm filing this bug for a transition of ros-ros-comm . It is 
in experimental. It builds on all architectures in testing, where it built 
previously. 

Ben file:

title = "ros-ros-comm";
is_affected = .depends ~ 
/\b(libmessage\-filters1d|librosbag\-storage1d|librosbag1d|librosconsole2d|libroscpp1d|libroslz4\-1d|libtopic\-tools1d|libxmlrpcpp1d|libmessage\-filters0d|librosbag\-storage0d|librosbag0d|librosconsole1d|libroscpp0d|libroslz4\-0d|libtopic\-tools0d|libxmlrpcpp0d)\b/
is_good = .depends ~ 
/\b(libmessage\-filters1d|librosbag\-storage1d|librosbag1d|librosconsole2d|libroscpp1d|libroslz4\-1d|libtopic\-tools1d|libxmlrpcpp1d)\b/
is_bad = .depends ~ 
/\b(libmessage\-filters0d|librosbag\-storage0d|librosbag0d|librosconsole1d|libroscpp0d|libroslz4\-0d|libtopic\-tools0d|libxmlrpcpp0d)\b/

All reverse dependencies test rebuilds. All rdepends are listed here:
https://release.debian.org/transitions/html/auto-ros-ros-comm.html

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

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

Bug#802702: CVE-2011-5325: busybox: Directory traversal via crafted tar file which contains a symlink pointing outside of the current directory

[Ben Hutchings]

On Wed, 2016-06-29 at 10:39 +0200, Petter Reinholdtsen wrote:
> [Chris Lamb]
> > IIRC it was deemed to be low-priority from an LTS point of view so/and
> > I could not justify spending more time on it then. Happy to look again
> > if there is a more urgent requirement.
> 
> Right.  It is still unsolved in stable, testing, unstable and upstream,
> and the second oldest open CVE on my stable laptop (the oldest is in
> ruby, and pending a stable update), so I would like to see it fixed to
> reduce the number of known security problems on my machine. :)
> 
> Can not say much about the priority or urgency related to other issues,
> though. :)
> 
> I've poked upstream too, and hope some solution will materialise.

This was fixed in GNU tar some years ago, and I was able to implement a
similar fix in p7zip (thought that was simpler because p7zip doesn't
support hard links).

busybox tar should do basically the same as GNU tar, though without
copying code since they are unfortunately not licence-compatible.

Ben.

-- 

Ben Hutchings
Make three consecutive correct guesses and you will be considered an
expert.


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

Bug#741972: ITP: popcorn-time -- Torrent movie streamer (Was: intent to package)

[Petter Reinholdtsen]

There is a "fork" of the Popcorn Time client named Butter Desktop,
https://github.com/butterproject/butter-desktop >, which might be
a useful alternative to package in Debian.

-- 
Happy hacking
Petter Reinholdtsen

Bug#818757: [Debian-med-packaging] Bug#818757: orthanc-postgresql: does not start

[Karsten Hilbert]

On Wed, Jun 29, 2016 at 08:07:17AM +0200, Sebastien Jodogne wrote:

> What I would need would be a full backtrace of the C++ code. This requires a
> fresh build in debug mode, with static linking, of both Orthanc 1.1.0 and
> PostgreSQL plugin 2.0. Static linking allows to become independent of a
> potential instability of your Debian setup.
> 
> After downloading the source code of each package, create a "Build"
> directory inside, and run:
> 
> # cmake .. -DSTATIC_BUILD=ON -DCMAKE_BUILD_TYPE=Debug
> # make
> 
> Obviously, make sure that your Orthanc configuration points to the newly
> built PostgreSQL plugin.
> 
> Then, please post the full gdb backtrace (command "bt") of the crash when
> you try and run [Orthanc]

Attached a full backtrace of a stock Debian Orthanc 1.1.0
with o-pg 2.0 (it is lacking symbols so might be of limited
use).

Any chance a -dbgsyms package can be provided ?

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
Skript gestartet auf Mi 29 Jun 2016 14:40:04 CEST
root@hermes:~/bin# gdb --args /usr/sbin/Orthanc --trace 
--logdir=/var/log/orthanc /etc/orthanc/
GNU gdb (Debian 7.11.1-2) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/Orthanc...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/sbin/Orthanc --trace --logdir=/var/log/orthanc 
/etc/orthanc/
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
*** stack smashing detected ***: /usr/sbin/Orthanc terminated
=== Backtrace: =
/lib/i386-linux-gnu/libc.so.6(+0x6929b)[0xb717629b]
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x37)[0xb7205eb7]
/lib/i386-linux-gnu/libc.so.6(+0xf8e78)[0xb7205e78]
/usr/share/orthanc/plugins/libOrthancPostgreSQLStorage.so(+0x11284)[0xb7fac284]
/usr/share/orthanc/plugins/libOrthancPostgreSQLStorage.so(+0xa9bf)[0xb7fa59bf]
/usr/share/orthanc/plugins/libOrthancPostgreSQLStorage.so(OrthancPluginInitialize+0xab)[0xb7fabd7b]
/usr/sbin/Orthanc(+0xd8007)[0x800d8007]
/usr/sbin/Orthanc(+0xd8b70)[0x800d8b70]
/usr/sbin/Orthanc(+0xd8161)[0x800d8161]
/usr/sbin/Orthanc(main+0x4cd)[0x8002400d]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf7)[0xb7125517]
/usr/sbin/Orthanc(+0x2b568)[0x8002b568]
=== Memory map: 
8000-802ad000 r-xp  08:01 6288261/usr/sbin/Orthanc
802ad000-802b1000 r--p 002ac000 08:01 6288261/usr/sbin/Orthanc
802b1000-802b2000 rw-p 002b 08:01 6288261/usr/sbin/Orthanc
802b2000-804e7000 rw-p  00:00 0  [heap]
b4978000-b49a8000 r-xp  08:01 6898193
/usr/lib/i386-linux-gnu/libpq.so.5.8
b49a8000-b49aa000 r--p 0002f000 08:01 6898193
/usr/lib/i386-linux-gnu/libpq.so.5.8
b49aa000-b49ab000 rw-p 00031000 08:01 6898193
/usr/lib/i386-linux-gnu/libpq.so.5.8
b49ab000-b49df000 r-xp  08:01 6899772
/usr/lib/i386-linux-gnu/libjsoncpp.so.0.10.5
b49df000-b49e r--p 00033000 08:01 6899772
/usr/lib/i386-linux-gnu/libjsoncpp.so.0.10.5
b49e-b49e1000 rw-p 00034000 08:01 6899772
/usr/lib/i386-linux-gnu/libjsoncpp.so.0.10.5
b4a34000-b4a3d000 rw-p  00:00 0 
b4a3d000-b4a44000 r-xp  08:01 6899295
/usr/lib/i386-linux-gnu/libffi.so.6.0.4
b4a44000-b4a45000 r--p 6000 08:01 6899295
/usr/lib/i386-linux-gnu/libffi.so.6.0.4
b4a45000-b4a46000 rw-p 7000 08:01 6899295
/usr/lib/i386-linux-gnu/libffi.so.6.0.4
b4a46000-b4a5a000 r-xp  08:01 8151438
/lib/i386-linux-gnu/libgpg-error.so.0.19.0
b4a5a000-b4a5b000 r--p 00013000 08:01 8151438
/lib/i386-linux-gnu/libgpg-error.so.0.19.0
b4a5b000-b4a5c000 rw-p 00014000 08:01 8151438
/lib/i386-linux-gnu/libgpg-error.so.0.19.0
b4a5c000-b4a6e000 r-xp  08:01 6899143
/usr/lib/i386-linux-gnu/libtasn1.so.6.5.2
b4a6e000-b4a6f000 ---p 00012000 08:01 6899143
/usr/lib/i386-linux-gnu/libtasn1.so.6.5.2
b4a6f000-b4a7 r--p 00012000 08:01 6899143
/usr/lib/i386-linux-gnu/libtasn1.so.6.5.2
b4a7-b4a71000 rw-p 00013000 08:01 6899143
/usr/lib/i386-linux-gnu/libtasn1.so.6.5.2
b4a71000-b4a72000 rw-p  00:00 0 
b4a72000-b4ace000 r-xp  08:01 6898110
/usr/lib/i386-linux-gnu/libp11-kit.so.0.1.0
b4ace000-b4ad3000 r--p 0005b000 08:01 6898110
/usr/lib/i386-linux-gnu/libp11-kit.so.0.1.0
b4ad3000-b4ad4000 rw-p 

Bug#828968: ppp: Support custom host-uniq tags

[Matteo Croce]

Package: ppp
Version: 2.4.7-1+2
Severity: wishlist

Dear Maintainer,

Please consider applying the patch which allows to set an arbitrary host-uniq
pppoe tag, which is *needed* to connect to some ISP.

-- 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-apu+ (SMP w/2 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 ppp depends on:
ii  init-system-helpers  1.35
ii  libc62.22-11
ii  libpam-modules   1.1.8-3.3
ii  libpam-runtime   1.1.8-3.3
ii  libpam0g 1.1.8-3.3
ii  libpcap0.8   1.7.4-2
ii  procps   2:3.3.11-3

ppp recommends no packages.

ppp suggests no packages.

-- Configuration Files:
/etc/ppp/options changed [not included]

-- no debconf information

-- 
Matteo Croce
OpenWrt Developer
  ___ __
 |   |.-.-.-.|  |  |  |..|  |_
 |   -   ||  _  |  -__| ||  |  |  ||   _||   _|
 |___||   __|_|__|__||||__|  ||
  |__| W I R E L E S S   F R E E D O M
 -
 CHAOS CALMER (15.05)
 -
  * 1 1/2 oz GinShake with a glassful
  * 1/4 oz Triple Sec   of broken ice and pour
  * 3/4 oz Lime Juice   unstrained into a goblet.
  * 1 1/2 oz Orange Juice
  * 1 tsp. Grenadine Syrup
 -
From: Matteo Croce 
Date: Sat, 21 Nov 2015 18:45:43 +0100
Subject: [PATCH v2] pppoe: custom host-uniq tag

Add pppoe 'host-uniq' option to set an arbitrary
host-uniq tag instead of the pppd pid.
Some ISPs use such tag to authenticate the CPE,
so it must be set to a proper value to connect.

Signed-off-by: Matteo Croce 
Signed-off-by: Jo-Philipp Wich 
---
specify tag in hex format, use PPPoETag struct

 pppd/plugins/rp-pppoe/common.c  | 14 -
 pppd/plugins/rp-pppoe/discovery.c   | 51 +
 pppd/plugins/rp-pppoe/plugin.c  |  7 -
 pppd/plugins/rp-pppoe/pppoe-discovery.c | 38 +++-
 pppd/plugins/rp-pppoe/pppoe.h   | 31 +++-
 5 files changed, 86 insertions(+), 55 deletions(-)

diff --git a/pppd/plugins/rp-pppoe/common.c b/pppd/plugins/rp-pppoe/common.c
index 89c633c..8f175ec 100644
--- a/pppd/plugins/rp-pppoe/common.c
+++ b/pppd/plugins/rp-pppoe/common.c
@@ -119,15 +119,11 @@ sendPADT(PPPoEConnection *conn, char const *msg)
 conn->session = 0;
 
 /* If we're using Host-Uniq, copy it over */
-if (conn->useHostUniq) {
-	PPPoETag hostUniq;
-	pid_t pid = getpid();
-	hostUniq.type = htons(TAG_HOST_UNIQ);
-	hostUniq.length = htons(sizeof(pid));
-	memcpy(hostUniq.payload, &pid, sizeof(pid));
-	memcpy(cursor, &hostUniq, sizeof(pid) + TAG_HDR_SIZE);
-	cursor += sizeof(pid) + TAG_HDR_SIZE;
-	plen += sizeof(pid) + TAG_HDR_SIZE;
+if (conn->hostUniq.length) {
+	int len = ntohs(conn->hostUniq.length);
+	memcpy(cursor, &conn->hostUniq, len + TAG_HDR_SIZE);
+	cursor += len + TAG_HDR_SIZE;
+	plen += len + TAG_HDR_SIZE;
 }
 
 /* Copy error message */
diff --git a/pppd/plugins/rp-pppoe/discovery.c b/pppd/plugins/rp-pppoe/discovery.c
index 04877cb..5db8d0d 100644
--- a/pppd/plugins/rp-pppoe/discovery.c
+++ b/pppd/plugins/rp-pppoe/discovery.c
@@ -80,13 +80,10 @@ static void
 parseForHostUniq(UINT16_t type, UINT16_t len, unsigned char *data,
 		 void *extra)
 {
-int *val = (int *) extra;
-if (type == TAG_HOST_UNIQ && len == sizeof(pid_t)) {
-	pid_t tmp;
-	memcpy(&tmp, data, len);
-	if (tmp == getpid()) {
-	*val = 1;
-	}
+PPPoETag *tag = extra;
+
+if (type == TAG_HOST_UNIQ && len == ntohs(tag->length)) {
+	tag->length = memcmp(data, tag->payload, len);
 }
 }
 
@@ -104,16 +101,16 @@ parseForHostUniq(UINT16_t type, UINT16_t len, unsigned char *data,
 static int
 packetIsForMe(PPPoEConnection *conn, PPPoEPacket *packet)
 {
-int forMe = 0;
+PPPoETag hostUniq = conn->hostUniq;
 
 /* If packet is not directed to our MAC address, forget it */
 if (memcmp(packet->ethHdr.h_dest, conn->myEth, ETH_ALEN)) return 0;
 
 /* If we're not using the Host-Unique tag, then accept the packet */
-if (!conn->useHostUniq) return 1;
+if (!conn->hostUniq.length) return 1;
 
-parsePacket(packet, parseForHostUniq, &forMe);
-return forMe;
+parsePacket(packet, parseForHostUniq, &hostUniq);
+return !hostUniq.length;
 }
 
 /**
@@ -301,16 +298,12 @@ sendPADI(PPPoEConnection *conn)
 }
 
 /* If we're using Host-Uniq, copy it over */
-if (conn->useHostUniq) {
-	PPPoETag hostUniq;
-	pid_t pid = getpid();
-	hostUniq.type = htons(TAG_HOST_UNIQ);
-	hostUniq.length = htons(sizeof(pid));

Bug#828967: CVE-2016-4428: Possible client side template injection in horizon

[Thomas Goirand]

Source: horizon
Version: 3:9.0.1-1
Severity: important

See details here:
https://bugs.launchpad.net/horizon/+bug/1567673

Bug#802702: CVE-2011-5325: busybox: Directory traversal via crafted tar file which contains a symlink pointing outside of the current directory

[Chris Lamb]

> busybox tar should do basically the same as GNU tar

Indeed. The implementation wasn't quite as straightforward or as clean as 
fixing the symlinks case, hence why my patch on upstream's bugtracker only 
addresses that part.


Regards,

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

Bug#828969: dogecoin: please make the build reproducible

[Reiner Herrmann]

Source: dogecoin
Version: 1.10.0-2
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Forwarded: https://github.com/dogecoin/dogecoin/pull/1351

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that dogecoin could not be built reproducibly.
It sorts files without normalizing the locale, which results in
different orders under different locales.

The attached patch fixes this by using the C locale for sorting.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/0003-reproducible-build.patch b/debian/patches/0003-reproducible-build.patch
new file mode 100644
index 000..6217e4b
--- /dev/null
+++ b/debian/patches/0003-reproducible-build.patch
@@ -0,0 +1,11 @@
+--- a/src/leveldb/build_detect_platform
 b/src/leveldb/build_detect_platform
+@@ -176,7 +176,7 @@
+ PRUNE_TEST="-name *test*.cc -prune"
+ PRUNE_BENCH="-name *_bench.cc -prune"
+ PRUNE_TOOL="-name leveldb_main.cc -prune"
+-PORTABLE_FILES=`find $DIRS $PRUNE_TEST -o $PRUNE_BENCH -o $PRUNE_TOOL -o -name '*.cc' -print | sort | sed "s,^$PREFIX/,," | tr "\n" " "`
++PORTABLE_FILES=`find $DIRS $PRUNE_TEST -o $PRUNE_BENCH -o $PRUNE_TOOL -o -name '*.cc' -print | LC_ALL=C sort | sed "s,^$PREFIX/,," | tr "\n" " "`
+ 
+ set +f # re-enable globbing
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 8c7a8dc..10eb27e 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 0001-configure.ac_use_PIC.patch
 0002-rename-libbitcoinconsensus-to-libdogecoinconsensus.patch
+0003-reproducible-build.patch


signature.asc
Description: Digital signature

Bug#824703: file: magic entry to recognize Matlab V5 files

[Christoph Biedl]

tags 824703 moreinfo
thanks

Stephen Crowley wrote...

> please add the following entries to recognize Matlab V5/V4 file
> formats which are documented at 
> 
> https://maxwell.ict.griffith.edu.au/spl/matlab-page/matfile_format.pdf
> 
> 0x7e string IM Matlab V5
> 0x7e string MI Matlab V5

There already are some rules for Matlab in magic/Magdir/mathematica,
and they've been around for years:

| 0   string  MATLAB  Matlab v5 mat-file
| >126short   0x494d  (big endian)
| >>124   beshort x   version 0x%04x
| >126short   0x4d49  (little endian)
| >>124   leshort x   version 0x%04x

If they don't match your files, I'm interested in these, hex dump of
the first 256 byte was enough.

Christoph



signature.asc
Description: Digital signature

Bug#815639: geary: Geary won't start

[Kristof Csillag]

Package: geary
Version: 0.11.1-1
Followup-For: Bug #815639

I am still having the same problem.

When trying to launch geary:


(geary:16053): GLib-GIO-ERROR **: Settings schema 'org.yorba.geary' does not 
contain a key named 'composer-pane-position'
Trace/breakpoint trap


. and then it exits.

   Kristof


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

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

Versions of packages geary depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.22.0-1
ii  gnome-keyring3.14.0-1+b1
ii  kwalletmanager   4:4.14.2-1
ii  libc62.22-13
ii  libcairo21.14.0-2.1+deb8u1
ii  libcanberra0 0.30-3
ii  libgcr-base-3-1  3.14.0-2
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libgee-0.8-2 0.18.0-2
ii  libglib2.0-0 2.48.1-1
ii  libgmime-2.6-0   2.6.20-1+b1
ii  libgtk-3-0   3.20.6-2
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libsecret-1-00.18.5-1
ii  libsqlite3-0 3.13.0-1
ii  libwebkitgtk-3.0-0   2.4.11-2
ii  libxml2  2.9.3+dfsg1-1.2

geary recommends no packages.

geary suggests no packages.

-- debconf-show failed

Bug#827473: ostree: FTBFS on mipsel: "ostree pull" sometimes gets SIGBUS, SIGSEGV

[Simon McVittie]

On Wed, 29 Jun 2016 at 12:30:40 +, Radovan Birdic wrote:
> I tried to build ostree package on three different machines for mipsel
> architecture: Cavium, Loongson and Broadcom.

Thanks, much appreciated!

What specific CPU/sub-architecture/whatever are these machines? I'm
assuming that saying you have a Broadcom mipsel CPU is like saying you
have an AMD x86 CPU, rather than like saying it's a specific model of
Athlon or whatever?

I've seen "ostree pull" failing on the Debian mipsel porterbox
etler.debian.org, which has /proc/cpuinfo like this:

system type : loongson-ls3a-rs780e-1w
machine : Unknown
processor   : 0
cpu model   : ICT Loongson-3 V0.5  FPU V0.1
BogoMIPS: 718.84
wait instruction: no
microsecond timers  : yes
tlb_entries : 64
extra interrupt vector  : no
hardware watchpoint : yes, count: 0, address/irw mask: []
isa : mips1 mips2 mips3 mips4 mips5 mips32r1 mips64r1
ASEs implemented:
shadow register sets: 1
kscratch registers  : 0
package : 0
core: 0
VCED exceptions : not available
VCEI exceptions : not available

(and three more identical cores)

The official buildd where this has been failing is eberlin.debian.org,
which is described as "LS3A-RS780-1w (Quad Core Loongson 3A)" on
. Ordinary developers
can't log in to buildd machines, but the description on
 also says LS3A-RS780-1w,
so eberlin's /proc/cpuinfo would probably look the same.

> On Broadcom machine, following tests fails:
> test-basic.sh - on every run
> > ERROR: tests/test-basic.sh - too few tests run (expected 57, got 55)
> > ERROR: tests/test-basic.sh - exited with status 1
> test-pull-c - occasionally
> > ERROR: tests/test-pull-c - too few tests run (expected 2, got 1)
> > ERROR: tests/test-pull-c - exited with status 138 (terminated by signal 10?)

Those errors are not enough information to be useful or diagnostic. Please
could you attach the detailed logs from a failing run? That either means
test-suite.log, or the individual test logs from the failing tests
(tests/test-basic.sh.log and tests/test-pull-c.log in this case).

If you run the tests with VERBOSE=1 in the environment, they'll write
test-suite.log to stdout/stderr, somewhat later than the ERROR lines
you quoted. That's what appears if the tests fail during a package build,
or in the official Debian buildd logs like

(search for ".. contents::" to find logs similar to the ones I'd
need to see).

(This is standard Automake behaviour, not OSTree-specific.)

If you can get anything useful from a core dump - for instance
a useful backtrace - that would also be really helpful.

Thanks,
S

Bug#827186: Fwd: Bug#827186: links2: Setting "-only-proxies 1" also sets "-http.fake-firefox 1" unconditionally

[Mikulas Patocka]

On Wed, 29 Jun 2016, Axel Beckert wrote:

> Hi,
> 
> Mikulas Patocka wrote:
> > > Given your confirmation that the behaviour itself is intended, I think
> > > the "-only-proxies" option is definitely misnamed as it does not have
> > > "tor" in its name anywhere and its current name suggests something
> > > different than it does..
> > > 
> > >   Regards, Axel
> > 
> > The fact that this option is for tor is mentioned in the dialog box:
> 
> Yes, it mentions tor there, but not much more.
> 
> >   "[X] Connect only via proxies or Socks (useful for tor)"
> > and in the manual page:
> >   -only-proxies <0>/<1>
> >  (default 0)
> >   "1" causes that Links won't initiate any non-proxy connection.
> >   It is useful for anonymization with tor or similar networks.
> 
> "useful for" doesn't say anywhere that it overrides the UA setting
> unconditionally and something different that "only useful for tor" or
> "only meant to be used for anonymizing proxies like tor".
> 
> > Command line options should be small, I don't think it's necessary to 
> > extend the option name to be longer.
> 
> What about "-only-tor"? or even "-use-tor". That would be even
> shorter. (But yes, it probably suggests too much.) So what about
> "-anon" or "-anonymize"? That'd hopefully be generic enough that
> people read the man page for details.

That could break existing users' scripts.

I think it is not really needed to change that, there is just one bug 
report about that.

Mikulas

> IMHO at least the description should be extended and clarified to
> avoid irritated bug reports like this.
> 
>   Regards, Axel

Bug#828970: ITP: singularity -- application containerization platform

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist

* Package name: singularity
  Version : 2.0
  Upstream Author : Gregory M. Kurtzer
* URL : http://singularity.lbl.gov
* License : BSD
  Programming Lang: C
  Description : application containerization platform


Singularity is a container platform focused on supporting "Mobility of Compute".
.
Mobility of Compute encapsulates the development to compute model where
developers can work in an environment of their choosing and creation and when
the developer needs additional compute resources, this environment can easily
be copied and executed on other platforms. Additionally as the primary use case
for Singularity is targeted towards computational portability, many of the
barriers to entry of other container solutions do not apply to Singularity
making it an ideal solution for users (both computational and
non-computational) and HPC centers.

Package name (singularity) conflicts with a game package last released in
2011 with notable popcon of 300... so I guess I would need to come up with an
alternative name, e.g.

singularity-containers

Alternative recommendations are welcome!

Bug#828953: mxt-app FTBFS on 32bit architectures (i386, mips) on testing

[Nick Dyer]

Upstream fix in https://github.com/atmel-maxtouch/mxt-app/commit/da412c8b92867

Do you want me to tag it?

cheers

Nick

Bug#810030: disque: FTBFS on big-endian systems

[Chris Lamb]

forwarded 810032 https://github.com/antirez/disque/issues/186
thanks

@juricast filed this upstream.


Regards,

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

Bug#810032: disque: FTBFS on kFreeBSD: TCP_KEEP* undeclared

[Chris Lamb]

forwarded 810032 https://github.com/redis/hiredis/pull/254
thanks

Hi,

I've forwarded this issue upstream here:

 https://github.com/redis/hiredis/pull/254

It just needs a third-party code-copy sync.  


Regards,

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

Bug#769080: new Evince without title

[Harald Dunkel]

Hi Jason,

On 06/28/16 17:51, Jason Crain wrote:
> 
> As a workaround, someone running into this problem on fvwm can try
> editing ~/.fvwm2rc and removing the MWMDecor option to have fvwm ignore
> the mwm flags.
> 

That works.

Style   Evince  !MWMDecor

did the trick. Resizing the window works too.


Thanx very much
Harri

Bug#828902: utidylib: please update for new tidy-html5

[Michal Čihař]

Hi

Dne 28.6.2016 v 22:25 Gianfranco Costamagna napsal(a):
> please update the runtime dependency to the new tidy lib, I hope the binding 
> will still work

No, it doesn't, it segfaults, so the API has probably changed somewhere.
Is there upstream documentation on changes between original libtidy and
this fork?

> diff -Nru utidylib-0.2/debian/changelog utidylib-0.2/debian/changelog
> --- utidylib-0.2/debian/changelog 2014-02-23 13:54:41.0 +
> +++ utidylib-0.2/debian/changelog 2016-06-28 20:18:06.0 +
> @@ -1,3 +1,9 @@
> +utidylib (0.2-9.1) unstable; urgency=medium
> +
> +  * Use libtidy5 as runtime dependency.
> +
> + -- Gianfranco Costamagna   Tue, 28 Jun 2016 
> 22:04:19 +0200
> +
> utidylib (0.2-9build1) trusty; urgency=medium
> 
> * Rebuild to drop files installed into /usr/share/pyshared.
> diff -Nru utidylib-0.2/debian/control utidylib-0.2/debian/control
> --- utidylib-0.2/debian/control   2013-10-31 09:05:33.0 +
> +++ utidylib-0.2/debian/control   2016-06-28 20:16:58.0 +
> @@ -12,7 +12,7 @@
> 
> Package: python-utidylib
> Architecture: all
> -Depends: ${python:Depends}, ${misc:Depends}, libtidy-0.99-0 (>= 20051018)
> +Depends: ${python:Depends}, ${misc:Depends}, libtidy5
> Provides: ${python:Provides}
> Breaks: ${python:Breaks}
> Description: Python wrapper for TidyLib
> 
> I'll NMU/Team upload shortly if this blocks the transition.

Please don't do that unless you fix the code to work with new library as
well.

PS: Removing patch tag as the patch is obviously incomplete.

-- 
Michal Čihař | http://cihar.com/ | https://weblate.org/



signature.asc
Description: OpenPGP digital signature

Bug#828972: isc-dhcp-server: segmentation fault in ddns.c during ipv6 DDNS updates

[Alessandro Nozzoli]

Package: isc-dhcp-server
Version: 4.3.1-6+deb8u2
Severity: important
Tags: ipv6

Dear Maintainer,


After a random time depending on the amount of DDNS updates requested, a 
SEGV signo is

issued, causing the daemon to exit.

The core analysis reports:

Core was generated by `/usr/sbin/dhcpd -f -d -6 -cf 
/etc/dhcp/dhcpd6.conf -pf /var/run/dhcpd6.pid eth3'.

Program terminated with signal SIGSEGV, Segmentation fault.

(gdb) backtrace
#0  data_string_forget (data=data@entry=0x30, 
file=file@entry=0x7fcc65ece222 "ddns.c", line=line@entry=1780) at 
alloc.c:1281
#1  0x7fcc65e942a2 in ddns_cb_free (ddns_cb=0x30, 
file=file@entry=0x7fcc65ece222 "ddns.c", line=line@entry=1780) at 
dns.c:584
#2  0x7fcc65e78ed9 in ddns_removals (lease=lease@entry=0x0, 
lease6=lease6@entry=0x7fcc663dbd90, add_ddns_cb=add_ddns_cb@entry=0x0,

active=active@entry=isc_boolean_false) at ddns.c:1780
#3  0x7fcc65e875c7 in move_lease_to_inactive 
(pool=pool@entry=0x7fcc66202690, lease=lease@entry=0x7fcc663dbd90, 
state=state@entry=3 '\003')

at mdb6.c:1499
#4  0x7fcc65e88f50 in expire_lease6 (leasep=0x7ffedfa76928, 
pool=0x7fcc66202690, now=1467201107) at mdb6.c:1550
#5  0x7fcc65e8983f in lease_timeout_support (vpool=0x7fcc66202690) 
at mdb6.c:1916
#6  0x7fcc65e9320d in isclib_timer_callback (taskp=, 
eventp=0x7fcc66055070) at dispatch.c:174
#7  0x7fcc654becba in isc.taskmgr_dispatch () from 
/lib/x86_64-linux-gnu/libisc-export.so.95
#8  0x7fcc654c2136 in ?? () from 
/lib/x86_64-linux-gnu/libisc-export.so.95
#9  0x7fcc654c2c83 in ?? () from 
/lib/x86_64-linux-gnu/libisc-export.so.95

#10 0x7fcc65e93351 in dispatch () at dispatch.c:114
#11 0x7fcc65e48a1b in main (argc=, argv=out>) at dhcpd.c:804



The last lines in logfile are:

Added reverse map from 
3.6.2.e.1.0.0.0.0.0.0.0.0.0.0.0.5.0.0.1.5.0.c.2.0.6.7.0.1.0.0.2.ip6.arpa. 
to Marco-PC.lesc-ipv6

ddns.c(1278): Lease 2001:760:2c05:1005::1:e263 not found within pool.
Added reverse map from 
3.6.2.e.1.0.0.0.0.0.0.0.0.0.0.0.5.0.0.1.5.0.c.2.0.6.7.0.1.0.0.2.ip6.arpa. 
to Marco-PC.lesc-ipv6

ddns.c(1278): Lease 2001:760:2c05:1005::1:e263 not found within pool.
Renew message from fe80::4c7f:ea08:2dfd:fd6b port 546, transaction ID 
0x14ED6700
Reply NA: address 2001:760:2c05:1005::1:b609 to client with duid 
00:01:00:01:1b:30:89:53:e0:3f:49:86:cd:8f iaid = 518012745 valid for 
1800 seconds
ddns.c(1552): Failed to update internal lease structure with DDNS 
control block. Existing ddns_cb structure does not match 
expectations.IPv6=2001:760:2c05:1005::1:b609, old 
ddns_cb=0x7fcc66594320, triedto update to new ddns_cb=0x7fcc66594320

Sending Reply to fe80::4c7f:ea08:2dfd:fd6b port 546
Added new forward map from biancone.lesc-ipv6 to 
2001:760:2c05:1005::1:b609
Added reverse map from 
9.0.6.b.1.0.0.0.0.0.0.0.0.0.0.0.5.0.0.1.5.0.c.2.0.6.7.0.1.0.0.2.ip6.arpa. 
to biancone.lesc-ipv6

ddns.c(1278): Lease 2001:760:2c05:1005::1:b609 not found within pool.
Renew message from fe80::215:99ff:fe4b:1d8a port 546, transaction ID 
0xB83DD500
Discarding Renew from fe80::215:99ff:fe4b:1d8a; not our server 
identifier (CLIENTID 00:03:00:01:00:15:99:4b:1d:8a, SERVERID 
00:01:00:01:1d:6f:00:8c:00:50:56:00:00:03, server DUID 
00:01:00:01:1f:06:43:6b:00:50:56:00:00:03)
Renew message from fe80::215:99ff:fe4b:1d8a port 546, transaction ID 
0xB83DD500
Discarding Renew from fe80::215:99ff:fe4b:1d8a; not our server 
identifier (CLIENTID 00:03:00:01:00:15:99:4b:1d:8a, SERVERID 
00:01:00:01:1d:6f:00:8c:00:50:56:00:00:03, server DUID 
00:01:00:01:1f:06:43:6b:00:50:56:00:00:03)

Errore di segmentazione (core dump creato)


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=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 isc-dhcp-server depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  debianutils4.4+b1
ii  isc-dhcp-common4.3.1-6+deb8u2
ii  libc6  2.19-18+deb8u4
ii  libdns-export100   1:9.9.5.dfsg-9+deb8u6
ii  libirs-export911:9.9.5.dfsg-9+deb8u6
ii  libisc-export951:9.9.5.dfsg-9+deb8u6
ii  lsb-base   4.1+Debian13+nmu1

isc-dhcp-server recommends no packages.

Versions of packages isc-dhcp-server suggests:
pn  isc-dhcp-server-ldap  

-- Configuration Files:
/etc/dhcp/dhcpd.conf changed:
ddns-update-style standard;
ddns-updates on;
key dhcpupdateV4 {
  algorithm hmac-md5;
  secret "/suLcXaBX/DnNSTE7OdqmA==";
};
option domain-name-servers 10.108.1.2;
option netbios-name-servers 10.108.1.4;
option subnet-mask 255.255.255.0;
option time-servers 150.217.4.5;
default-lease-time 21600;
max-lease-time 43200;
authoritative;
log-facility local4;
subnet 10.108.1.0 netmask 255.255.255.0 {
  range 10.108.1.200 10.108.1.249;
  option domain-name "lesc-lart";
  opti

Bug#828973: Kernel crash with older QLogic Fibre Channel cards

[Janusz Dziemidowicz]

Package: linux-image-4.6.0-1-amd64
Version: 4.6.2-2

Kernel crashes as soon as qla2xxx driver is loaded (and using older
QLogic Fibre Channel card without MSI-X support). This was already
reported in Ubuntu [1] and LKML [2]. There is a very simple patch
available on LKML.
The author of the patch was supposed to submit it upstream, but it
still didn't happen. Given that this makes servers with older QLogic
cards unusable since 4.5.0 maybe it can be applied in Debian.

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1554003
[2] https://lkml.org/lkml/2016/4/11/888

-- 
Janusz Dziemidowicz

Bug#824804: update-rc.d: may invoke insserv without -f flag when initscripts is installed but not configured

[Felipe Sateler]

On 28 June 2016 at 06:13, Martin Pitt  wrote:
> Control: tag -1 pending
>
> Hello Felipe,
>
> CC'ing Andreas for the util-linux part.
>
> Felipe Sateler [2016-05-19 17:57 -0400]:
>> update-rc.d currently has support for invoking insserv with the -f flag,
>> to allow initscripts-less installations. This should allow packages to drop
>> dependencies on the initscripts package. However, this does not work if the
>> dependency is dropped, because now apt/dpkg can choose to configure the
>> package before it configures initscripts. This leads to the situation that
>> /etc/init.d/mountkernfs.sh exists (and thus invoke-rc.d does not pass -f 
>> flag),
>> but the links in /etc/rc?.d/S??mountkernfs.sh are not created yet, and then
>> insserv fails.
>
> I have some trouble reproducing this. In a schroot without initscipts,
> when I do
>
>   dpkg --unpack initscripts_2.88dsf-59.7_amd64.deb
>
> then there's only /etc/init.d/mountkernfs.sh.dpkg-new, as the
> conffiles are only moved into place at configure time, not at unpack
> time yet. And on upgrades the script and the previous rc?.d links
> should already be in place.
>
> So could it be that this is limited to debootstrap as that might just
> directly unpack conffiles instead of installing them as *.dpkg-new on
> unpack? This would make sense for debootstrap as that isn't concerned
> about upgrades.
>
> With this synthetic test I can reproduce it:
>
>   apt-get download initscripts
>   dpkg --unpack initscripts_*.deb
>   mv /etc/init.d/mountkernfs.sh{.dpkg-new,}
>   update-rc.d hwclock.sh defaults
>
>> 2. Extend the check to the links (ie, check if
>>`glob /etc/rc?.d/S??mountkernfs.sh` is not empty.
>
> I agree that this seems to be the best solution for now. Checkin for
> /etc/init.d/mountkernfs.sh was supposed to be a test for "initscripts
> is installed", but as you found it is only a sufficient test for
> "initscripts is unpacked".
>
> So I think this is mostly just limited to debootstrap and thus
> util-linux. But I'd indeed prefer if we do this in update-rc.d and
> drop the workaround from util-linux again.
>
>> 3. Consult the dpkg database via dpkg-query to determine if initscripts has 
>> been
>>configured
>
> Sounds fine as well, but more expensive than globbing, and actually
> not quite trivial either. "dpkg-query --showformat='${Status}' --show"
> needs parsing and has a trap as its package arguments are patterns,
> not fixed names. And "dpkg-query --status" would also need a
> non-trivial (but still simple, however) grep.
>
> So I committed this now:
>
>   
> http://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=14008bd4a
>
> I tested this with three scenarios (no initscripts, unpacked
> initscripts, configured initscripts) in a schroot and it now works
> fine. Does that sound ok to you?

I was very confused by this mail. We had already committed this same
fix in 79a4036f (in 1.34), so I wondered why was this still a problem.
Turns out the patch I applied on c167d9498a inadvertently reverted the
change :/

So, +1 from me.

-- 

Saludos,
Felipe Sateler

Bug#818757: [Debian-med-packaging] Bug#818757: orthanc-postgresql: does not start

[Sebastien Jodogne]

>> After downloading the source code of each package, create a "Build"
>> directory inside, and run:
>>
>> # cmake .. -DSTATIC_BUILD=ON -DCMAKE_BUILD_TYPE=Debug
>> # make
>
> Attached a full backtrace of a stock Debian Orthanc 1.1.0
> with o-pg 2.0 (it is lacking symbols so might be of limited
> use).

Thanks, but unfortunately, this log does not show anything useful for 
debugging because of the lack of symbols.


Couldn't you try and statically link Orthanc and Orthanc-PG in debug 
mode following the commands written above? Or, at least, compile the 
Debian package from source and modify the "debian/rules" so as to add 
"-DCMAKE_BUILD_TYPE=Debug"?


Also, do you remember which versions of Orthanc and Orthanc-PG generated 
the database you try and upgrade?



> Any chance a -dbgsyms package can be provided ?

I have no idea of how this can be done in Debian together with CMake; I 
am unable to understand the wiki [1]. Furthermore, besides keeping the 
symbols, it would be really important to compile in Debug mode, 
otherwise the trace would be very hard to understand.


Sébastien-


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

Bug#828971: clasp: please make the build reproducible

[Reiner Herrmann]

Source: clasp
Version: 3.1.4-2
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that clasp could not be built reproducibly.
A list of source files is not sorted, which causes a non-deterministic
linking order.

The attached patch fixes this.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible-build.patch b/debian/patches/reproducible-build.patch
new file mode 100644
index 000..8e840d1
--- /dev/null
+++ b/debian/patches/reproducible-build.patch
@@ -0,0 +1,14 @@
+Author: Reiner Herrmann 
+Description: Sort source files for deterministic linking order
+
+--- a/tools/Base.in
 b/tools/Base.in
+@@ -6,7 +6,7 @@
+ AR   ?= ar
+ -include .CONFIG
+ -include $(FLAGS)
+-SOURCES  := $(patsubst $(SOURCE_DIR)/%.cpp,%.cpp,$(wildcard $(SOURCE_DIR)/*.cpp))
++SOURCES  := $(patsubst $(SOURCE_DIR)/%.cpp,%.cpp,$(sort $(wildcard $(SOURCE_DIR)/*.cpp)))
+ ifeq ($(OUT_DIR),)
+ DEPS := $(patsubst %.cpp,%.dep, $(SOURCES))
+ OBJECTS  := $(patsubst %.cpp,%.o, $(SOURCES))
diff --git a/debian/patches/series b/debian/patches/series
index c78dfaa..9fd6edb 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 clasp-manpage.patch
 clasp-parallel-solve.patch
+reproducible-build.patch


signature.asc
Description: Digital signature

Bug#828974: ITP: svgwriter -- Python library for creating SVG images

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: svgwriter
  Version : 1.1.8
* URL : https://pypi.python.org/pypi/svgwrite/
* License : MIT/X
  Programming Lang: Python
  Description : Python library for creating SVG images

It is a about to appear in the python-modules repository,
Just waiting for this ITP number :o)

Bug#828902: utidylib: please update for new tidy-html5

[Gianfranco Costamagna]

control: tags -1 -patch

>No, it doesn't, it segfaults, so the API has probably changed somewhere.
>Is there upstream documentation on changes between original libtidy and
>this fork?


I'm ccing the maintainer, I have no knowledge on this matter.


cheers,

G.

Bug#828946: krb5: FTBFS in testing (LaTeX Error: File `iftex.sty' not found)

[Santiago Vila]

On Wed, Jun 29, 2016 at 08:32:08AM -0400, Sam Hartman wrote:
> For my notes, iftex.sty is in texlive-generic-extra on my system.
> I did the most recent build for sid in a chroot including the arch all
> packages, so it's more likely to be something changing than a
> then-missing-build-dep-indep, but I'll take a look while at Debconf.

For the record, I have a successful build log from 2016-06-05 for
exactly the same version 1.14.2+dfsg-1, which is certainly strange
because texlive-generic-extra is not in any of the build-depends.

While we are at it, both "dpkg-buildpackage -B" and "dpkg-buildpackage -A"
seem to work ok for this package. If you switch to make your uploads
as source-only (using "dpkg-buildpackage -S") we would get beautiful
and official build logs for archs "amd64" and "all" here:

https://buildd.debian.org/status/package.php?p=krb5

Thanks.

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

[Thomas Goirand]

On 06/29/2016 11:24 AM, Moritz Muehlenhoff wrote:
> Hi Thomas,
> https://bugs.launchpad.net/bugs/1567673 has been assigned CVE-2016-4428 and I 
> think we should fix
> it in jessie-security. Can you please prepare an update? unstable also needs 
> the patch.
> 
> Cheers,
> Moritz
> 

Hi Moritz,

I have uploaded fixes for both Sid and Experimental, and the fix for
Stable is committed to Git in here:

http://anonscm.debian.org/cgit/openstack/horizon.git/commit/?h=debian/icehouse&id=d74e751ce93f03240f3ad4206e93d6e7e05da55f

Since you may prefer a diff to read from your mail client, I have
attached it to this message.

I also uploaded the built package here:
http://sid.gplhost.com/jessie-proposed-updates/horizon/

Please allow me to upload it.

Cheers,

Thomas Goirand (zigo)

From d74e751ce93f03240f3ad4206e93d6e7e05da55f Mon Sep 17 00:00:00 2001
From: Thomas Goirand 
Date: Wed, 29 Jun 2016 15:28:37 +0200
Subject:   * CVE-2016-4428: Possible client side template injection in
 horizon. Applied upstream patch: "Escape angularjs templating in unsafe
 HTML" after rebasing it for Icehouse (Closes: #828967).

---
 debian/changelog   |  8 +++
 ...Escape_angularjs_templating_in_unsafe_HTML.patc | 74 ++
 debian/patches/series  |  1 +
 3 files changed, 83 insertions(+)
 create mode 100644 debian/patches/CVE-2016-4428_Escape_angularjs_templating_in_unsafe_HTML.patc

diff --git a/debian/changelog b/debian/changelog
index 9c30c37..276e48e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+horizon (2014.1.3-7+deb8u2) jessie-security; urgency=medium
+
+  * CVE-2016-4428: Possible client side template injection in horizon. Applied
+upstream patch: "Escape angularjs templating in unsafe HTML" after rebasing
+it for Icehouse (Closes: #828967).
+
+ -- Thomas Goirand   Wed, 29 Jun 2016 15:24:16 +0200
+
 horizon (2014.1.3-7+deb8u1) jessie-security; urgency=high
 
   * Fix CVE-2015-3219 with upstream patch (Closes: 788306).
diff --git a/debian/patches/CVE-2016-4428_Escape_angularjs_templating_in_unsafe_HTML.patc b/debian/patches/CVE-2016-4428_Escape_angularjs_templating_in_unsafe_HTML.patc
new file mode 100644
index 000..f626e46
--- /dev/null
+++ b/debian/patches/CVE-2016-4428_Escape_angularjs_templating_in_unsafe_HTML.patc
@@ -0,0 +1,74 @@
+Description: CVE-2016-4428: Escape angularjs templating in unsafe HTML
+ This code extends the unsafe (typically user-supplied) HTML escape
+ built into Django to also escape angularjs templating markers. Safe
+ HTML will be unaffected.
+Bug-Ubuntu: https://launchpad.net/bugs/1567673
+Bug-Debian: https://bugs.debian.org/828967
+Origin: upstream, https://review.openstack.org/#/c/329997/
+Change-Id: I0cbebfd0f814bdf1bf8c06833abf33cc2d4748e7
+Author: Richard Jones 
+Date: Tue, 3 May 2016 05:51:49 + (+1000)
+X-Git-Url: https://review.openstack.org/gitweb?p=openstack%2Fhorizon.git;a=commitdiff_plain;h=d585e5eb9acf92d10d39b6c2038917a7e8ac71bb
+Last-Update: 2016-06-29
+
+--- /dev/null
 horizon-2014.1.3/horizon/utils/escape.py
+@@ -0,0 +1,31 @@
++# Copyright 2016, Rackspace, US, Inc.
++#
++# Licensed under the Apache License, Version 2.0 (the "License");
++# you may not use this file except in compliance with the License.
++# You may obtain a copy of the License at
++#
++#http://www.apache.org/licenses/LICENSE-2.0
++#
++# Unless required by applicable law or agreed to in writing, software
++# distributed under the License is distributed on an "AS IS" BASIS,
++# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
++# See the License for the specific language governing permissions and
++# limitations under the License.
++
++import django.utils.html
++
++
++def escape(text, existing=django.utils.html.escape):
++# Replace our angular markup string with a different string
++# (which just happens to be the Django comment string)
++# this prevents user-supplied data from being intepreted in
++# our pages by angularjs, thus preventing it from being used
++# for XSS attacks. Note that we use {$ $} instead of the
++# standard {{ }} - this is configured in horizon.framework
++# angularjs module through $interpolateProvider
++return existing(text).replace('{$', '{%').replace('$}', '%}')
++
++
++# this will be invoked as early as possible in settings.py
++def monkeypatch_escape():
++django.utils.html.escape = escape
+--- horizon-2014.1.3.orig/openstack_dashboard/settings.py
 horizon-2014.1.3/openstack_dashboard/settings.py
+@@ -27,6 +27,10 @@ from django.utils.translation import uge
+ 
+ from openstack_dashboard import exceptions
+ 
++from horizon.utils.escape import monkeypatch_escape
++
++monkeypatch_escape()
++
+ warnings.formatwarning = lambda message, category, *args, **kwargs: \
+ '%s: %s' % (category.__name__, message)
+ 
+--- horizon-2014.1.3.orig/openstack_dashboard/test/settings.py
 horizon-2014.1.3/o

Bug#828976: krb5kdc: segfault

[BASTET Laurent (Administrateur de systèmes et réseaux au sein du groupe Infrastructure et Réseau) - SG/SPSSI/CPII/DOIP/IR/Infrastructure Bordeaux]

Package: krb5-kdc
Version: 1.12.1+dfsg-19+deb8u2
Release: Jessie

In /etc/krb5kdc/kdc.conf, i enable otp plugin 
(http://web.mit.edu/Kerberos/krb5-1.13/doc/admin/otp.html)


If i want to personalize my otp type putting a string on my principal 
which is different from empty [{}] ( in kadmin : setstr user otp 
[{"type":"foo"}] ) i obtain a kinit error and a segfault :


user@xx:~# kinit -T /tmp/krb5cc_0
Enter OTP Token Value:
kinit: Cannot contact any KDC for realm 'SEN.CENTRE-SERVEUR.I2' while 
getting initial credentials



And in the kdc logs :

Jun 29 13:15:32 xx kernel: [92474.284528] krb5kdc[23842]: segfault 
at fff0 ip 7f35d95e1b80 sp 7ffd4b307cf8 error 5 in 
libkrb5support.so.0.1[7f35d95db000+b000]
Jun 29 13:15:32 xx systemd[1]: krb5-kdc.service: main process 
exited, code=killed, status=11/SEGV
Jun 29 13:15:32 xx systemd[1]: Unit krb5-kdc.service entered failed 
state.


Regards

--
Laurent BASTET

Bug#788758: Pending fixes for bugs in the libnet-route-perl package

[pkg-perl-maintainers]

tag 788758 + pending
thanks

Some bugs in the libnet-route-perl package are closed in revision
4bc786a92085204911c0207339500dc4b7bbd7b4 in branch '  bugfix/788758'
by intrigeri

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libnet-route-perl.git/commit/?id=4bc786a

Commit message:

0001-Survive-systems-with-an-empty-routing-table.patch, 
0002-Survive-systems-without-a-default-route.patch: new patches, to have the 
test suite survive systems with an empty routing table, or with no default 
route (Closes: #788758).

Bug#828926: [Freewx-maint] Bug#828926: wxwidgets3.0: FTBFS with gcc-6 and glibc 2.23

[Scott Talbert]

On Tue, 28 Jun 2016, Daniel Schepler wrote:


../src/stc/scintilla/src/Editor.cxx: In function 'bool Close(Point, Point)':
../src/stc/scintilla/src/Editor.cxx:5844:23: error: call of overloaded
'abs(XYPOSITION)' is ambiguous
 if (abs(pt1.x - pt2.x) > 3)
  ^


This upstream commit should fix it:
https://github.com/wxWidgets/wxWidgets/commit/73e9e18ea09caac50237def0d9728a213c02

Bug#788758: libnet-route-perl: FTBFS with an empty routing table

[intrigeri]

Hi gregor,

gregor herrmann wrote (21 Sep 2015 19:11:32 GMT):
> With cowbuilder and USENETWORK=no I'm seeing a different failure:

Can you please try and reproduce on the bugfix/788758 branch?

Cheers,
--
intrigeri

Bug#826022: Does not work with Django 1.8

[Dominique Belhachemi]

I am going to upload a new package tonight.
Upstream removed only the Python 2.6 support, Python 2.7 is still
supported, so I will keep the python2 package.

-Dominique

Bug#641730: pacemaker: attrd never updates CIB when attributes are updated more frequently than their timeout setting

[Ferenc Wágner]

Hi,

In my reading, the -d option works as documented.  Did you mean to
submit a feature request?  In that case, we'll have to open an upstream
issue for this.
-- 
Feri

Bug#828977: faust: please make the build reproducible

[Reiner Herrmann]

Source: faust
Version: 0.9.73~repack1-1
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that faust could not be built reproducibly.
Some lists of source files are not sorted, which leads to a
non-deterministic linking order.

The attached patch fixes this.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible-build.patch b/debian/patches/reproducible-build.patch
new file mode 100644
index 000..e4eb74a
--- /dev/null
+++ b/debian/patches/reproducible-build.patch
@@ -0,0 +1,54 @@
+Author: Reiner Herrmann 
+Description: Sort list of source files for deterministic linking order
+
+--- a/compiler/Makefile.unix
 b/compiler/Makefile.unix
+@@ -1,6 +1,6 @@
+ subprojects := boxes errors evaluate generator normalize parser propagate parallelize signals tlib draw draw/device draw/schema extended patternmatcher documentator utils
+ 
+-sources = $(wildcard *.cpp) $(wildcard */*.cpp) $(wildcard draw/*/*.cpp)
++sources = $(sort $(wildcard *.cpp) $(wildcard */*.cpp) $(wildcard draw/*/*.cpp))
+ 
+ objects = $(sources:.cpp=.o)
+ 
+--- a/architecture/osclib/faust/Makefile
 b/architecture/osclib/faust/Makefile
+@@ -1,5 +1,5 @@
+ subprojects := . src src/lib src/msg src/nodes src/osc src/threads ../..
+-sources = $(wildcard src/*.cpp) $(wildcard src/*/*.cpp) 
++sources = $(sort $(wildcard src/*.cpp) $(wildcard src/*/*.cpp))
+ objects = $(sources:.cpp=.o)
+ 
+ VPATH = $(subprojects)
+--- a/architecture/osclib/oscpack/Makefile
 b/architecture/osclib/oscpack/Makefile
+@@ -3,25 +3,25 @@
+ 
+ ifeq ($(system), Darwin)
+ subprojects := ip ip/posix osc
+-sources := $(wildcard ip/*.cpp)  $(wildcard ip/posix/*.cpp)  $(wildcard osc/*.cpp)
++sources := $(sort $(wildcard ip/*.cpp)  $(wildcard ip/posix/*.cpp)  $(wildcard osc/*.cpp))
+ #ARCHFLAGS 	:=  -arch i386 -arch x86_64
+ 
+ else 
+ ifeq ($(system), Linux)
+ subprojects := ip ip/posix osc
+-sources := $(wildcard ip/*.cpp)  $(wildcard ip/posix/*.cpp)  $(wildcard osc/*.cpp)
++sources := $(sort $(wildcard ip/*.cpp)  $(wildcard ip/posix/*.cpp)  $(wildcard osc/*.cpp))
+ ARCHFLAGS 	:= 
+ CXXFLAGS += -fPIC
+ 
+ else 
+ ifeq ($(system), GNU/kFreeBSD)
+ subprojects := ip ip/posix osc
+-sources := $(wildcard ip/*.cpp)  $(wildcard ip/posix/*.cpp)  $(wildcard osc/*.cpp)
++sources := $(sort $(wildcard ip/*.cpp)  $(wildcard ip/posix/*.cpp)  $(wildcard osc/*.cpp))
+ ARCHFLAGS 	:= 
+ 
+ else
+ subprojects := ip ip/win32 osc
+-sources := $(wildcard ip/*.cpp)  $(wildcard ip/win32/*.cpp)  $(wildcard osc/*.cpp)
++sources := $(sort $(wildcard ip/*.cpp)  $(wildcard ip/win32/*.cpp)  $(wildcard osc/*.cpp))
+ ARCHFLAGS 	:= 
+ endif
+ endif
diff --git a/debian/patches/series b/debian/patches/series
index c4914b4..b1ed196 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@ kFreeBSD
 unistd
 ldflags
 spelling
+reproducible-build.patch


signature.asc
Description: Digital signature

Bug#818757: Bug#818757: orthanc-postgresql: does not start

[Andreas Tille]

Hi Sebastien,

On Wed, Jun 29, 2016 at 03:28:53PM +0200, Sebastien Jodogne wrote:
> 
> > Any chance a -dbgsyms package can be provided ?
> 
> I have no idea of how this can be done in Debian together with CMake; I am
> unable to understand the wiki [1]. Furthermore, besides keeping the symbols,
> it would be really important to compile in Debug mode, otherwise the trace
> would be very hard to understand.

That's usually created automatically since a certain point of time if
you build the package.  I intended to verify this for
orthanc-postgresql_2.0 but get a build error. :-(

...
JsonCpp include dir: /usr/include/jsoncpp
-- Looking for C++ include /usr/include/jsoncpp/json/reader.h
-- Looking for C++ include /usr/include/jsoncpp/json/reader.h - found
-- Could NOT find PostgreSQL (missing:  PostgreSQL_TYPE_INCLUDE_DIR) (found 
version "9.5.3")
-- Looking for C++ include orthanc/OrthancCppDatabasePlugin.h
-- Looking for C++ include orthanc/OrthancCppDatabasePlugin.h - found
Setting the version of the libraries to 2.0
CMake Error: The following variables are used in this project, but they are set 
to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake 
files:
PostgreSQL_TYPE_INCLUDE_DIR (ADVANCED)
   used as include directory in directory /build/orthanc-postgresql-2.0
   used as include directory in directory /build/orthanc-postgresql-2.0
   used as include directory in directory /build/orthanc-postgresql-2.0
   used as include directory in directory /build/orthanc-postgresql-2.0
   used as include directory in directory /build/orthanc-postgresql-2.0
   used as include directory in directory /build/orthanc-postgresql-2.0
   used as include directory in directory /build/orthanc-postgresql-2.0
   used as include directory in directory /build/orthanc-postgresql-2.0
   used as include directory in directory /build/orthanc-postgresql-2.0

-- Configuring incomplete, errors occurred!
See also "/build/orthanc-postgresql-2.0/Build/CMakeFiles/CMakeOutput.log".
See also "/build/orthanc-postgresql-2.0/Build/CMakeFiles/CMakeError.log".
"tail -v -n +0 CMakeCache.txt"
==> CMakeCache.txt <==
# This is the CMakeCache file.
# For build in directory: /build/orthanc-postgresql-2.0/Build
...

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#828980: pyx3: FTBFS in testing (LaTeX Error: File `iftex.sty' not found)

[Santiago Vila]

Package: src:pyx3
Version: 0.14.1-2
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious

Dear maintainer:

This package currently fails to build in stretch:


[...]
make -C _build/latex all-pdf
make[3]: Entering directory '/<>/faq/_build/latex'
pdflatex  'pyxfaq.tex'
This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) 
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./pyxfaq.tex
LaTeX2e <2016/03/31> patch level 1
Babel <3.9r> and hyphenation patterns for 3 language(s) loaded.
(./sphinxmanual.cls
Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual)
(/usr/share/texlive/texmf-dist/tex/latex/base/report.cls
Document Class: report 2014/09/29 v1.4h Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)))

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


A full build log is available here:

https://tests.reproducible-builds.org/debian/rbuild/testing/amd64/pyx3_0.14.1-2.rbuild.log

Thanks.