IRC logs for #baserock for Thursday, 2015-10-08

*** gtristan has quit IRC00:07
*** bfletcher has quit IRC00:23
*** bfletcher has joined #baserock00:28
*** fay_ has joined #baserock00:46
*** fay_ has quit IRC00:55
*** fay_ has joined #baserock01:06
*** fay_ has quit IRC01:20
*** gtristan has joined #baserock01:29
*** gtristan has quit IRC06:09
*** gtristan has joined #baserock06:10
*** franred has joined #baserock06:11
paulsherwoodsurprisingly, instances:2, max-jobs:8 is even faster...06:19
paulsherwood1 15-10-07 03:23:17 [172/278/278] [TOTAL] Elapsed time 03:23:1706:20
paulsherwood0 15-10-07 03:23:21 [106/278/278] [TOTAL] Elapsed time 03:23:2106:20
gtristanhmmm, any tips on getting the pointer device working in kvm ?06:43
gtristanseems the baserock built Xorg doesnt have any appropriate driver for the device kvm is exporting06:44
* gtristan thinks, kvm is just mirroring what is on my laptop ?06:45
* gtristan 's host Xorg loads synaptics_drv, better to try VirtualBox, maybe it will at least emulate something easier to cope with06:52
tiredcatwouldn't it be beter to just fix X?06:53
tiredcatalso if you're using virt-manager you can specify what sort of mouse to add ps/2, usb etc06:53
* gtristan installs virt-manager06:56
gtristantiredcat, I'm not sure honestly, havent had to dabble in VMs until now06:57
gtristanif the statement 'kvm mirrors my host system' is a true one, then yeah, ensuring that xorg has the synaptics input drivers built and installed would be the solution06:58
tiredcati don't think kvm mirrors your host drivers06:59
gtristanI mean devices, not drivers, but I have no clue really07:01
tiredcatyes i also meant devices :)07:01
*** ssam2 has joined #baserock07:09
*** ChanServ sets mode: +v ssam207:09
jjardongtristan: do you get the same if you try to start a Wayland session? I ask because weston seems to work correctly in KVM (with the fb backend)(i think I added weston to the GNOME system just to test this things)07:17
jjardongtristan: did you fix the gnome-keyring issue yesterday? The link you posted seems to en empthy07:20
gtristanjjardon, did not get to the bottom of gnome-keyring07:22
gtristanjjardon, question: has the xorg build been tested in anything else, other than gnome-system-x86_64 ?07:23
jjardonNo that im aware of07:24
gtristanthat's nice to know :)07:24
gtristanwell, kvm gives us a mouse and it works, that's for sure07:26
gtristanso says cat /dev/input/mouse007:26
gtristanso then I have xorg stuff to figure out07:27
gtristanjjardon, you are building *everything* in xorg ? or have you left anything out ?07:27
jjardonXorg has a lot of diferentes modules, its possible that something is missing07:30
gtristanI notice that there are complaints about fonts, but that's a tricky part of the config, and may have to do with missing --sysconfdir=/etc07:31
gtristanprobably we still have fc-cache things to call also07:31
gtristanbut I think the input drivers are there07:31
*** paulw has joined #baserock07:42
*** persia has quit IRC07:59
*** persia has joined #baserock08:00
*** toscalix__ has joined #baserock08:04
*** bashrc has joined #baserock08:05
*** mariaderidder has joined #baserock08:12
gtristanwith some tweaking, X -retro shows a working pointer device, but gnome-shell still hangs... lets look at what mutter is doing wrong...08:28
*** De|ta has quit IRC08:29
*** De|ta has joined #baserock08:29
Kinnisonisn't mutter built into gnome-shell these days?08:29
gtristannot that I can see08:32
gtristanbut this looks like the culprit:
gtristanwell, that looks like the fix for the problem08:33
* gtristan thinks better try master of gnome-shell/gnome-session/mutter08:33
KinnisonModern gnome-shell seems to fold window-management into itself08:33
KinnisonCertainly since 3.14 I've been unable to run xmonad with gnome-shell08:34
gtristanwell, the calls are all library calls, there is no separate process08:34
gtristanjjardon, why is gnome-shell unpetrify-ref baserock/3.18.0 ?08:38
ssam2probably he had to apply a patch08:38
ssam2so that branch will exist in gnome-shell.git on git.baserock.org08:38
gtristanok, that would explain why I dont have the commit id in upstream08:38
*** De|ta has left #baserock08:39
jjardonYeah, to change the submodules thing08:40
jjardonIs there a story to fix that at some point?08:41
gtristanI dont know what the submodules thing is08:41
gtristangnome-shell has some kind of git trigger which needs to be disabled by your patch, is it ?08:42
*** De|ta has joined #baserock08:43
gtristansigh, /me has a bad feeling about this08:45
*** De|ta has quit IRC08:47
Kinnisonwhy a bad feeling?08:47
Kinnisonall that commit does is rewrite the submodule URLs to point at the trove08:47
gtristanThe bad feeling: I may not even be able to build and test it without actually patching the upstream thing08:48
gtristanbut looks like it's happily downloading from and building08:48
KinnisonOh yeah, you *can* run without patching .gitmodules08:49
Kinnisonbut in the future that will fail because builders won't have network access outside of the trove08:49
Kinnisonso it's best to ensure you've patched .gitmodules before submitting for merge :_)08:49
*** De|ta has joined #baserock08:49
KinnisonI believe we've had discussion about putting that rewrite into the morphologies, but we've not gotten anywhere with making that happen yet08:50
gtristanperhaps it's better in the .morph to patch the .gitmodules, so as to not even require a patch to gnome-shell itself08:50
KinnisonCurrently that's not possible because the build tool sorts out the submodules08:51
gtristanright, think we're saying approximately the same :)08:51
KinnisonBut yes, it'd be nice08:51
gtristanan inline sed, in the configure-instructions08:51
* gtristan crosses fingers... and wants to see a GUI !08:52
Kinnisonsadly configure is run well after the git submodules are acquired08:54
Kinnisonbecause by then, network access is entirely removed, for reproducibility reasons08:54
franredI think the modules are downloaded before you run pre-configure commands (but I can be wrong) - so the sed line won't work / we need to change definitions-morph to replace the submodules by trove/other location repositories08:55
franredKinnison, snap :)08:55
*** jonathanmaw has joined #baserock08:57
gtristansame result with master gnome-shell/gnome-session/mutter09:17
gtristaneek, something went wrong somewhere it seems... see ybd log here:
gtristanone sec...09:31
gtristanand this is what I put for mutter in gnome.morph:
gtristannow specifically at line 421 in the build log, we find:09:32
gtristan15-10-08 00:01:41 [1/7/345] [mutter] Upstream version b975676c 3.18.0-25-gb975676 (3.18.0 + 25 commits)09:32
gtristancommit ID looks right... not sure what 3.18.0-25-gb975676 is all about...09:33
gtristanand in the resulting build I get the same hang here:
gtristanBut, looking at master's sources... it really does not follow the right codepath09:33
gtristanit looks like ybd did rebuild mutter, but not from master09:33
gtristanpossible ?09:34
tiagogomesgtristan I think it build from b975676c, which is the SHA1 that you set on the 'ref' field09:35
gtristanyeah, I checked my ~/.cache/ybd/gits...git_something__mutter/ ... and it does have the correct tip09:37
gtristanso the lorry is not out of sync (the commit in question is from only yesterday)09:37
gtristanonly stack trace seems to disagree :-/09:37
gtristanit should have passed through clutter_init() instead09:37
paulsherwoodgtristan: fwiw the ./cache path is set to that by default by a commit from jjardon because of XDG sometihng or other09:38
paulsherwoodiiuc you found it non-obvious?09:38
* paulsherwood had originally opted for /src/09:38
tiagogomesgtristan which stacktrace ? Where it says " Upstream version b975676c 3.18.0-25-gb975676 (3.18.0 + 25 commits)" ?09:39
gtristanpaulsherwood, ummm, now I *really* dont follow...09:40
paulsherwoodgtristan: 3.18.0-25-gb975676 is a combination of last tag (3.18.0-25) and commit id (b975676) returned by asking git09:40
gtristanpaulsherwood, the .morph had unpetrify-ref 3.18.0... but I changed the morph to 'master'09:40
paulsherwoodgtristan: (for the directory thing)09:41
paulsherwoodgtristan: ybd completely ignores unpetrify ref09:41
SotKgtristan: unpetrify-ref doesn't actually do anything, morph and ybd use the `ref` field to decide what to build09:41
gtristanpaulsherwood, so basically you are saying the line "Upstream version b975676c 3.18.0-25-gb975676 (3.18.0 + 25 commits)" is telling me... first the new version 'b97...' _and_ the version it was currently at '3.18.0-...' ?09:42
gtristananyway, what I am observing is that, in mutter master (b975676c)... core/main.c:358 calls meta_clutter_init()... but this is not reflected in the stack trace09:47
gtristanwhich is collected from the fresh build09:47
gtristanlet me clean up and try to deploy that again09:47
gtristanin this kind of scenario, it can always be a slip somewhere on my part09:48
gtristanis there any way to get rid of all of the outdated caches in ~/.cache/ybd/artifacts ?09:48
* gtristan is quickly running out of harddrive09:48
paulsherwoodgtristan: sadly not yet. i tend to remove all of them at once. patches welcome, but i'm aiming to get to it over the next week or so09:50
gtristanwell, mutter is not rebuilding09:51
paulsherwoodgtristan: it's saying that the actual commit is b975676, which is 25 commits applied on top of tag 3.18.009:51
* gtristan tries some ldd-foo in the latest artifact directory09:51
gtristansee if I can find at least the new meta_clutter_init() symbol09:51
gtristanpaulsherwood, right, that's what I wonder about... why does it care about 3.18.0 or tell me anything about how far ahead it is from 3.18.0 ?09:52
gtristanthe morph only says b975676 :)09:52
pedroalvarezgtristan: just free human readable information09:52
richard_mawgtristan: it thinks the user might be interested09:52
gtristanok but... why did it choose to say anything about 3.18.0... where is that coming from ?09:53
richard_mawgtristan: git tag09:53
Kinnisongit describe09:53
richard_mawyes, that one09:53
gtristanis it the place where it currently was ?09:53
gtristanok, that's what I was curious about09:53
gtristanot wants me to know... from where to where it went in the history09:53
paulsherwoodgtristan: because some use-cases make people interested in that09:54
paulsherwoodeg, if i have to complete a compliance matrix and folks want to know which 'version' of Linux kernel is present in my build... quoting a SHA is not very helpful09:55
paulsherwoodconversely... claiming 3.18 is dishonest, if there are patches applied to it09:55
gtristanright, it only threw me off09:56
gtristanas I am seeing the incorrect stack trace09:56
paulsherwood(eg i could go 3.18 and apply patches to revert loads of stuff to take the actual version back to 3.17)09:56
gtristanwhich doesnt coincide with the version09:56
paulsherwoodgtristan: intersesting. i'm normally highly confident that ybd is actually building the version it says it's building.... are you suggesting it may not be?09:57
*** fay__ has joined #baserock09:57
gtristanit may be more helpful btw to say: Building new version "<newversion>" (Previous build "<oldversion>")09:57
gtristaninstead of: Upstream version: <newversion> <oldversion>09:58
gtristanpaulsherwood, yes I am suggesting that, but I'm re-assembling the image09:58
gtristanit looks like, possibly the correct version was built but wrong artifact included ?09:59
paulsherwoodgtristan: sorry... that's not what it's saying. it's describing one version in two different ways09:59
gtristanpaulsherwood, so then the question arises again, where is 3.18.0-25-gb975676 coming from ?10:00
gtristanI mean, why 3.18.0-25 ?10:00
paulsherwood3.18.0 + 25 packages10:00
paulsherwood3.18.0 + 25 commits10:01
paulsherwoodb975676 *is* 3.18.0 + 25 commits10:01
* gtristan runs git describe in mutter master10:01
gtristanright, what I was thrown off by, is why git (or ybd), would choose to describe the version in relation to 3.18.010:02
gtristanI suspect, it may just be the most recent tag created in that repo ?10:02
gtristan(when I say why 3.18.0-25, I wondered why not 3.16-466 or whatever)10:03
*** fay__ has quit IRC10:04
paulsherwoodgtristan: yes, most recent tag, since i think that is most useful for answering human question 'which version of foo are we using'10:04
*** fay__ has joined #baserock10:06
gtristanI see, it seemed quite arbitrary, and as I've never seen a version described in that way - I was worried it could be the reason the image did not end up with the right mutter lib10:06
* gtristan has a new image10:07
paulsherwoodgtristan: i've never seen a version described this way either, but i strongly believe that describing it this way is better than any other description i've seen10:08
gtristan0000000000046620 T meta_clutter_init10:09
gtristanwell, that's in the image10:09
gtristanunfortunately I did not keep the old one... disk space :-/10:09
gtristangah, but here we are at the same stack trace10:12
gtristanoddly, the code paths have changed from one version to the other, but they land on an almost identical call stack10:13
gtristan(and meta_clutter_init() is simply omitted from the trace by gdb)10:13
gtristanso, all is well in ybd land, I'm due to clean out the artifacts and rebuild all10:14
gtristanand still don't have a solution for hang in XIGrabTouchBegin10:14
gtristanat this point, a checked out sandbox of mutter/gnome-shell would be useful...10:15
gtristanand a ybd 'buildone' command would be useful10:15
* SotK wonders what buildone would do10:15
gtristanjust build one artifact and update the image directly... ignoring modules which depend on that10:15
gtristan'use at your own risk, get it done now'10:16
gtristanalternative... scp source trees into the VM, and build mutter/gnome-shell directly there, with make install directly into /usr10:16
*** fay__ has quit IRC10:18
*** persia has quit IRC10:26
*** persia has joined #baserock10:27
gtristannod, fwiw, here are 2 *almost* identical stack traces: (old mutter) (new mutter)10:30
gtristanthat's what led me to panic, and presume I did not pick up the change10:31
gtristanwell, I've taken 2 approaches: bottom up - address as many errors as possible in the systemd journal10:42
gtristana lot of things fixed in that direction10:42
gtristanand: top-down; checking the stack traces where gnome-session/gnome-shell hang10:43
paulsherwoodgtristan: you can specify mutter (say) as your target, and it will rebuild that artifact10:44
gtristanthis allowed me to A.) identify that we needed to enable glx for gnome-session to detect HW acceleration10:44
paulsherwoodthen 'deploy' would be a matter of untarring the result in the right place10:44
gtristanand B.) Identify a hang10:44
paulsherwoodgtristan: to get to a checked out sandbox you could put 'exit 1' as a configure-command?10:46
paulsherwoodand then ybd will stop and give you the directory for the debris - which is what you want?10:47
gtristanI was thinking I would have to point the morph to a file:// checkout, but that could work10:47
gtristanwhat I want, is to build and deploy dozens of times in a row, with as least steps getting in the way10:48
* paulsherwood hopes it does :)10:48
richard_mawyou can use file:// paths for git repositories in morph and ybd10:48
richard_mawyou need to remember to commit your changes before building though10:48
paulsherwoodgtristan: deploy into what kind of target? a vm?10:49
gtristanrichard_maw, this would mean in any case, that I have to A.) Commit a change to get it included... B.) Build the artifact... C.) scp the artifact to the vm and D.) untar the artifact on that VM... *for every single deployment* ;-)10:49
gtristanyeah in a VM10:49
gtristanprobably I'm better off just scp the sources and ./configure, make, install in there10:50
paulsherwoodsadly, i fear you're right at this point10:50
gtristanbut then, I may not need this right now - but it's certainly what I want10:50
* paulsherwood notes the use-case10:50
gtristanpaulsherwood, you're on CC in an email where I asked this10:51
gtristanbasically, "what is the dev story for when I need to add some debug log, and deploy at least 10 time in the space of one hour"10:51
gtristanright now the sensible thing for me to ask myself though, is why... certainly I am getting this hang and others are not10:52
persiaI think I don't understand the use-case.10:53
persiaWhen doing rapid development, do we really want to deploy whole systems to see if the last 4-character change happened, or just havea  means to test the code, with formal system validation as a separate step?10:53
gtristanpersia, some past scenarios I've dealt with is... We maintain a build server with the target architecture but much more CPU/ram; developers build on that host and scp the binaries to a target system for testing10:56
gtristanpersia, another scenario is say, with buildroot, you painfully reproduce the entire image each time10:56
gtristanit's interesting that the image I have which runs in a VM happens to have all the dev tooling on it, though, at least it does allow me to build in the VM10:58
persiaHrm.  I think that workflow can be improved, but I think I need to think more  :)11:01
paulsherwoodgtristan: i believe that radiofree normally does his fast loops directly on the target11:02
paulsherwoodand that's probably what i'd recommend here11:02
paulsherwoodif it's feasible for you11:02
gtristanpaulsherwood, sometimes making noise on IRC is the fastest route... chances are someone else has seen the problem11:03
gtristan :)11:03
* gtristan breaths sigh of relief11:03
gtristanand decides it's time he can eat supper11:03
paulsherwoodgtristan: :-)11:03
*** gtristan has quit IRC11:28
*** zoli__ has joined #baserock11:55
*** gtristan has joined #baserock12:18
perryli'm trying to deploy a trove and getting the following issue in the process, can anyone help with what's going wrong? 'ERROR: The ssh-rsync write is for upgrading existing remote Baserock machines. It cannot be used for an initial deployment.'13:00
richard_mawperryl: what's in your cluster file?13:00
richard_mawit sounds like you're using the upgrade cluster rather than the initial deployment one13:01
perrylrichard_maw: clusters/trove-example, the description says it can be used for initial deployment and upgrade13:02
perrylyep, forgot to remove the upgrade lines13:02
*** wschaller has joined #baserock13:11
*** CTtpollard has joined #baserock13:12
*** zoli__ has quit IRC13:16
*** flatmush has joined #baserock13:31
*** fay_ has joined #baserock13:34
*** franred has quit IRC14:21
richard_mawtoscalix__: you had questions about the publish candidate step of ?14:47
toscalix__richard_maw: I have a note from a meeting in which it was mentioned a notification system once the candidate is published14:48
SotKany chance someone can put my ssh key on for me to have a look around? :)14:49
toscalix__I am unsure if you have had it in mind or is something I need to write down in the wiki page14:49
richard_mawtoscalix: I can't parse that, are you asking if there is one, whether we have ideas for one, or what?14:49
richard_mawcurrently it is a stub14:50
richard_maweventually we need it to produce a report, which includes things like the test results, where the artifacts that were produced can be reached, and how to fetch and apply the candidate14:51
pedroalvarezSotK: has anybody looked at that?15:05
ssam2SotK: yes15:05
ssam2pedroalvarez: I haven't touched myself15:05
pedroalvarezneither have I15:06
pedroalvarezis there anything that needs attention? or is just SotK wanting to look around to (some day) automate the process of deploying it :)15:06
SotKthe latter, and also maybe looking at updating it in place to something more recent for the time being15:07
*** wschaller has quit IRC15:14
*** paulwaters_ has joined #baserock15:16
ssam2SotK: done. don't break it!15:17
SotKI won't :)15:17
*** paulw has quit IRC15:18
* SotK wonders if there is a snapshot of lying around anywhere15:30
toscalix__richard_maw: sorry, got a phone call. Got you point. I will include report and notification. At least it will be recorded that we need to havethem in consideration15:32
*** wschaller has joined #baserock15:36
ssam2SotK: there's one on the datacentred openstack..15:37
ssam2which I took a while ago15:38
ssam2maybe pedroalvarez could fetch it for you15:38
* SotK hopes he can :)15:38
Zarassam2: ahhh, that's where it went! (we were wondering about where that was a while ago. looked in emails and nothing. meant to ask and forgot about it.)15:39
ZaraI'm glad there is one :)15:39
ssam2it took *hours* to make, so I hope it's useful :)15:39
ssam2i could download it for you but i'm in Germany so it is probably quicker if pedro (or anyone else with access to DC) downloads it straight to the office15:40
ssam2rather than me trying to upload it to a CT server from here...15:40
Zarassam2: I'm sorry about that, I think the development on worklists and boards work got pushed hard and the baserock side of things fell by the wayside. :( and I agree it doesn't make sense for you to do it from Germany.15:43
Zarapedroalvarez: would you be able to help us with this?15:44
rjekw/win 4915:46
perrylthe latest in my trove deployment woes: deploy gets as far as create_libvirt_guest in extensions/kvm.write then exits with the error 'ERROR: extensions/kvm.write failed with code 1: /src/tmp/deployments/tmpFseHYq/tmpTfhhsE/tmpvK5IIo is device /dev/loop015:51
ssam2ouch, bug in kvm.write I guess. no idea what15:53
ssam2if you don't have time to dig into kvm.write, you could deploy to rawdisk instead and set up the VM manually, as a workaround15:54
pedroalvarezssam2, Zara: sure!!15:54
perrylssam2: that might be an option at this stage :/ i was thinking of writing a patch for kvm.write to make it a bit more explanatory of what's going on at some point, for that matter15:55
Zarapedroalvarez: thanks :)15:57
pedroalvarezwow, 40G of snapshot15:57
ssam2perryl: that would be cool!16:05
Zarao.O sounds like one exciting snapshot!16:06
ssam2pedroalvarez: that's why it took hours!16:07
*** ssam2 has quit IRC16:08
toscalix__I would appreciate a review of the CIAT next steps>
rjektoscalix__: analised does not mean what you think it means.16:29
rjektoscalix__: I think you mean "analysed"16:29
toscalix__rjek: you are right16:29
rjekWell, you might mean what analised means, but that would surprise me.16:30
*** toscalix__ is now known as toscalix16:30
SotKcan you make the repo urls git:// rather than ssh:// too please?16:32
*** paulwaters_ has quit IRC16:32
toscalixSotK: yep16:35
*** mariaderidder has quit IRC16:48
*** tiagogomes has quit IRC16:52
*** De|ta has quit IRC16:56
*** bashrc has quit IRC17:00
*** De|ta has joined #baserock17:09
*** wschaller has quit IRC17:12
*** jonathanmaw has quit IRC17:22
*** edcragg has quit IRC17:43
*** paulwaters_ has joined #baserock17:43
*** zoli_ has joined #baserock17:51
*** paulwaters_ has quit IRC18:03
*** zoli_ has quit IRC18:51
*** paulwaters_ has joined #baserock19:47
*** paulwaters_ has quit IRC20:03
*** tiagogomes has joined #baserock20:32
*** zoli_ has joined #baserock20:39
*** zoli_ has quit IRC20:44
*** tiagogomes has quit IRC21:10
*** zoli_ has joined #baserock21:41
*** zoli_ has quit IRC21:46
*** fay_ has quit IRC21:57
*** flatmush has quit IRC21:57
*** edcragg has joined #baserock22:01
*** tiagogomes has joined #baserock22:03
*** tiagogomes has quit IRC23:04
*** zoli_ has joined #baserock23:27
*** zoli_ has quit IRC23:31
*** edcragg has quit IRC23:35

Generated by 2.15.3 by Marius Gedminas - find it at!