[00:05] <kgunn> RAOF: anything noteworthy about xserver mm 14 & intel mm7 ?
[00:06] <RAOF> I moved a little code from intel to the xserver so that ati & nouveau are less work, and intel mm7 might render correctly in situations where mm6 didn't?
[00:07] <kgunn> ah,....i see buffer stride via the interface
[00:09] <RAOF> Yeah.
[00:10] <RAOF> You know what would be awesome? If our acceptance tests weren't riddled with non-deterministic failures :(
[00:10] <robert_ancell> thomi, ah, xrandr is considered a bit unstable
[00:11] <thomi> ugh
[00:18] <RAOF> thomi: Also, that check will become incorrect as soon as I create outputs with correct names (like HDMI-1 and eDP-1, etc)
[00:19] <thomi> so, what should it be doind?
[00:19] <thomi> *doing
[00:21] <RAOF> ‘grep "LoadModule.*xmir" /var/log/Xorg.${DISPLAY#:}.log’ is reasonable.
[00:23] <thomi> RAOF: thanks
[00:23] <thomi> robert_ancell: that fix is now in place - should I run the tests again?
[00:23] <robert_ancell> thomi, please do
[00:24] <thomi> robert_ancell: it seems like some jobs are already running :-/
[00:24] <robert_ancell> thomi, I started it earlier, some might not have completed
[00:24] <thomi> should I kill them, or wait?
[00:25] <robert_ancell> thomi, kill them
[00:26] <thomi> ok, they're running again
[01:16]  * RAOF wonders whether he should set up an android test environment or just wait the 30minutes for Jenkins to run the tests...
[01:36] <RAOF> Now really isn't the time, but we should totally rewrite cross-compile-chroot to use debootstrap and not be a huge pile of hack.
[01:40] <duflu> I'd just like a script that I didn't have to Ctrl+C part way through to use effectively
[01:41] <duflu> Though, I also don't have an N4 right now :/
[01:44] <duflu> Are we waiting on anything to get the bypass patch back in the PPA for testing?
[01:45] <duflu> robert_ancell, RAOF ^
[01:52] <RAOF> We should probably reverse copy from qa-testing2 to qu-testing now that MM is pretty much good in qa-testing2
[02:01] <duflu> RAOF: Did you try ignoring buffer age yet?
[02:02] <RAOF> duflu: Yes. I was just about to say that it doesn't help.
[02:02] <RAOF> :)
[02:02] <duflu> Fark. Well at least we know it's not from bypass. Back to square one
[02:03] <RAOF> It's going to be the compositor displaying buffers out of order again.
[02:04] <duflu> RAOF: I am struggling to find any way to reproduce it with the tools in lp:mir alone. Being able to reproduce it would be a huge step
[02:05] <duflu> lp:mir is still /too flawless/. There's something our demos are not doing to trigger the bug
[02:06] <duflu> RAOF: Can you please triple check going age-less? I don't want to spent more days in that rabbit hole accidentally...
[02:07] <RAOF> Ok
[02:10] <RAOF> As I say, my bet is that we're going to want to annotate XMir with the buffer ID its submitting and then print out the buffer ID the compositor is drawing.
[02:13] <duflu> RAOF: That's feasible
[02:14] <duflu> Though we are almost certain already that it's the wrong order. The how and why is important
[02:14] <duflu> And how to reproduce it with lp:mir servers/clients only
[02:30] <robert_ancell> duflu, last I heard from kgunn and olli, yes
[02:31] <robert_ancell> duflu, sorry, "back into the PPA" - do you mean the multi-monitor PPA?
[02:35]  * RAOF just realises that this isn't a good test; it's going to update every frame regardless of damage, so I won't see any glitches easily
[02:36] <duflu> robert_ancell: Yes qa-testing*. If there are any bugs then someone needs to tell me
[02:38] <robert_ancell> duflu, at the moment we just want to be sure mm works before combining it with bypass
[02:40] <duflu> robert_ancell: No problem. I only feared that some miscommunication about it being hideously broken may have occurred
[02:41] <robert_ancell> duflu, does using bypass together amplify some bug still?
[02:41] <duflu> robert_ancell: For nouveau/radeon I think. Can only test nouveau myself. I have some ideas for how to improve nouveau, but also think XMir won't trigger the issue
[02:44] <RAOF> duflu: Absolutely positively super triple-dog-sure that buffer age isn't the problem. I can still reproduce when doing a fullscreen blit on all damage.
[02:45] <duflu> RAOF: Ok, ta
[02:46] <RAOF> Huh. It's actually *two* frames behind!
[02:47]  * RAOF types 123 into an xterm, and sees ‘1’
[02:49] <duflu> Hmm, I wonder what Mir clients look like when the bug is occurring
[02:50] <RAOF> Probably roughly normal, because they almost all buffer swap at vsync?
[02:50] <RAOF> Only fingerpaint is likely to show anything, right?
[02:51] <duflu> RAOF: Probably, but does it get input? I'll try
[02:51] <duflu> Oh no, I can't the output_id fix isn't in the PPA yet
[02:52] <duflu> RAOF: I'm not sure now. Is it only lag or wrong order too?
[02:53] <RAOF> On the second head it seems to be purely lag.
[02:53] <duflu> RAOF:  Hmm, hold a key down and sometimes you do see the future for a split second. That's wrong order
[02:53] <RAOF> Ah, yes.
[02:53] <RAOF> There we go.
[02:54] <duflu> Should we say seeing the future is a *feature*?
[02:54] <RAOF> Lag *and* out of order :)
[02:54] <duflu> Interestingly, one monitor is bug-free
[02:54] <RAOF> Yeah. We fixed the "only one surface buffer order presentation" problem :/
[02:55] <duflu> OK, I have some good hints to work with
[02:56] <duflu> RAOF: Have you seen any order problems with just one output?
[02:57] <RAOF> No
[02:59]  * RAOF luncheons
[03:05] <kgunn> duflu: robert_ancell ...yeah it was testing from the boston 8...which i think all turned out ok...altho, now, we need to "make it work" with multimon
[03:06] <kgunn> i'll defer to you guys what order things need to land...
[03:06] <robert_ancell> kgunn, duflu, I vote we land bypass now
[03:08] <duflu> robert_ancell: I know of no issues, assuming xmir doesn't trigger bug 1211700 for nouveau. Which I can't test due to XMir and nouveau not being on the same machines
[03:09] <kgunn> robert_ancell: so...wrt multimon ppa....we just make sure not to let mir get rebuilt once its in archive ?
[03:09] <robert_ancell> kgunn, we can make an inverse bypass branch if necessary for now
[03:10] <duflu> robert_ancell: Do we need an env var to control it in case?
[03:10] <robert_ancell> duflu, I wasn't aware it could be switched off - there may be a case for an option to disable it then
[03:10] <kgunn> duflu: i personally like that idea...we had one in android & used it often for debug
[03:11] <duflu> OK, will hack the option into the bypass branch first
[03:11] <kgunn> if its low investment of ur time
[03:11] <duflu> It's trivial
[03:13] <kgunn> cool
[03:14] <robert_ancell> kgunn, thomi, do you have the numbers for the bypass test?
[03:16] <kgunn> robert_ancell: thomi ...http://<IP_ADDRESS>:8080/view/qa-ppa/
[03:16] <kgunn> so you kinda have to dig a little
[03:16] <kgunn> nothing looks completely amiss
[03:17] <robert_ancell> kgunn, yeah, wondering if there's anything to copy and paste into the MP
[03:19] <robert_ancell> brb
[03:23] <duflu> kgunn, robert_ancell: OK you can disable it with MIR_BYPASS=0
[03:24] <robert_ancell> duflu, awesome
[03:24] <robert_ancell> duflu, did you consider a command line flag? Then it can be disabled by either a flag or an env variable
[03:25] <duflu> robert_ancell: No... would that set the environment internally? If not then there's a lot of wiring up that would require
[03:25] <robert_ancell> duflu, all command line flags can be set with MIR_SERVER_FOO for --foo
[03:26] <duflu> robert_ancell: That doesn't have to be redone for each server right?
[03:26] <robert_ancell> duflu, nope, they all get that
[03:28] <kgunn> robert_ancell: so...should we line up the canonical folks tonight we want to give multimon a shot their morning ??
[03:28] <robert_ancell> kgunn, RAOF, it only works for intel right?
[03:28] <kgunn> or should we wait a bit ?
[03:28] <duflu> Now it's a non-trivial exercise :/
[03:29] <kgunn> robert_ancell: i thot you were trying to run it on the boston 8 earlier ?...did ati/nouveau fail ?
[03:29] <duflu> robert_ancell: Too complex to rush in such logic right now. It's pretty hidden so we can change it later
[03:30] <duflu> ... because getting command line option values seems to create complex class dependencies
[03:30] <robert_ancell> kgunn, we don't have the drivers working for ati/nouveau yet afaik. And the Boston 8 is failing at the moment, seems to be a problem in the test script - thomi is looking at it
[03:34] <thomi> robert_ancell: re-running with some tweaks to the test script
[03:35] <RAOF> robert_ancell: ati & nouveau should work, but I haven't tested them.
[03:36] <kgunn> cool...so we could just line up the internal testers w reckless abandon
[03:38] <RAOF> Yup.
[03:38] <kgunn> thomi: think we could get a sanity (e.g. does it boot) on ati/nouveau within an hour ?
[03:39] <thomi> on the boston 8?
[03:39] <thomi> I can just run them without the test, if you like
[03:39] <kgunn> yes...or any for that mattter
[03:39] <RAOF> Yes, that would be nice.
[03:40] <thomi> ...do we expect it to not boot!?
[03:40] <kgunn> yeah...i just don't want to tell people to test w/o having some idea of what will happen
[03:40] <RAOF> Oh, I expect it to boot, but it *might* not bring up X
[03:40] <kgunn> :)
[03:40] <kgunn> just a little thing like that
[03:40] <RAOF> I don't *think* that there's anything wrong with the changes, but I haven't tested them :)
[03:40] <kgunn> so yeah..boot to usable ui is the litmus
[03:42] <thomi> heh, would be a lot easier if I was in the lab, but I can kick it off after the current test runs
[03:45] <duflu> Hmm, how come USC's XMir is frozen while I run native Mir apps on top? It should render both simultaneously, like mir_demo_server_shell does
[03:47] <RAOF> Output change?
[03:47] <RAOF> USC changes output layout when I fire up mir_demo_client_egltriangle.
[03:48] <RAOF> Which is expected behaviour; resolution is per-session.
[03:49] <duflu> RAOF: But XMir is still composited and visible. Just frozen when a Mir client is focussed.
[03:49] <duflu> If it's composited and visible, it should keep rendering
[04:04] <kgunn> bbiab
[04:10] <robert_ancell> RAOF, so do you have a multi-monitor desktop working at the moment?
[04:10] <RAOF> Yes.
[04:10] <robert_ancell> I can't get spanning working in Unity and while playing with it I just end up with a black screen
[04:10] <RAOF> qa-testing2 works fine for me.
[04:10] <RAOF> Do you have delicious logs?
[04:11] <robert_ancell> what would you like? I've just restarted into a fresh session
[04:12] <RAOF> Xorg log, unity-system-compositor log, & lightdm log?
[04:12] <robert_ancell> brb
[04:14] <thomi> bah, jobs still failing
[04:20] <RAOF> robert_ancell: Winning?
[04:21] <robert_ancell> RAOF, ok, lets start with what I see.
[04:21] <RAOF> robert_ancell: Winning! https://code.launchpad.net/~raof/mir/fix-multi-surface-buffer-tracking/+merge/181259
[04:21] <robert_ancell> RAOF, 1. Log into Unity without monitor connected, all good
[04:21] <robert_ancell> 2. Connect monitor
[04:22] <robert_ancell> 3. See a pile of flickering, then second monitor shows mirrored display
[04:22] <robert_ancell> 4. BUT, the second display is taller and thinner than my laptop one so the desktop is cropped and extended
[04:22] <robert_ancell> 5. Can't launch any new X apps
[04:23] <RAOF> Good so far. I'm not sure why it flickers so much - I think that Mir is doing more modesetting than necessary.
[04:23] <robert_ancell> the X log shows ~1.6 million lines of "_XSERVTransSocketUNIXAccept: accept() failed"
[04:23] <RAOF> What Mir do you have? That means it doesn't have https://code.launchpad.net/~raof/mir/fix-multi-surface-buffer-tracking/+merge/181259 merged into it.
[04:24] <robert_ancell> ah
[04:24] <RAOF> (Mir is flooding the server with fds until accept() can't open a new fd)
[04:24] <robert_ancell> I have qa-testing pinned, not qa-testing2
[04:24] <robert_ancell> ok, I'll rinse and repeat
[04:25] <thomi> kgunn: robert_ancell: I just updated the ppa2 job to not actually run the tests, so when the current jobs end, you can re-kick off the run_all job and you'll have your boot test
[04:25] <robert_ancell> thomi, ta
[04:25] <thomi> I gotta go lie down though, I'm sick :(
[04:25] <thomi> will be back later maybe
[04:29] <robert_ancell> thomi, get well!
[04:29] <robert_ancell> RAOF, Do you know if SwapIntervalSignalTest works with fix-multi-surface-buffer-tracking? i.e. is alan_g's problem resolved?
[04:29] <robert_ancell> duflu, can you review that too asap if you need to?
[04:29] <RAOF> robert_ancell: Yes, it's resolved.
[04:29] <RAOF> robert_ancell: (As you can see from the tests all passing ☺)
[04:29] <duflu> robert_ancell: Yeah. I also have a reasonable theory for bad buffer ordering now. But first, lunch, postoffice, coffee
[04:31] <RAOF> I'm going out for a couple of hours; I'll get back to testing once I'm back.
[04:32] <robert_ancell> duflu, do you want to delay landing this?
[04:37] <robert_ancell> RAOF, cool, aside from the known lagging issue it works for me!
[04:40] <duflu> robert_ancell, I don't want to delay anything... Just going to lunch
[04:41] <robert_ancell> duflu, I mean, should we wait for you or you don't plan on reviewing
[04:44] <robert_ancell> kgunn, do you have that list of internal testers for multi-monitor? I'm having trouble finding it in my email
[04:50] <kgunn> robert_ancell: i do ...i crafted a setup email just now
[04:51] <robert_ancell> ok, cool
[04:54] <kgunn> robert_ancell: i'm gonna send...please read, then just followup with expectations on ati/nouveau
[04:56] <robert_ancell> RAOF, ati/nouveau are expected to work, just no-one has tested them right?
[04:57] <kgunn> robert_ancell: yeah...that's what he was saying
[04:57] <robert_ancell> kgunn, the Boston 8 tests are all failing again
[04:57] <kgunn> :-|
[04:57] <robert_ancell> kgunn, can you see those jenkins logs?
[04:58] <kgunn> http://<IP_ADDRESS>:8080/view/qa-ppa2/
[04:58] <robert_ancell> yeah
[05:00] <kgunn> i don't get it tho...it says intel is failing but the results look good
[05:00] <kgunn> on both resolutions
[05:01] <robert_ancell> kgunn, where are you looking at results?
[05:01] <kgunn> robert_ancell: here...http://<IP_ADDRESS>:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-intel-2500-le/ws/results/test-results/
[05:01] <kgunn> then drill into each folder marked for resolution...
[05:02] <kgunn> then composite.xml
[05:02] <kgunn> i'm gonna head off to bed....see you tomorrow
[05:02] <robert_ancell> later
[05:02] <kgunn> tvoss: i'll see you in ~9 hrs w/ olli :)
[05:02] <tvoss> kgunn, ack, later
[05:18] <robert_ancell> RAOF, so you think ati works, but you haven't tested it? You have some ati hardware right?
[05:23] <robert_ancell> tvoss, duflu, RAOF etc, can I get a review on https://code.launchpad.net/~robert-ancell/unity-system-compositor/fix-usc-shell-wrapper/+merge/181942 please?
[05:27] <robert_ancell> I'm finishing up for the night, any last requests?
[05:28] <duflu> robert_ancell: Relax?
[05:28] <robert_ancell> that would be awesome
[05:36] <tvoss> duflu, ping
[05:36] <duflu> tvoss, pong
[07:01] <RAOF> Ok.
[07:01] <RAOF> Let's test that radeon boots, at least.
[07:04] <duflu> Argh. I _still_ can't find a theoretical reason for bad frame ordering. The algorithm's designed to make it (theoretically) impossible
[07:05] <dholbach> good morning
[07:07] <RAOF> Good morning.
[07:07] <RAOF> Ah. I seem to have managed to break radeon. Excellent.
[07:07] <dholbach> hey RAOF
[07:09] <mlankhorst> perfect
[07:09] <mlankhorst> duflu: maybe it's not the theory, it's the implementation? :P
[07:10] <duflu> mlankhorst: Yeah, which is why I'm trying to find bugs still
[07:10] <mlankhorst> RAOF: perfect, can I look at it? :P
[07:11] <RAOF> mlankhorst: You're welcome to. It's... oh, not hosted in any public git tree.
[07:11] <RAOF> Let me fix that :)
[07:11] <RAOF> I've probably set the stride of the thingy wrong.
[07:12] <mlankhorst> yeah those thingies can get picky
[07:18] <RAOF> mlankhorst: github.com/RAOF/xf86-video-ati, branch "foo"
[07:18] <mlankhorst> RAOF: what mir branch etc do I need for that? or ppa
[07:19] <RAOF> You need ppa:mir-team/qa-testing2
[07:19] <RAOF> Or github.com/RAOF/xserver , branch vladmir-upstreaming
[07:20] <mlankhorst> ah
[07:27] <RAOF> mlankhorst: I'll have set devKind incorrectly in the ModifyPixmapHeader call.
[07:27] <RAOF> Becasue I'm still not entirely sure what WTH that's meant to be :)
[07:28] <RAOF> mlankhorst: Oh, I may have done the same for nouveau...
[07:34] <RAOF> mlankhorst: Do you remember offhand what devKind is meant to be for radeon?
[07:35] <RAOF> Hm. It *is* meant to be stride.
[07:49] <mlankhorst> RAOF: it's stride for all ddx iirc
[07:49] <RAOF> Then I broke it somewhere else :/
[07:49] <mlankhorst> yeah I'll take a look
[07:49] <mlankhorst> power just cut out :/
[07:50] <mlankhorst> for like 5 minutes or so
[07:52] <tvoss__> mlankhorst, in your place?
[07:56] <mlankhorst> yeah
[08:12] <mlankhorst> RAOF: do you get something like this?
[08:12] <mlankhorst> [  403.880155] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x9
[08:12] <mlankhorst> [  403.880435] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2!
[08:12] <duflu> Sigh. We may yet need a universal frame counter to throttle clients accurately under multimonitor
[08:13] <duflu> Wait a minute... what is "accurate"?
[08:13] <duflu> Surely if your client doesn't do "accurate" timing and relies on vsync then 120Hz with two monitors is not necessarily wrong :/
[08:13] <duflu> Hmm
[08:15] <mlankhorst> duflu: that is assuming both monitors have the same scanrate
[08:15] <duflu> mlankhorst: I mean generally sum of all
[08:16] <duflu> I think we've been trying to meet a requirement that doesn't really exist...
[08:16] <mlankhorst> RAOF: lol
[08:16] <mlankhorst> [  595.892399] radeon 0000:01:00.0: evergreen_cs_track_validate_texture:850 texture bo too small (layer size 5299200, offset 0, max layer 1, depth 1, bo size 12288) (1472 900)
[08:19] <mlankhorst> combined with the previous errors it looks like your handles are corrupted :P
[08:22] <mlankhorst>  +      if (!pScreen->ModifyPixmapHeader(dst,
[08:22] <mlankhorst> -+                                       pScrn->virtualX, pScrn->virtualY,
[08:22] <mlankhorst> ++                                       output_box->x2 - output_box->x1,
[08:22] <mlankhorst> ++                     output_box->y2 - output_box->y1,
[08:22] <mlankhorst> looks wrong..
[08:29] <mlankhorst> hm and the last error might be from freeing a buffer
[08:33] <hikiko> hello :) could someone review this branch: https://code.launchpad.net/~hikiko/mir/mir.gbm-buffer-allocator-modifications/+merge/182049 if not busy?
[08:34] <mlankhorst> RAOF: with valgrind I seem to get more errors :P
[08:35] <mlankhorst> definitely looks like the bo's get unreffed before being used..
[08:37] <RAOF> mlankhorst: That seems... wat? The changes shouldn't change when the bos get unreffed!
[08:42] <mlankhorst> RAOF: well from the dmesg I'm guessing that somewhere something gets freed before it should
[08:44] <mlankhorst> if i run things with valgrind I end up with Xorg failing in random random crashes
[08:44] <mlankhorst> s/random.*/random places/
[08:48] <RAOF> mlankhorst: Oh, that reminds me. I should push the xf86-video-intel change to actually enable the valgrind support.
[08:49] <mlankhorst> wasn't --enable-valgrind already added, or did you redisable it?
[08:50] <RAOF> No, it's enabled, but only if DEB_HOST_ARCH == linux
[08:50] <RAOF> But DEB_HOST_ARCH is never linux; you misspelt DEB_HOST_ARCH_OS
[08:51] <mlankhorst> oops
[08:55] <mlankhorst> RAOF: anyway I'm getting some weirdness that indicates a flink leak, though. but no clue as to where it comes from yet..
[08:55] <RAOF> Colour me confused, then.
[08:55] <mlankhorst> erm I mean you're probably freeing something twice
[08:55] <mlankhorst> or before using it
[09:02] <mlankhorst> or a particularly nasty kernel corruption.. I'll try on my older card
[09:04] <mlankhorst> RAOF: were you getting the same kind of errors?
[09:07] <RAOF> mlankhorst: Hm, no.
[09:09] <RAOF> I don't get any valgrind errors that aren't either unrelated (hello, writev!) or a couple of the harmless "I don't understand your ioctls" errors.
[09:09] <mlankhorst> I'm getting tons of crap like this
[09:09] <mlankhorst> [   99.170371] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2!
[09:09] <mlankhorst> [   99.178895] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x9
[09:09] <mlankhorst> and
[09:09] <mlankhorst> [  101.124015] radeon 0000:01:00.0: evergreen_cs_track_validate_cb:476 cb[0] bo too small (layer size 6144, offset 0, max layer 1, bo size 4096, slice 23)
[09:10] <mlankhorst> [  101.124021] radeon 0000:01:00.0: evergreen_cs_track_validate_cb:480 problematic surf: (64 24) (0 4 1 0 0 4 3)
[09:10] <RAOF> Ah, yes. I see those.
[09:10] <mlankhorst> which makes me think that some stuff gets freed by the driver before submitting the commands
[09:11] <RAOF> Ah, fair enough.
[09:11]  * RAOF was confused about your valgrind comment.
[09:12] <mlankhorst> RAOF: well I get some memcpy crashes from valgrind
[09:12] <mlankhorst> but nothing pointing towards what is going on
[09:13] <RAOF> Huh, really?
[09:13] <RAOF> memcpy?
[09:14] <mlankhorst> RAOF: does the root window have damage tracking after a resize event?
[09:14] <RAOF> Yes.
[09:14] <RAOF> But we should be disabling everything that has damage associated with the screen pixmap before resizing.
[09:15] <RAOF> 'cause we throw away the screen pixmap on resize, but not the root window.
[09:15] <mlankhorst> .. do you? :p
[09:18] <RAOF> I'm reasonably sure?
[09:18] <mlankhorst> hm good enough
[09:18] <RAOF> Anyway, resize isn't called in xserver startup?
[09:19] <mlankhorst> I'm trying to figure out what is going on there though
[09:21] <RAOF> What's your memcpy crash, anyway?
[09:26] <duflu> Woo! Perfect multimonitor frame sync with no timers!
[09:29] <mlankhorst> RAOF: never the same twice :/
[09:29] <mlankhorst> but usually exa related
[09:30] <mlankhorst> actually always the same it seems, it's from fallback call. same thing that happens when acceleration in nouveau fails
[09:30] <mlankhorst> and preceded by failed to map pixmap: -2
[09:31] <mlankhorst> hm from procRenderCreateCursor..
[09:33] <mlankhorst> http://paste.debian.net/30292/ with memory summary removed
[09:35] <mlankhorst> RAOF: it worked on intel right?
[09:35] <RAOF> Yeah, works on intel.
[09:35] <mlankhorst> RAOF: implement shadowfb call :P
[09:35] <duflu> Well, actually, my sync is temporarily lost when VT switching, but it comes back eventually
[09:35] <RAOF> Also, I *don't* see that CreateCursor crash.
[09:36] <mlankhorst> hm actually it wouldn't help
[09:36] <mlankhorst> it's falling back to downloading to screen because the mapping was failing
[09:37] <duflu> You know, it's rather hard to create visual glitches when you're triple buffering. I never realized just how hard...
[09:44] <mlankhorst> it's easy if you relax the restriction and allow them to be fatal :P
[09:48] <RAOF> Heh
[09:58] <mlankhorst> RAOF: also curious it looks like xmir_copy_to_mir was wrong in another place
[09:59] <RAOF> Oh?
[09:59] <mlankhorst> you set dst x / y to 0 0, should probably be the same as src x y
[10:00] <RAOF> dst x/y is not location in the destination buffer?
[10:00] <mlankhorst> it is
[10:00] <RAOF> Then why wouldn't I want it to be 0 0?
[10:00] <mlankhorst> but I'm guessing the destination buffer is full sized?
[10:00] <RAOF> No, the destination buffer is output-sized.
[10:00] <RAOF> Welcome to the poor-man's Shatter.
[10:01] <mlankhorst> ah..
[10:01] <mlankhorst> RAOF: you allocate a single bo for the entire screen, but each output uses a chunk of it?
[10:02] <RAOF> There's a single bo for the ScreenPixmap.
[10:02] <RAOF> But we copy each region that corresponds to an output into a different xmir_window
[10:03] <mlankhorst> nasty
[10:03] <RAOF> Or, perhaps more understandably - each enabled xf86Crtc has an associated xmir_window, with a MirSurface, and we copy from the root window into that surface.
[10:04] <RAOF> Eh, I don't think it's particularly nastier than having a single framebuffer surface and copying the whole root window into it.
[10:09] <mlankhorst> I don't really see where this particular error is coming from, what is your failure mode?
[10:10] <RAOF> Of *course* I don't see this crash under gdb & mir_demo_server_shell!
[10:10] <RAOF> BAH.
[10:11] <mlankhorst> ..?
[10:13] <mlankhorst> and I'm killing off the dup syscall. I'll just set fd to negative, and use that internally to say 'do not close after opening' :P
[10:14] <RAOF> mlankhorst: I can, apparently, quite happily run radeon under mir_demo_server_shell in gdb.
[10:15] <RAOF> No crashes, no madness...
[10:15] <RAOF> To be fair I'm not *actually* looking at the display; it's upstairs, so it might be entirely wrong ☺
[10:15] <tvoss__> RAOF, rofl
[10:17] <mlankhorst> you're like those tv commercials where they put 'not showing the actual product' in small letters on the bottom
[10:22] <mlankhorst> RAOF: is it just the xserver, or a full session?
[10:22] <RAOF> Just the X server.
[10:22] <mlankhorst> well duh :P
[10:22] <RAOF> Why duh?
[10:22] <mlankhorst> see if it survives this: DISPLAY=:0 XDESKTOP_SESSION=ubuntu /etc/X11/Xsession
[10:23] <mlankhorst> erm
[10:23] <mlankhorst> DESKTOP_SESSION*
[10:23] <RAOF> Hm. dmesg does not survive DISPLAY=:33 glxgears :)
[10:23] <mlankhorst> hah
[10:23] <RAOF> [ 1806.614838] [drm:r600_cs_common_vline_parse] *ERROR* cannot find crtc<PHONE_NUMBER>
[10:24] <RAOF> I'm not surprised it can't find it!
[10:24] <mlankhorst> or are you? DUN DUN DUUUN
[10:24] <mlankhorst> 55a4b390
[10:31] <mlankhorst> RAOF: ah right, it's calling evergreen_cp_wait_vline_sync
[10:31] <RAOF> That seems unlikely to work. I thought I disabled vsyncing?
[10:33] <mlankhorst> all the calls are hidden behind accel_state->vsync
[10:34] <tvoss__> okay, time to take care of my visum for china
[10:34] <RAOF> Oh, dear.
[10:35] <RAOF> No, I undisabled vsynching when I shoved a non-null driver private in xf86Crtc.
[10:36] <mlankhorst> RAOF: erm it looks like the calls are only emitted if the driver has accel_state->vsync set though
[10:36]  * tvoss__ thinks about undisabled
[10:39] <RAOF> mlankhorst: Try bailing early with NULL from radeon_pick_best_crtc (in radeon_video.c)?
[10:40] <RAOF> Ok, time for me to sleep
[10:53] <mlankhorst> that's xv stuff..
[10:54] <mlankhorst> RAOF: did you explicitly enable vsync or something?
[10:55] <mlankhorst> looks like vsync is disabled in radeon unless you explicitly enable it
[11:00] <mlankhorst> hm indeed, same issue here :p
[11:02] <mlankhorst> radeon_dri2.c:    info->accel_state->vsync = info->swapBuffersWait;
[11:02] <mlankhorst> - OPTION_SWAPBUFFERS_WAIT, TRUE);
[11:03] <mlankhorst> + OPTION_SWAPBUFFERS_WAIT, !xorgMir);
[11:04] <mlankhorst> well that gets rid of 1 source of errors..
[12:07] <mlankhorst> meh on the crashing call..
[12:07] <mlankhorst> (gdb) print *(struct radeon_bo_gem*)((struct radeon_exa_pixmap_priv*)exaGetPixmapDriverPrivate(src))->bo
[12:07] <mlankhorst> $2 = {base = {ptr = 0x0, flags = 0, handle = 1, size = 5652480, alignment = 16384, domains = 4, cref = 3, bom = 0x5555559d81b0, space_accounted = 0, referenced_in_cs = 0}, name = 0, map_count = 0, reloc_in_cs = {
[12:07] <mlankhorst>     atomic = 0}, priv_ptr = 0x0}
[12:07] <mlankhorst> (gdb) print *(struct radeon_bo_gem*)((struct radeon_exa_pixmap_priv*)exaGetPixmapDriverPrivate(dst))->bo
[12:07] <mlankhorst> $3 = {base = {ptr = 0x0, flags = 0, handle = 9, size = 5299200, alignment = 0, domains = 2, cref = 2, bom = 0x5555559d81b0, space_accounted = 0, referenced_in_cs = 0}, name = 9, map_count = 0, reloc_in_cs = {
[12:07] <mlankhorst>     atomic = 0}, priv_ptr = 0x0}
[12:07] <mlankhorst> [  491.685460] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x9
[12:08] <mlankhorst> it still has refcount set >:(
[12:17] <kgunn> duflu: so is that branch good to go ?....e.g. add it to qa-testing2? or just build local for more confidence?
[13:02] <kgunn> mlankhorst: i see chris went to bed, so does ati work with multimon ? (i'm guessing no...)
[13:03] <mlankhorst> kgunn: it sort of looks like I'm hitting a kernel bug
[13:04] <kgunn> mlankhorst: does it work on standard xmir (w.o multimon?)
[13:05] <mlankhorst> hm I ws trying to rollback kernel, I guess standard xmir would be easier to test
[13:05] <kgunn> mlankhorst: glad i asked :) save you some effort
[13:14] <mlankhorst> hm I guess that works, weird stuff..
[13:17] <kgunn> mlankhorst: so xmir in archive works...but xmir (multimon, qa-testing2 ppa) does not ?
[13:18] <mlankhorst> yeah
[13:18] <kgunn> meaning...can't boot to unity ? or cycles endlessly on greeter ?...curious the symptom/end user result
[13:18] <mlankhorst> right now I just forced it to crash, saves times
[13:18] <kgunn> :)
[13:19] <kgunn> ricmm: i know you're swamped....had a chance to try xmir-multimonitor?
[13:19] <kgunn> rsalveti: ^
[13:20] <rsalveti> kgunn: will try today, have an ati board here
[13:20] <rsalveti> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620/M82 [Mobility Radeon HD 3450/3470]
[13:21] <kgunn> rsalveti: well... :)   ...i'm sure you can see mlankhorst 's posts above
[13:21] <rsalveti> but is that the same board?
[13:21] <rsalveti> mine is quite old
[13:22] <rsalveti> but guess I'd get the same crash
[13:22] <rsalveti> we'll see
[13:23] <ricmm> kgunn: negativo
[13:23] <ricmm> and I actually cant, I dont have a second monitor
[13:23] <ricmm> :(
[13:26] <mlankhorst> not required
[13:26] <mlankhorst> I was testing a single monitor setup
[13:27] <kgunn> ricmm: so it would still be useful to see if you can boot into a useable unity session even on 1 monitor
[13:53] <kgunn> RAOF: duflu ....just sharing, seems nvidia at least did get to run http://<IP_ADDRESS>:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-nvidia-gt440-le/ws/results/800x600.output
[13:53] <kgunn> altho...looks like it hung or bailed on the last test (unsure)
[13:54] <kgunn> ....looking from syslog...whoopsie might have gotten in the way ?
[13:54] <kgunn> mlankhorst: ^....just sharing...no action
[13:54] <mlankhorst> nouveau is easier to test though :P
[13:54] <kgunn> thomi: robotfuel ^
[13:55] <robotfuel> kgunn: I am watching some of the jobs now, I think some of the failures are because of the install phase package names had changed.
[13:56] <robotfuel> kgunn: I didn't setup the ppa2 jobs
[13:56] <kgunn> robotfuel: thanks....actually....i see a radeon run now too :)
[13:56] <kgunn> http://<IP_ADDRESS>:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-radeon-hd7450-le/ws/results/
[13:57] <robotfuel> kgunn: it looks like package name issue is fixed but hasn't been run, I can also disable whoopsie
[13:57] <kgunn> robotfuel: is that your subtle way of blaming the kiwi's :)
[13:57] <kgunn> mlankhorst: http://<IP_ADDRESS>:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-radeon-hd7450-le/ws/results/
[13:57] <kgunn> so that's interesting....that actually ran
[13:57] <mlankhorst> kgunn: yeah but I'm on drm-next
[13:58] <kgunn> mlankhorst: oh...
[13:58] <robotfuel> kgunn: this one also looked like openarena finished http://<IP_ADDRESS>:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-radeon-hd5750-le/4/artifact/results/
[13:58] <kgunn> mlankhorst: that was lost on me...so qa-testing2 on drm-now...is ok?
[13:58] <mlankhorst> no idea, stupid laptop won't cooperate :P
[13:58] <kgunn> olli_: ^
[13:58] <kgunn> olli_: so looks like nouveau & radeon are actually running
[13:59] <kgunn> not sure why the report says fail...but if you dig...you can see results
[14:00] <robotfuel> kgunn: unity-system-compositor wasn't running on that build I linked to before http://<IP_ADDRESS>:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-radeon-hd5750-le/4/artifact/results/ps-aux.log
[14:01] <kgunn> robotfuel: ah...got too excited
[14:05] <kgunn> robotfuel: so can you confirm the following...xmir-mm (aka qa-ppa2) on ati & nouveau specifically
[14:05] <kgunn> robotfuel: is actually running xmir & can boot to a usable unity ui (first)
[14:05] <robotfuel> kgunn: unity system compositor wasn't running on the intel jobs, I am rerunning everything now, it looks like the tests were fixed 6 hours ago, but they were run 10 hours ago
[14:06] <kgunn> robotfuel: second, can you actually plug/unplug a second monitor monitor
[14:06] <kgunn> robotfuel: like manually
[14:06] <kgunn> robotfuel: like...as soon as you're able
[14:06] <robotfuel> kgunn: sure, I will drive in during lunch
[14:06] <kgunn> robotfuel: is there anyone in the office who could try ?
[14:07] <kgunn> sorry racing clock
[14:07] <robotfuel> rfowler might be in.
[14:09] <robotfuel> kgunn: which machine do you want the monitor tried on first?
[14:09] <kgunn> robotfuel: either...
[14:09] <kgunn> robotfuel: we're just looking for a sanity test of multimonitor on xmir
[14:20] <kgunn> robotfuel: can't seem to find anyone else in lex...so i might just be needing you to head for lunch
[14:21] <robotfuel> kgunn: sounds good I can head in right after a meeting I have at 11am (40 minutes)
[14:22] <kgunn> robotfuel: much thanks
[14:38] <robotfuel> kgunn: I am getting no video on the kvm on intel with the qa-testing2 ppa
[14:39] <mlankhorst> hm guess it's not just me then :P
[14:39] <kgunn> robotfuel: meaning?...like you're in the unity ui but you can play youtube videos? or just nothing?
[14:39] <robotfuel> kgunn: black screen
[14:40] <robotfuel> kgunn: no ui
[14:40] <kgunn> robotfuel: are the other intels the same??
[14:40] <robotfuel> kgunn: yes same issue
[14:41] <kgunn> robotfuel: what does apt-cache policy for xserver-xorg-video-intel say ?
[14:41] <kgunn> robotfuel: what does apt-cache policy for unity-system-compositor say also ?
[14:43] <robotfuel> kgunn: the driver is the issue apt-get install unity-system-compositor didn't pull in the driver.
[14:43] <kgunn> robotfuel: sorry...i just have to ask...ppa pinned ?
[14:44] <robotfuel> kgunn: yes it's pinned
[14:44] <robotfuel> kgunn: unity-system-compositor is installed from the pinned ppa
[14:45] <robotfuel> kgunn: sudo apt-get install xserver-xorg-video-intel pulls in the driver from the pinned ppa
[14:46] <robotfuel> kgunn: seems like a packaging bug
[14:46] <kgunn> robotfuel: just curious....how so ?...i was wondering....how is it pinned ??
[14:46] <kgunn> take a look at this doc
[14:46] <kgunn> https://docs.google.com/a/canonical.com/document/d/1hmSrL_ZqnpMo0oDf-lee22J2cJr54jWmCeziMxR131s/edit
[14:47] <kgunn> ^ i am wondering if you need the extra bit at the top
[14:47] <robotfuel> cat /etc/apt/preferences.d/50-pin-mir.pref Package: *
[14:47] <robotfuel> Pin: origin "private-ppa.launchpad.net"
[14:47] <robotfuel> Pin-Priority: 1001
[14:47] <robotfuel> Package: *
[14:47] <robotfuel> Pin: release o=LP-PPA-mir-team-qa-testing2
[14:47] <robotfuel> Pin-Priority: 1002
[14:47] <kgunn> my pin is like the bottom
[14:47] <robotfuel> kgunn: my pin is like the bottom
[14:47] <kgunn> robotfuel: cool...
[14:48] <kgunn> so that's not it
[14:48] <kgunn> robotfuel: i guess you'll need to check the blasted ati/nouveaus as well...
[14:48] <robotfuel> kgunn: I can add the drivers to apt-get install line to get the correct driver.
[14:48] <mlankhorst> looks like I messed up nouveau vblank in my tree, time to retest :P
[14:48] <robotfuel> radeon is a black screen
[14:48] <kgunn> robotfuel: thanks
[14:49] <robotfuel> kgunn: wrong driver
[14:49] <mlankhorst> robotfuel: anything in dmesg?
[14:49] <robotfuel> kgunn: I need to update the test and re-run pulling in the driver.
[14:49] <robotfuel> oops mlankhorst^
[14:51] <kgunn> robotfuel: no problem...and as usual...thanks for the help
[14:51] <mlankhorst> fwiw, same blackness here
[14:52] <mlankhorst> on nouveau at least
[14:54] <kgunn> mlankhorst: you get matches on cross check of apt-cache policy & qa-testing2  packages ?
[14:56] <mlankhorst> yes
[14:59] <kgunn> mlankhorst: does it make it to greeter ?
[15:00] <mlankhorst> it's black, no idea, all I know is it doesn't crash
[15:01] <kgunn> freaky...what does Xorg.0.log say ?
[15:01] <mlankhorst> nothing interesting
[15:01] <mlankhorst> pretends everything is fine
[15:02] <kgunn> mmmm...can you vt switch....then $ sudo chmod 777 /tmp/mir_socket...$ sudo mir_demo_client_egltriangle...then switch back to vt7 ?
[15:03] <kgunn> robotfuel: are you actually in office  already ?
[15:03] <kgunn> must be driving
[15:04] <robotfuel> kgunn: no in a meeting
[15:04] <mlankhorst> kgunn: triangle works nicely
[15:04] <mlankhorst> but I like the plasma one more :p
[15:04] <kgunn> mlankhorst: do you see unity as a backdrop to the triangle ?
[15:04] <mlankhorst> no the same blackness
[15:05] <kgunn> huh
[15:05] <hikiko> mmm anyone for the meeting?
[15:05] <kgunn> so mir is up..u-s-c is up no problem
[15:05] <mlankhorst> I think RAOF needs to get back to the drawing board somehow, and review what is going on with lifetime :P
[15:05] <hikiko> I am alone there :)
[15:05] <kgunn> hikiko: uk is off today...
[15:05] <hikiko> oh :) i see
[15:05] <kgunn> hikiko: free day to focus on mir-on-mir :)
[15:06] <kgunn> mlankhorst: right...but this means mir is up, its like compiz failed
[15:06] <kgunn> mlankhorst: or...xmir failed to hook up compiz to u-s-c frontend
[15:06] <kgunn> mlankhorst: is there a way to verify is compiz loaded/rendered....but buffer just didnt make it to screen ?
[15:07] <kgunn> like there should be more than one gl client active
[15:07] <kgunn> 1 for mir....and 1 or more for unity/compiz
[15:08] <hikiko> mm then here's a quick status in case someone has time to review my branches: https://code.launchpad.net/~hikiko/mir/mir.native-gbm-platform-class https://code.launchpad.net/~hikiko/mir/mir.gbm-buffer-allocator-modifications
[15:08] <kgunn> mlankhorst: just trying to think how to help RAOF with some usable debug
[15:08] <hikiko> bye!
[15:12] <robotfuel> kgunn: I have a black screen on radeon using http://ppa.launchpad.net/mir-team/qa-testing2/ubuntu/ saucy/main xserver-xorg-video-radeon
[15:13] <kgunn> robotfuel: anything interesting at the end of /var/log/Xorg.0.log ?
[15:14] <robotfuel> kgunn: a lot of this [    28.871] reloc emit failure -22 (evergreen_set_render_target 318)
[15:14] <robotfuel> [    28.871] reloc emit failure -22 (evergreen_cp_set_surface_sync 371)
[15:14] <kgunn> mlankhorst: ^
[15:15] <kgunn> robotfuel: curious can you vt switch, then $ sudo chmod 777 /tmp/mir_socket
[15:16] <kgunn> then $sudo mir_demo_client_egltriangle...then vt switch back to vt7....and see what happens?
[15:16] <robotfuel> kgunn: ok
[15:19] <robotfuel> kgunn: vt change has a scrolling error gem object lookup failed 0xa
[15:19] <robotfuel> kgunn: this is on radeon
[15:19] <kgunn> robotfuel: got it....all good data
[15:20] <kgunn> robotfuel: did you do a cross-check match of packages installed vs qa-testing2 ?
[15:22] <robotfuel> kgunn: doing that now, it looks good so far
[15:22] <sil2100> kgunn: hi!
[15:23] <sil2100> kgunn: during the last mirslave run we noticed that one of the AP tests failed on both machines
[15:23] <sil2100> kgunn: https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/1276/
[15:24] <sil2100> kgunn: not sure if that's just a flacky test or is this a real failure, but I think I'll fill in a bug anyway
[15:26] <kgunn> sil2100: ack...
[15:26] <kgunn> thomi: ^
[15:26] <robotfuel> kgunn: my meeting is over I am going to drive in to lexington
[15:27] <kgunn> robotfuel: cool...it'll be easier for you there i'm sure...just ping me when you're ready
[15:31] <sil2100> kgunn: https://bugs.launchpad.net/unity-system-compositor/+bug/1216979
[16:31] <kgunn> bschaefer: hey...you got a spare set of cycles?
[16:32] <bschaefer> kgunn,  possibly, whats up?
[16:35] <kgunn> bschaefer: just lookin' for a second set of eyes/attempt on nouveau and/or ati
[16:35] <bschaefer> kgunn, yeah I can try, I've to finish up some reviews first
[16:35] <kgunn> using mir-team/qa-testing2 ppa
[16:35] <kgunn> sure
[16:35] <bschaefer> cool
[16:35] <bschaefer> ill let you know!
[16:36] <kgunn> low expectations...but if you try, let me know if you boot to a usable unity (single monitor :)
[16:37] <bschaefer> well hopefully I can :)
[16:44] <robotfuel> kgunn: I'll test nvidia first with multimonitor
[16:45] <robotfuel> kgunn: I am in the lab
[16:47] <kgunn> robotfuel: cool...
[16:48] <kgunn> robotfuel: will be good to know if you get the same black screen on boot
[16:49] <jono> kgunn, on the Mir multimonitor page I see I pin:
[16:49] <jono>     Package: * Pin: origin "private-ppa.launchpad.net" Pin-Priority: 1001 Package: * Pin: release o=LP-PPA-mir-team-qa-testing2 Pin-Priority: 1002
[16:50] <jono> but it says I use the     $> sudo add-apt-repository ppa:mir-team/system-compositor-testing PPA
[16:50] <jono> shouldn'
[16:50] <jono> shouldn't the pin represent that PPA?
[16:50] <jono> I just added the PPA and MM doesn'work for me
[16:50] <robotfuel> kgunn: it looks like one intel machine passed on the testing2 ppa (not a multi-monitor test)
[16:51] <kgunn> jono: dang it....(going to make a tshirt that says "i hate ppa's"
[16:51] <jono> kgunn, do I add a different PPA?
[16:51] <kgunn> jono: right...for now its all qa-testin2
[16:51] <jono> kgunn, so do I remove the system-compositor PPA?
[16:51] <kgunn> when we go live to test external...we'll use system-compositor-testing
[16:52] <kgunn> sorry for the confusion
[16:52] <jono> np
[16:53] <jono> kgunn, we go live today, right?
[16:53] <jono> according to balloons
[16:53] <kgunn> jono: yes
[16:53] <jono> cool
[16:53] <jono> will res changes and rotation be fixed this week?
[16:54] <jono> brb
[16:56] <kgunn> robotfuel: would you mind just hotplugging a monitor into the intel machine...so when olli asks i can say...yes, robotfuel saw multimon work on the anointed machine :)
[16:57] <robotfuel> kgunn: will do.
[16:57] <robotfuel> kgunn: the nvidia machine has a black screens
[16:57] <robotfuel> kgunn: I'll try the vt change thing and let you know how it goes
[16:58] <kgunn> robotfuel: sounds intimidating :)
[16:58] <kgunn> robotfuel: thanks
[16:58] <kgunn> and check xorg.0.log if you don't mind
[17:01] <robotfuel> kgunn:  x went to fallback mode after the vt switch
[17:02] <kgunn> robotfuel: ooo, well that's kinda nice
[17:02] <robotfuel> kgunn: fallback meaning low-graphics mode
[17:02] <kgunn> robotfuel: oh, nvmd that's awful
[17:03] <kgunn> robotfuel: Xorg.0.log ?
[17:04] <robotfuel> kgunn: I am grabbing that now, I'll pastebin it
[17:05] <kgunn> robotfuel: would be good to get one prior to vt switch (sorry to be so picky)
[17:06] <robotfuel> kgunn: http://pastebin.ubuntu.com/6029411/ (with vtswitch)
[17:08] <robotfuel> kgunn: without vtswitch http://pastebin.ubuntu.com/6029418/
[17:10] <kgunn> robotfuel: more than i could hope for...putting both in the bug
[17:11] <robotfuel> kgunn: do you want me to use apport on the u-s-c and xorg crashes?
[17:11] <kgunn> that'd be good robotfuel
[17:13] <kgunn> robotfuel: now just need to double check the ati's....i assume black screen...but need to check xorg & try vt switch as well...
[17:14] <robotfuel> kgunn: ack, after I do the apport thing I'll check ati, then intel last.
[17:14] <kgunn> great
[17:14] <kgunn> robotfuel: i'll brb...gonna eat a quick lunch
[17:35] <kgunn> robotfuel: i'm bacl
[17:35] <kgunn> back even
[17:47] <kgunn> and...quick reboot
[18:00] <bschaefer> kgunn, hey, I got a black screen,but I still heard the lightdm login sound...
[18:00] <bschaefer> i also was getting a strange error on my tty...but its not on any logs that I can find...
[18:00]  * bschaefer digs for it
[18:05] <robotfuel> bschaefer: something about gem object lookup failed?
[18:06] <bschaefer> robotfuel, yup!
[18:06] <bschaefer> i can't find it logged anywhere...
[18:06] <bschaefer> there it is:
[18:07] <bschaefer> kernel: [   67.625036] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xb
[18:07] <robotfuel> I have a 0xa on one with the kvm and 0x8 using 2 monitors
[18:07] <bschaefer> kernel: [   67.628417] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xb
[18:07] <bschaefer> kernel: [   67.629992] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2!
[18:08] <bschaefer> robotfuel, hmm interesting, let me try with 2 monitors, or one? I forgot if I had my other one turned on :)
[18:10] <bschaefer> though I don't think it matters much...
[18:11] <kgunn> bschaefer: thanks...adding your details to the bug
[18:11] <bschaefer> kgunn, my video card is: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Redwood XT [Radeon HD 5670/5690/5730]
[18:11] <bschaefer> the 5670 one...
[18:17] <robotfuel> kgunn: 2 of the intel machines time out, it looks like the benchmark hung using the new driver xserver-xorg-video-intel (2:2.21.14-4ubuntu2+xmirMM7) one of them passed
[18:21] <kgunn> robotfuel: did woopsie interfere ?
[18:22] <robotfuel> kgunn: I am watching the test run now to see what happens
[18:25] <kgunn> robotfuel: iirc i ran...but might have been one driver before....lemme run here
[18:33] <kgunn> robotfuel: hmmm running openarea no prob here...2 runs, 2 diff resolutions
[18:33] <kgunn> robotfuel: going to try my second machine
[18:44] <kgunn> robotfuel: did i miss it...did you also alreday check the ati machine(s)....just looking to be conclusive on "it didn't work" :)
[18:49] <kgunn> robotfuel: really only need 2 questions re qa-testing2 answered now #1) result of ati machine there boot to unity (single screen) & #2) did intel support hotplug of monitor to show multimon
[18:52] <robotfuel> kgunn: single intel on the kvm is messed up. I am trouble shooting that now.
[18:53] <robotfuel> kgunn: single monitor boot to unity on ati was a black screen.
[18:53] <robotfuel> kgunn: I'll plug in a monitor now, they are hard to get to.
[18:54] <kgunn> robotfuel: you might have to "liberate" some :)
[19:01] <robotfuel> kgunn: the video looked tiled on the kvm, but looks ok with a monitor connected
[19:02] <kgunn> robotfuel: ack thanks
[19:26] <robotfuel> kgunn: the intel machines don't have a place for a second monitor, they only have one hdmi port, no vga or dvi
[19:27] <kgunn> robotfuel: haha
[19:27] <kgunn> you can't make this stuff up
[19:30] <robotfuel> kgunn: the ps-intel-3000 has a vga and display port, so I can test it on that machine. the other 2 only have hdmi
[19:30] <kgunn> robotfuel: that's ok...both DP and hdmi worked
[19:38] <robotfuel> kgunn: benchmarks are up http://reports.qa.ubuntu.com/graphics/openarena/
[19:39] <kgunn> robotfuel: awesome! thanks...thanks for all the hard work that has gone (and is going) into that
[19:40] <robotfuel> kgunn: you can double click the bar and it will take you to the jenkins build for that run, so you can look at the log files easily.
[19:40] <kgunn> robotfuel: you're going to spoil us
[20:14] <robotfuel> kgunn: on intel xrandr is reporting 2 monitors are connected, even though only one monitor is connected
[20:15] <robotfuel> kgunn: I turned off the second monitor and the screen is blank now. (there was XMIR-0 and XMIR-2, I did xrandr --output XMIR-2 --off)
[20:16] <kgunn> robotfuel: was that using displayport ?
[20:16] <robotfuel> kgunn: hdmi
[20:16] <kgunn> hmmm...hadn't seen weirdness from hdmi yet...that's a good bug tho
[20:16] <kgunn> or good you caught it
[20:18] <robotfuel> kgunn: I resized XMIR-0 to 800x600 and it showed the 2 displays, one 800x600 and one 1024x768 display on the same monitor
[20:18] <robotfuel> I'll write a bug
[20:18] <kgunn> robotfuel: ta
[21:25] <jono> kgunn, installed the PPA, a bit of screwing with different res settings but dual-screen MM working perfectly on Intel :-)
[21:25] <kgunn> jono: good to hear :)
[21:25] <jono> kgunn, my default setup before-hand had part of the image chopped off
[21:59] <robotfuel> kgunn: will you need me in lexington tomorrow?
[22:00] <kgunn> robotfuel: i don't think so...
[22:02] <robotfuel> kgunn: ok I won't plan on it then. I won't be there first thing in the morning, but I'll drive in if you need me there again :)
[22:03] <kgunn> robotfuel: hey thank you for doing it today...greatly appreciate that...i owe you  abeer in a couple of weeks
[22:05]  * robert_ancell things kgunn is going to have a keg party :)
[22:06] <kgunn> robert_ancell: shhhhh
[22:06] <kgunn> that or just hand out fifths of whiskey
[22:08] <robert_ancell> thomi, could you copy the qa-ppa2 config and make a system-compositor testing one? That way we can test any of the PPAs in Jenkins
[22:11] <thomi> robotfuel: can you do that with your fancy-pants script?
[22:12] <robotfuel> thomi: so we want new tests or we want to modify the existing tests?
[22:12] <thomi> robotfuel: I guess a new set
[22:12] <thomi> with a corresponding new kickoff job
[22:13] <thomi> the only difference being the ppa we add
[22:13] <robotfuel> thomi: ok, I'll just need to create a new branch to pull from and I'll upload that
[22:13] <robotfuel> thomi: I'll ping you when I am done
[22:17] <netlar> Do they developers of apps for Ubuntu have to port over apps to mir, and if they do not the app will run on xmir right?
[22:25] <robotfuel> thomi: http://<IP_ADDRESS>:8080/view/sct-ppa/
[22:26] <thomi> robert_ancell: ^
[22:26] <thomi> thanks robert_ancell
[22:26] <thomi> err robotfuel
[22:26] <robert_ancell> thanks robotfuel!
[22:27] <robotfuel> thomi: BTW, I had to add apt-get install the intel radeon and nouveau drivers to get the qa ppa2 to work today
[22:28] <thomi> does the image install the proprietary drivers by default?
[22:29] <robotfuel> no those are the opensource drivers, they were pinned in the ppa, but not installed with apt-get install unity-system-compositor
[22:29] <robotfuel> if I explicitly do apt-get install xserver-xorg-<driver> they did get installed from the ppa
[22:31] <robotfuel> thomi: robert_ancell: BTW benchmarks are live http://reports.qa.ubuntu.com/graphics/openarena/
[22:31] <robert_ancell> robotfuel, this is from the main archive?
[22:32] <thomi> robotfuel: cool, I see my graph suggestions were too contentous to apply at short notice ;)
[22:32] <robotfuel> robert_ancell: yes the main archive
[22:32] <robert_ancell> robotfuel, can we get a line graph or similar? It's hard to tell if they're changing over time
[22:32] <robotfuel> thomi: I had your suggestions done in my first revision of the benchmarks using google charts. with the line graph and one day of results.
[22:33] <robotfuel> thomi: they didn't like the line graph
[22:33] <robotfuel> :(
[22:33] <thomi> yeah well, there's no educating some people
[22:34] <robotfuel> thomi: I could make a http://reports.qa.ubuntu.com/graphics/openarena/line and display a line graph
[22:34] <thomi> I should send someone a high school textbook and highlight the sections about histograms and bar graphs
[22:34] <thomi> robotfuel: nah, it's cool, I don't care that much :)
[22:34] <robotfuel> ok :) I am EOD ttyl
[22:35] <RAOF> Alright. Let's see if I can track down what madness I unleashed on radeon...
[22:38] <bschaefer> RAOF, if you need something to test out you can send me a patch :)
[22:38] <jono> RAOF, is https://bugs.launchpad.net/xmir/+bug/1192843 fixed?
[22:38] <RAOF> jono: no
[22:38] <jono> Matthew Garrett raised a valid point about this
[22:38] <jono> and I don't a clear mention of a security issue on the call for testing
[22:39] <jono> kgunn, ^
[22:40] <RAOF> Yes, we should stick a big fat warning on that.
[22:40] <kgunn> RAOF: jono robert_ancell ....i thot this was fixed
[22:41] <kgunn> we landed and i thot robert_ancell rebased on
[22:41] <RAOF> kgunn: The mir infrastructure required to fix that in XMir has landed; the actual fix in XMir isn't implemented.
[22:41] <robert_ancell> kgunn, no, only the first part of the fix is done - the bug report mentions that
[22:41] <jono> kgunn, RAOF, robert_ancell this really should have been mentioned in the call for testing
[22:41] <jono> I am updating the wiki now
[22:41] <kgunn> robert_ancell: my bad...can you add that to the ppa preamble ?
[22:42] <robert_ancell> kgunn, yes
[22:42] <kgunn> jono: so sorry...i really can't believe i missed that
[22:42] <kgunn> i guess we'll know if Matthew tries to test
[22:42] <jono> kgunn, unfortunately I heard about it from Matthew Garrett on Twitter
[22:42] <kgunn> jono: sorry...
[22:43] <jono> kgunn, nm
[22:44] <robert_ancell> kgunn, updated
[22:44] <kgunn> ta
[22:44] <robert_ancell> RAOF, anything I can do to help get that fixed in XMir?
[22:45] <robert_ancell> kgunn, there's two bugs marked "sessions" at the bottom of the description of the PPA - did you add that?
[22:45] <kgunn> robert_ancell: nope those were there...
[22:46] <robert_ancell> it's the VT input bugs, I've just moved them to the top
[22:50] <RAOF> robert_ancell: You could check that USC marks every surface as unfocused on VT switch.
[22:50] <robert_ancell> RAOF, will do
[22:51] <RAOF> robert_ancell: And that USC marks (at least one, but preferably) each window of an active session as focused.
[23:06] <kgunn> robert_ancell: i'm actually going get off for a while....but i'll be back on late just to check in
[23:07] <robert_ancell> kgunn, bye
[23:56]  * robert_ancell -> lunch


[00:02] <diddledan> (telegram is where all the cool kids seem to be, these days)
[00:02] <diddledan> and by cool kids, I mean popey and Wimpress
[00:02] <ali1234> the gif is currently the number one post on reddit lol
[00:03] <diddledan> that just proves the visceral nature of reddit for discerning news
[00:04] <ali1234> can you use telegram without giving them your phone number?
[00:04] <diddledan> no :-(
[00:04] <ali1234> not interested then
[00:04] <diddledan> it's not as bad as whatsapp though, which requires you to share your contacts before it lets you talk to anyone
[00:22] <daftykins> somewhere out there, there's probably a shauno, too...
[00:22] <daftykins> hmm not even not-shauno has been very active these days
[00:22] <daftykins> in fact he's gone!
[00:22] <diddledan> :-o
[00:23] <daftykins> ( m0nkey )
[00:23] <daftykins> if that was even the nick
[00:23] <diddledan> it was, and is
[00:23] <diddledan> he's over in #freenas right now
[00:24] <daftykins> daym he quit on us
[00:25] <diddledan> https://www.anandtech.com/show/12665/western-digital-launches-ultrastar-dc-hc530-14-tb-pmr-with-tdmr-hdd
[00:26] <daftykins> amusingly i just pasted that elsewhere, 267MB/sec from a spinner!
[00:29] <diddledan> interesting.. that article helpfully points out that 14TB offers 40% more space than 10TB
[00:31] <daftykins> cor
[00:31] <daftykins> a news bot in another channel usefully reported that debian 10 was to be succeeded by 11 and 12, the other day o0
[00:31] <diddledan> omg. really? 11?!
[00:32] <daftykins> i don't even know if i have the numbers right :>
[00:32] <diddledan> it's 1 louder!
[00:47] <Wimpress> diddledan: Cool?!
[07:19] <brobostigon> morning boys and girls.
[07:36] <zmoylan-pi> o/
[07:43] <brobostigon> o/
[08:00] <SuperMatt> morning
[08:04] <brobostigon> morning
[08:45] <knightwise> heyapeepz
[08:53] <brobostigon> hi knightwise
[21:05] <daftykins> hrmm someones OnePlus 3T android phone was on strike from showing calendar entries today, (google apps, but MS Exchange account)
[21:05] <daftykins> had to delete it and re-add to win :O


[00:47] <CIA-4> usb-creator: rgreening * r112 usb-creator/ (3 files in 2 dirs): (log message trimmed)
[00:47] <CIA-4> usb-creator: Update KDE ui (replace some Qt elements with KDE ones and connect some signals to the ui)
[00:47] <CIA-4> usb-creator: Reorganize some code (move some UI initialization to __initUI)
[00:47] <CIA-4> usb-creator: Make reference to backend really private
[00:47] <CIA-4> usb-creator: Try and fix format missing volume crash with a try/except block
[00:47] <CIA-4> usb-creator: Add source_selection_changed and connect appropriate signal to it
[00:48] <CIA-4> usb-creator: Add isEnabled check for the persist ui elements to get_persistence
[08:23] <mattn_> hi
[08:23] <mattn_> i'm trying to set up an modified live-cd at our company
[08:23] <mattn_> it works already great
[08:23] <mattn_> but now i'm trying to add a casper script to modify some gconf settings and desktop stuff
[08:23] <mattn_> adding a new script to /usr/share/initramfs-tools to the casper-bottom folder doesn't help
[08:23] <mattn_> seems the new script is not executed at all
[08:24] <mattn_> is there any documentation available on how to customize casper?
[08:24] <mattn_> even update-initramfs -u isn't helping
[08:40] <waters> Problem with install .. I just downloaded the iso .. however .. when i try to install .. i have to install in safe graphic mode ... or i only get the blue screen ... Any ideas on this ... Main problem is the only CD i had after i get to 60% tells me it's an input/output error ... so .. i can use the thing from fedora to make a live os on my flash drive ... boot that way .. but .. I cant get it to run in safe mode ... dont know how
[09:10] <waters> Help .. i need some help with installing ...
[09:11] <waters> all i get is the blue screen of death ... unless i run in safe graphics mode ...
[09:13] <davmor2> waters: try asking on #ubuntu  this channel is really meant for development use
[09:14] <davmor2> #ubuntu+1 for karmic
[09:22] <evand> waters: are you installing using Wubi?
[09:22] <waters> nope
[09:22] <waters> i live cd
[09:22] <waters> a live 9.04 cd
[09:23] <waters> i can get it to kinda work if i use the safe graphics mode option ... but doesnt go all the way
[09:23] <evand> I'm confused then, what is this blue screen you're talking about?  Ubuntu doesn't have that kind of kernel panic mechanism yet
[09:24] <waters> i think it's an Xwindows problem ..
[09:24] <waters> like if i do ctrl+alt+f1 and get into a console
[09:24] <waters> i can do dmesg
[09:25] <mattn_> davmor2: isn't this the correct channel for my question, too? also tried #ubuntu-devel
[09:25] <waters> and i see an error drm:i915-GET_VBLANK_COUNTER} *ERROR* tying to get vblank counfor disabled pipe 1
[09:26] <evand> lets start with the safe graphics mode problem
[09:27] <evand> can you get to a console and type ubuntu-bug xorg
[09:27] <waters> yep ...
[09:27] <evand> please describe the graphics problem in as much detail as you can (you're running the live CD, you had to run safe graphics mode, etc)
[09:28] <davmor2> mattn_: that would probably be best asked here.
[09:28] <mattn_> davmor2: thanks - then i'll idle around here and wait for help ;)
[09:29] <waters> safe graphics is the only way i can see anything when i start the install ... it get's to 60% .. then tells me that the CD or CD-ROM has a problem .. INPUT/OUTPUT ... ok .. so i check the desk .. from the start up ..and it doesn't find a problem ..
[09:29] <waters> so .. i try to install normal ... no screen ...
[09:29] <waters> screen is blue ..
[09:30] <evand> waters: right, so the fact that you're getting into safe graphics at all is a bug that I'm kindly asking you to file using ubuntu-bug xorg
[09:30] <waters> yeah
[09:30] <evand> waters: now, regarding the input/output issue, if you can get to the try or install option in safe graphics mode
[09:31] <waters> i did .. and it get's to 60%
[09:31] <evand> select install, run it until it crashes, and then put your /var/log/syslog on http://pastebin.ubuntu.com, I'd be happy to look at it further
[09:31] <waters> ok... thanks
[09:31] <evand> sure thing
[09:33] <waters> installing ...
[09:37] <evand> mattn_: the easiest way is going to be unpacking an existing CD, modifying from there, and then rebuilding the initramfs: https://help.ubuntu.com/community/LiveCDCustomization#Boot init
[09:37] <mattn_> evand: that's what i'm doing
[09:38] <mattn_> just added a new script to the casper-bottom dir and ran update-initramfs -u
[09:38] <mattn_> inside the chroot of course
[09:41] <evand> mattn_: when you boot the CD, hit F6, then escape, then add break=top to the kernel command line parameters.  Is your script in /scripts/casper-bottom, is it +x?
[09:44] <mattn_> yes - it is executable
[09:44] <mattn_> will try that break=top once i've burned and created the latest version
[11:39] <mattn_> evand: no, my customized script is not there - thanks for pointing this switch for me. so i'm doing something wrong while creating the initrd
[11:39] <mattn_> that's something i can work with - thanks
[11:40] <evand> anytime
[12:13] <CIA-4> user-setup: cjwatson * r183 ubuntu/ (debian/changelog user-setup-ask):
[12:13] <CIA-4> user-setup: Allow underscores in usernames, matching change in adduser 3.110ubuntu3
[12:13] <CIA-4> user-setup: (LP: #388822).
[12:15] <CIA-4> user-setup: cjwatson * r184 ubuntu/debian/changelog: releasing version 1.26ubuntu2
[12:26] <CIA-4> iso-scan: cjwatson * r265 ubuntu/debian/ (69 files in 2 dirs): merge lp:~al-maisan/iso-scan/ubuntu
[13:54] <rgreening> good day evand
[13:54] <evand> hello
[13:54] <rgreening> did you have a chance to look at my changes evand
[13:55] <rgreening> I'd like to add the wrappers to gtk_frontend.py and merge kbackend.py changes to kbackend.py
[13:55] <rgreening> I tested the kde side, and it works!!!!!! :)
[13:56] <evand> no, I haven't yet
[13:56] <rgreening> yay
[13:56] <evand> but fantastic
[13:56] <rgreening> I still have the io/watch/child functions to wrap.. but the timeout_add is completed.
[13:57] <rgreening> evand: http://roderick-greening.blogspot.com/ - have a quick look at the second post. describes what I did.
[14:02] <evand> good deal
[14:03] <rgreening> :)
[14:05] <rgreening> so, I think it's merge worthy into main backup.py and moving the required stuff to gtk_frontend.py using a quick wrapper to the same call. It's simpler on the gtk side, as we are only using the wrapper to move the function to frontend.
[14:12] <evand> okay, I'll try to take a closer look once I've cleared some other work off my plate.
[14:13] <rgreening> k\
[14:13] <rgreening> I'll see about the remaining gobject stuff.. see how to port them...
[14:14] <rgreening> can't wait to finish this part... then it's just cleanup tasks (translations, packaging, etc).
[15:34] <cr3> evand: reping, might you have a moment to help me understand some preseeding of ubiquity?
[15:35] <cr3> cjwatson: you might know this on top of your head: when installing from the desktop image, the content of .disk/info gets copied to one of the files under /var/log/installer. does the same happen when netinstalling from the alternate image? I'm guessing not because the netinstall could just as well be done directly from the archive
[15:38] <cjwatson> cr3: bug 364649
[15:39] <cjwatson> cr3: i.e. I don't think it does yet, and indeed it isn't guaranteed to exist in general
[15:39] <evand> cr3: sure
[15:42] <cr3> evand: so, to follow up on the thread for preseeding the clock-setup, I'm not sure I understand how to determine the package for which to define the preseed. for example, is this right: ubiquity clock-setup/ntp-server string foo.com
[15:43] <cr3> evand: I tried grepping around ubiquity for ntp-server but I couldn't find anything, so I'd like to have a better understanding of what happens
[15:45] <evand> cr3: it's in clock-setup, which ubiquity uses.  apt-get source ubiquity; cd ubiquity/d-i/source/clock-setup
[15:45] <evand> ah, I misread
[15:45] <evand> d-i or ubiquity is fine, they'll both work
[15:48] <cr3> evand: hm, how does that work? re. d-i or ubiquity? does that mean anything supported by d-i could be passed along by ubiquity?
[15:49] <cjwatson> err, the owner is not really very connected to that question
[15:49] <cjwatson> the first field of a preseed line specifies the owner of the question from debconf's point of view
[15:49] <cjwatson> this is used for garbage-collection when packages are removed
[15:50] <cjwatson> "d-i" is a special owner that says "don't copy this question to the installed system", for d-i
[15:50] <cjwatson> since we don't copy most questions to the installed system at all for ubiquity yet, it doesn't make a whole lot of difference, but when we implement that I guess we'll allow both "d-i" and "ubiquity" to have the same meaning
[15:51] <cjwatson> in general when preseeding things that are part of the installer you should use "d-i" (or "ubiquity" is OK too in the case of the desktop CD). When you expect preseeding to be processed by a package that's installed on the target system, use the appropriate package name
[15:53] <cr3> cjwatson: when you say the "the owner is not really very connected to that question", do you mean clock-setup/ntp-server for example which is not really connected to any owner and could potentially be given foobar as an owner, with the only difference that it won't be garbage collected and may affect the package foobar inadvertently?
[15:57] <cr3> cjwatson: potentially, I could reuse the preseed I use for the alternate image and just augment it with a few ubiquity-specific seeds and I should be good to go
[16:00] <evand> cr3: I believe that's exactly what he's saying, but you should still use d-i so it will be garbage collected :)
[16:01] <cr3> evand: right, I was just checksumming that my understanding was correct with some convoluted example :)
[16:01] <evand> heh, sure
[16:03] <shtylman> evand: I have a few ideas I have been throughing around for the kubuntu ubiquity installer (http://shtylman.com/stuff/kubuntu_installer/ubiquity_idea1.png) .. the biggest question I have is about the sidebar on the left...those are one work descriptions of the task and would probly require new translation entries...would that be acceptable if we went with something like this for kubuntu?
[16:04] <rgreening> blingy shtylman :P
[16:04] <shtylman> rgreening: :) one does try
[16:04] <cr3> evand: another question for you: what's the difference between the ubiquity and user-setup owners? for example, I see both being used for passwd/username
[16:05] <evand> creating strings for translation isn't a big deal for something like this, but my concern is screen space.  Those strings could get quite large when translated and we're already quite tight on space
[16:05] <evand> unfortunately I don't have a better suggestion :-/
[16:06] <evand> cr3: probably the difference of grabbing them via debconf-get-selections
[16:07] <cr3> evand: in case I want to add more preseed variables, how can I determine whether a particular variable might need to be grabbed via debconf-get-selections?
[16:07] <cjwatson> cr3: if you give it "foobar" as an owner, it will get copied to the installed system and never ever be removed unless you install and then purge a package called "foobar"
[16:07] <cjwatson> cr3: but otherwise yes
[16:07] <shtylman> evand: thanks...I will think about that...didn't really thing about horizontal space :/ (damn my large monitors)
[16:07] <evand> shtylman: my fault for not pointing this out earlier, but today is FeatureDefinitionFreeze.  I'm not entirely sure if that means community specs have to be done as well, though I would assume so.
[16:07] <cjwatson> cr3: by "the owner is not really very connected to that question" I meant that what owner you happen to set has nothing to do with whether anything supported by d-i can be passed along by ubiquity
[16:08] <evand> https://blueprints.edge.launchpad.net/ubuntu/+spec/kubuntu-karmic-ubiquity is looking a bit bare at the moment :)
[16:08] <cjwatson> cr3: you should never be using "user-setup" as an owner; that's a bug
[16:08] <cjwatson> cr3: as evand says, it might come from debconf-get-selections. Don't use debconf-get-selections.
[16:08] <cr3> evand: one of my concerns is that if I attempted to reuse the preseed I use for the alternate image for ubiquity, then passwd/username wouldn't've worked because I would've had to add an extra line for user-setup too
[16:08] <evand> apologies for not being more clear on that
[16:08] <cjwatson> cr3: use the installation guide instead; we add things that are actually useful there
[16:09] <cjwatson> right now, debconf-get-selections just gives you *everything*, including loads of stuff that's internal and shouldn't be preseedd
[16:09] <shtylman> evand: oh my...didn't know that...been all tied up with OO work...
[16:09] <cjwatson> +e
[16:09] <shtylman> ok...I will get on the spec fill out...with this mockup and see what I can produce
[16:09] <cr3> cjwatson: I've been using the preseed.txt.gz from the installation-guide as the base for my preseed template, which has been very useful. should I be expected to be able to use the exact same file for ubiquity as well?
[16:11] <cr3> by the way, I grab that preseed.txt.gz for each release and just add a few macros here and there to keep the diff between my file and the default one in the guide as short and readable as possible
[16:11] <cjwatson> cr3: largely
[16:12] <cjwatson> cr3: https://wiki.ubuntu.com/UbiquityAutomation documents the major differences (subject to errors and omissions)
[16:12] <cr3> cjwatson: excellent! I'll give that a try and follow up if there are any such errors and/or omissions. thanks for the reference!
[16:13] <cr3> using the same file for both alternate and desktop will make things much easier to maintain
[16:21] <cjwatson> I see you were the last person to edit that wiki page ;-)
[16:25] <cr3> cjwatson: I have to do so many things so far and wide, I don't even remember what I might've edited and it was only a month ago :)
[17:04] <evand> kirkland: Is there anything else that needs to be covered, or you would like to add to https://wiki.ubuntu.com/ServerKarmicEncryptedSwap ?
[17:05] <xivulon> evand, we can ship r136
[17:05] <xivulon> I have already starting moving forward to 9.10
[17:05] <xivulon> should be able to play with grub2 soon
[17:06] <evand> xivulon: indeed, I ran it by slangasek this morning and I just have to find time today to push it to releases.ubuntu.com
[17:06] <xivulon> cool
[17:06] <evand> xivulon: as today is Feature Definition Freeze, can you ensure that the Wubi specification for Karmic is drafted and ready to be reviewed?
[17:07] <xivulon> sure
[17:08] <evand> great, thank you
[17:08] <xivulon> will have to do it tonight do not have the gobby log with me (is it available online?)
[17:09] <xivulon> on colinux integration, did you have a chat with the kernel team?
[17:09] <evand> did we take notes in gobby?
[17:09] <xivulon> yes
[17:09] <evand> xivulon: not yet, please make that an action item of the spec
[17:09] <xivulon> I did
[17:09] <evand> one second, I'll pull them down
[17:11] <evand> I've emailed them to your gmail account
[17:11] <xivulon> I think that daemonccc is also working on that (see #376807)
[17:16] <evand> I've also dumped the notes here: https://wiki.ubuntu.com/FoundationsTeam/Specs/KarmicWubi and linked everything up.
[17:16] <xivulon> ot: was looking at genie programming language today (vala with python syntax), I love that stuff!
[17:17] <evand> I still think that the kernel patches are a *huge* blocker to official support and distribution from Ubuntu, but I'll follow up with the kernel team per the specification
[17:17] <evand> neat
[17:17] <xivulon> thanks
[17:19] <xivulon> as to genie it would be really cool if it cool spit out c code without gobject when objects are not used, and maybe integrated with tinypy with gobject introspection for embedding...

[17:22] <kirkland> evand: i've been seeing your updates/changes
[17:22] <kirkland> evand: let me read in full
[17:23] <kirkland> evand: looks great; simple, to the point; major points covered
[17:24] <evand> fantastic
[17:24] <xivulon> evand, shall I put everything in that spec? it's really 2 or 3 things: colinux, wubi-migration, wubi-enhancements, macbook (unlikely)
[17:26] <evand> I'd put them all in, but do note that individual bits can still be dropped and the spec can be considered complete for karmic
[17:27] <evand> case in point, colinux
[17:27] <xivulon> and macbook...
[17:27] <evand> right
[17:27] <xivulon> we already have a page for the migration tool by the way
[17:28] <evand> indeed, I'd just reference that
[17:28] <evand> as I believe we marked it as approved for 9.04
[17:28] <evand> or 8.10 :)
[17:29] <xivulon> 9.04, I guess we changed our views a bit
[17:29] <evand> oh, good call
[17:29] <xivulon> just to confirm, we will have migration inside of standard ubiquity, so we will not need a stage 1
[17:30] <xivulon> previously we agreed to have a stage 1 from within ubuntu, in karmic we decided to actually autodetect wubi installations
[17:32] <evand> right, I think this is best done within the live environment.  I see no reason for any work outside of that.
[17:32] <xivulon> yes that is in line with what discussed at last UDS, I will change the previous wiki
[17:37] <waters> Hi .. when i start ubuntu (a new install) all i get is a blank screen .. i can ctrl+alt+f1 and get to a console ... when i go dmsg i get this error: [drm:i915_get_vblank_counter} *ERROR* trying to get vblank count for disabled pipe 1.. Anyone got time to help?
[17:41] <xivulon> mpt, evand I had mentioned this change to the partitioning page UI in california, created a new page: https://wiki.ubuntu.com/UbiquityPartitioningPageProposal
[17:41] <xivulon> still think it's a good approach
[17:43] <evand> xivulon: I started a conversation with Ivanka (head of the Design and User Experience team) at UDS on ubiquity usability.  They seem to be a bit too busy for us at the moment, but she said the installer was on her radar, and I'll be sure to bring that design up when our turn comes for their resources.
[17:44] <cjwatson> waters: I think you'll need to ask either the kernel or X folks; it's a bit beyond me at least
[17:45] <waters> ok .. thanks
[17:46] <cody-somerville> cjwatson, Someone from Debian asked me to advocate LP #387944
[17:51] <cjwatson> cody-somerville: yes, I'm aware of it and am merging busybox at the moment
[17:51] <cjwatson> I'm already planning to include that change in my upload
[17:51] <cody-somerville> cjwatson, Thanks.
[17:51] <cody-somerville> :)
[17:51] <mpt> xivulon, I like the first part
[17:53] <evand> mpt: any idea on when and if you guys will be looking into the installer?
[17:53] <mpt> evand, no, sorry
[17:53] <mpt> I'd dearly love to
[17:53] <evand> no worries at all
[17:53] <evand> we've already got plenty to do this cycle :)
[18:02] <xivulon> do you think that it would be possible to upgrade the packages concurrently with a Wubi migration? Say migrating 9.04 wubi installation via a 9.10 CD. Certainly it would be impossible to upgrade some of the packages.
[18:12] <CIA-4> usb-creator: rgreening * r113 usb-creator/ (TODO usbcreator/kde_frontend.py):
[18:12] <CIA-4> usb-creator: Begin working on translation support for kde_frontend.py (needs lots of love)
[18:12] <CIA-4> usb-creator: Add warning dialog for when user cancels progress dialog and update connects
[18:12] <CIA-4> usb-creator: Remove unnecessary update_persist_label() (update directly in connect instead)
[18:12] <CIA-4> usb-creator: Ensure Make Startup Disk button is disabled from start
[18:12] <CIA-4> usb-creator: Update TODO
[18:13] <evand> xivulon: one step at a time :)
[18:13] <evand> I'm happy to just have the migration working for 9.10
[18:14] <kirkland> cjwatson: got a minute?  i need to chat with you about /var/lib/ecryptfs/$USER
[18:15] <kirkland> cjwatson: 3 users in 3 days have either re-installed jaunty, or upgraded from jaunty -> karmic
[18:15] <kirkland> cjwatson: they backed up or preserved $HOME, but did not do the same for /var/lib/ecryptfs
[18:16] <kirkland> cjwatson: i'm going to need to fix this in a Jaunty SRU for the jaunty->karmic upgrade scenario
[18:16] <kirkland> cjwatson: i wanted to bounce the idea off of you before i implement it
[18:17] <kirkland> cjwatson: i'd create an /etc/init.d/ecryptfs, that does a mkdir -p /home/.ecryptfs && mount -o bind /home /home/.ecryptfs
[18:17] <kirkland> cjwatson: /home/.ecryptfs will be a bind mountpoint only;  but will be established at boot, before any user logs in and mounts their homedir
[18:18] <kirkland> cjwatson: the config data that lives in each user's /var/lib/ecryptfs/$USER dir would be moved to /home/.ecryptfs/$USER/.ecryptfs
[18:18] <kirkland> cjwatson: which would move it out of /var, and into their unmounted home dir
[18:19] <kirkland> cjwatson: users are good with backing up $HOME, so they'd keep a copy of their config data in that case
[18:33] <cjwatson> kirkland: not today, sorry; can you send me a mail instead?
[18:34] <kirkland> cjwatson: sure
[18:34] <kirkland> cjwatson: i may well be able to attach a patch by that point
[18:34] <kirkland> cjwatson: after my spec definitions are done
[18:34] <kirkland> cjwatson: just one quick question ....
[18:34] <kirkland> cjwatson: are you diabolically opposed to a /home/.ecryptfs bind mount?
[18:34] <kirkland> cjwatson: would you prefer /.home instead?
[18:34] <cjwatson> sorry, I *really* can't do this right now
[18:35] <cjwatson> I'm trying to fill out financial declaration forms for school, and am only at the computer looking for information
[18:36] <kirkland> cjwatson: good luck ;-)  ttyl
[18:41] <xivulon> evand, https://wiki.ubuntu.com/FoundationsTeam/Specs/KarmicWubi
[18:42] <evand> xivulon:  awesome!  I'll take a closer look when I get back from walking the dog.  Thanks a bunch for doing that so quickly!
[18:49] <xivulon> evand, np, feel free to edit
[19:16] <xivulon> mpt, evand fyi, I made a couple of enhancements to https://wiki.ubuntu.com/UbiquityPartitioningPageProposal
[22:06] <cr3> might it be possible that late_command runs very early when attempting to preseed ubiquity? I've been seeing in-target errors popping by immediately after the preseed is being retrieved
[22:25] <cjwatson> I'm not aware that preseed/late_command is processed by casper/ubiquity at all


[08:10] <alkisg> tjaalton: Timo hi, how important is it that I test https://bugs.launchpad.net/bugs/1815172 currently? If I spend a couple of days, I should be able to find an affected school nearby, but I can't do it e.g. in a couple of hours...
[08:10] <alkisg> If a problem exists, I'll surely hear about black screens etc, so then it'll be much faster to find an affected school :D
[08:11] <tjaalton> alkisg: was hoping to get it verified this week
[08:11] <tjaalton> there were others who were affected, might ask them too
[08:12] <alkisg> OK, thanks; I have 5-6 other show-stopper issues that are much more pressing atm, so let's ask the others and I can search for a school if those don't reply
[08:14] <alkisg> One might be xorg-related too, i.e. the window manager `marco` crashes xorg on nouveau, but it doesn't crash it if the resolution is changed before running marco!
[08:14] <alkisg> This probably suggests "uninitialized variables" somewhere, but I'm not sure if those are on marco or on xorg/nouveau...
[08:14] <alkisg> Hrm actually since marco is restarted... they're probably in nouveau


[11:47] <bluca> we are hitting a problem that seems due to phased updates
[11:48] <bluca> the case is a jammy img with -updates enabled, that has systemd installed
[11:48] <bluca> with the new update, there's a new version of src:systemd, but it's phased
[11:48] <bluca> if you try to install a package that is not there by default, like systemd-container, it will have a strict dependency on packages that are installed, but held back by the phase
[11:50] <bluca> shouldn't either the phase be ignored in that case, or older versions kept around so that apt can satisfy the dependency by installing the previous version of the non-installed pkg?
[11:50] <bluca> https://github.com/actions/virtual-environments/issues/5806
[11:50] <seb128> bluca, check the discussion on https://irclogs.ubuntu.com/2022/06/23/%23ubuntu-devel.html
[11:51] <bluca> thanks, will do
[14:10] <rbasak> lvoytek: mysql-8.0 failed on riscv64 again with no build logs. I'll retry again.
[14:11] <lvoytek> Thanks! I just saw that too
[14:57] <kanashiro> hi, I have an email to ubuntu-release mailing list stuck in moderation, could any admin of that mailing list please accept it?
[15:01] <Skuggen> rbasak: This an infrastructure issue, or an issue with MySQL?
[15:09] <rbasak> Skuggen: o/
[15:09] <rbasak> Skuggen: just infrastructure. But thank you for checking in!
[15:17] <Skuggen> \o
[15:18] <Skuggen> I've been terrible at following up on Ubuntu/Debian building over the last year. Keep thinking "now I'll have some time", but then there's some fire before I can complete anything :|
[15:20] <Skuggen> But I do have a question. Is lvoytek going to work on keeping the debian/ubuntu packages in sync going forward? One thing we do with Fedora packaging which is easier to keep on top of is sending out packaging patches for every new release
[15:24] <rbasak> Skuggen: yes lvoytek is working on that. Maybe we could have a catch up call soon?
[15:45] <juliank> frickler, jbicha So I went back to the drawing board and I believe this solution solves all issues we experience now: https://salsa.debian.org/apt-team/apt/-/merge_requests/245/diffs
[15:45] <juliank> Essentially this plans a normal upgrade, and then holds back any update that should be ignored by phasing
[15:48] <juliank> I'm consulting with DonKult upstream if there are any solver issues I should be aware of but it sounds reasonable
[15:48] <juliank> Note that this behaves weirdly, like update-manager it will install the still-phasing version 3 from updates rather than version 2 from security
[15:48] <juliank> because it cannot change candidate versions at this stage
[15:49] <juliank> and 3 is hence considered a security update because 2 is and 3 > 2
[15:49] <juliank> (and 2 > 1)
[15:49] <juliank> the full policy driven approach would install 2 which is arguably a whole lot nicer
[15:59] <Skuggen> rbasak: Yeah, that sounds like a good idea!
[16:02] <rbasak> Skuggen: I'll set something up. lvoytek is in UTC-7. When's the latest you're available?
[16:08] <Skuggen> Up to 18UTC is fine as long as I don't have other plans :)
[16:37] <rbasak> Skuggen, lvoytek: OK I scheduled something for Friday 1st July. Is that time OK for both of you? I reused the old recurring invite, but cancelled subsequent recurrences as that meeting is basically dead anyway.
[16:38] <lvoytek> That time works for me!
[16:38] <rbasak> Great! I picked your earliest available time so as not to inconvience Skuggen too much!
[16:47] <Skuggen> Should be good, yeah!
[16:48] <rbasak> Skuggen: just checking: you're confirming the time in the email you got, right? I just realised I was ambiguous above. I moved the time of our previous regular sync back as it'd be too early for l_voytek.
[17:10] <Skuggen> Yeah, got one email that looks most like another invitation to the old meeting. But the new one is 1600 my time, which is fine
[17:10] <Skuggen> Though if we make it a more regular thing again I'd probably want to move it to a different day :)
[22:06] <jawn-smith> vorlon: you around? I've got an components question
[22:07] <jawn-smith> Or perhaps bdmurray
[22:08] <jawn-smith> The latest upload of vim introduces a new binary package, vim-motif, that creates 3 component mismatches
[22:08] <jawn-smith> Would it be worth looking into the possibility of having vim-motif be in universe rather than main?
[22:09] <jawn-smith> Instead of MIR-ing the 3 mismatches
[22:25] <vorlon> jawn-smith: https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html already shows that this is a candidate for demotion, just needed poking an AA to get it done
[22:26] <jawn-smith> oh neat, thanks!
[22:27] <vorlon> component changed now, shoud migrate soon if that was the only blocker
[22:27] <jawn-smith> that was indeed the only blocker
[22:27] <jawn-smith> Thanks!
[22:45] <arraybolt3[m]> Hey all. I'm attempting to backport libfm-qt11 from Kinetic to Jammy, and have hit a bit of a roadblock with the symbols. I was doing this over on #lubuntu-devel so I have a lot of background for this to make sense, so bear with me.
[22:46] <arraybolt3[m]> Initially, I got my packaging for libfm-qt11 from here: https://github.com/lubuntu-team/libfm-qt-packaging
[22:47] <arraybolt3[m]> I cloned it, prepped for the backport, uscan'd the source code, "debuild -S -d -sa", then uploaded the prepared packaging to a PPA, where I got a bunch of symbol data from the build logs for five different architectures.
[22:48] <arraybolt3[m]> I then extracted the symbol diffs from the build logs, and used "pkgkde-symbolshelper batchpatch" to apply them to the core symbol file in the package, then attempted an sbuild.
[22:48] <arraybolt3[m]> However, I've now run into the following error (given by the sbuild process): https://pastebin.com/cRxLScGk
[22:49] <arraybolt3[m]> It appears that somewhere along the way, some sort of "subst" symbol tag got involved, which appears to not even be an official symbol tag - the best documentation I could find was from here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533916 It appears that, depending on what architecture you build on, the symbol changes, based off of a placeholder within the symbol.
[22:49] <arraybolt3[m]> I'm unsure how to proceed. Any thoughts?
[22:50] <arraybolt3[m]> (I'm a newbie packager, so please be patient if it takes me a bit to understand.)
[23:07] <vorlon> arraybolt3[m]: I'm unfamiliar with the pkgkde-symbolshelper package, but it seems rather buggy for it to be emitting things not supported by dpkg.  The way to solve this is, for each of the affected symbols, to edit your symbols file to list two different symbols: one with the correct name for 32-bit archs and tagged (arch=i386 armhf), one with the correct name for 64-bit archs and tagged
[23:07] <vorlon> (arch=!riscv64 !i386 !armhf)
[23:08] <arraybolt3[m]> vorlon: OK, that makes sense. I can get all of the data necessary for putting together the symbols in this way from the individually built .deb packages from the PPA, right?
[23:09] <vorlon> arraybolt3[m]: yes
[23:09] <arraybolt3[m]> Thank you!


[03:13] <ubuntu_> Greetings anyone here tonight have a question
[03:21] <ObrienDave> !ask
[03:21] <ObrienDave> *sigh* note to self. SELF, make sure they're still here before responding ;P
[06:09] <lordievader> Good morning.
[06:10] <Mikaela> hi and bye, leaving for school
[06:10] <lordievader> ;0
[06:10] <lordievader> ;0*
[06:10] <lordievader> ;)* ugh no coffee
[12:27] <BluesKaj> Hiyas all
[12:36] <BluesKaj> hey elfy
[12:37] <elfy> hi BluesKaj :)


[00:00] <TimR> can anybody tell me why .htaccess is not working under 12.04.2 lts?
[00:01] <hitsujiTMO> TimR, what is your vhost config
[00:01] <TimR> what you mean?
[00:02] <hitsujiTMO> the virtualhost config for apache that the .htaccess file is loaded for
[00:02] <crimsonmane> hitsujiTMO: using full path /usr/bin/supybot still does not load it
[00:02] <crimsonmane> hitsujiTMO: is there a spot online I can read the different start on options?
[00:03] <TimR> I dont think there is one even loaded
[00:03] <hitsujiTMO> crimsonmane: echo $PATH   check each for the bin
[00:04] <crimsonmane> /usr/bin is present
[00:04] <crimsonmane> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
[00:05] <hitsujiTMO> crimsonmane http://upstart.ubuntu.com/cookbook/ apendices 28.1
[00:06] <TimR> ?
[00:06] <crimsonmane> thanks. i looked up the cookbook earlier and the page said it had not been created yet
[00:07] <hitsujiTMO> timR your virtualhosts are configured in /etc/apache2/sites-available
[00:07] <TimR> yes it is hitsujiTMO
[00:08] <crimsonmane> hitsujiTMO: what other options can i use other than "pre-start" ?
[00:08] <hitsujiTMO> what is the vhost config for the vhost that your having the issue with the .htaccess
[00:09] <TimR> well when I go to staff.domain.com I dont get an popup asking for username and password
[00:10] <hitsujiTMO> crimsonmane: chapter 6.1 - Process Definitions
[00:12] <hitsujiTMO> TimR, the option in the vhost can effect how the .htaccess is interpreted, i'm asking to see the actual config in question that effects the .htaccess. you can sanitise personal info
[00:13] <TimR> well I can pastbin it if you want me 2
[00:13] <hitsujiTMO> plz
[00:15] <TimR> http://pastebin.com/bjuyqpk4
[00:15] <hitsujiTMO> AllowOverride None    is your problem
[00:15] <TimR> ok
[00:15] <TimR> but if I switch it to ALL i get internal error 500
[00:17] <hitsujiTMO> 500 may mean theres an error in the .htaccess ... check the options here: http://httpd.apache.org/docs/2.2/mod/core.html#allowoverride
[00:18] <TimR> alright thanks hitsujiTMO I got it to work
[00:18] <hitsujiTMO> np
[00:23] <noobster> So I built a new 12.04 server and it does the same thing, I can copy about 2.3GB into transferring a 6GB file and the NFS freezes. The 2.3GB file is on the NFS server, and the ISO mount is still alive on the ESXi server so I dont think its the server.. Any ideas??
[00:24] <noobster> maybe I should try NFSv3
[00:45] <noobster> nfsvers=3 fixed my errors! no more dismount now that I am not using NFSv4
[00:47] <crimsonmane> I am having issue getting something to run on boot, prior to logging in. This is the /etc/init/ file contents: http://dpaste.com/1415814/
[00:49] <James_Epp> noobster: How much experience do you have with NFS? I've been having a troubling issue.
[00:50] <noobster> James_Epp: a little, whats your issue??
[00:50] <James_Epp> noobster: I'm in the process of trying to boot the ubuntu live discs over a network using nfs-kernel-server. Under my /etc/exports I have the following, however when clients boot they continue to give the error message "mount: Protocol not supported". http://paste.ubuntu.com/6233647/
[00:50] <James_Epp> But I can manually connect to the nfs share using the 'JFTP' program.
[00:53] <James_Epp> here is a screenie. http://imgur.com/IIlH0LI
[01:00] <noobster> James_Epp: I have not used ubuntu to pxe boot before, but if I recall you have to have tftp boot server, pxe bootloaded, dhcpd & no_squash_root all happy before it will work.
[01:00] <noobster> James_Epp: help.ubuntu.com/community/DisklessUbuntuHowto#Creating_your_NFS_installation
[01:00] <James_Epp> noobster: PXE and DHCP are perfect.
[01:01] <James_Epp> noobster: What does the no_squash_root option do? How does it differ from all_squash ?
[01:01] <noobster> James_Epp: then you have to install to the NFS like it is a hard drive
[01:01] <James_Epp> noobster: Not like that, I mean actually booting it as if there were a disc in the client machine.
[01:02] <James_Epp> Like, turn on machine, pxe boot, choose ubuntu, and the "live disc" gets pulled down for use.
[01:03] <James_Epp> noobster: Basically what is described at https://help.ubuntu.com/community/PXEInstallMultiDistro . However, their custom nfs export table doesn't work either :/
[01:03] <noobster> hmm I have not done that, you might need to extract the live cd onto the NFS but this is a little out of my field..
[01:06] <James_Epp> noobster: I already have. I have no clue what is happening. I followed several different guides' suggestions for the options in this table. None of them resolve the issue.
[01:06] <noobster> maybe bbs.archlinux.org/viewtopic.php?pid=1177557
[01:07] <noobster> not ubuntu but this guy is having what looks like the same issue
[01:07] <noobster> James_Epp: lets jump to PM so we don't get this channel off topic?
[01:08] <James_Epp> noobster: Sure
[01:09] <crimsonmane> I am having issue getting something to run on boot, prior to logging in. This is the /etc/init/ file contents: http://dpaste.com/1415814/
[01:35] <crimsonmane> I am having issue getting something to run on boot, prior to logging in. This is the /etc/init/ file contents: http://dpaste.com/1415814/
[02:16] <gdos> is it possible to use symbolic links (either hard or soft) to point from /var/www/doc (http://localhost/doc) to file://localhost/usr/share/doc/HTML/index.html ...???
[02:17] <pmatulis_> gdos: try it and let us know
[02:17] <gdos> pmatulis_ how?
[03:15] <gdos> add "FollowSymLinks" as an option for your DocumentRoot
[03:16] <gdos> ersi, how do i add "FollowSymLinks" as an option for my DocumentRoot under apache2?
[03:26] <linocisco> hi all
[03:27] <linocisco> i want to setup ubuntu server (File/Email/Proxy) for windows clients . instead of flash player, java updates on each windows clients, I want ubuntu server only download them and issue to each clients to reduce multiple download
[04:16] <linocisco> hello all
[05:19] <ersi> gdos: Why'd you ask me?
[05:20] <gdos> ersi, that should've been 'er, how do i add "FollowSymLinks" as an option for my DocumentRoot under apache2?'
[05:21] <ersi> Ah, alright. I got quite suprised :-)
[05:22] <ersi> Were you able to add FollowSymLinks by the way? You need to specify a Options line with it under the document root block definition.
[05:22] <gdos> ersi: no i can't figure out where to add it?
[05:32] <ersi> gdos: Open up /etc/apache2/sites-available/default and find a <Directory /> block
[05:32] <gdos> ok.
[05:33] <ersi> If there isn't a line that starts with 'Options', add one like "Options FollowSymLinks" (and other options if you'd like more, otherwise, skip that) and then give apache2 a restart/reload
[05:41] <gdos> ersi: how do i restart/reload apache2
[05:42] <ersi> gdos: "service apache2 restart"
[05:43] <gdos> ersi: thank you. :)
[05:44] <gdos> ersi: it is already there but what is allow over-ride? that a security risk?
[05:45] <ersi> "When the server finds an .htaccess file (as specified by AccessFileName) it needs to know which directives declared in that file can override earlier configuration directives."
[05:45] <ersi> That's what AllowOverride does
[05:50] <gdos> oh. ok. gotcha.
[07:12] <rbasak> jamespage: morning o/
[07:12] <rbasak> jamespage: for when you get in: I'm just starting on backporting that fix to dpkg for the cloud-tools pocket now.
[07:13] <jamespage> rbasak, excellent - start @0900 ish for me today
[07:16] <rbasak> OK
[11:20] <jamespage> adam_g, figured out that rabbitmq-server issue - hostname was resolving to multiple ip addresses
[12:18] <Rodge> Hi folks! I'm wondering about using BTSync on an Amazon EC2 cloud instead of Amazon S3 (kind of a network disk). Any disadvantages with that (on a production cloud)?
[12:19] <Rodge> (and of course, the EC2s run Ubuntu Server (12.04))
[12:37] <hallyn> zul: (qa-regression-tests are running against your libvirt-testing ppa)
[13:22] <hallyn> zul: the same four failures (which are due to kernel apparmor bug).  otherwise that libvirt package is a-ok - thx
[13:35] <esde> I've got ubuntu 12.04 setup as a remote backup for my backed up media. I'd like to be able to view the media from a wide range of internet enabled devices (smartphones and web browsers). What's the best way to do this? I have in mind something 'tube-like', that will "serve" up any videos in a certain directory, hopefully, lol
[13:36] <mardraum> a web server?
[13:38] <esde> It's already configured as such, LAMP (Percona and php5-fpm)
[13:39] <esde> i could only find like plex and packages for sharing to consoles, ios, android devices. i'd like something that relies more on a browser than a specific sharing protocol like dlna
[13:40] <mardraum> I don't think your question has much to do with ubuntu server
[13:41] <mardraum> go and find the software you want to run
[13:41] <mardraum> then work out how to run it.
[13:41] <esde> i was checking in hopes another user has faced the same issue and could offer first hand advice from their own experience
[13:42] <esde> thanks for replying and have a great day
[14:55] <Anomie_work> I'm trying to follow this guide to test if my postfix is working but the 'mail' command no longer works in 12.10 apparantly - does anyone know if there's a replacement? http://rtcamp.com/tutorials/mail/postfix-debugging/
[14:58] <maxb> mail works fine for me
[14:59] <Anomie_work> maxb: Are you running 12.10?
[14:59] <Anomie_work> maxb: It's not in the package list; http://packages.ubuntu.com/quantal/amd64/mailutils/filelist
[15:00] <maxb> I'm running 13.10
[15:01] <maxb> I'm using the version from the bsd-mailx package
[15:01] <Anomie_work> maxb: Thanks, got it working now :)
[15:02] <sandprickle> I'm having the worst time of Nginx/php5-fpm.  atm I'm getting: *12 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream
[15:02] <maxb> Anomie_work: Alternative versions appear to exist in 'mailutils' and 'heirloom-mailx'
[15:23] <hallyn> ahs3: i'm still setting up a test, but looks like we'll want something like http://people.canonical.com/~serge/netcf-wheezy.debdiff in wheezy
[15:28] <ahs3> hallyn: k.  easy enough to get into sid and let migrate -- or is it critical to wheezy alone?
[15:34] <hallyn> ahs3: it's only valid for wheezy, the others have the fix through a newer netcf version
[15:36] <hallyn> ahs3: does that mean it's not really worth pushing?
[15:37] <ahs3> hallyn: hrm.  is netcf useless without it?  then yes.  is it slightly annoying?  maybe not.
[15:38] <hallyn> ahs3: I suspect it's mindly annoying
[15:38] <hallyn> well, depends on your existing network infrastructure I guess
[15:38] <ahs3> hallyn: heh.  i like that: "mindly annoying" :)
[15:38] <hallyn> huh.  didn't realize i'd typed that :)
[15:40] <ahs3> so if it's pretty minor, it may be okay to just let it migrate normally.  if it was seriously broken, then yeah, we'd want to push it to wheezy
[15:44] <hallyn> ahs3: so it in theory would eventually hit wheezy from sid?
[15:44] <hallyn> ahs3: of course it's hung up on the same bunch of stuff as qemu and libvirt
[15:45] <hallyn> ok, i'll send an email saying bug is valid but we'll wait for the fix to migrate from sid.
[15:46] <ahs3> ah.  yeah, if it's connected to a bunch of other things like that, best to let it settle down first
[15:46] <hallyn> ahs3: ok, thanks - ttyl
[15:48] <ahs3> hallyn: np.  cya.
[17:01] <hallyn> qemu-img create -f rbd rbd:pool/vm1 10G
[17:01] <hallyn> kvm -m 512 -drive format=rbd,file=rbd:pool/vm1 -cdrom raring.iso -boot d
[17:01] <hallyn> feh.
[17:01] <hallyn> sorry
[17:11] <tasslehoff> it takes 5-6 second from I hit enter 'ssh myserver' until I'm logged in (public key auth). Any idea what can cause the delay?
[17:26] <zerick> tasslehoff, maybe some DNS search enabled entry ?
[17:35] <parallel21> If I wanted to use apt-get to install nginx but wanted to override it's install path, how might I do that?
[17:38] <zerick> parallel21,  ovewrite the install path ? you mean, overwrite the /etc dir  ?
[17:38] <parallel21> no
[17:39] <zerick> so ?
[17:39] <parallel21> choose where nginx get installed, so rather /etc/nginx would change to /opt/nginx
[17:40] <zerick> parallel21, not possible AFAIK, only possible when compiling
[17:41] <parallel21> shucks
[17:41] <zerick> You can try this, maybe works  for you http://www.linuxquestions.org/questions/debian-26/install-with-apt-get-in-other-path-386763/
[17:42] <parallel21> Yeah, I'll look at that. Looks like if I can get the deb file before install I can modify flags
[19:24] <tasslehoff> zerick: perhaps. I tried adding "UseDNS no" to my sshd_config, but after that I could not connect through ssh at all..
[19:34] <savid> Does logrotate automatically rotate all *.log files in /var/log?
[19:34] <savid> Or does there need to be explicit definitions for each log?
[19:38] <soren> savid: I don't think there's a catch-all configuration for logrotate.
[19:38] <soren> savid: ...and logrotate doesn't just do it on its own. There would need to be a config file telling it to do so.