Re: etc-init.d-mass-import is now inaccurately named?

> Max Bowsher <_...@maxb.eu> writes: > As far as I can see, etc-init.d-mass-import is no longer installed in > any /etc/init.d/ directory. > Am I wrong, or shall I do a MP to rename it? You're right. It's now run via the crontab (which ensures it runs in the quantal chroot) and

prisitine-tar failures related to multiple blocks xz files (fixed)

Hi all, After a long time waiting for a quantal chroot being available on jubany (see lp:udd for details on how the package importer runs from now on), I'm happy to report that we just finished unblocking ~240 packages leading to ~3000 releases being successfully imported \o/ Most of the package

Re: Upgrading pristine-xz on jubany

Breaking news on the topic below ;) >>>>> Barry Warsaw writes: > 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.

Re: Moving udd away from sqlite

> James Westby writes: > On Thu, 21 Jun 2012 15:35:44 +0200, John Arbash Meinel wrote: >> As I understand it, James still needs to do some work to get Storm to >> not require as strict of an isolation level. For me personally, I'd >> rather he was the one doing the rollout a

Re: Fwd: Re: Fwd: Re: Upgrading pristine-xz on jubany

> Dmitrijs Ledkovs writes: > 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 he

Re: Moving udd away from sqlite

>>>>> James Westby writes: > On Fri, 15 Jun 2012 12:34:12 +0200, Vincent Ladeuil wrote: >> > It's not magic. It's moving from a database that's not designed for >> > concurrent use to one that is designed for concurrent use. &

Re: Upgrading pristine-xz on jubany

Some good news after my tests Friday and this week-end: >>>>> Vincent Ladeuil writes: > - 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 fi

Re: Moving udd away from sqlite

> Jonathan Lange writes: >> There is a work in progress regarding the jubany package importer >> deployment, let's try to no step on each other feet ;) >> > What's the work in progress? Setting up a quantal lxc container that can be used for both test and production with

Re: Moving udd away from sqlite

> James Westby writes: > Hi, > 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 is a work in progress regarding the jubany package importer deployment, l

Re: Upgrading pristine-xz on jubany

>>>>> 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 de

Re: Upgrading pristine-xz on jubany

>>>>> Barry Warsaw writes: > 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 >

Re: Upgrading pristine-xz on jubany

> Max Bowsher <_...@maxb.eu> writes: > Right, I agree we should use stuff straight from Ubuntu when we > can, but I don't agree that it's necessarily wrong to customize > our deployment practices to get fixes faster. Good, I'm glad we agree on the 'get fixes faster' value.

Re: Upgrading pristine-xz on jubany

> Max Bowsher <_...@maxb.eu> writes: > On 06/06/12 13:43, John Arbash Meinel wrote: >> We're trying to work with webops to get Jubany at least upgraded from >> Lucid to Precise, > Great, what's the estimated timeline for that? Unknown. >> and then follow it up with somet

Re: Repairing a broken package import

> Barry Warsaw writes: > Today I wanted to work on the apport packaging branch, but the importer has > been failing on this package: > http://package-import.ubuntu.com/status/apport.html#2012-01-26 06:59:16.573850 > I took a look at bug 494481, which is referenced by the i

Re: Switching over to Quantal

> Max Bowsher <_...@maxb.eu> writes: > On 01/05/12 14:01, John Arbash Meinel wrote: >> Using the config item: >> launchpad.packaging_verbosity=False >> >> In bzr-2.5 and above, you can actually set that on the command line with: >> >> bzr -Olaunchpad.packaging_ver

Re: jubany package importer stopped?

> Jonathan Lange writes: > I should also add that James just recently filed an incident report > for this. Canonical folk can see it here: > https://wiki.canonical.com/IncidentReports/2012-04-09-Bazaar-package-importer-locking > And I've made a public paste at: >

Re: xz tar imports failing?

> Martin Pool 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 > about supporting xz in > bzr-builddeb: does that perhaps need to be deployed on Jub

Re: Moving udd to django

> Martin Pool writes: > I think switching from batch html, handcoded sql and ssh access to > higher-level alternatives would be well worth while and Django seems > like a good choice. +1 from me, and also on the specific incremental > changes. > I agree with James, and di

Re: Moving udd to django

>>>>> James Westby writes: > On Tue, 13 Dec 2011 09:11:36 +0100, Vincent Ladeuil wrote: >> > 3. It would also allow for starting to move udd to an SOA, or at least >> > make it easier. >> >> Not a concern

Re: Moving udd to django

> James Westby writes: > Hi, > I think there are a few reasons that we should consider moving udd to > django (more on what this actually means later.) > 1. We want to have remote commands so that we don't have to ssh > in and run scripts for common tasks Long term p

Re: Using lp:udd beyond its original purpose

> Jonathan Lange writes: >> It seems to me like we should keep lp:udd about the package importer, +1, or find another name but this hasn't been needed so far. >> and then split out the functionality you need. Does that make >> sense, or do you want to do it the other way aroun

Smarter .po merges

Hi guys, To address http://pad.lv/884270, I've written a plugin implementing a new merge hook: po_merge (available in a bzr branch at lp:~vila/bzr/884270-merge-po): $ bzr help po_merge Merge hook for ``.po`` files. To enable this plugin, add a section to your branch.conf or location

Notes from session foundations-p-udd-onramp

New features in UDD * Check on package freshness during 'bzr branch ubuntu:...' * 'bzr get-orig-source' - Gives you an '*.orig.tar.gz' file that you can use with 'debuild', rather than only having 'bzr builddeb'. * Support for multiple upstream tarballs (in progress) * dpkg-mergechangelogs - Us

NoFinalPath import failures (gnome-orca, paramiko, gwibber, udev, etc)

Hey, Nothing better than cracking a nutty bug before leaving for vacations ;) I just realized that 2.3.4 (recently deployed on jubany (reverted from 2.4b4)) included the fix for the NoFinalPath import failures (31 packages including gnome-orca, paramiko, gwibber, udev, ktorrent, some xserver stuf

Re: Improving merge-upstream

> James Westby writes: > 3) Improved conflicts. > I'm not sure this is really merge-upstream specific, but often people > have difficulty understanding why a conflict happened, especially with > this command it seems. > I know there has been some work on improving the

Re: Recipes vs. Looms vs. pipelines

> "jam" == John Arbash Meinel writes: >> The last times I had to merge trunk in these cases was... long >> ago and mainly had to do with branches left dormant too long. >> >> Vincent >> jam> Interesting. I have to do it all the time because of NEWS issues... In th

Re: Recipes vs. Looms vs. pipelines

> "Aaron" == Aaron Bentley writes: Aaron> That is fine with me, but do you have any comments on Aaron> the original issue? Aaron> The original discussion was about "down-thread; pull; up-thread -a" Aaron> feeling more natural than "pull -d submit:; merge; commit;". It was

Re: Recipes vs. Looms vs. pipelines

>>>>> "jam" == John Arbash Meinel writes: jam> Vincent Ladeuil wrote: >> I knew it was going to be a long day :) >> >> So I made an mistake in my argumentation. Hurrah ! I was wrong, I >> learned something new ! That was a

Re: Recipes vs. Looms vs. pipelines

I knew it was going to be a long day :) So I made an mistake in my argumentation. Hurrah ! I was wrong, I learned something new ! That was a good day finally :) Thanks to Aaron and John for that. Why I thought the merge was done in the other direction is still a bit of a mystery[1]... but irrelev

Re: Recipes vs. Looms vs. pipelines

> "jam" == John Arbash Meinel writes: jam> Nope. You still have to merge it into your top thread and commit that. jam> So the history in the top thread is the same. Hmmm, for me, history == graph, the graphs are different, so the histories are different. trunk -- my changes -- trunk

Re: Recipes vs. Looms vs. pipelines

>>>>> "Aaron" == Aaron Bentley writes: Aaron> Vincent Ladeuil wrote: >>>>>>> "jam" == John Arbash Meinel writes: jam> Actually, those produce the exact same history. >> >> No. >> No. A

Re: Recipes vs. Looms vs. pipelines

>>>>> "jam" == John Arbash Meinel writes: jam> Vincent Ladeuil wrote: >>>>>>> "barry" == Barry Warsaw writes: >> >> >> barry> loomnon-loom barry>

Re: Recipes vs. Looms vs. pipelines

> "barry" == Barry Warsaw writes: barry> loomnon-loom barry> barry> bzr down-thread rocketfuel bzr merge ../devel barry> bzr pullbzr commit -m'Merge rocketfuel' barry> bzr u

Re: your thoughts wanted on bzr team UDD focus

>>>>> "James" == James Westby writes: James> On Tue Dec 01 03:04:30 -0500 2009 Vincent Ladeuil wrote: >> Things we can safely add to this list: >> >> * add hooks allowing james_w to plug a customized merge for >> chan

Re: your thoughts wanted on bzr team UDD focus

>>>>> "jml" == Jonathan Lange writes: jml> On Tue, Dec 1, 2009 at 7:02 PM, Max Bowsher wrote: >> Vincent Ladeuil wrote: >> >>> * import all branches defined in a git repo instead of only HEAD >>> >>&g

Re: your thoughts wanted on bzr team UDD focus

> "martin" == Martin Pool writes: martin> I'd like to get a sanity check from UDD people on martin> what the Bazaar team is going to do for our 2.1 martin> release, which will have a feature freeze in February martin> and go into Karmic. >> From the previous threads, it s

Re: bzr loves Ubuntu @ UDS

> "Michael" == Michael Hudson writes: Michael> Well, at least currently the machine very much needs to be Michael> in the data centre. Though the thought of using EC2 for Michael> code imports has crossed my mind before now... Hmm, may be I misunderstood something. I thought t

Re: bzr loves Ubuntu @ UDS

>>>>> "Michael" == Michael Hudson writes: Michael> Vincent Ladeuil wrote: >>>>>>> "Michael" == Michael Hudson writes: >> >> >> Michael> Memory usage for large git imports is a real issue.

Re: bzr loves Ubuntu @ UDS

> "Michael" == Michael Hudson writes: Michael> Memory usage for large git imports is a real issue. Maybe Michael> we need to commission a big ass machine for initial imports Michael> and use that, but it hasn't happened yet. What do you call a big ass machine exactly ?

bzr loves Ubuntu @ UDS

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 understandi