Bug#736826: ITP: tea4cups -- The Swiss Army's knife of advanced CUPS administrators

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: tea4cups
  Version : 3.13~alpha1+svn3565
  Upstream Author : Jerome Alet 
* URL : http://www.pykota.com/software/tea4cups
* License : GPL
  Programming Lang: Python
  Description : The Swiss Army's knife of advanced CUPS administrators

 Tea4CUPS is a CUPS backend wrapper which can capture print datas before they
 are sent to a printer and process, duplicate or dispatch them in a number of
 ways.
 .
 Tea4CUPS is the Swiss Army's knife of the advanced CUPS administrator, and
 can easily replace or extend most of the existing specialized CUPS backends
 (pdf, email, ftp, etc...).
 .
 You are greatly encouraged to use this software instead of writing your own
 CUPS backends: Tea4CUPS will let you plug your own scripts, filters, tools,
 or commands wherever you want, while giving them access to all the print
 job's characteristics in a consistent way.
 .
 Tea4CUPS makes all information about the current print job, in particular the
 job's datas and attributes, available to your own commands through environment
 variables.
 .
 The possibilities are endless:
 .
   - Your own commands can optionally decide to discard the current print job
 instead of printing it.
   - Send the same job to several printers at the same time, which is not 
possible
 with CUPS.
   - Automate the PDF archiving of all print jobs.
   - Forbid duplicate print jobs (a simple example is shown in the sample
 configuration file)
   - Easily create a print accounting solution.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140127100255.2732.1135.report...@minobo.das-netzwerkteam.de

Re: Proposal: remove krb5-appl (rlogin, rsh, telnet, ftp with krb5 support)

[Simon Toedt]

On Mon, Jan 27, 2014 at 1:05 AM, Philipp Kern  wrote:
> On 2014-01-25 20:23, Joshuah Hurst wrote:
>>
>> One major advantage over ssh is that krb5-rsh has much lower latency
>> and overhead (in terms of used cpu time) when executing a plain
>> /bin/true on a remote host, doing that in a loop over 1000 logins can
>> take hours with ssh but takes minutes with krb-rsh. ssh is a *major*
>> pain in the arse if you have a distributed cluster which depends on
>> rsh/ssh - with ssh the cpu time overhead is so great that it often
>> doesn't even make sense to call the remote host to offload a job.
>> krb-rsh is much more lightweight, e.g. consumes much less cpu time.
>
>
> Given that it is mostly about the handshake, could you try if the
> ControlMaster feature helps here? At least locally for a user and a given
> target host (your /bin/true loop example) it should help. For different
> users or target hosts you will of course still pay the penalty once for
> each.

The problem is the general synchronous design of ssh. You can't fix it
without redesigning the protocol itself.

Hint: Before further claiming the obsolesce of krb-rsh/rlogin vs ssh
please try ssh on an ARM box (e.g gumstix) vs krb-rsh. ssh takes
almost 2.6 seconds to complete (even with tuning and using arcfour),
krb-rsh executes the same in less than 0.07 seconds.

If courses there is another issue: What still left as "use case" of
Kerberos5 if krb-rsh and krb-rlogin are no longer available? Typical
university setup is krb-NFSv3/krb-NFSv4 plus krb-rlogin internally and
ssh only for external access. What do you wish to sell them as
krb-rsh/rlogin replacement? ssh? Seriously?

Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAPL6_jTSJ83EuOfwqdqMMk5R+oBAgsJaONc2XpXbYDf=tm9...@mail.gmail.com

Re: Proposal: remove krb5-appl (rlogin, rsh, telnet, ftp with krb5 support)

[Jonathan Dowland]

On Mon, Jan 27, 2014 at 11:27:52AM +0100, Simon Toedt wrote:
> Hint: Before further claiming the obsolesce of krb-rsh/rlogin vs ssh
> please try ssh on an ARM box (e.g gumstix) vs krb-rsh. ssh takes
> almost 2.6 seconds to complete (even with tuning and using arcfour),
> krb-rsh executes the same in less than 0.07 seconds.

It's certainly slower on ARM boxes but I'd argue that the specific
case where this is really painful - large farms - is either not
applicable to low power ARM or is sufficiently niche that those folks
could reasonably be expected to build their own rsh.

> If courses there is another issue: What still left as "use case" of
> Kerberos5 if krb-rsh and krb-rlogin are no longer available? Typical
> university setup is krb-NFSv3/krb-NFSv4 plus krb-rlogin internally and
> ssh only for external access. What do you wish to sell them as
> krb-rsh/rlogin replacement? ssh? Seriously?

We use krb/ssh, my last University did the same. I've never seen one
still using rsh, but I'm prepared to believe they exist. More data
needed to assume that's the norm, though.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140127114829.ga24...@bryant.redmars.org

what about PTS (Re: libunwind and ia64)

[Osamu Aoki]

Hi,

It seems I got good answers then I have another practical question :
  Can I upload ibus-qt package with warnings on PTS as below.

On Sun, Jan 26, 2014 at 05:57:38PM +0100, Julien Cristau wrote:
> On Mon, Jan 27, 2014 at 01:06:07 +0900, Osamu Aoki wrote:
> 
> > libunwind seems to be holding off many packages to be uploaded to unstable 
> > now.
> >   https://release.debian.org/transitions/html/auto-libunwind.html
> > 
> No, it's not holding off anything.

Good.

On Sun, Jan 26, 2014 at 04:48:32PM +, Ben Hutchings wrote:
> The problem is that on ia64 *all* C programs and libraries directly
 
> depend on libunwind.  Thus the transition from libunwind7 to
> libunwind8 involves a very large number of source packages.

I do not see ***direct*** declaration of dependency but it seems
***indirectly*** depending on it.  I am a bit confused here.

It seems that this "auto-*" transition should not block upload if old
libunwind7 library is used.  Especially for packages indirectly
depending on one of the auto-* packages.  That is good.

The confusing info in PTS: http://packages.qa.debian.org/i/ibus-qt.html

| This package is part of the ongoing testing transition known as
| auto-libunwind. Please avoid uploads unrelated to this transition, they
| would likely delay it and require supplementary work from the release
| managers. On the other hand, if your package has problems preventing it
| to migrate to testing, please fix them as soon as possible. You can
| probably find supplementary information in the debian-release archives
| or in the corresponding release.debian.org bug.

It seems I can upload this package despite of the warning on PTS.  OK?

I also see in PTS: http://packages.qa.debian.org/i/ibus-qt.html

| This package is part of the ongoing testing transition known as icu52.
| Please avoid uploads unrelated to this transition, they would likely
| delay it and require supplementary work from the release managers. On
| the other hand, if your package has problems preventing it to migrate to
| testing, please fix them as soon as possible. You can probably find
| supplementary information in the debian-release archives or in the
| corresponding release.debian.org bug.

I do not understand why icu52 is in transition now.  It went to testing
on 2013-12-30 despite of the fact it is under the same kind "avoid"
warning.  Does some cron job stopped for a few weeks?

I guess it was OK since it is build with  libunwind7 on ia64.

Regards,

Osamu





-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140127131234.GA13169@goofy

Re: what about PTS (Re: libunwind and ia64)

[Andreas Beckmann]

On 2014-01-27 14:12, Osamu Aoki wrote:
> It seems that this "auto-*" transition should not block upload if old
> libunwind7 library is used.  Especially for packages indirectly
> depending on one of the auto-* packages.  That is good.

Looks like the transition tracker should get an optional flag "ignore"
for the transitions - and the auto-libunwind one should definitively get
this flag as it obviously causes lots of confusion :-)
And thereafter the PTS needs to be taught about "ignored" transitions.

Since ia64 is not considered for testing migration the libunwind
problems are no blockers for testing migration.

And regarding the icu52 transition: The transition tracker is not smart
enough to detect that a package has finished the transition (i.e.
testing has a version satisfying the "good" constraint.). But this does
not happen too often.


Andreas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e678fc.2020...@debian.org

Bug#736848: ITP: vim-tabular -- Vim script for text filtering and alignment

[Andrea Capriotti]

Package: wnpp
Severity: wishlist
Owner: Andrea Capriotti 

* Package name: vim-tabular
  Version : 1.0
  Upstream Author : Matthew J. Wozniski 
* URL : https://github.com/godlygeek/tabular
* License : BSD-3-Clause
  Programming Lang: Vim
  Description : Vim script for text filtering and alignment

Sometimes, it's useful to line up text. Naturally, it's nicer to have the
computer do this for you, since aligning things by hand quickly becomes
unpleasant. While there are other plugins for aligning text, the ones I've
tried are either impossibly difficult to understand and use, or too simplistic
to handle complicated tasks. This plugin aims to make the easy things easy and
the hard things possible, without providing an unnecessarily obtuse interface.
It's still a work in progress, and criticisms are welcome.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140127160343.18151.76930.report...@nb-capriotti.cineca.it

Bug#736850: ITP: lightcouch -- CouchDB Java API

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: lightcouch
  Version : 0.0.6
  Upstream Author : Ahmed Yehia 
* URL : http://www.lightcouch.org
* License : Apache-2.0
  Programming Lang: Java
  Description : LightCouch - CouchDB Java API

LightCouch aims at providing a simple and easy-to-use APIs for accessing
CouchDB databases. It offers a powerful and lightweight persistence
interface with minimal code base and dependency.

This API is a dependency of Apache Log4J 2 (ITP #718867)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e68539.2070...@apache.org

Re: what about PTS (Re: libunwind and ia64)

[Adam D. Barratt]

On 2014-01-27 15:19, Andreas Beckmann wrote:

On 2014-01-27 14:12, Osamu Aoki wrote:

It seems that this "auto-*" transition should not block upload if old
libunwind7 library is used.  Especially for packages indirectly
depending on one of the auto-* packages.  That is good.


Looks like the transition tracker should get an optional flag "ignore"
for the transitions - and the auto-libunwind one should definitively 
get

this flag as it obviously causes lots of confusion :-)
And thereafter the PTS needs to be taught about "ignored" transitions.


That functionality already exists, and is why the manually created 
libunwind transition doesn't show up on the PTS; it's just that the 
software creating the auto-* transitions doesn't support it yet.


[...]

And regarding the icu52 transition: The transition tracker is not smart
enough to detect that a package has finished the transition (i.e.
testing has a version satisfying the "good" constraint.). But this does
not happen too often.


The reason that the icu transition hasn't been closed is that libicu48 
is still in testing, so the transition is /not/ finished.


A list of packages which still need updating in (or removing from) 
testing can be found in the britney log or by "dak rm -Rn -s testing -b 
libicu48" on mirror.ftp-master.d.o.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/0d5cbd45e7183473294d9d63580b3...@mail.adsl.funky-badger.org

Bug#736844: ITP: mozilla-password-editor -- Create and edit entries in the password manager in Mozilla applications

[Ximin Luo]

Package: wnpp
Severity: wishlist
Owner: Ximin Luo 

* Package name: mozilla-password-editor
  Version : 2.7.2
  Upstream Author : Daniel Dawson 
* URL : 
https://addons.mozilla.org/en-US/firefox/addon/saved-password-editor/
* License : GPL-3
  Programming Lang: JavaScript
  Description : Create and edit entries in the password manager in Mozilla 
applications

This extension allows you to enter data into the Password Manager database 
instead of relying on Firefox, Thunderbird, SeaMonkey, etc., to do it, as well 
as making changes to existing entries.

This add-on also adds commands to the Password Manager window, which it makes 
accessible through Tools > Saved Passwords as well as a toolbar button.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140127144723.1716.99635.reportbug@localhost.localdomain

Re: what about PTS (Re: libunwind and ia64)

[Julien Cristau]

On Mon, Jan 27, 2014 at 16:19:24 +0100, Andreas Beckmann wrote:

> And regarding the icu52 transition: The transition tracker is not smart
> enough to detect that a package has finished the transition (i.e.
> testing has a version satisfying the "good" constraint.). But this does
> not happen too often.
> 
More to the point, the icu52 transition is not finished.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Proposal: remove krb5-appl (rlogin, rsh, telnet, ftp with krb5 support)

[Russ Allbery]

Joshuah Hurst  writes:

> Only in cases when Kerberos5 is not available.  One major advantage over
> ssh is that krb5-rsh has much lower latency and overhead (in terms of
> used cpu time) when executing a plain /bin/true on a remote host, doing
> that in a loop over 1000 logins can take hours with ssh but takes
> minutes with krb-rsh.

I'm dubious about this contention about ssh.

windlord:~> time sh -c 'for i in $(seq 1 1000) ; do ssh debuild-i386 true ; 
done'
10.764u 3.332s 1:52.78 12.4%0+0k 896+8io 0pf+0w

That's with Kerberos authentication.

I think you have something misconfigured with ssh or with your DNS
(Kerberos is very sensitive to DNS issues).

-- 
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: http://lists.debian.org/871tztmk62@windlord.stanford.edu

Re: Proposal: remove krb5-appl (rlogin, rsh, telnet, ftp with krb5 support)

[Russ Allbery]

Simon Toedt  writes:

> If courses there is another issue: What still left as "use case" of
> Kerberos5 if krb-rsh and krb-rlogin are no longer available? Typical
> university setup is krb-NFSv3/krb-NFSv4 plus krb-rlogin internally and
> ssh only for external access.

I am quite dubious of this statement.  My peers at other universities have
all or nearly all switched to ssh.

> What do you wish to sell them as krb-rsh/rlogin replacement? ssh?
> Seriously?

Yes, we stopped using those programs years ago in favor of ssh without a
single issue and with quite a bit of happiness on the part of our users,
since now Mac OS X works out of the box with Kerberos logins and Windows
is much easier to get working.

I think most people who looked in detail at the network protocol
implementation of rsh and rlogin would stop using them as well.  Both
are... to put it kindly, exceptionally weird.  rsh in particularly is
nearly impossible to firewall properly.

Anyway, krb5-appl has no upstream developers other than some courtesy
support by the MIT Kerberos developers because they feel some
responsibility for the legacy applications.  I think those who really want
to keep those programs should also be thinking about joining in upstream
development.  (And, regardless, the telnet implementation really needs to
go away.)

-- 
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: http://lists.debian.org/87wqhll5cu@windlord.stanford.edu

Re: Proposal: remove krb5-appl (rlogin, rsh, telnet, ftp with krb5 support)

[Brian May]

On 28 January 2014 04:08, Russ Allbery  wrote:

> (And, regardless, the telnet implementation really needs to go away.)
>

I don't know what problems telnet has, however I suspect you will find the
Kerberos ftp to be equally as bad.

At one stage, I seem to recall there was a bug in heimdal ftpd that meant
it would accept unencrypted commands despite encryption being turned on.

As far as I can tell, might have been the following commit that fixed this:
https://github.com/heimdal/heimdal/commit/b2c54991a28723352b96093f11fda0cc92394c82

I thought there was a Debian bug report on this, but all I can see is
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=271534 which looks like it
was closed a year earlier.
-- 
Brian May 

Re: Proposal: remove krb5-appl (rlogin, rsh, telnet, ftp with krb5 support)

[Russ Allbery]

Brian May  writes:
> On 28 January 2014 04:08, Russ Allbery  wrote:

>> (And, regardless, the telnet implementation really needs to go away.)

> I don't know what problems telnet has, however I suspect you will find
> the Kerberos ftp to be equally as bad.

I believe ftp at least uses GSS-API and has some degree of crypto agility.
Kerberized telnet is DES-only.

-- 
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: http://lists.debian.org/87txcp3uce@windlord.stanford.edu

Re: Proposal: remove krb5-appl (rlogin, rsh, telnet, ftp with krb5 support)

[Sebastian Feld]

On Sat, Jan 25, 2014 at 7:13 PM, Moritz Mühlenhoff  wrote:
> Brian May  schrieb:
>> --001a11c1fd62df72e504f0aac077
>> Content-Type: text/plain; charset=UTF-8
>>
>> On 24 January 2014 04:14, Jelmer Vernooij  wrote:
>>
>>> > My proposal is to drop the package from the archive, but I wanted to
>>> > give others a chance to shout out that I'm wrong and that there's some
>>> > compelling use-case I've missed.
>>> > If someone can convince me that the packages are useful I'm happy to
>>> > spend some effort on them.
>>> > However, I don't think that's the case.
>>> FWIW we are currently having the same discussion for the Heimdal packages.
>>>
>>
>> http://thread.gmane.org/gmane.comp.encryption.kerberos.heimdal.general/7608
>>
>> I think these old binaries could make the entire source package and all
>> binary packages it builds look bad, if for example somebody discovers a
>> serious security issue. Which is very possible, as I don't think anyone is
>> really interested in the source code any more.
>
> I agree with the removal. http://www.debian.org/security/2011/dsa-2375 was
> already a sufficiently unpleasant christmas present (exploit was posted on
> on 24th December)

I agree with the removal. Debian should really make itself obsolete by
removing any option to do fast and secure enterprise login. ssh is the
way to go for all, since all deserve slow and messy login performance.

Now seriously... think about it: Is it *wise* to remove these utilities?

Seb
-- 
Sebastian Feld - IT secruity expert


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAHnbEGLhZQG_HEWRBnaOm-P6Vz_7xDpGÏwfpckzjnjmmk...@mail.gmail.com

Re: Proposal: remove krb5-appl (rlogin, rsh, telnet, ftp with krb5 support)

[Russ Allbery]

Sebastian Feld  writes:
> On Sat, Jan 25, 2014 at 7:13 PM, Moritz Mühlenhoff  wrote:

>> I agree with the removal. http://www.debian.org/security/2011/dsa-2375
>> was already a sufficiently unpleasant christmas present (exploit was
>> posted on on 24th December)

> I agree with the removal. Debian should really make itself obsolete by
> removing any option to do fast and secure enterprise login. ssh is the
> way to go for all, since all deserve slow and messy login performance.

> Now seriously... think about it: Is it *wise* to remove these utilities?

Sebastian, people who are Kerberos experts and people who are security
experts, including in some cases upstream developers of this code, are
telling you that they're obsolete and in some cases (such as telnet)
absolutely not secure.  They're the only applications I know of that use
TCP urgent data as part of the protocol for weird out-of-band signaling,
rsh opens a back-channel port from the server back to the client to serve
standard error which causes huge firewall headaches, the protocols for
Kerberos rsh and rlogin are basically undocumented, and last time I
personally tried, the Heimdal and MIT versions of the utilities didn't
even interoperate.

Furthermore, as an enterprise authentication administrator for a heavily
Kerberos-based site (Stanford University, in particular), I'm telling you
that not only does GSS-API ssh work fine for us, it works much better than
Kerberos rsh or Kerberos rlogin for our entire user population and all of
our use cases.  It has far better cross-platform support, it's far more
reliable, it has better security support, and it's more widely understood
by the average user who hasn't been at a Kerberos institution since the
days when Kerberos rsh and rlogin were widespread.

It may well be that you have specific local requirements that change this
picture for you (in which case I strongly suggest getting in touch with
one or the other of the upstreams and seeing if you can find enough
like-minded people to pick up and maintain the software).  But I'm heavily
involved with both MIT and Heimdal upstreams, and I can tell you that
neither of them speak very enthusiastically about that software or think
that it's the best general-purpose option these days.

There have been discussions about the MIT Kerberos version of these
utilities for years, including open calls for people to pick up
maintenance of them and questions about whether they should dropped.  I
had actually volunteered for a time to try to look at upstream support,
since I didn't think we wanted to switch to ssh, but then I took a closer
look at the issues involved and realized that I was wrong and that ssh was
a much better approach.  Now, about five years later, I can repeat with
hindsight that I was completely correct in that decision: ssh was a much
better approach.

-- 
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: http://lists.debian.org/87fvo93tc8@windlord.stanford.edu

Bug#736908: ITP: optcomp -- syntax extension for optional compilation with cpp-like directives

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu" 

* Package name: optcomp
  Version : 1.5
  Upstream Author : Jérémie Dimino
* URL : https://github.com/diml/optcomp
* License : BSD
  Programming Lang: OCaml
  Description : syntax extension for optional compilation with cpp-like 
directives

Optcomp is a syntax extension which handles #if, #else, ... directives
in OCaml source files. Compared to cpp:
 * it does not interpret //, /*, and */ as comment delimiters
 * it does not complains about missing '
 * it is easier to integrate in the build process when using other
   camlp4 syntax extensions
 * it does not do macro expansion while cpp does
Compared to pa_macro, it does not require code that will be dropped to
be valid OCaml code. This can be useful for code that optionnally uses
GADTs, but can be compiled with older versions of OCaml.

-- 
Stéphane


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140128072456.5249.64877.report...@korell.up7.fr