[05:10] <pitti> Good morning
[08:01] <dholbach> good morning
[08:10] <didrocks> dholbach: good morning!
[08:10] <dholbach> salut didrocks
[08:10] <didrocks> how are you?
[08:10] <dholbach> good good - how about you?
[08:10] <didrocks> dholbach: I'm fine, thanks!
[08:11] <didrocks> dholbach: FYI, I just opened https://wiki.ubuntu.com/MeetingLogs/devweek1201/AutomatedUXTestingWithQt and I'm seeing that the css quote rectangle is cutting the speech :)
[08:11] <dholbach> I know
[08:11] <dholbach> it's a but
[08:11] <dholbach> bug
[08:11] <dholbach> https://bugs.launchpad.net/ubuntu-website/+bug/812337
[08:11] <dholbach> afaik sladen is on it
[08:12] <dholbach> maybe it needs newz2000 to deploy it?
[08:12] <dholbach> I just pinged both of them
[08:12] <didrocks> dholbach: thanks! :)
[08:40]  * apw notes he has _10_ updates which considering we are in freeze ... is unexpected
[11:51] <MacSlow> pitti, can you resubmit your wnck_shutdown-branch for notify-osd to be merged-proposed for lp:notify-osd/precise?!
[11:52] <MacSlow> pitti, that would make more sense because of the libwnck3-requirement, which is only met by precise
[11:52] <MacSlow> thanks in advance
[12:19] <pitti> MacSlow: why wouldn't it also go to trunk?
[12:19] <pitti> MacSlow: it's not a requirement, it's a conditional feature
[12:20] <pitti> MacSlow: it shoudl certainly also go to precise, but usually via trunk and a new release?
[12:20] <pitti> MacSlow: also, the precise package already has that patch
[12:26] <seb128> pitti, not sure but notify-osd has a weird series handling, tarballs have been rolled from ubuntu series and not trunk for quite some time
[12:26] <seb128> like it was the same in oneiric
[12:26] <seb128> seems trunk is not used
[12:29] <pitti> ok, re-doing the branch and MP
[12:30] <pitti> MacSlow: ok, done: https://code.launchpad.net/~pitti/notify-osd/wnck_shutdown-precise/+merge/91255
[12:31] <pitti> MacSlow: NB that nobody is not subscribed to that project; DX was subscribed to lp:notify-osd
[12:31] <pitti> argh, ignore this, it's broken
[12:32] <pitti> bzr lp-propose picked the wrong target
[12:33] <pitti> MacSlow: https://code.launchpad.net/~pitti/notify-osd/wnck_shutdown-precise/+merge/91257 it is
[12:33] <pitti> hmm
[12:34] <pitti> I did specify lp:notify-osd/precise, but now the MP is again against lp:notify-osd
[12:34] <pitti> WTH?
[12:34] <seb128> pitti, just edit the target on lp
[12:34] <pitti> https://code.launchpad.net/~pitti/notify-osd/wnck_shutdown-precise/+merge/91258
[12:34] <pitti> third time
[12:34] <pitti> it keeps setting it to lp:notify-osd
[12:34] <pitti> I suppose the two are aliases
[12:35] <pitti> and lp:notify-osd/precise _is_ the new trunk
[12:35]  * MacSlow scratches head
[12:35] <pitti> MacSlow: so, it should be good
[12:35] <pitti> MacSlow: my original MP merges just fine, too
[12:35] <MacSlow> sure... locally it works fine with both
[12:35] <pitti> MacSlow: oh, I understand
[12:35] <pitti> MacSlow: the old MP shows /oneiric now
[12:35] <pitti> it seems you switched trunk from /oneiric to /precise since I created the original MP
[12:35] <MacSlow> pitti, all good nos
[12:36] <MacSlow> now
[12:36] <MacSlow> pitti, yeah
[12:36] <pitti> please don't do that
[12:36] <pitti> MacSlow: anyway, https://code.launchpad.net/~pitti/notify-osd/wnck_shutdown-precise/+merge/91258 is good
[14:03] <pitti> jdstrand: hm, I just saw you earned bug 673925 from kees/
[14:03] <pitti> ?
[14:04] <pitti> jdstrand: it had already been MIR reviewed in the past, but 0.8 didn't validate SSL; 1.0 is supposed to
[14:08] <seb128> micahg, jdstrand: hey, just being curious but is there any bug or similar tracking the firefox 10 update for oneiric, eta, what is blocking it etc? some users seem eager to get it and keep asking I'm not sure where to point them ;-)
[14:11] <roaksoax> clear
[14:19] <jdstrand> pitti: yes. it is actually on my list of things to look at today
[14:19] <pitti> jdstrand: nice, thanks
[14:19] <KaM^PreT> ad orng ngga?
[14:21] <pitti> nuQneH?
[14:21] <jdstrand> seb128: looks like bug #
[14:21] <jdstrand> bug #923319
[14:22] <jdstrand> seb128: this is in the ubuntu-mozilla-security ppa
[14:22] <seb128> jdstrand, not a lot of content there ;-) seems the update are technically ready I was wondering if somebody blocks updates
[14:22] <seb128> uploads
[14:22] <jdstrand> seb128: I don't know the timeframe other than I know micahg is testing them and istr him saying something about next week
[14:23] <jdstrand> seb128: actually, he might have said this week. micahg, what is your time frame for ff 10? :)
[14:23] <seb128> jdstrand, ok, some users are making us some bad press because we are slow to update, over a week in a 6 weeks cycle seems a lot ;-)
[14:23] <seb128> jdstrand, I was trying to figure what to response
[14:24] <jdstrand> seb128: we block on them to test each release on i386 and amd64
[14:24] <seb128> jdstrand, thanks
[14:24] <seb128> jdstrand, well 10 is frozen and in the ppa for weeks, we should have got testing by now? official version is there since sunday it seems ... do we need extra testers? i.e should we do a call for help somewhere?
[14:25] <jdstrand> I know he has been actively working on that this week. I don't know when he will pull the trigger. if not today, then early next week (we avoid friday releases except in emergencies)
[14:25] <seb128> jdstrand, ok thanks
[14:25] <jdstrand> seb128: I doubt the older releases have gotten a lot of testing outside of chrisccoulson and micahg
[14:25] <seb128> jdstrand, it's maybe something we should look at fixing ;-)
[14:26] <seb128> getting testing earlier
[14:26] <jdstrand> seb128: the call for help was for 9. 9 to 10 shouldn't be a big deal
[14:26] <seb128> ok
[14:27] <jdstrand> seb128: yes. the lonstanding goal is for micahg to have these tested and ready by release day. then we wait 24 hours for upstream to find things, then we release if no show stoppers
[14:27] <seb128> jdstrand, sound great, I'm looking forward getting there ;-)
[14:27] <jdstrand> seb128: that got pushed back a bit with all the firefox 9 transition in lucid and maverick. now that everything is on one release, it should be easier for micahg to achieve that
[14:27] <seb128> jdstrand, excellent, thanks a lot of the details!
[14:28] <jdstrand> you're welcome :)
[14:29] <cyphermox> cking: I'm curious about your blog post about the 3G dongle
[14:29] <cyphermox> cking: 12d1:1446 already has a definition in usb-modeswitch-data at least in precise, so that definition would be wrong if your device didn't switch on connect?
[14:30] <cking> cyphermox, well, I bodged it because it wasn't working - I need to figure out why it wasn't working by default, it may be an upgrade issue
[14:30] <cyphermox> cking: sounds to me like maybe the definition file isn't right for some devices despite having the same usb ID
[14:30] <cyphermox> (e.g. there are some firmware impacts on how they respond to the switch message)
[14:31] <cking> cyphermox, I did see the following:
[14:31] <cking> usb_modeswitch_[326]: segfault at 8 ip 00007f7ca17f0541 sp 00007fffce9ff578 error 4 in libc-2.13.so[7f7ca176a000+197000]
[14:31] <cyphermox> ok
[14:31] <cyphermox> then that is probably entirely my fault, and I'll need to fix this
[14:32] <cking> hence I forced it with my own config file. do you need any more info to help resolve this bug?
[14:32] <cyphermox> I don't think so
[14:34] <cking> cyphermox, i was just pleased to get some form of connectivity via 3G yesterday - if you want me to test any fixes I'm happy to try them out
[14:37] <cyphermox> cking: sure
[14:51] <nigelb> seb128: Hey! Can you join the classroom channels? The bot's complaining you aren't in there yet :)
[14:51] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 (last day) starting in 8 minutes in #ubuntu-classroom
[14:52] <seb128> nigelb, done
[14:52] <nigelb> seb128: Thanks! :)
[14:53] <dholbach> seb128, mhall119, tumbleweed, jbicha, kirkland, warp10, ready? :)
[14:54] <seb128> dholbach, no :p
[14:56] <pitti> cjwatson: hm, the new sru-release method doesn't seem to auto-close the referenced bugs any more
[14:56] <jbicha> dholbach: good morning
[14:56] <pitti> cjwatson: ah nevermind, it just takes a minute or two
[14:57] <cjwatson> yep, see "asynchronous" :)
[14:59] <mhall119> dholbach: /me is always ready
[15:01] <dholbach> :)
[15:08] <kirkland> dholbach: more or less :-)
[15:08] <kirkland> sladen: https://answers.launchpad.net/byobu/+question/185066
[15:09] <kirkland> sladen: I'm getting that question fairly frequently now
[15:10] <sforshee> bryce, RAOF: is precise to power off the unused gpu in hybrid graphics systems by default?
[15:26] <dendrobates> mvo: hey I'm having a precise upgrade issue:  The package 'unity-scope-calculator' is marked for removal but it is in the removal blacklist
[15:26] <dendrobates> mvo: can you offer any pointers?
[15:28] <stgraber> hmm, it should indeed be removed (doesn't work with new Unity API and as it's a post-release extra app, it doesn't exist in Precise), these shouldn't get removal blacklisted
[15:31] <cjwatson> it's because unity is there and the regex search isn't anchored
[15:31] <cjwatson> or rather is only anchored at the start
[15:32] <DoctorPepper>  is anyone  of  the ubuntu kde team in here ?
[15:32] <cjwatson> dendrobates: fixed for next update-manager upload, thanks
[15:32] <dendrobates> cjwatson: np, thanks
[15:33] <mvo> dendrobates: woah, cjwatson was quicker
[15:33] <mvo> thanks cjwatson - I guess the regexp was too broad
[15:33] <cjwatson> -unity
[15:33] <cjwatson> +unity$
[15:33] <Riddell> DoctorPepper: yes
[15:33] <cjwatson> considered doing the same for unity-2d but it doesn't seem to have a similar breadth of addons
[15:33] <cjwatson> I mean not in that namespace
[15:34] <soren> cjwatson: So this change was in update-manager?
[15:34] <cjwatson> soren: yes
[15:34] <soren> cjwatson: And now you've uploaded the change?
[15:34] <cjwatson> soren: no
[15:34] <soren> How does it land in the upgrade tool?
[15:34] <soren> Oh, ok.
[15:34] <cjwatson> it'll be there from the next upload
[15:34] <soren> Is the generation of the upgrade tool part of the update-manager build process?
[15:34] <cjwatson> yes
[15:34] <cjwatson> it gets stuffed into LP as a custom upload
[15:34] <soren> Ah :)
[15:35] <cjwatson> basically a tarball of the DistUpgrade/ directory
[15:35] <DoctorPepper> ridell: i need some help i am running kde  4.8 on 10.10  from ppa  and  i am having some wierd  issue with  python based  plasmoid not working
[15:35] <soren> Ok. Is there a temporary workaround we can do locally?
[15:36] <cjwatson> not sure
[15:36] <soren> Yeah, it seems we'd have to be really quick.
[15:36] <Riddell> DoctorPepper: this is not a support channel I'm afraid
[15:36] <soren> Perhaps ctrl-z the update-manager process right after it downloads and unpacks it.
[15:36] <DoctorPepper> it  seens  that nobody is able to help me on the kubuntu
[15:36] <soren> ..fix the regex, and start it again.
[15:36]  * soren tries that
[15:36] <cjwatson> I was going to upload update-manager after the freeze ends today if mvo doesn't mind
[15:37] <cjwatson> having to work around the main.log thing I fixed is annoying :)
[15:37] <DoctorPepper> Riddell: it seems to me  that i am hitting a bug
[15:37] <Riddell> DoctorPepper: your options are the kde and plasma developer channel and the kubuntu channels.  but python on plasma is not a much used solution so you can't expect a quick answer on irc
[15:37] <mvo> soren: you could simply run "bzr branch lp:update-manager; cd update-manager/DistUpgrade; sudo ./dist-upgrade.py"
[15:38] <mvo> cjwatson: I don't mind at all, but I'm happy to do it too, there is one branch from jibel waiting for review that I would like to get done at some point, but its not urgent, both is fine
[15:38] <cjwatson> oh that's a handy trick
[15:38] <cjwatson> mvo: ok, cool, if you're going to anyway that's obviously fine by me ;-)
[15:40] <soren> mvo: Ah, yes.Neat. Thanks.
[16:08] <barry> jodh: your done symbol for our next meeting: http://www.fileformat.info/info/unicode/char/1f4a9/index.htm
[16:08] <jodh> barry: watcha tryin to say? ;)
[16:09] <barry> no commentary implied :)
[16:10] <barry> cjwatson: is this an up-to-date sync blacklist?  http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
[16:10] <cjwatson> barry: yes
[16:10] <barry> thx
[16:10] <jodh> barry: seems somewhat discriminatory - its comment is "dog dirt".
[16:11] <barry> i've seen that term used on my neighborhood listserv.  as in: "hey you freakin' neighbors, clean up your dog dirt!
[16:13] <ion> As opposed to dog poop?
[16:15] <barry> yeah, which is funny because of the things they *do* say when the flamewars erupt over indoor or outdoor cats
[16:26] <slangasek> Barzogh: pretty sure the bug is still open asking for that character to be supported in the fonts ;)
[16:26] <slangasek> hmm
[16:27] <slangasek> Barzogh: sorry, mistab :)
[16:36] <bryce> sforshee, theoretically yes
[16:39] <sforshee> bryce, what does that mean exactly? Should that support already be in place? Because I have a system with hybrid graphics, and the discrete card is not being powered off
[16:47] <barry> james_w: think we should get pkgme into precise?
[16:49] <JanC> for those of you who come to FOSDEM: https://wiki.ubuntu.com/Fosdem/2012 (I will further update the wiki later today & tomorrow, but feel free to add yourself, your talks and/or your ideas!)
[16:54] <smoser> slangasek, ping.
[16:55] <smoser> maybe you have some thoughts on this log https://jenkins.qa.ubuntu.com/view/Precise/job/precise-server-ec2/ARCH=i386,REGION=us-west-2,STORAGE=instance-store,TEST=cloud-config,label=ubuntu-server-ec2-testing/lastBuild/artifact/None/i386/m1.small/instance-store/i-e688ccd6/uec2-20120202-1453-d28473559d2145-terminated.console.txt
[16:55] <smoser>  Serious errors were found while checking the disk drive for /opt.
[16:55] <smoser>  Press I to ignore, S to skip mounting, or M for manual recovery
[17:02] <slangasek> smoser: what's the fstab look like?
[17:03] <smoser> slangasek, hold on.
[17:04] <micahg> seb128: jdstrand: the goal is to release Firefox 10 today, we decided to wait ~48 hours since there have been numerous chemspills lately, this time, it doesn't look as likely
[17:04] <smoser> slangasek, http://paste.ubuntu.com/826611/
[17:04] <jdstrand> micahg: ah, great! :)
[17:05] <smoser> slangasek, this is https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/898373
[17:06] <seb128> micahg, hey, great, thanks
[17:09] <slangasek> smoser: oh; well, that bug needs to be fixed then surely?
[17:09] <smoser> slangasek, :) surely it does
[17:09] <smoser> its rare
[17:09] <smoser> but...
[17:09] <smoser> so there is definitely a bug there (the 'busy')
[17:09] <slangasek> well, there are no shortcuts, if that's what you're asking. :)  We're not going to change mountall to stop doing what it's doing
[17:09] <smoser> but in EC2, there is no local console.
[17:10] <smoser> so prompting the user for fsck (and haning the system indefinitely?) is just pointless.
[17:11] <smoser> is there a way that i can configure it to say "if osmething other than / needs fsck, come up anyway"
[17:12] <slangasek> no
[17:12] <slangasek> you can mark the disk "noauto" or "nobootwait" in /etc/fstab, that's it
[17:13] <slangasek> otherwise, the filesystem is marked as a required part of the boot, and if the fsck fails it's not ready to be mounted
[17:14] <smoser> hm..
[17:14] <slangasek> I don't have a good way to deal with the prompt itself, since we need plymouth to capture boot-time output and if plymouth is present mountall thinks it's ok to prompt
[17:14] <smoser> well i dont like the nobootwait solution, as unless its dirty, i do want to wait.
[17:15] <slangasek> but even if we solved the prompt, mountall's fallback policy is to launch a root shell and let you fix it, which is also the correct policy but doesn't help you either
[17:16] <smoser> how hard, i wonder, would it be for it to launch ssh daemon ?
[17:16] <smoser> what would be nice is:
[17:17] <smoser>  "Uhoh, you're hosed. I've started an ssh daemon at IP:22. ssh here as root and you'll be dumped into a screen session where you can handle it"
[17:20] <slangasek> smoser: sure, either fixing /etc/init/mountall-shell.conf to support this, or diverting it in a cloud-specific job, seems reasonable there
[17:22] <smoser> slangasek, ok.
[17:22] <smoser> so the bug there still remains thoguh.
[17:22] <smoser> the device busy
[17:22] <smoser> i'll leave that bug open, and would greatly appreciate foundations help on it (and i can facilitate)
[17:22] <smoser> and i'll open up another bug specifically saying dirty filesystems make cloud-instances cry
[17:31] <tomreyn> hi, i'm on ubuntu 11.10 (oneiric), with oneiric-proposed and xorg-edgers repositories activated, and having trouble running any virtual machines since the driver modules are not loaded, and may not have been built by dkms automatically. i'm trying to find out why this is so I can make a proper bug report against ubuntu, but am having trouble finding the root cause, can someone guide me through?
[17:37] <SpamapS> smoser: hey, when is the last time you tried uncloud-init with the cloud images?
[17:37] <SpamapS> smoser: I tried it last night and things did not go well. :-/
[17:38] <smoser> not supported.
[17:38] <SpamapS> It was a cool idea. :)
[17:38] <smoser> what were you wanting to do ?
[17:38] <smoser> its better done now.
[17:38] <SpamapS> smoser: I ended up just converting the cloud image to raw, mounting it, and chrooting in to change the password and purge cloud-init
[17:38] <smoser> but you have to use a cdrom
[17:39] <smoser> but you can essentially boot the image in kvm with whatever user-data you'd like. (and your data would just do that)
[17:39] <smoser> you dont have to purge cloud-init (although you can)
[17:41] <SpamapS> smoser: perhaps we should update this https://help.ubuntu.com/community/UEC/Images
[17:41] <smoser> SpamapS, or maybe you could just read it ;)
[17:41] <smoser> https://help.ubuntu.com/community/UEC/Images#Ubuntu_Cloud_Guest_images_on_Local_Hypervisor_Natty_onward
[17:43] <SpamapS> smoser: I did read it... but I didn't feel like figuring out how to generate the appropriate user-data..  :-P
[17:43] <SpamapS> smoser: I just wanted to use it to get a quick KVM vm up
[17:43] <smoser> if you copied and pasted those lines it would have worked.
[17:43] <SpamapS> what would have worked? It would have somehow grabbed my ssh key and put it in the user-data ?
[17:43] <smoser> but feel free to update however you'd like to make it more clear.
[17:43] <SpamapS> Oh you're saying the passw0rd is embedded?
[17:44] <smoser> Then, log in with 'ubuntu' and password 'passw0rd'.
[17:44] <SpamapS> my laziness won the day then.. ;)
[17:44] <smoser> the file 'user-data' that is referred to by 'make-iso' changes the password
[17:45] <smoser> fwiw, in doing some other work, i was wanitng ot have a script that does all this for you
[17:45] <smoser> that can take an image as input and basically run it in the image for you via chroot or kvm boot.
[17:45] <smoser> and would use the ovf stuff behind the sceneds
[17:46] <SpamapS> smoser: yeah that would be cool
[17:47] <smoser> SpamapS, but seriously, feel free to make that page more readable.
[17:48] <smoser> or even just write "DO NOT USE UNCLOUD-INIT"
[17:51] <SpamapS> smoser: it sounded like such a simpler option ;)
[17:52] <smoser> i agree.
[17:53] <smoser> except for it can't be automated.
[17:53] <smoser> so i dont see a lot of value in maintaining it.
[18:11] <cnd> what's the real benefit of using bzr merge-update with a packaging branch that includes the upstream sources?
[18:11] <cnd> vs just having a packaging branch with the debian directory?
[18:13] <jtaylor> its much easier to mess with the orig source
[18:17] <cnd> jtaylor, what do you mean by that?
[18:18] <slangasek> cnd: using it as a real DVCS, where you have access to the full upstream source directly and can diff directly against the upstream?
[18:19] <cnd> slangasek, yes, in theory that sounds nice
[18:19] <cnd> but it makes bootstrapping the packaging branch more difficult
[18:19] <slangasek> does it?
[18:19] <cnd> it makes updating cumbersome (bzr mu with 8 options)
[18:19] <cnd> and I have yet to feel like it has helped in reality
[18:20] <cnd> the packaging branch bootstrapping involves tagging it in special ways, IIRC
[18:20] <cnd> it's been a while since I've done it, but we are making a new package right now
[18:20] <slangasek> cnd: http://web.dodds.net/~vorlon/wiki/blog/bzr-git_case_study/
[18:22] <slangasek> cnd: for me, one of the benefits is never having to root around looking for the right upstream tarball on the mirror
[18:22] <cnd> slangasek, isn't that what uscan is for?
[18:22] <slangasek> no
[18:23]  * cnd is confused...
[18:23] <slangasek> I'm talking about the orig.tar.gz for a version that's already in the archive
[18:23] <cnd> oh
[18:23] <cnd> uscan --download-current-version?
[18:23] <slangasek> which isn't always a bit-for-bit match for what upstream distributes
[18:23] <slangasek> again, no :)
[18:23] <cnd> well yeah, hopefully they're the same
[18:24] <slangasek> and sometimes it isn't, and it's good to have a workflow that's built on something more tangible than hope :)
[18:25] <cnd> heh
[18:25] <cnd> slangasek, is that the only place where it helps though?
[18:25] <cnd> if you need to add a patch to the sources
[18:26] <slangasek> I am astonished that you think this is a negligible case :)
[18:26] <cnd> I probably don't have as much experience in this area since I mostly package our own development work
[18:26] <cnd> we make new releases if there are bugs
[18:26] <cjwatson> I find it extremely beneficial to be able to bzr log/blame/etc. all in a single tree
[18:26] <cnd> so there usually isn't patches
[18:27] <cnd> ok
[18:27] <cnd> mostly I wanted to double check that it was important for some people to have a packaging branch maintained this way
[18:27] <cnd> since it is a bit harder for us to get started with
[18:28] <cnd> but if it helps, then we'll continue to do it that way
[18:28]  * cjwatson bangs head against lucid->precise dpkg/lzma upgrade tangles, and considers the pub instead
[18:28] <slangasek> cnd: well, the only time I think it's worth the effort of doing by hand is if you're branching from an upstream VCS as described at the link I pasted
[18:29] <slangasek> otherwise, you might as well just use the UDD branches, and let the importer do it for you
[18:29] <cnd> ok
[18:37] <cjwatson> slangasek: there you go
[18:38] <slangasek> cjwatson: thanks
[18:58] <BenC> Am I correct that powerpc and arm buildd's run the builds as root?
[19:01] <BenC> Actually, I'm guessing just the powerpc buildd is that way
[19:12] <micahg> infinity or lamont ^^
[19:14] <infinity> BenC: No.
[19:14] <infinity> BenC: dpkg-buildpackage -rfakeroot as an unprivileged user.
[19:41] <kirkland> jcastro: hey, they're having trouble over in ubuntu-classroom, getting voice
[19:41] <jcastro> k
[20:22] <micahg> lool: do you mind if I merge ca-certificates?
[20:23] <36DAARLF3> does anyone encounter this bug with google-chrome?: http://imgur.com/vu5am
[20:32] <coalwater> 36DAARLF3: is it with chrome only ?
[20:39] <jsmith-argotec> I am looking to make/submit a patch for a bug in bind9 - but that's about where my knowledge ends... anyone that might lend me some assistance?
[20:48] <coalwater> jsmith-argotec: u mean in launchpad?
[20:51] <jsmith-argotec> coalwater: umm idk, not sure exactly how to create a patch properly - tried once before but it was ugly...
[20:51] <jsmith-argotec> coalwater: and someone I spoke to about it recommended coming here or motu and getting help/sponsor
[20:52] <jsmith-argotec> coalwater: that package was part of universe therefore motu (haven't gotten to that yet)
[20:53] <micahg> jsmith-argotec: do you like bzr?
[20:53] <jsmith-argotec> micahg: not real familiar with it yet, seems ok
[20:54] <micahg> jsmith-argotec: well, I can point you to documentation on how to make a patch with bzr or without
[20:55] <jsmith-argotec> micahg: ahh well I am not partial to either way since it's fairly new territory for me so point to the better option
[20:56] <jsmith-argotec> micahg: I'm not sure if it should be submitted upstream too or if that makes a difference in which way it's made
[20:56] <micahg> jsmith-argotec: http://developer.ubuntu.com/packaging/html/fixing-a-bug.html
[20:58] <micahg> nah, both ways you should end with with a patch against the upstream code
[20:58] <jsmith-argotec> micahg: that looks easy enough. One more question - is it poor etiquette to submit a pactch that is just applying a fix someone posted in the bug report?
[20:58] <jsmith-argotec> micahg: from what I've read around it sounded like submitting a patch would help get it merged at all/quicker
[20:58] <micahg> jsmith-argotec: a debdiff, not at all, just give attribution where appropriate
[21:00] <jsmith-argotec> micahg: perfect!
[21:01] <jsmith-argotec> micahg: a couple more questions... is it only usefull if submitted against the latest distribution or ok if it's still a bug in the latest
[21:02] <jsmith-argotec> micahg: I'm only running Lucid not latest...
[21:02] <micahg> jsmith-argotec: umm, well, bugs need to be fixed in the dev release before they can be SRUd (https://wiki.ubuntu.com/StableReleaseUpdates)
[21:03] <jsmith-argotec> micahg: I'm not as concerned (though nice) if it's SRUd more so that it is fixed for the next LTS
[21:03] <micahg> jsmith-argotec: ah, ok, then just for precise is fine
[21:06] <jsmith-argotec> micahg: lastly - I've verified the bug exists in squeeze also. Should I submit a patch there too/instead?
[21:07] <micahg> jsmith-argotec: well, squeeze is the stable release, it would probably have to go through unstable, you can use the submittodebian tool from ubuntu-dev-tools to send the bug to Debian once you have the Ubuntu package
[21:08] <micahg> you can mention there if you're willing to make a patch for squeeze if it'll be accepted
[21:09] <jsmith-argotec> micahg: ok once I get through the Ubuntu process I'll look into that. Thanks for the help!
[21:09] <micahg> thank you for contributing to Ubuntu
[21:14] <slangasek> smoser: so what else is in the image that could account for /dev/xvda2 being busy?  Could you grab dmesg output from such a failed boot?
[21:15] <smoser> slangasek, i could, yeeah, but you think there would be something there that is not on that console ?
[21:15] <smoser> thats all the kernel messages.
[21:15] <slangasek> well, there could be
[21:15] <smoser> i can have somethign that runs dmesg on boot to a file, and then start a reboot loop later.
[21:15] <slangasek> I really have no idea what else might be holding that device open
[21:15] <slangasek> besides a kernel issue
[21:39] <36DAARLF3> coalwater, yes chrome only
[21:47] <coalwater> well i asked because it seemed similar to a bug about nvidia video driver thing, but it does that with all windows, and it sometimes gets fixed after resizing the window
[21:47] <coalwater> 36DAARLF3: ^
[21:48] <36DAARLF3> coalwater, any more info on that bug?
[21:50] <coalwater> i dont know, i could search for it, but it wasn't on my computer so i didn't look into it that much, let me check
[21:50] <36DAARLF3> thx
[21:51] <coalwater> 36DAARLF3: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/752445 i think this is it
[21:52] <36DAARLF3> thx
[22:59] <YokoZar> I'm guessing the archive admins were busy with alpha 2 and didn't have time for packages in New queue for the past few days yes?
[23:24] <SpamapS> YokoZar: they're not allowed to approve NEW stuff during the freeze
[23:24] <YokoZar> SpamapS: Even universe stuff?
[23:25] <SpamapS> YokoZar: I believe universe gets a freeze as well, as there are things in universe that end up on some CDs (just not the main Ubuntu cds)
[23:25] <SpamapS> but that sounds crazy when I read it back to myself
[23:26] <SpamapS> so disregard
[23:26]  * SpamapS goes back to trying to get a kvm vm to pxe boot
[23:26] <Laney> it is probably just for time reasons
[23:26] <slangasek> actually, it's generally fine to do new processing during a freeze
[23:26] <slangasek> because milestones are *also* supposed to have a consistent archive :)
[23:30] <RAOF> You need a MIR to promote a new binary package from a source package in main, right?
[23:30] <slangasek> RAOF: nope
[23:30] <RAOF> Excellent.
[23:32] <slangasek> hallyn: qemu-linaro 2012.01 ftbfs on 32-bit archs due to a problem in hw/qxl.c, which seems to be spice-specific... but neither the failing code nor the spice package has changed since the last upload.  Any ideas?
[23:42] <soren> slangasek: toolchain changes?
[23:49] <hallyn> slangasek: no idea...  if it also fails in a sbuild i'll try to reproduce tonight/tomorrow
[23:52] <soren> hallyn, slangasek: the spice package has been updated in the mean time, too. (On 2011-12-19, while the old qemu-linaro was bulit on 2011-12-15)
[23:53] <soren> Oh.
[23:53] <soren> Just found this:
[23:53] <soren> /«PKGBUILDDIR»/hw/qxl.c:1021:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
[23:54] <soren> I get that if I build the older qemu with a fresh tool chain.
[23:54] <soren> ...that's an error in the newer qemu.