[00:14] <racarr> killall mir_stress;
[00:14] <racarr> fun to write ;)
[00:19] <racarr> feel very close to this stress bug
[00:19] <racarr> but need to go help build a dome
[00:19] <racarr> back later :)
[00:33] <RAOF> racarr: Yo
[00:36] <racarr> RAOF: Hi! Sorry. I am about to leave (I literally have to go help build a dome)
[00:36] <RAOF> That's ok.
[00:36] <racarr> but, I will be around...was hoping we could have a hangout later
[00:36] <RAOF> Sure.
[00:36] <racarr> I am jumping more on the xmir train (WHISTLE WHISTLE SCREEEEEECH)
[00:36] <RAOF> Wooo wooo!
[00:37] <racarr> and have a few items I want to sync with you on and just in general
[00:37] <racarr> clarify
[00:43] <RAOF> Cool.
[00:44] <racarr> Ok play time!
[00:45] <racarr> aww truncated
[00:45] <racarr> *runs in shame*
[01:05] <RAOF> What the whatting what? My perfectly valid DrawablePtr gets mangled in the process of calling xmir_dri2_drawable_can_bypass. Are there two different definitions of struct _Drawable or something?
[01:09] <RAOF> There must be! What the whatting what?
[01:22] <RAOF> Well, that's moderately terrible. Always #include <xorg-config.h>, lest your structures magically change layout!
[01:46]  * duflu includes <xorg-config.h> in all files from now on
[01:58] <duflu> Oh kdub, you put conflicts in all my code today :)
[02:11] <duflu> Worse than conflicts... classes don't exist any more . Hmm...
[03:31] <kgunn> so does gdb have known issues with xmir ?
[03:39] <duflu> kgunn: X in general is not GDB friendly. You always have to GDB from an ssh login
[03:40] <duflu> or remote shell of choice...
[03:41] <RAOF> I'm happily gdbing XMir right now.
[03:41] <RAOF> FSVO “happily”
[03:44] <kgunn> got it
[03:59] <RAOF> Bah.
[03:59] <RAOF> I should have remembered the unofficial X motto.
[03:59] <RAOF> “X: More difficult than you think”
[04:00] <duflu> X: Solve everything for...
[04:04] <RAOF> Alright. That's enough GLX bypass for now. Upstreaming!
[04:06] <duflu> Woo!
[05:00] <duflu> thomi: Sorry to bug you late in the day but any idea about... https://jenkins.qa.ubuntu.com/job/mir-clang-saucy-amd64-build/1222/console
[05:25] <didrocks> hey kgunn!
[05:25] <kgunn> hey didrocks !
[05:26] <didrocks> waow, you are using French punctuation (space before ! : and ; )
[05:27] <didrocks> kgunn: I confirm that u-s-c depends on libmirserver FYI
[05:27] <didrocks> unity-system-compositor:
[05:27] <didrocks>  Depends: libboost-program-options1.53.0, libboost-system1.53.0, libc6 (>= 2.9), libgcc1 (>= 1:4.1.1), libmirserver0 (= 0.0.7+13.10.20130716ubuntu.unity.next-0ubuntu1), libstdc++6 (>= 4.6)
[05:28] <didrocks> (this dep is automatically resolved by the linker)
[05:29] <kgunn> didrocks: hmmm,  i know  it uses a "shared" header...but it must actually end up being in libmirserver
[05:29] <didrocks> src/system_compositor.h:#include <mir/default_server_configuration.h>
[05:29] <didrocks> yeah, should be that ^
[05:30] <kgunn> that be the one
[05:31] <didrocks> kgunn: so, +1 on the virtual package, created by a soname (in cmake) which creates a config.h file (#define)?
[05:31] <kgunn> didrocks: wanna join our team meeting ?....we can get all our stuff out of the way & ping you to join
[05:31] <racarr> didrocks: It's really fun. you know you want to
[05:31] <didrocks> racarr: ahah :p
[05:31] <didrocks> kgunn: oh sure, when is it? (I thought your meetings were on Thursday)
[05:32] <kgunn> nope tonight
[05:32] <kgunn> or this morning sorry
[05:32] <didrocks> I was able to translate :-)
[05:32] <didrocks> how long from now?
[05:32] <kgunn> we start in 1/2 hour
[05:33] <didrocks> ok, just time to get the coffee ready then!
[05:33] <kgunn> oh sure
[05:34]  * racarr jealous
[05:34] <racarr> If I had coffee there would be no going back
[05:34] <didrocks> racarr: caffein-free tea? :)
[05:34] <racarr> didrocks: One step ahead XD
[05:34] <didrocks> heh
[05:34] <racarr> it's the caffeine I want. it's just the caffeine I dont want in 1 hour
[05:48] <RAOF> didrocks: Incidentally, how do we work out when the ABI has changed for that?
[05:48] <RAOF> Empirically?
[05:48] <didrocks> RAOF: you mean, how do you see the ABI changed? Yeah, you have to notice that your change did that
[05:48] <didrocks> RAOF: the integration tests will tell you that quickly I think :p
[05:49] <RAOF> Ah, ok.
[05:54] <thomi> duflu: hey, I missed your message before
[05:54] <thomi> duflu: it looks like possibly a bzr bug? Did you retry the build?
[05:55] <duflu> thomi: No, I don't think I have the VPN set up any more
[05:55] <thomi> duflu: OK
[05:57] <thomi> duflu: I've just kicked it off again, we'll see if it works this time.
[05:57] <duflu> thomi: Ta
[05:57] <thomi> duflu: and I'll file a bug against bzr builder and see what the devs say
[05:57]  * duflu wonders if the VPN setup instructions are any simpler tnow
[05:58] <thomi> I'm not sure they're any simpler... but I set it up once, and have never had to touch it again
[05:58] <duflu> ... because I tend to wipe my machines between releases
[05:58] <thomi> I recommend using the network-manager-applet instructions
[05:58] <thomi> ahhh
[05:58] <thomi> I haven't done that for a few years now
[05:59] <thomi> duflu: perhaps you have a router that's VPN capable? Although that's not very secure, depending on who has access to your personal network
[06:00] <robert_ancell> thomi, hikiko, alf_ kgunn kdub meeting
[06:41] <RAOF> racarr: Are you still hankering for a hangout?
[06:56] <didrocks> kgunn: RAOF: let me enlight your day/night and please approve https://code.launchpad.net/~didrocks/mir/remove-powerpc/+merge/175201 :)
[07:03] <thomi> duflu: looks like the re-run of that jenkins job worked. I've filed a bug against bzr-builder anyway
[07:03] <duflu> thomi: Yep thanks
[07:09] <dholbach> good morning! :)
[07:12] <thomi> RAOF: Is a string like "Intel Corporation: 2nd Generation Core Processor Family Integrated Graphics Controller" useful enough to identify the graphics chipset for the xmir devices?
[07:12] <thomi> I as because that's all we get for the cert lab machines at the moment
[07:13] <thomi> But I guess ideally we'd get the specific model number
[07:13] <RAOF> thomi: It's pretty good, but could be better.
[07:13] <thomi> ok.. as long as it's not totally useless, I'll run with it for now
[07:13] <RAOF> Ideally we'd get a tuple of (gen, GT #).
[07:13] <RAOF> Xorg.0.log should actually have the (gen, GT #) tuple in in.
[07:14] <RAOF> But I can't tell at the moment, because btrfs has done it's "I'll just wedge for a couple of minutes, k" thing, and anything that hits the disc subsystem is going to hang in D state.
[07:14] <RAOF> Ah, there we go! Hissy fit ended!
[07:15] <RAOF> [  6184.799] (--) intel(0): Integrated Graphics Chipset: Intel(R) Sandybridge Mobile (GT2)
[07:15] <RAOF> That one's nice :)
[07:17] <tvoss_> didrocks, just let me know when I can have fun on the arm builders, happy to take a look
[07:17] <didrocks> tvoss_: yeah, I pinged infinity, but no luck :/
[07:17] <tvoss_> didrocks, no pong or "no, you can't have fun on the builders"?
[07:18] <didrocks> no pong
[07:22] <duflu> I hate it when I wait a month for something to arrive, and then the wrong thing arrives
[07:22] <duflu> Day spoiled
[07:23] <alf_> duflu: :/
[07:36] <duflu> alf_: You mentioned it's a problem when the ground moves under your feet and MPs become conflicted... Yes I experienced this today as I have many times already. I don't think it's a problem we can avoid completely while so many people are working on Mir simultaneously
[07:36] <didrocks> alf_: look at https://code.launchpad.net/~didrocks/mir/remove-powerpc/+merge/175201 for the first part I guess :)
[07:36] <alf_> didrocks: thanks
[07:36] <didrocks> yw!
[07:38] <alf_> didrocks: Agreed. My point was that if we have too many such "disruptions", it will unavoidably slow down critical work, and it is a risk we should have in mind.
[07:38] <alf_> duflu: ^^
[07:38] <alf_> didrocks: sorry, wrong nick :)
[07:39] <didrocks> alf_: I started to think I hadn't enough coffee :p
[07:39] <duflu> alf_: Yes. I guess then large changes must be justified and have high value for helping future work... which usually large changes do
[07:40] <duflu> For example; a driver interface. It's a large change, but has high value
[08:23] <alan_g> duflu: why do you think the graphics namespace might "go away"?
[08:24] <duflu> alan_g: Because it makes no sense to designate part of Mir as "graphics" and other parts not graphics. It's all intended for graphics, so we should avoid the word
[08:25] <duflu> alan_g: "platform" ?...
[08:25] <alan_g> duflu: I concede that it is possible you can persuade the team to rename "graphics" to <something else>, but the namespace will still exist.
[08:26] <duflu> How?
[08:26] <duflu> alan_g: How would it still exist if it was renamed?
[08:26] <alan_g> As, for example, "platform"
[08:26] <RAOF> But Mir is not all intended for graphics; there's input, too.
[08:26] <alan_g> It will still have the same contents and role
[08:26] <duflu> RAOF: Almost all. The statement still holds :)
[08:27] <RAOF> In put is *at least* as big as graphics.
[08:27] <duflu> alan_g: Yes, true. Is your current proposal significantly different to just the namespace changes though?
[08:27] <duflu> I haven't looked at it all in detail
[08:28] <alan_g> yes, it moves stuff into that namespace
[08:28] <tvoss_> duflu, if we remove graphics, we should have a namespace platform
[08:29] <alan_g> Which is part of having a delineated garphics/platform API we can take to vendors
[08:29] <tvoss_> duflu, we almost certainly end up with prefixes like Graphics* and that's what namespaces are for
[08:29] <duflu> tvoss_, alan_g: Looking in more detail, I see we are moving things out of "compositor" that are platform independent. I don't think such things make sense in "platform" actually
[08:30] <duflu> Maybe "graphics" is just a stepping stone
[08:32] <alan_g> "graphics" is intentionally platform independent. That's why we have android and gbm implementations.
[08:33] <alf_> alan_g: ... which contradicts our moving platform independent code into it :/
[08:34] <alan_g> alf_: how does ""graphics" is intentionally platform independent" contradict " moving platform independent code into it :/"
[08:34] <alan_g> ?
[08:35] <alf_> alan_g: sorry, I read graphics (thinking gbm/android) is platform *dependent*, my comment is invalid
[08:45] <didrocks> alf_: still no review on my branch?
[08:49] <alf_> didrocks: done
[08:49] <didrocks> thanks ;)
[09:36]  * duflu goes stealth mode to avoid bugging Europe for the day (and vice versa)
[10:28] <hikiko> alf_, ping!
[10:28] <alf_> hikiko: pong
[10:28] <hikiko> hi
[10:28] <hikiko> do you have some time to ask you about the miron mir?
[10:30] <alf_> hikiko: sure
[10:31] <hikiko> https://lists.ubuntu.com/archives/mir-devel/2013-June/000166.html
[10:31] <hikiko> I have this as a reference but I am not sure about my design:
[10:32] <hikiko> mg::create_native_platform will be similar to current create_platform and leave in gbm/android
[10:32] <hikiko> mg::create_nested_platform will be similar to create_platform and in nested_platform.cpp
[10:33] <hikiko> and the create_native_platform_nested will call both?
[10:34] <hikiko> if the native platform doesn't know anything about the nested platform
[10:35] <alf_> hikiko: @mg::create_nested_platform, as things have evolved, you can probably skip this function and instantiate NestedPlatform directly (because it will live in libmirserver)
[10:35] <hikiko> yes but where?
[10:36] <hikiko> if it's required that
[10:36] <alf_> hikiko: @mg::create_native_platform_nested, this will create a native platform configured for nested functioning (e.g. no drm, no vt)
[10:36] <hikiko> sure but
[10:36] <hikiko> my question is:
[10:37] <alf_> hikiko: you can select which platform to create in DefaultServerConfiguration::the_graphics_platform()
[10:40] <hikiko> so I choose there to create the native_platform_nested and this does the rest
[10:41] <hikiko> I mean I just have to load the right callback
[10:44] <alf_> hikiko: at that point you should create either 1. the native platform: with mg::create_native_platform or 2. the nested platform: use the NestedPlatform class. We can start with NestedPlatform calling mg::create_native_platform_nested() internally to create the native platform in "nested" mode.
[10:47] <hikiko> got it :)
[10:48] <hikiko> thanks alan_g
[10:48] <hikiko> alf_*
[10:48] <hikiko> :)
[10:48] <alan_g> hikiko: yw
[10:48] <hikiko> hahaha
[10:52] <tvoss_> greyback, ping
[10:52] <greyback> tvoss_: pong
[15:21] <tvoss_> something is flakey in our armhf tests
[15:25] <tvoss_> dear armhf machine, faster please
[15:26] <bregma> tvoss_, can you be more specific about the flakiness?
[15:26]  * bregma is not disagreeing
[15:27] <tvoss_> bregma, I'm not entirely sure, but the file-based sync mechanism should be totally reliable albeit a bit unelegant :)
[15:27] <tvoss_> however, I do see the clients starting in strace and immediately exiting with 0
[15:29]  * bregma goes off to play with the synch mech
[15:30] <tvoss_> bregma, a pipe should help :)
[15:51]  * tvoss_ thinks that he could help the armhf build machine a little in translating to assembler
[15:56] <tvoss_> bregma, I have something like http://pastebin.ubuntu.com/5884664/ in mind
[16:00] <bregma> might want to epoll/signal in the wait to avoid a deadlock (does pipe() close if the writer exits without a shutdown()?)
[16:01] <tvoss_> bregma, should, feel free to adjust ... if you can take care of that sync mechanism in the acceptance tests, I willl look into the flakiness
[16:01] <tvoss_> I think it comes down to an unholy combination of buildd, kernel version, epoll and reactors
[16:01] <tvoss_> just triggered a rebuild
[16:02] <bregma> sure, but your rebuilds are still faster than mine
[16:02] <tvoss_> bregma, not sure :)
[16:54] <smspillaz> 1
[16:54] <smspillaz> :(
[16:55] <alan_g> smspillaz: ?
[16:56] <smspillaz> alan_g: older versions of byobu required you to select a screen session whenever you launched byobu
[16:56] <smspillaz> newer versions automatically resume your first
[16:56] <smspillaz> So I have a muscle-memory of byobu-1 which ends up in me saying "1"  a lot
[16:57] <alan_g> Yes I guessed that
[16:57] <alan_g> All change is bad
[17:33] <bregma> d'oh, fork() and RAII do not mix well
[18:47] <racarr> Hours of stress testing -> lunch
[19:00] <tvoss_> bregma, any more insight on your side?
[19:02] <racarr> Ah! I had one more idea and failed to leave for lunch...and then now I think I finally found it
[19:02] <racarr> (stress test)
[19:05] <racarr> well it finally makes sense why it crashes at least
[19:05] <racarr> NOW real lunch
[19:15] <kdub> rvalue fun
[19:46] <bregma> tvoss_, I'm fairly certain there's a race condition when the socket is destroyed by multiple child processes in the tests, but I'm still looking for concrete proof .. good news is I can repro locally now (after a 6 hour build)
[19:47] <bschaefer> bregma, are you getting a pure virtual function called? Causing it to crash? (I've ran into that when attempting to close the mir server before...)
[19:47] <bschaefer> or close a connection to the server
[19:48] <bregma> bschaefer, there is a deadlock where the test case is waiting for a signal but the child (signaller) has exited beforre the wait begins (qhich itself is a sequencing problem)
[19:48] <bschaefer> bregma, oo different problem then :)
[19:49] <bschaefer> bregma, children should learn to wait!
[19:49] <bregma> indeed
[19:52] <tvoss_> bregma, \o/
[19:52] <tvoss_> bregma, I will EOD now
[20:16] <thomi> morning
[20:17] <racarr> Morning
[20:27] <racarr> this stress-test race is a little deeper than just adding a mutex or something struggling a bit to find a solution even now that it's found
[20:29] <racarr> kdub: I feel like the general theme may interest you
[20:30] <racarr> msh::Surface is almost impossible to use safely outside of the scope of the Session that owns it
[20:31] <racarr> because, say, when a surface is closed, so we have to find a new surface to focus, so we find it and get a shared_ptr<msh::Surface>
[20:31] <racarr> and then call surface.anything()
[20:31] <racarr> and then another thread closes the surface
[20:32] <racarr> so your msh::Surface pointer is stlil valid but surface.anything()
[20:32] <racarr> throws...
[20:32] <racarr> because the ms::Surface is gone
[20:33] <racarr> I guess, you need session to act as a synchronization point so rather than like
[20:34] <racarr> bla = session.default_surface()
[20:34] <racarr> bla.take_input_focus(targeter)
[20:35] <racarr> you can do like session.take_input_focus_on_default_surface(targeter)
[20:35] <racarr> and the session will hold it's internal lock preventing a close_surface from being processed
[20:36] <racarr> but this feels unsatisfying and unscalable
[20:39] <racarr> The other immediate direction that comes to mind is exposing locks out of the session as API, i.e. msh::Session::Freeze f(session);, but this seems really error prone.
[20:40] <racarr> So maybe what you really want, is some way to promote a surface pointer, i.e. surface.no_really_block_any_thread_that_is_trying_to_destroy_this_surface_until_the_return_value_of_this_function_is_destroyed
[20:41] <racarr> so now I start to think that these are transactions
[20:41] <racarr> and wonder what Alan's thoughts so far are on the new scenegraph model ;)
[20:42] <racarr> because these sort of inconsistencies, are what the hypothetical group-mind scenegraph model is supposed to be able to solve
[20:43] <racarr> Another random API idea: session.transcation(std::function<void>())
[20:43] <racarr> which freees the session (with a recursive mutex)
[20:43] <racarr> and then invokes the callback
[20:43] <racarr> so this way you can write like
[20:44] <racarr> session.transaction([&](Session& s) { auto surface = s.default_surface(); surface.take_input_focus(); }
[20:44] <racarr> and anything calling i.e. Session::destroy_surface
[20:44] <racarr> will block until your transaction is complete
[20:45] <racarr> It's not really a transaction
[20:45] <racarr> because it's not reapplicable, what is it...
[20:47] <racarr> it's like an atomic operation. but it's not clear what session.atomically_do means (atomic with respect to what?)
[20:50] <robert_ancell> racarr, can you merge lp:~robertcarr/mir/simplify-depth-assignment with trunk?
[20:50] <racarr> robert_ancell: Yeah doing so now
[20:50] <robert_ancell> cool
[20:50] <racarr> robert_ancell: I finally found the stress race :)
[20:50] <racarr> in a way that explained the weirdness from yesterday and everything
[20:50] <racarr> so uite happy
[20:50] <robert_ancell> \o/ awesome!
[20:51] <robert_ancell> me too :)
[20:51] <racarr> but the solution is a little tricky
[20:51] <robert_ancell> and thomi too I expect
[20:51] <racarr>  /unclear
[20:51] <thomi> hmmm?
[20:51] <kgunn> robert_ancell: hope it clears some other stuff
[20:51] <kgunn> too
[20:51] <thomi> racarr: cool!
[20:52] <thomi> racarr: when you have a branch with the fix, let me know and I'll review your MP and test it here
[20:52] <thomi> I seem to be able to trigger these things more easily than most people
[20:52] <racarr> XD I get it like
[20:52] <racarr> ALWAYS
[20:52] <kgunn> hey, does anyone know any special fiddling required to run a system with both nvidia & intel gfx ?
[20:52] <racarr> within a second
[20:52] <thomi> apparently my CPU isn't just hyper-threaded, it's hyper-mega-awesome-threaded
[20:52] <kgunn> i know RAOF said his ran
[20:52] <thomi> racarr: awesome :)
[20:53] <kgunn> do you just load nouveau for nvidia and everything else should he "happy happy happy" ?
[20:53] <kgunn> oops/he/be
[20:54] <racarr> kgunn: When I had hybrid graphics the special fiddling was always disable one in the BIOS ;) not sure if you are hoping to do more than that
[20:54] <kgunn> nope....dandrader was trying xmir and having issues...i'll share tht
[20:55] <racarr> oh god. what an awful merge conflict
[20:56] <kgunn> racarr: thx for it
[20:56] <racarr> :)
[20:57] <kgunn> racarr: dandrader was looking for something fun...i told him he'd get a couple of beers from me if he solves the input lag
[20:57] <racarr> you mean the output lag!
[20:57] <racarr> or was that a dream
[20:57] <racarr> sometimes the team meeting is hard to remember
[20:57] <kgunn> racarr: right
[20:57] <kgunn> all depends....:)
[20:57] <kgunn> and i think most correctly...yet to be determined lag
[20:58] <kgunn> racarr: btw...i capture 2 other "please add api" tasks in the unity prep bp
[20:58] <kgunn> 1 for osk surfacetype
[20:58] <kgunn> and 1 for greeter
[20:59] <kgunn> i figure you know what they are....but if not....ping dandrader for osk & mterry for greeter
[20:59] <racarr> I think I do
[20:59] <racarr> simplify-depth-assignment is the first part of the greeter fix
[21:00] <racarr> buttttttttttttttttttttttttttttttttttttttttttttt the second part isn't clear to me yet
[21:00] <racarr> ill make sure I don't lose track of them :)
[21:05] <racarr> robert_ancell: Merging simplify-depth-assignemtn will take a while
[21:05] <racarr> something...strange landed
[21:05] <racarr> and I can't even understand how the tests pass in trunk
[21:05] <robert_ancell> racarr, np, was just checking you'd seen it
[21:05] <racarr> all the tests which are supposed to test depth ID
[21:05] <racarr> got replaced with default_depth
[21:06] <racarr> oh and then they pass because the expectations got reordered
[21:06] <racarr> to make them pass
[21:06] <racarr> -.-
[21:31] <racarr> -.-
[21:31] <racarr> all the surface stack ordering tests are broken
[21:31] <racarr> because they verify by comparing the reference to the rendering criteria and the buffer stream
[21:32] <racarr> but they all use stub buffers that share the same
[21:32] <racarr> rendering criteria and buffer stream
[21:32] <racarr> so by broken I mean they always pass
[22:27] <racarr> I think I have decided on (at least for a first proposal) this msh::Session::perform_transaction(std::function)
[22:27] <racarr> API.
[22:27] <racarr> The test is difficult to design though.
[22:28] <racarr> the, test should verify that during the body of the function argument to perform_transaction
[22:28] <racarr> calls to create/destroy surface block
[22:28] <racarr> it should also not be a racy test ;)
[22:36] <racarr> one interesting possibility, requiring some serious pthread nastiness
[22:36] <racarr> is first you have to pin your test thread to one core, and set pthread sched param to
[22:37] <racarr> SCHED_FIFO
[22:37] <racarr> then you create a session, and a surface and call perform_transaction
[22:37] <racarr> in your body, you start a new thread, which calls session.destroy_surface
[22:38] <racarr> oh and the new thread also needs to be pinned to the same core
[22:38] <racarr> so then after you strt the new thread, the test yields guaranteeing your surface destroying thread will run now
[22:39] <racarr> since they are both pinned to the same core, and scheduling mode is SCHED_FIFO
[22:39] <racarr> the thread is guaranteed to continue to run until it blocks or yields
[22:40] <racarr> so, in the test thread, right after you yield, you can check if the surface has been destroyed
[22:40] <racarr> if it has, then create_surface blocked (otherwise that thread would still be executing and will have finished destroying the surface)
[22:41] <racarr> err, if it hasn't*
[22:41] <racarr> if it has, then clearly create_surface succeeded
[22:41] <racarr> and you have deterministic test results, i.e. create_and_destroy_surface_block_during_body_of_transaction
[22:42] <thomi> robert_ancell: I notice that u-s-c has no license file!?
[22:43] <robert_ancell> thomi, I guess. It has license headers
[22:43] <robert_ancell> feel free to add one
[22:46] <racarr> I have the sick feeling that that test
[22:46] <racarr> would never land
[22:47] <thomi> robert_ancell: will do
[22:50] <thomi> robert_ancell: https://code.launchpad.net/~thomir/unity-system-compositor/add-license-file/+merge/175422
[22:51] <racarr> I dont think it's even possible to use SCHED_FIFO without root XD
[22:55] <racarr> I'm not sure this test is even possible as a normal user
[22:55] <racarr> because threads and processes are the same to the linux scheduler
[22:56] <racarr> so any program that can guarantee a thread executes
[22:56] <racarr> until it blocks
[22:56] <racarr> can bring down a single core system :p
[22:56] <racarr> but really I just want to guarantee, that another particular thread wont execute until that thread blocks
[22:57] <racarr> It's not actually a realtime requirement, I don't care if the kernel lets other processes run
[23:04] <thomi> robert_ancell: for this autopilot test, what's the best way of figuring out what hardware is running?
[23:29] <racarr> what I need is PTHREAD_SCOPE_PROCESS
[23:29] <racarr> but it's no tsupported on linux...
[23:29] <racarr> lol
[23:34] <RAOF> Really? That's odd.
[23:35] <racarr> RAOF: Actually linux pthread implementation seems to be roughly
[23:36] <racarr> the least expressive pthread implementation allowed by the specification
[23:36] <racarr> because of the lack of distinction between
[23:36] <racarr> threads and processes.
[23:36] <racarr> ahaha
[23:36] <racarr> I am not happy about pthreads atm if you can tell
[23:37] <RAOF> You could probably rube-golberg up the behaviour you want with an extra thread, right?
[23:38] <racarr> RAOF: I can't figure out a way...
[23:38] <RAOF> ie: a watchdog thread that monitors the thread you're interested in, and sets a flag when it's blocked.
[23:38] <racarr> can't
[23:38] <racarr> do that either in linux
[23:39] <racarr> i.e. tell if a thread is blocked
[23:39] <RAOF> What do we mean by “blocked” in this case?
[23:39] <racarr> RAOF: voluntarily yielded
[23:40] <racarr> RAOF: So the idea is, I am developing this API like session.do_transaction(std::function)
[23:40] <racarr> for solving...a series of other races, the stress test stuff
[23:40] <racarr> so, the semantics it needs to provide are
[23:40] <racarr> create_and_destroy_surface_block_during_body_of_transaction_function
[23:41] <racarr> so as far as I can see, the only way to deterministically test that is to
[23:41] <racarr> start a second thread from within your transaction callback, which tries to destroy a surface
[23:42] <racarr> and then guarantee that that thread runs until it blocks
[23:42] <racarr> i.e. isn't preempted by your original thread
[23:43] <racarr> because otherwise, all you can say is "that thread hasn't gotten to destroy surface yet..." (or rather, whatever instruction in the implementation of destroy surface the lock is actually held on)
[23:43] <RAOF> You should be able to parse /proc to assert that the thread isn't running?
[23:43] <racarr> but whatever code does that
[23:44] <racarr> might preempt the thread
[23:44] <racarr> and then it wont be running
[23:45] <racarr> i.e. the thread might exhaust it's timeslice and be stopped from running beore it actually blocks
[23:45] <racarr> so, an easy fix is to use
[23:45] <racarr> SCHED_FIFO
[23:45] <racarr> and pin both threads to the same core
[23:45] <racarr> but, because there is no PTHREAD_SCOPE_PROCESS
[23:46] <racarr> SCHED_FIFO requires root, and can bring down your entire system
[23:46] <racarr> lol
[23:46] <RAOF> Eh, it's a testsuite.
[23:46] <RAOF> They're pretty much allowed to bring down your system ☺
[23:46] <RAOF> piglit does all the time!
[23:46] <racarr> yeah but can they run as root?
[23:46] <racarr>  / with some weird RT capability flag
[23:47] <RAOF> Why can't they?
[23:47] <racarr> I dunno
[23:48] <racarr> I guess I just kind of assume someone would object and stop that from landing
[23:48] <racarr> I don't mean anyone in prticular, I just mean it sounds really
[23:48] <racarr> objectional
[23:48] <racarr> lol
[23:48] <racarr> BUG: Can't run tests as non root user!
[23:48] <racarr> haha, I guess it can just be a disabled test.
[23:48] <RAOF> We build the packages as root already, so setting the RT capability on the tests shouldn't be _too_ bad.
[23:49] <racarr> mm.
[23:49] <racarr> ok, those are all very good points.
[23:50] <racarr> XD, Thank you
[23:50] <racarr> I was kind of spinning from "Can't use SCHED_FIFO"
[23:50] <racarr> and just going deeper down that line
[23:50] <racarr> and reading very strange websites about freebsd
[23:50] <RAOF> Damn it takes *forever* to build an Ubuntu kernel.
[23:51] <RAOF> You try and add one piece of functionality to dma-buf, you're waiting hours for it to build!


[21:27] <ebel> I am really not liking the new ubuntu release
[21:27] <ebel> I just upgraded there yesterday
[21:28] <ebel> There is no typing break. ☹


[03:44] <liberskym> Is anyone available?
[10:29] <decoder> suggestion for updating:
[10:29] <decoder> when the user has chosen "ubuntu classic" previously
[10:29] <decoder> the update should honor that
[10:29] <decoder> and not force switch back to unity
[10:30] <decoder> that causes major support issues because people dont know what to do when they were on gnome before by explicit setting
[10:30] <decoder> (not to mention that even less people will use unity like that because it's bad UX)
[11:08] <ikt> decoder: suggestion for 12.04?
[11:09] <ikt> would be best making a post to ayatana
[11:09] <ikt> mailing list
[11:14] <ikt> another issue :(
[11:14] <ikt> for some reason playing audio through my x-fi is horrible
[11:14] <ikt> but on my asus it works fine
[11:15] <ikt> heya penguin42 :)
[11:16] <penguin42> Good Morning ikt
[11:16] <ikt> penguin42: I take it by the co.uk hostname you just got up over there in the uk?
[11:17] <penguin42> ikt: Yeh - it's just gone noon but hey it's the weekend!
[11:17] <ikt> haha
[11:17] <ikt> I was a little scared because you're in the uk
[11:17] <ikt> and I just woke up 4 hours ago
[11:17] <ikt> waking up at 5pm is not good :x
[11:23] <penguin42> well that depends what you were up to the night before :-)
[11:25] <sroecker> hi, does Launchpad recognize when I upload a fixed package to my PPA? See bug #872967
[11:25] <ubot4> Launchpad bug 872967 in gdk-pixbuf (Ubuntu) (and 1 other project) "gdecrypt wont start: picture format unknown (affects: 3) (heat: 18)" [Undecided,New] https://launchpad.net/bugs/872967
[11:26] <penguin42> sroecker: Well it can't know what you fixed in a PPA I don't think
[11:28] <penguin42> sroecker: You can attach a patch to the bug, and add the tag patch
[11:29] <sroecker> penguin42: ok
[11:29] <penguin42> sroecker: Is your fix to gdecrypt or gdk-pixbuf?
[11:30] <sroecker> penguin42: to fix gdecrypt, gdk-pixbuf is still broken
[11:31] <sroecker> but at least gdecrypt works
[11:31] <penguin42> sroecker: So is your patch a work around in gdecrypt to work around the gdk-pixbuf problem or does it fix a real problem in gdecrypt?
[11:32] <sroecker> penguin42: it only catches the exception when the icon can't be loaded, which is missing anyway. program works without the icon
[11:33] <penguin42> sroecker: Hmm, so if gdk-pixbuf was fixed would you still need your patch?
[11:34] <sroecker> penguin42: I would guess it's better coding practice to not quit when an icon can't be loaded. Had a similar bug in arista
[11:35] <sroecker> bug #814911
[11:35] <ubot4> Launchpad bug 814911 in arista (Ubuntu) "arista-gtk crashed with GError in setup_source(): Icon 'camera-video' not present in theme (affects: 17) (dups: 13) (heat: 141)" [Undecided,Confirmed] https://launchpad.net/bugs/814911
[11:36] <penguin42> sroecker: OK, so what's the gdk-pixbuf bug then?
[11:37] <sroecker> penguin42: it fails to load a SVG, so maybe it's librsvg related
[11:38] <sroecker> funny thing is, eog can display the SVG
[11:39] <sroecker> will have a look at that later
[11:39] <penguin42> sroecker: OK, I was wondering whether to change the state to triaged; but since you don't actually know why gdk-pixbuf is fighting, I'm not sure it's right to do that
[17:14] <penguin42> does anyone know if there is a good signature of bug 873468 - or is anyone that moans about ubuntu-minimal to get lumped in with that?
[17:14] <ubot4> Launchpad bug 873468 in update-manager (Ubuntu Precise) (and 1 other project) "Update to latest Release failed for overloaded mirrors with no descriptive error message (affects: 100) (dups: 58) (heat: 524)" [Medium,Triaged] https://launchpad.net/bugs/873468
[20:58] <njin> hello, can someone triage better bug 883533 thanks
[20:58] <ubot4> Launchpad bug 883533 in unity (Ubuntu) "HighContrast miss shutdown button (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/883533


[22:15] <andrew_sayers> mdke: Needless to say, I disagree about IE6 with the site I linked to :)
[22:15] <mdke> ok
[22:15] <mdke> I don't think th comparison with firefox is a valid one
[22:15] <andrew_sayers> How so?
[22:16] <mdke> firefox respects web standards, and ie6 doesn't. More importantly, it has been superceded by ie7
[22:16] <mdke> it's not like it's an up and coming browser with a valid reason for people to keep making efforts to support it
[22:16] <mdke> especially if those efforts involve going out of one's way
[22:17] <mdke> as long as it works, and the site isn't broken, I'm happy
[22:17] <mdke> www.ubuntu.com has a number of substantial issues with IE6, and the approach was taken that as long as it is readable, it's ok
[22:17] <mdke> now you go :)
[22:18] <andrew_sayers> I'll stick to one point at a time, so here's my first argument :)
[22:18] <andrew_sayers> Doesn't that make us look like zealots?
[22:18] <mdke> no, I don't think so
[22:18] <andrew_sayers> Either you ditch your solution of choice, or you're a second class citizen?
[22:19] <mdke> that's not zealotry. People make choices like that all the time
[22:19] <andrew_sayers> Hmm, can you give me an example?
[22:19] <mdke> if the interests of 5% of users had to be catered for, no one would ever get any software UI work done
[22:20] <andrew_sayers> That's where the FF argument comes in though.
[22:21] <mdke> not really. To support firefox, all web designers had to do was to support web standards
[22:21] <andrew_sayers> Or if you prefer, colour blind people, properly blind people, people with JS disabled, people that use Dvorak keyboards...
[22:21] <mdke> right, people with JS disabled is another good example
[22:22] <mdke> obviously things should work without JS enabled, but that doesn't mean that it should never be used to improve a site for those who enable it
[22:22] <mdke> actually, for the theme, we're trying to use a JS solution for the editbar
[22:22] <mdke> to work around that issue you encountered with the firefox "find" utility
[22:22] <andrew_sayers> Yeah, I noticed something about that.
[22:23] <andrew_sayers> I have no problem with adding extra functionality where possible, my problem is with breaking basic stuff that doesn't have to be broken.
[22:24] <andrew_sayers> E.g. add colour to a website, but don't communicate information purely with colour, because of colour blindness.
[22:24] <mdke> yes, I understand that
[22:25] <mdke> what's the solution you had in mind for IE6?
[22:26] <andrew_sayers> For which issue?
[22:26] <mdke> the image transparency
[22:26] <andrew_sayers> Use the icons I provided.
[22:26] <andrew_sayers> Or alternatively, I'll do the same to the other icons.
[22:26] <mdke> and what is it that you did?
[22:26] <andrew_sayers> Converted the transparent background to the relevant colour.
[22:27] <andrew_sayers> (Yellow for hint, red for warning, etc.)
[22:27] <mdke> ok
[22:27] <mdke> that kinda makes it more difficult to change the colours in the future, I guess?
[22:28] <andrew_sayers> Yeah, although you seem to be saying you like it that way?
[22:28] <andrew_sayers> We can always keep the originals around.
[22:28] <mdke> no, that's not what I'm saying
[22:28] <andrew_sayers> (That we should hard-code the background colours, rather than putting it in the theme)
[22:29] <mdke> but it's not more difficult to edit the colours in the macro.py than it is to edit them in the theme.css
[22:29] <mdke> it's the same number of type strokes
[22:29] <mdke> but redoing the images is a bigger thing
[22:30] <mdke> which wouldn't be necessary with transparent images
[22:30] <mdke> also, using transparent images means we can use interchangeable icons with the system docs, which would be nice and simple
[22:30] <mdke> i guess one weighs these things up when considering whether to make the effort for IE6
[22:31] <andrew_sayers> Yeah - that was another point.  On a philosophical level, I feel the relationship between developer and user should be pretty unequal.
[22:31] <andrew_sayers> On a practical level, most remaining IE6 users aren't that way by choice.
[22:32] <andrew_sayers> Hmm... we can always give IE users different icons.
[22:33] <mdke> uhoh
[22:33] <andrew_sayers> Which makes the worst case (if we change BG colours) no different to the current case.
[22:34] <andrew_sayers> (Although this takes us way into "ugly hack" territory)
[22:34] <mdke> let's go with the edited images for everything. I'm sure it's easy enough to add the background and we'll have the transparent icons around for future reference if we change the colours
[22:34] <andrew_sayers> Fair enough.
[22:35] <andrew_sayers> But the GNOME icons rather than the current ones?
[22:35] <mdke> well, I like them more. But I'd like others to agree before signing off, on the basis that we would be changing them in the system docs too
[22:35] <mdke> do you like theme?
[22:35] <mdke> them*
[22:35] <andrew_sayers> I'll look again, gimme a mo...
[22:36] <andrew_sayers> I prefer the tip, think the caution is better implemented, but don't really like the note.
[22:36] <andrew_sayers> If it's an either/or choice, I'd say go with the GNOME ones.
[22:37] <mdke> :)
[22:37] <mdke> I don't really like the previous note icon, it's a bit oldfashioned and I don't see the use of having text in it
[22:38] <andrew_sayers> I quite like the text, but more importantly, I like that it's a small light rectangle - a big bright square is kinda offputting to me.
[22:39] <mdke> hmm
[22:39] <mdke> would you want to change the background colours if we switch icons?
[22:39] <andrew_sayers> Preferably, yeah.
[22:39] <mdke> I thought you would say that
[22:40] <mdke> damn perfectionists
[22:40] <andrew_sayers> :)
[22:41] <mdke> ok. Let's get the macro into review and on the wiki with the existing icons, and think about new icons at a later stage then. the work has all been done on that basis
[22:41] <mdke> can you send me the png files with the coloured backgrounds?
[22:41] <andrew_sayers> Well, hang on...
[22:41] <andrew_sayers> If you want the macro to work with old themes unmodified, we'll need to change the macro.
[22:41] <andrew_sayers> Since at present you'll just see an unstyled table.
[22:42] <mdke> you mean because the css isn't in the theme?
[22:43] <andrew_sayers> It's not in the old themes, yeah.
[22:43] <mdke> that's ok, I think. The ReleaseVersion macro requires css to be added to the theme too
[22:44] <andrew_sayers> Hmm.
[22:44] <andrew_sayers> I would think that either the CSS and image should be theme-specific, or neither should be.
[22:44] <mdke> most macros like that require css to be added to the theme, I think
[22:45] <andrew_sayers> Having them disagree sounds like a maintenance problem to me.
[22:45] <mdke> andrew_sayers: maybe you're right
[22:46] <mdke> ok, let's face it that I need to merge your other revisions too :)
[22:47] <andrew_sayers> Each of these opinions is a reaction to an old scar from making the opposite choice long ago :)
[22:47] <mdke> ok. I'll do the merge
[22:48] <andrew_sayers> Thanks.
[22:48] <andrew_sayers> Would you rather wait for me to put some more icons in?
[22:49] <mdke> I think these will work fine
[22:51] <andrew_sayers> Fair enough, although the icons are now done - I'll e-mail them?
[22:52] <mdke> ok, thanks. Maybe off-list
[22:52] <andrew_sayers> Yeah, good idea.
[22:52] <mdke> gtg to bed now
[22:52] <mdke> thanks for the chat
[22:52] <andrew_sayers> Night night.
[22:52] <andrew_sayers> Thanks for scratching the itch :)


[11:56] <emgent> morning
[12:59] <|DuReX|> https://bugs.launchpad.net/ubuntu/+bug/235889 could somebody check ? :)
[22:11] <|DuReX|> can somebody plz take a look @ https://bugs.launchpad.net/ubuntu/+bug/235889
[22:11] <|DuReX|> its kinda important for me


[22:12] <MarkDude> https://twitter.com/TheCommunitizer/status/732688392819900416
[22:12] <MarkDude> Mangyan Ambahan to Tagalog to Baybayin
[22:13]  * MarkDude is hella proud of this. Makatang puti ako
[22:13] <MarkDude> :D


[07:49] <mup> Bug #1885682 opened: Chrony configuration not updated <MAAS:Triaged by ack> <https://launchpad.net/bugs/1885682>
[07:58] <mup> Bug #1885682 changed: Chrony configuration not updated <MAAS:Triaged by ack> <https://launchpad.net/bugs/1885682>
[08:01] <mup> Bug #1885682 opened: Chrony configuration not updated <MAAS:Triaged by ack> <https://launchpad.net/bugs/1885682>
[08:07] <mup> Bug #1883752 changed: the installation procedure recommends the 2.8 snap, but it has no stable channel <MAAS:Fix Released> <https://launchpad.net/bugs/1883752>
[08:07] <mup> Bug #1885687 opened: hostname resolution of machines in different region don't work in dns-ha <MAAS:New> <https://launchpad.net/bugs/1885687>
[08:10] <mup> Bug #1885687 changed: hostname resolution of machines in different region don't work in dns-ha <MAAS:New> <https://launchpad.net/bugs/1885687>
[08:10] <mup> Bug #1883752 opened: the installation procedure recommends the 2.8 snap, but it has no stable channel <MAAS:Fix Released> <https://launchpad.net/bugs/1883752>
[08:13] <mup> Bug #1883752 changed: the installation procedure recommends the 2.8 snap, but it has no stable channel <MAAS:Fix Released> <https://launchpad.net/bugs/1883752>
[08:13] <mup> Bug #1885687 opened: hostname resolution of machines in different region don't work in dns-ha <MAAS:New> <https://launchpad.net/bugs/1885687>
[08:16] <mup> Bug #1885687 changed: hostname resolution of machines in different region don't work in dns-ha <MAAS:New> <https://launchpad.net/bugs/1885687>
[08:16] <mup> Bug #1883752 opened: the installation procedure recommends the 2.8 snap, but it has no stable channel <MAAS:Fix Released> <https://launchpad.net/bugs/1883752>
[08:19] <mup> Bug #1883752 changed: the installation procedure recommends the 2.8 snap, but it has no stable channel <MAAS:Fix Released> <https://launchpad.net/bugs/1883752>
[08:19] <mup> Bug #1885687 opened: hostname resolution of machines in different region don't work in dns-ha <MAAS:New> <https://launchpad.net/bugs/1885687>
[09:55] <mup> Bug #1885694 opened: Flaky test: maasserver.models.tests.test_bmc.TestPod.test_sync_hints_from_nodes <flaky-test> <MAAS:Triaged> <https://launchpad.net/bugs/1885694>
[15:46] <mup> Bug #1885739 opened: cannot compose VM when static IP assigned is reserved in DNS <cpe-onsite> <MAAS:New> <https://launchpad.net/bugs/1885739>
[20:20] <mup> Bug #1885777 opened: MAAS Fails to Connect to LXD Host <MAAS:New> <https://launchpad.net/bugs/1885777>


[04:29] <bazhang> nogo seems to think that being banned from -ot gives him license to be offtopic in +1 and #ubuntu
[06:54] <cyberix> could someone try downloading this http://archive.canonical.com/ubuntu/pool/partner/s/sun-java6/sun-java6-bin_6.21-1ubuntu1_amd64.deb
[06:54] <cyberix> It stops before reaching 4MB
[06:54] <cyberix> I do not understand why
[11:18] <knome> cyberix, worksforme. if there is nothing else we can help you with, please part the channel as we have a no-idle policy.
[11:26] <Tm_T> cyberix: also this is not the channel to ask such things usually (; (ja moi)
[13:37] <bazhang> supremo (nogo) in -ot
[13:50] <ikonia> explain
[14:00] <knome> bazhang, he's @#x as well
[14:01] <ikonia> ?
[14:01] <knome> "at #xubuntu"
[14:01] <bazhang> gobo nogo chonema multiple ban evasions in -ot ikonia
[14:02] <ikonia> is he known ?
[14:02] <ikonia> so he's evading now in OT ?
[14:02] <bazhang> yep. insane rantings about Chinese spying, etc etc
[14:02] <knome> well his comment @#x ringed my alarm bells as well
[14:02] <ikonia> is he evadind in #xubuntu
[14:03] <ikonia> evading
[14:03] <knome> no
[14:03] <bazhang> not afaik
[14:03] <ikonia> cool
[14:03] <bazhang> network wide issue though
[14:03] <ikonia> I'm sure
[14:12] <ikonia> is he banned in #ubuntu+1 ?
[14:12] <ikonia> I can't see it
[14:12] <bazhang> nope
[15:13] <kaddi> hi, I have been banned from ubuntu and I don't know why.. could someone shed some light?
[15:18] <ikonia> kaddi: one moment please
[15:21] <kaddi> I'm using a webchat client atm, but only because my pc no longer boots
[15:21] <ikonia> kaddi: I'm struggling to find a ban for you, do you know when you where banned
[15:21] <kaddi> no, it just told me [16:11] == #ubuntu Cannot join channel (+b) - you are banned even after I idnetified
[15:22] <kaddi> last time i could join just fine.. must have been 2-3 weeks ago though
[15:22] <ikonia> just looking now
[15:24] <ikonia> kaddi: do you use any other nicknames ?
[15:25] <kaddi> no, but I jsut logged in from teh unbootable machine with a default quassel config.. if that is what you are seeing
[15:25] <kaddi> i guess it must be the webclient they don`t like
[15:25] <ikonia> no, I'm just struggling to see a reason you're banned
[15:25] <ikonia> ahhh wait
[15:25] <kaddi> maybe because i first tried to join without an identified nick froma  webchat?
[15:26] <ikonia> kaddi: you should have been forwarded to the channel #ubuntu-proxy-users which will then grant you access to the channel
[15:26] <ikonia> kaddi: try manually joining that channel, I'll have a look why that's not worked
[15:26] <kaddi> k
[15:26] <kaddi> worked this time round
[15:27] <ikonia> just saw
[15:29] <kaddi> you want me to leave and try to rejoin?
[16:12] <IdleOne> ikonia: probably just need to reset the forward to -proxy-users
[16:15] <IdleOne> can someone reset the ban on *!*@gateway/web/*$#ubuntu-proxy-users in #kubuntu please
[16:15] <IdleOne> done in #u
[16:20] <IdleOne> Spoke to Dalton, he said he disabled what ever script he was running that spams the host of op and mask of user in modes set in channel.
[16:25] <jussi> ikonia: pm?
[16:28] <ikonia> sure sure sure
[16:28] <jussi> :D
[17:56] <IdleOne> done
[18:32] <IdleOne> what did nikkita do?
[18:33] <IdleOne> I missed something :/
[18:33] <jussi> IdleOne: you missed the hitler comments?
[18:33] <IdleOne> I did
[18:33] <jussi> [20:29:59] <-> hitlet is now known as h1tler
[18:33] <jussi> [20:30:05] <h1tler> brb killing jews
[18:33] <jussi> [20:30:09] <-> h1tler is now known as nikkita
[18:33] <IdleOne> I just saw them now on scroll back
[18:34] <IdleOne> I didn't see the nick change so was looking for nikkita and missed the hitler crap
[18:34] <jussi> and the other dungeon one
[18:35] <IdleOne> I saw that but wasn't sure what it was about
[18:36] <IdleOne> not having the full context and all
[18:37] <topyli> FOCUS!
[18:37] <topyli> :)
[18:38] <IdleOne> sorry :(
[18:38] <topyli> hehe
[18:38]  * IdleOne flogs himself *mia culpa, mia culpa*
[18:39] <topyli> i just stopped that and got out of the sauna
[18:39] <IdleOne> seems my highlight list is longer then the amount of words I use in daily conversation
[18:39] <IdleOne> just going to start highlighting *
[20:16] <IdleOne> Braber01 enjoys pushing the envelope of topicness
[23:32] <bazhang> Lauterino> ActionParsnip: Keep an eye out for illicit infiltrations. This is all i want. Be well my friend.
[23:32] <bazhang> ?


[01:41] <bradleyayers> I'm a bit confused about what http://upstart.ubuntu.com/cookbook/#restarting-jobs-with-complex-conditions means
[01:42] <bradleyayers> I was under the impression that upstart tracked the state of jobs, and would start jobs when their conditions were met
[01:43] <bradleyayers> would the situation (in that link) be any different if a 'stop on …' was defined?
[01:44] <bradleyayers> would it be any different if 'respawn' was specified?
[06:29] <SpamapS> bradleyayers: upstart tracks the state of jobs, but it only changes their goal-state on events, not conditions. Its a subtle difference.
[06:31] <SpamapS> bradleyayers: that section is a bit ambiguous.. I'm going to propose a slight change.
[06:32] <bradleyayers> so say i have a job X that "start on started A and started B", and "stop on stopping A or stopping B". A starts, then B starts, so 'started JOB=B' would be emitted, which would cause X to start right?
[06:32] <bradleyayers> then B changes its goal to stopped, so 'stopping JOB=B' would be emitted, which would cause X to change its goal to stopped, right?
[06:33] <bradleyayers> so then let's say X stops, then B stops
[06:33] <bradleyayers> what happens when i do 'start B'
[06:39]  * SpamapS draws it in his head
[06:40] <SpamapS> bradleyayers: it blocks
[06:40] <SpamapS> bradleyayers: until started A is emitted
[06:40] <bradleyayers> you mean started X?
[06:40] <SpamapS> no
[06:40] <bradleyayers> :O
[06:41] <SpamapS> because it is started A and started B ...
[06:41] <SpamapS> the and blocks
[06:41] <SpamapS> which is why and's require careful consideration
[06:41] <bradleyayers> oh okay, so B starts fine
[06:41] <SpamapS> bug #447654
[06:41] <bradleyayers> but then A stays with its goal as stopped
[06:41] <bradleyayers> aaa
[06:41] <bradleyayers> awit
[06:42] <bradleyayers> !!!
[06:42] <bradleyayers> Z stays with its goal as stopped**
[06:42] <bradleyayers> X
[06:42] <SpamapS> we had no Z!
[06:42] <bradleyayers> i know :(
[06:42] <SpamapS> ok
[06:42] <bradleyayers> I'll start again
[06:42] <SpamapS> yes X stays with its goal as stopped
[06:42] <bradleyayers> B starts properly
[06:42] <bradleyayers> then X stays with its goal as stopped
[06:42] <SpamapS> and perhaps more importantly, the started event for B is not "finished".. its blocking
[06:43] <SpamapS> so while B is started, the 'start' command (or event) will be waiting
[06:43] <SpamapS> There are times where this doesn't matter
[06:43] <SpamapS> you can use 'and' freely when the events that you are 'and'ing are never waited for
[06:44] <bradleyayers> but how can 'started' ever block, it's an event
[06:44] <SpamapS> for instance, the 'filesystem' event or the 'net-device-up' events aren't waited on
[06:44] <SpamapS> bradleyayers: ALL events can block
[06:44] <SpamapS> it is critical to the proper sequencing of the boot
[06:44] <bradleyayers> http://upstart.ubuntu.com/cookbook/#event-types says Signals don't block
[06:45] <SpamapS> for instance, the starting event needs to block, so that whatever you're trying to start before, doesn't start until you yourself are started
[06:45] <bradleyayers> which 'started' is
[06:45] <SpamapS> bradleyayers: signals aren't waited on.. but they actuall do still block.. :-/
[06:45] <bradleyayers> i should have said: "but how can 'started' ever block, it's a *signal*"
[06:45] <SpamapS> actually I should say
[06:45] <bradleyayers> ah okay, i didn't realise there was a difference between block and waited on :/
[06:45] <bradleyayers> my misunderstanding
[06:46] <SpamapS> started is not a signal
[06:46] <SpamapS> well it might be actually
[06:46] <SpamapS> I suppose it is since nothing is waiting for it.
[06:46] <SpamapS> starting, however, is always waited on
[06:47] <bradleyayers> that's my understanding too
[06:47] <bradleyayers> starting is a 'method event'
[06:47] <bradleyayers> or probably 'hook'
[06:49] <bradleyayers> so back to my original scenario, 'starting B' would be emitted, i dont understand why that doesn't trigger X's condition to be re-evaluated
[06:50] <bradleyayers> i'll read over bug #447654
[06:51] <SpamapS> bradleyayers: the condition is evaluated, and B's event satisfies only one side of it.
[06:51] <SpamapS> bradleyayers: since it is an and, you need to have A's started event *again*
[06:52] <bradleyayers> i see
[06:54] <SpamapS> bradleyayers: the disconnect that nearly everyone experiences is that they are events, not states, and so are inherently ephemeral.
[06:55] <bradleyayers> yeah :(
[06:55] <bradleyayers> i get it now
[06:55] <bradleyayers> so this definitely hasn't been fixed yet?
[06:57] <SpamapS> No, it effectively needs a rewrite of the event loop to add the ability to observe states.
[06:58] <SpamapS> In practice, it can be worked around with the 'wait-for-state' job.
[06:59] <SpamapS> bradleyayers: is this your bug btw: https://bugs.launchpad.net/upstart-cookbook/+bug/912348
[07:00] <bradleyayers> yeah that sums up what my question was
[07:01] <SpamapS> Cool, I just pushed up a merge proposal https://code.launchpad.net/~clint-fewbar/upstart-cookbook/clarify-complex-start-stop/+merge/90379
[07:04] <bradleyayers> i'd probably bold "is not known to upstart"
[07:04] <bradleyayers> but otherwise it looks good
[07:04] <bradleyayers> but a bit hard to be objective now that I actually understand it
[07:12] <SpamapS> bradleyayers: agreed on the bolding, pushed that up
[07:12] <bradleyayers> cool
[09:26] <bradleyayers> hey SpamapS thanks for the help before


[05:13] -queuebot:#ubuntu-release- New binary: derpconf [amd64] (focal-proposed/universe) [0.8.2-3] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: input-pad [amd64] (focal-proposed/universe) [1.0.3-4] (input-methods)
[05:13] -queuebot:#ubuntu-release- New binary: squaremap [amd64] (focal-proposed/universe) [1:1.0.5-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: gnome-shell-extension-xrdesktop [amd64] (focal-proposed/none) [0.13.2-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: xul-ext-exteditor [amd64] (focal-proposed/universe) [2.0.2-1~exp1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: sgmllib3k [amd64] (focal-proposed/none) [1.0.0-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: firewalld [amd64] (focal-proposed/universe) [0.8.0-2] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: pkgconf [s390x] (focal-proposed/universe) [1.6.3-5] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: pkgconf [amd64] (focal-proposed/universe) [1.6.3-5] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: xrdesktop [s390x] (focal-proposed/none) [0.13.2-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: input-pad [ppc64el] (focal-proposed/universe) [1.0.3-4] (input-methods)
[05:14] -queuebot:#ubuntu-release- New binary: pkgconf [ppc64el] (focal-proposed/universe) [1.6.3-5] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: python-traitsui [amd64] (focal-proposed/universe) [6.1.3-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: input-pad [s390x] (focal-proposed/universe) [1.0.3-4] (input-methods)
[05:14] -queuebot:#ubuntu-release- New binary: xrdesktop [ppc64el] (focal-proposed/none) [0.13.2-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: python-pydot-ng [amd64] (focal-proposed/universe) [1.0.0-4] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: pkgconf [arm64] (focal-proposed/universe) [1.6.3-5] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: q2-types [amd64] (focal-proposed/none) [2019.10.0-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: pkgconf [armhf] (focal-proposed/universe) [1.6.3-5] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: xrdesktop [amd64] (focal-proposed/none) [0.13.2-1] (no packageset)
[05:16] -queuebot:#ubuntu-release- New binary: input-pad [arm64] (focal-proposed/universe) [1.0.3-4] (input-methods)
[05:16] -queuebot:#ubuntu-release- New binary: xrdesktop [arm64] (focal-proposed/none) [0.13.2-1] (no packageset)
[05:16] -queuebot:#ubuntu-release- New binary: input-pad [armhf] (focal-proposed/universe) [1.0.3-4] (input-methods)
[05:16] -queuebot:#ubuntu-release- New binary: xrdesktop [armhf] (focal-proposed/none) [0.13.2-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: broker [s390x] (focal-proposed/universe) [1.2.4+ds1-1] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: fplll [s390x] (focal-proposed/universe) [5.3.1-1] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: broker [ppc64el] (focal-proposed/universe) [1.2.4+ds1-1] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: fplll [amd64] (focal-proposed/universe) [5.3.1-1] (no packageset)
[05:22] -queuebot:#ubuntu-release- New binary: fplll [ppc64el] (focal-proposed/universe) [5.3.1-1] (no packageset)
[05:26] -queuebot:#ubuntu-release- New binary: broker [arm64] (focal-proposed/universe) [1.2.4+ds1-1] (no packageset)
[05:30] -queuebot:#ubuntu-release- New binary: fplll [armhf] (focal-proposed/universe) [5.3.1-1] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: fplll [arm64] (focal-proposed/universe) [5.3.1-1] (no packageset)
[06:48] -queuebot:#ubuntu-release- New binary: mlpack [s390x] (focal-proposed/universe) [3.2.2-2] (no packageset)
[06:59] -queuebot:#ubuntu-release- New binary: mlpack [amd64] (focal-proposed/universe) [3.2.2-2] (no packageset)
[07:20] -queuebot:#ubuntu-release- New binary: mlpack [ppc64el] (focal-proposed/universe) [3.2.2-2] (no packageset)
[11:28] -queuebot:#ubuntu-release- New binary: mlpack [arm64] (focal-proposed/universe) [3.2.2-2] (no packageset)
[11:37] -queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [ppc64el] (focal-proposed/multiverse) [10.1.243-1] (no packageset)
[11:39] -queuebot:#ubuntu-release- New binary: mlpack [armhf] (focal-proposed/universe) [3.2.2-2] (no packageset)
[13:14] -queuebot:#ubuntu-release- New: accepted broker [arm64] (focal-proposed) [1.2.4+ds1-1]
[13:14] -queuebot:#ubuntu-release- New: accepted broker [s390x] (focal-proposed) [1.2.4+ds1-1]
[13:14] -queuebot:#ubuntu-release- New: accepted broker [ppc64el] (focal-proposed) [1.2.4+ds1-1]
[13:14] -queuebot:#ubuntu-release- New: accepted derpconf [amd64] (focal-proposed) [0.8.2-3]
[13:14] -queuebot:#ubuntu-release- New: accepted fplll [amd64] (focal-proposed) [5.3.1-1]
[13:14] -queuebot:#ubuntu-release- New: accepted fplll [armhf] (focal-proposed) [5.3.1-1]
[13:14] -queuebot:#ubuntu-release- New: accepted fplll [s390x] (focal-proposed) [5.3.1-1]
[13:14] -queuebot:#ubuntu-release- New: accepted input-pad [amd64] (focal-proposed) [1.0.3-4]
[13:14] -queuebot:#ubuntu-release- New: accepted input-pad [armhf] (focal-proposed) [1.0.3-4]
[13:14] -queuebot:#ubuntu-release- New: accepted input-pad [s390x] (focal-proposed) [1.0.3-4]
[13:14] -queuebot:#ubuntu-release- New: accepted mlpack [arm64] (focal-proposed) [3.2.2-2]
[13:14] -queuebot:#ubuntu-release- New: accepted mlpack [ppc64el] (focal-proposed) [3.2.2-2]
[13:14] -queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [ppc64el] (focal-proposed) [10.1.243-1]
[13:14] -queuebot:#ubuntu-release- New: accepted firewalld [amd64] (focal-proposed) [0.8.0-2]
[13:14] -queuebot:#ubuntu-release- New: accepted fplll [ppc64el] (focal-proposed) [5.3.1-1]
[13:14] -queuebot:#ubuntu-release- New: accepted input-pad [arm64] (focal-proposed) [1.0.3-4]
[13:14] -queuebot:#ubuntu-release- New: accepted mlpack [amd64] (focal-proposed) [3.2.2-2]
[13:14] -queuebot:#ubuntu-release- New: accepted mlpack [s390x] (focal-proposed) [3.2.2-2]
[13:14] -queuebot:#ubuntu-release- New: accepted pkgconf [arm64] (focal-proposed) [1.6.3-5]
[13:14] -queuebot:#ubuntu-release- New: accepted pkgconf [ppc64el] (focal-proposed) [1.6.3-5]
[13:14] -queuebot:#ubuntu-release- New: accepted fplll [arm64] (focal-proposed) [5.3.1-1]
[13:14] -queuebot:#ubuntu-release- New: accepted input-pad [ppc64el] (focal-proposed) [1.0.3-4]
[13:14] -queuebot:#ubuntu-release- New: accepted pkgconf [amd64] (focal-proposed) [1.6.3-5]
[13:14] -queuebot:#ubuntu-release- New: accepted pkgconf [s390x] (focal-proposed) [1.6.3-5]
[13:15] -queuebot:#ubuntu-release- New: accepted gnome-shell-extension-xrdesktop [amd64] (focal-proposed) [0.13.2-1]
[13:15] -queuebot:#ubuntu-release- New: accepted pkgconf [armhf] (focal-proposed) [1.6.3-5]
[13:15] -queuebot:#ubuntu-release- New: accepted mlpack [armhf] (focal-proposed) [3.2.2-2]
[13:15] -queuebot:#ubuntu-release- New: accepted python-pydot-ng [amd64] (focal-proposed) [1.0.0-4]
[13:15] -queuebot:#ubuntu-release- New: accepted q2-types [amd64] (focal-proposed) [2019.10.0-1]
[13:15] -queuebot:#ubuntu-release- New: accepted squaremap [amd64] (focal-proposed) [1:1.0.5-1]
[13:15] -queuebot:#ubuntu-release- New: accepted xrdesktop [arm64] (focal-proposed) [0.13.2-1]
[13:15] -queuebot:#ubuntu-release- New: accepted xrdesktop [ppc64el] (focal-proposed) [0.13.2-1]
[13:15] -queuebot:#ubuntu-release- New: accepted xul-ext-exteditor [amd64] (focal-proposed) [2.0.2-1~exp1]
[13:15] -queuebot:#ubuntu-release- New: accepted python-traitsui [amd64] (focal-proposed) [6.1.3-1]
[13:15] -queuebot:#ubuntu-release- New: accepted xrdesktop [amd64] (focal-proposed) [0.13.2-1]
[13:15] -queuebot:#ubuntu-release- New: accepted xrdesktop [s390x] (focal-proposed) [0.13.2-1]
[13:15] -queuebot:#ubuntu-release- New: accepted sgmllib3k [amd64] (focal-proposed) [1.0.0-1]
[13:15] -queuebot:#ubuntu-release- New: accepted xrdesktop [armhf] (focal-proposed) [0.13.2-1]
[15:07] -queuebot:#ubuntu-release- New binary: q2-demux [amd64] (focal-proposed/universe) [2019.4.1-1] (no packageset)
[15:07] -queuebot:#ubuntu-release- New binary: q2-quality-filter [amd64] (focal-proposed/universe) [2019.4.0-1] (no packageset)
[15:09] -queuebot:#ubuntu-release- New binary: q2-feature-table [amd64] (focal-proposed/universe) [2019.4.0+dfsg-1] (no packageset)
[15:12] -queuebot:#ubuntu-release- New binary: gnome-panel [s390x] (focal-proposed/universe) [1:3.35.1-1ubuntu1] (desktop-extra, edubuntu, ubuntu-budgie)
[15:13] -queuebot:#ubuntu-release- New binary: gnome-panel [ppc64el] (focal-proposed/universe) [1:3.35.1-1ubuntu1] (desktop-extra, edubuntu, ubuntu-budgie)
[15:14] -queuebot:#ubuntu-release- New binary: gnome-panel [amd64] (focal-proposed/universe) [1:3.35.1-1ubuntu1] (desktop-extra, edubuntu, ubuntu-budgie)
[15:15] -queuebot:#ubuntu-release- New binary: gnome-panel [arm64] (focal-proposed/universe) [1:3.35.1-1ubuntu1] (desktop-extra, edubuntu, ubuntu-budgie)
[15:15] -queuebot:#ubuntu-release- New binary: gnome-panel [armhf] (focal-proposed/universe) [1:3.35.1-1ubuntu1] (desktop-extra, edubuntu, ubuntu-budgie)
[15:53] -queuebot:#ubuntu-release- New: accepted q2-demux [amd64] (focal-proposed) [2019.4.1-1]
[15:53] -queuebot:#ubuntu-release- New: accepted q2-quality-filter [amd64] (focal-proposed) [2019.4.0-1]
[15:53] -queuebot:#ubuntu-release- New: accepted q2-feature-table [amd64] (focal-proposed) [2019.4.0+dfsg-1]
[17:12] -queuebot:#ubuntu-release- New binary: openlibm [amd64] (focal-proposed/universe) [0.7.0+dfsg-1] (no packageset)
[17:12] -queuebot:#ubuntu-release- New binary: openlibm [s390x] (focal-proposed/universe) [0.7.0+dfsg-1] (no packageset)
[17:13] -queuebot:#ubuntu-release- New binary: openlibm [arm64] (focal-proposed/universe) [0.7.0+dfsg-1] (no packageset)
[17:13] -queuebot:#ubuntu-release- New binary: openlibm [ppc64el] (focal-proposed/universe) [0.7.0+dfsg-1] (no packageset)
[17:13] -queuebot:#ubuntu-release- New binary: openlibm [armhf] (focal-proposed/universe) [0.7.0+dfsg-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-cfg-if [armhf] (focal-proposed/universe) [0.1.10-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-cfg-if [s390x] (focal-proposed/universe) [0.1.10-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-cfg-if [ppc64el] (focal-proposed/universe) [0.1.10-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-cfg-if [arm64] (focal-proposed/universe) [0.1.10-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-float-cmp [s390x] (focal-proposed/universe) [0.6.0-2] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: rust-float-cmp [arm64] (focal-proposed/universe) [0.6.0-2] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: rust-cfg-if [amd64] (focal-proposed/universe) [0.1.10-1] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: rust-float-cmp [armhf] (focal-proposed/universe) [0.6.0-2] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: rust-gimli [amd64] (focal-proposed/universe) [0.19.0-1] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: rust-gimli [ppc64el] (focal-proposed/universe) [0.19.0-1] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: rust-phf [arm64] (focal-proposed/universe) [0.8.0-1] (i386-excludes)
[23:18] -queuebot:#ubuntu-release- New binary: rust-float-cmp [amd64] (focal-proposed/universe) [0.6.0-2] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: rust-gimli [armhf] (focal-proposed/universe) [0.19.0-1] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: rust-phf [ppc64el] (focal-proposed/universe) [0.8.0-1] (i386-excludes)
[23:18] -queuebot:#ubuntu-release- New binary: rust-float-cmp [ppc64el] (focal-proposed/universe) [0.6.0-2] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: rust-gimli [s390x] (focal-proposed/universe) [0.19.0-1] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: rust-phf [amd64] (focal-proposed/universe) [0.8.0-1] (i386-excludes)
[23:18] -queuebot:#ubuntu-release- New binary: rust-regex-syntax [ppc64el] (focal-proposed/universe) [0.6.12-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: rust-phf [s390x] (focal-proposed/universe) [0.8.0-1] (i386-excludes)
[23:21] -queuebot:#ubuntu-release- New binary: rust-regex-syntax [arm64] (focal-proposed/universe) [0.6.12-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: rust-synstructure [amd64] (focal-proposed/universe) [0.12.3-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: rust-synstructure [s390x] (focal-proposed/universe) [0.12.3-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: rust-regex-syntax [s390x] (focal-proposed/universe) [0.6.12-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: rust-toml [arm64] (focal-proposed/universe) [0.5.5-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: rust-synstructure [armhf] (focal-proposed/universe) [0.12.3-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: rust-gimli [arm64] (focal-proposed/universe) [0.19.0-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: rust-regex-syntax [armhf] (focal-proposed/universe) [0.6.12-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: rust-synstructure [ppc64el] (focal-proposed/universe) [0.12.3-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: rust-toml [armhf] (focal-proposed/universe) [0.5.5-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: rust-unicode-width [amd64] (focal-proposed/universe) [0.1.7-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: rust-unicode-width [armhf] (focal-proposed/universe) [0.1.7-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: rust-phf [armhf] (focal-proposed/universe) [0.8.0-1] (i386-excludes)
[23:22] -queuebot:#ubuntu-release- New binary: rust-toml [amd64] (focal-proposed/universe) [0.5.5-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: rust-unicode-width [arm64] (focal-proposed/universe) [0.1.7-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: rust-synstructure [arm64] (focal-proposed/universe) [0.12.3-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: rust-unicode-width [ppc64el] (focal-proposed/universe) [0.1.7-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: rust-toml [ppc64el] (focal-proposed/universe) [0.5.5-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: rust-toml [s390x] (focal-proposed/universe) [0.5.5-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: threeten-extra [amd64] (focal-proposed/universe) [1.5.0-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: rust-unicode-width [s390x] (focal-proposed/universe) [0.1.7-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: vinnie [amd64] (focal-proposed/universe) [2.0.2-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: slepc4py [amd64] (focal-proposed/universe) [3.12.0-3] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: rust-regex-syntax [amd64] (focal-proposed/universe) [0.6.12-1] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: petsc4py [amd64] (focal-proposed/universe) [3.12.0-3] (no packageset)


[08:35] <rbasak> Is there an API equivalent to the https://launchpad.net/~racb/+uploaded-packages query? I'm also interested in "Synchronised packages". I can't find it against person or archive.
[08:37] <rbasak> getPublishedSources don't look like it can filter by uploader, for example.
[08:39] <rbasak> Or I could walk them and filter myself I guess. I only need the past week or so.
[09:36] <mapreri> I'm seeing PPA builds fail to build without giving me a build log nor failing emails and also taking way too little to fail (e.g. https://code.launchpad.net/~scribus/+archive/ubuntu/ppa/+build/12592513).  something bad going on?
[09:37] <mapreri> (I doubt it's that ifrewall outage from May 11th still in topic, right?)
[09:42] <wgrant> mapreri: There's an upgrade ongoing which is possibly causing some intermittent issues atm, will dig.
[09:49] <rbasak> I intended up filtering myself. Seems OK.
[12:21] <jochensp> Hi, a colleague of mine has problems logging into launchpad https://s3.amazonaws.com/uploads.hipchat.com/154521/3402713/eA8MuUQBxiysh93/aaa.png
[12:24] <cjwatson> Next time please get them to just copy-and-paste the OOPS ID so that we don't have to transcribe it from an image :)
[12:24] <cjwatson> I'll see about getting that account sorted out
[12:34] <cjwatson> jochensp: Should be sorted out now.
[12:34] <jochensp> cjwatson: thx!
[18:55] <vila> cjwatson, wgrant: SOrry, can't find it back :-/ What's the url for the page that list the number of bzr branches on lp? (Just for the sake of the data point ;-)
[18:56] <cjwatson> vila: Front page
[18:56] <cjwatson> https://launchpad.net/
[18:57] <cjwatson> vila: (It's actually only public branches - much quicker to calculate)
[18:57]  * vila faepalms
[18:57] <vila> cjwatson: how embarrassing ;-)
[18:57] <cjwatson> :-)
[18:58] <vila> cjwatson: so 1 million, good. Easy to remember even if it's only part of the picture (though I don't think adding the private ones will be that different ?)
[19:01] <cjwatson> In dogfood's slightly old DB copy there are about 78000 non-public branches
[19:02] <vila> thanks for confirming ;-)
[19:02] <cjwatson> This isn't taking activity into account or anything of course, so lots of those will be Merged or Abandoned
[19:02] <vila> yeah
[19:03] <vila> or packaging ones
[19:03] <vila> no worries
[19:03] <cjwatson> Surprisingly few actually; dogfood has a total of 822169 in active states
[19:03] <cjwatson> (i.e. Experimental, Development, or Mature)
[19:04] <vila> right, but that's.. not a direct value metric (that's floss after all) but the 200.00 (1 million minus 800.000) is still impressive
[19:05] <vila> 200.000
[19:15] <vagrantc> hey folks ... switching the ltsp project over to git, but it's unclear how to get the branches for https://code.launchpad.net/~ltsp-upstream/+git/ to show up on https://code.launchpad.net/ltsp/
[19:15] <vagrantc> i've selected git on https://code.launchpad.net/ltsp/+configure-code
[19:15] <cjwatson> vagrantc: They need to be in the ltsp project, not just personal repositories with ltsp in their names
[19:15] <vagrantc> but trying to link a reposotory fails
[19:16] <cjwatson> vagrantc: You can use "change details" on each of them and set the target to ltsp
[19:16] <vagrantc> how does one put it into a project?
[19:16] <vagrantc> aha
[19:16] <cjwatson> that'll change them to be ~ltsp-upstream/ltsp/+git/ltspfs etc.
[19:17] <vagrantc> that worked, nice!
[19:19] <george_e> I am having trouble creating a recipe - this is the error I get: http://i.stack.imgur.com/2eQVW.png
[19:19] <george_e> And yet, here is the branch it claims does not exist: https://code.launchpad.net/~george-edison55/nitroshare/+git/nitroshare-debian
[19:20] <vagrantc> is there a way to change https://code.launchpad.net/~ltsp-upstream to show git repositories instead of bzr?
[19:22] <cjwatson> george_e: I think it's getting confused about the fact that lp:nitroshare also exists in the Bazaar world.  See https://bugs.launchpad.net/launchpad/+bug/1623924
[19:22] <cjwatson> (workarounds in that bug)
[19:22] <cjwatson> vagrantc: Unfortunately not
[19:24] <vagrantc> cjwatson: ok, thanks for your help!
[19:28] <george_e> cjwatson: thanks!
[20:35] <kyrofa> I've been getting proxy errors when trying to upload my snap for about 10 minutes now
[20:41] <kyrofa> Make that 20
[21:56] <cjwatson> kyrofa: 502 proxy errors while LP is uploading a snap are always a problem with the store
[21:57] <kyrofa> cjwatson, yeah I suppose so. It resolved itself after about 30 minutes. Frustrating
[21:58] <cjwatson> (it's from the haproxy frontend to click-updown, I think)