Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Launchpad User (http://www.linux-archive.org/launchpad-user/)
-   -   PPA (http://www.linux-archive.org/launchpad-user/33831-ppa.html)

Henrik Stokseth 12-30-2007 05:37 PM

PPA
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Can someone please nuke all my PPA contents? Thanks.

Anyone know when users will be able to delete PPA submissions btw?

- - Henrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHd+VrF68VKf3+XAERArbYAKCDSu8VzLQ4AYFOOrhr8x IVi4BKUQCeOjmt
o4/iuwAOKsRgi4zftln9Vww=
=kTkg
-----END PGP SIGNATURE-----

--
launchpad-users mailing list
launchpad-users@lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users

Stéphane Glondu 05-01-2011 02:59 PM

PPA
 
Le 01/05/2011 15:34, Andreas Barth a écrit :
> 1. How to push from a vcs (git, svn, ...) to ppa? (This should be
> coordinated with ftp-masters, so that the same method could be used
> later on for uploading into unstable.)
>
> 2. How could we create new ppa repositories easy enough, how do we
> hold the data, how do we make sure that dependencies are there?
> (Basically "how do we extend dak for ppa?")
>
> 3. How do we extend authentication concepts for apt to ppa? (So that
> one could say "please give me this and that repository from ppa", and
> one doesn't need to add custom apt-keys.)
>
> 4. How do we get a good interface to see which patches are where, and
> which bugs are found (or fixed) where?
>
> 5. After 2. is done, setting up autobuilding for ppa. (I'll be happy
> to help with this part, but 2. needs to be done first.)

I don't understand why this is only point 5. Setting up a custom
repository easily usable is quite easy... and done already
(mozilla.debian.net has been mentioned; I also happen to provide
unofficial packages on ocaml.debian.net). I don't see why points 1-4
should be addressed by the project as a whole (and a prerequisite of 5):
each PPA maintainer can have its own tool / policy / proposals before
everyone agrees on something more unified.

On the other hand, custom repositories are always restricted to
architectures their maintainer have access to. It would be nice if the
autobuilding network would allow submitting jobs not targeted for
official suites. Something a PPA maintainer could use to get the binary
packages for architectures he doesn't have access to.


Cheers,

--
Stéphane


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DBD756D.8090404@debian.org">http://lists.debian.org/4DBD756D.8090404@debian.org

Andreas Barth 05-01-2011 03:16 PM

PPA
 
* Stéphane Glondu (glondu@debian.org) [110501 17:00]:
> Le 01/05/2011 15:34, Andreas Barth a écrit :
> > 1. How to push from a vcs (git, svn, ...) to ppa? (This should be
> > coordinated with ftp-masters, so that the same method could be used
> > later on for uploading into unstable.)
> >
> > 2. How could we create new ppa repositories easy enough, how do we
> > hold the data, how do we make sure that dependencies are there?
> > (Basically "how do we extend dak for ppa?")
> >
> > 3. How do we extend authentication concepts for apt to ppa? (So that
> > one could say "please give me this and that repository from ppa", and
> > one doesn't need to add custom apt-keys.)
> >
> > 4. How do we get a good interface to see which patches are where, and
> > which bugs are found (or fixed) where?
> >
> > 5. After 2. is done, setting up autobuilding for ppa. (I'll be happy
> > to help with this part, but 2. needs to be done first.)
>
> I don't understand why this is only point 5. Setting up a custom
> repository easily usable is quite easy... and done already
> (mozilla.debian.net has been mentioned; I also happen to provide
> unofficial packages on ocaml.debian.net).

It's easy for one piece of software. I maintained more than one dak
instance already.

However, to get that done right for multiple software is not so easy.
But please prove me wrong - as soon as 2. is done, I'm happy to help
setting up autobuilding (even if that happens this afternoon). It
needs however done in a way where buildds only pick up source packages
from one place, and upload to one place, independend whether the
source package is mozilla, ocaml, or something else.


> I don't see why points 1-4
> should be addressed by the project as a whole (and a prerequisite of 5):
> each PPA maintainer can have its own tool / policy / proposals before
> everyone agrees on something more unified.

Well yes, but how many autobuilding suites should we add? 50? 100?
200? How do we do key management so that we know that the autobuilder
build the packages that they should?

No, there will be only one new autobuilder suite per debian release,
and so there needs to be some apt-magic that hands out the appropriate
packages.


> On the other hand, custom repositories are always restricted to
> architectures their maintainer have access to. It would be nice if the
> autobuilding network would allow submitting jobs not targeted for
> official suites. Something a PPA maintainer could use to get the binary
> packages for architectures he doesn't have access to.

That would be some apt-repository. Create it in a way that allows to
specify appropriate build-dependencies (or just say that the package
need to specify all by hand as today in experimental), and we could
move on. (See 2. for some questions I had in mind).



Andi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110501151648.GI15003@mails.so.argh.org">http://lists.debian.org/20110501151648.GI15003@mails.so.argh.org

Raphael Hertzog 05-01-2011 04:22 PM

PPA
 
On Sun, 01 May 2011, Andreas Barth wrote:
> However, to get that done right for multiple software is not so easy.
> But please prove me wrong - as soon as 2. is done, I'm happy to help
> setting up autobuilding (even if that happens this afternoon). It
> needs however done in a way where buildds only pick up source packages
> from one place, and upload to one place, independend whether the
> source package is mozilla, ocaml, or something else.

Another aspect is that the PPA in question must be activated in the buildd
chroot so that build-dependencies can be solved in the PPA. Otherwise PPA
can't be used to prepare important transitions.

And you don't really want to mess up the build chroot, so it should really
use one of the sbuild/schroot method that throw away all changes after a
build.

> > I don't see why points 1-4
> > should be addressed by the project as a whole (and a prerequisite of 5):
> > each PPA maintainer can have its own tool / policy / proposals before
> > everyone agrees on something more unified.
>
> Well yes, but how many autobuilding suites should we add? 50? 100?
> 200? How do we do key management so that we know that the autobuilder
> build the packages that they should?

How can we submit jobs to a buildd?

I don't know if we can need to invent a new file format but it would be
nice to be able to send a job to the buildd with all the required
parameters:
- target suite (oldstable/stable/testing/unstable)
- APT entry to add (i.e. URL of the PPA so that the buildd can fetch
build-dependencies not satisfiable in the target suite)
- requested architectures
- URL where the resulting files needs to be uploaded (if needed, otherwise
they could just be made available for a given amount of time)
- email to use for any notice (error in the upload, etc.)

For one-time builds, those job files could be signed by a DD key. For PPA,
we might want some sort of indirection, i.e. a keyring where DD can add
the key used by their PPA to submit buildd jobs.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News â–¶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110501162231.GB14157@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110501162231.GB14157@rivendell.home.ouaza.com

Stéphane Glondu 05-01-2011 04:24 PM

PPA
 
Le 01/05/2011 17:16, Andreas Barth a écrit :
>> I don't understand why this is only point 5. Setting up a custom
>> repository easily usable is quite easy... and done already
>> (mozilla.debian.net has been mentioned; I also happen to provide
>> unofficial packages on ocaml.debian.net).
>
> It's easy for one piece of software. I maintained more than one dak
> instance already.
>
> However, to get that done right for multiple software is not so easy.

What do you mean by "right"? Have you ever used Lauchpad's PPAs? Does it
qualify as "right"?

PPAs are not perfect... but they are practical and useful enough for
developers and users.

> Well yes, but how many autobuilding suites should we add? 50? 100?
> 200? How do we do key management so that we know that the autobuilder
> build the packages that they should?

Why would we need more suites?

I was thinking of a request that would include a base suite (e.g.
squeeze, wheezy, or sid), files to drop in /etc/apt/sources.list.d (and
/etc/apt/preferences.d), and the key used to sign unofficial
repositories. Of course, the request itself would be signed (like
*.changes or *.commands files on ftp-master). Then a buildd accepting a
job would add the key with apt-key, drop the files in /etc/apt, upgrade
and launch the build as usual... the whole thing done in a throw-away
chroot, obviously (I use cowbuilder myself for that, but I heard that
sbuild had support for LVM snapshots).

--
Stéphane


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DBD8920.6010203@debian.org">http://lists.debian.org/4DBD8920.6010203@debian.org

Andreas Barth 05-01-2011 04:34 PM

PPA
 
* Raphael Hertzog (hertzog@debian.org) [110501 18:23]:
> On Sun, 01 May 2011, Andreas Barth wrote:
> > However, to get that done right for multiple software is not so easy.
> > But please prove me wrong - as soon as 2. is done, I'm happy to help
> > setting up autobuilding (even if that happens this afternoon). It
> > needs however done in a way where buildds only pick up source packages
> > from one place, and upload to one place, independend whether the
> > source package is mozilla, ocaml, or something else.
>
> Another aspect is that the PPA in question must be activated in the buildd
> chroot so that build-dependencies can be solved in the PPA. Otherwise PPA
> can't be used to prepare important transitions.

Finding out how to specify dependencies was part of point 2, for a
reason.


> And you don't really want to mess up the build chroot, so it should really
> use one of the sbuild/schroot method that throw away all changes after a
> build.

That's obvious - same as experimental today. Don't worry about that
part.



> How can we submit jobs to a buildd?

Have a list of packages with versions that need to be built. Or just a
list of source packges and binary packages and build anything missing,
like today for e.g. experimental. And have a common location where the
source packages are. That's basically. (One could specify additional
dependencies / conflicts that are not in the source package.)


> - APT entry to add (i.e. URL of the PPA so that the buildd can fetch
> build-dependencies not satisfiable in the target suite)

Why not just use one location - shouldn't be an issue unless you plan
to have the same packages and version numbers in multiple PPAs. And
that's something I recommend not to do.

> - requested architectures

All that are in the sources-file specified.


> - URL where the resulting files needs to be uploaded (if needed, otherwise
> they could just be made available for a given amount of time)

One upload location per queue (or for multiple queues) - one could
always have a backend which changes things.


> For one-time builds, those job files could be signed by a DD key. For PPA,
> we might want some sort of indirection, i.e. a keyring where DD can add
> the key used by their PPA to submit buildd jobs.

Why not just upload packages, and build from there? As we do now?



Andi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110501163402.GJ15003@mails.so.argh.org">http://lists.debian.org/20110501163402.GJ15003@mails.so.argh.org

Andreas Barth 05-01-2011 04:37 PM

PPA
 
* Stéphane Glondu (glondu@debian.org) [110501 18:24]:
> Le 01/05/2011 17:16, Andreas Barth a écrit :
> > Well yes, but how many autobuilding suites should we add? 50? 100?
> > 200? How do we do key management so that we know that the autobuilder
> > build the packages that they should?
>
> Why would we need more suites?
>
> I was thinking of a request that would include a base suite (e.g.
> squeeze, wheezy, or sid), files to drop in /etc/apt/sources.list.d (and
> /etc/apt/preferences.d), and the key used to sign unofficial
> repositories. Of course, the request itself would be signed (like
> *.changes or *.commands files on ftp-master). Then a buildd accepting a
> job would add the key with apt-key, drop the files in /etc/apt, upgrade
> and launch the build as usual... the whole thing done in a throw-away
> chroot, obviously (I use cowbuilder myself for that, but I heard that
> sbuild had support for LVM snapshots).

The source code of wanna-build and sbuild is available via git. Feel
free to code the necessary enhancements.


However, that's only a part of the answer: If you compare with the
starting mail of this sub-thread, there are quite much more things
than just "how can maintainers rebuild a package". And I think that
these do make things really helpful.


Andi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110501163708.GK15003@mails.so.argh.org">http://lists.debian.org/20110501163708.GK15003@mails.so.argh.org

Roger Leigh 05-01-2011 04:46 PM

PPA
 
On Sun, May 01, 2011 at 06:34:02PM +0200, Andreas Barth wrote:
> * Raphael Hertzog (hertzog@debian.org) [110501 18:23]:
> > On Sun, 01 May 2011, Andreas Barth wrote:
> > How can we submit jobs to a buildd?
> > - APT entry to add (i.e. URL of the PPA so that the buildd can fetch
> > build-dependencies not satisfiable in the target suite)
>
> Why not just use one location - shouldn't be an issue unless you plan
> to have the same packages and version numbers in multiple PPAs. And
> that's something I recommend not to do.

With the newer 'apt' and 'aptitude' resolvers, where we are creating
a local apt archive, we already have the code to add additional
apt entries into /etc/apt/sources.list.d and update apt. If we need
to add additional sources, and the existing buildd mechanism
(99builddsourceslist) is insufficiently flexible, then we can always
add them by allowing them to be specified on the command-line. This
mechanism might be a somewhat simpler and more flexible alternative to
99builddsourceslist for the general case as well.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.

Andreas Barth 05-01-2011 04:54 PM

PPA
 
* Roger Leigh (rleigh@codelibre.net) [110501 18:46]:
> On Sun, May 01, 2011 at 06:34:02PM +0200, Andreas Barth wrote:
> > * Raphael Hertzog (hertzog@debian.org) [110501 18:23]:
> > > On Sun, 01 May 2011, Andreas Barth wrote:
> > > How can we submit jobs to a buildd?
> > > - APT entry to add (i.e. URL of the PPA so that the buildd can fetch
> > > build-dependencies not satisfiable in the target suite)
> >
> > Why not just use one location - shouldn't be an issue unless you plan
> > to have the same packages and version numbers in multiple PPAs. And
> > that's something I recommend not to do.
>
> With the newer 'apt' and 'aptitude' resolvers, where we are creating
> a local apt archive, we already have the code to add additional
> apt entries into /etc/apt/sources.list.d and update apt. If we need
> to add additional sources, and the existing buildd mechanism
> (99builddsourceslist) is insufficiently flexible, then we can always
> add them by allowing them to be specified on the command-line. This
> mechanism might be a somewhat simpler and more flexible alternative to
> 99builddsourceslist for the general case as well.

It's quite easy to add them, agreed. That could even be done with the
old sbuild version.

However, somehow the keys needs to be feed into a safe way.

Anyways, if someone could come up with the relevant code which works
(and has been shown to work for some time - just do that as an example
on amd64 or i386), that would be good to have it integrated. As said,
wanna-build is available via git, new options can be transfered in the
api=1-yaml-format (search for extra-changelog: in the code). If that
works stable and reliable, that would be great and one large item from
my whishlist done. (And as always: Above all, no harm. It shouldn't
disrupt existing buildds, chroots, whatever - I can remember well the
most recent upgrade of our buildds.)



Andi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110501165429.GL15003@mails.so.argh.org">http://lists.debian.org/20110501165429.GL15003@mails.so.argh.org

Roger Leigh 05-01-2011 05:04 PM

PPA
 
On Sun, May 01, 2011 at 06:24:00PM +0200, Stéphane Glondu wrote:
> I was thinking of a request that would include a base suite (e.g.
> squeeze, wheezy, or sid), files to drop in /etc/apt/sources.list.d (and
> /etc/apt/preferences.d), and the key used to sign unofficial
> repositories. Of course, the request itself would be signed (like
> *.changes or *.commands files on ftp-master). Then a buildd accepting a
> job would add the key with apt-key, drop the files in /etc/apt, upgrade
> and launch the build as usual... the whole thing done in a throw-away
> chroot, obviously (I use cowbuilder myself for that, but I heard that
> sbuild had support for LVM snapshots).

sbuild has support for all the clonable chroot types schroot offers
(LVM snapshots, Btrfs snapshots, unionfs/aufs filesystem overlays
and file-based sources such as compressed tar). AFAICT most of the
buildds are now using LVM with snapshotting.

If you do want to work on this, checkout sbuild.git. See
etc/99builddsourceslist for the existing apt sources.list configuration
used by the buildds. Could this be extended to do what you need?
Otherwise see lib/Sbuild/ResolverBase.pm for the existing sources.list.d
stuff.

WRT the signing key, there would need to be some form of trust path
or else the signature would be worthless. If packages are being
uploaded to Debian infrastructure, and are under our control, can't
we use a single signing key? We presumably verified the integrity
and origin of the package on initital upload, so we should be able to
use a generic signing key surely? If this is provided in a package
then we can trigger automated installation of it. This could even
be installed prior to downloading the source package; we don't currently
do this (we use the already available archive signing keys), but we can
add it.

The main thing sbuild needs would be the information to add to
sources.list, signing key packages etc. This would probably require
passing from buildd, so probably more a question of how buildd will
be configured and get the information to pass to sbuild.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.


All times are GMT. The time now is 05:08 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.