[07:36] <Mirv> hi! could someone ack or no-ack bug #1047067? we'd very much like to start proper testing of compiz <IP_ADDRESS> soon and include the patch.
[07:36] <ubot2> Launchpad bug 1047067 in compiz "[FFE][UIFE][regression] workspace switcher layout needs adjustments" [Medium,In progress] https://launchpad.net/bugs/1047067
[07:36] <Mirv> it's essentially a regression fix
[07:36] <Mirv> to bring back 12.04 behavior
[09:31] <Laney> what seed (branches) are used for the china images?
[09:47] <Laney> nm
[10:07] <bencer> hi, anybody could have a look at this? https://bugs.launchpad.net/ubuntu/+source/zentyal-samba/+bug/1043654 we have been waiting already some days without reply, thanks!!
[10:07] <ubot2> Launchpad bug 1043654 in zentyal-samba "[FFe] New version of zentyal-samba" [High,Confirmed]
[11:01] <cjwatson> Right, I'm about to start landing/deploying the first third or so of the Python rewrite of cdimage, and I'll do an Ubuntu desktop respin to test
[11:01] <cjwatson> If I'm lucky and my existing test cases are sufficiently good, nobody will notice
[11:02] <cjwatson> But in the real world some of you will probably get some error mail
[11:06] <Laney> didrocks: ^ could you NEW u-s to main and remove u-d-s please?
[11:07] <didrocks> Laney: sure, looking
[11:07] <Laney> if it checks out, of course
[11:07] <Laney> I pushed the seed change, needs refreshing after that
[11:09] <didrocks> Laney: ok, source NEWed in main, I trust you on the C/R as you experimented it ;)
[11:12] <Laney> it works as long as u-d-s is removed :-)
[11:13] <didrocks> Laney: ok, and ubuntu-default-settings removed (thanks for the arch:all change btw), so they get published in the same publisher run
[11:14] <didrocks> Laney: you will take care of refreshing ubuntu-meta once the promotion in main is published?
[11:14] <Laney> I didn't do that, someone else must have done it in bzr
[11:14] <Laney> yeah sure
[11:15] <didrocks> Laney: I remember mentionning it to jbicha, wasn't sure he has done it :)
[11:15] <didrocks> Laney: thanks!
[11:31] <cjwatson> Gosh, that actually seems to have worked
[11:31] <cjwatson> Didn't try a full build, just for-project ubuntu cron.daily-live, but still, that'll have gone through the whole rewritten publish-daily
[11:34]  * ogra_ applauds
[11:38] <Daviey> cjwatson: is there a documented list of changes,improvements ?
[11:39] <cjwatson> * Test suite
[11:39] <cjwatson> ..
[11:39] <cjwatson> It's intended to be otherwise feature-equivalent right now
[11:39] <cjwatson> I have enough to do with a rewrite without extending it as well :-)
[11:40] <Daviey> cjwatson: is this the seeds to integration with Offspring?
[11:40] <cjwatson> That's not the primary driver, although it may help that later
[11:41] <cjwatson> (Or it may not; Offspring may well just use a subprocess interface)
[11:41] <cjwatson> It's more that some things have reached the point of being unchangeable without a test suite
[11:41] <cjwatson> And some things have been pushing the boundaries of being sensible to do in shell for a while
[11:42] <Daviey> right
[11:42] <Daviey> Is it also now easier to test code on a local machine?
[11:42] <cjwatson> ./run-tests
[11:42] <Daviey> i don't just mean pass tests.. i mean do feature work?
[11:43] <Daviey> as in, will it create an output :)
[11:43] <cjwatson> No
[11:43] <cjwatson> But for practically all feature work (once the rewrite is actually complete) it should be possible to write unit tests
[11:43] <Daviey> super
[11:43] <cjwatson> Remembering that most changes to image *content* have nothing to do with cdimage
[11:44] <cjwatson> (Ironically you can't yet do ./run-tests on nusakan because its unittest is too old, but maybe that will help persuade people to stop committing stuff on nusakan)
[11:45] <cjwatson> The other driver for this is that I have permission to kill off the private code branch of cdimage and open-source everything as long as it goes along with being in Python with a test suite
[11:45] <Daviey> oooooor, just people committing without running tests b:(
[11:46] <cjwatson> I have a rusty nail here for such purposes
[11:48] <cjwatson> I'll be moving the primary hosting to LP at some point, which will make it more or less impossible to commit from nusakan
[11:50] <Daviey> cjwatson: You underestimated the will of wrongdoers
[11:51] <cjwatson> Daviey: Well, speaking of which, I found (and committed) an uncommitted change in the deployed tree on nusakan which added a certain<EMAIL_ADDRESS>to etc/notify-addresses
[11:51] <cjwatson> I wonder who might have done that?
[11:52]  * xnox Daviey-- for being naughty
[11:53] <ogra_> lol
[11:53] <Daviey> cjwatson: hmm, that is odd... because stgraber told me he committed it. :/
[11:55] <Daviey> Oh wait, stgraber uncommited it.
[11:56] <Daviey>  <stgraber> Daviey: looks like you manually commited something on nusakan (etc/notify-addresses) preventing pulling the new revisions of cdimage-deployment... I "fixed" it by uncommiting your change for now
[11:59] <Daviey> 12:58 -!- cjwatson<EMAIL_ADDRESS>has quit [QUIT IN DISGUST]
[12:05] <Daviey> cjwatson: I'd like to work out what happend.. I thought i committed it to /srv/cdimage.ubuntu.com/bzr/private/cdimage tree..
[12:06] <Daviey> stgraber says he uncommitted something manually commited
[12:07] <Daviey> it's not unlike me to mess up, but i'd like to work out how.
[12:09] <cjwatson> There was no sign of a commit there
[12:09] <cjwatson> But it's hard to tell now
[12:09]  * cjwatson doesn't really feel like messing around with bzrlib to find uncommitted revisions :)
[12:10] <Daviey> Lets just draw it up that i suck.
[12:10] <xnox> cjwatson: $ bzr heads ?
[12:10] <knome> i know that "irc is not the optimal place to ask" (yeah right), but could a release team member give us an ack on bug 1049658
[12:10] <ubot2> Launchpad bug 1049658 in ubiquity-slideshow-ubuntu "[Xubuntu] Office slide needs to be updated" [Undecided,New] https://launchpad.net/bugs/1049658
[12:11] <knome> (for UIFe)
[12:11] <cjwatson> xnox: ah yes
[12:11] <cjwatson> Well, I can only see an uncommit from stgraber on 2012-06-07, which was to crontab and doesn't seem related
[12:11] <Laney> it's not optimal because it interrupts people rather than letting them get to it when they're in the right context.
[15:19] <rtg> infinity, doko: bug #1049650 indicates a binutils regression. Any thoughts on reverting the most recent update ?
[15:19] <ubot2> Launchpad bug 1049650 in linux "Regression: "Undefined video mode" with 3.5.0-14.16" [Medium,In progress] https://launchpad.net/bugs/1049650
[15:21] <doko> rtg, as already said on -kernel: I'll provide you with (some) toolchain builds
[15:22] <rtg> doko, oh, I thought your suggestion to use https://launchpad.net/ubuntu/quantal/+source/binutils/<IP_ADDRESS>20816-2ubuntu1 _was_ your tool chain build
[15:23] <doko> rtg, well, first trying to find out if it's a binutils or gcc issue, then trying to locate the issue
[15:23] <rtg> doko, then you're agreed now that it is a binutils issue ?
[15:24] <slangasek> toolchain, at least
[15:24] <slangasek> could still be a gcc regression tripped by a binutils change?
[15:24] <doko> yes, looking into this.
[15:25] <rtg> ok, I'll leave it to the experts.
[15:25] <doko> rtg, how can the kernel package be used to just build this one binary?
[15:26] <rtg> doko, I don't understand what you're asking. I updated binutils in my local chroot, then built and booted the resulting kernel.
[15:27] <doko> rtg, I was asking for a smaller testcase than building the complete package including n kernels
[15:27] <slangasek> because that's a limiting factor for those of us who don't have kernel team hardware ;)
[15:28] <rtg> well, doko has access to kernel team HW IIRC
[15:28] <slangasek> and access to install new binutils for testing?
[15:29] <rtg> but there are shortcuts to the build process that only build the kernel binary without headers and udebs, etc.
[15:29] <rtg> slangasek, uh, thats more difficult
[15:29] <slangasek> right, and I think that's what doko wants
[15:29] <slangasek> the shortcut
[15:29] <rtg> fakeroot debian/rules clean; fakeroot debian/rules binary-generic
[16:50] <doko> rtg: two binutils packages in my home on chinstrap. please check the newer one first, the older one only if the newer one doesn't work. afk now for some hours, will be back later tonight
[16:50] <rtg> doko, ack
[16:51] <rtg> doko, binutils_<IP_ADDRESS>20907-3_amd64.deb first ?
[16:52] <doko> rtg, yes, reverted a commit, which is the only touching generic files. everything else is arch specific in the update
[16:52] <doko> and the older is one is just the <IP_ADDRESS>20816-2ubuntu1 rebuilt with recent gcc
[16:53] <rtg> doko, ok, will do
[16:53] <doko> have to run
[17:15] <rtg> doko, binutils_<IP_ADDRESS>20907-3_amd64.deb seems to have done the trick. The kernel boots at least.
[17:15] <rtg> (quantal-amd64)rtg@salmon:~/ubuntu/ubuntu-quantal$ dpkg -l|grep binutils
[17:15] <rtg> ii  binutils                             <IP_ADDRESS>20907-3
[17:20] <cjwatson> GRUB 2.00 uploaded, whee
[17:24] <plars> Daviey: of interest... I get OOM with 256M, but not with 512.  Would logs showing the oom be useful? It sounds to me like the fact that I'm getting these OOMs, and failing to install completely with 128M would be a bug rather than an indication we should raise the minimum right?
[17:24] <cjwatson> Are you following the directions in lowmem/README?
[17:25] <cjwatson> If not, please do, it would be more helpful than raw figures with full installs
[17:39] <plars> cjwatson: it's not clear to me what you're suggesting I do from that README.  It seems to indicate how it can be simulated if you don't actually boot with low amounts of memory and you want to simulate the behavior with lower amounts of RAM, but in my case, I'm controlling the ram with kvm
[17:53] <dobey> mterry: ^^ is taht ubuntu-sso-client upload to precise-proposed yours?
[17:53] <mterry> dobey, yeah
[18:06] <doko> Riddell, please remind http://people.canonical.com/~ubuntu-archive/nbs.html (attica)
[18:07]  * Laney eyes twisted
[18:07] <Laney> doko: did you have FFe for that?
[18:07] <doko> Laney, bug fixes only
[18:08] <Laney> https://launchpadlibrarian.net/115528804/twisted_12.0.0-1ubuntu1_12.2.0-1.diff.gz ?
[18:08] <doko> Laney, while you are here, why the difference in haskell armhf/armel build failures
[18:13] <Laney> there is definitely a bug in the compiler, but for armel failing when armhf builds, check if the buildd in question is on precise
[18:15] <Laney> now, I clearly see "Features" in that diff...
[18:15] <Laney> when does twisted become installable again?
[18:19] <doko> in about 2h. why do you need to depend on this catch-all python-twisted package?
[18:20] <doko> if can't explain it, call it a compiler error ...
[18:20] <doko> if you can't explain it, call it a compiler error ...
[18:21] <balloons> So when I install today's daily on a machine which has 12.04.1, I am not given the option to upgrade. In addition, if I choose to install 12.10 alongside 12.04, I cannot chose the encryption or lvm options. This all seems correct, except me not being able to upgrade via the cd. Is this intended because of the LTS, because it's not final cd, or something else?
[18:22] <Laney> if the compiler segfaults, I'll call it a compiler error
[18:22] <Laney> but nice attempt at trolling me
[18:22] <doko> sorry, didn't see the bug report
[18:22] <xnox> balloons:  I was pondering about that as well. I'm not sure why. There are ~ bug reports about os_prober and missing fuse udeb
[18:23] <xnox> balloons: it should offer to upgrade (well lifecd style upgrade which is reinstall while preserving files)
[18:23] <balloons> xnox, right.. I thought so.. :-)
[18:24] <ogra_> funnily i get upgrade notifications for every arm SD card i plug into my 12.04 desktop :)
[18:24] <xnox> lol
[18:24] <balloons> xnox, so heh, do you want a new bug on this?
[18:24] <xnox> balloons: yeah....
[18:24]  * xnox how did I end up being the $installer dev?!
[18:25] <ogra_> you grabbed all these bugs :)
[18:26]  * xnox reassigns a few xnox -> ogra_
[18:26] <balloons> xnox, ohh you are?! Excellent, I've got more to assign you! :-)
[18:26]  * xnox /0\
[18:26]  * xnox where is the UTF characters head-desk when you need it
[18:28] <TheLordOfTime> lol...
[18:30] <Laney> doko: btw, it's not me depending on python-twisted, but kubuntu, ubuntu-server and ubuntustudio
[18:30] <Laney> so if it's buggy to do that take it up there :-)
[18:39] <mterry> Friendly poke about UIFe bug 1049231 and friends (unity-greeter ui nits)
[18:39] <ubot2> Launchpad bug 1049231 in unity-greeter "[UIFe] The gap between the user name and password entry is too large in the greeter" [Undecided,New] https://launchpad.net/bugs/1049231
[18:45] <doko> rtg: http://sourceware.org/ml/binutils/2012-09/msg00159.html
[18:51] <plars> xnox: since you're now officially the install expert... :)
[18:52] <xnox> hm?
[18:52] <plars> xnox: any idea why, if I have a 1GB disk, and select LVM, the max it wants to use is 813MB?
[18:52] <plars> it seems to want to leave about 200MB on the floor
[18:53] <xnox> plars: 1GB is actually less in real units and then -5% reserved for root ~= 813?!
[18:56] <plars> xnox: I seem to recall seeing what it came up with at one point and seeing about 200M unpartitioned space after this though, let me see
[18:56] <xnox> 953.674 - 5% = 905.35 no clue
[18:56] <xnox> so we are missing 92 MB
[18:57] <xnox> plars: oh when you do autopartition it creates separate /boot partition outside lvm?!
[18:57] <xnox> on my machine it's 300 MB but I'm not sure if I manually adjusted it.
[18:57] <plars> xnox: the 5% doesn't come into play until you format though, I'm talking about the partitioner saying it can only do 813MB of the 1G disk
[18:58] <plars> hmm, maybe that's it, let me see what it gives me
[19:00] <balloons> xnox, trying to file that bug.. I found two more
[19:00] <balloons> yikes
[19:01] <xnox> balloons: i will read them in my bug-mail tomorrow morning with coffee
[19:01] <xnox> ;-)
[19:02] <balloons> :-) technically one is apport related, the other is almost certainly only apport
[19:02] <xnox> lol
[19:58] <doko> infinity, do you understand https://launchpadlibrarian.net/115821556/buildlog_ubuntu-quantal-armhf.binutils_<IP_ADDRESS>20913-1ubuntu1_FAILEDTOBUILD.txt.gz ?
[20:12] <balloons> cjwatson, so the new grub2 package - -where all is it going to propagate to (image wise?)? Will I need to manually upgrade myself, or will I be automatically upgraded?
[20:12] <Laney> hmm
[20:13] <Laney> the china images I respun earlier didn't get pushed to http://china-images.ubuntu.com/quantal/daily-live/
[20:13] <Laney> ah
[20:15] <Laney> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-chinese-edition/quantal/daily-live-20120913.1.log
[20:15] <doko> rtg, slangasek: new binutils now pubished for amd64, i386. still building on the other archs. afk now
[20:16] <Laney> seems it needs to download from ubuntu-zh_CN/
[20:28] <slangasek> doko: thanks for the fix :)
[20:37] <Laney> cjwatson: ^ looks like UBUNTU_DEFAULTS_LOCALE doesn't make it through somehow
[20:57] <infinity> doko: Dunno.  Cosmic rays, or lamont messing with things.
[20:58] <doko> infinity, context? otoh lamont is good enought as an excuse ;-P
[20:59] <infinity> doko: Context being that lamont's been upgrading Pandas to precise today, and ain was on that list.
[20:59] <Laney> oh, /that's/ what it was
[20:59]  * Laney yays
[20:59] <infinity> doko: So, it's entirely possibly that what appeared to be file corruption was just external influence.
[21:00] <infinity> doko: Then again, still could have been cosmic rays and a random bit flip. ;)
[21:00] <doko> good to know
[22:34] <lamont> infinity: ain was down for several weeks before finally getting a fresh install today
[22:35] <lamont> infinity: that was the bad burn when we were testing pxeboot
[22:35] <infinity> lamont: Oh, right.  Well, no idea what doko's buildus interruptus was, but no big deal.
[22:36] <lamont> well, I did toss 5 others through the chomper this morning, since we were messing with PB01