Re: RFS: gnome-rdp
Hi, Op vrijdag 18-05-2007 om 23:51 uur [tijdzone +0200], schreef David Paleino: > It builds this binary package: > gnome-rdp - remote desktop client for GNOME > > Here's the long description: > gnome-rdp is a Remote Desktop client for GNOME. It supports RDP, VNC and > SSH protocols. Maybe you can add an comparison to tsclient to the long description? What does this program have what tsclient does not have. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: exaile
Op ma, 04-12-2006 te 08:52 +0100, schreef Tobias Richter: > [EMAIL PROTECTED] wrote: > > On Nov 03 2006, Tobias Richter wrote: > > > It's waiting for ftpmaster approval in the NEW queue: > > > > > > http://ftp-master.debian.org/new.html > > > > Unfortunately, it still seems to be there. :-( I would love to get it in > > Debian proper [*]. > > The queue is manually processed beginning with the oldest packages. > exaile is regularly updated, so I doesn't make it to the top. It will not get to the top on the webpage, but the ftp-masters and ftp-assistents DO look at the age of the oldest upload. So a new upload does not reset the time it will take to get through NEW. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: Why isn't this packages.d.o page updated?
Op wo, 15-11-2006 te 18:53 +0100, schreef Nikolaus Schulz: > Hi, > > the current version of the archivemail package in unstable is 0.7.0-1 > (thanks Joeyh!), and it's correctly listed at > > http://packages.debian.org/archivemail, > > but > > http://packages.debian.org/unstable/mail/archivemail.html > > still shows the previous version 0.6.2-5. Why? The package now is in > unstable for 3 days. Is this a bug somewhere? Probably the script which updates those package has not run in a couple of days. I don't know which script is responsible though, maybe someone better informed can shed a light on this? But anyway I would not be bothered by it yet. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: Need a sponsor
Op ma, 16-10-2006 te 23:49 +0200, schreef Daniel Baumann: > Danny van der Meeren wrote: > > I'm searching for a sponsor for the amd64 binary package of glimpse > > You know that Debian has autobuilders? You (resp. your sponsor) need to > upload source + binaries for one architecture, the rest is done > automatically. > > The only possibility would be, if you have special package where the > i386 and the amd64 sources are not identical (with even different name, > too), which doesn't seem to be the case here. This was also my first reaction, but it is a package for non-free. IIRC those are not autobuild, are they? Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: haskell-uulib
Hi, I renew my request for sponsorship of haskell-uulib. I have updated the package after some comments of James Westby and got clarification about the license of some parts of the library. Below is the usual information for a RFS: As I am still in the NM queue I am searching for a sponsor for "haskell-uulib". * Package name: haskell-uulib Version : 0.9.2-2 Upstream Author : Doaitse Swierstra <[EMAIL PROTECTED]> and Arthur Baars <[EMAIL PROTECTED]> Daan Leijen <[EMAIL PROTECTED]> * URL : * License : LGPL and BSD Section : devel It builds these binary packages: libghc6-uulib-dev - parser and pretty print combinator library for GHC 6 libhugs-uulib - parser and pretty print combinator library for hugs98 haskell-uulib-doc - API documentation for uulib Haskell library The package is linda an lintian clean. An upload would close ITP bug 376415 The package can be downloaded from my repository: - URL: http://moonshine.dnsalias.org/debian/unstable - Source repo: deb-src http://moonshine.dnsalias.org/debian unstable/ - dget http://moonshine.dnsalias.org/debian/unstable/haskell-uulib_0.9.2-2_i386.changes An upload would be appreciated. Greetings Arjan Oost p.s. Don't forget the -sa -v0.9.2-0 flags for dpkg-buildpackage when rebuilding the package. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: License DData (was Re: RFS: haskell-uulib)
Op za, 30-09-2006 te 20:29 +0100, schreef James Westby: > Hi Arjan, > > Has there been any progress on this issue? Did not hear anything from the original author of UU.DData yet. The upstream maintainer is planning on dropping the UU.DData parts of the library, but right now he still needs them for another program (uuagc) which builds against UU.DData. I have provided him patches to compile uuagc against some other libraries instead of UU.Data and upstream is looking at them I will wait a little bit longer for a response of the original author and else I repackage the upstream tarbal without the UU.DData parts. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: [Fwd: RFS: libmtp] (reminder)
Op di, 26-09-2006 te 16:20 +0100, schreef James Westby:
> On (26/09/06 11:09), Jean Parpaillon wrote:
> > I am looking for a sponsor for my package "libmtp".
>
> Hi I cannot sponsor, but I have some comments,
>
> * Can you please expand the long description. At least mention what
> the MTP is, and what sort of devices support it.
> * Should libmtp-doc be in Section: doc?
> * Please dtop using ${Source-Version}, see
> http://lists.debian.org/debian-mentors/2006/09/msg00228.html
> * Please sort out the debian/copyright, see
> http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
> Also there are more copyright holders to find, and a few files with
> unclear copyright status that should be clarified upstream.
> * I'm not sure whether you should install the rules in rules.d or in
> the parent dir and add a symlink.
From /usr/share/doc/udev/README.Debian.gz:
MAINTAINERS BEWARE: the use of /etc/udev/rules.d/ by other packages is
discouraged, except when only RUN rules are added.
If you think your package needs to create a file there, then please
contact the udev package maintainer and explain your needs.
Packages should NEVER create files in /etc/udev/rules.d/, but create a
symlink the first time the package is installed (and never try again, to
allow the local system administrator to remove it).
So contact Md and don't install any files in /etc/udev/rules.d!
Greetings Arjan
signature.asc
Description: Dit berichtdeel is digitaal ondertekend
Re: Where is "urgency=" documented?
Op do, 28-09-2006 te 10:06 +0900, schreef Charles Plessy: > Dear Mentors, > > As I am preparing the upload a package which fixes a versioning mistake > (1.x uploaded as 2.0), I was wondering if it would make sense to set an > urgency higher than "low" so that the package migrates faster to > testing. > > The package is very simple (one binary), and provides a functional test > which was passed successfuly. > > But I did not find a detailed explanation in the policy or the > developper's reference. Do you know where the impact of changing the > urgency is documented? From policy: The package must have been available in unstable for several days; the precise number depends on the upload's urgency field. It is 10 days for low urgency, 5 days for medium urgency and 2 days for high urgency. Those delays may be doubled during a freeze; And also see a mail on devel-announce: http://lists.debian.org/debian-devel-announce/2006/07/msg8.html Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: frown
Hi, I hereby renew my request for sponsorship. I have update the package after some remarks of James Westby and Stephane Bortzmeyer and hope that someone is willing to upload it, * Package name: frown Version : 0.6.1-3 Upstream Author : Ralf Hinze <[EMAIL PROTECTED]> * URL : http://www.informatik.uni-bonn.de/~ralf/frown/index.html * License : GPLv2 Section : devel It builds these binary packages: frown - LALR(k) parser generator for Haskell 98 The package is linda an lintian clean. An upload would close ITP bug 336978. The package can be downloaded from my repository: - URL: http://moonshine.dnsalias.org/debian/unstable - Source repo: deb-src http://moonshine.dnsalias.org/debian unstable/ - dget http://moonshine.dnsalias.org/debian/unstable/frown_0.6.1-3_i386.changes Greetings Arjan Oosting signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: Tunapie
Op ma, 25-09-2006 te 13:07 +0100, schreef James Stone: > On Mon, 25 Sep 2006 12:14:47 +0200, Thomas Huriaux wrote: > > > There are still a few warnings in 1.0-4: > > W: tunapie source: uses-dh-python-with-no-pycompat > > W: tunapie source: not-using-po-debconf > > W: tunapie source: out-of-date-standards-version > > 3.6.2 (current is 3.7.2) E: tunapie source: > > missing-dh_python-build-dependency python | > > python-dev | python-all-dev > > None of these come up on lintian (1.23.24) on my system. Strange, I see them here. > I was not sure about python deps because it depends on > python-wxgtk2.6 > > And I was assuming this would do the right thing in terms > of selecting an appropriate python version because of it's > dependence on python. The last thing I wanted to do was specify > a version of python that won't work with wx. > > > W: tunapie: script-not-executable ./usr/share/tunapie/Tunapie.py W: > > tunapie: script-not-executable ./usr/share/tunapie/tuneradult.py W: > > tunapie: script-not-executable ./usr/share/tunapie/tuner.py W: tunapie: > > script-not-executable ./usr/share/tunapie/tunersafe.py W: tunapie: I don't know anything about the new python-policy, but usaually lintian is right: E: tunapie source: missing-dh_python-build-dependency python | python-dev | python-all-dev N: N: The package runs dh_python in debian/rules but doesn't build-depend on N: python or python-dev. dh_python requires /usr/bin/python to run, so N: packages using dh_python must build-depend on python (or python-dev or N: python-all-dev, which in turn depend on python), even if they don't N: otherwise need Python to build. N: N: Refer to the dh_python(1) manual page for details. > In my opinion these are stupid warnings.. The python scripts are not > supposed to be executable.. they are run by the main program. Still, > does this need to be fixed for Debian? If so, how? Is there a way to > chmod them preinstall? If the are not supposed to be executable, you should remove the she-bang line (#!/usr/bin/env python) from the files. If you want them to be executable you can do a chmod in your debian/rules file. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: frown
Op za, 16-09-2006 te 18:20 +0100, schreef James Westby: > > > I have a couple of questions if you could answer them for me, (purely > > > out of interest > > > You have gone with cdbs handling debian/control. This is unpopular, can > > > you tell me why you chose it? > > Well it is very bad manners to do this on build time and the ftp-masters > > will reject the package if it does this. > > Yes I realise that. Though I don't think a REJECTED mail is strong > enough for this! Well the reason for that are quite clear in the REJECT FAQ, which boils down to that it is against policy and that is should be clear which binary packages a package produces by looking at the debian/control file. Furthermore updating the control file during build can cause changes in the source package between builds which is a side-effect that should be prevented. > > > The update-haskell-control stuff seems unecessary to me (I realise it is > > > not your choice.) Can you tell me why it is done like this? > > Well it substitutes some Haskell related variables (right build > > dependencies on ghc6, list of ghc6 arches etc) which can be especially > > usefull if the package contains a Haskell library. But right now I only > > use it to keep track of the list of Architectures frown can be build > > on. > > I was more asking why it added a list of architectures. Almost every > other package gets by with arch: any. It is also recommended to only > restrict the architectures for very specific reasons, does that apply to > Haskell? You could make a case for making it Arch: any, but I decided to keep using the list provided by update-haskell-control to keep all my Haskell packages consistent. The list of architectures that support ghc6 does not change that quickly so it is no problem in this case. I guess it is a matter of taste here and there is not big technical reason why I choose the specific architecture list instead of the usual Arch: any. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: haskell-edison
Hi James,
Thanks for reviewing another package.
Op do, 21-09-2006 te 17:31 +0100, schreef James Westby:
> Hi,
>
> Apologies that it took me a while to get to this package, it is more
> complex than the other two, and put me off each time I came to it until
> now.
Hehe,
It also took me some time to make it.
> The package looks good, apart from two things,
>
> * When using ${binary:Version} or ${source:Version} you need to add a
> versioned build-dep on dpkg-dev, see
> http://lists.debian.org/debian-mentors/2006/09/msg00228.html
> Note that this may apply to your other packages, could you please
> check? It only got added to my mental checklist recently.
Hmpf,
Thanks for noticing this. I have updated the package. New version is
available from my repository [1].
> * Your debian/copyright appears correct, but what worries me is that
> the upstream files say
> "License : BSD3; see COPYRIGHT file for terms and conditions"
> but the COPYRIGHT file doesn't contain BSD3. Is it worth seeking
> clarification?
Indeed. Again thanks for noticing. I will ask upstream.
> The packages look good overall. I hope you find a sponsor.
Thanks.
Greetings Arjan
[1] dget
http://moonshine.dnsalias.org/debian/unstable/haskell-edison_1.2.0.1-2_i386.changes
signature.asc
Description: Dit berichtdeel is digitaal ondertekend
Re: Watch files and QA page
Op do, 21-09-2006 te 09:23 -0700, schreef Patrick Ruckstuhl: > Hi, > > a package I'm maintaining (aria2) has a working watch file in it, but on > the debian QA page, there is no entry in the watch column. What could be > the reason for this? Do I have to do anything special or does it take > more time? (the package was uploaded around 11 days ago and entered > testing). You don't have to do anything. This just takes some/a lot of time. Just wait patiently. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: haskell-uulib
Hi James, Op za, 16-09-2006 te 00:35 +0100, schreef James Westby: > Hi, > > Again I cannot sponsor, but I have some comments on the package. > > * Also there is some boilerplate in files under debian/ that could be > removed (debian/rules and debian/watch specifically). Fixed in svn, will be in next upload. > Now, if only I could remember how to use Haskell so that I could check > all these packages. You should really do that, Haskell is a great language :-D Again thanks for the review. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: frown
Op za, 16-09-2006 te 00:13 +0100, schreef James Westby: > On (15/09/06 23:21), Arjan Oosting wrote: > > Hi potential sponsors, > > > > As I am still in the NM queue I am searching for a sponsor for "frown". > > > > * Package name: from > > Hi, package looks pretty cool. Thanks for packaging it. Thanks :-) > Only two very minor points I can make. > > * Homepage is by convention indented by two spaces. Fixed it in svn, > * debian/dirs is redundant here. Huh? Why is it redundant? The upstream Makefile does not create $(bindir) so I debian/dirs to make sure usr/bin exists. > Also you could use debian/compat 5, but there's no real need. Updated anyway in svn. I don't think these two changes require a new upload, but the changes will be included in 0.6.1-3. > I have a couple of questions if you could answer them for me, (purely > out of interest > You have gone with cdbs handling debian/control. This is unpopular, can > you tell me why you chose it? Well it is very bad manners to do this on build time and the ftp-masters will reject the package if it does this. I only have an additional Makefile target update-debian-control which I call manually to update dependencies when I update the package. Now for the why. The main reason is that I because the package uses CDBS and I am to lazy to keep up with the list of Build-Depends CDBS needs. ;-) > The update-haskell-control stuff seems unecessary to me (I realise it is > not your choice.) Can you tell me why it is done like this? Well it substitutes some Haskell related variables (right build dependencies on ghc6, list of ghc6 arches etc) which can be especially usefull if the package contains a Haskell library. But right now I only use it to keep track of the list of Architectures frown can be build on. Thanks for the review. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
License DData (was Re: RFS: haskell-uulib)
[ cc-ed Daan Leijen as he is the author of the DData library and Alexey Rodriguez as he is the upstream maintainer of uulib ] Hi Daan and Alexey, I am trying to get the uulib Haskell library (formarly known as uust) of the Utrecht University into the Debian archive. As you probably know this library contains your DData library as UU.DData. Op za, 16-09-2006 te 00:35 +0100, schreef James Westby: > * I'm not sure about debian/copyright. I usually like to see who holds > copyright over which file in the package. Well I can try to make that a little bit clearer. but the files don't contain version history so it is almost impossible to say by whom lies the copyright for each file. > Also the non LGPL files > are just said to be under a 'BSD-style' license as far as I can see. > In debian/copyright you assign them the BSD license. Do you have any > thing that shows that they meant the BSD license, and indeed the 3 > clause BSD? No I have not. I tried to find information on the webpage of DData but could not find the explicit license so I assumed it was the 3-clause BSD license also used by GHC. Daan, I tried to find the specific licencing terms of DData but could only find two emails [1,2] in which is stated that you have a specific BSD-style licence for DData: I think though that it would be best if you first create a package with your proposal for review before adding it to fptools. Furthermore, we should add a proper BSD style license to all the sources. I have a specific license which I will send to you that should be attached, as I have agreed this license upon some (undisclosed) companies that are using the DData library. Could you send the specific license you have in mind, so I can add that information to the Debian package and get uulib into Debian and Alexey can add the information to his COPYRIGHT file as well ? Greetings Arjan Oosting signature.asc Description: Dit berichtdeel is digitaal ondertekend
RFS: haskell-edison
Hi potential sponsors, As I am still in the NM queue I am searching for a sponsor for "haskell-edison". * Package name: haskell-edison Version : 1.2.0.1 Upstream Author : Original author Chris Okasaki, currently maintained by Robert Dockins <[EMAIL PROTECTED]> * URL : http://www.eecs.tufts.edu/~rdocki01/edison.html * License : MIT/X Programming Lang: Haskell Description : Haskell library of efficent, purely-functional data structures It builds these binary packages: libghc6-edison-api-dev - the Edison API (the type classes) for use with ghc6 libghc6-edison-core-dev - some implementations of the Edison API for use with ghc6 libhugs-edison-api - the Edison API (the type classes) for use with hugs libhugs-edison-core - some implementations of the Edison API for use with hugs haskell-edison - API documentation The package is linda an lintian clean. An upload would close ITP bug 382184 The package can be downloaded from my repository: - URL: http://moonshine.dnsalias.org/debian/unstable - Source repo: deb-src http://moonshine.dnsalias.org/debian unstable/ - dget http://moonshine.dnsalias.org/debian/unstable/haskell-edison_1.2.0.1-1_i386.changes An upload would be appreciated. Greetings Arjan Oosting signature.asc Description: Dit berichtdeel is digitaal ondertekend
RFS: frown
Hi potential sponsors, As I am still in the NM queue I am searching for a sponsor for "frown". * Package name: from Version : 0.6.1-2 Upstream Author : Ralf Hinze <[EMAIL PROTECTED]> * URL : http://www.informatik.uni-bonn.de/~ralf/frown/index.html * License : GPLv2 Section : devel It builds these binary packages: frown - LALR(k) parser generator for Haskell 98 The package is linda an lintian clean. An upload would close ITP bug 336978. The package can be downloaded from my repository: - URL: http://moonshine.dnsalias.org/debian/unstable - Source repo: deb-src http://moonshine.dnsalias.org/debian unstable/ - dget http://moonshine.dnsalias.org/debian/unstable/frown_0.6.1-2_i386.changes An upload would be appreciated. Greetings Arjan Oosting signature.asc Description: Dit berichtdeel is digitaal ondertekend
RFS: haskell-uulib
Hi potential sponsors, As I am still in the NM queue I am searching for a sponsor for "haskell-uulib". * Package name: haskell-uulib Version : 0.9.2-1 Upstream Author : Doaitse Swierstra <[EMAIL PROTECTED]> and Arthur Baars <[EMAIL PROTECTED]> Daan Leijen <[EMAIL PROTECTED]> * URL : * License : LGPL and BSD Section : devel It builds these binary packages: libghc6-uulib-dev - parser and pretty print combinator library for GHC 6 libhugs-uulib - parser and pretty print combinator library for hugs98 haskell-uulib-doc - API documentation for uulib Haskell library The package is linda an lintian clean. An upload would close ITP bug 376415 The package can be downloaded from my repository: - URL: http://moonshine.dnsalias.org/debian/unstable - Source repo: deb-src http://moonshine.dnsalias.org/debian unstable/ - dget http://moonshine.dnsalias.org/debian/unstable/haskell-uulib_0.9.2-1_i386.changes An upload would be appreciated. Greetings Arjan Oosting signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: anaconda
Op di, 12-09-2006 te 23:36 -0700, schreef Ryan Finnie: > On 9/12/06, Carlo Segre <[EMAIL PROTECTED]> wrote: > > > > I noticed that you first filed the ITP in June. Since then, we have had a > > python transition to 2.4 and there is a new standard for python packaging. > > Th python2.X-package type packages are no longer the norm. You will need > > to convert your package to either python-central or python-support. > > The wiki docs made it rather easy to understand and convert over to a > unified python package, but I need a small clarification. Since my > python package provides only public extensions (no .py modules), I do > not need to reference python-support/python-central, correct? > python-support/python-central are needed only for bytecompilation of > modules? > > Also, since I already uploaded to mentors.debian.net, I will have to > bump the revision from 11.1.0.50-1 to 11.1.0.50-2. -1's changelog > entry is "Initial release (Closes: #376187)" (the ITP), but since -1 > never actually made it to incoming, what is the procedure for making > sure the eventual upload will close the ITP? Should I put "Initial > release (Closes: #376187)" again in the changelog for -2? Remove -1's > changelog entry completely? No, do not modify your earlier changelog. To close the ITP during upload your sponsor can rebuild the package with -v11.1.0.50-0 argument to dpkg-buildpackage. This will make sure your the changelog of -1 and -2 is included it the changes file used during upload. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: detecting cutomized conffiles and debconf
Hi Mattia, Op ma, 11-09-2006 te 21:01 +0200, schreef Mattia Dongili: > Hello Mentors, > > to make the long story short this is an "how to deal existing conffiles > and a new set of debconf questions to setup the package?" question. > > Now, the package is cpufrequtils and what I'd like to achieve is > providing some nice debconf templates to configure > /etc/default/cpufrequtils which will allow the user to set a boottime > policy. > At the same time I'd like to avoid annoying users who already customized > their configuration (I assume they don't need to be questioned again) > and obviously avoid overwriting their customized file. > > Which is the way to go? > AFAICT debsums could help or maybe should I not make > /etc/default/cpufrequtils a conffile and manually manage it? If you change the contents of a configuration file in your maintainer scripts, for instance by using debconf, they should not be conffiles but regular configuration files. See Debian policy on this. You should stop shipping the file as conffile, read in the configfile in your preinst, save the values for use with debconf, and then make the file a configuration file. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: File permissions
Op ma, 11-09-2006 te 22:25 +1000, schreef James Healy: > Mentors, > > I am attempting to build a package and lintian is spitting out a bunch > of "executable-not-elf-or-script" warnings. > > The upstream tarball has an examples directory which I am installing > into the package using dh_installexamples. None of the examples are > shell scripts or ELF binaries, yet they seem to untar with executable > permissions. > > What is the best way to modify the permissions when I copy them over? Hi, Disregard my previous advise. I should have read the man page of dh_fixperms first: dh_fixperms makes all files in usr/share/doc in the package build directory (excluding files in the examples/ directory) be mode 644. So it seems you have to do it with a call to chmod in your debian/rules. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: File permissions
Op ma, 11-09-2006 te 22:25 +1000, schreef James Healy: > Mentors, > > I am attempting to build a package and lintian is spitting out a bunch > of "executable-not-elf-or-script" warnings. > > The upstream tarball has an examples directory which I am installing > into the package using dh_installexamples. None of the examples are > shell scripts or ELF binaries, yet they seem to untar with executable > permissions. > > What is the best way to modify the permissions when I copy them over? Call dh_fixperms after dh_installexamples in your debian/rules file. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: aria2 [sponsored again]
Op za, 02-09-2006 te 20:41 +0200, schreef Christoph Haas: > On Saturday 02 September 2006 20:19, Patrick Ruckstuhl wrote: > > >>> - please do not remove old debian/changelog entries. You already > > >>> closed the bug reports in the 0.7.2 version > > >> > > >> I thought because the package was rejected it is still the first > > >> upload (and therefore the first changelog entry with the closes). > > >> After the package is in debian it's clear to keep (and extend) the > > >> changelog. > > > > > > Basically you are right. I'm just a member of the "don't fake the > > > revision"-club. Some people insist that a Debian package's revision > > > must be "-1" to be uploaded. However often a package takes a few tries > > > until it's released so a revision can become 1.0-7 which is no problem > > > at all. I'm just comparing previous packages with newer packages and > > > wonder why debian/changelog entries disappear magically. > > > > So does the bts look at all changelog entries? Not only the latest > > (and would therefore not close the bug)? > > You got me. I believe only bugs are closed in the BTS that are listed in > the most current changelog entry because that's what makes it into the > source control file during the upload. > look at the -v flag of dpkg-buildpackage. From the manpage: -vversion In dpkg-buildpackage, dpkg-genchanges and dpkg-parsechangelog this causes changelog information from all versions strictly later than version to be used. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: anymeal
Op do, 31-08-2006 te 11:19 +0200, schreef Sandro Tosi: > Hi Thijs & d-mentors all, > > > Maybe you can address these things in your next version. Because of > > these are small issues I've uploaded this version now. > > (damn spam filters, I've noticed only now...) Upload of anymeal in > unstable has been rejected by FTP master due to this: > > rejected, you miss to mention the different license of the documentation, > and as thats GFDL you need to check if its one thats allowed in main. - > I've checked in the code by found reference of LGPL only in > acinclude.m4 and admin/acinclude.m4.in that have a copyright note in > their top as: The mail of the ftp-master mentions that the documentation is licensed under the GFDL. I see no mentioning of the LGPL there. You should check the documentation and see if it contains any invariant sections which would make the documentation non-free [1] Greetings Arjan [1] http://www.debian.org/vote/2006/vote_001#outcome signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: queuegraph (take two)
Op do, 31-08-2006 te 12:14 +0300, schreef George Danchev: > I grabbed some of your packages[1], but failed to see any text you claim any > copyright over your packaging. I'm just curious if there is any standard text > wrt to that like: > > It was downloaded from > ... > Upstream Author > ... > > since I wouldn't be impressed so much by any sort of free style poetry ;-): From /usr/share/debhelper/dh_make/licenses/gpl: On Debian systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL'. The Debian packaging is (C) #YEAR#, #USERNAME# <#EMAIL#> and is licensed under the GPL, see above. And I usually use something likes this Debian packaging copyright: (C) 2004-2006 Arjan Oosting <[EMAIL PROTECTED]> The Debian packaging may be redistributed and/or modified under the same terms as DrIFT itself. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
RFS: uuagc
Hi potential sponsors, I am searching for a sponsor for uuagc. * Package name: uuagc Version : 0.9.1 Upstream Author : Doaitse Swierstra <[EMAIL PROTECTED]>, Arthur Baars <[EMAIL PROTECTED]> and Alexey Rodriguez <[EMAIL PROTECTED]> * URL : http://www.cs.uu.nl/wiki/HUT/AttributeGrammarSystem * License : GPL Programming Lang: Haskell Description : compiler for the Utrecht University Attribute Grammar system The Attribute Grammar system can be used to annotate the production rules of a grammar with inherited and synthesized attributes. The values of the attributes can be determined while parsing/traversing an abtract syntax tree and will give the semantic value of the tree. . The inherited attributes are values which ares passed downwards in the abstract syntax tree and the synthesized attributes are passed upward. Haskell expressions are used to describe the computation of the attributes. . The uuagc compiler takes a set files in which the attribute grammar is defined and generate a Haskell file which contains the datatype definitions that corresponding to the grammar, semantic functions and catamorphisms (functions that take a syntax tree and return the semantic value of that tree) . The (Utrecht University) Attribute Grammar system is part of the Haskell Utrecht Tools set. . This package needs haskell-uulib to build, which also still needs a sponsor [1]. So anyone who is interested in sponsoring this package might sponsor haskell-uulib just as well. The package is of course linda and lintian clean and can be downloaded by doing dget http://moonshine.dnsalias.org/debian/unstable/uuagc_0.9.1-1_i386.changes Greetings Arjan Oosting [1] http://lists.debian.org/debian-mentors/2006/07/msg00354.html signature.asc Description: Dit berichtdeel is digitaal ondertekend
RFS: haskell-uulib
Hi, I am searching for a sponsor for the uulib Haskell library: * Package name: haskell-uulib Version : 0.9.2 Upstream Author : Doaitse Swierstra <[EMAIL PROTECTED]>, Arthur Baars <[EMAIL PROTECTED]>, Daan Leijen <[EMAIL PROTECTED]> and others * URL : http://www.cs.uu.nl/wiki/HUT/ * License : Partly LGPL and partly BSD Programming Lang: Haskell Description : uulib parser and pretty print combinator library for Haskell The uulib Haskell library contains fast, error repairing parser combinators (UU.Parsing), pretty print combinators (UU.Pretty) and a set of data structures and algorithms for working with sets and sequences (UU.DData) for Haskell. . The library is developed at Utrecht University and is part of the Haskell Utrecht Tools. . Homepage: http://www.cs.uu.nl/wiki/HUT/WebHome This package contain the fast error correcting parser combinators and the pretty print combinators developed at Utrecht University. This package is also a reverse dependency of the Utrecht Attribute Grammar System (uuagc, ITP #376491) and helium, the Haskell compiler designed for learning Haskell, (ITP #365728). The debian package is linda en lintian clean and can be downloaded from my website [1] by doing: dget http://moonshine.dnsalias.org/debian/unstable/haskell-uulib_0.9.2-1_i386.changes Greetings Arjan. [1] http://moonshine.dnsalias.org/debian/unstable/ signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: fetchexc (updated: 1.10-2)
Op ma, 10-07-2006 te 11:02 +1000, schreef Ted Percival: > > I seem to remember seeing somewhere that uploading 1.10-2 would mean > > that the ITP "Closes" in the changelog from the 1.10-1 package won't be > > processed. I can easily re-roll the changelog to include the new closes > > line if that's the best way. > > I'll bring it all back to a single changelog entry at version 1.10-1 > with the ITP "Closes" in an upload when I get home this evening. It's > probably worth waiting until I upload that package before assessing it. > Hopefully it will really be ready by then. That is not really necessary. You can use the -v flag of dpkg-buildpackage to include earlier changelog entries, so no need to rewrite history. If you use the -v flag you probably want to use -the -sa flags as well to make sure the source (orig.tar.gz) is included when it is uploaded. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: [Debian-haskell] Re: RFS: c2hs -- C->Haskell Interface Generator
Hi people,
Thanks for reviewing my package.
Op za, 01-07-2006 te 04:04 -0500, schreef John Goerzen:
> > You have a bashism in debian/rules:
> >
> > cp -f /usr/share/misc/config.{sub,guess} .
> > cp: cannot stat `/usr/share/misc/config.{sub,guess}': No such file or
> > directory
> > make: *** [config.status] Error 1
> > debuild: fatal error at line 1224:
> > debian/rules build failed
> >
> > It will likely not pass all autobuilders until this is corrected.
en op za, 01-07-2006 te 12:33 +0300, schreef Kari Pahula:
> Looks solid. However, one thing:
>
> > c2hs (0.14.5-1) unstable; urgency=low
> > - move groff and linuxdoc-tools to Build-Depends-Indep.
>
> The buildds will call debian/rules build, even though they're only
> building architecture dependent packages. Specifically they won't
> install Build-Depends-Indep. Your current debian/rules will fail with
> dpkg-buildpackage -B when Build-Depends-Indep remain uninstalled.
I fixed both issues and uploaded -3 to my homepage [1]. It is lintian
and linda clean should now build on buildds (I have tested this with
pdebuild --debbuildopts -B -- --binary-arch)
The packages is downloadable by doing:
dget http://moonshine.dnsalias.org/debian/unstable/c2hs_0.14.5-3_i386.changes
If one wants to rebuild and upload this, don't forget the
dpkg-buildpackage flags "-sa -v0.13.6-5" to include the complete
changelog and source.
Greetings Arjan
[1] http://moonshine.dnsalias.org/debian/unstable
c2hs (0.14.5-3) unstable; urgency=low
.
* Fix broken debian/rules:
- Let build only depend on binary-arch as dpkg-buildpackage (and thus
the buildds) will call build even when it is only building the
architecture dependent packages. (thanks Kari Pahula)
- Fix bashism. (thanks John Goerzen)
.
c2hs (0.14.5-2) unstable; urgency=low
.
* Update package for ghc6 version 6.4.2.
* debian/control.in:
- remove libghc6-cabal-dev from Build-Depends.
- add ghc6 (>= 6.4.2) to Build-Depends to get Cabal version >= 1.1.4.
- add ppc64 to Architectures as ghc6 is now available on ppc64.
* debian/patches/01_update-manpage.dpatch: updated. Fix typo.
* debian/patches/06_fix-Setup-for-ghc-6.4.2.dpatch: added. Replace
Setup.hs with version from upstream VCS to fix build with ghc 6.4.2.
.
c2hs (0.14.5-1) unstable; urgency=low
.
* New upstream release. Closes: #372836
- no longer ships a library for ghc6.
* New maintainer. Closes: #342801
* debian/c2hs-doc.doc-base: change section to Apps/Programming.
* added debian/control.in
- drop the libghc6-c2hs-dev package.
- use $ghc6_app_bdeps, $ghc6_arches substitution variables from
update-haskell-control to get the build dependency on ghc6 and
architecture list for c2hs.
- replace ${Source-Version} with ${binary:Version} and
${source:Version} to make the package binNMU safe.
- add build dependency on dpkg-dev (>= 1.13.19) which introduces
${binary:Version} and ${source:Version}.
- move groff and linuxdoc-tools to Build-Depends-Indep.
* debian/copyright: add copyright notice for the manual which is
licensed under the GNU Free Document License.
* debian/patches/*: remove old patches and change to dpatch.
* debian/rules: change from cdbs to debhelper.
* debian/watch: upgrade to format version 3.
signature.asc
Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: c2hs -- C->Haskell Interface Generator
> On Fri, Jun 30, 2006 at 10:59:27PM +0200, Arjan Oosting wrote: >> Could someone look at my package and upload it? > > Looks solid. However, one thing: > >> c2hs (0.14.5-1) unstable; urgency=low >> - move groff and linuxdoc-tools to Build-Depends-Indep. > > The buildds will call debian/rules build, even though they're only > building architecture dependent packages. Specifically they won't > install Build-Depends-Indep. Your current debian/rules will fail with > dpkg-buildpackage -B when Build-Depends-Indep remain uninstalled. > > You could do something like this in your debian/rules: > > install-indep: build-indep-stamp > dh_testdir > dh_testroot > dh_clean -k -i > dh_installdirs -i > if [ -e /usr/bin/sgml2html ] ; then $(MAKE) DESTDIR=debian/tmp > install-doc ; fi > dh_install -i Your completely right. I will fix this. One question though. The buildds first call build and will they then call binary or binary-arch? Greetings Arjan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-haskell] Re: RFS: c2hs -- C->Haskell Interface Generator
Hi John,
Thanks for looking at my package
> You have a bashism in debian/rules:
>
> cp -f /usr/share/misc/config.{sub,guess} .
> cp: cannot stat `/usr/share/misc/config.{sub,guess}': No such file or
> directory
> make: *** [config.status] Error 1
> debuild: fatal error at line 1224:
> debian/rules build failed
>
> It will likely not pass all autobuilders until this is corrected.
Hmpf, I will fix this tonight and upload a new package. I make a note to
use checkbashims on the rules files next time :)
Greetings Arjan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: c2hs -- C->Haskell Interface Generator
Op ma, 26-06-2006 te 23:50 +0200, schreef Arjan Oosting:
> Hi people,
>
> I intent to adopt c2hs (#342801) and prepared an updated packages which
> upgrades the package to upstream version 0.14.5. The complete changelog
> can be found below.
>
> I am searching for a sponsor to check and upload the package (I am still
> in the NM queue).
Hi people,
I am still searching for a sponsor. I have upgraded the package for the
new ghc6 version and uploaded this new version to my website [1]. The
package is still linda and lintian clean. The source can be downloaded
by doing
dget http://moonshine.dnsalias.org/debian/unstable/c2hs_0.14.5-2_i386.changes
When rebuilding take care to include the -sa and -v0.13.6-5 for
dpkg-buildpackage. This makes sure the source and the complete changelog
will be included when the package is uploaded.
Could someone look at my package and upload it?
Greetings Arjan Oosting
[1] http://moonshine.dnsalias.org/debian/unstable
c2hs (0.14.5-2) unstable; urgency=low
.
* Update package for ghc6 version 6.4.2.
* debian/control.in:
- remove libghc6-cabal-dev from Build-Depends.
- add ghc6 (>= 6.4.2) to Build-Depends to get Cabal version >= 1.1.4.
- add ppc64 to Architectures as ghc6 is now available on ppc64.
* debian/patches/01_update-manpage.dpatch: updated. Fix typo.
* debian/patches/06_fix-Setup-for-ghc-6.4.2.dpatch: added. Replace
Setup.hs with version from upstream VCS to fix build with ghc 6.4.2.
.
c2hs (0.14.5-1) unstable; urgency=low
.
* New upstream release. Closes: #372836
- no longer ships a library for ghc6.
* New maintainer. Closes: #342801
* debian/c2hs-doc.doc-base: change section to Apps/Programming.
* added debian/control.in
- drop the libghc6-c2hs-dev package.
- use $ghc6_app_bdeps, $ghc6_arches substitution variables from
update-haskell-control to get the build dependency on ghc6 and
architecture list for c2hs.
- replace ${Source-Version} with ${binary:Version} and
${source:Version} to make the package binNMU safe.
- add build dependency on dpkg-dev (>= 1.13.19) which introduces
${binary:Version} and ${source:Version}.
- move groff and linuxdoc-tools to Build-Depends-Indep.
* debian/copyright: add copyright notice for the manual which is
licensed under the GNU Free Document License.
* debian/patches/*: remove old patches and change to dpatch.
* debian/rules: change from cdbs to debhelper.
* debian/watch: upgrade to format version 3.
signature.asc
Description: Dit berichtdeel is digitaal ondertekend
RFS: frown -- LALR(k) parser generator for Haskell 98
Hi people, I am searching for a sponsor for frown. Frown is a parser generator for Haskell. It has similar syntax to Happy, another parser generator for Haskell, but frown has a couple of features not found in happy. * Package name: frown Version : 0.6 Upstream Author : Ralf Hinze <[EMAIL PROTECTED]> * URL : http://www.informatik.uni-bonn.de/~ralf/frown/index.html * License : GPL version 2 Description: LALR(k) parser generator for Haskell 98 I have packaged frown because it is a build-dependency of another package I am maintaining. The package can be downloaded from my website [1] and can the source package can be downloaded by doing dget http://moonshine.dnsalias.org/debian/unstable/frown_0.6.1-2_i386.changes When rebuilding the package don't forget to include the complete changelog and source by using the -sa -v0.6.0-0 flags when calling dpkg-buildpackage. Greetings Arjan Oosting [1] http://moonshine.dnsalias.org/debian/unstable Long description: Its salient features are: - The generated parsers are time and space efficient. On the downside, the parsers are quite large. - Frown generates four different types of parsers. As a common characteristic, the parsers are genuinely functional (ie 'table-free'); the states of the underlying LR automaton are encoded as mutually recursive functions. Three output formats use a typed stack representation, one format due to Ross Paterson (code=stackless) works even without a stack. - Encoding states as functions means that each state can be treated individually as opposed to a table driven-approach, which necessitates a uniform treatment of states. For instance, look-ahead is only used when necessary to resolve conflicts. - Frown comes with debugging and tracing facilities; the standard output format due to Doaitse Swierstra (code=standard) may be useful for teaching LR parsing. - Common grammatical patterns such as repetition of symbols can be captured using rule schemata. There are several predefined rule schemata. - Terminal symbols are arbitrary variable-free Haskell patterns or guards. Both terminal and nonterminal symbols may have an arbitrary number of synthesized attributes. - Frown comes with extensive documentation; several example grammars are included. . Furthermore, Frown supports the use of monadic lexers, monadic semantic actions, precedences and associativity, the generation of backtracking parsers, multiple start symbols, error reporting and a weak form of error correction. . Homepage: http://www.informatik.uni-bonn.de/~ralf/frown/index.html signature.asc Description: Dit berichtdeel is digitaal ondertekend
RFS: c2hs -- C->Haskell Interface Generator
Hi people,
I intent to adopt c2hs (#342801) and prepared an updated packages which
upgrades the package to upstream version 0.14.5. The complete changelog
can be found below.
I am searching for a sponsor to check and upload the package (I am still
in the NM queue).
The package is linda and lintian clean and can be found on my website
[1]. The source can be downloaded by doing
dget http://moonshine.dnsalias.org/debian/unstable/c2hs_0.14.5-1_i386.changes
Greetings Arjan Oosting
[1] http://moonshine.dnsalias.org/debian/unstable
* New upstream release. Closes: #372836
- no longer ships a library for ghc6.
* New maintainer. Closes: #342801
* debian/c2hs-doc.doc-base: change section to devel.
* added debian/control.in
- drop the libghc6-c2hs-dev package.
- use $ghc6_app_bdeps, $ghc6_arches substitution variables from
update-haskell-control to get the build dependency on ghc6 and
architecture list for c2hs.
- replace ${Source-Version} with ${binary:Version} and
${source:Version} to make the package binNMU safe.
- add build dependency on dpkg-dev (>= 1.13.19) which introduces
${binary:Version} and ${source:Version}.
- move groff and linuxdoc-tools to Build-Depends-Indep.
* debian/copyright: add copyright notice for the manual which is
licensed under the GNU Free Document License.
* debian/patches/*: remove old patches and change to dpatch.
* debian/rules: change from cdbs to debhelper.
* debian/watch: upgrade to format version 3.
signature.asc
Description: Dit berichtdeel is digitaal ondertekend
RFS: drift
Hi, I am searching a sponsor for DrIFT which I maintain. My regular sponsor, Isaac Jones, is quite busy right now and has not uploaded it yet. Below is the changelog, the packages fixes a bug and upgrades the package to the new upstream release. It is available from my webpage [1]. Just do dget http://moonshine.dnsalias.org/debian/unstable/drift_2.2.0-2_i386.changes When rebuilding the package don't forget the -v2.1.2-2 -sa flags for dpkg-buildpackage to include the complete changelog and source in the upload. Greetings Arjan [1] http://moonshine.dnsalias.org/debian/unstable drift (2.2.0-2) unstable; urgency=low . * debian/changelog: fix some spelling mistakes. * debian/drift.doc-base: add missing Index field for info format. (Closes: #366198) * debian/control.in: update to policy version 3.7.2. No changes needed. . drift (2.2.0-1) unstable; urgency=low . * New upstream release. * debian/control: update build dependencies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-haskell] RFS: haskell-http
Op ma, 01-05-2006 te 14:29 -0700, schreef Steve Langasek:
> > > I know, but the Depends are strict enough. And when a new version of ghc6
> > > hits unstable haske-http can be bin-NMU-ed. The package is setup that that
> > > should work. So no need for a new upload (and begging for sponsorship)
> > > then.
>
> > The problem is, with it as-is, you could get unpredictable results. One
> > platform might have a package that works only with GHC 6.4.1, while the
> > next has one that works only with 6.4.2, due to building it at different
> > times. I'm not really comfortable uploading it in this state.
>
> Are there auto-generated binary dependencies that reflect this, though? If
> so, I don't see any reason to worry about the prospect that a package *may*
> get built against the wrong ghc; if the package is binNMU-safe in the first
> place, then all it takes to fix this is a binNMU...
>
Yes. The ${haskell:Depends} in the source control file will be
substituted with ghc6 (>= "ghc6 version at build time"), ghc6 (<< "ghc6
version at build time"-999) in the binary control file.
So while I think my approach is save, I already have uploaded a new
revision to my webserver which Build-Depends on a specific ghc6
version.
John could you have another look and maybe upload it? When you rebuild
it don't forget the -v0.4.20050430-1 flag for dpkg-buildpackage to make
sure the changelog for -2 revision is also included and the bugs are
closed on upload. The package is available from my website [1], just do
dget
http://moonshine.dnsalias.org/debian/unstable/haskell-http_0.4.20050430-3_i386.changes
Greetings Arjan
[1] http://moonshine.dnsalias.org/debian/unstable
complete changelog of my changes:
haskell-http (0.4.20050430-3) unstable; urgency=low
.
* debian/rules:
- remove INSTALL_PROGRAM += -s cruft, we use dh_strip.
- remove configure and install targets, almost everything is done in
the binary-arch and binary-indep targets.
* debian/control.in:
- remove the versioned dependency on ghc6 version 6.4.2 as it is not
yet in the archive anyway.
- Build-Depend on a specific ghc6 version, to make sure the
libghc6-http-dev package Depends on the same ghc6 version on all
architectures.
- Upgrade to Standards-Version 3.7.0. No changes needed.
.
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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: HowTo upgrade to a newer Debian Policy version
> Hi all, > I've adopted an old package, and in its PTS page I can read "The > package should be updated to follow the last version of Debian Policy > (Standards-Version 3.6.2 instead of 3.5.10)." and so I'd like to > upgrade to the news Debian Polcy version. > > I've searched on google, and inside DD Ref and d-policy but I found > nothing about this task (but I could be blind...). > > Is this simple as just change "Standards-Version:" inside > debian/control and generate the package to get all the errors (but do > this generates errors/warnings? which script do they come from?) or > there is a precise process to follow to upgrade to new DP version? No it is not :-D Your package should adhere to the new policy as well. Just look at the upgrade-checklist. /usr/share/doc/debian-policy/upgrade-checklist.txt.gz Greetings Arjan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-haskell] RFS: haskell-http
> But when ghc6 6.4.2 hits unstable, all libghc6-* packages must be > rebuilt anyway. > > That's also why you need to tighten up the existing ghc6 deps. See > http://urchin.earth.li/%7Eian/haskell-policy/haskell-policy.html/ch-libraries.html#s-library_impl_deps > for details. I know, but the Depends are strict enough. And when a new version of ghc6 hits unstable haske-http can be bin-NMU-ed. The package is setup that that should work. So no need for a new upload (and begging for sponsorship) then. Greetings Arjan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-haskell] RFS: haskell-http
> Hi, > > I checked out the package and there are some problems with your > dependencies. You need to make sure to depend on a specific version of > GHC, in both the build-deps and the package deps. ghc 6.4.2 is not in > sid yet, so referencing it doesn't help right now. >From the changelog: >> - 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. The versioned depends for ghc6 is to make sure that it uses cabal version 1.1.1 or later. When ghc6 6.4.2 with cabal 1.1.4 hits unstable libghc6-cabal-dev is not longer neccesary. Thats why i have that build-dependency. Greetings Arjan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: haskell-http
Hi,
I already sent a message to this list about sponsoring haskell-http, but
I did not get a response.
Package name: haskell-http
Version : 0.4.20050430-3
URL : http://www.haskell.org/http
License : BSD
Description : Haskell HTTP client library
I have take over this package from Ganesh Sittampalam and I am searching
for a sponsor. Below is the changelog of this revision. The package
can be found at http://moonshine.dnsalias.org/debian/unstable and is
easily downloaded by doing:
dget
http://moonshine.dnsalias.org/debian/unstable/haskell-http_0.4.20050430-2_i386.changes
Could someone sponsor this upload? It fixes bugs!. :-)
Greetings Arjan
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.
-- Arjan Oosting <[EMAIL PROTECTED]> Thu, 20 Apr 2006 11:45:51 +0200
signature.asc
Description: Dit berichtdeel is digitaal ondertekend
Re: Keeping previous changelogs
> Dear Mentors, > > I'm thinking about having the new package's changelog been > started as a fresh new one, and keeping each sub-package's > previous changelog as "changelog-preX.Y.Z.Debian.gz". > > Is this OK according to Debian policy? Or is there other > recommended way? That seems ok, AFAIK there is nothing in then policy against this. There is not really another way of doing this anyway. Greetings Arjan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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: (slightly more complex) library upgrade
Op wo, 21-12-2005 te 13:31 +0100, schreef Michael Biebl: > > So, in order to achieve the removal of libpowersave7 and assure the > functioning of kpowersave during the upgrade, should I add a > Conflicts/Replaces: libpowersave7 to libpowersave10 (although this is > actually not the case) or should I use a versioned depends on powersaved > in kpowersave and move the libpowersave to oldlibs after the upgrade? > The Conflicts/Replaces solution would assure that the upgrade of > libpowersave is hold back until the new kpowersave is available. But it > seems to me that this is more of a hack and doesn't correctly reflect > the situation (libpowersave7+10 *can* be installed in parallel). > Moving libpowersave7 to oldlibs on the other hand wouldn't automatically > remove it. But at least it would make it easier for the user to spot, > that it could be safely removed. > What would you suggest, what is the cleanest solution? Do NOT do the conflicts/replaces routine. Aptitude will remove the library from the users system when no package needs it anymore. Deborphan also will tell that the library is not used anymore, so the user knows is ca n be removed from there system. Just don't force the removal! Greetings Arjan Oosting signature.asc Description: This is a digitally signed message part
Re: RFS: Conky - A lightweight, highly configurable system monitor based on Torsmo
Op do, 01-09-2005 te 13:12 -0700, schreef Steve Langasek: > > For future ref for anyone: > > > Yup, it's the BSD 3 clause licence, which is fine. > > The 4 clause isn't, as it has teh 'advertising' clause in it. > > Uh, no, 4 clause BSD *is* allowed in main. I also thought 4-clause BSD was non-free... I checked http://wiki.debian.net/?DFSGLicenses but the only time the 4-clause BSD licence is mentioned is in the comment on the 3-clause BSD Licence. No mention whether 4-clause is DSFG-free or not though. Maybe someone can make an update? (I don't think I know enough about licences and 4-clause BSD in particular to do an update myself) Greetings Arjan Oosting signature.asc Description: This is a digitally signed message part
Re: RFS: ITP: crystalcursors -- X11 mouse theme with the crystal
Op wo, 17-08-2005 te 17:20 -0400, schreef Justin Pryzby: > > > Ok, I've changed the target to /usr/lib/X11. But now instead of 1 warning > > > per cursor i get 2 errors per cursor: > > > > > > E: crystalcursors: package-installs-file-to-usr-something-x11 > > > usr/lib/X11/icons/crystalwhiteleft/cursors/plus > > > E: crystalcursors: use-of-compat-symlink > > > usr/lib/X11/icons/crystalwhiteleft/cursors/plus > > This is because /usr/lib/X11 is a symlink to /usr/X11R6/lib/X11, so you > > should not install in /usr/lib/X11, but just install > > in /usr/X11R6/lib/X11 as you did previously. > Really? Sorry, then. > > File a bug on lintian, too, if you can understand whats happening > (because for the moment I'm lost). Well, you are installing into a directory (/usr/lib/X11) which is actually a symlink to another directory (/usr/X11R6/lib/X11), and lintian complains (I guess because this can cause problems with dpkg or if the symlink was removed somehow). Effectively you are installing into the same directory as before, so you might as well install the cursors in usr/X11R6/lib/X11/. You will of course receive the lintian warning again - but that is better than an error ;) To get rid of this warning you should investigate if you can install the cursors in another directory which is NOT a subdirectory of usr/X11R6 or usr/lib/X11. You might want to look at gtk2-engines-industrial which install it cursors in a subdirectory of usr/share/icons. I hope this helps, Greetings Arjan signature.asc Description: This is a digitally signed message part
Re: RFS: ITP: crystalcursors -- X11 mouse theme with the crystal
Op wo, 17-08-2005 te 21:11 +0200, schreef Bastian Venthur: > Justin Pryzby wrote: > > > On Wed, Aug 17, 2005 at 07:41:13PM +0200, Bastian Venthur wrote: > >> Justin Pryzby wrote: > >> > On Wed, Aug 17, 2005 at 06:19:15PM +0200, Bastian Venthur wrote: > >> > >> >> W: crystalcursors: packages-installs-file-to-usr-x11r6 > >> >> usr/X11R6/lib/X11/icons/crystalwhiteleft_nonanim/ > >> >> > >> >> but I guess it's OK -- because these are cursors and they have to be > >> >> installed in this directory. > >> > My understanding is otherwise: > >> > > >> > http://lintian.debian.org/reports/Tpackages-installs-file-to-usr-x11r6.html > >> > | packages-installs-file-to-usr-x11r6 > >> > | Packages using the X Window System should not be configured to > >> > | install files under the /usr/X11R6/ directory unless they use > >> > | imake. The /usr/X11R6/ directory hierarchy should be regarded as > >> > | deprecated for all packages except the X Window System itself. > >> > > >> > | Programs that use GNU autoconf and automake are usually easily > >> > | configured at compile time to use /usr/ instead of /usr/X11R6/, and > >> > | this should be done whenever possible. > >> > > >> > | Refer to Policy Manual, section 11.8.7 for details. > >> > > >> > Could you test and see if it works if you use /usr/ instead? > >> > > >> > I'm no X11 expert, but I tend to believe that lintian/policy know what > >> > they're doing. > >> > >> I think in this special case this warning can be ignored, since all other > >> mousecursors on my system are installed in the very same dir. BTW I've > >> seen that other packages [1] which provide cursors have this warning too. > > $ ls -l /usr/lib/X11 > > lrwxrwxrwx 1 root root 16 Jun 8 22:26 /usr/lib/X11 -> ../X11R6/lib/X11 > > Ok, I've changed the target to /usr/lib/X11. But now instead of 1 warning > per cursor i get 2 errors per cursor: > > E: crystalcursors: package-installs-file-to-usr-something-x11 > usr/lib/X11/icons/crystalwhiteleft/cursors/plus > E: crystalcursors: use-of-compat-symlink > usr/lib/X11/icons/crystalwhiteleft/cursors/plus This is because /usr/lib/X11 is a symlink to /usr/X11R6/lib/X11, so you should not install in /usr/lib/X11, but just install in /usr/X11R6/lib/X11 as you did previously. Greetings, Arjan Oosting signature.asc Description: This is a digitally signed message part
Re: How to use svn(-buildpackage) with pbuilder?
Op di, 02-08-2005 te 17:50 +, schreef W. Borgert: > On Sun, Jul 31, 2005 at 07:03:14AM -0400, Yaroslav Halchenko wrote: > > borrowed from a nice minimalistic HOWTO > > http://workaround.org/moin/SvnBuildpackage > > That is indeed a very helpful HOWTO. Thanks! > > > 3 and 5 just add them to --svn-postbuild as IT IS SAID IN THE MAN PAGE: > > :-) OK, thanks. > > One more question, I could not answer myself from reading the > man page: > > If I have the complete upstream source in SVN, but not the > .tar.gz, how do I create the .orig.tar.gz, when I have a new > upstream version? svn-upgrade path/to/new-upstream.tar.gz Greetings Arjan Oosting -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to use svn(-buildpackage) with pbuilder?
Op ma, 01-08-2005 te 13:44 +0200, schreef Matthijs Mohlmann: > > I don't want to have all revisions of the package that ever existed on > > my filesystem. Is it possible to make svn-buildpackage create the > > tarballs on build-time? > > > AFAIK it isn't possible. It is, the orig.tar.gz is created if you do a FORCEEXPORT=yes svn-buildpackage It is not recommended to use this though because the resulting orig.tar.gz might be different (md5 checksum) from the upstream version which can complicate things substantially. Greetings Arjan Oosting signature.asc Description: This is a digitally signed message part
Re: Problem in building c2hs package
Op do, 07-07-2005 te 17:33 -0300, schreef Marco Tulio Gontijo e Silva: > Em Qui, 2005-07-07 às 22:23 +0200, Arjan Oosting escreveu: > > I don't know if you know the debian-haskell mailinglist > > [1] > (...) > > [1] [EMAIL PROTECTED] > > This links is broken... > > [EMAIL PROTECTED]:~$ ping lists.urchin.earth.li > ping: unknown host lists.urchin.earth.li > [EMAIL PROTECTED]:~$ That is alright. The webpage of the debian-haskell lists is: http://urchin.earth.li/mailman/listinfo/debian-haskell lists.urchin.earth.li is only an MX record: lists.urchin.earth.li. 604800 IN MX 10 mail-2.blackcatnetworks.co.uk. lists.urchin.earth.li. 604800 IN MX 5 urchin.earth.li. Greetings Arjan Oosting signature.asc Description: This is a digitally signed message part
Re: Problem in building c2hs package
Op do, 07-07-2005 te 16:24 -0300, schreef Marco Tulio Gontijo e Silva: > I've talked to him and he told me that was ok for me to package it. So I > have submitted a ITA ( > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=315674 ). That's nice. I don't know if you know the debian-haskell mailinglist [1], which topic is Debian packaging of Haskell packages and libraries. So if you have specific Haskell packaging questions, you can go there. Good luck, Arjan Oosting [1] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Problem in building c2hs package
Op wo, 06-07-2005 te 20:54 -0300, schreef Marco Tulio Gontijo e Silva: > Hello, > > I'm trying to build c2hs package, and I have made the debian/* files for > it, but when I try to build I get the following problem: Hi, c2hs is already packaged by Michael Weber, so why are you packaging it? Greetings Arjan Oosting. Package: c2hs Status: install ok installed Priority: optional Section: devel Installed-Size: 2088 Maintainer: Michael Weber <[EMAIL PROTECTED]> Architecture: i386 Version: 0.12.0-1 Depends: libc6 (>= 2.3.2-1), libgmp3, ghc5 (>= 5.04.3), ghc5 (<< 5.04.4) Suggests: haskell-doc Description: C->Haskell Interface Generator C->Haskell is an interface generator that simplifies the development of Haskell bindings to C libraries. The tool processes existing C header files that determine data layout and function signatures on the C side in conjunction with Haskell modules that specify Haskell-side type signatures and marshaling details. Hooks embedded in the Haskell code signal access to C structures and functions -- they are expanded by the interfacing tool in dependence on information from the corresponding C header file. . Haskell 98 is "the" standard lazy functional programming language. More info plus the language definition is at http://www.haskell.org/. signature.asc Description: This is a digitally signed message part
Re: GH packaging for Debian/frown availability
Op wo, 29-06-2005 te 13:38 +0200, schreef Andres Loeh: > Hi Arjan. > > Ralf showed me your mail requesting information of frown. > It's great that you want to package Generic Haskell for Debian. > I do, however, not understand why you would need UUAG and frown. > Both do clearly have free licenses, so the generated code is > clean. But why do they have to be available? It's the *recommended* > way to build the Generic Haskell binary not to rerun these tools. > The generated sources should be fine. > Is this some sort of strange Debian regulation? Do they really > require this somewhere? Do they also require you to regenerate > every autoconf file in a source distribution etc.? Hi Andres, [I am CC debian-mentors because there is much more knowledge then I have. I hope you don't mind] Generic Haskell is free (as in speech) and the generated source files are enough to build Generic Haskell, so maybe technically it is free enough to go in the main archive, I think. The problem is that there are no free compilers IN the Debian main archive to generate the sources from the sources which you use to develop Generic Haskell (the .ag files and the source file for frown). This means that if someone wants to modify/patch Generic Haskell he has to modify the generated sources which is a pain. (The output of uuagc is not really for human comsumption ;) ) So as long as uuagc (and frown) are not in main generic-haskell should be in contrib, IIRC Maybe someone from debian-mentors can tell me what the guidelines arefor packages which can build from generated sources with tools in Debian main, but not from the 'original' sources? I am planning to get uuagc in the main archive (and frown after it is available). When uuagc is in the archive I think Generic Haskell can be uploaded to main. (There is only one file processed frown which isn't modified that often) > Apart from that, I think that Ralf is still planning to release > frown to the public at a point, but I don't know when it will be > happening. That is nice. For now Debian packages of Generic-Haskell are available form http://moonshine.dnsalias.org/debian/unstable Greetings Arjan Oosting. signature.asc Description: This is a digitally signed message part
Re: RFS: Sponsor needed for em-panel-applet
Op vr, 10-06-2005 te 13:27 +0200, schreef Søren Hansen: > I'm not sure how it works, when you actually upload stuff to Debian. > Don't you just upload the source packages, and then the build servers > build it for the different archs? Well this depends :) If you are an Debian developer you upload an binary for one architecture and the source. If you're not an Debian developer your sponsor will rebuild you're package and then upload an binary for one architecture and the source. (This is different from Ubuntu where only source uploads are allowed.) > > I guess you build it on a Ubuntu system? Maybe next time you could built > > them in a Debian unstable chroot (with pbuilder). This way you also > > make sure it compiles and is installable on a Debian system. > > I suppose I could do that. Or maybe I should just not supply the > binaries.. :-) Well using pbuilder has a lot of advantages: - You're sure the package has the right build-dependencies (maybe to many but never to less) - You're always building against a clean environment. You don't have problems when you have packages from multiply sources/distributions installed. - You don't have problems when your package build-depends on packages which conflict with you're currently installed packages. A pbuilder environment is quite easy to setup and easy to use. Greetings Arjan Oosting signature.asc Description: This is a digitally signed message part
Re: RFS: Sponsor needed for em-panel-applet
Op vr, 10-06-2005 te 13:29 +0200, schreef Arjan Oosting: > Hi, > > One final thing i forgot in my previous message. Em-panel-applet depends > on DBUS notifications send by the new-mail-plugin from evolution. So you > should also mention that the new-mail-plugin should be enabled and maybe > also Recommend: evolution-plugins (which could replace the current > Recommend: evolution because evolution-plugins depends on evolution). > > And one final note... It doesn't work (for me?) I have enabled the > new-mail-plugin and started em-panel-applet but when I receive a new > mail nothing happens... I should have looked harder :) You first have to enable the plugin (which is in the extra menu) and then in preferences enable "Generate D-BUS event on arrival on new mail." Stupid me! Greetings Arjan signature.asc Description: This is a digitally signed message part
Re: RFS: Sponsor needed for em-panel-applet
Hi, One final thing i forgot in my previous message. Em-panel-applet depends on DBUS notifications send by the new-mail-plugin from evolution. So you should also mention that the new-mail-plugin should be enabled and maybe also Recommend: evolution-plugins (which could replace the current Recommend: evolution because evolution-plugins depends on evolution). And one final note... It doesn't work (for me?) I have enabled the new-mail-plugin and started em-panel-applet but when I receive a new mail nothing happens... signature.asc Description: This is a digitally signed message part
Re: RFS: Sponsor needed for em-panel-applet
Op do, 09-06-2005 te 23:10 +0200, schreef Søren Hansen: > Sponsor still needed, and all the issues mentioned by Sven should be > taken care of. New packages uploaded. Hi, I can't sponser you because I am not an DD (yet), but your package looked interesting so I tried to install. I had some problems though :) The package has a versioned depends on libxml2 (=> 2.6.17) but the latest version of libxml2 in unstable is 2.6.16-7, so your package can not be installed. I guess you build it on a Ubuntu system? Maybe next time you could built them in a Debian unstable chroot (with pbuilder). This way you also make sure it compiles and is installable on a Debian system. Your package also misses a build-dependency on libgnomeui-dev. Missing build-dependencies are also easily spotted when you build you're package with pbuilder. And maybe you could clarify the description a little bit? I expected an APPLET which a could a to one of the PANELs, but actually it is program which puts an icon into the NOTIFICATION area. And last but not least, maybe you could add an .desktop file so the program can be started from the gnome-menu instead of from some terminal. Greetings Arjan Oosting signature.asc Description: This is a digitally signed message part
reassigning bugs
Hi, I have packaged gaim-extendedprefs and yesterday I received a bugreport [1]. After looking at the code in the package, I believe the bug is not in gaim-extendedprefs but rather an interaction bug between gtk+2.0 and sawfish. I am not very familiar with sawfish and libgtk2.0 so I cannot really see where the problem is. I am thinking about reassigning the bug to libgtk2.0-0. Are there any guidelines about how to do this? Should I include more info by sending an email to [EMAIL PROTECTED] greetings Arjan Oosting [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301123 signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: CDBS and DESTDIR
Op di, 22-03-2005 te 12:04 -0300, schreef Nelson A. de Oliveira: > -BEGIN PGP SIGNED MESSAGE- > I have used that because I saw on a debian-mentors list archive. > (http://lists.debian.org/debian-mentors/2004/07/msg00392.html) > > Even when using > DEB_MAKE_INSTALL_TARGET := install DESTDIR=$(DEB_DESTDIR) > I had no sucess. This should work, but are you sure the upstream Makefile of your package understands DESTDIR? If not you should patch the upstream Makefile. Maybe you could send the upstream Makefile so we can have a look? Greetings Arjan Oosting signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: gaim-themes : Smiley themes collection for gaim
Op do, 03-03-2005 te 19:40 +0100, schreef Martin Braure de Calignon: > I am looking for a sponsor for this packages. > It exists in ITP list (#297961). > It can be downloaded at : > http://www.enseirb.fr/~braurede/deb_dev/gaim-themes/ Hi, I can't sponsor you because I am not a DD, but I do have a suggestion. The package doesn't contain any architecture specific files so you should change the Architecture to all in debian/control and move the installation commands from binary-arch to binary-indep in .debian/rules. Good luck with finding a sponsor! Greetings Arjan Oosting signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: Closing bugs
I'm sorry for flooding the list, my email client kept on complaining about errors in the TO header, so I rewrote and tried to send the message again and again. :-( Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Closing bugs
Hi, I have packages gaim-extendedprefs and close the ITP in the changelog of revision 3. My sponsors upload of revision 3 did not get accepted due to a missing .orig.gz, and since then I have made some changes to the package on request of my sponsor. Now I'm wondering if I should close the ITP in the changelog of revision 4 again? Are closing statements in revisions not accepted or uploaded considered by katie when accepting a new revisions, or do you have to affirm all previous fixed bugs in the changelog of the revision which is accepted by katie. Greetings Arjan Oosting signature.asc Description: Dit berichtdeel is digitaal ondertekend
Closing bugs
Hi, I've packaged gaim-extendedprefs and closed the ITP bug in revision 3 but my sponsors upload was not accepted by katie due to a missing .orig.tar.gz. On request of my sponsor I'm making some changes to the package, and I'm wondering if I have to close the ITP again in the changelog for revision 4? I'm not sure if the bugs closed in revisions not accepted, will be closed when closed when a new revision is accepted. Greetings Arjan Oosting signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: gaim-extendedprefs
Op wo, 23-02-2005 te 21:16 +, schreef Neil McGovern: > On Wed, Feb 23, 2005 at 09:02:11PM +0100, Arjan Oosting wrote: > > Hi, > > > > I haven't seen any response to my RFS for gaim-extendedprefs (Original > > message: http://lists.debian.org/debian-mentors/2005/02/msg00168.html ). > > Is there someone on this list interrested in sponsoring me, or does > > someone know an appropriate list where I can post a RFS for this > > package? > > > > Couple of problems with teh package: > > * You haven't closed the ITP in your changelog file I will upload a new version in a moment :) > * While trying to build: > "Trying patch debian/patches/00_destdir.patch at level 0...1...2...failure." I can't reproduce this error. I have checked out the source from my personal debian archive and have used pbuilder, debuild and fakeroot ./debian/rules binary, so maybe you could give me a more detailed error-log (maybe the output from debuild). Greetings Arjan Oosting signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: gaim-extendedprefs
Hi,
I haven't seen any response to my RFS for gaim-extendedprefs (Original
message: http://lists.debian.org/debian-mentors/2005/02/msg00168.html ).
Is there someone on this list interrested in sponsoring me, or does
someone know an appropriate list where I can post a RFS for this
package?
Thanks,
Arjan Oosting
> Short description: extended preferences plugin for the instant messenger
> gaim
> Long description: The Gaim Extended Preferences Plugin adds additional
> preferences that have been commonly called for in the past from Gaim
> that are either already implemented and hidden, or trivial to implement
> via a plugin.
> Upstream homepage: http://gaim-extprefs.sourceforge.net/
>
> I have already packaged it and it's available at
> http://moonshine.dnsalias.org/debian/unstable/ . There are more Debian
> packages there (I have been building packages for my private use for
> some time now), but this one is nice, small and useful and thus perfect
> for my first sponsored package.
signature.asc
Description: Dit berichtdeel is digitaal ondertekend
Re: RFS: drift
Op za, 19-02-2005 te 01:07 -0800, schreef Isaac Jones: > I'd be willing to sponsor you on this package. Are you eager to get > it into Sarge? I expect to be pretty busy with Cabal / GHC 6.4 until > the sarge release. No, I'm not that eager, I just thought it would be nice to have this package in Debian, and make Debian the best Haskell development environment there is! :) But for now the package will stay available at my home server, until you have time to upload it. > Thanks for packaging this. I was recently thinking of using it. You're welcome. I must admit I was surprised nobody else had packaged DrIFT already. Greetings Arjan Oosting signature.asc Description: Dit berichtdeel is digitaal ondertekend
RFS: drift
Hi, For some time now I have packaged drift for my own machines, and I was wondering if someone wants to sponsor me to get the drift in Debian or in Haskell-Experimental #1. Short Description: type sensitive preprocessor for Haskell Long Description: DrIFT automates instance derivation for classes that aren't supported by the standard compilers. In addition, instances can be produced in separate modules to that containing the type declaration. This allows instances to be derived for a type after the original module has been compiled. As a bonus, simple utility functions can also be produced from a type. Features: - DrIFT comes with a set of rules to produce instances for all derivable classes given in the Hasekell Prelude. There are also a number of extra useful rules to derive instances of a variety of useful classes. - DrIFT performs import chasing to find the definition of a type. - Code is generated using pretty-printing combinators. This means that the output is (fairly) well formatted, and easy on the eye. - Effort has been made to make the rule interface as easy to use as possible. This is to allow users to add rules to generate code specific to their own projects. As the rules are themselves written in Haskell, the user doesn't have to learn a new language to express rules. Upstream Homepage: http://repetae.net/john/computer/haskell/DrIFT/ I have already packaged it and it's available at http://moonshine.dnsalias.org/debian/unstable. Greetings Arjan Oosting 1) http://alioth.debian.org/projects/haskell-unsafe/ signature.asc Description: Dit berichtdeel is digitaal ondertekend
RFS: gaim-extendedprefs
Hi, I want to contribute to the Debian project, and I'm looking for a sponsor for gaim-extendedprefs. This is a plugin for Gaim which gives access to some additional preferences. (The "Hide buddy list at signon" is my favorite :)) Short description: extended preferences plugin for the instant messenger gaim Long description: The Gaim Extended Preferences Plugin adds additional preferences that have been commonly called for in the past from Gaim that are either already implemented and hidden, or trivial to implement via a plugin. Upstream homepage: http://gaim-extprefs.sourceforge.net/ I have already packaged it and it's available at http://moonshine.dnsalias.org/debian/unstable/ . There are more Debian packages there (I have been building packages for my private use for some time now), but this one is nice, small and useful and thus perfect for my first sponsored package. Greetings Arjan Oosting signature.asc Description: Dit berichtdeel is digitaal ondertekend
