[00:00] <infinity> Someone could perhaps educate him about the sun-java in partner, which is current.
[00:00] <infinity> Current, as in packaged for precise. :P
[00:01] <micahg> infinity: sun-java hasn't been in partner for 3 months
[00:01] <infinity> micahg: Oh.
[00:01] <bdmurray> hmm, the two duplicates are from different reporters
[00:01] <infinity> Nevermind, then.
[00:01] <infinity> bdmurray: Doing the same thing?
[00:02] <micahg> infinity: FYI, https://lists.ubuntu.com/archives/ubuntu-security-announce/2012-January/001554.html
[00:03] <infinity> bdmurray: Yeah, hardy on precise and hardy on oneiric.  Not sure if it was for the same REASON, but they've all done the same thing.
[00:03] <bdmurray> infinity: weird
[00:03] <infinity> micahg: Check, I missed that.
[00:05] <infinity> bdmurray: (The apport hook could, perhaps, include "cat /etc/apt/sources.list /etc/apt/sources.list.d/*"... Not everyone's quite as bizzarely log-parsing intuitive as I am)
[00:05] <skunk> i have a question about the linux kernel. When we write drivers.. do we write then to the kernel? Im confused.
[00:06] <infinity> skunk: Drivers can be external to the kernel or (ideally) committed upstream and included in the kernel sources.  Either way, they're "kernel code", and loaded into the kernel's address space.
[00:06] <infinity> skunk: Does that more or less answer your question?
[00:06] <skunk> kinda.. is that the reason why on alot of hardware ubuntu linux works out of the box??
[00:07] <skunk> hardware running ubuntu linux** i mean
[00:07] <infinity> It's the reason why Linux doesn't generally need you to download third-party drivers, right.
[00:07] <infinity> Except in the annoying case of binary-only 3D drivers.
[00:08] <infinity> (Though, we take care of doing that for you too)
[00:10] <skunk> yea lol.. makes sense.. I have a multi gesture touchpad that being run by a generic touchpad driver
[00:10] <infinity> bdmurray: Unless we intentionally don't do that because we think sources.list is an information leak... (Which I guess it is, if it has http://user:pass@hostname/ style entries in it)
[00:11] <skunk> i dunno how to improve it though, multitouch touchpad + ubuntu pixel perfect scrolling = mac like usability @ < $200
[00:12] <infinity> skunk: Talk to cnd for all your touchpad needs.  He LOVES talking about touch.
[00:12] <cnd> infinity, :)
[00:12] <skunk> ok thanks,. i think he has an email.. ill check the canonical website
[00:12] <skunk> oh
[00:13] <cnd> skunk, please describe your issue more?
[00:13] <infinity> (PS: By "mac like usability", do you mean "crashes when applying 11 fingers"?)
[00:14] <skunk> hello cnd, i have a acer aspire one D255 with a multigesture touchpad. But theres a generic driver running it. So i could only scroll on the right edge
[00:14] <skunk> i kin
[00:14] <cnd> infinity, I'm going to let that one slide...
[00:14] <infinity> skunk: Oh, edge versus two-finger scrolling is just a preference in settings.
[00:14] <cnd> infinity, not always
[00:14] <cnd> skunk, please pastebin the output of xinput
[00:15] <infinity> cnd: Well, not if multi isn't detected at all, I suppose.  But it's also set to edge by default, which I suspect confuses some people. :P
[00:15] <cnd> infinity, some touchpads actually send real scroll events when they are in "generic PS/2 mouse" mode
[00:16] <cnd> which they are by default, unless a Linux driver tells them to switch into a better mode
[00:16] <cnd> that's probably what is happening here
[00:16] <infinity> cnd: By "real scroll events", you mean buttons 4/5?
[00:16] <infinity> cnd: Or something extra special?
[00:16] <skunk> i really would like utilize the touchpad's abilty at the best possible. I did check the settings lol.. but it's not just that.. it would be nice to have things like zoom, rotate, switch between workspaces.
[00:16] <cnd> infinity, no, I mean the hardware device acts like a PS/2 mouse
[00:16] <cnd> and sends PS/2 scroll wheel events when you touch on the right edge
[00:17] <infinity> cnd: Yeah, and my PS/2 mouse used to send button events on scroll up and down. ;)
[00:17] <cnd> yeah, basically like that, but I thought you were implying at the X level
[00:17] <cnd> rather than at the hardware level
[00:17] <skunk> cnd: thats makes sense.. it's like a mouse emulator
[00:17] <infinity> Nah, I caught your meaning.
[00:18] <skunk> cnd: but ur gonna have to walk me through pastebin the output of ximput
[00:19] <cnd> skunk, install pastebinit
[00:19] <cnd> $ sudo apt-get install pastebinit
[00:19] <cnd> then install xinput
[00:19] <cnd> $ sudo apt-get install xinput
[00:19] <cnd> then pipe the output of xinput into pastebinit
[00:20] <skunk> cnd: wait.. can this still work on ubuntu 10.04?? or should I boot to precise?
[00:20] <cnd> $ xinput | pastebinit
[00:20] <cnd> skunk, uhhh... 10.04 was a *long* time ago :)
[00:20] <cnd> there wasn't any multitouch or gestures in 10.04
[00:20] <infinity> Chase was 11 when lucid came out.
[00:20] <cnd> you need to be on 12.04 :)
[00:20] <skunk> cnd: sorry.. ill boot to 12.04...
[00:21] <skunk> brb
[00:21] <cnd> :)
[00:23] <RAOF> cnd: While you're here - is the fact that Unity fails to recognise any gestures if I connect a magic touchpad after Unity loads a geis limitation or a Unity limitation?
[00:24] <cnd> RAOF, it's likely a geis bug
[00:24] <cnd> please file a bug and we'll take a look
[00:25] <RAOF> cnd: Is there a particular package to file against for maximum apport-hookage?
[00:25] <cnd> RAOF, not really, but utouch-geis is probably the real culprit
[00:26]  * infinity wonders what happens if one runs sru-release while something is ACCEPTED, but not yet published.
[00:27] <infinity> And as much as I'd like to test the theory, I don't feel like cleaning the mess.
[00:30] <cnd> so xserver-xorg-input-evdev really is getting compiled in a way that causes it to pass a bad address to an X server function
[00:30] <cnd> but only when compiled with optimizations...
[00:30] <cnd> and only on x86
[00:30] <RAOF> cnd: Have a fresh bug #1009270
[00:30] <cnd> RAOF, thanks :)
[00:30] <RAOF> cnd: That's wonderfully obscure.
[00:31] <cnd> I think I'm going to have to pester doko about it
[00:31] <RAOF> cnd: So just a rebuild won't fix that. Huzzah!
[00:31] <cnd> yeah
[00:31] <cnd> I thought a rebuild would fix bug 973297
[00:31] <cnd> because I had rebuilt and it went away
[00:32] <cnd> but I rebuilt without optimizations
[00:32] <cnd> the odd thing is that it only occurs in one area of the code
[00:32] <cnd> in other areas of the code, the function is called and behaves properly
[00:37] <cnd> hmm... skunk needs to come back soon
[00:37] <cnd> I need to go make dinner
[00:38] <infinity> Maybe rebooting set his laptop on fire..
[00:39] <RAOF> Speak of the devil!
[00:39] <skunk> cnd: im back with my pastebin, it turns out i do have a "ps/2 mouse"
[00:39] <skunk> âŽ¡ Virtual core pointer                    	id=2	[master pointer  (3)] âŽœ   â†³ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)] âŽœ   â†³ PS/2 Mouse                              	id=12	[slave  pointer  (2)] âŽœ   â†³ AlpsPS/2 ALPS GlidePoint                	id=13	[slave  pointer  (2)] âŽ£ Virtual core keyboard                   	id=3	[master keyboard (2)]     â†³ Virtual core X
[00:40] <cnd> skunk, I was hoping you could copy and paste the link you got from pastebinit :)
[00:40] <skunk> sorry again.. give me a few seconds
[00:40] <cnd> np :0
[00:40] <cnd> at least it wasn't an Xorg.log file
[00:40] <skunk> http://paste.ubuntu.com/1026027/plain/
[00:41] <cnd> ugh, why do I have to log in to see a public pastebin?
[00:41] <cnd> skunk, so most likely you have a trackpad that the Linux kernel doesn't have a driver for yet
[00:42] <skunk> yeah.. thats why i was wanting to make one. its very challenging tho
[00:42] <cnd> :(
[00:42] <cnd> you probably will have to reverse engineer it
[00:42] <cnd> which requires having a kvm setup and using passthrough ps/2 techniques
[00:42] <skunk> kvm??
[00:42] <cnd> and *then* figuring out how to modify the existing alps linux driver for your new device
[00:43] <infinity> cnd: You have to log in because he linked the /plain/ URL.
[00:43] <cnd> skunk, kvm is the open source version of vmware or parallels
[00:43] <cnd> infinity, what difference does that make?
[00:44] <infinity> cnd: /plain/ is password-protected due to some belief that people use pastebins to distribute teh sw33t w4r3z.
[00:44] <cnd> skunk, basically, I want to warn you that getting a driver for your trackpad working is a very non-trivial task
[00:44] <infinity> cnd: I have no comment beyond that. :P
[00:44] <cnd> ugh
[00:44] <cnd> skunk, if you want to attempt it though, sforshee has already done it once for alps trackpads :)
[00:45] <cnd> I don't know the kvm magic he did to get the raw packets, but he could tell you
[00:45] <skunk> when you say "non-trivial" what do you mean?? it sounds like its very trivial lol
[00:53] <cnd> skunk, you have to run windows in a virtual machine
[00:53] <cnd> inside of a kvm instance
[00:53] <cnd> then get the PS/2 packets from the virtual machine as it talks through linux to the real hardware
[00:53] <cnd> I don't know if you need special kvm patches for that step
[00:54] <cnd> then you need to reverse engineer the actual protocol of the trackpad
[00:54] <infinity> No special patches required if you don't mind running kvm in gdb.
[00:54] <infinity> (don't do this if you value your sanity)
[00:54] <skunk> gdb??
[00:56] <cnd> skunk, based on your questions, it sounds like you may not be ready to take on the task yet without a large amount of effort and work
[00:56] <cnd> you can use this to learn about all the tools and how to develop on linux
[00:56] <cnd> that would be a great teaching task
[00:56] <cnd> but this isn't trivial by any stretch
[00:58] <skunk> yes i know..but successfully doin it will teach alot about linux development.. embarassingly enough ive been a linux user since 06
[00:58] <cnd> skunk, that's not embarassing at all :)
[00:58] <cnd> everyone transitions from user to developer at some point :)
[00:58] <cnd> well, I mean, every developer went through a "just a user" phase
[00:59] <skunk> cnd: but you were saying that i could use what?? i mean to learn
[01:00] <skunk> .. and yes i know.. it;s nice to see how much has changed with ubuntu since 6.06. and im still here :)
[01:00] <cnd> skunk, you need to use many tools along the way
[01:00] <cnd> kvm is a key tool here that will help with reverse engineering
[01:01] <cnd> gdb is a debugger that you will likely use at some point, but probably not for the reverse engineering
[01:01] <cnd> skunk, however, I have to go make dinner now :(
[01:01] <skunk> ok.. is there something you could point me to? you know.. to get started?
[01:01] <cnd> skunk, have you developed programs on linux before?
[01:01] <cnd> using c?
[01:01] <skunk> yes.. but for school
[01:01] <skunk> no java
[01:02] <skunk> lol i know where this is going.. but yes.. it looks like i need to know something lower lever
[01:02] <skunk> level**
[01:02] <RAOF> You will indeed need to learn C.
[01:02] <skunk> looks like tomorrows a long trip to the library lol..
[01:03] <skunk> but thanks guys. ive beenwaiting for this conversation for weeks
[01:03] <cnd> skunk, yeah, the first step will be to learn how to develop a program with C
[01:03] <cnd> and get used to the toolchain and tools
[01:03] <cnd> gcc, gdb in particular
[01:03] <RAOF> Which is ok, because it's pretty easy - almost all of your knowledge will translate across, you'll just need to learn some different syntax, pointers, and manual memory management.
[01:03] <skunk> yeah.. you think i should review java first?/
[01:03] <cnd> ok, I'm out, good luck skunk!
[01:03] <skunk> kk thanks cnd
[01:04] <skunk> RAOF: you think i should review java first?? i mean.. wouldnt it be good for things like recursion and that??
[01:05] <RAOF> I don't think there's any particular reason to review java first; it's not *that* much easier.
[01:06] <skunk> kk
[01:06] <skunk> thanks
[01:50] <YokoZar1> Are the cloud.ubuntu.com ami images "official" ?  There's a bit of a regression in them related to the grub update that just went out
[03:05] <ScottK> !regression-alert
[03:05] <ScottK> YokoZar1: Yes.  What's up.
[03:05] <ScottK> !regression
[03:05] <ScottK> !regression-alert
[03:05] <ScottK> Yes, that's supposed to be the alert.
[03:05] <ScottK> RAOF: I guess you're likely awake and on the SRU team ... ^^^ not sure what's up though.
[03:06] <ScottK> Ah.  There it goes.
[03:06] <ScottK> That list should get updated.
[03:07] <skaet> YokoZar1,  has someone opened a bug?
[03:08] <RAOF> YokoZar1: You're talking about the https://launchpad.net/ubuntu/+source/grub2/1.99-21ubuntu3.1 update?
[03:09] <YokoZar1> RAOF: skaet: just opened it, LP: #1009294
[03:09] <YokoZar1> ScottK: ^^
[03:11] <skaet> thanks YokoZar1,   RAOF,  I'll start off the incident report,  can you start figuring  out what our best path forward is?
[03:12] <RAOF> skaet: Ok.
[03:12]  * skaet notes that the notification list on ubottu probably needs changing.
[03:12] <ScottK> It does.
[03:14] <YokoZar1> It's worth noting that the /etc/default/grub appears to be modified on the cloud.ubuntu.com AMIs (which are official I guess)
[03:16] <skaet> smoser, utlemming ^ if either of you are around, can you help us look into this?
[03:17] <vibhav> seb128: ping
[03:18] <TheMuso> vibhav: He is offline atm.
[03:18] <RAOF> Ok, so it's a ucf managed conffile.
[03:18] <vibhav> ah, fine
[03:18] <RAOF> Which is why you don't see it in dpkg -S
[03:19] <YokoZar1> Ahh, learn something new every day
[03:20] <RAOF> Workaround: setting the environment variable UCF_FORCE_CONFFNEW (or UCF_FORCE_CONFFOLD) should bypass that, and silently install the new (or leave the old) file.
[03:22] <RAOF> I'm not entirely sure what we should do about it at this point. It's not *really* a regression, but it is exposing an annoyance.
[03:24] <micahg> why is the file showing as modified though?
[03:24] <YokoZar1> micahg: probably cause it is (on the Ubuntu AMIs at least)
[03:24] <YokoZar1> micahg: if I click the diff button there are actual differences
[03:25] <YokoZar1> RAOF: this will happen with just about every UCF managed conffile then won't it?  (Why do we have something managing conf files other than dpkg?)
[03:25] <RAOF> YokoZar1: Yes, it will.
[03:25] <RAOF> We have ucf because dpkg's conffile handling doesn't extend far enough to handle things like /etc/default/grub.
[03:26] <YokoZar1> RAOF: what does that env variable need to be set to?
[03:26] <RAOF> Other things use it because it can eg: do a 3-way merge on package upgarde.
[03:27] <YokoZar1> RAOF: ahh, reasonable (though having two separate places to configure this sort of option is a pain now)
[03:27] <RAOF> Yes.
[03:27] <YokoZar1> UCF_FORCE_CONFFOLD=1 sudo apt-get dist-upgrade?
[03:29] <RAOF> Yeah; I've added that as an answer on the askubuntu question.
[03:29] <RAOF> Now we merely need to work out what to do about this.
[03:30] <RAOF> We can revert, but that'll prompt *again* for anyone who has already upgraded. And obviously re-introduces the dist-upgrade bug.
[03:31] <RAOF> Incidentally, I've forgotten what set of environment variables get stripped out by sudo.
[03:33] <RAOF> We can't unconditionally replace /etc/default/grub for everyone, and it's probably not a good idea to try to special-case the AMIs.
[03:33] <RAOF> YokoZar1: Do you have any idea why the AMIs have a different /etc/default/grub? Do you have any idea how that's generated?
[03:34] <YokoZar1> RAOF: not really, no.  My suspicion is it has something to do with booting quicker since it's always unprompted (indeed those are the two options changed)
[03:38] <RAOF> In which case, I *think* that should be handleable with a 3-way merge; ucf is just prompting to make sure users get an option. I wonder what would happen if you set a noninteractive debconf?
[03:39] <YokoZar1> RAOF: how do I test that?
[03:39] <YokoZar1> UCF_FORCE_CONFFOLD=1 sudo apt-get dist-upgrade  didn't seem to work btw
[03:40] <mwhudson> swap the sudo and the env var ?
[03:40] <mwhudson> sudo strips most environment variables by default i think
[03:42] <YokoZar1> bbialb
[03:43] <RAOF> Setting noninteractive debconf also works.
[03:50] <pitti> Good morning
[03:51] <pitti> barry: hello
[03:51] <RAOF> Good morning pitti!
[03:51] <RAOF> I see it's time for my lunch!
[03:55] <RAOF> pitti: I'd value your evaluation of the grub/AMI situation YokoZar/ScottK/skaet and I have been discussing above - bug #1009297
[03:56] <RAOF> Urgh, 7 is not 4
[03:56] <RAOF> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1009294
[03:57] <RAOF> It's not strictly-speaking a regression, and it is a flaw in those scripts, but it seems sufficiently annoying to do something about. I just don't really know *what*.
[03:58] <pitti> RAOF: so an SRU changed a non-dpkg config file into a conffile?
[03:58] <pitti> that sounds like a serious no-no
[03:58] <RAOF> No, an SRU changed a ucf-managed conffile.
[03:58] <RAOF> It's not a conffile in either case.
[03:58] <pitti> is that from http://launchpadlibrarian.net/105151158/grub2_1.99-21ubuntu3_1.99-21ubuntu3.1.diff.gz ?
[03:58] <pitti> ah, ok
[03:58] <RAOF> Yup.
[03:59] <skaet> https://wiki.ubuntu.com/IncidentReports/2012-06-05-grub-in-cloud-images <-- Incident Report Started
[04:00] <pitti> so the problem is that the AMI scripts change the grub configuration locally in a way ucf doesn't know about?
[04:00] <pitti> sorry, I don't know anything about how the AMI images work
[04:01] <RAOF> I think that the problem is (a) the AMI scripts change the grub configuration locally, and (b) we've pushed an update that changes the grub configuration, so ucf is going to prompt.
[04:01] <RAOF> I think that both of those behaviours are individually correct, but the combination is going to be frustrating.
[04:02] <RAOF> At least until the AMIs get grub from precise-updates in the base images (will they? I don't know how the AMIs are spun or really anything about them).
[04:02] <pitti> I don't think that (a) is correctr
[04:03] <pitti> changing any automatically managed conffiles in scripts is a disaster waiting to happen
[04:03] <pitti> regardless of dpkg or ucf
[04:03] <pitti> but oh well, there's little we can do about it for the precise images now
[04:03] <pitti> so there is no way to tell ucf "consider this the new pristine conffile"?
[04:04] <pitti> i. e. something which the AMI script builders could call after modifying grub's default?
[04:04] <pitti> RAOF: not knowing either well, my best advice is to revert the grub SRU and replace it with an SRU that only modifies the grub configuration if it is not locally modified
[04:05] <RAOF> They could do that, but then I think this update would have silently overwritten their grub configuration.
[04:05] <pitti> so that the fix for bug 978464 does not affect the AMI images at all
[04:07] <RAOF> That would work. Let's see how hard that would be.
[04:08] <RAOF> u
[04:09] <RAOF> ...quite easy.
[04:09] <RAOF> Ok.
[04:16] <skaet> pitti,  its getting late here for me,  can I hand off the tracking on this issue to you until Daviey comes on line?   I think he'll need to weigh in.
[04:16] <pitti> skaet: seems RAOF is already on a fix?
[04:17] <skaet> pitti,  yeah,  but incident report started needs explicit handoff.
[04:17] <RAOF> pitti: Yeah. I can upload the revert directly to precise-updates, right, and then upload a fixier fix to precise-proposed?
[04:17] <pitti> RAOF: I'd start with a -proposed upload, give it a quick test (upgrade, reboot, to guard against misbuilds)
[04:17] <pitti> RAOF: and then copy to -updates immediately after
[04:19] <RAOF> That is indeed a better plan.
[04:19] <pitti> RAOF: that'll delay things by half an hour, but that seems acceptable to me
[04:19]  * ScottK thinks the explicit handoff requirement is one of the best features of the process.
[04:26] <pitti> skaet: acknowledging, I'll update the report as events happen until Daviey comes online
[04:26] <skaet> Thanks pitti.   Appreciate it.
[04:27]  * skaet --> zzz
[04:30] <RAOF> grub2 revert accepted into -proposed
[04:33] <pitti> noted so in the report
[04:35] <RAOF> Now to find a precise system to upgrade...
[04:37] <pitti> RAOF: I can help testing on my wife's computer
[04:37]  * pitti updates that to the latest packages, so that testing the two grubs in -proposed will be faster
[04:53] <vibhav> Why is https://code.launchpad.net/~ubuntu-branches/ubuntu/lucid/pcb/lucid in "Development" ?
[04:58] <vibhav> wait, all lucid branches are in development, why?
[05:03] <maco> vibhav: two theories: 1) lucid is still supported so development is still happening to fix bugs and such 2) nobody ever gets around to changing branch status away from "development"
[05:08] <pitti> RAOF: my wife's machine is fully upgraded, currently at grub ubuntu3.1; waiting for 3.2 to get published
[05:14] <RAOF> Ta.
[05:14] <RAOF> Bah. ubuntu-vm-builder doesn't want to cooperate, it seems.
[05:21] <slangasek> RAOF: sorry, but this analysis is wrong.  The ucf prompt is about /etc/default/grub; the SRU does *not* change /etc/default/grub, it only changes /boot/grub/grub.cfg
[05:22] <slangasek> I don't know why it results in a prompt when there's no change to /etc/default/grub in this SRU, but whatever it is would probably have happened on *any* update to grub
[05:24] <RAOF> ...
[05:24] <slangasek> which means a second SRU would also trigger the same issue...
[05:25] <RAOF> Hm. So how is the /etc/default/grub prompt generated?
[05:25] <slangasek> by ucf in the grub-pc postinst
[05:25] <RAOF> Well, I know that. I guess what I mean is *why* is the /etc/default/grub prompt generated.
[05:26] <slangasek> yeah, I'm not sure yet
[05:26] <slangasek> looking
[05:26] <RAOF> Oh.
[05:26] <RAOF> If the AMI build process changes /etc/default/grub but doesn't update ucf's checksum of /etc/default/grub, ucf should notice that at next update, right?
[05:27] <pitti> oh, so it'd happen whenever you update grub, regardless of what that update actually does?
[05:27] <slangasek> so the postinst calls ucf thusly:ucf --three-way --debconf-ok --sum-file=/usr/share/grub/default/grub.md5sum ${tmp_default_grub} /etc/default/grub
[05:27] <slangasek> that's *supposed* to not prompt *at all* if the 'base' and 'other' versions of the file are identical
[05:28] <slangasek> so either this has to do with the --sum-file argument (which I've never seen used before)
[05:28] <slangasek> or the AMI has badly mangled the ucf database
[05:28] <slangasek> or it's a bug in ucf
[05:29] <pitti> seems we should remove that grub from -proposed then?
[05:29] <slangasek> yes please
[05:30] <pitti> removing binaries from accepted queue; they never got published
[05:31] <pitti> and removed source from precise-proposed
[05:31] <StevenK>  /usr/share/grub/default/grub.md5sum seems to be very strange on my machine.
[05:34] <pitti> I guess/hope it only really considers the possible md5sums, not the identifiers after them?
[05:35] <RAOF> None of the md5sums in /usr/share/grub/default/grub.md5sum match this freshly-installed grub-pc in my precise chroot.
[05:35] <pitti> 038c1c68801ef42ad81fa4d00f67fbc1  /etc/default/grub
[05:36] <pitti> here
[05:36] <pitti> right, not in my grub.md5sum file
[05:36] <RAOF> Likewise.
[05:36]  * slangasek nods
[05:43] <slangasek> pitti, RAOF: I have a modified /etc/default/grub here and can't reproduce the issue.  I think something in the AMI build is tampering with /var/lib/ucf.
[05:43] <RAOF> I can't seem to get an ucf upgrade prompt for /etc/default/grub at all.
[05:45] <RAOF> Time for me to get some actual lunch.
[05:45] <skunk> RAOF: what part of the world are u from??
[05:46] <slangasek> oh; I bet you can get one by running dpkg-reconfigure grub-pc and mucking with the timeout settings
[05:46] <slangasek> hmm, no, because I don't get a debconf prompt for that either ;P
[05:46] <skunk> anyways.. does anyone notice how the scrolling in the ubuntu software centre is no good?
[05:46] <skunk> like kipping over itself??
[05:46] <skunk> skipping**
[05:47] <pitti> slangasek: OOI, how would that behave differently than manually modifying the file?
[05:48] <pitti> I tried that here, and reinstall grub2-common; no prompt here
[05:48] <slangasek> pitti: because 'dpkg-reconfigure grub-pc' changes the *package's* version of the config file
[05:48] <slangasek> i.e., the one to be proposed for merging
[05:48] <pitti> urgh, it modifies the one in /usr/share/ ?
[05:48] <slangasek> no, it creates a temp file
[05:48] <slangasek> and merges from that
[05:49] <skunk> i guess not?? should just report as bug?
[05:49] <pitti> ah, "package's version" == what ucf considers "distro default"
[05:49] <slangasek> skunk: sounds like it should be a bug report, yes
[05:49] <slangasek> pitti: yep - which may be postinst-generated, as in this case
[06:20] <slangasek> RAOF, pitti: so I've done some analysis and posted it to the bug; this is a bug in the cloud image, not in grub-pc, and any grub update would trigger it
[06:20] <pitti> slangasek: thank you
[06:21] <pitti> slangasek: so fixing the AMI build process is the way forward, and for this one upgraders just need to deal with the prompt or set DEBIAN_FRONTEND?
[06:21] <slangasek> yep
[06:25] <RAOF> slangasek: Thanks for that.
[06:25] <slangasek> no prob
[06:25] <slangasek> I'm off to bed now :)
[06:52] <dholbach> good morning
[07:17] <dholbach> Laney, done
[07:56] <pitti> Daviey: good morning
[08:10] <apw> pitti, do we have UDD branches for clean debian, for when they are ahead of us ?  /me thought we did
[08:14] <Daviey> hola, pitti o/
[08:14] <pitti> Daviey: hey
[08:15] <pitti> Daviey: I kept track of https://wiki.ubuntu.com/IncidentReports/2012-06-05-grub-in-cloud-images until now; did you see it in scrollback?
[08:16] <Daviey> i have, yes.
[08:16] <Daviey> So.. this is fallout from bug 759545
[08:17] <Daviey> Still catching up on comments for this incident
[08:17] <Daviey> I hoped another avenue for resolving it would have been via bug 901600
[08:19] <Daviey> is slangasek still around?
[08:20] <micahg> he said he was going to bed ~2hrs ago
[08:20] <pitti> Daviey: no, he went to sleep
[08:20] <pitti> Daviey: I'm OTP right now, sorry for lagging
[08:20] <Daviey> pitti: ok, thanks
[08:20] <Daviey> infinity: around?
[08:20] <pitti> Daviey: by now it's clear that the bug is in the AMI build scripts
[08:21] <Daviey> pitti: I don't see how this is a new bug...
[08:21] <pitti> it's not
[08:21] <pitti> it just got exposed by that grub update
[08:21] <Daviey> pitti: i mean, it's a known issue.. we've constantly been hitting this, as decalred in bug 759545.
[08:22] <pitti> Daviey: ah, ok; so this is a duplicate?
[08:22] <pitti> Daviey: anyway, can I hand over https://wiki.ubuntu.com/IncidentReports/2012-06-05-grub-in-cloud-images to you now?
[08:23] <Daviey> pitti: I believe it is a duplicate, but still catching up.  Sure, i can take it from here.
[08:23] <Daviey> Thanks for driving it so far.
[08:23] <pitti> thanks
[08:31] <xnox> stgraber: cjwatson: do you remember a bug in grub/grub2 about adding extra checksums for the /etc/default/grub ? because it looks like it's affecting server this time around in bug 759545
[08:32]  * Laney snuggles dholbach 
[08:32] <apw> can someone remind me where the package importer hides its logs
[08:32] <xnox> apw: somewhere in package-import.ubuntu.com?
[08:32] <micahg> apw: http://package-import.ubuntu.com/status/
[08:33] <apw> thanks :)
[08:33] <pitti> apw: yes, we should; lp:debian/package ought to work
[08:33] <apw> pitti, ahhh ... i was trying debian/unstable/xxx doh
[08:34] <pitti> apw: that actually ought to work, too; but I haven't tested it
[08:34] <pitti> at least lp:ubuntu/precise/foo works
[08:34] <apw> pitti, hmmm, seems its /sid/ ...
[08:34] <pitti> ah
[08:47] <dholbach> Laney, \o/
[08:49] <ion> I wonder what is the right channel for questions about the commercial PPAs?
[09:08] <apw> ion, hmmm ... thats a good one ... i know there is an email address
[09:09] <czajkowski> aloha
[09:09] <apw> ion, czajkowski may be able to answer your question
[09:09] <czajkowski> ion: hiya how an I help?
[09:10] <ion> I’m just curious about when Psychonauts from the Humble Bundle is going to become available in the PPA. :-)
[09:11] <ion> The page has said “check back soon” for a while now. :-P
[09:11] <czajkowski> ion: let me find out
[09:14] <czajkowski> ion: no definate time but it will happen as soon as they get it ready
[09:14] <ion> Alright, thanks. It might be nice if the software-center.ubuntu.com page was less ambiguous about that, it’s unclear whether one should check back in an hour or in a month. :-)
[09:22] <apw> maxb, i am seeing issues with automake1.11 package imports, definatly for ubuntu and i think for debian as well, i wonder if you could cast an eye and tell me if thats something we can fix or we should be pushing over it
[09:26] <maxb> apw: acknowledged, I have some time later today when I can look at it
[09:26] <apw> maxb, puuurfect thanks
[09:36] <cjwatson> xnox: no specific bug comes to mind, but we've certainly added checksums before ...
[09:37] <xnox> cjwatson: ok. i think it was  https://launchpad.net/bugs/759545
[09:48] <apw> pitti, it seems cups has ftbs'd on ubuntu due to a new interface in a library (at least thats my interpretation of the log) is that something we might expect to allow, and if so is that something we carry as delta when it occurs ?
[09:49] <apw> pitti, this is on arm* only
[09:49] <pitti> apw: no, that shouldn't be a delta IMHO; I guess we could add it as an optional symbol into the .symbols file?
[09:51] <apw> pitti, ok will test and make sure that works as expected
[09:53] <apw> pitti, is this your master vcs branch: http://bzr.debian.org/pkg-cups/cups/debian-trunk/
[09:53] <pitti> right
[09:57] <apw> pitti, there is an incantion for packaging only branches to 'instantiate' the source into them isn't there ... can you remind me
[09:57] <pitti> apw: ah, that's "bzr bd-do"
[09:57] <pitti> that'll throw you into a "working tree" with the source
[09:57] <apw> pitti, our naming is somewhat terse :)
[09:57] <pitti> you can edit and test there
[09:58] <pitti> and if you exit 0, the changes will be written back to your checkout
[09:58] <pitti> exit != 0 and they will be thrown away
[09:58] <pitti> apw: well, it's something we have to type over and over every day, it better be short :)
[09:58] <pitti> apw: "bzr builddeb-do" if you prefer
[10:07] <apw> pitti, so should i be filing a bug in LP for this FTBS to include in any fix
[10:08] <pitti> apw: if you prefer a bug, sure; I'm also happy to just commit a patch if you have one, or merge a branch
[10:08] <apw> pitti, if you don't need a bug i don't need one either, will prepare a branch, its good for me
[10:08] <pitti> apw: we can't upload it during the freeze anyway, but then it's at least there for the next Debian/ubuntu upload
[10:08] <pitti> apw: many thanks for working on this!
[10:35] <apw> pitti, heh np, whats the incanation to get any package source at a specific version ...
[10:36] <pitti> apw: if you checked out "trunk", something like "bzr branch -r tag:1.2.3-4 trunk cups-1.2.3-4
[10:36] <pitti> apw: if you merely want to check a particular file at a particular version, you can also use bzr cat -r tag:1.2.3-4 debian/foo
[10:37] <apw> pitti, isn't there a ubuntu-devel type command for it, to get the uploaded dsc etc
[10:37] <apw> pitti, though thats useful to know too :)
[10:37] <pitti> apw: ah, sure; I thought you meant from bzr
[10:37] <cjwatson> apw: pull-lp-source
[10:37] <pitti> apw: pull-lp-source
[10:37] <apw> thanks :)
[11:05] <xnox> Got my quad HDD usb 3.0 docking station for RAID testing. Win! Discover bug #966248. Fail!
[11:09] <Daviey> xnox: i'm using a machine atm with 3 ports, 2 of them do not work.. but the yellow one does.. So i might have the same issue.
[11:09] <matttbe> Hello
[11:09] <matttbe> I have (maybe a stupid) question for chrisccoulson: why I see that Mozilla Firefox 14.0 beta 6 is currently building? I thought the 14.0 version was still in alpha, no?
[11:13] <doko> Sweetshark, ping
[11:15] <chrisccoulson> matttbe, surely the fact that it exists in the archive is enough to answer your question, isn't it?
[11:15] <matttbe> (sorry, I guess I'm wrong because this web link exists: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/14.0b6-candidates/ but there is no other beta)
[11:15] <chrisccoulson> and the release calendar is public too https://wiki.mozilla.org/RapidRelease/Calendar
[11:16] <matttbe> chrisccoulson: yes, sorry, it was just strange to see a beta 6 but without any previous beta versions
[11:17] <chrisccoulson> oh, that is to align the version numbers with mobile, which already had several release from the current ff14 branch
[11:19] <matttbe> chrisccoulson:  ok, thank you for this explanation. I thought it was a typo even if I know it's quite imposible :)
[11:33] <xnox> Daviey: I don't have a yellow one, only the blue one. I will try my housemate's yellow, when he comes back. This needs following up with kernel team =) cause I do want usb3.0 for raid testing across all four of my drives.
[11:34] <gogo_> Hello, I think there is a regression in latest Unity update
[11:35] <nemo> libcairo2 1.11? :)  'cause. that's why I'm hanging out here.  Ok, that's not exactly Unity.
[11:35]  * xnox and Daviey are not talking about skittles
[11:36] <nemo> hrm. you know... how *did* I end up w/ 1.11 - checking launchpad, precise is still on 1.10.  You know. n/m - maybe I'd just somehow installed some test version of some repo
[11:36] <nemo> and thus deserved any probs I got
[11:36] <nemo> righto. l8r
[11:44] <apw> maxb, it looks like fonts-nanum is in the same state when you get there
[11:56] <Daviey> xnox: generally, having only one working usb port on modern laptops is bad karma, right? :)
[11:56] <xnox> Daviey: I have 2 working USB2.X and 1 non-working USB3.X =(((( yeap it is bad karma =)
[11:57] <ogra_> does it get substracted then from your launchpad account ?
[11:58] <Daviey> dputblame should be a new tool that does just that.
[11:58] <ogra_> haha
[11:59] <Daviey> I fear i'd end up with negative karma.. :)
[12:20] <smoser> YokoZar, /etc/default/grub is modified by default in the images.
[12:20] <smoser> that is by design (known) causes config file change prompt on upgrade.
[12:26] <smoser> if you're aware of a way in which we can make the needed changes (http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/view/head:/vmbuilder-cloudimg-fixes) I'm more than interested in knowing.
[12:27] <smoser> skaet, ^
[12:33] <Daviey> smoser: Are you following the incident log?
[12:34] <TobsCorre> Hey Guys. After getting a lot from Ubuntu I'd like to give something back.
[12:34] <TobsCorre> So I'd like to translate some programs, or some of the interface. Is there a website that manages some of the programs, so I could apply some translations?
[12:35] <lynxman> tumbleweed: ping :)
[12:36] <smoser> Daviey, incident log?
[12:36] <smoser> i'm missing something.
[12:36] <Sweetshark> doko: pong
[12:36] <Daviey> smoser: https://wiki.ubuntu.com/IncidentReports/2012-06-05-grub-in-cloud-images
[12:37] <pitti> smoser: slangasek pointed out in the bug how to do that
[12:43] <smoser> so what am i missing.
[12:43] <maxb> apw: So, the automake1.11 problem appears to be that pristine-xz is failing to identify the compression options for the .orig.tar.xz. I've sent a mail to ubuntu-distributed-devel@l.u.c to discuss upgrading pristine-xz on the importer
[12:43] <smoser> is there some solution in bug 1009294? I do not see one. only "AMI image build probably needs to inject the grub settings via debconf preseeding, so that ucf as shipped in the image knows the intended answers to the debconf questions."
[12:43] <apw> maxb, ahh probabally the same same on fonts-nanum then, thats xz using
[12:44] <smoser> i've asked more than once how i could fix this, and never been given an answer.  grub configuration has caused more than a little bit of pain for me.
[12:56] <pitti> smoser: the workaround for the already existing updates seems to be to update with DEBIAN_FRONTEND=noninteractive
[12:57] <pitti> but I guess the build process should be changed to use debconf instead of manually changing the file
[12:59] <smoser> pitti, and how do i do that with debconf?
[12:59] <smoser> note, i've asked this for 2 years
[13:00] <smoser> (and also note, cloud-init does the right thing with debian_frontend=noninteractive and force-confold
[13:00] <pitti> I had assumed that this works by poking the changed variables with db_set and dpkg-reconfigure grub2-common
[13:00] <Daviey> pitti: I seem to remember we were going to put the updated hashsum into debconf but was advised there was a better way to do it.
[13:01] <infinity> Daviey: Oh hey, if this is a bug in the AMI build scripts, that would explain why I could never make it happen manually. :/
[13:01] <Daviey> infinity: Then why the heck didn't you tell us that?
[13:01] <Daviey> I thought it just fell off your plate...
[13:02] <infinity> It did.
[13:02] <infinity> "Couldn't reproduce" didn't mean "I then gave up", I means "I ran out of time to try harder".
[13:02] <Daviey> ah, ok :)
[13:03] <infinity> I do find it midly amusing, though, that a config file prompt is now considered worthy of an incident report and escalation.
[13:03] <infinity> It's a bug.  We have lots of bugs.
[13:04] <smoser> infinity, THANK YOU!
[13:04] <dobey> is there no tool to check which files from a package have been modified?
[13:04] <smoser> i did find that mildly amusing also
[13:04] <Daviey> infinity: I think the incident report was started because it was considered an SRU regression initially
[13:04] <smoser> i look forward to the day when we have so few bugs that all are worth of incident reports.
[13:05] <smoser> s/worth/worthy/
[13:05] <Daviey> well, SRU regressions *should* have Incident Reports...
[13:05] <geser> dobey: like debsums?
[13:05] <Daviey> so yes, i look forward to that day :)
[13:06] <infinity> Daviey: I don't agree with that statement either.  SRU regressions of high impact should have a stop-the-pressed effect.  Low impact ones should be fixed with... Another SRU.  Which happens all the time.
[13:16] <vibhav> Could anybody see https://bugs.launchpad.net/ubuntu/+source/zerofree/+bug/1009412 ?
[13:19] <geser> vibhav: the version should be 1.0.1-4ubuntu1 and you should close the merge bug in your changelog entry
[13:20] <vibhav> ah
[13:20] <vibhav> let me take a look
[13:20] <dobey> geser: thanks. searching the interwebs wasn't so helpful :)
[13:21] <geser> and it's usually preferred to have a debdiff against the Debian version you merged
[13:44] <tumbleweed> lynxman: hi
[13:44] <Daviey> infinity: I'm not part of the SRU team, and perhaps it's best handled by their process.  However, as a product leader.. any SRU regression i'd like bloody well documented.. and i don't think a bug is enough.
[13:53] <cjwatson> Daviey: It's debatable whether this is a regression, though.
[14:01] <Daviey> cjwatson: No, i'm saying that it wasn't incorrect to start an incident report when it was thought it was.
[14:01] <cjwatson> Fair enough
[14:11] <pitti> barry: just uploaded my first apport crash data blob with python3 apport :)
[14:11] <barry> pitti: \o/
[14:14] <s-fox> Hey nigelb :)
[14:14] <nigelb> hey s-fox!
[14:15] <pitti> barry: it says this now when you actually need the lplib functionality: http://paste.ubuntu.com/1026903/
[14:15] <pitti> barry: so I'll wiggle the dependencies accordingly
[14:16] <barry> pitti: i like your plan.  anything to reduce desktop dependencies is a win. :)
[14:16] <s-fox> nigelb, Thanks for the channel name and contact. Looking to get this in for 12.10 - https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/602265/comments/19
[14:16] <barry> pitti: can i help in any way?
[14:16] <pitti> barry: you could cross fingers that https://staging.launchpad.net/ comes back online soon :)
[14:16] <pitti> barry: I just wasted an hour debugging a HTTPError which suddenly appeared after I changed stuff from string to bytes
[14:16] <barry> pitti: fingers, toes *and* eyes!
[14:16] <lynxman> tumbleweed: hey, I just updated the mcollective merge request, thank you so much for your review :)
[14:17] <barry> ouch
[14:17] <pitti> barry: it turned out that it was actually working, just staging went down underneath me :)
[14:17] <barry> :-D
[14:17] <pitti> I can run it against production just fine
[14:17] <nigelb> s-fox: aha
[14:17] <s-fox> I mean we have even supplied a file to drop in. Just need to get it replaced now. haha
[14:18] <tumbleweed> lynxman: I get the feeling that you were preparing the merge in an unusual way, considering how many undocumented ubuntu changes were left
[14:18] <pitti> barry: just committed to trunk, including setup.py changing the hashbangs of the installed scripts to sys.executable (i. e. python3 when you run setup.py with python3)
[14:18] <pitti> barry: I'll do an upstream release now and then convert the packaging branch
[14:18] <pitti> barry: but might need to wait for next week; need to start packging and then Taekwondo soon..
[14:19] <pitti> barry: is the twisted build dep a problem?
[14:20] <barry> pitti: not a huge problem since we have other twisted ubuntu-desktop dependencies, but reducing unneeded deps is always a win
[14:20] <lynxman> tumbleweed: I'm trying to keep track of too many sheeps at the same time I'm afraid, I'm working with the debian maintainer to reduce our delta as much as possible but we still got some stuff unmerged that some other packages depend on
[14:20] <barry> pitti: unless it really is a dep and i missed it
[14:20] <pitti> barry: it's only a build dep, not a binary one
[14:20] <pitti> just for the test suite
[14:20] <tumbleweed> lynxman: you now have entries in the changelog as "remaining ubuntu changes" when they aren't, they are changes that debian made that you had reverted in your earlier proposal
[14:21] <barry> pitti: how do you test w/py3 if twisted is a b-d?
[14:21] <lynxman> tumbleweed: gah, need to fix that as well
[14:21] <pitti> barry: I just need the twistd program
[14:22] <pitti> barry: I might do away with that even, but I think I added it because the exectuable needs to exist for the _check_interpreted() logic
[14:22] <tumbleweed> lynxman: I suggest comparing your branch against sid and checking that the changelog matches the diff
[14:22] <barry> pitti: what's odd id that i grepped all the files and couldn't find a reference to 'twisted'
[14:22] <pitti> barry: grep for "twistd" :)
[14:22] <lynxman> tumbleweed: will do that, thanks :)
[14:22] <barry> pitti: pesky 'e' ;)
[14:23] <pitti> barry: let me try without
[14:23] <s-fox> Ping micahg , nigelb said you might be someone to talk to about the default firefox bookmarks and getting them updated.
[14:30] <pitti> barry: so, I do need the twistd build dep for now, but it shoudl not be too hard to remove it; but it's not that urgent, I presume
[14:31] <barry> pitti: nope, not urgent.  thanks!  i'm going to respond to your email in more detail, but getting rid of lplib is *huge*
[14:31] <barry> (getting rid as a dep for task:ubuntu-desktop
[14:32] <vibhav> geser: You there?
[14:36] <geser> vibhav: yes, but only short, have to leave in a few
[14:37] <vibhav> geser: If you have any free time, could you check the merge (bug 1009412) ?
[14:37] <vibhav> I uploaded a revised debdiff
[14:39] <geser> will do when I'm home
[14:39] <vibhav> thanks!
[14:46]  * vibhav waits for a patch pilot
[14:49] <basti> mvo, geser told me in #ubuntu-de that you are an developer of apt-get. i cant update the sources anymore ( http://nopaste.info/f6616a4b02.html). both apt-get and aptitude dont work anymore. is there any fix?
[14:49] <smoser> @pilot-in
[14:49] <udevbot> Error: "pilot-in" is not a valid command.
[14:49] <smoser> @pilot in
[15:04] <mvo> geser: hi, for basti, I don't know what is going on there, it should not try to fetch the uncompressed file
[15:20] <smoser> vibhav, where you looking for a pilot?
[15:22] <pitti> barry: ooh, python3-pykde4? nice
[15:22]  * pitti installs and tries PYTHON=python3 test/run ui_kde
[15:22] <barry> pitti: yep, though i didn't do the port (cjwatson did i think)
[15:23] <cjwatson> I just packaged it
[15:23] <cjwatson> Upstream had already done it by the time I got there
[15:26]  * pitti scratches head about
[15:26] <pitti>     programName = ki18n('Apport KDE')
[15:26] <pitti> TypeError: ki18n(): argument 1 has unexpected type 'str'
[15:27] <cjwatson> It wants bytes
[15:27] <pitti> urgh, it needs to be called with bytes
[15:27] <cjwatson> cf. ubiquity r5463
[15:27] <cjwatson> There's kind of some logic to it, ish
[15:39] <vibhav> smoser: Yes I was
[15:40] <smoser> whats up?
[15:41] <vibhav> smoser: Could you take a look at https://bugs.launchpad.net/ubuntu/+source/zerofree/+bug/1009412  ?
[15:42] <jamespage> vibhav, do you think you could verify bug 1000678?
[15:42] <smoser> sure, vibhav i'll take a look. thank you.
[15:43] <jamespage> (I don't like checking my own work and its blocking the other SRU for munin its grouped with)
[15:44] <pitti> barry: yay, got apport-kde working with py3 now, too \o/
[15:44] <barry> pitti: rock!
[15:48] <micahg> s-fox: pong, not right now, in a rush, can we chat tomorrow?
[15:49] <s-fox> micahg,  sure thanks for the pong. what sort of time works for you?
[15:49] <micahg> s-fox: not sure right now (18:00 UTC should be ok)
[15:49] <s-fox> Okay, cool :)
[15:50] <s-fox> Speak to you tomorrow micahg
[15:57] <smoser> vibhav, before i dig further you want to reply to bhavi's comments?
[16:05] <vibhav> smoser: I took the diff's from zerofree 1.0.1-2ubuntu1 (quantal) and zerofree 1.0.1-4 (sid)
[16:05] <smoser> yeah, is saw comment. looking now.
[16:05] <vibhav> Also, The changlog entry is less that 80 lines
[16:13] <geser> mvo: are there any debug options which might help to find out why apt does it? I've a few users in the german support channel with this problem in the last weeks, or is the german mirror to blame?
[16:15] <vibhav> smoser: how does the #2 debdiff look?
[16:16] <smoser> vibhav, looking. sorry.
[16:36] <vibhav> smoser: How does it look?
[16:36] <smoser> vibhav, i'm sorry, still poking at other things... sorry for slow
[16:42] <vibhav> ah fine
[16:44] <smoser> vibhav, do you know if debian/patches/01_fix-as-needed-linking.diff is still relevant?
[16:44] <smoser> unfortunately, theres basically no context onto why you want to move the -lext2fs
[16:45] <geser> smoser: the context is "ld --as-needed"
[16:45] <smoser> i assumed something like that.
[16:45] <smoser> seems like we should at least forward that to upztream.
[16:45] <smoser> (and to debian)
[16:46] <smoser> so we dont have this delta for that.
[16:46] <vibhav> looks fine to me
[16:46] <geser> this depends on how friendly the DD towards Ubuntu is, as this an Ubuntu-only "problem" as Debian doesn't use --as-needed by default
[16:47] <infinity> It's technically correct, regardless of how one calls their linker
[16:47] <infinity> It just accidentally works without --as-needed.
[16:48] <mvo> geser: yes (sorry, long meeting) -o Debug::acquire::http=true
[16:56] <maxb> *blink*
[16:56] <maxb> *wtf*
[16:56] <maxb> lp:~ubuntu-core-dev/ubuntu/hardy/apport/hardy contains a packaging of hal, not apport
[17:00] <vibhav> smoser: So, Is it worth forwarding to debian?
[17:03] <infinity> vibhav: Yes.
[17:03] <infinity> vibhav: We forward as-needed patches to Debian all the time.
[17:04] <smoser> vibhav, its worth forwarding to debian.
[17:04] <vibhav> fine
[17:04] <vibhav> Ill do it later
[17:04] <vibhav> (Since I have to sleep)
[17:05] <smoser> and its worth forwarding to zerofree upstream (if that is not debian)
[17:05] <smoser> vibhav, i'll go ahead and upload, but please then fill in the debian bug as reference.
[17:06] <adam_g> anyone know the cause of this bzr error? i seem to be able to branch fine from another machine: http://paste.ubuntu.com/1027173/
[17:08] <smoser> adam_g, i just hit the same thing.
[17:08] <adam_g> hmmph
[17:08] <maxb> adam_g, smoser: It's a bug in following stacked branches properly
[17:08] <adam_g> saw it for the first time yesterday, with the same branch
[17:08] <adam_g> ah
[17:08] <smoser> when i moved my ~/.bazaar out of the way, it seemed to work.
[17:08] <maxb> It's only being triggered from the thing which checks whether the branches are up to date, so one option is to turn that off
[17:09] <maxb> launchpad.packaging_verbosity = off in your bazaar.conf
[17:10] <smoser> maxb, is there a bug?
[17:10] <maxb> I think there's a bug about the underlying stacking sillyness somewhere
[17:10] <maxb> I don't know if there's one specifically about it affecting the uptodateness checker
[17:15] <smoser> vibhav, interestingly, upstream (assuming http://intgat.tigress.co.uk/rmy/uml/index.html is upstream) does not even have a makefile in their source tree (git clone http://intgat.tigress.co.uk/rmy/git/zerofree.git)
[17:32] <smoser> ivoks, ok. so i'm good to upload bug 887946, but it needs SRU information.
[17:32] <smoser> could you add taht?
[18:15] <ahasenack> hi, can someone from the ubuntu-sponsors team please take a look at my quantal upload? #1004678 thanks!
[18:38] <infinity> cjwatson: So, uhm.  This API version of remove-package isn't particularly performant with a monstrous set of arguments, is it?
[18:38]  * infinity wonders if he should have done this in a for loop instead.
[18:41] <slangasek> infinity: I believe that was mentioned in the release notes ;)
[18:41] <slangasek> (which may have been a one-off comment on #ubuntu-release, fwiw)
[18:43] <infinity> slangasek: Oh, I remember him mentioning it.  I didn't expect a kernel removal to still be grinding after several minutes, that's all. ;)
[18:43]  * infinity waits longer.
[18:43] <infinity> Kinda curious if it'll time out at some point, or actually complete.
[18:44] <maxb> The misguided inventiveness of users knows no bounds :-(.  /me unsubscribes the package import robot from a random dpkg postinst failure bug
[18:49] <infinity> slangasek: Heh.  12 minutes, and counting.
[18:49] <infinity> slangasek: See, I think I misread his "poor performance" note slightly.
[18:52] <slangasek> :)
[19:21] <smoser> smb, around?
[19:31] <smoser> anyone want to give me a reason not to upload the debdiff at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/415353/comments/50
[19:31] <smoser> ?
[19:32] <infinity> smoser: Is that code in precise?
[19:33] <infinity> smoser: If so, I'd say it's fairly well-tested, and seems a sane SRU candidate for lucid.
[19:33] <smoser> infinity, yes. the 'hidden_dep_add_modules' is in precise.
[19:33] <smoser> the failure case to me would seem to be inclusion of crc32c module in an initramfs when it wasn't needed.
[19:34] <infinity> smoser: Which, given the size of our initrds, isn't world-ending.
[19:34] <smoser> well, another 6240 bytes !
[19:34] <infinity> Oh noes.
[19:34] <smoser> (uncompressed)
[19:35] <smoser> ok. well, i'm gonna upload then.
[19:37] <slangasek> bdmurray: bug #511463> do you think we should close this as resolved, then?
[19:58] <ahasenack> hi, can someone from the ubuntu-sponsors team please take a look at my quantal upload? #1004678 thanks!
[19:58] <hyperair> bug #1004678
[19:58] <hyperair> it helps to add the "bug" for a clickable link
[19:59] <hyperair> hmm landscape-client's in main, so i can't sponsor it
[20:01] <ahasenack> hyperair: :(
[20:01] <hyperair> well sit and wait patiently =)
[20:01] <hyperair> someone will come
[20:01] <smoser> anyone ever seen this:
[20:02] <smoser>  http://paste.ubuntu.com/1027436/
[20:02] <smoser> thats a fresh ubuntu instance in ec2. i install pastebinit, and it decides it should re-create my initramfs
[20:02] <stgraber> ahasenack: having a look at it now, please not that it'll be uploaded to quantal-proposed as it's a seeded package and we're currently in freeze
[20:03] <ahasenack> stgraber: when is the freeze lifted?
[20:03] <stgraber> ahasenack: likely at some point tomorrow
[20:04] <ahasenack> stgraber: what happens then if the package is in proposed? Do I need to ping someone to move it to main?
[20:04] <stgraber> ahasenack: -proposed will be pocket copied to the release pocket, nothing you have to do
[20:05] <ahasenack> stgraber: ah, ok
[20:05] <ahasenack> stgraber: so are you taking a look at it now?
[20:05] <stgraber> ahasenack: yep, test building here before uploading
[20:05] <ahasenack> stgraber: thanks a lot
[20:07] <stgraber> ahasenack: right, builds fine and doesn't seem to be pulling any universe package in the process, so should be fine.
[20:07] <ahasenack> stgraber: thanks
[20:08] <stgraber> ahasenack: I see you've done a good job at cleaning up any lintian warning for the source, but not for the binaries: http://paste.ubuntu.com/1027450/
[20:08] <stgraber> ahasenack: nothing critical in there but certainly a list of nice to fix for the next few releases :)
[20:09] <ahasenack> stgraber: that's a nice output
[20:09] <stgraber> ahasenack: that's "lintian -iI *.dsc *.deb" after a binary build
[20:09] <ahasenack> stgraber: how did you get it? I only get the single line output for each warning
[20:09] <ahasenack> stgraber: thank, I will address those in the next upload indeed
[20:09] <ahasenack> stgraber: is the procedure of adding an override + comment ok, if that's the case?
[20:10] <ahasenack> stgraber: i.e., if I think the warning doesn't apply
[20:10] <stgraber> ahasenack: yes, if the warning doesn't apply, overriding it + commenting is the right thing to do
[20:10] <ahasenack> stgraber: ok, thanks for the review
[20:10] <stgraber> uploaded
[20:13] <Qasaur> hey guys
[20:15] <smoser> @pilot out
[20:17] <Daviey> ahasenack: ah, sorry - didn't realise you had a new candidate
[20:19] <bdmurray> slangasek: I'm double checking regarding 511463 but will close it out if I find no duplicates
[20:24] <ahasenack> Daviey: np :)
[20:25] <ahasenack> stgraber: I filed bug #1009707 to check/address those lintian warnings
[20:26] <ahasenack> weird, it exists
[20:26] <ahasenack> oh, private
[20:26]  * ahasenack fixes
[20:26] <ahasenack> bug #1009707
[20:26] <ahasenack> ok
[20:26] <stgraber> ahasenack: cool, thanks!
[20:35] <slangasek> bdmurray: great, thanks :)
[21:48] <tumbleweed> barry: given up on launchpadlib?
[21:49] <barry> tumbleweed: it has defeated me.... for now
[21:49] <tumbleweed> :)
[21:49] <barry> (really more its dep stack)
[21:49] <tumbleweed> yeah, there is quite a bit of that
[21:50] <tumbleweed> and they all use doc-tests which isn't that py3k-porting friendly
[21:56] <barry> tumbleweed: that's not even the hardest part (but yeah, the repr of bytes can be a pain).  the thing that defeated me was 1) huge test deps that were unported; 2) deps made different choices about bytes v strings so the higher up libraries (like lazr.restfulclient) couldn't win because either choice caused crashes in some different lower lib
[21:56] <lifeless> it doesn't help that python core has gone slightly insane
[21:57] <lifeless> claiming various headers are strings, when they are defined by a wire encoding, and folk care about performance
[21:57] <barry> lifeless: in this case, i think it's more that lazr.* needs a holistic approach
[21:57] <lifeless> if python itself wasn't so dog slow, it wouldn't be an issue :)
[21:57] <lifeless> barry: sure, but some of the rot goes all the way down to python3 mime/httplib
[21:57] <barry> ah well
[21:57] <YokoZar1> RAOF: ping
[21:58] <lifeless> barry: I have great sympathy for the issue; I posted to python-dev about various bits a few times
[21:58] <barry> lifeless: yep.  i have hope that rdm is finally untangling the email/mime ball of yarn
[21:58] <RAOF> YokoZar1: Pong.
[21:58] <barry> lifeless: so maybe by 3.4 :)
[21:59] <lifeless> barry: maybe :)
[21:59] <barry> lifeless: well, even 3.3 perhaps if he gets email6 landed in time
[21:59] <YokoZar1> RAOF: DEBIAN_FRONTEND=noninteractive; sudo apt-get -y dist-upgrade     isn't working for me :/
[22:00] <RAOF> YokoZar1: sudo su; DEBIAN_FRONTEND=noninteractive sudo apt-get -y dist-upgrade?
[22:01] <lifeless> barry: I keep getting tempted to just write something bottom up that is lean, no compat, but horribly usable.
[22:01] <lifeless> barry: then I wake up screaming.
[22:01] <tumbleweed> :)
[22:01] <RAOF> YokoZar1: You could also dpkg-reconfigure debconf; that'll guarantee that sudo doesn't strip out the environment variable ;)
[22:01] <YokoZar1> RAOF: DEBIAN_FRONTEND=noninteractive; sudo echo $DEBIAN_FRONTEND   outputs noninteractive though
[22:02] <Daviey> hang on
[22:02] <RAOF> Is your shell replacing $DEBIAN_FRONTEND before spawning the command? (I believe so)
[22:03] <Daviey> YokoZar1: before updating grub2.. please run DEBIAN_FRONTEND=noninteractive dpkg-reconfigure grub-pc
[22:03] <YokoZar1> ahh maybe it will work in the script and not in the shell then
[22:03] <Daviey> then dist-upgrade
[22:07] <cjwatson> YokoZar1: you want sudo DEBIAN_FRONTEND=noninteractive dpkg-reconfigure grub-pc
[22:12] <Daviey> YokoZar1: Please can you confirm ?
[22:12] <cjwatson> infinity: Yeah, it has to get a lot of BPPHs.  Some optimisation should be possible though; in particular being able to pass more than one status to Archive.getPublishedBinaries would make a big difference.
[22:13] <cjwatson> And maybe some cleverer searching in general.
[22:16] <infinity> cjwatson: It took 51m52.453s to remove two out-of-date kernels.  I was impressed.
[22:18] <infinity> cjwatson: Given that that's arguably the most frequent use of remove-package, it'll be entertaining. ;)
[22:25] <cjwatson> infinity: Pretty sure it wasn't anything like that bad for me.  It's probably somewhat RTT-sensitive ...
[22:25] <cjwatson> infinity: But yeah, worth improving.
[22:30] <YokoZar1> Daviey: cjwatson's reconfiguration works as noninteractive, which makes a subsequent sudo DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade work, however if I just do the latter command it doesn't work
[22:33] <Daviey> YokoZar1: Maybe i'm tired and missing it, but cjwatson and myself said the same thing?
[22:35] <Daviey> YokoZar1: fresh instance pre grub update, sudo DEBIAN_FRONTEND=noninteractive dpkg-reconfigure grub-pc ; sudo apt-get -y dist-upgrade ... Note, NO DEBIAN_FRONTEND=noninteractive on the upgrade.
[22:37] <YokoZar1> Daviey: what I'm saying is the dpkg-reconfigure on grub-pc is necessary
[22:38] <YokoZar1> I can't just do it on the dist-upgrade step
[22:39] <slangasek> there's no reason I can conceive of for that
[22:39] <slangasek> DEBIAN_FRONTEND=noninteractive means "do not show me any debconf prompts"; and the ucf prompt is a debconf prompt
[22:39] <YokoZar1> let me just recheck that I'm doing this properly then
[22:39] <YokoZar1> (spinning up new instances)
[22:41] <YokoZar1> Ahh I seemed to have slipped in two sudos there
[22:41] <Daviey> cheeky.
[22:41] <YokoZar1> ie sudo DEBIAN_FRONTEND=noninteractive sudo  ==> fail
[22:45] <YokoZar1> so yeah it works as expected, thanks
[22:47] <Daviey> YokoZar1: ok, thanks.  We will make it so the latest AMI's are fixed, but the ones currently out in the field will have this issue, until something smarter comes along.
[22:49] <YokoZar1> Daviey: Yeah that sounds reasonable.  The root cause might be bug 759545, which would be a good target to get in before the point release
[22:50] <Daviey> YokoZar1: Nope, that isn't the issue.
[22:51] <YokoZar1> Daviey: ahh right, cause our grub is modified
[22:51] <Daviey> For the entire Precise cycle, the issue was being tracked as that bug - but it's not that issue.  Which caused confusion, causing it not to be resolved.
[22:51] <Daviey> However, 12.04.1 will include a resolution regardless.. but the daily images will also start showing the resolution even sooner.