Bug#1027431: RFP: vim-nim -- Nim language support for Vim

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: vim-nim
  Version : 1.1.2+git2021.a15714f (or persuade upstream to
   tag releases more often...)
  Upstream Contact: Zahary Karadjov 
* URL : https://github.com/zah/nim.vim
* License : Expat (MIT)
  Programming Lang: Vim (+ Python)
  Description : Nim language support for Vim

nim.vim provides:
 * Syntax highlighting
 * Auto-indent
 * Build/jump to errors within Vim
 * Project navigation and Jump to Definition (cgats or
   compiler-assisted idetools)
for the Nim programming language.



I think this package may be useful, since there is currently
no Vim support for the Nim language in Debian, see bug [#1027002],
not even for syntax highlighting.

[#1027002]: 

I hope someone is willing to package this addon soon.
Thanks to anyone volunteering to do so and maintain it in Debian!

Bug#1020577: RFP: warewulf4 -- operating system provisioning platform for Linux

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: warewulf4
  Version : 4.3.0
  Upstream Author : Gregory Kurtzer  and others from HPCng 
community
* URL : https://warewulf.org/
* License : BSD-3-clause
  Programming Lang: Go
  Description : operating system provisioning platform for Linux

Long description

Warewulf is an operating system provisioning platform for Linux that is
designed to produce secure, scalable, turnkey cluster deployments that
maintain flexibility and simplicity.
.
Since its initial release in 2001, Warewulf has become the most popular
open source and vendor-agnostic provisioning system within the global
HPC community. Warewulf is known for its massive scalability and simple
management of stateless (disk optional) provisioning.
.
Warewulf leverages a simple administrative model centralizing administration 
around virtual node images which are used to provision out to the cluster 
nodes. This means you can have hundreds or thousands of cluster nodes all 
booting and running on the same, identical virtual node file system image.

Additional information
==
This package would be useful to manage HPC (High Performance Computing)
clusters (or other kinds of clusters), where many nodes boot from a
limited number of system images. These OS images may be updated and/or
modified and then propagated to the associated nodes.

Please note that this is a complete rewrite in Go (with different
license) with respect to version 3 (see bug #919494). Hence,
this RFP bug report should not be merged with the other one.

Bug#919508: ITP: warewulf -- systems management suite for Linux clusters

[Francesco Poli]

On Sat, 2 Jan 2021 14:08:45 -0600 Brian Smith  
wrote:

[...]
> This fell by the wayside due to the reasons discussed in this bug.
> Changing to RFP.

That's very sad.
Thanks anyway for starting the packaging effort.

Is your incomplete work in progress stored somewhere (for instance in a
public version control repository), so that other people interested can
take advantage of what you have already done?

Is there a better alternative to warewulf?
[Perceus] seems to be a basically dead project.
I am not aware of any other similar systems...
What are you currently using to manage an HPC cluster, if I may ask?

[Perceus]: see <http://moo.nac.uci.edu/~hjm/Perceus-Report.html>



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpFQojHeQSZW.pgp
Description: PGP signature

Bug#919508: ITP: warewulf -- systems management suite for Linux clusters

[Francesco Poli]

Hello Brian,
I wonder what's the status of the work in progress packaging of
warewulf.

I would be very happy to see it properly packaged and included in the
official Debian main archive.

Please let me know.
Thank you for what you have done so far and for what you are doing!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpqwdvmmVUC7.pgp
Description: PGP signature

Bug#941842: RFP: vimoutliner -- script for building an outline editor on top of Vim

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: vimoutliner
  Version : 0.4.0 (or some more recent git commit...)
  Upstream Author : Steve Litt ,
Noel Henson 
* URL : https://github.com/vimoutliner/vimoutliner
* License : mostly GPL-2 with some scripts under GPL-3
and some under BSD-3-clause
  Programming Lang: Vim
(+ Perl, Python, Ruby, AWK, Javascript for
 auxiliary scripts)
  Description : script for building an outline editor on top of Vim

 Vimoutliner provides commands for using the Vim text editor as an
 outline editor, to organize text hierarchically into discrete
 sections.


This package is really useful (I use it on a daily basis to manage
todo lists and the like...).
It has been [in Debian] for a long time, but it has been recently
[removed] from unstable and testing. I would be really really grateful
to anyone who volunteers to reintroduce it into Debian!

[in Debian]: 
[removed]: 


The reasons for the removal are listed in the removal page.
In the following, I comment each of them:

 * last MU in 2009
   → OK, this package (like any other!) needs to be properly maintained.
 At least, it should be kept up-to-date with respect to upstream
 releases... I hope whoever volunteers to reintroduce it into Debian
 is willing to commit.

 * last 3 uploads are NMUs
   → Likewise, bug reports should be dealt with, of course. From a quick
 look at the BTS, it looks like the package does not receive a great
 number of bug reports, anyway...

 * last upstream release in 2014
   → Upstream does not release too often, which can mean less effort
 is needed on the Debian package maintainer's side... The git
 repository on github seems to anyway receive updates (in the form
 of commits) from time to time, so I would not call this project
 "dead upstream", just "relaxed upstream"...

 * python2-only
   → This is the main issue to be fixed, as far as I can see. Upstream
 needs to be persuaded to switch from Python2 to Python3. But the
 good news is that Python seems to be used only for some auxiliary
 converter scripts (just one in package version 0.3.4+pristine-9.3
 included in Debian buster, some more in the latest upstream code
 on github): these converter scripts are not essential for the
 core functionality of the package and may even be temporarily
 excluded from the Debian package, until ported to Python3...

 * low popcon
   → This should not be in itself a reason to remove a package from
 Debian, in my humble opinion. Just an aggravating factor, so
 to speak...

I really hope that someone will soon step in and reintroduce the
package into Debian.
Many thanks to anyone willing to do so!

Bug#924766: RFP: webext-uppity -- toolbar button to "go up" on the web

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: webext-uppity
  Version : 2.1
  Upstream Author : arantius https://arantius.com/
* URL : https://github.com/arantius/uppity
* License : Expat
  Programming Lang: JavaScript
  Description : toolbar button to "go up" on the web

Navigate up one level (directory) on the web.  URLs are arranged
in a way similar to a file system, with other well defined pieces.
Uppity will remove an in-page anchor, the querystring,
the file, and the last directory in that order, whichever is first
found.  The keyboard shortcut ALT-Up will also navigate this way.

The toolbar button is controlled like any other toolbar button. Right click on 
your toolbar, choose Customize, and then just drag-and-drop the Uppity button 
to where you like it.




This package may be useful as a replacement for xul-ext-uppity,
which was removed because of the incompatibility with recent Firefox:
https://tracker.debian.org/pkg/uppity
https://tracker.debian.org/news/1015889/removed-158-5-from-unstable/

The rewrite as a WebExtension was mentioned in the bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906869

I hope someone is willing to package the new version.
Thanks for your time!

Bug#461486: RFP: luxcorerender -- physically based and unbiased rendering engine

[Francesco Poli]

Control: retitle -1 RFP: luxcorerender -- physically based and unbiased 
rendering engine


* Package name: luxcorerender
  Version : 2.0
  Upstream Author : David "Dade" Bucciarelli <dade...@gmail.com>
Jean-Philippe Grimaldi  <jean...@via.ecp.fr>
Jens Verwiebe <i...@jensverwiebe.de>
Tom "Tomb" Bech <tom.b...@gmail.com>
* URL : https://luxcorerender.org/
* License : Apache-2.0
  Programming Lang: C++
  Description : physically based and unbiased rendering engine

LuxCoreRender is a physically based and unbiased rendering engine.
Based on state of the art algorithms, LuxCoreRender simulates the flow
of light according to physical equations, thus producing realistic
images of photographic quality.



I noticed that the upstream project has slightly changed name and URL,
so I thought I could re-title the RFP bug report and update the info...

This rendering engine looks very promising.
I hope someone will package it for inclusion in Debian!



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpbzpDWslxB7.pgp
Description: PGP signature

Bug#896130: RFP: vim-julia -- Vim plugin for Julia support

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: vim-julia
  Version : N/A
  Upstream Author : Carlo Baldassi  and others
* URL : https://github.com/JuliaEditorSupport/julia-vim
* License : Expat
  Programming Lang: Vim script
  Description : Vim plugin for Julia support

julia-vim is a plugin for programming in Julia. It adds a number of useful
features to help you in writing Julia code.
.
The plugin provides:
* basic support for editing Julia files (automatic filetype detection,
  indentation, syntax highlighting)
* support for the matchit plugin
* support for Julia block-wise movements (i.e. jumping around between
  Julia blocks like if/end, function/end etc.) and block text-objects
* facilities for conversion of LaTeX entries to Unicode symbols which
  mimic and extend what the Julia REPL and the IJulia notebook
  interface do (optionally, this functionality can be used with all
  file types, not just Julia files)




I think this package may be useful to make the user's life easier,
while editing Julia code.
I hope someone will package and maintain it in Debian, it would
be really great. Thanks to anyone willing to do so!

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[Francesco Poli]

On Sat, 31 Mar 2018 16:39:53 +0200 W. Martin Borgert wrote:

> Upstream seems to make good progress:
> http://lists.qt-project.org/pipermail/pyside/2018-March/002557.html

Moreover, if I read the [announcement] correctly, it seems that PySide2
is going to be renamed as "Qt for Python" and adopted as official Qt
bindings for Python...

[announcement]: 
<https://blog.qt.io/blog/2018/04/13/qt-for-python-is-coming-to-a-computer-near-you/>

I really hope someone with good Python Debian packaging skills will
soon package pyside2 for inclusion in Debian!
This will be greatly appreciated.

Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpgZ84N845K1.pgp
Description: PGP signature

Bug#888981: RFP: vim-vimtex -- modern Vim plugin for editing LaTeX files

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: vim-vimtex
  Version : N/A
  Upstream Author : Karl Yngve Lervåg 
* URL : https://github.com/lervag/vimtex/
* License : Expat
  Programming Lang: Vim script
  Description : modern Vim plugin for editing LaTeX files

vimtex is a Vim plugin that provides support for writing LaTeX
documents. It is based on LaTeX-Box and it shares a similar goal: to
provide a simple and lightweight LaTeX plugin. It has been rewritten
from scratch to provide a more modern and modular code base.
.
See  for some more
comments on the difference between vimtex and other LaTeX plugins
for Vim.



I think this package may be useful to enhance the user experience
when editing LaTeX documents with Vim. Especially since it also
extends the Vim syntax highlighting for LaTeX, adding support
for a number of LaTeX packages (such as amsmath, and so forth...).

I hope someone is willing to package and maintain it in Debian.
Thanks a lot to anyone volunteering to do so!

Bug#883867: [Pkg-vala-maintainers] Anyone interested in packaging bookworm?

[Francesco Poli]

On Sun, 28 Jan 2018 20:21:01 +0100 Emilio Pozuelo Monfort wrote:

> On 27/01/18 19:06, Francesco Poli wrote:
> > Hello Debian Vala package maintainers!
> > 
> > I filed an RFP bug report for boorworm, a small e-book reader (written
> > in Vala).
> > For further details, see bug #883867.
> > 
> > Is anyone interested in packaging it?
> > I would really appreciate it.
> 
> The team only maintains the language (and related modules), not random apps
> written in Vala.

What I meant was "is anyone reading this mailing list interested in
packaging it as a single maintainer?".
I am searching for someone familiar with the Vala language and its
ecosystem, so that creating and maintaining the package would not
require an excessive burden.

> Why don't you maintain it yourself?

Because, unfortunately, I lack the time to package and maintain it and,
above all, to learn Vala and its libraries...   :-(


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpo5dppVIFVU.pgp
Description: PGP signature

Bug#883867: Anyone interested in packaging bookworm?

[Francesco Poli]

Hello Debian Vala package maintainers!

I filed an RFP bug report for boorworm, a small e-book reader (written
in Vala).
For further details, see bug #883867.

Is anyone interested in packaging it?
I would really appreciate it.

Thanks for considering.
Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp1mjFZmlsAm.pgp
Description: PGP signature

Bug#883867: RFP: bookworm -- simple, focused eBook reader

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: bookworm
  Version : 0.9.1
  Upstream Author : Siddhartha Das 
* URL : https://babluboy.github.io/bookworm/
* License : GPL-3+
  Programming Lang: Vala
  Description : simple, focused eBook reader

 Read the books you love without having to worry about the different
 format complexities.
 The current version of Bookworm (v0.9) supports eBooks in the
 following file formats: EPUB, PDF, MOBI, CBR, CBZ.
 .
 Key features for library management and reading in Bookworm:
 1. Toggle between a grid view and a list view for the library.
Sort, filter, and edit metadata.
 2. Easy, simple layout to read books. Three reading profiles.
Bookmarks. Full screen mode.
 3. Info button to access information about contents, bookmarks,
search results.
 4. Customization of cache, library view, font family, reading
profiles, directories to watch.


Other relevant information:

I think this package may be useful, because fbreader risks being
removed from Debian (see bug #874867): when this happens, we risk
being left without a simple lightweight e-book reader in Debian
(I've considered calibre, but it seems to be a huge package with
countless dependencies, which would bloat my systems with hundreds
of megabytes of extra packages). Bookworm looks like a possible
alternative to FBReader.

Please note that there seems to be a (somewhat outdated, I should
say) PPA for Ubuntu:
https://launchpad.net/~bookworm-team/+archive/ubuntu/bookworm
I am not sure whether this may be a starting point for the Debian
package.

I hope someone is willing to package Bookworm for Debian.
Thanks a lot to anyone who steps in!

Bye.

Bug#793057: ITP: godot -- open source MIT licensed game engine

[Francesco Poli]

On Mon, 7 Aug 2017 21:43:43 -0400 Kienan Stewart wrote:

> I've had a first pass at creating a package for godot :
> https://mentors.debian.net/package/godot
[...]
> Once I find some time to clear up the lintian warnings, I'll do
> the RFS procedure
[...]

Hello Kienan,
I am a Debian user and contributor interested in seeing Godot packaged
for Debian.

I am afraid I won't have time to actively helping you out in the
packaging effort, but I would like to throw some suggestions in...


I read your three comments on the above-cited mentors.d.o page.


As far as the possible-gpl-code-linked-with-openssl Lintian warning
is concerned, I guess it's really caused by the debian/* licensing.
The general suggestion here is to license debian/* files not only in a
DFSG-free manner, but also at least as permissively as the upstream
software package.
Since Godot is mainly released under the terms of the Expat (MIT)
license, I would recommend you to re-license the debian/* files under
those same terms.

Moreover, I noticed that the upstream github repository includes
a file (named COPYRIGHT.txt) which (except for an initial comment)
seems to be formatted following the machine readable debian/copyright
file specification.
That file could be a good starting point to build the actual
debian/copyright file for the Debian package, of course without
forgetting to check against the actual package content!

I think that thirdparty/* projects should be purged from the orig.tar
archive (after making them unused, obviously!).
If you manage to do so, then you should not need to document their
licensing status. You should just document that they have been removed
by repacking the orig.tar archive...


Regarding the godot2 / godot3 split: if the two are installable side
by side, with no conflict whatsoever, and they are mutually
incompatible, then I think they should be packaged separately as godot2
and godot3, with distinct executable binaries.
But I would first concentrate on one version only (the stable one,
or maybe the alpha one, assuming it is usable enough: you get to
decide...).


Regarding the man pages, I would recommend you report upstream that
they are missing. If upstream developers do not consider this to be
a bug, I would suggest you to write the man pages on the basis of
upstream documentation and to contribute them back upstream
(under the same licensing terms as Godot).
Please see
https://www.debian.org/doc/debian-policy/#manual-pages


That's all, I hope my comments may be of some help.

Thank you for your effort to package Godot for Debian!
Looking forward to seeing the package uploaded to unstable
and ready to be tested.

Bye!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpsIiN3qaNFd.pgp
Description: PGP signature

Bug#751339: RFP: ath9k-htc-firmware -- free firmware for Atheros AR7010/AR9271 wireless adapters

[Francesco Poli]

On Fri, 23 Jan 2015 17:51:55 +0100 Raphael Hertzog wrote:

[...]
> Looking more closely, https://github.com/qca/open-ath9k-htc-firmware
> generates two firmwares: htc_7010.fw and htc_9271.fw
> 
> Both of which are already available in firmware-atheros (albeit under a
> non-free license though, it dates back to before the license change
> apparently).
> 
> So what we actually want is to move them to firmware-free...

Hello,
I stumbled upon this RFP bug, which was converted into an ITP by Paul.

Is there any progress in properly packaging these two DFSG-free
firmware files for inclusion in Debian main?
It would be very nice to have them in firmware-free!

Please let me know, thanks for your time.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpj1ZtKxLHV8.pgp
Description: PGP signature

Bug#852179: RFP: xul-ext-quicklocaleswitcher -- browser plugin to switch language (for UI, spell checker, website content)

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: xul-ext-quicklocaleswitcher
  Version : 1.7.8.5.1
  Upstream Author : Martijn Kooij a.k.a. Captain Caveman
* URL : 
https://addons.mozilla.org/en-US/firefox/addon/quick-locale-switcher/
* License : MPL-1.1 or GPL-2+ or LGPL-2.1+
  Programming Lang: JavaScript and XUL
  Description : browser plugin to switch language (for UI, spell checker, 
website content)

This extension allows you to quickly switch to a different language
(User Interface, Spell Checker Dictionary and Website content) in your
Mozilla application.

 - why is this package useful/relevant?
 
I think this extension may be handy to quickly alter the website content
language, without modifying the general Firefox preferences (and then having
to revert the change...).

Please package this Firefox extension for inclusion in Debian.
Thanks for your time and helpfulness!

Bye.

Bug#289632: RFP: brlcad -- BRL-CAD is a constructive solid geometry (CSG) solid modeling computer-aided design (CAD) system

[Francesco Poli]

Control: merge 705640 816543


On Wed, 2 Mar 2016 19:27:53 + shirish शिरीष wrote:

> Package: wnpp
> Severity: wishlist
> 
> * Package name: brlcad
>   Version : 7.24.2
>   Upstream Author : Army Research Laboratary
> * URL : brlcad.org
> * License : BSD, LGPL
>   Programming Lang: C, C++, Tcl
>   Description : BRL-CAD is a constructive solid geometry (CSG)
> solid modeling computer-aided design (CAD) system
> 
> BRL-CAD is a constructive solid geometry (CSG) solid modeling
> computer-aided design (CAD) system. It includes an interactive
> geometry editor, ray tracing support for graphics rendering and
> geometric analysis, computer network distributed framebuffer support,
> scripting, image-processing and signal-processing tools.

Hello, there are already other three (merged) RFP bugs open for BRL-CAD.
I am merging this fourth bug with the others.

I hope someone will finally convert these bugs into ITP bugs and create
the package... Thanks to anyone who is willing to step in.

Bye.
 

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpFRSb_D3eVD.pgp
Description: PGP signature

Bug#814352: ITP: veracrypt -- Cross-platform on-the-fly encryption

[Francesco Poli]

On Thu, 18 Feb 2016 05:02:37 + Mike Gabriel wrote:

> On  Mi 17 Feb 2016 21:49:54 CET, Francesco Poli wrote:
[...]
> > Please send the updated debian/copyright file...
> >
> 
> Oh, I must have forgotten to attach that file. Here it comes.

Well, the so-called VeraCrypt License is just the TrueCrypt License
version 3.0 + the Apache License version 2.0.
Since both licenses apply, the situation is not really different from
the one we have discussed in the previous messages of this thread...

Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpzUcGz8J1sd.pgp
Description: PGP signature

Bug#814352: ITP: veracrypt -- Cross-platform on-the-fly encryption

[Francesco Poli]

On Wed, 17 Feb 2016 11:39:00 + Mike Gabriel wrote:

[...]
> (taking debian-edu-pkg-team @ Alioth into the discussion loop, as that  
> would be the maintainer team for VeraCrypt in Debian)

OK, fine.

> 
> On  Mi 17 Feb 2016 00:17:28 CET, Francesco Poli wrote:
> 
> > On Wed, 10 Feb 2016 18:07:48 +0100 Mike Gabriel wrote:
> >
> > [...]
> >>  1.
> >>  Is VeraCrypt suitable for the non-free section of Debian?
> >
> > I am not sure: the TC-3.0 license is still fairly unclear (at least
> > to my eyes), so I cannot really speculate on its possible
> > implications...
> 
> Hmmm... ok. I think the ftpmasters would be glad about some guidance  
> on why you see veracrypt (not the TC 3.0 license, see below) unfit for  
> Debian non-free. I have already uploaded VeraCrypt to Debian  
> NEW/non-free and it is waiting approval/rejection from an ftpmaster.

I didn't say that veracrypt is clearly unfit for the non-free archive.

I said that the TC-3.0 license is unclear, and that I am consequently
not sure about the possibility to distribute a package including code
under such a license (even in the non-free archive).

I hope I clarified what I meant.

> 
> Also, it'd be interesting if the upstream people of VeraCrypt can  
> apply any change(s) to the upstream sources, their VeraCrypt license  
> or whatever, to make the software fit at least for Debian non-free.

If VeraCrypt upstream developers (IDRIX, I suppose) are in good terms
with the copyright holders for the Truecrypt version they forked from
(TrueCrypt Developers Association, I suppose) and can persuade them to
agree to a re-licensing of the code-base, the outcome could be
definitely interesting.
Everything re-licensed under the terms of the 3-clause-BSD license
would be a huge win for everyone, since it would mean the possibility
to upload veracrypt to Debian main (assuming no other showstopper comes
up).

[...]
> >>  3.
> >>  The new upstream maintainer also states that all novelties of the code
> >>  are licensed under the Apache-2.0 license, but as long as any line from
> >>  the original code sticks out, the licensing of the code is governed by
> >>  the original Truecrypt 3.0 license, right?
> > [...]
> >
> > Then I am not sure I understand why the debian/copyright file draft
> > you sent states
> >   Files: *
> >   Copyright: 2003-2011, TrueCrypt Developers Association
> >  2013-2014, IDRIX
> >   License: TC-3.0 or Ms-PL
> >
> > What's Ms-PL ? Shouldn't it be Apache-2.0 ?
> > Moreover, "or" means dual-licensing, but I understand this to be a
> > code-mixing case: I think "and" should be used instead.
> >
> > See
> > https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> > for more details.
> 
> Oh, I am sorry. With this mail, I have attached the latest  
> debian/copyright file as I have it now after having it reworked two  
> days ago. I should have sent an updated copy to debian-legal  
> immediately. Sorry for that.

Mmmmh, I cannot see any attachment. Was it forgotten or lost somehow?

> 
> As it seems, the VeraCrypt upstream people have come up with a new  
> license, the VeraCrypt license. See attached copyright file for details.

Please send the updated debian/copyright file...

[...]
> > Anyway, without looking at any further details, a question arises:
> > why are you packaging veracrypt for the non-free archive? what does
> > it offer that tcplay doesn't?
> >
> > See
> > https://packages.debian.org/sid/tcplay
> > https://tracker.debian.org/pkg/tcplay
> 
> I have checked tcplay and also zulucrypt-gui again. We provide  
> veracrypt to teachers / students at school that come from the Windows  
> realm mainly. For them, it is essential to recognize some pieces of  
> software on our Linux environment that they have become so used to on  
> their Windows machines. VeraCrypt (for formerly TrueCrypt) is such an  
> application. Teachers here in Germany have to encrypt all personal  
> data that they carry around, so they need _one_ cross platform tool  
> for that. I'd be happy to provide that piece of software to other  
> people in Debian (Edu).
> 
> Working on the command line (tcplay) is not an option for the  
> teachers, we support here.

Then I hope someone will develop a GUI front-end for tcplay, if it is so
important for at least one category of users...

> And personally, I just tried out  
> zulucrypt-gui the second time and I could not get it running as  
> non-root. This is probably possible, I did not spend much time on  
> this, but honestly, I prefer a solution that works right away. Also  
> ZuluCrypt feels a little nerdy, not so user friendly as VeraCrypt  
> currently is.

Mmmmh, I see.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpXqMNnPmFZa.pgp
Description: PGP signature

Bug#814352: ITP: veracrypt -- Cross-platform on-the-fly encryption

[Francesco Poli]

On Wed, 10 Feb 2016 18:07:48 +0100 Mike Gabriel wrote:

[...]
>  1.
>  Is VeraCrypt suitable for the non-free section of Debian?

I am not sure: the TC-3.0 license is still fairly unclear (at least
to my eyes), so I cannot really speculate on its possible
implications...

>  .
>  2.
>  I suppose VeraCrypt is not suitable for the main section of Debian
>  as the TC-3.0 license is not DFSG-compliant. I suppose
>  this has not changed for VeraCrypt, compared to TrueCrypt, right?

Personally, I think this package should stay away from Debian main.
As I said, I am not even sure it is safe to be distributed in the
non-free archive.

>  .
>  3.
>  The new upstream maintainer also states that all novelties of the code
>  are licensed under the Apache-2.0 license, but as long as any line from
>  the original code sticks out, the licensing of the code is governed by
>  the original Truecrypt 3.0 license, right?
[...]

Then I am not sure I understand why the debian/copyright file draft
you sent states

  Files: *
  Copyright: 2003-2011, TrueCrypt Developers Association
 2013-2014, IDRIX
  License: TC-3.0 or Ms-PL

What's Ms-PL ? Shouldn't it be Apache-2.0 ?
Moreover, "or" means dual-licensing, but I understand this to be a
code-mixing case: I think "and" should be used instead.

See
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
for more details.


Anyway, without looking at any further details, a question arises:
why are you packaging veracrypt for the non-free archive? what does
it offer that tcplay doesn't?

See
https://packages.debian.org/sid/tcplay
https://tracker.debian.org/pkg/tcplay

I hope this helps a little.
Bye.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp8Acn_CGnej.pgp
Description: PGP signature

Bug#395573: visit: changing back from ITP to RFP

[Francesco Poli]

On Mon, 15 Jun 2015 07:24:31 +0100 Alastair McKinstry wrote:

 
 
 On 13/06/2015 14:58, Francesco Poli wrote:
[...]
  I see that there's very recent activity on the repository.
  Does this mean that you are back to work on visit packaging?!?
  That would be really really great news, and should perhaps be publicly
  announced with a new RFP→ITP bug conversion...   :-)
  I really hope you can confirm this.
 
 Yes. I plan to get visit into Stretch, as it is a requirement for the
 UV-CDAT analysis package,
 which is one of my main goals for stretch.

This is really wonderful news!   :-)
Thanks a lot for confirming.

Please don't forget to change back the RFP bug report to an ITP one,
when you feel it's time to do so.

 
 The main blocker for jessie was VTK6, which I think is (nearly?)
 resolved.  Visit depends on VTK6

Debian jessie has vtk6/6.1.0+dfsg2-6, are you waiting for something
that is fixed in vtk6/6.2.0+dfsg1-1 (currently in NEW)?

[...]
  P.S.: You replied to me privately: is there any special reason? I think
  that the URI for the git repository should be disclosed to the public
  on the RFP bug log... Could you please reply to the bug address, or,
  alternatively, authorize me to forward your reply there?
  Thanks!
 It was not meant to be private, so i've CC'd the bug address.

That's great: many thanks!

Bye.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpdvLw6uNzoK.pgp
Description: PGP signature

Bug#395573: visit: changing back from ITP to RFP

[Francesco Poli]

On Sun, 30 Nov 2014 22:28:17 +0100 Francesco Poli wrote:

 On Mon, 24 Nov 2014 11:49:08 + Alastair McKinstry wrote:
 
 [...]
  Its available at:
  ssh://git.debian.org/git/pkg-visit/pkg-visit.git
 [...]
 
 I seem to be unable to find it:
 
 
   $ git clone ssh://git.debian.org/git/pkg-visit/pkg-visit.git
   Cloning into 'pkg-visit'...
   fatal: '/git/pkg-visit/pkg-visit.git' does not appear to be a git repository
   fatal: Could not read from remote repository.
   
   Please make sure you have the correct access rights
   and the repository exists.
 
 
 Please note that I can access git.debian.org via SSH:
 
   $ ssh git.debian.org uname -a
   Linux moszumanska 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u1 x86_64 
 GNU/Linux
 
 
 Where am I going wrong?
 

Once again, Alastair: could you please tell us where is the git
repository for your packaging work?

Please reply.
Thanks for your time!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpDPxuDwR6AE.pgp
Description: PGP signature

Bug#289632: RFP: brl-cad -- Open Source Solid Modelling software

[Francesco Poli]

Control: merge 289632 705640


On Wed, 17 Apr 2013 22:29:00 +0100 root wrote:

 Package: wnpp
 Severity: wishlist
 
 * Package name: brl-cad
   Version : 7.22.0
   Upstream Author : d...@brlcad.org
 * URL : http://brlcad.org
 * License : LGPL, BSD
   Programming Lang: c
   Description : Open Source Solid Modelling software

I see that there are three RFP bugs open for BRL-CAD.
Two of them are already merged with each other; I am merging in the
third bug.

I hope someone will step in and convert these RFP bugs into an ITP bug!
Thanks for your time.

Bye.


-- 
 http://www.inventati.org/frx/
 fsck is a four letter word...
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpiuxTw7YL7O.pgp
Description: PGP signature

Bug#395573: visit: changing back from ITP to RFP

[Francesco Poli]

On Mon, 24 Nov 2014 11:49:08 + Alastair McKinstry wrote:

[...]
 Its available at:
 ssh://git.debian.org/git/pkg-visit/pkg-visit.git
[...]

I seem to be unable to find it:


  $ git clone ssh://git.debian.org/git/pkg-visit/pkg-visit.git
  Cloning into 'pkg-visit'...
  fatal: '/git/pkg-visit/pkg-visit.git' does not appear to be a git repository
  fatal: Could not read from remote repository.
  
  Please make sure you have the correct access rights
  and the repository exists.


Please note that I can access git.debian.org via SSH:

  $ ssh git.debian.org uname -a
  Linux moszumanska 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u1 x86_64 GNU/Linux


Where am I going wrong?


-- 
 http://www.inventati.org/frx/
 fsck is a four letter word...
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpk8Ifccrp2i.pgp
Description: PGP signature

Bug#395573: visit: changing back from ITP to RFP

[Francesco Poli]

On Thu, 06 Nov 2014 14:48:24 +0100 Christophe Trophime wrote:

 On Wed, 30 Jul 2014 10:32:34 +0100 Alastair McKinstry 
 alastair.mckins...@sceal.ie wrote:
  This is a note to say I have been working on visit packaging, but am
  unlikely to complete
  before December due to completing a PhD.  VisIt packaging has been
  mostly delayed
  awaiting vtk6 to be properly integrated and packaged in Debian (thus not
  requiring
  a separate visit-vtk).
  
  I have uploaded my work to date to alioth.debian.org (pkg-visit) where
  is can be downloaded
  via git.debian.org:/git/pkg-visit/pkg-visit.git
  
  
 
 It seems that the git repository pkg-visit is no longer accessible.
 Could you confirm?
[...]

Dear Alastair,
could you please help Christophe Trophime and me in finding the git
repository where you uploaded your packaging work?

I could not find it listed in
https://anonscm.debian.org/cgit/

I did find:
https://alioth.debian.org/projects/pkg-visit/
but the SCM Repository link takes me to
https://alioth.debian.org/scm/?group_id=100926
which is apparently accessible for alioth registered users only.
This is strange...

After logging in to Alioth, I could view the page describing the access
to the git repository: it mentions the Developer Git Access via SSH,
which is claimed to be for project developers only, and then
illustrates the Git Repository Browser with a link to
https://alioth.debian.org/scm/browser.php?group_id=100926
which, however, shows a

404 - No such project


Now I am really puzzled: where is the git repository?:-/

Please let us know.
Thanks for your time!



-- 
 http://www.inventati.org/frx/
 fsck is a four letter word...
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpQutC6lij9M.pgp
Description: PGP signature

Bug#727085: Now we don't depend on the weird libevent patch

[Francesco Poli]

On Sun, 29 Dec 2013 14:46:50 +0100 Faidon Liambotis wrote:

 On Sun, Dec 22, 2013 at 12:03:38AM +0100, Francesco Poli wrote:
 Not really, in my opinion.
 I think it's a valid rejection reason for anything that is not the
 reference PHP implementation published and copyrighted by the PHP Group.
 
 Personally, I consider the PHP License non-free even for PHP itself,
 but that's another story:
 https://lists.debian.org/debian-legal/2005/11/msg00272.html
 
 Just to clarify, since Paul may not be accustomed with Debian's
 structure or your involvement: this is your opinion

Sure, that's why I said personally.

I also added but that's another story, meaning that my side-note
talked about a fact that will probably have *no* effect on Debian
decision-making process. 

 but you're not a
 member of the Debian project

True: I could have said that more explicitly, even though I have never
claimed otherwise.
I apologize if the lack of explicit clarification caused any
confusion about this.

 and you're certainly not the decision maker
 for DFSG-freeness.

Once again true: I just pointed out a well known rejection reason that,
*in my own personal opinion*, could apply to the present case.

 
 The maintainer (and, possibly, sponsoring Debian Developer) is the first
 line of defense, and ultimately the decision is up to the ftp-master
 team[...] as part of the power of processing the NEW queue and accepting
 packages into Debian, a power that is delegated from the project leader.

That's my understanding of Debian procedures, too.

 
 PHP is in the archive and is licensed under the PHP License to my
 knowledge, so the current ftp-masters' stance is that it's a perfectly
 acceptable license for inclusion into Debian.

Yes, ftp-masters clearly think that the reference PHP implementation
copyrighted by the PHP Group is acceptable for Debian main.
I personally disagree, but, as I said, that's another story...

 
 There is zero evidence suggesting that HHVM is not going to be accepted
 in Debian for the licensing reasons that you stated and there is, in
 fact, evidence to the contrary. Please avoid suggesting so -or if you
 do, explain that you're not part of the decision process- and possibly
 frightening perfectly good upstreams, or asking them to do more work,
 especially when they've proved themselves to be very willing to
 collaborate with us.

I am not sure I agree with you on this.
In my *own personal* opinion, there's a possibility that something which
is not the reference implementation of the PHP language (the
implementation developed and copyrighted by the PHP Group) could be
rejected, if licensed under the terms of the PHP License.
It's true that the cited reject FAQ talks about PHP add-on packages,
but then explains that the problem is that this license talks only
about PHP, the PHP Group, and includes Zend Engine, so its not
applicable to anything else.
See again https://ftp-master.debian.org/REJECT-FAQ.html

Hence, I expressed my concern about this *possible* rejection reason.

That fact that the parts licensed under the terms of the PHP License
are derived from PHP itself may mitigate the issue or even eliminate
it, from the ftp-masters' point of view.
But please note that this fact surfaced *after* I had expressed my
concern.

Frankly speaking, I don't see any clear evidence that this issue is
non-existent. I was concerned about it, so I thought I could warn
people upfront and see whether it could be (more or less easily) solved
or worked around.

Once again, I apologize if anything I said was not crystal clear and
generated any confusion.

I reiterate my gratitude to the friendly and helpful upstream
developers.


Bye.


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpMr3EJXQKNO.pgp
Description: PGP signature

Bug#727085: Now we don't depend on the weird libevent patch

[Francesco Poli]

On Sun, 29 Dec 2013 15:22:09 +0100 László Böszörményi (GCS) wrote:

 On Sun, Dec 29, 2013 at 2:46 PM, Faidon Liambotis parav...@debian.org wrote:
  On Sun, Dec 22, 2013 at 12:03:38AM +0100, Francesco Poli wrote:
  Personally, I consider the PHP License non-free even for PHP itself,
  but that's another story:
  https://lists.debian.org/debian-legal/2005/11/msg00272.html
  That's seems to be an old email, things may changed a bit since then.

Not much, as far as I know.

The current version of the PHP License is still 3.01 and I am not aware
of any other licensing exception or additional permission granted by
the PHP Group over their PHP reference implementation.

I think that my old license analysis still holds.

 
  Just to clarify, since Paul may not be accustomed with Debian's
  structure or your involvement: this is your opinion but you're not a
  member of the Debian project and you're certainly not the decision maker
  for DFSG-freeness.
  It seems he _is_ connected with Debian. At least apt-listbugs[...]
 developed and maintained by him.

Yes, I am the current maintainer and developer of apt-listbugs, but
I am *not* a Debian Project member: I am an external contributor.

 
  PHP is in the archive and is licensed under the PHP License to my
  knowledge, so the current ftp-masters' stance is that it's a perfectly
  acceptable license for inclusion into Debian.
  I think he meant PHP License is not free for _other_ software than
 PHP itself.

Actually, I personally think even PHP itself is non-free.
But, as previously mentioned, ftp-masters disagree with me: they think
the reference PHP implementation is acceptable for Debian main.

 But I'm neither a legal person and will let the FTP
 Masters decide on this. I know one of them personally, may ask him in
 advance for a legal standpoint.
 I'm still interested about HHVM, will retry its packaging next year.

Good, thanks again.

Bye.

-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpELbhxZjEDt.pgp
Description: PGP signature

Bug#727085: Now we don't depend on the weird libevent patch

[Francesco Poli]

On Sun, 29 Dec 2013 22:42:43 + Paul Tarjan wrote:

[...]
 Francesco, I honestly thought you
 were speaking officially and we would be rejected.

Once again, if I gave the impression to speak as an official Debian
Project spokesperson, I apologize for the confusion.
My messages were full of in my opinion, I think, Personally, and
so forth: I thought it was clear I was just expression my own personal
viewpoint.

 When you didn't reply
 to my email asking What should I do? I didn't know what to think...

I think I did reply...

Anyway, sorry if anything I said caused confusion.


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpK_dmThQauM.pgp
Description: PGP signature

Bug#727085: Now we don't depend on the weird libevent patch

[Francesco Poli]

On Sat, 21 Dec 2013 23:09:18 + Paul Tarjan wrote:

[...]
 What would you like me to do?

Since, as you said, hhvm includes code derived from the reference PHP
implementation copyrighted by the PHP Group, I am afraid that it
wouldn't be trivial to get rid of the PHP License...

Would it be feasible to replace the code derived from the official PHP
with an independent clean room re-implementation released under the
terms of the 3-clause BSD license?

Otherwise, I don't see many other strategies, unless you manage to
persuade the PHP Group to re-license the official PHP under more
general and DFSG-free terms, such as the 3-clause BSD license...


That's my own viewpoint on this subject.


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp0lSeWVqt8q.pgp
Description: PGP signature

Bug#727085: Now we don't depend on the weird libevent patch

[Francesco Poli]

On Mon, 16 Dec 2013 19:43:37 + Paul Tarjan wrote:

 I'd like to revive this bug now that our libevent plans are solidified.

Good, thanks for getting back to work on the inclusion of hhvm into
Debian!

[...]
 
 What else should I be doing to get this packaged up for inclusion in
 debian?

Do you mean apart from persuading the copyright holder (Facebook, Inc.)
to re-license hhvm under more general DFSG-free terms, such as the
3-clause BSD license?
Your help in getting this issue solved would be highly appreciated, I
think.
Please re-read  http://bugs.debian.org/727085#60
for further details on the licensing issue.

 My method of packaging our release is very clowny (I compile the
 binary and then copy it into a directory with the skeleton for the package
 and then build that with dpkg -b) so I'd rather someone else with more
 debian experience build a proper package for us.

I think László (who reads us in Cc) is still interested in packaging
hhvm for inclusion in Debian.
At least the bug is still an ITP bug and still owned by László, hence,
unless he has just changed his mind, he should be still willing to work
on the packaging...

I suggest you to get in touch with László and ask him whether and how
you can help.

Thanks for being a Debian-friendly upstream developer and for offering
to help!

Bye.


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpAgaf4QMPla.pgp
Description: PGP signature

Bug#727085: Now we don't depend on the weird libevent patch

[Francesco Poli]

On Sat, 21 Dec 2013 20:42:37 + Paul Tarjan wrote:

 That rejection reason is pretty squarely aimed at people writing
 applications in the PHP language and makes sense for them.

Not really, in my opinion.
I think it's a valid rejection reason for anything that is not the
reference PHP implementation published and copyrighted by the PHP Group.

Personally, I consider the PHP License non-free even for PHP itself,
but that's another story:
https://lists.debian.org/debian-legal/2005/11/msg00272.html

[...]
 
 As for the direct question. Much of our extension code was directly
 imported from php-src so we will absolutely be unable to relicense
 that portion. Untangling our contributions from the php-src ones is a
 very arduous task since there are many bug fixes to their code (some
 upstreamed, some not) as well as API changes and data structure
 replacements. We are happy with the php license so releasing the
 whole package under the same umbrella makes development much easier.

Please let me understand: do you mean that hhvm includes code derived
from the reference PHP implementation published and copyrighted by the
PHP Group?


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131222000338.5f0864ba18d0188211293...@paranoici.org

Bug#570709: hhvm / hiphop-php: will it be rejected by Debian due to inappropriate licensing?

[Francesco Poli]

Hello Paul and hello László,
I've just stumbled upon your ITP bugs about hhvm and hiphop-php.

First of all, are these two bugs about the same piece of software?
Should the two bugs be merged?

This piece of software seems to be interesting: thanks for working
on its inclusion into Debian.

I have a concern, though.
If I understand correctly, this project is an interpreter or (JIT)
compiler for the PHP language, but is not PHP itself (that is to say,
it's not the reference implementation of the PHP language, developed
and copyrighted by the PHP Group).
Nonetheless, it is released under the terms of the PHP License v3.01
and the Zend Engine License.

As far as I know, this is ground for a reject from Debian.
Please see https://ftp-master.debian.org/REJECT-FAQ.html
(PHP License point).

I would strongly recommend to persuade the copyright holder (Facebook,
Inc.) to re-license under more general DFSG-free terms, such as the
3-clause BSD license: https://spdx.org/licenses/BSD-3-Clause

Please let me know.

Thanks for your time!
Bye.

-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpIPMNlFV5lz.pgp
Description: PGP signature

Bug#395573: Added wiki page on status

[Francesco Poli]

On Sat, 18 Jun 2011 17:05:50 +0200 Francesco Poli wrote:

 On Wed, 27 Apr 2011 15:35:51 +0100 Alastair McKinstry wrote:
[...]
  I've added a wiki page to describe the current state of packaging:
  http://wiki.debian.org/DebianScienceVisitPackaging
  
  I will be uploading the work in progress to a VCS within Debian.
 
 I've just taken a look at the wiki page and I must say that I am
 impressed!
 It seems that things are really progressing now.
 
 I cannot stress enough how much I am happy to read such an update.
 Thank you very much for your time and for your efforts: they are
 *really* appreciated!
 
 Looking forward to seeing VisIt included in Debian!
 Bye.

Hi again Alastair,
any news on this front?

I haven't seen much progress on the Debian wiki page lately...
But a quick look at
http://www.visitusers.org/index.php?title=VTK_Upgrade
seems to suggest that most (if not all) the showstoppers on the VTK side
are gone... Or am I completely off-track?

Have you tested VisIt with libvtk* version 5.8.0-13 (currently in
unstable and testing) or version 5.9.0-1 (currently in experimental)?

Please let me know...


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpwfglClT6Wb.pgp
Description: PGP signature

Bug#632655: ITA: conky -- highly configurable system monitor

[Francesco Poli]

On Thu, 14 Jul 2011 23:14:08 -0700 Vincent Cheng wrote:

[...]
  As I said, I am really happy about your plan.
  I am looking forward to seeing it implemented!
 
  Bye, and thanks again.
 
 I plan on uploading my packaging to collab-maint sometime tomorrow and
 have a source package uploaded to mentors.d.n within the next few
 days. Debian users have been waiting for the latest upstream release
 of Conky for over half a year, so I don't intend to keep them waiting
 much longer. :)

This is terrific news: thanks a lot!   :-)


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpCwcXP4JPnO.pgp
Description: PGP signature

Bug#632655: ITA: conky -- highly configurable system monitor

[Francesco Poli]

On Wed, 13 Jul 2011 16:46:33 -0700 Vincent Cheng wrote:

 On Wed, Jul 13, 2011 at 12:23 PM, Francesco Poli
 invernom...@paranoici.org wrote:
[...]
  I really hope that you manage to adopt it soon and that you are willing
  to move it back to the main archive, by disabling the nvidia support
  (see bug #579102 for the details).
[...]
 
 As a longtime Conky (and Debian) user, I'm definitely willing to make
 sure that Conky is properly maintained in Debian. :)

That's great to hear, indeed!   :-)

 
 I've taken a close look at #579102 and the various ways this issue can
 be fixed, I'm inclined to go with a different method altogether; have
 a source package conky that provides conky-cli and conky-std
 binaries (and the transitional conky package), both compiled without
 the --enable-nvidia flag (so it can be moved to main), as well as a
 new source package named conky-all that provides a conky-all
 binary, with Nvidia support (the status quo; this would go in
 contrib). The transitional conky package would depend on conky-all |
 conky-std (currently it only depends on conky-all), so Debian users
 with contrib enabled would install the former, and those without
 contrib would install the latter.

This sounds like a perfect solution!
Thank you very much for your intention to implement it.

I had thought about something similar, but I didn't dare to suggest it,
since it increases the burden on the maintainer's side. I was afraid
that such a proposal would have never been accepted!   ;-)

 If you want a comparison, I suppose
 this is somewhat similar to how p7zip and p7zip-rar are packaged.

Talking about rar, I really hope theunarchiver is uploaded soon to
unstable... (see ITP bug #619602)...

[...]
 With my solution, Debian users can still install
 Conky without the need for contrib, yet they also have the option to
 install a Conky compiled with --enable-nvidia, if they want to; Ubuntu
 users would not notice any difference.
 
 I'd gladly welcome any comments or suggestions.

As I said, I am really happy about your plan.
I am looking forward to seeing it implemented!

Bye, and thanks again.


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpksVjggSS70.pgp
Description: PGP signature

Bug#632655: ITA: conky -- highly configurable system monitor

[Francesco Poli]

On Tue, 12 Jul 2011 12:16:30 -0700 Vincent Cheng wrote:

 retitle 632655 ITA: conky -- highly configurable system monitor
 owner 632655 vincentc1...@gmail.com
 thanks

Hello Vincent!

I am very happy to see that you decided to adopt conky.
Even more happy to see how quickly you came to the rescue!
Thanks a lot for your willing to help!

I really hope that you manage to adopt it soon and that you are willing
to move it back to the main archive, by disabling the nvidia support
(see bug #579102 for the details).

Once again, many thanks for your intention to help out.

Bye.

-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpVuk5sXxvAA.pgp
Description: PGP signature

Bug#395573: Added wiki page on status

[Francesco Poli]

On Wed, 27 Apr 2011 15:35:51 +0100 Alastair McKinstry wrote:

 Hi,

Hi Alastair!

 
 I've added a wiki page to describe the current state of packaging:
 http://wiki.debian.org/DebianScienceVisitPackaging
 
 I will be uploading the work in progress to a VCS within Debian.

I've just taken a look at the wiki page and I must say that I am
impressed!
It seems that things are really progressing now.

I cannot stress enough how much I am happy to read such an update.
Thank you very much for your time and for your efforts: they are
*really* appreciated!

Looking forward to seeing VisIt included in Debian!
Bye.

-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp2aeFmFEqmQ.pgp
Description: PGP signature

Bug#570621: Parsing output = derivative work? (was: RFS: gnetworktester)

[Francesco Poli]

On Sun, 6 Mar 2011 12:04:35 +0100 W. Martin Borgert wrote:

 (out of curiosity moved to debian-legal)

(I guess you intended to ask to keep the other recipients in Cc: if so,
you should ask explicitly)

 
 On 2011-03-05 23:46, Timo Juhani Lindfors wrote:
  gnetworktester seems to parse the output of nmap and nmap upstream at
  http://insecure.org/nmap/data/COPYING gives me the impression that
  gnetworktester would thus be derivative work.
 
 IANAL, but since when parsing the output of another program
 constitutes a derivative work?

IANAL either, but I don't think that parsing the output of a program
creates a derivative-base relationship...

 Indeed, the forementioned file
 says, a program would be a derivate in the authors
 interpretation of the GPL, if it
 
 
  o Executes Nmap and parses the results (as opposed to typical shell or
execution-menu apps, which simply display raw Nmap output and so are
not derivative works.)
[...]
 
 
 What do the legal experts think about this, especially the
 parsing aspect?

It looks awkward, at least to me.

Even the FSF's interpretation (which stretches the definition of
derivative work quite a bit, in the attempt to defend the copyleft
mechanism of the GNU GPL) seems to assert that there's no derivation
going on, when the two programs communicate at arms length [1].

[1] http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem

I would say that two programs communicate at arms length, when one
executes the other and parses its output... 

Let's anyway wait for the opinion of other debian-legal regulars.


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpLWZ4BKOK8u.pgp
Description: PGP signature

Bug#610623: Nlopt: ITP RFP for the same piece of software

[Francesco Poli]

Hi Christophe!

Thanks for your intention to package NLopt!

It seems there was already an RFP bug for it, though
(bug #589692, in Cc:).
I think the RFP bug should be merged with the ITP one...

Good luck with your packaging effort!

-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp2dmS7GbdLu.pgp
Description: PGP signature

Bug#527151: Your debian e-mail address bounced

[Francesco Poli]

On Wed, 27 Oct 2010 23:58:17 +0200 David Frey wrote:

[...]
 On Sun, Oct 24, 2010 at 07:27:11PM +0200, Francesco Poli wrote:
  I hope the address I am writing to is still working...
 
 Yes, this address still works.

Great! That's a relief!   :-)

 
  I tried to write to you a message, but your @debian.org address
  bounced.
 
 I'm due to time constraints no longer a Debian developer.

That's sad news to learn, indeed.:-(

 
  You can read my message here:
  http://bugs.debian.org/527151#10
 
 I'm still the upstream developer of rpncalc; I have the latest version
 at the moment at my homepage http://homepage.hispeed.ch/david.frey/.

Good, thanks for clarifying!

 
 I am also aware of dc (of course)

Sure, dc is nice, but, unfortunately, lacks scientific functions
(no sine, cosine, logarithms, and so forth).

BTW, it was the lack of scientific capabilities in dc which led me
to find out about rpncalc in the first place!  ;-)

 and extcalc.

Extcalc also seems to be nice, but is not command-line and not RPN
(wait, there's concalc... ouch! unfortunately it's not RPN... even
though it seems to be a planned feature:
http://extcalc-linux.sourceforge.net/features.html ).

For the record, I forgot to add another feature to my desiderata:
I am looking for a command-line, RPN, scientific and arbitrary
precision calculator.
Concalc does not appear to support arbitrary precision calculations...

 
 Thanks,
   David

Thanks to you: now I really hope that someone will soon adopt the
Debian package of rpncalc!


-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp1dcz6y3oUl.pgp
Description: PGP signature

Bug#527151: O: rpncalc -- RPN calculator trying to emulate an HP28S

[Francesco Poli]

On Tue, 05 May 2009 23:20:07 +0200 David Frey wrote:

 I intend to orphan the rpncalc package.
 I am the upstream author.

That's unfortunate: rpncalc is my favorite calculator...   :-(

May I ask you to explain the reason(s) behind your decision to abandon
this package?

Moreover, are you abandoning the Debian package, while willing to go
ahead with upstream developing? Or are you abandoning both the Debian
package and the upstream program?

Are you aware of similar (command-line, RPN, scientific) calculators?

Thanks in advance for any help.

-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpnAPRnTP9nw.pgp
Description: PGP signature

Bug#600879: RFH: apt-listbugs -- tool which lists critical bugs before each apt installation

[Francesco Poli (t1000)]

Package: wnpp
Severity: normal

I request assistance with maintaining the apt-listbugs package.

The other co-maintainer (Ryan Niebur) is currently almost MIA and
finally told me that he no longer wants to be involved in apt-listbugs
maintenance: see http://bugs.debian.org/588636 and
http://git.debian.org/?p=apt-listbugs/apt-listbugs.git;a=commitdiff;h=b999e0ba2f3c03ee367e45d7e8de4abbfe892457
if you want to read the full story...

I would say that the package is generally in a decent shape:
it normally works as intended, lintian does not complain about it,
its non-pending bug count is decreasing
(see http://qa.debian.org/data/bts/graphs/a/apt-listbugs.png),
I usually manage to deal with bug reports and go ahead with developing
work by myself, ...

However, I sometimes need help with Ruby (I am not yet the Ruby expert
I would dream to be!) or with packaging techniques (I am still learning
them!).

Hence, I would like to find someone else who could co-maintain the
package with me.

The ideal candidate

 * has experience with the Ruby language

 * knows how to use Git

 * has Debian packaging experience

 * is willing to dedicate some time to this package (the amount of
   needed time is not big: I will mostly need some review of my work,
   and occasionally some help on stuff I am not too expert at)

Bonus points if the candidate is a DD or a DM, since I have no upload
rights (and hence I would need a sponsor for each upload, in the
absence of a DD or DM co-maintainer).

Thanks in advance to anyone who volunteers!



The package description is:
 apt-listbugs is a tool which retrieves bug reports from the Debian Bug
 Tracking System and lists them. Especially, it is intended to be invoked
 before each upgrade/installation by apt in order to check whether the
 upgrade/installation is safe.
 .
 Many developers and users prefer the unstable version of Debian for its new
 features and packages.  apt, the usual upgrade tool, can break your system by
 installing a buggy package.
 .
 apt-listbugs lists critical bug reports from the Debian Bug Tracking System.
 Run it before apt to see if an upgrade or installation is known to be unsafe.



-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101020213238.4689.51275.report...@homebrew

Bug#599747: ITP: SILO -- A mesh and field I/O library and scientific database

[Francesco Poli]

On Mon, 11 Oct 2010 09:40:46 +0100 Alastair McKinstry wrote:

   On 2010-10-10 21:52, Francesco Poli wrote:
[...]
  The package name should probably be changed in order to avoid confusion
  with the totally unrelatedhttp://packages.debian.org/sid/silo
  Maybe something like llnlsilo would do...
[...]

 Yes, the package needs to be renamed. I think 'silo-llnl' is the best 
 option,
 so people see it is 'a' silo package.

I don't know, I personally get the impression that silo-llnl could be
the LLNL variant of the SPARC boot-loader.
Since this is not the case, I suggested llnlsilo.
Of course, llnl-silo could be chosen, as well.

Anyway, since you are the owner of the ITP bug, you get to choose the
package name, with the constraint that name conflicts must be avoided,
obviously...

Bye, and thanks again.

-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpV5oZhNmIOL.pgp
Description: PGP signature

Bug#395573: Visit: License Problems with SILO

[Francesco Poli]

On Sat, 7 Nov 2009 20:10:07 +0100 Francesco Poli wrote:

 On Sat, 31 Oct 2009 23:34:31 +0100 Francesco Poli wrote:
 
 [...]
  On Sat, 24 Oct 2009 13:20:57 +0100 Alastair McKinstry wrote:
 [...]
   I've been looking at packaging SILO, a mandatory dependency of VisIt.
 [...]
  This seems to be very awkward: a Free Software application (VisIt)
  which links with a non-free library (Silo) by the same authors!
  :-(
[...]
 I got in touch with Silo's upstream.
 They quickly replied in an encouraging manner.
 First thing they told me is that Silo is no longer a mandatory
 dependency for VisIt: they say it's been an *optional* dependency for
 quite some time.
[...]
 I think VisIt could be packaged for Debian (main) with the Silo plugin
 disabled, while we wait for upstream to re-license Silo in a DFSG-free
 manner...
 Does it sound feasible?

Breaking news!!!   :-)

After a bit of persuading by some people (including me!), and after a
long re-licensing process, Silo is now Free Software under a 3-clause
BSD license: see the September 20, 2010 release notes at
https://wci.llnl.gov/codes/silo/release_notes.html
and the Silo-4.8-bsd*tar.gz downloads at
https://wci.llnl.gov/codes/silo/downloads.html

Unfortunately a couple of compression features were not re-licensed and
hence the Free version of Silo lacks some compression capabilities
(again, see the release notes).
Anyway, the rest of the library now does comply with the DFSG!   :-)

This means that we are now looking for someone who volunteers to
package the Silo library!   ;-)


-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpp3RycVaPNY.pgp
Description: PGP signature

Bug#395573: Visit: License Problems with SILO

[Francesco Poli]

On Sun, 10 Oct 2010 20:27:48 +0100 Alastair McKinstry wrote:

[...]
 Congrats!

Thanks, but I think you should really send congratulations and thanks
to LLNL for freeing Silo: I've just done some little pushing in the
right direction...   ;-)

 I've filed the ITP, but the actual packaging may take place after squeeze.

This is terrific news, indeed!   :-)
Thank you very much for volunteering to package Silo!

For those who read this bug report on the BTW web interface, the ITP is
http://bugs.debian.org/599747

 Life is a little busy just now, but I'll get Visit packaged!

Wow!
That's terrific news, for the second time!:-)

Did you manage to solve the issues with up-to-date versions of VTK?
Does VisIt work with current VTK?


-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpmn8KrRZrKf.pgp
Description: PGP signature

Bug#599747: ITP: SILO -- A mesh and field I/O library and scientific database

[Francesco Poli]

On Sun, 10 Oct 2010 20:19:53 +0100 Alastair McKinstry wrote:

 Package: wnpp
 Severity: wishlist
 Owner: Alastair McKinstry mckins...@debian.org
 
 * Package name: SILO
[...]

The package name should probably be changed in order to avoid confusion
with the totally unrelated http://packages.debian.org/sid/silo
Maybe something like llnlsilo would do...

Anyway, thank you very much for volunteering to package this library!

-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgph4V1DSZp2o.pgp
Description: PGP signature

Bug#522243: These two ITP bugs seem to be a duplication of efforts

[Francesco Poli]

Hi all!

Two RFP bugs for the same piece of software?
Both later converted into ITP bugs, but owned by different people?

I think that maybe these two bugs (#522243 and #569961) should be
merged and the two ITP owners could try to cooperate on the packaging
effort...

Dear Williams and Daniel, what's your opinion?

BTW, many thanks to both of you for starting a packaging effort for
this extension!   ;-)


-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpU22opEUMqC.pgp
Description: PGP signature

Bug#395573: VisIt ITP: how's the packaging going?

[Francesco Poli]

On Mon, 25 Jan 2010 10:16:50 + Alastair McKinstry wrote:

 On 2010-01-24 22:34, Francesco Poli wrote:
  Hi Alastair!
 
  Is there any progress on the packaging of VisIt?
[...] 
 Unfortunately I've been swamped with work (and expect to be so for the 
 next 3 months).
[...]
 I hope to get back to it after April.
[...]

Hi again,
did you manage to dedicate some time to VisIt?

I noticed that version 2.0.0 has been released.
Does it build with recent VTK?


-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpbBKKoqnzqZ.pgp
Description: PGP signature

Bug#522243: Important note: where is the source?

[Francesco Poli]

On Fri, 24 Apr 2009 00:42:35 +0200 Francesco Poli wrote:

 For anyone interested to package this iceweasel extension,
 its source code is distributed via CVS, and may be found here:
 http://chrispederick.com/work/user-agent-switcher/source
[...]

No one?
I am still interested in seeing this iceweasel extension packaged for
Debian...

Please, could some volunteer prepare a nice package?


-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp9uQi7rFwmU.pgp
Description: PGP signature

Bug#395573: VisIt ITP: how's the packaging going?

[Francesco Poli]

Hi Alastair!

Is there any progress on the packaging of VisIt?
Could you please provide a status update?

-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpbcCfo840EM.pgp
Description: PGP signature

Bug#395573: Is anyone interested in packaging VisIt?

[Francesco Poli]

Hello debian-science and debian-med lists,

is there anyone willing to package VisIt for Debian?

My RFP (see bug #395573) was converted into an ITP, but later was
converted back into an RFP...
I still think VisIt is an interesting visualization and graphical
analysis tool: the Debian distribution would benefit from having it
included, in my opinion.

Please Cc: me *and* the bug on replies, thanks.


-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpZbHlXwooZM.pgp
Description: PGP signature

Bug#395573: Visit: License Problems with SILO

[Francesco Poli]

On Sat, 31 Oct 2009 23:34:31 +0100 Francesco Poli wrote:

[...]
 On Sat, 24 Oct 2009 13:20:57 +0100 Alastair McKinstry wrote:
[...]
  I've been looking at packaging SILO, a mandatory dependency of VisIt.
[...]
 This seems to be very awkward: a Free Software application (VisIt)
 which links with a non-free library (Silo) by the same authors!
 :-(
 
  
  AFAIK, this is a show-stopper for packaging VisIT.  We could write to  
  LLNL and see if they
  are willing to relinquish this,
 
 I think this should definitely be done.

I got in touch with Silo's upstream.
They quickly replied in an encouraging manner.
First thing they told me is that Silo is no longer a mandatory
dependency for VisIt: they say it's been an *optional* dependency for
quite some time.

Alastair, did you try building VisIt without enabling the Silo plugin?

I think VisIt could be packaged for Debian (main) with the Silo plugin
disabled, while we wait for upstream to re-license Silo in a DFSG-free
manner...
Does it sound feasible?

 
  but since I started this ITP, Paraview has been packaged for
  Debian, and it does my visualisation needs, so I am no longer  
  packaging visit.
  
  Sorry about this,

Alastair, does the above pieces of news change anything with respect to
your willingness to package VisIt?


Please let me know: thanks in advance.

-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpRljsanIDHs.pgp
Description: PGP signature

Bug#395573: Visit: License Problems with SILO

[Francesco Poli]

On Sat, 7 Nov 2009 19:18:39 + Alastair McKinstry wrote:

 Hi,
 
 I contacted VisIt's upstream (via visit-users list) and found the same  
 thing; they are
 correcting the build notes that claim Silo is needed.

Great!  :-)

 
 I hadn't tested it without Silo. I'm trying to build it now, but Visit  
 1.12.0 needs
 VTK 5.0.0c  : I tested against vtk 5.2 which is in Debian, and they're  
 incompatible;

Ouch!  :-(
This is unfortunate.

 LLNL ship a VTK 5.0.0.c (with changes) tarball to build VisIt with; it  
 doesn't build
 on Debian, so back to working on the necessary fixes for visit 1.12.0  
 with Debian's VTK.

Do you feel that many invasive changes are needed?

 
 (Some of these may be in the repo for visit ; they are currently  
 working on visit 2.0
 upstream, but I'm not sure it would be ready for Squeeze).

Where's the repository for VisIt?
I seem to be unable to find it by reading the official website.

Which VCS do they use?

 
 I need to resign up to ITP visit.

Well, if you do not have time, so be it: thanks anyway for trying to do
it.

Do you have a preliminary package somewhere?
Do you feel it could be used as a base for further hacking?



-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpOwdXboh3mE.pgp
Description: PGP signature

Bug#395573: Visit: License Problems with SILO

[Francesco Poli]

retitle 395573 RFP: visit -- interactive parallel visualization and
graphical analysis tool noowner 395573
thanks


On Sat, 24 Oct 2009 13:20:57 +0100 Alastair McKinstry wrote:

 Hi,

Hi!

 
 I've been looking at packaging SILO, a mandatory dependency of VisIt.
 Unfortunately, it contains the following license clause:
 
   Commercialization of this product is prohibited without notifying the
   Department of Energy (DOE) or Lawrence Livermore National Laboratory  
 (LLNL).

Arrgh!  It looks like it really include this clause!!!

This seems to be very awkward: a Free Software application (VisIt)
which links with a non-free library (Silo) by the same authors!
:-(

 
 AFAIK, this is a show-stopper for packaging VisIT.  We could write to  
 LLNL and see if they
 are willing to relinquish this,

I think this should definitely be done.

 but since I started this ITP, Paraview has been packaged for
 Debian, and it does my visualisation needs, so I am no longer  
 packaging visit.
 
 Sorry about this,

I am not especially enthusiast of Paraview, which ships with its own
internal copy of VTK (see bug #495426) and hence does not automatically
benefit of any fix or enhancement is applied to the Debian vtk
package...

Anyway, if Paraview satisfies you, nobody forces you to package VisIt,
of course.
It's a pity that we found out this after so long time since you turned
this RFP into an ITP...  :-(

The commands at the beginning of this message should convert this ITP
back into an RFP.

Bye.

-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp9rf3gU04iJ.pgp
Description: PGP signature

Bug#395573: Visit: License Problems with SILO

[Francesco Poli]

On Sat, 31 Oct 2009 23:34:31 +0100 Francesco Poli wrote:

[...]
 On Sat, 24 Oct 2009 13:20:57 +0100 Alastair McKinstry wrote:
[...]
  I've been looking at packaging SILO, a mandatory dependency of VisIt.
  Unfortunately, it contains the following license clause:
  
  Commercialization of this product is prohibited without notifying the
  Department of Energy (DOE) or Lawrence Livermore National Laboratory  
  (LLNL).
 
 Arrgh!  It looks like it really include this clause!!!

Mmmh, the situation seems to be even worse: from a quick look, I cannot
find any grant of permission in the Silo tar archive: this would imply
that Silo is legally undistributable by anyone other than its copyright
holders...:-(


-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpbxn0vbKRO1.pgp
Description: PGP signature

Bug#395573: Any progress on VisIt packaging?

[Francesco Poli]

On Mon, 14 Sep 2009 21:16:23 +0100 Alastair McKinstry wrote:

 Hi,
 
 Sorry about the delay in responding. I've been busy packaging various  
 dependencies
 (of other packages, not just visit).

That's OK, I was just worried that you could not receive mail...

 
 Currently I've two issues:
 (1) packaging the SILO library needed by VISIT. See
ftp://ftp.llnl.gov/pub/visit/3rd_party/silo060605.sh

Yeah, that's the only mandatory dependency that's currently missing
from Debian, AFAIK.

As an aside, please note that, among the optional dependencies, libcgns
is now included in Debian: see bug #501924 and
http://packages.debian.org/libcgns

 (2) Visit appears to need VTK 5.0.0c, while 5.2 is in Debian unstable.

Definitely, and 5.4.x is on the way: see bugs #509296 and #531989.
I think that everything possible to make VisIt work with VTK 5.2.x
(and then 5.4.x) should be done.
I don't know whether upstream is willing to help with this task: I hope
so, since they are more and more out of date with VTK versions...

 
 I'm working on this now and hope to have it done over the next two  
 eeeks.

Wonderful!
I am really looking forward to see an upload to unstable (or even a
temporary test package).

Thanks for the update and please keep up with the good work!  ;-)


-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpCcuI6Ws16T.pgp
Description: PGP signature

Bug#395573: Any progress on VisIt packaging?

[Francesco Poli]

On Wed, 8 Jul 2009 23:09:18 +0200 Francesco Poli wrote:

 Hi!
 
 How's the packaging of VisIt going?
 Is there any progress?
 
 Have you already packaged (or helped others packaging) the missing
 dependencies?
 
 Please let me know.

Again, any news?


-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpd2ryBln9Ss.pgp
Description: PGP signature

Bug#436492: Open64 packaging: any progress?

[Francesco Poli]

On Mon, 27 Jul 2009 08:34:35 +0200 Gürkan Sengün wrote:

 Francesco Poli wrote:
  On Sun, 26 Jul 2009 04:37:59 +1000 Aníbal Monsalve Salazar wrote:
  
  On Sat, Jul 25, 2009 at 03:35:18PM +0200, Francesco Poli wrote:
  [...]
  How's the packaging going on?
  It was uploaded but was rejected. I'll try to fix the problem with the
  way debian/copyright was done. And then uploaded it again.
  
  Thanks for your quick answer.   :-)
  I hope you manage to get the package accepted soon!
 
 but that was verison 4.0 of open64, i never managed to build the later 
 versions,

Well, then I hope you manage to build the latest version and get it
accepted soon!  ;-)

Bye.

-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpIrIOmr7sGV.pgp
Description: PGP signature

Bug#436492: Open64 packaging: any progress?

[Francesco Poli]

Hi!

I've just found out this interesting DFSG-free compiler.
Thanks for attempting to package it for inclusion in Debian!

I fail to see any recent news in this ITP bug.
How's the packaging going on?
Please let me know.

Have a nice day.

-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpSVsRWN9lKb.pgp
Description: PGP signature

Bug#436492: Open64 packaging: any progress?

[Francesco Poli]

On Sun, 26 Jul 2009 04:37:59 +1000 Aníbal Monsalve Salazar wrote:

 On Sat, Jul 25, 2009 at 03:35:18PM +0200, Francesco Poli wrote:
[...]
 How's the packaging going on?
 
 It was uploaded but was rejected. I'll try to fix the problem with the
 way debian/copyright was done. And then uploaded it again.

Thanks for your quick answer.   :-)
I hope you manage to get the package accepted soon!

Bye.

-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpqdYDzAwvc1.pgp
Description: PGP signature

Bug#395573: Any progress on VisIt packaging?

[Francesco Poli]

Hi!

How's the packaging of VisIt going?
Is there any progress?

Have you already packaged (or helped others packaging) the missing
dependencies?

Please let me know.

-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpE64gz17xbG.pgp
Description: PGP signature

Bug#490705: When will this package hit the archive?

[Francesco Poli]

On Mon, 6 Jul 2009 00:11:12 -0300 Tiago Bortoletto Vaz wrote:

 On Sun, Jul 05, 2009 at 11:04:59PM +0200, Francesco Poli wrote:
  Hi!
  
  Is there any progress on the upload of package rakarrack?
  The ITP bug has been tagged pending for quite some time...
 
 It's waiting for a review from a Debian ftp master:
 
 http://ftp-master.debian.org/new/rakarrack_0.3.0-1.html

Mmmmh, it seems lintian complains with some warnings about your package...


-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpnAz3UqGycy.pgp
Description: PGP signature

Bug#490705: When will this package hit the archive?

[Francesco Poli]

On Mon, 6 Jul 2009 19:43:04 -0200 Tiago Bortoletto Vaz wrote:

 On Mon, 6 Jul 2009 19:27:44 +0200, Francesco Poli wrote
[...]
  Mmmmh, it seems lintian complains with some warnings about your package...
 
 which doesn´t implies the package rejection. It´s just time to wait for a
 human review from Debian, please be patient :) 

Yes, I am well aware that a human review is needed.
Anyway, I think the causes of those lintian warnings should be cured...


-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp19q4LloHPS.pgp
Description: PGP signature

Bug#490705: When will this package hit the archive?

[Francesco Poli]

Hi!

Is there any progress on the upload of package rakarrack?
The ITP bug has been tagged pending for quite some time...

-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp1u11WuGonv.pgp
Description: PGP signature

Bug#522243: Important note: where is the source?

[Francesco Poli]

For anyone interested to package this iceweasel extension,
its source code is distributed via CVS, and may be found here:
http://chrispederick.com/work/user-agent-switcher/source

Thanks to Christoph Goehre for pointing this out [1], inside the
interesting thread [2] that I started on the Mozilla extension
maintainers mailing list

[1] 
http://lists.alioth.debian.org/pipermail/pkg-mozext-maintainers/2009-April/19.html
[2] 
http://lists.alioth.debian.org/pipermail/pkg-mozext-maintainers/2009-April/14.html


-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpPyJ9RPyisD.pgp
Description: PGP signature

Bug#395573: VISIT in Debian

[Francesco Poli]

On Wed, 15 Apr 2009 15:44:24 +0100 Alastair McKinstry wrote:

 Hi,

Hi there!  :)

 
 You submitted an RFP for VISit in Debian.
 Have you done any work on this?

Not really, I have little packaging experience and I do not (yet) feel
to be ready for debianizing VISit.

 we use VISit at work, and I would like  
 to package it for Debian-Meteorology.

I would be *really* happy to see it packaged and included in Debian!
Thank you very much for volunteering to do this job!  :-)

Feel free to convert this RFP into an ITP, if you like.

Bye and thanks again.

-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpIR5t7zj0b6.pgp
Description: PGP signature

Bug#508468: ITP: ssreflect -- small scale reflection extension for the Coq proof assistant

[Francesco Poli]

 and both versions
 are deemed authentic.

Wow!  What happens if the two versions disagree?

[...]
 12.2 So as to ensure coherence, the wording of this Agreement is
 protected and may only be modified by the authors of the License, who
 reserve the right to periodically publish updates or new versions of the
 Agreement, each with a separate number. These subsequent versions may
 address new issues encountered by Free Software.
 
 12.3 Any Software distributed under a given version of the Agreement may
 only be subsequently distributed under the same version of the Agreement
 or a subsequent version.

Mandatory upgrade mechanism: a Licensor cannot choose to license
something under a specific version of this license without also
licensing under future versions.
Not a DFSG-freeness issue, but I would rather avoid adopting a license
with a mandatory upgrade mechanism: software authors, you have been
warned!

[...]
 13.2 Failing an amicable solution within two (2) months as from their
 occurrence, and unless emergency proceedings are necessary, the
 disagreements or disputes shall be referred to the Paris Courts having
 jurisdiction, by the more diligent Party.

This is a choice of venue clause: such clauses have been discussed to
death on debian-legal.  My own opinion is that they are non-free.

 
 
 Version 1.0 dated 2006-09-05.



-- 
 On some search engines, searching for my nickname AND
 nano-documents may lead you to my website...  
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpG7Vhtx4DNE.pgp
Description: PGP signature

Bug#462631: current status

[Francesco Poli]

On Sun, 17 Feb 2008 15:32:21 +0100 Ondrej Certik wrote:

 Hi Francesco,

Hi!  :)

 
 On Thu, Feb 07, 2008 at 12:23:00AM +0100, Francesco Poli wrote:
[...]
  I wonder if you managed to link Paraview against (and make it work
  properly with) libraries already packaged and included in Debian.
 
 Not yet. Currently we are still trying to make it compile on i386 and
 amd64 together with MPI and python. We just succeeded in the compilation
 itself, so at least the package builds now.

I see.

 
 Unfortunately, the python scripting still isn't working at runtime. When
 this is fixed, only then we'll try to build shared libraries and reuse
 as much as possible from Debian to reduce the sice of the paraview
 binary package (currently 100MB).

Really huge!  I hope you soon manage to successfully package it without
the extraneous libraries!

[...]
 If you would like to help us, it'd be awesome.

I'm afraid I do not (yet) have enough packaging experience to help
out...  I should start packaging something easier, first!  ;-)


Bye, and good luck!

-- 
 http://frx.netsons.org/progs/scripts/refresh-pubring.html
 New! Version 0.6 available! What? See for yourself!
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpguHZdls8EB.pgp
Description: PGP signature

Bug#462631: Linking with libraries already in Debian...

[Francesco Poli]

Hi!

Thanks for your ITP bug regarding Paraview!
I hope the packaging is going on well.

I wonder if you managed to link Paraview against (and make it work
properly with) libraries already packaged and included in Debian.

Last time I checked, it seemed Paraview could not be linked with
already installed libraries (without applying heavy modifications).
I think that, from a maintainability/code-duplication point of view,
shipping a special copy of VTK and TclTk just for Paraview would
not be acceptable.  Unfortunately though, last time I checked, Paraview
shipped with special versions of those libraries that had to be
recompiled:
http://public.kitware.com/pipermail/paraview/2006-October/003881.html

I hope the situation has improved in the meanwhile: for instance,
Paraview was going to switch from TclTk to Qt and it seems this
transition has already been completed... Is it now possible to easily
link Paraview against an already installed copy of VTK?
Or did you modify CMakeLists.txt in order to let Paraview compile and
link against debianized VTK?

-- 
 http://frx.netsons.org/progs/scripts/refresh-pubring.html
 New! Version 0.6 available! What? See for yourself!
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgphvNGDLsNRK.pgp
Description: PGP signature

Bug#453907: Mayavi2 seems to be promising

[Francesco Poli]

Hi!

I'm happy that someone is willing to package Mayavi2: it looks
promising.  I'm looking forward to seeing it uploaded to unstable and
migrated to testing.
I hope the packaging is going on well...

-- 
 http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html
 Need to read a Debian testing installation walk-through?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgps6fYKlGgao.pgp
Description: PGP signature

Bug#449205: RFP: stix-fonts -- the Scientific and Technical Information eXchange fonts

[Francesco Poli]

On Sat, 3 Nov 2007 21:50:21 -0400 Michael Gilbert wrote:

[...]
 The license seems open (and similar to other font licenses), but I am
 not sure if it adheres to the DFSG.  Someone in debian-legal will need
 to review.  The text of the license can be found at [7].
[...]
 [7] http://www.aip.org/stixfonts/font_download.jsp

It seems to me that we (debian-legal participants) are already
discussing the DFSG-freeness (or lack thereof!) of STIX fonts.

The thread begins here:
http://lists.debian.org/debian-legal/2007/11/msg0.html

I hope this helps.

-- 
 http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html
 Need to read a Debian testing installation walk-through?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp8J666Zzu4b.pgp
Description: PGP signature

Bug#395573: Build-dependencies

[Francesco Poli]

For anyone interested in packaging VisIt

  [  raise your hands, one at a time, please!  ;-)  ]

I gave a look at http://www.llnl.gov/visit/source.html and
and at http://www.llnl.gov/visit/1.6.1/BUILD_NOTES

It seems to me that VisIt has the following mandatory
build-dependencies:

 * Mesa 5.0   http://packages.debian.org/libgl1-mesa-dev
 * Mesa 6.4.2 http://packages.debian.org/libgl1-mesa-dev
 * Python 2.5 http://packages.debian.org/python
 * Qt X11 3.3.2   http://packages.debian.org/libqt4-dev
 * Qt X11 3.3.8   http://packages.debian.org/libqt4-dev
 * Silo060605 not in Debian?
 * VTK 5.0.0c http://packages.debian.org/libvtk5-dev

Moreover, it seems to have some optional build-dependencies (libraries
that may be linked or else left out, IIUC):

 * Boxlib 2.5 not in Debian?
 * CFITSIO 3006   http://packages.debian.org/libcfitsio3-dev
 * CGNS 2.4-3 not in Debian?
 * ExodusII 4.46  not in Debian?
 * GDAL 1.3.2 http://packages.debian.org/libgdal1-dev
 * H5Part 1.3.3   not in Debian?
 * HDF4 2.4.1 http://packages.debian.org/libhdf4g-dev
 * HDF5 1.6.5 http://packages.debian.org/libhdf5-{serial|lam|mpich}-dev
 * NetCDF 3.6.0   http://packages.debian.org/netcdfg-dev


I thought I should share these findings...

-- 
 http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html
 Need to read a Debian testing installation walk-through?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpt3x3QgoFxh.pgp
Description: PGP signature

Bug#395573: [EMAIL PROTECTED]: VisIt: interactive parallel visualization and graphical analysis tool]

[Francesco Poli]

On Sat, 6 Oct 2007 23:26:44 +0200 (CEST) Andreas Tille wrote:

 On Sat, 6 Oct 2007, Charles Plessy wrote:
 
  is anyone interested in packaging VisIt for Debian?
  Please see RFP bug #395573 [1] (which I'm Cc:ing).
 
 Sounds great.  Added it to the WML page of Debian-Med imaging todo
 list.

Good!
Let's hope that some DD pops up soon volunteering to package VisIt
(mmmh, what about... you?!?  ;-)

[...]
 Many thanks for the hint

Well, you're welcome, but thanks to you all for your work to improve
Debian!


P.S.: I am not a debian-med list subscriber, hence please Cc: me *and*
the bug on replies, thanks.

-- 
 http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html
 Need to read a Debian testing installation walk-through?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpcbbXEAJ7BZ.pgp
Description: PGP signature

Bug#395573: VisIt: interactive parallel visualization and graphical analysis tool

[Francesco Poli]

Hi all,

is anyone interested in packaging VisIt for Debian?
Please see RFP bug #395573 [1] (which I'm Cc:ing).

To get an idea of what this visualization tool is capable of, you
could take a look at its gallery [2].
I think the images are quite impressive and speak for themselves.

[1] http://bugs.debian.org/395573
[2] http://www.llnl.gov/visit/gallery.html


Please Cc: me *and* the bug on replies, thanks.


-- 
 http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html
 Need to read a Debian testing installation walk-through?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpwDHddwFCQy.pgp
Description: PGP signature

Bug#383316: Please vet this modified CC license for uploading FoF music to non-free

[Francesco Poli]

On Sun, 27 May 2007 14:59:49 +1000 [EMAIL PROTECTED] wrote:

 On 5/27/07, Francesco Poli [EMAIL PROTECTED] wrote:
  On Tue, 22 May 2007 15:31:21 -0400 Jason Spiro wrote:
 
  [...]
   So, I took
   http://creativecommons.org/licenses/by-nd-nc/1.0/legalcode
   and made some changes.
 
  Do you have the permission to create a derivative license of
  CC-by-nd-nc-v1.0 ?
  I don't recall which is the Creative Commons policy on modifying
  their licenses.
 
 CC releases their license texts public domain.
 
 http://creativecommons.org/policies:
 Except where noted otherwise below in our Trademark Policy, all
 content on this site is licensed under a Creative Commons Attribution
 license. We do not assert a copyright in the text of our licenses.

Ah, OK: I stand corrected, then.
Sorry for raising a non-existent issue...


-- 
 http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html
 Need to read a Debian testing installation walk-through?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp4hqVi4OXDs.pgp
Description: PGP signature

Bug#383316: Please vet this modified CC license for uploading FoF music to non-free

[Francesco Poli]

On Tue, 22 May 2007 15:31:21 -0400 Jason Spiro wrote:

[...]
 So, I took http://creativecommons.org/licenses/by-nd-nc/1.0/legalcode
 and made some changes.

Do you have the permission to create a derivative license of
CC-by-nd-nc-v1.0 ?
I don't recall which is the Creative Commons policy on modifying their
licenses.

 For example, I changed Creative Commons Legal
 Code to Restricted Media Legal Code.  I didn't use the name Frets
 on Fire there since I don't want people to think the license applies
 to the whole game.  It is only for Tommi Inkila's music.  As another
 example, I removed the trademark-related text.  I hereby release the
 new license text to the public domain.

Do you actually have the authorization to dedicate your derivative
license to the public domain?

I'm puzzled...

-- 
 http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html
 Need to read a Debian testing installation walk-through?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp0KlQYGUSkS.pgp
Description: PGP signature

Bug#383316: Derivative works for songs

[Francesco Poli]

On Sun, 13 May 2007 01:06:01 +0100 (BST) MJ Ray wrote:

 Francesco Poli [EMAIL PROTECTED] wrote:
[...]
  There's another issue with the remaining four songs, though.
  Is their source available?
  I mean: what's the preferred form[1] for making modifications to the
  songs?  Is this form available?
 
 I hope that the scores are available, or a track-by-track recording,
 to avoid any build-depends on Sony ACID Pro 5 in a really clear way.

Mmmh: I don't think it's included in the zip archived previously
referenced.  Each song consists of the following files:

$ file *
guitar.ogg:  Ogg data, Vorbis audio, stereo, 44100 Hz, ~256006 bps, created by: 
Xiph.Org libVorbis I (1.0)
License.txt: ASCII English text, with CRLF line terminators
notes.mid:   Standard MIDI data (format 1) using 2 tracks at 1/96
song.ini:ASCII text, with CRLF line terminators
song.ogg:Ogg data, Vorbis audio, stereo, 44100 Hz, ~256006 bps, created by: 
Xiph.Org libVorbis I (1.0)


 
 However, for debian compilation of the game, isn't the preferred
 source form the mixed recording?  The one used in the build?

We must determine what is the preferred form for making modifications to
the song.  I'm not sure an Ogg Vorbis + MIDI form qualifies...

-- 
 http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html
 Need to read a Debian testing installation walk-through?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpFl1O5AdZVe.pgp
Description: PGP signature

Bug#383316: Derivative works for songs

[Francesco Poli]

On Sun, 13 May 2007 19:11:32 +0200 (CEST) Miriam Ruiz wrote:

 
 --- Francesco Poli [EMAIL PROTECTED] escribió:
 
  We must determine what is the preferred form for making
  modifications to the song.  I'm not sure an Ogg Vorbis + MIDI form
  qualifies...
 
 I think that's quite complex to decide on a single-game basis, as that
 decision might affect most of other games, as well as synthetic
 videos, music all around the archive and most of media files in fact.

It *must* be decided on a case-by-case basis: no general rule can be
drawn from a specific decision, because what is source in one case, can
be compiled form in another.

This holds even for programs, not only for audio, video and similar
stuff.
Imagine we decided that C code is always source: that would be a wrong
oversimplification, because there are quite some cases where C code is
generated from some other form (typical examples: parser code generated
from a grammar description by Bison, or C code automatically translated
from a higher level language).

Hence, each case has to be examined to determine which is the source.

[...]
 At some point I guess we should need to reach a decision about this,
 which will probably involve massive bug-filling if we decide .mpg,
 .avi, .mp3, .ogg files and so do not qualify enough as modifiable
 files,

As I said, we cannot reach any reasonable *general* conclusion about a
format.
In some cases an Ogg Vorbis file qualifies as source, because maybe it's
the preferred form for making modification to a work.  In other cases,
an Ogg Vorbis file does not qualify.

[...]
 If not, it's time to start a big debate about
 what is considered source form in art (which, in fact, I think it'll
 be quite an interesting topic).

Art does not need any special-casing (and anyway the boundaries of art
are quite blurred: some programs can be so elegant to be considered
art...).
Source code is defined as the form of a work which is preferred for
making modifications to it.

 
 Greetings,
 Miry
 
 PS: I'm not subscribed to debian-legal, so please include me in CC in
 your replies.

P.S.: I am instead subscribed to debian-legal, so please do *not* Cc:
me, as long as debian-legal is in the loop!

-- 
 http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html
 Need to read a Debian testing installation walk-through?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp42GcD4VUhL.pgp
Description: PGP signature

Bug#383316: Derivative works for songs

[Francesco Poli]

On Fri, 11 May 2007 16:05:34 +0100 Matthew Johnson wrote:

 For the Frets on Fire arcade game which we are packaging I have found
 an original artist willing to licence his works under the MIT licence.

That's great news, indeed!  :)

 Four of the five songs are completely original works; the fifth,
 however, whilst being an original composition is inspired by another
 song. The email I have from the artist is below; I think that probably
 this counts as a derivative work, and hence would need permission from
 the original author, but I am not sure.

Mmmmh, the author says

| The song Ryu´s theme is a heavy metal version of the Ryu´s Song in
| the famous videogame Street Fighter 2

I really cannot remember the original Ryu's theme (it's been a looong
time since I last saw Street Fighter 2 in an arcade, and the audio is
usually set pretty low volume in arcades anyway...), hence I'm not
qualified to evaluate by myself.

However, if the author says that it's a metal version of Ryu's theme, I
think he means that the melody is the same, even though the musical
genre is changed.
*If* this is the case, I would call it a cover and hence I'm afraid it
qualifies as an adaptation or derivative work of the original
soundtrack, which is copyrighted by CAPCOM (most probably).

 Obviously debian-legal are not lawyers, but I would appreciate your
 opinions. I could just leave it out to be on the safe side, I could
 leave it in, hope that the ftp-masters accept it and hope that nothing
 comes of it or I could try and get an opinion from someone like SPI.

I would leave it out.


There's another issue with the remaining four songs, though.
Is their source available?
I mean: what's the preferred form[1] for making modifications to the
songs?  Is this form available?

I ask it because I'm convinced[2] that DFSG#2 mandates the distribution
of source, even for works whose license does not mandate it.
Moreover, I see that some of the songs have a comment that claims
Made with Sony ACID Pro 5.0.  Are they made with this proprietary
sequencer[3]?
If this is the case, I'm afraid that those songs Build-Depend on
non-free software...


[1] this is the most widely accepted definition of source code (it's the
one found in the GNU GPL)
[2] however, surprisingly enough, release managers don't seem to agree
with me for non-programmatic works...
[3] http://www.sonycreativesoftware.com/products/acidfamily.asp


-- 
 http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html
 Need to read a Debian testing installation walk-through?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpeXSXrtZEVx.pgp
Description: PGP signature

Bug#412063: ITP: rott -- Rise of the Triad: The HUNT begins

[Francesco Poli]

On Fri, 23 Feb 2007 11:06:16 +0100 Fabian Greffrath wrote:

[...]
 The package will install the GPL'ed game engine and then offer the
 user to automatically download the shareware data files from
 ftp.3drealms.com and install them into the filesystem (similar to
 `quake2-data' or `rocksndiamonds' packages).
[...]

I think that these situations are best handled by creating a game engine
package (rott) and a separate data downloader package (rott-data).
They both have to go in contrib, at best.

The game engine package can be moved to main, as soon as a set of
DFSG-free game data is found and packaged for main.


-- 
 http://frx.netsons.org/progs/scripts/refresh-pubring.html
 Need to refresh your keyring in a piecewise fashion?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpJCKbrJI54n.pgp
Description: PGP signature

Bug#119911: GPLed data?

[Francesco Poli]

On Tue, 20 Feb 2007 15:17:55 + Sam Morris wrote:

 On Wed, 2007-02-14 at 23:52 +0100, Francesco Poli wrote:
  Hi!
  
  One of the difficulties with packaging Aleph One seems to be the
  lack of DFSG-free game data.
  
  I found this set of game data for the Aleph One engine:
Title:  Excalibur: Morgana's Revenge
License:  GNU General Public License (GPL) [according to what is
  claimed on the sf.net project page]
Project Page:  http://sourceforge.net/projects/emr3/
  
  Take into account that I didn't verify anything, hence I don't know
  if they actually make source available for the game data, if they
  actually release all the data in a GPL-compatible way, and so forth.
  But I thought I could point this project out anyway...
  
  I hope this can help.
 
 Thanks for the pointer.

You're welcome!  :)

 I remember playing EMR many years ago and I am
 very happy to see that it has been released under the GPL!

I do not know anything about those games, but I got the impression that
the one I pointed out is a sort of new implementation (EMR3).

I hope that it does not qualify as a derivative work of a pre-existent
proprietary game (it would be if it qualified as a sequel or if it
shared characters with the original, for instance), otherwise we must
check that they obtained proper permissions to distribute the derivative
work under the GNU GPL...

 I guess
 this means that Aleph One can go into main without me having to dust
 off my copy of Anvil... ;)

As I said, the emr3 project is promising, but everything should be
checked and verified before feeling lucky.
Moreover those DFSG-free game data (assuming they actually comply with
the DFSG) must be packaged in order to let Aleph One go into main.

-- 
 http://frx.netsons.org/progs/scripts/refresh-pubring.html
 Need to refresh your keyring in a piecewise fashion?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpmztZv0CVBH.pgp
Description: PGP signature

Bug#119911: GPLed data?

[Francesco Poli]

Hi!

One of the difficulties with packaging Aleph One seems to be the lack
of DFSG-free game data.

I found this set of game data for the Aleph One engine:
  Title:  Excalibur: Morgana's Revenge
  License:  GNU General Public License (GPL) [according to what is
claimed on the sf.net project page]
  Project Page:  http://sourceforge.net/projects/emr3/

Take into account that I didn't verify anything, hence I don't know if
they actually make source available for the game data, if they actually
release all the data in a GPL-compatible way, and so forth.
But I thought I could point this project out anyway...

I hope this can help.

-- 
 http://frx.netsons.org/progs/scripts/refresh-pubring.html
 Need to refresh your keyring in a piecewise fashion?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpvLUfSfsGe5.pgp
Description: PGP signature

Bug#395573: URL for debian-legal thread

[Francesco Poli]

Please note that I've already asked debian-legal to confirm that
the license is suitable for a package in main.

The thread starts at:
http://lists.debian.org/debian-legal/2006/10/msg00209.html

So far there have been no objections...  :-)


-- 
But it is also tradition that times *must* and always
do change, my friend.   -- from _Coming to America_
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpxCfIzyyWT6.pgp
Description: PGP signature

Bug#395573: RFP: visit -- interactive parallel visualization and graphical analysis tool

[Francesco Poli]

Package: wnpp
Severity: wishlist

* Package name: visit
  Version : 1.5.4.060918
  Upstream Author : Lawrence Livermore National Laboratory - University of 
California
* URL : http://www.llnl.gov/visit/
* License : 3-clause BSD license with additional disclaimers 
(http://www.llnl.gov/visit/license.html)
  Description : interactive parallel visualization and graphical analysis 
tool

VisIt is a free interactive parallel visualization and graphical
analysis tool for viewing scientific data.  Users can quickly generate
visualizations from their data, animate them through time, manipulate
them, and save the resulting images for presentations.  VisIt contains
a rich set of visualization features so that you can view your data in
a variety of ways.  It can be used to visualize scalar and vector
fields defined on two- and three-dimensional (2D and 3D) structured and
unstructured meshes.
VisIt was designed to handle very large data set sizes in the terascale
range and yet can also handle small data sets in the kilobyte range.

Supported input data formats:

 * ANALYZE
 * ANSYS
 * BOV (brick of values)
 * Boxlib
 * CGNS
 * Curve2D
 * Ensight Gold
 * Enzo
 * Exodus
 * FITS
 * FLASH
 * FLUENT
 * FVCOM
 * GIS
 * Image
 * NASTRAN
 * NetCDF
 * OpenFOAM
 * PATRAN
 * PLOT3D
 * Protein Databank
 * SAMRAI
 * Silo
 * Spheral
 * STL
 * TecPlot
 * Vis5D
 * VTK
 * Wavefront OBJ
 * Xmdv
 * ZeusMP (HDF4)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#323420: License issues with metasploit-framework

[Francesco Poli]

On Wed, 19 Jul 2006 01:26:14 +0200 Francesco Poli wrote:

 If I manage to review the license completely, I will send my analysis
 to debian-legal only, because I don't think the BTS is the right place
 for license analysis and discussion.
 When a conclusion is reached a link to the list archives can be sent
 as a followup for the bug report...

I don't know if, at present, someone else is still willing to comment on
the license, but, anyway, the thread on debian-legal starts at:
http://lists.debian.org/debian-legal/2006/07/msg00108.html

In particular, my analysis of The Metasploit Framework
License v1.0 can be found here:
http://lists.debian.org/debian-legal/2006/07/msg00127.html
but, please, take a look to the other messages, too.

HTH.


-- 
But it is also tradition that times *must* and always
do change, my friend.   -- from _Coming to America_
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgppdUpbAGG4D.pgp
Description: PGP signature

Bug#323420: License issues with metasploit-framework

[Francesco Poli]

 which is in alpha now. The
 decided to change the license to The Metasploit Framework License
 v1.0.
 http://www.metasploit.com/projects/Framework/msf3/download.html?Release=alpha-r3

Oh my goodness!
Another project that decides they need their own awkward and
incompatible license!

Writing a good license is a really hard task: it requires good lawyers
and a long revision process.  Worse, it can fail even with such things!
Moreover, even when you create a good license, license proliferation is
bad, since it creates barriers that obstruct free software sharing and
reuse.

It would really be appreciated if you tried to persuade upstream to
adopt a well-established and clearly DFSG-free license, instead of
writing their own.

GNU GPLv2 is a good choice.
Even GPLv2/Artistic dual license is good.
Another good choice is the Expat license
(http://www.jclark.com/xml/copying.txt), if copyleft is not regarded as
an important goal.

 
 ===
 The Metasploit Framework License v1.0
 Copyright (C) 2006 Metasploit LLC
[...]
 ===
 
 The webpage requires a click through of this license to get the
 source.
 
 How does this license look? If it is DFSG-free, then the best option
 is probably to package this version.

I didn't find the time to thoroughly analyse the license, but I spotted
at least a choice of venue, which is non-free:

| Any
| litigation related to this License must be filed and heard in the
| courts for Travis County, Texas.

If I manage to review the license completely, I will send my analysis to
debian-legal only, because I don't think the BTS is the right place for
license analysis and discussion.
When a conclusion is reached a link to the list archives can be sent as
a followup for the bug report...

 
 Apologies for dumping everything here, but I want to be clear about
 the legal issues before proceeding.

Pasting the full text of licenses and unclear copyright  permission
notices is the recommended method to get advice from debian-legal, hence
I think you did nothing wrong.

 
 Thanks,

You're welcome!


-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpXVl4pri2b3.pgp
Description: PGP signature

Bug#362652: Apache license 1.1 for non-Apache software

[Francesco Poli]

On Fri, 28 Apr 2006 03:33:27 +0200 Gregory Colpart wrote:

 On Fri, Apr 21, 2006 at 12:42:36AM +0200, Francesco Poli wrote:
Could you confirm me that my package will be DFSG-compliant ?
   
   Not entirely, but it looks like it probably will be.
  
  I don't agree.
  The license under analysis is fully quoted below (for future
  reference). I do *not* think that a work released solely under this
  license can be considered to comply with the DFSG.
 
 To sum up, I hope persuading upstream to do one of following
 actions:
 
 - give permission to Debian project to package his softwares
   (like Apache Fundation for apache-1.3 woody packages [1]),

That way it should go in main, though.
At least, that's my opinion.

 - switch license to Apache license 2.0 like [2],
 - switch licens to 3-clause BSD [3] or Horde BSD-like [4],
 - switch license to GPL [5] like other horde softwares.

All these license changes would make the software clearly DFSG-free.
I hope you can persuade upstream to switch to one of these licenses...


 [1] 
 http://packages.debian.org/changelogs/pool/main/a/apache/apache_1.3.26-0woody6/copyright
 [2] http://www.apache.org/licenses/LICENSE-2.0
 [3] http://www.gnu.org/licenses/info/BSD_3Clause.html
 [4] http://www.horde.org/licenses/bsdl.php
 [5] http://www.horde.org/licenses/gpl.php 


-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpRbNinVbMXt.pgp
Description: PGP signature

Bug#362652: Apache license 1.1 for non-Apache software

[Francesco Poli]

On Sat, 29 Apr 2006 00:57:38 +0200 Francesco Poli wrote:

 On Fri, 28 Apr 2006 03:33:27 +0200 Gregory Colpart wrote:
 
  On Fri, Apr 21, 2006 at 12:42:36AM +0200, Francesco Poli wrote:
 Could you confirm me that my package will be DFSG-compliant ?

Not entirely, but it looks like it probably will be.
   
   I don't agree.
   The license under analysis is fully quoted below (for future
   reference). I do *not* think that a work released solely under
   this license can be considered to comply with the DFSG.
  
  To sum up, I hope persuading upstream to do one of following
  actions:
  
  - give permission to Debian project to package his softwares
(like Apache Fundation for apache-1.3 woody packages [1]),
 
 That way it should go in main, though.
 At least, that's my opinion.

Oooops!   :p
What I actually intended to write was:

  That way it should *not* go in main, though.

Sorry for having incorrectly stated the opposite of what I meant...  :-(


-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpKZvLvgCsaf.pgp
Description: PGP signature

Bug#362652: Apache license 1.1 for non-Apache software

[Francesco Poli]

On Wed, 19 Apr 2006 11:14:30 +0100 MJ Ray wrote:

 Gregory Colpart [EMAIL PROTECTED]
  I want to package Forwards (see my ITP [1]), a non-Apache
  software under Apache License 1.1 [2]).
 
 [2] is not the Apache License 1.1, but is Apache-1.1-like.
 I think your ITP License line is incorrect.

I agree.
The license is definitely similar, but not equal to Apache Software
License, Version 1.1
Actually it's ASLv1.1 with the necessary substitutions to adapt it to
Horde Project's Forwards.


[...]
  Could you confirm me that my package will be DFSG-compliant ?
 
 Not entirely, but it looks like it probably will be.

I don't agree.
The license under analysis is fully quoted below (for future reference).
I do *not* think that a work released solely under this license can be
considered to comply with the DFSG.

| Version 1.0
| 
| Copyright (c) 2002-2004 The Horde Project. All rights reserved.
| 
| Redistribution and use in source and binary forms, with or without
| modification, are permitted provided that the following conditions are
| met:
| 
| 1. Redistributions of source code must retain the above copyright
| notice, this list of conditions and the following disclaimer.
| 
| 2. Redistributions in binary form must reproduce the above copyright
| notice, this list of conditions and the following disclaimer in the
| documentation and/or other materials provided with the distribution.
| 
| 3. The end-user documentation included with the redistribution, if
| any, must include the following acknowledgment:
| 
|This product includes software developed by the Horde Project
| (http://www.horde.org/).
| 
| Alternately, this acknowledgment may appear in the software itself, if
| and wherever such third-party acknowledgments normally appear.
| 
| 4. The names Horde, The Horde Project, and Forwards must not be
| used to endorse or promote products derived from this software without
| prior written permission. For written permission, please contact
| [EMAIL PROTECTED]
| 
| 5. Products derived from this software may not be called Horde or
| Forwards, nor may Horde or Forwards appear in their name,
| without prior written permission of the Horde Project.
| 
| THIS SOFTWARE IS PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED
| WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
| MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
| IN NO EVENT SHALL THE HORDE PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR
| ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
| DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
| GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
| INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
| IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
| OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
| ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
| 
| This software consists of voluntary contributions made by many
| individuals on behalf of the Horde Project. For more information on
| the Horde Project, please see http://www.horde.org/.


The non-free part is, IMO, clause 5.
Actually this clause is basically identical to (the first part of)
clause 4 of PHP license version 3.01: there have been many
discussions[1][2][3][4][5][6][7] about PHP license version 3.01 on
debian-legal.
In a nutshell, this clause is a nasty restriction that goes beyond what
is allowed (as a compromise!) by DFSG#4.
It goes beyond because it forbids an entire infinite class of names for
derivative works, not just one (as allowed by DFSG#4).
Unfortunately only few people on debian-legal seem to agree that this
problem exists, while I see it as crystal clear...


Anyway, If I were you, I would try and persuade upstream to change
license.

Since the current license is a clone of Apache Software License, Version
1.1, you could suggest that they switch to Apache License Version
2.0[8], which is DFSG-free and can be applied unmodified to any work
(not just Apache!).

Alternatively, they could switch to the 3-clause BSD license[9], which
is quite similar to the current license (after dropping clauses 3. and
5.), but DFSG-free.


References:

[1] http://lists.debian.org/debian-legal/2005/10/msg00124.html
[2] http://lists.debian.org/debian-legal/2005/10/msg00127.html
[3] http://lists.debian.org/debian-legal/2006/01/msg00056.html
[4] http://lists.debian.org/debian-legal/2006/01/msg00066.html
[5] http://lists.debian.org/debian-legal/2006/01/msg00339.html
[6] http://lists.debian.org/debian-legal/2006/02/msg00013.html
[7] http://lists.debian.org/debian-legal/2006/04/msg00112.html
[8] http://www.apache.org/licenses/LICENSE-2.0
[9] http://www.gnu.org/licenses/info/BSD_3Clause.html



-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE

Bug#335185: [Fwd: ITP: newmat -- manipulate matrices using standard operations]

[Francesco Poli]

On Tue, 25 Oct 2005 14:48:14 -0500 David Moreno Garza wrote:

 Forwarding from a wnpp bug.
 
 debian-legal is the best place for discussing this.
[...]

On Mon, 24 Oct 2005 21:53:47 -0500 Dirk Eddelbuettel wrote:

[...]
 Let me add that I had quite a few email exchanges back then with
 newmat's author. Based on the fairly regular contact I had with him,
 there is no doubt in my mind that Robert would a) welcome inclusion of
 newmat in Debian,

Good.

 and b) consider newmat to be obviously open source.

The license is too vague and unclear, but, if the author wants his
software to be DFSG-free, we (at debian-legal) can suggest an
appropriate license change.

[...]
 From the newmat10 manual:
 -
  1.1 Conditions of use
[...]
 
 There are no restrictions on the use of newmat except that I take no
 liability for any problems that may arise from this use.

OK, no restrictions on use.

 
 I welcome its distribution as part of low cost CD-ROM collections.

Here it seems that permission to distribute is granted, but only as part
of low cost CD-ROM collections.
No permission to distribute via other means seems to be granted.
Non-free.

 
 You can use it in your commercial projects.

Nothing new, since the license already stated there are no restrictions
on use.

 However, if you distribute
 the source, please make it clear which parts are mine and that they
 are available essentially for free over the Internet.

OK, do not misrepresent.

 
 PLEASE UNDERSTAND THAT THERE MAY STILL BE BUGS AND ERRORS. USE AT YOUR
 OWN RISK. I TAKE NO RESPONSIBILITY FOR ANY ERRORS OR OMISSIONS IN THIS
 PACKAGE OR FOR ANY MISFORTUNE THAT MAY BEFALL YOU OR OTHERS AS A
 RESULT OF ITS USE.

Common desclaimer of responsibility, even if phrased in a weird manner.

 
 Please report bugs to me at robert (at) statsresearch.co.nz
 
 When reporting a bug please tell me which C++ compiler you are using,
 and what version. Also give me details of your computer. And tell me
 which version of newmat (e.g. newmat03 or newmat04) you are using.
 Note any changes you have made to my code. If at all possible give me
 a piece of code illustrating the bug. See the problem report form.
 
 Please do report bugs to me.

These sentences are kind requests and do not really belong in a license.

The license ends here.

There is no explicit permission to distribute (except as part of low
cost CD-ROM collections).
There is no explicit permission to modify or distribute modified
versions.
Non-free.


If the author really meant to make his software Free, it seems that he
wanted a simple permissive non-copyleft license.
I would suggest upstream author to change the license to the Expat
(a.k.a. MIT) license: http://www.jclark.com/xml/copying.txt

This would solve all the licensing issues: newmat would become DFSG-free
and reach the goals of license simplicity and permissiveness.

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpm9bzEQTBA1.pgp
Description: PGP signature

Bug#305112: Any progress?

[Francesco Poli]

On Wed, 24 Aug 2005 13:21:15 -0500 Carlos C Soto wrote:

 Hello Francesco.

Hi!  ;-)

 
 Sorry to take so much time to answer but I was out of my place/work.

No problem!  :)

 Yes, I made a few months ago a preliminary package for gcolor2 and I
 beleive I had to update it.

Yes, now version 0.4 is out...

 Check this personal URL: http://www.eclipxe.com.mx/debian/gcolor2/

I will take a look, or maybe I'll wait for an updated version...
Thanks.

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpDMVv0Da88Z.pgp
Description: PGP signature

Bug#305112: Any progress?

[Francesco Poli]

Hi Carlos!

How's the packaging going on?
Have you got any preliminary gcolor2 package to be tested?

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgprNIEY55feL.pgp
Description: PGP signature

Bug#278940: ITP: socket++ -- lightweight convenience library to handle low level BSD sockets in C++

[Francesco Poli]

On Sat, 30 Oct 2004 21:49:42 -0400 Dan Weber wrote:

 The new upstream (Herbert) is placing this in the LICENSE file as of
 the next release which will clarify for other distributions and
 packagers.

This is great news, indeed.

Obviously, the new upstream must make sure that each copyright holder
agrees on this clarification...

-- 
  Today is the tomorrow you worried about yesterday.
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpsEUyEbr8NH.pgp
Description: PGP signature