[05:52] <jose> jono: hey, are the times you mentioned UK or UTC?
[05:52] <jose> if they're UK, they need to change with DSTs
[05:53] <jono> jose, as I mentioned earlier, UK times
[05:53] <jose> ok
[05:53] <jono> but agreed we should make them UTC :-)
[05:53] <jono> so lets use those times but UTC as they are the same right now
[05:53] <jono> thanks!
[05:53] <jose> sure
[05:53] <jose> also
[05:53] <jono> thanks, man
[05:54] <jose> oh, nvm, got it sorted
[05:54] <jose> thanks to you!
[05:56] <jono> :-)
[05:56] <jono> thanks, jose!
[05:56] <jono> would like to catch up with you next about a few things
[05:56] <jono> 1. LoCo Council and 2. Ubuntu On Air and future ideas
[05:57] <jose> sure, we can do that, just that it can't be done at vUDS as school is in the middle
[05:57] <jose> are you free at 4:30pm your time tomorrow?
[05:59] <jose> jono: ^
[05:59] <jono> jose, I can't tomorrow, have meetings out of the office
[06:00] <jono> jose, and I am out on Fri too
[06:00] <jono> can we do Mon next week?
[06:00] <jose> jono: at what time?
[06:01] <jono> jose, 3pm Pac next week?
[06:01] <jose> jono: should be good, 3pm pacific on Monday then
[06:01] <jono> cool :-)
[06:02] <jose> so it's 1am here and bed is calling, talk to you on Monday!
[14:36] <benvantende> heyla guys, i just noticed the coc is now one document instead of two (leadership). what is the reason for the change. i did not dive into it. maybe someone can give a summary
[14:44] <AlanBell> benvantende: http://fridge.ubuntu.com/2012/11/19/coc-version-2-0-has-been-released/
[16:08] <jcastro> marcoceppi, nest time ... go
[16:09] <jcastro> 22 this month for me, 243 this year
[16:15] <marcoceppi> haven't gotten my report yet jcastro
[16:40] <AlanBell> jose: can you fridge this please https://lists.ubuntu.com/archives/ubuntu-irc/2013-November/001623.html
[19:57] <bkerensa> nigelb: First interview done :) at Lizard Land :D
[20:28] <jcastro> hey jono
[20:28] <jcastro> http://metalinjection.s3.amazonaws.com/wp-content/uploads/2013/08/James-Hetfield-hair-evolution.jpg
[20:29] <jono> hey jcastro
[20:29] <jono> LOL
[20:29] <jono> jcastro, hey, you check out http://www.badvoltage.org/2013/11/07/1x02/ yet?
[20:29] <jcastro> no
[20:30] <jono> slacker
[20:30] <jcastro> I found myself accidentally in charge of a computer society in ann arbor and had to go run a meeting
[20:30] <jono> well, if slacking is working and not slacking off listening to podcasts
[20:30] <jono> lol
[20:30] <jcastro> so I have been short on time this week
[20:30] <jono> ahh yeah
[20:30] <jono> FINE.
[20:30] <jcastro> oh it came out today
[20:30] <jono> :-)
[20:30] <jono> yup new ep
[20:31] <jcastro> hmmm what's the latest podcast app people are using?
[20:33] <jono> jcastro, my podcasting app is a web browser
[20:33] <jono> I download and listen
[20:33] <jono> lol
[20:33] <jcastro> weaksauce
[20:33] <jono> we need a good podcasting touch app
[20:36] <jcastro> jono, It's ricardo salveti's birthday
[20:36] <jcastro> since he likes metal I made a meme for G+
[20:36] <jono> jcastro, oh damn
[20:36] <jcastro> make one with like slayer or something
[20:36] <jcastro> http://memegenerator.net/Ridiculously-Photogenic-Metalhead
[20:36] <jcastro> could also work
[20:39] <jcastro> http://i.imgur.com/0a8xLHQ.jpg
[20:39] <jcastro> too soon?
[20:58] <popey> jono: catchpodder https://launchpad.net/catchpodder
[20:59] <jono> popey, cool
[20:59] <jono> popey, have you tried it?
[21:02] <popey> yes
[21:02] <popey> it needs re-packaging as a click
[21:02] <popey> i have used it as a deb before we went read-only
[21:45] <mhall119> jono: http://developer.ubuntu.com/apps/html-5/api/
[21:45] <mhall119> the can use some additional CSS, but they're published
[21:46] <jono> mhall119, awesome!
[21:46] <jono> looking great :-)
[21:46] <jono> so next stop is Cordova docs, I presume?
[21:46] <mhall119> daker gets all the credit
[21:46] <mhall119> jono: yes
[21:46] <jono> nice!
[21:46] <jono> thanks, daker!
[21:47] <daker> we are still looking for some issues with Kyle
[21:47] <daker> jono: yw
[22:23] <jono> mhall119, can you fix the copyright on the API site in the footer to match the one on the main d.u.c site?
[22:29] <mhall119> not quickly, no, but I can work on it tomorrow
[22:30] <mhall119> since they used different base themes, I'll have to adapt the mark to the django website theme
[22:30] <mhall119> I also need to adapt the global-nav
[22:31] <mhall119> and I just today filed an RT to get he sub-nav and side-nav back in sync
[22:31]  * mhall119 really wishes there was a better way to do this
[22:42] <daker> mhall119: check http://pad.ubuntu.com/YMNWSdreBY
[22:49] <jono> thanks, mhall119, not urgent
[22:50] <jono> just the text needs changing, not a consistent theme
[23:00] <mhall119> daker: hope my comments help
[23:03] <daker> mhall119: see the chatbox on the pad
[23:06] <mhall119> thanks daker
[23:06] <daker> mhall119: yw


[04:08] <theblazehen> maaz tell smallpox wouldn't encrypting the db not help, as the db will need to be mounted if the db is running, which it will be if it's owned?
[04:08] <Maaz> theblazehen: Got it, I'll tell smallpox on freenode
[06:17] <superfly> theblazehen: this is true. Also, security is a multi layered thing, and the more layers you implement, the more secure your data is.
[06:17] <Symmetria> sup
[06:17] <Symmetria> :)
[06:17] <theblazehen> superfly: Exactly
[06:18] <Symmetria> http://server.alstonnetworks.net/photos/IMG_0184.JPG <[06:19] <theblazehen> Symmetria: reddit.com/r/serverporn reddit.com/r/cableporn
[06:21] <Symmetria> lol
[06:21] <Symmetria> http://server.alstonnetworks.net/photos/IMG_0196.JPG <[06:21] <Symmetria> ;p
[06:21] <Symmetria> lol did that to protect the fiber optics
[06:21] <theblazehen> Yeah
[06:21] <Symmetria> even if the cabling is a mess
[06:22] <Symmetria> heh those really thin white fibers are what connect me to the net
[06:22] <Symmetria> 2 x 10G :)
[06:22] <theblazehen> You don't want to see mine at home. 5 multi plugs..
[06:22] <theblazehen> Nice
[06:22] <theblazehen> All running off a single outlet...
[06:23] <Symmetria> heh I got a 32 amp breaker for my office
[06:23] <theblazehen> Nice, 16A here
[06:23] <theblazehen> You running linux on there?
[06:24] <theblazehen> Ah, 2 PCs. Running 5 displays (was 6) off a single pc
[12:11] <superfly> Hey gremble
[12:12] <gremble> Hey superfly
[12:12] <gremble> How are you today?
[12:12] <theblazehen> Hi gremble, superfly
[12:13] <gremble> Hey theblazehen
[12:13] <superfly> Hi theblazehen
[12:13] <superfly> gremble: tired
[12:14] <superfly> And no Internet at home because my line is stuffed and Telkom needs to lay replacement cable
[12:15] <gremble> Having to deal with statal and parastatal organisations make my bones ache
[12:22] <gremble> I need some consumer advice. My sister is going to uni next year and we need to get her a laptop. Can either of you recommend a nice midrange laptop? I can budget up to 20k
[12:27] <theblazehen> gremble: How much would you count as midrange?
[12:28] <theblazehen> http://www.wootware.co.za/dell-latitude-3550-intel-core-i5-5200u-2-2ghz-8gb-2x-4gb-1600mhz-ddr3l-1tb-5400rpm-hdd-nvida-gt-830m-15-6-full-hd-1920x1080-anti-glare-led-windows-7-professional-64bit-notebook.html Is decent, and has Intel wifi, meaning that the drivers work quite well
[12:28] <gremble> I would assume top end laptops are corporate and gaming beasts and those are like 27k+ so I would assume that anything between 10 and 20 is midrange
[12:28] <gremble> I don't trust R4000 laptops. :x
[12:29] <theblazehen> yeah, same here
[12:29] <theblazehen> http://www.wootware.co.za/dell-nbdeca004l3550emea-latitude-3550-intel-core-i5-5200u-2-2ghz-4gb-1600mhz-ddr3l-500gb-7200rpm-hdd-15-6-hd-1366x768-anti-glare-wled-backlit-windows-7-pro-notebook.html This has intel graphics (Great drivers!) Maybe get an SSD, and another 4 GB RAM?
[12:30] <theblazehen> Also has intel wifi
[12:31] <theblazehen> I'd go for the 1st one, has a full HD screen and closed source nvidia drivers work well too. 8GB ram is a plus
[12:31] <theblazehen> With 8 GB RAM there isn't much need for an ssd really
[12:32] <gremble> The first one does look very nice. She'll appreciate the fact that she'll be able to game a little bit on it
[12:32] <theblazehen> Wait, I'm guessing she runs windows.. In that case I'd still go for the first, but there are no driver troubles, and yeah that is nice as well
[12:33] <theblazehen> I currently game on my Intel HD4600 overclocked to 1.4 GHz, while it drives 5 displays.. It's *okay*
[12:33] <theblazehen> Plays fallout 3 at low
[12:33] <gremble> Yes. I haven't been able to convert her successfully :P
[12:33] <gremble> She still wants to play league of legends with her boyfriend
[12:33] <theblazehen> Using wine-staging and CSMT, perhaps 50 fps. So the intel chips aren't too bad really
[12:34] <theblazehen> Yeah, wine won't work for that
[12:38] <gremble> Thanks theblazehen. I also forgot about wootware, but I remember you told me about them already :P I made sure to bookmark the site this time
[12:38] <theblazehen> Cool :) yeah, great deals there
[12:39] <gremble> Now all I have to do is remember everything that I did in my software architecture class
[12:39] <theblazehen> hah, have fun with that!
[12:44] <gremble> Did you know that you can get a certification for doing UML?
[12:45] <theblazehen> Nope, TIL
[12:46] <gremble> I didn't know it was something that needed more than a pamphlet to teach. There are some things that you have to remeber, but it is like getting a certificate for knowing how to draw one of those "breinkaarte" from grade 5
[12:46] <theblazehen> yeah
[12:46] <gremble> http://www.omg.org/ocup-2/ :P
[12:47] <theblazehen> Awesome
[12:47] <gremble> That is why I like mathematics. It doesn't ask of me to become certified in graph theory, it just lets me do wild things to graphs
[12:48] <theblazehen> To be fair, you don't need to be certified in linux stuff either
[12:48] <gremble> You do
[12:48] <gremble> LPI certs
[12:48] <gremble> Novell certs
[12:48] <gremble> Networking certs
[12:49] <theblazehen> Well, to do it for a living, sure
[12:49] <gremble> I considered doing something in that domain, but I have a bursary for a degree, not really one for certifications
[12:49] <theblazehen> yeah
[13:18] <gremble> http://www.yegor256.com/2014/12/01/orm-offensive-anti-pattern.html This guy is incredibly angry about ORM
[13:53] <Kilos> hmm...
[13:54] <theblazehen> Hi Kilos, what's up?
[13:54] <Kilos> afternoon superfly Cryterion gremble theblazehen and of course inetpro
[13:54] <Kilos> temperature mailny
[13:54] <Kilos> mainly
[13:55] <theblazehen> lol, true
[13:55] <Kilos> hows you theblazehen
[13:55] <theblazehen> I'm doing alright and you?
[13:55] <Kilos> good ty
[15:33] <superfly> Kilos: ai
[15:33] <Kilos> what superfly
[15:34] <Kilos> you left out the ! after ai!
[15:34] <superfly> You never came to the airport
[15:36] <Kilos> aw sorry sir
[15:36] <Kilos> welcome home
[15:36] <Kilos> you forgot to tell me when you arriving
[15:36] <Kilos> hehe
[16:26] <superfly> Kilos: got back yesterday
[16:26] <superfly> I logged into IRC while at the airport, but no one was around
[16:26] <Kilos> aw sorry
[18:23] <captine> evening all
[18:24] <captine> loooong time
[18:25] <theblazehen> hey captine!
[18:25] <gremble> Hey captine
[18:27] <captine> anyone else running 15.10 gnome edition?
[19:57] <Kilos> night all.sleep tight
[19:57] <Kilos> wb cap
[19:58] <Kilos> ai!


[08:19] <RikMills> tjaalton: did you manage to have any luck with mesa bisection?
[11:57] <tjaalton> RikMills: not yet.. will continue next tuesday after easter
[12:01] <RikMills> tjaalton: thank you. have a good eater weekend :)
[12:01] <RikMills> *easter
[12:01] <RikMills> though eater may also be valid ;)
[12:02]  * RikMills eyes an easter egg
[12:07] <tjaalton> yeah, just had lunch and already have to plan the dinner ;)
[12:08] <tjaalton> one thing you could try in the meantime is to install a snapshot mesa from a ppa like oibaf, and see if the bug is fixed
[15:29] <toffo> anyone using DLang and possibly trying to get it to compile to/on aarch64? I've only found casual references, i.e<EMAIL_ADDRESS>and my Visual Studio Code dlang stuff won't compile on Ubuntu 20.10 on RPi4B. (Visual Studio Code itself runs without problems on the aarch64 though)
[16:55] <bdmurray> vorlon: I uploaded privoxy and now the autopkgtest passes every where except armhf. Do you know what gives? https://launchpadlibrarian.net/531332297/privoxy_3.0.32-1_3.0.32-1ubuntu1.diff.gz<EMAIL_ADDRESS>[22:06] <sarnold> vorlon: hello :) focal's irssi 1.2.2-1ubuntu1.1 doesn't appear to have any ddebs generated for it -- there's nothing 1ubuntu1.1 on https://launchpad.net/ubuntu/focal/+package/irssi-dbgsym -- and there's nothing 1ubuntu1.1 on http://ddebs.ubuntu.com/pool/main/i/irssi/ -- any chance they're stashed anywhere else?
[22:25] <cjwatson> sarnold: May be vaguely related to https://bugs.launchpad.net/ddeb-retriever/+bug/1921940, which is on my list to investigate as soon as I get a spare minute
[22:27] <cjwatson> sarnold: https://launchpad.net/ubuntu/+source/irssi/1.2.2-1ubuntu1.1/+build/19780424 has them for amd64 though, or follow similar links under Builds on https://launchpad.net/ubuntu/+source/irssi/1.2.2-1ubuntu1.1 for other architectures
[22:27] <sarnold> cjwatson: woot! thanks :)
[22:27] <sarnold> cjwatson: sigh, I don't know how I missed them here. thanks


[02:08] <Bluefoxicy> is it possible to get apt to authenticate via certificate?
[02:09] <Bluefoxicy> http://lists.debian.org/debian-user/2011/06/msg02273.html never mind, apparently it is.
[02:36] <Bluefoxicy> oops it looks like Pulp can do that :)
[02:37] <Bluefoxicy> just needs a DEB/APT plug-in.
[06:28] <pitti> Good morning
[07:41] <dholbach> good morning
[07:47] <pitti> hey dholbach
[07:47] <dholbach> hey pitti
[07:51] <mitya57> hi dholbach & pitti
[12:28] <mlankhorst> cjwatson: doesn't look like I can drop more space than the shared libgallium thing :(
[12:30] <ogra_> does anyone know if there is something similar to udev-acl for sysfs files ?
[12:33] <ogra_> i could just use an upstart job to "chgrp users" but wonder if there isnt a more elegant way
[12:33] <xnox> well udev runs as root, and it can haz RUN stanza......
[12:35] <ogra_> but it only acts on devices, not sure there are matching devs at all
[12:37] <ogra_> (i'll check, running chgrp from udev isnt much diferent to upstart though)
[12:38] <cjwatson> mlankhorst: OK, well, it's a start anyway; thanks
[12:44]  * cjwatson is somewhat tempted to drop sl-modem-daemon from 12.04.2 images.  It costs 5MB on amd64 due to dragging in libc6-i386 ...
[13:42] <mlankhorst> cjwatson: should I re-upload the mesa (unrenamed) sru to put in a build fix against the new libdrm, and remove the references in the sru to libdrm-dev renamed?
[13:43] <cjwatson> Don't remove any existing changelog entries, please
[13:43] <cjwatson> But feel free to reupload with the shared libgallium fix
[13:43] <mlankhorst> I mean the unrenamed one, mesa 8.0.4
[13:44] <mlankhorst> the renamed mesa-lts-quantal is currently building https://launchpad.net/~mlankhorst/+archive/ppa/+packages
[13:44] <mlankhorst> I want to test it first
[13:45] <cjwatson> So what's the problem - mesa in precise-proposed fails to build against libdrm in precise-proposed?
[13:45] <mlankhorst> yes :)
[13:45] <cjwatson> I don't get what you mean by removing references in the SRU, since bug 1098215 doesn't mention libdrm
[13:47] <mlankhorst> well to be able to work right libdrm-dev-renamed had to be added to the list of packages that could satisfy the libdrm-dev dependency, else things would still break in some circumstances, but now that libdrm is no longer renamed, it could be dropped. But it should be harmless to keep the references to the renamed versions of libdrm-dev
[13:47] <cjwatson> Oh, right
[13:48] <cjwatson> I don't really mind which you do
[13:48] <mlankhorst> I think I'll commit the fix to our git repository only for now then, next sru could pick it up
[14:19] <tjaalton> why isn't armhf an "official" port in archive.u.c, but instead uses ports.u.c?
[14:20] <micahg> tjaalton: see https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures , it's been this way for a while
[14:21] <tjaalton> micahg: doesn't answer the question though :)
[14:21] <micahg> I would think so the world doesn't have to mirror less used archs
[14:22] <tjaalton> that's just a matter of doing proper mirroring
[14:22] <tjaalton> I'm not mirroring i386..
[14:22] <micahg> yes, but most mirrors are
[14:23] <micahg> (at least the public ones)
[14:23] <xnox> tjaalton: e.g. we'd rather mirrors mirror everything, instead of dropping out because there is too much data there.
[14:23] <xnox> same story is why lpia was on ports.
[14:24] <xnox> I guess one day i386 will move to ports & armhf/aarm64 might move into archive.
[14:24] <tjaalton> right
[14:38] <cjwatson> tjaalton: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Ports
[14:38] <cjwatson> armhf gets massively fewer downloads than i386
[14:38] <tjaalton> cjwatson: yeah, understood
[14:39] <cjwatson> Note https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Official_Architectures - armhf is still official even though it's on ports
[14:39] <Brogrammin> Morning guys. Python programmer looking to get involved with Ubuntu, any opportunities with Python?
[14:46] <brendand> Brogrammin, python is everywhere in ubuntu
[15:12] <mlankhorst> well the renamed mesa ran glxgears with shared libgallium so it can't be that broken for i915/nouveau, I'll test on radeon too to be sure
[15:19] <mlankhorst> ok radeon works too, uploaded..
[15:32] <hallyn> infinity: hey - the CVE patch you pushed to raring qemu...  does that actually do anything?  it seems to only add a check for 'size > 16384' when it already is triggering on 'size > 1522' ?
[15:34] <cjwatson> Most i386/amd64 Ubuntu (i.e. not PPA) builders going down soon for a hardware move, lasting about 30 minutes
[15:36] <Laney> hallyn: Hey ;-) Don't suppose you know anything about this: https://ubuntuone.com/27Vn82hay9zqxyL3O98V1k do you?
[15:39] <hallyn> Laney: hm.  brings up https://bugzilla.redhat.com/show_bug.cgi?id=885464
[15:40] <stgraber> @pilot in
[15:40] <Laney> hallyn: Indeed I found that but the responses aren't so helpful
[15:41] <stgraber> hallyn: ah yeah, I've got quite a few problems with qemu/kvm with libvirt yesterday. It was complaining quite a bit about the hda-duplex stuff, also about the usb2 devices and then about CPU flags and types.
[15:41] <stgraber> hallyn: as I needed it working, I simply wiped all matching entries from the libvirt xml file and it worked, but it wasn't a smooth upgrade ;)
[15:42] <hallyn> I don't see anything in upstream changelog...
[15:43] <hallyn> Laney: stgraber: does it by any chance help if you set cpu type to -cpu kvm64 ?
[15:43] <stgraber> hallyn: not really, I had to switch to kvm64 + remove all the list of flags that libvirt had stored in the xml file
[15:44] <stgraber> hallyn: I think I have a copy of the xml I can paste somewhere, hold on
[15:44] <Laney> Cannot find suitable CPU model for given data
[15:45] <hallyn> stgraber: Laney: a hacky workaround for now could be to use spice :)  that would use the old qemu-kvm-spice binary whic his still based on the old source tree.
[15:46] <stgraber> hallyn: http://paste.ubuntu.com/1555743/
[15:46] <hallyn> i'm not sure yet what the long term solution will be.  debian group is talking about a kvm wrapper to emulate the old behavior...
[15:47] <Laney> hmm if I change the audio device model to something else (leaving cpu type alone) I get permission denied errors
[15:48] <stgraber> so yeah, libvirt worked again after I removed all those "<feature>" tags, switched to kvm64, dropped all the "ich9-uhci*" entries and all the sound cards
[15:51] <hallyn> stgraber: that was a windwos vm, or ubuntu?  can you paste the /var/log/libvirt/qemu/<vm>.log ?
[15:51] <hallyn> It's possible the sound cards just erred because of the sound options being re-ordered (alsa first, pa at the end)
[15:52] <stgraber> hallyn: I first had the problem with a win8 VM yesterday, but the one I pasted above is an Ubuntu one
[15:53] <stgraber> hallyn: http://paste.ubuntu.com/1555758/
[15:54] <hallyn> stgraber:  so then what if you *only* switch out the cpu definition for -cpu kvm64 ?
[15:57] <stgraber> hallyn: hmm, it starts ;) which is vaguely surprising as that's what I tried to do with virt-manager yesteday but didn't work... anyway, I'll just blame virt-manager for now ;)
[15:57] <hallyn> stgraber: and does it give you sound?
[15:58] <stgraber> hallyn: ah, that VM doesn't appear to have a soundcard, might explain why just changing the CPU did the trick
[16:41] <Laney> hallyn: /dev/kvm was root:root for me until I rebooted - it's now root:kvm
[16:41] <hallyn> Laney: stgraber: what i said before was wrong - qemu-kvm-spice was always built on (modified) qemu, not qemu-kvm source.
[16:41] <Laney> Changing sound ich6→ac97 gets it to boot
[16:42] <Laney> and I still can't select kvm64 "Cannot find suitable CPU model for given data"
[16:42] <hallyn> Laney: you're on raring right?  if it was root:root then at this point i dunno, udev is borked
[16:42] <Laney> well it's right after a reboot ...
[16:42] <hallyn> what is your rootfs?  (wondering if inotify is not working)
[16:42] <Laney> ext4
[16:43] <hallyn> Laney: it shouldn't need a reboot.  qemu-kvm postinst calls udevadm trigger to force it to reread the udev rules for /dev/kvm
[16:43] <hallyn> Laney: is anything in your /var/log/syslog or /var/log/udev to show why it failed?  (group kvm not existing, or someting)?
[16:43] <Laney> should it be root:root if qemu isn't installed?
[16:44] <stgraber> hallyn: bah, I really used the wrong VM for an example didn't I? ;)
[16:44] <hallyn> Laney: yes, that's how the default udev rules set it up
[16:44] <stgraber> hallyn: let me switch to standard kvm and give you the other errors then :)
[16:44] <Laney> alright, so it's like that on my laptop now
[16:44] <Laney> let me apt-get install qemu and see what happens
[16:44] <stgraber> hallyn: right, now it fails to start even with kvm64, so similar to what I had with my other VM yesterday
[16:45] <Laney> yeah still root:root
[16:45] <Laney> Jan 21 16:44:56 iota udevd[357]: specified group 'kvm' unknown
[16:45] <hallyn> Laney: intersting, ich6 depends on hda-duplex.
[16:45] <hallyn> stgraber: is that due to ich6 audio?
[16:46] <stgraber> hallyn: nope, it's back to CPU problems
[16:46] <stgraber> hallyn: I don't have audio in that VM
[16:46] <stgraber> hallyn: I'm getting "error: internal error Cannot find suitable CPU model for given data" even with kvm64, probably because of the feature flags
[16:46] <hallyn> Laney: I wonder udev needs to be totally restarted, i.e. maybe it has cached a copy of /etc/group
[16:47] <hallyn> Laney: bc we very clearly, explicitly add group kvm long before we call udevadm trigger, in qemu-system.postinst
[16:47] <Laney> yeah I have the group now (didn't have it before)
[16:48] <hallyn> Laney: what do you mean by before?  before qemu was installed, right?
[16:48] <Laney> yes
[16:48] <Laney> so that part is as expected
[16:48] <Laney> sorry that we've ended up debugging three bugs at once
[16:52] <Laney> is it https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1092715 ?
[16:52] <hallyn> i don't understand, hda-duplex *should* be qemu...
[16:53] <hallyn> Laney: sort of, except that one describes symptoms due to several things
[16:53] <hallyn> Laney: one cause was the udev rule in qemu not explictly removing the group acl
[16:54] <hallyn> (which in debian gets set to group::rw-, and i think should in ubuntu as well - but i don't even know where that gets set)
[16:54] <hallyn> Laney: adam_g ran into the one where udev didn't see the new rule, some inotify failure
[16:54] <hallyn> Laney: and now you're seeing something i've occasionally seen, where udev for some idiotic reason doesn't yet know about group kvm
[16:55] <hallyn> i could add a sleep 2 to the qemu-system.postinst :)
[16:55] <hallyn> or 'while [ ! group-exists kvm ]; do : done
[16:56] <Laney> heh
[16:56] <Laney> so I touched 40-qemu-system.rules and then re-ran udevadm trigger and it's set it now
[16:57] <hallyn> stgraber: can you file a bug and attach the xml for the failing vm?
[16:57] <hallyn> stgraber: With luck we can have libvirt automatically do the appropriate update of xml contents...
[16:57] <stgraber> hallyn: yep, will do
[16:58] <hallyn> stgraber: thanks
[17:00] <Laney> what's responsible for displaying the bootdegraded prompt?
[17:00] <Laney> (changing the topic ...)
[17:02] <stgraber> hallyn: bug 1102487
[17:02] <stgraber> hallyn: sorry for the pretty short description but I have to run to a meeting
[17:02]  * Laney adds some info
[17:03] <hallyn> stgraber: thanks :)
[17:08] <jodh> on the topic of kvm, anyone else having major vm performance degradation after recent update?
[17:10]  * Laney gets far enough to find out
[17:11] <hallyn> jodh: make sure to add '-enable-kvm' to cmdline if you're running byhand
[17:11] <hallyn> (libvirt always does it for you)
[17:12] <jodh> hallyn: I get the following when modprobing kvm_intel (which used to work for me): 'kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround'
[17:12] <Laney> it's hard to tell
[17:14] <jodh> hallyn: thanks - that did it! Must be a behavioural change as kvm worked fine last week without that option.
[17:14] <hallyn> jodh: yes, it's due to the switch from qemu-kvm to qemu upstream source
[17:15] <hallyn> unfortunately that's the simplest change to fix, it seems :(
[17:15] <hallyn> s/fix/work around
[17:17] <jodh> hallyn: but hey, one down... ;)
[17:26] <hallyn> jodh: I'm afraid that one is going to weird out a lot of ppl.  I noted it in README.debian, but that really isn't very discoveraable imo
[17:27] <GuidoPallemans> where can I find all the GIcon icons?
[17:31] <infinity> hallyn: The patch is from upstream.  I agree that the initial || looks odd, but the rest makes sense.
[17:33] <hallyn> infinity: but it doesn't make any effective change...
[17:35] <cjwatson> amd64/i386 builders are back
[17:36] <infinity> hallyn: Did you follow the brackets?
[17:36] <cjwatson> ... or not
[17:38] <infinity> hallyn: if (size > BIG || (size > SMALL && register_set)) && other_register_set)
[17:38] <infinity> hallyn: The brackets are important.
[17:38] <jodh> hallyn: invocation now certainly has a tautological element to it :)
[17:40] <hallyn> infinity: ah, there it is :)  yes somehow i didn't see those.  i don't know how.  thanks
[17:40] <infinity> mlankhorst: Do we get that mesa/libdri linkage fix in Q and R as well, or just lts-quantal?
[17:41] <infinity> hallyn: I'm with you, I find nested brackets REALLY hard to track across line breaks.
[17:41] <infinity> hallyn: Which is why I copy and pasted it out and removed all the \n
[17:41] <hallyn> infinity: i was goign to blame the transparent terms.
[17:56] <mlankhorst> infinity: it's just for lts-quantal probably, which one do you mean?
[17:57] <hallyn> stgraber: Laney: good news, I see how I messed up the audio card list in packaging.
[17:57] <hallyn> I can't however reproduce problems with the cpu lists
[17:57] <hallyn> so let's see if when i uplaod a new version, maybe magically it'll fix it all
[17:57] <hallyn> (for me adding all those features to sandybridge cpu works fine)
[18:03] <Laney> nice, i'll try that tomorrow
[18:03] <infinity> mlankhorst: The libcricore static linkage thing.  It's just as much a bug in raring as it is in precise-lts-quantal, IMO.
[18:03] <Laney> night!
[18:03] <mlankhorst> infinity: yes but for raring we're moving to a new mesa, in which case we can do it in a much cleaner way
[18:04] <infinity> mlankhorst: Mmkay.
[18:04] <mlankhorst> there have been some patches on the mailing list, but with build system still in flux I've been holding it off
[18:06] <mlankhorst> as for quantal, well we could enable it if you want to, but size hasn't been as much as a concern with the cd requirement lifted, so we felt that it wasn't appropriate to enable close to release
[18:30] <infinity> mlankhorst: For Q, it would be more about keeping the Q and lts-Q packages in sync, since the latter is meant to just be a backport of the former.
[18:30] <mlankhorst> yeah I'm aware, but quantal didn't have the size considerations lts-q does
[18:31] <mlankhorst> so while I originally made the patch for q, being close to release time meant I didn't want to risk enabling it.
[18:34] <infinity> mlankhorst: Sure, but that was months ago, and this is now.  No release pending, just an SRU.
[18:34]  * infinity shrugs.
[18:34] <mlankhorst> I suppose if you really want one. :P
[18:35] <infinity> I'm not wildly picky, to be fair.  Will the next lts-backport stack in .3 also be Q, or will it be R by then?
[18:35] <mlankhorst> r
[18:35] <infinity> Okay, then if this is fixed properly in R, that's probably fine, if you'll never need to backport the Q mesa again.
[18:36] <mlankhorst> I can easily make it part of the scripts to uncomment it for quantal
[18:36] <infinity> (Of course, if the Q mesa has a CVE or other reason for SRU, it's way less effort in the future to apply fix to Q, backport with scripts to lts-q, done)
[18:37] <infinity> I guess what I'm driving at is that I see this as a real bug, not as a "we're pretending it's a bug due to ISO space constraints").
[18:39] <mlankhorst> the script could be made to do the same transformation
[18:40] <infinity> mlankhorst: Yes, but why?  The backport script shouldn't be fixing bugs, only mangling things needed to backport successfully.
[18:40] <infinity> mlankhorst: If there are bugs, they should be fixed in the source being backported, not the target backported to.
[18:41] <mlankhorst> we're already doing something like that for xorg-server, since lightdm passes -nc to the xserver, instead of -background none
[18:47] <infinity> mlankhorst: And is that a bug that should have been fixed in Q, or something that's P-specific?
[18:47] <mlankhorst> p specific
[18:48] <infinity> mlankhorst: Right, so script mangling that is fine.
[18:48] <infinity> mlankhorst: This is what I'm arguing for the mesa thing, it's not P-specific.
[18:49] <infinity> mlankhorst: We *noticed* it because of the P images being large and going hunting for the cause(s), but that doesn't make it any less a bug in Q/R.
[18:49] <infinity> Recklessly shipping tons of copies of something statically linked is always a bug (sure, not a hugely critical one, if it's all from the same source package, but still sloppy)
[18:50] <infinity> And while a single package maintainer can say "so what, it's only 10MB?", if every package had the same attitude, your installed system would be twice as big, or more. :P
[18:50] <infinity> Hence, bug.
[18:50] <mlankhorst> it's going to be fixed in raring
[18:50] <infinity> Check.
[19:03] <mlankhorst> infinity: http://lists.freedesktop.org/archives/mesa-dev/2012-August/026040.html
[19:07] <infinity> mlankhorst: So, in that latest mesa-lts-quantal build, the sizes of /usr/lib/<triplet>/dri/*.so are still huge compared to the P versions...
[19:07] <infinity> mlankhorst: Did your patch build things shared, but not actually link to the shared versions?
[19:08] <mlankhorst> it is actually smaller
[19:09] <infinity> -rw-r--r-- 1 root root 1284072 Mar 30  2012 r600_dri.so
[19:09] <infinity> -rw-r--r-- root/root   3405324 2013-01-21 18:16 ./usr/lib/i386-linux-gnu/dri/r600_dri.so
[19:09] <infinity> Old and new.
[19:09] <mlankhorst> but I mean smaller than it was before
[19:10] <mlankhorst> I'm unsure since the build system changed and I think the drivers started using llvm, is there any way to check what's causing the size?
[19:20] <stgraber> @pilot out
[19:25] <infinity> mlankhorst: Okay, yeah, you're right, the size did drop a little.  But it certainly isn't as much as I'd been hoping, given the previous size of these modules.
[19:28] <infinity> mlankhorst: Err, and the original complaint (linking statically against libdricore) is still there.
[19:28] <mlankhorst> oh ok, I'll try to see if I can get libdricore dynamic too, then
[19:29] <infinity> mlankhorst: http://paste.ubuntu.com/1556311/
[19:29] <mlankhorst> hmz indeed
[19:29] <mlankhorst> but there is no libdricore.a..
[19:30] <infinity> I'm sure there is during the build.
[19:30] <mlankhorst> nope :/
[19:34] <infinity> libtool: install: (cd /build/buildd/mesa-lts-quantal-9.0/build/dri/src/mesa/drivers/dri/i915; /bin/bash /build/buildd/mesa-lts-quantal-9.0/build/dri/libtool  --silent --tag CC --mode=relink gcc -DI915 -I../../../../../../../include -I../../../../../../../src/ -I../../../../../../../src/mapi -I../../../../../../../src/mesa/ -I../../../../../../../src/mesa/drivers/dri/common -I../../../../../../../src/mesa/drivers/dri/intel -I../../../../../../../src/
[19:35] <infinity> Gah.
[19:35] <infinity> LONG LINE IS LONG.
[19:35] <infinity> Sorry about that.
[19:36] <Laney> it got cut off anyway
[19:36] <infinity> mlankhorst: Anyhow, I bet you'll find that, at that point in the build, ../../../../../src/mesa/libdricore/libdricore9.0.0.la references a bunch of static objects instead of a shared linking script.
[19:36] <infinity> Laney: Phew.
[19:38] <infinity> mlankhorst: So, we go to all the trouble to build a proper shared library and then fail to use it, it would seem.
[19:40] <mlankhorst> it might appear to be so
[19:40] <roadmr> hey folks, what's the proper way to get bugs unlinked from an SRU? Deleting the link from the merge request? One of my SRUs failed one verification, I removed the code and resubmitted, but that bug still shows in the SRU queue
[19:42] <infinity> mlankhorst: And, indeed, the link lines on 8.0.x include an -ldricore (and an appropriate -L, I assume), which makes it all better.
[19:42] <infinity> roadmr: Hrm?  Which SRU?
[19:43] <mlankhorst> upstream fail :/
[19:43] <roadmr> infinity: checkbox 0.13.9, the fix for bug 990133 was bad so I removed it, yet it still shows in the pending-sru thing
[19:43] <mlankhorst> oh i guess not
[19:44] <infinity> roadmr: That's because you uploaded with -v
[19:44] <infinity> roadmr: This is one of those rare cases where you don't want to do that. :P
[19:45] <infinity> roadmr: But we can work around it, if all the other bugs verify fine.
[19:45] <mlankhorst> must have missed it during the rebase of that patch
[19:45] <roadmr> infinity: I didn't do the upload myself :( -v to which tool?
[19:45] <infinity> roadmr: Poke me when every other bug is (re)verified, and we'll make it go.
[19:46] <roadmr> infinity: thanks so much, I'll do that and get back to you (probably tomorrow, some of those bugs are a bit time-consuming to verify)
[19:46] <infinity> roadmr: Well, it's not just about who did the upload.  In this case, you would have had to drastically change the changelog.  I wouldn't worry about it, personally.  There are humans involved in this process for a reason.  We're generally smarter than the tools.
[19:46] <infinity> (Generally)
[19:47] <roadmr> infinity: heheh :) nice comment about humans. OK, I'll get a-verifying and trouble you for help once all verifiable bugs are done
[19:47] <infinity> roadmr: The SRU is only 2 days old, no huge rush.  Get back to me when it's all happy.
[19:48] <roadmr> will do, thanks :)
[21:18] <stgraber> cjwatson: and one more of my e-mails for you to let through ubuntu-devel-announce ;)
[21:19] <cjwatson> my kingdom for listadmin bash completion
[21:19] <cjwatson> done
[21:21] <stgraber> thanks :)
[21:28] <infinity> cjwatson: You could always share the u-d-a moderation burden.
[21:28] <cjwatson> 'cos it's so hard :)
[21:29] <cjwatson> I thought at least a couple of other people had them, but maybe they're all mostly-emeritus by now
[21:29] <slangasek> I suspect that's the case
[21:29] <infinity> cjwatson: You, mdz, and Keybuk.
[21:29] <slangasek> I think I have access to said queue, but receive no notifications :)
[21:29] <infinity> cjwatson: So, yeah.  Just you.
[21:29] <cjwatson> Do I smell two volunteers?
[21:30] <infinity> cjwatson: You could always give it the same password as ubuntu-archive@ and those of us who care could add ourselves to the admin notifications.
[21:30] <slangasek> I have no problem being added to the list of suckers
[21:30] <cjwatson> Meh, or I could just give you the current password
[21:30] <infinity> Or that.
[21:30] <infinity> But then I need to remember it.  Which is sooo haaard.
[21:31] <Laney> you need to teach it to listadmin ;-)
[23:51] <roaksoax> soren: howdy! yeah i removed it from the agenda as its US Holiday today and wasnt gonna be able to make it!! cheers