| *** rdale has quit IRC | 02:13 | |
| *** paulwaters_ has joined #baserock | 07:06 | |
| *** rdale has joined #baserock | 07:07 | |
| *** toscalix has joined #baserock | 07:59 | |
| *** anahuelamo has joined #baserock | 08:12 | |
| *** rdale has quit IRC | 08:13 | |
| *** jonathanmaw has joined #baserock | 08:32 | |
| *** gtristan has joined #baserock | 08:51 | |
| *** locallycompact has joined #baserock | 09:14 | |
| *** locallycompact has joined #baserock | 09:15 | |
| *** rdale has joined #baserock | 09:27 | |
| locallycompact | I can't find the url to submit lorry changes to gerrit | 11:34 |
|---|---|---|
| locallycompact | nvm got it | 11:35 |
| *** anahuelamo_ has joined #baserock | 13:22 | |
| *** anahuelamo has quit IRC | 13:22 | |
| *** rdale has quit IRC | 15:49 | |
| CTtpollard | is there an issue with paste.baserock? | 15:58 |
| pedroalvarez | CTtpollard: hm.. not that I'm aware of | 15:59 |
| paulsherwood | http://paste.baserock.org/oyucakasag | 15:59 |
| pedroalvarez | http://paste.baserock.org/ebewemoyew | 15:59 |
| CTtpollard | must just be on my end the, ta | 16:00 |
| CTtpollard | *then | 16:01 |
| CTtpollard | my cmake log http://paste.baserock.org/inahevinim & the file in which the variable it is complaining about is set http://git.projects.genivi.org/?p=AudioManagerPlugins.git;a=blob;f=cmake/FindAudioManager.cmake;h=ad97f2310e58f8b47e1ff8b370bf8b7cfb6d9036;hb=a0ed3b8f05147e9240d941655488d505057bbae7 | 16:02 |
| CTtpollard | in that error log, plugins such as Async and Dbus plugins are failing with the same error, these are in no way modify by GDP | 16:03 |
| CTtpollard | so this error should also occur in the baseline image | 16:04 |
| CTtpollard | so if anyone has better cmake knowledge, fire away | 16:05 |
| CTtpollard | actually... it's complaining re ' AUDIO_INCLUDE_FOLDER' the cmake file is trying to assign 'AUDIOMANAGER_INCLUDE_FOLDER' | 16:07 |
| CTtpollard | so, I need to find where AUDIO_INCLUDE_FOLDER is meant to be coming from | 16:09 |
| * paulsherwood imagines that opengrok.baserock.org would be the answer, but it seems to be down | 16:11 | |
| paulsherwood | pedroalvarez: ^^ ? | 16:11 |
| pedroalvarez | I took it off, it was failing and didn't have time to maintain it | 16:12 |
| paulsherwood | ah, ok | 16:12 |
| CTtpollard | np | 16:12 |
| pedroalvarez | and it only have sources for a minimal system | 16:12 |
| pedroalvarez | had* | 16:12 |
| pedroalvarez | CTtpollard: hm.. I'm not having problems with the baseline | 16:14 |
| CTtpollard | pedroalvarez: does the baserock baseline build the audiomanager plugins as a separate package? | 16:15 |
| pedroalvarez | I think they are only part of GDP in baserock, not of Baseline | 16:16 |
| pedroalvarez | well, I'm not sure | 16:17 |
| paulsherwood | strata/genivi.morph:- name: audiomanager | 16:17 |
| paulsherwood | strata/genivi.morph: repo: upstream:audiomanager | 16:17 |
| pedroalvarez | can you point me at the recipe that builds these plugins? | 16:17 |
| paulsherwood | strata/genivi-demo-platform.morph:- name: audiomanager@gdp | 16:18 |
| *** cosm has joined #baserock | 16:18 | |
| pedroalvarez | that's part of what I mean ^ | 16:18 |
| paulsherwood | http://concourse.baserock.org/pipelines/genivi-demo-platform-x86_64-generic/jobs/genivi-demo-platform-libs/builds/32 | 16:18 |
| * paulsherwood loves c.b.o sometimes :) | 16:19 | |
| paulsherwood | i guess that may mean we are not yet building what CTtpollard has encountered? | 16:20 |
| pedroalvarez | https://gerrit.baserock.org/2228 genivi-demo-platform-libs: dbus-python needs dbus-glib to build | 16:23 |
| paulsherwood | pedroalvarez: +2 | 16:24 |
| pedroalvarez | merged, let's see what concourse does this time | 16:25 |
| paulsherwood | :) | 16:25 |
| * jjardon adds gdp to the gitlab ci | 16:26 | |
| *** jonathanmaw has quit IRC | 16:28 | |
| jjardon | paulsherwood: any idea what is causing the tar failure here? https://gitlab.com/baserock/definitions/builds/2508653#down-build-trace | 16:30 |
| paulsherwood | jjardon: yes, this was discussed here with richard_maw. unfortunately haven't implemented the soln yet | 16:31 |
| paulsherwood | maybe over this weekend i'll get it done | 16:31 |
| jjardon | paulsherwood: ok, cheers | 16:39 |
| richard_maw | jjardon: if you're interested, the problem is that we're creating the tarballs top-down, when they should be bottom-up, and tar's work-around logic for this breaks on non-POSIX file systems, which is what the gitlab pipelines use, since they are run in a docker container using overalyfs | 16:42 |
| richard_maw | the solution is to do it bottom-up, but doing that in a sorted order isn't so easy in python, since you can only change the traversal order in top-down mode | 16:43 |
| richard_maw | the solutions are to either write your own file system traversal, or to use os.walk in top-down mode, sort the directories and files lists, and add the yielded directory path, directories and files to a list, which you then process in reverse | 16:44 |
| * pedroalvarez finds another bug: | 16:55 | |
| pedroalvarez | https://gerrit.baserock.org/2230 rvi: Fix dependencies | 16:55 |
| franred | pedroalvarez, merged | 16:57 |
| pedroalvarez | ta! | 16:57 |
| paulsherwood | http://concourse.baserock.org/pipelines/genivi-demo-platform-x86_64-generic/jobs/genivi-demo-platform-libs/builds/34 ? | 17:04 |
| * paulsherwood wonders if c.b.o didn't get the update somehow? | 17:05 | |
| pedroalvarez | i wonder if we are just re-triggering the same build, with same definitions sha | 17:06 |
| paulsherwood | oh, it's started from lower down | 17:06 |
| *** toscalix has quit IRC | 17:32 | |
| *** locallycompact has quit IRC | 17:32 | |
| *** gtristan has quit IRC | 17:44 | |
| *** leeming has quit IRC | 17:57 | |
| *** persia has quit IRC | 19:01 | |
| *** persia_ has quit IRC | 19:01 | |
| *** thrace_ has quit IRC | 19:01 | |
| *** cosm has quit IRC | 19:44 | |
| *** locallycompact has joined #baserock | 20:18 | |
| *** thrace has joined #baserock | 20:35 | |
| *** persia has joined #baserock | 20:35 | |
| *** persia_ has joined #baserock | 20:35 | |
| jjardon | pedroalvarez: is really necessary to create branches for every distbuild? | 21:03 |
| pedroalvarez | jjardon: for builds of unpushed changes, yes | 21:23 |
| pedroalvarez | ooi, why? | 21:24 |
| jjardon | pedroalvarez: imagine every single developer do that; the repo would be cluttered with a lot of branches | 21:24 |
| pedroalvarez | jjardon: oh right, but why is that worrying you now | 21:30 |
| pedroalvarez | there are not many distbuild/morph users right now | 21:31 |
| jjardon | because is the first time I notice that when I did a git pull today | 21:31 |
| jjardon | also, why distbuild users need to have git commit rights to the definitions repo? that approach doesnt seem to scale very well | 21:32 |
| pedroalvarez | I don't think we have to worry about implementation details of a tool that most of the people wants to deprecate.. | 21:35 |
| pedroalvarez | deprecate* | 21:37 |
| pedroalvarez | jjardon: I think is a good approach to share the definitions repository between the workers of the distbuild network | 21:38 |
| pedroalvarez | maybe, using another refs that don't show up in git or cgit would be better? I don't know | 21:39 |
| pedroalvarez | anyway, distbuld normally deletes the branch once the build finishes | 21:40 |
| jjardon | pedroalvarez: I've never used distbuild, and while it can be fine to do that for private projects, I do not think is a good practice to clutter the upstream definitions repo. Saying that, I was only curious about all those branches; not a massive problem until we have something better | 21:41 |
| *** locallycompact has quit IRC | 21:41 | |
| pedroalvarez | ack | 21:41 |
| jjardon | like gitlab runners? :) | 21:42 |
| pedroalvarez | Hahah | 21:45 |
| pedroalvarez | Regarding cluttering... I could start by cleaning my 130 branches | 21:45 |
| pedroalvarez | You have 75 :P | 21:46 |
| pedroalvarez | Hang on, how gitlab runners share definitions? | 21:46 |
| jjardon | pedroalvarez: yep, those are from the pre-gerrit era | 21:48 |
| jjardon | pedroalvarez: not sure I understand your question, they are all trigged from the same commit | 21:49 |
| pedroalvarez | jjardon: Heh, then they need git commit rights | 21:52 |
| jjardon | pedroalvarez: the runners? nope, why they would? | 21:53 |
| pedroalvarez | Developers using it | 21:54 |
| jjardon | pedroalvarez: no, you can always fork the definitions repo and do all the ci you want; then request a MR to merge your branch in the main repo when you are done | 21:55 |
| pedroalvarez | I somehow think that gitlab is not a replacement for distbuild | 21:56 |
| pedroalvarez | but I can be wrong, of course | 21:57 |
| pedroalvarez | my idea of distbuild (it doesn't have to be the current one, it doesn't have to be morph), is that you can easily setup various systems so that they build toghether | 21:58 |
| paulsherwood | i thought ybd proved that distbuild was unnecessary, but i may be wrong too | 21:58 |
| pedroalvarez | yup, that's why I said we shouldn't worry about the implemenation details of it | 22:03 |
| paulsherwood | ack, but i'm wondering if you still see a use-case that can't be reasonably satisfied by a bunch of (say, arm-based) gitlab runners? | 22:04 |
| jjardon | pedroalvarez: branches removed :) | 22:06 |
| paulsherwood | jjardon: did you manage to re-try https://github.com/devcurmudgeon/ybd/issues/230 ? | 22:08 |
| jjardon | paulsherwood: its running now: https://gitlab.com/baserock/definitions/pipelines/3760499 | 22:08 |
| paulsherwood | jjardon: do those builds share an artifact cache? | 22:09 |
| * paulsherwood checks and concludes, no | 22:10 | |
| jjardon | paulsherwood: if you are ok to them to use the public kbas server, I can try to setup it now | 22:11 |
| paulsherwood | yup that would be great, assuming credentials remain secret | 22:13 |
| paulsherwood | jjardon: so in effect, with artifact cache, your ci already does distbuild... since it allocates each target system to a different runner | 22:16 |
| paulsherwood | would be faster with dedicated runners, persistent cache on each runner etc | 22:17 |
| jjardon | yep, still there is a lot room for improvement | 22:17 |
| paulsherwood | always :) | 22:18 |
| pedroalvarez | I kind of think that depending on gitlab is not the right thing :/ | 22:18 |
| paulsherwood | pedroalvarez: why? | 22:19 |
| pedroalvarez | hm.. it seems like depending on something that might be really heavy to do something that is simpler | 22:19 |
| paulsherwood | oh, you mean the commandline use-case, then. well, absolute simplest is shell into n machines, run the build on all of them, with shared cache | 22:20 |
| pedroalvarez | simpler is to run a single command, without shelling into n machines | 22:21 |
| paulsherwood | that presumes you've setup a distbuild network... which last time i tried was not simple? | 22:22 |
| paulsherwood | but for ybd the single command could be achieved by a bash script, maybe? :) | 22:23 |
| paulsherwood | incidentally, in practice do think that the benefits of using gitlab (even though it's heavy) outweigh the commandline for most use-cases. we get better traceability, and afaict users are happy with the looptime | 22:26 |
| paulsherwood | s/do/i do/ | 22:26 |
| pedroalvarez | <pedroalvarez> my idea of distbuild (it doesn't have to be the current one, it doesn't have to be morph), is that you can easily setup various systems so that they build toghether | 22:42 |
| pedroalvarez | and then, your gitlab, worker, or another random ci worker, or just an user using comand line, benefits from it | 22:44 |
| paulsherwood | ok. i think ybd is *mostly* there for that | 22:45 |
| paulsherwood | i just don't know whether the implied requirement for scheduling across machines is really worth it | 22:45 |
| pedroalvarez | :) | 22:45 |
| pedroalvarez | I just like the idea, maybe it isn't worth it though | 22:46 |
| paulsherwood | edmund sutcliffe suggested just using nfs, and having the build job lobbed into a shared directory | 22:46 |
| paulsherwood | it would be easy enough to do the ybd part for that, but nfs performance is a black art to me, and when it tried lashing something together the performance was awful | 22:47 |
| pedroalvarez | anyway, I don't see the point of discussing this any further | 22:49 |
| paulsherwood | ack | 22:49 |
| pedroalvarez | and I should have some sleep :) | 22:50 |
| pedroalvarez | night! | 22:50 |
| paulsherwood | me too :) | 22:50 |
| paulsherwood | gnite | 22:50 |
| jjardon | paulsherwood: done | 22:51 |
| paulsherwood | ooh :) | 22:51 |
| jjardon | easiest thing ever | 22:52 |
| paulsherwood | :) | 22:53 |
| jjardon | paulsherwood: check https://gitlab.com/baserock/definitions/variables | 22:53 |
| paulsherwood | i need to re-read rmaw's explanation of the tar problem | 22:53 |
| paulsherwood | jjardon: oddly, that is 404 for me | 22:53 |
| jjardon | mmm, maybe only owners can see that page, but basically I defined env variable YBD_kbas_password | 22:55 |
| paulsherwood | ack | 22:55 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!