| *** gtristan has quit IRC | 04:42 | |
| *** toscalix has joined #baserock | 05:25 | |
| *** gtristan has joined #baserock | 05:31 | |
| *** toscalix has quit IRC | 06:20 | |
| *** ctbruce has joined #baserock | 07:32 | |
| *** ChanServ has quit IRC | 09:14 | |
| *** SotK has quit IRC | 09:17 | |
| *** inara` has quit IRC | 09:17 | |
| *** rjek has quit IRC | 09:17 | |
| *** franred has quit IRC | 09:17 | |
| *** dabukalam has quit IRC | 09:17 | |
| *** benbrown_ has quit IRC | 09:17 | |
| *** cosm has quit IRC | 09:17 | |
| *** vgrade has quit IRC | 09:17 | |
| *** juergbi has quit IRC | 09:17 | |
| *** malinus has quit IRC | 09:17 | |
| *** perryl has quit IRC | 09:17 | |
| *** bfletcher has quit IRC | 09:18 | |
| *** ctbruce has quit IRC | 09:18 | |
| *** cyndis has quit IRC | 09:18 | |
| *** _longines has quit IRC | 09:18 | |
| *** persia has quit IRC | 09:18 | |
| *** JPohlman1 has quit IRC | 09:18 | |
| *** persia_ has quit IRC | 09:18 | |
| *** tiagogomes_ has quit IRC | 09:18 | |
| *** anahuelamo has quit IRC | 09:18 | |
| *** jmacs has quit IRC | 09:18 | |
| *** gtristan has quit IRC | 09:18 | |
| *** leeming has quit IRC | 09:18 | |
| *** paulsher1ood has quit IRC | 09:19 | |
| *** bjdooks has quit IRC | 09:19 | |
| *** gary_perkins has quit IRC | 09:19 | |
| *** tardyp has quit IRC | 09:19 | |
| *** radiofree has quit IRC | 09:19 | |
| *** jmacs has joined #baserock | 10:28 | |
| *** anahuelamo has joined #baserock | 10:28 | |
| *** paulsher1ood has joined #baserock | 10:28 | |
| *** leeming has joined #baserock | 10:28 | |
| *** inara has joined #baserock | 10:28 | |
| *** locallycompact has joined #baserock | 10:28 | |
| *** persia_ has joined #baserock | 10:28 | |
| *** radiofree has joined #baserock | 10:28 | |
| *** tardyp has joined #baserock | 10:28 | |
| *** bjdooks has joined #baserock | 10:28 | |
| *** gary_perkins has joined #baserock | 10:28 | |
| *** cyndis has joined #baserock | 10:28 | |
| *** _longines has joined #baserock | 10:28 | |
| *** persia has joined #baserock | 10:28 | |
| *** JPohlman1 has joined #baserock | 10:28 | |
| *** perryl has joined #baserock | 10:28 | |
| *** bfletcher has joined #baserock | 10:28 | |
| *** dabukalam has joined #baserock | 10:28 | |
| *** benbrown_ has joined #baserock | 10:28 | |
| *** cosm has joined #baserock | 10:28 | |
| *** vgrade has joined #baserock | 10:28 | |
| *** juergbi has joined #baserock | 10:28 | |
| *** malinus has joined #baserock | 10:28 | |
| *** rjek has joined #baserock | 10:28 | |
| *** SotK has joined #baserock | 10:28 | |
| *** franred has joined #baserock | 10:28 | |
| *** ctbruce has joined #baserock | 10:28 | |
| *** tiagogomes has joined #baserock | 10:28 | |
| *** ChanServ has joined #baserock | 10:30 | |
| *** niven.freenode.net sets mode: +o ChanServ | 10:30 | |
| tiagogomes | ybd is unusable on my system unless I do some hackery. Because it requires running as root, it working directory will be /root/ybd, and the partition where '/' is doesn't have much allocated space comparing with /home. | 10:31 |
|---|---|---|
| tiagogomes | Is there a way to set the working dir? Maybe setting XDG_CACHE_HOME | 10:32 |
| pedroalvarez | tiagogomes: I believe that in the readme is explained how to change that | 10:35 |
| leeming | ^ for direct help. make a file "ybd.conf" with the following fields | 10:36 |
| leeming | artifacts, tmp, ccache_dir, gits, jobs (all yaml format) | 10:37 |
| leeming | pointing to the associated directories in your home dir | 10:37 |
| leeming | tiagogomes, ^^ | 10:37 |
| tiagogomes | leeming thanks | 10:39 |
| leeming | but once i get this very messy rebase working, ybd may not require root | 10:41 |
| tiagogomes | how are you handling extracting artifacts the contain device nodes? | 10:42 |
| leeming | depends on what you mean by extract? | 10:45 |
| leeming | it should be doing whatever ybd usually does, which is directory based i believe | 10:45 |
| leeming | $SANDBOX/dev , is mounted in bwrap as a special device mount | 10:45 |
| tiagogomes | The fhs-dirs artifact is a gzip archive that contains devices nodes. To extract this archive, you need root privileges. | 10:49 |
| tiagogomes | So or you get rid of the device nodes on that artifact, or you have a small wrapper executable with the setuid bit set that is called by ybd and does the extraction. | 10:50 |
| leeming | would ybd successfully build if it couldnt extract it? | 10:50 |
| tiagogomes | With current master, it would fail. | 10:51 |
| leeming | then it does something I do not understand, as it works | 10:52 |
| tiagogomes | Perhaps coz you are running it as root or there isn't a prebuilt artifact for fhs-dirs in the cache. | 10:54 |
| *** gtristan has joined #baserock | 11:00 | |
| leeming | hmm, i will nuke all the caches and try it again then.. and i wasn't running as root | 11:03 |
| jjardon | locallycompact: paulsher1ood ok to merge this? https://gitlab.com/baserock/ybd/merge_requests/249 | 11:19 |
| paulsher1ood | jjardon: yup, i've clicked the button | 11:23 |
| jjardon | cheers | 11:23 |
| paulsher1ood | would folks consider s/assemblage/stack/ ? | 11:46 |
| paulsher1ood | locallycompact: ^^ | 11:46 |
| locallycompact | Not for my purposes but you're free to do so for the current model. | 11:49 |
| locallycompact | It actually might make a lot of sense | 11:49 |
| paulsher1ood | i'm just thinking of an easy/memorable name, not too overloaded. it could still stand for everything you want assemblage to be | 11:50 |
| gtristan | While I personally find the abbreviation of assemblage more amusing than troublesome, I also find the word to be a bit complicated to digest. I'd also love to take the opportunity to kill off the words "strata"/"stratum" | 11:51 |
| locallycompact | I still like stratum ontologically | 11:52 |
| locallycompact | Although, one could get away with substack | 11:52 |
| gtristan | since I think with V10 a stratum only denotes an assemblage that is a part of another assemblage (from the mail), instead of what it actually is, right ? | 11:52 |
| locallycompact | it's an important logical note that resides in something "as something", and doesn't simply exist | 11:53 |
| locallycompact | s/that/that it/ | 11:55 |
| * paulsher1ood proposes 'stack'ain | 11:55 | |
| paulsher1ood | again | 11:55 |
| jmacs | Stack implies an ordering; there are things at the bottom and top; is that the intention? | 11:55 |
| paulsher1ood | not my intention, no | 11:56 |
| jmacs | Assemblage doesn't have that meaning, to me | 11:56 |
| gtristan | I understand it as a layer within a system (the system which is more of a stack), unfortunately, they already took the word layer | 11:57 |
| paulsher1ood | tier. but i think it's not correct anyway because assemblage can be a set of layers | 11:58 |
| paulsher1ood | s/layers/whatevers/ | 11:58 |
| locallycompact | jmacs, it is however how things are arranged currently, there are things at the bottom and things at the top, because we denote build-depends by name and they form a strict partial ordering | 11:58 |
| paulsher1ood | deck | 11:58 |
| paulsher1ood | (as in a deck of cards) | 11:58 |
| locallycompact | what I want for assemblages is to infer build-depends by capacity, which would deduce into a stack | 11:58 |
| leeming | are we discussing renaming assemblages? | 11:59 |
| leeming | to use a generic overloaded word? | 12:00 |
| locallycompact | I'm not 'renaming' assemblages because assemblages are totes not finished | 12:00 |
| locallycompact | but I do think how it appears in V10 as stack-like | 12:01 |
| locallycompact | s/as/is | 12:01 |
| * paulsher1ood is proposing to call the thing locallycompact is callig 'assemblages' to 'stack', before the name sticks | 12:01 | |
| gtristan | I think that we need to really understand what the big picture is, otherwise when we hit V15 and assemblages mean something else, we'll want to rename it again :-/ | 12:02 |
| paulsher1ood | i don't think that's true | 12:02 |
| paulsher1ood | but then, i think i understand the big picture to some extent | 12:03 |
| locallycompact | assemblages "really mean" what they mean in assemblage theory | 12:03 |
| jjardon | paulsher1ood: ok to merge https://gitlab.com/baserock/ybd/merge_requests/250 ? | 12:03 |
| locallycompact | if it diverges from that I would call it something else | 12:03 |
| tiagogomes | I agree with gtristan. A roadmap would be nice | 12:03 |
| gtristan | I'm not clear on the concrete plan on how one will infer build depends by capacity, I'm not sure how "this layer provides the capacity to be a display server" for instance will be useful concretely | 12:04 |
| tiagogomes | Otherwise the ideas suggested in he mailing list will become a bit forgotten | 12:04 |
| paulsher1ood | tiagogomes: what precisely would you like to see in a roadmap? | 12:05 |
| paulsher1ood | (and same question to others) | 12:05 |
| locallycompact | roadmap: fix the ontology | 12:06 |
| jjardon | radiofree: https://gitlab.com/baserock/ybd/merge_requests/250 | 12:07 |
| tiagogomes | A list of work items that will lead to a future shape of definitions that addresses the major problems with the current definitions. | 12:07 |
| gtristan | A description of how dependencies will be resolved, once the assemblages idea comes to full fruition. Otherwise: V10 features stand on their own, we name them in the way we feel makes sense with the present V10 features, and anything else is left to future schemes | 12:07 |
| locallycompact | also have something that allows to visualize the ontology with big descriptions of everything in a web view that makes no reference to syntax | 12:08 |
| locallycompact | like this but better http://vowl.visualdataweb.org/webvowl/ | 12:09 |
| jmacs | <bikeshedding> Force directed layouts are rubbish </bikeshedding> | 12:10 |
| gtristan | On topic (I think): some of us agree we need a simple set of words to describe the (hopefully *few*) data types which definitions describe, in the interest of being user friendly. Personally I think accuracy of the word is of less importance than simplicity and recognizability. | 12:16 |
| locallycompact | dog | 12:16 |
| gtristan | Analogies are also great. Dog *could* make sense if definitions were Zoo and YBD was ZooKeeper (although probably not Dog, perhaps Cage, where Chunk would be Animal) | 12:17 |
| gtristan | although the Zoo theme doesnt seem to be a great fit. | 12:18 |
| radiofree | paulsher1ood: any chance you could approve this https://gitlab.com/baserock/ybd/merge_requests/251 | 12:19 |
| radiofree | (have tested it) | 12:19 |
| locallycompact | technical definitions please, metaphors can happen in the future after we are not confused | 12:19 |
| gtristan | I dont feel "stack" to be the best choice, but I would place my vote on "stack", since we do have say... a graphics stack and possibly other stacks which make up a final OS | 12:20 |
| gtristan | I would place my vote on stack in the absence of anything better - and I would hate to rename things in the future, thats a compatibility issue | 12:21 |
| gtristan | we cant be on a mission to constantly be changing the format :-S | 12:21 |
| locallycompact | I'm happy with stack so long as it only ever means a strict partial order | 12:23 |
| gtristan | In absence of a clear roadmap of where this is going, I dont think we can guarantee that it will always mean what you want it to. Instead: V10 brings new features which solve real problems | 12:27 |
| gtristan | And I think that's the right way to proceed, introducing one change at a time and giving pause before the next. | 12:28 |
| *** edcragg_ has joined #baserock | 12:29 | |
| locallycompact | I want to make assemblages the testbed for capactive dependencies. In that light the cache key logic for assemblages can always be framed as deducing a stack from an assemblage. | 12:29 |
| locallycompact | f: Assemblage -> Stack | 12:29 |
| locallycompact | and I want the mechanism for assemblage capacities to be coeffects | 12:30 |
| locallycompact | for that to work stacks can only ever be strict partial orders | 12:30 |
| pedroalvarez | stack reminds me to the "full stack" engineers job offers | 12:33 |
| * SotK looks forward to "add the openstack stack" | 12:35 | |
| gtristan | What worries me is this: Definitions can not be a testbed for anything, what we have works to accomplish a given task, we can improve on it; and testbed outside of it. | 12:37 |
| paulsher1ood | no-one likes deck over stack? | 12:37 |
| locallycompact | definitely not | 12:37 |
| pedroalvarez | I actually don't dislike it | 12:37 |
| pedroalvarez | (stack) | 12:38 |
| pedroalvarez | for me deck doesn't say much | 12:38 |
| *** CTtpollard has quit IRC | 12:39 | |
| gtristan | What describes a group of components with some tight relationship to eachother: Thats what the thing is I think. Its a convenient grouping of components which allows one to disregard to some extent it's internal details. | 12:39 |
| *** CTtpollard has joined #baserock | 12:39 | |
| SotK | gtristan: "group" :) | 12:40 |
| * SotK runs away | 12:40 | |
| gtristan | so what describes that, a stack sort of makes sense because it's software. a group is too ultimately generic, right | 12:40 |
| paulsher1ood | 'deck doesn't say much' may be considered an advantage : | 12:40 |
| * locallycompact wonders if anybody has ever actually googled 'group' and read the definition of a group | 12:41 | |
| * paulsher1ood has | 12:41 | |
| pedroalvarez | notes make chords, and then you can make songs | 12:41 |
| pedroalvarez | and the build tool is the band! | 12:42 |
| pedroalvarez | base rock & roll | 12:42 |
| SotK | pedroalvarez: :D | 12:42 |
| pedroalvarez | (random idea, maybe can be elaborated by someone) | 12:42 |
| gtristan | pedroalvarez, that is already awesome | 12:43 |
| * SotK knows what a group is also, but I don't see why we have to abide by the mathematical definition of a word here | 12:43 | |
| locallycompact | because it's ubiquitous in every field of science, that's wy | 12:43 |
| paulsher1ood | pedroalvarez: lol | 12:43 |
| SotK | when I hear group I first think of the layman definition, i.e. "look at that group of people" | 12:44 |
| gtristan | I do prefer analogies naming, but nobody cares about strata and morphologies, that was a weird choice | 12:44 |
| * SotK likes the geology metaphors, but knows he is alone :( | 12:45 | |
| locallycompact | The actual "thing" that this is a series-parallel partial order, it's what I modelled V10 on | 12:45 |
| gtristan | We have: chunk | strata | system | cluster... system is the best name we have, cluster implies that as a superset of systems one might be deploying a cluster of systems, perhaps a render farm | 12:49 |
| gtristan | chunk is.. alright.. strata well.. I dont know | 12:50 |
| gtristan | subsystem ? | 12:50 |
| pedroalvarez | "system" has a lot of meanings too | 12:50 |
| gtristan | To be completely boring and bland ? | 12:50 |
| SotK | subsystem is already a part of clusters | 12:51 |
| gtristan | right | 12:51 |
| * gtristan facerock | 12:51 | |
| gtristan | I think we should just make pedroalvarez name everything | 12:52 |
| gtristan | He has the best imagination so far | 12:52 |
| * SotK agrees | 12:52 | |
| pedroalvarez | we might get away by just creating random names | 12:52 |
| gtristan | and the result will be better than everyone having a say :) | 12:52 |
| *** ChrisPolin has joined #baserock | 13:03 | |
| tiagogomes | tbh, I would just leave the names as they are. | 13:14 |
| pedroalvarez | I was thinking that I like the word "tree" | 13:15 |
| pedroalvarez | to define what a system currently is | 13:15 |
| tiagogomes | ostree is taken | 13:16 |
| pedroalvarez | i said just tree | 13:17 |
| paulsher1ood | we'd confuse this with git trees, i fear | 13:18 |
| locallycompact | And also it isn't a tree, trees only capture one relationship, this has two - containment and dependency | 13:18 |
| pedroalvarez | roots and fruits | 13:19 |
| SotK | maybe we should extend the geology metaphor and call them "formations" | 13:19 |
| leeming | fruit n nuts? | 13:20 |
| pedroalvarez | locallycompact: anyway, true. I just meant what a built system is. A tree. | 13:20 |
| leeming | a hedge.. that is a flat tree right? | 13:21 |
| jjardon | paulsher1ood: can we have this in? https://gitlab.com/baserock/ybd/merge_requests/247 | 13:27 |
| pedroalvarez | jjardon: quick question to understand gitlab better | 13:29 |
| pedroalvarez | in the discussion tab of that MR, there are like 4 different blocks | 13:30 |
| pedroalvarez | are they different versions of the MR? | 13:30 |
| jjardon | pedroalvarez: yes | 13:34 |
| * SotK wonders if there is a way to see a diff between versions that he can't find | 13:35 | |
| jjardon | you can compare differences between versions here: https://gitlab.com/baserock/ybd/merge_requests/247/diffs similar as you can in gerrit | 13:35 |
| SotK | jjardon: lovely, thanks | 13:36 |
| pedroalvarez | not bad | 13:37 |
| * tiagogomes finds that gitlab UI is pleasant to use | 13:38 | |
| pedroalvarez | bit annoying that the diff between versions include all the commits | 13:40 |
| SotK | hmm, those diffs don't seem right actually | 13:40 |
| SotK | I see the same basic changes in all the options | 13:41 |
| tiagogomes | maybe the new versions were just a rebase on master? | 13:42 |
| SotK | (eg I see the change in app.py in the diff between v4 and v3, and also in the diff between v3 and v2) | 13:42 |
| leeming | gitlabs UI is a little minimal at times | 13:50 |
| * SotK notices the diff content wraps if the columns are too narrow in side-by-side mode :( | 13:52 | |
| *** gtristan has quit IRC | 14:05 | |
| *** gtristan has joined #baserock | 14:11 | |
| *** franred has quit IRC | 14:14 | |
| *** franred has joined #baserock | 14:27 | |
| radiofree | hi, i'm getting an error building (and occasionally cloning) ansible | 14:48 |
| radiofree | https://gitlab.com/jamesthomas/definitions/builds/5079847 | 14:48 |
| radiofree | first time round cloning the repo seemed to fial | 14:49 |
| radiofree | s/fial/fail/ | 14:49 |
| radiofree | /sbin/ldconfig.real: /usr/lib/libbz2.so.1.0 is not a symbolic link | 14:50 |
| pedroalvarez | radiofree: jjardon hit the same problem this week | 14:50 |
| pedroalvarez | radiofree: are these problesm in gitlab CI or also locally? | 14:51 |
| radiofree | well, it's running locally on a machine here | 14:51 |
| radiofree | via gitlab | 14:51 |
| radiofree | in a docker container if that makes a difference? | 14:53 |
| jjardon | pedroalvarez: the strange thing is that is always the ansible repo the one that fails to build | 14:53 |
| pedroalvarez | can you giveme a timestamp of a recent clone failure? | 14:55 |
| radiofree | ~22minutes ago | 14:57 |
| radiofree | https://gitlab.com/jamesthomas/definitions/builds/5078783 | 14:57 |
| radiofree | can't be more exact sorry | 14:57 |
| pedroalvarez | let'ssee if I can see something weird in g.b.o. | 14:57 |
| radiofree | ta | 14:58 |
| pedroalvarez | radiofree: I can't see anything related | 15:06 |
| pedroalvarez | either network problems, either the build tool | 15:06 |
| locallycompact | can we bring gcc 5.4 into gcc-tarball? | 15:15 |
| pedroalvarez | not 6? | 15:17 |
| locallycompact | I thought there are problems with 6 | 15:17 |
| pedroalvarez | there are, but all problems can be fixed? :P | 15:17 |
| locallycompact | I am hitting this bug bootstrapping from 6 on arch into 5.3 in baserock https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959 | 15:18 |
| pedroalvarez | locallycompact: send a patch to the lorry file to upgrade | 15:18 |
| SotK | speaking of lorries, can we upgrade g.b.o to understand yaml lorries soon? :) | 15:19 |
| pedroalvarez | why are you looking at me? | 15:19 |
| * SotK is happy to do it, but doesn't know if he has the permissions to do so, or if there is some process around upgrading the infra these days | 15:20 | |
| pedroalvarez | SotK: is it just an upgrade to lorry? or also to lorry controller? | 15:21 |
| SotK | lorry and lorry-controller | 15:21 |
| pedroalvarez | right.. then I think I could try to upgrade cache.baserock.org. test that it works in there, and then upgrade g.b.o. | 15:22 |
| SotK | that seems sensible, sorry for creating work | 15:36 |
| leeming | long overdue (sorry) but here is an implementation of bwrap in sandboxlib -> https://github.com/CodethinkLabs/sandboxlib/pull/25 | 15:39 |
| tiagogomes | no gitlab PR instead? | 15:43 |
| pedroalvarez | hm... pbr fails to build? | 15:44 |
| pedroalvarez | :) nope, g.b.o can't be upgraded | 15:47 |
| SotK | :( | 15:48 |
| SotK | whats up with pbr? | 15:49 |
| pedroalvarez | python3-core pbr | 15:49 |
| pedroalvarez | may be trivial to fix, http://paste.baserock.org/qitesomati | 15:51 |
| SotK | it worked at the weekend when I built a trove | 15:52 |
| SotK | I wonder if the python3 update broke it | 15:52 |
| * SotK will look later | 15:52 | |
| SotK | though that would be a weird way for it to break... | 15:54 |
| paulsher1ood | jjardon: do you think dropping python2 is acceptable? will any users be affected by this ? | 15:55 |
| pedroalvarez | SotK: upgraded to latest, and it works | 15:56 |
| jjardon | paulsher1ood: yes, I think so | 15:56 |
| pedroalvarez | SotK: maybe a built-in library is not included anymore? | 15:56 |
| SotK | perhaps | 15:56 |
| * paulsher1ood would prefer that ybd continues to be runnable with python2... but assumes this is too much to hope for | 16:01 | |
| pedroalvarez | how do I trigger gitlab ci? by sending a MR? | 16:05 |
| pedroalvarez | how do I do that also? | 16:05 |
| pedroalvarez | oh, just found the fork button | 16:05 |
| *** franred has quit IRC | 16:10 | |
| *** CTtpollard has quit IRC | 16:14 | |
| paulsher1ood | :) | 16:15 |
| *** ctbruce has quit IRC | 16:20 | |
| pedroalvarez | everything fails: https://gitlab.com/baserock/definitions/merge_requests/1/builds | 16:22 |
| pedroalvarez | :/ | 16:22 |
| tiagogomes | At least they are consistently failing | 16:23 |
| jjardon_matrix | pedroalvarez fork from current master | 16:24 |
| pedroalvarez | hm.. gitlab's or g.b.o ? | 16:26 |
| pedroalvarez | (not sure if gitlabs carries something) | 16:26 |
| jjardon_matrix | Gitlab is a mirror | 16:26 |
| jjardon_matrix | Exactly the same on both | 16:27 |
| jjardon_matrix | So simply rebase your branch and force push it | 16:27 |
| pedroalvarez | great, no need to MR to trigger ci | 16:30 |
| pedroalvarez | nicer than github+travis | 16:31 |
| pedroalvarez | not sure if it's my network, but gitlab is slow to navigate | 16:33 |
| leeming | no, you just need a .gitlab-ci file or somethjing | 16:33 |
| leeming | gitlab is slow | 16:33 |
| paulsher1ood | we're working on that, i believe | 16:34 |
| pedroalvarez | to improve the speed of the web ui? | 16:34 |
| tiagogomes | yes, my main complain about gitlab so far | 16:34 |
| paulsher1ood | oh, if you mean the webui, we'd need to self host | 16:35 |
| leeming | their web ui can be slow at times, as well as the unknown wait queue for runners | 16:35 |
| * paulsher1ood thought you meant runners | 16:35 | |
| jmacs | I've also found gitlab's site rather slow, on a different project | 16:36 |
| * SotK has always found it slow also | 16:36 | |
| tiagogomes | "We'll be deploying GitLab 8.13.0-rc2 shortly". rc? | 17:06 |
| edcragg_ | rc2 at that | 17:10 |
| *** tiagogomes has quit IRC | 17:16 | |
| *** gtristan has quit IRC | 20:37 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!