[05:47] <zyga-mbp> o/
[05:59] <mardy> hi zyga-mbp!
[05:59] <zyga-mbp> hey :)
[06:00] <zyga-mbp> how are you doing?
[06:00] <zyga-mbp> it's a remarkably cold day
[06:00] <zyga-mbp> it's 18C right now
[06:24] <mardy> zyga-mbp: well... 18C is not remarkably cold :-) Now it's 20C in Saint Petersburg. But indeed, yesterday it was much warmer
[06:24] <zyga-mbp> mardy: it was close to 32 recently
[06:25] <mardy> ouch
[07:04] <pstolowski> morning
[08:12] <mborzeck1> hmm matrix bridge seems to be having troubles again
[08:13] <mborzecki> or not?
[08:16] <pstolowski> hey mborzecki
[08:16] <mborzeck1> pstolowski: hey
[08:16] <mborzeck1> yeah, i can send messages from matrix, but don't see any coming back
[08:40] <mborzeck1> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/10485 ?
[08:43] <pstolowski> sure
[09:47] <mborzeck1> mvo: hi, can you take a look at https://github.com/snapcore/snapd/pull/10481 ?
[11:12] <pstolowski> eod, cu
[11:14] <mvo> enjoy pstolowski
[11:18] <mardy> mvo: the mount-control interface, should it auto-connect?
[11:19] <mvo> mardy: not by default I think
[11:25] <pstolowski> ty o/
[11:31] <mborzeck1> heh the #fedora channel is flooded with part/join messages due to matrix bridge issues
[11:36] <mborzeck1> anyone seen this? https://paste.ubuntu.com/p/4MbGfvNfZ6/ keypair manager with latest master
[11:42] <mborzeck1> mardy: can you run go test in asserts pacakge with the latest master?
[11:47]  * cachio_ afk
[12:22] <ijohnson[m]> Morning folks, is the matrix IRC bridge working perchance?
[12:22] <mardy> mborzeck1: yes, got failures in private_key.go
[12:22] <mborzeck1> mardy: apaprently govendor sync is needed
[12:22] <mborzeck1> ijohnson[m]: not quite, i'm getting messages from 4-5 hours back
[12:23] <mborzeck1> ijohnson[m]: https://twitter.com/matrixdotorg/status/1410917181861343233
[12:26] <mborzeck1> mvo: https://github.com/snapcore/snapd/pull/10486 this is the remodel draft branch, it'll get smaller as things land
[12:26] <mardy> mborzeck1: oh, thanks, indeed that fixes the issue
[12:54] <mvo> mborzecki: nice, thanks
[13:29] <ijohnson[m]> mborzeck1: hmm is it back now, I see some messages from you showing up now?
[13:30] <mborzeck1> ijohnson[m]: might be messages from an hour ago ;)
[13:30] <ijohnson[m]> mborzeck1: well I saw your reply just now
[13:30]  * ijohnson[m] goes to join regular IRC anyways too
[13:30] <mborzecki> and this one?
[13:30] <ijohnson[m]> oh yeah I see that
[13:31] <ijohnson1> hello from IRC
[13:32] <ijohnson[m]> oh I see that message immediately, I think the bridge is working now
[13:48] <mborzeck1> great, switching back to matrix then
[13:56] <ijohnson[m]> bboozzoo: oh no, I still am on IRC via ijohnson1 and didn't see your "and yay" message come through on IRC there ☹
[13:56] <ijohnson1> but I can still see ijohnson[m]'s message just now
[14:32] <mborzecki> hahaha
[14:32] <mborzecki> and yay
[14:38]  * cachio_ bank appointment
[16:23] <cachio_> mborzecki, hey, when you have a moment could you please take a look to this comment? https://github.com/snapcore/snapd/pull/10483#issuecomment-873017393
[19:01]  * cachio_ afk
[19:26] <ijohnson1> cachio_for https://github.com/snapcore/snapd/pull/10483, how can I get a 18.04-32 environment to reproduce the failure ?
[19:26] <ijohnson1> cachio_ ^
[22:23] <cachio> ijohnson1, hi
[22:24] <cachio> sorry for the delay
[22:24] <cachio> just came back to home
[22:24] <cachio> you just need to add
[22:25] <cachio>             - ubuntu-18.04-32:
[22:25] <cachio>                   workers: 6
[22:25] <cachio> to the google systems
[22:25] <cachio> and tun the snap-run test


[01:59] <studio> hey guys, why would my file system suddenly go read-only?  I am running 14.04.  This seems to happen to me with all versions, having done the same in 12.10 and 13.10 also.
[02:01] <studio> I like studio and would rather stay with it.  Any clues as to what causes this and/or how to prevent it?
[02:25] <holstein> studio: user error?
[02:25] <holstein> studio: also, your hard drive could be failing..
[02:50] <studio> How can I check my hard drive?
[02:50] <holstein> studio: i use tools such as gsmartcontrol on a live CD
[02:50] <holstein> some bios's will have checks
[02:51] <studio> ok
[17:42] <element> hi
[19:59] <reha> i need help on ardour for monitoring what i play
[20:00] <reha> and i said hello first of course


[13:15] <BHXSpecter> wtf? I updated firmware for router and passed the test by changing to port 8001 but I'm still banned from #ubuntu and I did all this yesterday evening :/
[13:15] <BHXSpecter> definitely been more than 10 minutes now lol


[10:17] <airurando> morning
[10:17] <czajkowski> aloha airurando
[10:18] <airurando> hi czajkowski
[10:18] <ebel> yo
[10:18] <airurando> hi ebel
[10:18] <czajkowski> 7 weeks to xmas :D
[10:18] <czajkowski> shall we all start taking bets now on snow and me getting back
[10:19] <airurando> don't even contemplate it
[10:19] <airurando> positive thinking
[10:19] <zmoylan> and bring snow shoes! :-D
[10:20] <czajkowski> I've started the xmas shopping list
[10:20] <czajkowski> so semi prepared
[10:20] <czajkowski> and moing house in 2 weeks
[10:20] <czajkowski> back down to aldershot
[10:20] <airurando> good stuff
[10:21] <airurando> I posted 20 x 12.10 and 20 x 12.04 discs to NUIG Comp Soc this morning for their installfest
[10:21] <ebel> czajkowski: that's mad with the price
[10:21] <ebel> my sister & boyfriend are getting the sail & rail instead of flights due to price
[10:22] <ebel> czajkowski: I remember when me and Tom were going to wales for offroad biking lessons. We bought "volcano insurance", i.e. a ferry ticket :P
[10:23] <czajkowski> sail and rai works out to be roughly the same bar I think 40 quid tbh
[10:23] <czajkowski> give i've to get a train to the sail
[10:23] <czajkowski> and then a train down to limerick
[10:23] <ebel> aye.
[10:23] <czajkowski> plus the time involved means you lose a day either side of your holiday
[10:24] <ebel> well my sister is going from southhampton, but no train on irish side
[10:24] <ebel> Think it was about £100 cheaper or so all in for them.
[10:24] <czajkowski> nods
[10:24] <czajkowski> 100 quid is a lot
[10:24] <ebel> agreed about time. you either spend money or time :P
[10:24] <czajkowski> yup
[10:24] <czajkowski> I also factor in my back and travel
[10:25] <czajkowski> and a 60 quid train to limerick at xmas is not ideal
[10:25] <czajkowski> been there done that
[10:25] <ebel> aye


[10:04] <alan_g> dednick: re ..._trusted socket. I think the essentials are done (I need some tests around starting up providers - but it ought to "just work" as a side effect of the production changes). Let me know if you try it: lp:~alan-griffiths/mir/permissions-and-error-handling-for-prompt-sessions
[10:05] <dednick> alan_g: thanks. i'll take a look
[10:05] <alan_g> dednick: Sorry, wrong branch in paste buffer...  lp:~alan-griffiths/mir/spike-trusted-helper-socket
[10:43] <alf_> greyback: Hi! In case you know... why are using a QCoreApplication in USC? Is it a left-over? Are we going to need it in the near future?
[10:43] <greyback> alf_: I don't know. mterry would
[10:44] <alf_> greyback: yes, but US is on vacation today :) thanks
[10:49] <greyback> alf_: sorry, I've barely looked as USC code
[10:49] <alf_> greyback: no, worries, I will just remove it and we can put it back if needed
[10:51] <greyback> alf_: it's mainly just adds an event loop so you can use qt signal/slots - it's not used for GUIs
[10:53] <alf_> greyback: ahh, it's used by our dbus infrastructure in USC
[10:54] <greyback> alf_: yeah, would be needed for that too
[11:15] <greyback> alf_: can I ask you some questions on mir, gl configs & mesa?
[11:16] <alf_> greyback: of course
[11:16] <greyback> alf_: the qtcompositor code right now just uses the gl context that Mir chooses for it. Which is perfect on phablet devices as GLES is supported
[11:16] <greyback> alf_: but on desktop, Qt compiled with only desktop GL support.
[11:17] <greyback> alf_: I know in qtubuntu we had a hack to call eglBindAPI(OPEN_GL) which persuaded Mesa to let us use a GLES context with GL shaders and stuff
[11:17] <greyback> alf_: was that it? Nothing else had to be done?
[11:18] <greyback> I'm trying to do the same thing for QtComp but am not having success.
[11:20] <alf_> greyback: I don't recall the detail, only that this was a hack that just happened to work with Mesa. The issue is that since Mir uses GLES2 it links with libGLES2. If qtcompositor comes and indirectly links with libGL (which offers many of the same symbols) there could be trouble.
[11:21] <greyback> alf_: that's an idea. Perhaps there's some lib preloading happening somewhere to get around that
[11:26] <mpt> Oh dear I just realized that default window positioning depends on whether you’re using an LTR or an RTL language
[11:27] <alf_> greyback: but ideally Qt should support selecting GL vs GLES2 at runtime... I think they have made some first steps to support this?
[11:27] <greyback> alf_: qt5.3 does, but our packaging hasn't turned it on
[11:32] <greyback> alf_: ah, it's windows only :( So no change there
[11:33] <alf_> greyback: So, what kind of errors are you getting?
[11:37] <greyback> alf_: http://pastebin.ubuntu.com/7746717/ just a snippit (bit messy, I've debug code in)
[11:44] <alf_> greyback: ok, how about creating a new GL context shared from the GLES2 context that Mir gives you and using that with Qt?
[11:45] <greyback> alf_: that's what qtcomp is doing actually
[11:46] <greyback> http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/platforms/mirserver/miropenglcontext.cpp
[11:47] <greyback> combined with http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/platforms/mirserver/mirserverintegration.cpp#L124
[11:47] <alf_> greyback: it seems though, that Qt produces a fragment shader for GL but is being compiled with a GLES2 context, and thus complains about missing precision
[11:48] <greyback> alf_: right. So I tried calling eglBindAPI(EGL_OPENGL_BIT) before makeCurrent and swapBuffers, but no good
[11:49] <greyback> err eglBindAPI(EGL_OPENGL_API)
[11:49] <greyback> but same error
[11:50] <greyback> so a difference I see is that in qtubuntu, eglBindAPI is also called before the context is created
[11:54] <alf_> greyback: I don't see how the code in miropenglcontext sets the context to desktop GL. It eventually calls DisplayBuffer::make_current() which will use the built-in mir context (which is GLES2)
[11:55] <greyback> alf_: it doesn't. I had thought that Mesa would "force" a GLES context to accept desktop GL
[11:56] <greyback> alf_: I can confirm, if I hack Mir to use a desktop GL context, this works fine
[11:56] <greyback> this = Qt Comp on desktop
[11:56] <greyback> it's just the GL/GLES mismatch that I'm fighting
[11:57] <greyback> and I'm trying to emulate what qtubuntu does
[11:57] <alf_> greyback: From what I understand, what Mesa accepts is linking against libGLESv2 and asking for a desktop GL context and vice versa and it works
[11:58] <alf_> greyback: but if the current context is GLES2 you can't do GL stuff with it
[11:59] <greyback> alf_: which makes sense to me.
[12:00] <greyback> alf_: so is qtubuntu actually creating a desktopGL context: http://bazaar.launchpad.net/~phablet-team/qtubuntu/trunk/view/head:/src/platforms/base/context.cc#L55
[12:00] <greyback> just by having bound the api before eglCreateContext
[12:00] <greyback> ?
[12:03] <alf_> greyback: right
[12:03] <greyback> alf_: ok. Then that's my problem then so. Mir creates GLES2 context, but Qt needs desktopGL.
[12:10] <alf_> greyback: what do you change in Mir to force a GL context? Only the eglBindAPI() call in display_helpers?
[12:11] <greyback> alf_: I hacked Mir to choose GL context, just to prove to myself Qt would work with it on desktop. I've not tried this eglBindAPI thing before
[12:12] <alf_> greyback: right, I mean how did you hack it, do you have a diff?
[12:13] <greyback> alf_: all extremely messy: http://pastebin.ubuntu.com/7746824/ I hope you can see what I'm attempting though
[12:17] <alf_> greyback: You also mentioned that you hacked Mir itself to produce a desktop GL context. Do you have a diff for that?
[12:17] <greyback> alf_: ah. Maybe, lemme see if I kept it. It was several months ago now
[12:19] <greyback> alf_: I doubt it'll apply cleanly: http://pastebin.ubuntu.com/7746849/
[12:20] <greyback> it was to add a compile-time option to mir, similar to what Qt had. Think it broke more than it solved overall
[12:21] <greyback> EGL_RENDERABLE_TYPE, EGL_OPENGL_BIT, <- the main bit really
[12:26] <alf_> greyback: If you can confirm that just changing EGL_RENDERABLE_TYPE, EGL_OPENGL_BIT and eglBindAPI(EGL_OPENGL_API) in display_helpers.cpp (while still building mir against libGLESv2) works for you, we can provide a workaround in Mir
[12:26] <alf_> greyback: with the understanding that this is the WRONG way to do it :)
[12:26] <greyback> alf_: it is, definitely
[12:29] <alf_> greyback: but barring Qt having runtime GL vs GLESv2 selection (or perhaps Mir having it?) there is not much we can do, other than take advantage of this fortunate quirk in Mesa
[12:29] <greyback>  alf_ yeah. If I can manage to exploit the Mesa quirk, I might be happy enough for now
[12:30] <alf_> greyback: ok, so try just hacking EGL_OPENGL_BIT and eglBindAPI(EGL_OPENGL_API) in display_helpers.cpp and if it works let me know
[12:32] <alf_> greyback: (I want to stress again the "while still building mir against libGLESv2" part)
[12:32] <greyback> alf_: sure
[13:06] <MacSlow> Greetings!
[13:09] <MacSlow> I'm constantly getting the error "libEGL warning: unsupported platform (null)" when trying to run a mir-client (using mir_demo_server_basic from lp:mir) on my desktop machine (ATI Radeon, driver: Gallium 0.4)
[13:09] <MacSlow> I also tried passing EGL_PLATFORM=mir, but that doesn't fix it.
[13:09] <MacSlow> starting a mir-client on this very system used to work just fine a couple of weeks ago.
[13:10] <MacSlow> What changed in the required procedure to make that work?
[13:10] <alf_> MacSlow: I don't think the error is related, we have been getting it forever (on working systems)
[13:11] <MacSlow> alf_, I'll try some other clients just for cross-checking...
[13:12] <alf_> MacSlow: How exactly are you are running the server and client, are you using you own build, or packages?
[13:12] <MacSlow> alf_, hm... the egltriangle example from lp:mir works
[13:12] <MacSlow> odd
[13:13] <MacSlow> alf_, the mir-client I'm trying to get to work is the unity-system-compositor-spinner... which works fine on the phone (N4)
[13:13] <MacSlow> alf_, guess i've to dig deeper
[14:55] <MacSlow> How would one start a mir-client on a current UbuntuTouch image running the unity-system-compositor?
[15:03] <alan_g> MacSlow: I think USC still exports a socket to the filesystem, so check you have +rw access and supply that via "-m"
[15:06] <MacSlow> alan_g, sudo ./unity-system-compositor-spinner -m /run/mir_socket
[15:06] <MacSlow> alan_g, is what I try to execute... but it fails and only spits out...
[15:06] <MacSlow> Current active output is 2560x1600 +0+0
[15:06] <MacSlow> Server supports 3 of 6 surface pixel formats. Using format: 1
[15:06] <MacSlow> and then exits
[15:06] <MacSlow> running mir-clients used to be a piece of cake some weeks ago
[15:08] <alan_g> MacSlow:  ls -l /run/mir_socket?
[15:10] <MacSlow> srwxrwxrwx 1 root root 0 Jul  4 16:50 /run/mir_socket=
[15:10] <MacSlow> I just tried MIR_SOCKET=/run/mir_socket /usr/bin/unity-system-compositor-spinner
[15:10] <MacSlow> which did not fail or exit... but the greeter is unresponsive to touch-inputs... I'm restarting the N10
[15:15] <alan_g> MacSlow: how does a demo client behave? E.g. mir_demo_client_display_config -m /run/mir_socket
[15:18] <MacSlow> alan_g, I've a way to test it... greyback suggested to kill lightdm/unity-system-compositor and start the mir_demo_server_shell
[15:18] <MacSlow> alan_g, with that as basis it allows me to get my mir-client  running and visible
[15:19] <alan_g> MacSlow: if you can work with mir_demo_server_shell it eliminate a bunch of code from the mix.
[15:21] <MacSlow> hm... but oddly the locally compiled unity-system-compositor-spinner (from lp:unity-system-compositor) segfaults while the system-wide installed one does work
[15:23] <alan_g> Are they built with the same compiler?
[15:24] <alf_> MacSlow: alan_g: Confirmed, I get the same behavior
[15:26] <alf_> MacSlow: ==9958== Invalid read of size 4
[15:26] <alf_> ==9958==    at 0x50C5D60: cairo_surface_status (in /usr/lib/x86_64-linux-gnu/libcairo.so.2.11301.0)
[15:26] <MacSlow> cairo_surface_status() crashes according to the backtrace
[15:26] <alf_> ==9958==    by 0x4032FB: uploadTexture (eglspinner.c:150)
[15:26] <alf_> ==9958==    by 0x403BA1: main (eglspinner.c:365)
[15:26] <alf_> ==9958==  Address 0x1c is not stack'd, malloc'd or (recently) free'd
[15:30] <alf_> MacSlow: cmake .. -DCMAKE_INSTALL_PREFIX=/usr
[15:30] <alf_> MacSlow: it can't find the png file otherwise
[15:32] <alf_> MacSlow: of course it should just print a nice error message instead of crashing :)
[15:33] <MacSlow> alf_, I'll add something while I'm fixing the issue I initially wanted to address :)
[15:41] <alan_g> dednick: any feedback on lp:~alan-griffiths/mir/spike-trusted-helper-socket? (I've MP'd it now)
[15:42] <dednick> alan_g: hm. I was waying for tyhicks, but just realised that he's on holiday today. 4th July.
[15:42] <dednick> s/waying/waiting
[15:42] <MacSlow> greyback, alan_g, alf_: got all issues sorted out (on N10 and desktop) soaring away with the optimization for the spinner now... thanks!
[15:43] <alf_> MacSlow: great, have fun :)
[15:43] <greyback> good to hear
[15:43] <alan_g> dednick: ack
[15:43] <dednick> alan_g: he's back on monday
[15:43] <alan_g> MacSlow: \o/
[15:45] <alan_g> dednick: while that discussion might obsolete the approach I think we need something like this short term.
[15:46] <dednick> alan_g: yes. i agree. I can try take a look at the MP this afternoon


[03:50] <Lhademmor> Hello. Is this project still alive?
[03:52] <Nailor> Yes. Why?
[03:53] <Lhademmor> I'm on a ThinkPad R51, and was wondering if anyone needed that...
[03:53] <Nailor> Needed what?
[03:54] <Nailor> You got a spare R51 you're willing to give away? ;)
[03:54] <Lhademmor> A LaptopTest of it. Is that not what this project is about?
[03:54] <Lhademmor> Hehe, not yet :P
[03:54] <Lhademmor> You wouldn't want the old crap anway ;)
[03:54] <Nailor> Well, if you're interested in testing how things work on it please do
[03:54] <Nailor> Just report your findings to wiki
[03:55] <Nailor> Testing itself is quite straightforward operation
[03:55] <Lhademmor> I'll see if I can figure it out...
[03:55] <Lhademmor> But I'm testing from installed Feisty, not from a Live-CD. Does that make a difference?
[03:56] <Nailor> Not really
[03:56] <Nailor> The information we prefer is how the installed system works
[03:56] <Lhademmor> Ok, cool. I'm on it. First one off, the middle-mouse-button is broken - I'll see if I can figure out how to report that
[04:01] <Nailor> Check out the wiki page (http://wiki.ubuntu.com/LaptopTestingTeam) for more info
[04:02] <Nailor> You should check if your laptop is being tested already
[04:02] <Lhademmor> It seems not..
[04:02] <Nailor> ok
[04:02] <Nailor> Then you should just copy the testing template to be used for it
[04:02] <Lhademmor> I'll work on it :)
[04:04] <Lhademmor> I have a dream.... About a Ubuntu Wiki which is updated and contains up-to-date and relevant information. I'll start here.
[04:07] <Nailor> =)
[04:25] <Lhademmor> Nailor: What happened to the LaptopTeamTemplate?
[04:26] <Lhademmor> Screw that, I'll just copy something from one of the other entries
[04:27] <Nailor> Good question :p
[04:47] <Lhademmor> https://wiki.ubuntu.com/LaptopTestingTeam/Lenovo_IBM/IBM/Lenovo/ThinkpadR51 (<-- there, the initial report)


[11:59] <vrederv> How do I use the web API to fetch the version of a package?
[12:00] <cjwatson> easiest if you have it in the form of a source package name, then you'd use archive.getPublishedSources
[12:01] <cjwatson> something like http://paste.ubuntu.com/23672829/
[12:01] <cjwatson> https://launchpad.net/+apidoc/devel.html#archive-getPublishedSources
[12:02] <cjwatson> you can use archive.getPublishedBinaries if you really need to go by binary package name, in which case you also need to specify the architecture
[12:02] <cjwatson> In [1]: lp.distributions['ubuntu'].main_archive.getPublishedBinaries(binary_name='man-db', exact_match=True, distro_arch_series='/ubuntu/zesty/amd64', pocket='Release', status='Published')[0].binary_package_version
[12:02] <cjwatson> Out[1]: u'<IP_ADDRESS>-1'
[12:03] <vrederv> thank you ... I am not using the Python module
[12:03] <cjwatson> you'll have to derive the required requests from the above then, but it's a pretty regular transformation
[12:04] <cjwatson> https://help.launchpad.net/API/Hacking
[12:05] <vrederv> Let's take Ubuntu's apache2 package as an example, the site is https://launchpad.net/ubuntu/+source/apache2
[12:06] <vrederv> The archive URL should be https://api.launchpad.net/1.0/ubuntu/+archive/apache2
[12:07] <cjwatson> no it shouldn't
[12:07] <vrederv> alright what should it be?
[12:07] <cjwatson> /ubuntu/+archive/primary is the archive; apache2 is not an archive
[12:08] <vrederv> So https://api.launchpad.net/1.0/ubuntu/+archive/ubuntu/+archive/primary ?
[12:08] <cjwatson> $ curl -s 'https://api.launchpad.net/devel/ubuntu/+archive/primary?ws.op=getPublishedSources&source_name=apache2&exact_match=true&distro_series=/ubuntu/zesty&pocket=Release&status=Published' | jq '.entries[0].source_package_version'
[12:08] <cjwatson> "2.4.23-7ubuntu1"
[12:08] <cjwatson> (remove the duplicate /ubuntu/+archive segment from yours)
[12:09] <vrederv> thank you!
[12:09] <cjwatson> you're welcome
[13:30] <clivejo> Hi folks, can an existing LP bug be converted into an SRU, or should a brand new bug be submitted for the SRU?
[13:32] <cjwatson> clivejo: that's an SRU team question rather than an LP question.  but anyway, usual practice is that if the existing bug is just for the one thing that's being changed in the SRU, then it's fine to reuse it, otherwise file a new bug
[14:29] <smoser> where do i configure webhooks for https://code.launchpad.net/cloud-init ?
[14:29] <smoser> i can't seem to find it poking around in the ui
[14:37] <cjwatson> smoser: some things are only on the repository page and not on the code index, somewhat confusingly
[14:37] <cjwatson> smoser: so follow the "lp:cloud-init" link and then "Manage webhooks" under there
[14:38] <smoser> hm.
[14:38] <smoser> i swear i looked there. or at least had some other view of that repo. thank you !
[14:38] <cjwatson> np
[14:38] <cjwatson> the code index has a sort of partial view - I have a batch of UI changes in progress to try to make things clearer there
[14:39] <smoser> ok. i also looked https://code.launchpad.net/cloud-init
[14:39] <smoser> i did read the docs... so if they had some "git hooks configure at a url like ...." then i'd have probably not bothered you
[14:39] <smoser> thank you though.
[14:40] <cjwatson> well, it's a UI bug really.  there should just be a "Manage webhooks" link right there.
[19:51] <rlaager> cjwatson: No answer on https://answers.launchpad.net/launchpad/+question/407771 in three days. He is still unable to login.
[19:52] <nacc> rlaager: could just be timing, holidays and all
[19:53] <rlaager> nacc: Sure. I have no idea what the commercial support process is supposed to look like. This is preventing him from pushing stuff to our paid-for private PPA.
[19:53] <cjwatson> I've been the only LP staff person on duty and I've had a hellish deadline to meet before end of year
[19:54] <cjwatson> also not sure anyone said it was commercial ...
[19:54] <nacc> rlaager: right, i'd never have known it was commercial myself :)
[19:55] <rlaager> cjwatson: It sounds like your other thing is more important. We can wait.
[19:55] <cjwatson> I'm done for the year
[19:55] <cjwatson> But let me see if I can figure something out
[19:56] <user0> Hi, I've got the same problem as that 407771. I think this happened to me 3 months ago when I created the account, so I let it time :-) But still Oops-* all time now.
[19:57] <user0> can't access https://launchpad.net/people/+me/
[19:57] <cjwatson> user0: what's the OOPS ID?
[19:58] <user0> OOPS-8748ac6f6e9da2126007ef4659c66de4 , right now
[19:58] <ubot5`> https://oops.canonical.com/?oopsid=OOPS-8748ac6f6e9da2126007ef4659c66de4
[19:59] <cjwatson> ok, will look into both once a sysadmin responds to my query
[19:59] <rlaager> Also for reference: My existing account can login (in new browser sessions) just fine. We tried a couple different browsers for his, and it reproduces in both of them.
[19:59] <cjwatson> rlaager: yeah, it's specific to his account because he previously had an autocreated person record due to a translation import
[20:00] <cjwatson> neither the behaviour of your account nor the browser is relevant - the OOPS uniquely identifies the problem
[20:01] <cjwatson> this is all https://bugs.launchpad.net/launchpad/+bug/1607242, just need to get a sysadmin to tell me what the new openid association in the DB is so that I can request the proper merge
[20:01] <ubot5`> Ubuntu bug 1607242 in Launchpad itself "Logging into a placeholder person OOPSes if email address already on another person" [Critical,Triaged]
[20:14] <cjwatson> Er, s/translation/bug comment/ in my comment above.
[20:34] <cjwatson> rlaager,user0: should work now
[20:34] <cjwatson> sorry for the delay
[20:39] <rlaager> cjwatson: Thanks!
[21:02] <user0> Wow!!!
[21:02] <user0> thank you very much cjwatson
[21:03] <user0> Hopefully I found this IRC @ https://help.launchpad.net/Oops
[21:03] <user0> thumbs up


[17:20] <dlundquist> Can I cause upstart to reexec itself? (I'm trying to pivot_root)
[18:19] <JanC> dlundquist: sending SIGTERM should restart upstart
[18:45] <dlundquist> JanC: thank you, that did it
[21:01] <xMopxShell> Hi, is it possible to make a service depend on a service that may or may not exist?
[21:01] <xMopxShell> i.e., if it exists, wait for it to start, if not, continue


[00:12] <eaerth> good morning, everyone!
[19:18] <thorwil> so tired of having to reenable my wacom after every ubuntu upgrade :/