Bug#820127: I confirm the bug

[Majid Tajamolian]

​​
Hi,
I confirm the bug is exist in the last debian testing image (Build
2016-04-18) as yet.
The severity is high.

Majid Tajamolian

Bug#821874: faumachine: RM faumachine -- RoQA, unmaintained, RC-Buggy, Depends on to be removed packages

[Tobias Frost]

Source: faumachine
Severity: serious

As already asked in #746843 it seems this package is unmaintained:
- RC buggy since 2 years, RC-Bug has no reply
- 2 other bugs without reply on the BTS

It seems also to be dead-upstream: no visible activity since 2012.

Additionally it Depends on soon to be removed libpng 1.2, which is planned to be
removed soonish.

I file this bug against faumachine to give the maintainer a (final) change to
react; I will reassign this bug to ftp.debian.org in one week from now or when
we file a RM bug for libpng1.2 (whatever is earlier).

Thanks!

-- 
tobi

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
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#821270: Review of firefox-branding-iceweasel

[Charles Plessy]

Le Tue, Apr 19, 2016 at 01:46:46PM -0700, Sean Whitton a écrit :
> 
> "Every package must be accompanied by a verbatim copy of its copyright
> information and distribution license in the file
> /usr/share/doc/package/copyright."
> 
> It then makes an *exception* to this verbatim rule:
> 
> "Packages distributed under the Apache license (version 2.0), the
> Artistic license, the GNU GPL (versions 1, 2, or 3), the GNU LGPL
> (versions 2, 2.1, or 3), and the GNU FDL (versions 1.2 or 1.3) should
> refer to the corresponding files under /usr/share/common-licenses,
> rather than quoting them in the copyright file."
> 
> Since you are not using /usr/share/common-licenses, your package doesn't
> fall under this exception and so you need to include it in your
> d/copyright file.

Hi all,

actually, the MPL-2 will be added to /user/share/common-licenses when a Policy
Editor will find time to make it happen.

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

So I suggest that it is fine to be forward-compatible with the future Policy :)

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Markus Koschany]

Am 20.04.2016 um 00:53 schrieb Ben Finney:
> On 19-Apr-2016, Markus Koschany wrote:
>> thanks for your update. There are only a few things left before we can
>> upload the package.
> 
> Thank you for working with me on this.
> 
>> My main concern is the adventure-common binary package because I
>> don't believe that shipping advent.dat with an extra package is very
>> useful at the moment.
> 
> Would you decline to upload on that basis? I appreciate you don't
> think there's a benefit, but is there any appreciable harm from having
> the ‘adventure-common’ package?
> 
>> I think it is cool to have a modern Python3 version but it would be
>> rather boring to have identical versions that simply reuse the same
>> story from advent.dat.
> 
> My thinking is that the Python 3 package is rather idiosyncratic, and
> that I'd like to make it clear the common files are available for
> different ports from the original Fortran program.
> 
> I'm not going to insist, but I'd like to know whether you think this
> structure is harmful, or only that this isn't the style you would
> choose.

I think the word harmful is a bit too strong but I don't think that your
current approach is beneficial either. The rationale for providing
multiple binary packages is that users should be able to install a
subset of an application and save some disk space. In this case they
always have to install both packages because otherwise the game would be
broken. It would be a different case if they already had a choice and
could choose between different variants.

Games often provide a significant amount of data and media files and
then it really makes sense to split off the data into some arch:all
-data or -common package when the architecture dependent data is small
compared to the arch-indep part. It would have been extremely wasteful,
if I hadn't done that for freeorion. (C++ game, -data package ~150 MB)
but in your case the game is already arch:all instead of arch:any and
adventure-common is even smaller than colossal-cave-adventure. So
another variable must be taken into account: metadata. Every binary
package in Debian's archive produces metadata and _every_ user has to
fetch this information, for instance with apt when doing a daily update.
In your case the performance penalty (even when it's rather small) is
greater than the advantage of having a separate -common package which
could be reused for a potential and not yet packaged adventure variant.

And last but not least the ftp team once rejected an extra -doc package
for the game njam because it was very small and insisted to merge it
into the -data package. The funny part is that my sponsor back then
thought it was a good idea, so the situation was kind of reversed.

I wouldn't decline to upload but you should take this wall of text into
consideration. In my opinion you can always split the package later when
a potential port might require it.

[...]
>> and that we use cgit for better performance.
> 
> Recently, the default browser on Alioth was switched to Cgit. So,
> at  the Cgit
> browser is presented.

Indeed they redirect all requests now. I don't know if that comes with a
performance penalty though. I wonder why we need two fields, Vcs-Browser
and Vcs-Git, if they are identical...

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#232584: HELLO

[Tabitha Romeo]

My name Tabitha contact me urgently now so that i can tell you more details 
about me
  

Bug#821872: ntp 4.2.8p4+dfsg-3 fails with dpkg-buildpackage

[Kalnozols, Andris]

Package: ntp
Version: 4.2.8p4+dfsg-3

I downloaded the "stretch" source package for ntp on my Proliant server
running "jessie" since we have a Spectracom Tsync card; support for
this card only began with ntp release 4.2.7p266.

Building this package with "dpkg-buildpackage -b -us -uc" fails to
complete unless the following patches are applied:


> --- debian/rules.orig  2015-07-25 07:36:54.0 -0700
> +++ debian/rules   2016-04-14 01:22:51.0 -0700
> @@ -20,7 +20,7 @@
> --with-sntp=no \
> --with-lineeditlibs=edit \
> --without-ntpsnmpd \
> -   --disable-local-libopts \
> +   --enable-local-libopts \
> --enable-ntp-signd \
> --disable-dependency-tracking \
> --with-openssl-libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
> @@ -50,13 +50,8 @@
> 
> $(MAKE) install DESTDIR=$(CURDIR)/debian/tmp
> 
> -   # move the administrator programs from /usr/bin to /usr/sbin
> -   for file in ntpdate ntp-wait ntpd ntptime ntp-keygen; do \
> -   mv debian/tmp/usr/bin/$$file debian/tmp/usr/sbin/$$file || 
> exit; \
> -   done
> -
> # don't install tickadj
> -   rm debian/tmp/usr/bin/tickadj
> +   rm debian/tmp/usr/sbin/tickadj
> 
> install -D -m 0755 scripts/ntpsweep/ntpsweep 
> debian/ntp/usr/bin/ntpsweep
> install -D -m 0644 debian/ntp.dhcp 
> debian/ntp/etc/dhcp/dhclient-exit-hooks.d/ntp
> @@ -66,7 +61,8 @@
> install -D -m 0644 debian/ntp.conf debian/ntp/etc/ntp.conf
> 
> # remove upstream man pages, which are currently not as nice as ours 
> / ntpsnmpd we don't want
> -   rm $(addprefix debian/tmp/usr/share/man/man1/,ntpd.1 ntpdc.1 
> ntp-keygen.1 ntpq.1)
> +   rm $(addprefix debian/tmp/usr/share/man/man1/,ntpdc.1 ntpq.1)
> +   rm $(addprefix debian/tmp/usr/share/man/man8/,ntpd.8 ntp-keygen.8)
> 
> # Remove empty directory (/usr/libexec/)
> find debian/tmp -type d -empty -delet


> --- debian/ntp.install.orig2015-07-25 07:36:53.0 -0700
> +++ debian/ntp.install 2016-04-13 22:59:08.0 -0700
> @@ -1,12 +1,12 @@
> -debian/tmp/usr/bin/calc_tickadj
>  debian/tmp/usr/bin/ntpdc
>  debian/tmp/usr/bin/ntpq
>  debian/tmp/usr/bin/ntptrace
> -debian/tmp/usr/bin/update-leap
> +debian/tmp/usr/sbin/calc_tickadj
>  debian/tmp/usr/sbin/ntp-keygen
>  debian/tmp/usr/sbin/ntp-wait
>  debian/tmp/usr/sbin/ntpd
>  debian/tmp/usr/sbin/ntptime
> +debian/tmp/usr/sbin/update-leap
>  debian/tmp/usr/share/ntp/lib/NTP/Util.pm
>  debian/tmp/usr/share/doc/ntp/ntp-wait.html
>  debian/tmp/usr/share/doc/ntp/ntp.conf.html
> @@ -18,8 +18,8 @@
>  debian/tmp/usr/share/doc/ntp/ntpsweep.html
>  debian/tmp/usr/share/doc/ntp/ntptrace.html
>  debian/tmp/usr/share/doc/ntp/update-leap.html
> -debian/tmp/usr/share/man/man1/calc_tickadj.1
> -debian/tmp/usr/share/man/man1/ntp-wait.1
>  debian/tmp/usr/share/man/man1/sntp.1
> -debian/tmp/usr/share/man/man1/update-leap.1
>  debian/tmp/usr/share/man/man5/ntp.keys.5
> +debian/tmp/usr/share/man/man8/calc_tickadj.8
> +debian/tmp/usr/share/man/man8/ntp-wait.8
> +debian/tmp/usr/share/man/man8/update-leap.8


1. "--enable-local-libopts" was necessary for "util/ntp-keygen-opts.c"
   to compile.  Without this option, the wrong header file was chosen;

 /usr/include/autoopts/options.h
   instead of
 ./sntp/libopts/autoopts/options.h

   and the compile failed due to the VOIDP macro being undefined.
   I don't have access to a system running "stretch" - perhaps the
   VOIDP macro is defined in the /usr/include/autoopts/options.h
   header file in which case "--disable-local-libopts" can be left
   as-is.

2. The loop to move the administrator programs from "tmp/usr/bin"
   to "/tmp/usr/sbin" is unnecessary since they're already in "sbin".

3. The paths for removing the upstream man pages needed fixing.

4. The paths for various files in "ntp.install" were not correct.

Regards,
Andris

Bug#821869: scim would prevent normal "quick find/search" feature of generic file manager (caja, etc)

[Tz-Huan Huang]

Hi,

2016-04-20 10:33 GMT+08:00 yh.jen :

> Package: scim
> Version: 1.4.15-3
> Severity: important
> Tags: newcomer
>
> Dear Maintainer,
>
> 在一般的情況下，如果沒有裝scim。當我使用檔案管理程式例如nautilus
> 或是 caja，它們有一個功能是quick
> find/search，這個功能的作用是在檔案檢視清單的時候，
> 如果按下任一個字母按鍵例如
> "h"，螢幕上會出現一個文字輸入框框，內容為h，同時清單會自動跳選到第一個字母為h開頭的檔案,這時如果再按下例如"3"，螢幕上的文字輸入框內容會變成
> "h3"，清單也會自動跳轉到檔案開頭為"h3"的檔案（如沒有，它不會有動作)。在很多的檔案管理程式，這個功能很普遍。
>
>
> 但是當我安裝了scim，配置好輸入法設定時，這個功能不見了，scim沒有開啟輸入法的時候(系統夾中的圖示是一個小鍵盤),在檔案管理程式按下每一個英文字母，它變的沒有反應.
>
> 我認為scim吃掉了它不應該吃掉的按鍵，或者是im-
> config用了不對的方法啟動scim。我不了解電腦程式，不知道可能的問題會是什麼。
>
> 還有一個奇怪的現像,
>
> 我好幾個同時使用的輸入法（酷音，倉頡五，行列等），它們運作都很正常。但是當輸入法切換到英文模式時(按下shift變為英數模式)，除了酷音以外，大部份其它輸入法都無法輸入英文字母及空白(倉頡行列都一樣).在我以前使用debian
> 舊版的時代(我從6版開始用)沒有這個問題
>
> 我以前使用debian 6時也曾出現這個問題(指quick find feature
> ）那時還是用im-switch，但是那時候我只要裝scim-
> bridge就能避免，而現在這個package沒有了，那個時候切換到英文模式時還能正常輸入英文。
>
> 我找遍了google, 除了
> https://bugs.launchpad.net/ubuntu/+source/scim/+bug/287719
> 以外沒有有用的訊息能解決問題
>
> 有沒有人能研究一下這個二問題?
>
> 1. scim會吃掉 caja 內的quick find/search功能
> 2. scim輸入法切換到英文輸入模式時不能輸入英文
>
> 謝謝
>
> 我用 debian 8.4 amd64 stable 版
>
>
>
Thank you for the bug report. I'll investigate it.

Thanks,
Tz-Huan


>
> -- Package-specific info:
> Related packages:
> ii  libscim8c2a:am 1.4.15-3 amd64library for SCIM platform
> ii  scim   1.4.15-3 amd64smart common input method
> platfor
> ii  scim-chewing:a 0.3.4-4.1amd64Chewing IM engine module for
> SCIM
> ii  scim-clutter-i 1.4.15-3 amd64Clutter input method module
> with
> ii  scim-gtk-immod 1.4.15-3 amd64GTK+ input method module with
> SCI
> ii  scim-im-agent  1.4.15-3 amd64IM agent for SCIM platform
> ii  scim-kmfl-imen 0.9.8-1.1amd64KMFL (Keyboard Mapping for
> Linux)
> ii  scim-modules-s 1.4.15-3 amd64socket modules for SCIM
> platform
> ii  scim-modules-t 0.5.14-1 amd64generic tables IM engine
> module f
> ii  scim-tables-zh 0.5.14-1 all  Chinese input method data
> tables
>
> Related environment variables:
> $XMODIFIERS=@im=SCIM
> $GTK_IM_MODULE=scim
> $QT_IM_MODULE=xim
>
> Installed SCIM components:
> /usr/lib/scim-1.0:
> 1.4.0
>
> /usr/lib/scim-1.0/1.4.0:
> IMEngine
> SetupUI
>
> /usr/lib/scim-1.0/1.4.0/IMEngine:
> kmfl.a
> kmfl.la
> kmfl.so
>
> /usr/lib/scim-1.0/1.4.0/SetupUI:
> kmfl_imengine_setup.a
> kmfl_imengine_setup.la
> kmfl_imengine_setup.so
>
> -- System Information:
> Debian Release: 8.4
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages scim depends on:
> ii  libatk1.0-0  2.14.0-1
> ii  libc62.19-18+deb8u4
> ii  libcairo-gobject21.14.0-2.1+deb8u1
> ii  libcairo21.14.0-2.1+deb8u1
> ii  libgcc1  1:4.9.2-10
> ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u4
> ii  libglib2.0-0 2.42.1-1+b1
> ii  libgtk-3-0   3.14.5-1+deb8u1
> ii  libpango-1.0-0   1.36.8-3
> ii  libpangocairo-1.0-0  1.36.8-3
> ii  libscim8c2a  1.4.15-3
> ii  libstdc++6   4.9.2-10
> ii  libx11-6 2:1.6.2-3
>
> Versions of packages scim recommends:
> ii  im-config [im-switch]  0.27-2
> ii  scim-gtk-immodule [scim-gtk-immodule]  1.4.15-3
> ii  scim-im-agent  1.4.15-3
>
> Versions of packages scim suggests:
> pn  scim-anthy  
> pn  scim-canna  
> ii  scim-chewing0.3.4-4.1
> pn  scim-hangul 
> pn  scim-m17n   
> pn  scim-pinyin 
> pn  scim-prime  
> pn  scim-skk
> pn  scim-tables-additional  
> pn  scim-tables-ja  
> pn  scim-tables-ko  
> ii  scim-tables-zh  0.5.14-1
> pn  scim-thai   
> pn  scim-uim
>
> -- Configuration Files:
> /etc/X11/xinit/xinput.d/scim changed [not included]
>
> -- no debconf information
>
>

Bug#821873: ITP: fonts-yrsa-rasa -- Open-source, libre fonts for Latin + Gujarati

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 

* Package name: fonts-yrsa-rasa
Version :  1.002
Upstream Author :
* URL : https://github.com/rosettatype/yrsa-rasa
* License : OFL
Programming Lang: font
Description : Open-source, libre fonts for Latin + Gujarati

Yrsa and Rasa are open-source type families published by Rosetta with
generous financial support from Google. The fonts support over 92
languages in Latin script and 2 languages in Gujarati script (Gujarati
and Kachchi).

 - how do you plan to maintain it? inside a packaging team
   (check list at https://wiki.debian.org/Teams)? are you
   looking for co-maintainers? do you need a sponsor?

 A: debian-in-workers/debian-fonts team.

-- 
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com

Bug#781064: Update File

[Himadri Ganguly]

I have updated the information of Ms Solveig from
https://wiki.debian.org/DebianWomen/Profiles into this profile for the web.

Thank you.
Solveig
#use wml::debian::profiles
#include "$(ENGLISHDIR)/women/profiles/profiles.def"


 

 


# How long have you been using Debian?

I've been using Debian since around 2004. I contribute to it since 2013 only :)



# Are you a Debian Developer?

Nope. I might become a non-uploading DD at some point, but not yet.



# What areas of Debian are you involved in?

I mostly contribute to Tails, a Debian derivative.

	In Debian, I did some bug triaging, translations, and participated to 2 ?DebConfs so far :)



# What got you interested in working with Debian?

I was using Debian since a long time, and contributing to Tails since the beginning, so at some point I was interested in bringing back to upstream.



# Do you have any tips for women interested in getting more involved with Debian?

It helps to find a team where people work on things that interest you and are willing to mentor your beginnings in Debian. Most teams are happy to welcome new people :)

	Also don't hesitate to join the debian-women irc chan, mailing-list and events. The activity varies, but it's a fabulous bunch of people :)



# Are you involved with any other women in technology group? Which one(s)?

	



# A bit more about you...

   

Bug#353697: a hacky "fix" upstream, missing from the package

[Adam Borowski]

Hi!
Since two years ago, this has been marked as "RESOLVED FIXED" upstream:
https://bugzilla.samba.org/show_bug.cgi?id=3653

It's not a real fix, merely a nasty hacky script to post-process rsync's
output and ignore this particular error.  Still, the included script
(rsync-no-vanished) is missing from the Debian package.


John Van Essen wrote:
> Instead of attacking the symptom, attack the problem.  You are backing
> up temporary files that are not needed on a restore.  These "vanished"
> messages actually help pinpoint directories whose contents should be
> excluded, in this case via --exclude=/drbd/var/www/tmp/*

While indeed _most_ such churn comes from temporary files, there are
hundreds of places they can happen.  Just from three last rsync spams I got:
* icinga checkresults spool
* a session file from one of customers' php site
* a new mail inside a Maildir/
so am I supposed to maintain pages worth of --exclude= arguments, adding a
new one every time I receive a rsync spam?
And, believe me or not, actual non-temporary files do get removed too --
usually mails but on your boxes it might be something else.


But, as upstream is apparently not willing to fix this in a clean way,
please at least include the rsync-no-vanished workaround.


Meow!
-- 
A tit a day keeps the vet away.

Bug#821424: pulseaudio: Do not put normal users on group audio

[Christian PERRIER]

Quoting Ben Hutchings (b...@decadent.org.uk):

> I don't know where you get this 'all possible use cases of the
> installer' from.  Adding the first user to device access groups only

.../...

Something like "not default installs" or "non default desktop
environments". Indeed, I have no precise idea, just somerthing along
"what would be the consequences of dropping these 'default groups' in
non default installs".

I'm all in for simplifying things and it"s very likely possible that
these things are just remains of the past, just as you own tests seem
to show.

> I've done a quick test of removing myself from the device access groups
> on a current GNOME desktop, with these results:
> 
> - audio:      redundant, I'm on the ACL for /dev/snd/*
> - cdrom:      redundant, I'm on the ACL for /dev/sr0
> - floppy:     unknown, but expect this to work like cdrom
> - video:      redundant, I'm on the ACL for /dev/video0
> - plugdev:    redundant, I'm on the ACL for /dev/bus/usb/002/006
> - netdev:     redundant, I'm on the ACL for /dev/rfkill
> - scanner:    redundant, I'm on the ACL for /dev/sg2
> - bluetooth:  unknown, seems broken whether or not I'm a member of the group
> 
> The other groups (dip, debian-tor, lpadmin, sudo) make more sense,
> though CUPS should probably be changed to treat sudo like lpadmin.


So, well, are there any objections to us dropping all the above
groups from the list of groups the first created user is added to?



signature.asc
Description: PGP signature

Bug#821871: Acknowledgement (lightdm: Missing cursor and flicking after unlock with XFCE, clears after VT switch)

[Nathaniel Roach]

I also forgot to add that changing display settings (adding a screen or 
doing anything that causes the screen to flicker briefly, like a 
resolution change) will also clear the flickering and fix the cursor.

Bug#821871: lightdm: Missing cursor and flicking after unlock with XFCE, clears after VT switch

[Nathaniel Roach]

Package: lightdm
Version: 1.18.1-1
Severity: important

Dear Maintainer,

When using XFCE4 and lightdm, after unlocking the mouse cursor is not visible 
(but does exist) and there is often flickering. The cursor may reappear while 
using gnome-terminal, as it hides/un-hides the cursor, but the easiest fix is 
switching to TTY1 and back (also clears the flickering).

I'm filing it against lightdm, but it may be an XOrg bug. As it does not happen 
with GNOME/GDM3, I'd presume it may lie in how lightdm handles the VT switch.

I'm running debian testing x64 on a Thinkpad X200 with a custom kernel, but 
it's also effecting other users with newer hardware (T460, for example) and is 
not specific to my kernel build/config.

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

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

Versions of packages lightdm depends on:
ii  adduser3.114
ii  dbus   1.10.8-1
ii  debconf [debconf-2.0]  1.5.59
ii  libaudit1  1:2.4.5-1+b1
ii  libc6  2.22-6
ii  libgcrypt201.6.5-2
ii  libglib2.0-0   2.48.0-1
ii  libpam-systemd 229-4
ii  libpam0g   1.1.8-3.2
ii  libxcb11.11.1-1
ii  libxdmcp6  1:1.1.2-1.1
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.1-2

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+14

Versions of packages lightdm suggests:
ii  accountsservice  0.6.40-3
ii  upower   0.99.4-2

-- Configuration Files:
/etc/lightdm/lightdm.conf changed:
[LightDM]
[Seat:*]
xserver-allow-tcp=true
greeter-hide-users=false
autologin-user=nroach44
autologin-user-timeout=0
[XDMCPServer]
[VNCServer]


-- debconf information:
  lightdm/daemon_name: /usr/sbin/lightdm
* shared/default-x-display-manager: lightdm

Bug#821270: Review of firefox-branding-iceweasel

[Sean Whitton]

Hello,

On Wed, Apr 20, 2016 at 10:47:05AM +0800, Paul Wise wrote:
> On Wed, Apr 20, 2016 at 4:46 AM, Sean Whitton wrote:
> 
> > Yes, it should definitely be xul-ext-iceweasel-branding -- that's
> > pkg-mozext policy for anything that appears in about:addons.  dh_xul-ext
> > assumes that your package is called xul-ext-foo, and it will generate a
> > Provides: entry for firefox-foo.
> 
> The package name was suggested by Mozilla folks:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006#145

As far as I can see the person making that suggestion is not a part of
the pkg-mozext team, though.  And it's in the (draft) group policy:
https://wiki.debian.org/Mozilla/ExtensionsPolicy

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#821782: openafs-modules-dkms: module FTBFS against Linux 4.5: osi_vnodeops.c:1935:5: error: implicit declaration of function 'nd_set_link'

[Benjamin Kaduk]

On Tue, 19 Apr 2016, Andreas Beckmann wrote:

> Package: openafs-modules-dkms
> Version: 1.6.17-2
> Severity: serious
>
> from the attached make.log:
>
>   CC [M]  
> /var/lib/dkms/openafs/1.6.17/build/src/libafs/MODLOAD-4.5.0-1-amd64-SP/osi_vnodeops.o
> /var/lib/dkms/openafs/1.6.17/build/src/libafs/MODLOAD-4.5.0-1-amd64-SP/osi_vnodeops.c:
>  In function 'afs_linux_follow_link':
> /var/lib/dkms/openafs/1.6.17/build/src/libafs/MODLOAD-4.5.0-1-amd64-SP/osi_vnodeops.c:1935:5:
>  error: implicit declaration of function 'nd_set_link' 
> [-Werror=implicit-function-declaration]
>  nd_set_link(nd, name);
>  ^

Thanks for the report; it is known upstream but there is no candidate fix
yet.  I am not sure how soon I will be able to properly dive in,
unfortunately.

-Ben

Bug#821350: dh-golang: generates rubbish in Built-Using; errors on invocation

[Michael Hudson-Doyle]

New patch. Builds everything on Dmitry's list without any stderr from
dh_golang and the built-using headers produced look reasonable.

Cheers,
mwh

On 20 April 2016 at 11:13, Michael Hudson-Doyle
 wrote:
> On 20 April 2016 at 09:05, Dmitry Smirnov  wrote:
>> On Tuesday, 19 April 2016 12:02:10 PM AEST Michael Hudson-Doyle wrote:
>>> Are there any other packages you think would be particularly good to
>>> try to build?
>>
>> You can check the following packages, starting from top:
>
> Thanks for this list.
>
>> golang-github-aws-aws-sdk-go
>
> This manages to trigger an "Argument list too long" in my patch. New
> one coming in a little while.
>
> Cheers,
> mwh
>
>> docker-swarm
>> influxdb
>> golang-github-unknwon-com
>> cadvisor
>> golang-github-revel-revel
>> runc
>>
>> Thanks.
>>
>> --
>> Cheers,
>>  Dmitry Smirnov.
From 10cd725d7996c71b1ff4784e7d0894c21d3f9d6d Mon Sep 17 00:00:00 2001
From: Michael Hudson-Doyle 
Date: Tue, 19 Apr 2016 11:59:51 +1200
Subject: [PATCH] More dh_golang fixes

---
 debian/changelog | 15 +++
 script/dh_golang | 58 
 2 files changed, 48 insertions(+), 25 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index a4b3689..451dd19 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+dh-golang (1.16) UNRELEASED; urgency=medium
+
+  * Make dh_golang more robust:
+- Initialize the buildsystem more correctly, so --builddirectory=_build
+  works (Closes: 821350)
+- Exit with an error if any of the 'go list' or 'dpkg-search' commands
+  fail.
+- Quote the current working directory in the regexp used to filter out
+  files from the build directory.
+- Store package / directory lists in files and use xargs to avoid
+  constructing over-long command lines.
+  * Also trim dh_golang's use statements. 
+
+ -- Michael Hudson-Doyle   Tue, 19 Apr 2016 11:42:26 +1200
+
 dh-golang (1.15) unstable; urgency=medium
 
   [ Michael Hudson-Doyle ]
diff --git a/script/dh_golang b/script/dh_golang
index 5e1e71d..d39523b 100755
--- a/script/dh_golang
+++ b/script/dh_golang
@@ -9,14 +9,8 @@ dh_golang - Generates Built-Using substvar
 use strict;
 use Cwd qw(realpath);
 use Debian::Debhelper::Dh_Lib; # not in core
-use Dpkg; # not in core
-use Dpkg::Control; # not in core
-use Dpkg::Control::Info; # not in core
-use Dpkg::Deps; # not in core
-use Dpkg::Gettext; # not in core
-use Scalar::Util qw(blessed); # in core since v5.7.3
-use List::Util qw(first); # in core since v5.7.3
-use Debian::Debhelper::Buildsystem::golang;
+use Debian::Debhelper::Dh_Buildsystems; # not in core
+use File::Temp qw(tempdir);
 
 =head1 SYNOPSIS
 
@@ -35,34 +29,48 @@ The best way to invoke B is by using B.
 
 =cut
 
-init();
-
 
 # Generate misc:Built-Using substvar.
 
 
-my $bs = Debian::Debhelper::Buildsystem::golang->new();
+buildsystems_init();
+my $bs = load_buildsystem("golang");
 
-$bs->_set_dh_gopkg();
 $bs->_set_gopath();
 
 my @targets = $bs->get_targets();
 
-my $godeps = `go list -f '{{ range .Deps }}{{.}} {{ end }}' @targets`;
-$godeps =~ s/\n/ /g;
-my @godirs = split /\n/, `go list -f '{{ .Dir }}' $godeps`;
-my $realgodirs;
-my $cwd = $bs->{cwd};
-for my $godir (@godirs) {
-my $realpath = realpath($godir);
-# @godirs will include the directories of the package being built, so exclude them.
-if ($realpath !~ /^$bs->{cwd}/) {
-$realgodirs .= realpath($godir) . " ";
+my $tmpl = '{{ range .Deps }}{{.}}
+{{ end }}';
+
+my $tmpdir = tempdir("dh_golang_XXX", TMPDIR => 1, CLEANUP => 1);
+
+system("go list -f \"$tmpl\" @targets > $tmpdir/godeps") == 0
+or die "go list of targets failed with code $?, $!";
+
+system("sort -u $tmpdir/godeps | xargs go list -f '{{ .Dir }}' > $tmpdir/godirs") == 0
+or die "go list of dependencies failed with code $?, $!";
+
+open(my $inp, "<", "$tmpdir/godirs");
+open(my $outp, ">", "$tmpdir/realgodirs");
+while (<$inp>) {
+chomp;
+my $realpath = realpath($_);
+# godirs will include the directories of the package being built, so exclude them.
+if ($realpath !~ /^\Q$bs->{cwd}\E/) {
+printf $outp "%s\n", $realpath;
 }
 }
-my $pkgs = `dpkg-query --search $realgodirs | cut -d: -f1`;
-$pkgs =~ s/\n/ /g;
-my $built_using = `dpkg-query -f='\${source:Package} (= \${source:Version}), ' -W $pkgs`;
+close($inp);
+close($outp);
+
+system("cat $tmpdir/realgodirs | xargs dpkg-query --search > $tmpdir/pkgs") == 0
+or die "dpkg-query --search failed with code $?, $!";
+
+my $built_using = `cut -d: -f1 $tmpdir/pkgs | sort -u | xargs dpkg-query -f='\${source:Package} (= \${source:Version}), ' -W`;
+if ($? != 0) {
+

Bug#821870: deb822: Restore support for -{Add,Remove}

[James McCoy]

Package: apt
Version: 1.2.10
Severity: normal
Tags: patch

Redesign of multivalue options in 463c8d801595ce5ac94d7c032264820be7434232
caused the parser to look for {Add,Remove} (no hyphen)
instead of the expected -{Add,Remove}.

-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (no /etc/apt/sources.list present) --


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (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.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt depends on:
ii  adduser 3.114
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.20-6
ii  gnupg2  2.1.11-7
ii  gpgv1.4.20-6
ii  init-system-helpers 1.29
ii  libapt-pkg5.0   1.2.10
ii  libc6   2.22-7
ii  libgcc1 1:5.3.1-14
ii  libstdc++6  5.3.1-14

apt recommends no packages.

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.7.8-1
ii  dpkg-dev1.18.4
ii  python-apt  1.1.0~beta2

-- Configuration Files:
/etc/apt/apt.conf.d/01autoremove changed [not included]

-- no debconf information
>From 98eefc423a8979fb5b1ca77b78e8dc542c9d68f4 Mon Sep 17 00:00:00 2001
From: James McCoy 
Date: Tue, 19 Apr 2016 22:27:21 -0400
Subject: [PATCH] deb822: Restore support for -{Add,Remove}

Redesign of multivalue options in 463c8d801595ce5ac94d7c032264820be7434232
caused the parser to look for {Add,Remove} (no hyphen)
instead of the expected -{Add,Remove}.
---
 apt-pkg/sourcelist.cc|  4 ++--
 test/integration/test-apt-sources-deb822 | 10 ++
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/apt-pkg/sourcelist.cc b/apt-pkg/sourcelist.cc
index 82d2ed3..afbf3e6 100644
--- a/apt-pkg/sourcelist.cc
+++ b/apt-pkg/sourcelist.cc
@@ -98,8 +98,8 @@ bool pkgSourceList::Type::ParseStanza(vector ,	/*{{{*/
std::map > mapping;
 #define APT_PLUSMINUS(X, Y) \
mapping.insert(std::make_pair(X, std::make_pair(Y, true))); \
-   mapping.insert(std::make_pair(X "Add", std::make_pair(Y "+", true))); \
-   mapping.insert(std::make_pair(X "Remove", std::make_pair(Y "-", true)))
+   mapping.insert(std::make_pair(X "-Add", std::make_pair(Y "+", true))); \
+   mapping.insert(std::make_pair(X "-Remove", std::make_pair(Y "-", true)))
APT_PLUSMINUS("Architectures", "arch");
APT_PLUSMINUS("Languages", "lang");
APT_PLUSMINUS("Targets", "target");
diff --git a/test/integration/test-apt-sources-deb822 b/test/integration/test-apt-sources-deb822
index fd275f9..9f761cb 100755
--- a/test/integration/test-apt-sources-deb822
+++ b/test/integration/test-apt-sources-deb822
@@ -189,3 +189,13 @@ EOF
 testsuccessequal --nomsg "'http://emacs.naquadah.org/stable/InRelease' emacs.naquadah.org_stable_InRelease 0 
 'http://emacs.naquadah.org/stable/Packages.xz' emacs.naquadah.org_stable_Packages 0 
 'http://emacs.naquadah.org/stable/en.xz' emacs.naquadah.org_stable_en 0 " aptget update --print-uris
+
+# multivalue -Add/-Remove
+msgcleantest 'Test deb822 sources.list file which has' '-Add/-Remove multivalues'
+echo "$BASE" > $SOURCES
+echo "Languages-Remove: en" >> $SOURCES
+echo "Architectures-Add: armel" >> $SOURCES
+testsuccessequal --nomsg "'http://ftp.debian.org/debian/dists/stable/InRelease' ftp.debian.org_debian_dists_stable_InRelease 0 
+'http://ftp.debian.org/debian/dists/stable/main/binary-i386/Packages.xz' ftp.debian.org_debian_dists_stable_main_binary-i386_Packages 0 
+'http://ftp.debian.org/debian/dists/stable/main/binary-all/Packages.xz' ftp.debian.org_debian_dists_stable_main_binary-all_Packages 0 
+'http://ftp.debian.org/debian/dists/stable/main/binary-armel/Packages.xz' ftp.debian.org_debian_dists_stable_main_binary-armel_Packages 0 " aptget update --print-uris
-- 
2.8.1

Bug#821270: Review of firefox-branding-iceweasel

[Paul Wise]

On Wed, Apr 20, 2016 at 4:46 AM, Sean Whitton wrote:

> Yes, it should definitely be xul-ext-iceweasel-branding -- that's
> pkg-mozext policy for anything that appears in about:addons.  dh_xul-ext
> assumes that your package is called xul-ext-foo, and it will generate a
> Provides: entry for firefox-foo.

The package name was suggested by Mozilla folks:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006#145

> How about adding a new file /usr/share/applications/iceweasel.desktop
> that launches firefox with the old icon?  This would make this extension
> conflict with iceweasel, but I think that would be okay so long as you
> added a Conflicts: line in d/control.

I think it would be best to handle this in the iceweasel package instead.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#819682: libpwquality-tools: package should depend on cracklib-runtime

[Michael Biebl]

Control: severity -1 normla
Control: tags -1 + moreinfo unreproducible

On Fri, 01 Apr 2016 03:04:25 +0800 sharuzzaman 
wrote:
> Package: libpwquality-tools
> Version: 1.2.3-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> 1. install libpwquality-tools, cracklib-runtime was not pulled in
> 2. after installation finish, run the command pwmake
> 3. got the following output
> 
> sharuzzaman@debian:~$ pwmake 56
> /var/cache/cracklib/cracklib_dict.pwd: No such file or directory
> /var/cache/cracklib/cracklib_dict.pwd: No such file or directory
> /var/cache/cracklib/cracklib_dict.pwd: No such file or directory
> Error: Password generation failed - required entropy too low for settings
> 
> 4. install cracklib-runtime
> 5. run the command pwmake again
> 
> sharuzzaman@debian:~$ pwmake 56
> 3j1EjfaR4toN
> 
> ---
> 
> Conclusion: cracklib-runtime should a dependency to libpwquality-tools

I can not reproduce the bug:

[michael@pluto ~]$ apt-cache policy cracklib-runtime
cracklib-runtime:
  Installed: (none)
  Candidate: 2.9.2-1+b2
  Version table:
 2.9.2-1+b2 500
500 http://ftp.de.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
[michael@pluto ~]$ pwmake 56
s0nujYjMyJEp


Can you reproduce the issue?

Anyway, not a grave bug as the package is still functional. So downgrading

Michael
-- 
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#821270: RFS: firefox-branding-iceweasel/0.3.0 [ITP] -- Preserves Iceweasel branding for new Firefox packages

[Paul Wise]

On Mon, 2016-04-18 at 14:31 +, nord-stream wrote:

> Technically a Firefox extension cannot change this. It's a .desktop
> file's job, I assume. But can we replace a .desktop file from another
> package? Adding extra files to be installed also complicates rules a
> lot.

I think this would have to be handled in the iceweasel package:

pabs@chianamo ~ $ dpkg -L iceweasel 
/.
/usr
/usr/bin
/usr/share
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/iceweasel
/usr/share/applications
/usr/share/applications/iceweasel.desktop
/usr/share/doc
/usr/share/doc/iceweasel
/usr/share/doc/iceweasel/copyright
/usr/share/doc/iceweasel/MPL-1.1.gz
/usr/share/doc/iceweasel/MPL-2.0.gz
/usr/share/doc/iceweasel/changelog.Debian.gz
/usr/bin/iceweasel
pabs@chianamo ~ $ grep -i exec /usr/share/applications/iceweasel.desktop
Exec=firefox-esr %u
pabs@chianamo ~ $ grep -i icon /usr/share/applications/iceweasel.desktop
Icon=firefox-esr
pabs@chianamo ~ $ ls -l /usr/bin/iceweasel
lrwxrwxrwx 1 root root 30 Apr 13 10:13 /usr/bin/iceweasel -> 
../lib/firefox-esr/firefox-esr*

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#803112: Same here

[Bruce LaZerte]

Upgraded to latest Debian testing and same version of gdm3 as reported
here. Same problems. Same work arounds.
Asus UL-30A with Intel's GMA X4500MHD graphics chip.
 

Bug#821869: scim would prevent normal "quick find/search" feature of generic file manager (caja, etc)

[yh.jen]

Package: scim
Version: 1.4.15-3
Severity: important
Tags: newcomer

Dear Maintainer,

在一般的情況下，如果沒有裝scim。當我使用檔案管理程式例如nautilus
或是 caja，它們有一個功能是quick
find/search，這個功能的作用是在檔案檢視清單的時候，
如果按下任一個字母按鍵例如
"h"，螢幕上會出現一個文字輸入框框，內容為h，同時清單會自動跳選到第一個字母為h開頭的檔案,這時如果再按下例如"3"，螢幕上的文字輸入框內容會變成
"h3"，清單也會自動跳轉到檔案開頭為"h3"的檔案（如沒有，它不會有動作)。在很多的檔案管理程式，這個功能很普遍。

但是當我安裝了scim，配置好輸入法設定時，這個功能不見了，scim沒有開啟輸入法的時候(系統夾中的圖示是一個小鍵盤),在檔案管理程式按下每一個英文字母，它變的沒有反應.

我認為scim吃掉了它不應該吃掉的按鍵，或者是im-
config用了不對的方法啟動scim。我不了解電腦程式，不知道可能的問題會是什麼。

還有一個奇怪的現像,
我好幾個同時使用的輸入法（酷音，倉頡五，行列等），它們運作都很正常。但是當輸入法切換到英文模式時(按下shift變為英數模式)，除了酷音以外，大部份其它輸入法都無法輸入英文字母及空白(倉頡行列都一樣).在我以前使用debian
舊版的時代(我從6版開始用)沒有這個問題

我以前使用debian 6時也曾出現這個問題(指quick find feature
）那時還是用im-switch，但是那時候我只要裝scim-
bridge就能避免，而現在這個package沒有了，那個時候切換到英文模式時還能正常輸入英文。

我找遍了google, 除了
https://bugs.launchpad.net/ubuntu/+source/scim/+bug/287719
以外沒有有用的訊息能解決問題

有沒有人能研究一下這個二問題?

1. scim會吃掉 caja 內的quick find/search功能
2. scim輸入法切換到英文輸入模式時不能輸入英文

謝謝

我用 debian 8.4 amd64 stable 版



-- Package-specific info:
Related packages:
ii  libscim8c2a:am 1.4.15-3 amd64library for SCIM platform
ii  scim   1.4.15-3 amd64smart common input method platfor
ii  scim-chewing:a 0.3.4-4.1amd64Chewing IM engine module for SCIM
ii  scim-clutter-i 1.4.15-3 amd64Clutter input method module with 
ii  scim-gtk-immod 1.4.15-3 amd64GTK+ input method module with SCI
ii  scim-im-agent  1.4.15-3 amd64IM agent for SCIM platform
ii  scim-kmfl-imen 0.9.8-1.1amd64KMFL (Keyboard Mapping for Linux)
ii  scim-modules-s 1.4.15-3 amd64socket modules for SCIM platform
ii  scim-modules-t 0.5.14-1 amd64generic tables IM engine module f
ii  scim-tables-zh 0.5.14-1 all  Chinese input method data tables 

Related environment variables:
$XMODIFIERS=@im=SCIM
$GTK_IM_MODULE=scim
$QT_IM_MODULE=xim

Installed SCIM components:
/usr/lib/scim-1.0:
1.4.0

/usr/lib/scim-1.0/1.4.0:
IMEngine
SetupUI

/usr/lib/scim-1.0/1.4.0/IMEngine:
kmfl.a
kmfl.la
kmfl.so

/usr/lib/scim-1.0/1.4.0/SetupUI:
kmfl_imengine_setup.a
kmfl_imengine_setup.la
kmfl_imengine_setup.so

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

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

Versions of packages scim depends on:
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u4
ii  libcairo-gobject21.14.0-2.1+deb8u1
ii  libcairo21.14.0-2.1+deb8u1
ii  libgcc1  1:4.9.2-10
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u4
ii  libglib2.0-0 2.42.1-1+b1
ii  libgtk-3-0   3.14.5-1+deb8u1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libscim8c2a  1.4.15-3
ii  libstdc++6   4.9.2-10
ii  libx11-6 2:1.6.2-3

Versions of packages scim recommends:
ii  im-config [im-switch]  0.27-2
ii  scim-gtk-immodule [scim-gtk-immodule]  1.4.15-3
ii  scim-im-agent  1.4.15-3

Versions of packages scim suggests:
pn  scim-anthy  
pn  scim-canna  
ii  scim-chewing0.3.4-4.1
pn  scim-hangul 
pn  scim-m17n   
pn  scim-pinyin 
pn  scim-prime  
pn  scim-skk
pn  scim-tables-additional  
pn  scim-tables-ja  
pn  scim-tables-ko  
ii  scim-tables-zh  0.5.14-1
pn  scim-thai   
pn  scim-uim

-- Configuration Files:
/etc/X11/xinit/xinput.d/scim changed [not included]

-- no debconf information

Bug#821868: openstack-dashboard: causes trigger loop

[Andreas Beckmann]

Package: openstack-dashboard
Version: 2:9.0.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package causes a trigger loop.
This was observed during a testing -> sid upgrade test (where
openstack-dashboard had the same versions in testing and sid, and the
installation in testing went without problems).

>From the attached log (scroll to the bottom...):

  Processing triggers for libc-bin (2.22-6) ...
  dpkg: cycle found while processing triggers:
   chain of packages whose triggers are or may be responsible:
openstack-dashboard -> openstack-dashboard
   packages' pending triggers which are or may be unresolvable:
openstack-dashboard: /usr/share/javascript/jquery: 
/usr/share/javascript/angular.js
  dpkg: error processing package openstack-dashboard (--configure):
   triggers looping, abandoned
  Errors were encountered while processing:
   openstack-dashboard


cheers,

Andreas


openstack-dashboard_2:9.0.0-1.log.gz
Description: application/gzip

Bug#821867: plasma-desktop: Defaut/Breeze Login Screen was designed badly

[J Mo]

Package: plasma-desktop
Version: 4:5.4.3-1
Severity: normal

The default Login Screen (SDDM), Breeze, hides login options, user accounts, 
and can potentially put the user into a position where they can not log back in 
without deviating from reasonable behavior.

Let's just call it thoughtlessly bad design.

First, add at least five users accounts to the system.

At the default login screen, we are presented with a large clock, some squares 
representing users with the username below the square, and a login prompt and 
Login button below.

Select the right-most user and all but the left-adjacent users have 
disappeared. There is no indication that these users exist. They have just 
magically disappeared and there is no obvious way to get them back. Any logical 
reasonable person who sat down to the computer in this state would think there 
was only two user accounts on the system and nothing else. And, if the last 
user to log into the computer was the right-most in the list, this is exactly 
what happens when the system boots and presents the login screen. The only way 
to make the other accounts appear to to click on the 2nd-right most user on the 
bar or use the left-arrow key. Additionally, I suspect if there are enough user 
accounts (ten in the case of my screen), they will also not be visible and 
there will be no hint/indication that they exist.

Next let's log in and then lock our screen (ctrl+alt+l).

We are presented with three squares: The user, "New Session", and "Change 
Session". Click on the Change Session square, or press right-arrow twice.

Tada, your user account has disappeared and is nowhere to be found. It no 
longer exists. Pressing the Esc key does nothing. Mouse wheel does nothing. 
Take any average computer user, stick them down in front of this screen, and 
count the milliseconds away until frustration and confusion occurs.

The only way to correct the situation is to click on the "New Session" button 
or press the right-arrow key on the keyboard, neither of which is a logical 
thing to do.




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

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

Versions of packages plasma-desktop depends on:
ii  breeze  4:5.4.3-1
ii  kactivities 5.16.0-1
ii  kde-cli-tools   4:5.4.3-1
ii  kded5   5.16.0-1
ii  kio 5.16.0-1
ii  libc6   2.22-6
ii  libcanberra00.30-3
ii  libfontconfig1  2.11.0-6.4
ii  libgcc1 1:5.3.1-14
ii  libkf5activities5   5.16.0-1
ii  libkf5activitiesexperimentalstats1  4:5.4.3-1
ii  libkf5archive5  5.16.0-1
ii  libkf5auth5 5.16.0-1
ii  libkf5baloo55.16.0-1
ii  libkf5bookmarks55.16.0-1
ii  libkf5codecs5   5.16.0-1
ii  libkf5completion5   5.16.0-1
ii  libkf5configcore5   5.16.0-1
ii  libkf5configgui55.16.0-1
ii  libkf5configwidgets55.16.0-1
ii  libkf5coreaddons5   5.16.0-1
ii  libkf5dbusaddons5   5.16.0-1
ii  libkf5emoticons55.16.0-2
ii  libkf5globalaccel5  5.16.0-1
ii  libkf5guiaddons55.16.0-1
ii  libkf5i18n5 5.16.0-1
ii  libkf5iconthemes5   5.16.0-1
ii  libkf5itemviews55.16.0-1
ii  libkf5jobwidgets5   5.16.0-1
ii  libkf5kcmutils5 5.16.0-1
ii  libkf5kdelibs4support5  5.16.0-1
ii  libkf5kiocore5  5.16.0-1
ii  libkf5kiofilewidgets5   5.16.0-1
ii  libkf5kiowidgets5   5.16.0-1
ii  libkf5newstuff5 5.16.0-1
ii  libkf5notifications55.16.0-1
ii  libkf5notifyconfig5 5.16.0-1
ii  libkf5parts55.16.0-1
ii  libkf5people5   5.16.0-1
ii  libkf5peoplewidgets55.16.0-1
ii  libkf5plasma5   5.16.0-1
ii  libkf5plasmaquick5  5.16.0-1
ii  libkf5quickaddons5  5.16.0-1
ii  libkf5runner5   5.16.0-1
ii  libkf5service-bin   5.16.0-1
ii  libkf5service5  5.16.0-1
ii  libkf5solid55.16.0-1
ii  libkf5sonnetui5 5.16.0-1
ii  libkf5wallet-bin5.16.0-1
ii  libkf5wallet5   5.16.0-1
ii  libkf5widgetsaddons55.16.0-1
ii  

Bug#821407: debtags: scripts use python3 but have Python 2-only syntax

[Paul Wise]

On Tue, 2016-04-19 at 15:37 +0200, Enrico Rossi wrote:

> both scripts are broken and no longer maintained. I'm going to remove
> them from the next version.

Seems like they are useful scripts that should be fixed instead?

Please remove python3-debtagshw if you remove debtags-hardware.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#820866: r-cran-tgp: FTBFS: cmath:171:3: error: template with C linkage

[Andreas Beckmann]

Control: tag -1 moreinfo unreproducible

Hi Chris,

On Wed, 13 Apr 2016 10:11:37 +0100 Chris Lamb  wrote:
> Source: r-cran-tgp
> Version: 2.4-9-1

> r-cran-tgp fails to build from source in unstable/amd64:

>   /usr/include/c++/5/cmath: At global scope:
>   /usr/include/c++/5/cmath:171:3: error: template with C linkage
>  template

I cannot reproduce this in my sid pbuilder setup. Could you check again?
(I think gcc got updated since you filed this bug.)


Andreas

Bug#821808: [pkg-gnupg-maint] Bug#821808: Acknowledgement (libgpgme11: Fails to locate new key in agent (wrong keygrip?))

[Daniel Kahn Gillmor]

On Tue 2016-04-19 20:27:38 -0400, Matthew Gabeler-Lee wrote:
> On Tue, 19 Apr 2016, Daniel Kahn Gillmor wrote:
>
>> Thanks for the followup.  I'm closing this report since there's a clear
>> workaround.  However, gpg2 (from the 2.1 branch) should have migrated
>> your secret keyring automatically the first time it ever encountered
>> them.
>
> It did do that properly.  My problem was having created a new key with 
> gpg long after gpg2 ran that migration.

ah, right, understood.  I don't think that the gpg2 migration process
has any way to account for this situation. :(

All the more reason we should rip off the bandaid and just transition
already.

>> fwiw, i'm hoping that gpg and gpg2 will be the same thing (from the
>> 2.1.x sources) in debian in the not-too-distant future.
>
> :happydance:

glad you're happy about it too :)

 --dkg

Bug#378779: xmessage -default ignores -print

[Yuriy M. Kaminskiy]

Control: tags -1 patch
Control: found -1 x11-utils/7.7+2
thanks

Still present in jessie. Attached patch should fix it.
>From f4ef2e191e39c7a2de5902d761e4103dfa571074 Mon Sep 17 00:00:00 2001
From: "Yuriy M. Kaminskiy" 
Date: Wed, 20 Apr 2016 03:51:46 +0300
Subject: [PATCH] xmessage: -default ignores -print

Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378779
---
 xmessage.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/xmessage.c b/xmessage.c
index 6f31007..d7ff0f9 100644
--- a/xmessage.c
+++ b/xmessage.c
@@ -150,7 +150,11 @@ default_exit_action(Widget w, XEvent *event, String *params,
 Cardinal *num_params)
 {
 if (default_exitstatus >= 0)
+  {
+if (qres.default_button != NULL && qres.print_value)
+  puts(qres.default_button);
 	exit(default_exitstatus);
+  }
 }
 
 /* Convert tabs to spaces in *messagep,*lengthp, copying to a new block of
-- 
2.1.4

Bug#821866: aptitude -t option does not work as documented; -t unstable download gets package from experimental

[Josh Triplett]

Package: aptitude
Version: 0.7.8-1
Severity: normal

"man aptitude" says:

> -t , --target-release 
> Set the release from which packages should be installed. For
> instance, “aptitude -t experimental ...”  will install packages
> from the experimental distribution unless you specify otherwise.
> For the command-line actions “changelog”, “download”, and “show”,
> this is equivalent to appending / to each package named on
> the command-line;

However:

/tmp$ aptitude -t unstable download apt-listchanges
Get: 1 http://ftp.us.debian.org/debian experimental/main amd64 apt-listchanges 
all 3.1 [101 kB]
Fetched 101 kB in 0s (301 kB/s)

/tmp$ aptitude download apt-listchanges/unstable
Get: 1 http://ftp.us.debian.org/debian unstable/main amd64 apt-listchanges all 
2.89 [95.7 kB]
Fetched 95.7 kB in 0s (267 kB/s)

The same goes for "show" and "changelog".

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.7.8
Compiler: g++ 5.3.1 20160224
Compiled against:
  apt version 5.0.0
  NCurses version 6.0
  libsigc++ version: 2.6.2
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20160319
  cwidget version: 0.5.17
  Apt version: 5.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffd9d5a9000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7f9406c8d000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7f9406a5d000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f9406832000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f940662b000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f940632e000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f9406033000)
libboost_iostreams.so.1.58.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0 (0x7f9405e19000)
libboost_filesystem.so.1.58.0 => 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0 (0x7f9405c0)
libboost_system.so.1.58.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0 (0x7f94059fb000)
libxapian.so.22 => /usr/lib/x86_64-linux-gnu/libxapian.so.22 
(0x7f94055f7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f94053da000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f940505e000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f9404d6)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f9404b4a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f94047a5000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f94045a2000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f940439e000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f9404186000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f9403f6b000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f9403d5b000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f9403b37000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f9403925000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f940371c000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f9403517000)
/lib64/ld-linux-x86-64.so.2 (0x55f3986e4000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common0.7.8-1
ii  libapt-pkg5.0  1.2.10
ii  libboost-filesystem1.58.0  1.58.0+dfsg-5+b1
ii  libboost-iostreams1.58.0   1.58.0+dfsg-5+b1
ii  libboost-system1.58.0  1.58.0+dfsg-5+b1
ii  libc6  2.22-6
ii  libcwidget3v5  0.5.17-4+b1
ii  libgcc11:5.3.1-14
ii  libncursesw5   6.0+20160319-1
ii  libsigc++-2.0-0v5  2.8.0-1
ii  libsqlite3-0   3.12.1-1
ii  libstdc++6 5.3.1-14
ii  libtinfo5  6.0+20160319-1
ii  libxapian22v5  1.2.23-1

Versions of packages aptitude recommends:
pn  aptitude-doc-en | aptitude-doc  
ii  libparse-debianchangelog-perl   1.2.0-8
ii  sensible-utils  0.0.9

Versions of packages aptitude suggests:
pn  apt-xapian-index  
pn  debtags   
pn  tasksel   

-- no debconf information

Bug#821865: FTBFS on various architectures with -Werror=format-security

[Michael Biebl]

Source: totem
Version: 3.20.1-1
Severity: serious

totem FTBFS on various architectures
https://buildd.debian.org/status/package.php?p=totem

Those build failures are caused by -Werror=format-security

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

Kernel: Linux 4.5.0-1-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)

-- no debconf information

Bug#821864: Please drop dependency on liboobs

[Michael Biebl]

Package: lxqt-admin
Version: 0.10.0-3
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs

Hi,

liboobs is dead upstream (last update is over 5 years ago) and no longer
properly maintained.

We want to get rid of it in the Debian archive. Please update lxqt-admin
to no longer rely on liboobs.

Regards,
Michael


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

Kernel: Linux 4.5.0-1-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)

Bug#821863: Do not release with stretch

[Michael Biebl]

Source: liboobs
Version: 3.0.0-2
Severity: serious

liboobs is dead and no longer maintained properly
(upstream and downstream)

We shouldn't release stretch with this package, so I'm filing this RC
bug. Eventually we should remove it from the archive completely.



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

Kernel: Linux 4.5.0-1-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)

Bug#821862: Do not release with stretch

[Michael Biebl]

Source: system-tools-backends
Version: 2.10.2-2
Severity: serious

system-tools-backends is dead and no longer maintained properly
(upstream and downstream)

We shouldn't release stretch with this package, so I'm filing this RC
bug. Eventually we should remove it from the archive completely.


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

Kernel: Linux 4.5.0-1-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)

Bug#821808: [pkg-gnupg-maint] Bug#821808: Acknowledgement (libgpgme11: Fails to locate new key in agent (wrong keygrip?))

[Matthew Gabeler-Lee]

On Tue, 19 Apr 2016, Daniel Kahn Gillmor wrote:


Thanks for the followup.  I'm closing this report since there's a clear
workaround.  However, gpg2 (from the 2.1 branch) should have migrated
your secret keyring automatically the first time it ever encountered
them.


It did do that properly.  My problem was having created a new key with 
gpg long after gpg2 ran that migration.



fwiw, i'm hoping that gpg and gpg2 will be the same thing (from the
2.1.x sources) in debian in the not-too-distant future.


:happydance:

--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#821341: debian-installer: unbootable, no gpt partition for uefi install

[Steve McIntyre]

Hey Josh,

On Mon, Apr 18, 2016 at 10:33:31PM +0200, josh wrote:
>Hi Steve,
>
>thanks for your reply.
>
>> It depends very much on the machine involved, to be honest - many will
>> boot UEFI from appropriately partitioned MBR-partitioned disks. It
>> depends very much on the firmware of the machine here.
>
>hmmm...I didn't wade through the 1000+ page UEFI specs myself, but this
>entry on superuser.com cites them and claims that according to the
>specs, a UEFI boot partition /must/ reside on a gpt disk (this makes
>some sense since gpt is part of the UEFI specs afaik...):
>
>http://superuser.com/questions/563074/do-hard-drives-need-a-guid-partition-table-gpt-to-boot-in-uefi-mode
>
>This MSDN article states the same
>(https://msdn.microsoft.com/en-us/library/windows/hardware/dn640535%28v=vs.85%29.aspx#gpt_faq_mixed_gpt_mbr):
>
>"Systems that support UEFI require that boot partition must reside on a
>GPT disk. Other hard disks can be either MBR or GPT."

That's just for Windows booting - see further down the same page

"Do only GPT Disks have ESPs?

No, MBR disks can also have ESPs. UEFI specifies booting from either
GPT or MBR. The ESP on an MBR disk is identified by partition type
0xEF. However, Windows does not support booting UEFI from MBR disks or
0xEF partitions."

Section 5.2 in UEFI 2.5
(http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf)
deals with UEFI and MBR, and specifcally lists supporting an ESP with
partition type 0xEF.

The superuser.com answer may sound authoritative, but I believe it to
be incorrect.

>> This is clearly difficult to do in some cases, e.g. if
>> other OSes are on the system already.
>
>I agree that if somebody's installing to drive that already has
>something installed on it, than you can't just go and change the mbr to
>a gpt without asking. I was doing a virgin install of a new machine
>originally partitioning and formatting a new blank disk. In this case
>you should definitely have at least the option of having a gpt and
>probably a notification that this would be preferable.

If your disk was blank and you've booted the installer in UEFI mode,
it will choose GPT by default. That's the standard flow. If you choose
to "use entire disk", it will deliberately choose to switch from MBR
partitioning to GPT partitioning at that point. I've just tested
exactly this with the 8.4.0 amd64 netinst. Are you totally sure that
your disk was blank up-front? I'm wondering why you've not had the
same experience I've had developing and using this code!

>As far as I remember, I /did/ select expert install and I didn't find an
>option for choosing gpt. Are you saying there is one, and I missed it?
>If so, it doesn't seem easily findable (or I'm blind, or didn't select
>expert install after all...).

There is a question available, at priority=low which is what the
expert installer uses, yes. If you select the disk itself in the
partitioning menu, it will ask you if you want to create a new blank
partition table and then it will ask you what partition format to
use. It's not the most obvious, admittedly. :-)

>If it is the case that the UEFI specs actually require a gpt for efi
>boot, than a gpt should be the *default* for an UEFI install imho. If
>d-i detects another OS and the disk is mbr, than d-i should display a
>message either asking whether the disk should be converted to mbr
>stating the risks and/or state that the system likely won't be UEFI
>bootable if a gpt is not selected. All this should be available even in
>a non-expert install, again imho.
>
>Also, if it is the case that the UEFI specs require a gpt for efi boot,
>and some systems are uefi booting from mbrs, than those are the buggy
>ones, and whether one hopes it or not, one might expect that more and
>more mainboard chipsets will implement the specs correctly and not uefi
>boot from non-gpt disks. I have an MSI mainboard, which I think are
>pretty good, and it definitely refused to boot from an mbr disk with an
>efi partition.

We *do* default to GPT for most UEFI installations right now, but even
so I'm fairly convinced that MBR should work on most machines (both
from experience and from reading the specifications). It's not
uncommon that edge conditions bite people, though - various UEFI
implementations in the wild are notoriously buggy and ignore parts of
the specification in favour of "just do what Windows works with, and
test that only." :-( See

  http://wiki.osdev.org/Broken_UEFI_implementations 

for a table of known bugs that the Linux distro developers have put
together to share our experiences in this area. It might be worth
mentioning that your MSI mainboard doesn't like MBR UEFI boot there.

In terms of improving d-i, we *can* add a warning message that some
machines may not boot UEFI on MBR. I'll try to get to that before the
stretch release, but I'll be honest and say that it's not going to be
a high priority for me. Patches welcome if you'd like to help here!
:-)

-- 
Steve McIntyre, 

Bug#821363: debian-policy: Allow line-end comments in all Debian packaging control files

[Guillem Jover]

Hi!

On Mon, 2016-04-18 at 14:52:22 +1000, Ben Finney wrote:
> Package: debian-policy
> Severity: normal
> Control: tags -1 patch

> The specification of Debian control files in Policy §5.1 says:
> 
> Lines starting with # without any preceding whitespace are
> comments lines that are only permitted in source package control
> files (debian/control). These comment lines are ignored, even
> between two continuation lines. They do not end logical lines.
> 
> What is the rationale for explicitly disallowing line-end comments in
> any but that one file?

This just predates other files in source packages using deb822 syntax.
The reason is that the control file in a binary package does not
support comments for example. If you want to extend this list, please
make sure each and every file you want to add supports comments by
the major parsers. Remember that policy tends to be descriptive not
prescriptive.

> The ‘debian/copyright’ file is an example of a file of the described
> syntax, that benefits from line-end comments (e.g. for editor hints,
> or for temporarily disabling some lines, or for explaining an unusual
> value for a field).

The fact that it might benefit from it does not mean that this should
be documented as such w/o getting agreement that this is alright, and
implementing the support in the major parsers. In the case of the
copyright file, the document specifying it does not list # as valid
comment markers.

For example parsing debian/copyright files (or any other file using
deb822-based syntax) via the Dpkg::Control::Hash perl module would
make it accept such comments, but I don't know if other parsers will
accept those too.

> If there is no good rationale to categorically deny all line end
> comments in other files with that syntax, I suggest the attached
> patches.

Yes, they are probably just not supported.

Thanks,
Guillem

Bug#505893: x11-utils: xmessage ignores locale encoding

[Yuriy M. Kaminskiy]

Control: found -1 x11-utils/7.7+2
Control: tags -1 patch
thanks

For the record:
1) xmessage 1.0.4 was included in 7.7+1
2) ...however, as of jessie, xmessage seems still broken;
3) I've found workaround:

  python -c 'print u"aix\xf2".encode("utf-8")' | \
 xmessage -xrm '*international:true' -file -

(assuming LANG=en_US.UTF-8 or other utf-8 locale).

(No idea why/how it worked for James Cloos; I don't see any relevant 
change in upstream xmessage repo, and there are no patches or 
customizations in gentoo xmessage package either; maybe something sets 
this xresource system-wide? or some libxaw change affects this?).


Patch attached.
--- x11-utils-7.7+3/xmessage/app-defaults/Xmessage.orig	2013-07-09 19:03:18.0 +0400
+++ x11-utils-7.7+3/xmessage/app-defaults/Xmessage	2016-04-20 02:43:33.0 +0300
@@ -4,3 +4,4 @@
 *message.scrollHorizontal:	Never
 *Command.shapeStyle:		oval
 *Command.highlightThickness:	1
+*international: true

Bug#821861: Drop gnome-screenshot from gnome-core

[Michael Biebl]

Package: gnome-core
Version: 1:3.14+4
Severity: normal

GNOME shell has builtin screenshot functionality and gnome-screenshot is
no longer used.
We should therefor drop it from the gnome-core meta package.

The gnome-flashback session probably still want's to pull it in.
CCing mity...@debian.org


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

Kernel: Linux 4.5.0-1-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 gnome-core depends on:
ii  adwaita-icon-theme 3.20-2
ii  at-spi2-core   2.18.3-4
ii  baobab 3.20.1-1
ii  caribou0.4.20-1
ii  caribou-antler 0.4.20-1
ii  dconf-cli  0.26.0-1
ii  dconf-gsettings-backend0.26.0-1
ii  empathy3.12.11-2
ii  eog3.20.1-1
ii  evince 3.20.0-1
ii  evolution-data-server  3.18.5-1+rebuild
ii  firefox-esr45.0.2esr-1
ii  fonts-cantarell0.0.21-1
ii  gdm3   3.20.1-1
ii  gkbd-capplet   3.6.0-1
ii  glib-networking2.48.0-1
ii  gnome-backgrounds  3.20-1
ii  gnome-bluetooth3.18.3-1
ii  gnome-calculator   3.20.0-1
ii  gnome-contacts 3.19.91-1
ii  gnome-control-center   1:3.20.1-1
ii  gnome-dictionary   3.18.0-2
ii  gnome-disk-utility 3.20.1-1
ii  gnome-font-viewer  3.20.0-1
ii  gnome-keyring  3.20.0-1
ii  gnome-menus3.13.3-6
ii  gnome-online-accounts  3.19.92.1-1+rebuild
ii  gnome-online-miners3.20.0-2
ii  gnome-packagekit   3.18.0-1
ii  gnome-screenshot   3.18.0-1
ii  gnome-session  3.20.1-1
ii  gnome-settings-daemon  3.20.1-1
ii  gnome-shell3.20.1-1
ii  gnome-shell-extensions 3.20.0-2
ii  gnome-sushi3.19.90-1
ii  gnome-system-log   3.9.90-4
ii  gnome-system-monitor   3.20.1-1
ii  gnome-terminal 3.20.1-2
ii  gnome-themes-standard  3.20-1
ii  gnome-user-guide   3.20.1-1
ii  gnome-user-share   3.18.1-1
ii  gsettings-desktop-schemas  3.20.0-3
ii  gstreamer1.0-plugins-base  1.8.0-1
ii  gstreamer1.0-plugins-good  1.8.0-1+b1
ii  gstreamer1.0-pulseaudio1.8.0-1+b1
ii  gucharmap  1:3.18.2-1
ii  gvfs-backends  1.28.1-1
ii  gvfs-bin   1.28.1-1
ii  gvfs-fuse  1.28.1-1
ii  libatk-adaptor 2.18.1-3
ii  libcanberra-pulse  0.30-3
ii  libcaribou-gtk-module  0.4.20-1
ii  libcaribou-gtk3-module 0.4.20-1
ii  libgtk-3-common3.20.3-1
ii  libpam-gnome-keyring   3.20.0-1
ii  mousetweaks3.12.0-1
ii  nautilus   3.20.0-1
ii  pulseaudio 8.0-2+b2
ii  sound-theme-freedesktop0.8-1
ii  totem  3.20.1-1
ii  tracker-gui1.8.0-2+b1
ii  vino   3.20.1-1
ii  yelp   3.20.1-1
ii  zenity 3.20.0-1

Versions of packages gnome-core recommends:
ii  anacron2.3-23
ii  network-manager-gnome  1.1.93-1

Versions of packages gnome-core suggests:
pn  gnome  

-- no debconf information

Bug#821860: dh-php: dh_php needs manpage

[Daniel Kahn Gillmor]

Package: dh-php
Version: 0.10
Severity: normal

0 dkg@alice:~/tmp$ dh_php --help
Usage: dh_php [options]

  dh_php is a part of debhelper. See debhelper(7)
  and dh_php(1) for complete usage instructions.
1 dkg@alice:~/tmp$ man dh_php
No manual entry for dh_php
See 'man 7 undocumented' for help when manual pages are not available.
16 dkg@alice:~/tmp$

please supply dh_php(1)!

thanks,

--dkg

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing'), (200, 'unstable'), (1, 
'experimental-debug'), (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.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-php depends on:
ii  debhelper   9.20160403
ii  liblist-moreutils-perl  0.413-1+b1
ii  perl5.22.1-9

dh-php recommends no packages.

dh-php suggests no packages.

-- debconf-show failed

Bug#821859: debian-policy: New virtual package ‘adventure’

[Ben Finney]

Package: debian-policy
Severity: wishlist

The classic game “Adventure” has an existing implementation in Debian,
and I am packaging another implementation (‘python-adventure’) which
hews closer to the original PDP-10 implementation's behaviour.

I have worked with the maintainer of the existing Debian package
‘bsdgames’, to make the name ‘/usr/games/adventure’ available via the
Debian alternatives system.

There are many existing implementations of Adventure, with different
choices made in details of implementation. I will be providing a
second implementation (in ‘colossal-cave-adventure’). We intend to use
the ‘adventure’ virtual package name, to declare providing an
implementation of the classic game Adventure.

-- 
 \   “Are you thinking what I'm thinking, Pinky?” “Uh... yeah, |
  `\ Brain, but where are we going to find rubber pants our size?” |
_o__)   —_Pinky and The Brain_ |
Ben Finney 


signature.asc
Description: PGP signature

Bug#821858: openjdk-7-jre-headless: postinst turns /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi into a dangling symlink

[Andreas Beckmann]

Package: openjdk-7-jre-headless
Version: 7u95-2.6.4-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package deletes the zoneinfo
database it ships.

The postinst seems to contain code leftover from the time when tzdata-java
existed as a separate package. But now the opposite direction would be needed:
cleaning up the /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi symlink before
replacing it with a proper directory tree. (dpkg-maintscript-helper 
symlink_to_dir
might help here).

>From the attached log (usually somewhere in the middle...):

0m52.3s INFO: dirname part contains a symlink:
  /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi/Africa 
(openjdk-7-jre-headless:amd64) != /usr/share/javazi/Africa (?)
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi -> ../../../../../share/javazi
  /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi/Africa/Abidjan 
(openjdk-7-jre-headless:amd64) != /usr/share/javazi/Africa/Abidjan (?)
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi -> ../../../../../share/javazi
  /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi/Africa/Accra 
(openjdk-7-jre-headless:amd64) != /usr/share/javazi/Africa/Accra (?)
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi -> ../../../../../share/javazi
  /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi/Africa/Algiers 
(openjdk-7-jre-headless:amd64) != /usr/share/javazi/Africa/Algiers (?)
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi -> ../../../../../share/javazi
[...]

0m52.4s DEBUG: Starting command: ['debsums', '--root', 
'/tmp/piupartss/tmp3EYIf5', '-ac']
0m53.2s DUMP: 
  debsums: missing file 
/tmp/piupartss/tmp3EYIf5/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi/Africa/Abidjan
 (from openjdk-7-jre-headless:amd64 package)
  debsums: missing file 
/tmp/piupartss/tmp3EYIf5/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi/Africa/Accra
 (from openjdk-7-jre-headless:amd64 package)
  debsums: missing file 
/tmp/piupartss/tmp3EYIf5/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi/Africa/Algiers
 (from openjdk-7-jre-headless:amd64 package)
  debsums: missing file 
/tmp/piupartss/tmp3EYIf5/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi/Africa/Bissau
 (from openjdk-7-jre-headless:amd64 package)
  debsums: missing file 
/tmp/piupartss/tmp3EYIf5/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi/Africa/Cairo
 (from openjdk-7-jre-headless:amd64 package)
  debsums: missing file 
/tmp/piupartss/tmp3EYIf5/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi/Africa/Casablanca
 (from openjdk-7-jre-headless:amd64 package)
  debsums: missing file 
/tmp/piupartss/tmp3EYIf5/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi/Africa/Ceuta
 (from openjdk-7-jre-headless:amd64 package)
[...]


cheers,

Andreas


openjdk-7-jre-headless_7u95-2.6.4-3.log.gz
Description: application/gzip

Bug#821857: FTBFS with gtk+ < 3.20

[Michael Biebl]

Source: gnome-contacts
Version: 3.19.91-1
Severity: serious
Forwarded: https://bugzilla.gnome.org/show_bug.cgi?id=765147

gnome-contacts needs gtk+ >= 3.20 to compile successfully

See
https://buildd.debian.org/status/fetch.php?pkg=gnome-contacts=mipsel=3.19.91-1=1461065031


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

Kernel: Linux 4.5.0-1-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)

-- no debconf information

Bug#821361: Voting for CTTE Chair

[Don Armstrong]

On Sun, 17 Apr 2016, Don Armstrong wrote:
> The ballot is the following:
> 
> ===BEGIN===
> 
> The chair of the CTTE will be:
> 
> A: Don Armstrong
> B: Andreas Barth
> C: Phil Hands
> D: Sam Hartman
> E: Tollef Fog Heen
> F: Keith Packard
> G: Didier Raboud 
> ===END===

Just for the avoidance of doubt, I'm OK with being re-elected as chair
until we nominate one more CTTE member, but I'm also OK with
transitioning to someone who isn't terming out in December.

If there is someone who would like to serve as chair, feel free to vote
for yourself first.

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

We want 6. 6 is the 1.
 -- "The Prisoner (2009 Miniseries)" _Checkmate_

Bug#821847: [Pkg-dns-devel] Bug#821847: Bug#821847: dnsval: FTBFS on kFreeBSD: undefined reference to `getprogname'

[Aaron M. Ucko]

Ondřej Surý  writes:

> #define getprogname() program_invocation_short_name

It looks like this variable is available, and a standard glibc feature;
as such, I'd recommend conditionalizing its use on __GLIBC__ rather than
__linux__.  Likewise, this logic probably shouldn't need to exclude EABI
ARM systems.

Also, I see that this logic appears in both libval/val_policy.c and
libval_shim/libval_shim.c; please make sure to cover both, if you
haven't already.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#821350: dh-golang: generates rubbish in Built-Using; errors on invocation

[Michael Hudson-Doyle]

On 20 April 2016 at 09:05, Dmitry Smirnov  wrote:
> On Tuesday, 19 April 2016 12:02:10 PM AEST Michael Hudson-Doyle wrote:
>> Are there any other packages you think would be particularly good to
>> try to build?
>
> You can check the following packages, starting from top:

Thanks for this list.

> golang-github-aws-aws-sdk-go

This manages to trigger an "Argument list too long" in my patch. New
one coming in a little while.

Cheers,
mwh

> docker-swarm
> influxdb
> golang-github-unknwon-com
> cadvisor
> golang-github-revel-revel
> runc
>
> Thanks.
>
> --
> Cheers,
>  Dmitry Smirnov.

Bug#808610: Accepted xapian-core 1.2.22-3~bpo8+1 (source amd64 all) into jessie-backports, jessie-backports

[Olly Betts]

Control: fixed -1 1.2.12-2+deb7u1
Control: fixed -1 1.2.19-1+deb8u1

On Thu, Apr 07, 2016 at 10:26:20AM +0100, Olly Betts wrote:
> On Thu, Apr 07, 2016 at 09:05:43AM +, Eric Wong wrote:
> > Thanks Olly.  Are you still planning on getting #808610 fixed in
> > normal jessie (and not just jessie-backports)?
> 
> Yes, that's in progress:
> 
> https://bugs.debian.org/820059

Now uploaded for jessie, and also for wheezy:

http://bugs.debian.org/821757

The SRMs have OKed the patches - once these uploads are processed, I
will update wheezy-backports with a backport of 1.2.19-1+deb8u1 so that
this is fixed there too.

Cheers,
Olly

Bug#821855: segmentation fault with Polari since the 3.20 update

[Michael Biebl]

Control: forcemerge 820795 -1

Am 20.04.2016 um 00:31 schrieb Thibaut:
> Package: polari
> Version: 3.20.0-1
> 
> Hello,
> 
> Since Polari update to 3.20 version, I get a segmentation fault every
> time I tried to launch it :
> 
> $ polari
> Erreur de segmentation
> 

Duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820795

-- 
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#821856: mousepad: Changing preferences is always reset + doesn't save them

[Jiff]

Package: mousepad
Version: 0.4.0-3
Severity: normal

Hi, dear Mama Intainer,

   * What led up to the situation?

An attempt to change tabs & home/end preferences.

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

Open mousepad,
open the preferences panel,
change tabs to be spaces instead of tabulations,
change home/end from Disabled to Always,
close preferences,
close mousepad.

   * What was the outcome of this action?

Only the accel file is created into ~/.config/Mousepad,
no preferences file,
a reopen of mousepad confirmed that whatever change is made to it's
preferences,
   it is systematically reset when closing the panel.

   * What outcome did you expect instead?

Being able to change and save mousepad preferences.

Regards,
JY



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

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

Versions of packages mousepad depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  libc62.22-6
ii  libglib2.0-0 2.48.0-1
ii  libgtk2.0-0  2.24.30-1.1
ii  libgtksourceview2.0-02.10.5-2
ii  libpango-1.0-0   1.40.1-1

mousepad recommends no packages.

mousepad suggests no packages.

-- no debconf information

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Ben Finney]

On 19-Apr-2016, Markus Koschany wrote:
> thanks for your update. There are only a few things left before we can
> upload the package.

Thank you for working with me on this.

> My main concern is the adventure-common binary package because I
> don't believe that shipping advent.dat with an extra package is very
> useful at the moment.

Would you decline to upload on that basis? I appreciate you don't
think there's a benefit, but is there any appreciable harm from having
the ‘adventure-common’ package?

> I think it is cool to have a modern Python3 version but it would be
> rather boring to have identical versions that simply reuse the same
> story from advent.dat.

My thinking is that the Python 3 package is rather idiosyncratic, and
that I'd like to make it clear the common files are available for
different ports from the original Fortran program.

I'm not going to insist, but I'd like to know whether you think this
structure is harmful, or only that this isn't the style you would
choose.


> colossal-cave-adventure.desktop: error: (will be fatal in the future):
> value "colossal-cave-adventure.png" for key "Icon" in group "Desktop
> Entry" is an icon name with an extension, but there should be no
> extension as described in the Icon Theme Specification if the value is
> not an absolute path

I didn't see that part of the specification, thank you.

> Please change the Vcs fields […] so that the name of the git
> repository is identical to the source package name

Okay. The name ‘pkg-python-adventure’ was originally chosen because
the repository had only the Debian packaging, like other ‘pkg-foo’
repositories. I will re-name it now that the repository also contains
the upstream code.

> and that we use cgit for better performance.

Recently, the default browser on Alioth was switched to Cgit. So,
at  the Cgit
browser is presented.

> There is a authoritative list of virtual package names (yeah,
> bureaucracy in Debian is wonderful)
> 
> https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
> 
> Please follow the procedure outlined in this text file

Great, I didn't know that existed :-) I will follow that procedure.

-- 
 \“I fly Air Bizarre. You buy a combination one-way round-trip |
  `\ticket. Leave any Monday, and they bring you back the previous |
_o__) Friday. That way you still have the weekend.” —Steven Wright |
Ben Finney 


signature.asc
Description: PGP signature

Bug#821793: python-llfuse: FTBFS in testing

[Nikolaus Rath]

retitle 821793 fusermount should not attempt to use /etc/mtab
severity 821793 normal
reassign 821793 fuse
thanks
bye
exit
whatever

On Apr 19 2016, Santiago Vila  wrote:
> On Tue, Apr 19, 2016 at 09:42:11AM -0700, Nikolaus Rath wrote:
>> Your build system is missing /etc/mtab (should be a symlink to
>> /proc/mounts).
>> 
>> At the moment I consider this a bug in your system, not in the
>> package. But I'm willing to be convinced by suitably convincing
>> references :-).
>
> Ok. Let's try:
>
> * I think we can both agree that a package should be buildable both
> in "native" form but also in a chroot.
>
> * The file does not belong to any package:
>
> $ dpkg -S /etc/mtab 
> dpkg-query: no path found matching pattern /etc/mtab
>
> * chroots are usually created by debootstrap. debootstrap does not
> create the symlink either.
>
> * schroot does not create the file when entering a chroot.
>
> * sbuild does not create the file when building a package.
>
> Based on the above, it seems that the file is only useful/required in
> living running systems at most, but not on chroots used to build
> packages.

That's convincing. But the problem is that /etc/mtab is not used by the
python-llfuse build directly, but by the "fusermount" command (which is
called by the unit tests). fusermount is shipped by the fuse package,
and presumably has a better case for opening /etc/mtab.

> I found this documentation from Linux From Scratch:
>
> http://www.linuxfromscratch.org/lfs/view/development/chapter06/createfiles.html
>
>   Historically, Linux maintains a list of the mounted file systems in
>   the file /etc/mtab. Modern kernels maintain this list internally and
>   exposes it to the user via the /proc filesystem. To satisfy utilities
>   that expect the presence of /etc/mtab, create the following symbolic
>   link:
>
>   ln -sv /proc/self/mounts /etc/mtab
>
> The way I read that, it seems mtab is a leftover from the past and
> it's there only for "historical reasons", but it does not seem to be
> something which is actually required.
>
> Moreover, accesing mtab directly seems very "low level". The "mount"
> command shows the mounted filesystems (even if in a different format).
>
> But even this seems to be deprecated as well, this is what the mount
> manpage says about mount's "listing mode":
>
>   The listing mode is maintained for backward compatibility only.
>
>   For more robust and customizable output use findmnt(8), especially
>   in your scripts.
>
> The findmnt command belongs to the mount package, which is "Essential: yes".
>
> So, to summarize: In a Debian chroot used to build packages, the symlink
> /etc/mtab may or may not be there (as this report itself shows).
>
> OTOH, in a Debian system the findmnt command is always there.
>
> Therefore, packages should probably not rely on /etc/mtab.
>
> If you still do not agree, please downgrade this bug, clone it, and
> reassign the cloned bug to sbuild, etc.


I don't want to dodge the issue, but I think reassigning to "fuse" is
really the only thing I can do. Unless you would argue that the
python-llfuse build should not be calling fusermount, because it's
intended for use on living systems only...?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#818265: Bug#818187: Bug#818265: Bug#818187: zeromq3 migrated without any transition being done

[Julian Taylor]

On 13.04.2016 15:39, Julian Taylor wrote:

On 04/13/2016 03:24 PM, Emilio Pozuelo Monfort wrote:

On 29/03/16 19:10, László Böszörményi (GCS) wrote:

Hi Julian,

On Sun, Mar 20, 2016 at 12:27 PM, Julian Taylor
 wrote:

On 20.03.2016 11:11, László Böszörményi (GCS) wrote:

  Sorry, my life was chaotic. Yes and no, checked it. First, there's a
new upstream version of pyzmq (15.2) for two months. It seems to be
security related according to the release log[1]:
- FIX: unicode/bytes bug in password prompt in zmq.ssh on Python 3
- workaround overflow bug in libzmq preventing receiving messages
larger than MAX_INT

[...]

The latest version does unfortunately not fix the problem. It is also
not security related, it just could not send large data due to bugs in zmq.
I guess a good approach would be to bisect zmq to see what they changed
to cause it.

  Just a friendly ping; could you test the latest Git master if that
fixes the hang and/or could you ask upstream for advice? Should I do
it? It seems it constantly get fixes that may be relevant.


The package is team maintained, so I would say go ahead and do a team upload.



I see nothing in git that might be related and I'm not a fan of just
doing a guess upload but if you like go ahead.
Note that you have to disable the new large send test as it will fail on
32 bit and possibly swap on 64 bit.
I still need to get porterbox access before I can look at it, but if
someone can bisect libzmq before that happens for me would be great.



here is what I have been able to figure out on powerpc, not much 
unfortunately.

https://github.com/zeromq/pyzmq/issues/838

Bug#821855: segmentation fault with Polari since the 3.20 update

[Thibaut]

Package: polari
Version: 3.20.0-1

Hello,

Since Polari update to 3.20 version, I get a segmentation fault every 
time I tried to launch it :


$ polari
Erreur de segmentation

My system :
libc6 2.22-6
Linux HAL 4.5.0-1-amd64 #1 SMP Debian 4.5.1-1 (2016-04-14) x86_64 GNU/Linux

Thanks

Bug#821854: kdepim: kmail and kleopatra should Depend: gnupg (>= 2) | gnupg2

[Daniel Kahn Gillmor]

Source: kdepim
Severity: normal

In debian experimental, we are preparing a version of gnupg that is
built from the "modern" GnuPG branch (today, that's GnuPG 2.1.x).
This means that we hope to have the gnupg packages (and /usr/bin/gpg)
provided from 2.1.x.

we'll be providing backward-compatible gnupg2 packages (e.g. with
symlinks from /usr/bin/gpg2 to /usr/bin/gpg) so that packages that
depend on the old path can continue to use it.

But we'd like to be able to remove those transitional/symlink packages
at some point.

kmail and kleopatra both explicitly Depend: on gnupg2.

It would be better if they Depended on gnupg (>= 2) | gnupg2 instead.

The attached patch should do the trick.

Thanks for maintaining kdepim in debian!

--dkg

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing'), (200, 'unstable'), (1, 
'experimental-debug'), (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.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/control b/debian/control
index cb35a09..7643048 100644
--- a/debian/control
+++ b/debian/control
@@ -225,7 +225,7 @@ Section: net
 Architecture: any
 Depends: dirmngr,
  gnupg-agent,
- gnupg2,
+ gnupg (>= 2) | gnupg2,
  gpgsm,
  pinentry-qt4 | pinentry-x11,
  ${misc:Depends},
@@ -241,7 +241,7 @@ Architecture: any
 Depends: ${misc:Depends}, ${perl:Depends}, ${shlibs:Depends}
 Recommends: accountwizard,
 gnupg-agent,
-gnupg2,
+gnupg (>= 2) | gnupg2,
 kdepim-doc,
 kdepim-themeditors,
 ktnef,

Bug#821757: wheezy-pu: package xapian-core/1.2.12-2

[Olly Betts]

On Tue, Apr 19, 2016 at 08:47:15PM +0100, Adam D. Barratt wrote:
> Please go ahead.

Thanks, now uploaded.

Cheers,
Olly

Bug#820059: jessie-pu: package xapian-core/1.2.19-1

[Olly Betts]

On Tue, Apr 19, 2016 at 08:38:11PM +0100, Adam D. Barratt wrote:
> Please go ahead.

Thanks, now uploaded.

Cheers,
Olly

Bug#821852: gpa: please allow gpa to depend on gnupg (>= 2) | gnupg2

[Daniel Kahn Gillmor]

Package: gpa
Version: 0.9.9-3
Severity: normal
Tags: patch

in debian experimental, we now have gnupg binary packages provided by
gnupg2 source packages.  This means that gnupg version 2.1.11-7+exp1
provides /usr/bin/gpg, which is from the "modern" branch of gnupg.

to make use of this, gpa should change its Build-Depends (and its
regular Depends) from "gnupg2" to "gnupg (>= 2) | gnupg2".

I've pushed the relevant patch (along with several other patches for
minor packaging cleanup) to the work-with-gpg2-as-gpg branch on
alioth.

Andreas, I'm happy upload this to debian directly if you want me to.
But i of course would prefer to have your review and approval!

I've just made a similar fix to the gpgme1.0 packaging, fwiw.

 --dkg

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing'), (200, 'unstable'), (1, 
'experimental-debug'), (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.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gpa depends on:
ii  gnupg2   2.1.11-7+exp1
ii  gpgsm2.1.11-7+exp1
ii  libassuan0   2.4.2-3
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-6
ii  libcairo21.14.6-1+b1
ii  libfontconfig1   2.11.0-6.4
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.32.3-2
ii  libglib2.0-0 2.48.0-1
ii  libgpg-error01.21-2
ii  libgpgme11   1.6.0-2
ii  libgtk2.0-0  2.24.30-1.1
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpangoft2-1.0-01.38.1-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

gpa recommends no packages.

gpa suggests no packages.

-- debconf-show failed

Bug#821369: my bad

[Martin Quinson]

Hello,

I'm sorry, I didn't notice the netanim package. I will stop building
it from the ns3 source package.

Sorry, Mt.

-- 
If it isn't straightforward to modify it, it will never be any good.
It will never be fast, it will never be correct. And it will
eventually be replaced by something modifiable. -- Paul Phillips


signature.asc
Description: PGP signature

Bug#821853: emacs: Emacs Menu entry has disappeared

[Toby Speight]

Package: emacs
Version: 46.1
Severity: normal

Dear Maintainer,

Has the menu file been dropped from the Emacs packages?  I can no
longer start Emacs directly from fvwm, and must resort to starting an
xterm just to launch an Emacs.

Please restore this useful functionality.

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

Kernel: Linux 3.16.7-ckt2-balti (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages emacs depends on:
ii  emacs24  24.5+1-6+b2

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#821848: perl: Regexp-matching "hangs" indefinitely on illegal input using binmode :utf8 using 100%CPU

[Dominic Hargreaves]

On Tue, Apr 19, 2016 at 11:49:02PM +0300, Alexandros Kosiaris wrote:
> Package: perl
> Version: 5.20.2-3+deb8u4
> Severity: normal
> Tags: upstream patch
> 
> Dear Maintainer,
> 
> There is a bug in Perl 5.8.9 (at least) that causes regular
> expressions an malformed UTF8 inputs to go into a forever loop and
> consume 100% CPU. Upstream's tracker url is
> https://rt.perl.org/Public/Bug/Display.html?id=123562. Patch is at
> http://perl5.git.perl.org/perl.git/commitdiff/22b433eff9a1ffa2454e18405a56650f07b385b5
> and attached is a version rebased for Debian Jessie. I have not
> confirmed it, but based on the versions numbers I believe Stretch and Sid are 
> also affected.

Thanks for the report. This was fixed in perl 5.22.1, which is now
in sid and stretch.

We might be able to fix this in stable; we'll see how that goes.

Cheers,
Dominic.

Bug#821777: [Reproducible-builds] Bug#821777: Bug#821777: diffoscope fails with "pkg_resources.DistributionNotFound: python-magic"

[Reiner Herrmann]

On Tue, Apr 19, 2016 at 09:57:45PM +, Mattia Rizzolo wrote:
> > There it simply doesn't clean up requires.txt.
> 
> Do you think it's safe and sane enough to just ignore all the python egg
> foo and empty the file during the build in d/rules or something on that
> line?
> I'm afraid I know nothing about distutils/setuptools and in general
> stuff to generate a python package for distribution, so I can't really
> judge on this...

I'm not yet sure what a good solution for this is, as I'm also not
really experienced with setuptools.
It might be nice for non-distribution installations, but it messes a bit
more with everything than I like (see also the auto-generated diffoscope
script...).


signature.asc
Description: Digital signature

Bug#820008: fixed in linux 4.5.1-1

[Arthur Gautier]

On Tue, Apr 19, 2016 at 10:48:51PM +0100, Ben Hutchings wrote:
> On Tue, 2016-04-19 at 19:15 +, Arthur Gautier wrote:
> > On Thu, 14 Apr 2016 15:00:55 + Ben Hutchings wrote:
> > > 
> > > Source: linux
> > > Source-Version: 4.5.1-1
> > > 
> > > We believe that the bug you reported is fixed in the latest version of
> > > linux, which is due to be installed in the Debian FTP archive.
> > > 
> > Hello,
> > 
> > As far as I tested, I believe the bug is incorrectly fixed. The modules
> > are not signed and fails to load with secureboot. insmod fails to load 
> > modules with "required key not available" error message.
> 
> You have to install the corresponding linux-modules-*-signed package
> from experimental, and my modified version of kmod from
> people.debian.org.  Full instructions will be on planet.debian.org
> soon.
> 

Hello Ben,
I can confirm this is working as expected. I haven't seen the
linux-signed package. Sorry for the noise.

Thanks!

-- 
\o/ Arthur
 G  Gandi.net

Bug#821815: Pending fixes for bugs in the rkt package

[Dmitry Smirnov]

On Tuesday, 19 April 2016 11:44:06 PM AEST Andreas Beckmann wrote:
> On 2016-04-19 23:31, Dmitry Smirnov wrote:
> > Why would it be wrong to remove cron job? Because of potential
> > modifications, right?
> 
> configuration files must be retained after removal, they are only
> removed during purge
> 
> conffiles (i.e. configuration files *shipped* by the package in /etc and
> managed by dpkg) must not be touched by maintainer scripts (removal
> would be noticed by dpkg and will be remembered - the file won't come
> back on upgrade/reinstallation (unless the package is purged inbetween);
> modification will cause dpkg to prompt about a "modified conffile" upon
> upgrades)
> 
> (see the respective policy sections for longer definitions of
> 'configuration file' and 'conffile')

I remember now... Thank you for feedback and explanation, Andreas.
I've never had to install a cron job before...

-- 
All the best,
 Dmitry Smirnov.


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

Bug#821777: [Reproducible-builds] Bug#821777: diffoscope fails with "pkg_resources.DistributionNotFound: python-magic"

[Reiner Herrmann]

On Tue, Apr 19, 2016 at 10:25:41AM +0200, Holger Levsen wrote:
> I'd expect this problem would be intercepted and a helpful error message
> would be displayed.

What I also just saw is that /usr/bin/diffoscope is a auto-generated
script from easy_install coming from "entry_points={ 'console_scripts' ... }"
in setup.py. Not bin/diffoscope from the source directory.
So this auto-generated script is actually throwing the error (because of
requires.txt described in the previous mail), not diffoscope.



signature.asc
Description: Digital signature

Bug#821777: [Reproducible-builds] Bug#821777: diffoscope fails with "pkg_resources.DistributionNotFound: python-magic"

[Mattia Rizzolo]

On Tue, Apr 19, 2016 at 11:50:30PM +0200, Reiner Herrmann wrote:
> I saw in the changelog of dh-python that cleaning this file up is a recent
> change [1], which explains why dh-python in stable behaves differently.

That change appears to be from Nov 2015, but I'm pretty sure this also
happened before.

> There it simply doesn't clean up requires.txt.

Do you think it's safe and sane enough to just ignore all the python egg
foo and empty the file during the build in d/rules or something on that
line?
I'm afraid I know nothing about distutils/setuptools and in general
stuff to generate a python package for distribution, so I can't really
judge on this...

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#821777: [Reproducible-builds] Bug#821777: diffoscope fails with "pkg_resources.DistributionNotFound: python-magic"

[Reiner Herrmann]

On Tue, Apr 19, 2016 at 10:25:41AM +0200, Holger Levsen wrote:
> $ diffoscope piuparts_0.70_source.changes piuparts_0.70~bpo8+1_source.changes
> Traceback (most recent call last):
>   File "/usr/bin/diffoscope", line 5, in 
> from pkg_resources import load_entry_point
>   File "/usr/lib/python3/dist-packages/pkg_resources.py", line 2876, in 
> 
> working_set = WorkingSet._build_master()
>   File "/usr/lib/python3/dist-packages/pkg_resources.py", line 449, in 
> build_master
> ws.require(__requires__)
>   File "/usr/lib/python3/dist-packages/pkg_resources.py", line 745, in require
> needed = self.resolve(parse_requirements(requirements))
>   File "/usr/lib/python3/dist-packages/pkg_resources.py", line 639, in resolve
> raise DistributionNotFound(req)
> pkg_resources.DistributionNotFound: python-magic

As Mattia found out, this is because the requires.txt of the backported
diffoscope is non-empty.

It contains the lines:
> python-magic
> libarchive-c

... which are the dependencies listed in setup.py as install_requires.
On unstable, those lines are _also_ in requires.txt _before_ dh_python3
runs. After it runs, it got cleaned up and the file is empty.
I saw in the changelog of dh-python that cleaning this file up is a recent
change [1], which explains why dh-python in stable behaves differently.
There it simply doesn't clean up requires.txt.

[1]: https://tracker.debian.org/media/packages/d/dh-python/changelog-2.20151103


signature.asc
Description: Digital signature

Bug#820008: fixed in linux 4.5.1-1

[Ben Hutchings]

On Tue, 2016-04-19 at 19:15 +, Arthur Gautier wrote:
> On Thu, 14 Apr 2016 15:00:55 + Ben Hutchings wrote:
> > 
> > Source: linux
> > Source-Version: 4.5.1-1
> > 
> > We believe that the bug you reported is fixed in the latest version of
> > linux, which is due to be installed in the Debian FTP archive.
> > 
> Hello,
> 
> As far as I tested, I believe the bug is incorrectly fixed. The modules
> are not signed and fails to load with secureboot. insmod fails to load 
> modules with "required key not available" error message.

You have to install the corresponding linux-modules-*-signed package
from experimental, and my modified version of kmod from
people.debian.org.  Full instructions will be on planet.debian.org
soon.

Ben.

-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
  - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'

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

Bug#821442: [buildd-tools-devel] Bug#821442: schroot: operation not permitted (only with 4.5 kernel)

[Ben Hutchings]

On Tue, 2016-04-19 at 10:10 -0300, Antonio Terceiro wrote:
> On Tue, Apr 19, 2016 at 10:08:54AM -0300, Antonio Terceiro wrote:
> > 
> > On Mon, Apr 18, 2016 at 09:58:31PM -0400, Barry Warsaw wrote:
> > > 
> > > On Apr 18, 2016, at 09:40 PM, James McCoy wrote:
> > > 
> > > > 
> > > > I've been seeing something similar.  Am I right to assume that
> > > > these are
> > > > union-type=overlay?  If so, this seems to be a change in the
> > > > kernel.
> > > Yep, union-type=overlay.
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1555997
> > seems to be related
> > 
> > Looks like something that needs to be fixed in linux. :-/
> ... and is supposed to be fixed upstream AFAICT (comment #10 in the
> launchpad bug above)

The bug fix that report refers to is

which is in 4.5, and refers to a regression in 4.5~rc1 caused by

.  The regression and fix commits were backported in 4.4.3 and 4.4.6
respectively.

So any regression when upgrading from 4.4.6-1 to 4.5.1-1 must be a
different bug.

Ben.

-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
  - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'


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

Bug#821850: e17: Using `mixer settings' from shelve, and changing anything, leads to the infamous SEGV'd.

[enno]

Package: e17
Version: 0.17.6-1
Severity: important

Dear Maintainer,

Rightclick Mixer icon on shelve, click mixer->settings, click e.g.
`Lock slider' or anything else, click OK (or Apply) -> e17 SEGV'd

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

Kernel: Linux 4.4.0-1-686-pae (SMP w/4 CPU cores)
Locale: LANG=de_AT@euro, LC_CTYPE=de_AT@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages e17 depends on:
ii  dbus-x11   1.10.8-1
ii  e17-data   0.17.6-1
ii  libasound2 1.1.0-1
ii  libc6  2.22-4
ii  libdbus-1-31.10.8-1
ii  libecore-con1  1.8.6-2.5
ii  libecore-evas1 1.8.6-2.5
ii  libecore-file1 1.8.6-2.5
ii  libecore-imf1  1.8.6-2.5
ii  libecore-input11.8.6-2.5
ii  libecore-ipc1  1.8.6-2.5
ii  libecore-x11.8.6-2.5
ii  libecore1  1.8.6-2.5
ii  libedbus1  1.7.10-1
ii  libedje-bin1.8.6-2.5
ii  libedje1   1.8.6-2.5
ii  libeet11.8.6-2.5
ii  libeeze1   1.8.6-2.5
ii  libefreet-bin  1.8.6-2.5
ii  libefreet1a1.8.6-2.5
ii  libeina1   1.8.6-2.5
ii  libeio11.8.6-2.5
ii  libevas1   1.8.6-2.5
ii  libevas1-engines-x [libevas1-engine-software-x11]  1.8.6-2.5
ii  libpam0g   1.1.8-3.2
ii  libxcb-keysyms10.4.0-1
ii  libxcb-shape0  1.11.1-1
ii  libxcb11.11.1-1

Versions of packages e17 recommends:
pn  pm-utils  

e17 suggests no packages.

-- no debconf information

Bug#821815: Pending fixes for bugs in the rkt package

[pkg-go-maintainers]

tag 821815 + pending
thanks

Some bugs in the rkt package are closed in revision
4e127a8f3a00f6a990b750c2b4a47dc73abcff7a in branch 'master' by Dmitry
Smirnov

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/rkt.git/commit/?id=4e127a8

Commit message:

cron: check if executable is available (Closes: #821815).

Fixes previous commit.

Thanks, Andreas Beckmann.

Bug#821815: Pending fixes for bugs in the rkt package

[Andreas Beckmann]

On 2016-04-19 23:31, Dmitry Smirnov wrote:
> Why would it be wrong to remove cron job? Because of potential modifications, 
> right?

configuration files must be retained after removal, they are only
removed during purge

conffiles (i.e. configuration files *shipped* by the package in /etc and
managed by dpkg) must not be touched by maintainer scripts (removal
would be noticed by dpkg and will be remembered - the file won't come
back on upgrade/reinstallation (unless the package is purged inbetween);
modification will cause dpkg to prompt about a "modified conffile" upon
upgrades)

(see the respective policy sections for longer definitions of
'configuration file' and 'conffile')


Andreas

Bug#821795: lttng-modules-dkms: module FTBFS in jessie against Linux 3.16: error: conflicting types for 'trace_mm_page_alloc_extfrag'

[Michael Jeanson]

Hi,

Here is a debdiff against the current package fixing the build
failure, I'll ask Jon to make a new upload.

Michael


lttng-modules-2.5.1-fix-build.debdiff
Description: Binary data

Bug#821815: Pending fixes for bugs in the rkt package

[Dmitry Smirnov]

On Tuesday, 19 April 2016 11:04:16 PM AEST Andreas Beckmann wrote:
> Instead check in the cronjob whether the binary exists and skip it
> silently if it doesn't:
> 
> test -x /usr/bin/rkt || exit 0

OK, thanks, I'll do that. It is safe and good idea in general.

Why would it be wrong to remove cron job? Because of potential modifications, 
right?

-- 
All the best,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B

---

The Santa myth is one of the most effective means ever devised for
intimidating children, eroding their self-esteem, twisting their
behavior, warping their values, and slowing their development of
critical thinking skills.
-- Tom Flynn, "The Trouble with Christmas"


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

Bug#817949: RFS: niceshaper/1.2.2-1 [ITP]

[Mariusz Jedwabny]

Hello,

I've just uploaded 1.2.2-2 version.

Changes since the last upload:

niceshaper (1.2.2-2) unstable; urgency=low

  * Move iptables from Depends to Recommends.
  * debian/copyright: point out that src/libnetlink.* is GPL-2+ (not GPL-2).
  * Bump Standards-Version to 3.9.8, no changes needed.

 -- Mariusz Jedwabny   Sun, 17 Apr 2016 20:59:23 +0200


On 15.04.2016 15:29, Gianfranco Costamagna wrote:

Hi again,


niceshaper (1.2.2-1) unstable; urgency=low


*one* single entry.
niceshaper (1.2.2-1) unstable; urgency=low


* Initial foo release closes: bar

signature.

that's all.


This signature is already there in the changelog, it was added to 
initial 1.0.0-2 version.


now it seems to be 3.9.8 :)


True:)

Bumped.



I would like, at least for now, to stay with exactly GPLv2 - without
option of v2.2 or v3.x or whatever.


licensecheck * -r |grep GPL |grep -v debian

src/libnetlink.h: *No copyright* GPL (v2 or later)
src/libnetlink.cc: *No copyright* GPL (v2 or later)


so your sources are wrong.
(at least they are missing from copyright file)




I've added paragraph about src/libnetlink.* files to debian/copyright, 
to inform that these are licensed under GPL-2+

and who are the authors.

Just to explain. These two files are originated from iproute2, wrapped 
into a C++ class by another author and, at the end,

adapted to NiceShaper needs by me.
Unfortunately, there was never "Copyright" clause in these files, only 
GPL-2+ license header text and Author fields.

There is still no such clause in original iproute2 source.
So, I hope I made the best what I could.

Regards
Mariusz Jedwabny

Bug#821272: rkt: Can't run docker images

[Nicolas Le Cam]

Hi Alban, Dmitry,

Thanks for your feedback.

Default umask is 0022
I'm using an ext4 FS

running busybox image returns different errors :
$ sudo rkt fetch --insecure-options=image docker://busybox
image: remote fetching from URL "docker://busybox"
Downloading sha256:385e281300c: [==] 676 KB/676 KB
Downloading sha256:a3ed95caeb0: [==] 32 B/32 B
sha512-cdb74a334f97f442a4da5230610ccf46
$ sudo rkt run --interactive docker://busybox --exec bash
image: using image from file /usr/lib/rkt/stage1-host.aci
image: using image from local store for url docker://busybox
networking: loading networks from /etc/rkt/net.d
networking: loading network default with type ptp
stage1: failed to write default.target: open
stage1/rootfs/usr/lib/systemd/system/default.target: operation not
permitted
$ sudo rkt run --interactive docker://busybox --exec bash
image: using image from file /usr/lib/rkt/stage1-host.aci
image: using image from local store for url docker://busybox
stage0: error setting up app image: open
/var/lib/rkt/pods/run/9ba6840a-96d5-493f-8c2d-434184c689c9/stage1/rootfs/opt/stage2/busybox/manifest:
operation not permitted
$ sudo rkt run --interactive docker://busybox --exec bash
image: using image from file /usr/lib/rkt/stage1-host.aci
image: using image from local store for url docker://busybox
networking: loading networks from /etc/rkt/net.d
stage1: failed to setup network: open
stage-1/rootfs/etc/rkt/net.d/99-default.conf: operation not permitted

Also tried with alpine, same error :
$ sudo rkt fetch --insecure-options=image docker://alpine
image: remote fetching from URL "docker://alpine"
Downloading sha256:420890c9e91: [==] 2.32 MB/2.32 MB
sha512-e738eac1830750ac3fcd152b3c83bf75
$ sudo rkt run --interactive docker://alpine --exec bash
image: using image from file /usr/lib/rkt/stage1-host.aci
image: using image from local store for url docker://alpine
stage0: error setting up app image: open
/var/lib/rkt/pods/run/18b328cc-ff10-4e04-8457-7aa6e47aab37/stage1/rootfs/opt/stage2/alpine/manifest:
operation not permitted

Same error with rkt 1.4.0, also tried with systemd-container and
btrfs-tools installed, no more luck.

I'll try docker2aci when time will permit but I did understood that
rkt automatically does the conversion when fetching docker:// uris

regards,
Nicolas

2016-04-19 12:22 GMT+02:00 Dmitry Smirnov :
> Hi Alban,
>
> Thank you for checking this issue.
>
> FYI by default Debian bug tracker send emails only to maintainers. You need
> to explicitly CC to reporter or to nn-submit...@bugs.debian.org (added to
> CC). See more:
>
> https://www.debian.org/Bugs/Developer#followup
>
> --
> Best wishes,
>  Dmitry Smirnov.
>
>
> On Tuesday, 19 April 2016 11:59:40 AM AEST Alban Crequy (Kinvolk) wrote:
>> Hi,
>>
>> I have not seen that issue before. I cannot reproduce.
>>
>> Does it work with other Docker images such as docker://busybox? What
>> is your default umask when running things with sudo? What is the
>> filesystem used for /var/lib/rkt (ext4, btfs...)?
>



-- 
Nicolas Le Cam

Bug#627782:

[Ben Hutchings]

Control: severity -1 important
Control: tag -1 upstream fixed-upstream patch

On Tue, 2016-04-19 at 14:57 +0900, Akihiro Suda wrote:
> The issue is not resolved yet in 3.16.7-ckt20-1+deb8u3 of
> linux-image-3.16.0-4-amd64.
>
> Although I didn't do test with Debian's 3.16 tree yet, the following
> commits to AUFS should fix the issue:
> 
> * 
> https://github.com/sfjro/aufs3-linux/commit/565ce4aa61963ebfd90b7768b1ba6c7d6af53c88
> * 
> https://github.com/sfjro/aufs3-linux/commit/e3fb13540a9cc40f106a13bfe89460f251b1ca30
>
> Can anyone please test and merge these commits?
> How to test the issue is posted on
> https://github.com/docker/docker/issues/20199#issuecomment-182719550

Thank you for researching this issue.  Now that a patch is available, I
think I'll be able to fix this soon.

I'm also raising the severity as it's clear aufs is widely used outside
of Debian Live despite our disclaimer of support.

Ben.

-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
  - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'


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

Bug#802919: unison: synchronization incompatibility when built with Ocaml versions pre/post-4.02

[Niels Elgaard Larsen]

On Thu, 24 Mar 2016 14:14:21 +0100 Baptiste Jonglez 
 wrote:

As a side note, the current state of unison/ocaml on stretch is confusing:
ocaml 4.02.3 is in stretch, but the unison binary package still seems to
be built against ocaml 4.01.  This is non-obvious and I spent quite some
time wondering why unison from stretch did not interoperate with another
unison client built against ocaml 4.02.




So did I. When I figured out, I just had to build unison from source and 
everything worked again.


At least "unison -version" should tell which version of ocaml it uses.

Bug#821150: cmucl: non-DFSG license

[Dmitry Smirnov]

On Tuesday, 19 April 2016 8:49:13 AM AEST Peter Van Eynde wrote:
> think you object to:
> >  Any person obtaining a copy of this software is requested to send their
> >  
> >  name and post office or electronic mail address to:
> >CommonLoops Coordinator
> >Xerox PARC
> > Coyote Hill Rd.
> >Palo Alto, CA 94304
> >  
> >  (or send Arpanet mail to commonloops-coordinator...@xerox.arpa)
> >  .
> >  Suggestions, comments and requests for improvements are also welcome.
> 
> As the last release of PCL was in September 1992 and PARC stopped doing
> common lisp, I think that no-one is listening for any emails anymore and
> that we can simply remove this request.

But this requirement is not optional. License do not allow us to speculate 
whether they are checking their post box or email and choose whether to 
comply with this requirement...


> Would you agree to this?

I'm not a copyright holder so I believe it is not up to me to decide on the 
matter. Could you clarify with upstream please?

-- 
All the best,
 Dmitry Smirnov.

---

Writing non-free software is not an ethically legitimate activity, so if
people who do this run into trouble, that's good! All businesses based
on non-free software ought to fail, and the sooner the better.
-- Richard Stallman


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

Bug#821847: [Pkg-dns-devel] Bug#821847: Bug#821847: dnsval: FTBFS on kFreeBSD: undefined reference to `getprogname'

[Ondřej Surý]

Aaron,

could you please check on kFreeBSD if something from those are defined
on kFreeBSD?

#define getprogname() program_invocation_short_name
#endif
#ifdef solaris2
#define getprogname() getexecname()
#endif
#ifdef WIN32
#define getprogname() NULL
#endif
#ifdef __OpenBSD__
#define getprogname() NULL
#endif
#ifdef eabi
#define getprogname() NULL
#endif

I will redefine it to NULL on kFreeBSD,  but it would be better to have
a real function here :).

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

On Tue, Apr 19, 2016, at 22:57, Ondřej Surý wrote:
> Aw, crap. The upstream use of autotools is quite creative, so it's
> probably some underlinking. I'll look into that tomorrow (could you
> please remind me if you don't hear from me withing a week? thanks)
> 
> O.
> -- 
> Ondřej Surý 
> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
> 
> On Tue, Apr 19, 2016, at 22:14, Aaron M. Ucko wrote:
> > Source: dnsval
> > Version: 2.2-2
> > Severity: important
> > Justification: fails to build from source (but built successfully in the
> > past)
> > 
> > Thanks for taking care of #821746 promptly!  Alas, another error
> > turned up:
> > 
> >   ../libval/.libs/libval-threads.so: undefined reference to `getprogname'
> >   collect2: error: ld returned 1 exit status
> >   Makefile:131: recipe for target 'dt-validate' failed
> > 
> > Could you please look into it as well?
> > 
> > Thanks!
> > 
> > ___
> > pkg-dns-devel mailing list
> > pkg-dns-de...@lists.alioth.debian.org
> > https://lists.alioth.debian.org/mailman/listinfo/pkg-dns-devel
> 
> ___
> pkg-dns-devel mailing list
> pkg-dns-de...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-dns-devel

Bug#821845: Acknowledgement (fails to copy first line of multi-line selection)

[Michael Biebl]

Hi Robert

thanks for this detailed bug report!

Am 19.04.2016 um 23:01 schrieb Robert Edmonds:
> Robert Edmonds wrote:
>> I reproduced this behavior in the sakura terminal emulator, so now I
>> think the bug is actually in vte2.91.
> 
> Yes. I bisected the buggy behavior to this commit in the upstream vte
> repository:
> 
> commit 3696348c0b9c7d60caf7302411ec4c0298f56e57
> Author: Christian Persch 
> Date:   Fri Dec 4 20:10:04 2015 +0100
> 
> widget: Rework get_text()
> 
> Ignore the passed VteSelectionFunc callback and just always use
> the whole passed range.
> 
> :04 04 8b7beb4d621909eb20522625d724d50edbc422ae 
> 6bdd1bf89bdef0f0b41412340395df6941f94275 M  src
> 

It would be great if you can forward this upstream to
https://bugzilla.gnome.org/page.cgi?id=browse.html=vte


Regards,
Michael
-- 
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#821815: Fwd: Re: Bug#821815: Pending fixes for bugs in the rkt package

[Andreas Beckmann]

The "Pending fixes ..." email had a Reply-to set to a mailing list that
rejects non-subscriber posting.

Andreas

 Forwarded Message 
Subject: Re: Bug#821815: Pending fixes for bugs in the rkt package
Date: Tue, 19 Apr 2016 21:04:20 +
From: pkg-go-maintainers-ow...@lists.alioth.debian.org
To: a...@debian.org

You are not allowed to post to this mailing list, and your message has
been automatically rejected.  If you think that your messages are
being rejected in error, contact the mailing list owner at
pkg-go-maintainers-ow...@lists.alioth.debian.org.




--- Begin Message ---
On 2016-04-19 22:51, pkg-go-maintain...@lists.alioth.debian.org wrote:
> The full diff can be seen at
> https://anonscm.debian.org/cgit/pkg-go/packages/rkt.git/commit/?id=00bc1fe

That's the wrong approach.

The cronjob is shipped as a conffile, do not touch it in the maintainer
scripts, dpkg takes care of it.
(install, remove (don't purge), install again - the cronjob would be
missing with the postrm in git)

Instead check in the cronjob whether the binary exists and skip it
silently if it doesn't:

test -x /usr/bin/rkt || exit 0


Andreas



--- End Message ---

Bug#821350: dh-golang: generates rubbish in Built-Using; errors on invocation

[Dmitry Smirnov]

On Tuesday, 19 April 2016 10:32:58 PM AEST Michael Stapelberg wrote:
> Dmitry, please let us know if the patch works for you and I’ll be happy to
> upload it.

Hi Michael,

Unfortunately I won't be able to spare time for testing at least till 
weekend.
Please upload if patch looks good for you -- I doubt it could make situation 
worse than it already is.

I should trust you to remember to test this important package before every 
upload. ;)

Uploaded or not I'll have a look at first opportunity. Thanks.

-- 
Cheers,
 Dmitry Smirnov.

---

Truth — Something somehow discreditable to someone.
-- H. L. Mencken, 1949


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

Bug#821849: RFP: golang-github-parnurzeal-gorequest -- HTTP client library for Google Go

[Daniel Stender]

Package: wnpp
Severity: wishlist
Control: block 820614 by -1

* Package name: golang-github-parnurzeal-gorequest
  Version : 0.2.13
  Upstream Author : Theeraphol Wattanavekin 
* URL : https://github.com/parnurzeal/gorequest
* License : Expat
  Programming Lang: Go
  Description : HTTP client library for Google Go

Simplified, fast HTTP client for Google Go (inspired by famous SuperAgent lib 
in Node.js).

This a requirement for vuls.

Thanks,
DS

Bug#821424: pulseaudio: Do not put normal users on group audio

[Ben Hutchings]

On Tue, 2016-04-19 at 11:24 +0300, asu wrote:
> 
> On 04/19/2016 07:07 AM, Christian PERRIER wrote:
> > 
> > Control: reassign -1 user-setup
> > 
> > Quoting Felipe Sateler (fsate...@debian.org):
> > > 
> > > Control: reassign -1 debian-installer
> > > 
> > > On 18 April 2016 at 13:06, Corcodel Marian  wrote:
> > > 
> > > > 
> > > > Any way pulseaudio is default sound server on debian and suggest to do 
> > > > not put
> > > > users on audio group because cross interference with alsa programs, now 
> > > > alsa is
> > > > for power users and pulseaudio is on default.
> > > Pulseaudio does not add the user to the audio group. I'm guessing the
> > > installer does, so I reassign there.
> > Adding the *first created* user to so-called "useful" groups is done
> > by user-setup.
> > 
> > We'll need a detaailed explanantion abou twhy this shouldn't be done
> > anymore, including all possible use cases of the installer.
> > 
> > 
> Just simple scenario i add asterisk user on group audio and asu user on 
> group audio result is bad
>   here is result of lsoff:
> root@marian1000:/home/asu# lsof /dev/snd/*
> COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> pulseaudi 961 asterisk  memCHR  116,4  9689 /dev/snd/pcmC0D0c
> pulseaudi 961 asterisk  memCHR  116,3  9688 /dev/snd/pcmC0D0p
> pulseaudi 961 asterisk   15u   CHR  116,2  0t0 9684 /dev/snd/controlC0
> pulseaudi 961 asterisk   20u   CHR  116,2  0t0 9684 /dev/snd/controlC0
> pulseaudi 961 asterisk   21u   CHR  116,3  0t0 9688 /dev/snd/pcmC0D0p
> pulseaudi 961 asterisk   22u   CHR  116,2  0t0 9684 /dev/snd/controlC0
> pulseaudi 961 asterisk   27u   CHR  116,2  0t0 9684 /dev/snd/controlC0
> pulseaudi 961 asterisk   32u   CHR  116,4  0t0 9689 /dev/snd/pcmC0D0c
> 
> On my user asu pulseaudio have acces only on Dummy card .
> Second on my audio application audacious  set to use  output to alsa 
> (assumed that pulseaudio is down)
> same issue audacious take control of audio device and is no room for 
> pulseaudio.

I don't believe the audio group has anything to do with this.  As I
explained, users logging in locally get access to sound cards even if
they aren't in the audio group.

I think the problem you have is one of:

1. Your X session doesn't start PA automatically
2. ALSA hasn't been properly configured to make applications uses PA
   when available
3. The application is overriding the default.

in descending order of likelihood.

(The pulseaudio package sets the default by installing these
configuration files for ALSA:

    /usr/share/alsa/pulse-alsa.conf
    /usr/share/alsa/alsa.conf.d/pulse.conf

but those can be overridden elsewhere.)

Ben.

-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
  - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'

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

Bug#820220: [Pkg-julia-devel] Bug#820220: Bug#820220: julia: FTBFS on armel/armhf

[Graham Inggs]

Hi Peter

On 19 April 2016 at 21:17, Peter Colberg  wrote:
> julia 0.4.5-3 FTBFS on armel due to an outdated llvm-3.8 package:

Yes, suihkulokki pointed this out previously.

I requested removal of the armel binaries in bug #820713, and that
already has been processed.
Since the 0.4.5-3 upload, the package builds again on armhf.  At the
moment there is nothing blocking testing migration, it should happen
in the next few days.

> I think it would be a good idea to retain the version constraint
> llvm-3.8-dev (>= 1:3.8~+rc1) that was dropped in commit 17796f1.

I don't think this is necessary.  Since the armel binaries have been
removed, consecutive armel build failures will not block migration.

Regards
Graham

Bug#821350: dh-golang: generates rubbish in Built-Using; errors on invocation

[Dmitry Smirnov]

On Tuesday, 19 April 2016 12:02:10 PM AEST Michael Hudson-Doyle wrote:
> Are there any other packages you think would be particularly good to
> try to build?

You can check the following packages, starting from top:

golang-github-aws-aws-sdk-go
docker-swarm
influxdb
golang-github-unknwon-com
cadvisor
golang-github-revel-revel
runc

Thanks.

-- 
Cheers,
 Dmitry Smirnov.


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

Bug#821845: Acknowledgement (fails to copy first line of multi-line selection)

[Robert Edmonds]

Robert Edmonds wrote:
> I reproduced this behavior in the sakura terminal emulator, so now I
> think the bug is actually in vte2.91.

Yes. I bisected the buggy behavior to this commit in the upstream vte
repository:

commit 3696348c0b9c7d60caf7302411ec4c0298f56e57
Author: Christian Persch 
Date:   Fri Dec 4 20:10:04 2015 +0100

widget: Rework get_text()

Ignore the passed VteSelectionFunc callback and just always use
the whole passed range.

:04 04 8b7beb4d621909eb20522625d724d50edbc422ae 
6bdd1bf89bdef0f0b41412340395df6941f94275 M  src

-- 
Robert Edmonds
edmo...@debian.org

Bug#821847: [Pkg-dns-devel] Bug#821847: dnsval: FTBFS on kFreeBSD: undefined reference to `getprogname'

[Ondřej Surý]

Aw, crap. The upstream use of autotools is quite creative, so it's
probably some underlinking. I'll look into that tomorrow (could you
please remind me if you don't hear from me withing a week? thanks)

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

On Tue, Apr 19, 2016, at 22:14, Aaron M. Ucko wrote:
> Source: dnsval
> Version: 2.2-2
> Severity: important
> Justification: fails to build from source (but built successfully in the
> past)
> 
> Thanks for taking care of #821746 promptly!  Alas, another error
> turned up:
> 
>   ../libval/.libs/libval-threads.so: undefined reference to `getprogname'
>   collect2: error: ld returned 1 exit status
>   Makefile:131: recipe for target 'dt-validate' failed
> 
> Could you please look into it as well?
> 
> Thanks!
> 
> ___
> pkg-dns-devel mailing list
> pkg-dns-de...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-dns-devel

Bug#821815: Pending fixes for bugs in the rkt package

[pkg-go-maintainers]

tag 821815 + pending
thanks

Some bugs in the rkt package are closed in revision
00bc1fefdfd0035b83437a2ca979761f9b0a96c7 in branch 'master' by Dmitry
Smirnov

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/rkt.git/commit/?id=00bc1fe

Commit message:

Do not leave cron job behind after package removal (Closes: #821815).

 Thanks, Andreas Beckmann.

Bug#821424: pulseaudio: Do not put normal users on group audio

[Ben Hutchings]

On Tue, 2016-04-19 at 06:07 +0200, Christian PERRIER wrote:
> 
> 
> Control: reassign -1 user-setup
> 
> Quoting Felipe Sateler (fsate...@debian.org):
> > 
> > 
> > 
> > Control: reassign -1 debian-installer
> > 
> > On 18 April 2016 at 13:06, Corcodel Marian 
> > wrote:
> > 
> > > 
> > > 
> > > 
> > > Any way pulseaudio is default sound server on debian and suggest
> > > to do not put
> > > users on audio group because cross interference with alsa
> > > programs, now alsa is
> > > for power users and pulseaudio is on default.
> > Pulseaudio does not add the user to the audio group. I'm guessing
> > the
> > installer does, so I reassign there.
> Adding the *first created* user to so-called "useful" groups is done
> by user-setup.
> 
> We'll need a detaailed explanantion abou twhy this shouldn't be done
> anymore, including all possible use cases of the installer.

I don't know where you get this 'all possible use cases of the
installer' from.  Adding the first user to device access groups only
ever made sense for single-user desktop/mobile systems.  The installer
doesn't make device access work automagically for other local users of
multi-user desktop/mobile systems, nor does it do the right thing for
servers - where the first user is likely to be a remote admin (and
often one of a team of admins who shuld have the same privileges).

systemd installs udev rules (/lib/udev/rules.d/70-uaccess.rules) that
add the 'uaccess' tag to many kinds of devices.  systemd-logind then
adds locally logged-in users to the ACLs for the corresponding device
nodes.  This makes all or most of the groups for local device access
redundant.

I've done a quick test of removing myself from the device access groups
on a current GNOME desktop, with these results:

- audio:      redundant, I'm on the ACL for /dev/snd/*
- cdrom:      redundant, I'm on the ACL for /dev/sr0
- floppy:     unknown, but expect this to work like cdrom
- video:      redundant, I'm on the ACL for /dev/video0
- plugdev:    redundant, I'm on the ACL for /dev/bus/usb/002/006
- netdev:     redundant, I'm on the ACL for /dev/rfkill
- scanner:    redundant, I'm on the ACL for /dev/sg2
- bluetooth:  unknown, seems broken whether or not I'm a member of the group

The other groups (dip, debian-tor, lpadmin, sudo) make more sense,
though CUPS should probably be changed to treat sudo like lpadmin.

Ben.

-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
  - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'


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

Bug#821848: perl: Regexp-matching "hangs" indefinitely on illegal input using binmode :utf8 using 100%CPU

[Alexandros Kosiaris]

Package: perl
Version: 5.20.2-3+deb8u4
Severity: normal
Tags: upstream patch

Dear Maintainer,

There is a bug in Perl 5.8.9 (at least) that causes regular
expressions an malformed UTF8 inputs to go into a forever loop and
consume 100% CPU. Upstream's tracker url is
https://rt.perl.org/Public/Bug/Display.html?id=123562. Patch is at
http://perl5.git.perl.org/perl.git/commitdiff/22b433eff9a1ffa2454e18405a56650f07b385b5
and attached is a version rebased for Debian Jessie. I have not
confirmed it, but based on the versions numbers I believe Stretch and Sid are 
also affected.

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

Kernel: Linux 4.4.0-0.bpo.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 perl depends on:
ii  dpkg  1.17.26
ii  libbz2-1.01.0.6-7+b3
ii  libc6 2.19-18+deb8u4
ii  libdb5.3  5.3.28-9
ii  libgdbm3  1.8.3-13.1
ii  perl-base 5.20.2-3+deb8u4
ii  perl-modules  5.20.2-3+deb8u4
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages perl recommends:
ii  netbase  5.3
pn  rename   

Versions of packages perl suggests:
pn  libterm-readline-gnu-perl | libterm-readline-perl-perl  
ii  make4.0-8.1
ii  perl-doc5.20.2-3+deb8u4

-- no debconf information
Index: perl-5.20.2/regexec.c
===
--- perl-5.20.2.orig/regexec.c
+++ perl-5.20.2/regexec.c
@@ -7830,6 +7830,10 @@ S_reghop3(U8 *s, SSize_t off, const U8*
 if (UTF8_IS_CONTINUED(*s)) {
 while (s > lim && UTF8_IS_CONTINUATION(*s))
 s--;
+if (! UTF8_IS_START(*s)) {
+dTHX;
+Perl_croak(aTHX_ "Malformed UTF-8 character (fatal)");
+}
 	}
 /* XXX could check well-formedness here */
 	}
@@ -7856,6 +7860,10 @@ S_reghop4(U8 *s, SSize_t off, const U8*
 if (UTF8_IS_CONTINUED(*s)) {
 while (s > llim && UTF8_IS_CONTINUATION(*s))
 s--;
+if (! UTF8_IS_START(*s)) {
+dTHX;
+Perl_croak(aTHX_ "Malformed UTF-8 character (fatal)");
+}
 }
 /* XXX could check well-formedness here */
 }
@@ -7887,6 +7895,10 @@ S_reghopmaybe3(U8* s, SSize_t off, const
 if (UTF8_IS_CONTINUED(*s)) {
 while (s > lim && UTF8_IS_CONTINUATION(*s))
 s--;
+if (! UTF8_IS_START(*s)) {
+dTHX;
+Perl_croak(aTHX_ "Malformed UTF-8 character (fatal)");
+}
 	}
 /* XXX could check well-formedness here */
 	}
Index: perl-5.20.2/t/re/pat.t
===
--- perl-5.20.2.orig/t/re/pat.t
+++ perl-5.20.2/t/re/pat.t
@@ -20,7 +20,7 @@ BEGIN {
 require './test.pl';
 }
 
-plan tests => 726;  # Update this when adding/deleting tests.
+plan tests => 727;  # Update this when adding/deleting tests.
 
 run_tests() unless caller;
 
@@ -1602,6 +1602,21 @@ EOP
 		ok(1, "did not crash");
 		ok($match, "[bbb...] resolved as character class, not subscript");
 	}
+{   # Test that we handle some malformed UTF-8 without looping [perl
+# #123562]
+
+my $code='
+BEGIN{require q(test.pl);}
+use Encode qw(_utf8_on);
+my $malformed = "a\x80\n";
+_utf8_on($malformed);
+watchdog(3);
+$malformed =~ /(\n\r|\r)$/;
+print q(No infinite loop here!);
+';
+fresh_perl_like($code, qr/Malformed UTF-8 character/, {},
+"test that we handle some UTF-8 malformations without looping" );
+}
 } # End of sub run_tests
 
 1;

Bug#821270: Review of firefox-branding-iceweasel

[Sean Whitton]

Hello,

On Tue, Apr 19, 2016 at 02:51:35PM +, nord-stream wrote:
> I thought of creating packages named firefox-branding-iceweasel,
> thunderbird-branding-icedove, etc. I am aware of the naming convention,
> but these extensions are not much like extensions but just branding
> packages. (In fact it Provides: xul-ext-iceweasel-branding.)
> Is that naming mandatory? I also found many of xul-ext-* packages do not
> include a single XUL file. (Neither does firefox-branding-iceweasel.)
> More discussion at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006#145

Yes, it should definitely be xul-ext-iceweasel-branding -- that's
pkg-mozext policy for anything that appears in about:addons.  dh_xul-ext
assumes that your package is called xul-ext-foo, and it will generate a
Provides: entry for firefox-foo.

> > - don't install the MPL-* files using debian/docs.  Instead, include
> > the full license text in debian/copyright.
> 
> firefox-esr package seems to do this. Do you mean that it is not
> appropriate for a branding package?

I'm pretty sure that firefox-esr is wrong to do that.  Policy 12.5 says:

"Every package must be accompanied by a verbatim copy of its copyright
information and distribution license in the file
/usr/share/doc/package/copyright."

It then makes an *exception* to this verbatim rule:

"Packages distributed under the Apache license (version 2.0), the
Artistic license, the GNU GPL (versions 1, 2, or 3), the GNU LGPL
(versions 2, 2.1, or 3), and the GNU FDL (versions 1.2 or 1.3) should
refer to the corresponding files under /usr/share/common-licenses,
rather than quoting them in the copyright file."

Since you are not using /usr/share/common-licenses, your package doesn't
fall under this exception and so you need to include it in your
d/copyright file.

Further the machine-readacble copyright specification says "... this
field should either include the full text of the license(s) or include a
pointer to the license file under /usr/share/common-licenses."

> > - on my machine, the package doesn't change the application icon --
> >   see the top of the attached screenshot.  Maybe you can't fix that,
> >   though.
> 
> Not possible with an extension. Doable with a .desktop file, I think.

How about adding a new file /usr/share/applications/iceweasel.desktop
that launches firefox with the old icon?  This would make this extension
conflict with iceweasel, but I think that would be okay so long as you
added a Conflicts: line in d/control.

> The complex part of Makefile is from Iceweasel package. Although most
> extensions' Makefiles just pack files into .xpi, it generates files from
> source files. This tiny override just saved me of hours of studying more
> about customizing dh_xul-ext.

Indeed: most of your Makefile complexity is unavoidable.

However, some reasons why it would be good if you avoided the override:

- it makes it easier for team members working on dh_xul-ext to know
  whether some change they are working on will break this package; and

- more generally, it makes it easier for team members to work on your
  package if files have the standard layout (that's the point of team
  maintenance).

It's not just about a short debian/rules: it makes your package more
standardised overall which is a good thing for your project :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#821260: RFS: python-adventure/1.4-1 [ITP], Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Markus Koschany]

Hello Ben,

thanks for your update. There are only a few things left before we can
upload the package. My main concern is the adventure-common binary
package because I don't believe that shipping advent.dat with an extra
package is very useful at the moment. As a compromise I offer you help
in resolving future issues with possibly other adventure variants in
Debian. However I expect that they will a) just ship the file with their
own package and b) it is rather unlikely that we will see another
implementation of the original adventure game in Debian. I think it is
cool to have a modern Python3 version but it would be rather boring to
have identical versions that simply reuse the same story from advent.dat.

Please fix

colossal-cave-adventure.desktop: (found with desktop-file-validate)

colossal-cave-adventure.desktop: error: (will be fatal in the future):
value "colossal-cave-adventure.png" for key "Icon" in group "Desktop
Entry" is an icon name with an extension, but there should be no
extension as described in the Icon Theme Specification if the value is
not an absolute path

Please change the Vcs fields from:

Vcs-Git:
https://anonscm.debian.org/git/collab-maint/pkg-python-adventure.git

Vcs-Browser:
https://anonscm.debian.org/git/collab-maint/pkg-python-adventure.git

to

Vcs-Git: https://anonscm.debian.org/git/collab-maint/python-adventure.git
Vcs-Browser:
https://anonscm.debian.org/cgit/collab-maint/python-adventure.git

so that the name of the git repository is identical to the source
package name and that we use cgit for better performance. Please push
the package to collab-maint next time and I will work and upload from there.

Last but not least:

There is a authoritative list of virtual package names (yeah,
bureaucracy in Debian is wonderful)

https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

Please follow the procedure outlined in this text file and post to
debian-devel and CC this RFS bug report. Personally I have no objections
against using the adventure name but it is polite to inform fellow DDs too.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#821350: dh-golang: generates rubbish in Built-Using; errors on invocation

[Michael Stapelberg]

Dmitry, please let us know if the patch works for you and I’ll be happy to
upload it.

On Tue, Apr 19, 2016 at 2:02 AM, Michael Hudson-Doyle <
michael.hud...@canonical.com> wrote:

> The attached should fix this. I get this for rkt's Built-Using now:
>
>  Built-Using: docker-registry (= 2.3.1~ds1-1), golang (= 2:1.6.1-2),
> golang-context (= 0.0~git20140604.1.14f550f-1), golang-github-appc-cni
> (= 0.2.0~rc0+dfsg-1), golang-github-appc-docker2aci (= 0.9.3+dfsg-1),
> golang-github-appc-spec (= 0.7.4+dfsg-1),
> golang-github-coreos-go-systemd (= 5-1),
> golang-github-coreos-ioprogress (= 0.0~git20151023.0.4637e49-1),
> golang-github-cznic-b (= 0.0~git20151027.0.01b13d7-1),
> golang-github-cznic-bufs (= 0.0~git20140818.0.3dcccbd-1),
> golang-github-cznic-fileutil (= 0.0~git20150708.0.1c9c88f-1),
> golang-github-cznic-mathutil (= 0.0~git20150605.0.a804f0f-1),
> golang-github-cznic-ql (= 1.0.2-1), golang-github-cznic-sortutil (=
> 0.0~git20150617.0.4c73428-1), golang-github-cznic-strutil (=
> 0.0~git20150430.0.1eb03e3-1), golang-github-cznic-zappy (=
> 0.0~git20160305.0.4f5e6ef-1), golang-github-dustin-go-humanize (=
> 0.0~git20151125.0.8929fe9-1), golang-github-google-btree (=
> 0.0~git20150413.0.cc6329d-1), golang-github-gorilla-mux (=
> 0.0~git20150814.0.f7b6aaa-1), golang-github-hashicorp-errwrap (=
> 0.0~git20141028.0.7554cd9-1), golang-github-pborman-uuid (=
> 0.0+git20150824.0.cccd189-1), golang-github-peterbourgon-diskv (=
> 2.0.0-1), golang-github-spf13-cobra (= 0.0~git20160117.0.8e91712-1),
> golang-github-spf13-pflag (= 0.0~git20151218.0.7f60f83-2),
> golang-go-semver (= 0.0~git20150304-1), golang-go.crypto (=
> 1:0.0~git20151201.0.7b85b09-2), golang-gocapability-dev (=
> 0.0~git20150506.1.66ef2aa-1), golang-golang-x-net-dev (=
> 1:0.0+git20160110.4fd4a9f-1), golang-google-grpc (=
> 0.0~git20151002.0.3e7b7e5-1), golang-goprotobuf (= 0.0~git20160330-1),
> golang-speter-go-exp-math-dec-inf (= 0.0~git20140417.0.42ca6cd-2)
>
> which looks at least plausible.
>
> On 19 April 2016 at 10:28, Dmitry Smirnov  wrote:
> > On Tuesday, 19 April 2016 10:19:56 AM AEST Michael Hudson-Doyle wrote:
> >> Wow, I'm not sure that package gets much from using dh-golang at all?
> >> But I think the problem is the " --builddirectory=_build" in the
> >> default target, somehow that needs to get funnelled into the right
> >> place. Will have a look.
> >
> > Thanks. We actually have many Golang packages with
> "--builddirectory=_build"
> > so fixing that is very important.
>
> Are there any other packages you think would be particularly good to
> try to build?
>
> Cheers,
> mwh
>



-- 
Best regards,
Michael

Bug#821835: jessie-pu: package libcrypto++/5.6.1-6+deb8u2

[GCS]

On Tue, Apr 19, 2016 at 9:27 PM, Adam D. Barratt
 wrote:
> Control: tags -1 + confirmed
>
> On Tue, 2016-04-19 at 19:19 +0200, László Böszörményi wrote:
>> There's a vulnerability in Crypto++, the C++ class library of
>> cryptographic schemes.
[...]
> Please go ahead.
 Just uploaded the package.

Regards,
Laszlo/GCS

Bug#821766: gle-graphics: FTBFS on hurd-i386, but previously did

[Tobias Frost]

This could be caused by #778462 

--
tobi

Bug#745412: evince-gtk: selected text is a solid black box, renders text unreadable

[Tim Wiederhake]

A-Ha!

The problem seems to be connected to the Raleigh theme (xfce default?),
as with Adwaita text selection is indeed white on blue ground. Funny
that this problem only occurs with evince, text selection in any other
program (qt5 / gtk) works fine.

Regards,
Tim

Am Tue, 19 Apr 2016 14:57:19 -0500 schrieb Jason Crain
:

> On Tue, Apr 19, 2016 at 07:19:07PM +0200, Tim Wiederhake wrote:
> > Installed gnome-themes-standard now (and rebooted, fwiw) to no
> > effect.
> > 
> > I hesitate to install gnome-tweak-tool, since I'm using xfce and
> > gnome-tweak-tool pulls in a lot of dependencies. Is there a cli way
> > to set the theme?  
> 
> It's interesting that it happens under Xfce.  I might have to make a
> fresh install in a virtual machine to try it.  I think under Xfce you
> can change the theme through the applications menu > Settings >
> Appearance.  What style do you have selected there?  Does it work if
> you change it to Adwaita?

Bug#821847: dnsval: FTBFS on kFreeBSD: undefined reference to `getprogname'

[Aaron M. Ucko]

Source: dnsval
Version: 2.2-2
Severity: important
Justification: fails to build from source (but built successfully in the past)

Thanks for taking care of #821746 promptly!  Alas, another error
turned up:

  ../libval/.libs/libval-threads.so: undefined reference to `getprogname'
  collect2: error: ld returned 1 exit status
  Makefile:131: recipe for target 'dt-validate' failed

Could you please look into it as well?

Thanks!

Bug#618445: apt: Please downgrade "There is no public key available ..." to a notice

[Daniel Kahn Gillmor]

On Tue 2011-03-15 04:03:42 -0400, Uwe Kleine-König wrote:
> I'm about to change the gpg key used to sign our apt and so signed the
> archive for now with two keys and will update the keyring package to
> contain the new key soon.
>
> The "problem" I'm faced with now is that if apt only knows one of the
> two keys used it prints a warning
>
>   W: There is no public key available for the following key IDs:
>   ...

I agree that this warning is problematic.  For most users who haven't
thought about the issue, they'll take it as a problem that needs fixing,
even when their system can already validate the particular files that
they're trying to validate.  As a result, they might try to track down
and add an additional key to their apt keyring.

A system that depends on a signature from any one of N+1 keys is by
definition more vulnerable than a system that depends on a signature
from any one of N keys, so this warning is actively encouraging debian
system administrators to enlarge their attack surface.

Consider a rogue mirror that redistributes the debian archive, but can
add an additional OpenPGP signature in InRelease or Releases.gpg.

If the mirror operator wanted to, they could mint a new OpenPGP
certificate with a user ID like "Debian Archive Automatic Signing Key
(8.0/jessie) ", and add that signature's keys to
the InRelease file.

This would be a legitimate debian archive, with an extra signature
attached, but it would produce the above warnings.

Any local admin who tries to "fix" the warning by importing that key
will now be vulnerable to future attack by that mirror operator.

A sensible admin who regularly prunes their apt-key list (e.g. removing
the wheezy keys on systems that are well past wheezy) will find
themselves incurring additional warnings.

These warnings are actively bad for the security of debian systems, and
should be muted entirely as long as the package lists successfully
validate.  If some download doesn't validate at all, then this
information should be supplied, but as an error, not as a warning.

 --dkg

Bug#821834: wheezy-pu: package libcrypto++/5.6.1-6+deb7u2

[GCS]

On Tue, Apr 19, 2016 at 9:27 PM, Adam D. Barratt
 wrote:
> Control: tags -1 + confirmed
>
> On Tue, 2016-04-19 at 19:19 +0200, László Böszörményi wrote:
>> There's a vulnerability in Crypto++, the C++ class library of
>> cryptographic schemes.
[...]
> Please go ahead.
 Thanks, just uploaded.

Cheers,
Laszlo/GCS

Bug#820708: [Pkg-pascal-devel] Bug#820708: Bug#820708: Bug#820708: castle-game-engine: hardcoded libpng12 dependency

[Michalis Kamburelis]

  

  

  

> Packages build with CGE that NEED png  
support are soon broken in testing (the moment libpng12 is removed)  
without a way to be fixed. And fixing this bug is not enough, those  
packages need to be rebuild as well.

  

Ah, indeed, you will need to recompile and release new view3dscene binary
version. In general, every package depending on CGE needs to be recompiled in
such cases (for now, it's only view3dscene?). Even though the source code
changed only in CGE.

I see your point.  

That's how static linking works, this reasoning applies to every change in
FreePascal standard library or CGE or any other library that is traditionally
"statically compiled" in Debian. It seems like the "Build-Using" you mention
is the way to declare this.

Regards,

Michalis