[00:21] <claydoh> what happened to libkgeomap for digikam/kipi in wily?
[00:25] <sgclark> no clue
[00:52] <claydoh> https://bugs.launchpad.net/ubuntu/+source/digikam/+bug/1459443
[00:53] <claydoh> but I can't find why it is gone or if it is coming back
[00:54] <sgclark> umm well http://osdir.com/ml/ubuntu-bugs/2015-08/msg16295.html
[00:55] <sgclark> seems odd
[00:56] <sgclark> ahh indeed it is qt4 only
[00:56] <sgclark> won't work in wily
[00:57] <claydoh> ahh I suspected it was something like that.
[00:58] <claydoh> changelog makes it confusing
[00:59] <claydoh> http://changelogs.ubuntu.com/changelogs/pool/universe/d/digikam/digikam_4.12.0-0ubuntu5/changelog
[07:58] <lordievader> Good morning.
[10:15] <yossarianuk>  Hi - does this mean that plasma 5.4.2 will be the default version in 15.10 (i.e no need to add a PPA, etc) -> http://scarlettgatelyclark.com/2015/kubuntu-plasma-5-4-2-ready-testing-come-join-the-fun/
[10:16] <sitter> such was the plan
[10:24] <yossarianuk> sitter: groovy !
[10:24] <yossarianuk> been running 15.10 for about a month - seems far more stable than kubuntu 15.04 (plasma 5.2.x)
[10:43] <allee> I've installed wily to test 5.4.2: End of wily install a popup appears that asks to reboot.  The button shows not text until I hovered over the button and bg turned blue (starts with fg=bg maybe?)
[10:45] <clivejo> allee: what GPU?
[10:48] <allee> clivejo: Mac Air with Intel
[10:51] <clivejo> can you try running the installer (DVD, USB etc) in nomodeset ?
[10:51] <soee_> allee: yeah iv seen this, teh whole button ws kind of white ?
[10:54] <allee> soee_:  light gray like the the rest of the dialog
[10:55] <soee_> i wonder if it is gone  now when ubiquity was updated to match breeze theme
[10:55] <soee_> i think sitter ws working on ubiquite styles
[10:55] <howlymowly> hi everyone..   i installed amd fglrx drivers on kubuntu wiley with a radeon 6850   get a black screen after rebooting ..   is this a known bug?
[10:57] <clivejo> soee_: http://postimg.org/image/rvk14tdl5/
[10:58] <allee> soee_:  about login delay.  Where with fresh install and 5.4.1:  Login in -> progress bar does to ~ 66%  25 sec delay, then ~80%, then ~90% with ~ 2-3 sec, them plasma desktop shows
[10:58] <allee> soee_:  5.4.2 installing right now ...
[11:00] <soee_> clivejo: daily or beta2 ?
[11:00] <clivejo> seems to be an issue with Nvidia GPU
[11:01] <allee> soee_: with 5.4.2 progress bar goes to 100% in a few secs.  Then ~ 20 - 23 sec delay before plasma-desktop is shown
[11:01] <clivejo> if I run the DVD in nomodeset the graphics are fine
[11:03]  * allee lunch. bbl.
[11:03]  * clivejo goes in search of lunch too
[11:38] <Riddell> yossarianuk: if people test it
[11:46] <BluesKaj> Hi all
[11:51] <Riddell> hi BluesKaj, able to test plasma 5.4.2 on wily?
[11:51] <Riddell> http://scarlettgatelyclark.com/2015/kubuntu-plasma-5-4-2-ready-testing-come-join-the-fun/
[11:54] <BluesKaj> Riddell:  yup, I'm there
[12:02] <BluesKaj> no luck with the ppa tho, invalid or it can't be read
[12:04] <BluesKaj> ok , already had it , was commented
[12:29] <Riddell> sitter: could we please have jenkins on mobile.kci able to ssh into thrift? bshah is working on the mobile image creation
[12:29] <sitter> Riddell: why does it need to get onto thrift? thrift is supposed to die, no?
[12:29] <clivejo> now got message bus issues in PIM
[12:30] <bshah> sitter: it hosts plasma-mobile's images and its crazy ubuntu-image server
[12:30] <Riddell> sitter: I don't know, what's your thinking there?
[12:30] <clivejo> Did Plasma 5.4.2 change anything with dbus?
[12:31] <sitter> Riddell, bshah: relocate to taspar?
[12:31] <sitter> actually, relocate to s3fs. but for now relocate to taspar
[12:31] <sitter> I am not entirely sure why we need a dicated server to host random files
[12:32] <sitter> Riddell: what user on thrift
[12:32] <sitter> and what key
[12:32] <sitter> and what what
[12:33] <clivejo> what where?
[12:33] <Riddell> sitter: jenkins@taster to log into ubuntu@thrift using whatever key jenkins can know about
[12:35] <sgclark> morning
[12:35] <Riddell> hola sgclark!
[13:16] <BluesKaj> after upgrading from the staging ppa the only difference I've seen so far is the pulseaudio install/upgrade, otherwise systemsettings5  as root still doesn't apply the settings changes so the toolbar fonts on any root opened files, for editing, still aren't large enough to read on my large screen monitor/tv (one of my major peeves so far). This peeve obviously has nothing to do with the staging ppa upgrades
[13:16] <BluesKaj> so=to
[13:17] <soee_> BluesKaj: did you noticed maybe some 'lag' when loading system after sddm screen ?
[13:17] <soee_> liek the progress bar stops for ~ 15/20 sec
[13:17] <BluesKaj> soee_:  no more than usual , no
[13:19] <BluesKaj> and I rebooted twice after reseting my audio prefernces to alsa without pulse and gstremaer backend
[13:20] <BluesKaj> but soee_ I don't have fast booting pc , still using ancient hdd '
[13:22] <zokiDimovski> soee_: I have that 'lag' on my 2 machines. Just yesterday on my laptop it took about 60sec. On my PC it took about 30sec.
[13:23] <BluesKaj> going to switch to 256Gb SSD next month ..maybe then it will show any boot speed problems
[13:50] <Riddell> sgclark: any plans to upload 5.4.2?
[13:50] <sgclark> how is the testing going?
[13:51] <Riddell> sgclark: good for me, BluesKaj just said same issues but reported no problems, clivejo had an issue in kdepim but I think that's unrelated
[13:52] <Riddell> allee installed it and had a problem on logout, dunno if that's continuous or caused by 5.4.2
[13:52] <sgclark> mm yeah pim is applications.
[13:53] <mamarley> sgclark: I am using it too and I haven't had any new issues. :)
[13:53] <sgclark> And I am shocked applications is ok in wily. I am fighting with patches in backports.
[13:54] <Riddell> oh?
[13:54] <Riddell> sgclark: I can upload 5.4.2 if you're busy fighting with backports
[13:54] <sgclark> kde4libs lots of fuzz that needs adjustments
[13:55] <sgclark> sure Riddell go ahead. If you are satisfied. I have been using 5.4.2 fine as well.
[13:55] <clivejo> +1 seems ok to me
[13:56] <BluesKaj> upgrading from the staging ppa on my laptop atm , will report back in a few mins
[14:14] <sgclark> Riddell: please refresh my memory on kde-l10n repo does not exist and seems I remember some script or something?
[14:14] <Riddell> sec..
[14:14] <Riddell> sgclark: https://community.kde.org/Kubuntu/Packaging/L10nOperatorGuide
[14:14] <sgclark> thanks
[14:14] <Riddell> lp:~kubuntu-packagers/kubuntu-packaging/kde-l10n-common  has the wily packaging
[14:14] <Riddell> Backport branches are kde-l10n-common-${release}-backports
[14:15] <Riddell> so you probably need to make that branch if you're doing backports
[14:16] <allee> Riddell, sgclark: it's on login not logout and 'only' a delay of ~ 20 sec.  Same for 5.4.1 just in an earlier login stage.   With 5.4.1 it often required several alt-ctrl-dels to logout.  That worked with 5.4.2 the few times I tried.   I had not much luck testing 5.4.2 yet as the mac air stopped booting.  Black screen (of death?)  :-(   Still trying to find out what's wrong
[14:17] <soee_> cool stuff https://plus.google.com/+MartinGr%C3%A4%C3%9Flin/posts/WZaDPFpoXSB
[14:27] <allee> os-prober does not find the wily installation of this morning.  Does Mac GPT partitioned disk require a different tool?
[14:27] <sgclark> I have never had a mac sorry
[14:53] <Riddell> shadeslayer's a mac head
[15:19] <Riddell> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20151001-wily.html#kubuntu a few things to tidy up there
[15:53] <allee> sgclark: I'd to installed wily 2 times. Everytime I logged in to 5.4.2 for the 1st time I got a black screen with a cursor.  Plasmashell was not running.   alt-ctrl-del and 2nd login and plasma-desktop started fine this time.
[15:54] <allee> I've to leave now, but will retry with a freshly created user once more later
[15:54] <sgclark> that does not sound good
[15:54] <sgclark> let see if there is a bug
[15:56] <sgclark> Riddell: did you upload 5.4.2?
[16:02] <allee> sgclark: mhh, created new user with user manager,  quit system-settings,  went into user-manager again and the account create a minute ago is not listed.
[16:03] <allee> But when I used the new user to login into plasma, I got no black screen.  plasmashell was started the 1st time.  So can't really reprocude  what happend with 1st user with uid 1000.
[16:03] <allee> bbl
[17:34] <allee> user-manager bug: I've created an unpriv. user.  Logged in as this user and created a 3rd user.  This Worked!  Weird!  User manager only ask for pw.  1st and 2nd user have same pw.  So I'm not sure if in the back, the 1st admin user id was used instead of the current unpriviliged one.  Nevertheless: something is wrong.
[17:36] <allee> application luncher bug:  favorites and all other tab but 'leave'  use the old oxygen icons. not the flat breeze icons.
[17:37] <sgclark> woah, I do not see that at all
[17:38] <sgclark> allee: can you please file a bug report? obviously this need further investigation but I will not be able to get to it today.
[17:38] <sgclark> pretty please :)
[17:38] <allee> k
[17:40] <sgclark> assign it to me and I will deal with where it needs to go.
[17:41] <sgclark> attach any logs you might find useful
[17:48] <allee> bbl
[18:07] <yofel> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20151001-wily.html#kubuntu
[18:07] <yofel> not too bad..
[19:33] <soee_> lordievader: did ou tested already 5.4.2 ?
[19:34] <allee> sgclark: oxygen icons in launcher fixed themself. Now almost all icons but e.g. firefox are from breeze. I'm puzzled!!!!!
[19:35] <soee_> oh i see that 5.4.2 wasalready pushed to archive
[19:37]  * clivejo nods
[20:41] <clivejo> are dbuild logs mostly the same?
[20:43] <yofel> depends on the way dh is invoked and whether DH_VERBOSE is set. In general they're mostly the same as there are fixed build targets that have to be met
[20:44] <clivejo> yofel: is there a tool to compare how and why kreports builds onmy local machine, but fails on LP?
[20:44] <yofel> not that I know of.. your best bet usually is to try and replicate the LP environment as close as possible
[20:53] <lordievader> soee_: Haven't really been near a computer today. Is that for Wily?
[20:53] <soee_> lordievader: yes. but it is already in Wily so no need for more testing.
[20:54] <lordievader> Ah, I see. Oh well, earliest time I could test would be monday anyways.
[20:54] <lordievader> Hmm, seems 5.4.2 ain't in Gentoo yet.
[21:42] <allee> sgclark: I could not reproduce the user manager bugs.  Frustrating.
[21:43] <allee> sgclark: nevertheless 5.4.2 seems to be fine so far.  No real (reproducable) bug found yet.  Great work!


[08:18] <vish> doctormo: whats wrong with your site.. i cant seem to access it :(
[10:13] <czajkowski> duanedesign: I did in the end
[10:13] <czajkowski> but still havn't been able to get it to show all my old mail
[10:13] <czajkowski> which does exist
[18:59] <czajkowski> aloha
[19:29] <doctormo> hey czajkowski, not much going on today
[19:40] <vish> is anyone able to access doctormo's site?
[19:40] <vish> or is doctormo just blocking me! ;p
[19:40] <doctormo> nope
[19:40] <doctormo> vish: Sorry about that, I can check with my ISP
[19:41] <vish> doctormo: thanks.. :)
[19:41] <doctormo> vish: Do you get a response from trying to contact doctormo.org?
[19:42] <vish> doctormo: FF just lets me "The server at doctormo.org is taking too long to respond."
[19:42] <vish> the usual connection timed out..
[19:43]  * vish tries chrome
[19:44] <vish> nope that doesnt help either
[19:44] <doctormo> vish: Can you use the command line? try and do a whois on doctormo.org and then try a wget.
[19:46] <vish>  whois http://paste.ubuntu.com/488859/
[19:47] <vish> doctormo: wget http://paste.ubuntu.com/488862/
[19:47] <vish> it keeps on retrying..
[19:48] <doctormo> vish: OK so it's not a dns problem and it's going to the right place.
[19:50] <vish> doctormo: yeah , i just noticed this happening since your last post about the wallpaper.. not sure when the last time i accessed your blog directly , might be a month ago.
[19:50] <paultag> It's alive here.
[19:50] <paultag> Must be some kind of ISP issue
[19:50] <doctormo> vish: Can you access left-click.org?
[19:51] <vish> doctormo: nope , same retry loop
[19:52] <paultag> vish: `traceroute doctormo.org'
[19:55] <vish> paultag: hmm , i tried using the nettools , its not able to trace past my local router
[19:55]  * vish was lazy to install traceroute package ;p
[19:56] <paultag> vish: http://<IP_ADDRESS>/
[19:56] <vish>  got a huge list of no reply
[19:59] <vish> same, no go..
[20:00] <paultag> vish: well then it's not DNS. It's either ISP or doctormo's host's rules
[20:00] <vish> paultag: traceroute for ya : http://paste.ubuntu.com/488871/
[20:00] <paultag> Well that's rough
[20:02] <paultag> That looks like the ISP
[20:02] <paultag> Not sure, though
[20:03] <paultag> I'm no networking guru
[20:10] <pleia2> does traceroute to other places work? that's not even getting *to* your isp's gateway, which doesn't make sense
[20:11] <pleia2> anyway, sometimes routing on the internet breaks and you can't get certain places, it wasn't designed to be what it is ;)
[20:15] <paultag> +1 pleia2
[20:15] <paultag> pleia2: We need to destroy the web asap
[20:15] <pleia2> lol
[20:15] <paultag> <-- Not kidding
[20:16] <paultag> The stateless seven layer model is not working well
[20:16] <pleia2> honestly the more I learn about routing and "how the internet works" the more amazed I am that it works at all :)
[20:16] <paultag> +1
[22:22] <doctormo> Man I'm agitated that Collin Pruitt posted Chapter 07 of Ubunchu (in japanese) to the planet before we've even had chance to translate it. Most uncool.
[22:57] <doctormo> nigelb: Apparently there is a block list coming from this site http://www.wizcrafts.net/chinese-iptables-blocklist.html can you check if this blocklist is involved?


[00:51] <cjwatson> slangasek: ^- avoid breakage from including signed kernel in image
[00:53] <cjwatson> slangasek: does the .efi.signed image work when booted using a legacy BIOS, by any chance?
[00:54] <cjwatson> OK, I'm going to have to defer booting images with signed kernels until tomorrow, just too tired
[00:55] <infinity> cjwatson: Wait, we're shipping a signed and unsigned kernel?
[00:55] <infinity> cjwatson: Wouldn't a signed one Just Work, even in the absence of anything that cares if it's signed?
[00:55] <cjwatson> Well we have to ship an unsigned one somewhere due to the mechanics
[00:56] <infinity> cjwatson: I meant in images, obviously the archive has one.
[00:56] <cjwatson> As for images it depends how specific the format is to EFI, I forget
[00:56] <cjwatson> Hence my question
[00:56] <infinity> Yeah, fair.
[00:57] <cjwatson> If anyone else wants to work on it, I think the steps are: for desktop, make livecd-rootfs move vmlinuz-*.efi.signed to kernel-$FLAVOUR if it exists - or possibly to kernel-$FLAVOUR.efi.signed depending on the answer to my question above, in which case debian-cd will need some work to handle that; for server, I have a suspicion that the easiest way is going to be to modify linux-signed to spit out a kernel-signed-image ...
[00:57] <cjwatson> ... udeb so that debian-installer can use it
[00:57] <cjwatson> again depending on the answer to my question above
[00:58] <cjwatson> hopefully BIOSes can boot vmlinuz-*.efi.signed and it's all simpler
[00:58] <infinity> Hopefully.
[00:58] <infinity> Otherwise, this is all disgusting.
[00:58] <infinity> Well, more disgusting than I thought it was.
[00:58] <infinity> Which was already a pretty vile.
[00:59] <infinity> cjwatson: In other news, that mlwhatever compiler is just awful.
[01:00] <cjwatson> The underlying .efi file is just a copy of vmlinuz, extension notwithstanding
[01:00] <infinity> cjwatson: It does some initial bootstrappy bits, and then just sits there with no output for (many) hours, doing... presumably... something to itself.
[01:01] <infinity> cjwatson: Right, I has hoped it was just a vmlinuz, and I'm also hoping that the signing process took care to make sure it didn't mangle it in any awful ways.
[01:01] <infinity> cjwatson: Thus leading to the theory that one can just ship a single signed image.
[01:02] <infinity> cjwatson: (Which would also mean that linux-signed should be the one spitting out the linux-image-$(abi)-generic package, while the linux source just spits out linux-generic-raw to sign from, but it's a bit too late in the cycle to rearchitect that. :P
[01:02] <cjwatson> The cert table goes at the end, so it's probably OK, but I was hoping somebody more awake had boot-tested it.
[01:03] <cjwatson> Maybe I can install it here and ask kvm.  Yay multiarch.
[01:04] <cjwatson> "error: premature end of file /boot/vmlinuz-blah"
[01:04] <infinity> Lame. :/
[01:04] <cjwatson> actually maybe that's just insufficient syncing
[01:04] <cjwatson> 'kvm -snapshot -hda /dev/sda' is handy but produces nonintuitive results sometimes
[01:06] <cjwatson> Right, that boots fine if I actually sync all the data to disk
[01:06] <infinity> \o/
[01:06] <infinity> So, this may sound awful and vile.
[01:06] <infinity> But instead of moving things in build scripts, and other ickiness.
[01:07] <infinity> Why not just, along with having linux-signed-image depend on linux-image (whatever), we also have it replace that same version, and install the kernel to vmlinuz-$(abi)-flavour and be done with it?
[01:07] <cjwatson> I've already changed the installer to handle linux-signed-* specially in various ways, and GRUB to handle .efi.signed.  Changing package and file names would involve undoing or at least rethinking all of that.
[01:07] <infinity> Replaces will keep it as the file installed, even if you reinstall the underlying kernel.
[01:07] <cjwatson> IOW tell me this two weeks ago.
[01:08] <infinity> Well, I just looked at it now. :P
[01:08]  * infinity gets a time machine.
[01:08] <slangasek> cjwatson: .efi.signed image> sorry, are you asking whether grub can boot the vmlinuz.efi.signed under BIOS?
[01:08] <cjwatson> Happy to make it more rational for R.  For now I just need to make it work.
[01:08] <cjwatson> slangasek: I was until I tested it and found that it can.
[01:08] <slangasek> ok
[01:09] <cjwatson> Actually what I care about is syslinux not grub, but I think the odds are good
[01:09] <cjwatson> So that I can just have one /casper/vmlinuz and have it work on both
[01:09] <infinity> cjwatson: Does Q have a plan for keeping signed images up to date, too?
[01:09] <cjwatson> infinity: kernel team will just reupload linux-signed as part of each sru stack
[01:09] <infinity> cjwatson: Yes, but...
[01:09] <infinity> cjwatson: I see no meta for it.
[01:10] <cjwatson> Look harder.
[01:10] <infinity> Or, again, wasn't paying attention.  *looks*
[01:10] <cjwatson> linux-signed-{,image-}generic
[01:10] <infinity> Ahh, there it is.
[01:10] <infinity> Check.
[01:10] <cjwatson> base-installer will install that as appropriate.
[01:10] <infinity> I missed that bit.
[01:10] <cjwatson> Assuming I got all the code right.
[01:11] <infinity> So, still feels better to not have two kernels installed, but otherwise, meh.  This works.
[01:12] <slangasek> right, but that's not a last-minute-before-release kind of change
[01:12] <infinity> Nope.
[01:12] <infinity> See above, re: time machines.
[01:13] <cjwatson> So actually this means my ubuntu-defaults-image approach is a bit suboptimal.  I'll upload a new version tweaking that.
[01:15] <cjwatson> This is basically all the set of weird build script nonsense that I expected to have to change anyway :-)
[01:20] <cjwatson> ogra_: You didn't push your most recent livecd-rootfs changes to bzr.  Fixing up by hand, but please bind your bzr branch so that this doesn't happen again.
[01:26] <cjwatson> OK.  If somebody could review ubuntu-defaults-builder 0.43 and livecd-rootfs 2.90, that would be very helpful, and then at least the desktop images should be using a signed kernel in the morning.
[01:26] <cjwatson> I'll figure out how to do the same for server tomorrow.
[01:28] <stgraber> I'll review them
[01:29] <cjwatson> Thanks.
[01:29]  * cjwatson -> zonk
[01:31] <stgraber> good night
[01:44] <ScottK> jbicha: Does Bug #713423 need any changes for ubuntu-docs to be complete?  If not, please remove the docs task.
[01:44] <ubot2> Launchpad bug 713423 in ayatana-design "[FFe/UIFe] Unity launcher gets cluttered when having multiple partitions and/or external volumes attached" [High,Fix committed] https://launchpad.net/bugs/713423
[01:50] <infinity> doko_: Oh, duh.  armhf takes so much longer than armel because the testsuite runs twice, I'm betting.
[01:50] <infinity> doko_: unix + unix/-mthumb
[01:51] <infinity> doko_: Err, wait.  That's all backward.  armel takes longer.  And both run -mthumb.
[01:51] <infinity> doko_: Nevermind me.
[01:51] <infinity> doko_: (Why DOES armel take so much longer?  Is v7 optimisation really that awesome?)
[01:55] <ScottK> jbicha: Same for Bug #876017.
[01:55] <ubot2> Launchpad bug 876017 in ayatana-design "[FFE][UIFE] Window management - We should be able to close windows in spread mode" [Medium,Fix committed] https://launchpad.net/bugs/876017
[02:12] <jbicha> I'd like to try to retarget 876017 to R but LP won't let me
[02:15] <ScottK> Let me try.
[02:17] <ScottK> Weird.  No "R" there for me either.
[02:19] <infinity> There's a bug whereby a series disappears if... Some condition.
[02:19] <infinity> Maybe when it's been targetted then rejected?
[02:19] <infinity> Don't recall.
[02:19] <ScottK> Thanks.
[02:20] <ScottK> I unsubscribed the release team, so my caring factor has declined.
[02:20] <infinity> Shouldn't matter anyway, since the default of "untargetted" is correct as soon as R is the current devel release. :P
[02:21] <stgraber> looking at the bug history, that's because it was targeted at r-series then someone removed the bug tasks
[02:21] <infinity> stgraber: Yeah, that's the bug.
[02:21] <infinity> But, again, who cares?
[02:21] <infinity> R = devel soon, = "Ubuntu" tasks are R.
[02:21] <infinity> So, meh.
[02:24] <infinity> Right, then.  Mozillafest is done on x86, I'm going to give i386 another buildd and open the langpack floodgates.
[02:47] <ScottK> https://bugs.launchpad.net/~ubuntu-release from 95 bugs/tasks to 19.
[02:53] <stgraber> thanks!
[03:58] <micahg> yep, targeted then deleted task makes series disappear
[03:59] <infinity> Yay, gcc-snapshot on armhf finished.
[03:59] <infinity> In just about the right amount of time to make that thunderbird ain picks up finish around the same time as the last firefoxen.
[03:59] <infinity> Serendipitous.
[04:01] <micahg> all your arm* buildds are belong to us :)
[04:02] <micahg> *working arm* buildds :)
[04:35] <ScottK> https://launchpad.net/builders/primero is looking a bit schizophrenic at the moment.
[04:38] <micahg> hrm, amsn is back, I guess that's fine for non-LTS...
[04:39] <ScottK> It's allegedly maintained again.
[04:41] <micahg> right...let's see what happens with that :)
[04:42] <micahg> people seem to like it for some reason, and at this point, it's not any worse that some of the other software in universe
[04:42] <infinity> Spoken like a dedicated MOTU.
[04:43] <ScottK> jbicha TIL, so whatever, his problem.
[04:43] <ScottK> infinity: ^^^ that's a dedicated MOTU.
[06:04] <pitti> dpm asked me to upload the two packages which are affected by https://bugs.launchpad.net/launchpad/+bug/1048556
[06:04] <ubot2> Ubuntu bug 1048556 in ubuntu-translations "Language pack translations export needs to add universe packages to domain map" [Undecided,New]
[06:05] <pitti> they will drop the X-Ubuntu-Langpack header, so that they will use the upstream translations again and include them in the .debs
[06:05] <pitti> instead of stripping them and relying on the langpacks to carry them
[06:05] <pitti> (both are universe packages)
[06:05] <pitti> gnome-panel and banshee
[06:06] <pitti> I upload them to -proposed for being cautious, but they are intended for the final release
[06:06] <pitti> as the final langpacks are uploaded now
[06:16] <infinity> pitti: Want to let that neko in?  Just a rebuild (and moving a debian-changes patch), fixes an FTBFS on armhf for its r-build-deps.
[06:16] <pitti> infinity: I'm not officially in ~ubuntu-release any more, but if you want to pretend for a moment that I was, I'm happy to review it :)
[06:17] <infinity> I'm all for pretending.
[06:17]  * pitti puts on his -release veteran hat
[06:17]  * infinity curses the queue diffs, and diffs gnome-panel manually.
[06:18] <pitti> infinity: LGTM, accepted; thanks for cleaning up that as-needed patch
[06:20] <infinity> And the mozillathon is finally coming to a close.
[06:20] <micahg> infinity: well, the mozilla buildathon :)
[06:22] <infinity> micahg: Were the FTBFSes on sparc expected?
[06:22] <micahg> infinity: yes, unfortunately
Compile-time page size does not divide the runtime one.
[06:23] <infinity> ^-- Is that a fancy way of saying LOLALIGNMENT?
[06:23] <micahg> I'm pretty sure Debian has the fix, just no one has had time to dig it out
[06:24] <micahg> and since you can't install sparc from lucid media, we haven't cared too much
[06:24] <infinity> Not even from d-i images?
[06:24] <micahg> AFAIK, no
[06:24] <infinity> Special.
[06:24] <micahg> or did you fix that?
[06:25] <infinity> Was I going to?
[06:25] <infinity> What was broken?
[06:25] <micahg> ISTR having this conversation with you before
[06:25] <infinity> I made d-i stop FTBFSing on sparc, but that doesn't mean it works.
[06:26] <infinity> I didn't know it didn't work, just that it didn't build.
[06:26] <infinity> Oh, and that was on hardy.
[06:26] <infinity> Which is what we're talking about.
[06:26] <micahg> right
[06:26] <infinity> Even if you said lucid. :P
[06:26] <infinity> Oh, wait.
[06:26] <infinity> No.
[06:26] <infinity> You meant lucid.
[06:26]  * infinity wonders what's wrong with lucid.
[06:27] <infinity> Oh well, I have no hardware to test on anyway, so without blindingly obvious bug reports, I wouldn't be able to do much.
[06:27] <micahg> yeah, powerpc was the only arch we got complaints about
[06:28] <micahg> and BenC was kind enough to fix that
[06:28] <infinity> Not so much kindness as being paid, I think.
[06:29] <micahg> whatever gets the job done ;)
[06:32] <micahg> PPC in quantal is in better shape than precise
[06:32] <infinity> cjwatson: So, it was neko that was doing the wrong thing.  With neko rebuilt, neither haxe nor mercurial-buildpackage FTBFS (no need to rebuild either of those, mind you)
[06:32] <infinity> micahg: Yeah, shame he didn't start on his crusade about 3 months earlier.
[06:32] <micahg> heh, right
[06:32] <infinity> micahg: Though he got precise in pretty decent shape.
[06:32] <micahg> yeah, it's not bad
[06:32] <infinity> micahg: Certainly good enough for most server workloads, which is actually what his employer cared about.
[06:33] <infinity> micahg: I think fixing the rest of the world was just a point of pride, and cause whoever pays him didn't really understand that they didn't care. ;)
[06:37] <infinity>   241 root      20   0     0    0    0 D   15  0.0 131:52.45 usb-storage
[06:37] <infinity> 14520 adconrad  20   0  668m 352m  100 D    4 39.0  20:09.78 mlton-compile
[06:37] <infinity> 14395 adconrad  20   0  678m 288m   80 D    3 31.8  20:02.58 mlton-compile
[06:37] <infinity> ^-- Dear Santa, I'd like an ARM box with RAM, so I can stop spending more time swapping than compiling, kthx.
[08:06] <infinity> ^--- Best version number EVAR.
[08:09] <Laney> what in the
[08:09] <Daviey> infinity: it could only be better if it regressed and we had to drop back with, 7.2~alpha5+cvs20101124-1+deb7u0ubuntu2~really7.2~alpha5+cvs20101124-1ubuntu1
[08:10] <infinity> Daviey: Except that's the same upstream, so it would just be ubuntu2. :P
[08:10] <Laney> is that a convention for tpu?
[08:10] <pitti> (Don't forget the ~precise1 backport suffix)
[08:10] <infinity> Laney: Apparently.
[08:10] <Daviey> infinity: bah! :)
[08:11] <cjwatson> pitti: ~ubuntu12.04.1 you mean :-)
[08:14] <Laney> <IP_ADDRESS>+<IP_ADDRESS>5ubuntu1~hardy1+really<IP_ADDRESS>ubuntu1
[08:14] <Laney> still wins
[08:16]  * xnox I am tempted to make some software and actually call it <IP_ADDRESS>.5, first upstream version will also match the name of the software.
[08:16] <infinity> Aaaanyhow, if someone would like to review that instead of making fun of the version number... ;)
[08:17] <infinity> I think that's the only legitimate FTBFS left in main.
[08:18] <infinity> And I'm sick of staring at mlton bootstrapping, so I might go to bed.
[08:18] <infinity> cjwatson: mlton bootstrappyness will happen in-archive tomorrow, by the looks of this local build.
[08:21] <cjwatson> Cool.
[08:22] <cjwatson> Impressed at somebody fixing libatomic-ops.  I tried and failed.
[08:22] <cjwatson> (Like, last release.)
[08:22]  * cjwatson goes cross-eyed at x86 asm
[08:22] <cjwatson> Only one coffee ...
[08:26] <didrocks> small internationalization fix to generate some javascript strings in pot which can be translated :p ^
[08:56] <apw> linux-signed upload adding di integration as a step towards netboot support
[08:56] <infinity> (and server)
[09:03]  * cjwatson reviews
[09:04] <cjwatson> LGTM
[09:25] <psivaa> cjwatson, i notice source.list contains uncommented deb cdrom:[Ubuntu 12.10 _Quantal Quetzal_ - Beta i386 (20121010)]/ quantal main restricted after an i386 reinstall
[09:25] <psivaa> cjwatson, is that intended?
[09:28] <ogra_> hmpf, whats wrong with the arm builds
[09:28] <cjwatson> psivaa: Sounds reasonable to me
[09:29] <pitti> cjwatson: is that for installing network drivers etc. post-installataion?
[09:29] <psivaa> cjwatson, ok, on amd64 i see that line commented though
[09:30] <cjwatson> pitti: for example; also if you have the stuff locally then why not
[09:30] <cjwatson> apt used to be irritating and ask for the CD, but it doesn't any more
[09:30] <cjwatson> psivaa: honestly - it might be a micro-bug somewhere, but I'm doubtful that it's worth spending any time on
[09:31] <psivaa> cjwatson, ack, software center asks for the CD when this line is uncommented
[09:32] <cjwatson> !
[09:32] <cjwatson> That bug was fixed in apt in, what, 2005?
[09:32] <infinity> ogra_: You mean ARM image builds?
[09:33] <cjwatson> psivaa: Sigh, file a bug on whichever installer you're using with logs, then
[09:33] <ogra_> infinity, yeah
[09:33] <infinity> ogra_: Could be suffering from skew since all the Pandas were busy with firefox/thunderbird all day.
[09:33] <ogra_> infinity, livefs builds particulary
[09:33] <infinity> ogra_: And I mean *all* the Pandas.
[09:33] <infinity> ogra_: The queues will catch up in a bit.
[09:33] <ogra_> oh, did we now switch to LP buildds ?
[09:34] <infinity> ogra_: Hrm?  No, I meant that we could have had package skews due to ARM not building anything useful for 12h.
[09:34] <ogra_> (i.e. is it pointless to look at celbalrai ?)
[09:34] <Laney> psivaa: how did you get s-c to ask you for a CDROM?
[09:34] <Laney> I can't get that here
[09:34] <ogra_> oh, well, i dont even see build attempts for the last two days
[09:34] <pitti> infinity: thanks for accepting udev; for quantal, did you intend to land this in quantal proper, or SRU? (I'm fine with final, it's quite straightforward and tested by two people)
[09:34] <infinity> Oh, that's disconcerting.
[09:34] <ogra_> right
[09:34] <infinity> pitti: I was going to let it in.
[09:35] <cjwatson> I got some empty error mails about ARM builds
[09:35] <cjwatson> (livefs)
[09:35] <pitti> infinity: cheers
[09:35] <ogra_> ac100 has a build attempt yesterday with some weird chroot cleanup message
[09:35] <pitti> banshee and gnome-panel look good, they now have translations
[09:35] <ogra_> and omap/omap4 hanst even been attempted it seems
[09:35] <ogra_> *hasnt
[09:35] <psivaa> Laney, when you try to install something  using software center it asks for the cd,
[09:35]  * ogra_ suspects a buildd issue
[09:35] <Laney> no, I don't see that
[09:35] <infinity> ogra_: Could be that someone needs to hard rm -rf chroot/build/*
[09:35] <infinity> ogra_: Where's that log?
[09:35] <ogra_> yep
[09:35] <psivaa> well even if the line is uncommented?
[09:35] <Laney> yes
[09:36] <Laney> ah, perhaps I need apt-cdrom
[09:36] <Laney> no
[09:36] <infinity> ogra_: Oh, found it.
[09:36] <pitti> Laney: merely adding the line won't help; did you actually add it in apt?
[09:36] <Laney> ho hum.
[09:36] <ogra_> http://paste.ubuntu.com/1272866/
[09:36] <infinity> ogra_: Weird.  It has no errors.  Just doesn't configure.
[09:36] <cjwatson> psivaa: desktop image, presumably?
[09:36] <psivaa> cjwatson, yes
[09:37] <Laney> pitti: I just uncommented it in sources.list
[09:37] <cjwatson> psivaa: from DVD or USB?
[09:37] <Laney> do I have to do more?
[09:37] <pitti> apt-cdrom add, I think
[09:37] <psivaa> cjwatson, usb
[09:37] <cjwatson> And when you tested amd64, was that also from USB?
[09:37] <infinity> ogra_: 20121009 was okay, though.
[09:37] <psivaa> cjwatson, yes
[09:37] <ogra_> yep
[09:37] <infinity> ogra_: So, this is very recent.
[09:38] <cjwatson> Curious.  I suppose the difference might relate to multiarch, since we've never really tidied up multiarch on the CD.
[09:38] <ogra_> but there was no livecd-rootfs or live-build uploads or anything in that timeframe
[09:38] <ogra_> i uploaded a change on the 3rd ... we had working builds since and colin uploaded the efi change today
[09:39] <cjwatson> psivaa: FWIW my snap assessment is that commenting that out has a high risk of regressions both in the installer and in post-install tasks such as installing restricted network drivers
[09:39] <cjwatson> So I'd much rather see software-center fixed to not ask
[09:39] <cjwatson> But I'll have a look to see if it's something subtler
[09:39] <cjwatson> (Which is quite possible)
[09:40] <infinity> ogra_: Try a by-hand lubuntu-ac100 build?
[09:40] <infinity> Or...
[09:40] <infinity> Wait.
[09:41] <ogra_> nothing suspicious in debian-cd either
[09:41] <infinity> debian-cd wouldn't relate anyway.
[09:42] <ogra_> well, neither in cdimage :)
[09:42] <ogra_> yeah, let me try a manual buildlive
[09:43] <infinity> I was just about to do a manual core.
[09:43] <psivaa> cjwatson i actually did a reinstall from amd64 ->i386,  then i see the line uncommented -> when i use s-c it asks for a cd and after i comment the line the s-c does not ask for the cd
[09:43] <cjwatson> what sort of reinstall?
[09:43] <ogra_> infinity, are you running already ?
[09:43] <infinity> ogra_: I will be, yeah.  Hands off for a sec.
[09:44] <ogra_> lubuntu-armhf-ac100 on celbalrai.buildd starting at 2012-10-11 09:43:28
[09:44] <ogra_> lockfile: Try praying, giving up on "/home/buildd/buildLiveCD.lock"
[09:44] <ogra_> lubuntu-armhf-ac100 on celbalrai.buildd finished at 2012-10-11 09:43:30 (failed)
[09:44] <ogra_> Null message body; hope that's ok
[09:44] <ogra_> Error: no livefs builds succeede
[09:44] <infinity> Ahh.
[09:44] <psivaa> cjwatson, usb-> and the new Re-install option
[09:44] <cjwatson> Not that new, but OK
[09:44] <infinity> ogra_: Working with webops to fixify it.
[09:44] <cjwatson> And the amd64 install was a fresh unmodified install of quantal?
[09:45] <cjwatson> It'd be great if I could have exact directions rather than asking lots of questions :)
[09:45] <ogra_> infinity, great, thx
[09:46] <xnox> cjwatson: well it wasn't shown for dev-releases until I fixed it recently ;-) hence "new in quantal recently". I wonder if we should not allow cross-grading... or do some sanity to sources.list.
[09:47] <psivaa> cjwatson, ill reproduce that and file a bug, with steps to reproduce
[09:48] <infinity> ogra_: So, celbalrai went read-only.  That would explain the weird logs. :P
[09:48] <ogra_> haha
[09:48] <ogra_> yeah
[09:49]  * ogra_ wants arm boards with 6G RAM and tmpfses for live builds !
[09:49] <infinity> How about 4G of RAM and a filesystem that's not tethered to the machine with a USB cable?
[09:51] <infinity> ogra_: Right, it's being escalated with some urgency.  For now, you has no livefses.  I hope you had other things to work on...
[09:52] <ogra_> well, i was about to roll a ubuntu rootfs tarball :)
[09:52] <ogra_> but yeah, i can do enough other stuff
[09:53] <infinity> Oh, you can't be serious... libatomic-ops now segfaults on armel?
[09:53] <infinity> FML.
[09:54]  * infinity gives it back and prays that was cosmic rays screwing with him.
[09:54] <xnox> infinity: welcome to this timezone ;-)
[09:54] <ogra_> heh
[09:54] <cjwatson> You say that as if infinity has a home timezone.
[09:54] <infinity> xnox: I've been up for 22h, I'm not actually sure what TZ I'm in.
[09:55] <xnox> infinity: clearly the odd one ;-)
[09:55] <Daviey> infinity works 24x7 during freezes, and release times.  Outside of those times, he sleeps.
[09:56] <infinity> The latter bit may not be true.
[10:03] <infinity> *sigh*... And now it's gone into an infinite loop.
[10:03] <cjwatson> Ooh, I can haz netbeans fix?
[10:03]  * cjwatson reviews
[10:04] <infinity> Why do I have a sinking feeling this isn't going to end well?
[10:05] <smartboyhw> lol
[10:06] <infinity> Ifinitely-looping testsuites make me sad.
[10:22] <cjwatson> Would anyone object to syncing in sugar-base-0.88 and sugar-toolkit-0.88 so that sugar-moon-activity can build?
[10:23] <cjwatson> (I might test-build them first)
[10:25] <infinity> Oh, feh.  I see the problem with atomic-ops on armel.  I think.  I'll need to look at this in the morning.
[10:25] <infinity> If this was on a v5 buildd, it would just happily SIGILL instead of doing Weird Things.
[10:26] <cjwatson> -march FTW?
[10:27] <infinity> cjwatson: You mean just force it to v7 and be done with it for now? :P
[10:28] <cjwatson> I meant v5, but perhaps I misunderstand
[10:28] <infinity> cjwatson: I was going to just backport the newer sysdeps/gcc/arm.h, since it actually properly deals with Thumb1/Thumb2.
[10:28] <cjwatson> Ah
[10:28] <infinity> cjwatson: The problem is the inline ASM in the old version of libatomic-ops we carry assumes thumb == thumb2, and does Very Bad Things.
[10:29] <infinity> Well, that's *a* problem.  I can't tell if that's what just exploded aleya until I fix it.
[10:29] <infinity> But yeah.  I need a nap.
[10:29] <infinity> Will fix in the "morning", whenever that happens.
[10:35] <cjwatson> OK, sugar-{base,toolkit}-0.88 build cleanly here, and should be enough to resolve that dep-wait, even if they don't represent a complete Sugar environment.
[10:35] <cjwatson> So synced.
[10:40] <cjwatson> Oh, that's where linux-signed got to
[10:40]  * cjwatson curses -proposed, made me waste an hour
[10:52] <infinity> cjwatson: Say, how did libatomic-ops miss your napalm rebuild-for-armv5 run anyway?
[10:53] <infinity> cjwatson: Then this would have been your problem. ;)
[10:53] <infinity> cjwatson: (Turns out I was wrong about the thumb thing, it is guarded elsewhere, so it never executes.. But this infinite looping testsuite has been seen on several arches in recent rebuilds on Debian too)
[10:55] <infinity> Kinda tempted to just disable the test suite on armel and say screw it for now.
[10:56] <cjwatson> infinity: Not quite sure.
[10:57] <cjwatson> Possibly worth debugging if I had any time :-)
[11:03] <infinity> I'm pretty sure I never should have collapsed the waveform on this one.
[11:04]  * infinity naps for real this time, and hopes he doesn't dream of atomics.
[11:18]  * cjwatson battles with ruby-fusefs
[11:58] <ScottK> Apparently I mashed the wrong buttton on sugar and it can't be fixed:
[11:58] <ScottK> FAILED: sugar-toolkit-0.88 (Can't resurrect rejected syncs)
[11:58] <ScottK> FAILED: sugar-base-0.88 (Can't resurrect rejected syncs)
[11:58] <Laney> yeah, re-sync them
[11:58] <cjwatson> Yeah, you can't ... that.  I can resync.
[11:58] <ScottK> Thanks.
[12:00]  * ScottK tries again.
[12:14] <cjwatson> Hmm, sugar-* still rejected
[12:15] <cjwatson> Damn, it was deleted from quantal
[12:15] <cjwatson> I wonder if I can re-copy it from precise
[12:15] <cjwatson> Or even from quantal come to that
[12:20]  * cjwatson tries
[12:22] <cjwatson> Ha!  Master.  Hopefully that won't break the publisher.
[12:48]  * infinity gives up on the mystery of libatomic-ops.  No, really.  Honest.
[12:49] <cjwatson> You can review d-i instead :)
[12:49] <cjwatson> Seeing as you're clearly failing to sleep
[12:50] <infinity> I'm also failing to reproduce the failures the buildds are seeing.
[12:50] <infinity> And it's making me a sad panda.
[12:50] <cjwatson> barry: so, um, why is this python-mode sync appropriate during final freeze?
[12:51] <cjwatson> While I understand the desire to get all one's own Debian packages in sync :)
[12:51] <barry> cjwatson: dang, you noticed. :)
[12:55] <cjwatson> barry: I'm wary of anything but crash/build/other-serious-bug-fixes and maybe some already-known feature freeze exceptions at this point, TBH
[12:56] <infinity> cjwatson: Why not just ifdef; if -e; mv boot/$nameALT boot/$name; fi; endif, instead of duplicating the other mv with an else?
[12:57] <cjwatson> infinity: I suppose if I did that *after* the other mv
[12:57] <cjwatson> Oh, or I could read what you wrote
[12:57] <barry> cjwatson: that's cool.  this does fix real problems people have with functionality, it's universe, but i have no problems sru'ing it after release if you prefer.
[12:57] <cjwatson> Yeah, that would work
[12:57] <infinity> cjwatson: It just seems a bit more readable to me that way.  And shorter.
[12:58] <cjwatson> barry: Yeah, I'd rather that at this point, honestly.  More time to spot any new breakage.
[12:59] <barry> cjwatson: np
[12:59] <infinity> cjwatson: So, basically, just ditching the rm/else/mv, and then ending the ifdef, rather than elsing it.
[12:59] <infinity> (elsing is totally a verb, right?)
[12:59] <cjwatson> infinity: http://paste.ubuntu.com/1273151/ ?
[13:00] <infinity> Why does diff insist on silly ordering I can't read.
[13:00] <infinity> Yeah, that looks like what I'm driving at.
[13:01] <cjwatson> mkay, will upload ubuntu183
[13:01] <infinity> Ends up doing the same thing, but the smaller the unusual ifdef code blocks, the better, IMO.
[13:01] <infinity> Easier to track WTF they're up to.
[13:01] <infinity> I'll just reject 182, and you can re-tag it.
[13:01] <cjwatson> I prefer a new version anyway
[13:02] <infinity> Alright. :)
[13:02]  * infinity probably abuses bzr tag --force a bit too often.
[13:04] <cjwatson> Yay, resurrecting with copy-package totally works, admittedly with a couple of slight hacks only one of which I committed.
[13:05] <infinity> My local copy-package is hacked to bits for that sort of thing.
[13:05] <infinity> But not in any remotely committable way.
[13:05] <cjwatson> Maybe I should write a dedicated undelete-package.  Except the opposite is called remove-package, and unremove-package doesn't sound right.   :P
[13:05] <cjwatson> I fixed lputils in a way that deals with most of what you usually complain about
[13:05] <cjwatson> But you also have to comment out the target-same-as-source guard
[13:06] <infinity> The opposite of remove would be insert, surely.
[13:06] <infinity> insert-package
[13:06] <cjwatson> Not really in this sense ...
[13:06] <infinity> Cause that doesn't sound dirty at all.
[13:06] <cjwatson> restore, but it looks too similar.
[13:06] <cjwatson> Or resurrect.
[13:06] <infinity> I think just giving copy an option to do it seems sane.
[13:06] <infinity> Since it really *is* a copy.
[13:07] <infinity> Just a weird one.
[13:07] <cjwatson> It is, it's just that only people who know Soyuz will think of it that way.
[13:09] <cjwatson> Laney: So I was looking at removing pandoc/armel, since I suspect that mysterious build failure isn't likely to go away
[13:09] <ScottK> I like resurrect.
[13:09] <infinity> revive?
[13:09] <cjwatson> revive isn't bad
[13:10] <cjwatson> Though even more similar to remove
[13:10] <cjwatson> Laney: Looks like the rdepends stack that would need to be removed on armel would be: bup carettah imageshack-uploader purity-ng libnss-rainbow2 tempest-for-eliza
[13:10] <cjwatson> What do you think?
[13:10] <infinity> cjwatson: remove-package --not? :P
[13:11] <infinity> --just-kidding
[13:11] <cjwatson> remove-package --undo
[13:11] <infinity> Alright, going to try harder to nap.    It doesn't HAVE to have 'package' in the name.
[13:19] <Laney> cjwatson: feel free
[13:19] <Laney> Someone who cares more could look into removing the pandoc BDs on those packages (at least some of them are likely to be for documentation only)
[13:20] <infinity> cjwatson: Oh, by the way, if that paste was a pastebinit pipe, "pastebinit -f diff" makes it pretty (aliased to pastediff here, cause that's 99% of my pastes).
[13:21] <cjwatson> My bin/ubuntu-paste is old-skool.  One of these days I might switch to pastebinit.
[13:22] <cjwatson> Laney: OK, removed
[13:23] <bdrung> hi, vlc 2.0.4 will be released on sunday. it contains a bunch of bug-fixes and adds support for opus (= only new feature). now likely is it to get a FFe?
[13:23] <jdstrand> skaet, cjwatson: is now an ok time to pocket copy firefox and tbird?
[13:23] <cjwatson> bdrung: I suspect an SRU at this point would be more likely
[13:23] <cjwatson> jdstrand: yes
[13:24]  * skaet has cup of tea in hand, and prepares to work through the back scroll.
[13:24] <skaet> jdstrand,  ok by me,  but am just catching up on the overnight status.   cjwatson?  infinity?
[13:24] <cjwatson> Yes, I said yes above :-)
[13:24] <skaet> ah,  just saw cjwatson's yes
[13:25] <jdstrand> skaet: it is built on all archs and tested
[13:25] <skaet> sorry
[13:25]  * skaet increases caffine intake.  ;)
[13:25] <skaet> thanks jdstrand
[13:26] <jdstrand> ok, firefox and tbird are copied. I hope we can stay out of your hair now
[13:31] <ScottK> mvo: Is there a reason this software center upload can't go to -proposed?
[13:32] <mvo> ScottK: it can go to -proposed, the reinstall previous purchases bug is important but its certainly ok if it goes into -proposed - I can reupload there
[13:32] <ScottK> Thanks.  Will reject the current upload.
[13:33] <mvo> ScottK: thanks, is there still a chance it may go on the CD in in case a rebuild is needed or is it stricly out of the question now?
[13:34] <skaet> mvo, depends on what's in it, and risk
[13:34] <Laney> when should we decron and stuff?
[13:34] <skaet> Laney,  was thinking it was looking close to now actually.
[13:34]  * skaet staring at her checklists ;)
[13:35] <mvo> skaet: thanks, risk is small but non-zero (of course). I understand if -proposed is the way to go at this point of course
[13:38] <cjwatson> My one remaining thing is that I'd like to get a grub2 upload in to help us debug stgraber's mysterious failure to boot unsigned kernels.
[13:38] <skaet> cjwatson,  is there anything still pending from your perspective?  (am not sure from the backscroll if all the UEFI bits have been sorted into place yet)
[13:38] <skaet> lol
[13:38] <cjwatson> snap
[13:38] <cjwatson> Just preparing that now - shouldn't be any functional change when debug is unset
[13:38] <skaet> ok,  lets turn off the cron.
[13:38] <ScottK> xubuntu-docs is in queue.
[13:39] <ScottK> Doesn't affect anyone but them.
[13:39] <skaet> yup, was waiting for diff, and don't see any problem with it going in on priinciple.
[13:39] <skaet> low risk, affects them.
[13:39] <ScottK> cjwatson: This memtest86+ upload needs in too, right?
[13:41] <cjwatson> ScottK: It would be useful
[13:42] <cjwatson> And fairly low risk AFAICS
[13:43] <skaet> crontab disabled
[13:44]  * skaet wondering why diffs are taking so long to generate
[13:44] <skaet> its been 30 minutes now on xubuntu-docs
[13:45] <ScottK> Seems reasonable then to get memtext86+, grub2, and xubuntu-docs in and then declare victory.
[13:45] <Laney> a whoopsie just came in
[13:45]  * Laney is amused that he got to type that
[13:45] <ev> it did
[13:46] <skaet> what's the backstory on it ev?
[13:46] <ev> I'll give whoever lets that through a giant pile of candy
[13:46] <skaet> yeah,  but while we wait for the diff to show up - what's it fixing?
[13:46] <ev> skaet: it's needed for https://bugs.launchpad.net/whoopsie/+bug/1050853
[13:46] <ubot2> Ubuntu bug 1050853 in apport "Not recorded whether an error is in a -proposed or -updates package" [Undecided,Fix committed]
[13:46] <skaet> :)
[13:46] <ev> I probably should've linked to that :)
[13:46] <ev> the only change is that we send the Tags field up with the report
[13:47] <ev> single line diff
[13:47] <ev> I'll also backport it to precise in a bit
[13:48] <skaet> ev,  thanks.   pending review, yeah would be good to get in.
[13:48] <ev> wonderful
[13:49] <cjwatson> Oh, and grub2 will need a grub2-signed later on too ...
[13:49] <Laney> wasn't there a new shim?
[13:49]  * cjwatson lobs it up quickly
[13:50] <cjwatson> Laney: it's in -proposed pending mjg59 approval
[13:50] <Laney> yeah, so that
[13:50] <Laney> and then shim-signed presumably
[13:50] <cjwatson> Which I think in practice will need to be around when slangasek wakes up
[13:50] <cjwatson> But grub2 will take a little while to build anyway
[13:50] <cjwatson> (Not horrible, but not instant)
[13:51] <cjwatson> quantal_outdate_all is beginning to look almost tractable
[13:52] <cjwatson> There's certainly more non-image stuff we need to fix
[13:54] <skaet> cjwatson,  do we have the d-i bits all lined up too?
[13:54] <cjwatson> yes
[13:54] <skaet> :)
[13:55] <cjwatson> We have at least one ubiquity patch queued, but not the end of the world if it doesn't land; in any event I would be surprised if we didn't have to upload ubiquity at some point over the next week
[13:55] <cjwatson> Though I can hope
[13:55] <cjwatson> dpm's asked for another translations sync if we do end up doing that
[13:57]  * skaet can hope too
[14:05] <cjwatson> doko: ^- is that to fix a build failure somewhere?
[14:05] <doko> cjwatson, ibus-rime b-d
[14:05] <cjwatson> gotcha, will look
[14:08] <cjwatson> Can somebody review grub2?
[14:09] <stgraber> cjwatson: doing that now (and memtest86)
[14:10] <cjwatson> ta
[14:11] <Laney> Conflicts/Breaks?!
[14:12] <stgraber> cjwatson: accepted both. Will be offline for the next hour or so but should be available for another test after that (before leaving for the airport).
[14:15] <slangasek> cjwatson: no word from mjg yet on the shim change
[14:16] <cjwatson> Laney: changelog disagrees with control - it's Replaces/Breaks in control
[14:16] <Laney> righto
[14:19] <slangasek> so there's an armadaxp ABI change just landed; that's going to require a d-i upload, no?
[14:19] <cjwatson> Already did that
[14:19] <slangasek> ok
[14:20]  * slangasek pushes the seed change
[14:20] <cjwatson> Oh I forgot that, sorry
[14:20] <slangasek> no worries
[14:24]  * cjwatson stares at the long-running ruby-hdfeos5 failure
[14:24] <cjwatson> I'm pretty sure that "Latitude" is being transformed into "LocalSgitude" at some point along the way
[14:24] <cjwatson> Which is ... inventive
[14:26] <ogra_> cjwatson, do we plan to have R build working from day one ? or is there the usual "dont care before A1" in place ?
[14:26] <ogra_> *R builds
[14:27]  * ogra_ is wondering ... with all these new policies etc ...
[14:29] <skaet> ogra_,    hopefully from day 1,  or shortly thereafter.
[14:30] <ogra_> skaet, good
[14:31] <cjwatson> It won't be practical until after the auto-sync has settled, since we don't yet have automatic continuous integration from -proposed into release.
[14:31] <cjwatson> Until then we shouldn't make promises we can't keep.
[14:31] <cjwatson> This isn't quite the same as "don't care" - "can't quite commit yet".
[14:43] <cjwatson> slangasek: ^- grub2, grub2-signed
[14:57] <slangasek> cjwatson: do those need a staged accept?
[15:00] <cjwatson> slangasek: no
[15:02] <skaet> cjwatson,  has cd release-upgrader been set to ""useDevelopmentRelease=False" ?
[15:03] <slangasek> cjwatson: ok
[15:03] <slangasek> skaet: TTBOMK, cd release-upgrader has been obsoleted with the dropping of alternate CDs
[15:04] <slangasek> rather, with the dropping of non-livefs CDs
[15:04] <slangasek> (since server could use it, but server is also using livefses now)
[15:04] <skaet> slangasek, ack.
[15:04]  * skaet makes note to remove that line item from the checklist then.
[15:04] <cjwatson> right
[15:05] <skaet> cjwatson,   how are the langpacks going out with the images looking?
[15:06] <cjwatson> skaet: You mean the ones uploaded last night?  infinity accepted them before I woke up; they've long since all built
[15:07] <skaet> cjwatson,  was wondering which languages are going to be shipped by default,  and whether we have head room to add a few more back in actually.
[15:08] <cjwatson> Oh, that I haven't looked at at all
[15:14] <doko> cjwatson, uploaded a new minor version of visualvm, which builds using netbeans, then libnb-platform-java can be removed (ftbfs)
[15:23] <cjwatson> doko: right, nice, will review
[15:23] <cjwatson> doko: I got ruby-hdfeos5 to build!  Only took six months since I first looked at it
[15:23] <doko> \o/
[15:27] <skaet> cjwatson,  have taken care of setting up iso tracker, and .conf file,   so when we spin up the first set of images they should go to the right place.
[15:31]  * skaet crosses fingers that first set is the last one.  ;)
[16:20]  * skaet --> early lunch,  back later
[16:24] <stgraber> cjwatson: installed grub2-signed 1.5, will reboot and get you a new photo
[16:30] <stgraber> cjwatson: got an extra line of output, will upload the photo now
[16:35] <stgraber> cjwatson: http://www.stgraber.org/download/2012-10-11_12-27-38_458.jpg
[16:37] <Riddell> kdeplasma-addons for a very visual issue in kubuntu active on first boot
[16:37] <Riddell> ScottK: fancy looking at that one? ^^
[16:37] <cjwatson> stgraber: so I guess my debugging output wasn't quite perfect, but looks to me as though that's stuck inside shim
[16:38] <cjwatson> slangasek: over to you? :-)
[16:38] <cjwatson> slangasek,skaet: do you know if anyone's notified the web team about the demise of the alternate installere?
[16:41] <xnox> cjwatson: I did, when me and ev had a "meeting" with them.
[16:42] <cjwatson> oh, and the DVD ...
[16:42] <xnox> cjwatson: as well as s/CD/DVD/ and the fact that server will probably not have i386.
[16:42] <cjwatson> I think I should double-check
[16:42] <xnox> in the offices.
[16:43] <xnox> cjwatson: yeah, I haven't heard back from the meeting much, but they were "hungry" for information and taking action points / list of changes.
[16:43] <slangasek> cjwatson: so it's stuck in shim_verify?
[16:44] <cjwatson> slangasek: appears to be
[16:44] <cjwatson> stuck or crashed
[16:44] <slangasek> cjwatson: are these debug statements in the current grub2 in the archive?
[16:44] <cjwatson> slangasek: yes
[16:44] <cjwatson> xnox: sent a "better safe than sorry" mail, anyway
[16:46] <xnox> cjwatson: ok.
[16:46]  * cjwatson starts refreshing memory on how to top up images with language packs
[16:46] <xnox> 8)
[16:49] <ScottK> Riddell: Will look.
[16:53] <cjwatson> skaet: I've topped up Ubuntu quantal-desktop-powerpc.iso, which was the only one that I felt needed it (I'm not going to bother topping up the ARM ones)
[16:53] <cjwatson> I figure other flavours can manage this themselves if they want to
[16:54] <slangasek> cjwatson: I guess it's unlikely that grub_efi_locate_protocol() is hanging or crashing?
[16:54] <cjwatson> slangasek: Yeah, hence my comment about debugging being not quite perfectly granular, but it seems pretty unlikel
[16:54] <cjwatson> y
[16:55] <cjwatson> That's a straightforward wrapper over LocateProtocol
[16:58]  * slangasek nods
[17:01] <cjwatson> Ellen is out of the office; do we know who's covering for her on the web team?
[17:03] <ScottK> Riddell: You verified this doesn't screw up non-Active images, right?
[17:03] <popey> Ellen is no longer on the web team cjwatson
[17:03] <cjwatson> Oh, we need to update our process pages then
[17:04] <cjwatson> I wish Canonical made better use of role addresses for things
[17:08]  * cjwatson pokes the directory and comes up with some possibilities, at least
[17:11] <popey> cjwatson, I am informed Tanya Edwards is your contact
[17:12] <cjwatson> Good, she was one of the three addresses I came up with
[17:18] <cjwatson> skaet: OK, so I'm going to have to finish for today; the netinstall issue raised by the server team turned out to be not a relevant one for us at this point (it's something to do with precise, not quantal); after this publisher run (so call it half an hour for safety, though probably less), from my point of view we can start building candidates
[17:19] <cjwatson> skaet: scrollback suggests Kubuntu might want to wait until this kdeplasma-addons problem is sorted out, not sure
[17:19] <Laney> there's a webapp upload coming apparently
[17:19] <Laney> from kenvandine
[17:20] <Laney> I think it includes some deferrable-to-SRU changes, but ymmv
[17:21] <seb128> is that a difference between SRU and release uploads from an uploader perspective?
[17:21] <seb128> or it's just "upload to quantal-proposed" and then see when it gets accepted?
[17:22] <Laney> for SRU you'll need the bug reference, but I suppose otherwise not
[17:22] <Laney> however this webapp upload contains a change that we do want in the release which makes it more difficult
[17:23] <seb128> Laney, why difficult? we still have an unity upload coming so we will need to respin isos anyway...
[17:23] <Laney> more difficult to aim at proposed
[17:24] <seb128> I'm annoyed by https://bugs.launchpad.net/ubuntu/quantal/+source/libreoffice/+bug/1064962
[17:24] <ubot2> Ubuntu bug 1064962 in indicator-appmenu "Global menubar items do not work when opening a document directly from nautilus with no LibreOffice instance running" [High,Confirmed]
[17:24] <seb128> but I guess it's too late at this point for such changes for release
[17:24] <seb128> ?
[17:24] <seb128> I still want to mention it
[17:25] <Laney> seb128: doesn't look like there is even a fix for that yet?
[17:25] <seb128> the bug is basically "if you double click on a lo-file in nautilus you will get no menus"
[17:25] <seb128> Laney, no, they are working on it, just got discussed a bit earlier on #ubuntu-desktop
[17:26] <Laney> I think basically SRU yeah, but I agree it is annoying
[17:26] <doko> cjwatson, diagnostics is the last one for me today. please watch https://launchpad.net/ubuntu/+source/pandoc/<IP_ADDRESS>-2build1/+build/3744152 and give back optgeo once it's in the archive
[17:45] <Laney> skaet: what do you think about the webapps stuff?
[17:45] <Laney> in queue
[17:46] <ScottK> Looks like SRU material to me.
[17:50] <Laney> Yeah.
[17:51] <Laney> kenvandine: I think it would be best for us to only take the API key stuff for account-plugins and get the rest into proposed
[17:51] <Laney> Taking the API keys because you have to re-authenticate if they change which would be pretty crap post release
[17:52] <xnox> also the diff looks very strange... was all the auto-generated stuff removed on purpose or by accident? why it's 2.4.1 and 2.4 in configure.ac?
[17:59] <Laney> I'll do a safety reject out of unapproved/release
[18:10] <skaet> cjwatson,  talked to the web team about the images at beta 2 time,  but its on the check list to doublecheck with them once they have the staging site up.
[18:11] <skaet> ScottK,  Riddell - where is the kdeplasma-addons issues?   do you want the kubuntu images to wait for it?
[18:12] <ScottK> skaet: If you have others to do, go ahead with them.  I'm waiting to hear back from Riddell on testing before accepting.
[18:12]  * skaet now trying to figure out what's the issue webapps...
[18:13] <skaet> ScottK,  ok.   won't spin up Kubuntu and Kubuntu active until I hear from you/Riddell
[18:32] <didrocks> Laney: if you want to pre-test the legal notice we discussed, you can test unity from the ubuntu-desktop ppa once it's built
[18:33] <Laney> did he quit?
[18:34] <peterm-ubuntu> Laney is this the legal notice from Ivanka?
[18:35] <Laney> No idea who it's from
[18:35] <peterm-ubuntu> Laney untu.com/aboutus/privacypolicy/thirdparties.html ?
[18:36] <Laney> peterm-ubuntu: I'm not sure, I haven't seen it
[18:36] <peterm-ubuntu> well… propery started
[18:36] <peterm-ubuntu> ok
[18:36] <Laney> it's a link from the dash to some legal notice
[18:36] <peterm-ubuntu> because that one isn't quite right
[18:36] <skaet> Laney,  yeah let me know what you and didrocks find out,  this is one of the other bits on the critical path for the images it seems.
[18:36] <Laney> but I don't know wha tthe final design is or anything
[18:36] <Laney> skaet: I'll be away, sorry
[18:36] <Laney> I'm off tomorrow too
[18:38] <skaet> Laney,  ack
[18:38] <Laney> peterm-ubuntu: It needs to be right very soon
[18:38] <Laney> we're in final freeze now.
[18:39] <skaet> and are supposed to be spinning up the images now.... :P
[18:39] <seb128> Laney, skaet: re. didrocks: yes, it's the "Legal notice" link from design,#ps
[18:39] <skaet> seb128, is there a bug number so we can track progress that way?
[18:39] <peterm-ubuntu> Laney sorry, I am playing catch-up, this happened on my ride home… but I think it is meant to be a link to all the thirdparty privacy policies
[18:39] <seb128> Laney, skaet: do you have any question about that?
[18:40] <seb128> skaet, I don't think so, that has been handled in fire fighting mode over IRC today
[18:40] <skaet> seb128,  when is it landing,  who's tested it so far,  how do we know no regression from including it.   (the usual ;) )
[18:40] <seb128> skaet, seems it's a legal requirement in the U.K to have a link to those notes
[18:40] <Laney> seb128: No, no question. I just don't want us to be caught in the middle of a design fight
[18:41] <seb128> well, the ppa is a backport of what design,#ps agreed on, implemented
[18:41] <peterm-ubuntu> Laney and it can't end in .html… so I think it needs to be: http://www.ubuntu.com/aboutus/privacypolicy/thirdparties
[18:41] <ScottK> The bug number question is a good one.
[18:41] <Laney> Where does this link go?
[18:41] <ScottK> 404 ATM
[18:42] <Laney> Sorry, unclear. Where will it be in the desktop?
[18:43] <peterm-ubuntu> Laney are you asking me?
[18:43] <Laney> peterm-ubuntu: anyone who knows ;-)
[18:44] <peterm-ubuntu> Laney all I have is Peter,
[18:44] <peterm-ubuntu> A last minute request from SteveG via Ivanka regarding a page that lists links to all the privacy policies for our third partys.  This page link will live on the 'dash' aside the link to our privacy policy (ubuntu.com/aboutus/privacypolicy).
[18:44] <peterm-ubuntu> Ivanka needed to know ASAP the URL that we intend this link to be. Amrit, Ivanka and I discussed and logically it sits as a page off the Ubuntu privacy policy page (ubuntu.com/aboutus/privacypolicy), so therefore the new link would be ubuntu.com/aboutus/privacypolicy/thirdparties.
[18:44] <peterm-ubuntu> ubuntu.com/aboutus/privacypolicy/thirdparties.html is what I included in the doc which will now land in Ubuntu.
[18:44] <peterm-ubuntu> We will talk with U1 people tomorrow about creating the content for the page which is simply a list of third parties and links to their privacy policies so nothing fancy.
[18:44] <peterm-ubuntu> Ivanka
[18:45] <Laney> OK. I don't know where that existing link is TBH
[18:45] <seb128> skaet, Laney: didrocks is not around anymore but bottom line is: preview is in the ppa, we will have a bug with all those infos tomorrow going with the official upload
[18:46] <Laney> seb128: OK. I don't think I'll be able to look at it (away tomorrow), so someone else on the RT can
[18:46] <seb128> Laney, ok, enjoy your W.E!
[18:47] <Laney> beer festival - certainly will!
[18:47] <seb128> nice!
[18:48] <seb128> Laney, is that UDS training? ;-)
[18:48] <skaet> Laney,  about the one you put on hold,  has the problem been fully solved,  or is it a partial?
[18:48] <ScottK> Did we get firefox 16.0.1 in quantal yet?
[18:48] <seb128> ScottK, yes
[18:48] <skaet> ScottK,  yes,  copied over this morning by jdstrand
[18:48] <ScottK> Cool.
[18:49] <Laney> skaet: I left kenvandine a message with what I think should be done for the release
[18:49] <Laney> which is to take just one of the fixes and leave the rest for SRU
[18:50] <skaet> thanks Laney.   ok.   will follow up with him.
[18:51]  * skaet shifting location,  back on soon.
[19:35] <skaet> ScottK, ^ after kdeplasma-addons publishes, ok to spin your images up then?
[19:36] <ScottK> skaet: I also want bluedevil in since we have a window.  It's just a copy from -proposed so it should be done first.
[19:36] <skaet> ScottK,  ok.
[19:36] <Riddell> thanks ScottK
[19:37] <ScottK> bluedevil is done, so once you have kdeplasma-addons, it should be good.
[19:48] <skaet> gilir,  anything you're waiting for, or can we start spinning up lubuntu?
[19:51] <ScottK> Someone might rescore kdeplamsa-addons so it gets an earlier start on armel.
[19:52] <stgraber> ScottK: doing that now
[19:52] <skaet> infinity, ^ can you oblige?
[19:52] <skaet> ah
[19:52] <ScottK> Thanks.
[19:52] <skaet> thanks stgraber,  never mind infinity
[20:00] <ScottK> The rescore bought us about half an hour.
[20:19] <gilir> skaet, no, you can start
[20:23] <skaet> thanks gilir,   there will likely need to be respins (cjwatson's fix), so don't go wild testing them yet,  but I want to make sure no other surprises.
[20:31]  * skaet  starting to spin up trial set of ubuntu, xubuntu, and lubuntu images -  will be respun later.
[20:41] <kenvandine> Laney, skaet: account-plugins uploaded again
[20:41] <kenvandine> thanks for looking at that
[20:41] <skaet> thanks kenvandine
[21:16] <skaet> could I get a second set of eyes on account-plugins in the queue?   its looking basically sane, but would appreciate a second opinion.
[21:17] <infinity> Sure.
[21:18] <slangasek> skaet: looks ok to me
[21:18] <slangasek> er, excetp
[21:18] <slangasek> --with-flickr-consumer-secret
[21:18] <slangasek> doesn't look very secret, does it?
[21:19] <infinity> And -with-twitter-consumer-secret
[21:19] <infinity> I think this may be a different use of the word "secret" than I'm familiar with.
[21:20] <slangasek> kenvandine: can you clarify? ^^ is it actually ok that these "secrets" are published for the world to see?
[21:21] <kenvandine> slangasek, yes... that was the agreement we had with twitter for gwibber in the past
[21:21] <slangasek> funky
[21:21] <kenvandine> separating it from the source was "good enough"
[21:21] <kenvandine> they said they couldn't guarantee they wouldn't revoke it... if it got abused
[21:21] <kenvandine> but they said they wouldn't revoke it unless it was abused
[21:21] <infinity> kenvandine: Same deal with flickr?
[21:22] <kenvandine> we never talked to them about it
[21:22] <kenvandine> afaik
[21:22] <kenvandine> but we need it somewhere... better than in trunk
[21:23] <infinity> I dunno.  I suspect the point's moot.  The "secrets" need to be there at some point, somehow, so they're never all that secret.
[21:24] <kenvandine> infinity, right
[21:24] <kenvandine> for open source apps... it's tough
[21:25] <infinity> kenvandine: Even for closed source, it's no more secret.
[21:25] <kenvandine> yeah
[21:25] <infinity> kenvandine: If the secret has to be given to me by the app vendor (rather than having my own), then it's either compiled in or fetched somehow, and I can find it.
[21:25] <kenvandine> it is really easy to find... segfault published most of twitter's own secret in one of his articles
[21:25] <kenvandine> took him less than 10 minutes to find it
[21:26] <infinity> strings | eyeball
[21:28] <slangasek> this sounds like an uncomfortable habit
[21:29]  * skaet drums her fingers waiting for ubuntu desktop to emerge on armhf....
[21:29] <knome> skaet, in what rhythm? paranoid?
[21:30] <skaet> knome, impatience with the speed.  :P
[21:30] <infinity> Does this mean IS fixed celbalrai while I was asleep?
[21:31] <skaet> infinity,  well it started....
[21:31] <skaet> but that might explain it.   Can you check?
[21:32] <infinity> Well, this morning it has a read-only filesystem, and some sort of make-it-gooder was being escalated for me by webops.
[21:32] <infinity> Chasing that up.
[21:37] <infinity> skaet: Nope, it's all fixed, just requires more patience. :)
[21:38] <infinity> (If someone could accept that mlton sooner, rather than later, that would be nice, it's going to eat two buildds for the better part of a day)
[21:39] <slangasek> infinity: can you make LP generate queuediffs faster? :)
[21:39] <xnox> infinity: https://launchpad.net/ubuntu/+source/pandoc/<IP_ADDRESS>-2build1/+build/3744152 looks exactly the same as it did ~4h ago....
[21:40] <xnox> infinity: never mind.... my browser is "overcaching"
[21:40] <skaet> infinity,  looks like its being spit out now...
[21:41] <infinity> slangasek: Sure.  Abraqueueudiffra.  They're faster now.  Enjoy.
[21:41] <slangasek> infinity: huh?
[21:41] <slangasek> queuediff relies on LP having already generated the diff
[21:42] <infinity> Yeah, it just downloads it...
[21:42]  * xnox ponders why armhf panda is building armel and confusing me.
[21:42] <slangasek> right, so if it's not there yet that doesn't help
[21:42] <slangasek> though in this case I simply forgot the -q quantal argument, thanks for the sass ;)
[21:42] <xnox> infinity: https://launchpad.net/ubuntu/+source/pandoc/<IP_ADDRESS>-2build1/+build/3744152 looks stuck.
[21:42] <infinity> Would probably be nice if, lacking a diff to download, it would fetch and diff instead.
[21:42] <slangasek> infinity: dude why you wasting my time making me review a no-change rebuild
[21:43] <infinity> slangasek: I asked someone to ACCEPT it, not review it!
[21:43] <slangasek> mmhmm
[21:43] <slangasek> pretty sure if you don't want review, you know how to do the accept yourself :)
[21:43] <slangasek> (accepted)
[21:44] <infinity> xnox: You're probably right.
[21:44] <xnox> infinity: doko was hoping it would build...
[21:45] <infinity> Sucks to be doko, I guess.
[21:45] <doko> but why did it build on armhf?
[21:45] <infinity> doko: Because GHC on armel is differently sad than on armhf.
[21:45] <infinity> doko: Ask Laney.  I've been mostly ignoring that mess this cycle.
[21:46] <xnox> infinity: at least doko got to keep his pythons ;-)
[21:46] <Laney> colin said he was removing that
[21:46] <Laney> if it's pandoc/armel
[21:46] <xnox> yeap
[21:46] <infinity> Right.
[21:46] <infinity> Well, let me go free up that poor machine.
[21:47] <TheLordOfTime> LTSes are every two years?
[21:47] <TheLordOfTime> (8.04, 10.04, 12.04, kind of sets that assumptino)
[21:47] <infinity> TheLordOfTime: So far, that's been the trend.
[21:47] <TheLordOfTime> so unless something changes, 14.04's the next LTS?
[21:47] <infinity> Yeahp.
[21:49] <TheLordOfTime> cool.  thanks.  :)
[21:49] <TheLordOfTime> just wanted to confirm before stating that "approximation of LTS release" standard in #ubuntu
[21:49] <TheLordOfTime> :)
[22:07] <tkamppeter> Can someone reject my HPLIP 3.12.6-3ubuntu4 upload? I have forgotten to fill the changelog entry in it.
[22:08] <infinity> tkamppeter: Done.
[22:11] <tkamppeter> infinity, thanks, new package will come in some minutes.
[22:13] <cjwatson> kenvandine: that reminds me of one of my favourite Debian signature file entries
 # Note: the masterlist file is kept private since it contains
[22:13] <cjwatson>         e-mail addresses
[22:13] <cjwatson> * joeyh wonders again about the web team's drug levels
 "private" being a synonym for "in anonymously accessible CVS and
[22:14] <cjwatson>         shipped on every Debian CD"
[22:14] <kenvandine> :)
[22:18] <tkamppeter> infinity, corrected version uploaded.
[22:25] <skaet> gilir, lubuntu pre-candidate version has posted for alternates,  others coming.
[22:26] <gilir> skaet, ok thanks
[22:50] <ScottK> skaet: kdeplasma-addons should be in now.
[22:56] <skaet> ScottK,  coolio.  Ok, starting that set off before I shift location.
[23:06] <skaet> ScottK,  Kubuntu's started now.
[23:06]  * skaet --> shifting location again now.


[01:34] <chilts> ibeardslee: except, no, they can't do it
[01:35] <chilts> apparently they couldn't get the old copper cable out, so they'll send a new team in to cut up the driveway to put the new cable down
[01:35] <chilts> so I'm stuck on this crappy connection for longer now :/
[01:42] <ibeardslee> bugger
[01:56] <mwhudson> chilts: argh
[01:56] <G> Hmmm, remembering from reading back, Lenovo laptops have had a lot of discussion here, is the Gen3 Carbon a yay or nay for Ubuntu/etc?
[01:57] <mwhudson> G: working pretty well for me
[01:57] <mwhudson> ibeardslee might still be able to get you one without windows too...
[02:00] <ibeardslee> had some issues with the super high resolution version
[02:00] <G> ibeardslee: oh?
[02:01] <ibeardslee> yeah we still seem to need to use the Utopic lts-enablement kernel
[02:01] <G> Personally, I'm not sure if I should jump now, or wait and see if they do a Gen 4 with USB-C & 6th Gen Intel
[02:02] <ibeardslee> although the default 14.04 trusty kernel may not be an issue if you don't care about the screen in the boot process of the disk decryption passphrase being unreadable
[02:03] <G> In that regard Dell seem to fall in the 1-up category, but from everything I've read and seen, the build quality and design are a bit shoddy...
[02:03] <G> ibeardslee: haha, anything could be better than Ubuntu on my current desktop ;)
[02:03] <ibeardslee> a fresh install of the 14.04.02 kernel (essentially the same as the Vivid lts enablement) breaks the display for external monitors a bit
[02:04] <mwhudson> ibeardslee: or you could just run wily :-)
[02:04] <ibeardslee> that seems to be a problem as well
[02:04] <mwhudson> oh?
[02:04] <mwhudson> it's working fine for me
[02:04] <ibeardslee> hmmm
[02:04] <ibeardslee> with an external display?
[02:05] <ibeardslee> HDMI or the mini displayport?
[02:05] <mwhudson> external display
[02:05] <mwhudson> using a dock, mind
[02:06] <mwhudson> i've used the builtin hdmi to play stuff on tv at home
[02:06] <G> mwhudson: you use the OneLink Dock?
[02:06] <mwhudson> G: the onelink pro one yeah
[02:06] <ibeardslee> we use those as well
[02:07] <mwhudson> one "poorly documented" feature was that the dock can only drive one screen > 1080p
[02:07] <ibeardslee> need to still use the minidisplay port for the 2nd external monitor
[02:07] <ibeardslee> yes
[02:07] <mwhudson> ibeardslee: i thought that was a dock limitation, not a kernel one?
[02:07] <ibeardslee> well it can drive two, but they are cloned :(
[02:08] <ibeardslee> mwhudson: I understand that those docks are supposed to support two displays .. for a certain legacy operating system
[02:09] <ibeardslee> I could be wrong and misread something, which would be annoying.
[02:09] <mwhudson> ibeardslee: it works for two displays if both are set at 1920x1080
[02:10] <mwhudson> or it did for me when i was last fooling around with this
[02:10] <ibeardslee> hmm
[02:10] <ibeardslee> Looks like I may have to find some time to do some more playing
[02:10] <ibeardslee> .. testing
[02:10] <G> hmmmm, wonder how it'd react to two 1920x1200s then...
[02:13] <mwhudson> heh didn't try that
[02:14] <ibeardslee> mwhudson: that's with Wily?
[02:14] <mwhudson> ibeardslee: it was with vivid
[02:14] <mwhudson> i only have one monitor plugged in currently for $reasons
[02:15] <ibeardslee> G: of course that discussion about the silly high resolution on the display is irrelevant now, as we have a lower spec than what mwhudson got.
[02:15] <mwhudson> G: http://download.lenovo.com/ibmdl/pub/pc/pccbbs/options/tp_onelink_pro_dock_ug_en.pdf sez that two 1920x1200 is ok
[02:16] <ibeardslee> i5, 8GB, 256GB, 1920x1080 non-touch
[02:16] <mwhudson> ibeardslee: yeah, the hires screen is nice but not very practical
[02:16] <mwhudson> if only you could get 16GB somehow, it would be close to perfect
[02:17] <ibeardslee> we are getting the T550 for those that need a full on desktop replacement developer spec
[02:17] <ibeardslee> I had heard a rumour that the Gen 2 was supposed to have been available with 16GB
[02:17] <ibeardslee> but that seemed to be wrong
[02:18] <G> that is a good point, the hires on the same Intel 5500 can't be that great performance wise, just eat up more battery & that.
[02:18] <G> mwhudson: ibeardslee: what is the glare situation like?
[02:19] <mwhudson> G: the hires is just squinty ime :-)
[02:19] <mwhudson> G: um, fine? that's not the sort of thing i tend to get upset about in other laptops though
[02:19] <mwhudson> also i use an external display a lot of the time
[02:19] <ibeardslee> they seem to be reasonable, unfortunately I don't have one myself so haven't used it for extended time in different places
[02:20] <ibeardslee> reasonably ok
[02:20] <G> Thanks, main thing is, it works okay :)
[02:22] <ibeardslee> yes
[02:24] <mwhudson> yep
[02:24] <ibeardslee> on the whole we are pretty happy with them
[02:24] <ibeardslee> all 70 or so of the X1s
[02:25] <ibeardslee> as I remind each Dell Account Manager giving me a call
[02:25] <G> Yeah, well that is why even though the XPS is more up to date I'm seriously thinking of getting the Carbon instead
[02:26] <ibeardslee> can you get an XPS in NZ without a legacy OS?
[02:28] <G> Good point, that too (although I'm not so worried about that, it's only what, an extra 100-ish dollars OEM, not like I'm buying 100 of them :))
[02:29] <ibeardslee> Our theory at Catalyst has been that we want the suppliers records to show that they sold $x laptops without Windows
[02:30] <ibeardslee> we make serious effort to buy our laptops without a Windows licence
[02:31] <G> Yeah, I really do wish they'd make more of an effort in that regard
[02:36] <ibeardslee> according to the lastest Dell guy .. As discussed, please check the below link for Latitude E6450, click on help me choose option at Operating system section which shows that Ubuntu 12.04 Linux is available.
[02:36] <ibeardslee> http://www.dell.com/nz/business/p/latitude-e6540-laptop/pd?oc=cal204e6540nz&model_id=latitude-e6540-laptop&l=en&s=bsd
[02:40] <mwhudson> 12.04 woo
[02:40] <G> haha
[02:41] <G> I think I'll pass on Dell :)
[02:41] <ibeardslee> meh who really cares about the Linux version
[02:41] <mwhudson> oh yeah, you can't actually select it?
[02:41] <mwhudson> the xps developer editions looked pretty nice
[02:41] <mwhudson> before they sold out
[02:41] <ibeardslee> yeah, have to call or get in touch with Dell directly about it
[02:48]  * ibeardslee isn't looking forward to Dell actually starting to make laptops with Linux more readily available in NZ
[02:49] <ibeardslee> it means that I'd have to seriously consider getting them and then dealing with there 'support'
[02:49] <ibeardslee> s/there/their/
[19:06] <ibeardslee> morning
[19:06] <ibeardslee> a somewhat damp one in the capital
[19:25] <hads_> Morning. Hot one down here.
[20:33] <olly_> morning


[08:46] <binghe> :)
[09:36] <binghe> @handsome_feng
[09:36] <ubot5-ng> binghe: Error: "handsome_feng" is not a valid command.