[06:25] <fishor> hello all, i currently rewriting gnome-sound-recorder and i got one idea which i wont to discuss with some one. I wont to remove all File parts from this program, so it will just save all records to some folder. Logical next step will be to add some sort of file browser. I do not see any sense to build a new one, i think it is best way to integrate it to nautilus or to use some sort of nautilus libs
[06:26] <fishor> if i do it, i will autoamtically got everey thing i need: search, send file... and so on
[06:27] <fishor> i need some comments or critics on it
[06:27] <diwic> fishor, hi, have you tried talking to GNOME upstream about it?
[06:28] <diwic> fishor, Ubuntu is unlikely to take a big change of gnome-sound-recorder if it's not coming from Gnome.
[06:29] <fishor> well, there is no one who cares about it
[06:29] <fishor> this project is dead
[06:29] <fishor> i talked about it on gnome-media list
[06:30] <fishor> one persen tried to start it from scratch, but filed due time
[06:31] <diwic> fishor, okay...
[06:31] <diwic> fishor, then you seem to have tried, at least
[06:32] <fishor> diwic, currently i have recorder which works with ubuntu 13.04 and works with gstreamer-1.0
[06:33] <fishor> gnome-recored installed on 13.04 is not working at all
[06:34] <diwic> fishor, have you submitted those changes (transition from gstreamer 0.10 to 1.0) to upstream?
[06:37] <fishor> diwic, i tried, but it was decided to suspend gnome-media. transition to gst-1.0 affects complete packet and makes most of it useless
[06:38] <dholbach> good morning
[06:38] <fishor> only good way was to split the packet and make gnome-recorder stand alone project
[06:38] <diwic> fishor, interesting
[06:38] <fishor> for example gst-mixer and profiles wont work with gst-1.0
[06:40] <fishor> diwic, here is the source of my fork https://github.com/olerem/gnome-recorder
[06:42] <diwic> fishor, I hope you manage to get it into distributions, that might be the biggest challenge
[06:44] <fishor> i know...
[08:03] <Laney> cjwatson: deduplicate-packages> haha, nice work
[08:04] <seb128> Laney, what is deduplicate-packages?
[08:04] <Laney> wasn't aware of the speed differences there :-)
[08:04] <Laney> seb128: something the transition tracker uses
[08:40] <xnox> cjwatson: imported lp:click-package into readthedocs to automatically build documentation from the trunk branch =) https://click-packages.readthedocs.org/en/latest/
[08:47] <seb128> !ops
[08:47] <seb128> ups, not really an emergency
[08:48] <seb128> but could any op block that guy who keeps exit/join? (he's on #ubuntu-mir/touch/unity as well at least)
[09:02] <xnox> seb128: such requests usually go to #ubuntu-irc channel where there are also various freenode ops.
[09:04] <seb128> xnox, thanks, asked there
[09:17] <cjwatson> xnox: Please remove that; I'd already created https://click-package.readthedocs.org/en/latest/
[09:17] <cjwatson> xnox: Which actually matches the project name ;-)
[09:18] <xnox> cjwatson: oh cool. My google foo failed me. Is it linked from somewhere?
[09:18] <cjwatson> Not sure
[09:18] <cjwatson> xnox: It's linked from https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-click-package
[09:19] <xnox> cjwatson: I was hoping for a link from https://launchpad.net/click-package =)
[09:19] <xnox> e.g. Homepage / Documentation or whatever URLs launchpad can offer to display =)
[09:19] <xnox> cjwatson: removed from readthedocs.
[09:20] <cjwatson> xnox: I think just the description is probably better, since LP is the home page.  Thanks
[09:20] <cjwatson> And thanks for the effort, even if you were late to the party ;-)
[09:21] <xnox> cjwatson: hehe =) was reading the spec, to see how the app-containment (apparmor) policies could be integrated.
[09:21] <xnox> i gather it will need to be some kind of a hook, but not sure.
[09:24] <cjwatson> Yeah, I'm not sure the hooks spec is flexible enough for that yet, since it wouldn't necessarily correspond to a separate file in the package, just manifest contents
[09:33] <xnox> cjwatson: well, sbeattie is after a json manifest with keywords (of what is allowed/not-allowed). I simply handed over everything that happened during copenhagen's dh_appcontainment session. About integration with click packages, I pointed to talk with you about it =))))
[09:34] <dpm> hey all, could an archive admin have a look at uploading qreator on https://launchpad.net/ubuntu/saucy/+queue ? Thanks!
[09:34] <xnox> the blueprint got postponed around raring's FF
[09:35] <cjwatson> xnox: every click-package has a manifest.json, and I already said to the security team that they should just define a subtree of it
[09:38] <xnox> thanks.
[09:38] <cjwatson> xnox: What I haven't worked out yet is exactly what needs to be run after each click package is unpacked; I'd much rather that be a system hook defined by apparmor or whatever than something hardwired into click-package itself
[09:40] <xnox> cjwatson: last I heard, we'd want upstart user-session to launch all apps and it will be upstart that will load up the apparmor profile(s) to launch an app.
[09:40] <cjwatson> OK, which leaves the remaining question of how to tell upstart what to launch
[09:41] <cjwatson> We don't actually have a defined "here is your entry point" in click-package yet *cough*
[09:41] <xnox> yeah... and i guess api to click-packages to query: apps & it's manifest.
[09:41] <cjwatson> If needed
[09:42] <cjwatson> I'd prefer to do things using a hook that attaches each installed app to upstart
[09:42] <cjwatson> Though I wonder if that means I need to think about hooks based on the user's home directory - hmm
[09:42] <xnox> cjwatson: well the apps should somehow appear in the search / dash / home screens - which are all kind of scopes. I was expecting there will be "unity" hook that gets triggered on app install, and then displays launchers where it needs in the UI.
[09:43] <cjwatson> Definitely need to hammer out the exact details there
[09:43] <cjwatson> Because there are interesting interactions with requirements for per-user app installation
[09:43] <xnox> (not sure how that translates to command-line and manually launching apps - something like xdg-open but rather unity-open ?!)
[10:10] <ev> cjwatson: mornin'. Could you please approve my post to ubuntu-devel-announce?
[10:12] <cjwatson> ev: done
[10:12] <ev> cheers!
[10:13] <ev> for those of you who don't subscribe to ubuntu-devel-announce, we've opened up access to https://errors.ubuntu.com: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-May/001039.html
[10:14] <cjwatson> For those of you who don't subscribe to ubuntu-devel-announce, why not? :-)
[10:15] <cjwatson> chrisccoulson: http://hg.mozilla.org/mozilla-central/rev/489ab986ea69 seems to be enough to fix the firefox build on powerpc.
[10:15] <jacobw> My mailbox is big enough as it is :)
[10:15] <cjwatson> chrisccoulson: Or at least it makes "make -j4 -C /home/cjwatson/firefox-22.0~b3+build1/./obj-powerpc-linux-gnu" pass.
[10:16] <ev> cjwatson: :D
[10:21] <chrisccoulson> cjwatson, excellent, thanks for testing that. if i add you to https://launchpad.net/~mozillateam , do you want to commit that to lp:firefox/beta? :)
[10:21] <cjwatson> Can I do that and then immediately remove myself from the team? ;-)
[10:21] <chrisccoulson> cjwatson, if you like ;)
[10:22] <infinity> ev: Yay on the errors NDA coming to fruition.
[10:22] <ev> inknowright
[10:22] <cjwatson> Then sure.  Wouldn't want to promise any actual ongoing activity ...
[10:22] <chrisccoulson> heh :)
[10:22] <infinity> ev: Someone might want to make the oauth for that page check if I'm already in groups that allow me access and say "you don't need to use this form, doofus".
[10:22] <cjwatson> Just that branch?
[10:22] <jdstrand> xnox, cjwatson: upstart will be used to launch an app, but because these are part of user sessions, upstart will be running as non-root and cannot load the policy into the kernel. upstart will be used to change into the profile, which does not need root
[10:22] <ev> infinity: I'll talk to Neil M about that
[10:23] <cjwatson> jdstrand: Right, so we still need a rootly hook to load the policy?
[10:23] <jdstrand> cjwatson: exactly
[10:23] <infinity> ev: All in all, awesome news, though.  I hope people read it in the "we have to do this, because sensitive data" light, and don't tear it apart as us being secretive or some silliness.
[10:23] <jdstrand> for handling loading policy before a reboot (just like we talked about at the sprint)
[10:24] <cjwatson> jdstrand: We were talking about a non-root "software" user to unpack packages at various points.  I wonder whether that's more trouble than it's worth, because we'd only be able to use it for the unpack, not for hooks.
[10:24] <ev> infinity: yeah, I originally wrote it fairly defensively, but EmilyMaher helped me turn it into a positive thing. I really like the idea that it's effectively a contract between the people signing it and the users.
[10:24] <cjwatson> I guess we could, but click-install would need to know to drop privileges.
[10:24] <ev> A way of codifying the users' expectations
[10:25] <infinity> ev: I certainly don't read any obvious evil in it, so good job on the writing and editing.
[10:25] <jdstrand> cjwatson: right, mdeslaur and I both feel that the 'software' user is valuable and safer-- everything except this one hook chould be able to run as it
[10:25] <cjwatson> jdstrand: I think in practice many hooks would need root.
[10:26] <jdstrand> cjwatson: have other hooks been identified?
[10:26] <cjwatson> jdstrand: Since they will in general involve symlinking files into root-owned directories.
[10:26] <cjwatson> jdstrand: Not specifically
[10:26] <jdstrand> what directories would we be symlinking into?
[10:26] <cjwatson> But "software" is only used by click-install, so I find it unlikely that it will be able to do much of any interest if other hooks are identified
[10:27] <cjwatson> My working example would be something like a Unity scope
[10:27] <cjwatson> Not sure if that's a good example, but for the sake of argument
[10:27] <cjwatson> In any case, I don't want to put configuration in hooks that says which user they run as, and I don't want to special-case your hook
[10:27] <cjwatson> So IMO either all hooks run as root or none of them do
[10:27] <jdstrand> I had assumed that things like the /usr/share/... problem would be solved in other non-rootly ways
[10:28] <cjwatson> Click packages don't get to control any hook code - that's all shipped in system packages
[10:28] <cjwatson> So I don't see this as a particular problem
[10:28] <jdstrand> for example, I figured that the apparmor profile wouldn't live in /etc/apparmor.d, but somewhere in /opt
[10:28] <jdstrand> and apparmor would have to understand how to find the profile
[10:28] <cjwatson> I think that's a big assumption, because it will often be inconvenient to change system packages to iterate over a bunch of directories
[10:29] <cjwatson> I think it will be more sensible in the long run to have the click-package design integrate with system packages in a low-effort way, rather than requiring a bunch of moderately invasive patches that people will get wrong
[10:29] <jdstrand> I was assuming that because I thought I read that as a requirement (I thought that was part of the whole "must be in /opt" part of the specification
[10:30] <cjwatson> The app itself must be in /opt, but that doesn't preclude system hooks being poked to create symlinks/copies/whatever elsewhere
[10:31] <cjwatson> Heh, I was about to go and write a to-do item for the privilege drop, and found I already had:
[10:31] <cjwatson>  * drop privileges to software user when unpacking; retain root for hook execution
[10:31] <jdstrand> cjwatson: yes, we discussed this at the sprint and you agreed to it :)
[10:31] <cjwatson> Memory like a thing with holes in.  That's why I write to-do lists
[10:31] <jdstrand> hehe :)
[10:32] <cjwatson> I might call it something else though, probably something like clickpkg
[10:33] <jdstrand> so, maybe there are other cases for other root-hooks, that's 'fine' I guess. from my pov, devs control everything in the click package. there will be limited review of these, therefore we should have anything that they they can control happen as non-root
[10:33] <cjwatson> Indeed, I entirely agree on that
[10:33] <cjwatson> Hooks are absolutely not under the control of the click package
[10:33]  * jdstrand nods
[10:34] <jdstrand> ok, it sounds like we are on the same page then
[10:34] <jdstrand> I was just reiterating the priv drop is a good idea :)
[10:34] <cjwatson> jdstrand: https://click-package.readthedocs.org/en/latest/hooks.html is my current skeletal spec FWIW
[10:34] <jdstrand> mdz: fyi ^
[10:34] <jdstrand> meh
[10:34] <jdstrand> mdz: sorry
[10:34] <jdstrand> mdeslaur: ^
[10:35] <cjwatson> I should probably post a call for real-world examples
[10:38]  * jdstrand imagines a flaw in font or icon processing software that can do code exec and a dev adding this to the click package such that the root-run trigger escalates privs
[10:39] <cjwatson> While it's possible, that seems like the sort of thing that would have plenty of other (perhaps more profitable) avenues of attack
[10:39] <cjwatson> Maybe hooks should be confined?
[10:40] <cjwatson> Just with apparmor rather than by dropping to non-root
[10:40] <jdstrand> re possible> I imagine what I described would be used to jailbreak
[10:40] <jdstrand> confining root-run hooks with apparmor seems plausible
[10:41] <jdstrand> those hooks should be extremely well defined
[10:41] <jdstrand> and therefore easy to profile
[10:41] <cjwatson> Yep
[10:44] <jdstrand> seccomp would also be useful there
[10:45] <jdstrand> not sure what language was planning on being used to implement the hooks
[10:45] <mitya57> ev: \o/
[10:46] <ev> :D
[10:46] <cjwatson> jdstrand: The Exec interface I think has to be subprocess, since (if it's useful at all) it will probably involve running update-foo programs shipped with the package itself
[10:46] <cjwatson> So I wasn't intending to nominate an implementation language there
[10:46] <ev> just working on getting the necessary change to https://errors.ubuntu.com deployed
[10:46] <cjwatson> chrisccoulson: Do you care which directory the patch goes in?
[10:47] <cjwatson> chrisccoulson: And should I upload after commit, since there are no other staged changes?
[10:48] <jdstrand> cjwatson: you are talking about the "An integrated-with system package" there, right? not a click package, or do I misundestand?
[10:49] <cjwatson> jdstrand: Indeed, since the only influence click packages have over hooks is declaring their use for a given file in their manifest
[10:49] <jdstrand> right
[10:49] <jdstrand> so the hooks themselves *could* be C, and therefore leverage seccomp
[10:49] <cjwatson> If appropriate, I guess, yes
[10:50] <jdstrand> my gut feeling says apparmor is enough at first, and we could move over to C/seccomp as a hardening measure down the line
[10:50] <cjwatson> I think that should be part of defence in depth rather than a core requirement though
[10:50] <cjwatson> Agreed
[10:50] <jdstrand> mdeslaur: once again, fyi ^
[10:50] <chrisccoulson> cjwatson, the patch can just go in debian/patches. the other directories are only there to separate out all of the testing related stuff
[10:51] <chrisccoulson> and feel free to upload it afterwards :)
[10:51] <cjwatson> Though I am currently unfairly bitter towards seccomp for making me think about https://bugzilla.mindrot.org/show_bug.cgi?id=2107 :-)
[10:51] <cjwatson> chrisccoulson: k
[10:52] <jdstrand> hmm
[10:52] <jdstrand> cjwatson: on the other hand, that demonstrates it is quite effective at limiting what something can do :)
[10:53] <cjwatson> Oh, indeed.  As I say, my bitterness is unfair
[10:53] <jdstrand> hopefully the hooks what be nearly as complicated as openssh
[10:53] <jdstrand> :)
[10:53] <cjwatson> Though I must say it is a ghastly pain in the arse to debug
[10:53] <jdstrand> I can imagine. I've not personally had to do that
[10:53] <jdstrand> (yet)
[10:54] <cjwatson> A seccomp confinement failure tends to kill gdb :-)
[10:54] <jdstrand> heh
[10:54] <cjwatson> Not to mention that the confinement failure in question is inherently multiprocess plus buried somewhere in a pile of Kerberos libraries
[10:55] <jdstrand> :\
[10:55] <cjwatson> I might just go ahead and apply that patch, since upstream haven't replied and gssapi is currently borked
[10:58] <jdstrand> food for thought, the apparmor hook would ideally only run as root for the single 'apparmor_parser -r' command
[10:59] <jdstrand> the generation of the profile (ie, parsing manifest.json) does not need to, and I would argue should not, happen as root
[11:01] <cjwatson> Perhaps the apparmor hook could drop privileges for most of itself?
[11:01] <jdstrand> yeah
[11:01] <cjwatson> That seems simplest
[11:02] <cjwatson> Committed revision 1000.
[11:02] <cjwatson> chrisccoulson: ha
[11:03] <ev> ScottK: are you able to log into errors.ubuntu.com and get to a problem page now?
[11:04] <ev> tkamppeter_: same question ^ :)
[11:05] <ev> tumbleweed: ^
[11:05] <ev> hopefully that'll be enough that someone proves this thing works :)
[11:06] <ScottK> Yes
[11:06] <ev> yay!
[11:17] <tumbleweed> ev: yes, thanks
[11:17] <ev> tumbleweed: awesome!
[11:17] <ev> cheers
[11:17] <tumbleweed> this has come along a bit since I was last here
[11:17] <ev> :D
[11:17] <ev> let me know if you run into any trouble with it
[11:17] <ev> or feel free to file bugs :)
[11:20] <tkamppeter> ev, I can log in. I have clicked the link in the confirmation e-mail, got asked to log in, and after that, I am on "indicator-weather (AttributeError) on_apply → export_location_details".
[11:20] <Laney> ev: trouble> "An error occurred while trying to load the most common problems" when I'm logged in ;-)
[11:20] <Laney> https://errors.ubuntu.com/?user=laney&period=day that is
[11:23] <ev> Laney: ah, I can reproduce that. Looks like we're taking too long to iterate through all your subscriptions: Failed to load resource: the server responded with a status of 504 (Gateway Time-out)
[11:24] <tumbleweed> Laney: your auto-subscribe script?
[11:24] <Laney> I'm probably subscribed to quite a lot of stuff
[11:24] <Laney> tumbleweed: that shouldn't be too many, but haskell-* likely is
[11:24] <Laney> or at least haskell-* the last time I ran the script to subscribe to them
[11:28] <ev> Laney: https://bugs.launchpad.net/errors/+bug/1186215 - the table will load if you switch it off your personal view (users of: [ all binary packages ])
[11:28] <Laney> ev: yeah, found that. Thanks!
[11:28] <ev> unfortunately there's nothing I can do to get your personal view loading today though
[11:28] <Laney> No worries
[11:28] <ev> I'll try to get that resolved quickly
[11:29] <ev> tkamppeter: thanks for confirming :)
[12:02] <cjwatson> pk11merge.c:1075:5: error: unknown type name 'CK_ULONF'
[12:02] <cjwatson> I *really* wish our builders suffered fewer one-bit errors
[12:03] <cjwatson> (Quite a few in that case, actually)
[13:18] <cjwatson> chrisccoulson: https://launchpad.net/ubuntu/+source/firefox/22.0~b3+build1-0ubuntu2/+build/4630546 \o/
[13:19] <chrisccoulson> cjwatson, excellent, thanks!
[13:28] <Laney> thanks to whoever gave my evo stuff back :-)
[13:29] <mitya57> doko: any reason why you didn't file a bug about http://people.debian.org/~doko/logs-20130217/gcc48/gdcm_2.2.1-1.1_unstable_gcc48.log? looks that now we have this failure in saucy...
[14:04] <stgraber> ScottK: so the new kde-workspace has published. Do you need any help for the call for testing?
[14:06] <Riddell> stgraber: what is this upstart user session job lark?
[14:11] <stgraber> Riddell: I wrote a startkde.conf user job yesterday that allows for the kde-plasma session to behave in a similar way as the unity session. That means that Xsession spawns upstart in usermode instead of startkde, then upstart starts dbus and then actually spawns startkde.
[14:12] <stgraber> Riddell: the main advantage being that all the processes related to the session are now nicely grouped together under upstart (we use a magic prctl flag to ensure that) and you can have upstart jobs running as a user (and triggering on system or user events)
[14:12] <stgraber> Riddell: if you want to try it on current saucy, just add "kde-plasma" to /etc/upstart-xsessions and logout/login for it to take effect
[14:14] <stgraber> Riddell: my goal is to have every desktop environment that ships as a live CD to run under user sessions as the ubiquity developers are considering moving the whole ubiquity-dm mess to a simple upstart user session job (and we'd like to avoid having to maintain two implementations of that stuff)
[14:20] <Riddell> stgraber: hmm interesting, probably won't be able to test it until monday though
[14:21] <lordievader> Hello, I heard upstart needs testing in Saucy?
[14:21] <BluesKaj> ditto
[14:21] <stgraber> are you guys using Kubuntu on saucy?
[14:21] <lordievader> stgraber: Yes, I am.
[14:22] <BluesKaj> what are we looking for ? yes saucy kubuntu here
[14:22] <stgraber> cool, so yeah, we'd like some testing of upstart usersessions with Kubuntu
[14:22] <stgraber> first make sure you have the latest kde-workspace-bin installed (4.10.3-0ubuntu4)
[14:23] <stgraber> then edit /etc/upstart-xsessions to add "kde-plasma" and finally logout and login again. That should give you a working KDE session but running under upstart.
[14:23] <stgraber> if that works, confirm that you see "startkde" running when doing (as a user) "initctl list"
[14:23] <stgraber> if the session doesn't start properly, simply remove "kde-plasma" from /etc/upstart-xsessions to revert to the old behaviour
[14:26] <mitya57> doko: or maybe you know what could cause that error (^)?
[14:27] <lordievader> stgraber: No need to reboot? For loggin out & in, the "startkde" is not listed when "initctl list" is run.
[14:28] <stgraber> lordievader: can you confirm that /usr/share/upstart/sessions/startkde.conf exists on your system?
[14:28] <lordievader> stgraber: Yes that does exist.
[14:29] <stgraber> lordievader: hmm, and you have kde-plasma on its own line in /etc/upstart-xsessions?
[14:30] <lordievader> stgraber: This is in the file: http://paste.ubuntu.com/5720012/
[14:30] <seb128> lordievader, what Session= do you have in ~/.dmrc?
[14:31] <lordievader> seb128: kde-plasma
[14:31] <BluesKaj> all seems fine here after the changes
[14:31] <seb128> lordievader, did you try without a blank line in /etc/upstart-xsessions?
[14:32] <stgraber> BluesKaj: cool, and "initctl status startkde" shows you "start/running"?
[14:33] <lordievader> stgraber, seb128 Ah now it is present, without the white line.
[14:34] <lordievader> Without the blank-line in upstart-xsessions I mean.
[14:34] <seb128> lordievader, initctl lists things?
[14:35] <BluesKaj> stgraber, yup startkde start/running , is the first line among many :)
[14:35] <lordievader> seb128: This is the output of initctl lists: http://paste.ubuntu.com/5720021/
[14:35] <seb128> stgraber, ^
[14:35] <lordievader> Same here now.
[14:37] <stgraber> cool, that looks good
[14:38] <stgraber> lordievader: can you also pastebin a "ps faux" output, I want to confirm that all the user processes are now under upstart.
[14:38] <BluesKaj> stgraber, my above comment was about the "initctl list"command , the "initctl status startkde" command gives , startkde start/running, process ...
[14:38] <lordievader> stgraber: Here you go: http://paste.ubuntu.com/5720040/
[14:57] <xnox> Daviey: jamespage: I hear that maxb needs/wants to port python-libvirt to python3. Have you heard if that's wanted/needed/started for OpenStack as well?
[14:57] <maxb> Hm? Not me
[14:57] <maxb> bad tab complete?
[14:57] <xnox> maxb: correct, got the wrong nick.
[14:58] <xnox> I am after Max Brustkern which is nuclearbob
[14:58] <Daviey> maxb: Feel free to be a stakeholder
[14:58] <Daviey> xnox: Yes, all things python3, want, yes.
[14:58] <xnox> Daviey: well nuclearbob said he has time to do it =)
[14:58] <Daviey> zul: ^
[14:58] <xnox> Daviey: he was pondering if anyone else was doing it already.
[14:59] <Daviey> xnox: Perfect.  Thanks
[14:59] <Daviey> xnox: zul is working on some deps right now.. but i don't think he touched that yet.
[14:59] <zul> xnox:  havent touched it yet
[14:59] <xnox> zul: yeah, it's ugly pit of auto-generated C bindings from custom xml sources.....
[15:00] <zul> xnox:  be my guest ;)
[15:00] <xnox> zul: what are you working on porting?
[15:00] <zul> xnox: just make sure you push upstream
[15:00] <zul> xnox:  just porting opentsack dependencies to python3
[15:00] <xnox> zul: those that are pure-python?
[15:00] <zul> xnox: so far yes
[15:01] <xnox> ack.
[15:20] <dholbach> hum... could anyone help me debug why the microphone I'm using probably doesn't work? hrm, it worked yesterday
[15:22] <seb128> dholbach, tried to reboot?
[15:22] <dholbach> yes
[15:22] <seb128> dholbach, or to boot a previous kernel?
[15:22] <dholbach> yes, I was too quick to delete the old one, just downloading it now :)
[15:22] <seb128> always keep the n-1
[15:22] <dholbach> yeah :)
[15:22] <seb128> that can come handy :p
[15:23] <dholbach> brb :)
[15:26] <dholbach> seb128, no dice
[15:27] <seb128> :-(
[15:27] <seb128> dholbach, how/where do you test it?
[15:27] <dholbach> skype and google hangout
[15:27] <dholbach> tried alsamixer and gnome-volume-control (or whatever it's called now) settings
[15:28] <seb128> do you see the level stuff move in the system settings panel?
[15:29] <dholbach> no
[15:29] <seb128> :-(
[15:30] <dholbach> not sure where to go from here
[15:30] <seb128> dholbach, do you see any error in the pulseaudio log (if you pulseaudio -k && pulseaudio --start)?
[15:31] <dholbach> no
[15:32] <dholbach> not sure if "(gnome-settings-daemon:1925): media-keys-plugin-WARNING **: Unable to get default sink" is supposed to mean anything or when it came up in .xsession-errors
[15:33] <seb128> dholbach, drop the --start, just "pulseaudio" to get the output
[15:33] <seb128> dholbach, weird, you shouldn't have logs in .xsession-errors to start since we have upstart user sessions and they log in .cache/upstart
[15:33] <dobey> cjohnston: hi there. if you have a few seconds, i was wondering if you could poke at doing bug #1185988 please. thanks. :)
[15:34] <dholbach> this is raring, not saucy
[15:34] <seb128> oh
[15:34] <cjwatson> dobey: ITYM me
[15:35] <dobey> cjwatson: ITVM?
[15:35] <cjwatson> "I think you mean"
[15:35] <dobey> cjwatson: oh yes. sorry. i did mean you. :)
[15:36] <dobey> cjohnston: ignore that :)
[15:36] <seb128> dholbach, $ gconftool --get /system/gstreamer/0.10/default/audiosink
[15:36] <zyga> andrewhaigh_cell: that's very odd, can you show me output of 'vagrant box list'
[15:36] <seb128> though I'm not even sure skype/hangout use gstreamer...
[15:36] <dholbach> seb128, autoaudiosink
[15:36] <zyga> hmm
[15:36] <seb128> dholbach, nothing in the pulse log if you stat without --start?
[15:37] <dholbach> seb128, no
[15:37] <seb128> dholbach, we would need diwic around :/
[15:38] <seb128> dholbach, try to sudo apt-get install paprefs
[15:38] <seb128> dholbach, wait
[15:38] <dholbach> pavucontrol?
[15:38] <cjwatson> My fingers *still* reach for lp-remove-package.py as their first instinct when removing a package
[15:38] <seb128> dholbach, yes, rather
[15:38] <seb128> dholbach, what does that list as input?
[15:38] <cjwatson> Exactly a year after it was obsoleted
[15:39] <dholbach> seb128, Analog Input
[15:39] <dholbach> just one
[15:39] <dholbach> and it's the "Internal Audio" device with "Analog Stereo Duplex"
[15:40] <cjwatson> dobey: done
[15:40] <seb128> dholbach, and the orange bar bellow it doesn't move?
[15:40] <seb128> dholbach, the volume is not muted right?
[15:40] <dholbach> no
[15:43] <dholbach> unfortunately not - I've no idea what else it could be, I'm on the old kernel and this was never much of a problem
[15:43] <seb128> dholbach, could be an hardware issue ...
[15:43] <seb128> dholbach, you don't have a bluetooth headset, webcam or other?
[15:43] <dholbach> no, nothing of the sort
[15:44] <dholbach> but now I just plugged in a usb audiocard and the internal mic works now
[15:44] <dholbach> :-(((
[15:44] <seb128> wth
[15:44] <dholbach> yes
[15:44] <dholbach> wth
[15:44] <seb128> dholbach, sorry I don't know enough about pulse to be useful, we would need diwic or TheMuso
[15:45] <dholbach> will do
[15:45] <dholbach> next week :)
[15:46] <seb128> dholbach, well, at least you got it working
[15:46] <dholbach> yeah, "working" ;-)
[15:48] <dobey> cjwatson: thanks much!
[15:55] <mitya57> seb128: fwiw, I had some progress with gdcm, it now builds up to 69 %, will continue debugging on WE
[15:57] <seb128> mitya57, thanks, we didn't sort out libreoffice yet and Riddell didn't fix okular either
[15:57] <Riddell> I didn't?
[15:57]  * Riddell looks
[15:57] <Riddell> hmm, so I didn't
[15:58] <Riddell> seb128: uploaded
[15:58] <seb128> Riddell, thanks ;-)
[16:00]  * claudevandort 
[16:26] <mitya57> bdmurray: re bug 1047424, it's already in the sru queue
[16:27] <bdmurray> mitya57: The raring queue?
[16:30] <bdmurray> I rejected an upload of software-properties to the raring queue earlier today because it really should have gone to saucy.
[16:30] <slangasek> cjwatson: so the pango changes seem to have broken the cryptsetup initramfs hook; can you point me to what we should be doing there now?
[16:31] <mitya57> bdmurray: oh yes, I saw it a couple of days ago there and thought it still is there
[16:31] <cjwatson> slangasek: Follow the lead of https://launchpad.net/ubuntu/+source/plymouth/0.8.8-0ubuntu7, I think
[16:31] <xnox> is that due to linking harfbuzz?! (me's laptop is booting fine with full-disk-encryption)
[16:31] <xnox> ah.
[16:31] <slangasek> cjwatson: oh, er, maybe I meant plymouth rather than cryptsetup actually
[16:32] <slangasek> cjwatson: ah, apparently I have a local plymouth 0.8.8-0ubuntu7 here with different changes :P
[16:32] <slangasek> yeah, that would do it! thanks :)
[16:32] <cjwatson> Heh :)
[16:34] <mitya57> bdmurray: do you want a debdiff from me then?
[16:34] <bdmurray> mitya57: that'd be great
[16:35] <mitya57> bdmurray: you can take https://bazaar.launchpad.net/~ubuntu-core-dev/software-properties/main/diff/842.1.1 then (I'm cheating, yes)
[17:59] <Quintasan> stgraber: FYI, that upstart KDE magic worked for me too. At least on a VirtualBox machine
[18:00] <stgraber> cool
[19:11] <blitzkrieg3> what's the procedure if you wan to develop on top of a -proposed bzr branch that is verification-failed?
[19:12] <tumbleweed> so it was deleted from -proposed?
[23:07] <cjwatson_> infinity: Second opinion needed: I don't suppose you can work out why automake1.13 is failing (https://launchpad.net/ubuntu/+source/automake1.13/1:1.13.2-1ubuntu1/+build/4628811)?  For the life of me I can't reproduce it locally, and I tried to get more information with a PPA build (https://launchpad.net/~cjwatson/+archive/ppa/+build/4630398) but that inconveniently succeeded.
[23:07] <cjwatson> I could keep throwing it against the wall in case it randomly works, but that seems an unfriendly thing to do with an 80-minute build.
[23:08] <cjwatson> And I sort of feel bad about inserting instrumentation into distro uploads.
[23:09] <cjwatson> Unless it's a subsecond-granularity-in-filesystem-mtimes thing, perhaps ...
[23:09] <cjwatson> What filesystems do the buildds use?
[23:10] <infinity> cjwatson: ext... Probably 3, given the age of some of the installs.  Though, I'd expect 4 on the newer x86 kit.
[23:11] <cjwatson> Last procenv build seems to think ext4 on allspice.
[23:12] <infinity> It could be a bit more verbose about HOW that test failed...
[23:12] <cjwatson> But both my automake1.13 failures were on roseapple.
[23:12] <cjwatson> Indeed.  Maybe my PPA hack wouldn't be too unreasonable for a distro upload anyway.
[23:13] <cjwatson> Specifically http://paste.ubuntu.com/5721401/
[23:13] <infinity> cjwatson: I'm all for fixing racy testsuites (and we should), but if it works almost all the time and is hard to diagnose, I'm also pragmatic.
[23:13] <cjwatson> Aha, https://launchpadlibrarian.net/138643870/buildlog_ubuntu-saucy-i386.procenv_0.20-1_UPLOADING.txt.gz says roseapple is ext3.
[23:13] <infinity> cjwatson: buildd time on weekends is virtually free, giving it back for !roseapple would be acceptablish.
[23:14] <infinity> cjwatson: roseapple's the oldest x86 buildd, so it being ext3 makes sense.
[23:14] <infinity> cjwatson: On the flipside, if we have a testsuite that blows up on ext3, that seems less than ideal.
[23:14] <cjwatson> And ext3 doesn't have subsecond timestamps.
[23:15] <infinity> cjwatson: Does the testsuite *depend* on subsecond timestamps, or it is just racy enough to sometimes fail without 'em?
[23:15] <cjwatson> Looking at the code, I suspect it's racy.
[23:16] <cjwatson> It's repeatedly running configure/make, prodding stuff, checking that configure gets automatically rebuilt.
[23:16] <infinity> cjwatson: Well, I'm happy with either "dig deeper and fix" or "scream LA LA LA CAN'T SEE YOU as we requeue it on !roseapple"... Up to you.
[23:16] <cjwatson> Which is going to depend on whether the runs in question take it across a second boundary.
[23:17] <cjwatson> I think I might do both.  Requeue on !roseapple for now, in parallel attempt to reproduce on ext3 and report upstream.
[23:18] <infinity> cjwatson: That works.  It wasn't an XOR. ;)
[23:18] <infinity> (Though, I suppose the English word "either" preceding an OR implies XOR, doesn't it?)
[23:18] <infinity> Boolean interpretation of conversational language is tricky.
[23:18] <cjwatson> conventionally :)
[23:20] <cjwatson> Whoops.  Dear cjwatson, try giving back the correct version.
[23:30] <cjwatson> Bingo, that test fails first time on ext3.
[23:30] <infinity> cjwatson: Probably fair to say, as a belt-and-bracers thing, that we should file a ticket to reinstall any remaining ext3 buildds as ext4.  Not for the testsuite, but just for not tripping on make races in general.
[23:30] <cjwatson> I'll report it tomorrow
[23:30] <cjwatson> Yeah, there's an argument for that, I guess
[23:30] <cjwatson> Though you do have to be working at it to trip over this
[23:31]  * cjwatson -> bed
[23:32] <infinity> cjwatson: Well, it mostly only matters on sufficiently speedy hardware, which means that, in practice, roseapple may be the only affected machine, really.
[23:32] <infinity> cjwatson: ia64 and sparc will be ext3, but I don't care, and ross and adare probably are, but are slow enough to not trip often on such things.
[23:36] <infinity> Grr, forgot to accept the UEIF blobs for that kernel SRU.  Such an unintitive workflow...