IRC logs for #baserock for Friday, 2015-10-16

*** tiredcat_ has joined #baserock00:04
*** richard_maw has joined #baserock00:04
*** rdale has joined #baserock00:04
*** robtaylor has joined #baserock00:04
*** kornbluth.freenode.net sets mode: +v richard_maw00:04
*** ChanServ has quit IRC00:04
*** persia has quit IRC00:04
*** flatmush has quit IRC00:04
*** jjardon has quit IRC00:04
*** _longines has quit IRC00:04
*** cyndis has quit IRC00:04
*** nowster has joined #baserock00:06
*** gtristan has joined #baserock00:06
*** pedroalvarez has joined #baserock00:06
*** bjdooks has joined #baserock00:06
*** inara has joined #baserock00:06
*** bfletcher_ has joined #baserock00:06
*** De|ta has joined #baserock00:06
*** petefotheringham has joined #baserock00:06
*** kornbluth.freenode.net sets mode: +v pedroalvarez00:06
*** gary_perkins has joined #baserock00:08
*** juergbi has joined #baserock00:08
*** JPohlmann has joined #baserock00:10
*** Kinnison has joined #baserock00:10
*** radiofree has joined #baserock00:10
*** lachlanmackenzie has joined #baserock00:10
*** SotK has joined #baserock00:10
*** drnic has joined #baserock00:12
*** rjek has joined #baserock00:12
*** tlsa has joined #baserock00:12
*** sebh has joined #baserock00:12
*** wdutch has joined #baserock00:12
*** benbrown_ has joined #baserock00:12
*** ratmice____ has joined #baserock00:12
*** perryl has joined #baserock00:12
*** persia has joined #baserock00:14
*** flatmush has joined #baserock00:14
*** jjardon has joined #baserock00:14
*** _longines has joined #baserock00:14
*** cyndis has joined #baserock00:14
*** brlogger` has joined #baserock00:16
*** edcragg has joined #baserock00:16
*** paulsherwood has joined #baserock00:16
*** petefoth has joined #baserock00:16
*** dabukalam has joined #baserock00:16
*** ctgriffiths has joined #baserock00:16
*** Zara has joined #baserock00:16
*** doffm has joined #baserock00:16
*** bwh has joined #baserock00:16
*** Kinnison has quit IRC00:21
*** Kinnison has joined #baserock00:21
*** ChanServ has joined #baserock00:30
*** card.freenode.net sets mode: +o ChanServ00:30
*** gtristan has quit IRC03:02
*** gtristan has joined #baserock03:20
*** jmacs_ has quit IRC03:51
*** jmacs has joined #baserock03:51
gtristanSharing ICU libraries ready for review: https://gerrit.baserock.org/#/q/topic:share-icu-common04:33
gtristanNote, the last one in the list on gerrit is the first one on the branch (of course); in this case, it's important that the last one is merged first (the others do not matter at all and wont conflict)04:34
gtristanIf your curious about the $TARGET conditional; ask James Thomas about commit 8874a7c7 :)04:36
* gtristan wonders if he can get gerrit to tell him about Change-Id: I282f6d4f1f599e76a1c196269233e38ea2d57d4f04:36
gtristanah, found it through search (some reason I couldnt find it first try, maybe I messed up the search term)04:44
gtristanhttps://gerrit.baserock.org/#/c/82/04:44
gtristanlooks like it's intended to also build on x86 targets, but I *think* we prefer the conditional04:45
*** paulwaters_ has joined #baserock06:11
gtristanSo... I have a dependency (enchant library from abisource)... and it's svn, the lorry will look like this: http://paste.baserock.org/weqecuwutu06:17
gtristanNow, before uploading that lorry... I of course want to test building it from definitions/06:18
gtristanWhat will I put in the ref: and the repo: ?06:18
gtristanwill the .morph happily gobble up an svn repo: ?06:19
gtristanhmmm06:24
gtristanfatal: repository 'http://svn.abisource.com/enchant/' not found06:24
* gtristan submits https://gerrit.baserock.org/1227 ...06:30
* SotK +1s06:47
SotKfor testing in the meantime, you can run lorry locally if you're using a devel system and set repo: to point to the directory on your system06:48
gtristanAh, so I will have to look into that... running lorry locally...06:51
gtristanSotK, for now... maybe it's not worth the overhead ?06:51
gtristanI hope that anything else will be gits... libwebp is a git so I was able to test06:52
gtristanRight now there is also a lorry patch in gerrit for libwebp, and a definitions patch for libwebp (which adds it to graphics-common)06:53
*** paulwaters_ has quit IRC06:57
*** paulwaters_ has joined #baserock06:58
* richard_maw is confused about the difference between WebKit and QTWebKit, since we seem to always be building the latter07:10
gtristanrichard_maw, I am also confused, but looking at the lorry - qt5/qtwebkit points to something at code.qt.io07:14
gtristanwho knows what that is07:15
richard_mawit's probably a fork of an old version07:15
gtristanFWIW, this morning I did that ICU refactoring https://gerrit.baserock.org/#/q/topic:share-icu-common07:15
richard_maweveryone seems to fork Webkit…07:15
gtristantrying to get that out of the way07:15
gtristanpossibly a downstream fork indeed07:16
gtristansigh, I've been searching google, debian package sources... irc channels07:17
gtristanI cant seem to locate the source of libhyphen07:17
gtristandistros have libhyphen-dev, and webkit even has tools in it's build directory, to assist in downloading libhypnen-dev *from a distro*07:18
* gtristan wonders if it's some orphaned project07:18
richard_mawgtristan: cool, I'll add the enchant lorry. There is a 2 hour timeout on lorry imports, but it doesn't look so large a repository that it can't import07:18
gtristanthanks, I have a floating .morph ready to test against an existing enchant :)07:19
gtristanwith libwebp, enchant... and the missing "hyphen.h" which I still have to track down, that will give us all the deps needed for WebKit07:20
gtristanI will have to move some things out of gnome/, which WebKit itself depends on07:20
Kinnisonplease don't rearrange the location of repositories07:20
Kinnisonit causes pain for downstream troves07:20
gtristanlibsecret, libgweather, geoclue and libnotify07:20
gtristanKinnison, I mean move out of definitions/strata/gnome/07:21
Kinnisonoh that's less awful :-)07:21
gtristan:)07:21
richard_mawgtristan: I applaud your nice separation into atomic commits for ICU. We usually append the stratum build-depends to the end of the list, rather than inserting it at the beginning07:23
*** ssam2 has joined #baserock07:24
*** ChanServ sets mode: +v ssam207:24
gtristanrichard_maw, it's not really like a regular project repo, but I like to stick to the atomic commits07:25
gtristanfollow rules where you know, it should at least build between any given commit, if ever the need to bisect arises07:25
* gtristan imagines the weeks it would take to bisect definitions tracking some regression, testing it would require a build each time ;-)07:26
richard_mawit would, but caching would help there07:31
richard_mawgtristan: http://sourceforge.net/projects/hunspell/files/Hyphen/ appears to be hyphen07:37
richard_maw(googling for `webkit "hyphen.h"` led to http://osdir.com/ml/commits.gnome/2015-09/msg02449.html which had a link in a .spec file07:37
richard_maw)07:37
*** jonathanmaw has joined #baserock07:42
gtristanrichard_maw, thanks :)07:46
gtristanSo question... regarding libsecret/libgweather/geoclue/libinotify...07:46
gtristanlibs/apps in gnome/ depend on those, and so does webkit07:46
gtristanmy inclination is to create separate stratum for each of those, with the regular -common suffix07:47
gtristanand not try to group them07:47
gtristanthoughts ?07:47
gtristananother option would be to start on a gnome-deps stratum... but it doesnt make sense really to have webkit depending on gnome-deps, and then have gnome depending on gnome-deps + webkit07:48
gtristancause anything else building webkit (I would assume potentially a lot)... would be pulling in unneeded cruft from gnome-deps07:48
richard_mawThe current stratum model in definitions assumes you can easily put together groups of logically cohesive components, which is looking to be increasingly not the case.07:50
richard_mawthe libgweather and geoclue look like positioning components, which might be sensibly grouped07:50
richard_mawas a purist I'd argue that libinotify and libsecret are fairly integral system libraries, but pragmatically, that'll just cause unnecessary rebuilds07:51
richard_mawgtristan: honestly, I have no right answer for you.07:51
*** tiagogomes has joined #baserock07:52
gtristanalright08:02
pedroalvarezhehe, that ICU change makes sense, it will triger some rebuilds here :)08:03
pedroalvarezbut it*08:03
gtristanI think for now, go with -common stratum for each, giving maximum flexibility - and most easy to change and regroup later if that becomes desirable08:04
gtristanas opposed to gnome.morph which is tightly coupled and more work to untangle08:05
gtristannote regarding ICU: I have a problem without merging that; which is ICU is currently repeated in gnome/ AND a dependency of webkit08:06
gtristanif I were to work around it, I will end up building it twice08:06
*** ssam2 has quit IRC08:06
gtristanand hopefully ybd would complain about that08:07
*** bashrc has joined #baserock08:07
gtristanthen again, adding icu-common does not mean you absolutely _must_ merge the qt[45]-tools patches right away08:07
gtristanso there is middle ground :)08:08
richard_mawlast time I used YBD the algorithm was to pick the first one defined, whether it was a dependency of what you wanted to build, and use that for all of the builds08:08
gtristanhmmm08:12
gtristanIs this an error with the svn lorry: http://git.baserock.org/cgi-bin/cgit.cgi/delta/enchant.git/ ?08:13
gtristanor just time skew ?08:13
gtristani.e. just still not cloned yet08:13
jjardonHi, FYI, qtwebkit is deprecated and will be removed in next Qt releases08:15
jjardonQt webengine (based on chromium) is the new thing08:17
gtristanlooking at http://svn.abisource.com/enchant/... and http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/tree/open-source-lorries/enchant.lorry ... can someone spot an error ?08:18
gtristanit looks to me like "layout" : "standard" is correct for that repository08:18
gtristanhas the regular trunk/ branches/ tags/ layout08:18
richard_mawit does to me too, hence why I approved it08:18
* gtristan scratches head08:19
richard_mawhttp://git.baserock.org/lc-status.html says enchant is queued to be run in 2h40m, which implies it must have already tried08:19
richard_mawhmm08:19
jonathanmawjjardon: interesting. Do you know if it builds in less than an hour?08:19
jjardonNo idea; but I know qtwebkit will be removed in Qt 5.608:20
richard_mawpedroalvarez: do you remember how to see the lorry controller logs?08:20
rjekjjardon: They're removing things in a point release?08:20
jonathanmawrjek: maybe "qt5." is its name now :)08:21
jjardonrjek: https://wiki.qt.io/New_Features_in_Qt_5.608:22
pedroalvarezrichard_maw: I guess you don't mean lorry logs08:22
richard_mawpedroalvarez: specifically, I want to see the logs for job id 6455908:23
rjekThis reminds me of one of the many reasons I dislike Qt :)08:23
pedroalvarezrichard_maw: `ssh -L 12765:localhost:12765 root@git.baserock.org`08:24
pedroalvarezand then in a browser you will be able to open "localhost:12765/1.0/status-html"08:24
richard_mawah, grand!08:25
richard_maw    Bad URL passed to RA layer: Unrecognized URL scheme for 'http://svn.abisource.com/enchant' at /usr/share/perl/Git/SVN.pm line 148.08:25
richard_mawhm, git svn doesn't like plain http URLs apparently08:25
* pedroalvarez appreciates people helping with baserock-ops :)08:26
gtristanhmmm08:27
gtristangrepping through open-source-lorries/* ... there are mostly http://svn.... when it comes to SVN lorries :-/08:28
gtristansome of them are svn:// indeed, a mix08:29
richard_mawhttps://github.com/AbiWord/enchant looks like either an official git mirror, or that they've moved development to git08:29
gtristanrichard_maw, commits there are 7+ years old ?08:32
gtristanah no08:32
gtristanthere is recent dev there08:32
gtristanbut project page http://www.abisource.com/projects/enchant/ does not refer to the github thing08:33
pedroalvarezheh I wonder if they are still alive at   #abiword (irc.gnome.org)08:38
gtristanfwiw, svn co svn://svn.abisource.com/enchant/ gives an error08:38
gtristanpedroalvarez, I'm already there ;-)08:39
gtristannobody answered so far08:39
gtristanhub is channel op, but he's montreal based so it's in the middle of the night08:39
gtristanokaaay... in the meantime, let's solve hyphen.h08:41
* pedroalvarez reads this pull request: https://github.com/AbiWord/enchant/pull/208:41
pedroalvarez'Enchant is on life support. There is no real maintainer at the moment. But I'm willing to accept "trivial" patches like these.'08:42
paulsherwoodpedroalvarez: presumably you can see that the artifact server has all of the GDP artifacts?08:43
pedroalvarezmuy build finished in 5 hours!08:43
pedroalvarez(I assume using some of your cache)08:43
paulsherwoodyup08:43
paulsherwoodhow long does it take normally?08:43
gtristanfrom sourceforce project page at least: https://github.com/hunspell/hyphen.git08:44
pedroalvarezpaulsherwood: never had the time to measure it08:44
pedroalvarez:)08:44
paulsherwood:)08:44
*** mariaderidder has joined #baserock08:49
*** toscalix__ has joined #baserock08:58
gtristanok, hyphen builds, webp builds... patches up for those and those definitely work... need to sort out enchant09:03
gtristanjjardon, gnome system morph ? how come ?09:04
* gtristan opens that up to see09:04
gtristanit's not implied by strata/gnome.morph, due to the build-depends line ?09:05
gtristanwe have to specify *every* strata in the system morph ?09:05
SotKgtristan: yes09:05
gtristanif that's the case, we also need to do the same for anything that include qt4-tools, qt5-tools and webtools09:06
SotKit'll build fine thanks to the build-depends line, but the new stratum won't be in the resulting system so things will probably break at runtime09:06
perrylooooh09:07
perrylwrong window09:07
* gtristan greps through systems... this is probably not the ideal setup :-/09:07
* SotK thinks its better than the alternative of not being able to see which strata will be in a system at a glance09:08
gtristanSotK, that should be very easy to generate, though09:09
gtristanybd.py --inspect systems/pony.morph: print a list of all packages implied by this system09:09
gtristanor such09:09
*** paulwaters_ has quit IRC09:10
*** paulwaters__ has joined #baserock09:11
gtristanwell, considering that the concept which grouping packages into self contained stratum - fails to accommodate many use cases - I suppose we're headed towards less and less grouped up morphs, and more towards a definition repository full of single-chunk stratum09:11
gtristanwhich would imply, lots more work maintaining the system morphs09:11
gtristananyway, today is today09:11
SotKthat would help in some cases, but if I was looking at cgit I'd still have to go digging09:11
gtristanlets deal with today09:11
gtristanany preference on the order in which they are specified in the system .morph ?09:13
* gtristan would suspect, order of build dependency would be preferred09:13
gtristanbut eh, thats tricky09:13
gtristanappend at the end ?09:14
* richard_maw usually does09:14
jjardonAlphabetically?09:16
*** franred has joined #baserock09:17
gtristanNew branch: https://gerrit.baserock.org/#/q/topic:share-icu-common09:20
gtristanAll should build09:20
gtristan(and run)09:25
gtristanok, lets just take enchant from github then09:27
* gtristan can at least test the definitions morph build from github before pushing another lorry patch09:27
gtristanOk, enchant builds with https://gerrit.baserock.org/#/c/1236/ & https://gerrit.baserock.org/#/c/1237/09:46
gtristanhyphen & libwebp added to graphics-common (sensible location I think ?) also verified to build at least09:47
gtristanICU patches updated for systems to include the new strata... still TODO: untangle some remaining libs from gnome.morph and add finally build webkit09:48
* gtristan feels on fire, but seems not to have reached his WebKit build target today :-S09:48
rjekWould you like an extinguisher?09:49
jjardongtristan: are those chunks only required by webkit? if yes, why are you putting them in a separate stratum?09:50
* gtristan stands in the clear and awaits an extinguisher09:50
paulsherwoodjonathanmaw: i can confirm that ybd does not deal with local checkouts of components... i'll aim to fix that soonish09:51
jonathanmawin the meantime, can I manage with a file:// URL?09:51
gtristanjjardon, hyphen, enchant & libwebp are only *currently* needed by WebKit... enchant is a spell-checker and hyphen is some Tex transformation tool09:51
paulsherwoodjonathanmaw: ah, i haven't tried that...09:51
gtristanit's a far cry to say that only because they are required by WebKit *today*, they wont be required ever by anything else09:52
wdutchI guess if I move the ciat server in AWS I can reuse the IP so ciat.baserock.org will still work09:52
gtristanjjardon, I already have to yank out geoclue, libinotify and 2 others from gnome.morph, because that kind of assumption was made in the past09:52
jonathanmawor for that matter, an ssh:// url pointing at localhost may work as well09:52
gtristanjjardon, honestly though, I wonder if the opposite is a better question: If WebP image codec is only required by WebKit, why push it into *everything* that requires graphic-common, potentially bloating other builds, instead of creating an individual stratum for libwebp ?09:54
paulsherwoodjonathanmaw: not really. it needs 'some love09:54
paulsherwood'09:54
jjardongtristan: I know, we need to think if the stratum model makes sense09:55
jjardonit more or less work for the low level stack, but no so well for the upper levels09:55
gtristanif you read the scrollback, my statement was that I would create individual -common packages for these because in the future it will be more easy to regroup them (if desired), than it would be to untangle things that are already grouped (as I need to do with gnome.morph)09:56
gtristanjjardon, I took the ensuing silence as ambivalent approval :)09:56
jjardonI try to keep thing in already existing stratums because the pain of update all the systems, and because the original baserock idea was to not have packages but strata of different chunks; but as you can see it doesnt scale very well09:59
gtristanRight, I wonder if it would be better to have the systems auto-resolve that from a few toplevel dependencies, because of the added work it is to update those, but this sounds like a discussion more suited for the ML10:00
jonathanmaw\o/ got GDP deployed! Though this was my branch, not pedro's so I'll have to sort that out.10:00
paulsherwood:)10:00
paulsherwoodjonathanmaw: artifacts should be at http://185.98.148.244:800010:01
gtristanjjardon, I am collecting issues to bring up on the ML, this is one, and another would be about package versions - it's unclear to me how we deal with those at the moment10:01
gtristanjjardon, i.e. for instance, qt5-blabla-devel-system may want one version of ICU, while the other might want another, and then there is the question of stable versions vs experimental, etc10:01
gtristanmaybe we want definitions-wide revisioning, maybe we want something else, I dont know10:02
jjardongtristan: yeah, we have that problem mainly with kernel versions10:02
gtristanit's something I probably have to solve, as currently we will want to do CI with at least toplevel GNOME packages10:03
gtristanbut those will require more bleeding edge dependencies10:03
gtristanand upgrading those dependencies to bleeding-edge compromises stability of other systems living in the same definitions/ repository10:03
jjardongtristan: by bleeding edge you mean latest stable tag or current master? because the current approach is to use latest stable tag at the moment10:04
gtristanone interesting approach is to let git handle some of this, by branching the definitions repository, and only doing CI on a -devel version, keeping stable branches of definitions/ for the builds of stable systems10:05
gtristanjjardon, well, to build gnome 3.18 stable one could expect that gnome's dependencies remain on stable branches of third parties, but one cannot expect that to be true when building master10:06
*** ssam2 has joined #baserock10:07
*** ChanServ sets mode: +v ssam210:07
gtristanin any case, there should be a solution for that *even* if building gnome 3.18 required a new *stable* version of a third party that is shared with another system - it's too intrusive IMO to force the upgrade on the other system just because of a gnome 3.18 requirement10:08
jjardongtristan: you mean a different branch for each system? not sure that will scale very well, and it will make more difficult to contribute10:09
gtristanjjardon, no I mean a baserock wide branching scheme10:09
gtristanjjardon, like "definitions 1.0.0" builds stable *everything* where there is an agreement between "system" maintainers on common dependences10:10
gtristanand then "definitions 1.1.x" becomes dev, suitable for experimental, and then our own internal release cycle10:11
gtristanit's one approach possible anyway10:11
*** gary_perkins has quit IRC10:11
jjardongtristan: oh, ok, I think that could make sense, yes10:11
jjardongtristan: btw, are you trying to build webkit? for what system?10:14
*** gary_perkins has joined #baserock10:15
gtristanjjardon, for GNOME, particularly, I want my next milestone to run gnome-initial-setup10:15
gtristanbut it's also a requirement for various GNOME apps, evolution's message composer for instance uses it10:15
jjardonah, you need to build webkitgtk I guess?10:16
gtristanyes10:16
gtristancurrently I'm using jhbuild 3.18 as reference there10:16
gtristanhttps://git.gnome.org/browse/jhbuild/tree/modulesets/gnome-suites-core-deps-3.18.modules#n135010:16
gtristanjjardon, fwiw, the build is otherwise running nicely with the new icons and backgrounds :)10:17
gtristanjust need to boot, groupadd/useradd a user and give it a password10:17
gtristanand then run systemctl start gdm10:18
jjardonthen I do not think you need to separate all those chunk in different strata, put everything in gnome as I doubt webkitgtk is used outside the gnome world (we can separate them if needed later) what do you think?10:18
jjardongtristan: nice! :)10:19
gtristanwell, it's webkit really, is it only webkitgtk ?10:19
gtristanI think it's webkit, and webkitgtk is just a support wrapper no ?10:19
gtristanwhich does happen to be built inside webkit10:20
gtristanbut that same webkit can generate the qt wrapper too, and contains the engine, it should be shared no ?10:20
jjardongtristan: Id like  to try to run a only-wayland GNOME as a future milestore as well. Lets see if I have some time this weekend :)10:20
* gtristan thinks it's interesting also to provide the platform without the Desktop10:21
* gtristan thinks the GNOME Shell is just about the least interesting thing that comes out of git.gnome.org10:21
rjekAn automobile made from snakes and angry weasels would be exciting.10:22
gtristanit's sad that GTK+ is losing ground though, maybe it's time to jump ship and side with EFL10:22
jjardongtristan: not sure about the webkit thing: but Qt is not using webkit anymore anyway10:22
gtristanwell, we could do 'gnome-platform' 'gnome-desktop' and 'gnome-apps'10:23
gtristanleaving 'gnome-platform' as an interesting stratum to build systems on top of10:24
gtristanembedded or kiosk or other10:24
jjardongtristan: drawing lines is always difficult, but we can try, sure10:24
gtristanright, which is why I personally have the inclination to abort stratums entirely :)10:25
gtristanbut lets table that for a proper ML discussion hahaha10:25
jjardon:)10:25
jjardongtristan:  for example, its really difficult sometimes to decide if something should go in core or core-deps in jhbuild modulesets10:26
gtristanjjardon, purely practical thought: If we put weblit inside gnome/ ... then *any* dependency below gnome/ will trigger an hour of webkit rebuild ;-)10:29
jjardongtristan: ok, you convince me, put it in a separate stratum :)10:30
gtristanhahah :)10:32
jonathanmaw:/ still seeing the confusion in artifact caching.10:33
jonathanmawpedroalvarez: do you have a linux-api-headers.4ef4909b00804245bacfefd19214514c95f90df26d412a3f565bcb2c34cf4509 ?10:33
paulsherwoodjonathanmaw: please go to master ybd, it should enforce arch on you10:33
paulsherwoodjonathanmaw: http://185.98.148.244:8000/artifacts/* has that linux-api-headers10:34
paulsherwoodjonathanmaw: what have you set as kbas-url? it should be http://185.98.148.244:8000/10:35
jonathanmaw>.< I was missing the "/" on the end10:39
*** mariaderidder has quit IRC10:41
pedroalvarezpaulsherwood: I think ybd does 2 deployments at the same time /o\10:46
pedroalvarez(because I have instances: 2 I assume)10:47
paulsherwoodhah, yes10:47
pedroalvarezhahah10:47
paulsherwoodbug!10:47
* jonathanmaw lunches while things get downloaded10:47
gtristanjjardon, before I wrap up for the day... regarding https://gerrit.baserock.org/#/c/1223/, this is solved by https://gerrit.baserock.org/#/c/1232/ right ?10:53
gtristani.e. icu/gnome-system10:53
pedroalvarezpaulsherwood: this worked anyway :)10:58
paulsherwoodcool!10:59
jjardongtristan: yep, can we squash both commits?11:06
gtristanjjardon, is that preferable ? if so, we squash the 3 others too ?11:11
gtristancurrently there is the base patch (applied), 4 patches on strata, and 4 patches against systems11:12
gtristanI did not really expect a 1:1 relation between those systems and strata, but it happened to be the case11:12
jjardonI'd prefer that, yes; so we do not brake the build after applying any of the commits11:13
* gtristan has a definitions checkout with only the icu patches handy11:13
gtristanso I can do it easily11:14
jjardongtristan: great, its only a preference so leave it as its if its going to take too much time of your Friday :)11:16
gtristanit's done11:16
gtristanor it's doing :)11:17
gtristanah crap11:17
gtristanone min11:17
* gtristan goes to discard the extra commits manually from gerrit UI, as re-pushing the topic branch leaves stale patches in place11:18
gtristanjjardon, all done :)11:20
jjardoncheers! :)11:20
gtristanhave a good weekend !11:23
tiredcat_ssam2, you around?11:28
*** tiredcat_ is now known as straycat11:28
perrylif i were to make a change to trove-setup.git, how would i implement it? would it be in the configuring/upgrading trove pages on w.b.o or would i need to redeploy?11:28
perrylby implement i mean integrate so i can see the change on my own trove instance of course :)11:29
SotKI think you'd need to redeploy11:29
SotKs/redeploy/upgrade your trove/11:29
perrylcool! i'll get on that after some brain food11:31
pedroalvarezalso, depending on what kind of changes you can try to test them in place first.11:31
*** gtristan has quit IRC11:33
ssam2tiredcat_: yes11:41
straycatssam2, how would you feel about the reintroduction of detect_build_system, on account of the import tool needing to be able to produce morphs that have build-systems in them?11:44
ssam2I don't understand, could you explain in a bit more detail ?11:45
straycatfrom what i can see when you removed support for older versions of definitions you removed support for build system detection, morph now requires build systems to be explicitly defined or for build instructions to be defined by chunk morphs, so the import tool now needs to produce definitions that specify the build-system11:46
ssam2yes, that's true11:47
ssam2surely the import tool can do that, though ?11:47
straycatsure11:47
straycatthe simplest way seems to be to bring back detect_build_system, since the import tool already uses morphlib, alternatives are probably copy-paste >.>11:47
ssam2if only the import tool is using the code, then it makes more sense to me for the code to be in importlib11:48
ssam2it's only copy-paste if thee's11:48
ssam2*there's more than 1 copy11:48
richard_mawit's cut-paste instead!!!11:49
ssam2but no harm in it being in morphlib, the reason for removing autodetection was that it makes definitions much easier to parse11:49
straycatit's not really so coupled to BuildSystem actually, so cut and paste would be fine11:51
ssam2cool11:51
*** paulwaters__ has quit IRC12:23
jjardonssam2: hi, still ok with https://gerrit.baserock.org/#/c/1097/ ?12:32
ssam2yeah, let's do it12:39
* pedroalvarez is facing this problem with ybd: http://paste.baserock.org/zuyevayuxa12:56
pedroalvarezah, I see why12:56
pedroalvarezbecause this extension relies on the metadata being json12:57
pedroalvarezpaulsherwood: ^^12:57
*** nowster has quit IRC13:00
*** toscalix_ has joined #baserock13:01
*** toscalix__ has quit IRC13:01
*** toscalix_ has quit IRC13:01
jjardonmmm, mason is failing13:04
jjardonhttp://paste.baserock.org/umayupigup13:05
SotKoh dear, I thought that was fixed ages ago? :/13:05
jjardontime to upgrade mason to use latest morph maybe? :)13:06
SotKI'm thinking "fixed sometime last year" kind of ages ago13:07
pedroalvarezjjardon: whenever we do a release, not before :)13:08
pedroalvarezjjardon: I'm happy to do releases, but not to write the release notes :D13:09
ssam2seems the line of code that is breaking has not been touched since the distbuild code was merged into morph.git13:11
*** toscalix__ has joined #baserock13:11
ssam2maybe the problem was fixed somewhere else, and now it triggers the same error further down13:11
ssam2the fix is probably to change that line and its friend to f.write(msg['stdout'].encode('unicode-escape')) I think?13:12
ssam2which would be needed for python 3 portability anyway13:12
ssam2i don't have time to look at it myself13:12
pedroalvareznor have I, but thanks for the hint!13:12
pedroalvarezI'll probable publish a patch with that, but saying that has to be tested13:14
jonathanmawpaulsherwood: got local changes to a repo working in ybd, file:// URLs worked when git:// and ssh:// urls didn't13:19
pedroalvarezssam2: If I find a few minutes I'll put that in mason, and see what happens :)13:21
jjardonwhy every message is repeated 5 times in https://mason-x86-64.baserock.org/current.log ? is that expected?13:34
ssam2jjardon: yes -- mason calls scripts/release-build which calls `morph distbuild` once for each thing it can build13:35
ssam2scripts/release-build is pretty simple, it could be fixed to be less dumb13:35
paulsherwoodjonathanmaw: cool! does un-tarring work?13:35
jonathanmawpaulsherwood: just about to find that out13:35
jjardonssam2: ah, ok13:35
pedroalvarezpaulsherwood: I ended up with a strange situation here13:38
ssam2pedroalvarez: cool, thanks13:41
*** edcragg has quit IRC13:42
*** edcragg has joined #baserock13:43
jonathanmawI've got a new entry in the launcher. unfortunately, journalctl's not logging this boot, for some reason (`journalctl -b` is empty), and I need to set the environment variable for the DBus socket to find out the status of user units13:52
jonathanmawlet's see if I can dig up what the environment variable should be...13:52
pedroalvarezjonathanmaw: `systemctl restart systemd-journald`, and you have journalctl working again13:53
richard_mawjonathanmaw: the journalctl thing could be that /var was mounted on top. Systemd doesn't support separate /var unless / is read-only to begin with13:53
*** toscalix__ has quit IRC13:59
*** toscalix__ has joined #baserock14:04
jonathanmawgrah! the gdp-hmi-launcher2 doesn't start systemd services, so adding an app to the launcher doesn't do anything unless you alter the controller as well.14:11
paulsherwoodjonathanmaw: did you manage to try the untar?14:11
jonathanmawpaulsherwood: yep. `tar -zxf $ARTIFACT_DIR/$ARTIFACT/$ARTIFACT -C /` works a treat14:12
jonathanmawp.s. I think that's a bug14:13
paulsherwoodwhy a bug?14:15
jonathanmawyou have an artifact tar inside a directory with the same name as the artifact tar14:15
jonathanmawand that artifact tar directory is adjacent to the artifact's build log and .meta file in the cachedir14:16
jonathanmaws/cachedir/artifact dir/14:16
paulsherwoodjonathanmaw: it is the current solution for atomicity14:16
jonathanmawwould the .meta and build-log also benefit from atomicity?14:17
paulsherwoodcurrently the downloadable artifact doesn't include them14:18
paulsherwood(well, metadata is in its /baserock subdir)14:18
paulsherwoodjonathanmaw: but in any case, i'll raise an issue on it14:19
paulsherwoodjonathanmaw: so can you summarise what you did to work on a local checkout, please?14:23
paulsherwood(and is this from ybd master-ish?)14:23
jonathanmawpaulsherwood: ok, a document on paste.baserock.org okay, or would you prefer an E-mail?14:24
paulsherwoodpaste is fine14:24
jonathanmawybd masterish, i.e. last commit "Remove forgotten debug log line"14:24
paulsherwood:)14:24
paulsherwoodpedroalvarez: have you arrived at a commit for tagging?14:27
pedroalvarezpaulsherwood: yup, branch and tag created14:27
pedroalvarezI've started now with the actual release :)14:27
paulsherwoodkewl!14:27
paulsherwoodGENIVI-K1.0 i assume?14:28
pedroalvarezyes14:30
*** toscalix_ has joined #baserock14:43
*** franred has quit IRC14:43
jonathanmawpaulsherwood: my instructions for local changes http://paste.baserock.org/odasezinof14:46
*** toscalix__ has quit IRC14:47
*** toscalix_ has quit IRC14:48
paulsherwoodjonathanmaw: fabulous14:50
richard_mawjonathanmaw: you could make it a little faster by telling git not to check out HEAD when cloning, and change the git command to explicitly create your hack branch from master, but that complication may just confuse people following the instructions.14:57
jonathanmawit'd also be faster if I located the cached git repo and pulled from that, but again, complications.14:59
pedroalvarezpaulsherwood: note that paste.baserock.org data is not persistent15:01
jonathanmawpaulsherwood, pedroalvarez: anything else I should be doing, and will pedroalvarez need this Jetson to prepare it for the hands-on?15:04
paulsherwoodpedroalvarez: thanks!15:09
paulsherwoodjonathanmaw: fix any of the issues in ybd? :)15:09
jonathanmawpaulsherwood: no thanks15:10
paulsherwoodjonathanmaw: interesting response to your CEO :)15:10
pedroalvarezhohoho15:12
* jonathanmaw remembered that there are various misc fixes to the GDP.15:20
jonathanmawpedroalvarez: are you accepting patches to that branch, given it's already tagged?15:20
paulsherwoodjonathanmaw: we can accept patches. they could be usefully applied during the hands-on for example15:21
pedroalvarezjonathanmaw: create a separate branch based on the tagged one, please :)15:22
* paulsherwood assumes jonathanmaw would only ever work that way :)15:26
* jonathanmaw is dithering on the patches as it seems he's had important E-mails that he's been neglecting :C15:34
paulsherwoodjonathanmaw: can't they wait?15:34
jonathanmawpaulsherwood: most of them can, not the AGL and GDP lifecycle ones, I imagine.15:36
paulsherwoodwhat is http://ciat.baserock.org:8010/waterfall actually doing at this point? it seems to have been rather quiet15:52
SotKnothing since wednesday from the look of things :/15:53
paulsherwoodthat's quite an expensive way to run a statit website15:55
paulsherwoodstatic15:55
*** paulwaters_ has joined #baserock16:20
*** ssam2 has quit IRC16:32
*** bashrc has quit IRC16:57
*** jonathanmaw has quit IRC16:58
*** toscalix__ has joined #baserock17:00
*** toscalix__ has quit IRC17:13
*** paulwaters_ has quit IRC17:16
*** edcragg has quit IRC17:20
pedroalvarezpaulsherwood: I agree, we need to continue spending time on ciat17:39
pedroalvarezfirst of all, automate the deployment17:40
pedroalvarezthen move it to somewhere cheaper, and start making in elastic17:45
* pedroalvarez heads off17:45
*** paulwaters_ has joined #baserock17:57
*** paulwaters_ has quit IRC18:11
*** tiagogomes has quit IRC18:21
*** paulwaters_ has joined #baserock19:01
*** paulwaters_ has joined #baserock20:18

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!