date:20161213

> On Tue, Nov 08, 2016 at 06:23:00PM +, Thiago Franco Moraes wrote:
> > Hi Andreas,
> > 
> > We are now working in a new InVesalius version. This commit to the debian
> > package is just to adapt to the new (3.1, unstable yet) invesalius version.
> > I was only antecipating the changes to make the package to version we are
> > going to release soon. Sorry if I behave incorrectly.

BTW, do you intend to fix

   https://bugs.debian.org/779655

in the new version?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#847681: packaging repository and sid diverging? Various fixes needed.

2016-12-13 Thread Andreas Henriksson

On Wed, Dec 14, 2016 at 08:11:52AM +0100, Daniel Pocock wrote:
> 
> 
> On 13/12/16 22:46, Andreas Henriksson wrote:
> > On Tue, Dec 13, 2016 at 08:55:34PM +0100, Daniel Pocock wrote:
> >> Hi Ben,
> >>
> >> Thanks for providing this feedback
> >>
> >> I've done the following:
> >> - forked the upstream repository
> >> - created a debian/sid branch
> >> - copied debian/* from jessie into that branch and committed
> >> - copied debian/* from sid into that branch and committed
> > [...]
> > 
> > Haven't checked the actual repo, but this sounds horrible to me.
> > 
> 
> It is not universally bad

I don't want to create additional burdens for you making progress here,
just thought I could suggest alternative approaches that I would personally
use instead.

> 
> The benefit is that it makes it easier for integrating with upstream
> work and quickly testing code that upstream hasn't tagged or released, e.g.
> 
> 
> git checkout master (upstream's master)
> git pull(get latest unreleased stuff)

Well, after following one of my previously suggested methods then you
could just rename the branches (and set up new tracking)
and you can still do it like you're describing.

> 
> git checkout -b debian/test-latest-2016-12-14 debian/sid
> git merge master
> vi debian/changelog
> git add debian/changelog && git commit -m 'Test build 2016-12-14'
> 
> dpkg-buildpackage -rfakeroot -i.* -b -us -uc
> 
> 
> When I am working in my own projects where I am upstream I find it very
> convenient to be able to rapidly build and test packages like that
> before tagging my upstream releases.  My goal there is to ensure every
> release tarball can work on Debian without patching.
> 
> I agree the loss of Debian packaging history is a concern, that is one
> reason I didn't clobber the existing repository and I wrote that we can
> blow this away if there isn't consensus about it.

Yeah, but ever more importantly now is to not get stuck on details I guess.

Regards,
Andreas Henriksson

Bug#847305: Bug#847050: ITP: gnome-shell-extension-log-out-button -- A GNOME Extension to add a log out button to the system activities menu

2016-12-13 Thread Kyle Robbertze



On 14/12/2016 09:05, Tobias Frost wrote:
> Am Dienstag, den 13.12.2016, 08:16 +0200 schrieb Kyle Robbertze:
>>>
>>> two more points to be fixed:
>>>
>>> - you do not write "rm -f " in d/clean, just filenames/paths.
>>> See
>>> dh_clean(1)
>>>
>>> - metadata.json still says 3.22.2
>>>
>>
>> Both are now fixed
>>
>> Cheers
>> Kyle
>>
> 
> Uploaded. Thanks for your contributions.
> The file is now in the NEW queue -- please manually remove it from
> mentors.
> 
Thanks a lot. Will do



signature.asc
Description: OpenPGP digital signature

Bug#847681: packaging repository and sid diverging? Various fixes needed.

2016-12-13 Thread Andreas Henriksson

Hello Raphaël Halimi,

Congrats on completely derailing a thread that for once was about
proper mainenance and solving a bigger problem into becoming
about your pet peeve. Please feel free to stop CCing me if you
don't actually want my feedback.

On Tue, Dec 13, 2016 at 11:01:19PM +0100, Raphaël Halimi wrote:
> Wontfix ? Really ? Are you that much intent on killing sysvinit ?

Unless by "killing sysvinit" you mean "use it as intended", then no.

> 
> Last time I checked, the Policy still required alternative init systems
> to be supported by package maintainers.

I wonder which policy you're reading then. Fwiw, I recently posted
patches to policy to make it sysvinit compatible, but maybe we
should go the other way around and cite the current very outdated
policy as a reason for sysvinit removal instead?

> Since it's so easy to override
> these settings with systemd (I'm not ironical here, I really don't know
> how it's done), what harm would this patch do if it was applied to
> satisfy sysvinit users ?

If you think it's about making it easy to do it in multiple separate
ways, then you don't understand the problem. You want exactly
*one* way to do it that's supported by all, so we can continue
keeping that one way working and avoid incompatible upgrades.
You know Debian cares alot about integration and easy upgrades, right?

> 
> They would have at last the possibility of modifying rpcnfsdopts through
> /etc/default/nfs-kernel-server, and thus reliably disable nfsv4, and
> systemd users could still do the same through whatever facility systemd
> provides and that I'm not aware of.

You already have this option. These files are conffiles. Please read
up on what that means (in policy for example).

Maybe also think a bit about why making incompatible changes to
conffiles and shipping new versions of them in a package is something
you want to avoid as a maintainer, and why a user don't want a
maintainer to do that either.

Regards,
Andreas Henriksson

Bug#833997: atop: process accounting does not work

2016-12-13 Thread Marc Haber

On Tue, Dec 13, 2016 at 03:50:31PM +0100, Martin Steigerwald wrote:
> I see. Marc, IMHO this issue should not hold back uploading new atop to 
> Debian 
> unstable for inclusion into next Debian version. What do you think?

Agreed. I will document this in NEWS.Debian and would like to include
kernel bugzilla and kernel mailig lists references.

Gerlof, do you want to do a new official release of atop to package?
The atoptool.nl web page still has the version from June 2016.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#846583: cloud.debian.org: AWS Image should enable DHCPv6 client

2016-12-13 Thread Thomas Lange

I wonder why you need to source /usr/lib/fai/subroutines for importing
the ifclass subroutine. If your scripts are bash scripts, this
function should be already available.

-- 
regards Thomas

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

2016-12-13 Thread Gianfranco Costamagna


>So while I'm not sure it will help, there might be benefit to try to get a
>stack trace from DOMCount.  It's possible there's an exception being
>thrown but it's getting caught/squashed.  If someone wants to try to get
>a stack trace, the command will be
>
>libtool --mode=execute gdb --args samples/DOMCount samples/data/personal.xml
>
>and the steps inside of gdb will be the same as before.



http://paste.debian.net/902113/

G.

Bug#845753: Treescape fails to build on i386 and armhf architecture

Hi Thibaut,

thanks for your attempt to help in this issue.

On Fri, Dec 09, 2016 at 02:04:16PM +, Thibaut Jombart wrote:
> Sorry I cannot be more help on this. But if it is a RGL problem on i386, I
> suspect it should occur with other packages too..

I can confirm that the issue is not caused by an RGL problem.  I was able
to do a proper RGL configuration which does not show the Warning any more
but the crash persists. :-(

> Let me know if I can help further, and thanks for looking into this!

Here is a recent build log on i386:

https://buildd.debian.org/status/fetch.php?pkg=r-cran-treescape&arch=i386&ver=1.10.18-2&stamp=1481697760

which ends in

** data
*** moving datasets to lazyload DB
** inst
** preparing package for lazy loading
Creating a generic function for 'toJSON' from package 'jsonlite' in package 
'googleVis'
Error: segfault from C stack overflow

Do you have any further idea?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#847681: packaging repository and sid diverging? Various fixes needed.

2016-12-13 Thread Daniel Pocock

On 13/12/16 22:46, Andreas Henriksson wrote:
> On Tue, Dec 13, 2016 at 08:55:34PM +0100, Daniel Pocock wrote:
>> Hi Ben,
>>
>> Thanks for providing this feedback
>>
>> I've done the following:
>> - forked the upstream repository
>> - created a debian/sid branch
>> - copied debian/* from jessie into that branch and committed
>> - copied debian/* from sid into that branch and committed
> [...]
> 
> Haven't checked the actual repo, but this sounds horrible to me.
> 

It is not universally bad

The benefit is that it makes it easier for integrating with upstream
work and quickly testing code that upstream hasn't tagged or released, e.g.

git checkout master (upstream's master)
git pull(get latest unreleased stuff)

git checkout -b debian/test-latest-2016-12-14 debian/sid
git merge master
vi debian/changelog
git add debian/changelog && git commit -m 'Test build 2016-12-14'

dpkg-buildpackage -rfakeroot -i.* -b -us -uc

When I am working in my own projects where I am upstream I find it very
convenient to be able to rapidly build and test packages like that
before tagging my upstream releases.  My goal there is to ensure every
release tarball can work on Debian without patching.

I agree the loss of Debian packaging history is a concern, that is one
reason I didn't clobber the existing repository and I wrote that we can
blow this away if there isn't consensus about it.

Regards,

Daniel

Bug#848103: ibm-3270: copyright file does not include reasons for being in non-free (Policy 12.5)

2016-12-13 Thread Paul Wise

Source: ibm-3270
Severity: normal

According to Debian Policy section 2.5:

https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile

> Packages in the contrib or non-free archive areas should state in the
> copyright file that the package is not part of the Debian
> distribution and briefly explain why.

As far as I can tell the ibm-3270 copyright file doesn't state that parts
of it are non-free, which parts are non-free and why they are non-free.

http://metadata.ftp-master.debian.org/changelogs/non-free/i/ibm-3270/unstable_copyright

Also, I can't find anything non-free in the licenses, should this
package move from non-free to main?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#845753: Help: r-cran-treescape does not build on i386, armel and armhf any more

Hi Christian,

On Wed, Dec 14, 2016 at 12:32:24AM +0100, Christian Seiler wrote:
> On 11/02/2016 05:20 PM, Andreas Tille wrote:
> 
> Hmm, was going to take a shot at debugging your segfault, but I
> simply can't reproduce this:
> ...
> architectures.

Unfortunately autobuilders keep on reproducing it. :-(

> I can provide full build logs if you need them.
> 
> Maybe ask for a give-back at debian-wb-t...@lists.debian.org to
> have the i386 and armhf buildds try the build again? As far as
> I can tell the build should succeed...
> 
> Notable differences between buildd chroot and my freshly created
> one (in the i386 case):
> 
>  buildd:gcc 6.2.1-5, binutils 2.27.51.20161201-1
>  my system: gcc 6.2.1-6, binutils 2.27.51.20161212-1
> 
> Maybe this was a toolchain bug that was fixed recently? If so,
> maybe wait a couple of days (buildd chroots are updated twice
> a week IIRC) and then ask for a give-back.

I have uploaded a package where I fixed the xvfb issue and did a source
only upload to make sure also amd64 will be autobuilt.  While amd64 is
fine (also regarding the xserver issue - thanks to Gregor for the hints)
the i386 build log[1] shows the

** inst
** preparing package for lazy loading
Creating a generic function for 'toJSON' from package 'jsonlite' in package 
'googleVis'
Error: segfault from C stack overflow
* removing 
'/«PKGBUILDDIR»/debian/r-cran-treescape/usr/lib/R/site-library/treescape'

again even if the log also has gcc-6-base i386 6.2.1-6  and binutils
i386 2.27.51.20161212-1 - so the toolchain on autobuilder is the same as
it worked for you.  There might be a difference between a qemu emulation
and real hardware, thought.

Kind regards and thanks for checking anyway

 Andreas.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=r-cran-treescape&arch=i386&ver=1.10.18-2&stamp=1481697760

-- 
http://fam-tille.de

Bug#700082: AllowFilter and sftp does not work

2016-12-13 Thread Mathieu Malaterre

fixed 1.3.5b-1
thanks

On Tue, Dec 13, 2016 at 8:26 PM, Hilmar Preusse  wrote:
> On 08.02.13 Mathieu Malaterre (ma...@debian.org) wrote:
>
> Hi,
>
>> AllowFilter does not work with SFTP, see:
>>
>> https://forums.proftpd.org/smf/index.php/topic,11256.0.html
>>
>> Curently affect 1.3.4 and 1.3.5rc, see:
>>
>> https://forums.proftpd.org/smf/index.php/topic,11256.msg30722.html#msg30722
>>
> This is an old issue and the github trakker states that the fix has
> been merged into the master branch. Hence I'd expect that the fix is
> in 1.3.5b (uploaded yesterday) and the latest rc.
>
> Could you check if the problem is fixed current packets?

I confirm this is fixed in sid. Thanks !

Bug#847305: Bug#847050: ITP: gnome-shell-extension-log-out-button -- A GNOME Extension to add a log out button to the system activities menu

2016-12-13 Thread Tobias Frost

Am Dienstag, den 13.12.2016, 08:16 +0200 schrieb Kyle Robbertze:
> > 
> > two more points to be fixed:
> > 
> > - you do not write "rm -f " in d/clean, just filenames/paths.
> > See
> > dh_clean(1)
> > 
> > - metadata.json still says 3.22.2
> > 
> 
> Both are now fixed
> 
> Cheers
> Kyle
> 

Uploaded. Thanks for your contributions.
The file is now in the NEW queue -- please manually remove it from
mentors.

-- 
tobi

Bug#846583: cloud.debian.org: AWS Image should enable DHCPv6 client

2016-12-13 Thread Noah Meyerhans

On Sat, Dec 10, 2016 at 08:57:22PM +0100, Bernhard Schmidt wrote:
> I don't think this will ever be fixed with ifupdown. I think
> systemd-networkd and NetworkManager do the right thing here, but I have
> never had a look at either for maintaining a _server_. So I will not
> propose switching to those.

I've put together a workaround for ifupdown that does the right thing
for both dual-stack and ipv4-only instances:

https://anonscm.debian.org/cgit/cloud/fai-cloud-images.git/commit/?h=dhcpv6&id=ff79069df0eb08634f52a355e5c578c10532479c

This change isn't merged into the master branch in the fai-cloud-images
repo, and I'd like others on the cloud team to review it and see if
there's anything I'm missing or that could be improved. Of course, it
should go without saying that such a hack is unfortunate, and it'd be
preferable if ifupdown did the right thing, but as you say, it probably
never will.

Something similar should work for the jessie images, but I'm not
familiar with how they're generated. jessie doesn't have
/lib/ifupdown/wait-for-ll6.sh, so that functionality may need to be
incorporated into a helper script similar to the one in my branch.

The key is that /etc/network/interfaces is populated with entries of the
form:

iface eth0 inet dhcp
iface eth0 inet6 manual
up /usr/local/sbin/inet6-ifup-helper
down /usr/local/sbin/inet6-ifup-helper

The inet6-ifup-helper takes care of starting and stopping dhclient -6 on
the appropriate interfaces. It should only exit 0, so it shouldn't
interfere with ifupdown's operation.

I've tested this configuration on the primary interface and on secondary
interfaces on instances in both dual-stack and v4-only networks and it
works as expected.

I don't really like the idea of installing actual code on AMIs from the
fai-cloud-images repo, but I'm not really interested in packaging
inet6-ifup-helper either.

I've created public AMIs ami-290ca649 (us-west-2) and ami-95a7fdf0
(us-east-2) based on these changes if anyone would like to perform
additional testing...

noah

signature.asc
Description: PGP signature

Bug#748959: r-cran-rcurl: Contains a ca-bundle

Hi,

I'm currently browsing long standing bugs in Debian Med team.  Could you
please clarify what files from r-cran-rcurl you mean and how to replace
them (symlinks to what?)

Sorry for the naive question

Andreas.

-- 
http://fam-tille.de

Bug#848102: [octave] crashed with some random typing in octave editor

2016-12-13 Thread lumin

Package: octave
Version: 4.2.0-1
Severity: normal

Hi,

Randomly typing something in octave editor will cause
a crash with SIGSEGV.

For example, I launched Octave and typed merely "asdfasdf"
and then octave crashed.

(gdb) run
Starting program: /usr/bin/octave 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Gtk-Message: Failed to load module "canberra-gtk-module"
octave exited with signal 11
[Inferior 1 (process 12389) exited normally]
(gdb)

Bug#848101: Package name + config.txt & cmdline.txt as conffiles

2016-12-13 Thread karl156

Package: raspi3-firmware
Version: 1.20161123-2
Severity: important
Tags: sid

Thanks for packaging the raspi firmware.

As this package basically only contains the blobs which are working on
all Raspberry Pis (1-3), wouldn't it be more appropriate to name this
package "raspi-firmware"? (And make it available on armhf too.)


Also config.txt & cmdline.txt should be treated as conffiles so that
changes the user has made (e.g. special hdmi parameters or codec
licenses) won't get overridden on every kernel update.

I would suggest to place them somewhere in /etc instead of
auto-generating them in the kernel postinst script and just copy them to
the firmware folder in the kernel postinst script.
If you copy the kernel, initramfs + dtb to fixed positions (like the
"/vmlinuz" & "/initrd.img" symlinks) in the kernel postinst script then
config.txt & cmdline.txt don't need to be touched on every update.
Another idea would be to only write them if they don't exist yet.

I've put these two issues together because without a customizable
config.txt the package indeed only works on a raspi3 because of the
"arm_control=0x200" & "device_tree=bcm2837-rpi-3-b.dtb" lines.

Severity set to important, cause all user changes to the config files
are lost on every update, rendering this package useless for many users.

Bug#822551: [octave] Octave crashes when user clicks plot figures

2016-12-13 Thread lumin

Hi,

I encountered the same problem with Octave several
months ago. However this problem was gone after
an apt upgrade. Now I cannot reproduce it with Octave 4.2.0-1.

Bug#829380: Orthanc 1.2.0

Hi Sébastien,

On Wed, Dec 14, 2016 at 06:49:20AM +0100, Sébastien Jodogne wrote:
> This issue is very low priority wrt. my TODO list for the upstream project.
> 
> Anyone is obviously welcome to help me and contribute by packaging this
> script into the orthanc Debian package.

Thanks for the clarification.  The new package is uploaded.  Please git
pull for a bumped debhelper compat level.

Kind regards

 Andreas.
 
> Le 14 déc. 2016 06:42, "Andreas Tille"  a écrit :
> 
> Do you plan to provide any upgrade script as it was asked for in
> 
>https://bugs.debian.org/829380

-- 
http://fam-tille.de

Bug#747185: Do the conflicting return types of function DejaVu_create exist in new upstream version?

Hi Michael,

I'm currently checking older bugs and stumbled upon this one.  I
currently can not find the said cruel mix of definitions is used for
ALPHABET_SIZE in the code base of 2.4.0.  Could you please recheck
and confirm whether this bug can be closed or explain in more detail
in how far different definitions are used?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#828069: icedove: random crashes after latest security update

2016-12-13 Thread Carsten Schoenert

Hi,

On Wed, Dec 14, 2016 at 10:00:52AM +1100, Jason Lewis wrote:
> I see the same behaviour Vladimir is seeing. for what its worth.
> 
> any tips for generating a gdb log?

I believe this information is written several times not only to this bug
report. The wiki page for Icedove in the Debian wiki has dedicated
instructions for this.

> Vladimir K wrote on 13/12/16 18:18:
> > I haven't observe the crash in upstream Thunderbird yet.
> > I seem to able to increase the probability of the crash by
> > vigourously browsing through mail in Icedove, caught it a few times.
> > But upstream Thunderbird is pretty stable with the same profile.

There main reason for this is also written here in this bug report, see
#message55

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828069#55

Debian is using GCC 4.9 for stable-security (GCC 4.8 on Wheezy LTS) and
GCC 6.2 in unstable/testing.

Mozilla is still using GCC 4.7.3 right now. So I believe most of the
problems are related due gcc is not going that lazy anymore than the old
gcc. There are several also known problematic things due the strictness
of new gcc versions by Mozilla. So in the end we can't do much about
that segfault issue for now.

Regards
Carsten

Bug#848100: neovim-qt: Please install as alternative for "gvim"

2016-12-13 Thread Ph. Marek

Package: neovim-qt
Version: 0.2.4-1
Severity: wishlist

Please install a gvim alternative:
# update-alternatives --install /usr/bin/gvim gvim /usr/bin/nvim-qt 50

Thank you very much!


BTW, the initial size of the nvim-qt window is ~9 by 4 characters for me... 
shouldn't nvim-qt have some more sane defaults?


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

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

Versions of packages neovim-qt depends on:
ii  libc6   2.24-7
ii  libgcc1 1:6.2.1-5
ii  libmsgpackc21.4.2-4
ii  libqt5core5a5.7.1~20161021+dfsg-6
ii  libqt5gui5  5.7.1~20161021+dfsg-6
ii  libqt5network5  5.7.1~20161021+dfsg-6
ii  libqt5widgets5  5.7.1~20161021+dfsg-6
ii  libstdc++6  6.2.1-5
ii  neovim  0.1.7-1

neovim-qt recommends no packages.

neovim-qt suggests no packages.

-- no debconf information

Bug#848099: some results are repeated

2016-12-13 Thread 積丹尼 Dan Jacobson

Package: dict-stardic
Version: 1.3.1-5
Severity: minor

$ dict nipple|grep -A 2 star
>From Stardic English-Chinese Dictionary [stardic]:

  n. 乳首,奶头,奶头;

Here 奶头 is repeated.

Bug#848097: terminal.app: Provides x-terminal-emulator, but doesn't implement the requirements

2016-12-13 Thread Ben Longbons

Package: terminal.app
Version: 0.9.8-1+nmu1+b2
Severity: serious
Justification: Policy 11.8.3

Dear Maintainer,

Quoting policy:

>To be an x-terminal-emulator, a program must:

> * Be able to emulate a DEC VT100 terminal, or a compatible terminal.

> * Support the command-line option -e command, which creates a new terminal 
> window[106] and runs the specified command, interpreting the entirety of the 
> rest of the command line as a command to pass straight to exec, in the manner 
> that xterm does.

> * Support the command-line option -T title, which creates a new terminal 
> window with the window title title.

/usr/bin/Terminal appears to not have *any*, options, not even `--help`.

Until (or unless) this is implemented, the `Provides:` header and the
update-alternatives logic must be removed.

-Ben


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

Kernel: Linux 4.7.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 terminal.app depends on:
ii  libc62.24-7
ii  libgnustep-base1.24  1.24.9-3
ii  libgnustep-gui0.25   0.25.0-4
ii  libobjc4 6.2.1-5

terminal.app recommends no packages.

terminal.app suggests no packages.

-- no debconf information

Bug#848098: Maybe don't print the () part if it is the same character

2016-12-13 Thread 積丹尼 Dan Jacobson

Package: unicode
Version: 2.4
Severity: wishlist

$ unicode  k K 奶| grep '(.)'
k (K)   #OK
K (k)   #OK
奶 (奶) #Yuck

Maybe don't print the () part if it is the same character.
That would be less distracting and not leaving us look for minor differences.

Bug#848096: guake: Provides x-terminal-emulator, but doesn't implement the requirements

2016-12-13 Thread Ben Longbons

Package: guake
Version: 0.8.7-1
Severity: serious
Justification: Policy 11.8.3

Dear Maintainer,

Quoting policy:

>To be an x-terminal-emulator, a program must:

> * Be able to emulate a DEC VT100 terminal, or a compatible terminal.

Guake does this one, at least.

> * Support the command-line option -e command, which creates a new terminal 
> window[106] and runs the specified command, interpreting the entirety of the 
> rest of the command line as a command to pass straight to exec, in the manner 
> that xterm does.

Guake implements this incorrectly - it uses the shell's -c option
rather than consuming the rest of the arguments.

This is the reason for gnome-terminal.wrapper, though the underlying
functionality will need to be implemented at all before a wrapper can be
written.

Also, it does not make the terminal visible, and behaves quite oddly
if run from outside an existing guake.

> * Support the command-line option -T title, which creates a new terminal 
> window with the window title title.

Guake does not implement this at all. The `-r` argument DTWT if already
within a guake terminal, doesn't make the terminal visible, and doesn't
block.


Since guake is a somewhat special-purpose terminal, the simplest solution is
to simply remove the `Provides:` header and the `update-alternatives` logic.
(This doesn't stop *users* from using guake primarily, of course).

If you *do* decide to implement the missing requirements, take care that
the caller blocks for the right duration in all cases: (if starting guake
for the first time; if guake was already running; if run from within guake).

-Ben


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

Kernel: Linux 4.7.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 guake depends on:
ii  gconf2  3.2.6-4
ii  libgtk2.0-0 2.24.31-1
ii  notification-daemon 3.20.0-1
ii  plasma-workspace [notification-daemon]  4:5.8.2-1
ii  python  2.7.11-2
ii  python-dbus 1.2.4-1
ii  python-gconf2.28.1+dfsg-1.2
ii  python-glade2   2.24.0-5.1
ii  python-keybinder0.3.1-1
ii  python-notify   0.1.1-4
ii  python-vte  1:0.28.2-5+b1
ii  python-xdg  0.25-4
ii  python2.7   2.7.12-7
pn  python:any  

guake recommends no packages.

guake suggests no packages.

-- no debconf information

Bug#848095: ITP: libcache-memcached-libmemcached-perl -- cache interface to Memcached::libmemcached

2016-12-13 Thread Christopher Hoskin

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

* Package name: libcache-memcached-libmemcached-perl
  Version : 0.04001
  Upstream Author : Daisuke Maki 
* URL : https://metacpan.org/release/Cache-Memcached-libmemcached
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : cache interface to Memcached::libmemcached

Cache::Memcached::libmemcached is the Cache::Memcached compatible interface to
libmemcached, a C library to interface with memcached.

Cache::Memcached::libmemcached is built on top of Memcached::libmemcached.
While Memcached::libmemcached aims to port libmemcached API to perl,
Cache::Memcached::libmemcached attempts to be API compatible with
Cache::Memcached, so it can be used as a drop-in replacement.

Cache::Memcached::libmemcached inherits from Memcached::libmemcached. While you
are free to use the Memcached::libmemcached specific methods directly on the
object, doing so will mean that your code is no longer compatible with the
original Cache::Memcached API therefore losing some of the portability in case
you want to replace it with some other package.

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

Bug#848065: python-cryptography: renders ansible unusable

2016-12-13 Thread Tristan Seligmann

Control: notfound -1 1.5.3-1

You have an installation of PyOpenSSL in
/home/pjs/.local/lib/python2.7/site-packages that is not compatible with
Cryptography 1.5.3; removing or upgrading this should solve your problem.

To avoid this kind of problem in future, I would recommend using virtualenv
rather than installing things to ~/.local, as packages in a virtualenv will
not interfere with the system Python like ~/.local / --user packages will.

On Tue, 13 Dec 2016 at 20:03 Paulo Silva  wrote:

> Package: python-cryptography
> Version: 1.5.3-1
> Severity: critical
> Justification: breaks unrelated software
>
> Upgrading python-cryptography from 1.5.2-1 to 1.5.3-1 renders ansible
> unusable:
>
> $ ansible-playbook -vvv playbook.yml
> ERROR! Unexpected Exception: 'module' object has no attribute 'SSL_ST_INIT'
> the full traceback was:
>
> Traceback (most recent call last):
>   File "/usr/bin/ansible-playbook", line 103, in 
> exit_code = cli.run()
>   File "/usr/lib/python2.7/dist-packages/ansible/cli/playbook.py", line
> 159, in run
> results = pbex.run()
>   File
> "/usr/lib/python2.7/dist-packages/ansible/executor/playbook_executor.py",
> line 89, in run
> self._tqm.load_callbacks()
>   File
> "/usr/lib/python2.7/dist-packages/ansible/executor/task_queue_manager.py",
> line 177, in load_callbacks
> for callback_plugin in callback_loader.all(class_only=True):
>   File "/usr/lib/python2.7/dist-packages/ansible/plugins/__init__.py",
> line 394, in all
> self._module_cache[path] = self._load_module_source(name, path)
>   File "/usr/lib/python2.7/dist-packages/ansible/plugins/__init__.py",
> line 324, in _load_module_source
> module = imp.load_source(name, path, module_file)
>   File
> "/usr/lib/python2.7/dist-packages/ansible/plugins/callback/hipchat.py",
> line 32, in 
> from ansible.module_utils.urls import open_url
>   File "/usr/lib/python2.7/dist-packages/ansible/module_utils/urls.py",
> line 150, in 
> from urllib3.contrib.pyopenssl import ssl_wrap_socket
>   File "/usr/lib/python2.7/dist-packages/urllib3/contrib/pyopenssl.py",
> line 47, in 
> import OpenSSL.SSL
>   File "/home/pjs/.local/lib/python2.7/site-packages/OpenSSL/__init__.py",
> line 8, in 
> from OpenSSL import rand, crypto, SSL
>   File "/home/pjs/.local/lib/python2.7/site-packages/OpenSSL/SSL.py", line
> 124, in 
> SSL_ST_INIT = _lib.SSL_ST_INIT
> AttributeError: 'module' object has no attribute 'SSL_ST_INIT'
>
> Downgrading to python-cryptography to 1.5.2-1 fixes the issue:
>
> $ sudo dpkg -i
> /var/cache/apt/archives/python-cryptography_1.5.2-1_amd64.deb
> dpkg: warning: downgrading python-cryptography from 1.5.3-1 to 1.5.2-1
> (Reading database ... 575660 files and directories currently installed.)
> Preparing to unpack .../python-cryptography_1.5.2-1_amd64.deb ...
> Unpacking python-cryptography (1.5.2-1) over (1.5.3-1) ...
> Setting up python-cryptography (1.5.2-1) ...
>
> $ ansible-playbook -vvv playbook.yml
> PLAYBOOK: playbook.yml
> *
> (...)
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500,
> 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages python-cryptography depends on:
> ii  libc62.24-8
> ii  libssl1.11.1.0c-2
> ii  python   2.7.11-2
> pn  python-cffi-backend-api-max  
> pn  python-cffi-backend-api-min  
> ii  python-enum341.1.6-1
> ii  python-idna  2.1-1
> ii  python-ipaddress 1.0.17-1
> ii  python-pyasn10.1.9-2
> ii  python-setuptools28.7.1-1
> ii  python-six   1.10.0-3
> pn  python:any   
>
> python-cryptography recommends no packages.
>
> Versions of packages python-cryptography suggests:
> pn  python-cryptography-doc  
> ii  python-cryptography-vectors  1.5.3-1
>
> -- no debconf information
>

Bug#848094: RFS: gap-toric/1.8+ds-1 [ITP] toric variety for GAP

2016-12-13 Thread Jerome Benoit

Package: sponsorship-requests
Severity: wishlist

Dear Sponsor,

I am looking for sponsorship for the Debian GAP package gap-toric [1,2]
which brings to Debian the GAP package Toric. It is a GAP package for
computing with toric varieties. This GAP package is preloaded by the GAP
interface of Sage[Math].

Thanks in advance,
Jerome

[1] https://bugs.debian.org/848053
[2] https://anonscm.debian.org/cgit/debian-science/packages/gap-toric.git

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

Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#817777: dask package for Debian.

2016-12-13 Thread Diane Trout

Hello,

I've built a packaging for dask (#847497), dask.distributed (#847524)
and all of their required currently unpackaged dependencies. I'm
currently working on creating the git repositories and uploading them
to NEW.

I don't have packages for s3fs, flexx, or jupyter notebook.

I have a non Debian policy compliant package for bokeh, but that's
probably going to stay stuck as I don't know how to deal with building
the javascript library.

Diane



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

Bug#568897: [debhelper-devel] Bug#568897: Bug#568897: debhelper: DEB_BUILD_OPTIONS=nocheck should prevent override_dh_auto_test rule to be run

2016-12-13 Thread Steve M. Robbins

Peter,

You raise a lot of interesting questions about the general handling of 
DEB_BUILD_OPTIONS in the various tools.  I haven't got any real answer for the 
general question -- and, truthfully, your questions lead me to think it needs 
to be considered on a case-by-case basis -- so I'd like to close by bringing 
the discussion back to the narrow question of handling "nocheck".

On Tuesday, December 13, 2016 10:33:18 AM CST Peter Pentchev wrote:

> Um, no, not really, those were practically two different statements.  I was
> suggesting that somebody might write (or not have converted yet) a rules
> file that invokes dh_auto_test directly from within the "build" target, and
> then I gave '"build", "binary", etc' as an enumeration of examples of
> targets that somebody might invoke the dh_* commands directly from :)

I think it is fine if the debhelper author wants to keep the behaviour of 
dh_auto_test.  That is certainly the conservative approach.  *This* feature 
request is to ask that "nocheck" inhibit running tests whether they are (a) 
relying on the implicit dh_auto_test or (b) using rule override_dh_auto_test.  
In short: treat both approaches the same. 

-Steve

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

Bug#847933: vim: please update supported Ubuntu series

2016-12-13 Thread James McCoy

On Mon, Dec 12, 2016 at 03:57:12PM +0200, Graham Inggs wrote:
> Please consider the attached patch for dropping Vivid and Wily from the list
> of supported Ubuntu series.

I intentionally stopped doing that, actually.  Those old release names
aren't invalid, they're just not currently targeted for use.  I'd rather
have debchangelog adapted to highlight them distinctly, similar to
debsources.vim, and maintain the list of old releases.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#793660: Is still an issue

2016-12-13 Thread Borden Rhodes

The Fedora patch link is dead now, but I just got bitten by this bug.
How difficult would it be to apply the patch to Debian's copy of sudo
if upstream won't fix it?

Bug#847997: [pkg-go] Bug#847997: golang-github-jessevdk-go-flags-dev: Cannot be co-installed golang-go-flags-dev

2016-12-13 Thread Potter, Tim

> On 14 Dec 2016, at 4:38 AM, Hilko Bengen  wrote:
> 
> Hi Tim,
> 
>> I think I'll probably ask the FTP Masters very nicely to remove the
>> new package rather than mess with the reverse dependencies.
> 
> Keep in mind that golang-go-flags-dev was released with jessie. I am not
> entirely sure if Adding Breaks/Replaces is enough to ensure smooth
> upgrades there.

I've filed a removal request for the new package with the ftp-masters.


Tim.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#831388: RFH: dee -- model to synchronize mutiple instances over DBus

2016-12-13 Thread Kartik Mistry

On Wed, Dec 14, 2016 at 3:38 AM, Gianni Ciccarelli
 wrote:
> I have seen your RFH on the debian.org page.
> I'm new to debian and I would like to help.
> I have prepared the deb packages while reading the new mantainer's guide
> (https://www.debian.org/doc/manuals/maint-guide/) using the last version of
> dee from https://launchpad.net/dee reading .
>
> Since I'm not able to upload the packages using dupload
> what should I do?

Thanks!

Upload package to mentors.debian.org (See dput config) and ask me and
others to review.

See: https://mentors.debian.net/intro-maintainers for more details.

Let me know if you've any other questions.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com

Bug#848093: RFS: manpages-zh/1.5.4.1-1

2016-12-13 Thread Boyuan Yang

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: cjwat...@debian.org
X-Debbugs-CC: a...@debian.org
X-Debbugs-CC: chinese-develop...@lists.alioth.debian.org

Dear mentors and chinese-developer folks,

I am looking for a sponsor for the team package "manpages-zh".

 * Package name: manpages-zh
   Version : 1.5.4.1-1
   Upstream Author : [ switching to myself ]
 * URL : https://github.com/man-pages-zh/manpages-zh
 * License : GFDL-1.2+
   Section : doc

It builds those binary packages:

manpages-zh - Chinese manual pages

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

  https://mentors.debian.net/package/manpages-zh

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

dget -x https://mentors.debian.net/debian/pool/main/m/manpages-zh/
manpages-zh_1.5.4.1-1.dsc

Alternatively, one can obtain binary package and its piuparts / buildlog / 
buildinfo information at deb-o-matic:

http://debomatic-amd64.debian.net/distribution#unstable/manpages-zh/
1.5.4.1-1

All changes have been pushed onto team git repository:

https://anonscm.debian.org/git/chinese/manpages-zh.git

Explanations for the new upload:

The original maintainer, LI Daobing, is retiring (as the MIA Team indicates 
[1]). This upload would take over this package and get the package back into 
good shape.

Even though there are still many outdated man pages in this release, at least 
we are moving one step forward into the cleanup of old cruft and improve the 
situation, and the bug solved in groff and man-db [2] would greatly help 
improve the typesetting quality of Chinese man pages in Stretch.

[1] https://bugs.debian.org/841805
[2] https://bugs.debian.org/848030

Explanations for lintian checks and package itself:

Lintian warnings on deb-o-matics about zh.tmac is a false-positive, since 
zh.tmac was added yesterday and does not exist in Jessie yet. This file will be 
in Stretch however.

Lintian error on mentors.d.n is a false-positive, since mentors system is old 
and does not recognize debhelper v10, in which dh-autoreconf is a dependency 
of debhelper, so no need to worry. Clean chroot is successful on fresh 
unstable system.

Changes since the last upload:

 manpages-zh (1.5.4.1-1) unstable; urgency=medium
 .
   * Team upload.
   * ACK previous NMU. Thank you Colin!
   * Remove LI Daobing from uploaders list. (Closes: #841805)
 Thank you for all your contributions!
   * New upstream release.
 - Switch to new upstream.
 - Remove all conflict man pages.
 - Remove some nonexist command pages. (Closes: #723565)
 - Import some translations of coreutils.
 - Various fixes.
   * Apply "wrap-and-sort -abst".
   * d/rules: switch to dh buildsystem.
   * d/control:
 - Add myself into uploaders list.
 - Bump standards version to 3.9.8.
 - Use debhelper compat v10, drop dh-autoreconf dep.
 - Update Vcs-* fields.
   * d/watch: info update.
   * d/copyright: rewrite with machine-readable format.

Regards,
 Boyuan Yang

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

Bug#848092: RM: golang-github-jessevdk-go-flags: ROM; already exists under a different name

2016-12-13 Thread Potter, Tim

Package: ftp.debian.org
Severity: normal

Hi ftp-masters.

Could you please remove the [newly accepted into unstable] version of 
golang-github-jessevdk-go-flags
from the archive?  I must admit that I messed up and didn't search hard enough 
for an existing package
which existed under the old naming standard for the pkg-go team.

I am the sponsor for this package's upload and member of the pkg-go team.  
There are no reverse
dependencies for this package.


Thanks,

Tim.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#848091: Additionally...

2016-12-13 Thread Boruch Baum


6] The instructions for uninstalling may be unclear. It seems that the
   procedure mentioned will do the equivalent of `apt-get purge'. If I
   understand TPM correctly and what the uninstall script is
   performing, then: The uninstall instructions should say that
   uninstalling requires commenting out the definition line and
   pressing prefix-r to reload the config, and; There should be
   instructions for purging the plugin, which would include
   prefix-M-u.


--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Bug#848089: openssh: silently changes configuration

2016-12-13 Thread Colin Watson

On Wed, Dec 14, 2016 at 01:32:14AM +0100, Christoph Anton Mitterer wrote:
> I've just stumbled (after much searching, since there seems to be no
> changelog entry o.O) over commit 18a9bd1867ee6fb9d913515773b322a279759b5d.

That very commit includes a changelog entry.  o.O, as you eloquently
say.

> Since I was quite sure that I didn't set prohibit-password and since don't use
> the default config file shipped/generated by the package, I was pretty 
> concerned
> at first that there might have been some intrusion.
> So second, why is that change done silently/automagically at all?
> Doesn't policy 10.7.3 "local changes must be preserved during a package 
> upgrade"
> imply that this is forbidden?
> And shouldn't one at least get some interaction or sshd_config.dpkg-new or 
> similar
> hint that you mangled around with the config?

I don't accept that policy forbids this change.  The semantics are
identical as far as sshd is concerned, it's not generally overwriting a
local change, and in most cases it's in fact just updating a previous
change that was made with debconf involvement.

> In this case the change is not serious, of course, since the two mean the 
> same, but
> it still has an effect, e.g. when the ssh config is checked with rkhunter and 
> that
> in turn configured with ALLOW_SSH_ROOT_USER=without-password .

I didn't know about that, admittedly, but that's the sort of problem
that tools such as rkhunter are always going to have when parsing other
packages' configuration files.  After all, "without-password" was the
default value for a while, so even just standard dpkg conffile handling
with no local modifications would have exhibited the same behaviour.

> There's another case where you, AFAICT, silently mangle around with the config
> that may be user modified:

Policy does *not* say that it is not permissible to modify a
user-modified configuration file.  It says that packages must preserve
user changes.  It does not specifically concern itself with whether
those changes are at the file level or more fine-grained than that.
This may seem like nitpicking but it's an important distinction.

> if dpkg --compare-versions "$2" lt-nl 1:6.6p1-1 && \
>[ "$(get_config_option PermitRootLogin)" = yes ] &&
>db_get openssh-server/permit-root-login && [ "$RET" = true ]; then
> set_config_option PermitRootLogin prohibit-password
> fi
> 
> Obviously this is in a way a good change, as it makes things more secure, but
> AFAIU it's also applied on every config, whether the user made modifications
> or not... and there doesn't seem to be a corresponding entry in NEWS.Debian.

No, it's not applied on every config.  openssh-server/permit-root-login
defaults to false with a high-priority debconf question on upgrade from
pre-1:6.6p1-1 unless no root password is set; and if no root password is
set, then "PermitRootLogin prohibit-password" is effectively the same as
the old default anyway.

> Generally I'd say you never should make such auto-magical changes since there 
> may
> be situations in which you just break things or even make them less secure, 
> and
> this may not be directly visible.

I'm afraid that in my experience it's simply not possible to maintain
openssh with this absolutist philosophy.  Upstream routinely (not
necessarily frequently, but routinely) makes changes that cause old
configuration files to be unparseable.  If I didn't make the sort of
"auto-magical changes" that upset you, I'd be underwater in RC bug
reports because people's sshds would fail to start on upgrade.  This is
one of the essential tools in my arsenal for dealing with this kind of
problem.

> E.g. sshd_config may make use of Match blocks and only some of the directives
> should be changed while others shouldn't where as you auto-magic cannot know 
> which.

I would welcome constructive contributions to improve the processing,
but I'm not going to change the fundamental approach.

> But if you really feel you'd need to do such changes, properly document in
> NEWS.Debian, even if it seems the change may be simple and just safe for 
> everyone.

Some changes are suitable for documenting in NEWS.Debian, while others
are suitable for documenting in the changelog - as I did.  There is such
a thing as swamping people with too much information.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#813754: [Pkg-mpd-maintainers] Bug#813754: Bug#813754: Bug#813754: Can't open port 6600 when run syste, -wide vis systemd

2016-12-13 Thread Lisandro Damián Nicanor Pérez Meyer

On martes, 13 de diciembre de 2016 21:23:46 ART Florian Schlichting wrote:
> Hi Matthew,
> 
> On Tue, Dec 13, 2016 at 05:34:28AM -0500, Matthew E. J. Draisey wrote:
> > I just fixed a situation where I couldn't get mpd to work over my home
> > network. I think it may be this same issue.
> > 
> > On my system
> > 
> > # sysctl net/ipv6/bindv6only
> > net.ipv6.bindv6only = 1
> > 
> > netstat would show init listening on [::]:6600 but doesn't report the
> > IPV6_V6ONLY socket state so I had missed there was no socket listening on
> > ipv4.
> > 
> > Adding
> > 
> > [Socket]
> > BindIPv6Only=both
> > 
> > to the mpd.socket unit fixed my problem.
> 
> that's an interesing observation. Lisandro could you check that?

Yes, will do so tomorrow.

-- 
[00:01] --> chirimbolito se ha unido a este canal (n=Daniel@hos...).
[00:02]  alguien sabe cual es la ventaja de las mangeras ide de
   80 pines respecto a las de 40 pines?
[00:08]  chirimbolito: disminuye impedancia creo...
[00:09]  aunque no creo que sea asi, porque la impedancia imagen
   de un cuadripolo t no depende de la seccion. Si puede
   ser que varie la admitancia...
[00:09]  por ende... no me cierra mi respuesta
[00:10] <-- chirimbolito ha dejado este servidor ("Saliendo").
[00:15]  a ver... entró, preguntó, se respondió solo
  (interactuando consigo mismo) y salió? Esos son
  usuarios autogestivos

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#847458: RFS: clues-emacs/0~2014.09.23.69d873c-1 ITP

2016-12-13 Thread Dmitry Bogatov


I received reply from upstream, so now version is oficially 1.0.0.  One
more review, please.

About d/watch -- seems I used old version of dh-make-elpa. Latest
version correctly creates d/watch with https:// links in both modes
(with and without --pkg-emacsen).

--
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.


pgpb09bZiXupF.pgp
Description: PGP signature

Bug#844404: gnome-shell: Unable to use any combination of F1 key without opening help.

2016-12-13 Thread Mladen Mijatov

That's really stupid on Gnome's part. What's next, consolidating all
the shortcuts from all the operating systems?It's another Gnome "thing"
we have to live with now. They are really not helping their users.
Thanks for clearing this up. It's pointless to file bug upstream as it
will be closed immediately because reasons.-- 
On Tue, 2016-12-13 at 18:15 -0500, Jeremy Bicha wrote:
> The Super+F1 part is intentional:
> 
> https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=147c0b2
> 62f
> 
> For the other examples you listed, maybe you should file a bug
> against
> GNOME directly?
> 
> Thanks,
> Jeremy Bicha
Mladen Mijatov

Key ID: 4096R/83EFD5A0 2013-08-18

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

Bug#847819: [performous] update the ffmpeg and continue the issue

2016-12-13 Thread Andreas Cadhalpun

Control: reopen -1
Control: tags -1 moreinfo

Hi Fernando,

On 13.12.2016 15:49, Fernando Toledo wrote:
> Hi i try and update to 3.2 ffmpeg version from sid (remove the old deb
> multimedia packages with purge and install fresh from sid), the issue
> continue
> 
> the debug log do not show nothing when freeze the video
> the only lines relates can be this (when startup performous):
> 
> opengl/error: Shader dancenote: 0:49(14): warning: `lightDir' used
> uninitialized
> 
> and:
> 
> ffmpeg/error: header/lib version mismatch:
> avutil:55.34.100(ff)/55.34.100(ff) avcodec:57.64.100(ff)/57.64.101(ff)
> avformat:57.56.100(ff)/57.56.100(ff) avresample:3.1.0(lav)/3.1.0(lav)
> swscale:4.2.100(ff)/4.2.100(ff)
> 
> i paste the log at end.
> 
> please can you reopen the bug?

I've done that now.

> --- System information. ---
> Architecture: Kernel:   Linux 4.8.0-1-amd64
> 
> Debian Release: stretch/sid
>   500 unstablerepo.huayragnulinux.com.ar   500 testing
> repo.huayra.conectarigualdad.gob.ar   500 testing
> http.debian.net   500 stable  dl.google.com   500 sid
>  linux.dropbox.com   500 huayra-torbellino repo.bbs.docksud.com.ar

You have quite a few external repositories enabled.
Can you reproduce the issue on a fresh installation, e.g. in a virtual machine?

Best regards,
Andreas

Bug#848091: tmux-plugin-manager: Install bugs

2016-12-13 Thread Boruch Baum

Subject: tmux-plugin-manager: Install bugs
Package: tmux-plugin-manager
Version: 3.0.0-1
Severity: normal

Dear Maintainer,

Thanks for the new package, ChangZhuo Chen (陳昌倬)!

1] The 'normal' install instructions need to be modified for the
   debian-ized package, to reflect the correct pathname of TPM:

 run '/usr/share/tmux-plugin-manager/tpm'

2] The 'normal' install instructions need to be modified for the
   debian-ized package, to reflect that the following recommendation
   is not advisable (because we're using the debian package, not the
   git repository, so we don't want to re-install also from git):

 set -g @plugin 'tmux-plugins/tpm'

3] The install script completes with a message: "Done, press ENTER to
   continue." However, it should be "press q".

4] The install script should direct the user to the correct readme /
   README.md file for usage details. Maybe even offer to display it in
   $PAGER.

5] The package should include either a sub-set or the entire
   collection of 'official' plugins. This would maintain a consistency
   of operation and quality-control. I guess then that the install
   instructions for each would just be the `run' statement in the
   tmux.conf file.


-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 1.0 (jessie)
Release:1.0
Codename:   jessie
Architecture: x86_64

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

Versions of packages tmux-plugin-manager depends on:
ii  git   1:2.1.4-2.1+deb8u2
ii  tmux  2.3-4~bpo8+1

tmux-plugin-manager recommends no packages.

tmux-plugin-manager suggests no packages.

-- debconf information:
Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/^(.*?)(\\)?\${ <-- HERE ([^{}]+)}(.*)$/ at 
/usr/share/perl5/Debconf/Question.pm line 72.
Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/\${ <-- HERE ([^}]+)}/ at /usr/share/perl5/Debconf/Config.pm line 
30.


--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Bug#847216: wget: let the user --convert-links separately, without downloading

2016-12-13 Thread Thaddeus H. Black

On Tue, Dec 13, 2016 at 09:22:19AM +0100, Noël Köthe wrote:
> My strong advise is to contact the upstream mailinglist were you will
> get the best feedback regarding patches and hints for integration.
> The upstream maintainer switched since 2010 and other developer are
> very active on the mailinglist.
> 
> https://lists.gnu.org/mailman/listinfo/bug-wget

Okay.  Upstream will ask how the patch works, of course, especially
since the patch serializes existing data structures.  I will be
able to answer upstream better once I can show minimally
working code.  Therefore, let me hack some more, after which I
will seek feedback and hints on bug-wget as you advise, within
the next 30 days.

Thanks!  I will keep you apprised here.

Obviously, this bug will be for stretch+1 == buster.  As far as
I know, there is nothing to do for stretch.

signature.asc
Description: Digital signature

Bug#848090: haveged/systemd somehow clutter up /var/tmp

2016-12-13 Thread Christoph Anton Mitterer

Package: haveged
Version: 1.9.1-5
Severity: normal


Hi.

I've noticed this on all my systems:
/var/tmp# ls -al
total 0
drwxrwxrwt 1 root root 107210 Dec 13 18:46 .
drwxr-xr-x 1 root root 90 Mar  4  2012 ..
drwx-- 1 root root  6 Jun  9  2016 
systemd-private-0a274b7a4a4d4a2598c6c57c1313a4e3-haveged.service-OOFnxD
drwx-- 1 root root  6 Sep 27  2015 
systemd-private-0a406a21c1474b1fbb2502e54773f450-haveged.service-YZgxXX
drwx-- 1 root root  6 Mar 27  2016 
systemd-private-0a1020ae163942a8a49e8a20613e6fc8-haveged.service-cWLH4v
drwx-- 1 root root  6 May 12  2016 
systemd-private-0a7713a9cbb64b7fbc29935c0746bb20-haveged.service-2npJH9
drwx-- 1 root root  6 Oct 12 15:28 
systemd-private-0a86202cf3a84fea888be2a69f239e32-haveged.service-rtqs5h
drwx-- 1 root root  6 May  8  2016 
systemd-private-0abcb415d33a43c285529587026fd2f3-haveged.service-3iqL2W
drwx-- 1 root root  6 Sep 20  2015 
systemd-private-0abed600c2934176b64f2ba6e04bce5f-haveged.service-kwIrOT
drwx-- 1 root root  6 Jun 14  2016 
systemd-private-0b8b04646aaa4831a46365f9f08614dd-haveged.service-U8gtEz
drwx-- 1 root root  6 Jan 25  2016 
systemd-private-0b9598203c224c57931d415609f9655f-haveged.service-oLsiNf
drwx-- 1 root root  6 Jan 11  2016 
systemd-private-0ba4a56ffea348be9c693027a1594ce8-haveged.service-Uhd26A
drwx-- 1 root root  6 Jan 15  2016 
systemd-private-0bd9a4efb9bc40f996ad722b16abcea8-haveged.service-AxzTPw
drwx-- 1 root root  6 Jul 18 18:59 
systemd-private-0c4a85d1724f4b92bc6a63de76b65034-haveged.service-X3fskD
drwx-- 1 root root  6 Apr  2  2016 
systemd-private-0c50a523d9a645009b452625baf1ea90-haveged.service-2jEYGE
drwx-- 1 root root  6 Mar 26  2016 
systemd-private-0cace4fa586c4008a718075da40e7d6f-haveged.service-xriblB
drwx-- 1 root root  6 Mar  7  2016 
systemd-private-0cafed53b0574fc79728f9acd5a81ee7-haveged.service-JYvl4X
drwx-- 1 root root  6 Jul 12 21:38 
systemd-private-0d76de7112e14caabc9bb9190d9be42d-haveged.service-vPTKHE
drwx-- 1 root root  6 Jul  2 16:07 
systemd-private-0d857b1720104eb1ab34cfec04616b9d-haveged.service-Cf5OD1
drwx-- 1 root root  6 Mar 30  2016 
systemd-private-0dcdf781a67b487f998429a6c2309c97-haveged.service-ZBK1h0
drwx-- 1 root root  6 Oct 27  2015 
systemd-private-0dd9b0c65fa74185b65a456f4d36a899-haveged.service-SqClXN
drwx-- 1 root root  6 Nov 19  2015 
systemd-private-0e0aed52123b4488ab3f799ad5bf522a-haveged.service-A2GwoI
drwx-- 1 root root  6 Jul 29 23:03 
systemd-private-0e2e63a9cc1d4ffea6fd98ce47387b46-haveged.service-749jPd
drwx-- 1 root root  6 Sep 14 01:12 
systemd-private-0e3b06715cd1432a96c6328b49fda1b5-haveged.service-tsGtjl
drwx-- 1 root root  6 Mar 10  2016 
systemd-private-0e07e2d2c0e44e1c8c56d10b1a12428b-haveged.service-KO5bOF
drwx-- 1 root root  6 Sep  3 17:54 
systemd-private-0eacbca150fa433ca5244bf4fe27988b-haveged.service-Xnx7Pw
drwx-- 1 root root  6 Sep  2 14:27 
systemd-private-0ebdc1e26e514eeb816c85e6e2bc3ac9-haveged.service-Fye2sk
drwx-- 1 root root  6 Apr  6  2016 
systemd-private-0ec3d5d0873b44d780a67f2b3e39a283-haveged.service-bNgMFP
drwx-- 1 root root  6 Nov 27 02:03 
systemd-private-0f747f69677742e6b5362021002fc4a8-haveged.service-tSZ7Ui
drwx-- 1 root root  6 Apr  9  2016 
systemd-private-0fc9e9d583d84af9b05b52a1ef23ab41-haveged.service-BsBZr4
drwx-- 1 root root  6 Dec  3 17:12 
systemd-private-00fd6efd61ed464b99ba0e98f810dd24-haveged.service-7Wlokw
drwx-- 1 root root  6 Jan 11  2016 
systemd-private-0fedb3a648144a71a6f8dc495ca0313f-haveged.service-GAjqm8
drwx-- 1 root root  6 Jan 23  2016 
systemd-private-1a7a90b9ad8d4af1af4cf565d2996fc9-haveged.service-zjGTlp
drwx-- 1 root root  6 Jan  6  2016 
systemd-private-1a8e6912dcdc4db0ab1defc6de829ad2-haveged.service-MEMqkI
drwx-- 1 root root  6 Apr 20  2016 
systemd-private-1a29ab159f5440fb934d08db5f3b0709-haveged.service-rZDeN1
drwx-- 1 root root  6 Jun  9  2016 
systemd-private-1a6586d8d95741328846c263444997de-haveged.service-SvjMV1
drwx-- 1 root root  6 Oct 14 17:26 
systemd-private-1a183184f0bc4c9b9e0bfe301e1abfd5-haveged.service-T3llLo
drwx-- 1 root root  6 Jan 14  2016 
systemd-private-1aadab41cc7e4efab3ba3b118c265b3c-haveged.service-7Y593l
drwx-- 1 root root  6 Sep 21 19:49 
systemd-private-1ad3103da67e48519c9b921fb644d986-haveged.service-D62C1n
drwx-- 1 root root  6 Jul 23 22:31 
systemd-private-1b3eabb94dfb4bd7b1d5bb57ac2f77e6-haveged.service-ZbvSlF
drwx-- 1 root root  6 Sep 23 22:16 
systemd-private-1bd52f415dbb488eb413f1880ff3e88d-haveged.service-zksCCj
drwx-- 1 root root  6 Apr 11  2016 
systemd-private-1beb9dd12f1f4c8b9c2df5091b7ed400-haveged.service-85nUYk
drwx-- 1 root root  6 Jan 11  2016 
systemd-private-1c2e4e44849a45ae9d36a01c6f7327c3-haveged.service-pOuxjB
drwx-- 1 root root  6 Oc

Bug#848089: openssh: silently changes configuration

2016-12-13 Thread Christoph Anton Mitterer

Source: openssh
Severity: normal


Hi.

I've just stumbled (after much searching, since there seems to be no
changelog entry o.O) over commit 18a9bd1867ee6fb9d913515773b322a279759b5d.

Which automagically/silently replaces "without-password" with 
"prohibit-password"
for some versions.

First, apparently this doesn't generally work, since I have sid systems where 
this
has happened and some where it didn't, even though all are on the same version 
of
the package now.


Since I was quite sure that I didn't set prohibit-password and since don't use
the default config file shipped/generated by the package, I was pretty concerned
at first that there might have been some intrusion.
So second, why is that change done silently/automagically at all?
Doesn't policy 10.7.3 "local changes must be preserved during a package upgrade"
imply that this is forbidden?
And shouldn't one at least get some interaction or sshd_config.dpkg-new or 
similar
hint that you mangled around with the config?

In this case the change is not serious, of course, since the two mean the same, 
but
it still has an effect, e.g. when the ssh config is checked with rkhunter and 
that
in turn configured with ALLOW_SSH_ROOT_USER=without-password .


There's another case where you, AFAICT, silently mangle around with the config
that may be user modified:
if dpkg --compare-versions "$2" lt-nl 1:6.6p1-1 && \
   [ "$(get_config_option PermitRootLogin)" = yes ] &&
   db_get openssh-server/permit-root-login && [ "$RET" = true ]; then
set_config_option PermitRootLogin prohibit-password
fi

Obviously this is in a way a good change, as it makes things more secure, but
AFAIU it's also applied on every config, whether the user made modifications
or not... and there doesn't seem to be a corresponding entry in NEWS.Debian.




Generally I'd say you never should make such auto-magical changes since there 
may
be situations in which you just break things or even make them less secure, and
this may not be directly visible.
E.g. sshd_config may make use of Match blocks and only some of the directives
should be changed while others shouldn't where as you auto-magic cannot know 
which.

But if you really feel you'd need to do such changes, properly document in
NEWS.Debian, even if it seems the change may be simple and just safe for 
everyone.



Cheers,
Chris.



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

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

Bug#848041: [request-tracker-maintainers] Bug#848041: request-tracker4 requires allow-blessed in Web.pm

2016-12-13 Thread Dominic Hargreaves

On Tue, Dec 13, 2016 at 04:55:37AM -0900, James Zuelow wrote:
> I run request-tracker4, apache2, and postfix.  I've been tracking testing in 
> order to get a newer version of request-tracker4 than is available in Jessie.
> 
> After upgrading request-tracker4 when I run the unmodified package, Apache 
> generates a 500 internal
> server error as such:
> 
> x
> 
> [31143] [Tue Dec 13 13:29:06 2016] [error]: encountered object '1', but 
> neither allow_blessed, convert_blessed nor allow_tags settings are enabled 
> (or TO_JSON/FREEZE method missing) at /usr/share/perl5/JSON.pm line 154.
> 
> Stack:
>   [/usr/share/perl5/JSON.pm:154]
>   [/usr/share/request-tracker4/lib/RT/Interface/Web.pm:197]
>   [/usr/share/request-tracker4/lib/RT/Interface/Web.pm:4065]
>   [/usr/share/request-tracker4/html/Elements/JavascriptConfig:79]
>   [/usr/share/request-tracker4/html/Elements/Header:64]
>   [/usr/share/request-tracker4/html/index.html:4]
>   [/usr/share/request-tracker4/lib/RT/Interface/Web.pm:681]
>   [/usr/share/request-tracker4/lib/RT/Interface/Web.pm:369]
>   [/usr/share/request-tracker4/html/autohandler:53] 
> (/usr/share/request-tracker4/lib/RT/Interface/Web/Handler.pm:209)
> 
> xx
> 
> I've tried updating JSON via CPAN, etc. without success.  However a simple 
> addition to Web.pm resolves the issue.  I've been running this modification 
> in production without any issues.  There has been at least one other person 
> on rt-users that has needed this in conjunction with a Debian install, so I'm 
> fairly sure that this isn't being caused by a local modification.  (Unless 
> we've both made the same modification without realizing it.)  However Best 
> Practical hasn't responded on: rt-users, so this may be Debian specific.
> 
> Patch for /usr/share/request-tracker4/lib/RT/Interface/Web.pm:
> 
> xx
> 
> --- Web.pm  2016-12-13 04:40:12.199936566 -0900
> +++ Web-jfz.pm  2016-12-13 04:39:53.643473002 -0900
> @@ -194,7 +194,7 @@
>  =cut
>  
>  sub EncodeJSON {
> -my $s = JSON::to_json(shift, { allow_nonref => 1 });
> +my $s = JSON::to_json(shift, { allow_blessed => 1, allow_nonref => 1 });
>  $s =~ s{/}{\\/}g;
>  return $s;
>  }
> 
> xx

> -- Package-specific info:
> Changed files:
>   usr/share/request-tracker4/lib/RT/Interface/Web.pm
> 
> There are locally modified files in /usr/local/share/request-tracker4/,
>  these may (or may not) be the source of the problem.

Hi James,

Sorry to hear that you are having problems. Just a quick question
before I dive into the code; can you clarify what web server interface
you are using (mod_perl or something else), and whether you can
reproduce the problem without your other local modifications. It 
would help if you could share the changes in
/usr/local/share/request-tracker4/ if they look relevant.

I note that this problem looks similar to one seen quite a while ago:

http://requesttracker.8502.n7.nabble.com/Update-to-RT-4-2-1-gt-JSON-error-after-login-td55890.html

and a similar problem is here:

http://www.perlmonks.org/?node_id=1159078

In both of those mod_perl is implicated, and maybe JSON::XS too.
You mention that JSON::XS is installed, but it's not a direct dependency
of RT - can you try uninstalling it (from the package and CPAN install)
and see if that makes a difference?

Cheers,
Dominic.

Bug#847768: hoichess: please make the build reproducible

2016-12-13 Thread Samuel Henrique

Hi Holger,

I bet you'll like these patches[1], it's your pick, let me now and i can
patch on my [debian] side so we have reproducible hoichess builds before
you make a new release.

[1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847768

Samuel Henrique

Bug#846850: mitmproxy uninstallable in current Sid and soon Stretch Testing (again)

2016-12-13 Thread Bob Proulx

Sébastien Delafond wrote:
> On Dec/03, Bob Proulx wrote:
> > By my count there are 23 "<<" dependencies in use with mitmproxy!
> > Wow!  That is a lot of very fragile and breakage prone packages.  It
> > is doomed to have repeated breakages in Sid and Testing as those
> > modules get uploaded. It isn't a good way to do things. Basically
> > there are 23 timebomb snags in this package that can go off at any
> > time due to any of those being upgraded.  That is bad.
> > 
> > Why so many timebombs in this package?
> 
> Because that's how setup.py is written upstream ? If you have time to
> contribute patches fixing some of those (by testing they are
> unnecessary, for instance), please do so, and I'll happily include them
> right away.

I have not worked with python packaging and therefore am at this time
inexperienced in how setup.py files are written or should be written.
Therefore I don't have a good idea of what to do here.  I only know
that it is an impossible system.  I feel certain this can't be
necessary.  I know it is not a healthy and happy state.

Just today there are two more python packages that have been uploaded
breaking the << dependencies of mitmproxy again.  This is inevitable.
Do you wish us to simply keep filing individual bug reports each time
this happens?

Thank you for working on the problem regardless.

Bob

signature.asc
Description: PGP signature

Bug#847972: man: Eliminate warnings from '*roff' about the undefined register 'F'

2016-12-13 Thread Colin Watson

On Tue, Dec 13, 2016 at 11:17:18PM +, Bjarni Ingi Gislason wrote:
> On Mon, Dec 12, 2016 at 06:40:21PM -0800, Russ Allbery wrote:
> > Apologies for the regression; this is the confluence of two things that
> > basically no one ever does (enable nroff warnings, and use this obscure
> > indexing code), so it's essentially never tested.
> > 
> > >   1) 'F' is not a random register in manual pages.
> > 
> > It is, though.  It's a completely random register picked by Tom
> > Christiansen years and years ago to hang this feature off of because it
> > wasn't used for anything else.  From the nroff and man-db perspective,
> > it's just some random user-defined register, not anything special.
> 
>   I have a different conception of "random".  The variable 'F' is in all
> manual pages, that "pod2man" creates.

It is "random" from man-db's point of view, because it has no standard
or predictable meaning across the set of all manual pages.

pod2man is just one way to create input files for nroff, and man-db pays
it no special consideration beyond just generally making sure that it
can parse its output properly.  Some other manual page or manual page
generator might quite legitimately define the 'F' number register to do
something completely different.  (It would not surprise me to find some
page deciding to use it for something to do with input file names, like
\n[.F], or fonts, like \n[.f], for instance.)  man has no business
predefining 'F' by default simply in order to work around a pod2man bug;
doing so might well cause problems elsewhere.

Even if this predefinition didn't happen to cause any problems today,
it's completely the wrong layer for the fix, and would be terrible
software engineering.  Fix problems at the layer where they arise; don't
patch around them elsewhere.  That way lies spaghetti architecture.

> Besides that, it is an "input variable"(!) for "*roff".

I'm not sure what your exclamation mark signifies or why you believe
this makes a difference.  pod2man may have set things up so that you're
expected to predefine that variable in order to enable this indexing
thing, but that doesn't mean it should be given any special
consideration by man-db.  Again, it's simply the wrong layer.

>   So there are only two small changes needed to "man.c":
> 
> 1) The default value of "roff_opt" is "-rF0" and not an empty value.  Plus a
> comment about the reason.
> 
> 2) Adding an explanation to the manual, saying what the default value is and
> why.

You can absolutely set this environment variable locally as a workaround
to make the (off by default anyway!) warnings go away; this kind of
thing is why that variable exists, and I'm glad you find it useful.
However, for the reasons given above I won't change man-db in the way
you propose.  The fix belongs in pod2man.

Regards,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

2016-12-13 Thread Bill Blough

On Tue, Dec 13, 2016 at 11:15:26PM +, Gianfranco Costamagna wrote:
> 
> http://paste.debian.net/902086/
> 
>  ^^ this is the file you requested
> 
> G.

That's great.  As I had hoped, ignoring that exception allows SAXCount
to complete successfully, and with the expected output (despite the
possible memory leak and/or corruption that is still an issue).

It now appears to be failing later in the test process. This time
there's no exception terminating the program, rather, it's just not
printing what it's supposed to be printing.

Although, SAXCount should have caught and handled the exception we saw
there, but somehow it skipped the handler and terminated the program
rather than being caught and handled.

So while I'm not sure it will help, there might be benefit to try to get a
stack trace from DOMCount.  It's possible there's an exception being
thrown but it's getting caught/squashed.  If someone wants to try to get
a stack trace, the command will be

libtool --mode=execute gdb --args samples/DOMCount samples/data/personal.xml

and the steps inside of gdb will be the same as before.

In the mean time, I'll dig back into the source.

Thanks!

Bill

Bug#828069: icedove: random crashes after latest security update

2016-12-13 Thread Jason Lewis

I see the same behaviour Vladimir is seeing. for what its worth.

any tips for generating a gdb log?

Vladimir K wrote on 13/12/16 18:18:
> I haven't observe the crash in upstream Thunderbird yet.
> I seem to able to increase the probability of the crash by vigourously 
> browsing through mail in Icedove, caught it a few times. But upstream 
> Thunderbird is pretty stable with the same profile.
> 

-- 
Jason Lewis
http://emacstragic.net

Bug#756017: Partial packaging

2016-12-13 Thread Trout, Diane E.

On Tue, 08 Sep 2015 22:25:11 -0700 Diane Trout 
wrote:
> I have a packaging tree that I'm using at:
> https://github.com/detrout/python-bokeh

I updated my packaging recipe to 0.12.3, though it still uses the
prebuilt javascript provided when upstream builds the pypi package.

I also looked through the bokehjs dependency list

Name  | | Debian  | Version
underscore|  ^1.5.2 | libjs-underscore|   1.8.3
backbone  |  ^1.1.0 | libjs-backbone  |   1.3.3
es6-promise   |   3.0.2 | libjs-es6-promise   |   3.2.2
jquery|  ^2.1.1 | libjs-jquery|   3.1.1
jquery-mousewheel | ^3.1.12 | libjs-jquery-mousewheel |  11
jquery-ui | ^1.10.5 | libjs-jquery-ui |  1.12.1
jsnlog|  ^2.7.5 | |
mathutils |   0.0.1 | |
rbush |  ^1.3.5 | node-rbush  |   2.0.1
proj4 | ^2.3.10 | libjs-proj4 |  2.3.15
sprintf   |  ^0.1.5 | node-sprintf-js?|   1.0.3
timezone  |  0.0.38 | |
coffee-script |   1.9.3 | coffeescript    |  1.10.0

Most of the dependencies seem to be in Debian. The build process seems
to use gulp and browserfy.

Also there's another key "devDependency" in the package.json of which I
have no idea how many are important.

Bug#833239: trivial patch, NMU'd to DELAYED/3

Control: tag -1 patch

Hi,

I have just NMU'd libnfsidmap/0.25-5.1 to DELAYED/3, the debdiff is
attached. Feel free to reschedule or cancel my upload as you see fit.

Cheers,
-Hilko

diff -Nru libnet-daemon-perl-0.48/debian/changelog 
libnet-daemon-perl-0.48/debian/changelog
--- libnet-daemon-perl-0.48/debian/changelog2011-06-25 07:35:18.0 
+0200
+++ libnet-daemon-perl-0.48/debian/changelog2016-12-14 00:19:54.0 
+0100
@@ -1,3 +1,10 @@
+libnet-daemon-perl (0.48-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Remove explicit setting of compression type (Closes: #833239)
+
+ -- Hilko Bengen   Wed, 14 Dec 2016 00:19:54 +0100
+
 libnet-daemon-perl (0.48-1) unstable; urgency=low

   * New upstream
diff -Nru libnet-daemon-perl-0.48/debian/rules 
libnet-daemon-perl-0.48/debian/rules
--- libnet-daemon-perl-0.48/debian/rules2011-06-25 07:35:40.0 
+0200
+++ libnet-daemon-perl-0.48/debian/rules2016-12-14 00:19:39.0 
+0100
@@ -69,7 +69,7 @@
dh_shlibdeps
dh_gencontrol
dh_md5sums
-   dh_builddeb -- -Zbzip2 -z9
+   dh_builddeb

 source diff:
@echo >&2 'source and diff are obsolete - use dpkg-source -b'; false

Bug#847972: man: Eliminate warnings from '*roff' about the undefined register 'F'

2016-12-13 Thread Bjarni Ingi Gislason

On Mon, Dec 12, 2016 at 06:40:21PM -0800, Russ Allbery wrote:
> Bjarni Ingi Gislason  writes:
> 
> >   1) The comment is wrong, because the code was changed from what it
> > originally was (in my patch in the original bug report; see the last
> > line of my input in the first e-mail of this thread).
> 
> Well, the comment is correct in that this is what is being attempted.  :)
> Apparently it isn't working again.
> 
> Your original patch caused problems on HP-UX, which is why it was changed
> upstream.  See:
> 
> https://rt.cpan.org/Public/Bug/Display.html?id=92979
> 

  I found my patch to be too complicated.  A simpler and correct solution is
worded at the end of this e-mail.

> However, I think all those changes may have not been necessary and only
> the missing backslashes were necessary and your original patch was
> otherwise fine once those backslashes are added (and possibly more correct
> in avoiding warnings).  I'll give that a try.
> 

  There is no need for any changes (from the original).  My patch was at the
wrong place.

> Apologies for the regression; this is the confluence of two things that
> basically no one ever does (enable nroff warnings, and use this obscure
> indexing code), so it's essentially never tested.
> 
> >   1) 'F' is not a random register in manual pages.
> 
> It is, though.  It's a completely random register picked by Tom
> Christiansen years and years ago to hang this feature off of because it
> wasn't used for anything else.  From the nroff and man-db perspective,
> it's just some random user-defined register, not anything special.
> 

  I have a different conception of "random".  The variable 'F' is in all
manual pages, that "pod2man" creates.  Besides that, it is an "input
variable"(!) for "*roff".

> Honestly, there's part of me that just wants to drop this entire feature
> from Pod::Man, since I'm dubious that anyone actually runs roffitall more
> than once every five years or so, or that it's worth maintaining all this
> rather opaque code to support.  But I try to be intensely backward
> compatible about Pod::Man.
> 

  There is no need to change anything.

  While thinking about my suggestion of adding '-rF=0' to the code of "man"
(hard-coded addition), I realized that it was a bad idea.  Better to add it
as an option to "man", but option "-r" is already used by it.  So an
environmental variable should be better.  It could then contain all options
that "*roff" accepts.  A name like "ROFFOPTIONS" occurred to me.

  (Not sure if the following is really correct, as my memory is not so
reliable.)

  While reading the code of "man", I saw the name "MANROFFOPT" (was
searching for "ROFFOPT" (short for "ROFFOPTIONS").  Checking the manual page
of "man", this was exactly the environmental variable I was interested in.

  So there are only two small changes needed to "man.c":

1) The default value of "roff_opt" is "-rF0" and not an empty value.  Plus a
comment about the reason.

2) Adding an explanation to the manual, saying what the default value is and
why.

  In the meantime an user can define "MANROFFOPT='-rF0'" or even
"MANROFFOPT='-rF1'" to get the list according to the "IX" macro.

  My statement ("indeed it can't") in an earlier e-mail of mine about:

And "man" is not used to get these index entries, indeed it can't.

  is thus wrong.

> -- 
> Russ Allbery (r...@debian.org)   

-- 
Bjarni I. Gislason

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

2016-12-13 Thread Gianfranco Costamagna

Hi,

>Was that the only exception?  If so, that exception gets thrown (and

>handled) even on a successful run.  In which case, can you post the
>test-results.log?


yes, the only one
(gdb) continue
Continuing.
samples/data/personal.xml: 40029473 ms (37 elems, 12 attrs, 134 spaces, 134 
chars)
[Inferior 1 (process 31957) exited normally]
(gdb) 


(mattia please confirm)


http://paste.debian.net/902086/

 ^^ this is the file you requested

G.

Bug#833251: trivial patch, NMU'd to DELAYED/3

Control: tag -1 patch

Hi,

I have just NMU'd libnfsidmap/0.25-5.1 to DELAYED/3, the debdiff is
attached. Feel free to reschedule or cancel my upload as you see fit.

Cheers,
-Hilko

diff -Nru libx86-1.1+ds1/debian/changelog libx86-1.1+ds1/debian/changelog
--- libx86-1.1+ds1/debian/changelog 2012-06-09 00:54:16.0 +0200
+++ libx86-1.1+ds1/debian/changelog 2016-12-14 00:10:34.0 +0100
@@ -1,3 +1,10 @@
+libx86 (1.1+ds1-10.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Remove explicit setting of compression type (Closes: #833251)
+
+ -- Hilko Bengen   Wed, 14 Dec 2016 00:10:34 +0100
+
 libx86 (1.1+ds1-10) unstable; urgency=low

   * Build with x86emu
diff -Nru libx86-1.1+ds1/debian/rules libx86-1.1+ds1/debian/rules
--- libx86-1.1+ds1/debian/rules 2012-06-09 00:47:02.0 +0200
+++ libx86-1.1+ds1/debian/rules 2016-12-14 00:10:34.0 +0100
@@ -25,6 +25,3 @@

 override_dh_strip:
dh_strip --dbg-package=libx86-dbg
-
-override_dh_builddeb:
-   dh_builddeb -- -Zbzip2 -z9

Bug#844404: gnome-shell: Unable to use any combination of F1 key without opening help.

2016-12-13 Thread Jeremy Bicha

The Super+F1 part is intentional:

https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=147c0b262f

For the other examples you listed, maybe you should file a bug against
GNOME directly?

Thanks,
Jeremy Bicha

Bug#833250: trivial patch, NMU'd to DELAYED/3

Control: tag -1 patch

Hi,

I have just NMU'd libtextwrap/0.1-14.1 to DELAYED/3, the debdiff is
attached. Feel free to reschedule or cancel my upload as you see fit.

Cheers,
-Hilko

diff -Nru libtextwrap-0.1/debian/changelog libtextwrap-0.1/debian/changelog
--- libtextwrap-0.1/debian/changelog2013-06-06 11:07:11.0 +0200
+++ libtextwrap-0.1/debian/changelog2016-12-14 00:04:17.0 +0100
@@ -1,3 +1,10 @@
+libtextwrap (0.1-14.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Remove explicit setting of compression type (Closes: #833250)
+
+ -- Hilko Bengen   Wed, 14 Dec 2016 00:04:17 +0100
+
 libtextwrap (0.1-14) unstable; urgency=low

   * Merge 0.1-13ubuntu1
diff -Nru libtextwrap-0.1/debian/rules libtextwrap-0.1/debian/rules
--- libtextwrap-0.1/debian/rules2013-06-06 06:39:29.0 +0200
+++ libtextwrap-0.1/debian/rules2016-12-14 00:04:06.0 +0100
@@ -96,7 +96,7 @@
dh_shlibdeps
dh_gencontrol
dh_md5sums
-   dh_builddeb -plibtextwrap-dev -- -Zbzip2 -z9
+   dh_builddeb -plibtextwrap-dev
dh_builddeb -plibtextwrap1
dh_builddeb -plibtextwrap1-udeb

Bug#824739: telepathy-haze: diff for NMU version 0.8.0-2.1

2016-12-13 Thread Simon McVittie

Control: tags 824739 + patch
Control: tags 824739 + pending

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

As with telepathy-salut, I've done this as an NMU since I don't really
consider myself to be part of the pkg-telepathy team any more. However,
I have included pending changes from pkg-telepathy git (removing myself
and Jonny Lamb from Uploaders), and I have pushed the NMU changes
(except for the final changelog entry) to pkg-telepathy git for your
convenience. Please revert any changes you don't want.

It would be great if someone active in this team could do a round of
testing and uploads before stretch, to update all the Uploaders
(and make sure everything still builds).

Thanks,
S
diffstat for telepathy-haze-0.8.0 telepathy-haze-0.8.0

 changelog   |   15 +++
 control |4 +---
 patches/purple-2.0.12.patch |   25 +
 patches/series  |1 +
 4 files changed, 42 insertions(+), 3 deletions(-)

diff -Nru telepathy-haze-0.8.0/debian/changelog telepathy-haze-0.8.0/debian/changelog
--- telepathy-haze-0.8.0/debian/changelog	2014-09-16 19:10:55.0 +0100
+++ telepathy-haze-0.8.0/debian/changelog	2016-12-13 21:22:54.0 +
@@ -1,3 +1,18 @@
+telepathy-haze (0.8.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload, incorporating pending changes from
+pkg-telepathy git.
+
+  [ Simon McVittie ]
+  * Remove myself from Uploaders
+  * d/p/purple-2.0.12.patch: add patch by Koop Mast from FreeBSD
+to fix build with recent libpurple (Closes: #824739)
+
+  [ Jonny Lamb ]
+  * Remove myself from Uploaders.
+
+ -- Simon McVittie   Tue, 13 Dec 2016 21:22:54 +
+
 telepathy-haze (0.8.0-2) unstable; urgency=medium
 
   * debian/watch: only watch for 0.x stable versions
diff -Nru telepathy-haze-0.8.0/debian/control telepathy-haze-0.8.0/debian/control
--- telepathy-haze-0.8.0/debian/control	2014-09-16 19:10:55.0 +0100
+++ telepathy-haze-0.8.0/debian/control	2016-12-13 21:22:54.0 +
@@ -2,9 +2,7 @@
 Section: net
 Priority: optional
 Maintainer: Debian Telepathy maintainers 
-Uploaders: Laurent Bigonville ,
-   Simon McVittie ,
-   Jonny Lamb 
+Uploaders: Laurent Bigonville 
 Build-Depends: debhelper (>= 9),
dh-autoreconf,
dpkg-dev (>= 1.16.1~),
diff -Nru telepathy-haze-0.8.0/debian/patches/purple-2.0.12.patch telepathy-haze-0.8.0/debian/patches/purple-2.0.12.patch
--- telepathy-haze-0.8.0/debian/patches/purple-2.0.12.patch	1970-01-01 01:00:00.0 +0100
+++ telepathy-haze-0.8.0/debian/patches/purple-2.0.12.patch	2016-12-13 21:22:54.0 +
@@ -0,0 +1,25 @@
+From: Koop Mast 
+Date: Mon, 11 Jan 2016 11:53:23 +0100
+Subject: Fix the build with libpurple 2.0.12
+
+http://pidgin.im/pipermail/devel/2015-March/023639.html
+Replaces the old emu with the _PASSIVE.
+
+Origin: vendor, FreeBSD, https://lists.freebsd.org/pipermail/svn-ports-head/2016-January/111612.html
+---
+ src/media-stream.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/media-stream.c b/src/media-stream.c
+index 7b4f29f..da088d1 100644
+--- a/src/media-stream.c
 b/src/media-stream.c
+@@ -1076,7 +1076,7 @@ haze_media_stream_new_native_candidate (TpSvcMediaStreamHandler *iface,
+   if (proto == TP_MEDIA_STREAM_BASE_PROTO_UDP)
+ protocol = PURPLE_MEDIA_NETWORK_PROTOCOL_UDP;
+   else if (proto == TP_MEDIA_STREAM_BASE_PROTO_TCP)
+-protocol = PURPLE_MEDIA_NETWORK_PROTOCOL_TCP;
++protocol = PURPLE_MEDIA_NETWORK_PROTOCOL_TCP_PASSIVE;
+   else
+ DEBUG ("Unknown network protocol");
+ 
diff -Nru telepathy-haze-0.8.0/debian/patches/series telepathy-haze-0.8.0/debian/patches/series
--- telepathy-haze-0.8.0/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ telepathy-haze-0.8.0/debian/patches/series	2016-12-13 21:22:54.0 +
@@ -0,0 +1 @@
+purple-2.0.12.patch

Bug#832865: [Pkg-telepathy-maintainers] Bug#832865: telepathy-python: FTBFS: will not overwrite just-created '/«PKGBUILDDIR»/debian/python-telepathy//usr/lib/python2.7/dist-packages/telepathy/_generat

2016-12-13 Thread Emilio Pozuelo Monfort

On 13/12/16 23:15, Santiago Vila wrote:
> On Tue, 4 Oct 2016, Santiago Vila wrote:
> 
>> But in either case, look at the error message. It's essentially like
>> this:
>>
>> /usr/bin/install -c -m 644
>>   some-files _generated/errors.py some-files _generated/errors.py some-files 
>> directory
>>
>> This fails because _generated/errors.py is listed twice.
> 
> And in fact the patch below shows that $(BUILT_SOURCES), which is what
> the install target tries to install, contains _generated/errors.py twice.
> 
> To test it, apply the patch, build the package with "dpkg-buildpackage -A"
> and then try:
> 
> make -C src show_BUILT_SOURCES | grep --color _generated/errors.py
> 
> You should see _generated/errors.py twice, one because it's listed
> explicitly and another one as the result of the patsubst in spec_files.
> 
> The question, then, is not why it fails, but why it does not always fail.
> 
> Please try to explain how the current Makefile tries to avoid the
> failure. I guess it relies on  wildcard $(spec_dir)/*.xml  having
> a particular order, but the order of such wildcard expansion
> depends on filesystem ordering, so it may be anything.
> 
> So I really think there is a Makefile bug here, even if can't
> explain it in full. please forward the bug upstream.

This module is dead upstream. It is replaced by gir1.2-telepathy-glib-*. It
won't see any upstream fixes at all.

I want to get it removed from Debian, but there are a few rdeps. I'll probably
do that anyway once stretch is released.

Cheers,
Emilio

Bug#833241: trivial patch, NMU'd to DELAYED/3

Control: tag -1 patch

Hi,

I have just NMU'd libnfsidmap/0.25-5.1 to DELAYED/3, the debdiff is
attached. Feel free to reschedule or cancel my upload as you see fit.

Cheers,
-Hilko

diff -Nru libnfsidmap-0.25/debian/changelog libnfsidmap-0.25/debian/changelog
--- libnfsidmap-0.25/debian/changelog   2013-05-25 03:26:52.0 +0200
+++ libnfsidmap-0.25/debian/changelog   2016-12-13 23:54:00.0 +0100
@@ -1,3 +1,10 @@
+libnfsidmap (0.25-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Remove explicit setting of compression type (Closes: #833241)
+
+ -- Hilko Bengen   Tue, 13 Dec 2016 23:54:00 +0100
+
 libnfsidmap (0.25-5) unstable; urgency=low

   * Standards Version is 3.9.4
diff -Nru libnfsidmap-0.25/debian/rules libnfsidmap-0.25/debian/rules
--- libnfsidmap-0.25/debian/rules   2012-06-09 09:25:09.0 +0200
+++ libnfsidmap-0.25/debian/rules   2016-12-13 23:51:35.0 +0100
@@ -85,7 +85,7 @@
dh_shlibdeps
dh_gencontrol
dh_md5sums
-   dh_builddeb -- -Zbzip2 -z9
+   dh_builddeb

 binary: binary-indep binary-arch
 .PHONY: build clean binary-indep binary-arch binary install

Bug#848088: telepathy-salut: diff for NMU version 0.8.1-5.1

2016-12-13 Thread Simon McVittie

Package: telepathy-salut
Version: 0.8.1-5
Severity: normal
Tags: patch pending

I've prepared an NMU for telepathy-salut (versioned as 0.8.1-5.1)
fixing #815068 (RC) and #828749 (reproducible build), and uploaded it
to DELAYED/10. Please feel free to tell me if I should delay it longer.

I've done this as an NMU since I don't really consider myself to be part of
the pkg-telepathy team any more. However, I have included pending changes
from pkg-telepathy git (removing Jonny Lamb from Uploaders), and I have
pushed the NMU changes (except for the final changelog entry) to
pkg-telepathy git for your convenience. Please revert any changes you
don't want.

It would be great if someone active in this team could do a round of
testing and uploads before stretch, to update all the Uploaders
(and make sure everything still builds).

Thanks,
S
diffstat for telepathy-salut-0.8.1 telepathy-salut-0.8.1

 changelog|   16 
 control  |5 ++---
 patches/reproducible_build.patch |   27 +++
 patches/series   |1 +
 4 files changed, 46 insertions(+), 3 deletions(-)

diff -Nru telepathy-salut-0.8.1/debian/changelog telepathy-salut-0.8.1/debian/changelog
--- telepathy-salut-0.8.1/debian/changelog	2015-12-10 00:22:44.0 +
+++ telepathy-salut-0.8.1/debian/changelog	2016-12-13 21:22:41.0 +
@@ -1,3 +1,19 @@
+telepathy-salut (0.8.1-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload, incorporating pending changes from
+pkg-telepathy git.
+
+  [ Jonny Lamb ]
+  * Remove myself from Uploaders.
+
+  [ Simon McVittie ]
+  * Build-depend on a version of python-twisted that has absorbed
+python-twisted-words (Closes: #815068)
+  * d/p/reproducible_build.patch: apply patch from Reiner Herrmann to
+sort signals marshallers in a reproducible order (Closes: #828749)
+
+ -- Simon McVittie   Tue, 13 Dec 2016 21:22:41 +
+
 telepathy-salut (0.8.1-5) unstable; urgency=medium
 
   [ Simon McVittie ]
diff -Nru telepathy-salut-0.8.1/debian/control telepathy-salut-0.8.1/debian/control
--- telepathy-salut-0.8.1/debian/control	2015-12-10 00:22:44.0 +
+++ telepathy-salut-0.8.1/debian/control	2016-12-13 21:22:41.0 +
@@ -2,8 +2,7 @@
 Standards-Version: 3.9.6
 Maintainer: Debian Telepathy maintainers 
 Uploaders: Sjoerd Simons ,
-   Laurent Bigonville ,
-   Jonny Lamb 
+   Laurent Bigonville 
 Section: net
 Priority: optional
 Build-Depends: debhelper (>= 9),
@@ -18,7 +17,7 @@
xsltproc,
python (>= 2.5),
python-avahi,
-   python-twisted-words,
+   python-twisted (>= 15.4),
libsoup2.4-dev,
libgnutls28-dev (>= 2.8.2),
libsqlite3-dev,
diff -Nru telepathy-salut-0.8.1/debian/patches/reproducible_build.patch telepathy-salut-0.8.1/debian/patches/reproducible_build.patch
--- telepathy-salut-0.8.1/debian/patches/reproducible_build.patch	1970-01-01 01:00:00.0 +0100
+++ telepathy-salut-0.8.1/debian/patches/reproducible_build.patch	2016-12-13 21:22:41.0 +
@@ -0,0 +1,27 @@
+From: Reiner Herrmann 
+Date: Mon, 27 Jun 2016 15:25:32 +0200
+Subject: Make the build reproducible
+
+While working on the "reproducible builds" effort [1], we have noticed
+that telepathy-salut could not be built reproducibly.
+During build some symbols are extracted and sorted, but their order
+varies because sort sorts differently depending on the locale.
+
+[1]: https://wiki.debian.org/ReproducibleBuilds
+---
+ lib/gibber/Makefile.am | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/gibber/Makefile.am b/lib/gibber/Makefile.am
+index d442531..a5aeb81 100644
+--- a/lib/gibber/Makefile.am
 b/lib/gibber/Makefile.am
+@@ -73,7 +73,7 @@ gibber-signals-marshal.list: $(HANDWRITTEN_SOURCES) Makefile.am
+ 	$(AM_V_GEN)( cd $(srcdir) && \
+ 	sed -n -e 's/.*_gibber_signals_marshal_\([[:upper:][:digit:]]*__[[:upper:][:digit:]_]*\).*/\1/p' \
+ 	$(HANDWRITTEN_SOURCES) ) \
+-	| sed -e 's/__/:/' -e 'y/_/,/' | sort -u > $@.tmp
++	| sed -e 's/__/:/' -e 'y/_/,/' | LC_ALL=C sort -u > $@.tmp
+ 	if cmp -s $@.tmp $@; then \
+ 		rm $@.tmp; \
+ 	else \
diff -Nru telepathy-salut-0.8.1/debian/patches/series telepathy-salut-0.8.1/debian/patches/series
--- telepathy-salut-0.8.1/debian/patches/series	2015-12-10 00:22:44.0 +
+++ telepathy-salut-0.8.1/debian/patches/series	2016-12-13 21:22:41.0 +
@@ -1 +1,2 @@
 Add-a-systemd-user-service.patch
+reproducible_build.patch

Bug#757421: how should we do this?

Please tell me a regex that would add the required "security=selinux" kernel 
option and I'll add it.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#847514: Amazon::S3 vs. Net::Amazon::S3

2016-12-13 Thread Dominic Hargreaves

On Tue, Dec 13, 2016 at 09:03:07PM +, Christopher Hoskin wrote:
> I'd already done most of this at the weekend, so thought I might as
> well upload it. Hope you don't mind!
> 
> https://anonscm.debian.org/cgit/pkg-perl/packages/libamazon-s3-perl.git

Awesome. Thank you both!

Bug#776205: closing, I think it's resolved

close 776205
thanks

The problem here was apparently a misconfiguration.  One could argue that it's 
a bug in dbus, but I'm sure it's not a bug in SE Linux.

I think that Laurent addressed the configuration issue, so I think this issue 
is resolved.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#835439: gdb --write segfaults on quit in _bfd_elf_strtab_finalize

2016-12-13 Thread Ben Harris


Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=20948

On Tue, 13 Dec 2016, Hector Oron wrote:

Thanks for the report, I am able to reproduce it with the upcoming 7.12 
package. Could you please forward this one upstream to the GNU GDB 
community and keep this one up to date.


It looks like it's already been reported upstream:

https://sourceware.org/bugzilla/show_bug.cgi?id=20948

--
Ben Harris, University of Cambridge Information Services.

Bug#765393: closing due to lack of response

close 765393
thanks

selinux-activate is not essential, anyone can edit the config files manually 
if they are using one of the less common boot loaders.

Due to a lack of response as to how selinux-activate could work with pyGrub 
I'm closing this bug.  Feel free to reopen if you can suggest how to do what 
you think should be done.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#846462: webcit: FTBFS (zlib.h was not found or is not usable)

2016-12-13 Thread Christoph Biedl

tags 846462 patch
thanks

Santiago Vila wrote...

> checking for zlib.h... no
> configure: error: zlib.h was not found or is not usable.  Please install zlib.

Again, using libssl1.0-dev makes the build pass.

Christoph

diff -u webcit-902-dfsg/debian/changelog webcit-902-dfsg/debian/changelog
--- webcit-902-dfsg/debian/changelog
+++ webcit-902-dfsg/debian/changelog
@@ -1,3 +1,10 @@
+webcit (902-dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use SSL compatibility library. Closes: #846462
+
+ -- Christoph Biedl   Tue, 13 Dec 2016 
23:38:58 +0100
+
 webcit (902-dfsg-2) unstable; urgency=medium
 
   * Use SSL compatibility API. (Closes: #828598)
diff -u webcit-902-dfsg/debian/control webcit-902-dfsg/debian/control
--- webcit-902-dfsg/debian/control
+++ webcit-902-dfsg/debian/control
@@ -4,7 +4,7 @@
 Maintainer: Debian Citadel Team 
 Uploaders: Wilfried Goesgens , Michael Meskes 
, Alexander Wirt 
 Build-Depends: debhelper (>= 9), po-debconf, quilt, libical-dev (>= 2.0.0), 
gettext, locales,
- libcitadel-dev (>= 902), autotools-dev, libssl-dev, libexpat1-dev, 
libmarkdown2-dev
+ libcitadel-dev (>= 902), autotools-dev, libssl1.0-dev, libexpat1-dev, 
libmarkdown2-dev
 Standards-Version: 3.9.8
 Vcs-Git: git://anonscm.debian.org/pkg-citadel/webcit.git
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-citadel/webcit.git


signature.asc
Description: Digital signature

Bug#837167: RFS: aiscm/0.6.2-2

2016-12-13 Thread Jan Wedekind


On Tue, 13 Dec 2016, Andrey Rahmatullin wrote:


On Mon, Dec 12, 2016 at 09:51:36PM +, Jan Wedekind wrote:

There is no such package in the archive. Is this a new package? If yes,
please follow the procedures outlined at
https://mentors.debian.net/intro-maintainers



Hi Andrey,
Thanks for your email. The version 0.6.2-2 is three months old. Here is the
most recent version:

   http://wedesoft.github.io/aiscm/apt/pool/main/a/aiscm/aiscm_0.9.1-1.dsc
   http://wedesoft.github.io/aiscm/apt/pool/main/a/aiscm/aiscm_0.9.1.orig.tar.gz
   
http://wedesoft.github.io/aiscm/apt/pool/main/a/aiscm/aiscm_0.9.1-1.debian.tar.xz

It has the same problem, you need to open the ITP bug and close it in the
first and the only changelog entry, see
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#newpackage
if you've missed that part in the mentors link I gave you.


Ok, thanks. I filed an ITP here:

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


Other problems:
- the package doesn't build in a clean sid chroot:
not ok 19 - Check a pixel in the first video frame of the video (ERROR: In procedure 
#f: Wrong type (expecting ffmpeg): #)
FAIL: test_ffmpeg.scm 19 - Check a pixel in the first video frame of the video 
(ERROR: In procedure #f: Wrong type (expecting ffmpeg): #)


I have not managed to reproduce the failing test (even using pbuilder). 
Can you let me know how you created the chroot environment with the 
failing test?



- you shouldn't list shared lib dependencies explicitly, they should be
 found automatically


Ok, thanks for letting me know. I removed the explicit shared lib 
dependencies.



- current standards version is 3.9.8.


Ok, I updated the version number.




I tried to upload it to mentors.debian.net but I didn't manage to figure out
how to create a "changes" file as required by "dput".

By building the package.


Let me know if it is
necessary to upload it to mentors.debian.net in which case I'll have another
look at it.

No, it is not necessary, as you already have a dget-able link.



I managed to upload the updated version aiscm-0.9.2 to mentors.debian.net 
(not sure why I didn't notice the "changes" file before):


https://mentors.debian.net/package/aiscm

Regards
Jan

Bug#795518: closing due to lack of response