Bug#647995: ITP: cellprofiler -- quantitatively measure phenotypes from images automatically
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: cellprofiler Version : 2.0 Upstream Author : Broad Institute * URL : http://www.cellprofiler.org * License : GPL Programming Lang: Python Description : quantitatively measure phenotypes from images automatically CellProfiler is a software designed to enable biologists without training in computer vision or programming to quantitatively measure phenotypes from thousands of images automatically. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2008083724.12423.90240.report...@hpdesk.malat.net
Bug#648006: ITP: png23d -- Converts PNG images into three dimensional representations.
Package: wnpp Severity: wishlist Owner: Vincent Sanders * Package name: png23d Version : 1.10 Upstream Author : Name * URL : http://kyllikki.github.com/png23d/ * License : MIT Programming Lang: C Description : Converts PNG images into three dimensional representations. This tool converts images in the PNG format into OpenSCAD or STL files with extensive control over the conversion process. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2008083733.1987.20871.reportbug@derik
Re: directory under /usr/bin -- Ok or not?
Marvin Renich writes: > How is /usr/libexec/ better than /usr/lib/ in these > cases? Placing executables in /usr/lib/package is just messy, if it contains, for instance, libraries. Having binaries in /usr/lib//bin, as inn2 does, is a bit better at least. -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7xhb2ehpo8@fsck.linpro.no
Bug#648017: ITP: local-file -- small clojure library
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: local-file Version : 0.1.0 Upstream Author : Arthur Edelstein * URL : https://github.com/arthuredelstein/local-file/ * License : Programming Lang: Java Description : small clojure library To use this very small clojure library, add [local-file "0.1.0"] to the dependencies list in your project.clj file. Then call (use 'local-file) or "use" local-file in your (ns...) macro call in a clojure source file. . To get the current clojure project's directory (the parent dir of the source dir) call project-dir with no arguments. The file* function takes a relative path and returns an absolute path relative to the project directory. . To read and write files in a clojure project's directory, use spit* and slurp* with the same signatures as the standard spit and slurp calls. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2008112856.10968.92520.report...@hpdesk.malat.net
Re: Bug#648017: ITP: local-file -- small clojure library
On Tue, Nov 08, 2011 at 12:28 +0100, Mathieu Malaterre wrote: > > * Package name: local-file > Version : 0.1.0 > Upstream Author : Arthur Edelstein > * URL : https://github.com/arthuredelstein/local-file/ > * License : > Programming Lang: Java > Description : small clojure library > > To use this very small clojure library, add [local-file "0.1.0"] to the > dependencies list in your project.clj file. Then call (use 'local-file) or > "use" local-file in your (ns...) macro call in a clojure source file. > . > To get the current clojure project's directory (the parent dir of the source > dir) call project-dir with no arguments. The file* function takes a relative > path and returns an absolute path relative to the project directory. > . > To read and write files in a clojure project's directory, use spit* and > slurp* > with the same signatures as the standard spit and slurp calls. Some notes: * Please name the package liblocal-file-clojure as this is in line with the naming convention for other clojure libraries such as clucy (libclucy-clojure), robert-hooke (librobert-hooke-clojure), ... * The license is missing in the description even though local_file.clj states that it is in the public domain. IANAL and not sure if upstream needs to declare this more formally with, for example [0] * The short description should give the reader an idea what this package/library can be used for. "small clojure library" is not particularly informative and I would replace it by something like upstream's short description "Read and write files locally from a clojure program". * The long description is just a verbatim copy of upstream's README.md and is targeted at people who *do not* use the Debian package, but want to install it with leiningen. Please write an informative description that gives the reader a good idea why (s)he would like to install this package and what it could be used for. All that being said: Thank you for your continuing work on clooj and its dependencies. [0] http://www.gnu.org/licenses/license-list.html#CC0 -- Wolodja 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: Bug#648017: ITP: local-file -- small clojure library
Hi Mathieu, On Tue, Nov 08, 2011 at 12:28 +0100, Mathieu Malaterre wrote: > Programming Lang: Java This should probably be "Clojure" and not "Java" :) -- Wolodja 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Bug#648040: ITP: jailkit -- chroot jail utilities
Package: wnpp Severity: wishlist Owner: "Björn Esser" * Package name: jailkit Version : 2.1.4 Upstream Author : Olivier Sessink * URL : http://olivier.sessink.nl/jailkit/ * License : BSD Programming Lang: C, Python Description : chroot jail utilities Jailkit is a set of utilities to create chroot jails for users, processes and daemons. There are utilities to build a jail, to test a jail, and to run a jail. . Jailkit is known to be used in network security appliances from several leading IT security firms, internet servers from several large enterprise organizations, internet servers from internet service providers, as well as many smaller companies and private users that need to secure cvs, sftp, shell or daemon processes. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2008140848.2512.35342.reportbug@debian-vm
Re: Bug#647995: ITP: cellprofiler -- quantitatively measure phenotypes from images automatically
On Tue, Nov 08, 2011 at 09:37:24AM +0100, Mathieu Malaterre wrote: > * Package name: cellprofiler > Upstream Author : Broad Institute Last time I used it, Cell Profiler required a Matlab runtime which included not only the proprietary Matlab libraries, but also an entire Linux distribution including the C library and runtime linker, as well as a complete copy of Java and several fonts! Awful! Is this version of Cell Profiler dependent in any way upon Matlab, even to generate the code indirectly? The reason I ask is that the preferred form for modification may require proprietary tools to generate a functional program, even if the final program runs using only free software. If it's 100% python, that's great, but due to its past, and the fact that its heavy image processing most likely requires the use of non-python code for speed, I just wanted to check exactly how free it is nowadays. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2008155027.gn28...@codelibre.net
Re: Bug#647995: ITP: cellprofiler -- quantitatively measure phenotypes from images automatically
On Tue, Nov 8, 2011 at 4:50 PM, Roger Leigh wrote: > If it's 100% python, that's great, but due to its past, and the > fact that its heavy image processing most likely requires the > use of non-python code for speed, I just wanted to check exactly > how free it is nowadays. I have never used the matlab version. It is still accessible as "version 1": http://cellprofiler.org/developers.shtml I will only be working on "version 2" which is the python re-implementation. 2cts -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+7wUsz6h6ObSGMDmr7DaQ7wnVYW82=qywgy4kyonno0mf2...@mail.gmail.com
Re: Description-less packages file
Hello, I welcome this change as it will also bring benefits in the local processing speed (at least, for some tools). As for Cupt, a couple of simple patches is needed for the support of the grabbing new 'Description-md5' from Packages-files, but even without them the program should work correctly (aside of "seeing" empty descriptions). If/when this will go forward, I would like to ask for the official confirmation a couple of weeks before so there is a time to apply the patches. P.S. As David said already, would be nice to see all usual i18n/* files in newdists/ for the cleaner testing. P.P.S. Thanks for care. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2008202817.GA5954@r500-debian
Resolve namce conflise with node and nodejs [was Re: Is anyone maintaining (the ham radio tool) node?]
Where is the voice of the nodejs maintainers in this? They are listed as: Debian Javascript Maintainers Jérémy Lal Dave Beckett Jonas Smedegaard -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? signature.asc Description: Digital signature
Re: Is anyone maintaining (the ham radio tool) node?
On Tue, Nov 08, 2011 at 07:16:35AM +1100, Damien Gardner Jnr wrote: > > I have to pop my head up from my lurker-hole here, and say that I'm a more > than a little confused, why a 15 year old application should change its name > at all? Even the Node.js wiki makes it clear that the application should be > called Node.js 'to disambiguate it from other nodes' - it sounds like the > developers are being proactive in notifying users that they picked a name > which conflicts with other packages? > You would think there would be some weight given to the length of time a binary has been in the project, but there is not. First come, first served does not apply according to Debian Policy. > I don't know about others, but I'm not overly keen on the idea of > reconfiguring machines which were installed last century, because a program > which appeared in the last two years has the same name.. If you think about > it, node.js is *much* more 'able' to change the name of its binary - it still > has an actively developed community! - I don't know about other folk, but I > find it pretty darned hard to find much 'current' documentation about a lot > of the older x.25 & bbs stuff I have running on some of my older boxen - one > of my BBS packages doesn't even appear in a google search anymore (god help > me if the wrapper I setup in 2001 to make it telnet-accessible as well as > dial-in, ever breaks ;) ) I hope to avoid any issues with breaking old boxes with the eventual resolution of the issue. > > Although I'm curious why both packages can't just shove a Conflicts: in for > each other, and be done with it? Or just leave it as is, since they're in > different directories, provided a nice big must-click-ok dialog comes up > during install/upgrade to notify the user of the change? From the AX.25 > side, and probably at least partly from the Node.js side, the users are going > to be fairly cluey, if not accomplished hackerers - having multiple binaries > of the same name, in different directories in the path is nothing new (hell, > we used to rely on it on some of our hosting servers - things like reboot, > shutdown, etc were wrappered with scripts in higher-preferenced directories > from the PATH, to make sure accidental reboots, shutdowns, rm's etc, couldn't > happen, as explicit paths had to be used.. As for scripts etc, well, if > you're not specifying the absolute path to any binary you're calling, you're > just asking for trouble anyway! > The issue is one of following policy. Debian policy doesn't allow such a "resolution" to this issue. Consensus on which must change, or both must change are the only allowed outcomes. 73, Pat -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2008194814.gd30...@flying-gecko.net
Dynamic linking against binutils libraries (again) (attn: doko)
Since this discussion in 2005:
http://lists.debian.org/debian-devel/2005/05/msg01085.html
binutils has got a shlibs file that specifies a tight dependency on the
current upstream version. Thus frequent binNMUs of any packages linking
dynamically against libbfd or libopcodes are needed, or those packages will
hold back binutils from migrating, as is the case right now, but there should
hopefully at least be no breakage.
I just want to check that the prohibition in the package description of
binutils-dev ("Note that building Debian packages which depend on the shared
libbfd is Not Allowed") is still in force and that doko hasn't just forgotten
about it. In that (former) case I'm volunteering to fix the offending packages
(lush and nitpic) and close the bugs my friend Niels opened.
(It does seem a bit pointless to help packages that link dynamically that much
if it's forbidden, but on the other hand binutils is definitely not a proper
library package.)
--
Magnus Holmgrenholmg...@debian.org
Debian Developer
signature.asc
Description: This is a digitally signed message part.
Trivia: very old files on incoming.debian.org
Hi all, Not sure where else to send this… but while checking for a small upload I did I saw some very old files on incoming. If you check sorted by date, http://incoming.debian.org/?C=M;O=A, you'll see some very old things (1997, 2003, 2007, etc…). Their size is not big, but seems… unclean to not remove failed uploads (which I presume they are) after a while. regards, iustin signature.asc Description: Digital signature
Re: Dynamic linking against binutils libraries (again) (attn: doko)
On Tue, Nov 08, 2011 at 09:57:02PM +0100, Magnus Holmgren wrote:
> Since this discussion in 2005:
> http://lists.debian.org/debian-devel/2005/05/msg01085.html
> binutils has got a shlibs file that specifies a tight dependency on the
> current upstream version. Thus frequent binNMUs of any packages linking
> dynamically against libbfd or libopcodes are needed, or those packages
> will hold back binutils from migrating, as is the case right now, but
> there should hopefully at least be no breakage.
> I just want to check that the prohibition in the package description of
> binutils-dev ("Note that building Debian packages which depend on the
> shared libbfd is Not Allowed") is still in force and that doko hasn't just
> forgotten about it. In that (former) case I'm volunteering to fix the
> offending packages (lush and nitpic) and close the bugs my friend Niels
> opened.
> (It does seem a bit pointless to help packages that link dynamically that
> much if it's forbidden, but on the other hand binutils is definitely not a
> proper library package.)
I don't think there's been any change wrt the prohibition on dynamic linking
of libbfd, and I wonder why these packages are doing so. I think fixing
those packages to link statically is the right thing to do.
HTH,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Re: Trivia: very old files on incoming.debian.org
On Wed, 2011-11-09 at 06:34 +0900, Iustin Pop wrote: > Not sure where else to send this… but while checking for a small upload > I did I saw some very old files on incoming. If you check sorted by > date, http://incoming.debian.org/?C=M;O=A, you'll see some very old > things (1997, 2003, 2007, etc…). > > Their size is not big, but seems… unclean to not remove failed uploads > (which I presume they are) after a while. They're not. They're part of (or at least associated with) very recent uploads, and their being there is a Good Thing[tm], as it means incoming.d.o contains source for the binaries provided there. The 1997 file, for instance, is xloadimage_4.1.orig.tar.gz, sitting alongside xloadimage_4.1-16.3_*.deb for several architectures. [Also note that the public HTTP-exported view of incoming.d.o has been little more than a link tree for some time now (since the introduction of "install-direct-from-unchecked-to-projectb" iirc) rather than the "accepted files not yet in the archive" it once was.] Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1320789028.464.13.ca...@hathi.jungle.funky-badger.org
Re: Trivia: very old files on incoming.debian.org
On Tue, Nov 08, 2011 at 09:50:27PM +, Adam D. Barratt wrote: > On Wed, 2011-11-09 at 06:34 +0900, Iustin Pop wrote: > > Not sure where else to send this… but while checking for a small upload > > I did I saw some very old files on incoming. If you check sorted by > > date, http://incoming.debian.org/?C=M;O=A, you'll see some very old > > things (1997, 2003, 2007, etc…). > > > > Their size is not big, but seems… unclean to not remove failed uploads > > (which I presume they are) after a while. > > They're not. They're part of (or at least associated with) very recent > uploads, and their being there is a Good Thing[tm], as it means > incoming.d.o contains source for the binaries provided there. > > The 1997 file, for instance, is xloadimage_4.1.orig.tar.gz, sitting > alongside xloadimage_4.1-16.3_*.deb for several architectures. Aaaah, I see. Thanks for the explanation! I should have realised this is the case from the fact that only orig.tar.gzs have such old dates. (which also means: we can still build upstream software from more than one decade ago? nice! even if patched…) > [Also note that the public HTTP-exported view of incoming.d.o has been > little more than a link tree for some time now (since the introduction > of "install-direct-from-unchecked-to-projectb" iirc) rather than the > "accepted files not yet in the archive" it once was.] Ah, I'm not familiar with that change, so thanks again for the information. iustin signature.asc Description: Digital signature
Package mailing lists (was: bits from the DPL for September 2011)
On Sun, Oct 09, 2011 at 03:48:35PM +0200, Stefano Zacchiroli wrote: > - I've made the "private email aliases considered harmful" point [10], > in a somehow unrelated thread. I ask you to watch out for interactions > in Debian that could happen only through private email addresses. > There are some cases where they are warranted (e.g. security or > privacy concerns), but having regular activities of a team going > through private email aliases harms us in so many ways. Please point > me to project areas that could benefit from improvements on this > front, ... unless you can just go ahead and fix the issue! Sorry for reviving and old email. To what extend do you think this should apply - even at individual package level? I ask this because of the following: recently I had a 1-1 discussion with a co-maintainer of one of my packages, which went between our personal emails. I quite disliked this (since it will be buried in our mailboxes), but email conversations seem simpler than going through the BTS for all discussions. On the other hand, http://wiki.debian.org/Alioth/PackagingProject discourages requesting Alioth projects for smaller packages, so in that sense it encourages people contacting directly the maintainers via their emails, instead of having the archived, indexable lists. Could/should Debian make it easier for each package to have an own email list (i.e. making it easier to have "1-person team maintenance")? Or is BTS enough? (I don't think so, since it doesn't have a simple canonical entry point for all packages) regards, iustin signature.asc Description: Digital signature
Re: Simplifying bootstrap on circular-dependent packages
Hi, In my humble experience I just used debian/shlibs.local :-) 05.11.2011 01:30, Daniel Ruoso пишет: I have been thinking about the bootstrapping of pakages lately. I am involved in bootstrapping a partial system -- no kernel and no libc -- for some architectures for internal use. And I just thought that we could use one trick to help in the bootstrap of packages that depend on other shared libraries, this is something we use internally for other reasons but I guess it could fit here as well. The basic idea is creating "dummy libraries" that would serve for the linking but that had no code on it. This would allow the linking to happen -- of course this only helps in the case where the build process doesn't run anything from the build-dependency. Later the other package in the cycle would be built, and the actual library would be made available instead of the "dummy", and the linker would find the actual library. We already extract all that information for dpkg-shlibdeps to work, we could just build a fake shared library automatically based on that. What do you think? daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eb9af83.4050...@gmail.com
Re: Package mailing lists (was: bits from the DPL for September 2011)
[Iustin Pop]
> Could/should Debian make it easier for each package to have an own email
> list (i.e. making it easier to have "1-person team maintenance")?
We have {pkg}@packages.debian.org and {srcpkg}@packages.qa.debian.org.
I don't know if mail to these aliases get archived, but at least it is
going through Debian infrastructure. The latter even, I believe, uses
proper list software.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2008232617.gb2...@p12n.org
Re: Resolve namce conflise with node and nodejs [was Re: Is anyone maintaining (the ham radio tool) node?]
On 11-11-08 at 02:34pm, Patrick Ouellette wrote: > Where is the voice of the nodejs maintainers in this? For my own part, I am following the thread, quite happy to hear the voice of the (ham) node maintainers, but wondering what is so precious about keeping the name of its binary. Form my understanding it is a daemon, which (again from my limited understanding) means normally only sysV scripts should need to know the actual name of that binary, not all sorts of locally written scripts. As has already been pointed out (but not commented on, as far as I have noticed) the nodejs binary is an interpreter as thus normally used directly in all user scripts in their hash-bang. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
