IRC logs for #baserock for Thursday, 2016-07-21

*** rdale has quit IRC02:13
*** paulwaters_ has joined #baserock07:06
*** rdale has joined #baserock07:07
*** toscalix has joined #baserock07:59
*** anahuelamo has joined #baserock08:12
*** rdale has quit IRC08:13
*** jonathanmaw has joined #baserock08:32
*** gtristan has joined #baserock08:51
*** locallycompact has joined #baserock09:14
*** locallycompact has joined #baserock09:15
*** rdale has joined #baserock09:27
locallycompactI can't find the url to submit lorry changes to gerrit11:34
locallycompactnvm got it11:35
*** anahuelamo_ has joined #baserock13:22
*** anahuelamo has quit IRC13:22
*** rdale has quit IRC15:49
CTtpollardis there an issue with paste.baserock?15:58
pedroalvarezCTtpollard: hm.. not that I'm aware of15:59
CTtpollardmust just be on my end the, ta16:00
CTtpollardmy cmake log & the file in which the variable it is complaining about is set;a=blob;f=cmake/FindAudioManager.cmake;h=ad97f2310e58f8b47e1ff8b370bf8b7cfb6d9036;hb=a0ed3b8f05147e9240d941655488d505057bbae716:02
CTtpollardin that error log, plugins such as Async and Dbus plugins are failing with the same error, these are in no way modify by GDP16:03
CTtpollardso this error should also occur in the baseline image16:04
CTtpollardso if anyone has better cmake knowledge, fire away16:05
CTtpollardactually... it's complaining re ' AUDIO_INCLUDE_FOLDER' the cmake file is trying to assign 'AUDIOMANAGER_INCLUDE_FOLDER'16:07
CTtpollardso, I need to find where  AUDIO_INCLUDE_FOLDER is meant to be coming from16:09
* paulsherwood imagines that would be the answer, but it seems to be down16:11
paulsherwoodpedroalvarez: ^^ ?16:11
pedroalvarezI took it off, it was failing and didn't have time to maintain it16:12
paulsherwoodah, ok16:12
pedroalvarezand it only have sources for a minimal system16:12
pedroalvarezCTtpollard: hm.. I'm not having problems with the baseline16:14
CTtpollardpedroalvarez: does the baserock baseline build the audiomanager plugins as a separate package?16:15
pedroalvarezI think they are only part of GDP in baserock, not of Baseline16:16
pedroalvarezwell, I'm not sure16:17
paulsherwoodstrata/genivi.morph:- name: audiomanager16:17
paulsherwoodstrata/genivi.morph:  repo: upstream:audiomanager16:17
pedroalvarezcan you point me at the recipe that builds these plugins?16:17
paulsherwoodstrata/genivi-demo-platform.morph:- name: audiomanager@gdp16:18
*** cosm has joined #baserock16:18
pedroalvarezthat's part of what I mean ^16:18
* paulsherwood loves c.b.o sometimes :)16:19
paulsherwoodi guess that may mean we are not yet building what CTtpollard has encountered?16:20
pedroalvarez genivi-demo-platform-libs: dbus-python needs dbus-glib to build16:23
paulsherwoodpedroalvarez: +216:24
pedroalvarezmerged, let's see what concourse does this time16:25
* jjardon adds gdp to the gitlab ci16:26
*** jonathanmaw has quit IRC16:28
jjardonpaulsherwood: any idea what is causing the tar failure here?
paulsherwoodjjardon: yes, this was discussed here with richard_maw. unfortunately haven't implemented the soln yet16:31
paulsherwoodmaybe over this weekend i'll get it done16:31
jjardonpaulsherwood: ok, cheers16:39
richard_mawjjardon: 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 overalyfs16:42
richard_mawthe 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 mode16:43
richard_mawthe 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 reverse16:44
* pedroalvarez finds another bug:16:55
pedroalvarez rvi: Fix dependencies16:55
franredpedroalvarez, merged16:57
paulsherwood ?17:04
* paulsherwood wonders if c.b.o didn't get the update somehow?17:05
pedroalvarezi wonder if we are just re-triggering the same build, with same definitions sha17:06
paulsherwoodoh, it's started from lower down17:06
*** toscalix has quit IRC17:32
*** locallycompact has quit IRC17:32
*** gtristan has quit IRC17:44
*** leeming has quit IRC17:57
*** persia has quit IRC19:01
*** persia_ has quit IRC19:01
*** thrace_ has quit IRC19:01
*** cosm has quit IRC19:44
*** locallycompact has joined #baserock20:18
*** thrace has joined #baserock20:35
*** persia has joined #baserock20:35
*** persia_ has joined #baserock20:35
jjardonpedroalvarez: is really necessary to create branches for every distbuild?21:03
pedroalvarezjjardon: for builds of unpushed changes, yes21:23
pedroalvarezooi, why?21:24
jjardonpedroalvarez: imagine every single developer do that; the repo would be cluttered with a lot of branches21:24
pedroalvarezjjardon: oh right, but why is that worrying you now21:30
pedroalvarezthere are not many distbuild/morph users right now21:31
jjardonbecause is the first time I notice that when I did a git pull today21:31
jjardonalso, why distbuild users need to have git commit rights to the definitions repo? that approach doesnt seem to scale very well21:32
pedroalvarezI don't think we have to worry about implementation details of a tool that most of the people wants to deprecate..21:35
pedroalvarezjjardon: I think is a good approach to share the definitions repository between the workers of the distbuild network21:38
pedroalvarezmaybe, using another refs that don't show up in git or cgit would be better? I don't know21:39
pedroalvarezanyway, distbuld normally deletes the branch once the build finishes21:40
jjardonpedroalvarez: 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 better21:41
*** locallycompact has quit IRC21:41
jjardonlike gitlab runners? :)21:42
pedroalvarezRegarding cluttering...  I could start by cleaning my 130 branches21:45
pedroalvarezYou have 75  :P21:46
pedroalvarezHang on, how gitlab runners share definitions?21:46
jjardonpedroalvarez: yep, those are from the pre-gerrit era21:48
jjardonpedroalvarez: not sure I understand your question, they are all trigged from the same commit21:49
pedroalvarezjjardon: Heh, then they need git commit rights21:52
jjardonpedroalvarez: the runners? nope, why they would?21:53
pedroalvarezDevelopers using it21:54
jjardonpedroalvarez: 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 done21:55
pedroalvarezI somehow think that gitlab is not a replacement for distbuild21:56
pedroalvarezbut I can be wrong, of course21:57
pedroalvarezmy 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  toghether21:58
paulsherwoodi thought ybd proved that distbuild was unnecessary, but i may be wrong too21:58
pedroalvarezyup, that's why I said we shouldn't worry about the implemenation details of it22:03
paulsherwoodack, 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
jjardonpedroalvarez: branches removed :)22:06
paulsherwoodjjardon: did you manage to re-try ?22:08
jjardonpaulsherwood: its running now:
paulsherwoodjjardon: do those builds share an artifact cache?22:09
* paulsherwood checks and concludes, no22:10
jjardonpaulsherwood: if you are ok to them to use the public kbas server, I can try to setup it now22:11
paulsherwoodyup that would be great, assuming credentials remain secret22:13
paulsherwoodjjardon: so in effect, with artifact cache, your ci already does distbuild... since it allocates each target system to a different runner22:16
paulsherwoodwould be faster with dedicated runners, persistent cache on each runner etc22:17
jjardonyep, still there is a lot room for improvement22:17
paulsherwoodalways :)22:18
pedroalvarezI kind of think that depending on gitlab is not the right thing :/22:18
paulsherwoodpedroalvarez: why?22:19
pedroalvarezhm.. it seems like depending on something that might be really heavy to do something that is simpler22:19
paulsherwoodoh, you mean the commandline use-case, then. well, absolute simplest is shell into n machines, run the build on all of them, with shared cache22:20
pedroalvarezsimpler is to run a single command, without shelling into n machines22:21
paulsherwoodthat presumes you've setup a distbuild network... which last time i tried was not simple?22:22
paulsherwoodbut for ybd the single command could be achieved by a bash script, maybe? :)22:23
paulsherwoodincidentally, 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 looptime22:26
paulsherwoods/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  toghether22:42
pedroalvarezand then, your gitlab, worker, or another random ci worker, or just an user using comand line, benefits from it22:44
paulsherwoodok. i think ybd is *mostly* there for that22:45
paulsherwoodi just don't know whether the implied requirement for scheduling across machines is really worth it22:45
pedroalvarezI just like the idea, maybe it isn't worth it though22:46
paulsherwoodedmund sutcliffe suggested just using nfs, and having the build job lobbed into a shared directory22:46
paulsherwoodit 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 awful22:47
pedroalvarezanyway, I don't see the point of discussing this any further22:49
pedroalvarezand I should have some sleep :)22:50
paulsherwoodme too :)22:50
jjardonpaulsherwood: done22:51
paulsherwoodooh :)22:51
jjardoneasiest thing ever22:52
jjardonpaulsherwood: check
paulsherwoodi need to re-read rmaw's explanation of the tar problem22:53
paulsherwoodjjardon: oddly, that is 404 for me22:53
jjardonmmm, maybe only owners can see that page, but basically I defined env variable YBD_kbas_password22:55

Generated by 2.15.3 by Marius Gedminas - find it at!