[04:43] <pitti> Godo morning
[04:43] <pitti> infinity: can do, yes
[04:44] <pitti> bdmurray: I wouldn't have bothered with quantal/raring, for precise it sounds fine to me; but it's already in -proposed now anyway :)
[04:51] <pitti> infinity: btw, I synced postgresql-9.1, that should build on arm64 now
[04:52] <infinity> pitti: \o/
[04:52] <infinity> pitti: Will look shortly.
[05:10] <pitti> infinity: meh, still no export on https://translations.launchpad.net/ubuntu/saucy/+language-packs
[05:10] <pitti> wgrant, StevenK: ^ could you please check whether this is running, or something went wrong?
[05:11] <wgrant> 2013-10-10 11:31:31 ERROR   Uncaught exception while exporting PO file 2444794
[05:11] <pitti> argh
[05:11] <wgrant> DB thing, it seems
[05:11] <pitti> apparently the delta packs run like clockwork, so so PO file 2444794 apparently hasn't been touched for a while
[05:12] <wgrant> Nah, nothing particular to that pofile, I don't think
[05:12] <wgrant> Just a DB glitch
[05:12] <pitti> wgrant: the last export also took about a day longer than expected, but eventually arrived; did that get restarted manually or did it somehow recover from that error?
[05:13] <wgrant> pitti: I haven't manually scheduled one in months. You sure it just wasn't the export that happens a couple of days later?
[05:13] <pitti> wgrant: it could have very well been that
[05:13] <pitti> but time is more critical now with the final release around the cordner
[05:13] <pitti> corner
[05:14] <wgrant> IIRC saucy happens tue/thu
[05:14] <wgrant> Might have to kick a special one off now
[05:14] <pitti> that would be good, so that we can build them Monday morning (or I kick them off on Sunday)
[05:16] <pitti> infinity: ah darn, missed the final freeze for psql? I was waiting for the LP import of the sid upload, but it didn't happen until I had to leave
[05:17] <pitti> infinity: well, I guess it can stay in -proposed and we 0-day update it to -updates if you don't want it in the release any more
[05:17] <infinity> pitti: Nah, it's all good.
[05:18] <infinity> pitti: Bonus points if it actually builds.
[05:18] <pitti> infinity: well, I refreshed config.guess/sub to latest saucy autotools-dev; I'm not sure it'll actually work there, let's see what the tests say
[05:19] <pitti> infinity: in 9.3.1 I saw a log entry "add arm64 s_lock code", we might want to backport that
[05:19] <infinity> Other than random segfaults and, of course, compilers needing to be ported, most stuff has Just Worked, so I have high hopes.
[05:20] <infinity> I don't much care if anything's *optimised* for arm64 right now, so if 9.3.x will make it to 14.04, that's cool.
[05:22] <infinity> sarnold: Have you looked at #1220434?  Looks like the last MIR of the cycle.
[05:23] <pitti> infinity: yes, 9.3 will be in 14.04
[05:24] <infinity> pitti: Kay.  So, if this 9.1 build works at all, we win.
[05:24] <infinity> pitti: More concerned about it because it's part of the base bootstrap loop, not because I think people will want to run psql on their simulators. :)
[05:25] <pitti> infinity: at the worst case I can reupload with a trivial change to add arm64 to the 'test failure is okay' list in debian/rules
[05:25] <pitti> (currently hurd and kfreebsd)
[05:32] <bdmurray> pitti: I meant the verifying the fix for the bug
[05:33] <pitti> bdmurray: it's certainly not verified until it gets tested with the actual binaries from -proposed
[05:33] <pitti> (guard against weird build failures, etc.)
[05:39] <pitti> infinity: OOI, did you find out why gid=tty now magically works?
[05:39] <pitti> (or does it?)
[05:40] <pitti> wgrant: just to avoid misunderstandings, did you kick off a new export now?
[05:40] <wgrant> pitti: I poked ops about it, haven't got a response yet, will repoke once UK appears I guess.
[05:40] <pitti> wgrant: ah, thanks
[05:40] <pitti> hm, why is consolekit still being installed by default
[05:41]  * pitti checks germinate
[05:43] <infinity> pitti: It works fine for me.  I can't figure out what WASN'T working before I rebooted.
[05:45] <infinity> postgres (27651): /proc/27651/oom_adj is deprecated, please use /proc/27651/oom_score_adj instead.
[05:45] <infinity> pitti: Yell at your upstream about that. :P
[05:45] <infinity> pitti: This is 2013, I shouldn't still be seeing those messages.
[05:46] <infinity> pitti: (Build went fine on arm64, though)
[05:47] <pitti> wow, already built?
[05:47] <pitti> it takes some 10 minutes with all the tests even on my machine
[05:47] <pitti> ah, time flies fast this morning
[05:48] <pitti> yay
[05:48] <pitti> infinity: upstream is on BSD :)
[05:48] <pitti> infinity: yeah, I've got a bug for oom_adj
[05:50] <infinity> pitti: My inability to recreate the broken situation I had with the new eglibc leads me to believe I just had something weird going on locally.  But I dunno.
[05:53] <pitti> infinity: (btw, I uploaded umockdev earlier)
[05:53] <infinity> pitti: Thanks.
[05:54] <infinity> pitti: You apparently have fans, because mir build-depends on it.
[05:54] <pitti> heh, yeah
[05:55] <pitti> I could actually also make upower build-dep on it, now that we have it in Debian, too
[06:15] <infinity> pitti: component-mismatches was your code, right?
[06:15] <pitti> infinity: I wrote the SVG/html report on top of it
[06:15] <pitti> http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[06:15] <pitti> not c-m itself
[06:15] <pitti> I thought that was part of LP?
[06:16] <infinity> Ahh, hrm.  I'm trying to figure out why the c-m python script appears to be crashing on a binary that doesn't exist. :P
[06:16] <pitti> ah no, that was NBS
[06:17] <infinity> Oh.
[06:17] <infinity> I bet it's because germinate's still crashing on pepo.
[06:17] <infinity> wgrant: Did anyone look into that?
[06:18] <wgrant> infinity: Colin said he might, but I suspect he was a bit busy.
[06:32] <Guest3903> i'm seeing quite serious issues while trying to install kubuntu using beta2 or latest ISO  -- looks like it's failing in some partition parsing, so the installer is completely stuck after the "Prepare" step
[06:33] <Guest3903> i have filed a bug here: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1238446
[06:33] <Guest3903> could someone help me debug, or populate the bug report and make it more useful? thanks
[06:59] <dholbach> good morning
[07:02] <Guest3903> hi dholbach: i am facing a serious ubiquity bug on the livecd. could you help me out? or at least help me provide a better bug report?
[07:02] <Guest3903> i have filed a bug here: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1238446
[07:06] <dholbach> Guest3903, I just had a look at /usr/share/apport/package-hooks/source_ubiquity.py - and if you could find an upstart/ubiquity.log and/or casper.log and/or oem-config.log that'd probably help
[07:07] <dholbach> Guest3903, but this is just me doing guesswork - I'm not an expert
[07:07] <Guest3903> dholbach: i am still on the livecd, so if you can tell me where, i can try
[07:08] <dholbach> Guest3903, also in /var/log - like the other log files you added
[07:08] <Guest3903> Attached /var/log/casper.log
[07:08] <Guest3903> i dont' see an upstart/ubiquity.log
[07:15] <dholbach> oSoMoN, happy birthday! :)
[07:16] <Guest3903> i have a feeling i can resolve the problem by clearing out all my partitions, but i thought i'd rather file the bug so that if it's a ubiquity problem, it can be fixed
[07:22] <infinity> Guest3903: What filesystem is/was on that partition?
[07:22] <infinity> Guest3903: Was it XFS?
[07:23] <Guest3903> no
[07:23] <Guest3903> infinity: there are 4 partitions, all of them are either vfat or NTFS
[07:24] <Guest3903> infinity: just added that info to the bug report
[07:25] <infinity> Fun.
[07:26] <Guest3903> yea, the XFS errors confused me too
[07:26] <infinity> Oh, there isn't even an sda4 (well, it probably exists as an extended container)
[07:26] <infinity> The plot thickens.
[07:26] <Guest3903> well, does GPT even have concept of an extended partition?
[07:28] <Guest3903> infinity: also, curiously, parted crashes while trying to print the partition table
[07:28] <infinity> Oh, this is GPT?  I missed that on the first.
[07:28] <infinity> pass...
[07:28] <infinity> Maybe GPT doesn't deal well with having holes in the numbering scheme?
[07:30] <infinity> Guest3903: What does /proc/partitions have to say about it?
[07:31] <Guest3903> infinity: udpated report
[07:33] <Guest3903> infinity: sda4 seems to be partition of unknown type with flag "msft-reserved" -- unlikely to be a hole
[07:34] <infinity> Guest3903: Yeah, I found that in the partman log too.  No idea what that is.  Maybe a place where they stuff filesystem snapshots or something?
[07:35] <infinity> Guest3903: Anyhow, your simple way forward is just to blow up the partition table.  But if you're keen on debugging and fixing that, you might try asking xnox about it when he's around in an hour or two.
[07:35] <xnox> infinity: "in an hour or two" phhhh
[07:35] <infinity> Or right now. :P
[07:35]  * xnox yawns
[07:36] <Guest3903> infinity: yes, i'd rather help fix it if i can :)
[07:36] <xnox> Guest3903: i don't see anything obvious. And indeed it's strange that gpt partition table gives you head-aches.
[07:37] <Guest3903> and interestingly, the 13.04 installer did not have any issues on this exact setup
[07:38]  * xnox ponders why there is Permission Denied.
[07:38] <xnox> Guest3903: all of them are unmounted right?
[07:38] <Guest3903> xnox: yes, "mount" does not show any sdaX partitions mounted
[07:39] <xnox> Guest3903: ok. And what are the labes on /dev/sda2 and /dev/sda1 ?
[07:39] <xnox> *labels
[07:39] <Guest3903> xnox: sda1 is "SONSYS" and sda2 is "Recovery", type vfat and ntfs respectively
[07:40] <oSoMoN> dholbach: thanks :)
[07:40] <Guest3903> i have a feeling that SONSYS is the EFI System partition, Recovery the OEM "windows recovery" partition, no clue about msft-reserver, and the last partition my actual windows install, xnox
[07:42] <jderose> xnox: since you're around... any ideas as to why the OEM user isn't getting removed by oem-config after the user config runs? my highest priority item the next week is getting this fixed (on behalf of System76)... so please task me with whatever will help :)
[07:42] <xnox> Guest3903: infinity: so couple of things are weird. Cause EFI is usually first, not /dev/sda3, and parted thinks they are called "/dev/sda1	žé" and "/dev/sda2	9"
[07:44] <jderose> xnox: and a quick question: is there a way to make ubiquity do more verbose logging during the user config?
[07:44] <Guest3903> xnox: both look like EFI, though it's impossible: https://dpaste.de/ADXx
[07:44] <Guest3903> xnox: i think sda1 is ESP for sda2 "recovery" OS, and sda3 is ESP for sda4/sda5 "windows" OS
[07:44] <xnox> jderose: i wonder if it is a side-effect of ubiquity starting a logind session. Let me get you version numbers such that we can test downgrading oem-config "between the install & prepare for final shipping" stage.
[07:45] <Guest3903> xnox: and if i power my laptop using "assist" button, the recovery ESP kicks in and starts the "recovery" OS (which is windows recovery mode)
[07:45] <Guest3903> if i power on using the power button, windows starts as usual
[07:45] <xnox> jderose: yes, more verbose mode would be, I still think "debug-ubiquity" at kernel cmdline, https://wiki.ubuntu.com/DesktopCDOptions
[07:46] <jderose> xnox: yeah, my hunch is it's related to the new PAM stuffs in ubiquity-cm, but i don't have enough ubiquity knowledge to grok what's really going on :)
[07:46] <xnox> jderose: oh right, yeah.
[07:46] <xnox> jderose: you can't delete a user with active pam session.
[07:47] <xnox> jderose: we usually hang out on #ubuntu-installer, but I guess we can continue here.
[07:47] <jderose> xnox: so bits of the user config are running as the OEM user then?
[07:48] <xnox> cjwatson: infinity: so ubiquity-dm opens a pam/login session for the oem-config user.... thus can't delete it whilst it's well still logged in. Where/how should the user account be deleted? oem-config/post-stop?
[07:49] <Guest3903> xnox: any more useful info i can provide/
[07:50] <xnox> Guest3903: what's the output of "$ sudo parted -l" ?
[07:51] <Guest3903> xnox: https://dpaste.de/7vqi same error pretty much
[07:51] <infinity> xnox: Yeah, if there's a point where we shut down that session, that's when we should delete the user, I guess.
[07:52] <xnox> jderose: so what happens is that machine boots normally -> starting lightdm even is emitted in upstart, oem-config job starts and blocks lightdm. Oem-config job checks for magic file, and start ubiquity-dm as root. At that point ubiquity-dm creates a pam session for the oem-config user ( i think). At the end of the ubiquity-dm run, it deletes the user.
[07:52] <xnox> *not user but session.
[07:52] <xnox> infinity: right, let me look at that code path and check if I can close the pam session earlier, before deleting the user.
[07:53] <xnox> Guest3903: i think your bug is against parted and or windows. So partition/filesystem labels really should not have multiwide characters / unknown encoding.
[07:54] <xnox> Guest3903: if you can boot into windows, open partitioning/admin utilties and try to rename or remove partition labels of whatever is /dev/sda1 and /dev/sda2 in windows.
[07:54] <xnox> Guest3903: then somehow reboot or check that windows still works.
[07:54] <Guest3903> but kde partition manager seems to understand the labels fine, xnox.. so it could be a partition thing?
[07:54] <xnox> Guest3903: then boot up the 13.10 live cd and see what's there.
[07:54] <Guest3903> *parted thing
[07:54] <xnox> Guest3903: hm, we do have old parted.
[07:55] <Guest3903> sounds like a regression still, because 13.04 installer worked on the same setup. i should probably try redoing that to test
[07:55] <xnox> Guest3903: what does kde partitioner manager say? maybe screenshot, or copy strings?
[07:55] <Guest3903> xnox: kde partition manager screenshot is in the report
[07:55] <Guest3903> xnox: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1238446/comments/13
[07:55] <xnox> Guest3903: well, you can fetch /var/log/installer/* from the installed 13.04 and check if the partitions were named the same back when you did 13.04 install. Not much has changed in parted stack in the installed in 13.10.
[07:55] <Guest3903> argh. https://launchpadlibrarian.net/153474755/snapshot1.png
[07:57] <Guest3903> xnox: i don't have the installed system any more, sorry.. i could try running the 13.04 installer again i guess
[07:57] <xnox> Guest3903: strange.
[07:57] <Guest3903> i am sure it worked, though, because i cloned my current disk from the same disk image used when i had installed 13.04
[08:01] <jderose> xnox: so when i use debug-ubiquity, does this additional logging go into syslog, or are there other log files i should be looking at?
[08:01] <xnox> jderose: /var/log/installer/oem-config i think =/ or look at other files under /var/log/installer/*
[08:01] <xnox> jderose: there should also be /var/log/upstart/[oem-config|ubiquity].log
[08:05] <jderose> xnox: upstart/ubiquity.log - http://paste.ubuntu.com/6221392/
[08:05] <jderose> not sure if that ValueError is related or not
[08:06] <xnox> i don't think so.
[08:06] <xnox> it's probably from the "normal/first install"
[08:06] <xnox> not from oem-config run.
[08:08] <Guest3903> whoa, the parted in 13.10 is 3 years old! the lates t release was also in 2012 .. any idea why i
[08:09] <Guest3903> any idea why we have such an old release?
[08:10] <xnox> Guest3903: because FS code was removed in the new major parted series, and debian-installer is not ported yet to the new world order.
[08:10] <Guest3903> xnox: ah i see
[08:11] <Guest3903> xnox: ok, i am going to try booting the kubuntu 13.04 iso to see if it actually works or i'm just misremembering
[08:12] <Guest3903> can't think of anything else useful to do :)
[08:12] <Guest3903> apart from booting to windows and changing the partition labels as you suggested
[08:13] <xnox> Guest3903: or change the labels using KDE partition manager & reboot the installer again.
[08:13] <Guest3903> but parted is not tripping up on the labels, is it? it's tripping up on the device names right
[08:14] <xnox> no, device names are fine.
[08:14] <xnox> i think.
[08:15] <xnox> infinity: it's hallarious but purely from packaging I'm failing to see where "ubiquity" ui is actually started upon oem-config-firstboot. lol.
[08:15] <jderose> xnox: i attached a tarball of all of /var/log after running the user config (and with the debug-ubiquity boot arg) - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1231166
[08:16] <xnox> jderose: thanks.
[08:16] <jderose> xnox: well, makes me feel a little better about me struggling to find my way around ubiquity :P
[08:16] <xnox> infinity: bug #624888
[08:20] <infinity> xnox: Did the s/deluser/userdel/ thing get reverted, or does userdel now shut you down too?
[08:21] <jderose> infinity: i looked at that earlier today... currently it's using userdel, in oem-config-wrapper i believe is the script
[08:22] <xnox> infinity: does it know about systemd?
[08:22] <xnox> infinity: well logind.
[08:24] <jderose> if the problem is trying to delete the OEM user when that user is logged, can the userdel bit be moved to later stage?
[08:25] <infinity> xnox: Effed if I know.
[08:26] <infinity> xnox: uderdel is pretty dumb, it's not meant to know about much at all.
[08:26] <infinity> xnox: Does userdel perhaps just need a '-f' to fix the bug?
[08:26] <jderose> it's being called with `userdel --force --remove oem`
[08:27] <xnox> jderose: || true
[08:27] <infinity> I guess force needs to be taught to force harder...
[08:27] <jderose> well, yeah, that bit too :P
[08:27] <xnox> so we don't fail, on not removing oem-config user.
[08:28]  * xnox will move it to post-stop exec line in upstart job and check what happens.
[08:28] <jderose> yeah, that seems a bit fragile... better to get a loud error in that case so regressions are noticed sooner
[08:28]  * xnox goes to find coffee
[08:29] <jderose> xnox: infinity: thanks for your help on this! much thanks from System76 :D
[08:31] <Guest42952> xnox: i was wrong, 13.04 ubiquity has the exact same problem. it's stuck after "preparing"
[08:31] <Guest42952> and parted also errors out with the same message
[08:31] <Guest42952>  and yet again kde partition manager works perfectly
[08:33] <infinity> Guest42952: Can you try relabelling to test xnox's theory that the hang is due to multibyte chars?
[08:33] <infinity> Guest42952: We can argue if that's a bug that parted (or something) can't read those labels, and it probably is, but it would be nice to prove it first. :)
[08:34] <Guest42952> well kde partition manager is not allowing me to change labels
[08:35] <Guest42952> but if both blkid and kde partition manager can read the labels fine, it has to be a Parted issue, right?
[08:35] <infinity> I'm not convinced that parted's problem is the labels just yet.
[08:38] <pitti> seb128: bonjour, ça va ?
[08:38] <pitti> seb128: did you already talk to the release team about 3.10.1 bits next Monday?
[08:38] <seb128> pitti, salut, oui, et toi ?
[08:38] <pitti> seb128: je vais très bien, merci
[08:38] <seb128> pitti, no, I planned to just SRU those, we don't have so much 3.10 anyway
[08:39] <pitti> seb128: ok, then I perhaps upload gnome bug 709223 as a patch right now
[08:39] <pitti> seb128: I'll release pygobject 3.10.1 on Monday with that (and a memleak fix)
[08:39] <seb128> pitti, if you want it in the release, today seems a better bet than monday in any case
[08:39] <seb128> who knows we might not get respins after monday
[08:40] <infinity> Monkeys may fly, too.
[08:40] <infinity> (But I appreciate the enthusiasm and confidence)
[08:40] <pitti> oh, I thought it was the pigs who can fly, but perhaps that doesn't work in Canada? :-)
[08:41] <xnox> pitti: britain is a funny place.
[08:41] <xnox> infinity: or not yet?
[08:41] <xnox> =)
[08:41] <pitti> in Canada they say "Adams can sleep"
[08:41] <infinity> pitti: It is, and the monkeys traditionally do something slightly less tasteful.
[08:41] <infinity> xnox: Not in London until Sunday.
[08:41] <xnox> pitti: The Adams family, tudutudutudu.
[08:41] <Guest42952> infinity: anything else i can provide to help?
[08:41] <pitti> oh those mental pictures *off*, *off*!
[08:42] <infinity> Guest42952: Not sure, TBH.  Hence why I pointed you at xnox.  Not my area of expertise. :)
[08:42] <Guest42952> fair enough. xnox, anything else that could help debug/
[08:42] <xnox> not really no.
[08:45] <Guest42952> ok. thanks for all the help, xnox, infinity!
[08:46] <tvoss_> pitti, pin
[08:46] <tvoss_> g even
[08:46] <pitti> hey tvoss_
[08:48] <jderose> er, what did i do... now oem config is launching the ubiquity installer rather than the user config... hmm, time to unbork my VM i guess
[08:51] <tvoss_> pitti, mind having a look here: https://bugs.launchpad.net/mir/+bug/1238417
[08:51] <pitti> tvoss_: queueing
[08:52] <tvoss_> pitti, ack and thx
[08:58] <jderose> xnox: so what were you moving to post-stop?
[08:59] <xnox> jderose: i am investigating at the moment.
[09:00] <jderose> xnox: please let me know if there is anything you want me to try/test
[09:00] <xnox> jderose: there is also kernel cmd line option "debug-oem-config" in addition to "debug-ubiquity"
[09:00] <jderose> ah, okay, i'll try that too. my VM is again submitting to my will, so i'm ready to go
[09:02] <jderose> xnox: is there any use in using debug-oem-config and debug-ubiquity together, or should I just use debug-oem-config?
[09:06] <xnox> i think you just need "debug-oem-config" but debug-ubiquity will not hurt.
[09:08] <jderose> okay, i just tried without the "|| true" bit, hopefully the failure will log something useful...
[09:13] <jderose> xnox: attached another /var/log tarball - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1231166
[09:14] <xnox> jderose: i think that should work: http://paste.ubuntu.com/6221565/
[09:15] <xnox> jderose: so, "before shipping to use"
[09:15] <xnox> jderose: modify /etc/init/oem-config.conf to include the bits at the end from "post-start script ... end script"
[09:15] <xnox> jderose: then reboot, do end user config, and observe that oem-config user is removed.
[09:15] <jderose> xnox: okay, trying now...
[09:24] <jderose> xnox: yup, that fixes it!
[09:25] <jderose> oem isn't in passwd or group, and /home/oem has been removed
[09:25] <jderose> user login works as expected
[09:26] <xnox> jderose: good.
[09:26] <xnox> jderose: we do keep ubuntuone package for the end user configuration. but it's a separate package from oem-config, FYI.
[09:27] <jderose> yeah, i saw the plugin is in a separate binary package... first thing i tried was removing it, just in case that was the problem :P
[09:28] <jderose> but we'll leave it in place, btw
[09:29] <jderose> xnox: what's the best way for me to help with this? https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1237694 <= my next highest priority
[09:29] <xnox> jderose: i'm working on bug #1226912 at the moment
[09:30] <jderose> (also, BTW, i'm not 100% sure 2.15.21 was what introduced that regression)
[09:30] <xnox> hm.
[09:31] <jderose> xnox: so does this only happen when you "try ubuntu first" rather than directly choose "install ubuntu"? I think i hadn't noticed this because i tend to use the latter
[09:32] <xnox> jderose: no, if you press Esc at boot splash and select "try ubuntu without changing your computer" text menu item.
[09:32] <xnox> jderose: or e.g. if you select that on an UEFI machine.
[09:32] <jderose> gotcha
[09:32] <pitti> bdmurray, stgraber, ScottK: would you mind ack'ing the psql microrelease uploads for all stables? (they have a MRE, and nothing out of the ordinary, so it should be rather straightforward); bug 1237248
[09:45] <jderose> xnox: okay, my brain is mush and i need sleep now, but i'll do what i can to help out on these ubiquity bugs tomorrow, and next week. thanks again!
[09:46] <xnox> jderose: no worries. Thank you.
[10:12] <pitti> infinity: I uploaded apport to disable crash reporting to LP for final release (as per release checklist); it needs to go into the final image, but not necessarily today yet, so please accept whenever it's convenient
[10:13] <infinity> pitti: Yeahp, thanks.
[10:14] <infinity> pitti: To be clear, this is just disabling the "open a web browser and file a bug and make me hate you for it" part, not the reporting to errors.ubuntu.com, right?
[10:14] <pitti> infinity: correct, the whoopsie/daisy parts stay
[10:14] <pitti> infinity: same procedure as last release (and the ones before..)
[10:15] <infinity> pitti: Yeah, it's gotten a bit fuzzy with whoopsie in the mix.  I think we even had one release (or most of one) where we never had the web browser bits.  I liked that cycle. :P
[10:16] <pitti> infinity: before whoopsie we completely disabled apport, to avoid the CPU overhead
[10:16] <infinity> pitti: No, I meant during a dev cycle, we didn't re-enable the browsery bits once.
[10:16] <pitti> then we had that rather long and heated discussion, I admitted defeat, and now it's done like that ever since
[10:16] <pitti> infinity: we usually didn't do before alpha-2
[10:16] <infinity> Anyhow, no big deal.  Current situation works.  Thanks for the upload.
[10:16] <pitti> but it's a matter of some gut feeling "it's time now"
[10:33] <ev> slangasek, pitti, others: I'm finding it hard to find time for bug 1235436. Is anyone available to help out?
[10:40] <xnox> ev: i think it's a funny integration with ro-system images. You cannot rely on file being present or not. Instead you should check if contents of it is zero / non-zero. Or some such. As we can make that file available by default, and allow users over-writting its content, but not completely delete the file.
[10:40] <xnox> ev: this is similar to the timezone changes not persisting across ro-system upgrades bug.
[10:41] <xnox> ev: how is /etc/init/apport-noui.conf created at the moment?
[10:41] <ev> xnox: it's shipped as part of apport
[10:41] <xnox> sorry, i mean the /etc/apport/autoreport.
[10:41] <xnox> that shipped as well?
[10:42] <xnox> ev: i think will be SRUing that bug report.
[10:43] <ev> xnox: oh dear. We need to add that to the writable paths - it's created by system-settings
[10:43] <pitti> it's not in the current images at least
[10:43] <pitti> so, another victim of our hacked-up /etc? :-/
[10:44] <xnox> ev: and you can't test with [ -e ], as system-image updates are ro, and bind-mounted. If user "deletes" the bind-mount, it would be recreated on reboot.
[10:45] <xnox> ev: but you can make it writable, thus one needs to check it's contents, or some such. Which means that maybe you can reuse existing whoopsie config file which is parsable and add "auto=True" key to it.
[10:45] <ev> xnox: can you please add your thoughts to the bug so we're tracking this in a single place?
[10:45] <xnox> ev: ok.
[10:45] <ev> thanks, just trying to manage calls and chatting here at the same time
[10:45] <xnox> ev: and then there is the race to fix of multiple apports tracing the same thing =)))))
[10:45] <ev> I'm going to lose some details :)
[10:46] <pitti> xnox: nah, let's not automatically modify conffiles
[10:46] <xnox> pitti: hm, good point.
[10:46] <pitti> (sorry, just half a brain cell here either, it seems today is the day when I get bombarded with "OMGcanyoulookintobugXXXXX" requests)
[10:46] <xnox> ev: right after I make ubiquity to stop spinning in an infinite loop.
[10:46] <xnox> pitti: ditto =)
[10:47] <pitti> but please let's not do any knee-jerk addition of files o writable-files
[10:47] <pitti> the current implementation for handling files there is quite frankly rather broken and not maintaintable at all
[10:48] <pitti> ev: I'd rather move the file to /lib or something
[10:48] <pitti> ev: or an alternative lookup path to /userdata, or whichever path we actually have left for putting data into
[10:48] <pitti> as we essentially said "/etc/ is not for configuration any more", I guess /userdata is the logical replacement
[10:54] <ev> pitti: I honestly don't mind where we put it
[10:54] <ev> definitely deferring to your better judgement on this :)
[11:14] <infinity> pitti: I'm emptying out the stragglers in the NEW queue, and there's an oddity there from you.
[11:15] <infinity> pitti: You removed flphoto from saucy because it "didn't work with libgphoto 2.5+" and then, on the same day, you uploaded a no-change rebuild, which got cause in NEW because you'd already removed the previous version.
[11:15] <infinity> pitti: So, which is it? :)
[11:15] <infinity> s/cause/caught/
[11:19] <pitti> infinity: I think the reupload was an error, I probably just forgot to rm it from my local "to rebuild"  folder, sorry
[11:42] <tvoss_> pitti, wondering: which value is adjusted by upstart when defining an oom adjustment for a job?
[12:05] <ogra_> tvoss_, how does that matter, since we artificially set it to what we like from lightdm
[12:06] <ogra_> (which is -10 for all apps started by the session currently)
[12:07] <ogra_> tvoss_, http://bazaar.launchpad.net/~mad-wol/upstart/oom-score-stanza/revision/1280
[12:10] <ogra_> tvoss_, "/proc/%d/oom_score_adj", getpid ());
[12:10] <ogra_> it seems to also just use the /proc node
[12:11] <ogra_> (and defaults to 0 as you can see in the code)
[12:11] <ogra_> tvoss_, if you want to allow users to set it you will have to change the kernel i fear
[12:11] <tvoss_> ogra_, not users, u8, but I think I found a way
[12:11] <ogra_> u8 runs as phablet
[12:11] <ogra_> since it gets started by the session upstart process
[12:12] <ogra_> which runs as phablet as well
[12:12] <tvoss_> ogra_, yup, but we can use setcap
[12:12] <ogra_> ah, that could possibly work
[12:27] <mdeslaur> @pilot in
[12:36]  * dholbach hugs mdeslaur
[12:36]  * mdeslaur hugs dholbach
[13:09] <roadmr> hello folks! I was following the procedure to secure-boot over pxe (https://wiki.ubuntu.com/UEFI/SecureBoot-PXE-IPv6) and found what appears to be a typo in shim.efi.signed, it tries to load "grubx64.efi(", I found this by monitoring the tftp log file after it failed to load "grubx64.efi"
[13:48] <GridCube> I wonder why "users" list two times any user name, i understand that users list currently logged users to a system, so it means that my user is logged twice?
[13:54] <xnox> slangasek: ^ see roadmr message.
[13:57] <dobey> GridCube: #ubuntu is for asking for help on ubuntu. the one user listed multiple times is because of virtual terminals and such (if you have terminal windows open, for example)
[13:59] <GridCube> oh correct! dobey :D i opened a bunch of terminals and i got a bunch of my names, thanks a lot. (and sorry for using the wrong channel)
[14:19] <ice9> I want to start with Ubuntu development so where to find simple bugs to start with?
[14:25] <rbasak> ice9: try looking for bugs tagged 'bitesize'. Eg: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize&orderby=-date_last_updated&start=0
[15:09] <mardy> seb128, Laney: about the EDS integration with UOA, I just forwarded you a patch
[15:09] <seb128> mardy, I was just reading that, what did you ask to mbarnes? if it would be easy to backport the fix?
[15:10] <mardy> seb128, Laney: it's a backport of the OAuth support for calendar, to 3.8
[15:10] <mardy> seb128: yes, and he did this in a very few minutes
[15:10] <seb128> hehe
[15:10] <mardy> seb128: so I guess it's not tested, but that's up to us
[15:10] <seb128> the guy is a rockstar ;-)
[15:10] <seb128> mardy, right
[15:10] <seb128> mardy, it's too much of a diff for saucy anyway
[15:10] <seb128> mardy, but let's land early next cycle (then maybe backport it)
[15:12] <mardy> seb128: maybe we can keep it in -proposed, and give it quite some time for testing before pushing it to everyone?
[15:13] <seb128> mardy, yes, just not for saucy since we are frozen for release since yesterday
[15:13] <mardy> seb128: sure
[15:13] <seb128> mardy, but I'm keeping it on my todo for after next week
[15:13] <mardy> seb128: thanks
[15:18] <roadmr> xnox: perhaps I could file a bug about the shim problem? is lp:ubuntu/shim-signed a good place for that?
[16:06] <mdeslaur> @pilot out
[16:11] <slangasek> ev: I could kick in some time for buG #1235436, but would want pitti's and your guidance on architecture
[16:12] <ev> slangasek: happy to provide guidance, I just don't want to see it fall on the floor as I transition. It's best that more than my eyes are watching its progress.
[16:12] <slangasek> roadmr, xnox: that's no typo in shim.efi.signed; that wiki page was a bit optimistic, and assumed that we would get the fixed shim back signed from MS in a timely fashion
[16:13] <slangasek> roadmr: i.e., this is fixed in shim 0.4-0ubuntu4, but we've been waiting 2 weeks for a signature
[16:15] <slangasek> ev: so if I were to take a stab at this, I would do what I described, having whoopsie scan directly and give whoopsie an 'autoupload' config option.  Where should that option live for whoopsie? Should it reuse /etc/apport/autoreport, or would you like an /etc/whoopsie/autoreport?  Or do you disagree with having whoopsie directly handle this?
[16:15] <ev>  /etc/default/whoopsie?
[16:15] <ev> slangasek: or either of those. I'm not fussy
[16:16] <ev> though pitti and xnox discussed concerns over using /etc on touch
[16:16] <ev> since it's not writable
[16:17] <slangasek> ev: /etc/default/whoopsie has the difficulty that it's owned by the whoopsie package, so how do we configure it differently for phones vs. notphones
[16:18] <slangasek> so, probably needs to be a separate file
[16:18] <infinity> Writing to /etc at runtime is wrong even on classic UNIX systems.
[16:18] <slangasek> (and what was supposed to own that file anyway, since /etc/apport/autoreport still doesn't exist?)
[16:18] <ev> slangasek: *nods*
[16:18] <infinity> At least, I assume we're talking about runtime settings here.
[16:18] <ev> slangasek: it's created by system-settings
[16:18] <ev> but it should be already populated
[16:19] <slangasek> oh?
[16:19] <ev> we got agreement from legal on that, provided we mention it in the first use dialog
[16:19] <ev> and it should be - it's in the spec
[16:19] <infinity> Which belong in user configs or system-wide stuff in /var (or whatever crazy Android equivalent the phone is currently using)
[16:19] <xnox> ev: we don't have first use dialog.
[16:19] <ev> though no one implemented that, did they
[16:19] <xnox> yet.
[16:19] <ev> wooooo
[16:19] <slangasek> heh
[16:19] <ev> priorties
[16:19] <slangasek> so, by default we have no mention of it, which means by default we can't turn it on?
[16:20] <xnox> slangasek: ev: does that file has contents? we can bind mount it and writable, but then it's always present but has content that can be changed.
[16:20] <ev> slangasek: we should check with legal - maybe there's a way out of this
[16:20] <slangasek> xnox: to be determined
[16:20] <ev> it'd be really awful if we had it off by default
[16:20] <ev> as that pretty much guarantees it wont get used
[16:21] <slangasek> ev: I'm not going to try to circumvent the legal guidance here
[16:21] <slangasek> because I agree with it ;)
[16:21] <ev> *nods*
[16:21] <slangasek> for now, I'll focus on sorting out the backend
[16:21] <slangasek> is system-settings supposed to have a toggle for this?
[16:21] <ev> though I am curious as to why you were seeing apport-noui running if nothing was creating that file
[16:21] <ev> yes, and it does
[16:21] <ev> I wrote it
[16:21]  * ev checks on the actual phone
[16:22] <slangasek> ev: because I created the file myself for testing ;)
[16:23] <ev> oh right
[16:23] <ev> and here I was worried it was all going to hell in a handbasket
[16:23] <ev> (not that it isn't :-P)
[16:24] <ev> yup, it's there
[16:24] <ev> security and privacy -> diagnostics
[16:35] <slangasek> ev: ah, so the toggle is there, and it's selected, but it doesn't seem to control /etc/apport/autoreport since I don't have that file
[16:43] <ev> slangasek: on a call, sorry!
[16:43] <roadmr> slangasek: oh I understand, I'll wait for the next version then, rather than filing a bug.
[16:43] <roadmr> slangasek: (re: the "typo" in the shim)
[16:45] <ogra_> slangasek, so since i dont think that we will fix the ureadahead bug before release, would you be very opposed if i shipped an override upstart job for ureadahead (from lxc-android-config or ubuntu-touch-session) that mounts and unmounts debugfs at a place like like /dev/.ureadahead dynamically from pre-start/post-stop scripts ?
[16:46] <slangasek> ogra_: er, what would doing that help?
[16:46] <ogra_> slangasek, it generates proper pack files on the phone here
[16:46] <slangasek> yes, I'm opposed to it because we analyzed the bug and showed that the debugfs mount had nothing to do with the failures
[16:47] <stgraber> right, it'd generate the packs and then never use them and then generate them all over again the next boot since at the time ureadahead starts it won't find them
[16:47] <slangasek> ogra_: did the problem of /var/lib/ureadahead not being mounted before ureadahead starts get solved?
[16:47] <ogra_> stgraber, oh ? why ? they are in a rw dir
[16:48] <ogra_> stgraber, that would surely be mounted already once the upstart job fires
[16:48] <stgraber> ogra_: ureadahead starts before any of the bind-mounts are applied
[16:48] <ogra_> well it definitely works fine on my maguro with such a hacked up upstart job
[16:48] <ogra_> stgraber, ?
[16:48] <ogra_> stgraber, dont you mount them in the initrd ?
[16:48] <stgraber> no
[16:48] <ogra_> oh
[16:48] <stgraber> mountall mounts those
[16:49] <stgraber> (note, we had that very discussion at least once already ;))
[16:49] <ogra_> slangasek, nope, my job would have to start later
[16:49] <ogra_> stgraber, right, i just noticed that i had a modified start on line in my test code
[16:50]  * ogra_ would really like to get these 10sec faster boots :/
[16:50] <slangasek> certainly; but you're not going to get that unless you manage to write pack files that actually get read again
[16:51] <slangasek> and that's not something that lends itself to a quick'n'dirty change
[16:51] <ogra_> so i would need to write them to a temporary space and copy them ...
[16:51] <slangasek> /sys/kernel/debug, btw, should almost always be mounted before the local filesystems
[16:51] <slangasek> no
[16:51] <slangasek> "temporary space and copy" means that they again won't be in the right place on the next boot
[16:52] <stgraber> the real fix there is to get the initrd to mount /var/lib/ureadahead (I believe that was the conclusion of the discussion we had last time)
[16:52] <stgraber> since that's the only way to have that directory readable and writable early enough for ureadahead
[16:52] <ogra_> ok
[16:52] <cjwatson> That's also a workaround, but a better one
[16:53] <ogra_> me grumbles about the metapackage update he just runs ...
[16:53] <ogra_> I: Checking Release signature
[16:53] <ogra_> gpgv: Signature made Fri Oct 11 18:36:48 2013 CEST using DSA key ID 437D05B5
[16:53] <ogra_> gpgv: BAD signature from "Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>"
[16:53] <ogra_> i get that pertty often in recent times
[16:53] <ogra_> (a second fresh run usually works then)
[16:54] <stgraber> cjwatson: it's not pretty I agree but I can't think of a cleaner way of doing it since / is read-only and so can't possibly contain the pack files. ureadahead is meant to start before mountall so can't depend on anything mounted by mountall, therefore we need the kernel, the initrd, upstart of ureadahead itself to mount the pack file location. The least ugly option being the initrd.
[16:55] <stgraber> *or
[16:57] <cjwatson> stgraber: Clint offered the general outline of a solution in https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/523484/comments/34 which I think would be viable
[17:00] <stgraber> cjwatson: that'd mean the very early boot wouldn't benefit from ureadahead but it seems like an acceptable compromise to have a solution which works for everyone
[17:01] <stgraber> though I don't think we should attempt something like that for saucy
[17:01] <cjwatson> stgraber: ureadahead is "start on starting mountall" anyway, and not very much else runs while mountall is running; I don't think it would delay it much unless the fs containing /var/lib/ureadahead is unreasonably slow to mount
[17:02] <cjwatson> stgraber: There are probably some complexities related to ureadahead-other
[17:02] <cjwatson> stgraber: Yeah, I thought about taking a day or two and doing it, but I think it's too risky now
[17:02] <stgraber> sounds like something that should be done in early 14.04
[17:03] <cjwatson> Yep, we definitely should, that bug has dragged on way too long
[17:03] <stgraber> ogra_: http://paste.ubuntu.com/6223336/ should (untested) give you a working ureadahead and also fix the fsck flag you mentioned the other day.
[17:04] <ogra_> stgraber, awesome !
[17:04] <ogra_> i'll test that on the weekend
[17:04] <ogra_> (and take care of landing it on monday)
[17:07] <stgraber> cjwatson: I commented in the bug and milestoned for 13.11 so it hopefully ends up on a list somewhere and we don't forget about it for 14.04
[17:10] <cjwatson> stgraber: thanks
[17:17] <sarnold> infinity: no, I haven't looked at curtin 1220434 yet
[19:49] <slangasek> xnox: why the reopen of the dbus task on bug #1234731?
[20:26] <cjwatson> jdstrand: hmph, I wish I'd noticed earlier that apparmor/saucy has started pulling Python 2 back into standard, when raring had relegated it to desktop
[20:26] <jdstrand> why is it doing that?
[20:26] <cjwatson> For the sake of one script that would probably take five minutes to port
[20:26] <jdstrand> we wrote everything for python3
[20:26] <cjwatson> /usr/sbin/apparmor_status
[20:26] <cjwatson> #!/usr/bin/python
[20:26] <jdstrand> that should be py3
[20:26] <jdstrand> hrm
[20:27] <cjwatson> certainly doesn't seem to require anything 2-specific
[20:27] <jdstrand> yeah, that script is bi-lingual no less
[20:28] <jdstrand> we did it that way intentionally
[20:28] <jdstrand> but obviously got part of it wrong
[20:30] <jdstrand> cjwatson: it is a one character fix that I would be happy to upload
[20:30] <jdstrand> of course, I'd probably need a landing request and everythign else
[20:31] <mdeslaur> lol @ bilingual python
[20:56] <infinity> jdstrand: I'm all for the one-charater fix and no more python2.7 in standard, BTW.
[21:16] <linux> It will be great if ubuntu have on login option to choose effects ccsm like
[21:16] <linux> minimum , medium , maximum with all posibilities like fire , wather , cube ... etc that will be great in unity for new users like girl and boys
[23:39] <Noskcaj> There's spam on http://qa.ubuntuwire.com/bugs/rcbugs/ again
[23:40] <Noskcaj> Also, is there any chance we could sync libtar? it fixes a CVE and nothing else
[23:44] <slangasek> Noskcaj: libtar would be allowed in if someone synced it, yes
[23:55] <Noskcaj> slangasek: Is there any chance you cpuld, or at least file a bug. I'm not able to do anything other than irc curretly