Sponsoring haskell-http
Hi People,
I have taken over maintenance of haskell-http from Ganesh Sittampalam. I
have prepared a new version which fixes all bugs which are open in the
BTS.
I am not a DD yet and my regular sponsor is quite busy, so I am
searching for someone who could upload this package for me.
The package I have prepared is available from my website [1]
The easiest way to download it is:
dget
http://moonshine.dnsalias.org/debian/unstable/haskell-http_0.4.20050430-2_i386.changes
Below is the changelog of my revision.
Greetings Arjan Oosting
[1] http://moonshine.dnsalias.org/debian/unstable
haskell-http (0.4.20050430-2) unstable; urgency=low
.
* Take over maintainership with permission of previous maintainer.
* Run update-haskell-control to update the Build-Depends, Depends and
Architecture lines. (Closes: #337979, #360878, #336396, #336268)
* Remove support for nhc98 from the package.
* debian/control.in:
- Move haskell-http-doc to section doc.
- Change to Standards-Version 3.6.2. No changes needed.
- Cleanup the Build-Depends and Build-Depends-Indep
- Add Homepage: http://www.haskell.org/http/ to the descriptions.
- Properly escape ${haskell:Depends}.
- Add versioned libghc6-cabal-dev and ghc6 to the Build-Depends to use
Cabal version 1.1.1 or later which introduces a new installation
prefix for libraries.
libghc6-http-dev determinable.
* debian/compat: added and set debhelper compatability level to 5.
* debian/copyright: updated.
* debian/haskell-http-doc.dirs: added.
* debian/libhugs-http.install: added.
* debian/libhugs-http.linda-overrides: added. The *.hs files need to be
installed in /usr/lib/hugs/ so override linda warning.
* debian/rules:
- split the dh_haskell -a -i call two calls. Move all the architecture
independent stuff to binary-indep and all the architecture dependent
stuff to binary-arch. (Closes: #315333)
- remove the empty directory usr/lib/haskell-packages/ghc6/bin
(Closes: #324718)
- do not ignore errors on clean and remove redundant make clean call.
- general cleanup.
* debian/watch: added watch file.
* http.cabal: add package base to Build-Depends.
signature.asc
Description: Dit berichtdeel is digitaal ondertekend
Re: building rpms on debian system?
[This is probably the wrong list for this.] Ek Zindagoi wrote: I would like to build rpms on a debian system for use on a redhat system. Can I do that on a debian system ? In short, no; system libraries on a RedHat system likely have different versions (and soversions), as well as a few different filesystem paths. Libraries *will* have different names, except in a few very rare cases. (Worse, all Debian libraries have package names "lib"; very few RH libs do unless the upstream name is libsomething.) Even if I wanted to install the RPM on a debain system, can I run the rpmbuild -bb command on a debian system and successfully build an RPM This is a little different. The short answer is "sort of". However, it won't build easily or well, and it will not install cleanly as an rpm. There are a couple of solutions: 1) Build in whatever is the "native" package format, then use alien to convert package formats. This is in no way guaranteed to work well, if at all (athough it should be pretty good in most cases). This means you still need a real RedHat system to build .rpm packages, however. (Or at least, a suitable chroot - my experiences there have been, shall we say, less than positive.) Or a premade package instead of creating your own. 2) Use my nifty package-building tool debbuild (no direct relation to anything other than rpm, and that only in the interface and visible behaviour, as far as I can tell), available at http://www.deepnet.cx/debbuild/. It's basically an emulation of the build process and interface used by rpmbuild (the actual rpm component used to create .rpm packages), except that it builds packages that will install in some manner resembling "correct" on Debian systems. Please note, however: this will **NOT** create "Debian Packages"!! It has some limitations; most notably the various dependency entries in the spec file will NOT be translated to the suitable Debian equivalents (I have no idea how that might even be done maintainably). You WILL almost certainly have to tweak the .spec file for the package you want to rebuild in order for it to build correctly on Debian. Certain complex macros will effectively be ignored. Some things in the %files section will be ignored - largely because there doesn't seem to be any backend support for such operations in Debian. (IE, specifying alternate ownership for arbitrary files in the package.) That said, I think it's a useful tool (otherwise I wouldn't have written it). I find the RPM build system much easier to work with than the documented methods for creating Debian Packages in the Debian New Maintainer's docs, Debian Policy, and pretty much anywhere else I looked. (The worst problem I ran into is that I could never figure out if my current build was picking up artifacts from a previous build - evidence from the .diff.gz in several cases seemed to indicate that I was. The RPM build process eliminates that by unpacking the tarball fresh on each build.) -kgd -- Get your mouse off of there! You don't know where that email has been! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: python-urwid - Console UI Library for Python
Hello, I am looking for a sponsor for the python-urwid debian packages I have created. Urwid is a console user interface library for Python. It has a number of features that that are not available in similar libraries. See the Urwid web site for full details: http://excess.org/urwid/ Urwid is written in pure python and is arch-independent. I have packaged versions for python2.1, 2.2, 2.3 and 2.4, and I've made them available in an apt repository on excess.org. A number of people have already packaged Urwid for other distributions and operating systems. It would be great to see it in unstable too. Let me know if you can help. Regards, Ian Ward WNPP submitted on November 30, 2005: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341344 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: python-urwid - Console UI Library for Python
On Thu, 2006-04-20 at 15:59 -0400, Ian Ward wrote: > I am looking for a sponsor for the python-urwid debian packages I have > created. > WNPP submitted on November 30, 2005: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341344 You will notice that I retitled that RFP bug to ITP. I've created much simpler packaging, committed it to python-modules SVN and found a sponsor who has uploaded it. It is now waiting in the NEW queue: http://ftp-master.debian.org/new.html You are welcome to take over maintainership of it, or co-maintain it with me, perhaps buxy can add you to the python-modules SVN. > I have packaged versions for python2.1, 2.2, 2.3 and 2.4, and I've > made them available in an apt repository on excess.org. I think a better option would be to use python-support to make a single deb that supports all python versions. I intend to do that once urwid enters debian. More info here: http://wiki.debian.org/DebianPythonFAQ -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: RFS: python-urwid - Console UI Library for Python
On Fri, 21 Apr 2006, Paul Wise wrote: > You are welcome to take over maintainership of it, or co-maintain it > with me, perhaps buxy can add you to the python-modules SVN. Given than Ian is the upstream author of the module, he is of course welcome in the team if he so wishes. Ian, just give me your alioth login if you are interested. > > I have packaged versions for python2.1, 2.2, 2.3 and 2.4, and I've > > made them available in an apt repository on excess.org. > > I think a better option would be to use python-support to make a single > deb that supports all python versions. I intend to do that once urwid > enters debian. More info here: I suggest on the contrary to do that before it enters Debian so that the ftpmaster do not create packages that will disappear shortly after and so that you don't have an upgrade path to handle. I did that for kid. And I mailed ftpmasters to tell them that they could reject the previous upload if that helped them (but my second upload was a new upstream version). Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: python-urwid - Console UI Library for Python
On Fri, 2006-04-21 at 15:58 +0200, Raphael Hertzog wrote: > > > I have packaged versions for python2.1, 2.2, 2.3 and 2.4, and I've > > > made them available in an apt repository on excess.org. > > > > I think a better option would be to use python-support to make a single > > deb that supports all python versions. I intend to do that once urwid > > enters debian. More info here: > > I suggest on the contrary to do that before it enters Debian so that the > ftpmaster do not create packages that will disappear shortly after and so > that you don't have an upgrade path to handle. To clarify, the version I uploaded only has one package (python-urwid), supporting the default version of python (2.3). -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: building rpms on debian system?
On Thu, Apr 20, 2006 at 03:32:14PM -0400, Kris Deugau wrote:
> [This is probably the wrong list for this.]
>
> Ek Zindagoi wrote:
> > I would like to build rpms on a debian system for use on a redhat
> >system. Can I do that on a debian system ?
>
> In short, no; system libraries on a RedHat system likely have different
> versions (and soversions), as well as a few different filesystem paths.
> Libraries *will* have different names, except in a few very rare
> cases. (Worse, all Debian libraries have package names "lib";
> very few RH libs do unless the upstream name is libsomething.)
[...]
I'm not sure I've seen what seems to me to be the obvious solution
come through in a reply yet, but why not just create a custom chroot
for your target distribution (be it RHEL 4 or SUSE 9 or whatever)
and build in there? Do it a la pbuilder and just keep a tarfile of
the clean system archived so you can have several without taking up
much space, and upgrade them periodically as needed. Your only
limitation is that you're stuck in the chroot using whatever kernel
you've booted for Debian, but if that becomes an issue, UML to the
rescue (in some ways easier to manage than chroots, in my opinion).
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: python-urwid - Console UI Library for Python
On Fri, 21 Apr 2006, Ian Ward wrote: > >Given than Ian is the upstream author of the module, he is of course > >welcome in the team if he so wishes. Ian, just give me your alioth login > >if you are interested. > > Sure, but I am not a debian developer.. should I create a guest account > on alioth? Yes. > >I suggest on the contrary to do that before it enters Debian so that the > >ftpmaster do not create packages that will disappear shortly after and so > >that you don't have an upgrade path to handle. > > My understanding of debian packaging is quite limited. I tried to create > packages the same way I saw another python library packaged. If the > python-urwid package that enters the debian repositories is different > than what I have created, how do I transition people that are using my > repository to the new python-support way? Do I even have to? Packages won't conflict so the user may have both installed. We can consider adding conflicts to avoid this problem. > I would like to continue to support people that aren't running debian > unstable with packages for python2.1 (and python2.4 for ubuntu) The package with python-support would work with any python version. Ubuntu probably has python-support (in universe) so it shouldn't be a problem either. I'll let you check those details with Paul. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
php[4|5]+apache DSO - should I care about php4?
Hello, I'm working on debianizing my apache2 module (http://www.crackerjack.net/mod_bt/). My hope is to eventually become a debian package maintainer and supply debian with this apache2 extension. I've gotten the core shared libs and apache2 handler done, and now it's time for me to do the perl and php extensions. Of course, both php4 and php5 are still out there and probably both are widely used at this point. There's two ways I can think of to go about rolling .deb's for each: - change "--with-php-config" in my configure script to "--with-php4-config" and "--with-php5-config", which would do the exact same thing, only twice. :-) - build that part of the source tree twice with two different sets of configure options to create the two DSOs. But should I be overly concerned with building a php4- package? Or is PHP4 expected to be retired soonish? Also, the PHP module needs access to PHP, Apache2, and mod_bt's API all at once, which means that if php_mod_bt is being used from within a php.ini, mod_bt.so needs to be loaded before libphp4.so or libphp5.so. Convienently enough, "lib" comes earlier in a sort than "mod", so this happens by default already... but have there been other situations where apache2 module loading order was important, and if so, how were they handled? Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: php[4|5]+apache DSO - should I care about php4?
On Fri, Apr 21, 2006 at 01:58:08PM -0700, Tyler MacDonald wrote: > Of course, both php4 and php5 are still out there and probably both > are widely used at this point. There's two ways I can think of to go about > rolling .deb's for each: > > - change "--with-php-config" in my configure script to > "--with-php4-config" and "--with-php5-config", which would do the exact same > thing, only twice. :-) > > - build that part of the source tree twice with two > different sets of configure options to create the two DSOs. These two options seem more or less the same. It's quite common to do this, BTW -- see Python modules that build for multiple Python versions, or Apache modules that build for both 1.3 and 2 (libapache-mod-auth-mysql is an example of this). > But should I be overly concerned with building a php4- package? Or > is PHP4 expected to be retired soonish? Based on the Debian experience with PHP3, I'd doubt it. It's not even dead upstream yet, and PHP4 still has massive mindshare. Since converting existing code to PHP5 is non-trivial, I seriously doubt that PHP4 will be going away any time soon. That being said, there's no reason why you have to support PHP4. There's plenty of software out there that's PHP5 only; you just have to decide if the increased developer exposure is worth the extra maintenance burden. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: php[4|5]+apache DSO - should I care about php4?
Matthew Palmer <[EMAIL PROTECTED]> wrote: > > - change "--with-php-config" in my configure script to > > "--with-php4-config" and "--with-php5-config", which would do the exact same > > thing, only twice. :-) > > > > - build that part of the source tree twice with two > > different sets of configure options to create the two DSOs. > These two options seem more or less the same. It's quite common to do this, > BTW -- see Python modules that build for multiple Python versions, or Apache > modules that build for both 1.3 and 2 (libapache-mod-auth-mysql is an > example of this). I think I'm going to go with option #2, since if an individual is building from source and calling "configure" themselves, they'll probably only want to build against one of then anyways. > Based on the Debian experience with PHP3, I'd doubt it. It's not even dead > upstream yet, and PHP4 still has massive mindshare. Since converting > existing code to PHP5 is non-trivial, I seriously doubt that PHP4 will be > going away any time soon. > > That being said, there's no reason why you have to support PHP4. There's > plenty of software out there that's PHP5 only; you just have to decide if > the increased developer exposure is worth the extra maintenance burden. As it stands right now, php_mod_bt.so compiles cleanly against both php4 and php5 (even though it only uses php4's "php_apache.h" header at that! ha!)... so long as that remains true, I think I'm going to try to support both as debian packages. Thanks for the feedback! - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: thailatex (orphaned package for babel-based Thai latex support)
Dear mentors, I have adopted the orphaned thailatex package in the bug: http://bugs.debian.org/357871 And now the brand new package has been dressed up, waiting for sponsoring. Here is the package information: Package: thailatex License: BSD-style Description: This package provides Thai language add-on for Latex. It is based on babel package which comes with tetex distribution. . This package needs Thai words separator such as cttex and swath, in order for latex to be able to break sentences. The upstream project is hosted at: http://linux.thai.net/plone/TLWG/thailatex/ And the debianized source for 0.3.7-1 release, which I'm requesting for sponsor, is kept at: http://linux.thai.net/~thep/debian/source/thailatex/ Please help an orphan to survive. :-) Thank you, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/
Re: RFS: python-urwid - Console UI Library for Python
Raphael Hertzog wrote: On Fri, 21 Apr 2006, Paul Wise wrote: You are welcome to take over maintainership of it, or co-maintain it with me, perhaps buxy can add you to the python-modules SVN. Given than Ian is the upstream author of the module, he is of course welcome in the team if he so wishes. Ian, just give me your alioth login if you are interested. Sure, but I am not a debian developer.. should I create a guest account on alioth? I have packaged versions for python2.1, 2.2, 2.3 and 2.4, and I've made them available in an apt repository on excess.org. I think a better option would be to use python-support to make a single deb that supports all python versions. I intend to do that once urwid enters debian. More info here: I suggest on the contrary to do that before it enters Debian so that the ftpmaster do not create packages that will disappear shortly after and so that you don't have an upgrade path to handle. My understanding of debian packaging is quite limited. I tried to create packages the same way I saw another python library packaged. If the python-urwid package that enters the debian repositories is different than what I have created, how do I transition people that are using my repository to the new python-support way? Do I even have to? I would like to continue to support people that aren't running debian unstable with packages for python2.1 (and python2.4 for ubuntu) Ian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
