Re: Sponsors and the Uploaders field (was: RFS: dict-freedict ...)

2005-10-04 Thread Matthew Palmer
On Wed, Oct 05, 2005 at 01:40:03AM +0200, Christoph Berg wrote:
> Re: Matthew Palmer in <[EMAIL PROTECTED]>
> > The primary reason I've seen expressed for desire to be added to the
> > Uploaders field is so that the sponsor can get a quick summary of a
> > sponsored package's state from the excellent developer.php script on
> > qa.debian.org.  I've noticed that being able to do a "subscription" in
> > developer.php is a requested feature, but I can't see a way to do that yet.
> 
> I'm working on it. Jeroen committed a first patch on Sunday, which
> makes the internal backend data more handy. There is no nice interface
> yet, but you can already put
> 
>   &packages=bla+foo+bar

Whoa... mondo cool.

I'd be inclined to perhaps have a separate page (or at least a well separate
mode) that allowed someone to add packages to their "list" (like a "add new
package:" box at the top) and then they can bookmark that particular page. 
Alternately, if there's persistent storage behind the page, a similar thing
but without the need to bookmark would be handy.

Very, very cool feature already though. I like having the collection of
packages in a separate table too... keeps things clean.

- Matt


signature.asc
Description: Digital signature


Re: RFS: fbgetty

2005-10-04 Thread Sylvain LE GALL
Hello,

On Tue, Oct 04, 2005 at 11:07:48PM +0200, Kurt Roeckx wrote:
> On Tue, Oct 04, 2005 at 10:24:27PM +0200, Sylvain LE GALL wrote:
> > > > The package seems almost lintian clean (2 warnings about outdated
> > > > config.sub/config.guess which are patched during the build, so it should
> > > > not generate any real errors).
> > > 
> > > Any reason not to put the correct version in the .diff.gz?
> > > 
> > 
> > I think it is best to keep the correct version in a dpatch file which i
> > can easily send to upstream. I like to have only debian/ in the diff.gz 
> > (but it is only a matter of taste). I try to always use pristine 
> > upstream source.
> 
> I recommend that you build depend on the autotools-dev package
> instead (which is already pulled in) and that you upgrade to that
> version at build time.
>

I don't see the problem with sending a patch to upstream... I don't like
to auto upgrade part of the source: it should break the build system of
the upstream author...

> You should probably take a look at the license of your
> documentation.  I have to wonder what "modified versions [...]
> under the conditions for verbatim copying" means.  That seem to
> conflict with itself.
> 

Yes, it seems to be auto conflicting.

> You also might want to look into the license of src/alloca.c.
> 

It seems to be public domain (fast reading). I don't see the problem ?

Regards
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Sponsors and the Uploaders field (was: RFS: dict-freedict ...)

2005-10-04 Thread Christoph Berg
Re: Matthew Palmer in <[EMAIL PROTECTED]>
> The primary reason I've seen expressed for desire to be added to the
> Uploaders field is so that the sponsor can get a quick summary of a
> sponsored package's state from the excellent developer.php script on
> qa.debian.org.  I've noticed that being able to do a "subscription" in
> developer.php is a requested feature, but I can't see a way to do that yet.

I'm working on it. Jeroen committed a first patch on Sunday, which
makes the internal backend data more handy. There is no nice interface
yet, but you can already put

&packages=bla+foo+bar

at the end of the URL and it will display additional packages.

Suggestions on how to make that persistent are welcome. We already set
a cookie, so we can extend that, but we probably don't want the
additional packages to show up on every page you view (e.g. when
clicking on the maintainer link on the PTS pages), so it has to be
associated with "your" page (whatever that means).

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature


Re: RFS: fbgetty

2005-10-04 Thread Kurt Roeckx
On Tue, Oct 04, 2005 at 10:24:27PM +0200, Sylvain LE GALL wrote:
> > > The package seems almost lintian clean (2 warnings about outdated
> > > config.sub/config.guess which are patched during the build, so it should
> > > not generate any real errors).
> > 
> > Any reason not to put the correct version in the .diff.gz?
> > 
> 
> I think it is best to keep the correct version in a dpatch file which i
> can easily send to upstream. I like to have only debian/ in the diff.gz 
> (but it is only a matter of taste). I try to always use pristine 
> upstream source.

I recommend that you build depend on the autotools-dev package
instead (which is already pulled in) and that you upgrade to that
version at build time.

You should probably take a look at the license of your
documentation.  I have to wonder what "modified versions [...]
under the conditions for verbatim copying" means.  That seem to
conflict with itself.

You also might want to look into the license of src/alloca.c.


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: RFS: fbgetty

2005-10-04 Thread Sylvain LE GALL
Hello,

On Tue, Oct 04, 2005 at 03:11:57PM +0200, Christoph Berg wrote:
> Re: Sylvain LE GALL in <[EMAIL PROTECTED]>
> > I am looking for a sponsor to fbgetty. This package has been orphaned
> > and i want to take his maintainance. 
> > 
> > I have prepared a package, that can be found here:
> > http://sylvain.le-gall.net/debian-public
> 
> Please fix your ServerName (or post URLs that do not require redirects
> because the trailing slash is missing).
> 

Sorry for the redirected url, here is the full one:
http://le-gall.net/sylvain/debian-public/

> > The package seems almost lintian clean (2 warnings about outdated
> > config.sub/config.guess which are patched during the build, so it should
> > not generate any real errors).
> 
> Any reason not to put the correct version in the .diff.gz?
> 

I think it is best to keep the correct version in a dpatch file which i
can easily send to upstream. I like to have only debian/ in the diff.gz 
(but it is only a matter of taste). I try to always use pristine 
upstream source.

Anyway the patch will be sent to upstream in order to have a release
with updated config.guess/config.sub. Since it is patched before
configure, there is really no difference.

Kind regard
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: RFS: fbgetty

2005-10-04 Thread Christoph Berg
Re: Sylvain LE GALL in <[EMAIL PROTECTED]>
> I am looking for a sponsor to fbgetty. This package has been orphaned
> and i want to take his maintainance. 
> 
> I have prepared a package, that can be found here:
> http://sylvain.le-gall.net/debian-public

Please fix your ServerName (or post URLs that do not require redirects
because the trailing slash is missing).

> The package seems almost lintian clean (2 warnings about outdated
> config.sub/config.guess which are patched during the build, so it should
> not generate any real errors).

Any reason not to put the correct version in the .diff.gz?

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature