launchpad help|
⇤ ← Revision 1 as of 2007-09-14 15:16:35
Size: 10415
Comment:
|
Size: 10452
Comment: Formatting
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| This is an edited transcript of the ''PPA and Ubuntu Packaging 101'' session held in #launchpad at 15.00 UTC on 13th September 2007. | ''Questions are left in context, unless they appear in a mass Q&A section of the session.'' |
| Line 3: | Line 3: |
| For details of other PPA IRC sessions, see the [:PPA101:PPA 101] page. Questions are left in context, unless they appear in a mass Q&A section of the session. The original log of #launchpad for this day is available at: http://people.ubuntu.com/~fabbione/irclogs/launchpad-2007-09-13.html Search for "Hello and welcome to the PPA and Ubuntu Packaging 101 session!" |
|
| Line 14: | Line 5: |
| '''Led by:''' Jordan Mantha - Laserjock - MOTU team | '''Led by:''' Jordan Mantha - !LaserJock - MOTU team |
| Line 16: | Line 7: |
| LaserJock: ok, so we don't have time to launch into a big session on packaging LaserJock: but there are some basics that are useful when doing PPAs LaserJock: so first off, what does PPA accept? LaserJock: it accepts *source* packages LaserJock: so you don't want to upload .debs |
!LaserJock: ok, so we don't have time to launch into a big session on packaging[[BR]] !LaserJock: but there are some basics that are useful when doing PPAs[[BR]] !LaserJock: so first off, what does PPA accept?[[BR]] !LaserJock: it accepts *source* packages[[BR]] !LaserJock: so you don't want to upload .debs |
| Line 22: | Line 13: |
| LaserJock: anybody actually read the Ubuntu Packaging Guide? LaserJock: :-) |
!LaserJock: anybody actually read the Ubuntu Packaging Guide?[[BR]] !LaserJock: :-) |
| Line 27: | Line 18: |
| LaserJock: Ok, so I wanted to say that remember that we deal with source packages, that is .dsc, .diff.gz, and .orig.tar.gz normally | !LaserJock: Ok, so I wanted to say that remember that we deal with source packages, that is .dsc, .diff.gz, and .orig.tar.gz normally |
| Line 29: | Line 20: |
| LaserJock: now, to start with you might find it easiest to take an existing Ubuntu package LaserJock: you can either apt-get source <packagename> LaserJock: and note that you shouldn't do that with sudo LaserJock: or you can get the files from Launchpad or archive.ubuntu.com LaserJock: you can then mess around in the unpacked source package ( dpkg-source -x <package>.dsc if it isn't unpacked already) LaserJock: and to rebuild it you can do debuild -S (which is a wrapper around dpkg-buildpackage -S -rfakeroot) LaserJock: if you need to include the .orig.tar.gz in the upload, like the first time you have that .orig.tar.gz in your PPA LaserJock: then add -sa , debuild -S -sa LaserJock: the packages need to be signed with your gpg key (the same one that's on Launchpad) LaserJock: so make sure that the email address in your changelog entry is the same as in your gpg key LaserJock: I would strongly suggest that people test their source package by building them locally into .debs LaserJock: a good way to do that is with pbuilder |
!LaserJock: now, to start with you might find it easiest to take an existing Ubuntu package[[BR]] !LaserJock: you can either apt-get source <packagename>[[BR]] !LaserJock: and note that you shouldn't do that with sudo[[BR]] !LaserJock: or you can get the files from Launchpad or archive.ubuntu.com[[BR]] !LaserJock: you can then mess around in the unpacked source package ( dpkg-source -x <package>.dsc if it isn't unpacked already) !LaserJock: and to rebuild it you can do debuild -S (which is a wrapper around dpkg-buildpackage -S -rfakeroot)[[BR]][[BR]] !LaserJock: if you need to include the .orig.tar.gz in the upload, like the first time you have that .orig.tar.gz in your PPA[[BR]] !LaserJock: then add -sa , debuild -S -sa[[BR]] !LaserJock: the packages need to be signed with your gpg key (the same one that's on Launchpad)[[BR]] !LaserJock: so make sure that the email address in your changelog entry is the same as in your gpg key[[BR]] !LaserJock: I would strongly suggest that people test their source package by building them locally into .debs[[BR]] !LaserJock: a good way to do that is with pbuilder[[BR]] |
| Line 42: | Line 33: |
| superm1: its much more time consuming and annoying to let the PPA fail to build than it is to do it locally | superm1: its much more time consuming and annoying to let the PPA fail to build than it is to do it locally[[BR]] |
| Line 45: | Line 36: |
| LaserJock: superm1: exactly LaserJock: pbuilder creates a minimal Ubuntu envioronment in a chroot |
!LaserJock: superm1: exactly[[BR]] !LaserJock: pbuilder creates a minimal Ubuntu envioronment in a chroot |
| Line 48: | Line 39: |
| LaserJock: and and it provides a "clean room" because all the changes are dropped at then end of each session LaserJock: I don't seem to have it on me, but I made a script that allows you to easiy create and use pbuilders zakame: just to add: you'd want to look into /usr/lib/pbuilder/pbuilder-satisfydepends to be able to get the depencies for your package prior to building ;) LaserJock: I'll email the launchpad-users list with a URL later stdin: There a guide to create/use pbuilder on the wiki -> https://wiki.ubuntu.com/PbuilderHowto LaserJock: in any case you can have multiple pbuilders LaserJock: one for each Ubuntu release for example LaserJock: so you can be running Feisty and build Gutsy .debs LaserJock: I would highly recommend testing *each* source package before you upload LaserJock: simply as a way to minimize problems LaserJock: with lots of packages in the build queues, etc. it can take a while to get a package into the PPA archive |
!LaserJock: and and it provides a "clean room" because all the changes are dropped at then end of each session[[BR]] !LaserJock: I don't seem to have it on me, but I made a script that allows you to easiy create and use pbuilders[[BR]] zakame: just to add: you'd want to look into /usr/lib/pbuilder/pbuilder-satisfydepends to be able to get the depencies for your package prior to building ;)[[BR]] !LaserJock: I'll email the launchpad-users list with a URL later[[BR]] stdin: There a guide to create/use pbuilder on the wiki -> https://wiki.ubuntu.com/PbuilderHowto[[BR]] !LaserJock: in any case you can have multiple pbuilders[[BR]] !LaserJock: one for each Ubuntu release for example[[BR]] !LaserJock: so you can be running Feisty and build Gutsy .debs[[BR]] !LaserJock: I would highly recommend testing *each* source package before you upload[[BR]] !LaserJock: simply as a way to minimize problems[[BR]] !LaserJock: with lots of packages in the build queues, etc. it can take a while to get a package into the PPA archive |
| Line 60: | Line 51: |
| tezem: LaserJock: for every Ubuntu release seperately? LaserJock: yes |
tezem: !LaserJock: for every Ubuntu release seperately?[[BR]] !LaserJock: yes |
| Line 63: | Line 54: |
| LaserJock: also note that the Packaging Guide is a community project, any help, proofreading, etc. is appreciated | !LaserJock: also note that the Packaging Guide is a community project, any help, proofreading, etc. is appreciated |
| Line 67: | Line 58: |
| LaserJock: ok, are there any parts that people had problems with specifially when it came to PPAs? | !LaserJock: ok, are there any parts that people had problems with specifially when it came to PPAs? |
| Line 69: | Line 60: |
| '''Question:''' damon_: what if my source code is pure python,do I need to learn all about make files and ./config etc before I can do anything useful? | '''Question:''' damon_: what if my source code is pure python,do I need to learn all about make files and ./config etc before I can do anything useful?[[BR]] '''Answer:''' !LaserJock: damon_: no. python packages often use distutils. check out a similar package from the Ubuntu archive to see how they did it. |
| Line 71: | Line 63: |
| '''Answer:''' LaserJock: damon_: no. python packages often use distutils. check out a similar package from the Ubuntu archive to see how they did it. '''Question:''' superm1: well the big thing i know i ran into with PPAs off the bat was that you need to manually put the section in. which isn't addressed in that guide. since there is no override system. '''Answer:''' cprov: superm1: but it's mentioned in PPAQuickStart. PPA don't automaticaly apply overrides, it doesn't propagate adjustments made on component/section/priority in previous uploads. '''Further discussion:''' superm1: cprov, indeed, but i think people might have needed a clarification on what that meant LaserJock: I'm guessing people would find a sample debian/changelog file helpful? cprov: superm1: yes, it definitely needs a better description then. Any suggestion ? og3: samples are always good cprov: LaserJock: yes, debian/{control, changelog} samples |
'''Question:''' superm1: well the big thing i know i ran into with PPAs off the bat was that you need to manually put the section in. which isn't addressed in that guide. since there is no override system.[[BR]] '''Answer:''' cprov: superm1: but it's mentioned in PPAQuickStart. PPA don't automaticaly apply overrides, it doesn't propagate adjustments made on component/section/priority in previous uploads.[[BR]] '''Further discussion:'''[[BR]] superm1: cprov, indeed, but i think people might have needed a clarification on what that meant[[BR]] !LaserJock: I'm guessing people would find a sample debian/changelog file helpful?[[BR]] cprov: superm1: yes, it definitely needs a better description then. Any suggestion ?[[BR]] og3: samples are always good[[BR]] cprov: !LaserJock: yes, debian/{control, changelog} samples[[BR]] |
| Line 83: | Line 73: |
| '''Question:''' vinze: So is it also possible to package e.g. GTK themes? '''Answer:''' LaserJock: it's possible to package basically anything. |
'''Question:''' vinze: So is it also possible to package e.g. GTK themes?[[BR]] '''Answer:''' !LaserJock: it's possible to package basically anything. |
| Line 86: | Line 76: |
| '''Question:''' laga: what has caught me a few times already: the time it takes between the upload and the availability of the source packages at least. i uploaded a package to gutsy and the same package to feisty, with the orig.tar.gz this time. the second upload was reject because the orig.tar.gz was not in the archive yet. xhaker: cprov, LaserJock: as laga pointed out, ppa requires you to upload the orig.tar.gz . Is there any plans to make ppa able to find the corresponding orig.tar.gz when it is somewhere in ubuntu. |
'''Question:''' laga: what has caught me a few times already: the time it takes between the upload and the availability of the source packages at least. i uploaded a package to gutsy and the same package to feisty, with the orig.tar.gz this time. the second upload was reject because the orig.tar.gz was not in the archive yet.[[BR]] xhaker: cprov, !LaserJock: as laga pointed out, ppa requires you to upload the orig.tar.gz . Is there any plans to make ppa able to find the corresponding orig.tar.gz when it is somewhere in ubuntu.[[BR]] |
| Line 95: | Line 85: |
| '''Question:''' laga: cprov: does it also allow users to rebuild completed builds? '''Answer:''' cprov: laga: no, only failed builds. Once a build is completed it gets published in the archive, so a 'rebuild' as this point would be a bin-NMU which is not allowed in ppas '''Further discussion:''' geser: laga: that wouldn't be wise as this could create debs with the same name (and version) but different dependencies |
'''Question:''' laga: cprov: does it also allow users to rebuild completed builds?[[BR]] '''Answer:''' cprov: laga: no, only failed builds. Once a build is completed it gets published in the archive, so a 'rebuild' as this point would be a bin-NMU which is not allowed in ppas[[BR]] '''Further discussion:''' geser: laga: that wouldn't be wise as this could create debs with the same name (and version) but different dependencies[[BR]] |
| Line 100: | Line 90: |
| cprov: the 'retry' link is presented for PPA owners on the left-top portlet in the build page | cprov: the 'retry' link is presented for PPA owners on the left-top portlet in the build page[[BR]] |
| Line 103: | Line 93: |
| laga: tbh, i hadn't noticed it until i was told it was there | laga: tbh, i hadn't noticed it until i was told it was there[[BR]] |
| Line 106: | Line 96: |
| '''Question:''' DaveMorris: I didn't know before, but it's easy once your told, but how do you reupload the source file, the same as before? | '''Question:''' DaveMorris: I didn't know before, but it's easy once your told, but how do you reupload the source file, the same as before?[[BR]] |
| Line 109: | Line 99: |
| DaveMorris: my email's did't have direct links to rebuild cprov: DaveMorris: the link points to the "build page" |
DaveMorris: my email's did't have direct links to rebuild[[BR]] cprov: DaveMorris: the link points to the "build page"[[BR]] |
| Line 115: | Line 105: |
| '''Question:''' LaserJock: cprov: if a build fails do we upload with the same versioning or do we need to bump? '''Answer:''' cprov: LaserJock: same version would be reject ;) uploads have to use higher versions always |
'''Question:''' !LaserJock: cprov: if a build fails do we upload with the same versioning or do we need to bump?[[BR]] '''Answer:''' cprov: !LaserJock: same version would be reject ;) uploads have to use higher versions always |
| Line 118: | Line 108: |
| '''Question:''' DaveMorris: won't a revison bump make it appear as a new build though, rather than rebuilding the previous | '''Question:''' DaveMorris: won't a revison bump make it appear as a new build though, rather than rebuilding the previous[[BR]] |
| Line 121: | Line 111: |
| '''Question:''' Derevko: old packages versions are marked as "PendingRemoval", when they will be removed? | '''Question:''' Derevko: old packages versions are marked as "PendingRemoval", when they will be removed?[[BR]] |
| Line 127: | Line 117: |
| cprov: Ogre-model is a mechanism to force build-dependencies to be in the same or lower components cprov: i.e., source in main can only build-depend on binaries in main, source in universe can build-depend on binaires in main, restricted, universe |
cprov: Ogre-model is a mechanism to force build-dependencies to be in the same or lower components[[BR]] cprov: i.e., source in main can only build-depend on binaries in main, source in universe can build-depend on binaires in main, restricted, universe[[BR]] |
| Line 132: | Line 122: |
| '''Question:''' mrevell: Hobbsee suggested that "ogre model" is a confusing term. Would you agree? '''Answer:''' cprov: mrevell: we can think about another name, but that's the term used in debian and ubuntu. '''Further discussion:''' Hobbsee: cprov: if it's the term used in debian and ubuntu, how come most of the MOTU's dont recognise it? superm1: Hobbsee, because its something that we normally wouldn't be exposed to since there is an override system on the archive? cprov: Hobbsee: dunno, I didn't know it in debian either, but it's being referred like that since I implemented it two years ago Hobbsee: cprov: the highups may know about it. Hobbsee: superm1: depends if you ever upload to main. if you puload to main, even in ubuntu, you'll get depwaits if you build-dep on universe packages. cprov: Hobbsee: and superm1 is right, with auto-overrides uploads almost never notice it cprov: Hobbsee: we very rarely have uploads to main in ubuntu, they usually get promoted/overridden from universe Hobbsee: cprov: sure, but if you upload a newer version fo what's already there, it'll land in main Hobbsee: (if the original was in main) cprov: Hobbsee: yes, even if the Section is "universe/<section>", that's auto-override fault. |
'''Question:''' mrevell: Hobbsee suggested that "ogre model" is a confusing term. Would you agree?[[BR]] '''Answer:''' cprov: mrevell: we can think about another name, but that's the term used in debian and ubuntu.[[BR]] '''Further discussion:''' [[BR]] Hobbsee: cprov: if it's the term used in debian and ubuntu, how come most of the MOTU's dont recognise it?[[BR]] superm1: Hobbsee, because its something that we normally wouldn't be exposed to since there is an override system on the archive?[[BR]] cprov: Hobbsee: dunno, I didn't know it in debian either, but it's being referred like that since I implemented it two years ago[[BR]] Hobbsee: cprov: the highups may know about it.[[BR]] Hobbsee: superm1: depends if you ever upload to main. if you puload to main, even in ubuntu, you'll get depwaits if you build-dep on universe packages.[[BR]] cprov: Hobbsee: and superm1 is right, with auto-overrides uploads almost never notice it[[BR]] cprov: Hobbsee: we very rarely have uploads to main in ubuntu, they usually get promoted/overridden from universe[[BR]] Hobbsee: cprov: sure, but if you upload a newer version fo what's already there, it'll land in main[[BR]] Hobbsee: (if the original was in main)[[BR]] cprov: Hobbsee: yes, even if the Section is "universe/<section>", that's auto-override fault.[[BR]] |
| Line 147: | Line 137: |
| '''Question:''' gnomefreak: ppa is no longer beta right? | '''Question:''' gnomefreak: ppa is no longer beta right?[[BR]] |
| Line 150: | Line 140: |
| mrevell: Great, thanks very much both to cprov and LaserJock, and to everyone for coming! PLease post further questions to the wonderful launchpad-users list | mrevell: Great, thanks very much both to cprov and !LaserJock, and to everyone for coming! PLease post further questions to the wonderful launchpad-users list |
Questions are left in context, unless they appear in a mass Q&A section of the session.
Basics of Ubuntu packaging
Led by: Jordan Mantha - LaserJock - MOTU team
LaserJock: ok, so we don't have time to launch into a big session on packagingBR LaserJock: but there are some basics that are useful when doing PPAsBR LaserJock: so first off, what does PPA accept?BR LaserJock: it accepts *source* packagesBR LaserJock: so you don't want to upload .debs
LaserJock: anybody actually read the Ubuntu Packaging Guide?BR LaserJock: 
Various people say they have.
LaserJock: Ok, so I wanted to say that remember that we deal with source packages, that is .dsc, .diff.gz, and .orig.tar.gz normally
LaserJock: now, to start with you might find it easiest to take an existing Ubuntu packageBR LaserJock: you can either apt-get source <packagename>BR LaserJock: and note that you shouldn't do that with sudoBR LaserJock: or you can get the files from Launchpad or archive.ubuntu.comBR LaserJock: you can then mess around in the unpacked source package ( dpkg-source -x <package>.dsc if it isn't unpacked already) LaserJock: and to rebuild it you can do debuild -S (which is a wrapper around dpkg-buildpackage -S -rfakeroot)BRBR LaserJock: if you need to include the .orig.tar.gz in the upload, like the first time you have that .orig.tar.gz in your PPABR LaserJock: then add -sa , debuild -S -saBR LaserJock: the packages need to be signed with your gpg key (the same one that's on Launchpad)BR LaserJock: so make sure that the email address in your changelog entry is the same as in your gpg keyBR LaserJock: I would strongly suggest that people test their source package by building them locally into .debsBR LaserJock: a good way to do that is with pbuilderBR
superm1: its much more time consuming and annoying to let the PPA fail to build than it is to do it locallyBR DaveMorris: for signing you can also use debsign -k<key-id> <program>_source.changes
LaserJock: superm1: exactlyBR LaserJock: pbuilder creates a minimal Ubuntu envioronment in a chroot
LaserJock: and and it provides a "clean room" because all the changes are dropped at then end of each sessionBR LaserJock: I don't seem to have it on me, but I made a script that allows you to easiy create and use pbuildersBR zakame: just to add: you'd want to look into /usr/lib/pbuilder/pbuilder-satisfydepends to be able to get the depencies for your package prior to building ;)BR LaserJock: I'll email the launchpad-users list with a URL laterBR stdin: There a guide to create/use pbuilder on the wiki -> https://wiki.ubuntu.com/PbuilderHowto[[BR]] LaserJock: in any case you can have multiple pbuildersBR LaserJock: one for each Ubuntu release for exampleBR LaserJock: so you can be running Feisty and build Gutsy .debsBR LaserJock: I would highly recommend testing *each* source package before you uploadBR LaserJock: simply as a way to minimize problemsBR LaserJock: with lots of packages in the build queues, etc. it can take a while to get a package into the PPA archive
tezem: LaserJock: for every Ubuntu release seperately?BR LaserJock: yes
LaserJock: also note that the Packaging Guide is a community project, any help, proofreading, etc. is appreciated
Questions
LaserJock: ok, are there any parts that people had problems with specifially when it came to PPAs?
Question: damon_: what if my source code is pure python,do I need to learn all about make files and ./config etc before I can do anything useful?BR Answer: LaserJock: damon_: no. python packages often use distutils. check out a similar package from the Ubuntu archive to see how they did it.
Question: superm1: well the big thing i know i ran into with PPAs off the bat was that you need to manually put the section in. which isn't addressed in that guide. since there is no override system.BR Answer: cprov: superm1: but it's mentioned in PPAQuickStart. PPA don't automaticaly apply overrides, it doesn't propagate adjustments made on component/section/priority in previous uploads.BR Further discussion:BR superm1: cprov, indeed, but i think people might have needed a clarification on what that meantBR LaserJock: I'm guessing people would find a sample debian/changelog file helpful?BR cprov: superm1: yes, it definitely needs a better description then. Any suggestion ?BR og3: samples are always goodBR cprov: LaserJock: yes, debian/{control, changelog} samplesBR cprov: changelog -> "bar (1.0-21) gutsy; urgency=low" and control -> "Section: universe/web" are the important bits, IMHO
Question: vinze: So is it also possible to package e.g. GTK themes?BR Answer: LaserJock: it's possible to package basically anything.
Question: laga: what has caught me a few times already: the time it takes between the upload and the availability of the source packages at least. i uploaded a package to gutsy and the same package to feisty, with the orig.tar.gz this time. the second upload was reject because the orig.tar.gz was not in the archive yet.BR xhaker: cprov, LaserJock: as laga pointed out, ppa requires you to upload the orig.tar.gz . Is there any plans to make ppa able to find the corresponding orig.tar.gz when it is somewhere in ubuntu.BR Answer: cprov: xhaker: allowing file lookups in ubuntu archive would be helpful, we are investigating the implications in the archive, let me find the specific bug
Basics of PPA features
Led by: Celso Providelo - cprov - Launchpad team
cprov: ok, PPA UI allow users to 'retry' failed builds
Question: laga: cprov: does it also allow users to rebuild completed builds?BR Answer: cprov: laga: no, only failed builds. Once a build is completed it gets published in the archive, so a 'rebuild' as this point would be a bin-NMU which is not allowed in ppasBR Further discussion: geser: laga: that wouldn't be wise as this could create debs with the same name (and version) but different dependenciesBR cprov: laga: if you want to rebuild a completed build you have to upload a new version of the source in question
cprov: the 'retry' link is presented for PPA owners on the left-top portlet in the build pageBR cprov: has everyone noticed it ? is it clear to get in the build page ?
laga: tbh, i hadn't noticed it until i was told it was thereBR cprov: laga: but you do receive a build-failure-notification email with direct links, no ?
Question: DaveMorris: I didn't know before, but it's easy once your told, but how do you reupload the source file, the same as before?BR Answer: cprov: DaveMorris: yes, just follow the established procedure
DaveMorris: my email's did't have direct links to rebuildBR cprov: DaveMorris: the link points to the "build page"BR DaveMorris: yeah that one is there,
cprov: where you can find out if it's a temporary failure (which could be sorted by a rebuild) or if it's permanent, like a broken source or a ogre-model failure
Question: LaserJock: cprov: if a build fails do we upload with the same versioning or do we need to bump?BR Answer: cprov: LaserJock: same version would be reject 
uploads have to use higher versions always
Question: DaveMorris: won't a revison bump make it appear as a new build though, rather than rebuilding the previousBR Answer: cprov: DaveMorris: yes, new source versions will generate new builds and that's what you want. The old build records will remain as "failed".
Question: Derevko: old packages versions are marked as "PendingRemoval", when they will be removed?BR Answer: cprov: Derevko: backend will be added in the next LP release cycle (in two weeks)
What is the ogre model?
Led by: Celso Providelo - cprov - Launchpad team
cprov: Ogre-model is a mechanism to force build-dependencies to be in the same or lower componentsBR cprov: i.e., source in main can only build-depend on binaries in main, source in universe can build-depend on binaires in main, restricted, universeBR cprov: currently, ogre-model failures can only be solved by another source upload
Question: mrevell: Hobbsee suggested that "ogre model" is a confusing term. Would you agree?BR Answer: cprov: mrevell: we can think about another name, but that's the term used in debian and ubuntu.BR Further discussion: BR Hobbsee: cprov: if it's the term used in debian and ubuntu, how come most of the MOTU's dont recognise it?BR superm1: Hobbsee, because its something that we normally wouldn't be exposed to since there is an override system on the archive?BR cprov: Hobbsee: dunno, I didn't know it in debian either, but it's being referred like that since I implemented it two years agoBR Hobbsee: cprov: the highups may know about it.BR Hobbsee: superm1: depends if you ever upload to main. if you puload to main, even in ubuntu, you'll get depwaits if you build-dep on universe packages.BR cprov: Hobbsee: and superm1 is right, with auto-overrides uploads almost never notice itBR cprov: Hobbsee: we very rarely have uploads to main in ubuntu, they usually get promoted/overridden from universeBR Hobbsee: cprov: sure, but if you upload a newer version fo what's already there, it'll land in mainBR Hobbsee: (if the original was in main)BR cprov: Hobbsee: yes, even if the Section is "universe/<section>", that's auto-override fault.BR cprov: Hobbsee: once we have UI to allow manual overrides in PPAs we can enable auto-overrides too
Question: gnomefreak: ppa is no longer beta right?BR Answer: mrevell: gnomefreak: PPA is in beta but on Launchpad's production site
mrevell: Great, thanks very much both to cprov and LaserJock, and to everyone for coming! PLease post further questions to the wonderful launchpad-users list
Next session
Further PPA introductory and Q&A sessions will be held, including as part of Ubuntu Open Week in October. Please subscribe to the [:PPA101:PPA and Ubuntu Packaging 101] wiki page to get updates.
