[09:02] <ogra_> hmm, whats that update-apt-xapian-index issue in the image builds ?
[09:03] <Laney> bug #1019581
[09:03] <ubot2> Launchpad bug 1019581 in software-center "update-apt-xapian-index crashed with ImportError in /usr/share/apt-xapian-index/plugins/software-center.py: cannot import name index_name" [Critical,Confirmed] https://launchpad.net/bugs/1019581
[09:04] <ogra_> ah
[09:04] <jibel> ogra_, I just pinged mvo on #ubuntu-desktop
[09:04] <ogra_> we really should have a variable to skip it
[09:04] <ogra_> so you can temporary build images without updated index
[09:11] <cjwatson> jibel: I just nagged on #ca-internal too
[09:11] <cjwatson> ogra_: I considered that but it seems entirely possible that this breaks some upgrades too, so I didn't want to work around it and help to take it off the radar
[09:11] <cjwatson> Can't be that hard to just fix
[09:12] <ogra_> indeed ...
[09:13] <ogra_> hmm, seems i forgot to disable kubuntu preinstalled builds
[09:18] <ogra_> did someone just disable them in bzr ? i get a merge conflict
[09:19] <ogra_> (looks like /srv/cdimage.ubuntu.com/etc/crontab was hacked directly or some such
[09:19] <ogra_> )
[09:20] <ogra_> ... hmm, and wasnt installed with the crontab command at all
[09:20] <cjwatson> I'm pretty sure Daviey did that a few days back
[09:20] <ogra_> hmpf
[09:21] <cjwatson> merge conflict> you mean when trying to pull into /srv/cdimage.ubuntu.com?
[09:21] <ogra_> right
[09:21] <cjwatson> Are you on top of it or do you need help disentangling it?
[09:21] <ogra_> i removed the kubuntu preinstalled line while the tree has it manually commented and seemingly uncommitted
[09:22] <ogra_> well, just editing it in the tree and a bzr resolved should do, no ?
[09:22] <cjwatson> For the time being, yes
[09:22] <ogra_> k
[09:22] <cjwatson> I usually check 'diff -u etc/crontab <(crontab -l)' rather than just blindly overwriting the live copy
[09:23] <cjwatson> Because it's very common to only comment out the live copy during milestone prep
[09:23] <ogra_> yep
[09:31] <ogra_> hmm, thats quite a big diff
[09:35] <cjwatson> That's just "uncomment lots"
[09:35] <cjwatson> Let me resolve some of it
[09:35] <ogra_> yes
[09:36] <ogra_> well, i'm just pulling the original crontab into the tree here
[09:36] <cjwatson> Try that
[09:36] <cjwatson> etc/crontab should never have been edited locally in the first plac
[09:36] <cjwatson> e
[09:37] <ogra_> right, i know
[09:37] <cjwatson> Either commit to bzr, or do it just in 'crontab -e' for temporary stuff, not a weird halfway house
[09:37] <cjwatson> committer: CD Image <cdimage@nusakan>
[09:37] <ogra_> well, it shouldnt have gotten into that condition in the first place
[09:37] <cjwatson>   fix etc/crontab conflict (please dont edit directly on nusakan, or at least commit it to the tree)
[09:38] <cjwatson> The irony hurts.  Please edit on your local system not on nusakan
[09:38] <ogra_> yes, that was me
[09:38] <ogra_> how can i, i dont get the conflict over here
[09:38] <cjwatson> Good grief, scp exists
[09:38] <cjwatson> Can I resolve this?
[09:38] <ogra_> yes, i'll keep my fingers off it
[09:39] <cjwatson> I realise this isn't your fault but I want to carefully get this back to a sane state ...
[09:40] <ogra_> so how would you do it (for the next time) ? scp the whole tree from /srv/cdimage to your local machine and discard your existing working tree ?
[09:40] <cjwatson> Heck no
[09:40] <cjwatson> 1443 should never have been committed; that should have been reverted on nusakan instea
[09:40] <ogra_> then i dont get it
[09:40] <cjwatson> d
[09:41] <cjwatson> If it's already edited locally on nusakan, then you can edit there for the purpose of undoing things or resolving the conflict, but you must never commit on nusakan
[09:41] <cjwatson> You can copy the file back locally to commit
[09:42]  * ogra_ is irritated ... 
[09:43] <ogra_> so there was a change on nusakan that wasnt committed ... usually i get an uncommitted changes error here, and bzr would refuse to go on with the merge ... why didnt that happen here
[09:44] <cjwatson> Because it was only not committed in the working tree you were pulling into
[09:44] <cjwatson> Not the tree you were running merge in
[09:44] <ogra_> it merged and created the conflict .. that shouldnt be possible
[09:44] <ogra_> oh, stacked trees
[09:44] <ogra_> *lightbulb*
[09:44] <cjwatson> It's all resolved now.
[09:45] <ogra_> thx
[09:55]  * ogra_ wonders why ac100 initrds are suddenly built with lzma
=== yofel is now known as Guest57033
[11:17] <rbasak> What's the quantal publishing interval now? 20 minutes?
[11:18] <cjwatson> 30
[11:19] <cjwatson> It starts at :03 and :33
[11:20] <rbasak> Thanks
[11:25] <cjwatson> (FWIW, not that this is well-known or anything, but I believe anyone in Canonical can check out lp:lp-production-crontabs now and the times are there)
[11:26] <cjwatson> cocoplum-lp_publish in particular
[11:35] <rbasak> It seems I can - thanks.
[11:43] <xnox> last daily image is from 29th, long weekend for the CD-building? (this is daily-live/quantal/amd64)
[11:44] <cjwatson> xnox: bug 1019581
[11:44] <ubot2> Launchpad bug 1019581 in software-center "update-apt-xapian-index crashed with ImportError in /usr/share/apt-xapian-index/plugins/software-center.py: cannot import name index_name" [Critical,Fix released] https://launchpad.net/bugs/1019581
[11:44] <cjwatson> broke image builds all weekend
[11:45] <cjwatson> I whined about it on Saturday morning but nobody relevant was aruond
[11:45] <cjwatson> *around
[11:46] <Laney> and you can see why they failed if you look at the livefs build logs, for example http://people.canonical.com/~ubuntu-archive/livefs-build-logs/quantal/ubuntu/20120702/livecd-20120702-amd64.out
[11:48] <xnox> cjwatson: Laney ok thanks
[11:52] <mvo> cjwatson: should be fixed now
[11:52] <mvo> sorry for the breakage
[11:53] <cjwatson> ta
[12:58] <cjwatson> Oops, didn't catch that in time ...
[12:58] <cjwatson> mute queue new quantal-release
=== Guest57033 is now known as yofel
[14:15] <mterry> Hello!  Would someone mind pushing a few packags from quantal-proposed to quantal for me?   update-manager, ubuntu-release-upgrader, and update-notifier source packages
[14:15] <cjwatson> unmute queue new quantal-release
[14:16] <cjwatson> mterry: done
[14:17] <mterry> cjwatson, thanks!
[14:55] <mterry> Is there any reason aisleriot is in main still?  It's not seeded anymore
[14:56] <seb128> mterry, it's not? it was still on the CD for precise I though
[14:56] <seb128> mterry, did we drop it since?
[14:56] <mterry> seb128, I just ran seeded-in-ubuntu, but I thought it had been dropped in precise, so I might be wrong here
[14:57] <mterry> seb128, yup, still recommended by ubuntu-desktop
[14:57] <seb128> mterry, cool
[14:57] <mterry> seb128, seeded-in-ubuntu's got some 'splaining to do
[14:59] <Laney> We should drop it though.
[14:59] <Laney> Nobody's going to work to get guile-2.0 into main
[14:59] <Laney> seb128: ^^^
[14:59] <Laney> (plus guile-2.0 FTBFS on arm)
[15:00] <tumbleweed> hrm, it's in the manifest
[15:00]  * tumbleweed looks at why seeded-in-ubuntu got that wrong
[15:01] <Laney> tumbleweed: it's not wrong
[15:01] <Laney> https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.quantal/view/head:/desktop#L119
[15:01] <Laney> oh, false /negative/
[15:01] <Laney> because it depwaits?
[15:01] <seb128> Laney, or we should got back to the old version
[15:01] <tumbleweed> ah, one of those
[15:02] <tumbleweed> we should display a warning for that, as it's a known issue
[15:02] <seb128> Laney, if it depwaits we can just delete the source and reupload the old version ;-)
[15:02] <seb128> without having to tweak
[15:02] <Laney> really?
[15:02] <Laney> the source would be published, no?
[15:02] <seb128> Laney, yes, pitti did that one beofre
[15:02] <seb128> once
[15:02] <cjwatson> Err
[15:02] <cjwatson> If you can that's a Soyuz bug and I find it quite doubtful
[15:02] <seb128> Laney, soyuz doesn't check for that
[15:03] <cjwatson> I would really very much prefer that you did not do that
[15:03] <Laney> I remember going backwards but I can't remember why it was ok
[15:03] <micahg> the source being published isn't a problem, it's the binaries that are an issue (you just can't use the same version again)
[15:03] <Laney> there are no binaries.
[15:03] <seb128> right
[15:03] <seb128> cjwatson, hum k, it was handy though :p
[15:03] <cjwatson> Please just be explicit and bump the version forward if you're going to revert
[15:03] <Laney> maybe it hadn't been published yet or something
[15:03] <micahg> that's why totem is precise didn't have a crazy version number
[15:03] <cjwatson> explicit is better than implicit
[15:03] <micahg> *in
[15:03] <seb128> micahg, yes
[15:04] <Laney> ah, it was even cjwatson wot done it last time
[15:04] <micahg> cjwatson: why should it matter if a source was published?  that's just used for uploading new sources, as long as there were no binaries, there's no apt/dpkg issue
[15:04] <cjwatson> haha, ref?
[15:04] <Laney> https://launchpad.net/ubuntu/+source/totem/+publishinghistory
[15:04] <seb128> cjwatson, https://launchpad.net/ubuntu/+source/totem/+publishinghistory
[15:04] <seb128> 2012-01-10 01:10:17 CET 	Deleted 	Precise 	release 	main 	gnome 	3.3.4-0ubuntu1~precise1
[15:04] <seb128> 2012-01-13 12:37:39 CET 	Superseded 	Precise 	release 	main 	video 	3.0.1-0ubuntu13
[15:05] <seb128> cjwatson, 3.3.4 was uploaded by error and never built
[15:05] <cjwatson> micahg: I'm aware of that, there are all sorts of things inside Soyuz and in API scripts that make stronger assumptions about ordering that are reasonable as long as people aren't playing silly buggers
[15:05] <seb128> pitti deleted the source and we reuploaded 3.0.1 which worked
[15:05] <Laney> wasn't pitti
[15:05] <seb128> oh, I though it was
[15:05] <Laney> expand "deleted" and you can see
[15:05] <seb128> sorry
[15:05] <cjwatson> Hah, right, I wouldn't do that again
[15:06] <seb128> heh
[15:06] <cjwatson> But I guess that means it works at least sometimes
[15:06] <micahg> cjwatson: I guess that's the "trouble" of knowing the code :)
[15:06] <cjwatson> Indeed
[15:06] <seb128> Laney, well anyway I guess we are good to do a new.is.really.old upload
[15:06]  * Laney would still prefer to replace it with sgt-puzzles or nethack :P
[15:06] <cjwatson> Laney++
[15:07] <cjwatson> I guess that the above hack mostly worked because things tend to do archive.getPublishedSources()[0]
[15:08] <cjwatson> So it ends up being most recent by upload order
[15:08] <cjwatson> All this stuff is in code I'm not convinced anyone gets right though, which is a reason I'm newly wary of it
[15:08] <cjwatson> The other day I discovered three different implementations of roughly the same ancestry detection logic, none of which I entirely agreed with
[19:03] <cjwatson> infinity: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1019514 passed my test, FWIW
[19:03] <ubot2> Ubuntu bug 1019514 in livecd-rootfs "Need to be able to generate images with -proposed in sources.list" [High,Fix committed]
[19:12]  * infinity checks the log.
[19:13] <infinity> 0 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
[19:14] <infinity> ^-- This would probably take some live-build hacking, but an upgrade post-debootstrap would be a good idea.
[19:14] <infinity> cjwatson: Maybe not critical for proposed testing, but would seem the right thing to do for actual point-releases, so -security and -updates packages are installed on the image.
[19:15] <infinity> cjwatson: Oh, never mind, that happens later in the log.  I guess someone thought of this already. :P
[19:16] <infinity> cjwatson: Looks good, then.
[19:17] <infinity> cjwatson: Fast-tracking it through.  Thanks for the test output.
[19:19] <cjwatson> Great, thanks.  And as you say.
=== robbiew is now known as robbiew-afk
=== bjf is now known as bjf[blood]
=== robbiew-afk is now known as robbiew
=== bjf[blood] is now known as bjf