Bug#566375: ITP: freeplane -- A Mind Mapping software written in Java.

[Eric Lavarde]

Package: wnpp
Severity: wishlist
Owner: Eric Lavarde 


* Package name: freeplane
  Version : 1.0.38
  Upstream Author : Dimitri Polivaev 
* URL : http://freeplane.org/
* License : GPL
  Programming Lang: Java
  Description : A Mind Mapping software written in Java.

(from )

In July 2009, Freeplane was launched as a fork of the FreeMind project.
Since then, while maintaining file format compatibility with FreeMind,
Freeplane adds many new features.

New features of Freeplane include:

* Export to PNG, JPEG, SVG (in addition to HTML / XHTML and PDF)
* Find / Replace in all open maps
* Paste HTML as node structure
* Outline mode
* Portable version (run from a USB flash drive)
* Scripting via Groovy
* Spell Checker



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#566378: ITP: dehydra -- Scriptable static analysis tool for C++

[Mike Hommey]

Package: wnpp
Severity: wishlist
Owner: Mike Hommey 

* Package name: dehydra
  Version : 0.9.hg20100123
  Upstream Author : Mozilla Corporation
* URL : https://developer.mozilla.org/en/Dehydra
* License : GPL2+
  Programming Lang: C, C++, JS, tiny bits of python
  Description : Scriptable static analysis tool for C++

Dehydra is a lightweight, scriptable, general purpose static analysis tool
capable of application-specific analyses of C++ code. In the simplest
sense, Dehydra can be thought of as a semantic grep tool. It presents a
wealth of semantic information that can be queried with concise
JavaScripts. It is also useful to find bugs in source code as it allows
for much more error checking than C++ is capable of by itself.

Dehydra is built as a GCC plugin, thus it is easy to use for projects that
already support GCC.

Dehydra is also useful for generating language bindings and is used to
bootstrap Treehydra, a heavy-duty static analysis GCC plugin.

(This description is just a copy/paste of
https://developer.mozilla.org/en/Dehydra)

Please note that treehydra is part of the dehydra build, so it will also
be packaged at the same time. As both require gcc 4.5 plugin support, it
will live in experimental.

Anyone interested in co-maintaining this tool is welcome.

Cheers,

Mike



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#566364: RFH: doc-central

[Stefano Zacchiroli]

On Sat, Jan 23, 2010 at 04:12:22PM +0900, Charles Plessy wrote:
> doc-central has one release-critical bug, making it unfit for the release. Are
> there volunteers to adopt it? Robert? The QA team? Otherwise, despite it is
> useful, it is maybe time to give up and remove it from our archive...

I find this request of yours unsubstantiated.

The RC bug has a patch pending and is pretty easy to fix. I might
eventually NMU it to fix that, even though I'm not willing to maintain
the package right now.  Beside that bug, the package works quite well,
has a respectable number of popcon user (as you observe); I, for
instance, am a daily user of it.

So, exactly *why* you want this package to be removed, considering that
there are way more "bad" packages in the archive (and almost completely
unused) that would deserve removal first?

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Bug#566364: RFH: doc-central

[Neil Williams]

On Sat, 23 Jan 2010 12:00:25 +0100
Stefano Zacchiroli  wrote:

> The RC bug has a patch pending and is pretty easy to fix. I might
> eventually NMU it to fix that, even though I'm not willing to maintain
> the package right now.  Beside that bug, the package works quite well,
> has a respectable number of popcon user (as you observe); I, for
> instance, am a daily user of it.

Just out of interest, what's the difference between doc-central and
dwww ? 

AFAICT dwww does more via extensions to view the relevant package
details as well as manpages and other content in /usr/share/doc/ that
doesn't need a doc-base file.

I use dwww almost constantly, never considered doc-central. I'm not
saying doc-central should be removed - sounds like it just needs to be
orphaned and put into QA. Just curious.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpUvfqXH3mbB.pgp
Description: PGP signature

Re: Bug#566364: RFH: doc-central

[Stefano Zacchiroli]

On Sat, Jan 23, 2010 at 11:18:57AM +, Neil Williams wrote:
> Just out of interest, what's the difference between doc-central and
> dwww ? 

That's a pretty damn good question :-)

I've made the choice between dwww and doc-central several years
ago. _IIRC_ , back then dwww was missing decent browsing of the doc-base
sections which is my main access path to documentation; more generally,
I liked dwww more back then.  FWIW I've just re-looked at dwww after
your prod, and it seems that it has improved a lot over time.

If the point of yours, beside curiosity, was also to phase out
doc-central in favor of dwww, that might be an option, but then
agreement should be sought between the two packages maintainer and a bit
of smooth upgrade path should be provided.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Bug#566404: ITP: [PACKAGE] -- dropbox

[Ivan Borzenkov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

   Package name: dropbox
Version: 0.7.97
Upstream Author: Dropbox
URL: http://www.dropbox.com/
License: freeware (AS IS), close source
Description: Secure backup, sync and sharing made easy.

Dropbox is the simplest, most elegant file-synchronization tool. Dropbox Basic 
provides 2GB of storage free, and Dropbox Pro gives you 50GB for $9.95 per 
month or $99.95 per year. The service stores files with strong encryption on 
multiple servers in Amazon's S3 service and works equally smoothly on Windows, 
Mac, and Linux PCs.


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

Re: Bug#566364: RFH: doc-central

[Neil Williams]

On Sat, 23 Jan 2010 12:50:38 +0100
Stefano Zacchiroli  wrote:

> On Sat, Jan 23, 2010 at 11:18:57AM +, Neil Williams wrote:
> > Just out of interest, what's the difference between doc-central and
> > dwww ? 
> 
> That's a pretty damn good question :-)
> 
> I've made the choice between dwww and doc-central several years
> ago. _IIRC_ , back then dwww was missing decent browsing of the doc-base
> sections which is my main access path to documentation; more generally,
> I liked dwww more back then.  FWIW I've just re-looked at dwww after
> your prod, and it seems that it has improved a lot over time.

Agreed - and as dwww has progressed, doc-central appears to have
stalled. The Documentation Menu in dwww covers all I need from doc-base
and the addition of man page browsing, info document browsing, viewing
any file in any /use/share/doc/ directory and automatic linking from
changelog.Debian.gz to the BTS and similar - it's all really neat. Add
in the dpkg-www package to link to the Packages / apt cache data and
doc-central could have a lot of catching up to do.

The only thing missing (for me) from dwww is an area covered by devhelp
- and even then a simple symlink is enough to make things like the
gtk2.0 reference manual available in dwww.

devhelp has useful integration with some IDEs so that's why I use that
one as well.

> If the point of yours, beside curiosity, was also to phase out
> doc-central in favor of dwww, that might be an option, but then
> agreement should be sought between the two packages maintainer and a bit
> of smooth upgrade path should be provided.

Any migration would only be due to doc-central becoming orphaned and
then not adopted. doc-central appears to be a native Debian package, so
if it really is abandoned, it is could fall into bit-rot quite
quickly.

There are plenty of situations in Debian where users have a choice of
options that have pros-and-cons. Personally, I don't see a need to
migrate - yet - as long as doc-central is usable and does the smaller
task of just the doc-base files, it is probably worth having both.

If there is any particular content that advises doc-central over dwww
(on www.debian.org or on the Wiki) I'm not aware of it, so it's left to
user choice.

Having dwww just means that should doc-central need to be removed for
problems that arise in the future, we have a easy alternative.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpRqOzoH4ue9.pgp
Description: PGP signature

Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support

[Martin Koegler]

On Fri, Jan 22, 2010 at 08:08:03PM +0100, Ralf S. Engelschall wrote:
> This seems like a Debian related discussion. But as the author of
> GNU Pth I can at least say that I've never heard of "pthsem"
> myself (if I received any email, then, sorry, it seems it was
> filtered by the anti-spam stuff) and also don't know why GNU Pth is  
> considered unmaintained.

First, I happy, that contacting you has (finally) succeed and one of
mails reached you.

> Sure, I've not released any newer versions since 2006, but as long
> as nobody drops me a note that something is broken there is no
> requirement for any new releases. I'm using it at least under
> the latest versions of FreeBSD, Linux and Solaris since years.
> The functionality of GNU Pth is fully complete (at least to the
> extend I originally planned at about 2004) since 2006 and
> version 2.0.x.

Yes, pth is stable and working, but probably not feature complete for
some people (otherwise there would be no need for forks).

> Over the last 10 years we have seen half a dozen forks of
> GNU Pth (for various addon functionalities or whatever), but they
> were at least never named "GNU Pth" or just "Pth". If the current
> name of this fork is "pthsem", please keep it this way. But please avoid  
> naming it (or its Debian package) just "pth". Thanks.

Calling it pth was the idea of some people on the debian mailing list
to avoid having GNU pth and a "extended" pth package in the distribution.

> If "pthsem" is really fully backward compatible to GNU Pth,
> then we can even check whether we can include its functionality into
> GNU Pth, too. Where do I find its latest sources? Is is the one
> under http://www.auto.tuwien.ac.at/~mkoegler/index.php/pth?

The latest sources can be found at:
http://bcusdk.git.sourceforge.net/git/gitweb.cgi?p=bcusdk/bcusdk;a=shortlog;h=refs/heads/pthsem/master

I'll send you in a private mail more details and hits to the relevant
changes.

Regards,
Martin Kögler


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#566485: ITP: uncertainties -- transparent calculations with uncertainties on the quantities involved

[Jakub Wilk]

Package: wnpp
Severity: wishlist
Owner: Jakub Wilk 

* Package name: uncertainties
  Version : 1.2.2
  Upstream Author : Eric O. LEBIGOT
* URL : http://pypi.python.org/pypi/uncertainties/
* License : GPLv2
  Programming Lang: Python
  Description : transparent calculations with uncertainties on the 
quantities involved

uncertainties is a Python module, which allows calculations such as
(0.2 +/- 0.01)*2 = 0.4 +/- 0.02 to be performed transparently; much more 
complex mathematical expressions involving numbers with uncertainties 
can also be evaluated transparently.


--
Jakub Wilk


signature.asc
Description: Digital signature

Bug#566489: ITP: kwalletcli -- CLI for the KDE Wallet

[Thorsten Glaser]

Package: wnpp
Severity: wishlist
Owner: Thorsten Glaser 

* Package name: kwalletcli
  Version : 2.01
  Upstream Author : Thorsten Glaser 
* URL : https://www.mirbsd.org/kwalletcli.htm
* License : Code MirOS, Logo LGPL
  Programming Lang: C, C++, mksh
  Description : CLI for the KDE Wallet

kwalletcli implements a command line interface tool to get and set
password entries in the KDE Wallet. Also included are a shell wrapper
around pinentry, a pinentry-kwallet application checking the KDE Wallet
for the passphrase requested before asking the user for use with the
GnuPG Agent, which is also capable of running without a pinentry as
backend, and kwalletaskpass, which stores SSH key passphrases in the
KDE Wallet for use with the OpenSSH Agent.

If the pkg-kde team intends to take this package over once I uploaded
the initial version, feel free to do so.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#566364: RFH: doc-central

[Charles Plessy]

Le Sat, Jan 23, 2010 at 12:00:25PM +0100, Stefano Zacchiroli a écrit :
> I find this request of yours unsubstantiated.
> 
> The RC bug has a patch pending and is pretty easy to fix. I might
> eventually NMU it to fix that, even though I'm not willing to maintain
> the package right now.  Beside that bug, the package works quite well,
> has a respectable number of popcon user (as you observe); I, for
> instance, am a daily user of it.
> 
> So, exactly *why* you want this package to be removed, considering that
> there are way more "bad" packages in the archive (and almost completely
> unused) that would deserve removal first?

I am also a happy user of doc-central and I am not saying that it should be
removed by all means. However, if it is de facto abandonned, the Project should
seek for a long term solution since it is a native package (i.e. it has not
upstream apart from Debian itself.)

This package was NMUed in Lenny and needs to be NMUed for Squeeze. If we do not
want to rely on somebody to NMU it in Squeeze+1, I think it needs to be
maintained or removed. I would be most happy if it would be maintained,
therefore I have CCed the person who seems to care most for this package.

If you NMU this package, may I suggest to orphan it and put it in collab-maint?
I offer to do the work if you like the idea (svn or git, just let me know).

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#566364: RFH: doc-central

[Frank Lin PIAT]

On Sat, 2010-01-23 at 12:53 +, Neil Williams wrote:
> On Sat, 23 Jan 2010 12:50:38 +0100
> Stefano Zacchiroli  wrote:
> 
> > On Sat, Jan 23, 2010 at 11:18:57AM +, Neil Williams wrote:
> > > Just out of interest, what's the difference between doc-central and
> > > dwww ? 
> > 
> > That's a pretty damn good question :-)
> > 
> > I've made the choice between dwww and doc-central several years
> > ago. _IIRC_ , back then dwww was missing decent browsing of the doc-base
> > sections which is my main access path to documentation; more generally,
> > I liked dwww more back then.  FWIW I've just re-looked at dwww after
> > your prod, and it seems that it has improved a lot over time.
> 
> Agreed - and as dwww has progressed, doc-central appears to have
> stalled. The Documentation Menu in dwww covers all I need from doc-base
> and the addition of man page browsing, info document browsing, viewing
> any file in any /use/share/doc/ directory and automatic linking from
> changelog.Debian.gz to the BTS and similar - it's all really neat. Add
> in the dpkg-www package to link to the Packages / apt cache data and
> doc-central could have a lot of catching up to do.
> 
> The only thing missing (for me) from dwww is an area covered by devhelp
> - and even then a simple symlink is enough to make things like the
> gtk2.0 reference manual available in dwww.
> 
> devhelp has useful integration with some IDEs so that's why I use that
> one as well.
> 
> > If the point of yours, beside curiosity, was also to phase out
> > doc-central in favor of dwww, that might be an option, but then
> > agreement should be sought between the two packages maintainer and a bit
> > of smooth upgrade path should be provided.
> 
> There are plenty of situations in Debian where users have a choice of
> options that have pros-and-cons. Personally, I don't see a need to
> migrate - yet - as long as doc-central is usable and does the smaller
> task of just the doc-base files, it is probably worth having both.

I don't use either. I gave a quick-try to both of them.
If I where to use one of them, I would probably use doc-central, because
it doesn't depends on any indexing tools (dlocate, squish...).

> If there is any particular content that advises doc-central over dwww
> (on www.debian.org or on the Wiki) I'm not aware of it, so it's left to
> user choice.

It's best if packages pros/cons are summarized in package description.

Here's a page for g**glers (contributions are welcome):
 http://wiki.debian.org/doc-base

Franklin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Outdated mirror in http.us.debian.org

[Anthony DeRobertis]

http://35.9.37.225/debian/dists/testing/main/binary-amd64/ show this 
mirror hasn't updated since the 19th, but its still in the 
http.us.debian.org rotation.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

ucf was run from a maintainer script that uses debconf...

[jidanni]

found 513142 1.8.42
tags 513142 - unreproducible
notfixed 513142
thanks

I wish the line below,
Please inform the package maintainer about this problem.
would say which package it is talking about. Or at least it could say
"don't tell the maintainers of x y and z'.

Setting up dbconfig-common (1.8.42) ...
*** WARNING: ucf was run from a maintainer script that uses debconf, but
 the script did not pass --debconf-ok to ucf. The maintainer
 script should be fixed to not stop debconf before calling ucf,
 and pass it this parameter. For now, ucf will revert to using
 old-style, non-debconf prompting. Ugh!

 Please inform the package maintainer about this problem.
Need debconf to interact
dpkg: error processing dbconfig-common (--configure):
subprocess installed post-installation script returned error exit status 2

I found
Bug #513142 [dbconfig-common] ucf/dbconfig warning when package is installed

All I know is I still get the warning.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

advice sought for hamlib new upstream vs "embedded ltdl"

[Stefano Zacchiroli]

tags 559814 + help
thanks

I'm looking for advice / testers for #559814 (one of the dreaded
"vulnerable embedded copy of ltdl").

The bug is against hamlib, which is orphaned but has at least one binary
package with high popcon (about 300).

The bug seems to be fixed with new upstream release 1.2.10 which has
recent version of ltdl. Also, with such a recent version come flexible
autoconf macros that make it easy to link against the system ltdl
library, hereby avoiding similar problems in the future.  On the
contrary, the Debian version (1.2.9) has 5-year old autoconf macros
which hinder linking against the system library [1].

I'd like to upload new upstream to fix the security / RC bug, but I
don't intend to take over maintenance of the package, nor I _use_
it. Can please some user of the library get in touch with me with a test
case or something so that we avoid screwing up a lib? dd-list of
maintainers of reverse deps is reported at the bottom of this mail [2].

I'll then take care of doing a QA upload of the new usptream, together
with some misc QA fixes.

Of course it would be even better if someone steps up as a volunteer
maintainer for hamlib (hint, hint).

Cheers.

[1] I've *almost* managed to do that, but the resulting .diff.gz is as
big as the .orig due to re-autotoolization, ... quite pointless if
you ask me.

[2] Debian Hamradio Maintainers 
   fldigi

Hamish Moffatt 
   fldigi (U)
   gmfsk

Patrick Ouellette 
   fldigi (U)

Jaime Robles 
   fldigi (U)
   klog


-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Thank you, Debian project, for working to make a free software operating system (was: Is tabular data in binary format acceptable for Debian ?)

[Andrei Popescu]

On Fri,22.Jan.10, 10:11:45, Ben Finney wrote:
> Charles Plessy  writes:

> > sometimes degrades our relations with Upstream, and I have not yet
> > seen a user thanking us for doing this.
> 
> I've often expressly, and in public, thanked the specific people who put
> forth efforts to ensure free software in the Debian operating system. I
> encourage anyone else to do this too; it's a good way to increase the
> likelihood such work continues to be done.

I wonder, does --kudos work for package 'general'? ;)

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: ucf was run from a maintainer script that uses debconf...

[Holger Levsen]

Hi,

On Samstag, 23. Januar 2010, jida...@jidanni.org wrote:
> *** WARNING: ucf was run from a maintainer script that uses debconf,
> but the script did not pass --debconf-ok to ucf. The maintainer script
> should be fixed to not stop debconf before calling ucf, and pass it this
> parameter. For now, ucf will revert to using old-style, non-debconf
> prompting. Ugh!

So using ucf wronly results in seriously buggy behaviour (not using debconf 
for user prompting)? I think this is also a serious bug in ucf, besides being 
a normal bug in the package using ucf. 

Or am I missing something?


regards,
Holger


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

Bug#566592: ITP: freehep-graphicsio-tests -- FreeHEP GraphicsIO Test Library

[Gabriele Giacone]

Package: wnpp
Severity: wishlist
Owner: Gabriele Giacone <1o5g4...@gmail.com>

* Package name: freehep-graphicsio-tests
  Version : 2.1.1
  Upstream Author : The FreeHEP team 
* URL : http://java.freehep.org/
* License : LGPL-2.1+
  Programming Lang: java
  Description : FreeHEP GraphicsIO Test Library

 The VectorGraphics package of the  FreeHEP Java Library enables any Java
 program to export to a variety of vector graphics formats as well as bitmap
 image formats. Among the vector formats are PostScript, PDF, EMF, SVF, and
 Flash SWF, while the image formats include GIF, PNG, JPG and PPM.
 The package uses the standard java.awt.Graphics2D class as its interface
 to the user program. Coupling this package to a standard Java program is
 therefore straightforward. It also comes with a dialog box which allows you
 to choose between all the formats mentioned above and set specific parameters
 for them.
 .
 FreeHEP is a collection of Java libraries used in High Energy Physics.
 .



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#566593: ITA: purple-plugin-pack - 30 useful plugins for pidgin

[Felix Geyer]

Package: wnpp
X-Debbugs-CC: debian-devel@lists.debian.org

The old maintainer of purple-plugin-pack, Benjamin Seidenberg, is
apparently not active anymore. The currently packaged version is from
November 2007 (uploaded in March 2008).
In July 2009 I packaged a new version of purple-plugin-pack and sent
him the changes I made. After an inital response I haven't heard from him.

I'd like to adopt the package to keep it up-to-date with new upstream
versions and to convert the package to modern dh 7 rules.

An inital version of my packaging work is already in Ubuntu:
https://launchpad.net/ubuntu/+source/purple-plugin-pack/2.6.2-0ubuntu1

Regards,
Felix





-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ucf was run from a maintainer script that uses debconf...

[Steve Langasek]

On Sun, Jan 24, 2010 at 01:09:38AM +0100, Holger Levsen wrote:

> On Samstag, 23. Januar 2010, jida...@jidanni.org wrote:
> > *** WARNING: ucf was run from a maintainer script that uses debconf,
> > but the script did not pass --debconf-ok to ucf. The maintainer script
> > should be fixed to not stop debconf before calling ucf, and pass it this
> > parameter. For now, ucf will revert to using old-style, non-debconf
> > prompting. Ugh!

> So using ucf wronly results in seriously buggy behaviour (not using debconf 
> for user prompting)? I think this is also a serious bug in ucf, besides being 
> a normal bug in the package using ucf. 

> Or am I missing something?

It's not a bug in 'cat' that you can invoke it from a maintainer script in a
way that violates the policy on user interaction.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: ucf was run from a maintainer script that uses debconf...

[Henrique de Moraes Holschuh]

On Sat, 23 Jan 2010, Steve Langasek wrote:
> On Sun, Jan 24, 2010 at 01:09:38AM +0100, Holger Levsen wrote:
> > On Samstag, 23. Januar 2010, jida...@jidanni.org wrote:
> > > *** WARNING: ucf was run from a maintainer script that uses debconf,
> > > but the script did not pass --debconf-ok to ucf. The maintainer script
> > > should be fixed to not stop debconf before calling ucf, and pass it this
> > > parameter. For now, ucf will revert to using old-style, non-debconf
> > > prompting. Ugh!
> 
> > So using ucf wronly results in seriously buggy behaviour (not using debconf 
> > for user prompting)? I think this is also a serious bug in ucf, besides 
> > being 
> > a normal bug in the package using ucf. 
> 
> > Or am I missing something?
> 
> It's not a bug in 'cat' that you can invoke it from a maintainer script in a
> way that violates the policy on user interaction.

Unless it is a particular version of "cat" that knows when it is invoked by
a maintainer script, and on top of that, knows when it is invoked in a wrong
way that would force it to violate Debian policy...

The real question is: which causes the least amount of long-term damage: try
to recover, or abort with extreme prejudice to force whatever is misusing
ucf to be fixed ASAP?

I don't claim to have an answer to that question, btw.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ucf was run from a maintainer script that uses debconf...

[Holger Levsen]

On Sonntag, 24. Januar 2010, Steve Langasek wrote:
> > Or am I missing something?
> It's not a bug in 'cat' that you can invoke it from a maintainer script in
> a way that violates the policy on user interaction.

Right, thanks.



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

Bug#566616: ITP: libjreleaseinfo-java -- Create a Java source file during build process

[Per Wawra]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: libjreleaseinfo-java
Version: 1.3.0
Upstream Author: http://jreleaseinfo.sourceforge.net/team-list.html
URL: http://jreleaseinfo.sourceforge.net/
License: Apache 2.0
Description: Create a Java source file during build process

JReleaseInfo is an Ant Task which creates a Java source file during the
build process. This class provides getter methods to the program
version, the build number or any other information you have defined.
Optionally this data can be shown in a window.

I'm currently creating a package for this tool.
The current state can be seen on Mentors.

This package is needed because libl2fprod-common-java depends on it and
that package is needed for tvbrowser.

http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=libjreleaseinfo-java
http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=libl2fprod-common-java
http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=tvbrowser






signature.asc
Description: OpenPGP digital signature

Bug#566615: ITP: libl2fprod-common-java -- modern user interface widgets for swing

[Per Wawra]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: libl2fprod-common-java
Version: 7.3
Upstream Author: L2FProd.com 
URL: http://www.l2fprod.com/common/
License: Apache 2.0
Description: L2FProd.com Common Components - modern user interface
widgets for swing

Swing has lot of components built-in but still some are missing. This
project provides the developer community with these missing components,
components inspired (copied?!) from modern user interfaces.

Build-Depends:
 ant-optional
 libcommons-collections-java
 libcommons-logging-java
 libjcalendar-java
 libjreleaseinfo-javaITP by me, see mentors
 libnachocalendar-java
 libspring-richclient-java   I am unable to build this

I'll package this because l2fprod-common-tasks is needed to build the
TV-Browser package.
http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=tvbrowser

Upstream download:
https://l2fprod-common.dev.java.net/files/documents/1218/53087/l2fprod-common-7.3-20070317.zip

The zip-file only contains the pre-build jar- and java-files.
Files to build the project can be obtained from CVS.

I built a package with springrcp disabled:
http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=libl2fprod-common-java

CVS:
cvs -Q -d:pserver:gu...@cvs.dev.java.net:/cvs export -f -r COMMON_7_3
l2fprod-common

l2fprod-common builds the following jar-packages:
 l2fprod-common-all.jar
 l2fprod-common-directorychooser.jar
 l2fprod-common-outlookbar.jar
 l2fprod-common-shared.jar
 l2fprod-common-springrcp.jar
 l2fprod-common-totd.jar
 l2fprod-common-buttonbar.jar
 l2fprod-common-fontchooser.jar
 l2fprod-common-sandbox.jar
 l2fprod-common-sheet.jar
 l2fprod-common-tasks.jar





signature.asc
Description: OpenPGP digital signature

Bug#566614: RFP: libspring-richclient-java -- A Java GUI Framework based on Springsource

[Per Wawra]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: libspring-richclient-java
Version: 1.1.0
Upstream Author: The spring-richclient team
(http://spring-rich-c.sourceforge.net/1.1.0/team-list.html)
URL: http://spring-rich-c.sourceforge.net/
License: Apache 2.0
Description: A Java GUI Framework based on Springsource

The Spring Rich Client Project (RCP) is a sub-project of The Spring
Framework. Spring-RCP's mission is to provide an elegant way to build
highly-configurable, GUI-standards-following rich-client applications
faster by leveraging the Spring Framework, and a rich library of UI
factories and support classes. Initial focus is on providing support for
Swing applications but a goal of Spring-RCP is to be view agnostic as
much as possible.

SVN:
https://spring-rich-c.svn.sourceforge.net/svnroot/spring-rich-c/tags/spring-richclient-1.1.0/spring-richclient/

Needed for building l2fprod-common-springrcp.jar and
l2fprod-common-all.jar in the libl2fprod-common-java package.

I tried package this lib, but am unable to build it.




signature.asc
Description: OpenPGP digital signature