Bug#538802: ITP: mercury -- The Mercury programming system, a pure logical/functional programming language.
Package: wnpp Severity: wishlist Owner: Paul Bone -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: mercury Version : 0.13.1-rotd20090725 Upstream Author : Mercury Group * URL : http://www.mercury.csse.unimelb.edu.au/ * License : GPL2 Programming Lang: Mercury Description : The Mercury programming system, a pure logical/functional programming language. Mercury is a logic/functional programming language, which combines the clarity and expressiveness of declarative programming with advanced static analysis and error detection features. Its highly optimized execution algorithm delivers efficiency far in excess of existing logic programming systems, and close to conventional programming systems. Mercury addresses the problems of large-scale program development, allowing modularity, separate compilation, and numerous optimization/time trade-offs. - -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkptWJAACgkQ5BL8BUmFfuXH+ACfX/iUhm+zlv0V85zTT/QXzNHg R8oAoI3JqP0TdK3p75QkCesNUgnwogDs =bi3e -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: waf into NEW, please test it with your packages
Ryan Niebur ha scritto: > It doesn't work with midori apparently... Right, I prepared a patch to build with 0.1.7, but I noticed new upstream version (0.1.8) builds correctly. If you plan to upgrade to the new version, you should not have any issue with waf Debian package. Thanks for testing! Regards, -- . ''`. Luca Falavigna : :' : Ubuntu MOTU Developer `. `'` Debian Maintainer `- GPG Key: 0x86BC2A50 signature.asc Description: OpenPGP digital signature
Re: Comments on the "Changing the default system shell" talk
On Sun, Jul 26, 2009 at 11:47:00PM -0500, Manoj Srivastava wrote: > > You think the average user doesn't care about getting 50% faster boot > > speeds? > > Now, where do you get the 50% faster speedup? I seem to recall > a post on this list which reported much more modest speedups, and > pointed to a Debian wiki page which seems to imply average boot time > improvements were of the order of 4% or or? I don't have the reference > handy, though it was mentioned in a list mail recently. What I did find > was: > http://wiki.debian.org/DebianEeePC/Dash > ehich says 5%, which seems to be in the same ball park. i'd expect the speedup to be conservatively somewhere in the ballpark of 5-15% based on http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/bootcharts.html which for etch saw a 4 seconds saving on a 32 second boot time. i haven't timed my boots so i'm only guessing that it's probably around the same. sean signature.asc Description: Digital signature
Re: Comments on the "Changing the default system shell" talk
On Mon, Jul 27, 2009 at 02:07:05AM +0200, Steve Langasek wrote: > You think the average user doesn't care about getting 50% faster boot > speeds? I don't get why you people keep repeating that it's only about faster boots. All shell scripts receive a speed boost. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian, universal operating system?
On 2009-07-27 01:11, George Danchev wrote:
Quoting "Ron Johnson" :
On 2009-07-26 17:00, Miles Bader wrote:
Chris Lamb writes:
Agreed. IMHO, it is one of those phrases (along with "Our priority is
our users") that actually means extremely little in practice, except
for
generating lots of hot air with nobody agreeing.
"Our priority is endless surreal flamewars over minor technicalities"
seems about right to me.
Anyone who *really* thinks that Debian actually, seriously claims to
be The One True Universal OS has been in the basement way too long,
and needs a little sunshine, drink some beer and go where there are
lots of pretty girls.
However, Debian is unique with its (controlled?) expansion in several
directions (just like the Universe): it is expanding (fast) as
developers and users, as packages and bugs, and last but not least as
kernels and libc's ;-). Surely, that looks quite universal to the pretty
girls.
If you go all etymological, then I guess you *could* say that Debian
actually *is* a universal OS. Just like that pesky BSD, which,
according to Netcraft, is dead.
Universe \U"ni*verse\, n. [L. universum, from universus
universal; unus one + vertere, versum, to turn, that is,
turned into one, combined into one whole; cf. F. univers. See
{One}, and {Verse}.]
--
Scooty Puff, Sr
The Doom-Bringer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Comments on the "Changing the default system shell" talk
On Mon, Jul 27, 2009 at 11:15:35AM +0200, Adam Borowski wrote: > On Mon, Jul 27, 2009 at 02:07:05AM +0200, Steve Langasek wrote: > > You think the average user doesn't care about getting 50% faster boot > > speeds? > I don't get why you people keep repeating that it's only about faster boots. > All shell scripts receive a speed boost. Boot time is the one case in which shell performance is critical path for all users. -- 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
On Sun, Jul 26, 2009 at 05:10:59PM +0200, Frans Pop wrote: > You're correct of course. If we want to go this way there should be two > questions: one for the system shell to use and one for the default user > shell, each with per-arch defaults. Do you really think that the latter warrants a question? Admins can set their own policies by wrapping adduser; derivers can set their own policies by modifying the adduser package. > From the discussion there seem to be three groups: > - embedded: want to have only a single, lightweight shell installed for > both system and users; > - generic: want a fast system shell, but a more powerful shell for users; > - conservative: don't want to run any risk with script incompatibilities > and thus want to have the same, powerful shell for system and users. > It seems to me all three are valid. Has anyone actually said in this thread that "I'm developing an embedded system and I want the user shell to be dash"? dash is a terrible user shell, after all. Otherwise, yes, these are all valid cases, but I don't think that's really been a point of contention here; the only contention has been: - which configuration is the default? - do we need to generalize beyond dash and bash to meet these use cases? -- 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Comments on the "Changing the default system shell" talk
Jonathan Wiltshire wrote: On Sun, Jul 26, 2009 at 05:08:20PM +0200, Luk Claes wrote: On upgrades you are asked if you want to have dash as default system shell unless you have dash already installed, then we leave it as is. On my unstable box I received dash a few days ago, because an upload of bash started depending on it. After upgrading dash to 0.5.5.1-2.2 today, /bin/sh is still bash. Presumably this means unstable users are going to have to dpkg-reconfigure dash to get any benifit from this change? For unstable users, this kinda defeats the point of pushing such a change. The dependency on dash was a bit premature, and indeed for unstable users that upgraded to bash already without getting any debconf question it's a matter of dpkg-reconfiguring dash. Note that there will follow a message on debian-devel-announce about the swith to dash with pointers to possible issues. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Comments on the "Changing the default system shell" talk
Goswin von Brederlow wrote: Raphael Hertzog writes: I just would like it to be even better. And I haven't seen any real constructive discussion about different methods of providing /bin/sh. Mostly just angry replies along the lines of "We don't want to break things. We do it this way." without disclosing what or why things would break. If my reply sounded angry, it was certainly not meant to be. Currently if you install any shell other than bash or dash to provide /bin/sh, you have moments were /bin/sh is not available on the system. This might introduce all kind of breakage and is the breakage we're talking about. Using a mechanism like alternatives for instance does not make sure that there is always a working /bin/sh on the system. There seems to be one group of people that would like more flexibility (including the option of keeping bash as /bin/sh even in the long run) and the other group being dead set on the dash plan. And no dialog between the groups. Both sides (and feel free to include me there too) stay in their corner and say "nay" to each other. It is sad that we can't discuss the merrits and problems of proposals rationally and work out a solution that works for all. It's perfectly fine to have people wanting to have more flexibility. Note that keeping bash as /bin/sh even in the long run is not at all excluded the way we implemented the new default system shell btw. Though working out a solution that works in a more flexible way is far from trivial and it does not seem like anyone is interested enough to work on it. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Comments on the "Changing the default system shell" talk
Goswin von Brederlow wrote: Manoj Srivastava writes: On Sun, Jul 26 2009, Raphael Geissert wrote: Goswin von Brederlow wrote: So the deconf thing is purely a temporary thing and goes away. There won't be a choice left. Users will just get /bin/sh pointing to dash period. No, /bin/sh is shipped to guarantee a symlink. I take this to mean that installaations with /bin/sh -> /bin/bash will not be affected? That is good, if true. How could it not be changed? Unless something dpkg-diverts /bin/sh away from dash (which sort of conflicts with dash possibly dpkg-diverting it away from bash) then dpkg will overwrite /bin/sh when it unpacks the new dash. So unless you tell dash not to divert and then add a dummy diversion of /bin/sh from dash before updating you will get /bin/sh changed. Or dash could have preinst code that adds the diversion on itself if it detects it is being updated from a system that has bash as /bin/sh. Didn't see a plan for that. If that is planed then be a step forward. It's what has been implemented. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Comments on the "Changing the default system shell" talk
Goswin von Brederlow wrote: Luk Claes writes: Manoj Srivastava wrote: On Sun, Jul 26 2009, Luk Claes wrote: Goswin von Brederlow wrote: A faster and smaller default system shell is important to a lot of our users. I see this asserted a lot. I am pretty sure that the average user very likely does not care. The embedded system folks certainly do --- but I am not sure that the counter assertion that systems will break if /bin/sh is changed under them do not equal in number the people who benefit from small default system shell. I think it is OK to start with dash as the default on new installations, and to ask if people want to switch older ones. Forcing the switch would be, in my opinion, buggy behaviour. Pardon me if forcing the /bin/sh to point to dash on existing machines is not the plan. On upgrades you are asked if you want to have dash as default system shell unless you have dash already installed, then we leave it as is. Cheers Luk Two things: 1) I updated dash the last day and I didn't get asked and I don't remeber ever having been asked before. Having dash installed before shouldn't prevent the question. Please do always ask the question if it wasn't asked before. If you installed dash before, we assume that you already chose if you wanted dash as /bin/sh or not. If that's not the case you are welcome to dpkg-reconfigure dash to change your mind. 2) That changes when dash ships the /bin/sh link. So the question really is: What mechanism will you use, if any, to preserve bash as /bin/sh later when dash does ship /bin/sh? At the moment I don't see any reason why we should change what we currently implemented which leaves the option to choose bash or dash while shipping /bin/sh in both packages. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538849: ITP: stardict-english-simpchinese -- Stardict package for English to and from Simplified Chinese dictionaries
Package: wnpp Severity: wishlist Owner: LIU Qi * Package name: stardict-english-simpchinese Version : 20090727-1 Upstream Author : Paul Denisowski, Ma Suan, Fu Jianjun, Hu Zheng * URL : http://stardict.sourceforge.net/Dictionaries_zh_CN.php * License : GPL-2, CEDICT Description : Stardict package for English to and from Simplified Chinese dictionaries This is a package of the English to and from Simplified Chinese dictionaries for Stardict. . It contains the CEDICT Chinese-English dictionary, stardict1.3 English-Chinese dictionary, XDICT Chinese-English dictionary and XDICT English-Chinese dictionary. -- LIU Qi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538852: ITP: stardict-english-tradchinese -- Stardict package for English to and from Traditional Chinese dictionaries
Package: wnpp Severity: wishlist Owner: LIU Qi * Package name: stardict-english-tradchinese Version : 20090727-1 Upstream Author : Paul Denisowski, Fu Jianjun, Hu Zheng * URL : http://stardict.sourceforge.net/Dictionaries_zh_TW.php * License : GPL-2, CEDICT Description : Stardict package for English to and from Traditional Chinese dictionaries This is a package of the English to and from Traditional Chinese dictionaries for Stardict. . It contains the CEDICT Chinese-English dictionary, XDICT Chinese-English dictionary and XDICT English-Chinese dictionary. -- LIU Qi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538853: ITP: scitools -- Python library for scientific computing
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: scitools Version: 0.6 Upstream authors: Hans Petter Langtangen, Johannes H. Ring, Ilmar Wilbers, and Rolv E. Bredesen URL: http://scitools.googlecode.com/ License: BSD Description: Python library for scientific computing SciTools is a Python package containing lots of useful tools for scientific computing in Python. The package is built on top of other widely used packages such as NumPy, SciPy, ScientificPython, Gnuplot, etc. I have already prepared Debian files for SciTools and the package is currently available from the private repository located at http://packages.simula.no. Regards, Johannes -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538854: ITP: swiginac -- Python interface to GiNaC
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: swiginac Version: 1.5.1 Upstream authors: Ola Skavhaug and Ondrej Certik URL: http://swiginac.berlios.de/ License: GPL Description: Python interface to GiNaC Swiginac is a Python interface to GiNaC, built with SWIG. The aim of swiginac is to make all the functionality of GiNaC accessible from Python as an extension module. I have already prepared Debian files for swiginac and the package is currently available from the private repository located at http://packages.simula.no. Regards, Johannes -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#538802: ITP: mercury -- The Mercury programming system, a pure logical/functional programming language.
On Mon, Jul 27, 2009 at 05:34:44PM +1000, Paul Bone wrote: > * Package name: mercury > Version : 0.13.1-rotd20090725 > Upstream Author : Mercury Group > * URL : http://www.mercury.csse.unimelb.edu.au/ > * License : GPL2 > Programming Lang: Mercury > Description : The Mercury programming system, a pure logical/functional > programming language. This used to be in Debian some time ago, because I remember trying to work on the package for some reason. I believe that it is self-hosting[0], which may be a problem, except that it supposedly comes with a C version of the compiler as well. To make life easy for porters, I'd request that you always build the C compiler and then, if you want to, bootstrap the Mercury compiler from that. If I'm remembering incorrectly, or that's no longer the case, feel free to disregard this. [0] That is, the compiler is written in Mercury. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bug#538857: rocksndiamonds: post-installation fails
>> The site www.artsoft.org is (temporary?) down. Why do You think it >> must be another way? Postinst returns error code because it can't >> download resource. Other packages (for example msttcorefonts) have >> the same behaviour. GLB> Do You think I shouldn't have report that problem? I think this is site's problem, i considered a few packages which download something from somewhere and all of them return errorcode when downloading fail. Of course we can complain of something like: - our provider provides us with bad connection; - the website we have link on is down. but does it refer to the specific package? Hmm... But I still don't know is this behavior is right. If the script doesn't return failcode, somebody could post the bug like 'I had no fail when I installed the package, but it doesn't work', even if he had seen the error message. I Cc-ed the mail to debian-devel: may be somebody gives us advice. -- ... mpd paused: Helloween - Guardians . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Bug#538881: ITP: libweed0 -- Library for inclusion of plugins into LiVES
Package: wnpp Severity: wishlist Owner: Harry Rickards * Package name: libweed0 Version : 1.0.0 Upstream Author : Gabriel Finch * URL : http://lives.sourceforge.net * License : GPLv3 Programming Lang: C Description : Library for inclusion of plugins into LiVES A library that was origionally only avaliable as part of LiVES (package lives) but is now avaliable seperately. Allows for the inclusion of plugins into LiVES. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538880: ITP: leo -- Literate Editor with Outlines
Package: wnpp Severity: wishlist Owner: "Ville M. Vainio" * Package name: leo Version : 4.6 Upstream Author : Edward Ream * URL : http://webpages.charter.net/edreamleo/front.html * License : MIT/X Programming Lang: Python Description : Literate Editor with Outlines -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#538897: World and group readable home directories in a default install
Processing commands for cont...@bugs.debian.org: > reassign 538897 general Bug #538897 [unknown] World and group readable home directories in a default install Warning: Unknown package 'unknown' Bug reassigned from package 'unknown' to 'general'. Bug #538897 [general] World and group readable home directories in a default install Bug No longer marked as found in versions Unknown. Bug #538897 [general] World and group readable home directories in a default install Ignoring request to alter fixed versions of bug #538897 to the same values previously set > -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian, universal operating system?
On Jul 26, 12:30 am, Frank Lin PIAT wrote:
> ## BANNER {http://www.debian.org/banners/3.1/sarge-ban1-6.png}
>
> Universal operating system #...@!
>
> First of all, let's make it clear, Debian is not THE universal operating
> system. I mean it is definitely not the one and only OS.
>
> Is Debian an universal operating system?
When I think about that slogan, I consider all Debian-derived
distributions to be 'Debian'. With that in mind Debian is a pretty
universal operating system. A few years ago I prepared a Debconf slide
about derived distributions and I found that Debian had more derived
distributions that all other distributions combined. I doubt that has
changed much. Most Linux distributions are based on Debian. Thus
Debian is a lot of things to a lot of people. Very universal and very
adaptable.
The key to that in my mind is feeding back changes and bringing
derivations back into the fold - the more Debian derived distributions
would be able to fully exist inside Debian (as fully official Debian
Pure Blends or whatever), the more Debian universality Debian as a
whole will gain.
In this context in my opinion it would be useful to find out what
things Debian-derived distributions want to do that can not be
currently done inside Debian with Debian resources and try to resolve
that. One great thing that we could copy is the PPA system from
Launchpad - a contributor can sign up, upload a source package and
have it compiled and put into a separate repository fully
automatically. Imagine such a system existing in Debian (with support
for all architectures, compile logs, lintian output, 'push this
version to unstable/experimental' button) and a lot more people would
be able to contribute in new ways. Now imagine a build system where
you could log in, define a Debian Pure Blend (metapackage
dependencies, setting overrides, ...) and have metapackages,
installation images and livecd images generated and hosted for you on
Debian hardware - you one stop shop to creating and hosting a
Debian-derived distribution in a way where you can easily contribute
it back to Debian.
If we have a vision of being an universal operating system, lets
strive for it using the best we have - people who use us to satisfy
their needs.
--
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
#--#
| .''`.Debian GNU/Linux (http://www.debian.org)|
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `'Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--#
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538914: ITP: kcemu -- A software emulator for microcomputers made in the former state of East Germany
Package: wnpp Severity: wishlist Owner: Adrian Glaubitz * Package name: kcemu Version : 0.4.2 Upstream Author : Torsten Paul * URL : http://kcemu.sourceforge.net/ * License : GPL Programming Lang: C Description : A software emulator for microcomputers made in the former state of East Germany kcemu is a software emulator similar to ViCE which emulates the KC85 microcomputers made in the former state of East Germany. These computers were built around the U880 microprocessor, a clone of the Z80 CPU made by Zilog. kcemu emulates various models from the KC-series, including all KC85 variants, the KC87, the LC80 and a few more. In order to function, kcemu requires ROM images and disk images which are copyrighted material and thus not included in this package. -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#538802: ITP: mercury -- The Mercury programming system, a pure logical/functional programming language.
On Mon, Jul 27, 2009 at 05:13:06PM +, brian m. carlson wrote: > On Mon, Jul 27, 2009 at 05:34:44PM +1000, Paul Bone wrote: > > * Package name: mercury > > Version : 0.13.1-rotd20090725 > > Upstream Author : Mercury Group > > * URL : http://www.mercury.csse.unimelb.edu.au/ > > * License : GPL2 > > Programming Lang: Mercury > > Description : The Mercury programming system, a pure > > logical/functional programming language. > > This used to be in Debian some time ago, because I remember trying to > work on the package for some reason. I believe that it is > self-hosting[0], which may be a problem, except that it supposedly comes > with a C version of the compiler as well. To make life easy for porters, > I'd request that you always build the C compiler and then, if you want > to, bootstrap the Mercury compiler from that. > > If I'm remembering incorrectly, or that's no longer the case, feel free > to disregard this. > This is mostly correct. Mercury is indeed self-hosting and was previously included in Debian. Mercury has a number of different backends two of these target C, high-level C and low-level C. The Mercury source distribution includes C intermediate files for the standard library and compiler generated by the low-level C backend, these can be compiled with GCC to generate binaries which can be used to bootstrap an installation by re-compiling the Mercury sources. I have a working Debian package that builds and bootstraps Mercury from the source distribution. It requires gcc-3.4 as a build-depend and is able to bootstrap itself so that the resulting binaries are optimal on 32bit and 64bit machines (the explanation involves a discussion of tagged pointers). I hope that this will be acceptable by the Debian project and that distributing intermediate files in the .orig.tar.gz file is not a problem. Mercury should build from the Debian source package equally as well as it can build from the upstream source distribution on all architectures. Cross-compilation should not be necessary. See also the list of supported architectures here: http://www.mercury.csse.unimelb.edu.au/download/rotd.html I hope this helps. If you have any more questions please let us know. Thanks. signature.asc Description: Digital signature
Bug#538939: ITP: libmodule-pluggable-ordered-perl -- Perl module to load plugins in a specified order
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: libmodule-pluggable-ordered-perl Version : 1.5 Upstream Author : Christopher Nehren * URL : http://search.cpan.org/dist/Module-Pluggable-Ordered/ * License : Artistic | GPL-1+ Programming Lang: Perl Description : Perl module to load plugins in a specified order Module::Pluggable::Ordered is a Perl module which extends the functionality provided by Module::Pluggable, allowing hooks to determine an ordering for modules to be loaded, producing an effect like the System V init process, where files can specify where in the init sequence they'd like to be called. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538942: ITP: libcatalyst-plugin-setenv-perl -- Perl module to automatically set up the environment
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: libcatalyst-plugin-setenv-perl Version : 0.03 Upstream Author : Marcus Ramberg * URL : http://search.cpan.org/dist/Catalyst-Plugin-Setenv/ * License : Artistic | GPL-1+ Programming Lang: Perl Description : Perl module to automatically set up the environment Catalyst::Plugin::Setenv is a module which allows one to conveniently set up the values of arbitrary environment variables automatically. Your Catalyst application simply loads the Setenv plugin, which then dutifully opens your configuration file and extracts your desired %ENV settings. Among other uses, this provides a simple way to set up special variables like PATH. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538943: ITP: libdbix-class-encodedcolumn-perl -- Extension to automatically encode column values
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: libdbix-class-encodedcolumn-perl Version : 0.2 Upstream Author : Guillermo Roditi * URL : http://search.cpan.org/dist/DBIx-Class-EncodedColumn/ * License : Artistic | GPL-1+ Programming Lang: Perl Description : Extension to automatically encode column values DBIx::Class::EncodedColumn is a DBIx::Class component which can automatically encode a column's contents whenever the value of that column is set, similar to DBIx::Class::DigestColumns. Any data you write is automatically converted on-the-fly and, in contrast to DigestColumns, any arbitrary message digest or encryption method can be supported through an appropriate encoding class. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538944: ITP: libdata-formvalidator-constraints-datetime-perl -- D::FV constraints for dates and times
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: libdata-formvalidator-constraints-datetime-perl Version : 1.09 Upstream Author : Michael Peters * URL : http://search.cpan.org/dist/Data-FormValidator-Constraints-DateTime/ * License : Artistic | GPL-1+ Programming Lang: Perl Description : D::FV constraints for dates and times This package provides constraint routines for Data::FormValidator for dealing with dates and times. It provides an easy mechanism for validating dates of any format (using strptime(3)) and transforming those dates (as long as you 'untaint' the fields) into valid DateTime objects, or into strings that would be properly formatted for various database engines. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#538802: ITP: mercury -- The Mercury programming system, a pure logical/functional programming language.
On Tue, Jul 28, 2009 at 08:35:14AM +0200, Reinhard Tartler wrote: > Paul Bone writes: > > > This is mostly correct. Mercury is indeed self-hosting and was > > previously included in Debian. Mercury has a number of different > > backends two of these target C, high-level C and low-level C. The > > Mercury source distribution includes C intermediate files for the > > standard library and compiler generated by the low-level C backend, > > these can be compiled with GCC to generate binaries which can be used to > > bootstrap an installation by re-compiling the Mercury sources. > > > > I have a working Debian package that builds and bootstraps Mercury from > > the source distribution. It requires gcc-3.4 as a build-depend and is > > able to bootstrap itself so that the resulting binaries are optimal on > > 32bit and 64bit machines (the explanation involves a discussion of > > tagged pointers). > > > > I hope that this will be acceptable by the Debian project and that > > distributing intermediate files in the .orig.tar.gz file is not a > > problem. > > The same applies to the package aspectc++, a package that I maintain > since some time. AspectC++ is a language extension for C++ for aspect > oriented programming (AOP). It is built on top of an C/C++ Parsing and > Manipulation framework (PUMA), where some functionality (e.g. support > for various GNU language extension) is implemented using AspectC++ > aspects. There you have a pretty similar situation, and I'm doing a very > similar approach: Shipping intermediate files that can be processed with > gcc. > > I suggest that you use these intermediate files only for compiling an > intermediate compiler for bootstrapping. With that compiler, redo all > intermediate files and build the binaries of the compiler that will > eventually end up in the package. This ensures that you'll end with a > working compiler on all architectures. Yep, That's what we do. > BTW, this approach was actually suggested to me by Lamont Jones a few > years ago. It seems to be a quite common approach, FWIW. Thanks. signature.asc Description: Digital signature
