Bug#821066: ITP: glide -- Vendor package management for golang

2016-04-14 Thread 陳昌倬
Package: wnpp
Severity: wishlist
Owner: "ChangZhuo Chen (陳昌倬)" 

* Package name: glide
  Version : 0.10.2
  Upstream Author : Copyright (C) 2014-2016, Matt Butcher and Matt
Copyright (C) 2016, Hewlett Packard Enterprise Development 
LP
Copyright (C) 2015, Google
* URL : http://www.example.org/
* License : Expat
  Programming Lang: golang
  Description : Vendor package management for golang

 Manage your vendor and vendored packages with ease. Glide is a tool for
 managing the vendor directory within a Go package. This feature, first
 introduced in Go 1.5, allows each package to have a vendor directory
 containing dependent packages for the project. These vendor packages
 can be installed by a tool (e.g. glide), similar to go get or they can
 be vendored and distributed with the package.

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = EC9F 905D 866D BE46 A896  C827 BE0C 9242 03F4 552D
  BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature


Work-needing packages report for Apr 15, 2016

2016-04-14 Thread wnpp
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 723 (new: 0)
Total number of packages offered up for adoption: 189 (new: 0)
Total number of packages requested help for: 45 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



No new packages have been orphaned, but a total of 723 packages are
orphaned.  See http://www.debian.org/devel/wnpp/orphaned
for a complete list.



No new packages have been given up for adoption, but a total of 189 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

[NEW] javaparser (#820471), requested 6 days ago
 Description: Java library for parsing Java 1.5.
 Reverse Depends: umlet
 Installations reported by Popcon: 766

   athcool (#278442), requested 4188 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 27

   awstats (#755797), requested 631 days ago
 Description: powerful and featureful web server log analyzer
 Installations reported by Popcon: 4181

   balsa (#642906), requested 1663 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 702

   cardstories (#624100), requested 1816 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 6

   cups (#532097), requested 2504 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups boomaga chromium
   cinnamon-settings-daemon cloudprint cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client (66 more omitted)
 Installations reported by Popcon: 170208

   cyrus-sasl2 (#799864), requested 204 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-admin 389-ds-base 389-ds-base-libs 389-dsgw
   adcli autofs-ldap cairo-dock-mail-plug-in claws-mail
   claws-mail-acpi-notifier claws-mail-address-keeper (123 more
   omitted)
 Installations reported by Popcon: 192415

   developers-reference (#759995), requested 593 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 19317

   devscripts (#800413), requested 198 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   bzr-builddeb customdeb debci debian-builder debmake debpear (27 more
   omitted)
 Installations reported by Popcon: 13170

   ejabberd (#767874), requested 528 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
 Reverse Depends: ejabberd-contrib ejabberd-mod-cron
   ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml
   ejabberd-mod-mam-mnesia ejabberd-mod-message-log
   ejabberd-mod-muc-log-http ejabberd-mod-post-log ejabberd-mod-rest (4
   more omitted)
 Installations reported by Popcon: 775

   fbcat (#565156), requested 2283 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 213

   freeipmi (#628062), requested 1785 days ago
 Description: GNU implementation of the IPMI protocol
 Reverse Depends: conman freeipmi freeipmi-bmc-watchdog
   freeipmi-ipmidetect freeipmi-ipmiseld freeipmi-tools ipmitool
   libfreeipmi-dev libfreeipmi16 libipmiconsole-dev (7 more omitted)
 Installations reported by Popcon: 6451

   freerdp (#799759), requested 205 days ago
 Description: RDP client for Windows Terminal Services (X11 client)
 Reverse Depends: freerdp-x11 freerdp-x11-dbg libfreerdp-cache1.1
   libfreerdp-client1.1 libfreerdp-codec1.1 libfreerdp-common1.1.0
   libfreerdp-core1.1 libfreerdp-crypto1.1 libfreerdp-dbg
   libfreerdp-dev (28 more omitted)
 Installations reported by Popcon: 73755

   gnat-gps (#496905), requested 2786 days ago
 Description: co-maintainer needed
 Reverse Depends: gnat-gps gnat-gps-dbg
 Installations reported by Popcon: 528

   gnokii (#677750), requested 1398 days ago
 Description: Datasuite for mobile phone management
 Reverse Depends: gnokii gnokii-cli gnokii-smsd gnokii-smsd-mysql
   gnokii-smsd-pgsql gnome-phone-manager libgnokii-dev libgnokii6
   xgnokii
 Installations reported by Popcon: 1252

   gridengine (#703256), requested 1124 days ago
 Description: Distributed resource management
 Reverse Depends: gridengine-client gridengine-drmaa-dev
   grideng

Processed: live builds will need UEFI Secure Boot changes

2016-04-14 Thread Debian Bug Tracking System
Processing control commands:

> block 820036 with -1
Bug #820036 [general] Debian does not run on systems with Secure Boot enabled
820036 was blocked by: 821051 820050 821054 821053 820041 820037 820129 820010 
820124 820008 820052 820038 820006
820036 was not blocking any bugs.
Added blocking bug(s) of 820036: 821055
Warning: Unknown package 'live-wrapper'

-- 
820036: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820036
821055: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821055
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: debian-cd will need changes for UEFI Secure Boot

2016-04-14 Thread Debian Bug Tracking System
Processing control commands:

> block 820036 with -1
Bug #820036 [general] Debian does not run on systems with Secure Boot enabled
820036 was blocked by: 821051 820010 820037 820050 820006 820052 820008 820041 
820038 820124 820129 821053
820036 was not blocking any bugs.
Added blocking bug(s) of 820036: 821054

-- 
820036: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820036
821054: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821054
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: UEFI Secure Boot support in d-i build

2016-04-14 Thread Debian Bug Tracking System
Processing control commands:

> block 820036 with -1
Bug #820036 [general] Debian does not run on systems with Secure Boot enabled
820036 was blocked by: 820041 820050 820038 820010 820124 820006 820008 820129 
820052 821051 820037
820036 was not blocking any bugs.
Added blocking bug(s) of 820036: 821053

-- 
820036: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820036
821053: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821053
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: Need support for uploading and signing EFI executables

2016-04-14 Thread Debian Bug Tracking System
Processing control commands:

> block 820036 with -1
Bug #820036 [general] Debian does not run on systems with Secure Boot enabled
820036 was blocked by: 820052 820129 820124 820041 820050 820006 820008 820038 
820010 820037
820036 was not blocking any bugs.
Added blocking bug(s) of 820036: 821051

-- 
820036: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820036
821051: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821051
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#821045: ITP: golang-github-gorilla-context -- A golang registry for global request variables

2016-04-14 Thread Potter, Tim (HPE Linux Support)
Package: wnpp
Severity: wishlist
Owner: Tim Potter 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org

* Package name: golang-github-gorilla-context
  Version : 0.0~git20160226.0.1ea2538-1
  Upstream Author : Gorilla web toolkit
* URL : https://github.com/gorilla/context
* License : BSD-3-clause
  Programming Lang: Go
  Description : Golang registry for global request variables

The package context for this library stores values shared during a
request lifetime.
.
For example, a router can set variables extracted from the URL and
later application handlers can access those values, or it can be used
to store sessions values to be saved at the end of a request. There
are several others common uses.


signature.asc
Description: Message signed with OpenPGP using GPGMail


Bug#821035: ITP: luksipc -- LUKS in-place conversion tool

2016-04-14 Thread Vincent Bernat
Package: wnpp
Severity: wishlist
Owner: Vincent Bernat 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: luksipc
  Version : 0.04
  Upstream Author : Johannes Bauer
* URL : http://johannes-bauer.com/linux/luksipc/
* License : GPL-3
  Programming Lang: C
  Description : LUKS in-place conversion tool

luksipc is a tool to convert (unencrypted) block devices to
(encrypted) LUKS devices in-place (therefore it's name LUKS in-place
conversion). This means the conversion is performed without the need
of copying all data somewhere, recreating the whole disk (i.e. create
a LUKS device, create a new filesystem on the mapped LUKS device, copy
all data back). Instead, the process is reduced to:

 1. Unmounting the filesystem

 2. Resizing the filesystem to shrink about 10 megabytes (2048 kB is
the current LUKS header size -- but do not trust this value, it
has changed in the past!)

 3. Performing luksipc
 4. Adding custom keys to the LUKS keyring

I intend to also provide an initramfs hook to make the conversion of a
root filesystem for simple cases only (notably cloud payload).

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJXD/hYAAoJEJWkL+g1NSX5efUP/jFnaliNfpQrdLRDtRbdnigb
Npks/CXDdE6Zizme8WMnLLgnmVtc0BCrgZqtaNBSFVRh/VKLler8tftOF7aPRrHf
d+T5N1hL+0MrFfzBBs68rfUoPirpaalAP+/uS96Oh0o9v2pj22rlWUrCDDj1mbx9
rzUZDcXyUUAkQZYdU0NABMmOuRGJy54yrpfYbORL3m7p8b9XRI4bJgzJcaWhUon1
zyz9toI3l5OgUvSIg0pPmZiP8vJWitpIDQCHbLTTLrhr5man9aHeZC1DzlEk1u8Y
w51UI3OWI/J6UmheVnK8XHgHiVY/EfiZI2epFMp8o3ESQ4k2Fxhn/nMf+Wk2vGE9
YQTxeyzVNdcOMwCnt05PZfkytxIGJqsMshGt+w8+6DCEMbXFht7vNWuoldvNfGtC
cGoVzErJA/GvinISVJRgVsVwYy+9yi+x11dnNxgGnuKIH7piVELCbYdBalhXOxvE
zqx8Dxuf2YjHrfnWIpEZhiw3HtTBQu0Veo9XF2Go6qFFBusAN1tfUfXkCZMPCInC
9TGxcxQK/okK6kRExI7fgrofHmI2gcM11cHNEP1mBAKzUVgcJ81ecffY9wiyPOUR
dCdFhuZabojMEzzT+Ytz++QJyoG1lPydd+jqovAvHdvxzjzqy9+3atc8/Jo1G4Ab
CcraSGvL4wtU/UoFViKB
=QkX1
-END PGP SIGNATURE-



Bug#821024: ITP: xcb-util-xrm -- utility functions for the X resource manager

2016-04-14 Thread Michael Stapelberg
Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg 

* Package name: xcb-util-xrm
  Version : 1.0
  Upstream Author : Ingo Bürk
* URL : https://github.com/Airblader/xcb-util-xrm
* License : MIT/X
  Programming Lang: C
  Description : utility functions for the X resource manager

 This package contains the header and library files needed to build software
 using libxcb-xrm, providing utility functions for the X resource manager.
 .
 The xcb-util module provides a number of libraries which sit on top of libxcb,
 the core X protocol library, and some of the extension libraries. These
 experimental libraries provide convenience functions and interfaces which make
 the raw X protocol more usable. Some of the libraries also provide client-side
 code which is not strictly part of the X protocol but which have traditionally
 been provided by Xlib.

This package will be used by the i3 window manager and the awesome
window manager.



Re: Packaging of static libraries

2016-04-14 Thread Jakub Wilk

* Milan Kupcevic , 2016-04-10, 20:34:
We should change policy and packaging tools such that static 
linking are not enabled by default and only enabled when there is a 
good reason to do so; when requested by users or when there is some 
other

No, we should not.

+1

A lintian check should suffice.

Lintian check for what?



In the context of discussion and Paul's proposal[0][1] lintian check 
for statically linked binaries in Debian packages should suffice. If 
the one we've got[2] is deficient then we should look into it and 
figure out how to fix it.



[...]


[0] https://lists.debian.org/debian-devel/2016/04/msg00210.html
[1] https://wiki.debian.org/StaticLinking
[2] https://lintian.debian.org/tags/statically-linked-binary.html


I wouldn't call the check deficient, but I don't think it does what 
you'd want it to do.


statically-linked-binary is emitted only when the binary is not linked 
to any shared libraries (not even libc).


It would be helpful if we could check if an dynamic binary is linked to 
a static library from another package; but I'm not aware of any reliable 
method to implement such check.


--
Jakub Wilk



Bug#821008: ITP: pyfr -- flux reconstruction in Python

2016-04-14 Thread Ghislain Vaillant

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: pyfr
  Version : 1.3.0
  Upstream Author : Imperial College London
* URL : http://www.pyfr.org/
* License : BSD
  Programming Lang: Python
  Description : flux reconstruction in Python

Long-Description
 PyFR is an open-source Python based framework for solving 
advection-diffusion

 type problems on streaming architectures using the Flux Reconstruction
 approach of Huynh. The framework is designed to solve a range of governing
 systems on mixed unstructured grids containing various element types. 
It is
 also designed to target a range of hardware platforms via use of an 
in-built

 domain specific language derived from the Mako templating engine.

This package will be co-maintained by the Debian Science Team.



Re: Debian policy recommended snippet prevents building packages from external Makefile

2016-04-14 Thread Jakub Wilk

* Emmanuel Kasper , 2016-04-14, 13:29:

in the Debian policy 4.9.1 we recommend to add build flags as such:

MAKEFLAGS += -j$(NUMJOBS)

and I guess most packages, like tar,  will then call

$(MAKE) $(MAKEFLAGS)


You don't need to pass $(MAKEFLAGS) here.

And, as you noticed, you shouldn't, because it's not always suitable as 
arguments for make.


--
Jakub Wilk



Bug#821003: ITP: r-cran-goftest -- GNU R Classical Goodness-of-Fit Tests for Univariate Distributions

2016-04-14 Thread Andreas Tille
Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-goftest
  Version : 1.0-3
  Upstream Author : Adrian Baddeley
* URL : http://cran.r-project.org/web/packages/goftest/
* License : GPL
  Programming Lang: GNU R
  Description : GNU R Classical Goodness-of-Fit Tests for Univariate 
Distributions
 This R package provides Cramer-Von Mises and Anderson-Darling tests of
 goodness-of-fit for continuous univariate distributions, using efficient
 algorithms.


Remark: This is a new dependency needed to upgrade r-cran-spatstat and hopefully
helps to fix  #767884.  It will be maintained by the Debian Science team at
   
svn://anonscm.debian.org/debian-science/packages/R/trunk/packages/r-cran-goftest/trunk/



Re: Packaging of static libraries

2016-04-14 Thread Vincent Danjean
Le 13/04/2016 20:02, Bas Wijnen a écrit :
> On Wed, Apr 13, 2016 at 05:17:54PM +0200, Marco d'Itri wrote:
>> On Apr 13, Ian Jackson  wrote:
>>> We in Debian are in a good position to defend our users from the
>>> fallout from this problem.  We could change our default compiler
>>> options to favour safety, and provide more traditional semantics.
>> Which would not solve any problem in this case, because then the HPC 
>> users will just not use Debian or use custom optimized builds.
> 
> If users have such specialized needs, I think it is not only reasonable that
> they build their own versions of their libraries; I expect them to prefer 
> that.
> So we should make that as easy as possible.  I can imagine that Gentoo also
> seems attractive to them, and it may be a good (or even better) solution.  But
> as Debian, I think the best we can do to help them is to make it easy to build
> our packages from source with custom build flags.  I'm guessing that we're
> probably talking less than 100 people in the world, maybe less than 10, that
> need this.  It makes no sense to put a package in the archive just for them.

  I do not understand where your numbers come from. I do not know the
number of people that want optimized libraries for HPC, but I know
myself more than 10 just around me.
  I also know lots of HPC clusters installed with Debian. If Debian
choose to favor safety wrt to performance (instead of trying to find
a good compromise as currently), it will probably loose some users.
  And no, admins (and most users) do not prefer to recompile software
instead of using the installed one (some users do not have enough
computer science skills to do it and some admins are already
overloaded and will not want to manage a derivative distribution)

> And changing the default compiler settings to fit their needs makes even less
> sense.

However, it already occurred : we compile by default with -O2, not
with the compiler default (no -O options). Until now, the Debian
project seems to agree that this is a good tradeoff between
optimization and "code correction".

  Regards,
Vincent

> Thanks,
> Bas
> 

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main



Re: migrating to Debian gitlab

2016-04-14 Thread Olivier Berger
Pirate Praveen  writes:

>
>>Beyond that I couldn't test, my VM only has 1 GiB of RAM and no
>>swap, and that is apparently not sufficient for gitlab (unicorn
>>complains that it's out of memory). Which seems weird to me,
>>because this was otherwise an empty throwaway VM; an empty
>>instance using 1 GiB of RAM seems a bit excessive if you ask me,
>>but oh well...
>
> Strange to me as well because the test vm I use is just 512MB ram.
>

FWIW, I also tried to install on a Virtualbox VM with 1 GB
(v. 8.4.3+dfsg-12) and got child sacrifice messages on the console (OOM
messages from the kernel), and had to grant it 2GB of RAM (or at least
1.5GB, not sure exactly). Maybe that has improved a bit with latest from
upstream/testing (8.5.8+dfsg-5), though.

My 2 cents,

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)



Debian policy recommended snippet prevents building packages from external Makefile

2016-04-14 Thread Emmanuel Kasper
Hi

The Problem
~~~
While preparing a backport of GNU tar, I notice that calling
dpkg-buildpackage from an external Makefile errors when we use the
parallel jobs options fails.

A Makefile with something like

do-build:
 cd ${EXTRACTED}; dpkg-buildpackage -b -uc -us

does not work.


The Details
~~~
Suppose you have these files

$PWD/Makefile
all:
cd subdir && $(MAKE)

and

$PWD/subdir/Makefile
 $(info $(MAKEFLAGS))


if you call make from $PWD you will get an output of w ( this is the
make switch --print-directory is added, I don't know why at the momment)

Now in the Debian policy 4.9.1 we recommend to add build flags as such:

MAKEFLAGS += -j$(NUMJOBS)

and I guess most packages, like tar,  will then call

$(MAKE) $(MAKEFLAGS)


now if dpkg-buildpackages is called from a Makefile in a parent folder
w is passed without being prepended a dash, and it will be interpreted
as a target name, causing make to bail out with

RSH="/usr/bin/rsh" CPPFLAGS="`dpkg-buildflags --get CPPFLAGS`"
CFLAGS="`dpkg-buildflags --get CFLAGS` -Wall" \
LDFLAGS="`dpkg-buildflags --get LDFLAGS`" /usr/bin/make w -j
--jobserver-fds=3,4
make[2]: Entering directory '/home/e.kasper/pve/tar/tar-1.28'
make[2]: *** No rule to make target 'w'.  Stop.


my workaround at the momment is to override dpkg-buildpackage make
call by doing

 cd ${EXTRACTED}; dpkg-buildpackage -b -uc -us -R"$(MAKE)
--no-print-directory -f debian/rules"


So am I missing something here ? are we using MAKEFLAGS in a sane way ?


If you came down to here, thanks for your attention !

Emmanuel







Debian policy recommended snippet prevents building packages from external Makefile

2016-04-14 Thread Emmanuel Kasper
Hi

The Problem
~~~
While preparing a backport of GNU tar, I notice that calling
dpkg-buildpackage from an external Makefile errors when we use the
parallel jobs options fails.

A Makefile with something like

do-build:
 cd ${EXTRACTED}; dpkg-buildpackage -b -uc -us

does not work.


The Details
~~~
Suppose you have these files

$PWD/Makefile
all:
cd subdir && $(MAKE)

and

$PWD/subdir/Makefile
 $(info $(MAKEFLAGS))


if you call make from $PWD you will get an output of w ( this is the
make switch --print-directory is added, I don't know why at the momment)

Now in the Debian policy 4.9.1 we recommend to add build flags as such:

MAKEFLAGS += -j$(NUMJOBS)

and I guess most packages, like tar,  will then call

$(MAKE) $(MAKEFLAGS)


now if dpkg-buildpackages is called from a Makefile in a parent folder
w is passed without being prepended a dash, and it will be interpreted
as a target name, causing make to bail out with

RSH="/usr/bin/rsh" CPPFLAGS="`dpkg-buildflags --get CPPFLAGS`"
CFLAGS="`dpkg-buildflags --get CFLAGS` -Wall" \
LDFLAGS="`dpkg-buildflags --get LDFLAGS`" /usr/bin/make w -j
--jobserver-fds=3,4
make[2]: Entering directory '/home/e.kasper/pve/tar/tar-1.28'
make[2]: *** No rule to make target 'w'.  Stop.


my workaround at the momment is to override dpkg-buildpackage make
call by doing

 cd ${EXTRACTED}; dpkg-buildpackage -b -uc -us -R"$(MAKE)
--no-print-directory -f debian/rules"


So am I missing something here ? are we using MAKEFLAGS in a sane way ?


If you came down to here, thanks for your attention !

Emmanuel







Refresh the CUPS driver recommends (was: Re: Opt out style recommends)

2016-04-14 Thread Didier 'OdyX' Raboud
Package: cups
Version: 1.5.2-9

Le vendredi, 8 avril 2016, 10.31:17 Josh Triplett a écrit :
> I'm not going to go through a full analysis here, but here's a *tiny*
> subset of the output on my system, with some annotations:
> 
> (…)
> cups Recommends: printer-driver-gutenprint
> 
> Why does cups recommend some printer drivers and only suggest others?
> For instance, I have printer-driver-hpcups installed instead.

This should indeed be changed. Reporting a bug to keep track.

-- 
Cheers,
OdyX