Re: Moving udd away from sqlite
On Thu, Jun 14, 2012 at 06:23:24PM -0400, James Westby wrote: We're interested in moving our deployment of udd away from sqlite to postgres, and we're interested in doing the same thing for the package importer deployment. There are two main reasons for this: 1) that we were asked to by canonical sysadmins, and 2) because it's the right thing to do. udd has evolved past the point where sqlite is a good choice for the db. It's not purely about cleanliness though. Currently udd will wait up to 30s to acquire a sqlite lock, and I believe that it frequently uses a significant portion of that time. Therefore moving to postgres with its improved locking would improve the performance of the importer (though I have no numbers to show that it would significantly affect latency or throughput.) As you know, we've tried a first step towards this previously. We ported the db access to storm, so that we could replace the db underneath, taking advantage of storm's support for multiple database types. That didn't go so well, as after a few hours/days of usage it would deadlock due to sqlite locking. That's one of the reasons why sqlite isn't a great choice, as it shows we are currently operating close to the threshold that sqlite allows. After lots of head-scratching I believe I've worked out why changing to storm made this happen when the underlying db was the same. Storm forces sqlite to operate at a higher isolation level, so udd was taking locks more frequently or holding them for longer, leading to more contention and eventually the deadlock. I haven't proven that it would fix the deadlock issue, just that reduces the incidence of database is locked errors on a test instance rigged to stress the db even more. As I see it we have N options: 1) Deploy the same code as last time (with some fixes for bugs that Max spotted that were unrelated to locking.) Live with the degraded performance while we migrate to postgres. 2) Deploy the same code with a change to stop storm forcing the isolation level. This may fix the deadlock issues, but we won't be sure. It's also not clear that storm will function correctly in that condition. 3) Deploy the storm code, but migrate the db to postgres at the same time. It introduces more changes at the same time so is riskier, but we're fairly sure we won't see the locking issues with postgres. I'm pretty sure that we can still rollback from this fairly easily, as we can just go back to the sqlite dbs and the importer will pick up from where it left off, duplicating some work. 4) Leave the package importer on sqlite and do something else for our instance (fork basically) Are there any others? What do you think of these options? We'd like to avoid option 4 if possible. Moving UDD to postgres would be a good idea in general. I agree it would be nice to avoid 4 - UDD wouldn't benefit from your changes to move to postgres *and* we would end up with two codebases and the problems associated with that. (2) seems like a gamble, perhaps even more so than (3) and it gets us less far. (1) is probably more work, since you're doing two migrations rather than one. It would be nice to have a bit more hands on deck if there is another attempt to migrate to storm, in case any problems come up. Cheers, Jelmer signature.asc Description: Digital signature -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Improved quilt patch handling
On Thu, Jan 26, 2012 at 12:30:54PM +, Colin Watson wrote: On Thu, Jan 26, 2012 at 01:02:43PM +0100, Jelmer Vernooij wrote: bzr-builddeb 2.8.1 has just landed on Debian Sid and Ubuntu Precise. This version contains some of my improvements from late last year for the handling of quilt patches in packaging branches. Most of these improvements depend on bzr 2.5 beta 5, which is also in Sid/Precise. This sounds great, thank you! Note, however, that the latest version of bzr-builddeb failed to build in precise, so this won't be usable until somebody fixes that: https://launchpadlibrarian.net/91021351/buildlog_ubuntu-precise-i386.bzr-builddeb_2.8.2_FAILEDTOBUILD.txt.gz You may not have seen this due to: https://bugs.launchpad.net/launchpad/+bug/862251 I indeed hadn't, thanks! I'll keep a closer eye on builds from my sync requests and will look into this issue. Furthermore, you can now specify whether you would like bzr to automatically apply all patches for stored data and whether you would like to automatically have them applied in your working tree by setting 'quilt-tree-policy' and 'quilt-commit-policy' to either 'applied' or 'unapplied'. This means that you can have the patches unapplied in the repository, but automatically have them applied upon checkout or update. Are these options per-tree? We surely don't want branches flip-flopping between policies depending on people's local bzr-builddeb configuration. They're in the bzr-builddeb configuration, which can either be in the tree (debian/bzr-builddeb.conf) or in the users' local configuration. The tree configuration takes precedence over the home dir configuration. The value of quilt-tree-policy isn't really relevant for anybody other than the user themselves. It only affects what is in the working tree, and not what ends up in a branch. Once bzr-builddeb's code is updated to use the new config stack infrastructure in bzr 2.5, it should be easy to make quilt-commit-policy entirely tree-specific. Cheers, Jelmer signature.asc Description: Digital signature -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: bzr merge-upstream: why delete and add the same unchanged file?
Am 29/03/12 05:14, schrieb James Westby: On Tue, 20 Mar 2012 18:06:52 -0300, Andreas Hasenack andr...@canonical.com wrote: I understand they are isolated and separated branches. I thought supporting a bzr branch for the upstream branch was more of a convenience and that merge-upstream would actually just export it to a temporary tarball and then move on like if I had given it a tarball to work with, but I see now that's not the case. Yeah, there is some old code in bzr-builddeb to do that, but I've forgotten how to activate it now :-) I think I'm missing some context - are you talking about running bzr merge-upstream branch ? That should still work. Cheers, Jelmer signature.asc Description: OpenPGP digital signature -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: bzr merge-upstream: why delete and add the same unchanged file?
Am 29/03/12 16:02, schrieb James Westby: On Thu, 29 Mar 2012 12:21:41 +0200, Jelmer Vernooij jel...@canonical.com wrote: Am 29/03/12 05:14, schrieb James Westby: On Tue, 20 Mar 2012 18:06:52 -0300, Andreas Hasenack andr...@canonical.com wrote: I understand they are isolated and separated branches. I thought supporting a bzr branch for the upstream branch was more of a convenience and that merge-upstream would actually just export it to a temporary tarball and then move on like if I had given it a tarball to work with, but I see now that's not the case. Yeah, there is some old code in bzr-builddeb to do that, but I've forgotten how to activate it now :-) I think I'm missing some context - are you talking about running bzr merge-upstream branch ? That should still work. That will merge in the branch as well as export the tarball right? Yeah. I think Andreas was asking about a way to just export the tarball and use it in merge-upstream without also merging the branch. Aha. I guess you could always use something like this: bzr export -d upstream-branch foo-0.1.tar.gz bzr merge-upsteam foo-0.1.tar.gz Cheers, Jelmer signature.asc Description: OpenPGP digital signature -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: problem with recipe build
On 03/05/2012 03:37 PM, Scott Moser wrote:
On Sat, 3 Mar 2012, Jelmer Vernooij wrote:
On Fri, 2012-03-02 at 22:02 -0500, Scott Moser wrote:
Which seems sane to me. The upstream source doesn't have tags named
'upstream-version', but only 'release-version'.
Help?
[...]
bzr: ERROR: Unable to find the upstream source. Import it as tag
upstream-0.9.4+r4177 or build with --allow-fallback-to-native.
Your version number is saying this is a non-native package, which
requires an upstream tarball to build against.
Well, its not a native package, so it makes sense (to me) that the
version number would reflect that.
Non-native packages require a .orig.tar.gz. bzr-builder tries to
retrieve the contents of that tarball by taking the contents of the tree
at that particular tag.
That does make sense. I just was expecting that the daily build code for
a non-native version string would essentially do:
$ bzr branch $UPSTREAM_BRANCH upstream
$ ( cd upstream bzr export \
--root ${PKG_NAME}-${UPSTREAM_VERSION_PART} \
../${PKG_NAME}_${UPSTREAM_VERSION_PART}.orig.tar.gz )
Where UPSTREAM_VERSION_PART in this case would be '0.9.4+r4177'.
And the error message does suggest the right path, but it just seemed
wrong.
The recipe doesn't know the upstream branch, so it doesn't have a way to
do this. It is just a set of operations to combine branches, none of
them really have any special properties.
I did verify that '--allow-fallback-to-native' worked, but it is just
confusing to me, as this is clearly not a native package, and somehow the
recipe above works, and works on launchpad.
This makes sense, as Launchpad has --allow-fallback-to-native enabled by
default.
That makes sense as to why it builds.
Is the following basic form for an upstream build sane:
| # bzr-builder format 0.3 deb-version
| # 2.0.0~bzr{revno}~{revno:packaging}-0ubuntu2
| lp:euca2ools
| nest-part packaging lp:~smoser/ubuntu/oneiric/euca2ools/upstream-pkg debian
debian
Yep, that makes sense. I would generally put ~{revno:packaging} after
the debian revision though, as that's what it relates to.
You can also use {debupstream} to extract the upstream version string
from the packaging branch. That way you don't have to update the recipe
each time there is a new upstream version.
E.g.:
{debupstream}~bzr{revno}-0ubuntu2~bzr{revno:packaging}
Hope this helps.
Cheers,
Jelmer
--
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: UDD breakdown when building orig.tar.gz from upstream VCS
Hi Barry! On Wed, Feb 15, 2012 at 08:21:37AM -0500, Barry Warsaw wrote: I just want to put this out there for the historical record. I think this is a rare enough use case that UDD doesn't need to address, certainly not any time soon, if ever. OTOH, maybe there's an easy workaround. I was working on an NBS for the fgfs-atlas package (LP: #903225). The solution was straightforward enough: upstream had all the necessary fixes in their CVS repository, but hadn't done a release in a long time. I twiddled the packaging to build an orig.tar.gz from CVS, and the googlez helped find some good general packaging information on how to do this. Unfortunately, UDD is essentially useless here. The problem is that after creating the tarball from CVS, `bzr bd -S` can't be used because dpkg-source will complain too much about deltas between the tarball and the source tree. It'll warn about a lot of stuff, but then fail with some unrepresentable changes to source. How did you update the upstream version number in debian/changelog? I worked around this by unpacking the new orig.tar.gz and `cp -a` the debian/ directory from the precise version of the package (with my changes) over into the unpacked tarball. After a few rounds of tweaking, and using `debuild -S -sa`, I had a debian/ that built locally, so I uploaded it and will let the importer (hopefully) sort out the mess. I still did all my changes to debian/ in a source branch though, because that made it easier to get a diff for the linked Debian bug. Is there's a magical udd switch or config setting that would have helped me keep all the changes in the source branch? It seems like this is somewhat similar to the merge-upstream issue when upstream has a rather large released tarball delta. bzr merge-upstream should help here. You can pass it a tarball and a version. Of course, these will have to be different than the previous release (since it's a new upstream version). In your case, I would imagine something like: $ cvs export -d :pserver:... fgfs-atlas-20120209.tar.gz $ cd packaging-branch $ bzr merge-upstream --version 0.3+cvs20120209 ~/fgfs-atlas-20120209.tar.gz This will import the pristine tar data into the packaging branch as a new revision, merge the changes into the packaging branch and add a new changelog entry 0.3+cvs20120209-0ubuntu1. Cheers, Jelmer signature.asc Description: Digital signature -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: xz tar imports failing?
On Wed, Feb 01, 2012 at 08:40:11AM +0100, Vincent Ladeuil wrote: Martin Pool m...@sourcefrog.net writes: I haven't dug into whether these are new, or whether there is already a bug for them, but they do seem to be new. I see https://bugs.launchpad.net/udd/+bug/553668 about supporting xz in bzr-builddeb: does that perhaps need to be deployed on Jubany? bzr-buildeb 2.8.2 is already deployed on jubany. These failures seem to be fallouts from deploying a more recent pristine-tar instead but that's just a gut feeling and I haven't investigated yet. There are also some 'PristineTarDeltaTooLarge' failures where pristine-tar cannot find 'compress' (seriously ???). Indeed ncompress is not installed on jubany (and probably never was) which seems a bit surprising. Newer versions of pristine-tar have become a fair bit stricter. If they're not able to figure out the compression method, they fall back to storing the entire compressed file. There is now a cap on the size of the delta that is stored - so that it won't generate a 500Mb delta if it can't find out the compression options for a .xz file. Cheers, Jelmer signature.asc Description: Digital signature -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Improved quilt patch handling
bzr-builddeb 2.8.1 has just landed on Debian Sid and Ubuntu Precise. This version contains some of my improvements from late last year for the handling of quilt patches in packaging branches. Most of these improvements depend on bzr 2.5 beta 5, which is also in Sid/Precise. The most relevant changes (enabled by default) are: * 'bzr merge-package' is now integrated into 'bzr merge' (it's just a hook that fires on merges involving packages) * patches are automatically unapplied in relevant trees before merges * before a commit, bzr will warn if you have some applied and some unapplied quilt patches Furthermore, you can now specify whether you would like bzr to automatically apply all patches for stored data and whether you would like to automatically have them applied in your working tree by setting 'quilt-tree-policy' and 'quilt-commit-policy' to either 'applied' or 'unapplied'. This means that you can have the patches unapplied in the repository, but automatically have them applied upon checkout or update. Setting these configuration options to an empty string causes bzr to not touch your patches during commits, checkout or update. We've done some testing of it, as well as running through a package merge involving patches with Barry, but none of us do package merges regularly. If you do run into issues or if you think there are ways we can improve the quilt handling further, please follow up to this email or file a bug report against the UDD project (https://launchpad.net/udd/+filebug). Caveats: * If there are patches to unapply for the OTHER tree, bzr will currently create a separate checkout and unapply the patches there. This may have performance consequences for big packages. The best way to prevent this is to set 'quilt-commit-policy = unapplied'. * 'bzr merge' will now fail if you are merging in a packaging tree that is lacking pristine tar metadata; I'm submitting a fix for this, but it's not in 2.8.1. * if you set 'quilt-commit-policy' and 'quilt-tree-policy' but have them set to a different value, bzr will consider the tree to have changes. To disable the automatic unapplying of patches and fall back to the previous behaviour, set the following in your builddeb configuration: 'quilt-smart-merge = False' Cheers, Jelmer -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: juju-izing udd
Am 22/12/11 08:11, schrieb Martin Pool: I'm going to try writing a Juju charm for the udd importer. W00t! (time passes) Well, I did start, but I got bogged down in debugging why my lxc provider won't boot. Details and tiny patches on the juju list (which you should join.) If someone else wants to have a go, please do. Plan: * it runs on Lucid, so we need a lucid charm Is there actually a requirement to have it run on lucid? It might be nicer to run it on oneiric, as various packages are more recent there. * the importer ought to be checked out from the branch * what other packages does it need? bzr, bzr-builder, ... * where is it going to store its working state? on ebs? Perhaps just a mount point? It seems there are a couple of providers of that already. * how does it get the secret keys to access Launchpad? Perhaps they'll fit into the configuration for the service? I'm not sure how public the data in there is though. Cheers, Jelmer signature.asc Description: OpenPGP digital signature -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Fwd: Thanks for fixing recipes...and Launchpad Recipe help please
Hi Scott, On Thu 10 Nov 2011 04:32:58 CET, Martin Pool wrote: Is there a place where I can track this? I'd like to know when it becomes available. Thanks for the full answer :) That's a good question, and maybe something that's a bit missing in lp's communication at the moment. We will reply on this thread and also put something on the Launchpad blog when it's live. This has now been deployed, so the latest tag variable should now work. Cheers, Jelmer -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Fwd: Thanks for fixing recipes...and Launchpad Recipe help please
Am Tue 15 Nov 2011 17:37:17 CET schrieb Scott Ritchie: On 11/15/2011 10:58 AM, Jelmer Vernooij wrote: Hi Scott, On Thu 10 Nov 2011 04:32:58 CET, Martin Pool wrote: Is there a place where I can track this? I'd like to know when it becomes available. Thanks for the full answer :) That's a good question, and maybe something that's a bit missing in lp's communication at the moment. We will reply on this thread and also put something on the Launchpad blog when it's live. This has now been deployed, so the latest tag variable should now work. Cheers, Jelmer If someone could update: https://help.launchpad.net/Packaging/SourceBuilds/Recipes that would be fantastic :) Done. Cheers, Jelmer -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Fwd: Thanks for fixing recipes...and Launchpad Recipe help please
Hi Scott, Martin,
On 11/10/2011 01:01 AM, Martin Pool wrote:
I don't know the answer to this off hand. Does someone else? Maybe
we can add this to the help.l.n documentation?
Martin
-- Forwarded message --
From: Scott Ritchiescottritc...@ubuntu.com
Date: 10 November 2011 06:05
Subject: Thanks for fixing recipes...and Launchpad Recipe help please
To: martin.p...@canonical.com
Hey Martin,
Thanks a ton for helping fix the daily build recipes bzr-out-of-memory
issue. Now that my daily builds are building again, I'm hoping I can
bother you with a question...
How exactly do I use Git tags in a recipe? It seems like there's
support for this, but I couldn't figure it out.
Currently my recipe looks like this:
# bzr-builder format 0.3 deb-version {debupstream}+daily-{date}
lp:wine
nest-part packaging lp:~scottritchie/wine/natty-packaging debian debian
The {debupstream} pulls the upstream version from that natty-packaging
branch I set up, but what I'd like it to use is the GIT tag from lp:wine
since I don't really have any reason to update this branch other than to
increment the version number.
1) Are git tags preserved at all in LP's BZR imports?
Yes, they're imported as regular Bazaar tags. Bazaar doesn't have
annotated tags, so any annotated tags will simply be converted into
regular tags. Tags that point at objects that are not commits (i.e.
trees) are ignored.
2) If yes, what's the equivalent of {debupstream} that I can use to
access them?
Newer versions of bzr-builder have support for the {latest-tag} variable
in deb-version, which gets replaced with the name of the most recent tag
in the branch. See also https://bugs.launchpad.net/bzr-builder/+bug/608912
This version isn't deployed on Launchpad yet; we're working on deploying
a new version at the moment.
In the mean time, you should be able to test your recipes (with
{latest-tag}) with the bzr-builder package in oneiric and precise.
Cheers,
Jelmer
--
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: bzr get-orig-source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/04/2011 12:28 PM, Robert Collins wrote: On Tue, Oct 4, 2011 at 11:10 PM, Jonathan Riddell jridd...@ubuntu.com wrote: I added a command to builddeb, bzr get-orig-source. This helps with my workflow .. Others prefer to use bzr builddeb [-- -nc] but I find all the changing directories that requires is more hassle than gain. What directory changing? I think Jonathan means that if you use -nc (no cleanup of build directory), you have to cd ../build-area/mypkg-1.0 to get to the build directory. Personally, I just use bzr bd / bzr pbd, then fixup whatever is wrong, then bzr bd again - no changing of directories involved. Cheers, Jelmer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOiuBeAAoJEACAbyvXKaRXCIEP/1r4h6AyUMJjMxvZr8I6dJ4e bN03edNQFC346dCe3Vt75mCWvEufmpE0n8N/fhmnWfZbPrIhFA8Ax78rzz52Tz4l QQUifkKgre4WOp0tUQQhQD07nqJkIq0T1ENBZk5koHjKfH6rTFuwt31xwh4G0Naf HXj6Ztcdv//ni/GZhVjgQ+4NVJ4LMPdtHYFXFDKChwdQwu8egGZatmwKpsUvF26T 4XMGezTD49Dte/iOc2MttkPD7JvV4lrxWZJ4CTOfJZdI8/VAXbwYG6i9eRwEcPMa qrFHZgZ4Eb8jJJ8NHRDcfIU+2TDe2hLHlyCq4owuCWeXY+c9VExvXCMFxvoVhli4 hkjlWUlyJch8CFQCNDskpmL1tAIKJsE+lWMgB7PB2AzNOFNK+xU/+xU194xx6zOO St8Qccuv1yqAnWcdbpZkHB0sAA+pQH09F2kusl/lrdG91zRvr6r6GQac4SrrXeo6 kYn4UdRtudYIfSJaTMaqYSOGG1NT7tOUVdh3nLVzPYCugIsjhyBAu6smcP/RpPAw yd8aQHoWvEWb95OPY2j5Digv0TE7XFmXMFffn9MonJnAEWzOKaO73O4OqZsL7HlQ NcetZxSlZcGzfjzrScoxj4x6tc2LMgyxgnvgaA0Q0SxtAQeXyX2/ioJulYfQHgbF GPe3psGyYrVlmGCVUVNw =Rn6g -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: bzr get-orig-source
On 10/04/2011 12:48 PM, Jonathan Riddell wrote: On Tue, Oct 04, 2011 at 12:30:54PM +0200, Jelmer Vernooij wrote: I think Jonathan means that if you use -nc (no cleanup of build directory), you have to cd ../build-area/mypkg-1.0 to get to the build directory. Yes, and then copy any changes to packaging back manually. I guess we could improve this workflow too - e.g. by having bzr-builddeb not chdir back after a build has failed. Though with bzr get-orig-source in place that's not really important anymore. Personally, I just use bzr bd / bzr pbd, then fixup whatever is wrong, then bzr bd again - no changing of directories involved. Using bzr builddeb assumes you can find out what is wrong just from the build logs, maybe you need to update the .symbols files, you need the build tree around for that. Also restarting the build from scratch takes a long time for large packages, e.g. Qt takes well over an hour to build each time. dpkg-gensymbols spits out a diff which I usually use to update the symbols file (after careful reviewing, of course). Fortunately, my packages (even Samba and Heimdal) build in roughly 10 minutes on my machine so I don't care that much about starting from scratch each time. What is bzr pbd? charis:~/lp% bzr alias bzr alias autobuild=dpush git+ssh://sn-devel/home/jelmer/autobuild/samba-autobuild bzr alias commit=commit --strict bzr alias pbd=bd --builder=pdebuild --buildresult /home/jelmer/buildresult Cheers, Jelmer -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: bzr get-orig-source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/04/2011 04:01 PM, Barry Warsaw wrote: On Oct 04, 2011, at 12:30 PM, Jelmer Vernooij wrote: I think Jonathan means that if you use -nc (no cleanup of build directory), you have to cd ../build-area/mypkg-1.0 to get to the build directory. Since I usually use sbuild or pbuilder directly to build the binary package, I `cd ..` to run the build (or more usually, open a different shell). Still, I think `bzr get-orig-source` is a nice addition. Yeah, I also think it's a useful addition. Personally, I just use bzr bd / bzr pbd, then fixup whatever is wrong, then bzr bd again - no changing of directories involved. % bzr pbd --help bzr: ERROR: unknown command pbd It's an alias for running pdebuild, see my other email. Cheers, Jelmer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOixMCAAoJEACAbyvXKaRXOSsQAJm5saywvBDXs+y5pqfYha0x WETmjVQvqmNtQ15NQ3aDSY6HCwsxhK9FjR5vJm+0ENrilymUn+QijPgp5M4fImIA G4qH+Vn5wAoXqHCuYxwp6YI/IkFmc3xim54oGWmcsHkQzFdHTaG/h5MXQarMM9iH SCxDRPk58Km04ZOCHbe3QkKilu96oJAhujv1JweE9/I2DbF5qeqyqrtVrWIsL10R M/X7DUuuQmFJi2liZY3w5399XSihfTNyBJ5s9KY0zbSrKQYiYmToH/ogRp1ggHpG nFpv0oLnVi5zNC7YqjVGlH2L5EEnTNVAB2WNBZDnAZGdMH570Yhn3oFButVOrVeq wD/g1miyky9gSFK55HdZAj/4AWINK1NLZwCYaMycqKtPUCuV/p5tOOhZlC1OPDqX 5iR5ZIwsMvLjMDYVZ5jh6Y0xiymHWxGRtIyRavz2Ou8SxmhluoFjchL57AF5kV2M /Xo+gGxHbYoIbZQe5roMbO4zuWmcvtETT5c1oyaYnno0QVoZ1DdzFNEPuu3Jg43s 8AsjbN8NSYKDhmW3hIdejI0bLwMlhLVe8t5Kqex2yUiKIiiUTz6e1fZumQCEDtPL lmg+qgtdFYJjOB3N7+rmtuInW+nL4u4IqSU/lbEYdcwYyivB9hhmdYZBVhXdeNMQ XTaKCggowwFatRLEmnIv =UZM6 -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: UDD up-to-date
On Tue 27 Sep 2011 11:34:57 AM CEST, Martin Pool wrote: Thanks for posting the progress update. mgz, jam and vila will be at UDS-P: we need to propose some session topics: at the moment I'm thinking of one about BuildFromBranchIntoArchive, one about quilt merging, one about bzr/lp/udd in general. Any other ideas? I think BuildFromBranchIntoArchive is pretty well defined at this point. It might be good to have another session about BuildFromBranchIntoPrimary, though I'm not sure if there's much new to learn there. Cheers, Jelmer -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: ubuntu: branches lacking history with upstream branches
Hi Barry, On 09/22/2011 05:14 PM, Barry Warsaw wrote: On Sep 22, 2011, at 07:08 PM, Martin Pool wrote: lp:indicator-power is one example, and the desktop team actually maintain an unofficial packaging branch that does share history: lp:~ubuntu-desktop/indicator-power/ubuntu At the moment, gtimelog is another. What I've done recently is to first do a release from trunk, i.e. lp:gtimelog, push the new tarball to Launchpad and PyPI, then in ubuntu:gtimelog, I do `bzr merge-upstream` and build the Ubuntu release from that. It's not perfect, but it works. One problem seemed to be a weird lag in the debian/watch url between what I was seeing in my browser, where the 0.7.0 release was visible, but uscan took a while before it saw the new tarball. I didn't quite understand that, but wasn't in a desperate hurry to push the new Ubuntu version anyway, so I just waited a bit. It would certainly be more useful to have ubuntu:gtimelog share history with lp:gtimelog, but I think it would be best in that case if ubuntu:gtimelog only version controlled the debian directory. Why would this be better than actually having all of the history there? It seems to me like that would mostly just add extra overhead because you have to fetch two branches rather than one. I use bzr merge-upstream to merge new upstream versions into the packaging branches of bzr, samba4, heimdal and various other projects . See for example the ubuntu:bzr branch (although that seems to be out of date at the moment). This would more closely mirror how packages are managed in Debian. However, I'd *still* want `bzr branch ubuntu:gtimelog` to give me the full source. I wonder if nested branches are the answer here. One trick would be that I'd only want the source from the upstream branch based on a particular tag. E.g. I might have unreleased changes in lp:gtimelog, but I want to base ubuntu:gtimelog (and the source package built from it) to work off the 0.7.0 tag or some such. The practice of versioning debian/ only mostly seems to happen if the VCS used is SVN. Even then, there are a couple of teams that import the full upstream source into SVN. I think I've seen more Git repositories that include the full source than repositories that don't. Cheers, Jelmer -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Our biweekly meetings
Hi Barry, On 09/06/2011 02:57 PM, Barry Warsaw wrote: At our last meeting, we talked about starting up the UDD bi-weekly meetings again this week (Wednesday Sept 7 @ 1100 UTC). However, both Martin and I are pretty tired of the old format, so let's think about how we can restructure the meeting to be most effective for everyone. If we really don't think we *need* them anymore, that's fine too. What would *you* like to get out of these meetings? The main thing I appreciated about the meetings was hearing what other people had done towards UDD. I think a part of this is also that UDD as a project doesn't really have releases - and no really visible changelog. So despite a lot of things getting done, we normally wouldn't hear about them. Another thing that was occasionally useful was discussions about particular problems, like what to do about the project branch and packaging branch for a native package. The mailing list seems to work reasonably well for that sort of discussion too though, when it happens to come up. Cheers, Jelmer -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: building the package to alter the packaging
On Tue, 2011-07-26 at 12:05 +0100, Jonathan Riddell wrote: In traditional packaging I would often build the package with debuild then make some changes based on the compile (edit .install files, add .symbols files etc) then check it works with debuild -nc then tidy up with debuild -S. Is there an equivalent in UDD with bzr-builddeb? If I run bzr builddeb it will finish the compile and clean the build tree so I don't get a chance to look at the resulting tree. One messy way is to alter the changelog so it doesn't have my e-mail in it then it will complain that it can't sign the result and keep the build tree around. I can then edit that, use debuild -nc, clean it with debuild -S and copy the result back, but it's not very elegant. My guess is that something like bzr builddeb -- -nc will leave the build directory in ../build-area around for inspection. You can then manually remove it afterwards. Cheers, Jelmer signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: patches
On Mon, 2011-07-25 at 16:28 +0100, Jonathan Riddell wrote: Writing the packaging guide chapter on patching highlighted for me that patches don't always work well with UDD. http://bazaar.launchpad.net/~ubuntu-packaging-guide-team/ubuntu-packaging-guide/trunk/view/head:/patches-to-packages.rst I keep all patches unapplied for packages I maintain in Debian. This works best for the bzr-builddeb commands and doesn't cause spurious changes to e.g. the .pc directory. (line 90) What are people's favourite tactics for the .pc directory when adding a new patch? I recommeded just bzr add .pc/* but Barry says he will revert changes. (line 103) Upgrading to New Upstream Versions is ugly with patches (and that means most packages), you have to unapply all the patches, commit with them unapplied then do the upgrade. I think it would be nicer if bzr merge-upstream did the unapply for you and if it didn't need a commit. I filed https://bugs.launchpad.net/bzr-builddeb/+bug/815854 This seems to be a simpler instance of the problem of merging two branches with quilt patches (the OTHER branches simply doesn't have any patches in this case). Cheers, Jelmer -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: building the package to alter the packaging
On Tue, 2011-07-26 at 12:20 +0100, Jonathan Riddell wrote: On Tue, Jul 26, 2011 at 01:12:11PM +0200, Jelmer Vernooij wrote: My guess is that something like bzr builddeb -- -nc will leave the build directory in ../build-area around for inspection. You can then manually remove it afterwards. It does but you then have to revert to non UDD commands to finish your packaging and manually copy it back. Something like bzr bd-do would be more elegant where it puts you in a temporary shell, you can make your changes then exit to have the magically copied back. That makes sense. Perhaps this would be useful as a new option to bzr-builddeb. Or, alternatively, it would be useful to have bzr bd-do always build by default and support the current behaviour if -S was specified. This would be more consistent with the current bzr bd interface. Cheers, Jelmer signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: UDD with new upstream version
On Thu, 2011-04-14 at 15:00 -0400, Scott Kitterman wrote: I decided to try UDD again for a new upstream version that was just released. I was following the documentation here: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/NewUpstreamVersion I got to this step: bzr merge-upstream --version 1.2 http://example.org/releases/foo-1.2.tar.gz and after considering this would require me to look up the exact download address on sourceforge, decided to back up and do: apt-get source opendkim cd opendkim-2.3.1 uscan instead. I don't know if this is a documentation shortfall or it's really that much more complicated, but documenting/updating so this works easily with watch files would be a big win. the bzr-builddeb in natty can use the watch file. If you have a watch file it will use the watch file to download the upstream release. The --version argument is also optional if you have a watch file; it will default to the latest upstream version. Cheers, Jelmer signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: missed meeting
On Thu, 2011-02-24 at 10:08 -0600, John Meinel wrote: I just realized that I agreed to meet next week, but I'll be moving to The Netherlands on Sunday. As such, my timezone is going to not be very good for the evening meetings. (I believe 6pm Eastern, is Midnight Netherlands). So I should really not be voting here. The meetings have been at 10 CET here, so it's not quite as late as midnight, but it is well past the work day. Cheers, Jelmer On Thu, Feb 24, 2011 at 9:20 AM, Barry Warsaw ba...@ubuntu.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Feb 23, 2011, at 04:15 PM, John Arbash Meinel wrote: On 2/23/2011 4:01 PM, Barry Warsaw wrote: Apologies. My clock was off and I didn't notice the UDD meeting scheduled for today. Since Martin also sent his apologies (in advance ;) I guess the meeting didn't happen. In two weeks I will be traveling to Pycon and will likely not be settled in time to participate. We can either try to have one next week, or y'all can go ahead without me in two weeks time. What is your preference? -Barry Next week sounds like a good idea. Sounds good. I propose we meet on 2011-03-02, then skip the 03-09 meeting and start back up again on the regularly scheduled 03-23 meeting. Thus: 2011-03-02 meet 2011-02-23 meet I've updated the wiki pages to reflect this schedule. Cheers, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJNZnczAAoJEBJutWOnSwa/Mx4QAMH962AXHHAD8uPhg1EyxyH+ 0Le4PSZmO9aPwP66JLAY+b+7MeB/P4l+hzd41KK4TyTYeVwiC4J309fd49DQf +7E 18/ZXOKkNSrwBgtc51aMvCE +A9H3jNqRFqjhEuj0p5thSDCcP2jBI6xFG3cN4I3X vGIh2tsxa2ophUOiGiMlTkURkacWr0i8ka8t0r5s64bBRnDTIlI09stym7x5yrWY /uSEQw3cfLvEor3DvSAnXHWR6Yw7pQO6dMJnzhTlJzms2JqR7OmfweBFpUKoKobE NLTRkDFnwSr2ARsmBoL4glCkR3U0HdS/5A +RBjQnM05tPQSC8dlguQDmhnyJYNz6 XuP9Zh5vVTNMKukwZdwauovi6j3ZI3ZeMN11Xo6g0WWgQBhglCEXKHsq1omtpSJi vz3rJZtaAyxcOUQe6DDQw4RVuSNMdq66TZWX7yORPargmaYn4r8TywXnWFzxGoAf /B9s8qfDqI+o +3mN6d/J7wW7gh2yLwPCIbA8bjfUsCMSca1MxMHdsVIoDzenhrVy 7Mbr19JjolbnwUKEZX38gAQdz/T/4ZTh9vU +nijwUnsx9is5xUGBGOCAkZHOnazb Ava5ZsDWICopqAHAs8k/BFoQlPuldx6VTcEWPoJcU8gshjml1SeAejtut5SrmFzy OeAZKALhCYtn8BQI5bxV =gEmV -END PGP SIGNATURE- signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: UDD survey results
On Thu, 2010-11-18 at 11:16 -0500, James Westby wrote: Hi Martin, Thanks for running and summarising the survey, very interesting results. On Thu, 18 Nov 2010 18:23:56 +1100, Martin Pool m...@canonical.com wrote: * The patch format from bzr is awkward - I'm not sure what this means; maybe that it is not smart about debdiff stuff I believe this is that they don't like bundles. They want git format-patch/git am as the way to send patches around. I've found this myself as well. It's useful to be able to comment on individual patches in larger set of of work. Translating this to Bazaar, it would be nice to be able to send a set of bundles for easier review, e.g. for a loom or a pipeline. Cheers, Jelmer signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Improving merge-upstream
On Tue, 2010-09-28 at 10:30 -0400, James Westby wrote: After talking with a few people about it over the last few weeks, and seeing some difficulties that people face with merge-upstream, I'd like to start a discussion of what could be done to improve it. I have some ideas, but please present any others you have. 1) The obvious one, watch file intergration. We don't have to make you give the URL of the tarball if you have a watch file. This has been the intent from the first day I wrote merge-upstream, and the reason why --version is a mandatory option right now, I just haven't got around to it. I'd be more than happy to help someone implement this. The uscan part isn't too hard, you just have to run it with a certain combination of options and parse the resulting xml-like. The only difficulty is threading it in to the maze of code to deal with all the optional arguments. I'd love to clean that up and get this feature in. +1 This'd be a great feature indeed. It would be nice to implement this by using the UpstreamSource API (perhaps by extending it with some optional methods). 2) Another obvious one, fixing bugs. I've just found another incosistent delta bug, and there are probably more. Getting them fixed would make it more reliable. There may be other classes of bug to fix too. I haven't seen any of these in a while. Maybe I'm just lucky :-) Cheers, Jelmer signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Lots of conflicts when trying to merge protobuf to maverick
Hi Elliot, On Tue, 2010-06-08 at 16:46 -0400, Elliot Murphy wrote: I took a look at merge protobuf from sid just now, and was surprised to see a lot of conflicts. What is the right way to get this merging smoothly again? The differences from debian should be very minor, a single patch file and the normal stuff in changelog and control. Is this a bug in the bzr merge-package command? Thanks for your advice, full recipe below: bzr get lp:ubuntu/maverick/protobuf; cd protobuf bzr merge-package lp:debian/sid/protobuf This happens when you import from two sources with different file ids. Bazaar doesn't recognize that two files (even though they have the same path) are the same and will generate these conflicts. Cheers, Jelmer signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
parallel imports
I realize I've brought up this topic before, but I think it's becoming increasingly important because of udd and it would be nice to know what the plans are (if any?) to deal with it. Bazaar does not have a way to do parallel imports properly. If two branches use different file ids for the same file then merging between the branches will cause conflicts every time. This is an issue for example when merging from upstream into the bazaar branches created by James' package importer. E.g. recently I have tried to use Bazaar to upload a newer version of Heimdal to Debian experimental. Ideally something like this should work: bzr branch lp:debian/sid/heimdal cd heimdal bzr merge lp:heimdal dch -v 1.4.0~bzr`bzr revno lp:heimdal` New upstream snapshot. debcommit bzr bd It doesn't because of the file id conflicts in bzr merge lp:heimdal step. Are there any plans to deal with these file id conflicts in Bazaar itself, or do we rather need tools that basically rebase branches to use different file ids ? Cheers, Jelmer signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: How many Ubuntu branches share history with upstream?
On Wed, 2010-02-10 at 13:58 +, Jonathan Lange wrote: In a previous discussion about Ubuntu distributed development, someone suggested that we graph the number of Ubuntu branches that share history with upstream. I think that's a very interesting thing to graph, but I have absolutely no idea on how to get that information -- even with access to Launchpad. How could we do it? The simplest thing to check would just be to see if the first revision of the upstream branch is part of the ancestry of the packaging branches' tip. Are you going to use the database for this or are you fine with calling out to Bazaar and using the branches on disk / remote servers? Cheers, Jelmer signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: How many Ubuntu branches share history with upstream?
On Wed, 2010-02-10 at 14:10 +, Jonathan Lange wrote: On Wed, Feb 10, 2010 at 2:08 PM, Jelmer Vernooij jel...@canonical.com wrote: On Wed, 2010-02-10 at 13:58 +, Jonathan Lange wrote: In a previous discussion about Ubuntu distributed development, someone suggested that we graph the number of Ubuntu branches that share history with upstream. I think that's a very interesting thing to graph, but I have absolutely no idea on how to get that information -- even with access to Launchpad. How could we do it? The simplest thing to check would just be to see if the first revision of the upstream branch is part of the ancestry of the packaging branches' tip. Are you going to use the database for this or are you fine with calling out to Bazaar and using the branches on disk / remote servers? I'd like to use the database, since I think the other option would be grindingly slow. So checking whether a revision is part of another branches' ancestry is not really possible then, if I understand the current database scheme correctly. You should be able to detect the common ancestry in most of the cases by just checking that the first revision of the upstream branch and first revision of the packaging branch have the same revid. This won't allow you to detect the situation where the packaging branch was created first and the upstream merged into it later, but as far as I can tell that's quite rare. Something related to this that has an open bug in lp-code - it is impossible to have common ancestry between upstream and debian packaging branches at the moment because it is impossible to register mirrors / imports for packaging branches. Cheers, Jelmer signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: hottest100
On Thu, 2010-02-04 at 13:35 +, Martin Pool wrote: On 3 February 2010 22:14, Reinhard Tartler siret...@ubuntu.com wrote: Your list includes this: mplayer categorized package-bug:513282 categorized ok_upstream lp:mplayer0ok_upstream this cannot be true. mplayer makes heavy use of svn:externals which don't appear in the bazaar branch. This means that the bzr import is unusable. Thanks for pointing that out. https://code.edge.launchpad.net/~vcs-imports/mplayer/trunk does seem to be importing it happily so it's an interesting question. For historical reasons bzr-svn ignores svn:externals rather than printing an error message saying it requires nested trees as bzr-git does. Arguably, if mplayer's repo isn't usable without externals, it should be tagged nested-trees. Cheers, Jelmer signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: hottest100 (was Re: Bazaar focus for 2.1 and 2.2)
On Tue, 2010-01-26 at 05:38 -0500, Francis J. Lacoste wrote: On January 26, 2010, Martin Pool wrote: and in passing we're fixing some misregistration. At the moment the biggest problem we can't fix is that some Launchpad projects have branches but no development focus (ie default branch) and we don't have permission to change it. But we are collating that data and presumably can ask a registry admin to change them. I've asked Tom to approve canonical-bazaar membership to the Registry Administrators. That should allow you to fix a few of them yourselves. Let us know if there are still some that you can't fix. I've fixed those I can up myself, since I'm already a member of the Registry Administrators somehow. There's quite a few that seem to be owned by community members or teams but haven't actually been touched in a while. The following projects we can not update because of permissions: lp:amarok - lp:~vcs-imports/amarok/master lp:empathy - lp:~vcs-imports/empathy/master lp:brasero - lp:~vcs-imports/brasero/master lp:ekiga - lp:~vcs-imports/ekiga/git-trunk lp:evince - lp:~vcs-imports/evince/master Cheers, Jelmer signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: hottest100 (was Re: Bazaar focus for 2.1 and 2.2)
On Tue, 2010-01-26 at 11:46 +0100, Jelmer Vernooij wrote: On Tue, 2010-01-26 at 05:38 -0500, Francis J. Lacoste wrote: On January 26, 2010, Martin Pool wrote: and in passing we're fixing some misregistration. At the moment the biggest problem we can't fix is that some Launchpad projects have branches but no development focus (ie default branch) and we don't have permission to change it. But we are collating that data and presumably can ask a registry admin to change them. I've asked Tom to approve canonical-bazaar membership to the Registry Administrators. That should allow you to fix a few of them yourselves. Let us know if there are still some that you can't fix. I've fixed those I can up myself, since I'm already a member of the Registry Administrators somehow. There's quite a few that seem to be owned by community members or teams but haven't actually been touched in a while. The following projects we can not update because of permissions: lp:amarok - lp:~vcs-imports/amarok/master lp:empathy - lp:~vcs-imports/empathy/master lp:brasero - lp:~vcs-imports/brasero/master lp:ekiga - lp:~vcs-imports/ekiga/git-trunk lp:evince - lp:~vcs-imports/evince/master I've now changed these as well as the following other changes: registered lp:~vcs-imports/amarok/master registered lp:~vcs-imports/brasero/master registered lp:~vcs-imports/evince/master registered lp:~vcs-imports/evolution-exchange/master lp:evolution-exchange - lp:~vcs-imports/evolution-exchange/master lp:dpkg - lp:~vcs-imports/dpkg/master lp:f-spot - lp:~vcs-imports/f-spot/master registered lp:~vcs-imports/f-spot/master lp:file-roller - lp:~vcs-imports/file-roller/trunk registered lp:~vcs-imports/gdm/master lp:gdm - lp:~vcs-imports/gdm/master lp:gnome-applets - lp:~vcs-imports/gnome-applets/trunk registered lp:~vcs-imports/gnome-control-center/trunk lp:gnome-control-center - lp:~vcs-imports/gnome-control-center/trunk lp:gnome-games - lp:~vcs-imports/gnome-games/trunk lp:gnome-media - lp:~vcs-imports/gnome-media/trunk lp:gnome-panel - lp:~vcs-imports/gnome-panel/master lp:gnome-screensaver - lp:~vcs-imports/gnome-screensaver/git-trunk lp:gnome-system-monitor - lp:~vcs-imports/gnome-system-monitor/trunk lp:gnome-terminal - lp:~vcs-imports/gnome-terminal/trunk lp:python-gst - lp:~andrewsomething/python-gst/trunk lp:gstreamer - lp:~kiko/gstreamer/trunk lp:gvfs - lp:~vcs-imports/gvfs/trunk registered lp:~vcs-imports/hal/master lp:hal - lp:~vcs-imports/hal/master registered lp:~vcs-imports/nautilus/master lp:nautilus - lp:~vcs-imports/nautilus/master lp:network-manager - lp:~vcs-imports/network-manager/trunk lp:network-manager-applet - lp:~vcs-imports/network-manager-applet/git-master registered lp:~vcs-imports/grub/grub2-bzr lp:grub/grub2 - lp:~vcs-imports/grub/grub2-bzr registered lp:~vcs-imports/totem/master lp:totem - lp:~vcs-imports/totem/master converted lp:~vcs-imports/vim/vim7 to bzr-svn lp:vim - lp:~vcs-imports/vim/vim7 registered lp:~vcs-imports/tracker/master lp:tracker - lp:~vcs-imports/tracker/master registered lp:~vcs-imports/system-config-printer/master lp:system-config-printer - lp:~vcs-imports/system-config-printer/master registered lp:~vcs-imports/evolution/master lp:evolution - lp:~vcs-imports/evolution/master lp:evince - lp:~vcs-imports/evince/master lp:empathy - lp:~vcs-imports/empathy/master lp:amarok - lp:~vcs-imports/amarok/master lp:ekiga - lp:~vcs-imports/ekiga/git-trunk Cheers, Jelmer -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: hottest100 (was Re: Bazaar focus for 2.1 and 2.2)
On Thu, 2010-01-14 at 18:07 +1100, Andrew Bennetts wrote: Import exists but fails (even after retry): --- gnome-control-center This was a broken import - I've removed it and created it again to force it to import from scratch. gnome-power-manager I couldn't find the project on launchpad for this - where is it? Cheers, Jelmer signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: hottest100 (was Re: Bazaar focus for 2.1 and 2.2)
On Fri, 2010-01-15 at 09:49 +1100, Andrew Bennetts wrote: Jelmer Vernooij wrote: On Thu, 2010-01-14 at 18:07 +1100, Andrew Bennetts wrote: Import exists but fails (even after retry): --- gnome-control-center This was a broken import - I've removed it and created it again to force it to import from scratch. gnome-power-manager I couldn't find the project on launchpad for this - where is it? The Launchpad project for that package is “gnome-power” for some reason: https://code.edge.launchpad.net/gnome-power. I'm not sure why, given that upstream also calls it gnome-power-manager... perhaps we should rename the Launchpad project while we're there? Yeah, that makes sense. We can still keep the old name as an alias. FWIW the import of gnome-power-manager fails because of a bug that's fixed in newer versions of bzr-git. mwh landed a newer version of bzr-git on Launchpad so after the next roll-out it should be a matter of hitting retry. Cheers, Jelmer signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: fastimport and the scope of the hottest 100 effort
Hi Ian, On Mon, 2010-01-11 at 18:53 +1000, Ian Clatworthy wrote: James raised the question recently about whether some of the packages in the hottest 100 ought to excluded or not, e.g. pidgin's upstream is in monotone and we don't have a bzr-monotone plugin. My answer is yes, we'll need to exclude some things. The import breakdown analysis I did last Friday showed some packages don't have publicly available source code, e.g. the HP printer drivers and various X drivers. In terms of strategy, I think we should focus on getting as many imports in the top 100 as possible working via bzr-svn, bzr-git and bzr-hg. We should also take a moment to confirm imports of these packages are into 2a branches, *not* earlier or development formats. Looking at the top 10 packages on https://edge.launchpad.net/ubuntu/+upstreamreport, *I* can certainly see value in also supporting fastimport if my current assumptions wrt bzr-svn/git/hg are correct. The top 10 packages include: * the kernel - in git, huge and (iiuic) not supported by bzr-git This fails on Launchpad at the moment, but it works fine here locally. Launchpad importing only X (where 1 = X = 5000) revisions at a time should fix this. * firefox - in hg and very popular * open office - in hg (now) and huge in size Same here. For each of these, fastimport may be the best option, given fastimport-generated branches are often much smaller than those created via Jelmer's plugins. Is this still true after packing? I'm a bit surprised as to what could be causing this. We have the same data, after all. Cheers, Jelmer signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Breakdown of import failures in the hottest100
Imports not yet defined --- == === Product VCS Comments == === aptitudehg http://hg.debian.org/hg/aptitude/head cupsys svn http://svn.easysw.com/public/cups/trunk/ IIRC this was the old package name for cups, which already has that URL registered (AFAIK it's not possible to import the same URL for multiple projects). kdebase svn failing with pysvn._pysvn_2_5.ClientError: No such revision 1071409 It would be interesting to try this import with bzr-svn. Cheers, Jelmer signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Bazaar focus for 2.1 and 2.2
On Thu, 2009-12-17 at 12:02 +, Jelmer Vernooij wrote: On Wed, 2009-12-16 at 11:36 -0500, Francis J. Lacoste wrote: On December 16, 2009, John Arbash Meinel wrote: Francis J. Lacoste wrote: On December 15, 2009, Martin Pool wrote: I just had a good talk with James about what the Bazaar team could do to help UDD move forward. We are making progress on some particular bugs but the analysis feels a bit inchoate. So my theory is that we will be more efficient if we pick a clearer focus to do first. We talked about: * vcs imports - very visible so could be good, but not a pressing problem now Well, the linux kernel import is still not working. And that's with the recent fixes to bzr-git by Jelmer and the improved memory usage by John. So there are things to improve there. So I think the kernel is probably good for visibility, it certainly isn't worthwhile from a people are going to start using bzr to develop the kernel sort of thing. It's more than for visibility, having an import of the kernel is a prerequisite for doing udd and daily builds with it. Would it perhaps be an option to have the import system only import e.g. only 1000 revisions at a time? This would make the memory leaks less of a problem, and it should make the scheduling of code imports a bit fairer, since large branches would not keep the system busy for a long time. The overhead of resuming an existing import should be relatively small. Another advantage that such an approach would have is that imports for which one of the last few steps in the process fails (such as creating the branch after fetching the revisions) would not have such a burden on the system as they have now as there are at most 1000 revisions fetched per time for broken imports. E.g. if importing revision 121453 of the Linux kernel failed then the system would only repeatedly try to fetch revisions 121000 to 121453 a couple of times before giving up completely. Cheers, Jelmer signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: bzr loves Ubuntu @ UDS
Hi Vincent, Thanks for writing this up. On Wed, 2009-11-18 at 16:49 -0600, Vincent Ladeuil wrote: Many discussions and sessions related to the daily builds and the source packages have happened here already. It's a bit hard to report about them without repeating a lot of things that has been covered during our bzr sprint, so I'll try to focus on the main differences (at least in my understanding, feel free to correct me). 1) code imports First of all, I'll appreciate some rehash of the arguments about why code imports should be at priority #2 behind mini-grumpy. There seem to be many problems around branches with different histories between the upstream, debian and ubuntu branches. The sooner we get the first ones via code imports the less problems of history rewriting we'll have to deal with. Is there something wrong with that reasoning ? It has been mentioned in one of the sessions that there are ~100 packages that are more important than the others but we still don't know if we import them correctly. Establishing which of these 100 are not imported today sounds like a good first step. Working from there and making the most important ones work first also sound like a task for which we can allocate resources on demand and be ready to handle the coming growing demand (5000 new imports are expected shortly). +1, it seems a lot easier to get the history right in the first place than to fix it up later on. 3) package variety While discussing with Steve Langasek, he showed me the samba package: - upstream: git, not yet imported, it is, actually: https://code.edge.launchpad.net/~vcs-imports/samba/trunk Cheers, Jelmer -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
