RFS: xhangglider package uploaded to mentors

[Rudy Godoy]

Hi there, as i've said before [0] I'm willing to adpot xhangglider, I've
worked on the package and I've finally uploaded [1] to mentors.debian.net.
If there's anybody who wants to sponsor this package I'll appreciate to take
a look on it and let me know.

regards,
Rudy

0- 
http://lists.debian.org/debian-mentors/2004/debian-mentors-200402/msg1.html
1-
http://mentors.debian.net/debian/dists/unstable/main/binary-i386/xhangglider/

-- 

  ++
  | Somos libres, seamoslo con software libre  * http://debian.org |
  ++
  | http://www.apesol.org.pe -*- http://stone-head.org |
  | GPG FP: 0D12 8537 607E 2DF5 4EFB  35A7 550F 1A00 3433 BD21 |
  ++


signature.asc
Description: Digital signature

Re: RFS: xhangglider package uploaded to mentors

[Joshua Kwan]

On Tue, Feb 17, 2004 at 01:54:57AM -0500, Rudy Godoy wrote:
> Hi there, as i've said before [0] I'm willing to adpot xhangglider, I've
> worked on the package and I've finally uploaded [1] to mentors.debian.net.
> If there's anybody who wants to sponsor this package I'll appreciate to take
> a look on it and let me know.

This doesn't look too much different from the old package...

1) You should work the build system so that the binary and manpage are
built in the build-stamp target.

2) You should remove Makefile from the orig.tar.gz in the clean target at
some point and upload a new one. Currently, refreshing the Makefile that
came in the orig.tar.gz causes major diff.gz bloat:

$ zcat ../*.diff.gz | diffstat
 Imakefile   |6 
 Makefile|  552 
 debian/README.Debian|5 
 debian/changelog|   57 
 debian/compat   |1 
 debian/control  |   14 +
 debian/copyright|   19 +
 debian/dirs |3 
 debian/docs |4 
 debian/menu |4 
 debian/rules|   65 +
 debian/xhangglider.1|   36 ++
 debian/xhangglider.1x   |   36 ++
 debian/xhangglider.es.1 |   39 +++
 debian/xhangglider.manpages |1 
 glider.def  |4 
 16 files changed, 694 insertions(+), 152 deletions(-)

Or you could move it away at build time and move it back later.

3) It is probably desirable to support DEB_BUILD_OPTIONS=noopt in your
debian/rules, so that the binary is built at -O0 instead of -O2 (i.e.
for debugging purposes.)

Otherwise this looks pretty nice. I took a look at the bugs page for
xhangglider and posted a patch to #192923 - seems to work and you should
apply it I think.

-- 
Joshua Kwan


signature.asc
Description: Digital signature

Re: RFS: xhangglider package uploaded to mentors

[Colin Watson]

On Tue, Feb 17, 2004 at 12:07:28AM -0800, Joshua Kwan wrote:
> 2) You should remove Makefile from the orig.tar.gz in the clean target at
> some point and upload a new one. Currently, refreshing the Makefile that
> came in the orig.tar.gz causes major diff.gz bloat:

Huh? I haven't looked at this, but why would one generate a new
.orig.tar.gz that isn't original? .diff.gz bloat is to be lived with.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: RFS: xhangglider package uploaded to mentors

[Joshua Kwan]

On Tue, Feb 17, 2004 at 10:16:17AM +, Colin Watson wrote:
> Huh? I haven't looked at this, but why would one generate a new
> .orig.tar.gz that isn't original? .diff.gz bloat is to be lived with.

I guess the line between keeping the diff.gz bloat and orig.tar.gz
constant with upstream is a gray area.

For example, I've had to re-tar the Visual Boy Advance sources just now
because it extracted as VisualBoyAdvance-1.7.1 and not
visualboyadvance-1.7.1, as dpkg-source expects (or at least prefers.) Is
that not justified?

I agree, though, in general one Makefile probably wouldn't justify
repacking.

-- 
Joshua Kwan


signature.asc
Description: Digital signature

Re: RFS: xhangglider package uploaded to mentors

[Colin Watson]

On Tue, Feb 17, 2004 at 02:42:20AM -0800, Joshua Kwan wrote:
> On Tue, Feb 17, 2004 at 10:16:17AM +, Colin Watson wrote:
> > Huh? I haven't looked at this, but why would one generate a new
> > .orig.tar.gz that isn't original? .diff.gz bloat is to be lived with.
> 
> I guess the line between keeping the diff.gz bloat and orig.tar.gz
> constant with upstream is a gray area.
> 
> For example, I've had to re-tar the Visual Boy Advance sources just now
> because it extracted as VisualBoyAdvance-1.7.1 and not
> visualboyadvance-1.7.1, as dpkg-source expects (or at least prefers.) Is
> that not justified?

Not in my book, no. dpkg-source has been happy with .orig.tar.gz
extracting to a different name for a long time now. To suppress
warnings, you should just need to build from a directory called
visualboyadvance-1.7.1.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

applying patches

[Radu Spineanu]

hello 
 
I have to apply a small patch to my xmail package,
however  
i ran into different opinions while looking on how
to do this. 
Some suggested dbs, others dpatch, others just
applying the 
patch dirrectly to the source. 
 
I would like xmail to be part of debian ( in case
someone 
decides to sponsor it ) so which option is the
correct way for 
patching ? 
 
Radu Spineanu 

Multi-person sponsorship

[Matthew Palmer]

Prompted by a comment made by one of my potential sponsees, I've been
reworking my semi-automated sponsorship queue from a "helps me" thing to a
"could help lots of people" thing.  The comment was along the lines of
"wouldn't it be cool if we could remove the SPOF of sponsors, and have a
group of people sponsoring packages".

Well, I'm to the point now where I think that I can make that happen.  What
I've got so far is an upload queue, a test autobuilder (to make sure that
the package at least builds cleanly before wasting a sponsor's time with
it), and the generation of a tarball containing the .dsc, everything that
the .dsc references, and the build log from the test build.  All of that is
ticking along nicely, and I'd like to thank Lucas Wall and Juergen Strobel
for throwing their packages at the queue for the last few days while I
tweaked the bugs out of it.

The final question I'd like feedback on is this: how many sponsors would
consider pointing their sponsees to this service, rather than whatever
methods you're using now?  The benefits are that other sponsors might
occasionally take a bit of your workload, and if you go on holidays / get
sick / whatever, your sponsees aren't left to start from scratch.  Another
benefit could be that "occasional" uploads (such as NMUs and whatnot) could
be handled by a team, rather than by lots of indiscriminate begging on
d-mentors and elsewhere.

BTW, if a large part of what I'm describing below sounds like
mentors.debian.net, you're not alone.  Looking back, it might have been
easier to try and hack this into the m.d.n system.  That might be where this
all ends up.  I don't know.  One thing I'm not keen on is providing an
apt-getable archive, and I also want to keep track of what's been sponsored
and what's still waiting around - things that, AFAICT, m.d.n doesn't
provide.

The final step I'm planning on building into the system is a way for
sponsors to get packages out of this queue system I've built so they can
check them over and upload.  The problem is, I'm not sure how to do this
optimally.  My constraints are:

* Must be quick and simple to use.  Too much hassle will cause sponsors not to
use the system due to excessive pain.

* I'd like (but it's not an absolute requirement) to be able to track who
"claimed" each package for sponsorship, so sponsees can harass a particular
someone if the upload never gets done.

* Minimal manual intervention required on the administration side of things. 
Preferably no need for setup of accounts beyond that provided by a GPG
public key.

* Once selected by a sponsor, a package for sponsorship is taken "off the
market" for others, but can be reinstated later if the original downloader
can't upload, but the package shouldn't be rejected.

* If possible, sponsors should be able to select a package they want to
check and upload, rather than being given the "next in the queue".  For
instance, I'm not qualified to sponsor java packages, and I'm sure others
are in the same boat.

* As simple to implement as possible.  Duh.

So, given all of that, I've got two different ways thought up.  Both suck,
but in different ways.

1) E-mail.  Sponsors send a GPG signed e-mail to a request address, get the
next package on the list e-mailed back to them.  They could also request a
particular package, and if it's available, they'll get that.  Fails the
"select" part badly, but can be hacked to do most everything else.  But who
wants multi-megabyte files in their inbox, hmm?

2) Web.  Surprise!  Makes the tracking stuff harder (probably need to go to
a login-based approach - yay, another password to remember/manage) but
simplifies the package selection and downloads won't be quite so horrendous. 
Easier for me to implement because it's what I get paid to write (webapps).

There have also been thoughts of mutant hybrids flying through my brain,
where you list on the web and send e-mail to retrieve, then get a URL to
download, but these have, well, severely limited attractiveness for me.  But
it's another possibility.  How about an e-mail to get the list of packages,
then reply with the one you want, and you get back a URL to download the one
you want.  Ugly, though, and I'd need to write code to parse MIME for the
GPG signatures (more Python learning, I guess).

So, comments, brickbats, acclaim, whatever.  Throw it at me.

- Matt

Re: applying patches

[Matthew Palmer]

On Tue, Feb 17, 2004 at 03:04:39PM +0200, Radu Spineanu wrote:
> I have to apply a small patch to my xmail package,
> however  
> i ran into different opinions while looking on how
> to do this. 
> Some suggested dbs, others dpatch, others just
> applying the 
> patch dirrectly to the source. 
>  
> I would like xmail to be part of debian ( in case
> someone 
> decides to sponsor it ) so which option is the
> correct way for 
> patching ? 

Whatever works.  

If you're not expecting many patches, you could go the "direct to source"
route.  It's simple, easy to comprehend, and doesn't require any extra
packaging overhead.

However, at some point you'll probably end up with a bunch of separate
patches which are backports from upstream CVS fixing urgent bugs, unofficial
patches which you thought were a good idea but upstream hates, patches
Debian users have created which haven't made it into an upstream release,
and so on.  Managing these, particularly the ones that are likely to be in
upstream at a later point, becomes a problem.  For that, one of the patch
management systems above, or one of a couple of others I've heard mentioned,
are better ways to go.

As to which one is best, I really can't tell you.  I've never gotten quite
to patch hell (although both PHPWiki and IRM are starting to get there). 
All of the systems available have their advocates and their detractors. 
Perhaps try a couple of them out and see which one makes the most sense to
you?  I assume that they're all half-decent, or nobody would be using them
and they'd have died by now.  From memory, dbs is a fairly different build
system, cdbs even more so, while dpatch has the Unix nature - it does one
thing (patch management in Debian packages) and does it (hopefully) well.

Hmm, now you've got me wondering if I should dig out dpatch and try it out
on PHPWiki.  Onto the TODO list it goes.

- Matt

Re: applying patches

[Geert Stappers]

On Tue, Feb 17, 2004 at 03:04:39PM +0200, Radu Spineanu wrote:
> hello 
>  
> I have to apply a small patch to my xmail package,
> however  
> i ran into different opinions while looking on how
> to do this. 
> Some suggested dbs, others dpatch, others just
> applying the 
> patch dirrectly to the source. 
>  
> I would like xmail to be part of debian ( in case
> someone 
> decides to sponsor it ) so which option is the
> correct way for 
> patching ? 

Welcome to Free Software, where you can choose.

>  
> Radu Spineanu 
> 

Geert Stappers, happy dpatch user

Re: Multi-person sponsorship

[Jamin W. Collins]

On Tue, Feb 17, 2004 at 11:57:55PM +1100, Matthew Palmer wrote:
> 
> The final question I'd like feedback on is this: how many sponsors
> would consider pointing their sponsees to this service, rather than
> whatever methods you're using now?  The benefits are that other
> sponsors might occasionally take a bit of your workload, and if you go
> on holidays / get sick / whatever, your sponsees aren't left to start
> from scratch.  Another benefit could be that "occasional" uploads
> (such as NMUs and whatnot) could be handled by a team, rather than by
> lots of indiscriminate begging on d-mentors and elsewhere.

I like the automatic build testing, but would like to stress that these
packages would still need installation and usage testing.

> The final step I'm planning on building into the system is a way for
> sponsors to get packages out of this queue system I've built so they
> can check them over and upload.  The problem is, I'm not sure how to
> do this optimally.  My constraints are:
> 
> * Must be quick and simple to use.  Too much hassle will cause
> sponsors not to use the system due to excessive pain.

Could create an upload queue similar to Debian's current ftp uploads.  I
would check the upload to see if it's signed by a developer's key.  If
so, it could remove the package from your queue and forward the signed
upload on to Debian's upload queue.

> 2) Web.  Surprise!  Makes the tracking stuff harder (probably need to
> go to a login-based approach - yay, another password to
> remember/manage) but simplifies the package selection and downloads
> won't be quite so horrendous.  Easier for me to implement because it's
> what I get paid to write (webapps).

I would prefer this approach.

-- 
Jamin W. Collins

To be nobody but yourself when the whole world is trying it's best night
and day to make you everybody else is to fight the hardest battle any
human being will fight. -- E.E. Cummings

Re: data files in /etc?

[Goswin von Brederlow]

Magosányi Árpád <[EMAIL PROTECTED]> writes:

> Hi!
> 
> There are some files in /etc which are actually data files representing
> the state of the system. Like /etc/mtab, /etc/network/ifstate, or

The BTS has several patches for mount that allow /etc/mtab to be a
link to another file. Thats an extension to being a link to
/proc/mounts, which has some drawbacks like breaking loopback mounts.

For the /etc/network/ifstate afaik someone did a rewrite working
differently at some stage and the package was fixed to deal with it
being linked a long time ago.

> /etc/lvmconf/* (it is not even a text file).

That can also be linked to another location.

> These files are written by programs in occasions one cannot with good
> heart call configuration. Isn't it against the policy?

The problem is that those files have always been there (historic
reason) and that they may be needed during boot before any alternative
place is available (practical reason). They can't be in /var/state if
that is not yet mounted, on a network filesystem/device or lvm, and so
on. Check for the discussions about adding /run or /state.

If they bother you and you know certain conditions don't apply to you
(like var being on a network device) they can be linked. Arguments
about the files has repeadatly ended with the compromise to allow them
to be linked somewhere more fitting for the individual system.

> There are practical reasons behind my question:
> -if one uses a configuration management tool (like tla) to track changes
>  in the configuration, one will stumble upon them sooner or later.
> -if one wants to make the boot process unable to modify configuration,
>  they will also be stumbled upon. (And given the fact that mount
>  actually deletes and recreates /etc/mtab, the challenge is...
>  challenging.)

Or when you want a read-only / and /usr filesystem.

Mounting a ramdisk or tmpfs early during boot and linking the files to
there solves that problem. Note that you need the patch for mount
otherwise it will try to create /etc/mtab~ and iirc /etc/mtab.tmp or
something.

MfG
Goswin

Re: buildd problem

[Goswin von Brederlow]

John Belmonte <[EMAIL PROTECTED]> writes:

> Hello,
> 
> Not being much of a buildd expert, I'm wondering what is keeping my
> xmlsec1 package from entering testing.  There was a problem with the
> s390 build attempted Feb 05: "libgnutls10-dev missing".  However, I
> see that the s390 binary of libgnutls10-dev has been available since
> Feb 10. Will this take care of itself or must I do something to
> trigger a new build attempt?
> 
> 
> -John

You can check out details of the state of your package on

http://www.buildd.net/

Depending on the state of your package in wanna-build its
automatic.  Correct state for "libgnutls10-dev missing" would be
Dep-Wait, which requeues the source once the dependency becomes
available (looks like that happened from what Colin Watson mailed).

More information about the different states and how it works is also
available if you follow links on the same page from above.

MfG
Goswin

Re: Multi-person sponsorship

[Goswin von Brederlow]

Matthew Palmer <[EMAIL PROTECTED]> writes:

> Prompted by a comment made by one of my potential sponsees, I've been
> reworking my semi-automated sponsorship queue from a "helps me" thing to a
> "could help lots of people" thing.  The comment was along the lines of
> "wouldn't it be cool if we could remove the SPOF of sponsors, and have a
> group of people sponsoring packages".
> 
> Well, I'm to the point now where I think that I can make that happen.  What
> I've got so far is an upload queue, a test autobuilder (to make sure that
> the package at least builds cleanly before wasting a sponsor's time with
> it), and the generation of a tarball containing the .dsc, everything that
> the .dsc references, and the build log from the test build.  All of that is
> ticking along nicely, and I'd like to thank Lucas Wall and Juergen Strobel
> for throwing their packages at the queue for the last few days while I
> tweaked the bugs out of it.

What kind of security do you have to prevent uploads of malicious
sources?

I hope you destroy the chroot after each build and unpack it anew.

Having a new-maintainer keyring, to which keys could get added by any
AM after it has been verified, and checking the signature on the dsc
files against it sounds good to. And the keyring would be usefull for
other purposes too.

> The final question I'd like feedback on is this: how many sponsors would
> consider pointing their sponsees to this service, rather than whatever
> methods you're using now?  The benefits are that other sponsors might
> occasionally take a bit of your workload, and if you go on holidays / get
> sick / whatever, your sponsees aren't left to start from scratch.  Another
> benefit could be that "occasional" uploads (such as NMUs and whatnot) could
> be handled by a team, rather than by lots of indiscriminate begging on
> d-mentors and elsewhere.

I like it.

> BTW, if a large part of what I'm describing below sounds like
> mentors.debian.net, you're not alone.  Looking back, it might have been
> easier to try and hack this into the m.d.n system.  That might be where this
> all ends up.  I don't know.  One thing I'm not keen on is providing an
> apt-getable archive, and I also want to keep track of what's been sponsored
> and what's still waiting around - things that, AFAICT, m.d.n doesn't
> provide.

It would be nice if some uncommon archs could have a buildd for this
so new maintainers are faced with protability right from the start.

> The final step I'm planning on building into the system is a way for
> sponsors to get packages out of this queue system I've built so they can
> check them over and upload.  The problem is, I'm not sure how to do this
> optimally.  My constraints are:
> 
> * Must be quick and simple to use.  Too much hassle will cause sponsors not to
> use the system due to excessive pain.

A mini-dinstall apt repository with limitd access. Accounts could be
activated once by signed mail stating a user/pass pair.

> * I'd like (but it's not an absolute requirement) to be able to track who
> "claimed" each package for sponsorship, so sponsees can harass a particular
> someone if the upload never gets done.

Sponsoring could work just like the normal buildds. The sponsor sends
a mail back to the buildd with the signature and the buildd does the
uploading. There could be a simple webpage where DDs can claim
packages for a limited time (say 24h default with a 1 week option)
with a simple click. The webpage could double at showing whats
available for sponsoring too.

> * Minimal manual intervention required on the administration side of things. 
> Preferably no need for setup of accounts beyond that provided by a GPG
> public key.

A mail wrapper could check against the debian keyring and activate
accounts fully automatic then.

> * Once selected by a sponsor, a package for sponsorship is taken "off the
> market" for others, but can be reinstated later if the original downloader
> can't upload, but the package shouldn't be rejected.

Unless its rejected by the sponsor (with an explaination) or a newer
version is uploaded. I think if the sponsor finds problems with a
package it shouldn't go back just because some time passed. Packages
should automatically come pack when no action is taken by the sponsor
though.

> * If possible, sponsors should be able to select a package they want to
> check and upload, rather than being given the "next in the queue".  For
> instance, I'm not qualified to sponsor java packages, and I'm sure others
> are in the same boat.
> 
> * As simple to implement as possible.  Duh.
> 
> So, given all of that, I've got two different ways thought up.  Both suck,
> but in different ways.
> 
> 1) E-mail.  Sponsors send a GPG signed e-mail to a request address, get the
> next package on the list e-mailed back to them.  They could also request a
> particular package, and if it's available, they'll get that.  Fails the
> "select" part badly, but can be hacked to do most everything els

Re: Multi-person sponsorship

[Thomas Viehmann]

Goswin von Brederlow wrote:
> Having a new-maintainer keyring, to which keys could get added by any
> AM after it has been verified, and checking the signature on the dsc
> files against it sounds good to. And the keyring would be usefull for
> other purposes too.

Why not just check if the key is signed by a key in the debian keyring?
This could be done completely automatically.

Cheers

T.

-- 
Thomas Viehmann, 


pgpLvo74gKGua.pgp
Description: PGP signature

Re: data files in /etc?

[Goswin von Brederlow]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Magosányi Árpád <[EMAIL PROTECTED]> writes:
> 
> > Hi!
> > 
> > There are some files in /etc which are actually data files representing
> > the state of the system. Like /etc/mtab, /etc/network/ifstate, or
> 
> The BTS has several patches for mount that allow /etc/mtab to be a
> link to another file. Thats an extension to being a link to
> /proc/mounts, which has some drawbacks like breaking loopback mounts.

The /proc/mounts has the drawbacks, the extra paches not.

> For the /etc/network/ifstate afaik someone did a rewrite working
> differently at some stage and the package was fixed to deal with it
> being linked a long time ago.
> 
> > /etc/lvmconf/* (it is not even a text file).
> 
> That can also be linked to another location.
> 
> > These files are written by programs in occasions one cannot with good
> > heart call configuration. Isn't it against the policy?
> 
> The problem is that those files have always been there (historic
> reason) and that they may be needed during boot before any alternative
> place is available (practical reason). They can't be in /var/state if
> that is not yet mounted, on a network filesystem/device or lvm, and so
> on. Check for the discussions about adding /run or /state.
> 
> If they bother you and you know certain conditions don't apply to you
> (like var being on a network device) they can be linked. Arguments
> about the files has repeadatly ended with the compromise to allow them
> to be linked somewhere more fitting for the individual system.
> 
> > There are practical reasons behind my question:
> > -if one uses a configuration management tool (like tla) to track changes
> >  in the configuration, one will stumble upon them sooner or later.
> > -if one wants to make the boot process unable to modify configuration,
> >  they will also be stumbled upon. (And given the fact that mount
> >  actually deletes and recreates /etc/mtab, the challenge is...
> >  challenging.)
> 
> Or when you want a read-only / and /usr filesystem.
> 
> Mounting a ramdisk or tmpfs early during boot and linking the files to
> there solves that problem. Note that you need the patch for mount
> otherwise it will try to create /etc/mtab~ and iirc /etc/mtab.tmp or
> something.
> 
> MfG
> Goswin
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Multi-person sponsorship

[Goswin von Brederlow]

Thomas Viehmann <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow wrote:
> > Having a new-maintainer keyring, to which keys could get added by any
> > AM after it has been verified, and checking the signature on the dsc
> > files against it sounds good to. And the keyring would be usefull for
> > other purposes too.
> 
> Why not just check if the key is signed by a key in the debian keyring?
> This could be done completely automatically.
> 
> Cheers
> 
> T.

Because then you would need a DD sponsoring your uploading sources to
the sponsoring pool be sponsored by a DD after build.

The check is ment for the source so as not to build just anything.

MfG
Goswin

Re: Multi-person sponsorship

[Thomas Viehmann]

Goswin von Brederlow wrote:
> Thomas Viehmann <[EMAIL PROTECTED]> writes:
> 
> 
>>Goswin von Brederlow wrote:
>>
>>>Having a new-maintainer keyring, to which keys could get added by any
>>>AM after it has been verified, and checking the signature on the dsc
>>>files against it sounds good to. And the keyring would be usefull for
>>>other purposes too.
>>
>>Why not just check if the key is signed by a key in the debian keyring?
^^^ the key, not the package
>>This could be done completely automatically.
> Because then you would need a DD sponsoring your uploading sources to
> the sponsoring pool be sponsored by a DD after build.
> The check is ment for the source so as not to build just anything.

I'd think you misunderstood me, but it might be vice versa...

Cheers

T.

-- 
Thomas Viehmann, 


pgp9Si3Ag3kIn.pgp
Description: PGP signature

xmail package updated

[Radu Spineanu]

Hello to all 
 
Since it was a very small patch (it added 2 lines)
i decided to 
apply it just like that. 
 
deb http://k9.bizland.ro/xmail ./ 
deb-src http://k9.bizland.ro/xmail ./ 
 
Linda returns an error that is misses a man page
for a binary 
but that is a script that makes sendmail.xmail
work with 
debian. 
 
Also i didn't get any responses from any D-D. I
must understand 
that nobody is interested :) ? 
 
Radu Spineanu 

Re: Multi-person sponsorship

[Matthew Palmer]

On Tue, Feb 17, 2004 at 07:11:08PM +0100, Goswin von Brederlow wrote:
> > Prompted by a comment made by one of my potential sponsees, I've been
> > reworking my semi-automated sponsorship queue from a "helps me" thing to a
> > "could help lots of people" thing.  The comment was along the lines of
> > "wouldn't it be cool if we could remove the SPOF of sponsors, and have a
> > group of people sponsoring packages".
> > 
> > Well, I'm to the point now where I think that I can make that happen.  What
> > I've got so far is an upload queue, a test autobuilder (to make sure that
> > the package at least builds cleanly before wasting a sponsor's time with
> > it), and the generation of a tarball containing the .dsc, everything that
> > the .dsc references, and the build log from the test build.  All of that is
> > ticking along nicely, and I'd like to thank Lucas Wall and Juergen Strobel
> > for throwing their packages at the queue for the last few days while I
> > tweaked the bugs out of it.
> 
> What kind of security do you have to prevent uploads of malicious
> sources?

If the .changes isn't signed by a key in the "uploaders" keyring, it gets
rejected.  The exact criteria for who gets their key in hasn't been thought
about yet - so far, it's been people I intend to sponsor.  I presume it'll
be something like that in the future, too.

> I hope you destroy the chroot after each build and unpack it anew.

Sing it loud, and sing it clear - "We love pbuilder!  We love pbuilder!"

> Having a new-maintainer keyring, to which keys could get added by any
> AM after it has been verified, and checking the signature on the dsc
> files against it sounds good to. And the keyring would be usefull for
> other purposes too.

I hadn't thought about an NM keyring, but that has a certain amount of sense
to it.  I'd like to not limit the sponsorship service to just people who are
in the NM queue, but even a "sponsee keyring" - perhaps separated by
NM/non-NM - would be of definite benefit.  Knowing the trust path of the
maintainer of your software would be useful, even when they're not a DD.

> It would be nice if some uncommon archs could have a buildd for this
> so new maintainers are faced with protability right from the start.

I'm not likely to get an S/390 anytime soon (although donations are, of
course, more than welcome).But I'm happy to put multiarch building
into the system if you'd be willing to run a buildd for it (I'm depressingly
single-arch these days).

> > The final step I'm planning on building into the system is a way for
> > sponsors to get packages out of this queue system I've built so they can
> > check them over and upload.  The problem is, I'm not sure how to do this
> > optimally.  My constraints are:
> > 
> > * Must be quick and simple to use.  Too much hassle will cause sponsors not 
> > to
> > use the system due to excessive pain.
> 
> A mini-dinstall apt repository with limitd access. Accounts could be
> activated once by signed mail stating a user/pass pair.

Hmm, yes.  What I've got at the moment is tarballs built from the
autobuilder output, with the .dsc, everything mentioned in there, and the
build log.  My thought was that sponsors, when they wanted to get something
to sponsor, would download that tarball (everything you need in one easy
package).  If you think it would be more helpful, I've already got a package
pool set up internally that I can easily convert for the purpose if needed.

> > * I'd like (but it's not an absolute requirement) to be able to track who
> > "claimed" each package for sponsorship, so sponsees can harass a particular
> > someone if the upload never gets done.
> 
> Sponsoring could work just like the normal buildds. The sponsor sends
> a mail back to the buildd with the signature and the buildd does the
> uploading. There could be a simple webpage where DDs can claim

I'm wondering if that might be sailing a little close to the wind, though. 
I'd prefer not to fiddle with the way things are done too much this early,
and "automating" uploads feels a little too much like it's ripe for abuse. 
At least this way, since it's going to take the sponsor some time just to
build the package ready for sign+upload, hopefully they'll spend the extra
time looking for problems and maybe trying the package.

> packages for a limited time (say 24h default with a 1 week option)
> with a simple click. The webpage could double at showing whats
> available for sponsoring too.

This isn't a bad idea.  I might have to get a little funky with my
mod_rewrite skills (pitiful as they are) and get something going so I can do
some reference-counting (and general funky stuff).

> > * Minimal manual intervention required on the administration side of 
> > things. 
> > Preferably no need for setup of accounts beyond that provided by a GPG
> > public key.
> 
> A mail wrapper could check against the debian keyring and activate
> accounts fully automatic then.

So I still have to write my MIME-aware 

Re: Multi-person sponsorship

[Goswin von Brederlow]

Thomas Viehmann <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow wrote:
> > Thomas Viehmann <[EMAIL PROTECTED]> writes:
> > 
> > 
> >>Goswin von Brederlow wrote:
> >>
> >>>Having a new-maintainer keyring, to which keys could get added by any
> >>>AM after it has been verified, and checking the signature on the dsc
> >>>files against it sounds good to. And the keyring would be usefull for
> >>>other purposes too.
> >>
> >>Why not just check if the key is signed by a key in the debian keyring?
> ^^^ the key, not the package
> >>This could be done completely automatically.
> > Because then you would need a DD sponsoring your uploading sources to
> > the sponsoring pool be sponsored by a DD after build.
> > The check is ment for the source so as not to build just anything.
> 
> I'd think you misunderstood me, but it might be vice versa...

Yes, I did.

MfG
Goswin

Re: Multi-person sponsorship

[Goswin von Brederlow]

Matthew Palmer <[EMAIL PROTECTED]> writes:

> On Tue, Feb 17, 2004 at 07:11:08PM +0100, Goswin von Brederlow wrote:
> > > Prompted by a comment made by one of my potential sponsees, I've been
> > > reworking my semi-automated sponsorship queue from a "helps me" thing to a
> > > "could help lots of people" thing.  The comment was along the lines of
> > > "wouldn't it be cool if we could remove the SPOF of sponsors, and have a
> > > group of people sponsoring packages".
> > > 
> > > Well, I'm to the point now where I think that I can make that happen.  
> > > What
> > > I've got so far is an upload queue, a test autobuilder (to make sure that
> > > the package at least builds cleanly before wasting a sponsor's time with
> > > it), and the generation of a tarball containing the .dsc, everything that
> > > the .dsc references, and the build log from the test build.  All of that 
> > > is
> > > ticking along nicely, and I'd like to thank Lucas Wall and Juergen Strobel
> > > for throwing their packages at the queue for the last few days while I
> > > tweaked the bugs out of it.
> > 
> > What kind of security do you have to prevent uploads of malicious
> > sources?
> 
> If the .changes isn't signed by a key in the "uploaders" keyring, it gets
> rejected.  The exact criteria for who gets their key in hasn't been thought
> about yet - so far, it's been people I intend to sponsor.  I presume it'll
> be something like that in the future, too.

That was what I had in mind, just everyone in the sponsoring group, or
any DD, should be able to add or remove keys.

Or accept any key signed by a DD or something that won#t be as hard as
becoming a DD itself.

> > I hope you destroy the chroot after each build and unpack it anew.
> 
> Sing it loud, and sing it clear - "We love pbuilder!  We love pbuilder!"
> 
> > Having a new-maintainer keyring, to which keys could get added by any
> > AM after it has been verified, and checking the signature on the dsc
> > files against it sounds good to. And the keyring would be usefull for
> > other purposes too.
> 
> I hadn't thought about an NM keyring, but that has a certain amount of sense
> to it.  I'd like to not limit the sponsorship service to just people who are
> in the NM queue, but even a "sponsee keyring" - perhaps separated by
> NM/non-NM - would be of definite benefit.  Knowing the trust path of the
> maintainer of your software would be useful, even when they're not a DD.

Whatever the name. I was just reminded that a NM keyring would be
usefull for tracking the NMs packages and similar jobs. The AM checks
the signatures and ID. If there is NM keyring the AM adds the key to
you would have some security and someone directly responsible for
adding the key for each NM without being overworked.

> > It would be nice if some uncommon archs could have a buildd for this
> > so new maintainers are faced with protability right from the start.
> 
> I'm not likely to get an S/390 anytime soon (although donations are, of
> course, more than welcome).But I'm happy to put multiarch building
> into the system if you'd be willing to run a buildd for it (I'm depressingly
> single-arch these days).

I was more thinking along the line of having at least i386, ppc and
alpha or amd64. i386 (or ppc) should usually cover having the same
system the uploader had. ppc has different chars (and endianness i
think) and alpha/amd64 for a 64 bit arch. Shouldn't be hard to get
those.

> > > The final step I'm planning on building into the system is a way for
> > > sponsors to get packages out of this queue system I've built so they can
> > > check them over and upload.  The problem is, I'm not sure how to do this
> > > optimally.  My constraints are:
> > > 
> > > * Must be quick and simple to use.  Too much hassle will cause sponsors 
> > > not to
> > > use the system due to excessive pain.
> > 
> > A mini-dinstall apt repository with limitd access. Accounts could be
> > activated once by signed mail stating a user/pass pair.
> 
> Hmm, yes.  What I've got at the moment is tarballs built from the
> autobuilder output, with the .dsc, everything mentioned in there, and the
> build log.  My thought was that sponsors, when they wanted to get something
> to sponsor, would download that tarball (everything you need in one easy
> package).  If you think it would be more helpful, I've already got a package
> pool set up internally that I can easily convert for the purpose if needed.

For signing the build log (sbuild includes the changes file) or the
changes file is needed. For testing or fetching source a repository is
easiest to install, at least thats what I came to for my own
packages.

> > > * I'd like (but it's not an absolute requirement) to be able to track who
> > > "claimed" each package for sponsorship, so sponsees can harass a 
> > > particular
> > > someone if the upload never gets done.
> > 
> > Sponsoring could work just like the normal buildds. The sponsor sends
> > a mail back to the buildd wi

Re: RFS: xhangglider package uploaded to mentors

[Joshua Kwan]

On Tue, Feb 17, 2004 at 01:54:57AM -0500, Rudy Godoy wrote:
> Hi there, as i've said before [0] I'm willing to adpot xhangglider, I've
> worked on the package and I've finally uploaded [1] to mentors.debian.net.
> If there's anybody who wants to sponsor this package I'll appreciate to take
> a look on it and let me know.

This doesn't look too much different from the old package...

1) You should work the build system so that the binary and manpage are
built in the build-stamp target.

2) You should remove Makefile from the orig.tar.gz in the clean target at
some point and upload a new one. Currently, refreshing the Makefile that
came in the orig.tar.gz causes major diff.gz bloat:

$ zcat ../*.diff.gz | diffstat
 Imakefile   |6 
 Makefile|  552 
 debian/README.Debian|5 
 debian/changelog|   57 
 debian/compat   |1 
 debian/control  |   14 +
 debian/copyright|   19 +
 debian/dirs |3 
 debian/docs |4 
 debian/menu |4 
 debian/rules|   65 +
 debian/xhangglider.1|   36 ++
 debian/xhangglider.1x   |   36 ++
 debian/xhangglider.es.1 |   39 +++
 debian/xhangglider.manpages |1 
 glider.def  |4 
 16 files changed, 694 insertions(+), 152 deletions(-)

Or you could move it away at build time and move it back later.

3) It is probably desirable to support DEB_BUILD_OPTIONS=noopt in your
debian/rules, so that the binary is built at -O0 instead of -O2 (i.e.
for debugging purposes.)

Otherwise this looks pretty nice. I took a look at the bugs page for
xhangglider and posted a patch to #192923 - seems to work and you should
apply it I think.

-- 
Joshua Kwan


signature.asc
Description: Digital signature

Re: RFS: xhangglider package uploaded to mentors

[Colin Watson]

On Tue, Feb 17, 2004 at 12:07:28AM -0800, Joshua Kwan wrote:
> 2) You should remove Makefile from the orig.tar.gz in the clean target at
> some point and upload a new one. Currently, refreshing the Makefile that
> came in the orig.tar.gz causes major diff.gz bloat:

Huh? I haven't looked at this, but why would one generate a new
.orig.tar.gz that isn't original? .diff.gz bloat is to be lived with.

-- 
Colin Watson  [EMAIL PROTECTED]


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

Re: RFS: xhangglider package uploaded to mentors

[Joshua Kwan]

On Tue, Feb 17, 2004 at 10:16:17AM +, Colin Watson wrote:
> Huh? I haven't looked at this, but why would one generate a new
> .orig.tar.gz that isn't original? .diff.gz bloat is to be lived with.

I guess the line between keeping the diff.gz bloat and orig.tar.gz
constant with upstream is a gray area.

For example, I've had to re-tar the Visual Boy Advance sources just now
because it extracted as VisualBoyAdvance-1.7.1 and not
visualboyadvance-1.7.1, as dpkg-source expects (or at least prefers.) Is
that not justified?

I agree, though, in general one Makefile probably wouldn't justify
repacking.

-- 
Joshua Kwan


signature.asc
Description: Digital signature

Re: RFS: xhangglider package uploaded to mentors

[Colin Watson]

On Tue, Feb 17, 2004 at 02:42:20AM -0800, Joshua Kwan wrote:
> On Tue, Feb 17, 2004 at 10:16:17AM +, Colin Watson wrote:
> > Huh? I haven't looked at this, but why would one generate a new
> > .orig.tar.gz that isn't original? .diff.gz bloat is to be lived with.
> 
> I guess the line between keeping the diff.gz bloat and orig.tar.gz
> constant with upstream is a gray area.
> 
> For example, I've had to re-tar the Visual Boy Advance sources just now
> because it extracted as VisualBoyAdvance-1.7.1 and not
> visualboyadvance-1.7.1, as dpkg-source expects (or at least prefers.) Is
> that not justified?

Not in my book, no. dpkg-source has been happy with .orig.tar.gz
extracting to a different name for a long time now. To suppress
warnings, you should just need to build from a directory called
visualboyadvance-1.7.1.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]


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

applying patches

[Radu Spineanu]

hello 
 
I have to apply a small patch to my xmail package,
however  
i ran into different opinions while looking on how
to do this. 
Some suggested dbs, others dpatch, others just
applying the 
patch dirrectly to the source. 
 
I would like xmail to be part of debian ( in case
someone 
decides to sponsor it ) so which option is the
correct way for 
patching ? 
 
Radu Spineanu 





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

Multi-person sponsorship

[Matthew Palmer]

Prompted by a comment made by one of my potential sponsees, I've been
reworking my semi-automated sponsorship queue from a "helps me" thing to a
"could help lots of people" thing.  The comment was along the lines of
"wouldn't it be cool if we could remove the SPOF of sponsors, and have a
group of people sponsoring packages".

Well, I'm to the point now where I think that I can make that happen.  What
I've got so far is an upload queue, a test autobuilder (to make sure that
the package at least builds cleanly before wasting a sponsor's time with
it), and the generation of a tarball containing the .dsc, everything that
the .dsc references, and the build log from the test build.  All of that is
ticking along nicely, and I'd like to thank Lucas Wall and Juergen Strobel
for throwing their packages at the queue for the last few days while I
tweaked the bugs out of it.

The final question I'd like feedback on is this: how many sponsors would
consider pointing their sponsees to this service, rather than whatever
methods you're using now?  The benefits are that other sponsors might
occasionally take a bit of your workload, and if you go on holidays / get
sick / whatever, your sponsees aren't left to start from scratch.  Another
benefit could be that "occasional" uploads (such as NMUs and whatnot) could
be handled by a team, rather than by lots of indiscriminate begging on
d-mentors and elsewhere.

BTW, if a large part of what I'm describing below sounds like
mentors.debian.net, you're not alone.  Looking back, it might have been
easier to try and hack this into the m.d.n system.  That might be where this
all ends up.  I don't know.  One thing I'm not keen on is providing an
apt-getable archive, and I also want to keep track of what's been sponsored
and what's still waiting around - things that, AFAICT, m.d.n doesn't
provide.

The final step I'm planning on building into the system is a way for
sponsors to get packages out of this queue system I've built so they can
check them over and upload.  The problem is, I'm not sure how to do this
optimally.  My constraints are:

* Must be quick and simple to use.  Too much hassle will cause sponsors not to
use the system due to excessive pain.

* I'd like (but it's not an absolute requirement) to be able to track who
"claimed" each package for sponsorship, so sponsees can harass a particular
someone if the upload never gets done.

* Minimal manual intervention required on the administration side of things. 
Preferably no need for setup of accounts beyond that provided by a GPG
public key.

* Once selected by a sponsor, a package for sponsorship is taken "off the
market" for others, but can be reinstated later if the original downloader
can't upload, but the package shouldn't be rejected.

* If possible, sponsors should be able to select a package they want to
check and upload, rather than being given the "next in the queue".  For
instance, I'm not qualified to sponsor java packages, and I'm sure others
are in the same boat.

* As simple to implement as possible.  Duh.

So, given all of that, I've got two different ways thought up.  Both suck,
but in different ways.

1) E-mail.  Sponsors send a GPG signed e-mail to a request address, get the
next package on the list e-mailed back to them.  They could also request a
particular package, and if it's available, they'll get that.  Fails the
"select" part badly, but can be hacked to do most everything else.  But who
wants multi-megabyte files in their inbox, hmm?

2) Web.  Surprise!  Makes the tracking stuff harder (probably need to go to
a login-based approach - yay, another password to remember/manage) but
simplifies the package selection and downloads won't be quite so horrendous. 
Easier for me to implement because it's what I get paid to write (webapps).

There have also been thoughts of mutant hybrids flying through my brain,
where you list on the web and send e-mail to retrieve, then get a URL to
download, but these have, well, severely limited attractiveness for me.  But
it's another possibility.  How about an e-mail to get the list of packages,
then reply with the one you want, and you get back a URL to download the one
you want.  Ugly, though, and I'd need to write code to parse MIME for the
GPG signatures (more Python learning, I guess).

So, comments, brickbats, acclaim, whatever.  Throw it at me.

- Matt


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

Re: applying patches

[Matthew Palmer]

On Tue, Feb 17, 2004 at 03:04:39PM +0200, Radu Spineanu wrote:
> I have to apply a small patch to my xmail package,
> however  
> i ran into different opinions while looking on how
> to do this. 
> Some suggested dbs, others dpatch, others just
> applying the 
> patch dirrectly to the source. 
>  
> I would like xmail to be part of debian ( in case
> someone 
> decides to sponsor it ) so which option is the
> correct way for 
> patching ? 

Whatever works.  

If you're not expecting many patches, you could go the "direct to source"
route.  It's simple, easy to comprehend, and doesn't require any extra
packaging overhead.

However, at some point you'll probably end up with a bunch of separate
patches which are backports from upstream CVS fixing urgent bugs, unofficial
patches which you thought were a good idea but upstream hates, patches
Debian users have created which haven't made it into an upstream release,
and so on.  Managing these, particularly the ones that are likely to be in
upstream at a later point, becomes a problem.  For that, one of the patch
management systems above, or one of a couple of others I've heard mentioned,
are better ways to go.

As to which one is best, I really can't tell you.  I've never gotten quite
to patch hell (although both PHPWiki and IRM are starting to get there). 
All of the systems available have their advocates and their detractors. 
Perhaps try a couple of them out and see which one makes the most sense to
you?  I assume that they're all half-decent, or nobody would be using them
and they'd have died by now.  From memory, dbs is a fairly different build
system, cdbs even more so, while dpatch has the Unix nature - it does one
thing (patch management in Debian packages) and does it (hopefully) well.

Hmm, now you've got me wondering if I should dig out dpatch and try it out
on PHPWiki.  Onto the TODO list it goes.

- Matt


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

Re: applying patches

[Geert Stappers]

On Tue, Feb 17, 2004 at 03:04:39PM +0200, Radu Spineanu wrote:
> hello 
>  
> I have to apply a small patch to my xmail package,
> however  
> i ran into different opinions while looking on how
> to do this. 
> Some suggested dbs, others dpatch, others just
> applying the 
> patch dirrectly to the source. 
>  
> I would like xmail to be part of debian ( in case
> someone 
> decides to sponsor it ) so which option is the
> correct way for 
> patching ? 

Welcome to Free Software, where you can choose.

>  
> Radu Spineanu 
> 

Geert Stappers, happy dpatch user


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

Re: Multi-person sponsorship

[Jamin W. Collins]

On Tue, Feb 17, 2004 at 11:57:55PM +1100, Matthew Palmer wrote:
> 
> The final question I'd like feedback on is this: how many sponsors
> would consider pointing their sponsees to this service, rather than
> whatever methods you're using now?  The benefits are that other
> sponsors might occasionally take a bit of your workload, and if you go
> on holidays / get sick / whatever, your sponsees aren't left to start
> from scratch.  Another benefit could be that "occasional" uploads
> (such as NMUs and whatnot) could be handled by a team, rather than by
> lots of indiscriminate begging on d-mentors and elsewhere.

I like the automatic build testing, but would like to stress that these
packages would still need installation and usage testing.

> The final step I'm planning on building into the system is a way for
> sponsors to get packages out of this queue system I've built so they
> can check them over and upload.  The problem is, I'm not sure how to
> do this optimally.  My constraints are:
> 
> * Must be quick and simple to use.  Too much hassle will cause
> sponsors not to use the system due to excessive pain.

Could create an upload queue similar to Debian's current ftp uploads.  I
would check the upload to see if it's signed by a developer's key.  If
so, it could remove the package from your queue and forward the signed
upload on to Debian's upload queue.

> 2) Web.  Surprise!  Makes the tracking stuff harder (probably need to
> go to a login-based approach - yay, another password to
> remember/manage) but simplifies the package selection and downloads
> won't be quite so horrendous.  Easier for me to implement because it's
> what I get paid to write (webapps).

I would prefer this approach.

-- 
Jamin W. Collins

To be nobody but yourself when the whole world is trying it's best night
and day to make you everybody else is to fight the hardest battle any
human being will fight. -- E.E. Cummings


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

Re: data files in /etc?

[Goswin von Brederlow]

Magosányi Árpád <[EMAIL PROTECTED]> writes:

> Hi!
> 
> There are some files in /etc which are actually data files representing
> the state of the system. Like /etc/mtab, /etc/network/ifstate, or

The BTS has several patches for mount that allow /etc/mtab to be a
link to another file. Thats an extension to being a link to
/proc/mounts, which has some drawbacks like breaking loopback mounts.

For the /etc/network/ifstate afaik someone did a rewrite working
differently at some stage and the package was fixed to deal with it
being linked a long time ago.

> /etc/lvmconf/* (it is not even a text file).

That can also be linked to another location.

> These files are written by programs in occasions one cannot with good
> heart call configuration. Isn't it against the policy?

The problem is that those files have always been there (historic
reason) and that they may be needed during boot before any alternative
place is available (practical reason). They can't be in /var/state if
that is not yet mounted, on a network filesystem/device or lvm, and so
on. Check for the discussions about adding /run or /state.

If they bother you and you know certain conditions don't apply to you
(like var being on a network device) they can be linked. Arguments
about the files has repeadatly ended with the compromise to allow them
to be linked somewhere more fitting for the individual system.

> There are practical reasons behind my question:
> -if one uses a configuration management tool (like tla) to track changes
>  in the configuration, one will stumble upon them sooner or later.
> -if one wants to make the boot process unable to modify configuration,
>  they will also be stumbled upon. (And given the fact that mount
>  actually deletes and recreates /etc/mtab, the challenge is...
>  challenging.)

Or when you want a read-only / and /usr filesystem.

Mounting a ramdisk or tmpfs early during boot and linking the files to
there solves that problem. Note that you need the patch for mount
otherwise it will try to create /etc/mtab~ and iirc /etc/mtab.tmp or
something.

MfG
Goswin


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

Re: buildd problem

[Goswin von Brederlow]

John Belmonte <[EMAIL PROTECTED]> writes:

> Hello,
> 
> Not being much of a buildd expert, I'm wondering what is keeping my
> xmlsec1 package from entering testing.  There was a problem with the
> s390 build attempted Feb 05: "libgnutls10-dev missing".  However, I
> see that the s390 binary of libgnutls10-dev has been available since
> Feb 10. Will this take care of itself or must I do something to
> trigger a new build attempt?
> 
> 
> -John

You can check out details of the state of your package on

http://www.buildd.net/

Depending on the state of your package in wanna-build its
automatic.  Correct state for "libgnutls10-dev missing" would be
Dep-Wait, which requeues the source once the dependency becomes
available (looks like that happened from what Colin Watson mailed).

More information about the different states and how it works is also
available if you follow links on the same page from above.

MfG
Goswin


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

Re: Multi-person sponsorship

[Goswin von Brederlow]

Matthew Palmer <[EMAIL PROTECTED]> writes:

> Prompted by a comment made by one of my potential sponsees, I've been
> reworking my semi-automated sponsorship queue from a "helps me" thing to a
> "could help lots of people" thing.  The comment was along the lines of
> "wouldn't it be cool if we could remove the SPOF of sponsors, and have a
> group of people sponsoring packages".
> 
> Well, I'm to the point now where I think that I can make that happen.  What
> I've got so far is an upload queue, a test autobuilder (to make sure that
> the package at least builds cleanly before wasting a sponsor's time with
> it), and the generation of a tarball containing the .dsc, everything that
> the .dsc references, and the build log from the test build.  All of that is
> ticking along nicely, and I'd like to thank Lucas Wall and Juergen Strobel
> for throwing their packages at the queue for the last few days while I
> tweaked the bugs out of it.

What kind of security do you have to prevent uploads of malicious
sources?

I hope you destroy the chroot after each build and unpack it anew.

Having a new-maintainer keyring, to which keys could get added by any
AM after it has been verified, and checking the signature on the dsc
files against it sounds good to. And the keyring would be usefull for
other purposes too.

> The final question I'd like feedback on is this: how many sponsors would
> consider pointing their sponsees to this service, rather than whatever
> methods you're using now?  The benefits are that other sponsors might
> occasionally take a bit of your workload, and if you go on holidays / get
> sick / whatever, your sponsees aren't left to start from scratch.  Another
> benefit could be that "occasional" uploads (such as NMUs and whatnot) could
> be handled by a team, rather than by lots of indiscriminate begging on
> d-mentors and elsewhere.

I like it.

> BTW, if a large part of what I'm describing below sounds like
> mentors.debian.net, you're not alone.  Looking back, it might have been
> easier to try and hack this into the m.d.n system.  That might be where this
> all ends up.  I don't know.  One thing I'm not keen on is providing an
> apt-getable archive, and I also want to keep track of what's been sponsored
> and what's still waiting around - things that, AFAICT, m.d.n doesn't
> provide.

It would be nice if some uncommon archs could have a buildd for this
so new maintainers are faced with protability right from the start.

> The final step I'm planning on building into the system is a way for
> sponsors to get packages out of this queue system I've built so they can
> check them over and upload.  The problem is, I'm not sure how to do this
> optimally.  My constraints are:
> 
> * Must be quick and simple to use.  Too much hassle will cause sponsors not to
> use the system due to excessive pain.

A mini-dinstall apt repository with limitd access. Accounts could be
activated once by signed mail stating a user/pass pair.

> * I'd like (but it's not an absolute requirement) to be able to track who
> "claimed" each package for sponsorship, so sponsees can harass a particular
> someone if the upload never gets done.

Sponsoring could work just like the normal buildds. The sponsor sends
a mail back to the buildd with the signature and the buildd does the
uploading. There could be a simple webpage where DDs can claim
packages for a limited time (say 24h default with a 1 week option)
with a simple click. The webpage could double at showing whats
available for sponsoring too.

> * Minimal manual intervention required on the administration side of things. 
> Preferably no need for setup of accounts beyond that provided by a GPG
> public key.

A mail wrapper could check against the debian keyring and activate
accounts fully automatic then.

> * Once selected by a sponsor, a package for sponsorship is taken "off the
> market" for others, but can be reinstated later if the original downloader
> can't upload, but the package shouldn't be rejected.

Unless its rejected by the sponsor (with an explaination) or a newer
version is uploaded. I think if the sponsor finds problems with a
package it shouldn't go back just because some time passed. Packages
should automatically come pack when no action is taken by the sponsor
though.

> * If possible, sponsors should be able to select a package they want to
> check and upload, rather than being given the "next in the queue".  For
> instance, I'm not qualified to sponsor java packages, and I'm sure others
> are in the same boat.
> 
> * As simple to implement as possible.  Duh.
> 
> So, given all of that, I've got two different ways thought up.  Both suck,
> but in different ways.
> 
> 1) E-mail.  Sponsors send a GPG signed e-mail to a request address, get the
> next package on the list e-mailed back to them.  They could also request a
> particular package, and if it's available, they'll get that.  Fails the
> "select" part badly, but can be hacked to do most everything els

Re: Multi-person sponsorship

[Thomas Viehmann]

Goswin von Brederlow wrote:
> Having a new-maintainer keyring, to which keys could get added by any
> AM after it has been verified, and checking the signature on the dsc
> files against it sounds good to. And the keyring would be usefull for
> other purposes too.

Why not just check if the key is signed by a key in the debian keyring?
This could be done completely automatically.

Cheers

T.

-- 
Thomas Viehmann, 


pgp0.pgp
Description: PGP signature

Re: data files in /etc?

[Goswin von Brederlow]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Magosányi Árpád <[EMAIL PROTECTED]> writes:
> 
> > Hi!
> > 
> > There are some files in /etc which are actually data files representing
> > the state of the system. Like /etc/mtab, /etc/network/ifstate, or
> 
> The BTS has several patches for mount that allow /etc/mtab to be a
> link to another file. Thats an extension to being a link to
> /proc/mounts, which has some drawbacks like breaking loopback mounts.

The /proc/mounts has the drawbacks, the extra paches not.

> For the /etc/network/ifstate afaik someone did a rewrite working
> differently at some stage and the package was fixed to deal with it
> being linked a long time ago.
> 
> > /etc/lvmconf/* (it is not even a text file).
> 
> That can also be linked to another location.
> 
> > These files are written by programs in occasions one cannot with good
> > heart call configuration. Isn't it against the policy?
> 
> The problem is that those files have always been there (historic
> reason) and that they may be needed during boot before any alternative
> place is available (practical reason). They can't be in /var/state if
> that is not yet mounted, on a network filesystem/device or lvm, and so
> on. Check for the discussions about adding /run or /state.
> 
> If they bother you and you know certain conditions don't apply to you
> (like var being on a network device) they can be linked. Arguments
> about the files has repeadatly ended with the compromise to allow them
> to be linked somewhere more fitting for the individual system.
> 
> > There are practical reasons behind my question:
> > -if one uses a configuration management tool (like tla) to track changes
> >  in the configuration, one will stumble upon them sooner or later.
> > -if one wants to make the boot process unable to modify configuration,
> >  they will also be stumbled upon. (And given the fact that mount
> >  actually deletes and recreates /etc/mtab, the challenge is...
> >  challenging.)
> 
> Or when you want a read-only / and /usr filesystem.
> 
> Mounting a ramdisk or tmpfs early during boot and linking the files to
> there solves that problem. Note that you need the patch for mount
> otherwise it will try to create /etc/mtab~ and iirc /etc/mtab.tmp or
> something.
> 
> MfG
> Goswin
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


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

Re: Multi-person sponsorship

[Goswin von Brederlow]

Thomas Viehmann <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow wrote:
> > Having a new-maintainer keyring, to which keys could get added by any
> > AM after it has been verified, and checking the signature on the dsc
> > files against it sounds good to. And the keyring would be usefull for
> > other purposes too.
> 
> Why not just check if the key is signed by a key in the debian keyring?
> This could be done completely automatically.
> 
> Cheers
> 
> T.

Because then you would need a DD sponsoring your uploading sources to
the sponsoring pool be sponsored by a DD after build.

The check is ment for the source so as not to build just anything.

MfG
Goswin


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

Re: Multi-person sponsorship

[Thomas Viehmann]

Goswin von Brederlow wrote:
> Thomas Viehmann <[EMAIL PROTECTED]> writes:
> 
> 
>>Goswin von Brederlow wrote:
>>
>>>Having a new-maintainer keyring, to which keys could get added by any
>>>AM after it has been verified, and checking the signature on the dsc
>>>files against it sounds good to. And the keyring would be usefull for
>>>other purposes too.
>>
>>Why not just check if the key is signed by a key in the debian keyring?
^^^ the key, not the package
>>This could be done completely automatically.
> Because then you would need a DD sponsoring your uploading sources to
> the sponsoring pool be sponsored by a DD after build.
> The check is ment for the source so as not to build just anything.

I'd think you misunderstood me, but it might be vice versa...

Cheers

T.

-- 
Thomas Viehmann, 


pgp0.pgp
Description: PGP signature

xmail package updated

[Radu Spineanu]

Hello to all 
 
Since it was a very small patch (it added 2 lines)
i decided to 
apply it just like that. 
 
deb http://k9.bizland.ro/xmail ./ 
deb-src http://k9.bizland.ro/xmail ./ 
 
Linda returns an error that is misses a man page
for a binary 
but that is a script that makes sendmail.xmail
work with 
debian. 
 
Also i didn't get any responses from any D-D. I
must understand 
that nobody is interested :) ? 
 
Radu Spineanu 





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

Re: Multi-person sponsorship

[Matthew Palmer]

On Tue, Feb 17, 2004 at 07:11:08PM +0100, Goswin von Brederlow wrote:
> > Prompted by a comment made by one of my potential sponsees, I've been
> > reworking my semi-automated sponsorship queue from a "helps me" thing to a
> > "could help lots of people" thing.  The comment was along the lines of
> > "wouldn't it be cool if we could remove the SPOF of sponsors, and have a
> > group of people sponsoring packages".
> > 
> > Well, I'm to the point now where I think that I can make that happen.  What
> > I've got so far is an upload queue, a test autobuilder (to make sure that
> > the package at least builds cleanly before wasting a sponsor's time with
> > it), and the generation of a tarball containing the .dsc, everything that
> > the .dsc references, and the build log from the test build.  All of that is
> > ticking along nicely, and I'd like to thank Lucas Wall and Juergen Strobel
> > for throwing their packages at the queue for the last few days while I
> > tweaked the bugs out of it.
> 
> What kind of security do you have to prevent uploads of malicious
> sources?

If the .changes isn't signed by a key in the "uploaders" keyring, it gets
rejected.  The exact criteria for who gets their key in hasn't been thought
about yet - so far, it's been people I intend to sponsor.  I presume it'll
be something like that in the future, too.

> I hope you destroy the chroot after each build and unpack it anew.

Sing it loud, and sing it clear - "We love pbuilder!  We love pbuilder!"

> Having a new-maintainer keyring, to which keys could get added by any
> AM after it has been verified, and checking the signature on the dsc
> files against it sounds good to. And the keyring would be usefull for
> other purposes too.

I hadn't thought about an NM keyring, but that has a certain amount of sense
to it.  I'd like to not limit the sponsorship service to just people who are
in the NM queue, but even a "sponsee keyring" - perhaps separated by
NM/non-NM - would be of definite benefit.  Knowing the trust path of the
maintainer of your software would be useful, even when they're not a DD.

> It would be nice if some uncommon archs could have a buildd for this
> so new maintainers are faced with protability right from the start.

I'm not likely to get an S/390 anytime soon (although donations are, of
course, more than welcome).But I'm happy to put multiarch building
into the system if you'd be willing to run a buildd for it (I'm depressingly
single-arch these days).

> > The final step I'm planning on building into the system is a way for
> > sponsors to get packages out of this queue system I've built so they can
> > check them over and upload.  The problem is, I'm not sure how to do this
> > optimally.  My constraints are:
> > 
> > * Must be quick and simple to use.  Too much hassle will cause sponsors not to
> > use the system due to excessive pain.
> 
> A mini-dinstall apt repository with limitd access. Accounts could be
> activated once by signed mail stating a user/pass pair.

Hmm, yes.  What I've got at the moment is tarballs built from the
autobuilder output, with the .dsc, everything mentioned in there, and the
build log.  My thought was that sponsors, when they wanted to get something
to sponsor, would download that tarball (everything you need in one easy
package).  If you think it would be more helpful, I've already got a package
pool set up internally that I can easily convert for the purpose if needed.

> > * I'd like (but it's not an absolute requirement) to be able to track who
> > "claimed" each package for sponsorship, so sponsees can harass a particular
> > someone if the upload never gets done.
> 
> Sponsoring could work just like the normal buildds. The sponsor sends
> a mail back to the buildd with the signature and the buildd does the
> uploading. There could be a simple webpage where DDs can claim

I'm wondering if that might be sailing a little close to the wind, though. 
I'd prefer not to fiddle with the way things are done too much this early,
and "automating" uploads feels a little too much like it's ripe for abuse. 
At least this way, since it's going to take the sponsor some time just to
build the package ready for sign+upload, hopefully they'll spend the extra
time looking for problems and maybe trying the package.

> packages for a limited time (say 24h default with a 1 week option)
> with a simple click. The webpage could double at showing whats
> available for sponsoring too.

This isn't a bad idea.  I might have to get a little funky with my
mod_rewrite skills (pitiful as they are) and get something going so I can do
some reference-counting (and general funky stuff).

> > * Minimal manual intervention required on the administration side of things. 
> > Preferably no need for setup of accounts beyond that provided by a GPG
> > public key.
> 
> A mail wrapper could check against the debian keyring and activate
> accounts fully automatic then.

So I still have to write my MIME-aware mail check

Re: Multi-person sponsorship

[Goswin von Brederlow]

Thomas Viehmann <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow wrote:
> > Thomas Viehmann <[EMAIL PROTECTED]> writes:
> > 
> > 
> >>Goswin von Brederlow wrote:
> >>
> >>>Having a new-maintainer keyring, to which keys could get added by any
> >>>AM after it has been verified, and checking the signature on the dsc
> >>>files against it sounds good to. And the keyring would be usefull for
> >>>other purposes too.
> >>
> >>Why not just check if the key is signed by a key in the debian keyring?
> ^^^ the key, not the package
> >>This could be done completely automatically.
> > Because then you would need a DD sponsoring your uploading sources to
> > the sponsoring pool be sponsored by a DD after build.
> > The check is ment for the source so as not to build just anything.
> 
> I'd think you misunderstood me, but it might be vice versa...

Yes, I did.

MfG
Goswin


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

Re: Multi-person sponsorship

[Goswin von Brederlow]

Matthew Palmer <[EMAIL PROTECTED]> writes:

> On Tue, Feb 17, 2004 at 07:11:08PM +0100, Goswin von Brederlow wrote:
> > > Prompted by a comment made by one of my potential sponsees, I've been
> > > reworking my semi-automated sponsorship queue from a "helps me" thing to a
> > > "could help lots of people" thing.  The comment was along the lines of
> > > "wouldn't it be cool if we could remove the SPOF of sponsors, and have a
> > > group of people sponsoring packages".
> > > 
> > > Well, I'm to the point now where I think that I can make that happen.  What
> > > I've got so far is an upload queue, a test autobuilder (to make sure that
> > > the package at least builds cleanly before wasting a sponsor's time with
> > > it), and the generation of a tarball containing the .dsc, everything that
> > > the .dsc references, and the build log from the test build.  All of that is
> > > ticking along nicely, and I'd like to thank Lucas Wall and Juergen Strobel
> > > for throwing their packages at the queue for the last few days while I
> > > tweaked the bugs out of it.
> > 
> > What kind of security do you have to prevent uploads of malicious
> > sources?
> 
> If the .changes isn't signed by a key in the "uploaders" keyring, it gets
> rejected.  The exact criteria for who gets their key in hasn't been thought
> about yet - so far, it's been people I intend to sponsor.  I presume it'll
> be something like that in the future, too.

That was what I had in mind, just everyone in the sponsoring group, or
any DD, should be able to add or remove keys.

Or accept any key signed by a DD or something that won#t be as hard as
becoming a DD itself.

> > I hope you destroy the chroot after each build and unpack it anew.
> 
> Sing it loud, and sing it clear - "We love pbuilder!  We love pbuilder!"
> 
> > Having a new-maintainer keyring, to which keys could get added by any
> > AM after it has been verified, and checking the signature on the dsc
> > files against it sounds good to. And the keyring would be usefull for
> > other purposes too.
> 
> I hadn't thought about an NM keyring, but that has a certain amount of sense
> to it.  I'd like to not limit the sponsorship service to just people who are
> in the NM queue, but even a "sponsee keyring" - perhaps separated by
> NM/non-NM - would be of definite benefit.  Knowing the trust path of the
> maintainer of your software would be useful, even when they're not a DD.

Whatever the name. I was just reminded that a NM keyring would be
usefull for tracking the NMs packages and similar jobs. The AM checks
the signatures and ID. If there is NM keyring the AM adds the key to
you would have some security and someone directly responsible for
adding the key for each NM without being overworked.

> > It would be nice if some uncommon archs could have a buildd for this
> > so new maintainers are faced with protability right from the start.
> 
> I'm not likely to get an S/390 anytime soon (although donations are, of
> course, more than welcome).But I'm happy to put multiarch building
> into the system if you'd be willing to run a buildd for it (I'm depressingly
> single-arch these days).

I was more thinking along the line of having at least i386, ppc and
alpha or amd64. i386 (or ppc) should usually cover having the same
system the uploader had. ppc has different chars (and endianness i
think) and alpha/amd64 for a 64 bit arch. Shouldn't be hard to get
those.

> > > The final step I'm planning on building into the system is a way for
> > > sponsors to get packages out of this queue system I've built so they can
> > > check them over and upload.  The problem is, I'm not sure how to do this
> > > optimally.  My constraints are:
> > > 
> > > * Must be quick and simple to use.  Too much hassle will cause sponsors not to
> > > use the system due to excessive pain.
> > 
> > A mini-dinstall apt repository with limitd access. Accounts could be
> > activated once by signed mail stating a user/pass pair.
> 
> Hmm, yes.  What I've got at the moment is tarballs built from the
> autobuilder output, with the .dsc, everything mentioned in there, and the
> build log.  My thought was that sponsors, when they wanted to get something
> to sponsor, would download that tarball (everything you need in one easy
> package).  If you think it would be more helpful, I've already got a package
> pool set up internally that I can easily convert for the purpose if needed.

For signing the build log (sbuild includes the changes file) or the
changes file is needed. For testing or fetching source a repository is
easiest to install, at least thats what I came to for my own
packages.

> > > * I'd like (but it's not an absolute requirement) to be able to track who
> > > "claimed" each package for sponsorship, so sponsees can harass a particular
> > > someone if the upload never gets done.
> > 
> > Sponsoring could work just like the normal buildds. The sponsor sends
> > a mail back to the buildd with the signature and the bui