date:20160327

Bug#819369: linux-image-4.4.0-1-amd64: kernel oops in DRM/Intel switching VTs triggered by light-locker

2016-03-27 Thread Ben Armstrong

Package: src:linux
Version: 4.4.6-1
Severity: normal

The second time I lock the display with light-locker, the attached
kernel oops reliably occurs for me. Apparently the VT switch does it,
as the oops matches this upstream report:

https://bugs.freedesktop.org/show_bug.cgi?id=93822

As reported in comment #5, it is fixed in 4.5 (tested with
linux-image-4.5.0-trunk-amd64). Also, the bug is not reproducible
with linux-image-4.3.0-1-amd64.

Since I have no other problems with 4.5, I'll just run that for now,
and I understand from talking to bwh on irc, it will enter unstable
soon anyway.

Thanks,
Ben Armstrong

-- Package-specific info:
** Version:
Linux version 4.4.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 
20160307 (Debian 5.3.1-11) ) #1 SMP Debian 4.4.6-1 (2016-03-17)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.4.0-1-amd64 
root=UUID=b7d082d8-c134-477f-8b6d-1fbadd46fad7 ro quiet quiet

** Tainted: DWO (4736)
 * Kernel has oopsed before.
 * Taint on warning.
 * Out-of-tree module has been loaded.

** Kernel log:
[   12.406974] VBoxPciLinuxInit
[   12.454817] vboxpci: IOMMU not found (not registered)
[   14.136197] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   14.211047] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   14.213508] atl1c :01:00.0: atl1c: eth0 NIC Link is Up<100 Mbps Full 
Duplex>
[   15.760715] ip_tables: (C) 2000-2006 Netfilter Core Team
[   15.874691] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   16.011731] Ebtables v2.0 registered
[  157.806058] systemd-journald[180]: File 
/var/log/journal/d7d5e9a4a98cebcc09ddeab8000f/user-1006.journal corrupted 
or uncleanly shut down, renaming and replacing.
[  229.406482] [ cut here ]
[  229.406578] WARNING: CPU: 0 PID: 1087 at 
/build/linux-dFNWCu/linux-4.4.6/include/linux/kref.h:46 
drm_framebuffer_reference+0x40/0x70 [drm]()
[  229.406731] Modules linked in: ebtable_filter ebtables ip6table_filter 
ip6_tables iptable_filter ip_tables x_tables pci_stub vboxpci(O) vboxnetadp(O) 
vboxnetflt(O) vboxdrv(O) cpufreq_powersave cpufreq_stats cpufreq_userspace 
cpufreq_conservative hid_logitech_hidpp hid_logitech_dj iTCO_wdt 
iTCO_vendor_support eeepc_wmi asus_wmi usbhid hid arc4 coretemp 
snd_hda_codec_realtek binfmt_misc snd_hda_codec_generic joydev serio_raw ath9k 
ath9k_common ath9k_hw ath snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep 
snd_pcm_oss snd_mixer_oss lpc_ich mac80211 mfd_core snd_pcm cfg80211 i915 
snd_timer snd drm_kms_helper soundcore shpchp drm wmi i2c_algo_bit battery ac 
sparse_keymap rfkill video acpi_cpufreq tpm_tis tpm button processor evdev 
uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core
[  229.406792]  v4l2_common videodev media sg cuse fuse loop autofs4 uas 
usb_storage ext4 crc16 mbcache jbd2 sd_mod psmouse ahci libahci libata scsi_mod 
ehci_pci uhci_hcd ehci_hcd usbcore atl1c usb_common thermal fjes
[  229.406806] CPU: 0 PID: 1087 Comm: Xorg Tainted: G   O
4.4.0-1-amd64 #1 Debian 4.4.6-1
[  229.406810] Hardware name: ASUSTeK Computer INC. 1001PX/1001PX, BIOS 0601
04/30/2010
[  229.406824]  0286 82bdce6e 812ea865 

[  229.406836]  a036a7e8 810774fd 88007876d280 
880045c93880
[  229.406846]  880045c93880 880079082000 8800367a5000 
a0342030
[  229.406849] Call Trace:
[  229.406870]  [] ? dump_stack+0x5c/0x77
[  229.406885]  [] ? warn_slowpath_common+0x7d/0xb0
[  229.406975]  [] ? drm_framebuffer_reference+0x40/0x70 [drm]
[  229.407063]  [] ? drm_atomic_set_fb_for_plane+0x28/0x80 
[drm]
[  229.407108]  [] ? 
__drm_atomic_helper_set_config+0xd9/0x3c0 [drm_kms_helper]
[  229.407146]  [] ? restore_fbdev_mode+0x215/0x250 
[drm_kms_helper]
[  229.407235]  [] ? drm_modeset_lock_all_crtcs+0x87/0xa0 
[drm]
[  229.407278]  [] ? 
drm_fb_helper_restore_fbdev_mode_unlocked+0x2e/0x70 [drm_kms_helper]
[  229.407318]  [] ? drm_fb_helper_set_par+0x29/0x50 
[drm_kms_helper]
[  229.407475]  [] ? intel_fbdev_set_par+0x16/0x60 [i915]
[  229.407489]  [] ? sock_poll+0x100/0x110
[  229.407503]  [] ? fb_set_var+0x208/0x400
[  229.407515]  [] ? do_sys_poll+0x146/0x560
[  229.407529]  [] ? update_curr+0xb6/0x130
[  229.407540]  [] ? enqueue_entity+0x359/0x9b0
[  229.407554]  [] ? fbcon_blank+0x2f1/0x330
[  229.407564]  [] ? __switch_to_xtra+0x194/0x1b0
[  229.407579]  [] ? do_unblank_screen+0xd8/0x1a0
[  229.407592]  [] ? complete_change_console+0x54/0xd0
[  229.407603]  [] ? vt_ioctl+0x6d8/0x1290
[  229.407697]  [] ? drm_ioctl+0x162/0x4c0 [drm]
[  229.407716]  [] ? tty_ioctl+0x33c/0xbf0
[  229.407729]  [] ? set_next_entity+0x71/0x830
[  229.407739]  [] ? __switch_to_xtra+0x194/0x1b0
[  229.407748]  [] ? __switch_to+0x3f9/0x570
[  229.407758]  [] ? do_vfs_ioctl+0x2ae/0x490
[  229.407771]  [] ? __schedule+0x2e8/0x950
[  229.407782]  [] ? SyS_ioctl+0x74/0x80
[  229.407792]  [] ? SyS_poll+0x6b/0x120
[  229.407803]  [] ? system_call_fast_compare_end+0xc/0x67

Bug#819370: rdiff-backup: does not follow symlinks to directories given on the command line

2016-03-27 Thread Christian Pernegger

Package: rdiff-backup
Version: 1.2.8-7
Severity: normal

Hi,

I'm trying to backup a path that ends in a symlink (pointing to a
directory) *from* a remote machine. This fails on the remote side:

Fatal Error: Source /.snapshots/latest is not a directory

(Note that adding a trailing slash to the argument does not change the
error message at all, i.e., it gets stripped off somewhere.)

This is similar to #206252, except that's ancient and supposedly
fixed.

Regards,
Christian



-- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: armhf (armv7l)

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

Versions of packages rdiff-backup depends on:
ii  libc6  2.22-3
ii  librsync1  0.9.7-10
ii  python 2.7.11-1
ii  python2.7  2.7.11-4

Versions of packages rdiff-backup recommends:
pn  python-pylibacl  
pn  python-pyxattr   

rdiff-backup suggests no packages.

-- no debconf information

Bug#806608: cjk: FTBFS when built with dpkg-buildpackage -A (mkdir: cannot create directory)

2016-03-27 Thread Santiago Vila

On Mon, 30 Nov 2015, Danai SAE-HAN (韓達耐) wrote:

> Hi Santiago
> Thanks for that bug report!  It looks like it doesn't clean up some folder.
> Let me try to run your commands on my PC at home this week, and see if I can 
> replicate it.

Actually, it is not lack of cleaning up:

dpkg-buildpackage calls the build targets and then the binary targets.

In the debian/rules for cjk, binary-indep depends on build-indep, so
when binary-indep is invoked, build-indep is executed again.

Because $(build_thaifonts) was already created the first time build-indep
was invoked, creating the directory again is what triggers the error.

Avoiding targets to be executed twice is precisely what stamp files
are used for. The attached patch (warning: not tested) might fix the problem.

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -35,7 +35,9 @@ unixdate := $(shell expr $(unixdate) + 86400 )

 build: $(QUILT_STAMPFN) build-stamp
-build-arch:
+build-arch: build-arch-stamp
+
+build-arch-stamp:
dh_testdir

# Update config.{guess,sub}
@@ -45,7 +47,9 @@ build-arch:

touch build-arch-stamp

-build-indep:
+build-indep: build-indep-stamp
+
+build-indep-stamp:
dh_testdir

mkdir $(build_thaifonts)

Bug#819368: konqueror: cannot browse HTTP anymore

2016-03-27 Thread Eduard Bloch

Package: konqueror
Version: 4:15.12.1-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

dist-uprade in sid

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

konqueror was still running, suddenly started reporting errors.
xsession-errors file said:
Could not open library '/usr/lib/kde4/kio_http.so'.
Cannot load library /usr/lib/kde4/kio_http.so:
(/lib/x86_64-linux-gnu/libresolv.so.2: symbol __h_errno, version
GLIBC_PRIVATE not defined in file libc.so.6 with link time reference)

   * What was the outcome of this action?

Afterwards, it stoped opening http links whatsoever. I wanted to report
a bug against kio_http.so containing package first but then upgraded it
first to Experimental version. Outcome: not really differend, no libc
error like the one above anymore but the links still don't work and I
see a useless error message:

The requested operation could not be completed

Cannot Initiate the http Protocol

Technical Reason: Unable to Launch Process

Details of the Request:

URL: http://www.heise.de/
Protocol: http
Date and Time: Sunday 27 March 2016 19:12
Additional Information: Unable to create io-slave: klauncher said: Error
loading 'kio_http'.

Regards,
Eduard.

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

Kernel: Linux 4.4.0-1-amd64 (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: sysvinit (via /sbin/init)

Versions of packages konqueror depends on:
ii  install-info6.1.0.dfsg.1-5
ii  kde-baseapps-bin4:15.12.1-1
ii  kde-baseapps-data   4:15.12.1-1
ii  kde-runtime 4:15.08.3-1+b1
ii  libc6   2.22-4
ii  libkcmutils44:4.14.16-1
ii  libkde3support4 4:4.14.16-1
ii  libkdecore5 4:4.14.16-1
ii  libkdesu5   4:4.14.16-1
ii  libkdeui5   4:4.14.16-1
ii  libkfile4   4:4.14.16-1
ii  libkhtml5   4:4.14.16-1
ii  libkio5 4:4.14.16-1
ii  libkonq5abi14:15.08.3-1
ii  libkonqsidebarplugin4a  4:15.08.3-1
ii  libkparts4  4:4.14.16-1
ii  libqt4-dbus 4:4.8.7+dfsg-6
ii  libqt4-qt3support   4:4.8.7+dfsg-6
ii  libqt4-xml  4:4.8.7+dfsg-6
ii  libqtcore4  4:4.8.7+dfsg-6
ii  libqtgui4   4:4.8.7+dfsg-6
ii  libstdc++6  5.3.1-13
ii  libx11-62:1.6.3-1

Versions of packages konqueror recommends:
pn  dolphin4 
ii  kfind4:15.08.3-1
ii  konqueror-nsplugins  4:15.12.1-1
ii  kpart-webkit 1.3.4-2

Versions of packages konqueror suggests:
pn  konq-plugins  

-- no debconf information

Bug#700870: [pkg-wpa-devel] Bug#700870: building eapol_test

2016-03-27 Thread Christopher Hoskin

Dear Stefan,

Thanks for the prompt reply! I have been able to build the packages using
the method outlined below for v2.3, v2.4, v2.5 and hostapd master (52844d6d
at the time of writing) and they all build fine. Also, I observe that since
October 2015 [0], cloning the http://w1.fi/hostap.git repository and
building eapol_test [1] has been part of the continuous integration of the
FreeRADIUS project. As the FreeRADIUS continuous integration tests
typically run several times a day [2], this would imply that there has been
a period of stability recently and also presumably that the FreeRADIUS
project has an interest in ensuring that this
remains the case.

Christopher

[0]
http://lists.freeradius.org/pipermail/freeradius-devel/2015-October/011322.html
[1]
https://github.com/FreeRADIUS/freeradius-server/blob/v3.1.x/scripts/travis/eapol_test-build.sh
[2] https://travis-ci.org/FreeRADIUS/freeradius-server/builds

Package Building Method:

git clone git://w1.fi/hostap.git
cd hostap/
cp -r ../pkg-wpa/wpa/trunk/debian ./

wget -O eapoltest.patch  "
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;filename=eapoltest.patch;bug=700870;msg=35
"
patch -p1 < eapoltest.patch
rm eapoltest.patch

dch --newversion 2.5.52844d6d-1
git archive --format tar --prefix wpa-2.5.52844d6d/ master README COPYING
CONTRIBUTIONS  src wpa_supplicant hostapd hs20 tests eap_example doc
wlantest wpadebug wpaspy radius_example mac80211_hwsim Android.mk
build_release | xz -c6 > ../wpa_2.5.52844d6d.orig.tar.xz
debuild -S
(comment out any patches which nolonger apply in debian/patches/series)
debuild

For X =3,4,5

git checkout hostap_2_X
dch --newversion 2.X-1
git archive --format tar --prefix wpa-2.X/ hostap_2_X README COPYING
CONTRIBUTIONS  src wpa_supplicant hostapd hs20 tests eap_example doc
wlantest wpadebug wpaspy radius_example mac80211_hwsim patches Android.mk
build_release | xz -c6 > ../wpa_2.X.orig.tar.xz
debuild -S
debuild

Bug#819367: gfortran: ICE with -fcheck=mem when initializing an array in a derived type

2016-03-27 Thread Xavier Andrade

Package: gfortran
Version: 4:5.3.1-1
Severity: important
Tags: upstream

Dear Maintainer,

I am receiving an internal compiler error (ICE) with gfortran when I
try to compile code that initializes an array (pointer or allocatable)
defined inside a datatype with a scalar value. The problem only
happens with the -check=mem flag.

This is a test code that triggers the error:

--

program test

  type tt
real(8), allocatable :: aa(:)
  end type tt

  type(tt) :: cc

  allocate(cc%aa(1:10))

  cc%aa = 0.0_8

end program test

--

This is the compilation line:

gfortran -fcheck=mem array.f90

and the error message:

--
array.f90:11:0:

   cc%aa = 0.0_8
 1
internal compiler error: in wide_int_to_tree, at tree.c:1464
0x969524 wide_int_to_tree(tree_node*,
generic_wide_int const&)
../../src/gcc/tree.c:1464
0x10ab123 build_int_cst(tree_node*, long)
../../src/gcc/tree.c:1272
0x64e6c3 gfc_trans_assignment_1
../../src/gcc/fortran/trans-expr.c:9127
0xd4cd60 trans_code
../../src/gcc/fortran/trans.c:1711
0xd4cd60 gfc_trans_code(gfc_code*)
../../src/gcc/fortran/trans.c:2020
0xd51782 gfc_generate_function_code(gfc_namespace*)
../../src/gcc/fortran/trans-decl.c:5927
0xd2f2a5 translate_all_program_units
../../src/gcc/fortran/parse.c:5406
0xd2f2a5 gfc_parse_file()
../../src/gcc/fortran/parse.c:5603
0x11fcaa5 gfc_be_parse_file
../../src/gcc/fortran/f95-lang.c:229
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
--

This is the output of gfortran -v

Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.3.1-12'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-
languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-
suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-
nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-
libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-
home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-
root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-
exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-
jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-
arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.1 20160316 (Debian 5.3.1-12)

Please let me know if there is any other information you might need.

Thank you,

Xavier





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

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

Versions of packages gfortran depends on:
ii  cpp 4:5.3.1-1
ii  gcc 4:5.3.1-1
ii  gfortran-5  5.3.1-12

gfortran recommends no packages.

Versions of packages gfortran suggests:
ii  gfortran-doc   5:4.9.2-1
pn  gfortran-multilib  

-- no debconf information
program test

  type tt
real(8), allocatable :: aa(:)
  end type tt

  type(tt) :: cc

  allocate(cc%aa(1:10))

  cc%aa = 0.0_8

end program test

Bug#811031: (no subject)

2016-03-27 Thread Bachsau

I would blame xorg for breaking compatibility. It is an excellent 
example of open source projects placing unnecessary obstacles in their 
own way. I don't think there really was a reason for this. It is just 
because some developer thought something would be more perfectly handled 
in another way regardless of the consequences.




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#819250: minidlna: Poor handling of inotify limits

2016-03-27 Thread Alexander Gerasiov

Hello Mark,

1. I don't think the reason of crash is someway linked to inotify. But
this doesn't matter because of 2.

2. I believe the problem is fixed in current testing version. Please
try 1.1.5 from testing or backports and report if crash persists.

On Fri, 25 Mar 2016 15:19:08 +
Mark Brown  wrote:

> Package: minidlna
> Version: 1.1.2+dfsg-1.1+b3
> Severity: important
> 
> On startup on my system minidlna exits with the following log message:
> 
> [2016/03/25 15:04:04] inotify.c:198: warn: WARNING: Inotify
> max_user_watches [16382] is low or close to the number of used
> watches [1887] and I do not have permission to increase this limit.
> Please do so manually by writing a higher value
> into /proc/sys/fs/inotify/max_user_watches.
> 
> There are several problems with this.  One is that this message is
> marked as a warning and it is therefore very surprising to find it
> treated as a fatal error.  This is especially the case since the
> message says that the number of used watches is about an order of
> magnitude lower than the limit which doesn't suggest that the limit
> has actually been hit.
> 
> The other is that since the program appears to have support for
> non-inotify operation (there's a configuration option to control
> inotify use) I'd expect it to fall back to that.
> 



-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: g...@cs.msu.su  Homepage: http://gerasiov.net  Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1

Bug#616447: Removal?

2016-03-27 Thread Christoph Haas

I haven't had a sponsorship request and Michael's offer is two years old
(as is his last commit to his repository). So I'm considering to have
"fyre" removed from Debian.



signature.asc
Description: OpenPGP digital signature

Bug#819258: [PKG-OpenRC-Debian] Bug#819258: openrc: dependency resolving fails using init-system-helpers

2016-03-27 Thread Benda Xu

Hi,

Thanks for the report.

Kevin Velghe  writes:

> On Sat, Mar 26, 2016 at 03:02:00AM +0100, Adam Borowski wrote:

>> I've tried multiple scenarios but failed to reproduce your problem.
>> Including dist-upgrades:
>>   jessie sysv-rc -> unstable -> openrc
>>   jessie sysv-rc -> openrc -> unstable
>> 
>> So there's something more complex on your system than just lvm2.  Letting us
>> know what might be helpful in trying to find out what's amiss for
>> you.

I cannot reproduce the bug by installing lvm2 on sid or jessie.

> The problem at boot might be related to the fact /boot is located on a
> lvm partition, otherwise I can't think about anything.
>
> OK, I'll check the installation problem on a container later, but if I
> install sysv-rc or current openrc package, then the installation of lvm2
> fails because the dependencies aren't enabled. 

[...]
> Yesterday, I upgraded lvm2. During the upgrade, I got the following error:
>  insserv: Service mountdevsubfs has to be enabled to start service lvm2
>  insserv: exiting now!

> This was fixed by manually enabling mountdevsubfs using insserv, after
> which I could finish upgrading. 

Why was mountdevsubfs not enabled?

Could you please paste the output of "ls -l /etc/rc*.d/*mountdev*" and
"rc-update | grep mountdev"?

On my system, they produce:

# ls -l /etc/rc*.d/*mountdev*
lrwxrwxrwx 1 root root 26 Feb 18 23:16 /etc/rcS.d/S02mountdevsubfs.sh -> 
../init.d/mountdevsubfs.sh

# rc-update | grep mountdev
 mountdevsubfs.sh |sysinit

> This morning however, booting hanged at lvm.

Did it hang with openrc?

> Downgrading lvbm2 didn't solve the problem, so I tried booting using
> sysv-rc, which had the same problem. systemd booted well, as did
> openrc 0.20.4-1.

Didn't openrc+lvm2 hang? Confused:(

>> As you say that sysv-rc failed too, it doesn't sound like anything related
>> to openrc.

> Yes, it is related to openrc, as openrc seems only affected because of
> the use of init-system-helpers to provide update-rc.d, which does not
> seem to use openrc to determine the dependencies.

The new update-rc.d from init-system-helpers calls rc-update to handle
the runlevels for openrc.  It is different from the old update-rc.d
shipped with openrc only in that it also calls insserv, too.

So the question really becomes: is your mountdevsubfs.sh enabled?

Benda


signature.asc
Description: PGP signature

Bug#805684: [Debian-olpc-devel] Bug#805684:

2016-03-27 Thread Jonas Smedegaard

Quoting SamuelOPH (2016-03-27 18:40:17)
> I uploaded a NMU

Thanks a lot!


> to 10-day/delay queue. Feel free to cancel this upload if needed.

On the contrary: Feel free to re-upload without deleay: Your changes are 
all excellent!

 - 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#819258: openrc: dependency resolving fails using init-system-helpers

2016-03-27 Thread Kevin Velghe

Hi,

I did some extra tests, and there is probably no openrc specific issue
indeed. I'm sorry for wasting your time.

OK, I did use insserv incorrect. Running insserv -d /etc/init.d does
almost nothing when running from the rescue mode on the installation
disk. It seems it only enables those currently running when no actual
scripts are passed.

OpenRC seems to generate it's dependency cache with the services enabled
in /etc/rc?.d, definitely when using openrc=0.20.4-2.1, but as it
created all symlinks for me, I think openrc=0.20.4-1 does the same. I
wonder where this happens though, as I can't find it immediately in the
diffs. It might be interesting for init-system-helpers to do the same, I
think.

The reason the installation of lvm2 failed was because mountdevsubfs.sh
was not enabled, which it should be, judging by the symlinks created by
openrc=0.20.4-1. I should have guessed after my tests with a container.
It would probably be interesting for init-system-helpers to enable
dependencies automatically.

I'm not sure however about the reason openrc initially failed. I haven't
been able to recreate the same problem. I can reproduce it with sysv-rc,
but I can't reproduce it anymore with openrc. I guess this issue can be
closed and/or sent to init-system-helpers/openrc/lvm2.

Best regards,
Kevin


signature.asc
Description: Digital signature

Bug#819366: RFA: filepp -- generic perl-based file pre-processor for text files

2016-03-27 Thread Christoph Haas

Package: wnpp
Severity:normal

The package needs minor fixes. I'm willing to sponsor uploads if
required. There have not been any updates of the upstream software in years.

Only 15 people have reportedly installed the package. So if nobody is
willing to adopt this package I will consider having it removed from Debian.



signature.asc
Description: OpenPGP digital signature

Bug#819365: assword gui fails to start when stderr is closed

2016-03-27 Thread Joey Hess

Package: assword
Version: 0.8-2.1
Severity: normal

Had a weird thing where my window manager's hotkey to start assword gui
stopped doing anything. Apparently assword is trying to print out a warning
(WARNING: could not validate OpenPGP signature on db file) and for some reason
stderr is closed, so it crashes

write(2, "print >>sys.stderr, \"WARNING: co"..., 80) = -1 EIO (Input/output 
error)
close(4)= 0
munmap(0x7fea62219000, 4096)= 0
write(2, "IOError", 7)  = -1 EIO (Input/output error)
write(2, ": ", 2)   = -1 EIO (Input/output error)
write(2, "[Errno 5] Input/output error", 28) = -1 EIO (Input/output error)
write(2, "\n", 1)   = -1 EIO (Input/output error)

I have no idea why my window manager is suddenly running the program with a
closed or unwritable stderr, but probably crashing in this situation is not
useful, so how about you catch this exception so that the gui can still
display. Especially since the gui helpfully displays the same warning..

To reproduce:

joey@darkstar:~>assword gui 2>/dev/full
- exit 1

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

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

Versions of packages assword depends on:
ii  python2.7.11-1
ii  python-gpgme  0.3-1.1+b1
ii  python-gtk2   2.24.0-4
ii  python-pkg-resources  20.1.1-1

Versions of packages assword recommends:
ii  python-xdo  0.2-2
ii  xclip   0.12+svn84-4

assword suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#805684:

2016-03-27 Thread SamuelOPH

Control: tags 805684 patch
Control: tags 805684 pending

Hi,

I uploaded a NMU to 10-day/delay queue. Feel free to cancel this
upload if needed.

The debian/changelog is:

python-box2d (2.0.2+svn20100109.244-1.2) unstable; urgency=medium

  * Non-maintainer upload.
  * debian/control:
- Change to new Homepage.
- Update to Debian Policy 3.9.7.
  * debian/patches:
- fix_comments.patch: Add patch to fix comment formatting so that the
  package doesn't FTBFS with SWIG 3 (patch courtesy of Jitka Plesnikova),
  thanks to Logan Rosen  for ponting out the patch
  (closes: #805684).
  * debian/watch:
- Change to new url from GitHub.
- Update to version 4.

I attached a debdiff.

Thanks.



Samuel Henrique O. P. [samueloph]


python-box2d.debdiff
Description: Binary data

Bug#818505: sortmerna FTBFS on !x86

2016-03-27 Thread Gert Wollny

On Sun, 2016-03-27 at 14:49 +0200, Adam Borowski wrote:
> 
> You're not allowed to use -msse2 on i386 either, unless for a code
> path that's run conditionally on runtime.

Actually, "not allowed" it not the right expression, "discouraged"
would be correct. If upstream requires sse2 then not enabling it would
mean that all users of i386 would not have access to this software,
even though one can assume that the majority uses hardware that is sse2
capable. 

Without looking at "sortmerna", having an unconditional include of
emmintrin.h and no mechanics that enable -msse2 from within the build
system seem to be good indicators that upstream didn't implement any
other code path. 

I think this discussion could be helpful (linking to the conclusion of
the maintainer): 

https://lists.debian.org/debian-devel/2014/09/msg00666.html

Best, 
Gert

Bug#819342: date command fails to parse some date strings close to a DST switch

2016-03-27 Thread Ben Hutchings

On Sun, 2016-03-27 at 12:16 -0400, Michael Stone wrote:
> On Sun, Mar 27, 2016 at 02:34:26AM -0600, Bob Proulx wrote:
> > 
> > > 
> > > $ date -d 00:59
> > > Sun 27 Mar 00:59:00 GMT 2016
> > > $ date -d "Sun 27 Mar 00:59:00 GMT 2016"
> > > date: invalid date ‘Sun 27 Mar 00:59:00 GMT 2016’
> > Unfortunately that input is not in a locale independent format.  That
> > is why it cannot be read by date in the above.  The date documentation
> > says this:
> > 
> >  ‘-d DATESTR’
> >  ‘--date=DATESTR’
> >   Display the date and time specified in DATESTR instead of the
> >   current date and time.  DATESTR can be in almost any common format.
> >   It can contain month names, time zones, ‘am’ and ‘pm’, ‘yesterday’,
> >   etc.  For example, ‘--date="2004-02-27 14:19:13.489392193 +0530"’
> >   specifies the instant of time that is 489,392,193 nanoseconds after
> >   February 27, 2004 at 2:19:13 PM in a time zone that is 5 hours and
> >   30 minutes east of UTC.
> >   Note: input currently must be in locale independent format.  E.g.,
> >   the LC_TIME=C below is needed to print back the correct date in
> >   many locales:
> >    date -d "$(LC_TIME=C date)"
> >   *Note Date input formats::.
> > 
> > The "locale independent format" looks to be the problem in the above
> > to me.  But I think that is only your command line test as that is
> > different from what I see in the tzdata postinst.
> This is where I rant that the entire -d interface should be officially 
> deprecated because it is so broken, and replaced with something reliable 
> that doesn't implement a confusing mess of kinda-NLP. 
[...]

It's a bit late for that.  Still, there should be clear documentation
of which locale-independent input formats can be relied on (and they
should be covered by regression tests).

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth

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

Bug#819342: date command fails to parse some date strings close to a DST switch

2016-03-27 Thread Michael Stone


On Sun, Mar 27, 2016 at 02:34:26AM -0600, Bob Proulx wrote:

$ date -d 00:59
Sun 27 Mar 00:59:00 GMT 2016
$ date -d "Sun 27 Mar 00:59:00 GMT 2016"
date: invalid date ‘Sun 27 Mar 00:59:00 GMT 2016’


Unfortunately that input is not in a locale independent format.  That
is why it cannot be read by date in the above.  The date documentation
says this:

 ‘-d DATESTR’
 ‘--date=DATESTR’
  Display the date and time specified in DATESTR instead of the
  current date and time.  DATESTR can be in almost any common format.
  It can contain month names, time zones, ‘am’ and ‘pm’, ‘yesterday’,
  etc.  For example, ‘--date="2004-02-27 14:19:13.489392193 +0530"’
  specifies the instant of time that is 489,392,193 nanoseconds after
  February 27, 2004 at 2:19:13 PM in a time zone that is 5 hours and
  30 minutes east of UTC.
  Note: input currently must be in locale independent format.  E.g.,
  the LC_TIME=C below is needed to print back the correct date in
  many locales:
   date -d "$(LC_TIME=C date)"
  *Note Date input formats::.

The "locale independent format" looks to be the problem in the above
to me.  But I think that is only your command line test as that is
different from what I see in the tzdata postinst.


This is where I rant that the entire -d interface should be officially 
deprecated because it is so broken, and replaced with something reliable 
that doesn't implement a confusing mess of kinda-NLP. 


env TZ=Europe/London LC_ALL=C date -d "Sun Mar 27 00:59:00 UTC 2016"

Sun Mar 27 00:59:00 GMT 2016

env TZ=Europe/London LC_ALL=C date -d "Sun Mar 27 01:00:00 UTC 2016"

date: invalid date 'Sun Mar 27 01:00:00 UTC 2016'

env TZ=US/Eastern LC_ALL=C date -d "Sun Mar 27 01:00:00 UTC 2016"

Sat Mar 26 21:00:00 EDT 2016

Seems broken to me...

Mike Stone

Bug#818897: Exim4 change CWD string to /

2016-03-27 Thread Andreas Metzler

On 2016-03-21 Roman Bulakh  wrote:
> Package: exim4
> Version: 4.80-7+deb7u2

> After updates exim to version 4.80-7+deb7u2 exim.c change CWD dir to /
> on startup.

> Checking cwd=/some/vay was a popular heuristic for
> identifying the source of malware sending email.

> The output would look something like this:

> 2016-03-04 11:46:22 cwd=/root 9 args: /usr/sbin/sendmail -FCronDaemon
> -i -odi -oem -oi -t -f root

> Now it looks like this:

> 2016-03-04 11:46:22 cwd=/ 9 args: /usr/sbin/sendmail -FCronDaemon -i
> -odi -oem -oi -t -f root
[...]

Hello,

/usr/share/doc/exim4-base/changelog.Debian.gz
exim4 (4.80-7+deb7u2) wheezy-security; urgency=high
  * 88_CVE-2016-1531.diff:
[...]
+ Exim changes it's working directory to / right after startup.
[...]
  * 89_01_only_warn_on_nonempty_environment.diff,
89_02_Store-the-initial-working-directory.diff: Upstream followups on the
CVE fix (Thanks, Heiko Schlittermann!):
[...]
+ Store the initial working directory and make it available in the new
  expansion variable $initial_cwd.


Sadly I made an error with the latter patch, but it is going to be fixed
in the next point release. See , you can
already grab 4.80-7+deb7u3 directly from the mirrors.
http://ftp.at.debian.org/debian/pool/main/e/exim4/

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#819363: ITP: r-cran-shiny -- GNU R web application framework

2016-03-27 Thread Geert Stappers

On Sun, Mar 27, 2016 at 05:15:31PM +0200, Andreas Tille wrote:
> 
> Remark: This package is part of a pyramid of dependencies required for
> the final target r-cran-treescape and will be maintained by the Debian
> Med team at
>https://anonscm.debian.org/git/debian-med/r-cran-shiny.git
> 

Hi,

According https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808142
is r-cran-httpuv -- GNU R package of HTTP and WebSocket Server Library
being maintained using debian-science's git at Alioth, at
http://anonscm.debian.org/gitweb/?p=debian-science/packages/r-cran-httpuv.git /
git://anonscm.debian.org/debian-science/packages/r-cran-httpuv.git .

Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#784792: network-manager: cannot connect with umts usb modem more than once

2016-03-27 Thread Michael Schwinck

A really nerve-racking problem. 
It is caused by the fact that the entry for the device used for the broadband 
connection is 
missing in the connection profile located in 
"/etc/NetworkManager/system-connections/".

Workaround:
1. If a USB stick is used for broadband connection plug it in and wait some 
seconds until the 
   device driver has been loaded. 
2. Invoke the command "nmcli dev" and look for the gsm device name. - If no gsm 
device is listed 
   wait additional seconds and repeat the command. 
3. Look for the name of your broadband connection profile in directory 
   "/etc/NetworkManager/system-connections/". 
4. As root user add the line "device="  to connection profile's
   "connection" section. Here  must be replaced be the name listed 
in the "device"
   column of the "nmcli dev" output. - That's all.

Example:
1. Let's assume device "ttyHS0" is listed for gsm connections by "nmcli dev". 
2. Let's further assume the broadband connection is named named "t-mobile".
3. As root user add the line "device=ttyHS0" to the section "[connection]" of 
the file 
   "t-mobile". - This file is located in the directory mentioned above.

-

Note: If the USB Modem is disconnected (unplugged) and then reconnected the 
device name 
changes. But that's not network-manager's fault.

Michael Schwinck
Mainz, Germany

--

On Fri, 8 May 2015 22:49:58 +0200 Paul Seyfert 
 wrote:
> 
> Package: network-manager
> Version: 0.9.10.0-7
> Severity: important
> 
> Dear Maintainer,
> 
> 
> I connect a usb umts modem to my computer (i am asked for the PIN), connect to
> the internet with it, disconnect from the network, unplug, replug (i am asked
> for the PIN again), i try to connect to the internet and receive the error
> 'Connection '' is not available on the device ttyUSB35
> at this time' (http://mathphys.fsk.uni-heidelberg.de/~pseyfert/nm.png)
> 
> when restarting the network manager (systemctl restart 
> network-manager.service)
> the connection can be established.
> 
> (i didn't do any further debuging)
> 
> 
> 
> -- System Information:
> Debian Release: 8.0
>   APT prefers stable
>   APT policy: (900, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/4 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 network-manager depends on:
> ii  adduser3.113+nmu3
> ii  dbus   1.8.16-1
> ii  init-system-helpers1.22
> ii  isc-dhcp-client4.3.1-6
> ii  libc6  2.19-18
> ii  libdbus-1-31.8.16-1
> ii  libdbus-glib-1-2   0.102-1
> ii  libgcrypt201.6.3-2
> ii  libglib2.0-0   2.42.1-1
> ii  libgnutls-deb0-28  3.3.8-6
> ii  libgudev-1.0-0 215-17
> ii  libmm-glib01.4.0-1
> ii  libndp01.4-2
> ii  libnewt0.520.52.17-1+b1
> ii  libnl-3-2003.2.24-2
> ii  libnl-genl-3-200   3.2.24-2
> ii  libnl-route-3-200  3.2.24-2
> ii  libnm-glib40.9.10.0-7
> ii  libnm-util20.9.10.0-7
> ii  libpam-systemd 215-17
> ii  libpolkit-gobject-1-0  0.105-8
> ii  libreadline6   6.3-8+b3
> ii  libsoup2.4-1   2.48.0-1
> ii  libsystemd0215-17
> ii  libteamdctl0   1.12-2
> ii  libuuid1   2.25.2-6

Bug#819016: jellyfish: Rename python bindings module name

2016-03-27 Thread Andreas Tille

Hi Diego,

thanks for diving into this.

On Fri, Mar 25, 2016 at 07:09:18PM +0100, Diego M. Rodriguez wrote:
> After some more testing, I'm wondering if it would be sensible to just
> *not* aim for having the python tests run during pybuild, and instead
> stick to running them on a separate stage (or during autopkgtest, which
> I have not ventured into yet). The main reason is that one of the tests
> (swig/python/test_mer_file.py) seems not really be meant to be executed
> using the standard unittest module, as it relies on a "data" variable
> created during __main__(), plus some hard-coded references to files
> generated during tests/swig_python.sh.

I need to admit I'm in favour of running any test at build time as well
as in an autopkgtest (see Debian Continuous Integration) as far as it is
sensible.  So if it turns out that parts of the test suite can not
sensibly be run under every condition only this part should be excluded.

> I made some attempts to running the tests during pybuild by:
> * building the extension with rpath, removing it with chrpath --delete
> right afterwards (kind of negating the "drop-rpath" patch temporarily):
> export PYBUILD_BUILD_ARGS=build_ext --rpath 
> "${CURDIR}/debian/tmp/usr/lib/${DEB_HOST_MULTIARCH}"
> ...
> pybuild ...
> chrpath --delete ...
> * patching the tests to provide a valid value for the "data" variable
> when run via unittest.
> * using PYBUILD_BEFORE_TEST and PYBUILD_AFTER_TEST to generate the files
> required by the test and place them in a reachable directory, cleaning
> up afterwards.
> 
> While it seems doable (and probably prone to be refined), it feels
> rather unorthodox and introducing some extra complexity for a seamingly
> small gain - I'm still not that familiar with the package's build system
> and specifics, but suspect that there are better ways to tackle this
> issue, and I'd appreciate some hints or thoughts on the best course of
> action.

I have not yet found time to dive into python-jellyfish yet so I'm just
saying what I would try to approach:  If it is easily possible to
deactivate this part of the test suite that seems troublesome I would
go for it.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#798430: apache2: please add systemd service file

2016-03-27 Thread Timo Aaltonen

26.03.2016, 10:06, Stefan Fritsch kirjoitti:
> Because of the things outlined above, I think the systemd unit should 
> still use the envvars file. Probably this is best achieved by calling 
> apachectl instead of apache2 directly.

Sure thing, looks like it works just fine with apache2ctl and then can
also drop Environment=* from the unit file.

>> I haven't tested it though, but a similar approach works great with
>> 389-ds-base and pki-server.
> 
> I will take a stab at separating htcacheclean in the init script and 
> adding a2enmod support. This is a necessary first step for adding unit 
> files.

Cool, looking forward to that.


-- 
t

Bug#819364: murano: [INTL:de] Initial German debconf translation

2016-03-27 Thread Chris Leick

Package: murano
Version: 1.0.1-2
Severity: wishlist
Tags: l10n patch


Hi,

please find attached the german debconf translation of murano.

Kind regards,
Chris

de.po.gz
Description: application/gzip

Bug#817893: [Reportbug-maint] Bug#817893: reportbug release.debian.org crashes with IndexError

2016-03-27 Thread Guido Günther

On Fri, Mar 11, 2016 at 02:43:37PM +0100, Uwe Kleine-König wrote:
> Hello,
> 
> On 03/11/2016 11:54 AM, Sandro Tosi wrote:
> > control: tags -1 + moreinfo
> > 
> > please upgrade to 6.6.6 from backport and try again
> 
> in a sid chroot on harris.d.o (with 6.6.6) this doesn't happen.

I'm still seeing this on testing with 6.6.6 for oldstable-pu

$ reportbug release.debian.org

Warning: no reportbug configuration found.  Proceeding in expert mode.
Detected character set: UTF-8
Please change your locale if this is incorrect.

Using '"Guido Günther" ' as your from address.
Will send report to Debian (per lsb_release).
What sort of request is this? (If none of these things mean anything to 
you, or you are trying to report a bug in an existing package, please press 
Enter to exit reportbug.)

1 binnmu  binNMU requests
2 britney testing migration script bugs
3 jessie-pu   jessie proposed updates requests
4 other   None of the other options
5 rm  Stable/Testing removal requests
6 transition  transition tracking
7 unblock unblock requests
8 wheezy-pu   wheezy proposed updates requests

Choose the request type: 8
Please enter the name of the package: gtk+3.0
Checking status database...
Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2247, in 
main()
  File "/usr/bin/reportbug", line 1115, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 1709, in user_interface
self.options.http_proxy)
  File "/usr/bin/reportbug", line 539, in special_prompts
return pkgprompts(package, bts, ui, fromaddr, timeout, online, 
http_proxy)
  File "/usr/lib/python2.7/dist-packages/reportbug/debbugs.py", line 458, 
in handle_debian_release
version = checkversions.get_versions_available(package, timeout, 
(tag[:-3],)).values()[0]
IndexError: list index out of range

so this does not look fixed yet or is this a different issue?
Cheers,
 -- Guido

Bug#819362: wheezy-pu: package gtk+3.0/3.4.2-7+deb7u1

2016-03-27 Thread Guido Günther

Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu

Hi,
I'd like to upate gtk+3.0 in wheezy to fix CVE-2013-7447.patch with the
attached debiff. Wheezy is currnelty the only unfixed gtk+3.0 version.

Cheers,
 -- Guido

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

Kernel: Linux 4.1.0-2-amd64 (SMP w/4 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)
diff --git a/debian/changelog b/debian/changelog
index 999a883..37c3d67 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+gtk+3.0 (3.4.2-7+deb7u1) oldstable-proposed-updates; urgency=medium
+
+  * Non-maintainer upload.
+  * CVE-2013-7447.patch: Avoid integer overflow when allocating a large block
+of memory in gdk_cairo_set_source_pixbuf (Closes: #818090)
+
+ -- Guido Günther   Sun, 13 Mar 2016 16:22:28 +0100
+
 gtk+3.0 (3.4.2-7) stable; urgency=low
 
   [ Raphaël Geissert ]
diff --git a/debian/patches/CVE-2013-7447.patch 
b/debian/patches/CVE-2013-7447.patch
new file mode 100644
index 000..cb851a2
--- /dev/null
+++ b/debian/patches/CVE-2013-7447.patch
@@ -0,0 +1,24 @@
+From: =?utf-8?q?Guido_G=C3=BCnther?= 
+Date: Sun, 13 Mar 2016 15:38:37 +0100
+Subject: CVE-2013-7447
+
+Cherry-pick of upstream commit
+
+https://git.gnome.org/browse/gtk+/commit?id=894b1ae76a32720f4bb3d39cf460402e3ce331d6
+---
+ gdk/gdkcairo.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/gdk/gdkcairo.c b/gdk/gdkcairo.c
+index 19bed04..2e1d8dc 100644
+--- a/gdk/gdkcairo.c
 b/gdk/gdkcairo.c
+@@ -213,7 +213,7 @@ gdk_cairo_set_source_pixbuf (cairo_t *cr,
+ format = CAIRO_FORMAT_ARGB32;
+ 
+   cairo_stride = cairo_format_stride_for_width (format, width);
+-  cairo_pixels = g_malloc (height * cairo_stride);
++  cairo_pixels = g_malloc_n (height, cairo_stride);
+   surface = cairo_image_surface_create_for_data ((unsigned char 
*)cairo_pixels,
+  format,
+  width, height, cairo_stride);
diff --git a/debian/patches/series b/debian/patches/series
index e9942cf..866e6e9 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -15,3 +15,4 @@
 074_try-harder-to-discriminate-Shift-F10-and-F10.patch
 075_gtkplug-fix-handling-of-key-events-for-layouts.patch
 076_check_wm_supports_hint.patch
+CVE-2013-7447.patch

Bug#782740: bugs.debian.org: broken link in "Changed bug forwarded-to-address" message

2016-03-27 Thread Frank Lichtenheld

Package: bugs.debian.org
Followup-For: Bug #782740

I've prepared a patch for this. The patch doesn't touch the regex in
Bugreport.pm since that is difficult to test. Instead it changes
some strings in Control.pm to include a '.' at the end of the
string to make them consistent with all other control messages.
This makes the regex from Bugreport.pm match correctly.

Obviously this will only fix new instances of the issue, not
retroactively fix all the instances from past bugs.

The patch also includes a test case. This part of the patch depends
on my patch from #767327.

Regards,
  Frank

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

Kernel: Linux 3.16.0-4-amd64 (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)
>From cfd18704f92efde38d5cbe0615fa84774dd57d24 Mon Sep 17 00:00:00 2001
From: Frank Lichtenheld 
Date: Sun, 27 Mar 2016 17:01:46 +0200
Subject: [PATCH] Control: Add missing full stop at the end of "Changed"
 messages

This leads to broken links for at least the forwarded-to case.
(Closes: #782740)
---
 Debbugs/Control.pm | 6 +++---
 t/07_bugreport.t   | 6 +-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/Debbugs/Control.pm b/Debbugs/Control.pm
index 44d0062..36c416f 100644
--- a/Debbugs/Control.pm
+++ b/Debbugs/Control.pm
@@ -1116,7 +1116,7 @@ sub set_submitter {
 	}
 	else {
 	if (defined $data->{originator} and length($data->{originator})) {
-		$action= "Changed $config{bug} submitter to '$param{submitter}' from '$data->{originator}'";
+		$action= "Changed $config{bug} submitter to '$param{submitter}' from '$data->{originator}'.";
 		$notify_old_submitter = 1;
 	}
 	else {
@@ -1231,7 +1231,7 @@ sub set_forwarded {
 		$action= "Unset $config{bug} forwarded-to-address";
 	}
 	elsif (defined $data->{forwarded} and length($data->{forwarded})) {
-		$action= "Changed $config{bug} forwarded-to-address to '$param{forwarded}' from '$data->{forwarded}'";
+		$action= "Changed $config{bug} forwarded-to-address to '$param{forwarded}' from '$data->{forwarded}'.";
 	}
 	else {
 		$action= "Set $config{bug} forwarded-to-address to '$param{forwarded}'.";
@@ -1316,7 +1316,7 @@ sub set_title {
 	}
 	else {
 	if (defined $data->{subject} and length($data->{subject})) {
-		$action= "Changed $config{bug} title to '$param{title}' from '$data->{subject}'";
+		$action= "Changed $config{bug} title to '$param{title}' from '$data->{subject}'.";
 	} else {
 		$action= "Set $config{bug} title to '$param{title}'.";
 	}
diff --git a/t/07_bugreport.t b/t/07_bugreport.t
index 80dfc92..78d89b1 100644
--- a/t/07_bugreport.t
+++ b/t/07_bugreport.t
@@ -1,7 +1,7 @@
 # -*- mode: cperl;-*-
 
 
-use Test::More tests => 14;
+use Test::More tests => 16;
 
 use warnings;
 use strict;
@@ -101,6 +101,10 @@ my @control_commands =
 			 value   => 'https://foo.invalid/bugs?id=1',
 			 regex   => qr{Set bug forwarded-to-address to https://foo\.invalid/bugs\?id=1;>https://foo\.invalid/bugs\?id=1\.},
 			},
+  forwarded_foo_2=> {command => 'forwarded',
+			 value   => 'https://foo.example/bugs?id=1',
+			 regex   => qr{Changed bug forwarded-to-address to https://foo\.example/bugs\?id=1;>https://foo\.example/bugs\?id=1 from https://foo\.invalid/bugs\?id=1;>https://foo\.invalid/bugs\?id=1\.},
+			},
   clone=> {command => 'clone',
 		   value   => '-1',
 		   regex   => qr{Bug 1 cloned as bug 2},
-- 
2.1.4

Bug#818862: [nvidia-kernel-dkms] fails to build for custom-compiled 4.4.6 kernel

2016-03-27 Thread Luca Boccassi

Control: tags -1 moreinfo

On Mon, 2016-03-21 at 09:26 +0500, Alex Volkov wrote:
> Package: nvidia-kernel-dkms
> Version: 352.79-5
> Severity: normal
> 
> --- Please enter the report below this line. ---
> 
> I use a custom kernel built from linux-source-4.4 (config is attached), and 
> the module fails to build (make.log is attached). How the hell you guys 
> managed to build it for linux-image-4.4.0-1 in the first place?

Hi,

The module builds fine on the 4.4.0-1 kernel that is in Sid, so I assume
it must be a problem with your config/package.

The diff between your config and Debian's is quite big:

1 file changed, 727 insertions(+), 2134 deletions(-)

So unfortunately I can't guarantee I'll be able to figure it out without
some help.

First of all, how did you build your kernel? Did you build a .deb
package? Are all the headers available? And finally, how did you run the
module build?

You could try doing a source build if you did a dkms build.
Install the nvidia-kernel-source package, then:

cd /usr/src
tar xJvf nvidia-kernel.tar.xz -C /tmp
cd /tmp/modules/nvidia-kernel
export KSRC=/usr/src/linux-headers-4.4.6-custom0-amd64
debian/rules binary_modules

And see if it still fails in the same way.

From your log there are a few config tests that fail:

#error kmem_cache_create() conftest failed!
#error on_each_cpu() conftest failed!
#error smp_call_function() conftest failed!
#error acpi_walk_namespace() conftest failed!
#error pci_dma_mapping_error() conftest failed!

I would suggest looking into
the /usr/src/nvidia-current-352.79/conftest.sh file.

What conftest.sh does, in a nutshell, is trying to compile a minimal
generated source file against in-kernel APIs, and if it fails/succeeds
it sets a variable. That's NVIDIA's way of supporting multiple kernel
versions in their out-of-tree shim module, by figuring out before
building the module what's there and what's missing.

For each of those failed tests, you can see exactly what they are trying
to build in the script.

Either a header is not available/visible, or one of the changes in the
config is disabling an API that is mandatory to build the module. Given
it cannot find kmem_cache_create, I'd guess it's the former. It's
defined in include/linux/slab.h. Is it available in the sources path of
your custom build that was used by the nvidia module
build: /usr/src/linux-headers-4.4.6-custom0-amd64 ?

Kind regards,
Luca Boccassi

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

Bug#819363: ITP: r-cran-shiny -- GNU R web application framework

2016-03-27 Thread Andreas Tille

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-shiny
  Version : 0.13.1
  Upstream Author : Winston Chang  and others
* URL : https://cran.r-project.org/web/packages/shiny/
* License : MIT
  Programming Lang: GNU R
  Description : GNU R web application framework
 Makes it incredibly easy to build interactive web applications with R.
 Automatic "reactive" binding between inputs and outputs and extensive
 pre-built widgets make it possible to build beautiful, responsive, and
 powerful applications with minimal effort.


Remark: This package is part of a pyramid of dependencies required for
the final target r-cran-treescape and will be maintained by the Debian
Med team at
   https://anonscm.debian.org/git/debian-med/r-cran-shiny.git

Bug#819361: openssh-client: ssh/scp rekey fails when using GSSAPI KEX

2016-03-27 Thread Peter Gille


Package: openssh-client
Version: 1:7.2p2-1
Severity: normal

Dear Maintainer,

I get failures during rekey when using ssh with kerberos authentication
and GSSAPI key-exchange. This can be noticed in long-running ssh
sessions or when doing large scp transfers (or triggered manually in the
ssh client, using the ~R escape sequence).

As far as I can make out the ssh client offers a different set of
key-exchange algorithms on initial connection and when doing the
rekeying. Here is an example output:

---
$ ssh -vvv foo.example.com
[...]
debug1: Authenticating to foo.example.com:22 as 'user'
[...]
debug2: local client KEXINIT proposal
debug2: KEX algorithms: 
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group14-sha1-A/vxljAEU54gt9a48EiANQ==,gss-gex-sha1-bontcUwnM6aGfWCP21alxQ==,gss-group1-sha1-bontcUwnM6aGfWCP21alxQ==,gss-group14-sha1-bontcUwnM6aGfWCP21alxQ==,gss-gex-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group1-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group14-sha1-eipGX3TCiQSrx573bT1o1Q==,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
[...]
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: 
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
[...]
Last login: Fri Mar 25 09:56:20 2016 from foo
foo% echo "now sending rekey request with ~R"
now sending rekey request with ~R
foo% debug1: need rekeying
debug1: SSH2_MSG_KEXINIT sent
debug1: rekeying in progress
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: 
curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
debug2: host key algorithms: 
ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,null
[...]
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: 
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
[...]
debug1: kex: algorithm: curve25519-sha...@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: rekeying in progress
debug1: rekeying in progress
debug1: Server host key: ecdsa-sha2-nistp256 
SHA256:w7yxbCZNBwQ0S0AgmCrFYa3XUpDjvWiDOw4/YOY9q8E
The authenticity of host 'foo.example.com (10.0.1.2)' can't be established.

ECDSA key fingerprint is SHA256:w7yxbCZNBwQ0S0AgmCrFYa3XUpDjvWiDOw4/YOY9q8E.
   Are you sure you want to continue connecting (yes/no)? 
  Host key 
verification failed.
---

So it appears that the client does not see the gss-* methods but the
server still does.

/ Peter


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

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=locale: Cannot set 
LC_ALL to default locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openssh-client depends on:
ii  adduser   3.114
ii  dpkg  1.18.4
ii  libc6 2.22-3
ii  libedit2  3.1-20150325-1+b1
ii  libgssapi-krb5-2  1.13.2+dfsg-5
ii  libselinux1   2.4-3+b1
ii  libssl1.0.2   1.0.2g-1
ii  passwd1:4.2-3.1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.9-1

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh
pn  monkeysphere  
pn  ssh-askpass   

-- debconf information:

Bug#815190: dh-make-perl: Accesses apt-file 3 cache directly

2016-03-27 Thread gregor herrmann

On Sun, 27 Mar 2016 08:29:04 +, Niels Thykier wrote:

> Damyan Ivanov:
> > FWIW the changes look good to me and now that the tests pass I see no 
> > reasons why this can't be merged in the master branch and released.

Great, thanks for checking!

> > What I am not clear about is whether this interface to apt-file is 
> > something new that is not available in stable. If so, we'd need either 
> > a suitable dependency or some kind of legacy support?
> > If this is a new interface I'd probably opt to adding the dependency 
> > and let stable users provide a patch :)

Yup, the dependency part in d/control is still missing.

> It is a new interface that requires APT 1.1 (or so).  It is not
> available in stable and nor do I expect it to be backported (though the
> APT maintainers could prove me wrong here).

Currently we have
Recommends: apt-file (>= 2.5.0),
and my idea was to bump this to >= 3.

apt-file itself has Depends: apt (>= 1.1.8); we could maybe also use
the same term; OTOH having apt-file explicitly makes it clearer what
this is about ...

I've now merged the changes into master, bumped the Recommends on
apt-file to >= 3 (but I'm also fine with going for apt directly), and
added a changelog entry.

Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Kante: Ituri

signature.asc
Description: Digital Signature

Bug#819288: console-setup-linux: keyboard-setup.sh init script (actually, the cached scripts) rely on /tmp, which may not be mounted at early boot

2016-03-27 Thread Felipe Sateler

On 26 March 2016 at 06:21, Anton Zinoviev  wrote:
> On Sat, Mar 26, 2016 at 12:53:45AM -0300, Felipe Sateler wrote:
>>
>> The cached scripts rely on the compiled keyboard maps to be present in
>> /tmp (presumably by having being saved by setupcon -k).
>
> Hm, this is totaly unexpected.  Normally the cached scripts rely on
> compiled keyboard maps in /etc.
>
> The only reason I can see the cached scripts rely on maps in /tmp is
> that /etc/ was read-only when `setupcon --save-only` was executed by
> /etc/init.d/console-setup.sh or `dpkg-reconfigure`.
>
> The cached scripts should never rely on files in /tmp and this is a bug
> I will have to fix somehow.  However, an important question we have to
> investigate here is this: why in your system the cached scripts rely on
> files in /tmp.

Interesting. Indeed, re-running console-setup.sh (after boot)
generates a new cached_setup_keyboard script that uses a file in /etc.
Even more, I cannot reproduce the original problem, and cannot find in
the code how did this happen in the first place (after all, the script
should not have been written to /etc either!)

But, maybe setupcon should force remove the cached script if it
contains references to /tmp (or better yet, the script does not match
/etc/console-setup/cached_*.map.gz)

-- 

Saludos,
Felipe Sateler

Bug#819190: libgl1-nvidia-legacy-340xx-glx: post-installation-Skript returns error code 137

2016-03-27 Thread Luca Boccassi

Control: tags -1 moreinfo

On Thu, 2016-03-24 at 18:14 +0100, Peter Schütt wrote:
> Package: libgl1-nvidia-legacy-340xx-glx
> Version: 340.96-3
> Severity: critical
> Justification: breaks the whole system
> 
> First I deinstalled all of nvidia
> 
> apt-get --purge remove *nvidia*
> 
> apt-get install nvidia-detect
> 
> Check for needed legacy-driver
> 
> apt-get install nvidia-legacy-340xx-driver
> 
> libgl1-nvidia-legacy-340xx-glx:amd64 (340.96-3) wird eingerichtet ...
> Killed
> dpkg: Fehler beim Bearbeiten des Paketes libgl1-nvidia-legacy-340xx-glx:amd64
> (--configure):
>  Unterprozess installiertes post-installation-Skript gab den Fehlerwert 137
> zurück
> 
> libgl1-nvidia-legacy-340xx-glx:i386 (340.96-3) wird eingerichtet ...
> 
> And after this line the installation process hangs.
> I have to kill the processes from another console.

Hi Peter,

Unfortunately I cannot reproduce this in a clean sid amd64 chroot with
neither:

apt-get install nvidia-legacy-340xx-driver

nor

apt-get install nvidia-legacy-340xx-driver
libgl1-nvidia-legacy-340xx-glx:i386

After the apt-get remove, are you sure there was no leftover? Have you
checked with dpkg -l? What version of the driver did you have installed
before?

Also, when posting the output of commands, could you please prefix them
with: LC_ALL=C this way the output is in English and it's easier for
non-German speaker to understand :-)

Kind regards,
Luca Boccassi


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

Bug#808911: dh-make-perl: Switch from libdpkg-parse-perl to libdpkg-perl modules

2016-03-27 Thread gregor herrmann

On Sun, 27 Mar 2016 08:02:00 +, Damyan Ivanov wrote:

> > Andy, Dam, what do you think about Guillem's patch?

Thanks for checking!
 
> Seems to work (tests pass), but is noticeably slower:
> 
>  * without the patch
>dh-make-perl-dev --cpan Catalyst  29,33s user 2,30s system 94% cpu 
>33,473 total
>(second try, after one dummy to fill CPAN/dh-make-perl caches)
> 
> 
>  * with the patch
>dh-make-perl-dev --cpan Catalyst  233,96s user 3,13s system 99% cpu 
>3:59,17 total
> 
> (both timings were on the gregoa/apt-file-3 branch)

Ouch; 4 minutes seems a bit suboptimal :/

Ok, I guess this change won't make it into 0.90 in the current form
:)

Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Kante: Ituri


signature.asc
Description: Digital Signature

Bug#819360: src:pam: Add bison into Build-Depends list

2016-03-27 Thread Roger Shimizu

Package: src:pam
Severity: normal
Tags: patch
X-Debbugs-Cc: rogershim...@gmail.com

Dear Maintainer,

I find src pkg "pam" need yacc, which usually provides by bison, when
build package.
So I create the patch enclosed.

I hope you can merge my patch soon. Thank you!

BTW. This patch is following by another patch, reported as #819359

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

Bug#816169: RFS: fake-factory/0.5.3-1

2016-03-27 Thread Wookey

+++ Mattia Rizzolo [2016-03-27 12:39 +]:
> On Sun, Mar 27, 2016 at 12:21:33PM +0100, Wookey wrote:
> > +++ Christopher Baines [2016-03-27 10:49 +0100]:
> > > On 20/03/16 03:12, Mattia Rizzolo wrote:
> > > A possible alternative would be to include a manpage made with help2man,
> > > and not generate it for this version (and switch to generating it later)?
> > 
> > Help2man breaks cross-building and is thus best avoided if
> > possible. Adding support for a 'nodocs' profile to skip its use is one
> > way to (mostly) deal with that.
> 
> How can this be a problem for arch:all builds?

Well I think it still breaks if one tries to cross-build arch:all
packages, but you are right that one doesn't need to do that so
it's not actually a problem there.

(I jumped in, so wasn't sure if we were discussing something arch:all or not)

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Bug#819359: src:pam: Add udeb support for libpam0g

2016-03-27 Thread Roger Shimizu

Package: src:pam
Severity: normal
Tags: patch, d-i
X-Debbugs-Cc: rogershim...@gmail.com

Dear Maintainer,

I'm trying to port GNU/screen to debian-installer [0].
GNU/screen depends on your library, so enclosed the patch I created to
make those udeb support.

I hope you can merge my patch soon. Thank you!

[0] https://lists.debian.org/debian-boot/2016/02/msg00547.html

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1
From 93b8a4fb85485a39e17e9f15388d6c6a5aa91657 Mon Sep 17 00:00:00 2001
From: Roger Shimizu 
Date: Sun, 27 Mar 2016 18:37:07 +0900
Subject: [PATCH 1/2] Add udeb support for libpam0g

---
 debian/changelog |  4 
 debian/control   | 17 +
 debian/libpam0g-udeb.install |  1 +
 3 files changed, 22 insertions(+)
 create mode 100644 debian/libpam0g-udeb.install

diff --git a/debian/changelog b/debian/changelog
index cb6ce6d..0c6d80b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
 pam (1.1.8-4) UNRELEASED; urgency=medium
 
+  [ Steve Langasek ]
   * Updated Swedish translation to correct a typo, thanks to Anders Jonsson
 and Martin Bagge.  Closes: #743875
   * Updated Turkish translation, thanks to Mert Dirik .
@@ -11,6 +12,9 @@ pam (1.1.8-4) UNRELEASED; urgency=medium
   * pam-auth-update: don't mishandle trailing whitespace in profiles.
 LP: #1487103.
 
+  [ Roger Shimizu ]
+  * Add udeb support for libpam0g
+
  -- Steve Langasek   Wed, 09 Apr 2014 14:04:10 -0700
 
 pam (1.1.8-3.1) unstable; urgency=high
diff --git a/debian/control b/debian/control
index d7a6830..b63805a 100644
--- a/debian/control
+++ b/debian/control
@@ -27,6 +27,23 @@ Description: Pluggable Authentication Modules library
  One may entirely upgrade the local authentication system without touching
  the applications themselves.
 
+Package: libpam0g-udeb
+XC-Package-Type: udeb
+Section: debian-installer
+Priority: required
+Architecture: any
+Multi-Arch: same
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Pre-Depends: ${misc:Pre-Depends}
+Description: Pluggable Authentication Modules library - udeb
+ Contains the stripped-down version of shared library for Linux-PAM,
+ a library that enables the local system administrator to choose how
+ applications authenticate users.
+ In other words, without rewriting or recompiling a PAM-aware application,
+ it is possible to switch between the authentication mechanism(s) it uses.
+ One may entirely upgrade the local authentication system without touching
+ the applications themselves.
+
 Package: libpam-modules
 Section: admin
 Priority: required
diff --git a/debian/libpam0g-udeb.install b/debian/libpam0g-udeb.install
new file mode 100644
index 000..622f9ef
--- /dev/null
+++ b/debian/libpam0g-udeb.install
@@ -0,0 +1 @@
+lib/*/lib*.so.*
-- 
2.8.0.rc3

Bug#812087: [pcscd] takes 100 % cpu

2016-03-27 Thread Philippe Teuwen


Hi Ludovic,

Version 1.8.16-1
Same problem.
See log.txt

Cheers
Phil
 pcscdaemon.c:261:main() pcscd set to foreground with debug send to 
stdout
0023 debuglog.c:310:DebugLogSetCategory() Debug options: APDU
[36m0003[0m [34mpcscdaemon.c:266:main() Force colored logs[0m
[36m0038[0m [01;31mutils.c:82:GetDaemonPid() Can't open 
/var/run/pcscd/pcscd.pid: No such file or directory[0m
[36m0039[0m configfile.l:281:DBGetReaderListDir() Parsing conf directory: 
/etc/reader.conf.d
[36m0024[0m configfile.l:353:DBGetReaderList() Parsing conf file: 
/etc/reader.conf.d/libccidtwin
[36m0032[0m configfile.l:315:DBGetReaderListDir() Skipping non regular 
file: .
[36m0012[0m configfile.l:315:DBGetReaderListDir() Skipping non regular 
file: ..
[36m0007[0m [34mpcscdaemon.c:567:main() pcsc-lite 1.8.16 daemon 
ready.[0m
[36m0134[0m [01;31mtokenparser.l:213:bundleParse() Could not open bundle 
file /usr/lib/pcsc/drivers/SCLGENERIC.bundle/Contents/Info.plist: No such file 
or directory[0m
[36m3756[0m hotplug_libudev.c:294:get_driver() Looking for a driver for 
VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/001/001
[36m0127[0m hotplug_libudev.c:294:get_driver() Looking for a driver for 
VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/001/001
[36m0118[0m hotplug_libudev.c:294:get_driver() Looking for a driver for 
VID: 0x0C45, PID: 0x6713, path: /dev/bus/usb/001/005
[36m0080[0m hotplug_libudev.c:294:get_driver() Looking for a driver for 
VID: 0x0C45, PID: 0x6713, path: /dev/bus/usb/001/005
[36m0097[0m hotplug_libudev.c:294:get_driver() Looking for a driver for 
VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/001/001
[36m0088[0m hotplug_libudev.c:294:get_driver() Looking for a driver for 
VID: 0x1050, PID: 0x0115, path: /dev/bus/usb/001/010
[36m0007[0m [34mhotplug_libudev.c:433:HPAddDevice() Adding USB device: 
Yubico Yubikey NEO U2F+CCID[0m
[36m0032[0m [34mreaderfactory.c:1066:RFInitializeReader() Attempting 
startup of Yubico Yubikey NEO U2F+CCID 00 00 using 
/usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Linux/libccid.so[0m
[36m0172[0m [34mreaderfactory.c:951:RFBindFunctions() Loading IFD 
Handler 3.0[0m
[36m0022[0m [34mifdhandler.c:1950:init_driver() Driver version: 
1.4.22[0m
[36m0420[0m [34mifdhandler.c:1967:init_driver() LogLevel: 0x0003[0m
[36m0004[0m [34mifdhandler.c:1978:init_driver() DriverOptions: 0x[0m
[36m0086[0m [34mifdhandler.c:110:CreateChannelByNameOrChannel() Lun: 0, 
device: usb:1050/0115:libudev:0:/dev/bus/usb/001/010[0m
[36m0014[0m [34mccid_usb.c:284:OpenUSBByName() Using: 
/usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist[0m
[36m0363[0m [34mccid_usb.c:302:OpenUSBByName() ifdManufacturerString: 
Ludovic Rousseau (ludovic.rouss...@free.fr)[0m
[36m0003[0m [34mccid_usb.c:303:OpenUSBByName() ifdProductString: Generic 
CCID driver[0m
[36m0002[0m [34mccid_usb.c:304:OpenUSBByName() Copyright: This driver is 
protected by terms of the GNU Lesser General Public License version 2.1, or (at 
your option) any later version.[0m
libusb: debug [libusb_init] created default context
libusb: debug [libusb_init] libusb v1.0.20.11004
libusb: debug [find_usbfs_path] found usbfs at /dev/bus/usb
libusb: debug [op_init] bulk continuation flag supported
libusb: debug [op_init] zero length packet flag supported
libusb: debug [op_init] sysfs can relate devices
libusb: debug [op_init] sysfs has complete descriptors
libusb: debug [linux_udev_event_thread_main] udev event thread entering.
libusb: debug [linux_get_device_address] getting address for device: usb1 
detached: 0
libusb: debug [linux_get_device_address] scan usb1
libusb: debug [linux_get_device_address] bus=1 dev=1
libusb: debug [linux_enumerate_device] busnum 1 devaddr 1 session_id 257
libusb: debug [linux_enumerate_device] allocating new device for 1/1 (session 
257)
libusb: debug [linux_get_device_address] getting address for device: 1-12 
detached: 0
libusb: debug [linux_get_device_address] scan 1-12
libusb: debug [linux_get_device_address] bus=1 dev=5
libusb: debug [linux_enumerate_device] busnum 1 devaddr 5 session_id 261
libusb: debug [linux_enumerate_device] allocating new device for 1/5 (session 
261)
libusb: debug [linux_get_parent_info] Dev 0x5610c9fa4f90 (1-12) has parent 
0x5610c9f9db10 (usb1) port 12
libusb: debug [linux_get_device_address] getting address for device: 1-2 
detached: 0
libusb: debug [linux_get_device_address] scan 1-2
libusb: debug [linux_get_device_address] bus=1 dev=10
libusb: debug [linux_enumerate_device] busnum 1 devaddr 10 session_id 266
libusb: debug [linux_enumerate_device] allocating new device for 1/10 (session 
266)
libusb: debug [linux_get_parent_info] Dev 0x5610c9f645f0 (1-2) has parent 
0x5610c9f9db10 (usb1) port 2
libusb: debug [linux_get_device_address] getting address for device: 1-4 
detached: 0
libusb: debug [linux_get_device_address]

Bug#812668: [m...@debian.org] Bug#812668: mailfilter: FTBFS - error: no match for 'operator='

2016-03-27 Thread Elimar Riesebieter

* Andreas Bauer  [2016-03-25 19:20 +0100]:

> Hi Elimar,
> 
> thanks again for letting me know about this issue and building the
> patch.  I too have tested the latest patch for a few weeks and just
> made a release of it, as it seems to do the trick:
> 
>   https://sourceforge.net/projects/mailfilter/files/Mailfilter/0.8.4/
> 
> I hope that as such, this package can remain in Debian.  Would be much
> obliged to get a quick confirmation of this, or further instructions
> on how I may be able to help in this regard.

Would one of the uploaders please update mailfilter to 0.8.4?

Thanks
Elimar
-- 
  Numeric stability is probably not all that
  important when you're guessing;-)


signature.asc
Description: PGP signature

Bug#819358: src:audit: Add udeb support to libaudit1 and libaudit-common

2016-03-27 Thread Roger Shimizu

Package: src:audit
Severity: normal
Tags: patch, d-i
X-Debbugs-Cc: rogershim...@gmail.com

Dear Maintainer,

I'm trying to port GNU/screen to debian-installer [0].
GNU/screen depends on your library, so enclosed the patch I created to
make those udeb support.

I hope you can merge my patch soon. Thank you!

[0] https://lists.debian.org/debian-boot/2016/02/msg00547.html

-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1
From 221d2917d89749cbfa19be92fcbcbf3cc67b2831 Mon Sep 17 00:00:00 2001
From: Roger Shimizu 
Date: Sat, 26 Mar 2016 19:11:00 +0900
Subject: [PATCH] Add udeb support to libaudit1 and libaudit-common

---
 debian/changelog|  7 +++
 debian/control  | 30 ++
 debian/libaudit-common-udeb.install |  1 +
 debian/libaudit1-udeb.install   |  1 +
 4 files changed, 39 insertions(+)
 create mode 100644 debian/libaudit-common-udeb.install
 create mode 100644 debian/libaudit1-udeb.install

diff --git a/debian/changelog b/debian/changelog
index 9db8787..8610959 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+audit (1:2.4.5-2) UNRELEASED; urgency=medium
+
+  [ Roger Shimizu ]
+  * Add udeb support to libaudit1 and libaudit-common
+
+ -- Roger Shimizu   Sat, 26 Mar 2016 19:07:09 +0900
+
 audit (1:2.4.5-1) unstable; urgency=medium
 
   * New upstream release
diff --git a/debian/control b/debian/control
index 82eecaa..be186dd 100644
--- a/debian/control
+++ b/debian/control
@@ -79,6 +79,21 @@ Description: Dynamic library for security auditing
  applications to use the audit framework. It is used to monitor systems for
  security related events.
 
+Package: libaudit1-udeb
+XC-Package-Type: udeb
+Section: debian-installer
+Architecture: linux-any
+Priority: optional
+Pre-Depends: ${misc:Pre-Depends}
+Depends: libaudit-common (>= ${source:Version}),
+ ${misc:Depends},
+ ${shlibs:Depends}
+Multi-Arch: same
+Description: Dynamic library for security auditing - udev
+ The audit-libs package contains the dynamic libraries needed for
+ applications to use the audit framework. It is used to monitor systems for
+ security related events.
+
 Package: libaudit-common
 Architecture: all
 Priority: optional
@@ -94,6 +109,21 @@ Description: Dynamic library for security auditing - common files
  This package contains the libaudit.conf configuration file and the associated
  manpage.
 
+Package: libaudit-common-udeb
+XC-Package-Type: udeb
+Section: debian-installer
+Architecture: all
+Priority: optional
+Depends: ${misc:Depends}
+Multi-Arch: foreign
+Description: Dynamic library for security auditing - udeb common files
+ The audit-libs package contains the dynamic libraries needed for
+ applications to use the audit framework. It is used to monitor systems for
+ security related events.
+ .
+ This package contains the stripped-down version of libaudit.conf configuration
+ file and the associated manpage.
+
 Package: libaudit-dev
 Section: libdevel
 Architecture: linux-any
diff --git a/debian/libaudit-common-udeb.install b/debian/libaudit-common-udeb.install
new file mode 100644
index 000..ea25713
--- /dev/null
+++ b/debian/libaudit-common-udeb.install
@@ -0,0 +1 @@
+etc/libaudit.conf
diff --git a/debian/libaudit1-udeb.install b/debian/libaudit1-udeb.install
new file mode 100644
index 000..e785d62
--- /dev/null
+++ b/debian/libaudit1-udeb.install
@@ -0,0 +1 @@
+lib/*/libaudit.so.*
-- 
2.8.0.rc3

Bug#819357: nanoc view requires Ruby gem 'adsf'

2016-03-27 Thread Stefano Costa

Package: nanoc
Version: 4.1.4-1
Severity: normal

Dear Maintainer,
the "nanoc view" command is not working after a normal install of the package,
since it depends on the 'adsf' Ruby gem. E.g. this happens:

steko@spheniscus:~/code/qaw2$ nanoc view
Could not find the required 'adsf' gem, which is necessary for the view 
command.

Ideally, the required gem should be offered as a recommended package.

Thanks,
steko

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

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

Versions of packages nanoc depends on:
ii  jruby [ruby-interpreter]1.7.22-2
ii  ruby1:2.3.0+1
ii  ruby-cri2.7.0-2
ii  ruby-listen 3.0.3-3
ii  ruby2.2 [ruby-interpreter]  2.2.4-1
ii  ruby2.3 [ruby-interpreter]  2.3.0-5

Versions of packages nanoc recommends:
pn  asciidoc
pn  ruby-bluecloth  
ii  ruby-builder3.2.2-4
ii  ruby-coffee-script  2.4.1-1
pn  ruby-compass
pn  ruby-erubis 
pn  ruby-haml   
ii  ruby-kramdown   1.10.0-1
pn  ruby-maruku 
ii  ruby-mime-types 2.6.1-1
ii  ruby-mustache   1.0.2-1
ii  ruby-nokogiri   1.6.7.2-3
ii  ruby-rdiscount  2.1.8-1+b3
ii  ruby-redcloth   4.2.9-5+b3
ii  ruby-rouge  1.10.1-1
ii  ruby-rubypants  0.2.0-2
ii  ruby-sass   3.4.21-1
pn  ruby-slim   
pn  ruby-uglifier   

Versions of packages nanoc suggests:
ii  python-pygments   2.1+dfsg-1
ii  rsync 3.1.1-3
pn  ruby-fog  
ii  ruby-pygments.rb  0.6.3-1
ii  ruby-rack 1.6.4-3

-- no debconf information

Bug#819356: RFS: arrayfire/3.3.1+dfsg1-1

2016-03-27 Thread Ghislain Vaillant


Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "arrayfire"

* Package name: arrayfire
  Version : 3.3.1+dfsg1-1
  Upstream Author : ArrayFire Development Group
* URL : http://arrayfire.com/
* License : BSD
  Section : science

It builds those binary packages:

  libarrayfire-cpu-dev - Development files for ArrayFire (CPU backend)
  libarrayfire-cpu3 - High performance library for parallel computing
(CPU backend)
  libarrayfire-cpu3-dbg - Debugging symbols for ArrayFire (CPU backend)
  libarrayfire-dev - Common development files for ArrayFire
  libarrayfire-doc - Common documentation and examples for ArrayFire
  libarrayfire-opencl-dev - Development files for ArrayFire (OpenCL
backend)
  libarrayfire-opencl3 - High performance library for parallel
computing (OpenCL backend)
  libarrayfire-opencl3-dbg - Debugging symbols for ArrayFire (OpenCL
backend)
  libarrayfire-unified-dev - Development files for ArrayFire (unified
backend)
  libarrayfire-unified3 - High performance library for parallel
computing (unified backend)
  libarrayfire-unified3-dbg - Debugging symbols for ArrayFire (unified
backend)

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

  http://mentors.debian.net/package/arrayfire

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

  dget -x 
http://mentors.debian.net/debian/pool/main/a/arrayfire/arrayfire_3.3.1+dfsg1-1.dsc


Successful build logs on debomatic:

  [amd64] 
http://debomatic-amd64.debian.net/distribution#unstable/arrayfire/3.3.1+dfsg1-1/buildlog


Changes since the last upload:

  * Release to unstable.
  * d/gbp.conf: use recommended packaging repository layout (DEP-14):
- change upstream branch from dfsg-clean to upstream/latest.
- change debian branch from debian/sid to debian/master.

Regards,
Ghislain Vaillant

Bug#767327: b.d.o: wrong package links in "reassigned" message

2016-03-27 Thread Frank Lichtenheld

Package: bugs.debian.org
Followup-For: Bug #767327

I've prepared a testcase and a patch for the issue.

Please see the attached commits.

Regards,
  Frank

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

Kernel: Linux 3.16.0-4-amd64 (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)
>From c6904460b23cb1e80987624dca932b959fb4d6b2 Mon Sep 17 00:00:00 2001
From: Frank Lichtenheld 
Date: Sun, 27 Mar 2016 15:24:15 +0200
Subject: [PATCH 1/2] Extend bugreport test cases to check the output of some
 control messages

This exposes #767327 (wrong package links in "reassigned" message)
as a test failure.
---
 t/07_bugreport.t | 41 +++--
 1 file changed, 39 insertions(+), 2 deletions(-)

diff --git a/t/07_bugreport.t b/t/07_bugreport.t
index 3600e1c..80dfc92 100644
--- a/t/07_bugreport.t
+++ b/t/07_bugreport.t
@@ -1,7 +1,7 @@
 # -*- mode: cperl;-*-
 
 
-use Test::More tests => 8;
+use Test::More tests => 14;
 
 use warnings;
 use strict;
@@ -90,7 +90,44 @@ print STDERR $mech->content();
 ok($mech->content() !~ qr/[\x01\x02\x03\x05\x06\x07]/i,
'No unescaped states');
 
-
+# now test the output of some control commands
+my @control_commands =
+ (
+  reassign_foo => {command => 'reassign',
+		   value   => 'bar',
+		   regex => qr{bug reassigned from package foo to bar},
+		  },
+  forwarded_foo  => {command => 'forwarded',
+			 value   => 'https://foo.invalid/bugs?id=1',
+			 regex   => qr{Set bug forwarded-to-address to https://foo\.invalid/bugs\?id=1;>https://foo\.invalid/bugs\?id=1\.},
+			},
+  clone=> {command => 'clone',
+		   value   => '-1',
+		   regex   => qr{Bug 1 cloned as bug 2},
+		  },
+ );
+
+while (my ($command,$control_command) = splice(@control_commands,0,2)) {
+  # just check to see that control doesn't explode
+  $control_command->{value} = " $control_command->{value}" if length $control_command->{value}
+and $control_command->{value} !~ /^\s/;
+  send_message(to => 'control@bugs.something',
+	   headers => [To   => 'control@bugs.something',
+			   From => 'foo@bugs.something',
+			   Subject => "Munging a bug with $command",
+			  ],
+	   body => <{command} 1$control_command->{value}
+thanks
+EOF
+  ;
+  # Now test that the output has changed accordingly
+  $mech->get_ok('http://localhost:'.$port.'/?bug=1',
+		'Page received ok');
+  like($mech->content(), $control_command->{regex},
+   'Page matches regex');
+}
 
 # Other tests for bugs in the page should be added here eventually
 
-- 
2.1.4

>From 6176d46de938ccb848b14ed8ca1098313bf7678f Mon Sep 17 00:00:00 2001
From: Frank Lichtenheld 
Date: Sun, 27 Mar 2016 15:26:20 +0200
Subject: [PATCH 2/2] Bugreport: Fix problems with reassign message

* Matched hardcoded "Bug" instead of $config{bug} (which leads
  to problems at least in the test suite)
* Use package_links() wrong. package_links() already adds HTML.
  (Closes: #767327)
---
 Debbugs/CGI/Bugreport.pm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Debbugs/CGI/Bugreport.pm b/Debbugs/CGI/Bugreport.pm
index b1be2ed..8ebbfe8 100644
--- a/Debbugs/CGI/Bugreport.pm
+++ b/Debbugs/CGI/Bugreport.pm
@@ -395,10 +395,10 @@ sub handle_record{
 		  {$1.$2.(bug_links(bug=>$3)).$4.
 			   english_join([map {bug_links(bug=>$_)} (split /\,?\s+(?:and\s+)?/, $5)])}eo;
 	  # Add links to reassigned packages
-	  $output =~ s{(Bug\sreassigned\sfrom\spackage\s(?:[\`']|\&\#39;))([^']+?)((?:'|\&\#39;|\\;)
+	  $output =~ s{($config{bug}\sreassigned\sfrom\spackage\s(?:[\`']|\&\#39;))([^']+?)((?:'|\&\#39;|\\;)
\sto\s(?:[\`']|\&\#39;|\\;))([^']+?)((?:'|\&\#39;|\\;))}
-	  {$1.q($2).$3.
-   q($4).$5}exo;
+	  {$1.package_links(package=>$2).$3.
+   package_links(package=>$4).$5}exo;
 	  if (defined $time) {
 	   $output .= ' ('.strftime('%a, %d %b %Y %T GMT',gmtime($time)).') ';
 	  }
-- 
2.1.4

Bug#812174: ITP: letsencrypt-sh -- ACME client implemented in Bash

2016-03-27 Thread Mattia Rizzolo

Control: retitle -1 ITP: letsencrypt.sh -- ACME client implemented in Bash

On Sun, Mar 27, 2016 at 01:01:18PM +0200, Daniel Beyer wrote:
> On Sat, 2016-03-26 at 21:07 +, Mattia Rizzolo wrote:
> > On Thu, Jan 21, 2016 at 08:10:13AM +0100, Daniel Beyer wrote:
> > > * Package name: letsencrypt-sh
> > 
> > Is there a good reason not to call this package 'letsencrypt.sh', with a
> > dot, as the official name?
> 
> No, there is no good reason for it. I wrongly thought a dot in a package
> name is not permitted. Let's name it letsencrypt.sh.

Cool, let's change it ;) (I retitled the ITP here)

> > Anyway, this email was to ask how it's going with this.
> 
> Since I needed it, I made some initial packaging [1] on GitHub, which
> fit my needs right know. It of course need some more work to get it
> ready for Debian (e.g. it needs to be rebased against upstream's v0.1.0
> and the repo should be moved to anonscm.d.o).

I'd be very happy to do some work and have you review it and see if it
fits your needs and likings.

Two things I'd do include using an apache2 configuration snippet (to go
in /etc/apache2/conf.available) instead of a fake virtual host in
/etc/apache2/sites.available.

Another is to install the full config snippet provided by upstream in
/usr/share/letsencrypt.sh/examples and install our version in /etc/ from
a static copy kept in debian/ instead of patching upstream's config.sh.

> > It should be a
> > fairly simple package, and I'm quite interested in it (can also sponsor
> > it or help to comaintain it, as you like, if you need it!).
> 
> I might have overcomplicated things a bit with the current packaging
> approach (e.g. providing apache configuration). You might want to take a
> look yourself and share your thoughts.

I like that you're providing a easy snippet of conf to easily set up
apache to do

> If you're up for it, I gratefully would like to accept your offer to
> co-maintain this package. Additionally it might be worth to ask having
> it under the umbrella of Debian Let's Encrypt [2].

Yes, that's a great idea.  I'm CCing letsencrypt-devel.  I asked
hlieberman via IRC if this would be ok for him, but he hasn't replied
yet.
If this is Ok for the letsencrypt team, would you be ok to add myself
(user: mattia) and Daniel Beyer (that I guess is dabe-guest on alioth)
to the team?

> Let me know if you think we can base our work on what I've done so far,
> or if we instead should make a fresh start.

If think your work is great :)

If you are ok, I'd start working on a clone of this and see what you
think of it; it really won't need much!

-- 
regards,
Mattia Rizzolo

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

signature.asc
Description: PGP signature

Bug#819355: ITP: augustus -- gene prediction in eukaryotic genomes

2016-03-27 Thread Sascha Steinbiss

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: augustus
  Version : 3.2.1
  Upstream Author : Lizzy Gerischer, Oliver Keller, Stefanie König, Lars 
Romoth, Mario Stanke 
* URL : http://bioinf.uni-greifswald.de/augustus/ 
* License : Artistic
  Programming Lang: C++
  Description : gene prediction in eukaryotic genomes

AUGUSTUS is a software for gene prediction in eukaryotic genomic sequences
that is based on a generalized hidden Markov model, which is a probabilistic
model of a sequence and its gene structure. After learning gene structures
from a reference annotation, AUGUSTUS uses the HMM to recognize genes in a new
sequence and annotates it with the regions of identified genes. External hints,
e.g. from RNA sequencing, EST or protein alignments etc. can be used to guide
and improve the gene finding process. The result is the set of most likely gene
structures that comply with all given user constraints, if such gene
structures exist.
AUGUSTUS already includes prebuilt HMMs for many species, as well as scripts
to train custom models using annotated genomes.

This package will be maintained under the umbrella of the Debian Med
Packaging Team.

Bug#783239: closed by Khalid Aziz <kha...@debian.org> (Bug#783239: fixed in kexec-tools 1:2.0.10-2)

2016-03-27 Thread Jérémy Bobbio

Control: reopen -1

Hi!

The patch did not account for locale variation so kexec-tools is still
unreproducible. An updated patch is attached.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
diff --git a/debian/patches/allow-external-build-date.patch b/debian/patches/allow-external-build-date.patch
index 9d196f5..3baf983 100644
--- a/debian/patches/allow-external-build-date.patch
+++ b/debian/patches/allow-external-build-date.patch
@@ -11,7 +11,7 @@ Author: Jérémy Bobbio 
  
 -AC_DEFINE_UNQUOTED(PACKAGE_DATE, "`date '+%d %B %Y'`",
 +if test "x$BUILD_DATE" = x; then
-+	BUILD_DATE=`date '+%d %B %Y'`
++	BUILD_DATE=`LC_ALL=C date '+%d %B %Y'`
 +fi
 +AC_DEFINE_UNQUOTED(PACKAGE_DATE, "$BUILD_DATE",
  		[Define to the release date of this package])
diff --git a/debian/rules b/debian/rules
index 1f31435..acf2c0a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,7 +9,7 @@
 #export DH_VERBOSE=1
 
 
-BUILD_DATE = $(shell dpkg-parsechangelog -S Date | date -u +'%d %B %Y' -f -)
+BUILD_DATE = $(shell dpkg-parsechangelog -S Date | LC_ALL=C date -u +'%d %B %Y' -f -)
 export BUILD_DATE
 
 ifneq (,$(filter parallel=%,$(subst $(COMMA), ,$(DEB_BUILD_OPTIONS


signature.asc
Description: Digital signature

Bug#819354: firejail firefox: invalid lines in profiles

2016-03-27 Thread Thomas Renard

Package: firejail
Version: 0.9.38-1
Severity: normal

Dear Maintainer,

the configuration for firejail does not work as expected.

call firejail firefox
expected: firefox is started in the sandbox
outcome:
Reading profile /etc/firejail/firefox.profile
Error: line 2 in the custom profile is invalid

line 2 in /etc/firejail/firefox.profile:
noblacklist ${HOME}/.mozilla

call firejail vlc
expected: vlc is started in the sandbox
outcome

Reading profile /etc/firejail/vlc.profile
Reading profile /etc/firejail/disable-mgmt.inc
Reading profile /etc/firejail/disable-secret.inc
Reading profile /etc/firejail/disable-common.inc
Error: line 2 in the custom profile is invalid

line 2 in /etc/firejail/disable-common.inc

blacklist-nolog ${HOME}/.history

Both configuration lines look normal.

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

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

Versions of packages firejail depends on:
ii  libc6  2.22-3

firejail recommends no packages.

firejail suggests no packages.

-- no debconf information

Bug#818505: sortmerna FTBFS on !x86

2016-03-27 Thread Adam Borowski

On Sun, Mar 27, 2016 at 07:31:23AM +0200, Andreas Tille wrote:
> On Thu, Mar 17, 2016 at 05:04:21PM +, Jurica Stanojkovic wrote:
> > Package sortmerna FTBFS on archs not in x86 group (amd64, i386, x32, etc. )
> > with following error:
> > gcc: error: unrecognized command line option '-msse2'
> > 
> > build logs:
> > https://buildd.debian.org/status/logs.php?pkg=sortmerna=2.1-1=sid
> > 
> > Package use -msse2 for all architectures, 
> > but not all archs have support for sse2 instruction set.
> > 
> > if -msee2 flag is removed from build next error reported is:
> > src/ssw.c:45:23: fatal error: emmintrin.h: No such file or directory
> 
> As far as I can see this might restrict the package to intel
> architectures.  If there is no hint how to build on those other
> architectures I'd restrict the architectures to these.

You're not allowed to use -msse2 on i386 either, unless for a code path
that's run conditionally on runtime.

And on amd64 and x32, -msse2 is redundant as it's already implied by default
compiler settings for those architectures.

-- 
A tit a day keeps the vet away.

Bug#816169: RFS: fake-factory/0.5.3-1

2016-03-27 Thread Mattia Rizzolo

On Sun, Mar 27, 2016 at 10:49:55AM +0100, Christopher Baines wrote:
> On 20/03/16 03:12, Mattia Rizzolo wrote:
> >> The issues that you commented on above are fixed in this repository.
> >>
> >> 1: https://anonscm.debian.org/cgit/python-modules/packages/faker.git
> > 
> > of what I wrote before these still need fixing:
> > 
> > * debian/control:
> >   + I: fake-factory source: duplicate-long-description python-fake-factory 
> > python3-fake-factory
> >   + I: python-fake-factory: extended-description-is-probably-too-short
> >   + I: python3-fake-factory: extended-description-is-probably-too-short
> 
> I have added the Python version to the extended description, which fixes
> these lintian issues.

Yes, that's probably the most common fix for duplicate-long-description
:)

> > did you manually fix this in the build manpage by any chance?
> 
> Yes

I see.

> I have made a pull request to the upstream project, improving the help
> output in a way that will fix these issues [1]. Its a bit awkward, but
> is the best step to take next, to wait for upstream to do a release with
> these changes?
> 
> A possible alternative would be to include a manpage made with help2man,
> and not generate it for this version (and switch to generating it later)?
> 
> 1: https://github.com/joke2k/faker/pull/342

This pull request looks cool to me.

I'd probably just include that patch in the package (either after
waiting an ACK from upstream or not, your call).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#816169: RFS: fake-factory/0.5.3-1

2016-03-27 Thread Mattia Rizzolo

On Sun, Mar 27, 2016 at 12:21:33PM +0100, Wookey wrote:
> +++ Christopher Baines [2016-03-27 10:49 +0100]:
> > On 20/03/16 03:12, Mattia Rizzolo wrote:
> > A possible alternative would be to include a manpage made with help2man,
> > and not generate it for this version (and switch to generating it later)?
> 
> Help2man breaks cross-building and is thus best avoided if
> possible. Adding support for a 'nodocs' profile to skip its use is one
> way to (mostly) deal with that.

How can this be a problem for arch:all builds?

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#500422: hexedit shows strange characters in the status bar when opening a file with a non-ascii filename

2016-03-27 Thread Aaron Small

Hi, unfortunately it does still occur. I just tried it with this file:

$ ls
00 - 回家.m4a

And see the following at the bottom of the screen when opening it in
hexedit:
---  00 - å~[~^家.m4a

I'm using stretch:
$ dpkg -l hexedit
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version
   Architecture   Description
+++-==-==-==-==
ii  hexedit1.2.13-1+b1
   amd64  view and edit files in
hexadecimal or in ASCII

On Sun, Mar 27, 2016 at 1:59 AM, Eriberto Mota  wrote:

> Control: tags 500422 moreinfo
>
> Hi,
>
> Some years after this bug have been opened, I would like to ask if
> this issue still occurring. Debian uses UTF-8 now and I didn't be able
> to reproduce the error.
>
> Thanks!
>
> Eriberto
>

Bug#814419: Fixed

2016-03-27 Thread Максим Кузьмин

After recent update everything seems to be OK.

-- 
Максим

Bug#819349: filed upstream

2016-03-27 Thread Adam Borowski

I've filed the patch upstream (to
https://bugzilla.mozilla.org/show_bug.cgi?id=1062903), but as NSS upstream
releases are quite rare, please apply it in Debian.

-- 
A tit a day keeps the vet away.

Bug#819316: closed by Andreas Tille <ti...@debian.org> (Bug#819316: fixed in plastimatch 1.6.2+dfsg-3)

2016-03-27 Thread Emilio Pozuelo Monfort

You also have to request the removal of the old binaries reporting a bug against
ftp.debian.org

Emilio

Bug#819326: jessie-pu: package postgresql-common/165+deb8u1

2016-03-27 Thread Adam D. Barratt

Control: tags -1 + pending

On Sat, 2016-03-26 at 22:19 +, Adam D. Barratt wrote:
> The upload appears to have acquired some cruft:
> 
>  165+deb8u1.diff   |   82 
> [...]
>  tags  |  263 
> ++

It was re-uploaded without the cruft, and I've flagged that version for
acceptance.

Regards,

Adam

Bug#819243: jessie-pu, wheezy-pu: package librsvg/2.40.5-1 and librsvg/2.36.1-2

2016-03-27 Thread Adam D. Barratt

Control: tags -1 + pending

On Sat, 2016-03-26 at 23:58 +0100, Santiago Ruano Rincón wrote:
> El 25/03/16 a las 13:58, Adam D. Barratt escribió:
> ...
> > 
> > On Fri, 2016-03-25 at 14:49 +0100, Santiago Ruano Rincón wrote:
[...]
> > > Please consider the following debdiffs to fix librsvg's CVE-2015-7557
> > > for Jessie and Wheezy. This is a no-dsa bug, that could fit a point
> > > release. It applies the following simple patch, that upstream proposed
> > > against 2.40.6.
> > 
> > Please go ahead.
> > 
> 
> Thanks. Packages uploaded.

Both flagged for acceptance.

Regards,

Adam

Bug#815888: bb-bug

2016-03-27 Thread Fulano Diego Perez

hi peter,

thanks for getting back

you wrote:
> Hi Fulano, Luca,
> 
> On Sat, Mar 12, 2016 at 01:29:47AM +1100, Fulano Diego Perez wrote:
>> hi
>>
>> Debian GNU/Linux stretch/sid \n \l
>>
>> Linux hesse 4.3.0-1-amd64 #1 SMP Debian 4.3.5-1 (2016-02-06) x86_64
>> GNU/Linux
> [..]
>> optirun (Bumblebee) 3.2.1
>>
>> see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815888
> 
>>From the Xorg.0.log it is visible that novueau is loaded. This is
> related to PRIME, but is incompatible with Bumblebee (use one or the
> other, not both).
> 
>>From the dmesg I can see that bbswitch initially disabled the card, but
> later enabled it (presumably because nvidia loads it).
> 
> If you would like to use Bumblebee, then ensure that nothing autoloads
> nouveau nor nvidia (for example by blacklisting these modules). Somehow
> I don't see a Xorg.8.log, could this be related to rootless Xorg?

could be

thats what luca thought

stretch does have rootless Xorg

if thats the case, how can i get around this if at all possible ?

im not technically adept at all with this area

if there's this much trouble then i suggest the DEB package should make
a few adjustments somehow...it doesnt seem to work out-of-the-box

> 
> I must admit that I have not used Bumblebee in a while. With my new
> laptop having a GTX965M (still needs research to get PM working
> properly) I prefer PRIME anyway because I am only interested in an
> external monitor, not the acceleration.

my use case was for acceleration

so to be clear, how exactly do you suggest i get to this point ?

i didnt quite fully understand above

Bug#819353: dh-python: pybuild_commands() should fail-fast instead of returning an empty list

2016-03-27 Thread Ximin Luo

Package: dh-python
Version: 2.20151103
Severity: normal

Dear Maintainer,

I just spent 30 minutes figuring out why `debian/rules build` wasn't working
and the answer is that the newbie I am helping didn't put "python3-all-dev" in
his Build-Depends.

Most people won't think to look into the source code of pybuild to figure this
out, and giving VERBOSE/-v options to either dh or dh_auto_build don't work
either. All over the world many potential Debian contributors are having their
time wasted and getting discouraged because pybuild_commands in pybuild.pm
thinks it's normal to return an empty list and happily do nothing.

Please make it throw an obvious exception instead so that we can spend our time
more productively.

X

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

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

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

dh-python recommends no packages.

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

-- no debconf information

Bug#819352: xpdf: please make the build reproducible

2016-03-27 Thread Sascha Steinbiss

Package: xpdf
Version: 3.04-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering

Hi,

While working on the "reproducible builds" effort [1], we have noticed
that xpdf could not be built reproducibly.
The linking step in the 'override_dh_auto_build' rules target uses a
file ordering based on wildcards alone, which results in different
binaries for different file orderings.

The attached patch fixes this by making sure objects are linked in sorted
order. Once applied, xpdf can be built reproducibly in our current
experimental framework.

Best regards,
Sascha

[1]: https://wiki.debian.org/ReproducibleBuilds
diff -Nru xpdf-3.04/debian/rules xpdf-3.04/debian/rules
--- xpdf-3.04/debian/rules	2016-02-07 17:59:57.0 +
+++ xpdf-3.04/debian/rules	2016-03-27 11:21:10.0 +
@@ -14,8 +14,8 @@
 files+=xpdf/XPDFApp xpdf/XPDFCore xpdf/XPDFTree xpdf/XPDFViewer xpdf/xpdf
 headers=xpdf/config.h xpdf/XPDFTreeP.h xpdf/about-text.h xpdf/*.xbm xpdf/xpdfIcon.xpm
 
-sources=$(shell for file in $(files); do echo $$file.*; done)
-objects=$(shell for file in $(files); do echo build/$$(basename $$file).o; done)
+sources=$(sort $(shell for file in $(files); do echo $$file.*; done))
+objects=$(sort $(shell for file in $(files); do echo build/$$(basename $$file).o; done))
 
 override_dh_clean:
 	dh_clean
@@ -30,7 +30,7 @@
 	mv build/parseargs.c build/parseargs.cc
 
 override_dh_auto_build: $(objects)
-	$(CXX) $(LDFLAGS) -o build/xpdf.real build/*.o $(LIBS)
+	$(CXX) $(LDFLAGS) -o build/xpdf.real $^ $(LIBS)
 
 %:
 	dh ${@}

Bug#819351: firefox-esr: [iceweasel to firefox-esr] leaves empty /etc/iceweasel directory tree

2016-03-27 Thread Martin-Éric Racine

Package: firefox-esr
Version: 45.0.1esr-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

After the migration from iceweasel 44 to firefox-esr 45, an empty directory 
tree remains below /etc/iceweasel.

- -- Package-specific info:

- -- Addons package information
ii  firefox-esr45.0.1esr-1  i386 Mozilla Firefox web browser
ii  firefox-esr-l1 45.0.1esr-1  all  Finnish language package for Fire
ii  gnome-shell3.18.1-1 i386 graphical shell for the GNOME des
ii  xul-ext-mozvoi 2.0.1-1  all  Finnish spell-checker extension f

- -- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (1001, 'testing'), (1001, 'stable')
Architecture: i386 (i586)

Kernel: Linux 3.16.0-4-586
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firefox-esr depends on:
ii  debianutils   4.7
ii  fontconfig2.11.0-6.3
ii  libasound21.1.0-1
ii  libatk1.0-0   2.18.0-1
ii  libc6 2.22-3
ii  libcairo2 1.14.6-1
ii  libdbus-1-3   1.10.8-1
ii  libdbus-glib-1-2  0.106-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-4
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6.3-3
ii  libgcc1   1:5.3.1-12
ii  libgdk-pixbuf2.0-02.32.3-1.2
ii  libglib2.0-0  2.46.2-3
ii  libgtk2.0-0   2.24.30-1
ii  libhunspell-1.3-0 1.3.3-4
ii  libnspr4  2:4.12-1
ii  libnss3   2:3.23-1
ii  libpango-1.0-01.38.1-1
ii  libsqlite3-0  3.11.1-1
ii  libstartup-notification0  0.12-4
ii  libstdc++65.3.1-12
ii  libvpx3   1.5.0-2
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  procps2:3.3.11-3
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages firefox-esr recommends:
ii  gstreamer1.0-libav 1.6.3-1
ii  gstreamer1.0-plugins-good  1.6.3-1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-2.1
ii  libgnomeui-0   2.24.5-3.1
ii  libgssapi-krb5-2   1.13.2+dfsg-5
pn  mozplugger 

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJW+ArFAAoJEK4fgnfEtNe2Y94QAKAIrXKYusbKMcxDuv+uQTzA
FKIvQXU2AOtrgfoEitNx+lvHd+XzQJzOomZ+M8GjSWCUn1tjUUW3Oy0ClfZ1Ctss
awRka2kU8Ezry50TkviLV3kKH2LO8xdb6Fh335hgvgJmp6mokb4hE7EBXck0U4zI
A677CkbGhQwKfjSfY1rk40TyBK3l7OEARjohuXSPEzVtSI7wpM12y0fb2Ka1Onp7
km6l526F7SeEg6tONlJGT3W5eXmHTHlK85HKUkVHEK1JnsGkYCWySNbBC9DePTsm
RNnKhImcHz1xNU3wTCpcfxMztEiAgkvycBAyNg/zJoPxMn6qncGvy8JgH/NokI3w
wTkowJhYUFcqUUPJjkU41iwT7mJVzgqtgMoM0qSLH4oqagJFCiVE31RxqgZeEYn4
Q+fP8iUbQyXmyRHgZGlQI7DHqJXcAcq3HtOjo2OCg20x9O3A7S64om1BuEdZFbHa
SY9dG2kolgeG0ho86Qo3LlmteauTzLrhsiKfkucfIRcbPZUhi7CloZ10h4/BbcgS
dXjpe3J4PxDzxM0HfxMxUxOUzd6zorD0YzvK7G+YGz6MPiRbpBTw0eDex+rND8q1
VguMqNdzEElQ9s52EZ2fTL6aslEhe0SMGIM6FNQlNqFNr9zVVOxzczhM78T1dA5G
i3inljl9xX8RKdRdFdu6
=zfVb
-END PGP SIGNATURE-

Bug#819342: date command fails to parse some date strings close to a DST switch

2016-03-27 Thread Ben Hutchings

On Sun, 2016-03-27 at 02:34 -0600, Bob Proulx wrote:
> Ben Hutchings wrote:
> > 
> > $  readlink /etc/localtime
> > /usr/share/zoneinfo/Europe/London
> I assume that your locale is set to en_GB.UTF-8?  Could you provide
> the output of locale so that we could see the other settings?  I am
> interested in LC_TIME and LC_ALL particularly.

LANG=C.UTF-8
LANGUAGE=
LC_CTYPE="C.UTF-8"
LC_NUMERIC=en_GB.UTF-8
LC_TIME=en_GB.UTF-8
LC_COLLATE="C.UTF-8"
LC_MONETARY=en_GB.UTF-8
LC_MESSAGES="C.UTF-8"
LC_PAPER=en_GB.UTF-8
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT=en_GB.UTF-8
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=

[...]
> > This caused an upgrade of tzdata to fail for me.
> It doesn't seem to me be a problem with date.  Looking briefly at the
> tzdata postinst I see this:
> 
>   set -e
>   ...
> TZBase=$(LC_ALL=C TZ=UTC0 date)
> UTdate=$(LC_ALL=C TZ=UTC0 date -d "$TZBase")
> TZdate=$(unset TZ ; LANG=C date -d "$TZBase")
> 
> Initially I don't see how that can fail but I may be missing
> something.  Can you provide any more information?
> 
> I am probably missing something but I don't see a way for it to fail.
> 
> TZBase=$(LC_ALL=C TZ=UTC0 date)
> 
> That sets LC_ALL=C and therefore will have the standard format.
> (I wish it used date -R format instead.)

Yes, I was going to propose that change to tzdata before I realised
that it was already selecting a standard format.

[...]
> In all three cases it was able to parse that date string okay.  I wish
> it set LC_ALL instead of LANG however so as to remove any doubt.
> 
> What am I missing?

To reproduce this I think you'll need to select a date/time around the
DST transition in your time zone, or override TZ for the last command.

Try this:

TZBase=$(LC_ALL=C TZ=UTC0 date -d '2016-03-27 01:00')
UTdate=$(LC_ALL=C TZ=UTC0 date -d "$TZBase")
TZdate=$(TZ=Europe/London ; LANG=C date -d "$TZBase")

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth


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

Bug#819350: bugs.debian.org: 500 on attempt to view bug #819083

2016-03-27 Thread Ben Armstrong

Package: bugs.debian.org
Severity: normal

I believe my system is affected by:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819083

However, I cannot view this bug because it returns an HTTP status 500.
I can view some other bugs successfully, just not this one.

Meanwhile, I'll see if I can find this report in any of the related
list archives as a workaround.

Thanks,
Ben

Bug#819349: libnss3: broken AES on x32 on certain Intel CPUs

2016-03-27 Thread Adam Borowski

Package: libnss3
Version: 2:3.23-1
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: port-x32

Hi!
I'm afraid there's a problem in the hardware AES implementation on x32 on
certain Intel CPUs.  This is caught by the testsuite but only when the package
is built on one of such CPUs.  This includes the vs76 buildd but none of
machines I currently have access to.

I've narrowed the problem to intel_aes_*_worker() functions in freebl, their
implementation is in nss/lib/freebl/intel-gcm-x64-masm.asm .  Alas, properly
fixing this would require knowledge of obscure crypto opcodes, which I don't
possess.  Here's a patch that disables this acceleration until someone with
more clue can help.
Description: disable Intel AES on x32
 Currently intel_aes_*_worker() doesn't appear to work on x32, at least on
 certain newer Intel CPUs (all reported to fail were i7).  Thus, disable this
 acceleration on x32 until someone who knows these functions can help.
--- nss-3.23.orig/nss/lib/freebl/rijndael.c
+++ nss-3.23/nss/lib/freebl/rijndael.c
@@ -1066,6 +1066,9 @@ aes_InitContext(AESContext *cx, const un
 }
 use_hw_aes = (PRBool)
 		(has_intel_aes > 0 && (keysize % 8) == 0 && blocksize == 16);
+#if defined __x86_64__ && defined __ILP32__
+use_hw_aes = 0; // disable on x32 for now
+#endif
 #ifdef INTEL_GCM
 use_hw_gcm = (PRBool)
 		(use_hw_aes && has_intel_avx>0 && has_intel_clmul>0);

Bug#819348: cjs: Typo in package description

2016-03-27 Thread Thomas Vincent

Source: cjs
Severity: minor

Dear Maintainer,

I noticed a typo while translating the description of the cjs package.
In the first paragraph, "introsepection" should be indeed replaced by 
"introspection".

Thanks for your work on cjs,
Thomas


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#814030: Security flaw fixed in version 6.2.0

2016-03-27 Thread Moritz Mühlenhoff

On Sun, Feb 07, 2016 at 02:28:04PM -0400, David Prévot wrote:
> Package: php-tcpdf
> Version: 6.0.093+dfsg-1
> Severity: serious
> Tags: security upstream
> 
> According to their changelog [1], upstream fixed a security issue over a
> year ago:
> 
> 6.2.0 (2014-12-10)
>   - Bug #1005 "Security Report, LFI posting internal files externally 
> abusing default parameter" was fixed.
> 
>   1: https://sourceforge.net/p/tcpdf/code/ci/master/tree/CHANGELOG.TXT
> 
> The upstream bug report [2] is not public, so I don’t have much
> information about the issue, the fix, nor it’s actual severity.
> 
>   2: https://sourceforge.net/p/tcpdf/bugs/1005/

Can you contact upstream for information on this security bug? I have
no idea what that could possibly mean.

Cheers,
Moritz

Bug#816169: RFS: fake-factory/0.5.3-1

2016-03-27 Thread Wookey

+++ Christopher Baines [2016-03-27 10:49 +0100]:
> On 20/03/16 03:12, Mattia Rizzolo wrote:
> A possible alternative would be to include a manpage made with help2man,
> and not generate it for this version (and switch to generating it later)?

Help2man breaks cross-building and is thus best avoided if
possible. Adding support for a 'nodocs' profile to skip its use is one
way to (mostly) deal with that.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

signature.asc
Description: Digital signature

Bug#786873: Fw: Openchrome-users Digest, Vol 30, Issue 6

2016-03-27 Thread Andreas Glaeser

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Begin forwarded message:

Date: Sat, 26 Mar 2016 15:52:27 +
From: openchrome-users-requ...@lists.freedesktop.org
To: openchrome-us...@lists.freedesktop.org
Subject: Openchrome-users Digest, Vol 30, Issue 6


Send Openchrome-users mailing list submissions to
openchrome-us...@lists.freedesktop.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.freedesktop.org/mailman/listinfo/openchrome-users
or, via email, send a message with subject or body 'help' to
openchrome-users-requ...@lists.freedesktop.org

You can reach the person managing the list at
openchrome-users-ow...@lists.freedesktop.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Openchrome-users digest..."


Today's Topics:

   1. New openchrome driver -version appeared inDebian-testing
  (Andreas Glaeser)


- --

Message: 1
Date: Sat, 26 Mar 2016 16:35:23 +0100
From: Andreas Glaeser 
To: openchrome-us...@lists.freedesktop.org
Subject: [Openchrome-users] New openchrome driver -version appeared in
Debian-testing
Message-ID: <20160326163523.3629560d@a68n.lokal>
Content-Type: text/plain; charset=US-ASCII

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Openchrome-driver was removed from testing a while ago, today I found, there is 
actually
a new one:
> Package: xserver-xorg-video-openchrome
> State: installed
> Automatically installed: no
> Version: 1:0.3.3+git20160310-1
> Priority: optional
> Section: x11
> Maintainer: Debian X Strike Force 
> Architecture: i386
> Uncompressed Size: 584 k
> Depends: libc6 (>= 2.1.3), libdrm2 (>= 2.3.1), libx11-6 (>= 2:1.4.99.1),
>  libxext6, libxv1, libxvmc1, xorg-video-abi-20, xserver-xorg-core (>=
>  2:1.17.99.902)
> Provides: xorg-driver-video
> Description: X.Org X server -- VIA display driver
>  OpenChrome is a project for the development of free and open-source drivers 
> for
>  the VIA UniChrome video chipsets. 
>  
>  Originally called the 'snapshot' release, since it was a snapshot of an
>  experimental branch of the unichrome cvs code, this is a continued 
> development
>  of the open source unichrome driver (from http://unichrome.sf.net) which also
>  incorporates support for the unichrome-pro chipsets. 
>  
>  Support for hardware acceleration (XvMC) for all chipsets has subsequently 
> been
>  ripped out of the unichrome.sf.net driver. Therefore your only option if you
>  wish to make use of the acceleration features of your VIA chip with free and
>  open-source drivers is to use this version of the driver.
> Homepage: https://www.freedesktop.org/wiki/Openchrome/
> Tags: hardware::video, implemented-in::c, role::plugin,
> use::driver 

I filed some bugs already in the Debian BTS regarding the openchrome-driver 
with some
thin-clients of mine, this particular problem appears with a mobile 
thin-client, that
fails to show any graphics, only the external VGA-screen works, and I think the 
situation
is widely unchanged with the new driver-version, just it doesn't point to 
openchrome.org
anymore, it has a VM800 chipset:

> [23.756] 
> X.Org X Server 1.18.2
> Release Date: 2016-03-11
> [23.757] X Protocol Version 11, Revision 0
> [23.757] Build Operating System: Linux 3.16.0-4-amd64 i686 Debian
> [23.757] Current Operating System: Linux m100 4.4.0-1-686-pae #1 SMP 
> Debian 4.4.6-1
> (2016-03-17) i686
[23.757] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-1-686-pae
root=UUID=1fd1c268-3803-45bf-b597-169e87e17e4a ro quiet
> [23.758] Build Date: 12 March 2016  07:32:54AM
> [23.758] xorg-server 2:1.18.2-1 (http://www.debian.org/support) 
> [23.758] Current version of pixman: 0.33.6
> [23.758]  Before reporting problems, check http://wiki.x.org
>   to make sure that you have the latest version.
> [23.758] Markers: (--) probed, (**) from config file, (==) default 
> setting,
>   (++) from command line, (!!) notice, (II) informational,
>   (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [23.759] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Mar 26 11:00:42 
> 2016
> [23.766] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
> [23.774] (==) No Layout section.  Using the first Screen section.
> [23.774] (==) No screen section available. Using defaults.
> [23.774] (**) |-->Screen "Default Screen Section" (0)
> [23.774] (**) |   |-->Monitor ""
> [23.780] (==) No monitor specified for screen "Default Screen Section".
>   Using a default monitor configuration.
> [23.780] (==) Automatically adding devices
> [23.780] (==) Automatically enabling devices
> [23.780] (==) Automatically adding GPU devices
> [23.780] (==) Max clients allowed: 256, resource mask: 0x1f
> [

Bug#812174: Update #812174: Updated wnpp info

2016-03-27 Thread Daniel Beyer

Package: wnpp
Severity: wishlist
Owner: Daniel Beyer 


* Package name: letsencrypt.sh
  Version : 0.1.0
  Upstream Author : Lukas Schauer 
* URL : https://github.com/lukas2511/letsencrypt.sh
* License : Expat
  Programming Lang: Bash
  Description : ACME client implemented in Bash

The letsencrypt.sh ACME client allows signing certificates with an
ACME server, like the one provided by the Let’s Encrypt certificate
authority (letsencrypt.org). It is implemented as a relatively simple
Bash script, which uses curl to communicate with the ACME server and
OpenSSL to deal with keys, sign requests and certificates.
.
The ACME (Automated Certificate Management Environment) protocol makes
it possible to automatically obtain browser-trusted certificate.


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

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

2016-03-27 Thread Karsten Hilbert

Is there anything else I can provide to get this bug looked at ?

Thanks,
Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Bug#812174: ITP: letsencrypt-sh -- ACME client implemented in Bash

2016-03-27 Thread Daniel Beyer

Hi Mattia,

thanks a lot for pushing this ITP.

On Sat, 2016-03-26 at 21:07 +, Mattia Rizzolo wrote:
> On Thu, Jan 21, 2016 at 08:10:13AM +0100, Daniel Beyer wrote:
> > * Package name: letsencrypt-sh
> 
> Is there a good reason not to call this package 'letsencrypt.sh', with a
> dot, as the official name?
> 

No, there is no good reason for it. I wrongly thought a dot in a package
name is not permitted. Let's name it letsencrypt.sh.

> 
> Anyway, this email was to ask how it's going with this.

Since I needed it, I made some initial packaging [1] on GitHub, which
fit my needs right know. It of course need some more work to get it
ready for Debian (e.g. it needs to be rebased against upstream's v0.1.0
and the repo should be moved to anonscm.d.o).

> It should be a
> fairly simple package, and I'm quite interested in it (can also sponsor
> it or help to comaintain it, as you like, if you need it!).
> 

I might have overcomplicated things a bit with the current packaging
approach (e.g. providing apache configuration). You might want to take a
look yourself and share your thoughts.
If you're up for it, I gratefully would like to accept your offer to
co-maintain this package. Additionally it might be worth to ask having
it under the umbrella of Debian Let's Encrypt [2].

Let me know if you think we can base our work on what I've done so far,
or if we instead should make a fresh start.

Greetings
Daniel

[1] https://github.com/ymc/letsencrypt.sh
[2] 
https://qa.debian.org/developer.php?login=letsencrypt-devel%40lists.alioth.debian.org

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

Bug#787334: qgit: "Amend Commit" incorrectly adds some garbage to the commit message

2016-03-27 Thread Andrey Rahmatullin

On Sun, May 31, 2015 at 05:12:40PM +0200, Ralf Jung wrote:
> "Amend Commit" incorrectly adds some garbage to the commit message. This can 
> be reproduced as follows:
> 1. Go to some git repo with a local change
> 2. Choose "Edit" - "Amend Commit"
> 3. Don't touch the commit message, jus hit "Ammend"
> 
> Now check the new commit message. It is *not* the same as the old one, 
> instead "on branch " and
> some file information has been added.
> The reason seems to be that qgit does not correctly process the suggested 
> message it gets from git,
> removing too many "#". When I use git on the CLI, the lines that qgit adds 
> start with a "#" and
> are hence ignored by git.
> 
> This is a regression, in earlier versions of git + qgit (like, a year ago or 
> so), things worked
> all right.
I cannot reproduce this with git 1:2.8.0~rc3-1, can you recheck?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#816982: maxima: FTBFS when built with dpkg-buildpackage -A (tests fail)

2016-03-27 Thread Santiago Vila

On Wed, 16 Mar 2016, Camm Maguire wrote:

> Greetings!  Could you also please try changing the following line from
> debian/rules:
> 
> echo ':lisp (setq maxima::*maxima-started* nil si::*optimize-maximum-pages* t 
> si::*code-block-reserve* (make-array 1000 :element-type (quote character) 
> :static t))(si::sgc-on nil)(si::gbc t)(si::save-system "foo")' | 
> ./maxima-local && mv foo src/binary-gcl/maxima
> 
> 
> to 
> 
> echo ':lisp (setq maxima::*maxima-started* nil si::*optimize-maximum-pages* t 
> si::*code-block-reserve* (make-array 5000 :element-type (quote character) 
> :static t))(si::sgc-on nil)(si::gbc t)(si::save-system "foo")' | 
> ./maxima-local && mv foo src/binary-gcl/maxima

Ok, tried today with the old configuration (5GB RAM + 2GB swap) using
a swap file.

The above change does not fix the build.

The way it fails is the same as before:

Error summary:
Errors found in /build/MAXIMA/maxima-5.37.3/tests/rtest15.mac, problems:
(47 49 55 61 67 73 79 85 91 165 174)
Error found in /build/MAXIMA/maxima-5.37.3/tests/rtest8.mac, problem:
(133)

To summarize so far:

A. It worked one month ago with only 2GB of RAM + 2 GB of swap.
B. It fails with 5GB of RAM + 2 GB of swap.
C. It works with 5GB of RAM + 3 GB of swap.

Why more memory (from A to B) should make a program to fail is still a
complete mystery to me.

Could you please try on a machine with 5GB of RAM + 2 GB of swap?
(If you are not used to virtual machines, try virt-manager, it works great).

In the meantime, I would suggest setting GCL_MEM_MULTIPLE=0.5
somewhere in debian/rules. I have the feeling that the upstream
default of 1.0 is not a good one.

Thanks.

Bug#819277: [pkg-cinnamon] Bug#819277: Bug#819277: cinnamon-screensaver: Cant put my password when in lock screen

2016-03-27 Thread Fabio Fantoni

Il 27/03/2016 11:44, Maximiliano Curia ha scritto:
> ¡Hola Casanova!
>
> El 2016-03-25 a las 20:01 -0300, Casanova Phillips escribió:
>> Package: cinnamon-screensaver Version: 2.2.4-6 Severity: wishlist
>>
>> When I wait for the lock screen, sometimes when I try to type my
>> password I can't. So I have to change user to go to the other screen
>> and type my username and password there. I don't know how to
>> reproduce it, because it only happens sometimes. When I change user
>> and go to the login screen I can type my password with no problem. I
>> was expecting to be able to type my password in the first lock screen.
>>
>> That's the lock screen where I can't type my password:
>> http://i.imgur.com/ HQ5GiEQ.png
>
> I've heard of a similar bug in the past, that I thought it was fixed.
>
> When you finally manage to unlock the screen is there a new pop-up
> showing up in your desktop? Is this a pop-up showing up coming from
> google-chrome or chromium?
>
> It's possible that this is fixed in the cinnamon version that is
> currently available in testing, we are working on making this version
> available as a backport to stable. Would you be interested in testing
> this when it's available?
>
> Happy hacking,
>

I also reproduced this problem with older cinnamon but if I remember
good I never had it with newer cinnamon versions.
A backport to jessie I think can be very useful to solves some bugs and
improve some important things.



smime.p7s
Description: Firma crittografica S/MIME

Bug#769016: [Debian-in-workers] Bug#769016: Bug#769016: Bug#769016: aspell-ml: Invalid format for /usr/lib/aspell/ml.rws

2016-03-27 Thread Vasudev Kamath


Hello Francois,

Francois Gouget  writes:

>> >> > Any news on this?
>> >> > It's been over a year...
>> >> 
>> >> Sorry for the delay I just missed all these bugs. But I wonder what is
>> >> the way to fix this bug. Any suggestions appreciated.
>> >
>> > According to a quick test it seems like all that's needed is to rebuild 
>> > the package.
>> 
>> Alright. I will do that and ask for upload of package. I wonder if its
>> possible just to ask buildd's to rebuild the affected packages?. Oh well
>> there is no Arch: all buildd's I guess.
>
> I don't see any package update in Unstable. It's still 0.04-1-6 which 
> was released in 2014...
> Same thing for aspell-or, aspell-pa and aspell-te.
>
> Should these packages deprecated? If so they should be removed from the 
> repository. At least things would be clear then.


I do not have upload rights on mentioned packages, so I had asked
Karthik (cced ) on IRC to rebuild and upload them. Guess he missed it.

Karthik can you please rebuild and upload the affected packages?.

Cheers,


signature.asc
Description: PGP signature

Bug#769016: [Debian-in-workers] Bug#769016: Bug#769016: aspell-ml: Invalid format for /usr/lib/aspell/ml.rws

2016-03-27 Thread Francois Gouget

On Mon, 7 Dec 2015, Vasudev Kamath wrote:

> Francois Gouget  writes:
> 
> > On Sun, 6 Dec 2015, Vasudev Kamath wrote:
> >
> >> Hi Francois,
> >> 
> >> Francois Gouget  writes:
> >> 
> >> > Any news on this?
> >> > It's been over a year...
> >> 
> >> Sorry for the delay I just missed all these bugs. But I wonder what is
> >> the way to fix this bug. Any suggestions appreciated.
> >
> > According to a quick test it seems like all that's needed is to rebuild 
> > the package.
> 
> Alright. I will do that and ask for upload of package. I wonder if its
> possible just to ask buildd's to rebuild the affected packages?. Oh well
> there is no Arch: all buildd's I guess.

I don't see any package update in Unstable. It's still 0.04-1-6 which 
was released in 2014...
Same thing for aspell-or, aspell-pa and aspell-te.

Should these packages deprecated? If so they should be removed from the 
repository. At least things would be clear then.

-- 
Francois Gouget   http://fgouget.free.fr/
The nice thing about meditation is that it makes doing nothing quite respectable
  -- Paul Dean

Bug#818906: wheezy-pu: package dpkg/1.16.18

2016-03-27 Thread Guillem Jover

Hi!

On Wed, 2016-03-23 at 18:07:46 +0100, Guillem Jover wrote:
> On Mon, 2016-03-21 at 16:36:16 +0100, Guillem Jover wrote:
> > Package: release.debian.org
> > Severity: normal
> > Tags: wheezy
> > User: release.debian@packages.debian.org
> > Usertags: pu
> 
> > Here's a proposed dpkg 1.16.18, with cherry picked fixes from master
> > (already in unstable). These include fixes for regressions, memory leaks,
> > segmentation faults, portability and interaction with tools such as
> > GNU tar or the system shell.
> > 
> > The change for Config-Version should be safe, as at worst it will have
> > no effect, otherwise packages relying on the correct behavior will
> > start to work now.
> > 
> > The «git log» fix is not yet in master though, but it should also be safe,
> > otherwise the build would simply fail. And I've just realized it's not
> > documented in debian/changelog, it will be in the ChangeLog, but I could
> > add it to debian/changelog too.
> > 
> > The changes have passed all unit tests which are part of the build,
> > and all functional test in the dpkg-tests git repo. Attached a diff
> > with translation updates filtered.
> 
> The same reply as the one for jessie applies here. I've also taken out
> the git log fix here, and I'm attaching the compressed full diff. Let
> me know if anything else needs clarification, etc.

Same as for the 1.17.x release, I've removed the string changes in the
man page and rerolled the release. Attached the new patch.

Thanks,
Guillem


dpkg-1.16.17-1.16.18.debdiff.xz
Description: application/xz

Bug#818908: jessie-pu: package dpkg/1.17.27

2016-03-27 Thread Guillem Jover

Hi!

On Wed, 2016-03-23 at 20:52:04 +0100, Julien Cristau wrote:
> On Mon, Mar 21, 2016 at 16:49:35 +0100, Guillem Jover wrote:
> > diff --git a/man/dpkg.1 b/man/dpkg.1
> > index 4e9f7a3..fb6c43e 100644
> > --- a/man/dpkg.1
> > +++ b/man/dpkg.1
> > @@ -694,8 +694,9 @@ Sent just before a processing stage starts. \fIstage\fR 
> > is one of
> >  .TP
> >  \fB\-\-status\-logger\fR=\fIcommand\fR
> >  Send machine-readable package status and progress information to the
> > -shell \fIcommand\fR's standard input. This option can be specified
> > -multiple times. The output format used is the same as in \fB\-\-status\-fd.
> > +shell \fIcommand\fR's standard input, to be run via \*(lqsh \-c\*(rq.
> > +This option can be specified multiple times.
> > +The output format used is the same as in \fB\-\-status\-fd.
> >  .RE
> >  .TP
> >  \fB\-\-log=\fP\fIfilename\fP
> > @@ -739,7 +740,7 @@ temporary files and directories.
> >  The program \fBdpkg\fP will execute when displaying the conffiles.
> >  .TP
> >  .B SHELL
> > -The program \fBdpkg\fP will execute when starting a new shell.
> > +The program \fBdpkg\fP will execute when starting a new interactive shell.
> >  .TP
> >  .B COLUMNS
> >  Sets the number of columns \fBdpkg\fP should use when displaying formatted
> 
> This change regresses translations.  As it's essentially a clarification
> rather than a fix to the previous text, wouldn't it be better to leave
> the text as-is so as not to invalidate existing translations?

I always hesitate with string changes, as PO files are designed to
cope with this gracefully, but in this case I guess it's indeed
probably not worth it. So I've removed them and rerolled the release.
Attached the new patch.

Thanks,
Guillem


dpkg-1.17.26-1.17.27.debdiff.xz
Description: application/xz

Bug#816169: RFS: fake-factory/0.5.3-1

2016-03-27 Thread Christopher Baines

On 20/03/16 03:12, Mattia Rizzolo wrote:
>> The issues that you commented on above are fixed in this repository.
>>
>> 1: https://anonscm.debian.org/cgit/python-modules/packages/faker.git
> 
> of what I wrote before these still need fixing:
> 
> * debian/control:
>   + I: fake-factory source: duplicate-long-description python-fake-factory 
> python3-fake-factory
>   + I: python-fake-factory: extended-description-is-probably-too-short
>   + I: python3-fake-factory: extended-description-is-probably-too-short

I have added the Python version to the extended description, which fixes
these lintian issues.

> of the manpage erros you output, I can see man has to complain about
> this:
> 
> :8: warning [p 1, 1.7i]: cannot adjust line
> :8: warning [p 1, 1.8i]: can't break line
> :33: warning [p 1, 5.3i, div `an-div', 0.0i]: cannot adjust 
> line
> :33: warning [p 1, 5.3i, div `an-div', 0.2i]: can't break line
> :33: warning [p 1, 5.3i, div `an-div', 0.3i]: cannot adjust 
> line
> :33: warning [p 1, 5.3i, div `an-div', 0.5i]: can't break line
> 
> Indeed `faker --help` outputs this
> 
>   -l 
> {lt_LT,lv_LV,de_AT,tr_TR,sv_SE,no_NO,pt_PT,it_IT,en_US,en_CA,en,zh_TW,fi_FI,hi_IN,hr_HR,fa_IR,bg_BG,zh_CN,sk_SK,fr_FR,en_GB,dk_DK,es,en_AU,sl_SI,el_GR,la,de_DE,bs_BA,uk_UA,pt_BR,nl_NL,pl_PL,ru_RU,cs_CZ,ja_JP,es_ES,ko_KR,es_MX,ne_NP},
>  --lang 
> {lt_LT,lv_LV,de_AT,tr_TR,sv_SE,no_NO,pt_PT,it_IT,en_US,en_CA,en,zh_TW,fi_FI,hi_IN,hr_HR,fa_IR,bg_BG,zh_CN,sk_SK,fr_FR,en_GB,dk_DK,es,en_AU,sl_SI,el_GR,la,de_DE,bs_BA,uk_UA,pt_BR,nl_NL,pl_PL,ru_RU,cs_CZ,ja_JP,es_ES,ko_KR,es_MX,ne_NP}
> specify the language for a localized provider (e.g.
> de_DE)
> 
> well, that's awful.
> did you manually fix this in the build manpage by any chance?

Yes

> imho the proper fix for this thing would be to have argparse (or
> whatever thing this library/app is using to parse the options) to not
> output the recognized options, and output them formatted in a saner way
> (e.g. separated by ', ') at the bottom of the --help, then maybe
> help2man will need some help to handle that correctly, though.
> 
> And BTW, I have another feeling that the list of languages is stored
> inside a set, and that is passed to argparse as a list of valid options;
> well, that makes argparse output non-reproducible, and as such the
> generated manpage is non reproducible; please make that either a real
> list (so the elements have a fixed position) or sort the set before
> passing it over to argparse, so that the output is reproducible between
> runs (and as such between rebuilds).
> https://paste.debian.net/plain/417202 (this is not built with the
> reproducible toolchain, and as such there is noise about filesystem
> order (actually there is not, but this is by chance) and timestamps
> inside the {control,data}.tar member of the .deb, that in the
> reproducible toolchain is fixed by a patched dpkg not yet included in
> dpkg mainstream)

I have made a pull request to the upstream project, improving the help
output in a way that will fix these issues [1]. Its a bit awkward, but
is the best step to take next, to wait for upstream to do a release with
these changes?

A possible alternative would be to include a manpage made with help2man,
and not generate it for this version (and switch to generating it later)?

1: https://github.com/joke2k/faker/pull/342



signature.asc
Description: OpenPGP digital signature

Bug#819347: starvoyager: please make the build reproducible

2016-03-27 Thread Sascha Steinbiss

Source: starvoyager
Version: 0.4.4-5.1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering

Dear Maintainer,

While working on the "reproducible builds" effort [1], we have noticed
that starvoyager could not be built reproducibly.

The Makefile uses wildcards in the linker call, leading to unstable input file
order and potentially different resulting binaries. I have attached a patch
to use a fixed order for input object files. This makes the build reproducible
for me in my local test environment.

Regards,
Sascha

[1]: https://wiki.debian.org/ReproducibleBuilds
diff -u starvoyager-0.4.4/debian/patches/00list starvoyager-0.4.4/debian/patches/00list
--- starvoyager-0.4.4/debian/patches/00list
+++ starvoyager-0.4.4/debian/patches/00list
@@ -3,0 +4 @@
+03_deterministic-linker-input
only in patch2:
unchanged:
--- starvoyager-0.4.4.orig/debian/patches/03_deterministic-linker-input.dpatch
+++ starvoyager-0.4.4/debian/patches/03_deterministic-linker-input.dpatch
@@ -0,0 +1,19 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## 03_deterministic-linker-input.patch.dpatch by Sascha Steinbiss 
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: No description.
+
+@DPATCH@
+diff -urNad '--exclude=CVS' '--exclude=.svn' '--exclude=.git' '--exclude=.arch' '--exclude=.hg' '--exclude=_darcs' '--exclude=.bzr' starvoyager-0.4.4~/Makefile starvoyager-0.4.4/Makefile
+--- starvoyager-0.4.4~/Makefile	2002-11-14 01:27:58.0 +
 starvoyager-0.4.4/Makefile	2016-03-27 09:32:05.492542234 +
+@@ -16,7 +16,7 @@
+ 
+ #Linking
+ starvoyager: alliance.o camera.o database.o error.o game.o interface.o presence.o ship.o sound.o ticker.o calc.o client.o equip.o frag.o graphic.o planet.o server.o sockhelper.o sv.o player.o os.o SDL_rotozoom.o SDL_gfxPrimitives.o
+-	$(CC) -o starvoyager *.o $(LIBS)
++	$(CC) -o starvoyager $^ $(LIBS)
+ 
+ #Include dependencies
+ *.o: *.h

Bug#819277: [pkg-cinnamon] Bug#819277: cinnamon-screensaver: Cant put my password when in lock screen

2016-03-27 Thread Maximiliano Curia


¡Hola Casanova!

El 2016-03-25 a las 20:01 -0300, Casanova Phillips escribió:
Package: cinnamon-screensaver 
Version: 2.2.4-6 
Severity: wishlist


When I wait for the lock screen, sometimes when I try to type my password I 
can't. So I have to change user to go to the other screen and type my username 
and password there. I don't know how to reproduce it, because it only happens 
sometimes. When I change user and go to the login screen I can type my password 
with no problem. I was expecting to be able to type my password in the first 
lock screen.


That's the lock screen where I can't type my password: http://i.imgur.com/ 
HQ5GiEQ.png


I've heard of a similar bug in the past, that I thought it was fixed.

When you finally manage to unlock the screen is there a new pop-up showing up 
in your desktop? Is this a pop-up showing up coming from google-chrome or 
chromium?


It's possible that this is fixed in the cinnamon version that is currently 
available in testing, we are working on making this version available as a 
backport to stable. Would you be interested in testing this when it's 
available?


Happy hacking,
--
“First, solve the problem. Then, write the code.” -- John Johnson
Saludos /\/\ /\ >< `/


signature.asc
Description: Digital signature

Bug#745732: fontforge: Please package new version

2016-03-27 Thread Laurent Bigonville

On Thu, 24 Apr 2014 10:49:34 -0400 "D. Stuart Freeman" 
 wrote:

>
> Dear Maintainer,

Hello,

> The version of fontforge currently in unstable is nearly 2 years out 
of date.

> Version 2.0 was released 4 months ago, see:
> https://github.com/fontforge/fontforge/releases

What is the status of this? There are at least two fonts waiting for a 
new version of fontforge ATM.

Would be really nice to have a new version for stretch.

Cheers,

Laurent Bigonville

Bug#818122: docker.io: FTBFS in stretch

2016-03-27 Thread Tianon Gravi

On 26 March 2016 at 23:37, Dmitry Smirnov  wrote:
> Thank you. It would be awesome if you could have a look whether you can build
> newer Docker. I think I've uploaded most if not all the dependencies it needs
> but there seems to be a problem with versioning of docker-notary and docker-
> distribution as Docker FTBFS with released versions of those libs...

After resolving the runc incompatibilities (whose resolutions were
actually pretty similar for either Docker 1.8.3 or 1.9.1), I run into
a non-trivial number of others, especially related to distribution.
I'm thinking we're probably too late to get 1.9.1 even building
successfully at this point, and should start looking directly at
1.10.3 (and hopefully the containerd dust that's coming with 1.11
settles before that's officially GA).

For posterity, here's the list of things I didn't feel were really
worth digging further into for getting 1.9.1 building properly:

# github.com/docker/libnetwork/iptables
.gopath/src/github.com/docker/libnetwork/iptables/firewalld.go:75:
cannot use c.sysconn.Object(dbusInterface, dbus.ObjectPath(dbusPath))
(type dbus.BusObject) as type *dbus.Object in assignment: need type
assertion
# github.com/docker/docker/daemon/logger/awslogs
.gopath/src/github.com/docker/docker/daemon/logger/awslogs/cloudwatchlogs.go:60:
undefined: aws.DefaultConfig in aws.DefaultConfig.Region
.gopath/src/github.com/docker/docker/daemon/logger/awslogs/cloudwatchlogs.go:60:
cannot assign to aws.DefaultConfig.Region
.gopath/src/github.com/docker/docker/daemon/logger/awslogs/cloudwatchlogs.go:82:
undefined: aws.DefaultConfig
.gopath/src/github.com/docker/docker/daemon/logger/awslogs/cloudwatchlogs.go:84:
undefined: aws.DefaultConfig in aws.DefaultConfig.Merge
# github.com/docker/docker/graph
.gopath/src/github.com/docker/docker/graph/pull_v2.go:69: manSvc.Tags
undefined (type distribution.ManifestService has no field or method
Tags)
.gopath/src/github.com/docker/docker/graph/pull_v2.go:240:
manSvc.GetByTag undefined (type distribution.ManifestService has no
field or method GetByTag)
.gopath/src/github.com/docker/docker/graph/pull_v2.go:247: undefined:
manifest.Manifest
.gopath/src/github.com/docker/docker/graph/pull_v2.go:443: undefined:
manifest.Manifest
.gopath/src/github.com/docker/docker/graph/pull_v2.go:443: undefined:
manifest.SignedManifest
.gopath/src/github.com/docker/docker/graph/pull_v2.go:467: undefined:
manifest.Manifest
.gopath/src/github.com/docker/docker/graph/pull_v2.go:490: undefined:
manifest.Manifest
.gopath/src/github.com/docker/docker/graph/pull_v2.go:536: undefined:
manifest.Manifest
.gopath/src/github.com/docker/docker/graph/push_v2.go:238: undefined:
manifest.Manifest
.gopath/src/github.com/docker/docker/graph/registry.go:102: undefined:
manifest.SignedManifest
.gopath/src/github.com/docker/docker/graph/pull_v2.go:467: too many errors
# github.com/docker/docker/api/client
.gopath/src/github.com/docker/docker/api/client/trust.go:444: cannot
use "github.com/endophage/gotuf/data".Hashes literal (type
"github.com/endophage/gotuf/data".Hashes) as type
"github.com/docker/notary/tuf/data".Hashes in field value
.gopath/src/github.com/docker/docker/api/client/trust.go:458:
ks.RootKeyStore undefined (type *keystoremanager.KeyStoreManager has
no field or method RootKeyStore)
.gopath/src/github.com/docker/docker/api/client/trust.go:462:
ks.GenRootKey undefined (type *keystoremanager.KeyStoreManager has no
field or method GenRootKey)
.gopath/src/github.com/docker/docker/api/client/trust.go:468:
ks.GetRootCryptoService undefined (type
*keystoremanager.KeyStoreManager has no field or method
GetRootCryptoService)


♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#812087: [pcscd] takes 100 % cpu

2016-03-27 Thread Eric Valette


On 26/03/2016 14:01, Ludovic Rousseau wrote:



Le 25/03/2016 12:52, Eric Valette a écrit :

On 03/24/2016 06:56 PM, Ludovic Rousseau wrote:

LIBUSB_DEBUG=99 pcscd -dfaT | tee log.txt


Here it is.

NB: the process was actually at 106% after inerting the key before I
stooped.


Eric,
 From the pcscd trace you sent I see that an application (or maybe 2
because I see 2 clients) is continuously calling SCardGetStatusChange()
with a 200 ms timeout.


Ye I noticed it too while taling the traces. However it started before 
the key was inserted and did not lead to noticeable CPU consumption.


In pcsc-lite 1.8.16 (that should arrive in Debian testing on Monday 28th
March 2016) I fixed a bug related to SCardCancel() and
SCardGetStatusChange().
Maybe that would fix the problem you have.


Given what I said earlier, I'm not sure but I will test and report.



Do you know what application is using pcscd?
To list all the applications using libpcsclite you can use:
$ sudo lsof /usr/lib/x86_64-linux-gnu/libpcsclite.so.1

Have you configured wpa_supplicant (Wifi password) to use the smart card?


No. Unless a kde stuff is doing that I normally use smart card only for 
VPN access "manually".


-- eric

Bug#819346: maint-guide: [Patch] Link to Lintian User's Manual failed

2016-03-27 Thread mechtilde

Source: maint-guide
Severity: normal
Tags: patch

Link to Lintian User's Manual gives "page not found"


I created a git patch:

index 3f806d4..fda6537 100644 (file)
--- a/common.ent
+++ b/common.ent
@@ -109,7 +109,7 @@ Remember, the *first* definition of an entity wins.
 https://bugs.launchpad.net/launchpad-
buildd/+bug/238141">
 http://en.wikipedia.org/wiki/Library_(computing)">
 http://en.wikipedia.org/wiki/GNU_Libtool;>
-
+https://lintian.debian.org/manual/index.html;>
 https://lists.debian.org/devel.html;>
 https://lists.debian.org/users.html;>
 http://upsilon.cc/~zack/talks/2011/20110321-taipei.pdf;>




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

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

Bug#818984: extplorer: Should extplorer be removed from Debian?

2016-03-27 Thread Salvatore Bonaccorso

Control: reassign -1 ftp.debian.org 
Control: retitle -1 RM: extplorer -- unmaintained, last update in 2012

Hi Thomas,

On Tue, Mar 22, 2016 at 04:16:27PM +0100, Salvatore Bonaccorso wrote:
> Source: extplorer
> Severity: normal
> 
> Hi Thomas,
> 
> extplorer is unmaintained in Debian unstable for a while now, the last
> upload was back in 2012. It got later a DSA for wheezy. But it was
> newer updated to a newer upstream version.
> 
> I will reassign this bug to ftp.d.o to request a removal in say about
> a week. If you disagree let me know please.

Doing so now.

Regards,
Salvatore

Bug#819291: pitivi: 0.95-1+b1 segfaults against gtk+3.0 3.20

2016-03-27 Thread Sebastian Dröge

On Sa, 2016-03-26 at 17:42 -0700, Marc J. Driftmeyer wrote:
> I unfortunately had not tested Pitivi of late. I'll see if I can run
> a debug set up and get back to you.

Thanks! For me pitivi still runs fine with the latest versions of
everything.

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

Bug#819314: procps: [sysctl] Missing dependency when used with systemd

2016-03-27 Thread Michael Biebl

Control: tags -1 + moreinfo

On Sat, 26 Mar 2016 16:03:24 +0100 Martin Mares  wrote:
> Package: procps
> Version: 2:3.3.9-9
> Severity: normal
> 
> With sysvinit, the init script for procps ensures that sysctl's
> are set before networking is started (via X-Start-Before: $network).
> 
> When run with systemd, procps.service does not have such dependency.
> Since system startup is highly parallel, there is a race condition:
> sometimes network interfaces are initialized before net.ipv6.conf.default.*
> is set.
> 

Are you sure?
networking.service has
> After=local-fs.target network-pre.target apparmor.service 
> systemd-sysctl.service

This makes sure that networking.service, which deals with type auto
interfaces, is started after systemd-sysctl.service.

And for hotplugged devices

/lib/udev/rules.d/99-systemd.rules contains
> 99-systemd.rules:# Apply sysctl variables to network devices (and only to 
> those) as they appear.
> 99-systemd.rules:ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo", 
> RUN+="/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name 
> --prefix=/net/ipv4/neigh/$name --prefix=/net/ipv6/conf/$name 
> --prefix=/net/ipv6/neigh/$name"

Can you explain the specific problem you ran into and what configuration
you are using exactly.


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



signature.asc
Description: OpenPGP digital signature

Bug#819342: date command fails to parse some date strings close to a DST switch

2016-03-27 Thread Bob Proulx

Ben Hutchings wrote:
> $  readlink /etc/localtime
> /usr/share/zoneinfo/Europe/London

I assume that your locale is set to en_GB.UTF-8?  Could you provide
the output of locale so that we could see the other settings?  I am
interested in LC_TIME and LC_ALL particularly.

  locale

> $ date -d 00:59
> Sun 27 Mar 00:59:00 GMT 2016
> $ date -d "Sun 27 Mar 00:59:00 GMT 2016"
> date: invalid date ‘Sun 27 Mar 00:59:00 GMT 2016’

Unfortunately that input is not in a locale independent format.  That
is why it cannot be read by date in the above.  The date documentation
says this:

  ‘-d DATESTR’
  ‘--date=DATESTR’
   Display the date and time specified in DATESTR instead of the
   current date and time.  DATESTR can be in almost any common format.
   It can contain month names, time zones, ‘am’ and ‘pm’, ‘yesterday’,
   etc.  For example, ‘--date="2004-02-27 14:19:13.489392193 +0530"’
   specifies the instant of time that is 489,392,193 nanoseconds after
   February 27, 2004 at 2:19:13 PM in a time zone that is 5 hours and
   30 minutes east of UTC.
   Note: input currently must be in locale independent format.  E.g.,
   the LC_TIME=C below is needed to print back the correct date in
   many locales:
date -d "$(LC_TIME=C date)"
   *Note Date input formats::.

The "locale independent format" looks to be the problem in the above
to me.  But I think that is only your command line test as that is
different from what I see in the tzdata postinst.

> $ date -d 02:00
> Sun 27 Mar 02:00:00 BST 2016
> $ date -d "Sun 27 Mar 02:00:00 BST 2016"
> date: invalid date ‘Sun 27 Mar 02:00:00 BST 2016’

I always recommend using 'date -R' to produce an unambiguous
representation.  This is an aside, but we are here.  Try this:

  TZ=Europe/London date -R -d 02:00
Sun, 27 Mar 2016 02:00:00 +0100
  TZ=Europe/London date -R -d 'Sun, 27 Mar 2016 02:00:00 +0100'
Sun, 27 Mar 2016 02:00:00 +0100

> This caused an upgrade of tzdata to fail for me.

It doesn't seem to me be a problem with date.  Looking briefly at the
tzdata postinst I see this:

  set -e
  ...
TZBase=$(LC_ALL=C TZ=UTC0 date)
UTdate=$(LC_ALL=C TZ=UTC0 date -d "$TZBase")
TZdate=$(unset TZ ; LANG=C date -d "$TZBase")

Initially I don't see how that can fail but I may be missing
something.  Can you provide any more information?

I am probably missing something but I don't see a way for it to fail.

TZBase=$(LC_ALL=C TZ=UTC0 date)

That sets LC_ALL=C and therefore will have the standard format.
(I wish it used date -R format instead.)

UTdate=$(LC_ALL=C TZ=UTC0 date -d "$TZBase")

Same there.  It consumes the previous output which is in the standard
format so should parse okay.

TZdate=$(unset TZ ; LANG=C date -d "$TZBase")

Here this makes me somewhat nervous because it sets LANG=C but either
LC_ALL or LC_TIME could override that setting.  But trying to trip a
problem there yielded nothing for me.

In the above LC_ALL=C will cause TZBase and UTdate to be in this
format:

  LC_ALL=C TZ=UTC0 date -d 'Sun, 27 Mar 2016 02:00:00 +0100'
Sun Mar 27 01:00:00 UTC 2016

  LC_ALL=C TZ=UTC0 date -d 'Sun Mar 27 01:00:00 UTC 2016'
Sun Mar 27 01:00:00 UTC 2016

That looks to be okay.  And the final date call:

  (unset TZ ; LANG=C date -d "Sun Mar 27 01:00:00 UTC 2016")
Sat Mar 26 19:00:00 MDT 2016

  (unset TZ ; LC_ALL=en_GB.UTF-8 LANG=C date -d "Sun Mar 27 01:00:00 UTC 2016")
Sat 26 Mar 19:00:00 MDT 2016

  (unset TZ ; LC_TIME=en_GB.UTF-8 LANG=C date -d "Sun Mar 27 01:00:00 UTC 2016")
Sat 26 Mar 19:00:00 MDT 2016

In all three cases it was able to parse that date string okay.  I wish
it set LC_ALL instead of LANG however so as to remove any doubt.

What am I missing?

Bob

signature.asc
Description: PGP signature

Bug#819290: Stack trace with symbols

2016-03-27 Thread Michael Biebl

Control: tags -1 + pending patch

Thanks for the debugging Yuriy

Am 27.03.2016 um 04:14 schrieb Yuriy M. Kaminskiy:
>> Regression by commit v228-745-gac9d396. Before that commit,
>> device_setup_unit checked that sysfs is not NULL before calling
>> path_equals().
>> I'd guess this commit should be just reverted.
> 
> See also upstream commit 5e1558f4a09e596561c9168384f2258e7c0718a1
> 
> P.S. asserts, asserts, asserts everywhere. /me hates.
> 

Martin had already pulled this patch into our Debian git [1]
Marking the issue as pending.

Regards,
Michael

[1]
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=b7f832a5c5ba8cb9ac6b063a4f46513785197085
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#815190: dh-make-perl: Accesses apt-file 3 cache directly

2016-03-27 Thread Niels Thykier

Damyan Ivanov:
> -=| gregor herrmann, 25.03.2016 17:19:47 +0100 |=-
>> [...]
> 
> Thank you gregor for your work on this!
> 

Indeed - thanks gregor

> FWIW the changes look good to me and now that the tests pass I see no 
> reasons why this can't be merged in the master branch and released.
> 
> What I am not clear about is whether this interface to apt-file is 
> something new that is not available in stable. If so, we'd need either 
> a suitable dependency or some kind of legacy support?
> 
> If this is a new interface I'd probably opt to adding the dependency 
> and let stable users provide a patch :)
> 
> 
> -- dam
> 

It is a new interface that requires APT 1.1 (or so).  It is not
available in stable and nor do I expect it to be backported (though the
APT maintainers could prove me wrong here).

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Bug#808911: dh-make-perl: Switch from libdpkg-parse-perl to libdpkg-perl modules

2016-03-27 Thread Damyan Ivanov

-=| gregor herrmann, 23.03.2016 17:21:59 +0100 |=-
> On Thu, 24 Dec 2015 12:07:06 +0100, Guillem Jover wrote:
> 
> > On Mon, 2015-09-28 at 12:37:22 +0100, Andrew Beverley wrote:
> > > On Mon, 2015-09-28 at 13:12 +0200, Guillem Jover wrote:
> 
> > > > What's the advantage of this over the various modules in libdpkg-perl?
> > > 
> > > I think it's the only way to retrieve version information. It's a long 
> > > time
> > > since I wrote my original patch for dh-make-perl, but I seem to remember
> > > that DPKG::Parse was the only module that provided certain information I
> > > needed (see 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774074).
> > > 
> > > I certainly tried to do it with other modules already packaged, but I
> > > couldn't gain all the required information.
> > 
> > The attached untested patch should in principle do it. In any case the
> > available file is only ever up-to-date when using dselect, so this is
> > probably not a very generic solution. And if it's too slow, this should
> > be fixed in libdpkg-perl anyway as that would benefit every caller.
> 
> Andy, Dam, what do you think about Guillem's patch?

Seems to work (tests pass), but is noticeably slower:

 * without the patch
   dh-make-perl-dev --cpan Catalyst  29,33s user 2,30s system 94% cpu 
   33,473 total
   (second try, after one dummy to fill CPAN/dh-make-perl caches)


 * with the patch
   dh-make-perl-dev --cpan Catalyst  233,96s user 3,13s system 99% cpu 
   3:59,17 total

(both timings were on the gregoa/apt-file-3 branch)


signature.asc
Description: Digital signature

Bug#812487: This was merged for 4.6

2016-03-27 Thread Wouter Verhelst

Control: retitle -1 Please ensure that commit 
37091fdd831f28a6509008542174ed324dd645bc reaches Debian

Hi,

The relevant patch was merged with the above commit ID during the 4.6 merge
window.

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#813252: pkg-config --libs libgit2 should include -lhttp_parser too

2016-03-27 Thread Josh Triplett

Control: tags -1 + moreinfo

On Sat, 30 Jan 2016 23:18:28 +0100 Giuseppe Bilotta 
 wrote:
> Package: libgit2-dev
> Version: 0.23.1-1+b1
> Severity: important
> 
> libgit2 depends on libhttp-parser, and libgit2-dev depends on
> libhttp-parser-dev. However, the pkg-config information for libgit2 does
> not include -lhttp_parser among the needed libraries, hence trying to
> compile a program that depends on libgit2 using $(pkg-config --libs
> libgit2) to get the compile flags will fail due to undefined references
> to http_parser_init and http_parser_execute methods.
> 
> This should be trivial to fix, by moving -lhttp_parser from the
> Libs.private to the Libs field in the .pc file.

Are you trying to link statically or dynamically?

If you're trying to link dynamically, the libgit2 dynamic library
already depends on libhttp_parser at runtime.  libgit2 doesn't directly
expose any symbols or types from libhttp_parser, so callers of libgit2
don't need to care that it uses libhttp_parser internally.  So, you
shouldn't pass -lhttp_parser unless you directly call symbols from
libhttp_parser yourself.  Doing so would introduce an unnecessary
dependency in your program or library, which (among other problems)
complicates transitions.

If you're trying to link statically, you need to use $(pkg-config
--static --libs libgit2) , which produces the following here:

-lgit2 -lcurl -lhttp_parser -lssh2 -lrt -lz

Bug#779321: slimit: Please provide python-slimit and python3-slimit

2016-03-27 Thread Brian May

Brian May  writes:

> As such slimit should be packaged as a Python library, and come supplied
> with a python2-slimit and a python3-slimit package.

Looks like I don't have commit access to the subversion repository, so
attached is my patch to fix this.
-- 
Brian May 
Index: debian/changelog
===
--- debian/changelog	(revision 13046)
+++ debian/changelog	(working copy)
@@ -1,3 +1,9 @@
+slimit (0.8.1-2) UNRELEASED; urgency=medium
+
+  * Split into python-slimit and python3-slimit. Closes: #779321.
+
+ -- Brian May   Sat, 26 Mar 2016 15:34:18 +1100
+
 slimit (0.8.1-1) unstable; urgency=low
 
   [ Jakub Wilk ]
Index: debian/compat
===
--- debian/compat	(revision 13046)
+++ debian/compat	(working copy)
@@ -1 +1 @@
-8
+9
Index: debian/control
===
--- debian/control	(revision 13046)
+++ debian/control	(working copy)
@@ -1,12 +1,12 @@
 Source: slimit
-Section: devel
+Section: python
 Priority: extra
 Maintainer: Python Applications Packaging Team 
-Uploaders: TANIGUCHI Takaki 
-Build-Depends: debhelper (>= 8.0.0)
-	, python-all
-	, python-setuptools
-Standards-Version: 3.9.3
+Uploaders: TANIGUCHI Takaki , Brian May 
+Build-Depends: debhelper (>=9), dh-python,
+ python-all (>= 2.6.6-3~), python-setuptools, python-ply,
+ python3-all, python3-setuptools, python3-ply,
+Standards-Version: 3.9.7
 Homepage: http://slimit.org/
 X-Python-Version: >= 2.7
 Vcs-Svn: svn://anonscm.debian.org/python-apps/packages/slimit/trunk/
@@ -14,6 +14,18 @@
 
 Package: slimit
 Architecture: all
+Depends: ${misc:Depends}, ${python3:Depends}, python3-slimit
+Description: JavaScript minifier/parser in Python
+ SlimIt is a JavaScript minifier written in Python. It compiles JavaScript
+ into more compact code so that it downloads and runs faster.
+ .
+ SlimIt also provides a library that includes a JavaScript parser, lexer,
+ pretty printer and a tree visitor.
+ .
+ This package contains the executable.
+
+Package: python-slimit
+Architecture: all
 Depends: ${misc:Depends}, ${python:Depends}
 	, python-pkg-resources
 Description: JavaScript minifier/parser in Python
@@ -22,3 +34,18 @@
  .
  SlimIt also provides a library that includes a JavaScript parser, lexer,
  pretty printer and a tree visitor.
+ .
+ This package contains the Python 2 module
+
+Package: python3-slimit
+Architecture: all
+Depends: ${misc:Depends}, ${python3:Depends}
+	, python3-pkg-resources
+Description: JavaScript minifier/parser in Python
+ SlimIt is a JavaScript minifier written in Python. It compiles JavaScript
+ into more compact code so that it downloads and runs faster.
+ .
+ SlimIt also provides a library that includes a JavaScript parser, lexer,
+ pretty printer and a tree visitor.
+ .
+ This package contains the Python 3 module
Index: debian/patches/fix-python3.patch
===
--- debian/patches/fix-python3.patch	(nonexistent)
+++ debian/patches/fix-python3.patch	(working copy)
@@ -0,0 +1,277 @@
+From e8331659fb89e8a4613c5e4e338c877fead9c551 Mon Sep 17 00:00:00 2001
+From: Lele Gaifax 
+Date: Sun, 9 Feb 2014 09:42:25 +0100
+Subject: [PATCH] Do not use ur"unicode-raw" strings, not supported by Python 3
+
+Use plain unicode strings instead, doubling backslashes when needed.
+---
+ src/slimit/tests/test_lexer.py |   6 +-
+ src/slimit/unicode_chars.py| 220 -
+ 2 files changed, 113 insertions(+), 113 deletions(-)
+
+diff --git a/src/slimit/tests/test_lexer.py b/src/slimit/tests/test_lexer.py
+index 922d628..e94d588 100644
+--- a/src/slimit/tests/test_lexer.py
 b/src/slimit/tests/test_lexer.py
+@@ -87,8 +87,8 @@ def test_illegal_unicode_char_in_identifier(self):
+  ['ID i', 'ID my_variable_name', 'ID c17', 'ID _dummy',
+   'ID $str', 'ID $', 'ID _', 'ID CamelCase', 'ID class2type']
+  ),
+-(ur'\u03c0 \u03c0_tail var\ua67c',
+- [ur'ID \u03c0', ur'ID \u03c0_tail', ur'ID var\ua67c']),
++(u'\u03c0 \u03c0_tail var\ua67c',
++ [u'ID \u03c0', u'ID \u03c0_tail', u'ID var\ua67c']),
+ # https://github.com/rspivak/slimit/issues/2
+ ('nullify truelie falsepositive',
+  ['ID nullify', 'ID truelie', 'ID falsepositive']),
+@@ -150,7 +150,7 @@ def test_illegal_unicode_char_in_identifier(self):
+ (r"""'\u0001' "\uFCEF" 'a\\\b\n'""",
+  [r"STRING '\u0001'", r'STRING "\uFCEF"', r"STRING 'a\\\b\n'"]
+  ),
+-(ur'"тест строки\""', [ur'STRING "тест строки\""']),
++(u'"тест строки\\""', [u'STRING "тест строки\\""']),
+ # Bug - https://github.com/rspivak/slimit/issues/5
+ (r"var tagRegExp = new

Bug#807797:

2016-03-27 Thread GCS

On Sun, Mar 27, 2016 at 7:33 AM, Brian May  wrote:
> "László Böszörményi (GCS)"  writes:
>> On Sat, Mar 26, 2016 at 3:42 AM, Brian May  wrote:
>> As I couldn't find example for DEP-8 tests, waiting for the answer to
>> your mail ATM.
>
> My latest version works.
 Confirmed.

> It does have the weird issue that the egg-info files are
> executable. Which gives lintian warnings. However I think that package
> should work fine regardless.
 I've the latest Lintian, 2.5.42.1 version. It doesn't show any messages.

I'm aware of DEP-5 on MIT versions vs Expat and took that change as
well. Even if it may confuse users, MIT is advertised everywhere as
the license of apscheduler.

Thanks for your help,
Laszlo/GCS

Bug#815190: dh-make-perl: Accesses apt-file 3 cache directly

2016-03-27 Thread Damyan Ivanov

-=| gregor herrmann, 25.03.2016 17:19:47 +0100 |=-
> On Wed, 23 Mar 2016 20:14:42 +0100, gregor herrmann wrote:
> 
> > On Fri, 19 Feb 2016 22:00:18 +0100, Niels Thykier wrote:
> > > The dh-make-perl package has code to access the apt-file cache
> > > directly.  In apt-file 3, this cache is removed (merged into APT's
> > > cache).
> > 
> > I pushed a first try to a branch gregoa/apt-file-3 in the gut repo.
> > (The changes are a bit intrusive, ripping out all kinds of things and
> > breaking the tests. But it seems to work :))
> 
> I've pushed some more commits to this branch.
> The test suite passes again, and my manual usage tests (with and
> without old/new Contents files and with and without a cache) look
> good.
> 
> Since the changes are not really small, I'd appreciate reviews /
> tests. [0]

Thank you gregor for your work on this!

FWIW the changes look good to me and now that the tests pass I see no 
reasons why this can't be merged in the master branch and released.

What I am not clear about is whether this interface to apt-file is 
something new that is not available in stable. If so, we'd need either 
a suitable dependency or some kind of legacy support?

If this is a new interface I'd probably opt to adding the dependency 
and let stable users provide a patch :)


-- dam


signature.asc
Description: Digital signature

Bug#819345: qpid-proton: CVE-2016-2166: reactor sends messages in clear if ssl is requested but not available

2016-03-27 Thread Salvatore Bonaccorso

Source: qpid-proton
Version: 0.10-1
Severity: important
Tags: security upstream fixed-upstream

Hi,

the following vulnerability was published for qpid-proton. The version
in experimental is affected.

CVE-2016-2166[0]:
reactor sends messages in clear if ssl is requested but not available

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-2166

Regards,
Salvatore

Bug#818122: docker.io: FTBFS in stretch

2016-03-27 Thread Dmitry Smirnov

On Saturday, 26 March 2016 11:20:43 PM AEDT Tianon Gravi wrote:
> It looks like an API change in the new runc (libcontainer bits):

I see... :(

> Currently digging to figure out whether Docker upstream already has a
> patch for the change to see how simple it'll be to convert over.

Thank you. It would be awesome if you could have a look whether you can build 
newer Docker. I think I've uploaded most if not all the dependencies it needs 
but there seems to be a problem with versioning of docker-notary and docker-
distribution as Docker FTBFS with released versions of those libs...

I hope you might have some ideas...

-- 
Best wishes,
 Dmitry Smirnov.

---

The foundation of morality should not be made dependent on myth nor
tied to any authority lest doubt about the myth or about the legitimacy
of the authority imperil the foundation of sound judgment and action.
-- Albert Einstein

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

Bug#818122: docker.io: FTBFS in stretch

2016-03-27 Thread Tianon Gravi

On 26 March 2016 at 21:54, Dmitry Smirnov  wrote:
> However Docker still FTBFS for another reason unrelated to runc as far as I
> can tell...

It looks like an API change in the new runc (libcontainer bits):

.gopath/src/github.com/docker/docker/daemon/execdriver/native/template/default_template.go:40:
unknown configs.Cgroup field 'AllowAllDevices' in struct literal
.gopath/src/github.com/docker/docker/daemon/execdriver/native/template/default_template.go:41:
unknown configs.Cgroup field 'MemorySwappiness' in struct literal

Currently digging to figure out whether Docker upstream already has a
patch for the change to see how simple it'll be to convert over.


♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#500422: hexedit shows strange characters in the status bar when opening a file with a non-ascii filename

2016-03-27 Thread Eriberto Mota

Control: tags 500422 moreinfo

Hi,

Some years after this bug have been opened, I would like to ask if
this issue still occurring. Debian uses UTF-8 now and I didn't be able
to reproduce the error.

Thanks!

Eriberto

< 1 2 3 >

101 - 200 of 200 matches

Mail list logo