Re: Bug#777732: ITP: nagios-check-xmppng -- monitoring plugin for checking XMPP servers

2015-02-15 Thread Evgeni Golov
On 02/11/2015 11:52 PM, Jan Dittberner wrote:
> * Package name: nagios-check-xmppng

Would you mind calling it monitoring-plugin-xmppng? In the end, it can
be used with nagios, icinga, icinga2, shinken, and whatever else
implements the proper interface.

Greets
Evgeni


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e057f6.4070...@debian.org



Bug#777373: ITP: doom3-dhewm3 -- GPL'ed Source code modification of the Doom3 game engine

2015-02-15 Thread Tobias Frost
Package: wnpp
Followup-For: Bug #777373
Owner: Tobias Frost 
Control: tags -1 pending

Package is now in the new queue.

Repository at: 
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-games/dhewm3.git

-- 
tobi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150215114219.5629.70010.report...@edoras.loewenhoehle.ip



Bug#778471: ITP: homesick -- Keeps your dotfiles under git

2015-02-15 Thread Alexander Gerasiov
Package: wnpp
Severity: wishlist
Owner: Alexander Gerasiov 

* Package name: homesick
  Version : 1.1.2
  Upstream Author : Josh Nichols, Jeremy Cook, Yusuke Murata and others
* URL : https://github.com/technicalpickles/homesick/
* License : MIT
  Programming Lang: Ruby
  Description : Keeps your dotfiles under git

Your home directory is your castle. Don't leave your dotfiles behind.

Homesick is sorta like rip, but for dotfiles. It uses git to clone a repository 
containing dotfiles, and saves them in ~/.homesick. It then allows you to 
symlink all the dotfiles into place with a single command.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150215144053.19967.15101.reportbug@vice



Bug#778474: ITP: golang-sorcix-irc-dev -- generic support for the IRC protocol in Go

2015-02-15 Thread Michael Stapelberg
Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg 

* Package name: golang-sorcix-irc-dev
  Version : 1.1.0
  Upstream Author : Vic Demuzere
* URL : https://github.com/sorcix/irc
* License : Expat
  Programming Lang: Go
  Description : generic support for the IRC protocol in Go

 Package irc allows your application to speak the IRC protocol.
 .
  * Limited scope, does one thing and does it well.
  * Focus on simplicity and speed.
  * Stable API: updates shouldn't break existing software.
  * Well documented code.
 .
 This package does not manage your entire IRC connection. It only translates
 the protocol to easy to use Go types. It is meant as a single component in a
 larger IRC library, or for basic IRC bots for which a large IRC package would
 be overkill.

This package is a dependency for another ITP I’m about to file.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150215153109.30405.14399.report...@x200.zekjur.net



Bug#778484: ITP: pluginhook -- simple plugin system for Bash programs

2015-02-15 Thread Alessio Treglia
Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: pluginhook
  Version : git snapshot
  Upstream Author : Jeff Lindsay 
* URL : http://github.com/progrium/pluginhook
* License : Expat/MIT
  Programming Lang: Go
  Description : simple plugin system for Bash programs

 The pluginhook command loops through all plugin directories found in the
 path defined by the environment variable PLUGIN_PATH and passes the same
 arguments to any hook scripts by that name. This means installing a
 plugin is as simple as putting it in your PLUGIN_PATH.
 .
 pluginhook does not only provide a mechanism for arguments broadcasting,
 it also accepts streams and pass them through each plugin.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150215174619.6236.45756.reportbug@nemesis



Bug#778489: ITP: jaligner -- implementation of the Smith-Waterman algorithm with Gotoh's improvement

2015-02-15 Thread Michael Crusoe
Package: wnpp
Severity: wishlist
Owner: Debian Med team 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org

* Package name: jaligner
  Version : 1.0
  Upstream Author : Ahmed Moustafa 
* URL : http://jaligner.sf.net
* License : GPL
  Programming Lang: Java
  Description : implementation of the Smith-Waterman algorithm with
Gotoh's improvement

JAligner is an open source Java implementation of the Smith-Waterman
 algorithm with Gotoh's improvement for biological local pairwise sequence
 alignment with the affine gap penalty model.

jaligner is a dependency of many bioinformatic programs including
trinityrnaseq. The packaging was started by Tim Booth and will be group
maintained by the Debian Med team.


Bug#778503: ITP: backupchecker -- Fully automated backup checker

2015-02-15 Thread Carl Chenet
Package: wnpp
Severity: wishlist
Owner: Carl Chenet 

* Package name: backupchecker
  Version : 1.1
  Upstream Author : Carl Chenet 
* URL : https://github.com/backupchecker/backupchecker
* License : GPL
  Programming Lang: Python
  Description : Fully automated backup checker

Backup Checker parses backups (tar, gz, bzip2, lzma, zip, apk archives
and file trees) to perform several different checks in order to verify
your backup integrity and its associated content.

Backup Checker is the new name of Brebis.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150215230616.26168.14393.reportbug@package



how to remove libsystemd0 from a live-running debian desktop system

2015-02-15 Thread Luke Kenneth Casson Leighton
http://lkcl.net/reports/removing_systemd_from_debian/

i've documented the process by which it is possible to run some of the
debian desktop window managers (TDE, fvwm, twm etc.) without the need
for systemd or libsystemd0 or any components related to systemd
whatsoever.

the process is not without difficulties, however out of (at the time
of writing) only two people who have followed this procedure, i was
the one that ended up having to disable udev: the other individual had
a working system (devoid of libsystemd0) purely by following only the
instructions to alter and replace bsdutils from the util-linux
package.

the reasons for demonstrating that this is possible have absolutely
nothing to do with my *personal* (technically-based) dislike of
systemd, although my reasons for actually removing libsystemd0 from
personal systems *are* based on a technical assessment (mostly with a
sysadmin eye).  but, i repeat: my *personal* choice has *nothing to
do* with the reason for posting this documentation.

the reason for demonstrating that this is possible is because nobody
has yet made it clear to either the upstream developers - or to the
distro maintainers who unfortunately are caught in the crossfire -
that systemd's unilateral adoption  is fast becoming an
"all-or-nothing" polarised choice that reminds me keenly of the
polarised Microsoft Monopoly power and dominance of the late 1990s.

and that *really is it*.  the technical issues are completely
irrelevant: those can and will be solved.  already we have evdev,
mdev, devuan, uselessd and many more, but those technical options are
*COMPLETELY SHUT OUT* by the exclusive - monopolistic - position that
systemd now has.

to illustrate the dominance of libsystemd0, if you carry out an
"apt-get --purge remove libsystemd0", *all* of the packages and many
more on the following PNG will be removed:

http://anfo.slavino.sk/libsystemd-journal0.png

that list is woefully incomplete, so i have generated a current list
using apt-rdepends -r libsystemd0 | some manual magic | sort | uniq.
http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt

the list is a whopping 4,583 packages (from the current
debian/testing).  apache2-dev, androidsdk, apt-cacher-ng,
avahi-daemon, blender, bluetooth, bochs, cairo-dock, calligra,
consolekit, cups-daemon, cups-core-drivers, cups-driver-gutenprint,
dbus - this is just a few major software libre packages i can see in
the the first 9% of the list that are affected (cannot be installed)
should anyone exercise their right to choose *not* to have libsystemd0
on their machines.

even dh is on the list.  erlang is on the list!  kde, gimp, xfce,
lxde, gnome, libreoffice, xine, mediawiki, mplayer, network-manager,
openjdk-7, phonon, php (??? why is php dependent on libsystemd0??),
pidgin, policykit-1, postfixadmin (??), pulseaudio, qemu, syslog-ng,
vlc, wicd (client and server), xbase-clients (??), x11-apps (??),
xbmc, xchat... those are just ones that i recognise out of the 4,500+
packages that are not permitted to be installed.

so the short and long of it is: i do not like it when people are not
given the freedom to choose...  and that includes when, just like when
microsoft was so dominant in the 1990s, the choices they are presented
are not really a choice at all.  what i have done therefore is to show
how to modify the debian packages for policykit-1, dbus, pulseaudio
and util-linux, such that libsystemd0 may be entirely removed.
removal of libsystemd0 from those packages trims that list of several
thousand unilaterally-excluded packages *significantly*.

this process comes with a price: i had to disable udev, and i had to
re-enable the keyboard and mouse sections in xorg.conf that i had
added years ago.  however, already within hours of the report's
publication i have received word from one other person who did *not*
have the same extensive difficulties that i encountered: udev
(unmodified) worked perfectly for them.  in a follow-up message they
did however explain that they have successfully installed and then
removed (at an earlier point) a source-compiled version of mdev, which
illustrates that they have some quite significant experience in
maintaining a hybrid of standard debian packages and system-critical
packages compiled directly from source.

so, in short, i have two key things to say.

to debian-users: you don't have complete choice (yet), but i have
demonstrated with a few hours work that there is a way to run
(certain) desktop environments without requiring libsystemd0 or any of
its dependencies, and after a little investigation there do appear to
be people working hard to give you your right to choose what software
to run *without* having to abandon debian.

to debian-developers: the technical issues are irrelevant (and can
always be solved over time) - it's that you are complicit in removing
people's software freedom right to choose what to run on their system:
that is why so many users

Re: how to remove libsystemd0 from a live-running debian desktop system

2015-02-15 Thread Josh Triplett
Luke Kenneth Casson Leighton wrote:
> to debian-developers: the technical issues are irrelevant (and can
> always be solved over time) - it's that you are complicit in removing
> people's software freedom right to choose what to run on their system:

People still have that right, just as they have the right to run a
system without glibc, PAM, or libpng; in all of those cases, they'll
have to do some work to do so, and they shouldn't expect any significant
support from developers for the result.

Consider toning down the hyperbole if you actually care about convincing
anyone who doesn't already agree with you.  You're currently complaining
at the developers of one of the only distributions to actually still
make it an *option* to use systemd, rather than making it mandatory.  In
particular, anyone following systemd development can easily see the
substantial volume of work that Debian's systemd maintainers have
generously done to *accomodate people who don't want to run their
software*, as well as the substantial effort this puts on people
maintaining the surrounding packages to cope with such configurations.
All while dealing with a regular stream of flames and vitriol about
their work.

> and that really is not
> a judgement, it's simply an insightful summarising statement of fact:

"insightful", really?  Do you think yet another thread on debian-devel
really added any significant value?  And apparently "users who don't
like systemd" was an insufficiently niche group, so instead you're
starting a thread on behalf of the subset of those users who find the
very sight of the string "systemd" in their package list revolting even
when prefixed by "lib".

> you have the right to choose whether the situation that you are
> complicit in is something that you find acceptable or whether you do
> not.  i leave it entirely to you to decide.

"The situation" being a pile of packages that depend on a 183k library,
while going painfully out of their way to avoid any actual dependencies
on systemd as the init system?  Oh no, it's a sign of the imminent
apocalypse. 

I for one look forward to the day when configurations without systemd as
the init system finally become so unsupportable that packages can start
actually using systemd features without fear of reprisal, or at least
shift the maintenance burden of such configurations to people who
actually run them and care about them.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150216043638.GA25449@thin



Bug#778515: ITP: golang-gomega -- Matcher/assertion library for the Go programming language

2015-02-15 Thread Martín Ferrari
Package: wnpp
Severity: wishlist
Owner: "Martín Ferrari" 

* Package name: golang-gomega
  Version : 0.1
  Upstream Author : Onsi Fakhouri
* URL : https://github.com/onsi/gomega
* License : MIT
  Programming Lang: Go
  Description : Matcher/assertion library for the Go programming language

Gomega is a matcher/assertion library. It is best paired with the Ginkgo BDD
test framework, but can be adapted for use in other contexts too.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150216064155.30124.43030.report...@aine.tincho.org



Bug#778516: ITP: golang-ginkgo -- BDD Testing Framework for Go

2015-02-15 Thread Martín Ferrari
Package: wnpp
Severity: wishlist
Owner: "Martín Ferrari" 

* Package name: golang-ginkgo
  Version : 1.1.0
  Upstream Author : Onsi Fakhouri
* URL : https://github.com/onsi/ginkgo/
* License : MIT
  Programming Lang: Go
  Description : BDD Testing Framework for Go

Ginkgo is a BDD-style Golang testing framework built to help you efficiently
write expressive and comprehensive tests. It is best paired with the Gomega
matcher library but is designed to be matcher-agnostic.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150216064503.30359.51013.report...@aine.tincho.org



Bug#778517: ITP: golang-snappy-go -- Implementation of the Snappy compression format in Go

2015-02-15 Thread Martín Ferrari
Package: wnpp
Severity: wishlist
Owner: "Martín Ferrari" 

* Package name: golang-snappy-go
  Version : 0+hg20150215.8850bd446ad6
  Upstream Author : The Snappy-Go Authors
* URL : https://code.google.com/p/snappy-go/
* License : BSD-3-clause
  Programming Lang: Go
  Description : Implementation of the Snappy compression format in Go

Snappy is a compression/decompression library. It does not aim for maximum
compression, or compatibility with any other compression library; instead, it
aims for very high speeds and reasonable compression. For instance, compared to
the fastest mode of zlib, Snappy is an order of magnitude faster for most
inputs, but the resulting compressed files are anywhere from 20% to 100%
bigger. On a single core of a Core i7 processor in 64-bit mode, Snappy
compresses at about 250 MB/sec or more and decompresses at about 500 MB/sec or
more.

This is an implementation of the Snappy compression format in the Go
programming language.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150216064914.30527.96377.report...@aine.tincho.org



Re: how to remove libsystemd0 from a live-running debian desktop system

2015-02-15 Thread Russ Allbery
Luke Kenneth Casson Leighton  writes:

> i've documented the process by which it is possible to run some of the
> debian desktop window managers (TDE, fvwm, twm etc.) without the need
> for systemd or libsystemd0 or any components related to systemd
> whatsoever.

Alas, the resulting distribution is still hopelessly compromised by the
NSA, who might be even worse than Lennart Poettering.  To see how deep the
tendrils of US government infiltration go, just try removing libselinux1,
and marvel at how much concerted malevolent effort has gone into
destroying your freedom.

Or, alternately, you could research how and why one would use shared
libraries in a binary distribution to support optional features.  But
that's boring, prosaic, and nowhere near as much fun to write about.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbj2e4bh@hope.eyrie.org