| *** zoli__ has joined #baserock | 04:52 | |
| *** zoli__ has quit IRC | 06:26 | |
| *** zoli__ has joined #baserock | 06:45 | |
| *** zoli__ has quit IRC | 06:55 | |
| *** mariaderidder has joined #baserock | 07:56 | |
| *** zoli__ has joined #baserock | 08:07 | |
| *** zoli__ has quit IRC | 08:08 | |
| *** bashrc has joined #baserock | 08:15 | |
| *** bashrc has quit IRC | 08:18 | |
| *** bashrc has joined #baserock | 08:18 | |
| *** jonathanmaw has joined #baserock | 08:45 | |
| *** ssam2 has joined #baserock | 08:48 | |
| *** ChanServ sets mode: +v ssam2 | 08:48 | |
| ssam2 | hello | 08:55 |
|---|---|---|
| ssam2 | https://gerrit.baserock.org/#/c/896/ fixes a pretty annoying bug in `morph show-build-log`, could anyone give it a quick review? | 08:55 |
| * SotK will take a look | 08:56 | |
| ssam2 | thanks! | 08:56 |
| * franred too | 08:57 | |
| *** edcragg has joined #baserock | 08:59 | |
| SotK | Using setuptools, does anyone know if there is a way to set the commandline options of the egg_info command which is run automatically when you do `python setup.py install`? | 09:00 |
| SotK | (without using setup.cfg) | 09:01 |
| ssam2 | wow, I have no idea | 09:01 |
| ssam2 | YBD seems to break every time I leave it overnight ... | 09:04 |
| ssam2 | this is the log output (it's quite long): http://paste.baserock.org/sadaforati | 09:05 |
| *** gary_perkins has joined #baserock | 09:05 | |
| ssam2 | I'm suspicious about the : 'tar: can't make dir ./usr/lib/terminfo/1: No such file or directory' errors | 09:06 |
| ssam2 | especially as they seem to be mixed in with the log output from the post-install commands | 09:06 |
| *** zoli__ has joined #baserock | 09:13 | |
| Kinnison | Possibly ran out of disk? | 09:15 |
| jmacs | Looks like there's a file (non-directory) called /usr/lib/terminfo | 09:17 |
| *** lachlanmackenzie has joined #baserock | 09:19 | |
| ssam2 | disks space is fine | 09:19 |
| ssam2 | -s | 09:19 |
| ssam2 | i'll investigate /usr/lib/terminfo, that might be it | 09:19 |
| ssam2 | hmm, I can see the same thing happened again with ncurses earlier on | 09:21 |
| ssam2 | so I guess it is that artifact. I'm confused how it managed a successful build, inbetween. | 09:22 |
| ssam2 | but then, YBD randomises build order | 09:22 |
| * ssam2 puts this info in https://github.com/devcurmudgeon/ybd/issues/86 | 09:23 | |
| ssam2 | lrwxrwxrwx 1 root root 17 Jun 19 09:31 /tmp/artifacttest/usr/lib/terminfo -> ../share/terminfo | 09:33 |
| ssam2 | so you were close, jmac.. it's actually a broken symlink | 09:34 |
| ssam2 | I guess I introduced this bug by sorting the order that the files are added to the .tar file! that seems a bit crazy, though | 09:35 |
| ssam2 | seems wrong that `tar x` depends on the ordering of Python's os.listdir() in order to function.. I must be missing something | 09:36 |
| *** zoli__ has quit IRC | 09:40 | |
| * ssam2 tries to figure out whether http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/builder.py#n432 is a solution to this problem | 09:42 | |
| SotK | so, babel hasn't seen a new commit in a year, and we already carry a patch against it, so I guess I'll just patch its setup.cfg to not put the date in the version since I can't figure out how to do taht on the command line | 09:42 |
| paulsher1ood | ssam2: ironic that make_deterministic_gztar_archive was makign things non-deterministic :-) | 10:34 |
| ssam2 | it was making things deterministic, just deterministically broken | 10:34 |
| paulsher1ood | lol | 10:35 |
| paulsher1ood | SotK: offer the patch upstream? | 10:35 |
| franred | paulsher1ood, looks like upstream is also not active - the repository of babel is managed by one unresponsive guy | 10:38 |
| paulsher1ood | franred: fair enough, so long as we document that we've offered the patch | 10:38 |
| franred | sounds sensible | 10:39 |
| paulsher1ood | http://54.82.85.58:8080/pipelines/demo-ybd/jobs/build/builds/6 | 10:40 |
| franred | paulsher1ood, which system are you building? | 10:45 |
| paulsher1ood | build-system-x86_64 i believe | 10:46 |
| paulsher1ood | technically it's not me... it's concourse, running on a machine setup by drnic at stark and wayne | 10:47 |
| paulsher1ood | i wonder if it's picked up the make_deterministic_gztar_archive fix :) | 10:48 |
| paulsher1ood | concourse does not support caching yet, hence it's puling in all the repos per run. which would get expensive if this were being done lots of times. | 10:49 |
| paulsher1ood | and it's slow, of course | 10:50 |
| * ssam2 is slightly worried about getting this guy involved https://imgur.com/gallery/qrupWrK | 10:50 | |
| paulsher1ood | :) | 10:51 |
| franred | hehe | 10:51 |
| jjardon | paulsher1ood: thats cool | 10:53 |
| paulsher1ood | jjardon: the coolest thing is that drnic set it up in less than a day, wallclock time. and i'm pretty sure he was working on other stuff at the time :) | 10:54 |
| paulsher1ood | we need tofigure out the caching of artifacts and repos, but still... it has potential :) | 10:55 |
| ssam2 | i deleted the broken ncurses artifact from my artifact cache, but instead of rebuilding it, YBD is exiting with 'cache artifact not found' | 10:59 |
| ssam2 | any idea why it doesn't rebuild it? | 10:59 |
| paulsher1ood | ssam2: because things that required it already exist, so the recursionbuild logic doesn't spot the omission | 11:01 |
| ssam2 | ah, I see | 11:01 |
| paulsher1ood | https://github.com/devcurmudgeon/ybd/issues/15 | 11:01 |
| paulsher1ood | it would be nice to fix it, but not at the expense of lots of code and complexity | 11:02 |
| paulsher1ood | ssam2: fix is to run ybd.py ncurses | 11:02 |
| paulsher1ood | s/fix/workaround/ | 11:03 |
| ssam2 | ah, I didn't think of that | 11:03 |
| paulsher1ood | neither did i, until a month or so after issues/15 :) | 11:03 |
| paulsher1ood | ouch, build 6 failed. | 11:04 |
| persia | ssam2: I missed you yesterday, but on the .pyc issue: it appears that PEP 3147 covers similar ground. PEP 304 also did, but this was withdrawn. If you don't find someone by general request on #python, you might try contacting one of the PEP 3147 or PEP 304 authors. | 11:05 |
| ssam2 | looks useful, thanks! | 11:06 |
| ssam2 | SoTK: would you mind sending a patch against master to do http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?id=554f6b401b5b34efc9d1f932992e2f8f4db45c31 ? | 11:20 |
| ssam2 | (the HOSTNAME part of it) | 11:20 |
| SotK | ssam2: sure | 11:40 |
| SotK | ssam2: https://gerrit.baserock.org/901 | 11:48 |
| paulsher1ood | SotK: is ybd deployment now working? i haven't touched that part of the readme in a while | 11:49 |
| SotK | paulsher1ood: it was when I last tried it | 11:50 |
| paulsher1ood | SotK: would you mind sending a patch for the readme? | 11:50 |
| SotK | paulsher1ood: Which part? It still can't choose which systems in a cluster to deploy, change deployment parameters or deploy other architecture stuff as far as I am aware :) | 11:52 |
| paulsher1ood | SotK: if the readme represents the truth, then great. is it still 'a mess' ? | 11:53 |
| SotK | that depends by what the definition of mess is | 11:55 |
| SotK | its tidier than it was | 11:55 |
| paulsher1ood | :) | 11:56 |
| paulsher1ood | for master definitions, can deployment now be done without morph present? | 11:58 |
| SotK | paulsher1ood: not yet, the patch to remove the morphlib dependency is still in need of review on the ML | 11:58 |
| paulsher1ood | ah, i thought that was inherent in the release you did | 11:59 |
| * paulsher1ood goes to gerrit | 11:59 | |
| SotK | paulsher1ood: the patch is on baserock-dev rather than gerrit, since it contains merge commits | 12:00 |
| * SotK apologises if paulsher1ood was going to gerrit for unrelated reasons :) | 12:00 | |
| ssam2 | Sotk: it has +1 from me | 12:01 |
| paulsher1ood | SotK: i can't find the patch - when did you send it? | 12:03 |
| SotK | paulsher1ood: http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-June/013101.html | 12:03 |
| paulsher1ood | SotK: and you did test it in the meantime? | 12:05 |
| SotK | paulsher1ood: mostly, I don't remember testing virtualbox-ssh with it | 12:06 |
| jmacs | Morph seems to have some issues running under the version of bash in definitions. | 12:08 |
| paulsher1ood | really? | 12:08 |
| paulsher1ood | is this recent/new, jmacs ? | 12:09 |
| SotK | jmacs: what are the issues? | 12:09 |
| jmacs | Probably not | 12:09 |
| jmacs | Just wondered if people knew about any issues - I'll report back when I have some more concrete evidence | 12:09 |
| paulsher1ood | SotK: +1 | 12:10 |
| paulsher1ood | jmacs: ok, thanks | 12:10 |
| SotK | paulsher1ood: great, thanks! | 12:10 |
| * SotK will merge it in a couple of hours unless there are complaints in the mean time | 12:11 | |
| SotK | Kinnison in particular may be interested | 12:11 |
| Kinnison | I may whatnow? | 12:30 |
| Kinnison | Your explanation sounds plausible, I will not block :) | 12:30 |
| SotK | Kinnison: thanks :) | 12:31 |
| jmacs | That error with morph upgrade inside bash: http://paste.baserock.org/vutemebewo | 13:08 |
| jmacs | If anyone else is doing a morph upgrade today, could they try it inside bash? | 13:09 |
| jmacs | Could well be environment variables | 13:09 |
| * paulsher1ood wonders if this also affects ybd | 13:10 | |
| SotK | paulsher1ood: it probably does, the code which caused the error is also in ybd | 13:11 |
| SotK | jmacs: does it work if you use busybox? | 13:12 |
| jmacs | /bin/sh is busybox | 13:13 |
| jmacs | That's the default shell, and what I'm using for the first upgrade in that paste | 13:13 |
| SotK | aha, I didn't notice there were two commands :3 | 13:14 |
| *** sambishop has quit IRC | 13:21 | |
| *** sambishop has joined #baserock | 13:35 | |
| ssam2 | jmacs: the reason is it is failing to parse $PS1 | 13:47 |
| ssam2 | jmacs: i've seen this before, it's a stupid bug | 13:47 |
| jmacs | Aah, I did have a custom PS1 in .bashrc | 13:50 |
| SotK | I intend to merge the stuff from http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-June/013101.html in about 10 minutes if there are no objections | 15:07 |
| SotK | OK, I guess I need to push the merge to master of Gerrit rather than g.b.o as last time | 15:27 |
| SotK | can anyone give me the correct permissions to do so (or have them and be willing to merge http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/adamcoldrick/remove-dependencies-v2)? | 15:28 |
| paulsher1ood | ssam2: ^^ | 15:29 |
| paulsher1ood | ? | 15:29 |
| ssam2 | SotK: I think anyone in Mergers group can do that. have you tried? | 15:31 |
| SotK | ssam2: it didn't work when I was pushing the branch which moved the exts into definitions, pedroalvarez had to give me some permission iirc | 15:32 |
| * SotK will try though | 15:32 | |
| ssam2 | i had a look at building HAProxy in Baserock | 15:35 |
| ssam2 | seems that haproxy.git only has the development versions, haproxy-1.5.git has the last stable version | 15:35 |
| ssam2 | should I send a patch to lorry haproxy-1.5.git? It seems less than ideal | 15:35 |
| ssam2 | eventually we'll have 1.6, 1.7, ... | 15:35 |
| ssam2 | the alternative is lorry both repos into our haproxy.git... but that doesn't sound very good either | 15:35 |
| SotK | ssam2: http://paste.baserock.org/pigogubudu is the outcome | 15:36 |
| ssam2 | interesting, OK | 15:37 |
| ssam2 | as a workaround you can push to git.baserock.org and it'll be mirrored, the mirroring is still active. | 15:37 |
| ssam2 | but I don't think I intended that to happen in the Gerrit config | 15:37 |
| SotK | ok then | 15:37 |
| ssam2 | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/infrastructure.git/tree/baserock_gerrit/All-Projects/project.config | 15:38 |
| SotK | there was a worry about pushing to g.b.o last time because of some issue with the mirroring breaking I think though? | 15:38 |
| ssam2 | the problem is that there's a 2 minute window where a merge conflict can occur | 15:38 |
| ssam2 | so it's not ideal | 15:38 |
| ssam2 | I think the 'exclusiveGroupPermissions = push' line for refs/heads/master might have broken this | 15:38 |
| ssam2 | it explicitly says anyone in Mergers group can 'Push' to refs/heads/* | 15:39 |
| ssam2 | but Gerrit lets you negate things later on, so it's quite hard to understand the whole ruleset | 15:39 |
| SotK | ok then, I'll push to g.b.o and hope no-one presses merge on anything for a couple of minutes :) | 15:39 |
| SotK | done | 15:40 |
| * ssam2 decides HAproxy-in-Baserock is too ambitious for this time on a Friday anyway | 15:40 | |
| paulsher1ood | :) | 15:41 |
| *** CTtpollard has quit IRC | 15:54 | |
| perryl | paulsher1ood: i've sent a pull request for my automated build/diff check script | 15:55 |
| * perryl vows to write it in python next time :) | 15:55 | |
| rjek | INTERCAL. | 15:56 |
| paulsher1ood | perryl: :) | 15:58 |
| *** franred has quit IRC | 16:05 | |
| tiagogomes | meh, there are three projects named snappy, a compressor/decompressor, a video player and Ubuntu's snappy | 16:06 |
| Kinnison | It's okay, the last one isn't very | 16:07 |
| Kinnison | (snappy that is) | 16:07 |
| tiagogomes | hehe | 16:07 |
| jmacs | I think there are about 100 software projects called Rosetta | 16:07 |
| Kinnison | And very few of them are interoperable | 16:07 |
| persia | Let's avoid making fun of other projects. Remember, this channel is logged, and the logs are gaining google-fu | 16:25 |
| paulsher1ood | does anyone have any opinions about me proposing that we lorry ybd ? | 16:26 |
| paulsher1ood | as upstream, i confirm that if ybd starts being lorried, there will be no further push -f incidents (on my watch) | 16:27 |
| ssam2 | with the goal of adding it to the 'build' systems ? | 16:27 |
| paulsher1ood | ssam2: that's one possibility - i hadn't got that far, tbh | 16:28 |
| paulsher1ood | if folks would like to add it i'd be very happy :) | 16:28 |
| ssam2 | ok. I'm not sure what the point of us lorrying it would be otherwise. but it's small so I'm not against lorrying it now | 16:28 |
| paulsher1ood | well, i'm expecting to start explaining to folks how to use ybd to build baserock systems soonish... it would seem strange if it wasn't on g.b.o | 16:29 |
| persia | Given how core the functionality in ybd is to Baserock, I wonder if we ought just fork it, rather than lorrying it. | 16:29 |
| persia | If the current maintainers are willing, I suspect we can grant them appropriate permissions in our gerrit. | 16:30 |
| paulsher1ood | if we were adding it to build-systems, there'd be a need for a setup.py for example | 16:30 |
| * persia would rather have two build systems in Baserock than to have an external build system being lorried | 16:30 | |
| ssam2 | it would be weird to me if ybd became a core part of Baserock to have it maintained with Github's tools instead of ours | 16:31 |
| paulsher1ood | interesting point, but this needs more clarification | 16:31 |
| paulsher1ood | so first i'm gonna stick with build-system => autotools, cmake etc | 16:31 |
| paulsher1ood | morph and ybd are both integration tools imo | 16:32 |
| paulsher1ood | ssam2: re your point... how do you define 'core part of baserock' ? | 16:32 |
| persia | Then I want two *integration tools* in Baserock, rather than anyone recommending using some random github software as a means to build Baserock systems. | 16:32 |
| ssam2 | paulsher1ood: something where we'd be screwed without it | 16:33 |
| paulsher1ood | ssam2: great definition :) | 16:33 |
| paulsher1ood | ok, so my problem with gerrit is the friction. i wouldn't want to limit adoption of ybd by hiding it on gbo with changes via gerrit | 16:34 |
| paulsher1ood | persia: any ideas how to deal with that? | 16:34 |
| persia | What friction? | 16:35 |
| persia | Someone reviews, someone else reviews and presses the merge button. | 16:35 |
| paulsher1ood | in practice it seems harder than that | 16:35 |
| persia | I'm not comfortable with a tool being advocated as useful for Baserock that doesn't have two reviewers. | 16:35 |
| persia | How so? | 16:36 |
| * persia is fairly confident of the workflow | 16:36 | |
| paulsher1ood | i expect you are. i'm not. | 16:36 |
| persia | Some people have drunk the git-flow Kool-Aid, and as a result have issues because gerrit hates merge commits, but since I hate merge commits, I consider the problem to be with the people, not the tool. | 16:36 |
| paulsher1ood | so i'm interested in your forking idea... how would that work? | 16:36 |
| persia | We'd fork ybd into gerrit. | 16:36 |
| persia | And ideally upstream would welcome this, so we could all work in gerrit collaboratively. | 16:37 |
| paulsher1ood | and continue to pull from ybd upstream from time to time? | 16:37 |
| persia | Ideally not: it makes history ugly and causes race conditions. | 16:37 |
| paulsher1ood | ybd upstream would welcome collaboration, to be sure | 16:37 |
| persia | Would upstream be willing to abandon github? | 16:38 |
| paulsher1ood | i confess i'm not 100% settled on github either, but progress has been much faster for me there than on gerrit | 16:38 |
| paulsher1ood | i'd have to think about it... the friction is real. lots more folks are comfortable using github, than gerrit | 16:39 |
| paulsher1ood | the workflow is easier, but doesn't scale | 16:40 |
| persia | gerrit scales :) | 16:40 |
| *** jonathanmaw has quit IRC | 16:40 | |
| persia | But seriously, I'd like to understand this "friction". In practice, it really seems to be two reviews, and a button push. | 16:40 |
| paulsher1ood | yup. but workflow is harder and ui is not to my taste | 16:40 |
| persia | Almost nobody seriously uses the gerrit web UI: it's horrid. THere are much better tools. | 16:41 |
| persia | Most of the useful better tools are already in Baserock development systems. | 16:41 |
| paulsher1ood | friction to adoption, for example - github publishes the readme and other stuff, making it trivial to fork or clone and go | 16:41 |
| persia | gerrit publishes the metadata, making it trivial to clone. | 16:42 |
| persia | For most of our projects, we mirror gerrit in gitano, so we have nice g.b.o URLs also. | 16:42 |
| paulsher1ood | i don't like that any *total n00b* would have to figure out anything regardign gerrit if ybd went that way | 16:42 |
| persia | Then I'm not sure how Baserock could ever consider ybd a component. | 16:42 |
| persia | Unless Baserock were to decide to move to github, but we had that conversation over a fairly long period about a year ago, and decided on the current model. | 16:43 |
| paulsher1ood | well, it can consider it like it considers all other upstreams :) | 16:43 |
| paulsher1ood | i'm suggesting delta/ybd not baserock/baserock/ybd | 16:44 |
| persia | yes, but it wouldn't be interesting to collaborate on it, nor include it in any refernece systems, since all meaningful integration system development would have to be in morph, which we know to be reviewed. | 16:44 |
| *** ssam2 has quit IRC | 16:44 | |
| persia | There are some really cool ideas in ybd, and I think some of them may cause discussion over the right integration tool. | 16:44 |
| persia | But if we have to rely on a third-party source, I don't imagine most of us would find that very exciting. | 16:45 |
| persia | Mostly because of the duplication of work involved in ensuring that our primary tool continues to work. | 16:45 |
| paulsher1ood | i find your perspectivde there surprising. there are many other delta/* things in reference systems | 16:45 |
| persia | Yes, but none of them are core to Baserock. | 16:45 |
| persia | (using ssam2's definition above) | 16:46 |
| paulsher1ood | really? linux, make, autotools? | 16:46 |
| persia | We could use BSD, alternate make implementations, and forgo all of GNU (the major autotools consumer) if we liked. | 16:46 |
| persia | Doesn't change the core story about reliability, maintainability, etc. | 16:46 |
| paulsher1ood | same goes for morph and ybd, persia :) | 16:47 |
| persia | Except that without morph, we have no build too. | 16:47 |
| persia | If we use an external build tool, what is the point of having a separate project? | 16:47 |
| paulsher1ood | ybd builds what morph builds :) | 16:47 |
| persia | It's a question of identity. | 16:47 |
| persia | Yes, which makes it redundant. | 16:47 |
| persia | If ybd is to be considered as a peer (or replacement) for morph, then it is interesting, if the project can control it. | 16:47 |
| paulsher1ood | other outcomes are possible :) | 16:47 |
| persia | If it's a third-party tool, then it is hard to depend on it for the core functionality of what Baserock does. | 16:48 |
| paulsher1ood | i disagree, simply because there are so many things that are already depended on, that the project cannot control | 16:48 |
| persia | OK. Since my opinion is mostly about the opinion of others, I encourage you to find a way to demonstrate me incorrect :) | 16:49 |
| paulsher1ood | heh. | 16:49 |
| paulsher1ood | i would say that baserock is not about control, anyway. it's about demonstrating working solutions | 16:50 |
| persia | While I agree, I would say that community identity is about being able to use consensus tooling to achieve goals by modifying software. Software not part of a project tends to get lower attention or local patches, and differing workflows confuse and irritate. | 16:51 |
| *** bashrc has quit IRC | 16:53 | |
| paulsher1ood | i'd like consensus, for sure. in this i think there's still some way to go, for ybd. but i don't see why it can't be considered useful, and thus lorried alongside (for example) screen, nano, bc etc. | 16:55 |
| paulsher1ood | (althoug obviously thosre projects have longer history and are more popular) | 16:55 |
| paulsher1ood | i should maybe just compare it to some of the more exotic python modules :) | 16:57 |
| persia | It isn't about whether it is useful, it is about whether it is a useful target for collaborative development to progress the Baserock project. | 16:58 |
| jjardon | paulsher1ood: my opinion: lorry it, keep development in github. We will discuss what happen next if it became a core component of baserock | 16:58 |
| persia | And whether it is worth the friction of using a third-party upstream for such a core component. | 16:58 |
| paulsher1ood | persia: do you accept jjardon's reasoning above? | 16:58 |
| persia | I don't believe the conversation about it being a core component of Baserock becomes interesting until/unless the issues with hosting it inside the Baserock project are resolved. | 16:59 |
| * paulsher1ood will send a lorry file, see if it gets approved :) | 16:59 | |
| jjardon | people has to use/try it before decide, and it makes easier to use it if its lorried and added in some of our reference systems | 17:01 |
| paulsher1ood | that would be my preference, but persia has clearly raised some counter-arguments | 17:02 |
| persia | Well, without a setup.py I disagree with that from the start, but if it was usefully installable, I could see that argument. | 17:02 |
| persia | I still don't think it is interesting to discuss whether it makes sense to use ybd in preference to morph as long as ybd upstream wants to be a separate project. | 17:02 |
| paulsher1ood | persia: i agree with you on that. i was hoping to postpone that discussion until ybd is a little more 'mature' | 17:03 |
| paulsher1ood | (for example, by establishing that upstream doesn't force push any more) | 17:03 |
| persia | heh | 17:03 |
| jjardon | persia: agree with that | 17:04 |
| persia | Note that we can't unlorry anything, by policy, so if we ever wish to adopt ybd as something other than delta, we'd end up with two ybd repos on g.b.o | 17:04 |
| *** mariaderidder has quit IRC | 17:04 | |
| jjardon | they are in different namespaces, so dont think it would be a problem? I can be wrong though | 17:05 |
| paulsher1ood | persia: noted. somewhere along the line i started wondering whether there's any real reason for having baserock/baserock/* as a special case at g.b.o ? | 17:05 |
| paulsher1ood | ie morph, definitions, lorry controller etc are projects, same as all the delta stuff (from the point of view of what gbo is mostly doing) | 17:07 |
| rdale | i feel we discuss way too much important stuff on irc, rather than the mailing list | 17:07 |
| paulsher1ood | rdale: fair point. | 17:07 |
| paulsher1ood | i'll write this up and get a mail out | 17:07 |
| rdale | that's a good idea, otherwise we'll keep repeating the same arguments | 17:08 |
| * persia doesn't like mailing lists much | 17:08 | |
| persia | paulsher1ood: I never understood the point of those namespaces: they predate my involvement in Baserock, and were never to my taste. | 17:09 |
| persia | But I think changing them would be conceptually expensive, break all the reference systems, and annoy all users. | 17:10 |
| jjardon | paulsher1ood: not really. delta/ repos are sumply mirrors, where /baserock/baserock are upstream projects developed by the baserock project | 17:10 |
| paulsher1ood | jjardon: yes, understood. i wondered if the upstream development should be separate from the mirrorign, is all | 17:12 |
| paulsher1ood | but persia is probably correct that it would cause too much pain | 17:12 |
| persia | Interestingly, one of the proposed methods to resolve the various feature requests that cause us to have both gerrit and gitano was to have gerrit be upstream for the Baserock projects, and then lorry them into gitano as we lorry anything else. | 17:13 |
| persia | But there's the legacy stuff that got in the way of implementing it that way. | 17:13 |
| jjardon | yes, I though that was the plan at some point | 17:17 |
| paulsher1ood | jjardon: did you see my suggestion about settling on /src instead of /home/build by default? | 17:18 |
| persia | jjardon: If you know a way around the legacy pain that requires us to change all the definitions in sync with the git server changes, and somehow propagate this to all downstream troves, and all users, then I think many of us would like to move in that direction. | 17:19 |
| *** gary_perkins has quit IRC | 17:28 | |
| *** tiagogomes has quit IRC | 17:35 | |
| jjardon | paulsher1ood: yes, sorry I didnt have time to rework the patch this week | 17:48 |
| jjardon | but the whole point of the patch was to not use /src | 17:48 |
| jjardon | so ybd will work in any machine without any tweak | 17:49 |
| * persia prefers the lack of reliance on /src: it always felt wrong | 17:49 | |
| persia | Personally, I would prefer no hardcoded paths, with a default to /var/cache/ybd/ in /etc/defaults/ybd, but that doesn't work as well for systems that aren't FHS-compliant. | 17:50 |
| *** lachlanmackenzie has quit IRC | 17:57 | |
| paulsher1ood | so the 'reliance on /src' is because that's the baserock default. if ybd defaults to something else, it will re-clone loads of git repos that may be already on the user's dev machine | 18:33 |
| persia | You mean because it is the morph default? | 18:34 |
| paulsher1ood | yup | 18:34 |
| persia | Except it isn't: it's only the config value that the wiki recommends folk put in their morph.conf | 18:34 |
| persia | ybd should similarly default to FHS compliance, and allow the user to specify an alternate location, if they wish. | 18:35 |
| paulsher1ood | right. but for folks who follow the instruction,s that's where they have their stuff | 18:35 |
| persia | RIght, so for folk who follow the instructions, that ought include a ybd.conf | 18:35 |
| persia | I prefer /etc/defaults/ybd, but that may just be me. | 18:35 |
| paulsher1ood | ybd allows the user to specify - it's called ybd.def though | 18:35 |
| persia | Then we're all set, except that it breaks by default for new users who didn't read the docs and didn't transition from having read the morph docs, which is undesired behaviour. | 18:36 |
| paulsher1ood | would ybd.conf be better than ybd.def, for some reason? | 18:36 |
| persia | More familiar name, Leaves the .def namespace more clearly open for definitions | 18:36 |
| paulsher1ood | fair | 18:36 |
| persia | Unless we gave up on the idea of transitioning foo.morph into foo.def at some point. | 18:36 |
| paulsher1ood | that's still on my list :) | 18:37 |
| persia | In that case, I think you really don't want ybd.def. | 18:37 |
| paulsher1ood | so - user /src if /src already contains /src/cache/gits, else use what's in ybd.conf? | 18:38 |
| persia | No. | 18:38 |
| persia | Use /var/cache/ybd/ unless there is somethig in ybd.conf | 18:38 |
| persia | Because it really belongs in /var/cache/ybd | 18:38 |
| persia | (or /var/cache/morph) | 18:38 |
| paulsher1ood | even though user has already cached s88loads in /src/cache/gits? | 18:39 |
| persia | The /src/ thing is only because people were runing the tool in qemu-managed VMs, and wanted to have a separate volume for their sources which was reused over several iterations of / | 18:39 |
| paulsher1ood | yup. and i have that use-case, still | 18:39 |
| persia | We have no idea whether a pathname "/src/cache/gits/" happens to be compliant with our expectation. | 18:39 |
| persia | Users who have such a cache should use it, by configuring the tool | 18:40 |
| persia | And users who have that use case should configure the tool to support the use case. | 18:40 |
| paulsher1ood | that means more *instructions*, so less easy to just download and go | 18:40 |
| persia | Whereas, if not otherwise specified, application-specific caches belong in a namespaced subdirectory of /var/cache on linux systems. | 18:40 |
| persia | For your specific use case, yes. For my use case, it makes it easier to use. | 18:41 |
| * persia wants to run the integration tool on a development laptop without needing to repartition the disk, or add special slow USB drives as additional volumes | 18:41 | |
| paulsher1ood | i'll put detection in, so we both get what we want. i think that's possible | 18:41 |
| persia | I want configuration and default to FHS-complaince. | 18:41 |
| persia | I'm not sure how I can get what I want with detection. | 18:41 |
| paulsher1ood | will you have a pre-ecisting /src/cache/gits directory, yet expressly not want to use it? | 18:42 |
| persia | Quite possibly. | 18:44 |
| persia | Perhaps I have a backup of a volume that was on a VM I was using for development that I've mounted on my laptop for extracting something. | 18:45 |
| paulsher1ood | well, i'm sure you'll figure it out :) | 18:45 |
| persia | Having that suddently try to update a loopback volume in a backup file rather than using my more recent cache would be annoying. | 18:45 |
| paulsher1ood | :-) | 18:45 |
| persia | yes, but it shouldn7t be the folk who want to have FHS-complaint systems that have to figure it out. It ought be the folk that are different because they have specialised use cases. | 18:46 |
| persia | I'm not saying the specialised use case should be hard to support: I just don't think making ybd less compliant than morph is a sensible feature to add. | 18:46 |
| paulsher1ood | trouble is jjardon's proposed solutions is neither FHS nor /src iiuc | 18:46 |
| persia | That's only a problem because the way github works, we can't update it without waiting for him. | 18:47 |
| paulsher1ood | https://github.com/devcurmudgeon/ybd/pull/82 | 18:47 |
| persia | Right, it's a pull request. Only folk with access to the original source can update the candidate commits to be landed to ybd. | 18:48 |
| paulsher1ood | i mean he is proposing a differnt default from you and from /src | 18:48 |
| paulsher1ood | i can update the candidate commits, i'm pretty sure | 18:48 |
| paulsher1ood | i just don't know what to update *to* | 18:49 |
| paulsher1ood | seems you and he want different things | 18:49 |
| persia | Have we solved the problem that it has to be run as root? | 18:49 |
| persia | If we have, his solution is better. | 18:50 |
| persia | If we haven't, his solution breaks user control over the user's home directory. | 18:50 |
| paulsher1ood | nope. i've been told 'it's a couple of weeks work' | 18:50 |
| persia | I'll mitigate my comment then, but I do not think it would be good to merge the current candidate before that lands, or at least, I would never want to use it in default mode in a system with non-root users. | 18:51 |
| persia | Anyway, this is a perfect example of what I consider friction with github. | 18:56 |
| *** edcragg has quit IRC | 18:57 | |
| paulsher1ood | why? | 18:57 |
| persia | There is no obvious way for me to pull jjardon's change into my local ybd repo in a new branch, edit the commit to do what I want, and publish it back into the ongoing conversation into which his commit was posted. | 18:57 |
| paulsher1ood | git add remote, git fetch etch? | 18:58 |
| paulsher1ood | etc | 18:58 |
| persia | And push where? | 18:58 |
| paulsher1ood | to your own fork? | 18:58 |
| persia | And open a new pull request, for a new conversation? | 18:58 |
| persia | What I want is to land my candidate commit in the *same* conversation, so we can discuss relative merits in one threaded discussion. | 18:59 |
| persia | (which gerrit supports) | 18:59 |
| paulsher1ood | understood. could you try it, please? and then add your sha to the existing issues conversation? | 18:59 |
| * paulsher1ood hasn't tried this, is interested | 19:00 | |
| persia | Try what how? | 19:00 |
| paulsher1ood | make a fork of jjardon's fork, amend, then cut and paste your new sha1 into a reply in the existing issue thread | 19:01 |
| paulsher1ood | github seems to magically make links for shas, i wonder if it will handle this | 19:01 |
| * persia struggles to find a fetch URL from the pull request discussion | 19:03 | |
| paulsher1ood | https://github.com/jjardon/ybd | 19:04 |
| * persia was hoping for easy copy&paste instructions like `git fetch https://gerrit.baserock.org/baserock/baserock/definitions refs/changes/06/906/1 && git cherry-pick FETCH_HEAD` | 19:06 | |
| * paulsher1ood was hoping for whirled peas | 19:06 | |
| persia | grumble. I can't `git fetch https://github.com/jjardon/ybd.git xdg_dirs` directly. I have to add a remote. | 19:08 |
| paulsher1ood | maybe this is not worth your time. i agree gh is not perfect, nor is gerrit | 19:08 |
| persia | This means a new remote for every developer whose changes I want to review locally. | 19:08 |
| persia | I don't understand how anyone can accept this UI. | 19:08 |
| paulsher1ood | it doesn't 'scale', that's for sure :) | 19:09 |
| persia | Perhaps. I don't use github except as a write-only store, so I'm digging through `git help remote` to try to figure out the next step. | 19:09 |
| persia | Stopping seems very pleasing. | 19:09 |
| paulsher1ood | git remote add jjardon https://github.com/jjardon/ybd | 19:09 |
| paulsher1ood | git fetch jjardon | 19:09 |
| paulsher1ood | stop, then, do more fun things, like whirled peas | 19:10 |
| persia | Heh, OK. | 19:11 |
| * paulsher1ood suddenly realises he should have saved his purple shirt for today's meetings :/ | 19:11 | |
| persia | With your commands, I was able to get it, but only by digging through the output of `git branch -r`, which I imagine gets ugly fast for more than a few developers. | 19:11 |
| paulsher1ood | yup | 19:12 |
| persia | Hrm. For github, do I have to do something to authorise a push? | 19:31 |
| *** edcragg has joined #baserock | 20:48 | |
| *** dabukalam_ is now known as dabukalam | 21:38 | |
| *** dabukalam has joined #baserock | 21:39 | |
| *** edcragg has quit IRC | 22:04 | |
| paulsher1ood | are you around? could you send me the spec? | 22:11 |
| paulsher1ood | req spec that was shown to mips licensees etc | 22:12 |
| *** SotK has quit IRC | 22:59 | |
| *** SotK has joined #baserock | 22:59 | |
| *** edcragg has joined #baserock | 23:04 | |
| *** edcragg has quit IRC | 23:46 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!