[12:01] <nessita> hello everyone. diwic, re: bug # 1201528, on Saturday I installed a fresh precise, and audio broke when I installed the raring kernel. Verbose pulseaudio log attached to the bug
[12:02] <diwic> nessita, yeah, I saw. So, it looks like the kernel is at fault here...
[12:02] <nessita> diwic, apparently...
[12:03] <nessita> diwic, I still have the installation on a separated partition, so if you need me to run more tests, just let me know
[12:06] <diwic> nessita, I guess rtg could set up a git bisect between 3.2 and 3.8 for you
[12:06] <nessita> diwic, sounds good
[12:07] <nessita> diwic, do we have a newer kernel in saucy? I could try that too
[12:07] <diwic> nessita, saucy is 3.10.
[12:07] <nessita> diwic, would you recommend that path?
[12:08] <diwic> nessita, I think you tried saucy at one point and it was still broken, right?
[12:08] <nessita> diwic, no, at that point you considered it wasn't going to help
[12:08] <nessita> or it likely wasn't ging to help
[12:09] <diwic> nessita, I still think it's more likely it does not help, but feel free to try
[12:10] <nessita> diwic, I have no leftover space in my disk for a separated partition, so I would have to upgrade this raring to saucy. Would you know if the transition is "smooth"?
[12:10] <diwic> nessita, try saucy from a live USB stick.
[12:10] <nessita> or is there a package with saucy's kernel for raring?
[12:10] <nessita> ah, can do that
[12:10] <diwic> nessita, btw, is your computer home-built?
[12:11] <diwic> nessita, or does it have a common name (like "Dell inspiron D505")?
[12:11] <nessita> diwic, I bought the separated parts and I assembled it
[12:11] <nessita> so, I guess the answer is "yes"
[12:11] <diwic> nessita, okay, what graphics card is in there?
[12:12] <nessita> nvidia gforce (grabbing exact model)
[12:12] <nessita> 8400 GS
[12:13] <nessita> diwic, FYI, I did not install the propietary drivers in the precise installation
[12:13] <diwic> nessita, since it has been the graphics showing up on the wakeup_rt tracer reports - do you have another card around that you don't use, you could try switching and see what happens?
[12:13] <nessita> diwic, hum, no, I don't have, and this MB does not have integrated graphics
[12:13] <diwic> nessita, okay
[12:19] <diwic> nessita, so, a long boring git bisect, or possibly switching graphics cards are my best bets at the moment - but saucy could be worth a try too if it is easy for you to test
[12:20] <diwic> nessita, but I'm far from sure it's the graphics card at all so don't go buy a new one just for this :-)
[12:21] <nessita> diwic, right, I wasn't planning on getting a new video card... is hard for me to understand how video can mess up with audio like this. Specially since this computer has "a lot" of cores, so I would expect audio and video to not mess each other
[12:22] <nessita> diwic, will do the sacuy test. I'm also happy to do the git bisect, but I'd need instructions/packages for that
[12:22] <diwic> nessita, yeah, I too think that is surprising. I'm not an expert on scheduling. And I'm not ruling out audio either, it's just that that biggest weirdness are these latencies.
[12:23] <ohsix> oh my god, i can't even believe bfq and deadline came up in discussion as a reasonable thing to do
[12:24] <ohsix> bug #1201528
[12:24] <ubot2`> Launchpad bug 1201528 in alsa-driver (Ubuntu) "[Realtek ALC889] - Audio Playback Unavailable" [Undecided,New] https://launchpad.net/bugs/1201528
[12:27] <ohsix> heh oh man, raymond is on launchpad now ;O
[13:07] <ohsix> diwic: doesn't have to be a scheduling problem, but that is indeed weird stuff
[13:08] <ohsix> i'd be interested to see if some of the power state latencies and stuff were correctly reported and if it's entering them
[13:14] <rtg> apw, I updated overlayfs. looks like it builds OK. maybe you could do your testing on it ?
[13:15] <apw> rtg, is that post what i build this morning ... assume so
[13:15] <rtg> apw, just now. updated to v19
[13:15] <apw> rtg, ok
[13:42] <diwic> nessita, could you attach the output of /proc/interrupts ? It does not have to be any specific kernel or release.
[13:45] <nessita> diwic, sure, will grab them from this session. Do I need to "break" audio first?
[13:46] <diwic> nessita, does not matter.
[13:47] <nessita> ack, attached https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1201528/comments/41
[13:47] <ubot2`> Ubuntu bug 1201528 in alsa-driver (Ubuntu) "[Realtek ALC889] - Audio Playback Unavailable" [Undecided,New]
[13:48] <nessita> diwic, properly formatted https://pastebin.canonical.com/95432/
[13:48] <ohsix> 45 is a busy one
[13:49] <nessita> FYI, audio playback is still working (haven't opened mumble yet)
[13:50] <diwic> nessita, just curious if nvidia and snd-hda-intel were on the same cpu but it seems like nvidia is spread across all CPUs.
[13:51] <nessita> and nvidia interrupts values seem "reasonable"
[13:51] <nessita> snd_hda_intel interrupts are crazy high
[13:52] <diwic> nessita, and this was raring, right?
[13:52] <nessita> diwic, yes, 13.04 with 3.8.0-26-generic
[13:52] <diwic> ok
[13:53] <nessita> that makes me remember... /me needs to download saucy iso
[14:01] <diwic> nessita, are you running with tsched=0 ?
[14:01] <nessita> diwic, not that I know of, let me check
[14:01] <diwic> nessita, if you are that could explain the large values on snd-hda-intel
[14:02] <nessita> diwic, can you please remind me where to look?
[14:02] <diwic> nessita, /etc/pulse/default.pa
[14:03] <nessita> diwic, full content of the file https://pastebin.canonical.com/95438/
[14:03] <nessita> i don't see tsched there
[14:04] <diwic> nessita, nope, looks like the origina
[14:04] <diwic> l
[14:04] <nessita> yeah, my recall was that I reverted all the changes I tried
[14:10] <rtg> apw, laid down some hacks on lttng in unstable. can you have a look to make sure what I did makes sense ?
[16:12] <brandon__> hello
[16:13] <brandon__> hi
[17:24] <nessita> ohsix, I see that diwic left, but just wanted to mention that booted a saucy live from pendrive, and auido playback broke as soon as I opened mumble, attached to the bug the pulse verbose log (with lots of underuns), and the /proc/interrupts from before


[00:12] <brainwash> Daekdroom: bug 1275556
[00:13]  * Daekdroom subscribes to the bug report
[00:18] <brainwash> Daekdroom: maybe you should add a comment and state which package still requires gstreamer0.10-ffmpeg to work properly
[00:19] <brainwash> to the report mentioned in comment #1
[00:23] <Daekdroom> Ok.
[00:51] <CarlFK> porting some setup scripts to Trusty.. how do I auto login a user?
[00:51] <CarlFK> something like this: printf "autologin-user=vagrant\n" >> /etc/lightdm/lightdm.conf
[04:00] <AussieDownUnder> Seem to not always be able to tab out of programs to get to the desktop or use any shortcuts to get to the desktop in xubuntu 14.04 what so ever, the main corporate is XBMC & Steam Games not letting me go to the desktop without having to quit.
[05:53] <xsacha> if i stick with the current 14.04 kernel and then upgrade to final 14.04 later, is there a need to update the kernel or is it safe to stay with the existing kernel?  3.13.0-14-generic
[05:54] <xsacha> i've heard that it might change to 3.14 and was wondering if anything in the OS/apps would depend on that
[07:19] <nikolam> There is problem with updatedb/locate/find and BTRFS snapshots . It index them from begining, since they are always available to read from the root of FS.
[07:20] <nikolam> updatedb/locate/find could be more smart and recognize dates in BTRFS snapshots, to use previous indexed data, to finish indexing of snapshots earlier (and/or using btrfs send data about changed blocks till snapshot to identify and index only changed files)
[07:20] <nikolam> Or. updatedb/locate/find could by default, not index snapshots in BTRFS on Ubuntu...
[12:09] <BluesKaj> Hiyas all
[18:03] <siavoshkc> I finally got to install Ubuntu 14.04 on an AthlonXP 2000+ with DDR1 RAM
[18:03] <siavoshkc> But it is extremly slow
[18:04] <siavoshkc> like running Descent with 4MB memory (it needs 8)
[18:04] <susundberg> How much do you have RAM on that machine?
[18:04] <siavoshkc> 1GB
[18:05] <susundberg> Have you used ubuntu before -- i mean is this 14.04 related or general issue with ubuntu ?
[18:05] <siavoshkc> 14.04 related
[18:05] <susundberg> (is the 14.04 your first ubuntu installation on that machine)
[18:05] <susundberg> oh ok
[18:05] <siavoshkc> it was running puppy
[18:05] <siavoshkc> puppy is very light
[18:05] <susundberg> well its kind of minimalistic compared to gnome
[18:05] <susundberg> yeah
[18:06] <susundberg> you dont get that integrated desktop fun without cost :)
[18:06] <siavoshkc> I sense it is not normal
[18:06] <susundberg> can you open up terminal ?
[18:06] <siavoshkc> yes
[18:06] <susundberg> what does "free -h" show
[18:07] <siavoshkc> it is on another system
[18:07] <siavoshkc> lets see
[18:08] <susundberg> if you want, that will show your memory usage, like: http://paste.ubuntu.com/7028901/
[18:08] <susundberg> and with 'top' you can see top-memory users after you hit 'shift + m'
[18:09] <susundberg> oh, it might be also your desktop effects -- check those (and disable to see if it helps)
[18:10] <susundberg> btw: i myself am using 'lubuntu' with my oldish laptop to save memory / cpu
[18:11] <susundberg> mm, seems like i am using 1.4G atm, so i would not rule out the memory issue
[18:15] <siavoshkc> I was wrong
[18:15] <siavoshkc> I cant even open terminal
[18:17] <siavoshkc> desktop effects are bothering for sure
[18:25] <siavoshkc> how can I disable desktop effects
[18:50] <rohan> does nvidia-prime do automatic power control?
[19:02] <siavoshkc> THE problem is not memory
[19:02] <siavoshkc> about 750 MB is free
[19:03] <siavoshkc> anf top shows that only 10% of cpu time is being utilized
[19:22] <siavoshkc> How can I disable genome efffect
[21:33] <hippiehunter_> im having trouble getting 32bit applications that call getpwuid to work on my 64bit system that uses winbind for logins. it looks from an strace like i need winbind:i386 installed but that appears to be blocked by python-dnspython anyone have any suggestions on a way forward?


[07:36] <paddatrapper> morning everyone
[09:52] <inetpro> good mornings everyone
[15:50] <Kilos> afternoon all you lurkers
[17:08] <inetpro> good mornings Kilos
[17:08] <inetpro> good to see you are still surviving


[16:47] <fraggle> Anyone experience an issue with MythGame where the roms are found but clicking them does nothing?
[23:06] <baggar11> Anyone else with audio drift?


[13:38] <mick0> davidcalle: I can't seem to get album art to show and saw the same thing on your grooveshark scope. Has the support for loading icons from a http path been removed or changed?
[13:38] <davidcalle> mick0, if you search for the same thing a second time, does it work?
[13:38] <mick0> no
[13:39] <mick0> It only shows an white "file" icon
[13:39] <mick0> every time
[13:40] <davidcalle> Weird. It happens to the Grooveshark scope when the network is bad, but only on the first time, like it needs some time to cache the icons.
[13:41] <davidcalle> I wonder if it's not a problem with the music lens. Other python lenses gathering http icons work very well.
[13:42] <mick0> Might be. You got album art working with the grooveshark scope on the music lens that is on 11.10?
[13:42] <davidcalle> gord, hi. Are you aware of a problem with http icons sometimes not loading in the Dash?
[13:42] <davidcalle> mick0, yes.
[13:44] <mick0> Might be beacuse Im proxying with socks over ssh (on an unencrypted wlan). Will try without.
[13:46] <mick0> davidcalle: Also, shouldn't the music lens show the artist name and not just track/album names?
[13:48] <davidcalle> mick0, I have an unofficial branch for it, showing the artist name. The current one is by design, which is Ok-ish for local tracks and albums, but makes things difficult for remote ones from our scopes.
[13:48] <davidcalle> mick0, but there might be improvements about this in Precise.
[13:49] <mick0> ok. I'll just continue to send the artist in the "comment field" and it will show up when the lens supports it.
[13:50] <davidcalle> mick0, I guess it will be less of a problem when you have cover art showing up. You can also pass a new line character ( \n ) to the title field, and put the artist there.
[13:55] <mick0> davidcalle: Yes, propbably. It will also solve the problem on seeing which results are from the spotify scope as all their album art contains the logo. Right now, specially while having the grooveshark scope as well, it is hard to tell the results apart.
[13:55] <mick0> And I will try the \n. Thanks :)
[13:56] <davidcalle> mick0, ;)
[18:54] <jo-erlend> Thunderbird has serious issues with the infrastructure. The launcher counter never corresponds to anything comprehensible and whenever I get an email, there's about 50% chance that the notification doesn't have any relation to the incoming email at all. Is this well known and reported?
[19:38] <mhall119> davidcalle: ping
[19:38] <davidcalle> mhall119, yep
[19:39] <mhall119> davidcalle: pleia2 would like someone to talk about Unity lenses at the upcoming Ubuntu User Days, would you be willing to run a session?
[19:39] <mhall119> it's user-centric, so it would be more about what they offer and how to use them, than how to develop them
[19:39] <mhall119> but there may be more technical questions too
[19:40] <davidcalle> mhall119, sure. When is it?
[20:08] <mhall119> davidcalle: https://wiki.ubuntu.com/UserDays
[20:08] <mhall119> Jan 14th
[20:16] <davidcalle> mhall119, fine for me. Any hour will work.
[20:16] <mhall119> davidcalle: ping pleia2 in the -community-team channel and let her know
[20:16] <mhall119> and thanks
[20:19] <davidcalle> mhall119, no problem :-)


[00:02] <mwhudson> oh
[00:02] <mwhudson> i guess my branch copying over vfs can screw this up
[00:03] <mwhudson> jelmer: does bzr info -v on a locked branch tell you about the lock?
[00:04] <jelmer> mwhudson: I'm not sure, I don't think t does
[00:04] <jelmer> *it
[00:49] <peitschie> hi... i was wondering if anyone might have the time to help me attempt to adapt https://code.launchpad.net/~spiv/bzr/chk-canonicalizer-613698/+merge/32294 to be targetable to specific revision set?  I have a repo that has been reconciled for all revisions bar 2 new ones which were accidentally checked in using a broken revision history... which is now sinking the shared repo again
[00:53] <mkanat> peitschie: Do you think it would be a good idea to write a pre_change_branch_tip hook that rejects commits if they're going to do that to your repo?
[00:54] <peitschie> mkanat: it'd likely have been useful if I'd anticipated it :)
[00:54] <mkanat> peitschie: Yeah. I just mean since you indicated in your email that this sort of thing happens all the time.
[00:54] <peitschie> mkanat: at this point though, reconciling and repairing the broken revs are my top priority
[00:54] <mkanat> peitschie: Sure, I understand that. (I don't know much of anything about that area, though, so I can't help there.)
[00:54] <peitschie> mkanat: not all the time :)... just since the update
[00:56] <mkanat> peitschie: Ah, okay. :-)
[07:21] <vila> hi all !
[07:22] <mgz> morning vila!
[07:22] <vila> mgz: hey !
[07:23] <mgz> first, coffee, then I need to dump some of this bzr state I've been carrying in my head
[07:59] <mgz> vila: what's the right way to set an env var for the duration of a test only? I'm blanking...
[07:59] <vila> set_or_unset something, let me check
[07:59] <vila> the tests themselves are isolated so you don't have to restore it
[07:59] <vila> if you use the right base class that is
[08:00] <mgz> I'm looking at that code, and it seems to isolate then reset certain env vars, but only those as far as I can tell
[08:00] <vila> oh, hum, _captureVar does it. I'm not sure that's the right API to use or we should make it public maybe
[08:00] <mgz> looks like TestCase._captureVar would do what I want, bar the underscore
[08:01] <mgz> ...vilawins.
[08:01] <vila> :)
[08:01] <vila> defined in TestCase anyway, so you shouldn't be able to leak
[08:02] <vila> hmm, yeah, don't use _captureVar
[08:02] <mgz> calling it more than once for the same value would be bad
[08:02] <vila> or you risk retoring the bad value
[08:02] <vila> restoring
[08:02] <mgz> in fact, I think it might already be broken on windows
[08:03] <vila> osutils.set_or_unset_env is the one to use, may be not the best name though
[08:03] <mgz> as it's case insensitive and the override dict has values differing only by case
[08:03] <vila> weeeell, don't do that then :)
[08:04] <vila> I don't know of a case where differently cased vars are set to different values on *nix, but _cleanEnvironment already list FTP_PROXY and ftp_proxy and the like
[08:05] <mgz> right, that's a problem on windows
[08:05] <mgz> because the first one resets the value
[08:05] <vila> only for tests writers, but it may be wise to update the docstring then
[08:05] <mgz> then the second one records that reset value as the right thing
[08:06] <vila> yes, that's the possible failure I was referring to
[08:06] <mgz> am I reasoning this thing right?
[08:06] <mgz> anyway, doesn't matter much, you'd need to be caring your proxy still worked after running selftest for it to matter
[08:06] <vila> but only if you use _captureVar, not if you use set_or_unset
[08:07] <vila> not if you set an unknown env var.... you need to update _cleanEnv to have it tracked :)
[08:08] <mgz> I'll think of some better way of spelling this, need to share the code with doctests anyway
[08:08] <mgz> but... back to what I was doing
[08:14] <vila> mgz: Any thought on http://wiki.hudson-ci.org/display/HUDSON/testng-plugin (I know I shouldn't divert you :)
[08:15] <mgz> I know nothing about testng, so I'd need to find out more to have useful thoughts
[08:21] <vila> mgz: no hurry, I'll keep it on my radar, reporting skips sounds like a nice addition
[08:21] <vila> well, not applicable even more
[08:22] <vila> the idea was more about, if we can do that for skipped and not applicable tests, may be we can also report leaks this way
[08:23] <vila> maxb: regarding bug #636930 what should be our next move ? None ?
[08:23] <mgz> I think we have things to be fixing to get better results anyway
[08:24] <mgz> see bug I'll be filing later when I get down my todo list a little further for instance
[08:24] <vila> mgz: I'll look
[09:20] <maxb> vila: Someone actually needs to produce test run logs of 2.2.1 on maverick, with each failure justified as occurring with 2.2.0-1 too
[09:20] <vila> maxb: I see
[09:22] <mgz> ...vila, does your new news script check the items are in the right slot? we have a bunch of mps up right now that'd merge but put their news under 2.3b1
[09:22] <vila> mgz: fixed-in ? No, it doesn't do any check
[09:22] <mgz> does anyone?
[09:23] <vila> I warned the PP after releasing 2.3b1...
[09:23] <mgz> this is why I never write any news!
[09:23] <mgz> it's more trouble that it's worth :)
[09:23] <vila> :-P
[09:24] <vila> mgz: asking the RM to do that will be order of magnitude more trouble :)
[09:24] <mgz> okay, I think only roryy's news needs moving of the bits that I merged
[09:25] <vila> at least fixed-in should make such errors more obvious
[09:25] <mgz> having some sensible means of doing the merge locally before handing off to pqm would also help
[09:32] <vila> mgz: you need to use pqm-submit for local merges
[09:33] <mgz> I remember you showing me that but don't actually remember how.
[09:33] <vila> mgz: which is what feed-pqm is using under the wood
[09:33] <mgz> ...I think 'wood' is the wrong noun, but I now can't remember the right one.
[09:34] <mgz> hood.
[09:34] <vila> "bzr pqm-submit -m '(nick)message(Name)'" as feed-pqm add nick/Name
[09:34] <mgz> it's a car metaphor, not a furniture one
[09:34] <vila> hehe, hood, 3 letters right out of 4, I can even pretend it was a typo :)
[09:35] <vila> thanks for pointing this out :)
[11:23] <mgz> ...just thought of a cunning manifest hack, and it appears to work
[11:26] <mgz> bundling a dll in each dir would be ridiculous, but can put in more than one manifest, doesn't even seem to matter much what they contain
[11:32] <vila> mgz: the last assumption sounds suspicious...
[11:33] <vila> mgz: 'what they contain' sounds like you may be finding an irrelevant (even if correct) dll already loaded no ?
[11:36] <mgz> yeah, don't really want to deploy it without some grounding in fact
[11:40] <mgz> hm, maybe it matters a bit more thant I thought, does seem to want the ..\
[11:41] <vila> hehe, funny how we tend to come here with vague beliefs to get them refuted ;)
[11:42] <vila> which is a Good Thing :)
[11:42] <mgz> well, it's not the actual location of the dll, but it's close enough apparently
[11:43] <vila> yeah for DWIM paths: look there or close enough
[11:45] <vila> bbiab
[12:07] <zyga> how can I change the default log format for all commands that use log somehow? Do I need to add lots of alias commands?
[12:08] <Glenjamin> what commands use log?
[12:09] <zyga> Glenjamin, for example bzr missing
[12:09] <zyga> I'd like missing to use git log format
[12:10] <Glenjamin> i suspect the "easiest" way to do this would be a plugin
[12:10] <zyga> !
[12:10] <zyga> no configuration for such a preference?
[12:18] <Glenjamin> ah, i was incorrect
[12:19] <Glenjamin> "bzr help log-formats" indicates there is a preference
[12:19] <Glenjamin> zyga: ^^
[12:20]  * zyga checks
[12:20] <zyga> Glenjamin, thank you that's exactly what I was looking for
[14:42] <vila> bialix, GaryvdM: ping, I see you don't add a '-1' in the windows installer names, is that deliberate ? Do you add it only if you need to build a new one ?
[15:41] <jam> morning all
[15:41] <jam> hi vila
[15:41] <vila> jam: hey !
[15:46] <jam> mtaylor: still having the "missing inventories" problem?
[16:01] <jam> vila: I'm trying to figure out how we generated 450 bug emails since last wed. It has been like 100 emails per day...
[16:05] <vila> jam: huh, really ?
[16:05] <jam> yep
[16:05] <jam> at least in my inbox
[16:05] <jam> it may be qbzr, etc
[16:06] <vila> ha, right, if I look at my bzr-bugs box, 450 goes back to sept 22
[16:42] <mgz> I have three more bugs to add to jam's mountain today as well
[16:42] <mgz> just working out the last one now
[16:43] <mgz> looks easy like the first rather than horrid like the second
[18:15] <immy> hii.
[18:15] <immy> why isn't anyone talking. :(
[18:16] <dash> immy: did you have a question? :)
[18:16] <immy> yes. :) what is this chtroom for. :)
[18:17] <dash> immy: http://bazaar-vcs.org/
[18:17] <dash> immy: a version control tool, mostly used by programmers. :)
[18:18] <immy> oh right.
[18:18] <immy> cool!
[18:18] <immy> why is it used?
[18:19] <dash> immy: did you ever save a file you were working on, then realize you deleted or changed some things you wanted to keep?
[18:19] <dash> immy: bzr is a tool for remembering all the older versions of your files in a project
[18:20] <dash> so you can look at its entire history, from the beginning up to now
[18:20] <immy> ohhh i see.
[18:20] <immy> cool!
[18:21] <dash> for text files it can also show you the differences between different versions
[18:21] <dash> and if you have a project that multiple people work on, it can merge together work done on different versions to make a combined version
[18:21] <rubbs> immy: http://betterexplained.com/articles/a-visual-guide-to-version-control/  and http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ can explain about what this does on a more "zoomed out" level
[18:22] <dash> the Ubuntu project uses bzr a lot as a tool to help programmers around the world cooperate on the same projects
[18:25] <mgz> so, version control is cool and all, but where are the cute guys?
[18:26] <vila> dash, rubbs, mgz : He's gone...
[18:26] <dash> alas.
[18:26] <mgz> ah, here's one.
[18:26] <rubbs> vila: opps. that's what I get for ignoring quits...
[18:26] <dash> i thought we had a new user ;)
[18:28] <mgz> wow, that's a pretty crazy traceback in bug 654684
[18:30] <vila> mgz: geez, that was fixed long ago...
[18:32] <mgz> he says he tried 2.2.1 which suggests otherwise
[18:32] <vila> weird, looks like bug #395714
[18:33] <mgz> the subprocess branch location is pretty unlikely, I doubt he's even trying to use http
[18:33] <mgz> so there's probably a qbzr or explorer bug there as well
[18:34] <vila> mgz: don't forget it's bencoded ?
[18:35] <mgz> ah, yeah.
[18:35] <mgz> he does say "local branch" but that could mean over the lan or something
[18:38] <vila> hmm, checkout with http will not allow commits either or is it different with svn ?
[18:38] <dash> vila: svn can do commits via http.
[18:38] <vila> anyway, jelmer will kill me still haven't implemented OPTIONS in our http transports :-/
[18:38] <vila> kill me for
[18:39] <mgz> on the topic of svn, I need some user support...
[18:39] <vila> dash: ha right, thanks
[18:40] <mgz> tried to do `svn update -r 78554 a_file` on the python 2.7 maint branch, which used to be python trunk, and it deleted the file rather than change it to an old version
[18:40] <mgz> presumably because the rev predated the name change which confused something?
[18:41] <mgz> what keywords can I use to find a fix for that, everything's too generic.
[19:26] <lifeless> mgz: 'svn UI doing as designed' ?
[19:40] <mgz> lifeless: how do I get the old rev then? switch then update -r worked but switch is a big hammer.
[19:46] <fullermd> Import into bzr, then...    ;)
[19:47] <mgz> heh.
[20:55] <maxb> mgz: As far as svn's concerned, a switch operation is strictly a superset of an update operation. Thus, you can switch -r
[20:56] <maxb> and on that note, /me afks
[21:30] <git__> anyone know what "PointlessCommit(No changes to commit)" mean?
[21:30] <dash> it means you tried to do a commit with no changes in it
[21:31] <git__> i made change to the file but still get the error message
[21:31] <git__> is there a limit how many directories bzr can traverse?
[21:31] <dash> git__: what does 'bzr status your/file/name' say?
[21:31] <dash> no
[21:32] <git__> doesn't say anything
[21:33] <dash> git__: then the file is unchanged.
[21:33] <git__> let me change the file now, and do bzr status [filename]
[21:33] <mgz> or unversioned.
[21:34] <mgz> do `bzr add yourfile`?
[21:34] <dash> mgz: it'd say "unknown" if it wasn't added
[21:34] <git__> even after changing the file, i did bzr status [filename], nothing return
[21:35] <mgz> not if it's in the ignore list I think.
[21:35] <dash> mgz: oh true
[21:35] <dash> git__: what's the filename
[21:35] <git__> category.tpl
[21:35] <git__> every files in the directory have that problem
[21:35] <dash> hmm well that won't be in the default ignore list
[21:36] <mgz> what's the directory name? :)
[21:36] <git__> product
[21:36] <mgz> okay, that's not very ignorable either
[21:43] <git__> I use bazaar explorer, it works
[21:57] <gmpff> hi
[22:23] <git__> is there any plan for bzr to support image differential?
[22:23] <git__> i like bzr upload feature, that's the coolest
[22:23] <dash> git__: you can use any diff program you like with bzr
[22:37] <jam> \o/ I finally dug myself out of 450 bug mail message backlog. The big offender was james_w with his udd spam. (Not that those aren't worthy, but it generated a *huge* amount of emails over the week(end))
[22:38] <jam> git__: "image differential"? I believe qbzr already supports showing images side-by-side when seeing them in a diff
[22:38] <jam> (bzr qdiff, IIRC)
[22:41] <james_w> jam: yeah, sorry about that
[23:01] <jam> james_w: I just responded to your history email, I think you might be wrong about the analysis, but I could have messed something up myself.
[23:01] <jam> I have to go now, but I'll try to follow up tomorrow.
[23:02] <james_w> jam: thanks, I'll take a look
[23:31] <jml> mgz: I promise, soon, I will review your branches.
[23:31] <jml> mgz: thank you for them
[23:31] <mgz> ha, do that then I just make you review more
[23:32] <mgz> (they all kinda need input rather than rubber stamping, so I don't mind you taking a while)
[23:33] <mgz> o, while I have you though, is it easy to give me triage rights on testtools?
[23:35] <mgz> I've filed a few things and then can't prio them.
[23:35] <jml> mgz: uhh, probably... I've made a note & will fix it if I can.
[23:36] <mgz> it's a niggle only.
[23:39] <jml> mgz: don't get me started on niggles
[23:39] <jml> anyway, must retire. g'night.
[23:39] <mgz> night!
[23:44] <poolie> hi jml, mgz, good night
[23:45] <mgz> hey poolie.


[00:20] <slangasek> xnox: s390x is being very unhelpful wrt gnucash
[00:36] <slangasek> xnox: n/m, it's just guile being segfaulty
[01:42] <ahasenack> do you guys need any help with some migration or dep8 test?
[01:44] <ahasenack> man, so many tests in progress
[04:54] -queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (bionic-proposed) [<IP_ADDRESS>]
[07:43] -queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (bionic-proposed) [1.178ubuntu2.7]
[10:27] <cjwatson> So, uh, shouldn't we be in Debian import freeze now, per the release schedule?
[10:27] <cjwatson> Or has that changed?
[10:29] <acheronuk> tsimonq2 did mention in passing he might ask for FF to be pushed back a week, but I have no clue if anything came of that
[10:54] <ahasenack> per #topic, we are not in FF yet
[11:03] <cjwatson> Yeah, I know that, but the release schedule on the wiki says otherwise so something has to give :)
[11:04] <cjwatson> (also, FF isn't necessarily the same as DIF ...)
[11:11] <ahasenack> I think there are not enough builders to cope with the huge queue, it will be a while
[11:11] <ahasenack> just guessing
[11:22] <cjwatson> That normally isn't a factor, since it's OK for things to land provided they were at least uploaded before the deadline
[11:22] <ahasenack> I'm counting on that actually
[11:22] <cjwatson> (You possibly mean autopkgtest runners.  The Launchpad build farm is mostly idle right now.)
[11:23] <ahasenack> true
[13:10] -queuebot:#ubuntu-release- New sync: devscripts-el (cosmic-proposed/primary) [40.1]
[13:11] -queuebot:#ubuntu-release- New sync: dpkg-dev-el (cosmic-proposed/primary) [37.4]
[13:12] <xnox> slangasek, who cares about guile, when emacs is busted =) please accept above two NEW packages, which got split out of emacs-goodies-el (which i forced synced now)
[13:13] <xnox> once above is in, i will readd ubuntu suite names to the dpkg-dev-el one
[13:44] -queuebot:#ubuntu-release- New source: spirv-tools (cosmic-proposed/primary) [2018.2-0ubuntu1]
[15:17] <teward> did something happen to FeatureFreeze?
[15:17] <teward> (proxy-requesting because dpb1 posted it in #ubuntu-server)
[15:31] <ddstreet> slangasek can you approve nodejs upload to bionic please
[16:42] -queuebot:#ubuntu-release- New: accepted devscripts-el [sync] (cosmic-proposed) [40.1]
[16:42] -queuebot:#ubuntu-release- New: accepted dpkg-dev-el [sync] (cosmic-proposed) [37.4]
[16:44] <slangasek> cjwatson: yeah, we should be in DIF now, switch flipped
[16:44] -queuebot:#ubuntu-release- New binary: devscripts-el [amd64] (cosmic-proposed/universe) [40.1] (no packageset)
[16:45] -queuebot:#ubuntu-release- New binary: dpkg-dev-el [amd64] (cosmic-proposed/universe) [37.4] (no packageset)
[16:49] <cjwatson> thanks
[16:52] <slangasek> xnox: your new emacs-goodies-el has a pile of component-mismatches too
[16:53] <xnox> slangasek, which i solved by dropping emacs-goodies-el from the seed.
[16:53] <slangasek> ok
[16:53] <xnox> slangasek, it's the other ones from new that we will want to keep in main, i.e. the debian/control|changelog modes which are now split out
[16:55] <jbicha> slangasek: could you promote guile-2.2 to main and once aisleriot migrates, we can demote guile-2.0?
[16:57] -queuebot:#ubuntu-release- New: accepted devscripts-el [amd64] (cosmic-proposed) [40.1]
[16:57] -queuebot:#ubuntu-release- New: accepted dpkg-dev-el [amd64] (cosmic-proposed) [37.4]
[17:04] <xnox> doko, apw - sigh
[17:04] <xnox> /usr/include/x86_64-linux-gnu/bits/statx.h:25:8: error: redefinition of ‘struct statx_timestamp’
[17:05] <xnox> /usr/include/linux/stat.h:56:8: note: originally defined here
[17:13] <xnox> ah, infinity ^
[17:14] <xnox> i think there is misscompat somehow between headers or something
[17:20] <tsimonq2> infinity, slangasek: Ping, I'd like an opinion on bug 1788904 when someone has the chance.
[17:21] <tsimonq2> Basically, I'm asking a policy to be formalized which has seemingly already been in effect for the Ubuntu Desktop Team among others.
[17:26] <infinity> xnox: I can haz larger example?
[17:26] <xnox> infinity, sbuild of systemd fails now =)
[17:26] <infinity> xnox: Oh, that's no big loss.
[17:26]  * infinity ducks.
[17:26] <xnox> infinity, so $ sbuild -A -d cosmic systemd_239-7ubuntu4
[17:27] <xnox> infinity, well you asked for a larger example, afterall =)
[17:27] <infinity> xnox: Hahaha.  A slightly smaller one? :P
[17:28] <infinity> xnox: But yeah, looks like statx is new to glibc (and the kernel, probably), and needs all the usual guards.
[17:28] <infinity> Hate this dance.
[17:28] <infinity> xnox: Of course, you might also be able to fix it by not including linux/stat.h
[17:36] <xnox> infinity, #include <linux/stat.h> #include <sys/stat.h> -> is that broken to include both now?
[17:36] <xnox> and #include <sys/xattr.h>
[17:36] <infinity> xnox: It's almost always wrong for userspace to include anything in linux/
[17:37] <infinity> Not always always, but almost always.
[17:37] <xnox> there is a mega comment saying that we want to use statx() cause it's exposed from v4.11+ and that it might not be there and fallback to something else.
[17:37] <xnox> i guess if statx is available now in userspace there is no need for linux/stat.h anymore.....
[17:38] <xnox> infinity, i'm just curious if this is a bug in systemd, or headers, or both.
[17:38] <infinity> It's certainly possible for glibc and the kernel to guard against this.
[17:38] <xnox> infinity, i mean i will fix systemd obviously, but not sure if the headers can be "better" (stupid-compatible?!) somehow.
[17:39] <infinity> On the other hand, Florian was the committer, and he's usually smarter than that.
[17:39] <infinity> So unless there appears to be a valid reason to want both, the conflict might be intentional.
[17:39] <xnox> 4/* Missing glibc definitions to access certain kernel APIs */
[17:39] <xnox> is the heading used for these includes in systemd tree
[17:39] <infinity> And I don't see any reason to want the kernel version, at a glance.
[17:39] <xnox> so possibly obsolete now.
[17:40] <infinity> Unfortunate that an upstream fix will have to have a conditional include.
[17:40] <infinity> But not world-ending either.
[17:41] <infinity> include sys/stat, ifndef foo, include linux/statx
[17:41] <infinity> xnox: I'm assuming Fedora already ran into this, since they probably shipped glibc 2 weeks ago.
[17:42] <infinity> xnox: Unless they've not rebuilt systemd since.
[17:42] <infinity> Now, if I could remember how to find fedora sources..
[17:43] <xnox> i'll propose conditional upstream i think.
[17:43] <xnox> (systemd)
[17:44] <infinity> Yeah, I'm going to look at what Fedora's done here for kicks.
[17:46] <infinity> Ahh, and that's that answer.  systemd in Fedora hasn't been built since mid-July.
[17:47] <infinity> Oh, wait.
[17:48] <infinity> xnox: https://src.fedoraproject.org/cgit/rpms/systemd.git/commit/?h=f29&id=5306894742943e5d46ac705a3f2d5db1a48a0a67
[17:49] <infinity> xnox: Looks like a Googler has already proposed a patch (and F29 is carrying it).
[17:49] <infinity> xnox: So, cheers.
[17:50] <xnox> infinity, lovely, cause propose to fedora and not to upstream?
[17:50]  * xnox checks master again
[17:51] <infinity> Gah, GitHub is all wonky.
[17:51] <infinity> WHY.
[17:52] <infinity> xnox: https://github.com/systemd/systemd/commit/75720bff62a84896e9a0654afc7cf9408cf89a38
[17:52] <infinity> xnox: Looks upstreamish to me.
[17:52] <teward> infinity: because GH is owned by Microsoft now?  *shot*  (no but seriously...)
[17:53] <infinity> teward: I suspect it doesn't particularly relate (except maybe Github higher-ups trying to look "busy" and "useful" to not get "fired" and made "homeless" by their new overlords)
[17:53] <infinity> Either way, this dashboard landing page madness is... Busy.
[17:53] <infinity> And useless.
[17:53] <xnox> infinity, it got replaced by https://github.com/systemd/systemd/commit/9c869d08d82c73f62ab3527567858ce4b0cf1257#diff-969b60ad3d206fd45c208e266ccfed38
[17:54] <teward> infinity: indeed.  (It's why I've been shifting to other providers, or running my own GitLab instead for my projects, but I digress)
[17:54] <teward> (I was going to ask "what happened to feature freeze" but I just saw the emails about it, so don't mind me :P )
[17:54] <infinity> xnox: Fancy.  Definitely a step in the not-silly direction.  Maybe.
[17:54] <xnox> we have thousands of things in autopkgtest queue backlog still....
[17:54] <xnox> hence to me FF is a bit meaningless
[17:55] <infinity> FF isn't about migration, it's about uploads.
[17:55] <teward> ^ that
[17:55] <infinity> Certainly not meaningless to say "okay, stop uploading MORE feature changes".
[17:56] <teward> indeed.  which reminds me, roaksoax has a proposed change to Cosmic that'd alter the package structure, that'd need an FFe review right?
[17:56] <teward> to Cosmic nginx*
[17:56] <teward> (at this point it's not yet 'tested' or 'accepted' as working so it didn't get included in the latest uploads I did for it)
[17:56] <infinity> xnox: Anyhow, based on those two commits, I'd say the systemd community is accepting that it's their bug, and not a bug in the headers.  And Lennart would argue six ways to Tuesday if he even 5% thought it was our bug, so I'm going to call that definitive. :P
[17:58] <xnox> infinity, he may have been on holiday since july and has not seen this commit yet
[18:00] <infinity> xnox: He committed the first one.
[18:01] <infinity>  filbranden authored and poettering committed on Jul 15
[18:09] <infinity> Oh look, and my build failed on two arches, despite testing it earlier.
[18:09]  * infinity looks.
[18:21] -queuebot:#ubuntu-release- Unapproved: rax-nova-agent (bionic-proposed/main) [2.1.15-0ubuntu1~18.04.0 => 2.1.15-0ubuntu1~18.04.1] (no packageset)
[18:47] <tsimonq2> doko: My updated assessment on the KDE autopkgtest situation is that there's enough library interdependencies that a build needs to be done for autopkgtest accuracy.
[18:48] <tsimonq2> doko: Alternatively we're exploring just really tightening the autopkgtest deps on the packages, but Santa was working on that and he's been in and out (likely on vac) lately.
[19:47] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.17.0-9.10] (core, kernel)
[19:48] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.17.0-9.10] (core, kernel)
[20:12] -queuebot:#ubuntu-release- New binary: murano-agent [amd64] (cosmic-proposed/universe) [1:3.5.1-0ubuntu2] (no packageset)
[20:31] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.17.0-9.10]
[20:31] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.17.0-9.10]
[20:53] <slangasek> jbicha: guile-2.2 promoted
[20:53] <slangasek> jbicha: did you see my question about whether you've received britney nagmails about zc.lockfile?
[21:01] <slangasek> anyone care yet about node + rollup?  or should I just remove the lot from -proposed?
[21:06] <LocutusOfBorg> slangasek, I care about node+rollup
[21:07] <LocutusOfBorg> at least after all the work I did
[21:07] <LocutusOfBorg> let me try to find a way
[21:51] <LocutusOfBorg> slangasek, is it possible to remove automake-1.15 from archive? useless now
[21:51] <LocutusOfBorg> NBS
[21:52] <slangasek> LocutusOfBorg: 'NBS' - it doesn't show up on http://people.canonical.com/~ubuntu-archive/nbs.html , what do you mean?
[21:53] <LocutusOfBorg> the "automake" binary is now part of src:automake-1.16, migrated in cosmic hours ago
[21:53] <LocutusOfBorg> so, the src:automake-1.15 is producing nothing, I don't know what is the best wording :)
[21:56] <slangasek> LocutusOfBorg: sounds like a source package whose removal we would pick up via Debian
[21:56] <LocutusOfBorg> [2018-08-10] automake-1.15 REMOVED from testing (Britney)
[21:56] <LocutusOfBorg> oh indeed, still part of unstable, meh
[21:57] <LocutusOfBorg> ok https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906928
[21:57] <slangasek> yah, not worth putting extra effort into those kinds of removals, they'll eventually get reaped
[21:57] <slangasek> I run process-removals several times between FF and release
[22:02] <LocutusOfBorg> nice
[22:31] -queuebot:#ubuntu-release- New sync: debian-el (cosmic-proposed/primary) [37.6]
[22:31] <xnox> slangasek, one more NEW package needed for the emacs-goodies-el split.... sorry that i missed that one. ^
[22:34] <slangasek> xnox: done
[22:34] -queuebot:#ubuntu-release- New: accepted debian-el [sync] (cosmic-proposed) [37.6]
[22:38] -queuebot:#ubuntu-release- New binary: debian-el [amd64] (cosmic-proposed/none) [37.6] (no packageset)
[23:38] <slangasek> jbicha: and guile-2.0 demoted
[23:52] <slangasek> LocutusOfBorg, acheronuk: I see you both retried the kdeconnect/s390x autopkgtest failure; it looks entirely reproducible and looks to me like there's a good chance it's a big-endian bug.  How should we proceed with this?
[23:53] <jbicha> slangasek: I didn't see your question the first time but I'll take a look at zc.lockfile
[23:54] <slangasek> jbicha: ok, thanks for looking - and did you previously receive emails?
[23:54] <slangasek> because I'm trying to figure out if we have a bug generally in not notifying people of stuck force-syncs
[23:56] <jbicha> I get lots of email from the Release Team :)


[15:25] <Martyn> Hurray!  Freescale /finally/ announced the i.mx51 netbooks this weekend
[15:25] <Martyn> Now we can babble about the Pegatron and Inventec devices all we want :)
[15:25] <Martyn> Unfortunately, they decided to only show it with Android.  *grr*
[15:26] <Martyn> That netbook would totally have looked awesome w/ Ubuntu
[19:55] <palin> Hi all! Does anyone know when the arm base netbooks are coming out? I have search but can not find a date.
[19:56] <palin> link anything?
[19:57] <palin> ok then ty


[16:00]  * slangasek waves
[16:00] <jodh> o/
[16:01] <slangasek> #startmeeting
[16:01] <meetingology> Meeting started Thu Feb 27 16:01:21 2014 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:01] <meetingology> Available commands: action commands idea info link nick
[16:01] <slangasek> [TOPIC] Lightning round
[16:01] <slangasek> $ echo $(shuf -e barry doko stgraber jodh bdmurray slangasek cjwatson xnox caribou infinity)
[16:01] <slangasek> slangasek barry stgraber infinity doko cjwatson caribou bdmurray jodh xnox
[16:01] <doko_> can I go first?
[16:01] <slangasek> doko_: go ahead
[16:01] <doko_> have to leave early ...
[16:01] <doko_> - aarch64 compiler discussions
[16:01] <doko_> - updated various cross compiler packages, and fixed the powerpc cross
[16:01] <doko_> - transitions: octave, qhull, spatialite, ...
[16:01] <doko_> - rest of the time spent on +1 maintenance work
[16:01] <doko_> (done)
[16:03] <slangasek> * fixes for nfs-utils getting ready for an LTS (bug #1284210)
[16:04] <slangasek> * slowed down this week by a sprained finger and a head cold
[16:04] <slangasek> * otherwise, head down in customer-facing work, so nothing to report
[16:04] <slangasek> (done)
[16:04] <barry> system-image: 2.1-0ubuntu4 loaded on the train (landing 10) which fixes LP: #1279056, LP: #1277589, LP: #1260768, LP: #1284217 (backported).  Also, reviewed and merged our first external contribution LP: #1278589.  New image update stack (s-i, u-d-m, and s-s) in landing 10 tested and verified ready to go.  also tested s-i against new server layout.
[16:04] <barry> autopilot: more py3 discussions, we have a plan, once the ci train gets back on track.  worked on gallery-app but again, waiting on the train.  review https://github.com/rilmodem/ofono/pull/56
[16:04] <barry> ubu/deb: python-virutalenv 1.11.4-1 (fixes pip installation problem). LP: #1283742; investigating LP: #1272359; investigating LP: #1284469
[16:05] <barry> other: ubuntu-on-air presentation on python 3 porting
[16:05] <barry> done
[16:05] <stgraber> LXC:
[16:05] <stgraber>  - Released LXC 1.0 and dealt with the following flood of e-mails, comments, ...
[16:05] <stgraber>  - Tracked down apparmor bug when switching profile on-eec on an overlayfs root (never happens...), workaround pushed to LXC upstream by Serge.
[16:05] <stgraber>  - Fixed a couple more important but trivial bugs.
[16:05] <stgraber>  - Sent patch to fix unprivileged containers started by root.
[16:05] <stgraber>  - Reviewed patches to fix some of the main issues for distros shipping with an rshared / (systemd based distros mostly).
[16:05] <stgraber>  - Planning to release 1.0.1 at some point next week.
[16:05] <stgraber> CGManager support for logind:
[16:05] <stgraber>  - Got basic create/remove/chown/chmod working at the moment.
[16:05] <stgraber>  - Current goal is to have the patch support all the basic cases we care about to create/destroy/list sessions, the rest will fallback to the fs interface if available.
[16:05] <stgraber>  - That ought to be enough to get it working with cgmanager for unprivileged containers and for us to stop shipping cgroup-lite while not risking regressions for the main non-container case.
[16:05] <stgraber> System-image:
[16:05] <slangasek> barry: so does "loaded on the train" mean it's landed, or just that it's in a silo?
[16:05] <stgraber>  - Applied a few changes for ports.
[16:05] <stgraber>  - Discussed the required changes to allow http-only and https-only servers.
[16:05] <stgraber>  - Helped a community member setup his server, quite a few more patches to review as a result.
[16:06] <stgraber>  - Started planning the mass channel rename (/* => /ubuntu-touch/*), looks like all the tools will cope with this fine, just need some more tests and an announcement.
[16:06] <stgraber> Other:
[16:06] <stgraber>  - Driving Beta 1 this week
[16:06] <barry> slangasek: only the silo :/
[16:06] <stgraber> (DONE)
[16:06] <slangasek> barry: ack
[16:06] <barry> stgraber: client trunk has support for turning off http or https
[16:07] <stgraber> barry: cool! the server branch support it too, so we just need to wait till the next client release and I'll be able to update the instructions.
[16:08] <barry> stgraber: i wonder if it's worth pushing out an s-i 2.2 for 14.04?  i guess that is dependent on getting 2.1 actually landed first.
[16:09] <slangasek> infinity: oh, your turn :)
[16:09] <stgraber> barry: 2.2 sounds good to me. I guess you're covered by the touch-packages FFe anyway, right?
[16:09] <barry> stgraber: i believe so, yes
[16:09] <infinity> slangasek: Lies.
[16:10] <infinity> slangasek: I'm just a tourist.
[16:10] <slangasek> infinity: you didn't end your statement with a (done)
[16:10] <infinity> I'M JUST A TOURIST (DONE)
[16:10] <cjwatson> welcome back to foundations, not that you really left :)
[16:10] <cjwatson> (modulo a day or three either way)
[16:11] <xnox> infinity says... whilst unlocking the safe full of golden bricks.
[16:11]  * xnox loved that movie.
[16:12]  * slangasek scratches his head
[16:12] <slangasek> cjwatson:
[16:12] <cjwatson> Oh yeah, confused by doko's reordering
[16:12] <cjwatson> Continuing work on libclick:
[16:12] <cjwatson>  - Finished initial draft of C implementation.
[16:12] <cjwatson>  - Decided that the amount of manual exception handling I was doing was ridiculous; rewrote in Vala.
[16:12] <cjwatson>  - Got some simpler bits of the test suite working against the new library.
[16:12] <cjwatson>  - Fighting with getting the rest of the test suite to work.  I want to be able to use mostly the same Python test code, which is reasonably feasible with GI, but also to be able to install mock functions that affect native code.  I think I have a nearly-functional if alarming answer ...
[16:12] <cjwatson> Cleaned up loose end of d-i/HTTPS support (enabled Acquire::https::Verify-Host in unauthenticated-SSL mode).
[16:12] <cjwatson> ..
[16:13]  * xnox slangasek: The Tourist, Angelina Jolie, Johnny Depp...
[16:14] <slangasek> caribou: hi, anything you want to share this week?
[16:14] <caribou> * Continued work on kdump problem
[16:14] <caribou> * some language training & tests
[16:15] <caribou> (done)
[16:15] <bdmurray> research into failed to retrace crashes on the error tracker
[16:15] <bdmurray> updated ubuntu-assets errors with javascript changes from mpt after merging his branches
[16:15] <bdmurray> updated ErrorTracker/Deployment wiki page with more info about assets
[16:15] <bdmurray> fixed an issue in errors with Launchpad bugs for kerneloops not being displayed (r454)
[16:15] <bdmurray> fixed an issue with the error tracking not returning all the linux binary packages
[16:15] <bdmurray> modifications to rate of crashes calculation for the phased updater
[16:15] <bdmurray> pushed change to errors to use new rls:srcpkg:pgk_version counters for rate of crashes calculation
[16:15] <bdmurray> bug triage of foundations bugs, ubuntu-release-upgrader bugs
[16:15] <bdmurray> helped kiko debug an upgrade failure
[16:15] <bdmurray> merged fix for update-notifier bug 1282760
[16:15] <bdmurray> investigation into apt-clone failure on !amd64 !i386
[16:15] <bdmurray> +1 maintenance
[16:15] <bdmurray> investigation into and fix of ubuntu-release-upgrader test failures with python3.4
[16:16] <bdmurray> pushed ubuntu-release-upgrader fix for bug 1272387
[16:16] <bdmurray> SRU team work and mentoring
[16:16] <bdmurray> dealing with a kerneloops on my desktop
[16:16] <bdmurray> ⌁ done ⌁
[16:16] <slangasek> caribou: "language training"?
[16:16] <barry> bdmurray: you are the new ev
[16:16] <infinity> slangasek: English is hard.
[16:16] <jodh> * foundations-1305-upstart-work-items:
[16:16] <jodh>   - core-1311-upstart-roadmap: cgroup support:
[16:16] <jodh>     - After discussions with hallyn+stgraber on leveraging the cgmanager
[16:16] <jodh>       code by reworking it into libcgmanager-core, transpires that this
[16:16] <jodh>       strategy is not realistic. Hence, continuing to work on the fix
[16:16] <jodh>       for the state machine issue (along with all the tests).
[16:16] <jodh> * ppc64el:
[16:16] <jodh>   - Investigated dep8 test failures for nih+upstart. Currently looking
[16:16] <jodh>       at sbuild and pbuilder failures.
[16:16] <jodh> ✨
[16:16] <caribou> slangasek: after years of playing around with C, I thought it would be useful to learn pythone
[16:16] <slangasek> infinity: I thought he meant that English was misbehaving and he was taking it to obedience school
[16:17] <caribou> pythone = python with ze french accent
[16:17] <slangasek> caribou: ah :)
[16:17] <jodh> darn - my chosen utf-8 char doesn't appear to render in weechat.
[16:17] <jodh> ⌁ done ⌁
[16:17] <jodh> bdmurray: immitation and flattery... :)
[16:17] <xnox> jodh: looks fine here... whatever it is.. twinkle stars?
[16:18] <jodh> yeah - "twinkles"
[16:18] <xnox> * python3 migration:
[16:18] <xnox>   - the big blockers: phablet-tools (phablet-test-run), unity8,
[16:18] <xnox>     ubuntu-ui-toolkit, ofono-scripts (thanks to pitti) are all ported
[16:18] <xnox>     to python3 and awaiting landing, when landings resume again.
[16:18] <xnox>   - most of other apps/clicks, are also ported, and pending landings.
[16:18] <xnox>   - along the way fixed packageit default backend to use python3 bug
[16:18] <xnox>     #1283574
[16:18] <xnox>   - made upstart-app-launch to not pull in gtk3/python2 via zeitgeist
[16:18] <xnox>     meta-package dependency.
[16:18] <xnox>   - porting gdebi to python3 or unseeding it from touch is remaining
[16:18] <xnox>     bigish task
[16:18] <xnox> * toolchains:
[16:18] <xnox>   - provided gcc-4.8 androideabi cross-toolchain for rsalveti, to
[16:18] <xnox>   hopefully build both android-system.img with 4.8 and
[16:18] <xnox>   hybris/platform-api with 4.8 and thus get us off 4.7.
[16:18] <xnox>   - refreshed arm cross-toolchains base packages to pick up eglibc
[16:18] <xnox>     2.19.
[16:18] <xnox>   - working on i686-android cross-toolchain to start building x86
[16:18] <xnox>     emulator in the archive.
[16:18] <xnox> * installer:
[16:18] <xnox>   - working to land proper fixes for bug #1012629
[16:18] <xnox>   - unbroke ubiquity for beta1 bug #1282640
[16:18] <xnox> * random:
[16:18] <xnox>   - removed vintage COF logo from all theme packages i could find
[16:18] <xnox>   - my PC RAM has memtest errors, sent of for RMA thanks to lifetime
[16:18] <xnox>     warranty. Recommendations on good 32GB (4x8GB) DDR3 RAM are
[16:18] <xnox>     welcome. Should I go for ECC?
[16:18] <xnox>   - working on my non-thinkpad, and not doing dm-raid work, will get
[16:18] <xnox>     replacement ram asap.
[16:18] <xnox> ..
[16:19] <slangasek> xnox: is the move to gcc-4.8 for android looking promising?  or do we not know yet if it works?
[16:20] <xnox> slangasek: i have gcc-4.8 toolchain in a PPA, and i know that android-4.4 does _not_ compile, as it has -Werror everywhere, and it's not 4.8-clean...
[16:20] <slangasek> k
[16:20] <doko_> doesn't google have its own 4.8 branch for android?
[16:20] <xnox> slangasek: in theory it should all work, in practice i remember starting out with 4.8, and reverting back to 4.7. Cause at the time nobody was on 4.8 (even linaro)
[16:21]  * slangasek nods
[16:21] <xnox> doko_: there is a google branch of 4.8, for master, not used by default. (not enabled for 4.4 release, nor kitkat stable branches, so i take it's for 4.5 or later...)
[16:21] <slangasek> any other questions about your teammates' status?
[16:22] <infinity> jodh: Is my pet session bug still on your radar?
[16:22] <jodh> infinity: I'm sure we can add that to the next release, assuming we get the MP backlog cleared (hint directed at other upstart devs ;)
[16:23] <xnox> infinity: jodh: what's the pet bug?
[16:24] <infinity> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1277594
[16:24] <xnox> infinity: with or without my crazy backwards compatible name for the option?! =)
[16:24] <infinity> ...
[16:24] <infinity> No, please not --no-no-sessions :P
[16:25] <slangasek> --bad-touch-sessions
[16:25] <jodh> --jfdwiw
[16:26] <infinity> If you implement that one successfully, we're all out of a job.
[16:26] <jodh> infinity: ;D
[16:26]  * jodh wonders if systemd has that one... ;)
[16:26] <slangasek> infinity: pretty sure if somebody implements that, we have lucrative careers ahead of us extricating users from what they said they wanted
[16:26] <infinity> No, systemd has --jfdwlw
[16:26] <xnox> slangasek: i was thinking to change --no-sessions to take a bool, with "true" as default, thus --no-sessions[=true] is default, and --no-sessions=false to re-enable them.
[16:27] <infinity> slangasek: Ahh, you're seeing it as an equivalent to --genie?
[16:27] <xnox> slangasek: this saves introducing an option.
[16:27] <slangasek> xnox: no opinion :)
[16:27] <barry> jodh: you just need to link in libjfdwiwastfu
[16:27] <slangasek> [TOPIC] Bugs
[16:27] <xnox> barry: i thought it's ldpreload, no?!
[16:27] <slangasek> bdmurray: so doko_ brought up a question about bug tracking
[16:28] <jodh> barry: heehee
[16:28] <barry> xnox: right! it allows you to call into python3-jfdi
[16:28] <bdmurray> about milestones correct?
[16:28] <slangasek> we haven't been systematically tracking bugs this cycle... I've been having a hard time even finding the page with the report :/
[16:28] <slangasek> bdmurray: yes
[16:28] <doko_> heh
[16:29] <xnox> barry: yes, but only vi gobject-introspection =))))
[16:29] <xnox> s/vi/via/
[16:29]  * doko_ has to leave now ...
[16:29] <barry> s/vi/emacs
[16:29] <slangasek> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-t-tracking-bug-tasks.html ?
[16:30] <slangasek> doko_: so the process hasn't changed, we've just been bad about following it :)
[16:30] <bdmurray> yes, that has the ones with an Trusty task
[16:31] <slangasek> can I ask that everyone take a look at the bugs on that report over the next week, and help make sure it's tracking the right issues for release?
[16:31] <slangasek> (claiming bugs you'll work on, and adding any bugs to the list that you think should be there by setting the right bug target + rls-t-incoming tag)
[16:32] <xnox> well bug #1246539 is fixed as part of driving python2 off touch images.
[16:32] <xnox> slangasek: right, ack.
[16:32] <doko_> slangasek, ok, and does anybody move the milestones? and which ones to ise by default?
[16:32] <xnox> ..
[16:32] <xnox> doko_: just needs targetting to series trusty, no milestone needed.
[16:33] <slangasek> doko_: we mostly haven't been using the milestones for bugs
[16:33] <doko_> ok
[16:33] <doko_> away now
[16:33] <xnox> bug #1277865 - looks strange, we do resize& use_free installation, on a system that does _not_ have ESP, yet try to install grub-efi into one, and we didn't crate ESP as part of resize and install.
[16:34] <slangasek> [TOPIC] AOB
[16:35] <slangasek> anything else?
[16:35] <slangasek> fyi, if your blueprints aren't in already for vUDS, they're late :P
[16:36] <barry> slangasek: i really have nothing new for vUDS.  i don't really see much of a point in fast forwarding the older blueprints and discussing them again.
[16:36] <slangasek> barry: indeed
[16:36] <slangasek> but anything you *do* want discussed should have been registered by now :)
[16:37] <stgraber> same here, I didn't submit anything because we're past FeatureFreeze and the remaining work is pretty clear (bugs!).
[16:38] <cjwatson> slangasek: so I *cough* haven't registered the Qt versions blueprint you asked me to do yet - is that still relevant in light of recent mail threads?  do you want it rephrased as how we're handling this on an ongoing basis?
[16:38] <xnox> slangasek: unless there isn't one, pruning useless technologies off the touch images would be a good one. E.g. gtk2, gtk3, X11 libraries, etc.
[16:39] <slangasek> cjwatson: my intent was to discuss early what the plan is for next cycle and going forward... definitely still relevant AFAICS
[16:39] <cjwatson> k
[16:39] <xnox> slangasek: and blacklisting them / establishing policy for touch-seed.
[16:40] <slangasek> xnox: if you think it's useful to have a discussion about this (planning how to divide and conquer the work?), please register it :)
[16:40] <xnox> slangasek: ack.
[16:40] <xnox> (need to check how much of that work is left...)
[16:41] <slangasek> #endmeeting
[16:41] <meetingology> Meeting ended Thu Feb 27 16:41:52 2014 UTC.
[16:41] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-02-27-16.01.moin.txt
[16:41] <slangasek> thanks all
[16:42] <jodh> thanks!
[16:42] <barry> thanks!
[16:42] <stgraber> thanks!


[06:44]  * os__ is away: هلق راجع
[07:56]  * os__ is back (gone 00:03:41)
[07:57]  * os__ is away: I'm busy
[07:57]  * os__ is away: هههههه
[07:57]  * os__ is away: I'm busy
[07:57]  * os__ is away: I'm busy
[07:57]  * os__ is back (gone 00:00:06)
[08:04]  * os__ is away: عم أشطف
[09:14]  * os__ is back (gone 01:09:59)
[09:14] <thelinuxer> os__: please stop the automatic messages
[09:14] <os__> OH ! SORRY
[09:14] <thelinuxer> os__: np :)