*** tiredcat_ has joined #baserock | 00:04 | |
*** richard_maw has joined #baserock | 00:04 | |
*** rdale has joined #baserock | 00:04 | |
*** robtaylor has joined #baserock | 00:04 | |
*** kornbluth.freenode.net sets mode: +v richard_maw | 00:04 | |
*** ChanServ has quit IRC | 00:04 | |
*** persia has quit IRC | 00:04 | |
*** flatmush has quit IRC | 00:04 | |
*** jjardon has quit IRC | 00:04 | |
*** _longines has quit IRC | 00:04 | |
*** cyndis has quit IRC | 00:04 | |
*** nowster has joined #baserock | 00:06 | |
*** gtristan has joined #baserock | 00:06 | |
*** pedroalvarez has joined #baserock | 00:06 | |
*** bjdooks has joined #baserock | 00:06 | |
*** inara has joined #baserock | 00:06 | |
*** bfletcher_ has joined #baserock | 00:06 | |
*** De|ta has joined #baserock | 00:06 | |
*** petefotheringham has joined #baserock | 00:06 | |
*** kornbluth.freenode.net sets mode: +v pedroalvarez | 00:06 | |
*** gary_perkins has joined #baserock | 00:08 | |
*** juergbi has joined #baserock | 00:08 | |
*** JPohlmann has joined #baserock | 00:10 | |
*** Kinnison has joined #baserock | 00:10 | |
*** radiofree has joined #baserock | 00:10 | |
*** lachlanmackenzie has joined #baserock | 00:10 | |
*** SotK has joined #baserock | 00:10 | |
*** drnic has joined #baserock | 00:12 | |
*** rjek has joined #baserock | 00:12 | |
*** tlsa has joined #baserock | 00:12 | |
*** sebh has joined #baserock | 00:12 | |
*** wdutch has joined #baserock | 00:12 | |
*** benbrown_ has joined #baserock | 00:12 | |
*** ratmice____ has joined #baserock | 00:12 | |
*** perryl has joined #baserock | 00:12 | |
*** persia has joined #baserock | 00:14 | |
*** flatmush has joined #baserock | 00:14 | |
*** jjardon has joined #baserock | 00:14 | |
*** _longines has joined #baserock | 00:14 | |
*** cyndis has joined #baserock | 00:14 | |
*** brlogger` has joined #baserock | 00:16 | |
*** edcragg has joined #baserock | 00:16 | |
*** paulsherwood has joined #baserock | 00:16 | |
*** petefoth has joined #baserock | 00:16 | |
*** dabukalam has joined #baserock | 00:16 | |
*** ctgriffiths has joined #baserock | 00:16 | |
*** Zara has joined #baserock | 00:16 | |
*** doffm has joined #baserock | 00:16 | |
*** bwh has joined #baserock | 00:16 | |
*** Kinnison has quit IRC | 00:21 | |
*** Kinnison has joined #baserock | 00:21 | |
*** ChanServ has joined #baserock | 00:30 | |
*** card.freenode.net sets mode: +o ChanServ | 00:30 | |
*** gtristan has quit IRC | 03:02 | |
*** gtristan has joined #baserock | 03:20 | |
*** jmacs_ has quit IRC | 03:51 | |
*** jmacs has joined #baserock | 03:51 | |
gtristan | Sharing ICU libraries ready for review: https://gerrit.baserock.org/#/q/topic:share-icu-common | 04:33 |
---|---|---|
gtristan | Note, 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 |
gtristan | If 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: I282f6d4f1f599e76a1c196269233e38ea2d57d4f | 04:36 | |
gtristan | ah, found it through search (some reason I couldnt find it first try, maybe I messed up the search term) | 04:44 |
gtristan | https://gerrit.baserock.org/#/c/82/ | 04:44 |
gtristan | looks like it's intended to also build on x86 targets, but I *think* we prefer the conditional | 04:45 |
*** paulwaters_ has joined #baserock | 06:11 | |
gtristan | So... I have a dependency (enchant library from abisource)... and it's svn, the lorry will look like this: http://paste.baserock.org/weqecuwutu | 06:17 |
gtristan | Now, before uploading that lorry... I of course want to test building it from definitions/ | 06:18 |
gtristan | What will I put in the ref: and the repo: ? | 06:18 |
gtristan | will the .morph happily gobble up an svn repo: ? | 06:19 |
gtristan | hmmm | 06:24 |
gtristan | fatal: repository 'http://svn.abisource.com/enchant/' not found | 06:24 |
* gtristan submits https://gerrit.baserock.org/1227 ... | 06:30 | |
* SotK +1s | 06:47 | |
SotK | for 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 system | 06:48 |
gtristan | Ah, so I will have to look into that... running lorry locally... | 06:51 |
gtristan | SotK, for now... maybe it's not worth the overhead ? | 06:51 |
gtristan | I hope that anything else will be gits... libwebp is a git so I was able to test | 06:52 |
gtristan | Right 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 IRC | 06:57 | |
*** paulwaters_ has joined #baserock | 06:58 | |
* richard_maw is confused about the difference between WebKit and QTWebKit, since we seem to always be building the latter | 07:10 | |
gtristan | richard_maw, I am also confused, but looking at the lorry - qt5/qtwebkit points to something at code.qt.io | 07:14 |
gtristan | who knows what that is | 07:15 |
richard_maw | it's probably a fork of an old version | 07:15 |
gtristan | FWIW, this morning I did that ICU refactoring https://gerrit.baserock.org/#/q/topic:share-icu-common | 07:15 |
richard_maw | everyone seems to fork Webkit… | 07:15 |
gtristan | trying to get that out of the way | 07:15 |
gtristan | possibly a downstream fork indeed | 07:16 |
gtristan | sigh, I've been searching google, debian package sources... irc channels | 07:17 |
gtristan | I cant seem to locate the source of libhyphen | 07:17 |
gtristan | distros 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 project | 07:18 | |
richard_maw | gtristan: 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 import | 07:18 |
gtristan | thanks, I have a floating .morph ready to test against an existing enchant :) | 07:19 |
gtristan | with libwebp, enchant... and the missing "hyphen.h" which I still have to track down, that will give us all the deps needed for WebKit | 07:20 |
gtristan | I will have to move some things out of gnome/, which WebKit itself depends on | 07:20 |
Kinnison | please don't rearrange the location of repositories | 07:20 |
Kinnison | it causes pain for downstream troves | 07:20 |
gtristan | libsecret, libgweather, geoclue and libnotify | 07:20 |
gtristan | Kinnison, I mean move out of definitions/strata/gnome/ | 07:21 |
Kinnison | oh that's less awful :-) | 07:21 |
gtristan | :) | 07:21 |
richard_maw | gtristan: 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 beginning | 07:23 |
*** ssam2 has joined #baserock | 07:24 | |
*** ChanServ sets mode: +v ssam2 | 07:24 | |
gtristan | richard_maw, it's not really like a regular project repo, but I like to stick to the atomic commits | 07:25 |
gtristan | follow rules where you know, it should at least build between any given commit, if ever the need to bisect arises | 07: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_maw | it would, but caching would help there | 07:31 |
richard_maw | gtristan: http://sourceforge.net/projects/hunspell/files/Hyphen/ appears to be hyphen | 07: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 file | 07:37 |
richard_maw | ) | 07:37 |
*** jonathanmaw has joined #baserock | 07:42 | |
gtristan | richard_maw, thanks :) | 07:46 |
gtristan | So question... regarding libsecret/libgweather/geoclue/libinotify... | 07:46 |
gtristan | libs/apps in gnome/ depend on those, and so does webkit | 07:46 |
gtristan | my inclination is to create separate stratum for each of those, with the regular -common suffix | 07:47 |
gtristan | and not try to group them | 07:47 |
gtristan | thoughts ? | 07:47 |
gtristan | another 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 + webkit | 07:48 |
gtristan | cause anything else building webkit (I would assume potentially a lot)... would be pulling in unneeded cruft from gnome-deps | 07:48 |
richard_maw | The 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_maw | the libgweather and geoclue look like positioning components, which might be sensibly grouped | 07:50 |
richard_maw | as a purist I'd argue that libinotify and libsecret are fairly integral system libraries, but pragmatically, that'll just cause unnecessary rebuilds | 07:51 |
richard_maw | gtristan: honestly, I have no right answer for you. | 07:51 |
*** tiagogomes has joined #baserock | 07:52 | |
gtristan | alright | 08:02 |
pedroalvarez | hehe, that ICU change makes sense, it will triger some rebuilds here :) | 08:03 |
pedroalvarez | but it* | 08:03 |
gtristan | I think for now, go with -common stratum for each, giving maximum flexibility - and most easy to change and regroup later if that becomes desirable | 08:04 |
gtristan | as opposed to gnome.morph which is tightly coupled and more work to untangle | 08:05 |
gtristan | note regarding ICU: I have a problem without merging that; which is ICU is currently repeated in gnome/ AND a dependency of webkit | 08:06 |
gtristan | if I were to work around it, I will end up building it twice | 08:06 |
*** ssam2 has quit IRC | 08:06 | |
gtristan | and hopefully ybd would complain about that | 08:07 |
*** bashrc has joined #baserock | 08:07 | |
gtristan | then again, adding icu-common does not mean you absolutely _must_ merge the qt[45]-tools patches right away | 08:07 |
gtristan | so there is middle ground :) | 08:08 |
richard_maw | last 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 builds | 08:08 |
gtristan | hmmm | 08:12 |
gtristan | Is this an error with the svn lorry: http://git.baserock.org/cgi-bin/cgit.cgi/delta/enchant.git/ ? | 08:13 |
gtristan | or just time skew ? | 08:13 |
gtristan | i.e. just still not cloned yet | 08:13 |
jjardon | Hi, FYI, qtwebkit is deprecated and will be removed in next Qt releases | 08:15 |
jjardon | Qt webengine (based on chromium) is the new thing | 08:17 |
gtristan | looking 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 |
gtristan | it looks to me like "layout" : "standard" is correct for that repository | 08:18 |
gtristan | has the regular trunk/ branches/ tags/ layout | 08:18 |
richard_maw | it does to me too, hence why I approved it | 08:18 |
* gtristan scratches head | 08:19 | |
richard_maw | http://git.baserock.org/lc-status.html says enchant is queued to be run in 2h40m, which implies it must have already tried | 08:19 |
richard_maw | hmm | 08:19 |
jonathanmaw | jjardon: interesting. Do you know if it builds in less than an hour? | 08:19 |
jjardon | No idea; but I know qtwebkit will be removed in Qt 5.6 | 08:20 |
richard_maw | pedroalvarez: do you remember how to see the lorry controller logs? | 08:20 |
rjek | jjardon: They're removing things in a point release? | 08:20 |
jonathanmaw | rjek: maybe "qt5." is its name now :) | 08:21 |
jjardon | rjek: https://wiki.qt.io/New_Features_in_Qt_5.6 | 08:22 |
pedroalvarez | richard_maw: I guess you don't mean lorry logs | 08:22 |
richard_maw | pedroalvarez: specifically, I want to see the logs for job id 64559 | 08:23 |
rjek | This reminds me of one of the many reasons I dislike Qt :) | 08:23 |
pedroalvarez | richard_maw: `ssh -L 12765:localhost:12765 root@git.baserock.org` | 08:24 |
pedroalvarez | and then in a browser you will be able to open "localhost:12765/1.0/status-html" | 08:24 |
richard_maw | ah, 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_maw | hm, git svn doesn't like plain http URLs apparently | 08:25 |
* pedroalvarez appreciates people helping with baserock-ops :) | 08:26 | |
gtristan | hmmm | 08:27 |
gtristan | grepping through open-source-lorries/* ... there are mostly http://svn.... when it comes to SVN lorries :-/ | 08:28 |
gtristan | some of them are svn:// indeed, a mix | 08:29 |
richard_maw | https://github.com/AbiWord/enchant looks like either an official git mirror, or that they've moved development to git | 08:29 |
gtristan | richard_maw, commits there are 7+ years old ? | 08:32 |
gtristan | ah no | 08:32 |
gtristan | there is recent dev there | 08:32 |
gtristan | but project page http://www.abisource.com/projects/enchant/ does not refer to the github thing | 08:33 |
pedroalvarez | heh I wonder if they are still alive at #abiword (irc.gnome.org) | 08:38 |
gtristan | fwiw, svn co svn://svn.abisource.com/enchant/ gives an error | 08:38 |
gtristan | pedroalvarez, I'm already there ;-) | 08:39 |
gtristan | nobody answered so far | 08:39 |
gtristan | hub is channel op, but he's montreal based so it's in the middle of the night | 08:39 |
gtristan | okaaay... in the meantime, let's solve hyphen.h | 08:41 |
* pedroalvarez reads this pull request: https://github.com/AbiWord/enchant/pull/2 | 08: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 |
paulsherwood | pedroalvarez: presumably you can see that the artifact server has all of the GDP artifacts? | 08:43 |
pedroalvarez | muy build finished in 5 hours! | 08:43 |
pedroalvarez | (I assume using some of your cache) | 08:43 |
paulsherwood | yup | 08:43 |
paulsherwood | how long does it take normally? | 08:43 |
gtristan | from sourceforce project page at least: https://github.com/hunspell/hyphen.git | 08:44 |
pedroalvarez | paulsherwood: never had the time to measure it | 08:44 |
pedroalvarez | :) | 08:44 |
paulsherwood | :) | 08:44 |
*** mariaderidder has joined #baserock | 08:49 | |
*** toscalix__ has joined #baserock | 08:58 | |
gtristan | ok, hyphen builds, webp builds... patches up for those and those definitely work... need to sort out enchant | 09:03 |
gtristan | jjardon, gnome system morph ? how come ? | 09:04 |
* gtristan opens that up to see | 09:04 | |
gtristan | it's not implied by strata/gnome.morph, due to the build-depends line ? | 09:05 |
gtristan | we have to specify *every* strata in the system morph ? | 09:05 |
SotK | gtristan: yes | 09:05 |
gtristan | if that's the case, we also need to do the same for anything that include qt4-tools, qt5-tools and webtools | 09:06 |
SotK | it'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 runtime | 09:06 |
perryl | ooooh | 09:07 |
perryl | wrong window | 09: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 glance | 09:08 | |
gtristan | SotK, that should be very easy to generate, though | 09:09 |
gtristan | ybd.py --inspect systems/pony.morph: print a list of all packages implied by this system | 09:09 |
gtristan | or such | 09:09 |
*** paulwaters_ has quit IRC | 09:10 | |
*** paulwaters__ has joined #baserock | 09:11 | |
gtristan | well, 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 stratum | 09:11 |
gtristan | which would imply, lots more work maintaining the system morphs | 09:11 |
gtristan | anyway, today is today | 09:11 |
SotK | that would help in some cases, but if I was looking at cgit I'd still have to go digging | 09:11 |
gtristan | lets deal with today | 09:11 |
gtristan | any preference on the order in which they are specified in the system .morph ? | 09:13 |
* gtristan would suspect, order of build dependency would be preferred | 09:13 | |
gtristan | but eh, thats tricky | 09:13 |
gtristan | append at the end ? | 09:14 |
* richard_maw usually does | 09:14 | |
jjardon | Alphabetically? | 09:16 |
*** franred has joined #baserock | 09:17 | |
gtristan | New branch: https://gerrit.baserock.org/#/q/topic:share-icu-common | 09:20 |
gtristan | All should build | 09:20 |
gtristan | (and run) | 09:25 |
gtristan | ok, lets just take enchant from github then | 09:27 |
* gtristan can at least test the definitions morph build from github before pushing another lorry patch | 09:27 | |
gtristan | Ok, enchant builds with https://gerrit.baserock.org/#/c/1236/ & https://gerrit.baserock.org/#/c/1237/ | 09:46 |
gtristan | hyphen & libwebp added to graphics-common (sensible location I think ?) also verified to build at least | 09:47 |
gtristan | ICU patches updated for systems to include the new strata... still TODO: untangle some remaining libs from gnome.morph and add finally build webkit | 09:48 |
* gtristan feels on fire, but seems not to have reached his WebKit build target today :-S | 09:48 | |
rjek | Would you like an extinguisher? | 09:49 |
jjardon | gtristan: 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 extinguisher | 09:50 | |
paulsherwood | jonathanmaw: i can confirm that ybd does not deal with local checkouts of components... i'll aim to fix that soonish | 09:51 |
jonathanmaw | in the meantime, can I manage with a file:// URL? | 09:51 |
gtristan | jjardon, hyphen, enchant & libwebp are only *currently* needed by WebKit... enchant is a spell-checker and hyphen is some Tex transformation tool | 09:51 |
paulsherwood | jonathanmaw: ah, i haven't tried that... | 09:51 |
gtristan | it's a far cry to say that only because they are required by WebKit *today*, they wont be required ever by anything else | 09:52 |
wdutch | I guess if I move the ciat server in AWS I can reuse the IP so ciat.baserock.org will still work | 09:52 |
gtristan | jjardon, I already have to yank out geoclue, libinotify and 2 others from gnome.morph, because that kind of assumption was made in the past | 09:52 |
jonathanmaw | or for that matter, an ssh:// url pointing at localhost may work as well | 09:52 |
gtristan | jjardon, 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 |
paulsherwood | jonathanmaw: not really. it needs 'some love | 09:54 |
paulsherwood | ' | 09:54 |
jjardon | gtristan: I know, we need to think if the stratum model makes sense | 09:55 |
jjardon | it more or less work for the low level stack, but no so well for the upper levels | 09:55 |
gtristan | if 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 |
gtristan | jjardon, I took the ensuing silence as ambivalent approval :) | 09:56 |
jjardon | I 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 well | 09:59 |
gtristan | Right, 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 ML | 10: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 |
paulsherwood | jonathanmaw: artifacts should be at http://185.98.148.244:8000 | 10:01 |
gtristan | jjardon, 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 moment | 10:01 |
gtristan | jjardon, 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, etc | 10:01 |
gtristan | maybe we want definitions-wide revisioning, maybe we want something else, I dont know | 10:02 |
jjardon | gtristan: yeah, we have that problem mainly with kernel versions | 10:02 |
gtristan | it's something I probably have to solve, as currently we will want to do CI with at least toplevel GNOME packages | 10:03 |
gtristan | but those will require more bleeding edge dependencies | 10:03 |
gtristan | and upgrading those dependencies to bleeding-edge compromises stability of other systems living in the same definitions/ repository | 10:03 |
jjardon | gtristan: by bleeding edge you mean latest stable tag or current master? because the current approach is to use latest stable tag at the moment | 10:04 |
gtristan | one 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 systems | 10:05 |
gtristan | jjardon, 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 master | 10:06 |
*** ssam2 has joined #baserock | 10:07 | |
*** ChanServ sets mode: +v ssam2 | 10:07 | |
gtristan | in 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 requirement | 10:08 |
jjardon | gtristan: you mean a different branch for each system? not sure that will scale very well, and it will make more difficult to contribute | 10:09 |
gtristan | jjardon, no I mean a baserock wide branching scheme | 10:09 |
gtristan | jjardon, like "definitions 1.0.0" builds stable *everything* where there is an agreement between "system" maintainers on common dependences | 10:10 |
gtristan | and then "definitions 1.1.x" becomes dev, suitable for experimental, and then our own internal release cycle | 10:11 |
gtristan | it's one approach possible anyway | 10:11 |
*** gary_perkins has quit IRC | 10:11 | |
jjardon | gtristan: oh, ok, I think that could make sense, yes | 10:11 |
jjardon | gtristan: btw, are you trying to build webkit? for what system? | 10:14 |
*** gary_perkins has joined #baserock | 10:15 | |
gtristan | jjardon, for GNOME, particularly, I want my next milestone to run gnome-initial-setup | 10:15 |
gtristan | but it's also a requirement for various GNOME apps, evolution's message composer for instance uses it | 10:15 |
jjardon | ah, you need to build webkitgtk I guess? | 10:16 |
gtristan | yes | 10:16 |
gtristan | currently I'm using jhbuild 3.18 as reference there | 10:16 |
gtristan | https://git.gnome.org/browse/jhbuild/tree/modulesets/gnome-suites-core-deps-3.18.modules#n1350 | 10:16 |
gtristan | jjardon, fwiw, the build is otherwise running nicely with the new icons and backgrounds :) | 10:17 |
gtristan | just need to boot, groupadd/useradd a user and give it a password | 10:17 |
gtristan | and then run systemctl start gdm | 10:18 |
jjardon | then 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 |
jjardon | gtristan: nice! :) | 10:19 |
gtristan | well, it's webkit really, is it only webkitgtk ? | 10:19 |
gtristan | I think it's webkit, and webkitgtk is just a support wrapper no ? | 10:19 |
gtristan | which does happen to be built inside webkit | 10:20 |
gtristan | but that same webkit can generate the qt wrapper too, and contains the engine, it should be shared no ? | 10:20 |
jjardon | gtristan: 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 Desktop | 10:21 | |
* gtristan thinks the GNOME Shell is just about the least interesting thing that comes out of git.gnome.org | 10:21 | |
rjek | An automobile made from snakes and angry weasels would be exciting. | 10:22 |
gtristan | it's sad that GTK+ is losing ground though, maybe it's time to jump ship and side with EFL | 10:22 |
jjardon | gtristan: not sure about the webkit thing: but Qt is not using webkit anymore anyway | 10:22 |
gtristan | well, we could do 'gnome-platform' 'gnome-desktop' and 'gnome-apps' | 10:23 |
gtristan | leaving 'gnome-platform' as an interesting stratum to build systems on top of | 10:24 |
gtristan | embedded or kiosk or other | 10:24 |
jjardon | gtristan: drawing lines is always difficult, but we can try, sure | 10:24 |
gtristan | right, which is why I personally have the inclination to abort stratums entirely :) | 10:25 |
gtristan | but lets table that for a proper ML discussion hahaha | 10:25 |
jjardon | :) | 10:25 |
jjardon | gtristan: for example, its really difficult sometimes to decide if something should go in core or core-deps in jhbuild modulesets | 10:26 |
gtristan | jjardon, purely practical thought: If we put weblit inside gnome/ ... then *any* dependency below gnome/ will trigger an hour of webkit rebuild ;-) | 10:29 |
jjardon | gtristan: ok, you convince me, put it in a separate stratum :) | 10:30 |
gtristan | hahah :) | 10:32 |
jonathanmaw | :/ still seeing the confusion in artifact caching. | 10:33 |
jonathanmaw | pedroalvarez: do you have a linux-api-headers.4ef4909b00804245bacfefd19214514c95f90df26d412a3f565bcb2c34cf4509 ? | 10:33 |
paulsherwood | jonathanmaw: please go to master ybd, it should enforce arch on you | 10:33 |
paulsherwood | jonathanmaw: http://185.98.148.244:8000/artifacts/* has that linux-api-headers | 10:34 |
paulsherwood | jonathanmaw: 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 end | 10:39 |
*** mariaderidder has quit IRC | 10:41 | |
pedroalvarez | paulsherwood: I think ybd does 2 deployments at the same time /o\ | 10:46 |
pedroalvarez | (because I have instances: 2 I assume) | 10:47 |
paulsherwood | hah, yes | 10:47 |
pedroalvarez | hahah | 10:47 |
paulsherwood | bug! | 10:47 |
* jonathanmaw lunches while things get downloaded | 10:47 | |
gtristan | jjardon, 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 |
gtristan | i.e. icu/gnome-system | 10:53 |
pedroalvarez | paulsherwood: this worked anyway :) | 10:58 |
paulsherwood | cool! | 10:59 |
jjardon | gtristan: yep, can we squash both commits? | 11:06 |
gtristan | jjardon, is that preferable ? if so, we squash the 3 others too ? | 11:11 |
gtristan | currently there is the base patch (applied), 4 patches on strata, and 4 patches against systems | 11:12 |
gtristan | I did not really expect a 1:1 relation between those systems and strata, but it happened to be the case | 11:12 |
jjardon | I'd prefer that, yes; so we do not brake the build after applying any of the commits | 11:13 |
* gtristan has a definitions checkout with only the icu patches handy | 11:13 | |
gtristan | so I can do it easily | 11:14 |
jjardon | gtristan: great, its only a preference so leave it as its if its going to take too much time of your Friday :) | 11:16 |
gtristan | it's done | 11:16 |
gtristan | or it's doing :) | 11:17 |
gtristan | ah crap | 11:17 |
gtristan | one min | 11:17 |
* gtristan goes to discard the extra commits manually from gerrit UI, as re-pushing the topic branch leaves stale patches in place | 11:18 | |
gtristan | jjardon, all done :) | 11:20 |
jjardon | cheers! :) | 11:20 |
gtristan | have a good weekend ! | 11:23 |
tiredcat_ | ssam2, you around? | 11:28 |
*** tiredcat_ is now known as straycat | 11:28 | |
perryl | if 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 |
perryl | by implement i mean integrate so i can see the change on my own trove instance of course :) | 11:29 |
SotK | I think you'd need to redeploy | 11:29 |
SotK | s/redeploy/upgrade your trove/ | 11:29 |
perryl | cool! i'll get on that after some brain food | 11:31 |
pedroalvarez | also, depending on what kind of changes you can try to test them in place first. | 11:31 |
*** gtristan has quit IRC | 11:33 | |
ssam2 | tiredcat_: yes | 11:41 |
straycat | ssam2, 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 |
ssam2 | I don't understand, could you explain in a bit more detail ? | 11:45 |
straycat | from 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-system | 11:46 |
ssam2 | yes, that's true | 11:47 |
ssam2 | surely the import tool can do that, though ? | 11:47 |
straycat | sure | 11:47 |
straycat | the 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 |
ssam2 | if only the import tool is using the code, then it makes more sense to me for the code to be in importlib | 11:48 |
ssam2 | it's only copy-paste if thee's | 11:48 |
ssam2 | *there's more than 1 copy | 11:48 |
richard_maw | it's cut-paste instead!!! | 11:49 |
ssam2 | but no harm in it being in morphlib, the reason for removing autodetection was that it makes definitions much easier to parse | 11:49 |
straycat | it's not really so coupled to BuildSystem actually, so cut and paste would be fine | 11:51 |
ssam2 | cool | 11:51 |
*** paulwaters__ has quit IRC | 12:23 | |
jjardon | ssam2: hi, still ok with https://gerrit.baserock.org/#/c/1097/ ? | 12:32 |
ssam2 | yeah, let's do it | 12:39 |
* pedroalvarez is facing this problem with ybd: http://paste.baserock.org/zuyevayuxa | 12:56 | |
pedroalvarez | ah, I see why | 12:56 |
pedroalvarez | because this extension relies on the metadata being json | 12:57 |
pedroalvarez | paulsherwood: ^^ | 12:57 |
*** nowster has quit IRC | 13:00 | |
*** toscalix_ has joined #baserock | 13:01 | |
*** toscalix__ has quit IRC | 13:01 | |
*** toscalix_ has quit IRC | 13:01 | |
jjardon | mmm, mason is failing | 13:04 |
jjardon | http://paste.baserock.org/umayupigup | 13:05 |
SotK | oh dear, I thought that was fixed ages ago? :/ | 13:05 |
jjardon | time to upgrade mason to use latest morph maybe? :) | 13:06 |
SotK | I'm thinking "fixed sometime last year" kind of ages ago | 13:07 |
pedroalvarez | jjardon: whenever we do a release, not before :) | 13:08 |
pedroalvarez | jjardon: I'm happy to do releases, but not to write the release notes :D | 13:09 |
ssam2 | seems the line of code that is breaking has not been touched since the distbuild code was merged into morph.git | 13:11 |
*** toscalix__ has joined #baserock | 13:11 | |
ssam2 | maybe the problem was fixed somewhere else, and now it triggers the same error further down | 13:11 |
ssam2 | the fix is probably to change that line and its friend to f.write(msg['stdout'].encode('unicode-escape')) I think? | 13:12 |
ssam2 | which would be needed for python 3 portability anyway | 13:12 |
ssam2 | i don't have time to look at it myself | 13:12 |
pedroalvarez | nor have I, but thanks for the hint! | 13:12 |
pedroalvarez | I'll probable publish a patch with that, but saying that has to be tested | 13:14 |
jonathanmaw | paulsherwood: got local changes to a repo working in ybd, file:// URLs worked when git:// and ssh:// urls didn't | 13:19 |
pedroalvarez | ssam2: If I find a few minutes I'll put that in mason, and see what happens :) | 13:21 |
jjardon | why every message is repeated 5 times in https://mason-x86-64.baserock.org/current.log ? is that expected? | 13:34 |
ssam2 | jjardon: yes -- mason calls scripts/release-build which calls `morph distbuild` once for each thing it can build | 13:35 |
ssam2 | scripts/release-build is pretty simple, it could be fixed to be less dumb | 13:35 |
paulsherwood | jonathanmaw: cool! does un-tarring work? | 13:35 |
jonathanmaw | paulsherwood: just about to find that out | 13:35 |
jjardon | ssam2: ah, ok | 13:35 |
pedroalvarez | paulsherwood: I ended up with a strange situation here | 13:38 |
ssam2 | pedroalvarez: cool, thanks | 13:41 |
*** edcragg has quit IRC | 13:42 | |
*** edcragg has joined #baserock | 13:43 | |
jonathanmaw | I'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 units | 13:52 |
jonathanmaw | let's see if I can dig up what the environment variable should be... | 13:52 |
pedroalvarez | jonathanmaw: `systemctl restart systemd-journald`, and you have journalctl working again | 13:53 |
richard_maw | jonathanmaw: the journalctl thing could be that /var was mounted on top. Systemd doesn't support separate /var unless / is read-only to begin with | 13:53 |
*** toscalix__ has quit IRC | 13:59 | |
*** toscalix__ has joined #baserock | 14:04 | |
jonathanmaw | grah! 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 |
paulsherwood | jonathanmaw: did you manage to try the untar? | 14:11 |
jonathanmaw | paulsherwood: yep. `tar -zxf $ARTIFACT_DIR/$ARTIFACT/$ARTIFACT -C /` works a treat | 14:12 |
jonathanmaw | p.s. I think that's a bug | 14:13 |
paulsherwood | why a bug? | 14:15 |
jonathanmaw | you have an artifact tar inside a directory with the same name as the artifact tar | 14:15 |
jonathanmaw | and that artifact tar directory is adjacent to the artifact's build log and .meta file in the cachedir | 14:16 |
jonathanmaw | s/cachedir/artifact dir/ | 14:16 |
paulsherwood | jonathanmaw: it is the current solution for atomicity | 14:16 |
jonathanmaw | would the .meta and build-log also benefit from atomicity? | 14:17 |
paulsherwood | currently the downloadable artifact doesn't include them | 14:18 |
paulsherwood | (well, metadata is in its /baserock subdir) | 14:18 |
paulsherwood | jonathanmaw: but in any case, i'll raise an issue on it | 14:19 |
paulsherwood | jonathanmaw: 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 |
jonathanmaw | paulsherwood: ok, a document on paste.baserock.org okay, or would you prefer an E-mail? | 14:24 |
paulsherwood | paste is fine | 14:24 |
jonathanmaw | ybd masterish, i.e. last commit "Remove forgotten debug log line" | 14:24 |
paulsherwood | :) | 14:24 |
paulsherwood | pedroalvarez: have you arrived at a commit for tagging? | 14:27 |
pedroalvarez | paulsherwood: yup, branch and tag created | 14:27 |
pedroalvarez | I've started now with the actual release :) | 14:27 |
paulsherwood | kewl! | 14:27 |
paulsherwood | GENIVI-K1.0 i assume? | 14:28 |
pedroalvarez | yes | 14:30 |
*** toscalix_ has joined #baserock | 14:43 | |
*** franred has quit IRC | 14:43 | |
jonathanmaw | paulsherwood: my instructions for local changes http://paste.baserock.org/odasezinof | 14:46 |
*** toscalix__ has quit IRC | 14:47 | |
*** toscalix_ has quit IRC | 14:48 | |
paulsherwood | jonathanmaw: fabulous | 14:50 |
richard_maw | jonathanmaw: 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 |
jonathanmaw | it'd also be faster if I located the cached git repo and pulled from that, but again, complications. | 14:59 |
pedroalvarez | paulsherwood: note that paste.baserock.org data is not persistent | 15:01 |
jonathanmaw | paulsherwood, pedroalvarez: anything else I should be doing, and will pedroalvarez need this Jetson to prepare it for the hands-on? | 15:04 |
paulsherwood | pedroalvarez: thanks! | 15:09 |
paulsherwood | jonathanmaw: fix any of the issues in ybd? :) | 15:09 |
jonathanmaw | paulsherwood: no thanks | 15:10 |
paulsherwood | jonathanmaw: interesting response to your CEO :) | 15:10 |
pedroalvarez | hohoho | 15:12 |
* jonathanmaw remembered that there are various misc fixes to the GDP. | 15:20 | |
jonathanmaw | pedroalvarez: are you accepting patches to that branch, given it's already tagged? | 15:20 |
paulsherwood | jonathanmaw: we can accept patches. they could be usefully applied during the hands-on for example | 15:21 |
pedroalvarez | jonathanmaw: 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 :C | 15:34 | |
paulsherwood | jonathanmaw: can't they wait? | 15:34 |
jonathanmaw | paulsherwood: most of them can, not the AGL and GDP lifecycle ones, I imagine. | 15:36 |
paulsherwood | what is http://ciat.baserock.org:8010/waterfall actually doing at this point? it seems to have been rather quiet | 15:52 |
SotK | nothing since wednesday from the look of things :/ | 15:53 |
paulsherwood | that's quite an expensive way to run a statit website | 15:55 |
paulsherwood | static | 15:55 |
*** paulwaters_ has joined #baserock | 16:20 | |
*** ssam2 has quit IRC | 16:32 | |
*** bashrc has quit IRC | 16:57 | |
*** jonathanmaw has quit IRC | 16:58 | |
*** toscalix__ has joined #baserock | 17:00 | |
*** toscalix__ has quit IRC | 17:13 | |
*** paulwaters_ has quit IRC | 17:16 | |
*** edcragg has quit IRC | 17:20 | |
pedroalvarez | paulsherwood: I agree, we need to continue spending time on ciat | 17:39 |
pedroalvarez | first of all, automate the deployment | 17:40 |
pedroalvarez | then move it to somewhere cheaper, and start making in elastic | 17:45 |
* pedroalvarez heads off | 17:45 | |
*** paulwaters_ has joined #baserock | 17:57 | |
*** paulwaters_ has quit IRC | 18:11 | |
*** tiagogomes has quit IRC | 18:21 | |
*** paulwaters_ has joined #baserock | 19:01 | |
*** paulwaters_ has joined #baserock | 20:18 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!