Re: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
On 13 November 2013 17:39, Andrew Starr-Bochicchio wrote: > On Fri, Nov 8, 2013 at 1:33 PM, Andrew Starr-Bochicchio > wrote: >> Though since we're talking about it, the one stop gap fix that would >> make me happy would be if all Ubuntu Developers could trigger the >> equivalent of the local 'requeue_package.py --full' command that UDD >> admins can run. Some history might get lost, but at least out of date >> branches could be made usable. > > This seems to have been the topic that has generated the most > interest. It seems to be a bit of an overkill to have a vUDS session > on it, especially if we don't have the right people in the room. So > maybe we can try to hammer out the requirements here? > > Currently you need shell access to Jubany in order to run the command. > [0] I know that this request has come up in the past, but my Google-fu > is failing me now. Adding the (seemingly dormant) UDD list to the > conversation in hopes of catching the right person. > > [0] https://bugs.launchpad.net/udd/+bug/713719 I requeue packages from time to time, upon request. But I don't keep a track of packages for which full requeue doesn't help. Nor have a good way to process such requests. Maybe a request wiki page? I'd subscribe to it, and would comment which one requeued and whether that fixes / not fixes the branch. Regards, Dmitrijs. -- 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: evolution is out of date.
On 19 March 2013 23:41, Mathieu Trudel-Lapierre wrote: > I've noticed today that evolution is out of date, I see it in the > package-importer status page; and it's listed under socket.error: > > Could anyone please look into this, or let me know how I can help fixing > that package? > Most up to date evolution branch is managed under ~ubuntu-desktop team umbrella. lp:~ubuntu-desktop/evolution/ubuntu I'll check later if those packages can be requeued, and whether that will help them to be imported. Regards, Dmitrijs. -- 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
Patch Pilot Report & bzr workflow used.
I did quite a few "bzr" merge proposals. The workflow I used was this: bzr branch lp:~logan/ubuntu/raring/rbbr/0.6.0-6 cd 0.6.0-6 bzr bd -S sbuild ../build-area/*.dsc bzr diff -rtag:last-ubuntu | filterdiff -x ".pc*" bzr diff -rtag:last-debian | filterdiff -x ".pc*" debsign ../build-area/*_source.changes dput ../build-area/*_source.changes bzr mark-uploaded bzr push lp:ubuntu/rbbr It worked very well & I had no hickups with any of the below listed branches I sponsored. It was quicker than using debdiffs / interdiff. And for some, the original new upstream tarball was in the branch as pristine delta, so I didn't need to manually fetch tarball. Here is my patch pilot report for today: > reject (stray proposal): > > > https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/postgresql-8.4/precise-proposed/+merge/139408 > > > > > comment: > > > https://bugs.launchpad.net/pam/+bug/952185 > > > > > > sync: > > > https://bugs.launchpad.net/ubuntu/+source/d-feet/+bug/1099704 > > > https://bugs.launchpad.net/ubuntu/+source/subtitleeditor/+bug/1099769 > > > > > > won't fix: for same reasons as in debian > > > https://bugs.launchpad.net/ubuntu/+source/clementine/+bug/995689 > > > > > > push & upload: > > > https://code.launchpad.net/~logan/ubuntu/raring/lazr.delegates/lintian-fixes/+merge/143060 > > > https://code.launchpad.net/~geoubuntu/ubuntu/raring/tvtime/1099042/+merge/143038 > > > https://code.launchpad.net/~logan/ubuntu/raring/sblim-cmpi-base/1.6.2/+merge/143018 > > > https://code.launchpad.net/~logan/ubuntu/raring/nxcomp/3.5.0-2/+merge/143017 > > > https://code.launchpad.net/~logan/ubuntu/raring/rbbr/0.6.0-6/+merge/143015 > > > https://code.launchpad.net/~logan/ubuntu/raring/swi-prolog/5.10.4-5/+merge/143007 > > > https://code.launchpad.net/~logan/ubuntu/raring/festival/1-2.1-release-5.1/+merge/142843 > > > > > > upload debdiff:
Missing history... ?!
Hello,
Did anyone ever encounter this error message?
$ bzr branch lp:ubuntu/quantal/libguestfs quantal
bzr: ERROR: Revision
{package-imp...@ubuntu.com-20120425223523-mwobgosb3qsujuhq} not
present in
"Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)],
[]".
Regards,
Dmitrijs.
--
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: package importer status after DC move
On 24 August 2012 10:49, Max Bowsher <_...@maxb.eu> wrote: > On 21/08/12 00:57, Dmitrijs Ledkovs wrote: >> Hello, >> >> I noticed that for example lp:ubuntu/distcc is out of date, not pending, >> nor failed in package-importer. >> >> Is everything ok with the package importer? >> >> $ bzr tags -d lp:ubuntu/distcc >> Most recent Ubuntu version: 3.1-5 >> >> Packaging branch version: 3.1-4ubuntu2 >> Packaging branch status: OUT-OF-DATE >> > > I requeued distcc, and then had to do 'bzr break-lock lp:ubuntu/distcc' > to break a 3 day old stale lock - owned by Dmitrijs. > > 3.1-5 is now imported. > interesting sorry about that =) -- 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
package importer status after DC move
Hello, I noticed that for example lp:ubuntu/distcc is out of date, not pending, nor failed in package-importer. Is everything ok with the package importer? $ bzr tags -d lp:ubuntu/distcc Most recent Ubuntu version: 3.1-5 Packaging branch version: 3.1-4ubuntu2 Packaging branch status: OUT-OF-DATE -- Regards, Dmitrijs. -- 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: Requesting merge of ICU
On 16/08/12 23:35, Dan Kegel wrote: > On Thu, Aug 16, 2012 at 3:23 PM, Dmitrijs Ledkovs > wrote: >> The right thing to do is to follow this: >> >> https://wiki.ubuntu.com/SyncRequestProcess > > As it turns out, the problem was purely that I was following the bzr workflow, > and that has failed in this case. See > https://bugs.launchpad.net/ubuntu/+source/icu/+bug/1037715 > > If I had used 'apt-get source', I would have not run into the problem. > > This has been an education! > - Dan > I am glad you learned something new today! Welcome to Developing Ubuntu =) -- Regards, Dmitrijs. -- 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: Requesting merge of ICU
On 16/08/12 20:28, Dan Kegel wrote: > Hi! > ICU isn't building in Quantal. The same bug appears to be fixed in debian, > see > https://bugs.launchpad.net/ubuntu/+source/icu/+bug/1037715 > and it seems like it's time to merge a new version. > The package is in sync with debian, so actually you want to do a sync request. You can perform sync requests with $ request-sync tool. > 'bzr log' says > committer: Package Import Robot > ... > committer: Package Import Robot > ... > committer: Package Import Robot > It says that for every single revision, of every package that get uploaded into ubuntu archive. It might not say that, if the developer chose to commit to the branch instead of letting the package importer do it instead. > so I gather the robot usually does the import, and the robot's page > says to discuss it here. > Other way around, people upload into the archive & importer notices it and creates a branch. Branches are not authoritative, the archive is. > The freeze just started, though, and I hear this means no more > robotic merges. > The freeze started for precise 12.04.1 release. The freeze for Quantal is next week. There are no robotic merges. There are autosyncs from debian. See: https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule > What's the right thing to do here (remembering that I'm an outsider, > barely aware of Ubuntu or Debian processes)? > The right thing to do is to follow this: https://wiki.ubuntu.com/SyncRequestProcess To learn more about developing Ubuntu see: https://wiki.ubuntu.com/UbuntuDevelopment/KnowledgeBase -- Regards, Dmitrijs. -- 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: Upgrading pristine-xz on jubany
On 29/06/12 12:04, Vincent Ladeuil wrote: > > If you have other specific targets, let me know. There are 359 failures > currently and I will requeue them progressively. > Don't know if aptitude will work. Also, mdadm would be nice. It works locally if I blacklist experimental series / broken package. And I really, really need mdadm because packaging got diverged significantly partly because of lack of package-imports. -- Regards, Dmitrijs. 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: landscape-client in oneiric-updates
On 19/06/12 18:16, Andreas Hasenack wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/19/2012 11:57 AM, Andreas Hasenack wrote: >>> pull-lp-source landscape-client bzr init landscape-client cd >>> landscape-client bzr import-dsc >>> ../landscape-client_12.04.3-0ubuntu0.11.10.dsc >> >>> That will at least give you a branch you can work with. Though >>> obviously, it won't have full history nor can you use a merge >>> request with it. You'll still have to proved a debdiff in the >>> end. >> >> Thanks, I didn't know about import-dsc either and did all that > > Ok, I dislike import-dsc. > > It commits and uses the debian/changelog for the commit message. > This will help: $ cat ~/.bazaar/builddeb.conf [BUILDDEB] commit-message-from-changelog=False Which bzr-builddeb are you using? Recent versions default to False. > Which in my case means spamming the IRC channel with debian/changelog. > > A huge one. > Instead of, bzr commit, you could use: debcommit --edit let's you edit before commiting, if you are doing a merge for example. These two are better, if you have for example LP: #XYYYZZZ in the changelog, debcommit / autocommit will automatically link the commit to the bug leading to linking the branch on launchpad on push automatically for you. > In fact, I'm starting to dislike all these bzr "automations/plugins" > that do unexpected things behind your back. It even mangles po files > nowadays. > The defaults are meant for majority / most common way of Ubuntu & Debian packaging. It is fully customizable to fit your workflow. -- Regards, Dmitrijs. -- 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: landscape-client in oneiric-updates
On 19/06/12 14:41, Andreas Hasenack wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/18/2012 06:58 PM, Dmitrijs Ledkovs wrote: > >> http://package-import.ubuntu.com/status/landscape-client.html#2012-04-22 >> >> > 00:43:56.697761 >> >> Should explain. > > What does that mean? Is it a temporary error? Is the branch corrupted? > What do I need to do? > Above status page, shows the traceback and a link to the bug in the package-importer which fails to import landscape-client and a few other packages. https://bugs.launchpad.net/udd/+bug/653312 Well it's a bug in the importer, so there is not much that you can do. Your best case is to use regular non-udd style of packaging. E.g.: $ pull-lp-source landscape-client oneiric-updates To get that source package, modify it, build it, create a debdiff and attached to a bug on launchpad, subscribe sponsors to sponsor it. -- Regards, Dmitrijs. -- 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: landscape-client in oneiric-updates
On 18/06/12 22:45, Andreas Hasenack wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > landscape-client got an update for oneiric a while ago, but the > lp:ubuntu/oneiric-updates/landscape-client branch doesn't exist. Is it > a case of the importer failing? How can we trigger it to run again for > that package? > http://package-import.ubuntu.com/status/landscape-client.html#2012-04-22 00:43:56.697761 Should explain. > The updated package: > http://packages.ubuntu.com/oneiric-updates/landscape-client > > But the branch: > > $ bzr branch lp:ubuntu/oneiric-updates/landscape-client > bzr: ERROR: Not a branch: > "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/oneiric-updates/landscape-client/". > > lp:ubuntu/oneiric/landscape-client exists, but it has the released > version as expected, not the update. > > Thanks! -- Regards, Dmitrijs. -- 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
Fwd: Re: Fwd: Re: Upgrading pristine-xz on jubany
FYI. Stephane is highly experienced with LXC and does a lot of work with it. On 06/15/2012 04:43 AM, Dmitrijs Ledkovs wrote: > Dear Stephane, > > Can you comment about running quantal LXC container on Lucid host? > It would help package importer a lot. > > Regards, > Dmitrijs Hi Dmitrijs, I wouldn't recommend running LXC on 10.04, the kernel lacks some required features and the userspace is really quite behind. Not to mention that these are not secured by apparmor. Instead I'd strongly recommend going with an Ubuntu 12.04 host and running the quantal container on top of that. This way you get the "supported" LXC stack, with apparmor and a working quantal template. Stéphane > Original Message > Subject: Re: Upgrading pristine-xz on jubany > Date: Fri, 15 Jun 2012 10:32:59 +0200 > From: Vincent Ladeuil > To: Barry Warsaw > CC: ubuntu-distributed-devel@lists.ubuntu.com > >>>>>> Barry Warsaw writes: > > > On Jun 14, 2012, at 05:21 PM, Vincent Ladeuil wrote: > >> - I'm already running successful tests inside a quantal lxc > container :) > > > It has become for many of us not just a nice-to-have but a > > must-have for Ubuntu development. > > That's my understanding as well. > > Here are my last achievements for the week: > > - I got in touch with pristine-tar maintainers resulting in a trivial > bugfix included in 1.25. This is a small step in getting *known* as a > primary consumer but it also demonstrates that we can get fixes > upstream quickly (1.25 has already been uploaded to sid and quantal). > > - I got in touch with xz maintainers and a fix is on its way there > (many thanks to Lasse Collin for its invaluable help here). This will > require an additional fix to pristine-xz which I will submit as soon > as I can test the xz fix). > > With these fixes in place, on quantal, it should remain only < 10 > pristine-tar import failures out of the current 338 on jubany. Said > failures include crazy stuff like tarballs containing files with > chmod bits... I haven't looked more precisely how to fix that (and I'm > not sure it's worth digging for now). > > And don't forget that when a package fail to import one release, all the > subsequent ones are blocked as well. When we fixed the bzip2 issue last > January, ~70 packages were blocked accounting for ~800 releases (don't > quote on these numbers, it's just a vague remembering but the scales > should be ok). > > I also have a pending patch for bzr-builddeb that makes it easier to > test against pristine-tar failures (will probably submit an mp for that > today). Roughly, both builddeb and pristine-tar use temp files so when > the import fails, the context is lost. The fix is to save enough of the > temp files to be able to re-run pristine-tar alone without re-trying an > import (the test cycle is then reduced to seconds instead of hours). > > With these 3 fixes, we'll be in a far better position to be more > reactive to pristine-tar failures in the future (running quantal will > then mean that getting fixes will be as simple as stopping the importer, > running apt-get upgrade and restart the importer). > > It also means that testing can occur on quantal without the need to > install a bunch of pre-requisites in sync with what is deployed on > jubany (which can quickly get totally out of control). > > I'm still investigating running a quantal lxc container right now on > jubany (any feedback about lxc on *lucid* welcome especially known > issues that has been fixed in precise). > > Once I validate this we can look at deploying a quantal lxc > container on jubany. > > Vincent -- 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: Moving udd away from sqlite
On 14/06/12 23:23, James Westby wrote: > > 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. > option 3) has +1 from me. I can help out if things go wrong. I don't know storm, but I have been doing a lot of orm work on top of postgres in python. -- Regards, Dmitrijs. -- 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: Upgrading pristine-xz on jubany
On 13/06/12 16:48, Barry Warsaw wrote: > On Jun 11, 2012, at 01:54 PM, Vincent Ladeuil wrote: > >> It's unclear to me that we are *known* as a primary consumer. >> >> It's clear that we need fixes faster. Being able to report better bugs >> should helps us getting there and also make us known as a primary >> consumer. >> >>> And it provides better service to Ubuntu developers if we can turn >>> around an upgrade of that sort of thing without communication >>> across a Dev/Ops boundary. >> >> I agree with this goal too. >> >> For the record, I have a trivial fix for pristine-xz that address 2 >> failures and a wip that could well fix the ~140 left on quantal. > > Foundations team had a brief discussion about this today, and we'd love to get > this fixed. For example, we were looking at packagekit, which is out-of-date > because of this problem. > > If I'm reading the thread correctly, the choices are roughly between upgrading > jubany to precise and backporting pristine-tar and xz-utils (and their > dependencies) to precise, or in some way getting the importer running on > quantal. We're in favor of whichever approach can be accomplished quickest > and gives us the highest probability of long-term importer improvement and > success :). > > If it helps, one of our guys would be willing to help backport some packages > to precise, but I'll let him speak for himself. :) > I defiantly would help back porting and validating backports if that's the route chosen. I heavily rely on package-import. It's no longer 'a demo' but really the only way I develop for ubuntu or debian (to have a nice debdiff). Regards, Dmitrijs. -- Regards, Dmitrijs. -- 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
DEB_VENDOR & package imports
Hello, I am having fun times with package lp:debian/accountsservice $ bzr cat lp:debian/accountsservice/.pc/applied-patches Most recent Debian version: MISSING 0001-formats-locale-property.patch 0002-create-and-manage-groups-like-on-a-ubuntu-system.patch 0005-gdm_config_file_path_ubuntu.patch 0006-adduser_instead_of_useradd.patch 0007-add-lightdm-support.patch 0008-nopasswdlogin-group.patch 0009-language-tools.patch 0010-set-language.patch 0011-add-background-file-support.patch 0012-add-keyboard-layout-support.patch 0013-add-has-message-support.patch 1001-buildsystem.patch 2001-icon_reset.patch 3001-show_more_than_one_user_powerpc.patch $ bzr cat lp:debian/accountsservice/debian/patches/series Most recent Debian version: MISSING 0002-create-and-manage-groups-like-on-a-debian-system.patch 0005-gdm_config_file_path.patch 0006-adduser_instead_of_useradd.patch 0007-add-lightdm-support.patch 1001-buildsystem.patch 2001-icon_reset.patch 3001-show_more_than_one_user_powerpc.patch It has both ./debian/patches/series & ./debian/patches/ubuntu.series And upon package import it appears that ubuntu.series got applied when importing into 'Debian' branch. Furthermore ubuntu.series were not refreshed by the debian maintainer upon last upload. This results in a failure messages from $ bzr merge(-package) upon trying to unapply patches. I think, the lp:debian/* imports should be run with export DEB_VENDOR=Debian This should make the lp:debian/package to match the source package as it is unpacked/built on Debian. But I'm not sure if this actually will make merging any easier. Thoughts? -- Regards, Dmitrijs. 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: Making bzr commit more like debcommit
On 24 January 2011 16:25, Micah Gersten wrote: > On 01/24/2011 10:16 AM, Barry Warsaw wrote: >> On Jan 24, 2011, at 10:09 AM, Micah Gersten wrote: >> >>> I actually wanted to add more features to debcommit like passing an >>> author name. It might be easier to try to standardize on debcommit so >>> that it's portable across multiple VCSs. Making bzr commit call >>> --fixes also sounds good for those that strictly use bzr. >> >> One of the reasons why I want to improve and recommend 'bzr commit' is that >> when using UDD, bzr is your front-end for most of the work. It seems jarring >> to have to remember to switch to debcommit for a step. Perhaps OTOH, >> debcommit should be recommended everywhere, but then, that seems jarring to >> someone used to using bzr. (We already recommended dch but that doesn't seem >> as bad because it doesn't really mirror a standard bzr command.) >> >> -Barry > > Right, but debcommit is the same as with any other VCS. You run VCS > foo, dch, and debcommit. <-- I wonder if debcommit is actually used > like this, I know that's what it's intended for, but it would be > interesting to know if it's actually used like that, especially with git. > I have used before: debcheckout, dch, debcommit. I do this for Debian packages. For ubuntu packages I tend to use: bzr branch lp:ubuntu/* dch `bzr commit' `bzr push' I would like to have `bzr debcommit' - commit on steroids =) > Micah > > -- > 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 > -- 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: Fw: [ubuntu/natty] pythonmagick 0.9.1-3ubuntu5 (Accepted)
On 12 December 2010 10:07, Michael Bienia wrote: > On 2010-12-11 09:24:37 -0500, Barry Warsaw wrote: >> So, I actually find these notifications less helpful than they could be. I'm >> used to being on various "-checkins" mailing lists where every change to a >> tree is included in the notification in unidiff format. This is a great, low >> impact way, to monitor what's happening to code you care about. It's also a >> cheap way to propagate post-commit review of changes. It's not uncommon for >> example to see a Python commit be questioned and adjusted after the fact >> (that's why we have a vcs, right? :). >> >> I would love to see the same thing in these -changes notifications. > > I could live with a link to the generated LP diff or a link to the > commit in the packaging branch for easier access but please don't > include the whole diff in the -changes mail as I prefer to have them > small. > For an ubuntuX → ubuntuX+1 upload the diff will most likely be only a > few kB but for an upload of a new upstream version the diff can be > several hundred kB or even some MB. I don't want to have such huge diffs > attached to the -changes email as I certainly won't read such big diffs > (and especially won't read diffs of generated files like configure or > updates of line numbers in translation templates). > The launchpad codehosting can limit the diff to e.g. 1000 lines. We are really interested in full debian/ diff and directly applied patches the rest is less important when it is new upstream release. >> How hard would it be to do that? > > As the -changes mail gets generated when the upload gets accepted that > would probably delay them if they need to wait on the diff. > How long does it take till the diff between two uploads is available in > LP? > > Michael > > -- > 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 > -- 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: Fw: [ubuntu/natty] pythonmagick 0.9.1-3ubuntu5 (Accepted)
On 11 December 2010 14:24, Barry Warsaw wrote: > So, I actually find these notifications less helpful than they could be. I'm > used to being on various "-checkins" mailing lists where every change to a > tree is included in the notification in unidiff format. This is a great, low > impact way, to monitor what's happening to code you care about. It's also a > cheap way to propagate post-commit review of changes. It's not uncommon for > example to see a Python commit be questioned and adjusted after the fact > (that's why we have a vcs, right? :). > > I would love to see the same thing in these -changes notifications. > > How hard would it be to do that? > -Barry > Manually subscribe to change & diff notifications on the branch lp:ubuntu/ ? Except that when you try to do that e.g. here https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/pythonmagick/natty You get subscribed to *natty* only and when o-series becomes active you would have subscribe again. https://launchpad.net/~ubuntu-branches is restricted team but maybe it would be usefull to have a mailing list with change notifications for all natty branches for example. > > Begin forwarded message: > > Date: Sat, 11 Dec 2010 02:15:28 - > From: Matthias Klose > To: natty-chan...@lists.ubuntu.com > Subject: [ubuntu/natty] pythonmagick 0.9.1-3ubuntu5 (Accepted) > > > pythonmagick (0.9.1-3ubuntu5) natty; urgency=low > > * Try harder to search for python2.7. > > Date: Sat, 11 Dec 2010 03:06:20 +0100 > Changed-By: Matthias Klose > Maintainer: Ubuntu Developers > Signed-By: Matthias Klose > https://launchpad.net/ubuntu/natty/+source/pythonmagick/0.9.1-3ubuntu5 > > -- > Natty-changes mailing list > natty-chan...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/natty-changes > > -- > 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 > > -- 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 health check?
On 13 July 2010 18:23, Elliot Murphy wrote: > On Tue, Jul 13, 2010 at 11:08 AM, Martin Pool wrote: >> I asked Barry how he was finding the UDD experience > >> Any other suggestions/wishes/hates? > > I have found UDD very pleasant for doing merges from debian to ubuntu, > and I *love* using merge proposals to ask for changes to be sponsored > into Ubuntu. When I want to put a python or erlang package into Ubuntu > via debian, I end up needing to use SVN and svn-buildpackage which is > a completely different world/workflow from UDD and that difference can > be a bit overwhelming at first. > Why not checkout debian/ dir using bzr-svn and add a local bzr-builddeb config to use this checkout in merge-mode? =) YMMV. > When/where to use the bzr mark-uploaded command when sponsoring > someone elses work is a bit mysterious to me. > > Overall UDD just works for me and generally stays out of my way. > -- > Elliot Murphy | https://launchpad.net/~statik/ > > -- > 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 > -- 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: upstream + packaging + looms + lp != happiness
Launchpad is getting building packages out of bzr branches via recipes from a branch. If i was you I would just keep upstream code & "upstream packaging" in lp:computer-janitor. Then locally setup bzr-builder recipes and use them to generate ubuntu/debian source packages (you can run arbitary commands and package version is auto-updated with branch bzr revision number, date, target distro etc.) You can already _set up_ recipes on launchpad as well to build from branch to PPA but the job will just sit there until building from branches using recipes on launchpad will be fully enabled. later if you want to package it for distribution you will use awesome bzr-bd - branch off from tag import pristine tarball to create "official packaging branch" for doing releases to debian/ubuntu archives. IMHO no need for looms nor pipelines =) ps. I'm rebasing all of my packaging branches against import of upstream $vcs's =) -- 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: Pipes3.0 maybe Threads3.0
(again inline but trimmed) On 29 March 2010 22:47, James Westby wrote: > On Sat, 27 Mar 2010 00:43:26 +0000, Dmitrijs Ledkovs > wrote: >> >> == Assumptions == >> >> Spec does not include multiple tarballs format. > > Yes, these are tricky to deal with, so I'm happy to defer including them > in this until we have an idea of how to handle them. > When we will have nested trees everything will be fine ;-) >> >> So for example you are MOTU (Master Of The Unseeded) and need to do a >> complex merge with 10 patches. You would grab lp:ubuntu/$package. >> Reveal it from the base revision. Import new debian revisions from >> lp:debian/$package in revealed state. Do a bzr pump resolving >> conflicts. Do a build, do testing. Fold the revealed state into >> lp:ubuntu/$package which will become a single commit/tag, mark >> uploaded and push to launchad for building. > > > Interesting approach. > > Do you think there is a benefit to providing a command to reveal the > patches, rather than making lp:$distro/* use the revealed structure? > 1) If lp branches are in the revealed structure we are loosing compatability with debian. Right now you can browse Logerhead view and ever single debian maintainer will understand what's going on. Even hard-core tool-chain maintainers we don't depend on dh at all =) 2) Storing in revealed structure will make it harder to move around & host elsewhere. Eg. people with bzr without any plugins. (looms & pipelines & buildeb are all optional and not shipped with bzr) 3) By having revealed state locally, I can rewrite it as much as possible until I like what I see ;-) > It certainly sounds like you have some good ideas for implementing some > of the tricky bits. > Thanks. Recent rumblings on Debian/Ubuntu planet got me thinking. Initial wiki history was far less pretty ;-) >> Stage 2 >> >> Add a new read & write content filter for '''debian/patches'''. Such >> that when you switch to debian pipe and all patches magically are >> refreshed. Removing a patch should remove pipe & vice-versa. > > Is this so that people can manipulate the debian/patches somewhat rather > than manipulating the pipes? > The content filter was so that you don't have to re-export patches after you have edited it in a pipe and came back to the top packaging pipe such that you can envoke bzr-builddeb You can edit debian/patches in regular mode and go between releaved <-> colapsed states if you want to switch between editing by hand & via pipes. In the revealed mode changing the order of patches in the series file will instantly make pipes history inconsistent which was just created. So no you can't edit debian/patches directly with editor, you have to commit to pipe. > Do you think it would confuse some people in to e.g. losing work as they > think they can just alter that patch and be done? > Good point. In revealed state add debian/patches/WARNING-DO-NOT-EDIT with help text? Make debian/patches non-writable? Drop people into subshell with cool modeline showing pipliene status? Have a notify-osd pop-up to reminde them? Needs work. > > Right, so you don't want to rewrite? > At this stage each time you reveal you are creating history and can do it locally as many times as you like until you make this plugin work ;-) When we are ready, we can rewrite, It will work best for 3.0 quilt packages cause we want to store the branch in patched state. And if we rewrite history we would be better off rewriting on top of vcs-imports. So my answer is maybe / later. > In all the talk so far the opinion has been that we would just make > lp:$distro/* a loom that would provide this without the extra step. > Ok. Chicken & Egg problem between: looms are used <--> logerhead & merge proposals work with looms. I haven't used looms yet. And pipes are far more stable imho cause it's just lightweigth checkouts with UI on top. Plus some parts of this spec will be useful even without whole reveal mechanism eg. quilt patch series import-export to from pipes of a single commit vs >> == GSoC2010 == >> >> Potentially my 3rd GSoC 2010 proposal. See >> [[DmitrijsLedkovs/GSoC2010]] and [[DmitrijsLedkovs/CadieSpec]]. Would >> you mentor this? > > Of course :-) I'd love to see someone taking on this problem, while I > think there's still plenty to talk about having something to evaluate > would be great. > Thanks a lot of comments. I will move to appropriate place such that at least this stub ideas are not lost ;-) -- 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
Pipes3.0 maybe Threads3.0
ilt''' - new option to use quilt logic for importing a single / multiple patches bzr '''import-quilt series''' - new command to import quilt '''series''' file as patches bzr '''export-quilt [destdir]''' - new command to export pipes as quilt series to destdir (default debian/patches) bzr '''export-quilt-hook''' - new '''hidden''' command / API for consumption by bzr-bd as pre-build hook bzr '''reveal''' - expose packaging branch as pipeline bzr '''hide''' - go back to packaging branch bzr '''fold''' - fold current committed state of top-level pipe as a commit on packaging branch === Code Changes === Not ready yet. Draft === Migration === Stage 1 will not have reveal/hide/fold. It will be able to import quilt series as pipes & export them. Which will already be improvement and will be usable for packaging. Stage 2 will add content filter to eliminate exporting patches. Stage 3 will have reveal/hide/fold for total Ayatana development. == Test/Demo Plan == Nearing completion of each stage, packaging recepies will we written for developers. == Unresolved issues == This also can be implemented using threads instead of pipeline. Which might be easier to do. But the design goal is to not push threaded/pipeline view to launchpad and not to rewrite public branch history. Our packaging branches have enough information already for this. == GSoC2010 == Potentially my 3rd GSoC 2010 proposal. See [[DmitrijsLedkovs/GSoC2010]] and [[DmitrijsLedkovs/CadieSpec]]. Would you mentor this? -- With regards, Dmitrijs Ledkovs. -- 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
Role of the Sponsorship Queue
I've read the whole thread =) Loads of stuff We are mixing patch qualification & patch review & patch sponsoring I think pre-patch review should be done by bugsquad Patch author uploads patch and subscribes bugsquad (or someone else for pre-patch review) Steps for pre-patch review a) check that problem still exists b) check that patch or debdiff apply cleanly to latest package c) check that package builds d) check that it fixes problem e) check that patch is sane and is the right-thing-to-do (optional) If fails on any of these steps -> canned responses & unsubscribe sponsor team If passes all of these steps -> subscribe sponsor team Sponsor team - Steps for patch review: e) check that patch is sane and is the right-thing-to-do f) any other stuff sponsors do If fails -> comment & unsubscribe sponsor team & canned response (eg subscribe sponsors after all issues address or something like that) If pass -> upload I've used the new bugs with patches pages on launchpad and after poking around I've realized there is a big melting pot of good/bad patches, patches against old versions, patches for no longer existing bugs. So to help everyone it would be great to work with bugsquad to storm through the sponsor queue / all patches to at least identify valid candidates and give a sense of direction for the rest of patch authors. ps. Now to make this really awesome it would be amazing to use advance free form build recipes & build latest ubuntu package with this patch downloaded and applied into my ppa so I can test it ;-) -- 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: Merging from Debian with patches applied
On 17 February 2010 13:26, James Westby wrote: > On Tue, 16 Feb 2010 16:19:20 -0600, John Arbash Meinel > wrote: >> To make sure I understand. If you use quilt, it moves the location on >> the patch stack (by reverse applying the patches). Leaving you with a >> working dir that doesn't have the 'newer' patches applied. Then if you >> change stuff and "build", it recomputes the current patch. > > Yes, I'm not sure if that's automatic, or whether you are expected to > "refresh" and then "pop" back to the top of the stack. > With my little experiments with v3 quilt yes that's what expected "refresh & push -a" cause otherwise it will try to push them itself and possibly get source package build error cause it can't push a patch. I truly dislike patches and i'd rather use native tools. dpkg-source has an option to generate just a single static flat patch where it compares the tree with orig-tree and stores binary & debian packaging into debian.tar.gz and generates just one patch for the rest of the modifications. This is targeted at *-buildpackage people who have topic branches to manage patches ;-) *hint* *hint* It can use a static header file where you generally point where you can find VCS or something else which is used to manage patches separately and sanely. Import quilt patches into pipelines and somehow get the pipelines back when you branch lp:ubuntu/package. And force use a single-patch at source package generation. Going forward we will be building out of the branches and this way it's much easier to work with all the different patches. Just a thought but needs backing/support on pipelines (or looms). And the associate patches.ubuntu.com & Debian backfeed collaboration support. Cause this kind of looks like Renaissance of no-patch-system-used except that we are not using static local folder but a VCS tip. ps. I really don't want to see diff of diffs again in $bzr diff. My eyes hurt. -- 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: [Launchpad-dev] RFC on build from branch UI
On 3 February 2010 20:58, Aaron Bentley wrote: > Michael Nelson wrote: >>> The main point that underlies all my comemnts is that your focus is on >>> "building a branch using a recipe," rather than "building a recipe." >> >> Yes, definitely. I had thought that the recipe is just a means to the >> user goal of building a branch. Sorry, I wasn't trying to minimise >> their importance or flexibility, but rather ensure that the desire "I >> want to build this branch" stays in focus. > > So are we sure that building from a recipe should be a user-level thing > at all? > > It seems like a major use case will be "build this branch using this > packaging branch". If we had a UI that just provided that, what > percentage of our users would still need more? > > Aaron IMHO it would be 50/50 split cause I'm still thinking in terms of packaging branch as the starting point and which branches do I want to build using it. For example as an upstream project maintainer I will strive to minimize amount of packaging branches / recipes cause that's not usually upstream expertise. So I would have one packaging branch possibly pinched of ubuntu and then I will go to it and start thinking which of my project branches I want to build eg. stable release, supported release and this wacky hack I'm working on. And ooops hardy has different lib sonames so i need to use this other packaging branch cause it has build time patch. So again I would go to hardy packaging branch and say oh yeah do just the stable branch cause I really don't want anyone to develop latest features with out-of-date libs for example. This feature will be a popular both from Ubuntu development side and the upstream projects using launchpad for project management, QA / ubuntu experience enhancement. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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: Feedback on merging via bzr
On 28 January 2010 12:04, Scott Kitterman wrote: >> On 28 January 2010 06:14, Reinhard Tartler wrote: > ... >>> Â - download the orig.tar.gz/orig.tar.bz2 files from debian >>> >> >> The branches are pristine-tar enabled you can just >> "$ bzr bd" them and a tarball will appear in your tarball's directory. > > Right, but which tarball? It's not always obvious. It's important that > we md5sum match Debian [1]. In cases where we don't we end up having to > do fake syncs once the differences between Debian and Ubuntu are resolved. > Well just pick your favorite package branch and inspect it with $bzr visualise or the kde equivalent. The import is quite good. Original tarballs are taken from debian and are imported using pristine-tar into the "upstream" branch nick. Then the debian packaging is done on the "debian" branch nick which has upstream as ancestor and then the ubuntu is another branch nick which is diverging from the "debian" one again. So from the resulting lp:ubuntu/package you can branch off any upstream release, debian or ubuntu package release. And each revision has the corresponding pristine-tarball delta, such that all tarballs can be regenerated with identical checksums as in the debian archive. So the branch import has been engineered really well in this respect and we should not have fake syncs anymore. This even scales to when the branches will get rebased ontop of the upstream releases, cause the pristine-tarball delta will be committed into a new branch nick based off upstream branch adding all the Makefile.in's and etc with the tarball delta. Can't remember either Karmic or Jaunty UDS had a video on this UDD master plan with all the explanations. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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: Feedback on merging via bzr
On 28 January 2010 10:09, Reinhard Tartler wrote: > On Do, Jan 28, 2010 at 11:01:37 (CET), Dmitrijs Ledkovs wrote: > >>> >>> it would be great if grab-merge could additionally >>> - check the freshness of the import branches >>> - download the orig.tar.gz/orig.tar.bz2 files from debian >>> >> >> The branches are pristine-tar enabled you can just >> "$ bzr bd" them and a tarball will appear in your tarball's directory. > > I expected that as well, but it didn't work with the xine-lib package. > I think it's a bug. Was it you who added .bzr-builddeb folder with Native config? IMHO that shouldn't be in there. And for example revision 36 of the lp:ubuntu/xine-lib reconstructs original tarball just fine and builds fine. You can try $bzr bd -r36 lp:ubuntu/xine-lib At some point branch got the .bzr-builddeb folder with native package option. Since then the orig-tarballs where not imported using pristine-tar. Investigate further and file a bug against bzr-builddeb or udd porojects on launchpad. >>>> Perhaps "bzr help grab-merge" should give recipes for the common diffs >>>> that we want instead of actually generating them? >>> >>> Yes, that would espc. help people less familiar with bzr. >>> >> >> That's documented already in the Distributed Development wiki. See >> tips section [1] > > which requires developers to open up yet another tool. Having the > documentation at hand improves the workflow espc. when the wiki is down > or you don't have a decently fast internet connection. > Fair enough =) then it should probably live in the bzr builddeb plugin as one of the help topics. Cause you need it to work UDD style with packages anyway ;-) >> I did a similar script which just creates a bunch of shared repos and >> pulls debian & ubuntu branches [2] It doesn't attempt to merge it's >> just there to grab a few merges in one go. > > Sounds interesting, I'll have a look. > >> To be fair the UDD wiki needs some love from people who used bzr for >> development. > > indeed. > -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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: Feedback on merging via bzr
On 28 January 2010 06:14, Reinhard Tartler wrote: > On Do, Jan 28, 2010 at 00:06:52 (CET), Andrew SB wrote: > >> On Sun, Jan 24, 2010 at 9:21 PM, James Westby >> wrote: >>> I would love to have something more akin to grab-merge, and again I >>> would be happy to help someone work on this. I would suggest it get >>> added to bzr-builddeb as that will make some things easier. >> >> Here's a quick attempt: >> >> https://code.edge.launchpad.net/~andrewsomething/bzr-builddeb/bzr-grab-merge >> >> Purpose: Grab packaging branchs for merging. >> Usage: bzr grab-merge PACKAGE >> >> Description: >> This initiates a shared repository and then grabs both >> lp:ubuntu/ and lp:debian/. Next, these >> branches are merged in ".//working_tree." >> >> Mostly I'm hoping that the ugliness of my code (I'm really just a >> packaging monkey) will scare someone who knows better into stepping >> up. =) >> >> I didn't implement any changelog handling as that seems to be >> in-progress elsewhere. >> >> I suppose the real question here is exactly what features we want this >> to have. Do we want to generate diffs like the current grab-merge? Do >> we feel the need to write a REPORT-like file locally? > > I think a 'bzr st -rbranch:../debian' and 'bzr st -rbranch:../ubuntu' > would be indeed interesting to have in REPORT. > > it would be great if grab-merge could additionally > - check the freshness of the import branches > - download the orig.tar.gz/orig.tar.bz2 files from debian > The branches are pristine-tar enabled you can just "$ bzr bd" them and a tarball will appear in your tarball's directory. >> Perhaps "bzr help grab-merge" should give recipes for the common diffs >> that we want instead of actually generating them? > > Yes, that would espc. help people less familiar with bzr. > That's documented already in the Distributed Development wiki. See tips section [1] I did a similar script which just creates a bunch of shared repos and pulls debian & ubuntu branches [2] It doesn't attempt to merge it's just there to grab a few merges in one go. To be fair the UDD wiki needs some love from people who used bzr for development. [1] https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging [2] http://people.ubuntuwire.org/~lucas/grab-branches.sh -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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)
2010/1/26 Jelmer Vernooij : > 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 > Well a few gnome projects might not be in hottest100 but I think it's still important for development focus to be right. Going through gnome meta-project on launchpad, please update: lp:accerciser -> lp:~vcs-imports/accerciser/main lp:at-spi -> lp:~vcs-imports/at-spi/git-trunk lp:ekiga -> lp:~vcs-imports/ekiga/git-trunk lp:gconf -> lp:~vcs-imports/gconf/trunk lp:glib -> lp:~jjardon/glib/trunk lp:gnome-common -> lp:~vcs-imports/gnome-common/trunk lp:gnome-cups-manager -> lp:~vcs-imports/gnome-cups-manager/trunk There are more =) -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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: Feedback on merging via bzr
2010/1/25 James Westby : > bzr-builddeb is a fine place to report them, if you know somewhere more > specific then you can do that, but I am happy to reassign if needed. > I guess launchpad.net/udd is not nice place for bugreports? Swamped with what it seems like automatic bug reports -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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
Tarball inside tarball
Main is still using https://code.edge.launchpad.net/~ubuntu-dev for their packaging. And that's ok until we iron out all Documentation & Infrastructure bugs. But some lp:ubuntu/package branches are pure evil =) For example https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/xulrunner-1.9.1/lucid is useless for UDD. It uses tarball-inside tarball packaging hence the branch is HUGE in size and useless for using bzr for example to patch it. This is probably a bad example of a package because it is managed as part of the ~ubuntu-dev branches in merge mode. But this probably affects a few package branches. Will it be possible to identify all of these packages and file bugs against them in Ubuntu/Debian (Priority Wishlist?) and make a switch to more regular layout? These requests will be somewhat blocked by the dpkg source 3.0 transition (support for bz2 compression) & the bzr-bd support for those source formats. Thoughts? -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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: Feedback on merging via bzr
2010/1/19 Michael Hudson : > Barry Warsaw wrote: >> On Jan 17, 2010, at 10:45 PM, Scott Kitterman wrote: >> >>> At this point I want to check the package against the previous Debian and >>> Ubuntu packages to make sure I have it correct. Traditionally, I would >>> locally debdiff the proposed merge with both the previous Debian and Ubuntu >>> packages to make sure I had documented all of the Ubuntu diff and not lost >>> any needed changes in the merge. To do it the new way, I did: >>> >>> $bzr diff --old lp:debian/squeeze/regina-normal | less >>> ssh key >>> (repeat, including redownloading each time the diff is done) >>> >>> I assume "bzr diff --old lp:ubuntu/regina-normal" would have worked for the >>> diff >>>from the previous Ubuntu package, but it isn't documented and I didn't think >>> to try it at the time. >> >> I just asked Scott to review a change to Lucid's distribute package >> (python-distribute). I merged debian/sid's version into the ubuntu/lucid >> version to get us to 0.6.10. Then I committed and pushed a branch to >> lp:~barry/ubuntu/lucid/distribute/sync-to-sid >> >> Unfortunately, the diff that's automatically generated on the merge proposal >> isn't what Scott wants for the review. As shown above, he really wants the >> diffs between the branch and current Ubuntu, and branch and current Debian. >> Perhaps merge proposals for distro packages need a different kind of >> automatic >> diff? > > This can probably be arranged, I guess. File a bug. Patches likely > welcome :-) > > Cheers, > mwh Hmmm = I *think* lp can do this already In the merge proposals options set lp:debian/sid/package as pre-requisite. Then the diff will be the one sponsors require! I'm so excited about this. Gonna test this and then comment on the bug. This will then need documentation as part of UDD-docs. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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
Feedback on merging via bzr
-- Forwarded message -- From: Dmitrijs Ledkovs Date: 2010/1/18 Subject: Re: Feedback on merging via bzr To: Scott Kitterman 2010/1/18 Scott Kitterman : >> Ubuntu patch compared to the common base version: >> >> ~/src/pkg-name/lucid/ $ bzr diff -rancestor:../squeeze/ >> >> Debian patch compared to the common base version: >> >> ~/src/pkg-name/squeeze/ $ bzr diff -rancestor:../lucid/ >> >> These two commands should generate the equivalent of the .patch files from >> MoM. >> > That doesn't solve the issue with the data being local versus remote, but > it definitely looks very helpful. Would you add that to the wiki page on > merging? > > Scott K > What do you mean? These commands _do not_ require access to remote branches at all! It's all local no trips to launchpad. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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: Feedback on merging via bzr
#x27;t have upload rights so I can't comment. > $ dput ubuntu regina-normal_4.6-1.1ubuntu1_source.changes > > At this point, I'd be done under the old method (and I could have stopped here > now and let the branch be created from the uploaded package, but I decided to > persevere). > > $ bzr mark-uploaded > > $ bzr push lp:ubuntu/regina-normal > ssh key ... > > Now we are done and have both an updated package in the archive and an updated > branch on Launchpad [3]. > > Currently, merging this way has a huge advantage over the traditional MoM > method in that the data for it is being updated and MoM is not. I suppose > that more granularity in the branch is an advantage, but I don't think it has > any real value for cases like there where only one person has worked on the > package (this will virtually always be true for merges). > > I feel like I've gone through a process that is far more complex than the old > one for no real benefit. I have some recommendations for improving and > simplifying this process. I think simplification is an essential element > because the learning curve for new contributors is very steep already and > raising the barrier to entry is not something that will benefit Ubuntu. > > 1. The most important change would be to have some kind of a wrapper for > getting the source. It would be nice to have a script that would download > branches for the common ancestor, current Ubuntu, and current Debian branches, > and do the proposed merge. Without local access to the different versions of > the package, it is very difficult to know if you've got a correct merge. > All of them have common ancestor and this way you choose what you want to merge: experimental, sid, squeeze, lenny. And also you can choose to merge ubuntu proposed, security etc. So I believe this method is superior cause now you can use the same workflow for any package upload to any ubuntu pocket. Note in addition you get the "hidden" upstream branch. $bzr branch lucid -r tag:upstream-0.1 And you get pure upstream branch with release per commit. Quite cool if there were accidental direct modifications in tarball while patch system present and you want to diff them back. > Additionally, if there were checkouts for the previous Debian and Ubuntu > packages locally, then it should be easy enough to diff the debian directories > to check for packaging changes when a new upstream version is involved. > $bzr diff debian/ -r tag:debian-release Or again any release you want. > 2. As you no doubt know, the changelog merging could be better and would > reduce repetitive, boring work potential contributors have to do. > > 3. As mentioned, the bzr builddeb interface and documentation needs work. > Ideally it would act similarly to debuild and pass all the dpkg-buildpackage > options to it without special flags. Yet another interface that is almost the > same is problematic. > It does more =) I like it as it is. But that's matter of opinion. > I know a huge amount of work has gotten to getting things as far as they are. > This feedback is not meant to miminize this accomplishment. I do not, > however, feel like this facility is really ready for general use yet. > Maybe I should write a guide. > Scott K > > [1] https://wiki.ubuntu.com/DistributedDevelopment/Documentation > [2] https://bugs.launchpad.net/ubuntu/+source/bzr-builddeb/+bug/499684 > [3] https://code.launchpad.net/~ubuntu-branches/ubuntu/lucid/regina- > normal/lucid > -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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: Recipes vs. Looms vs. pipelines
2010/1/4 Aaron Bentley : > Barry Warsaw wrote: >> Correct me if I'm wrong, but reconfigure-pipeline is actually pretty close to >> what I want, I think. 'bzr reconfigure-pipeline' will create a ./pipes >> directory in the current working tree, and all new pipes will go there. If >> this was named .bzr/pipes instead I think that would be perfect. > > That is right. If you find any problems with this, please report them > as bugs. > >> I did a quick and dirty hack which seems to DTRT. > > I saw that, and I'm 95% certain I'll land it as-is. It's possible I'll > add an option to restore the previous behaviour. My original motivation > for using a location outside the .bzr was to avoid too much "magic". I > was on a "pipes are just branches" kick. > OMG yes please. I've nuked my pipes quite a few times by running bzr clean-tree --ignored because upstream distclean targets were broken. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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
Bazaar focus for 2.1 and 2.2
-- Forwarded message -- From: Dmitrijs Ledkovs Date: Wed, 23 Dec 2009 06:52:02 + Subject: Re: Bazaar focus for 2.1 and 2.2 To: Martin Pool 2009/12/21 Martin Pool : > I think after the break we should focus on the vcs-imports of the top > 100 Ubuntu packages until they're all working well. jml and spm > helped with some scripts to query their current state, and we can map > that into a spreadsheet showing the root cause for each failure. > > I'll ask the Bazaar team to put most of their forward-development time > into this until they're either all working or we've specifically > chosen something else. We won't ignore other things people bring up > but we won't look for trouble elsewhere til we're done. > > We can focus on this at our mini-sprint in Strasbourg and I hope pair > with Jelmer on debugging some of the failures. > Then how-about https://answers.edge.launchpad.net/launchpad-code/+question/81994 and https://bugs.edge.launchpad.net/launchpad-code/+bug/366102 It doesn't really help having all of those Gnome SVN imports, since they do it in Git now. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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: Workflow with quilt patches & pipeline
2009/12/21 James Westby : > > Hi, > > Interesting idea. > > Does pump-patches take debian/patches and apply them in term as pipes? > > You are right that this does look quite simple. My concern is that it is > using patches as the interchange format for bzr. This makes things like > merging suboptimal, as you don't get the full power of the VCS. Maybe > there's a subtelty I am missing though. > > Have you seen https://wiki.ubuntu.com/NoMoreSourcePackages which > proposes something similar? > Yeap I did see it. NoMoreSourcePackage is the next step when we gonna have all branches imported without hickups and soyuz can build branches. My current proposal is the in-betweenie. How to work with lp:ubuntu/package branches now without using quilt push/refresh. Cause i don't like quilt at all =) I really can't wait for merges to be no different from syncs Eg. revert the ubuntu changes, merge debian branch, push. (sync done). I'm following the discussion on looms vs pipelines for *the* way to patch upstream branch and so far for my personal use (as a Debian maintainer) I'm gonna use throw-away pipes into patches. But this framework can be extended bzr merge-directive with patch is still a valid quilt patch ;-) And I don't believe you loosing much of bzr goodness. * pump-patches * switch to upstream pipe * import new upstream version * pump new upstream * update all the patchy pipes * regenerate patches. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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
Workflow with quilt patches & pipeline
Recent thread about how to add fixes to existing packages got me thinking. Here is my proposal: bzr branch lp:ubunt/package cd package bzr reconfigure-pipeline bzr pump-patches bzr show-pipeline package patch-01 patch-02 * patch-03 bzr add-pipe new-patch bzr switch-pipe :first bzr pipe-patches debian/patches dch -i -m "Added patch / fixes (lp: #1)" debcommit bzr push lp:~me/ubuntu/package/fixes bzr lp-open Merge proposal. Done. Note pump patches doesn't exist yet ;-) Ideally pump/pipe-patches should use DEB-3 for as much info as possible. Comments? Shall I try implement this? Doesn't look like it's gonna be hard. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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: Local testing of imports
2009/12/10 James Westby :
> Hi all,
>
> We have a number of packages failing to import, for a variety of reasons.
> It's useful to be able to run the code locally for testing purposes, so
> I've just pushed the driver code to
>
> lp:~james-w/bzr-builddeb/import-scripts
>
> They're not exactly designed to run on an arbitrary system, but you
> should be able to get them to work without too much effort.
>
> It requires bzr-builddeb, bzrtools, python-launchpadlib, python-debian
> and of course bzr to be installed.
>
> You first have to get some LP credentials:
>
> python create_creds.py
>
> You should be able to get away with "Read non-private", but may want
> to grant more.
>
> You can trigger a run with
>
> ./import_package.py --no-push
>
> (The --no-push ensures that it doesn't try and push to LP if it
> succeeds.)
>
> This will create a number of directories in your cwd. "updates"
> is where the work happens, and where the final branches end up.
> "revids" is where the audit data is stored. "logs" contains a log
> file per-package, you can tail it to watch progress. There are
> a few more of lesser importance.
>
> Any improvements are welcome. I know the code isn't very pleasant,
> and I am trying to clean up as I change things. Bug fixes are
> especially welcome.
>
> In addition, I think it would be useful if we could classify the
> list of current failures. Does the LP OOPS system have code to
> match tracebacks? Anyone know of anything else to do this? Perhaps
> a weekly email here with counts of classified tracebacks would
> help us reduce the number?
>
> Current failures are at
>
> http://package-import.ubuntu.com/failures/.bzr/failures/
>
> Thanks,
>
> James
>
Running the scripts I get (see below)
I have ssh key set up for launchpad. Where else is it trying to
authenticate to? (Permissin denied (publickey))
Please help
$ ./import_package.py --no-push ardour
No handlers could be found for logger "bzr"
Permission denied (publickey).
Traceback (most recent call last):
File "./import_package.py", line 983, in
extra_debian=options.extra_debian))
File "./import_package.py", line 925, in main
possible_transports=possible_transports)
File "./import_package.py", line 736, in find_unimported_versions
possible_transports=possible_transports)
File "/usr/lib/python2.6/dist-packages/bzrlib/branch.py", line 169, in open
possible_transports=possible_transports)
File "/usr/lib/python2.6/dist-packages/bzrlib/bzrdir.py", line 843, in open
return BzrDir.open_from_transport(t, _unsupported=_unsupported)
File "/usr/lib/python2.6/dist-packages/bzrlib/bzrdir.py", line 878,
in open_from_transport
return format.open(transport, _found=True)
File "/usr/lib/python2.6/dist-packages/bzrlib/bzrdir.py", line 2088, in open
return self._open(transport)
File "/usr/lib/python2.6/dist-packages/bzrlib/bzrdir.py", line 3320, in _open
return remote.RemoteBzrDir(transport, self)
File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 115,
in __init__
self._probe_bzrdir()
File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 124,
in _probe_bzrdir
self._rpc_open_2_1(path)
File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 131,
in _rpc_open_2_1
response = self._call('BzrDir.open_2.1', path)
File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 52, in _call
return self._client.call(method, *args)
File "/usr/lib/python2.6/dist-packages/bzrlib/smart/client.py", line
129, in call
result, protocol = self.call_expecting_body(method, *args)
File "/usr/lib/python2.6/dist-packages/bzrlib/smart/client.py", line
142, in call_expecting_body
method, args, expect_response_body=True)
File "/usr/lib/python2.6/dist-packages/bzrlib/smart/client.py", line
90, in _call_and_read_response
expect_body=expect_response_body)
File "/usr/lib/python2.6/dist-packages/bzrlib/smart/message.py",
line 299, in read_response_tuple
self._wait_for_response_args()
File "/usr/lib/python2.6/dist-packages/bzrlib/smart/message.py",
line 264, in _wait_for_response_args
self._read_more()
File "/usr/lib/python2.6/dist-packages/bzrlib/smart/message.py",
line 286, in _read_more
"Unexpected end of message. "
bzrlib.errors.ConnectionReset: Connection closed: Unexpected end of
message. Please check connectivity and permissions, and report a bug
if problems persist.
--
With best regards
Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
--
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: your thoughts wanted on bzr team UDD focus
(Sorry aaron didn't reply all first time around) 2009/12/8 Aaron Bentley : > > However, we can ignore svn issues because we're switching to bzr-svn. > (We hope that will solve many of our problems, but whichever problems > remain will be *different*) > Is there a bug I can subscribe to witch tracks switching to bzr-svn for imports? Cause I am currently pushing bzr-svn branch myself. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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
