=== highvoltage is now known as jocarter
=== nigelbabu is now known as nigelb
[03:51] <RAOF> The xorg-server that's about to land in quantal-proposed should not be copied out of there until the rest of the stack has been uploaded and built.
[03:52] <RAOF> But no one would do that, anyway, because until that happens it'll be obvious that the archive won't be installable :)
[07:04] <tkamppeter> Yesterday I discussed the CUPS SRU with infinity because the SRU has 5 of 6 bugs verified and the reporter of the remaining bug does not answer. The conclusion is what I have written in comment #79 of bug 973270. Infinity wanted to pass cups to -updates. He did not do so (forgotten?). Can someone pass the CUPS SRU to -updates?
[07:04] <ubot2> Launchpad bug 973270 in cups "Printer does not provide REQUIRED job history." [High,Fix committed] https://launchpad.net/bugs/973270
[08:29] <tkamppeter> seb128, are you in the release team?
[08:33] <seb128> tkamppeter, no, why?
[08:34] <tkamppeter> seb128, yesterday I have talked with infinity here about the CUPS SRU and he told me that he wanted to move it to -updates but he did not do so.
[08:34] <tkamppeter> Anyone of the release team around here?
[11:10] <tkamppeter> infinity, hi
=== doko_ is now known as doko
[11:10] <tkamppeter> cjwatson, hi
[11:11] <cjwatson> I'm in a coffee shop today, can't do anything particularly complex
[11:11] <cjwatson> In any case *please* don't send me contentless pings :)
[11:30] <tkamppeter> cjwatson, yesterday I have talked with infinity here about the CUPS SRU and he told me that he wanted to move it to -updates but he did not do so.
[11:31] <tkamppeter> cjwatson, can you move it to -updates?
[11:32] <cjwatson> I'd rather leave that to infinity if he already has context - my net access here is very slow and it will be difficult to go through bugs.  infinity said "I'll look into it more", not "I'll do it".
[11:33] <cjwatson> So I don't want to jump into the middle of that if he just got interrupted thinking about it.
=== rsalveti` is now known as rsalveti
[12:43] <zul> can an archive admin please review python-django-compressor, python-django-appconf, and python-warlock it will make horizon installable again (and ill buy them a beer when I see them next)
[12:44] <zul> they have been sitting in binary-new for a while
[12:52] <cjwatson> zul: Why not licence debian/* under the same terms as the upstream source, which is recommended practice?
[12:53] <zul> cjwatson: oh i wasnt aware of that, i can fix that up though
[13:00] <cjwatson> python-django-compressor looks like it needs to mention the Apache 2.0 licence of rjsmin.py in debian/copyright to
[13:01] <cjwatson> o
[13:02] <cjwatson> zul: oh, and typo in debian/rules, "get-orig-soruce"
[13:02] <skaet> cjwatson,  would you mind reviewing http://paste.ubuntu.com/1120535/?
[13:02] <cjwatson> but that lot's minor, so accepting -django-compressor
[13:02] <zul> cjwatson: ill fix that up in the next upload
[13:02] <cjwatson> skaet: could I have a diff against the current crontab?
[13:03] <skaet> cjwatson,  sure,  doing
[13:04] <cjwatson> skaet: also, we should never be using ARCHES= in crontab
[13:04] <cjwatson> it's hard to maintain and etc/default-arches should be sufficient
[13:06] <skaet> cjwatson, http://paste.ubuntu.com/1121384/
[13:06] <cjwatson> zul: for python-warlock using the same licence as upstream is even more important because Apache-2.0 and GPL-2 are incompatible
[13:07] <zul> cjwatson:  do you want to reject it do i can update it?
[13:07] <cjwatson> zul: it barely scrapes through as distributable because debian/* is GPL-2+, and Apache-2.0 and GPL-3 are compatible - but still, better to keep it simple
[13:07] <cjwatson> so this isn't a reject, but a licence change in -0ubuntu2 would be good, IMO
[13:08] <zul> cjwatson: ack
[13:08] <cjwatson> skaet: sorry, I should have said - diff -u is basically always lots easier to read than plain diff
[13:09] <cjwatson> old-style diffs are there for compatibility but they're awful :)
[13:11] <skaet> cjwatson,  no worries,  here you go: http://paste.ubuntu.com/1121396/
[13:12] <cjwatson> skaet: as far as I can make out, the ARCHES= bits there are equivalent to http://paste.ubuntu.com/1121399/ in etc/default-arches
[13:12] <cjwatson> I think people have said that changing default-arches is a bit awkward because we can't easily see the state at release, but hey, it's in bzr
[13:13] <cjwatson> and then drop the ARCHES= throughout and it should be a more readable diff
[13:13] <cjwatson> "buildlive kubuntu dvd precise" needs to be "buildlive kubuntu-dvd dvd precise" so that it puts the right bits in the squashfs
[13:14] <skaet> cjwatson,   sorry,   didn't make the changes between the two version,  just did the diff -u,  I'll work on adding the ARCHES to the defaults,  just wanted to see if there was something else that needed fixing...  (which there appears to be ;) )
[13:15] <cjwatson> right.  I think the diff I pasted should be fine for that
[13:15] <cjwatson> I don't see any other problems :)
[13:15] <cjwatson> coo, xorriso supports mac/efi hybrids now
[13:16] <cjwatson> I wonder if I can get us onto that for quantal
[13:22] <skaet> cjwatson,  the changes to etc/default-arches matches expectations.    ARCHES pulled, kubuntu-dvd added.   http://paste.ubuntu.com/1121414/
[13:25] <cjwatson> skaet: great.  looks good to me now.
[13:25] <cjwatson> shall I just commit my default-arches changes directly since I have them here?
[13:26] <skaet> thanks cjwatson,   yes,  please commit your default-arches,  will save me recreating it.
[13:26] <skaet> I'll upload after you finish
[13:27] <cjwatson> skaet: done
[13:48] <skaet> cjwatson,  new  version committed and pushed,  now at 1475
[13:52] <cjwatson> skaet: cool, pulled.  do you know why the mythbuntu quantal daily build is commented out in the live crontab but not in bzr?
[13:52] <ogra_> just fyi, i just changed the boot code for omap/omap4 in debian-cd and run a server testbuild now
[13:53] <ogra_> ah, done already, that was faster than i thought, ignore the noise :)
[13:54] <skaet> cjwatson,  hmm,  oversite from A3.   They aren't participating the milestones,  but daily should be turned back on.   (not releasing with 12.10, but participating in 12.04.1)
[13:54] <cjwatson> OK, odd that live and bzr were ever allowed to get out of sync though, even so
[13:55] <cjwatson> maybe it would be simpler to arrange for mythbuntu dailies not to be posted to the tracker for quantal, so that we can leave the dailies enabled and not worry about them?
[13:57] <stgraber> I don't know the details but maybe they want the dailies to post to the daily milestone on the tracker, but not to any "real" milestone
[13:58] <cjwatson> mm, trickier because cdimage doesn't know the current milestone (it lets u-a-t worry about that)
[13:59] <cjwatson> ah well, not important for now
[14:14] <dpm> hi, is there anyone from the SRU team who can sponsor jbicha's ubuntu-docs upload to precise-proposed? We need this upload to be able to prepare the language packs for 12.04.1, and any help would be appreciated. Here's the associated bug
[14:14] <dpm> bug 1019441
[14:14] <ubot2> Launchpad bug 1019441 in ubuntu-translations "Please update the ubuntu-docs Precise package with translations for 12.04.1" [High,Triaged] https://launchpad.net/bugs/1019441
[14:15] <stgraber> dpm: why do you need someone from the SRU team to sponsor an upload?
[14:16] <dpm> stgraber, I'm not familiar with the process, so if it's not the SRU team, then whoever who can sponsor the upload would do :)
[14:16] <stgraber> dpm: yeah, anyone with upload rights can do it. I'm taking a quick look now
[14:17] <dpm> excellent, thanks stgraber!
[14:26] <stgraber> dpm: failed to build locally but might be a problem with my environment, pushing to a PPA for test build, if that works I'll push to quantal + precise-proposed
[14:28] <dpm> stgraber, thanks. Would you mind keeping me up to date on how it goes? Once ubuntu-docs is in precise-proposed, I'd like to start building the language packs tomorrow, so that they can be ready by the 2nd.
[14:29] <stgraber> dpm: well, you'll need an SRU team member to approve it to -proposed before that, the queue for that is almost 30 packages long last I checked, so might need some direct poking to get it processed before the others
[14:31] <dpm> ok, gotcha
[14:57] <tkamppeter> infinity, hi
[15:07] <jdstrand> fyi, I'm dealing with the kde component mismatches
[15:40] <babyface_> jamespage, hi James
[15:44] <babyface_> jamespage, for bug:https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1028453,  it failed the test job in jenkins many days, when will it be fixed?
[15:44] <ubot2> Ubuntu bug 1028453 in ubuntu-meta "Quantal Ubuntu Server minimal install oversized" [High,Confirmed]
=== Ursinha` is now known as Ursinha
=== babyface_ is now known as baby_face
=== baby_face is now known as babyface_
[16:15] <infinity> tkamppeter: Relax, man. ;)
[16:50] <babyface_> anybody know why there are no builds for  quantal desktop ?
[16:50] <stgraber> let me check
[16:51] <babyface_> stgraber,  ok thanks.
[16:52] <stgraber> cron job is there, so it might be that it failed, checking the logs
[16:53] <infinity> livefs builds went fine.
[16:53] <stgraber> yeah, livefs looks good but debian-cd never ran
[16:54] <stgraber> at least, I don't see a daily-live log for 20120731
[16:55] <infinity> well, Colin and Oli were both fiddling with debian-cd yesterday.
[16:55] <infinity> Or today, or whatever.
[16:55] <stgraber> ok, I'll try to re-run just the debian-cd part of the build, see what happens...
[16:56] <stgraber> running
[16:57] <babyface_> thanks guys.  normally， how long will it take to finish the build ？
[16:58] <stgraber> should just be a few minutes as I'm not rebuilding the livefs, just the .iso
[16:58] <babyface_> stgraber, ack. thanks.
[17:00] <infinity> stgraber: The complete lack of logfile at all is a bit weird.
[17:01] <infinity> stgraber: And the reason is because buildlive is still running. :P
[17:01] <infinity> 21663 ?        S      0:00 ssh -n -o StrictHostKeyChecking no -o BatchMode yes buildd@royal.buildd /home/buildd/bin/BuildLiveCD -l -A powerpc -d quantal lubuntu
[17:01] <stgraber> that's lubuntu
[17:01] <infinity> Oh, so it is.
[17:01] <infinity> Mentally filtered the 'l'
[17:01] <stgraber> hehe :)
[17:02] <infinity> But... No logfile seems nearly impossible to manage, with the set of files that have been edited recently.
[17:02] <infinity> Maybe I'm missing an interim edit where someone briefly broke the world at just the wrong time.
[17:02]  * infinity shrugs.
[17:03] <stgraber> the only logical explenation would be a messed up crontab at the time the build started, anything else should have sent a failure e-mail (either debian-cd or cron)
[17:04] <stgraber> hmm, though MAILTO isn't set in the crontab, so I'm not exactly sure who would be notified of a failure (that's not handled by one of the other e-mail)
[17:08] <infinity> It would be in ubuntu-archive's spool.
[17:08] <infinity> Err, in cdimage's.
[17:09] <stgraber> which appears to be empty... odd
[17:09] <infinity> It's not empty.
[17:09] <infinity> But it certainly has no failure mails after the livefs build.
[17:10] <stgraber> oh, is "mail" lying to me (or it's just me not remembering how that stuff works ;))
[17:10] <infinity> Oh, wait.
[17:10] <infinity> I didn't scroll far enough up. :P
[17:10] <infinity> lockfile: Sorry, giving up on "/srv/cdimage.ubuntu.com/etc/.lock-build-image-set-ubuntu-daily-live"
[17:10] <infinity> Another image set is already building!
[17:11] <skaet> ?
[17:11] <infinity> So, stale lock from someone fiddling, I assume.
[17:11] <infinity> Mystery solved.
[17:11] <stgraber> oh, fun, apparently "mail -u cdimage" isn't the same as "mail"... go figure
[17:12] <infinity> I just read the spool raw with 'less'.
[17:12] <stgraber> that works too ;)
[17:12] <jbicha> hi, could an AA handle bug 1031416 for me?
[17:12] <ubot2> Launchpad bug 1031416 in ubuntu "Please remove mess from the blacklist & sync mess 0.146-2 (multiverse) from Debian non-free" [Wishlist,Confirmed] https://launchpad.net/bugs/1031416
[17:15] <stgraber> babyface_: built
[17:20] <babyface_> stgraber, got it. thanks.
[17:21] <infinity> jbicha: Will do.
[17:21] <jbicha> infinity: thank you
[17:30] <skaet> stgraber, infinity - have synched the crontab up with the version in cdimage/etc/crontab that contains the precise daily builds now.
[17:32] <infinity> Hrm?
[17:32] <infinity> precise daily builds were already running.
[17:32] <infinity> Or, so my mail told me.
[17:32] <skaet> infinity,  not for all the images on the manifest for 12.04.1
[17:33] <skaet> and some of the archs that were showing up on the precise dailies  weren't needed either, and just consuming arm/powerpc cycles for no reason.
[17:34] <skaet> cjwatson made some changes to the default-arches file earlier as well, as part of this.
[17:34]  * infinity sees that.
[17:35] <skaet> so,  it should all nicely match the 12.04.1 manifest now.
[19:49]  * stgraber prepares for the easiest MIR ever, zram-config
[19:52] <stgraber> infinity: hmm, did you notice all the install failure bugs against zram-config?
[19:56] <infinity> stgraber: Erm.  I don't even understand how it's possible that people upgrading from oneiric are upgrading zram-config, when it didn't exist previously...
[20:02] <infinity> stgraber: Probably doesn't help that some of them are mix-and-matching it with some random PPA package.
[20:02] <ogra_> why does it suddenly show up on main images and needs a MIR ?
[20:02] <infinity> ogra_: It's not being pulled in by anything...
[20:02] <infinity> stgraber: Why is it being MIRed?
[20:03] <stgraber> ogra_,infinity: I want to depend on it from ltsp-client
[20:03] <ogra_> right, the only image actually using it is ac100
[20:03] <ogra_> stgraber, ah !
[20:03] <stgraber> ogra_: we discussed it at the LTSP session at UDS, we killed the compcache code a while back but never replaced that by the zram equivalent
[20:04] <infinity> stgraber: Well, I have a mail from the "random PPA zram package" guy about trying to consolidate them.
[20:04] <infinity> stgraber: But I think both should go away, and we should fix the zram bits in initramfs-tools (which I didn't know existed when I did zram-config)
[20:04] <stgraber> that'd work too
[20:04] <ogra_> oh, i remember
[20:05] <stgraber> at least until we try to get rid of the initramfs ;)
[20:05] <stgraber> (which isn't likely to ever happen for LTSP considering how much stuff we do in the initramfs ;))
[20:05] <infinity> Well, I could pull it out of initramfs and turn it into a hybrid hook.
[20:06] <infinity> (ie: something that runs from either initramfs or the base system, but not both)
[20:06] <infinity> I dunno.  I haven't put much thought into it, since it "just works" for me.
[20:07] <infinity> The problems for people with conflicting packages are obvious, but some of the bug reports don't seem to fall into that category, so a bit of investigation here might be worthwhile.
[20:08] <stgraber> yeah, it also "just works" here and I'm pretty sure it'll also just work for LTSP without causing extra bug reports as it's a pretty well controlled environment (auto generated chroot that people usually don't mess with)
[20:08] <infinity> Does ltsp rely on tmpfses in any meaningful way?
[20:08] <stgraber> yeah
[20:09] <infinity> I might have hit a curious kernel bug here where swapping a tmpfs to zram causes explosions.
[20:09] <stgraber> as in, we don't have persistent storage and use tmpfs for everything ;)
[20:09] <infinity> I need to figure out a solid reproducer so I can debug and lay blame.
[20:09] <infinity> But if what I suspect is happening is happening, that could be a bit of a blocker for you.
[20:10] <stgraber> yeah, I can see some people finding this annoying ;)
[20:11] <stgraber> so far I've been mostly using zram on my swap-less systems which tend to have a lot of RAM and not using much tmpfs, thin clients are kind of the opposite of that, so booting a 64MB thin client might be interesting ;)
[20:11] <infinity> Yeah.  I have a ton of RAM, but I eat it all for tmpfs builds.
[20:12] <infinity> And I can't be positive without a controlled test case, but I *think* my oopses and panics are hitting at around the point where the tmpfs would be swapping.
[20:12] <infinity> Which would be when the kernel then tries to free some RAM for zram, so it can swap the tmpfs.
[20:12] <infinity> Whch all should work, in theory, but...
[20:12] <infinity> So many moving parts.
[20:14] <infinity> Maybe I can boot with MEM=$something_small and try to get a solid reproducer.
[20:14] <infinity> But that sounds like something I don't want to do today. :P
[20:16] <jbicha> aw, android-tools looked kinda useful
[20:17] <infinity> https://bugs.launchpad.net/ubuntu/+source/zram-config/+bug/956859 is weird too.
[20:17] <ubot2> Ubuntu bug 956859 in zram-config "zram-config terminates with status 2. zram swaps not enabled" [Undecided,Confirmed]
[20:18] <infinity> Waitaminute.
[20:18] <infinity> stgraber: I wonder if some/many of the upgrade bugs are due to people loading the zram module manually, perhaps in something like /etc/modules.
[20:18] <infinity> stgraber: Would explain the "using defaults" sort of message in the above bug.
[20:21] <stgraber> yeah, so I guess you may want to check for zram being already loaded in pre-start and "echo 'something vaguely useful' && stop" if that's the case
[20:21] <stgraber> should be better than failing
[20:21] <infinity> Hrm.
[20:21] <infinity> Also could be people without /usr mounted?
[20:21] <infinity> (I use free(1) in the init job, which is in /usr/bin)
[20:21] <infinity> But... Runlevel [2345] should guarantee /usr, surely.
[20:23] <infinity> Meh.  Anyhow, I should look at the PPA package, consolidate any good ideas he has, and add a Conflict to the package, at least.
[20:34] <ScottK> Publisher broken?
[20:34] <ScottK> Installation-guide has been pending for an hour.
[20:35] <ScottK> There it is.
[20:35] <infinity> ScottK: It's running.  Could have just been a slow run.
[20:35] <ScottK> Asking must have been the fix.
[20:35] <ScottK> OK.
[20:36] <ScottK> Very slow.
[20:36] <ScottK> Thanks for checking.
[20:37]  * ScottK was waiting for that because he's wanting to figure out how much of the K* stuff coming back into Main is real.
[20:37] <slangasek> I'm very puzzled by https://launchpad.net/ubuntu/+source/installation-guide/20100518ubuntu6
[20:37] <slangasek> published in precise in April; published in quantal 2 minutes ago?
[20:37] <slangasek> infinity: yes, runlevel [2345] guarantees /usr; and quantal forward, "out of the initramfs" will also guarantee it
[20:38] <ScottK> It got demoted and repromoted
[20:38] <slangasek> ah, ok
[20:38] <ScottK> No idea why that happened, but C-M got very noisy and some of it seems related.
[20:39] <micahg> I think jdstrand was trying to demote that
[20:39] <jdstrand> I mentioned earlier I was working on that
[20:39] <jdstrand> I had to bail because of poxml in kdesdk. I filed a bug on it
[20:40] <ScottK> What bug?
[20:40] <micahg> jdstrand: why should installation-guide make a difference, it has no reverse dependencies
[20:41] <ScottK> micahg: Isn't it used in D-I?
[20:41] <micahg> oh, is it?
[20:41] <jdstrand> micahg: it is seeded in platform.quantal/supported-installer-common
[20:41] <micahg> hrm, /me kicks seeded-in-ubuntu
[20:41] <ScottK> Even better, fix it.
[20:42] <jdstrand> I didn't notice that myself and thought I was ok, then saw the report and put everything back until bug #1031478 can be fixed
[20:42] <ubot2> Launchpad bug 1031478 in installation-guide "Drop Build-Depends on poxml" [Wishlist,Triaged] https://launchpad.net/bugs/1031478
[20:43] <micahg> ScottK: I fear the issue is server side
[20:43] <jdstrand> not to worry, I will put it all back
[20:44] <ScottK> micahg: Face your fear and step into it.
[20:44] <ScottK> jdstrand: Thanks.  I'll ignore C-M for awhile then.
[20:44] <jdstrand> I thought about just removing the seed entry, but then thought about the network-less installs
[20:44] <micahg> ScottK: I'd rather have someone else fix it now rather than waiting on me for a month
[20:45] <micahg> tumbleweed: ^^ can you have a look at seeded-in-ubuntu not showing stuff in supported-installer-common?
[20:47] <tumbleweed> sure. That sounds like something I just need to tell it to look at
[20:47] <micahg> jdstrand: alternatively, if poxml doesn't have interdependencies on the rest of kdesdk, it could be packaged separately (might be acceptable to Debian as well)
[20:48] <ScottK> micahg: It's part of KDE.
[20:48] <ScottK> It won't be acceptable to split the source in Debian, I can guarantee you.
[20:48] <micahg> ScottK: right, but it's a tool usable outside of KDE as well
[20:49] <ScottK> micahg: Yes.  So is everything that's not part of the libs/workspace.
[20:49] <micahg> ah, the binary is already usable without the bulk of stuff, so it's just a main/universe issue which needs to go away, nevermind :)
[20:50] <ScottK> It's a separate binary package, so from a Debian perspective there's zero incentive to split the source and it's a maintenance burden.
[20:50] <ScottK> Yeah.
[21:12] <ScottK> slangasek: So are you the partner repo dude now or just the guy that didn't duck fast enough when Skype needed doing?
[21:14] <slangasek> ScottK: I'm "the partner repo dude", and I'm also still trying to find a patsy for skype ;)
[21:14] <skaet> ogra_,  http://paste.ubuntu.com/1122227/  <-- this address the concern you raised last month?
[21:16] <skaet> slangasek, infinity,  also in that diff is updating the make-web-indices to indicate that mythbuntu and ubuntustudio were approved for LTS.
[21:18] <slangasek> skaet: the latter makes sense to me.  the former I'll let ogra_ speak on
[21:18] <skaet> slangasek,  thanks.
[21:21] <ogra_> skaet, yeah, looks fine to me
[21:21] <skaet> thanks ogra_.
[21:22] <ogra_> your dev machine is actually called ubuntu ? :)
[21:22] <tumbleweed> micahg: to make it appear, it looks like we need to parse a lot more of germinate-output. It's currently only looking at the supported seed's file. Not its dependency tree (I'm not at all familiar with germinate)
[21:23] <micahg> tumbleweed: hrm, no idea here
[21:24] <skaet> ogra_  just doing this on one of my test machines, since it was handy. :)
[21:25] <ogra_> heh
[21:28]  * ogra_ is finally done soldering our magic USB cables to autoboot the pandas
[21:28] <ogra_> phew