=== robert__ is now known as nudtrobert === wedgwood is now known as Guest48850 === jrib is now known as Guest10239 === henrix_ is now known as henrix [04:43] Godo morning [04:43] infinity: can do, yes [04:44] 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] infinity: btw, I synced postgresql-9.1, that should build on arm64 now [04:52] pitti: \o/ [04:52] pitti: Will look shortly. [05:10] infinity: meh, still no export on https://translations.launchpad.net/ubuntu/saucy/+language-packs [05:10] wgrant, StevenK: ^ could you please check whether this is running, or something went wrong? [05:11] 2013-10-10 11:31:31 ERROR Uncaught exception while exporting PO file 2444794 [05:11] argh [05:11] DB thing, it seems [05:11] apparently the delta packs run like clockwork, so so PO file 2444794 apparently hasn't been touched for a while [05:12] Nah, nothing particular to that pofile, I don't think [05:12] Just a DB glitch [05:12] 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] 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] wgrant: it could have very well been that [05:13] but time is more critical now with the final release around the cordner [05:13] corner [05:14] IIRC saucy happens tue/thu [05:14] Might have to kick a special one off now [05:14] that would be good, so that we can build them Monday morning (or I kick them off on Sunday) [05:16] 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] 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] pitti: Nah, it's all good. [05:18] pitti: Bonus points if it actually builds. [05:18] 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] infinity: in 9.3.1 I saw a log entry "add arm64 s_lock code", we might want to backport that [05:19] Other than random segfaults and, of course, compilers needing to be ported, most stuff has Just Worked, so I have high hopes. [05:20] 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] sarnold: Have you looked at #1220434? Looks like the last MIR of the cycle. [05:23] infinity: yes, 9.3 will be in 14.04 [05:24] pitti: Kay. So, if this 9.1 build works at all, we win. [05:24] 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] 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] (currently hurd and kfreebsd) [05:32] pitti: I meant the verifying the fix for the bug [05:33] bdmurray: it's certainly not verified until it gets tested with the actual binaries from -proposed [05:33] (guard against weird build failures, etc.) [05:39] infinity: OOI, did you find out why gid=tty now magically works? [05:39] (or does it?) [05:40] wgrant: just to avoid misunderstandings, did you kick off a new export now? [05:40] pitti: I poked ops about it, haven't got a response yet, will repoke once UK appears I guess. [05:40] wgrant: ah, thanks [05:40] hm, why is consolekit still being installed by default [05:41] * pitti checks germinate [05:43] pitti: It works fine for me. I can't figure out what WASN'T working before I rebooted. [05:45] postgres (27651): /proc/27651/oom_adj is deprecated, please use /proc/27651/oom_score_adj instead. [05:45] pitti: Yell at your upstream about that. :P [05:45] pitti: This is 2013, I shouldn't still be seeing those messages. [05:46] pitti: (Build went fine on arm64, though) [05:47] wow, already built? [05:47] it takes some 10 minutes with all the tests even on my machine [05:47] ah, time flies fast this morning [05:48] yay [05:48] infinity: upstream is on BSD :) [05:48] infinity: yeah, I've got a bug for oom_adj [05:50] 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] infinity: (btw, I uploaded umockdev earlier) [05:53] pitti: Thanks. [05:54] pitti: You apparently have fans, because mir build-depends on it. [05:54] heh, yeah [05:55] I could actually also make upower build-dep on it, now that we have it in Debian, too [06:15] pitti: component-mismatches was your code, right? [06:15] infinity: I wrote the SVG/html report on top of it [06:15] http://people.canonical.com/~ubuntu-archive/component-mismatches.svg [06:15] not c-m itself [06:15] I thought that was part of LP? [06:16] 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] ah no, that was NBS [06:17] Oh. [06:17] I bet it's because germinate's still crashing on pepo. [06:17] wgrant: Did anyone look into that? [06:18] infinity: Colin said he might, but I suspect he was a bit busy. [06:32] 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] i have filed a bug here: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1238446 [06:33] Ubuntu bug 1238446 in ubiquity (Ubuntu) "Ubiquity is stuck after "Prepare" step" [Undecided,New] [06:33] could someone help me debug, or populate the bug report and make it more useful? thanks [06:59] good morning [07:02] 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] i have filed a bug here: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1238446 [07:02] Ubuntu bug 1238446 in ubiquity (Ubuntu) "Ubiquity is stuck after "Prepare" step" [Undecided,New] [07:06] 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] Guest3903, but this is just me doing guesswork - I'm not an expert [07:07] dholbach: i am still on the livecd, so if you can tell me where, i can try [07:08] Guest3903, also in /var/log - like the other log files you added [07:08] Attached /var/log/casper.log [07:08] i dont' see an upstart/ubiquity.log [07:15] oSoMoN, happy birthday! :) [07:16] 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] Guest3903: What filesystem is/was on that partition? [07:22] Guest3903: Was it XFS? [07:23] no [07:23] infinity: there are 4 partitions, all of them are either vfat or NTFS [07:24] infinity: just added that info to the bug report [07:25] Fun. [07:26] yea, the XFS errors confused me too [07:26] Oh, there isn't even an sda4 (well, it probably exists as an extended container) [07:26] The plot thickens. [07:26] well, does GPT even have concept of an extended partition? [07:28] infinity: also, curiously, parted crashes while trying to print the partition table [07:28] Oh, this is GPT? I missed that on the first. [07:28] pass... [07:28] Maybe GPT doesn't deal well with having holes in the numbering scheme? [07:30] Guest3903: What does /proc/partitions have to say about it? [07:31] infinity: udpated report [07:33] infinity: sda4 seems to be partition of unknown type with flag "msft-reserved" -- unlikely to be a hole [07:34] 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? === CyclicFlux is now known as Guest29308 [07:35] 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] infinity: "in an hour or two" phhhh [07:35] Or right now. :P [07:35] * xnox yawns [07:36] infinity: yes, i'd rather help fix it if i can :) [07:36] Guest3903: i don't see anything obvious. And indeed it's strange that gpt partition table gives you head-aches. [07:37] 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] Guest3903: all of them are unmounted right? [07:38] xnox: yes, "mount" does not show any sdaX partitions mounted [07:39] Guest3903: ok. And what are the labes on /dev/sda2 and /dev/sda1 ? [07:39] *labels [07:39] xnox: sda1 is "SONSYS" and sda2 is "Recovery", type vfat and ntfs respectively [07:40] dholbach: thanks :) [07:40] 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] 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] 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] xnox: and a quick question: is there a way to make ubiquity do more verbose logging during the user config? [07:44] xnox: both look like EFI, though it's impossible: https://dpaste.de/ADXx [07:44] xnox: i think sda1 is ESP for sda2 "recovery" OS, and sda3 is ESP for sda4/sda5 "windows" OS [07:44] 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] 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] if i power on using the power button, windows starts as usual [07:45] jderose: yes, more verbose mode would be, I still think "debug-ubiquity" at kernel cmdline, https://wiki.ubuntu.com/DesktopCDOptions [07:46] 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] jderose: oh right, yeah. [07:46] jderose: you can't delete a user with active pam session. [07:47] jderose: we usually hang out on #ubuntu-installer, but I guess we can continue here. [07:47] xnox: so bits of the user config are running as the OEM user then? [07:48] 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] xnox: any more useful info i can provide/ [07:50] Guest3903: what's the output of "$ sudo parted -l" ? [07:51] xnox: https://dpaste.de/7vqi same error pretty much [07:51] 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] 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] *not user but session. [07:52] 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] 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] 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] Guest3903: then somehow reboot or check that windows still works. [07:54] but kde partition manager seems to understand the labels fine, xnox.. so it could be a partition thing? [07:54] Guest3903: then boot up the 13.10 live cd and see what's there. [07:54] *parted thing [07:54] Guest3903: hm, we do have old parted. [07:55] sounds like a regression still, because 13.04 installer worked on the same setup. i should probably try redoing that to test [07:55] Guest3903: what does kde partitioner manager say? maybe screenshot, or copy strings? [07:55] xnox: kde partition manager screenshot is in the report [07:55] xnox: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1238446/comments/13 [07:55] Ubuntu bug 1238446 in ubiquity (Ubuntu) "Ubiquity is stuck after "Prepare" step" [Undecided,Confirmed] [07:55] 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] argh. https://launchpadlibrarian.net/153474755/snapshot1.png [07:57] xnox: i don't have the installed system any more, sorry.. i could try running the 13.04 installer again i guess [07:57] Guest3903: strange. [07:57] 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] 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] jderose: /var/log/installer/oem-config i think =/ or look at other files under /var/log/installer/* [08:01] jderose: there should also be /var/log/upstart/[oem-config|ubiquity].log [08:05] xnox: upstart/ubiquity.log - http://paste.ubuntu.com/6221392/ [08:05] not sure if that ValueError is related or not [08:06] i don't think so. [08:06] it's probably from the "normal/first install" [08:06] not from oem-config run. [08:08] whoa, the parted in 13.10 is 3 years old! the lates t release was also in 2012 .. any idea why i [08:09] any idea why we have such an old release? [08:10] 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] xnox: ah i see [08:11] 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] can't think of anything else useful to do :) [08:12] apart from booting to windows and changing the partition labels as you suggested [08:13] Guest3903: or change the labels using KDE partition manager & reboot the installer again. [08:13] but parted is not tripping up on the labels, is it? it's tripping up on the device names right [08:14] no, device names are fine. [08:14] i think. [08:15] 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] 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:15] Ubuntu bug 1231166 in ubiquity (Ubuntu Saucy) "oem config user remains the default user after full oem installation" [High,Triaged] [08:16] jderose: thanks. [08:16] xnox: well, makes me feel a little better about me struggling to find my way around ubiquity :P [08:16] infinity: bug #624888 [08:16] bug 624888 in ubiquity (Ubuntu) "if oem user is logged in more than one tty when oem-config is set up, the oem user is never completely removed" [Undecided,Fix released] https://launchpad.net/bugs/624888 [08:20] xnox: Did the s/deluser/userdel/ thing get reverted, or does userdel now shut you down too? [08:21] infinity: i looked at that earlier today... currently it's using userdel, in oem-config-wrapper i believe is the script [08:22] infinity: does it know about systemd? [08:22] infinity: well logind. [08:24] 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] xnox: Effed if I know. [08:26] xnox: uderdel is pretty dumb, it's not meant to know about much at all. [08:26] xnox: Does userdel perhaps just need a '-f' to fix the bug? [08:26] it's being called with `userdel --force --remove oem` [08:27] jderose: || true [08:27] I guess force needs to be taught to force harder... [08:27] well, yeah, that bit too :P [08:27] 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] 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] xnox: infinity: thanks for your help on this! much thanks from System76 :D === kubuntu is now known as Guest42952 [08:31] xnox: i was wrong, 13.04 ubiquity has the exact same problem. it's stuck after "preparing" [08:31] and parted also errors out with the same message [08:31] and yet again kde partition manager works perfectly [08:33] Guest42952: Can you try relabelling to test xnox's theory that the hang is due to multibyte chars? [08:33] 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] well kde partition manager is not allowing me to change labels [08:35] but if both blkid and kde partition manager can read the labels fine, it has to be a Parted issue, right? [08:35] I'm not convinced that parted's problem is the labels just yet. [08:38] seb128: bonjour, ça va ? [08:38] seb128: did you already talk to the release team about 3.10.1 bits next Monday? [08:38] pitti, salut, oui, et toi ? [08:38] seb128: je vais très bien, merci [08:38] pitti, no, I planned to just SRU those, we don't have so much 3.10 anyway [08:39] seb128: ok, then I perhaps upload gnome bug 709223 as a patch right now [08:39] Gnome bug 709223 in general "problem with toggleref thread-safety" [Normal,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=709223 [08:39] seb128: I'll release pygobject 3.10.1 on Monday with that (and a memleak fix) [08:39] pitti, if you want it in the release, today seems a better bet than monday in any case [08:39] who knows we might not get respins after monday [08:40] Monkeys may fly, too. [08:40] (But I appreciate the enthusiasm and confidence) [08:40] oh, I thought it was the pigs who can fly, but perhaps that doesn't work in Canada? :-) [08:41] pitti: britain is a funny place. [08:41] infinity: or not yet? [08:41] =) [08:41] in Canada they say "Adams can sleep" [08:41] pitti: It is, and the monkeys traditionally do something slightly less tasteful. [08:41] xnox: Not in London until Sunday. [08:41] pitti: The Adams family, tudutudutudu. [08:41] infinity: anything else i can provide to help? [08:41] oh those mental pictures *off*, *off*! [08:42] Guest42952: Not sure, TBH. Hence why I pointed you at xnox. Not my area of expertise. :) [08:42] fair enough. xnox, anything else that could help debug/ [08:42] not really no. [08:45] ok. thanks for all the help, xnox, infinity! [08:46] pitti, pin [08:46] g even [08:46] hey tvoss_ [08:48] 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] pitti, mind having a look here: https://bugs.launchpad.net/mir/+bug/1238417 [08:51] Ubuntu bug 1238417 in Mir "Unity does not process events from evdev device created before unity is restarted (autopilot tests)" [Critical,Confirmed] [08:51] tvoss_: queueing === iahmad is now known as iahmad|afk [08:52] pitti, ack and thx [08:58] xnox: so what were you moving to post-stop? [08:59] jderose: i am investigating at the moment. [09:00] xnox: please let me know if there is anything you want me to try/test [09:00] jderose: there is also kernel cmd line option "debug-oem-config" in addition to "debug-ubiquity" [09:00] ah, okay, i'll try that too. my VM is again submitting to my will, so i'm ready to go [09:02] xnox: is there any use in using debug-oem-config and debug-ubiquity together, or should I just use debug-oem-config? === Nigel_ is now known as G [09:06] i think you just need "debug-oem-config" but debug-ubiquity will not hurt. [09:08] okay, i just tried without the "|| true" bit, hopefully the failure will log something useful... [09:13] xnox: attached another /var/log tarball - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1231166 [09:13] Ubuntu bug 1231166 in ubiquity (Ubuntu Saucy) "oem config user remains the default user after full oem installation" [High,Triaged] [09:14] jderose: i think that should work: http://paste.ubuntu.com/6221565/ [09:15] jderose: so, "before shipping to use" [09:15] jderose: modify /etc/init/oem-config.conf to include the bits at the end from "post-start script ... end script" [09:15] jderose: then reboot, do end user config, and observe that oem-config user is removed. [09:15] xnox: okay, trying now... [09:24] xnox: yup, that fixes it! [09:25] oem isn't in passwd or group, and /home/oem has been removed [09:25] user login works as expected [09:26] jderose: good. [09:26] jderose: we do keep ubuntuone package for the end user configuration. but it's a separate package from oem-config, FYI. [09:27] 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] but we'll leave it in place, btw [09:29] 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] Ubuntu bug 1237694 in System76 "Installation fails without Internet" [Critical,Triaged] [09:29] jderose: i'm working on bug #1226912 at the moment [09:29] bug 1226912 in ubiquity (Ubuntu Saucy) "ubiquity starts but does not appear" [High,Confirmed] https://launchpad.net/bugs/1226912 [09:30] (also, BTW, i'm not 100% sure 2.15.21 was what introduced that regression) [09:30] hm. [09:31] 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] jderose: no, if you press Esc at boot splash and select "try ubuntu without changing your computer" text menu item. [09:32] jderose: or e.g. if you select that on an UEFI machine. [09:32] gotcha [09:32] 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:32] bug 1237248 in postgresql-9.1 (Ubuntu Raring) "New upstream microreleases 9.1.10, 8.4.18" [Undecided,New] https://launchpad.net/bugs/1237248 [09:45] 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] jderose: no worries. Thank you. [10:12] 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] pitti: Yeahp, thanks. [10:14] 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] infinity: correct, the whoopsie/daisy parts stay === tkamppeter_ is now known as tkamppeter [10:14] infinity: same procedure as last release (and the ones before..) [10:15] 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] infinity: before whoopsie we completely disabled apport, to avoid the CPU overhead [10:16] pitti: No, I meant during a dev cycle, we didn't re-enable the browsery bits once. [10:16] then we had that rather long and heated discussion, I admitted defeat, and now it's done like that ever since [10:16] infinity: we usually didn't do before alpha-2 [10:16] Anyhow, no big deal. Current situation works. Thanks for the upload. [10:16] but it's a matter of some gut feeling "it's time now" === _salem is now known as salem_ [10:33] slangasek, pitti, others: I'm finding it hard to find time for bug 1235436. Is anyone available to help out? [10:33] bug 1235436 in apport (Ubuntu) "/etc/init/apport-noui.conf is non-functional on the phone" [Critical,New] https://launchpad.net/bugs/1235436 [10:40] 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] ev: this is similar to the timezone changes not persisting across ro-system upgrades bug. [10:41] ev: how is /etc/init/apport-noui.conf created at the moment? [10:41] xnox: it's shipped as part of apport [10:41] sorry, i mean the /etc/apport/autoreport. [10:41] that shipped as well? [10:42] ev: i think will be SRUing that bug report. [10:43] xnox: oh dear. We need to add that to the writable paths - it's created by system-settings [10:43] it's not in the current images at least [10:43] so, another victim of our hacked-up /etc? :-/ [10:44] 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] 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] xnox: can you please add your thoughts to the bug so we're tracking this in a single place? [10:45] ev: ok. [10:45] thanks, just trying to manage calls and chatting here at the same time [10:45] ev: and then there is the race to fix of multiple apports tracing the same thing =))))) [10:45] I'm going to lose some details :) [10:46] xnox: nah, let's not automatically modify conffiles [10:46] pitti: hm, good point. [10:46] (sorry, just half a brain cell here either, it seems today is the day when I get bombarded with "OMGcanyoulookintobugXXXXX" requests) [10:46] ev: right after I make ubiquity to stop spinning in an infinite loop. [10:46] pitti: ditto =) [10:47] but please let's not do any knee-jerk addition of files o writable-files [10:47] the current implementation for handling files there is quite frankly rather broken and not maintaintable at all [10:48] ev: I'd rather move the file to /lib or something [10:48] ev: or an alternative lookup path to /userdata, or whichever path we actually have left for putting data into [10:48] as we essentially said "/etc/ is not for configuration any more", I guess /userdata is the logical replacement [10:54] pitti: I honestly don't mind where we put it [10:54] definitely deferring to your better judgement on this :) === salem_ is now known as _salem === MacSlow is now known as MacSlow|lunch [11:14] pitti: I'm emptying out the stragglers in the NEW queue, and there's an oddity there from you. [11:15] 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] pitti: So, which is it? :) [11:15] s/cause/caught/ === Guest10239 is now known as jrib [11:19] infinity: I think the reupload was an error, I probably just forgot to rm it from my local "to rebuild" folder, sorry [11:42] pitti, wondering: which value is adjusted by upstart when defining an oom adjustment for a job? === iahmad|afk is now known as iahmad [12:05] tvoss_, how does that matter, since we artificially set it to what we like from lightdm [12:06] (which is -10 for all apps started by the session currently) [12:07] tvoss_, http://bazaar.launchpad.net/~mad-wol/upstart/oom-score-stanza/revision/1280 === MacSlow|lunch is now known as MacSlow [12:10] tvoss_, "/proc/%d/oom_score_adj", getpid ()); [12:10] it seems to also just use the /proc node [12:11] (and defaults to 0 as you can see in the code) [12:11] tvoss_, if you want to allow users to set it you will have to change the kernel i fear [12:11] ogra_, not users, u8, but I think I found a way [12:11] u8 runs as phablet [12:11] since it gets started by the session upstart process [12:12] which runs as phablet as well [12:12] ogra_, yup, but we can use setcap [12:12] ah, that could possibly work === _salem is now known as salem_ [12:27] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 2 released | Archive: frozen, final freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur [12:36] * dholbach hugs mdeslaur [12:36] * mdeslaur hugs dholbach [13:09] 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] 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] slangasek: ^ see roadmr message. [13:57] 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] 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] I want to start with Ubuntu development so where to find simple bugs to start with? [14:25] ice9: try looking for bugs tagged 'bitesize'. Eg: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize&orderby=-date_last_updated&start=0 === doko_ is now known as doko [15:09] seb128, Laney: about the EDS integration with UOA, I just forwarded you a patch [15:09] mardy, I was just reading that, what did you ask to mbarnes? if it would be easy to backport the fix? [15:10] seb128, Laney: it's a backport of the OAuth support for calendar, to 3.8 [15:10] seb128: yes, and he did this in a very few minutes [15:10] hehe [15:10] seb128: so I guess it's not tested, but that's up to us [15:10] the guy is a rockstar ;-) [15:10] mardy, right [15:10] mardy, it's too much of a diff for saucy anyway [15:10] mardy, but let's land early next cycle (then maybe backport it) [15:12] seb128: maybe we can keep it in -proposed, and give it quite some time for testing before pushing it to everyone? [15:13] mardy, yes, just not for saucy since we are frozen for release since yesterday [15:13] seb128: sure [15:13] mardy, but I'm keeping it on my todo for after next week [15:13] seb128: thanks [15:18] xnox: perhaps I could file a bug about the shim problem? is lp:ubuntu/shim-signed a good place for that? === wedgwood_ is now known as wedgwood [16:06] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 2 released | Archive: frozen, final freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [16:11] ev: I could kick in some time for buG #1235436, but would want pitti's and your guidance on architecture [16:11] bug 1235436 in apport (Ubuntu) "/etc/init/apport-noui.conf is non-functional on the phone" [Critical,New] https://launchpad.net/bugs/1235436 [16:12] 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] 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] roadmr: i.e., this is fixed in shim 0.4-0ubuntu4, but we've been waiting 2 weeks for a signature [16:15] 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] /etc/default/whoopsie? [16:15] slangasek: or either of those. I'm not fussy === dpm is now known as dpm-afk [16:16] though pitti and xnox discussed concerns over using /etc on touch [16:16] since it's not writable [16:17] 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] so, probably needs to be a separate file [16:18] Writing to /etc at runtime is wrong even on classic UNIX systems. [16:18] (and what was supposed to own that file anyway, since /etc/apport/autoreport still doesn't exist?) [16:18] slangasek: *nods* [16:18] At least, I assume we're talking about runtime settings here. [16:18] slangasek: it's created by system-settings [16:18] but it should be already populated [16:19] oh? [16:19] we got agreement from legal on that, provided we mention it in the first use dialog [16:19] and it should be - it's in the spec [16:19] Which belong in user configs or system-wide stuff in /var (or whatever crazy Android equivalent the phone is currently using) [16:19] ev: we don't have first use dialog. [16:19] though no one implemented that, did they [16:19] yet. [16:19] wooooo [16:19] heh [16:19] priorties [16:19] so, by default we have no mention of it, which means by default we can't turn it on? [16:20] 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] slangasek: we should check with legal - maybe there's a way out of this [16:20] xnox: to be determined [16:20] it'd be really awful if we had it off by default [16:20] as that pretty much guarantees it wont get used [16:21] ev: I'm not going to try to circumvent the legal guidance here [16:21]