Bug#776944: ITP: fitscut -- extract cutouts from FITS image format files

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-as...@lists.debian.org,debian-devel@lists.debian.org

* Package name: fitscut
  Version : 4.16
  Upstream Author : William Jon McCann
* URL : http://acs.pha.jhu.edu/general/software/fitscut/
* License : GPL
  Programming Lang: C
  Description : extract cutouts from FITS image format files

fitscut is designed to extract cutouts from FITS image format files.
FITS, PNG, and JPEG output types are supported. When multiple input
files are specified and the output type is PNG or JPEG the resulting
image is an RGB color image.

I will setup a git repository at
http://anonscm.debian.org/git/debian-astro/packages/fitscut.git

Best

Ole


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

Re: Any way to apply patch on some archs only?

[Thorsten Glaser]

On Thu, 29 Jan 2015, Clint Byrum wrote:

> Fair enough?

In some cases, the patch to fix the behaviour for some
architectures may-or-may-not-(but-this-has-to-be-proven)
hurt performance or something on other architectures
while retaining correctness. In these cases, always if
the language does not have #ifdef, but even sometimes if
it does, it’s better to use the one correct, slower on
some architectures, codepath than to over-optimise – for
example, see the recent discussion here about unaligned
data access on various architectures, where it was even‐
tually agreed to use the “safe” codepath everywhere, to
avoid UB and other pitfalls.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1502031533420.21...@tglase.lan.tarent.de

Re: motd handling in jessie

[Wouter Verhelst]

On Fri, Jan 23, 2015 at 08:18:33PM -0800, Russ Allbery wrote:
> Josh Triplett  writes:
> 
> > Please, no.  Under normal circumstances, the only dynamic bit of the
> > motd comes from uname, and only changes on reboot; updating it via cron
> > just wastes cycles and adds noise to syslog.
> 
> > I'm not particularly convinced that even the existing uname line has
> > much value.  So what about this: why don't we move all of that machinery
> > to an update-motd package or similar (priority optional), which can hook
> > into PAM as desired to display its message, and have the default motd of
> > the base system be completely static, with nothing run at boot *or*
> > login?
> 
> I do feel like we're losing some value by not showing users the uname
> information by default,

What value is that?

I've always thought of updating /etc/motd as a bad idea.

> and I'd like to still see us update that at boot. I certainly agree that
> running shell code from PAM by default is not a good idea.
> 
> That said, by far the best way to handle MOTD is to write out a static
> file using whatever configuration management system you're using, based on
> all the information that it gathers about the system (via something like
> ohai or facter).

Exactly. In the few cases where it helps (such as the example of "30k
machines" that I saw flow by on this thread), you can easily use
whatever config management system you're using to manage that file. On
my laptop, I usually *know* what kernel I'm running, if I even care.

If we're going to be producing dynamic output by default, I'd much
rather see us do something where that dynamic output is actually shown
in a dynamic way. I don't think we need to be showing the uname output
at all, but *if* we're going to continue doing so, we should just put
"uname -a" in /etc/profile and be done with it. That gets us the same
result at far less complexity and far less WTF moments for people who
are familiar with other unixish operating systems.

/etc/motd is supposed to be a *static* file. Installing all kinds of
contraptions to make it a dynamically static file is just horrible.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


signature.asc
Description: Digital signature

Bug#776992: ITP: python-dicttoxml -- Convert a Python dict or other data type to XML

[Russ Allbery]

Package: wnpp
Severity: wishlist
Owner: Russ Allbery 

* Package name: python-dicttoxml
  Version : 1.5.8
  Upstream Author : Ryan McGreal 
* URL : https://pypi.python.org/pypi/dicttoxml
* License : GPL 2.0
  Programming Lang: Python
  Description : Convert a Python dict or other data type to XML

Supports converting a wide variety of item and collection Python types,
as well as iterable and dict-like objects, into XML, with arbitrary
nesting for the collections.  Items with a datetime type are converted
into ISO format strings.

Packaging this as a prerequisite for moto.


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

Re: Bug#776992: ITP: python-dicttoxml -- Convert a Python dict or other data type to XML

[Russ Allbery]

Russ Allbery  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Russ Allbery 

> * Package name: python-dicttoxml
>   Version : 1.5.8
>   Upstream Author : Ryan McGreal 
> * URL : https://pypi.python.org/pypi/dicttoxml
> * License : GPL 2.0
>   Programming Lang: Python
>   Description : Convert a Python dict or other data type to XML

Actually, never mind.  There was a license conflict with moto (which was
the whole driver for packaging this), since moto is under Apache 2.0.  As
it turns out, the latest master revision of moto doesn't use this library
at all, so I'll just package that instead.

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


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

Bug#777000: ITP: limereg -- Lightweight Image Registration. Commandline application for image registration (automatically aligning two images with similar content).

[Roelof Berg]

Package: wnpp
Severity: wishlist
Owner: Roelof Berg 

* Package name: limereg
  Version : 1.1.0
  Upstream Author : Roelof Berg 
* URL : https://github.com/RoelofBerg/limereg
* License : BSD
  Programming Lang: C++
  Description : Lightweight Image Registration. Commandline application for
image registration (automatically aligning two images with similar content).

I developed this application as part of a scientific project. It offers 2D,
grayscale, rigid image registration with a powerful
derivative based approach and operates very fast and memory efficient (compared
to traditional derivative-based aproaches).

OpenCV is used to load and store the image data. The user can either output the
registered image (image aligned/shifted/rotated upon another one)
or it can output the numeric registration result (x-shift, y-shift and
rotation).

I want to develop this application further and want to maintain the .deb
package. Furthermore
I will publish the functionality as a library in an additional lib.deb and lib-
dev.deb package.
When the lib.deb package has been released I want to add it to imagemagik. This
would enable people to register images just by using imagemagik :)

I'm not aware of any other package offering image registration (if at all) in
this speed and quality. Our mathematical aproach (regarding speed and memory
usage) is very new and
it is extremely unlikely that any other package can offer it. We just published
it in a scientific magazine.
Preprint: http://www.embedded-software-
architecture.com/Berg2014Highly_Preprint.pdf

Applications:
HDR-Photograpy, Industrial Imaging (compare an actual photography to a
reference picture), Medical Imaging (align images from different times or
sensors), motion detection/compensation, and many more ...

I will put as much effort in the packaging as necessary. As I'm an experienced
software developer (e.g. Embedded Linux) my skills will be sufficient.
The effort is low as it is only a small command line tool (yet ;) and I can do
it alone.

However, I'm new to Open Source and to the packaging. Do I need a sponsor to
get the package accepted ? Also a review from an experienced packager would be
required as this is my first step into Open Source contribution.


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