*** rdale_ct has joined #baserock | 04:27 | |
*** rdale has quit IRC | 04:30 | |
*** gtristan has joined #baserock | 05:37 | |
*** gtristan has quit IRC | 05:39 | |
*** gtristan has joined #baserock | 05:39 | |
*** ctbruce has joined #baserock | 07:32 | |
*** rdale_ct has quit IRC | 07:44 | |
*** rdale has joined #baserock | 07:53 | |
*** rdale has quit IRC | 08:08 | |
*** jude_ has joined #baserock | 08:14 | |
*** franred has joined #baserock | 08:16 | |
*** rdale has joined #baserock | 08:18 | |
*** toscalix has joined #baserock | 08:19 | |
jjardon | tiagogomes_: hi! You have upgraded gcc before, I wonder if you have tried the branch to upgrade to gcc6 recently? | 09:20 |
---|---|---|
pedroalvarez | is this the branch I created? | 09:22 |
pedroalvarez | it would be good to give it a try again | 09:23 |
pedroalvarez | the error I hit was a really weird one that we should investigate if we hit it again | 09:23 |
jjardon | Yes | 09:23 |
jjardon | IIRC, one of the problems is syslinux, again | 09:24 |
pedroalvarez | nope, that wasn't a problem | 09:24 |
pedroalvarez | or if it was, i worked around it | 09:25 |
pedroalvarez | yep, this was the workaround: http://git.baserock.org/cgit/delta/syslinux.git/log/?h=baserock/pedroalvarez/gcc6 | 09:25 |
jjardon | Ah, cool | 09:32 |
*** locallycompact has joined #baserock | 09:33 | |
tiagogomes_ | jjardon, no I didn't try | 09:37 |
tiagogomes_ | So that branch doesn't build ? | 09:37 |
pedroalvarez | it builds, or used to | 09:38 |
pedroalvarez | it had runtime problems | 09:38 |
pedroalvarez | python broken because libffi was broken | 09:38 |
pedroalvarez | and if you re-compiled libffi in the deployed system, everything worked fine | 09:39 |
pedroalvarez | so, something weird was going on in my testing | 09:39 |
jjardon | It doesn't compile when I tried to upgrade to 6.2 in jjardon/gcc6 in gitlab; maybe its worth to try again without the gcc 6.2 changes | 09:40 |
*** CTtpollard has joined #baserock | 09:41 | |
tiagogomes_ | Gitlab only tests x86_64 right? | 09:41 |
pedroalvarez | how do I go from branch to CI results in gitlab? | 09:43 |
pedroalvarez | took me a while.. :/ | 09:45 |
jjardon | tiagogomes_: yep, until we setup ARM runners | 09:47 |
tiagogomes_ | and Power, x86_32 | 09:47 |
pedroalvarez | not sure about power | 09:48 |
tiagogomes_ | Is the opestack system being tested on gitlab ? | 09:48 |
pedroalvarez | built? yes | 09:48 |
tiagogomes_ | mm, building tftp-hpa is failing to me | 09:48 |
pedroalvarez | meh | 10:03 |
* pedroalvarez gives up trying to make gitlab test a branch | 10:03 | |
locallycompact | pedroalvarez, it should just run atuomatically | 10:04 |
locallycompact | pedroalvarez, what branch | 10:04 |
pedroalvarez | I pushed this branch https://gitlab.com/palvarez89/definitions/commits/baserock/pedroalvarez/gcc6-2 | 10:05 |
pedroalvarez | also commited a change to this one https://gitlab.com/baserock/definitions/commits/baserock/pedroalvarez/gcc6 | 10:05 |
locallycompact | is there a .gitlab-ci.yml file in that branch | 10:05 |
pedroalvarez | crap | 10:06 |
locallycompact | nop | 10:06 |
pedroalvarez | that's it... | 10:06 |
*** toscalix has quit IRC | 10:42 | |
*** toscalix has joined #baserock | 10:55 | |
pedroalvarez | jjardon: maybe we could go first to 6.1 if 6.2 is going to have more problems | 11:05 |
jjardon | pedroalvarez: sure | 11:44 |
paulsher1ood | tiagogomes_: are you ok with me dropping https://gitlab.com/baserock/ybd/merge_requests/254 based on the multi-instance requirement? | 11:54 |
jjardon | pedroalvarez: stage2-glibc seems to fail: https://gitlab.com/baserock/definitions/builds/5551543 | 11:57 |
jjardon | pedroalvarez: this is the bracnh Im using: https://gitlab.com/baserock/definitions/commits/jjardon/gcc6.1 | 11:58 |
pedroalvarez | hm.. | 11:58 |
pedroalvarez | the branch I pushed a while back builds that fine: https://gitlab.com/palvarez89/definitions/builds/5550695 | 11:58 |
jjardon | ah, Im missing the --disable-werror for glibc in my branch | 12:04 |
*** gtristan has quit IRC | 12:19 | |
*** CTtpollard has quit IRC | 12:19 | |
*** CTtpollard has joined #baserock | 12:21 | |
*** paulw has joined #baserock | 12:29 | |
tiagogomes_ | paulsher1ood I would like to rework the patch, but you can drop it for now | 12:40 |
paulsher1ood | tiagogomes_: np i'll look forward to your rework | 13:23 |
jjardon | mmm, any idea why Im getting this failure? "RuntimeError: ['mount', '-t', '', '-o', '', '/dev', '/dev'] failed: mount: unknown filesystem type '' https://gitlab.com/baserock/definitions/builds/5554760 | 13:44 |
jjardon | Is it because the runner should have btrfs support? | 13:45 |
leeming | should it be using linux-user-chroot anyway? | 13:47 |
leeming | not sure if normal chroot removes capabilities | 13:48 |
leeming | i expect it does | 13:48 |
tiagogomes_ | jjardon because '-o' is an invalid mount type | 13:49 |
leeming | ^well yes.. but i thinkg there is a real reason why '' was selected instead of something sensible | 13:50 |
tiagogomes_ | I don't understand why is trying to mount /dev in the chroot. Can't see code in either sandboxlib or ybd for that. | 14:15 |
*** jude_ has quit IRC | 14:19 | |
paulsher1ood | jjardon: pls can you try wth 16.42 ? | 14:21 |
* paulsher1ood merged a patch earlier today featuring /dev... maybe he shouldn't have | 14:22 | |
jjardon | sure, one sec | 14:22 |
jjardon | paulsher1ood: maybe its a good idea to not use the kbas in the ybd ci, so the minimal system gets actually build? or maybe do both? (using kbas and without using it) | 14:28 |
*** toscalix has quit IRC | 14:35 | |
jjardon | paulsher1ood: 16.42 seems to build fine: https://gitlab.com/baserock/definitions/builds/5561465 | 14:38 |
jjardon | paulsher1ood: how can I tell ybd to not use the kbas server? | 14:39 |
jjardon | set kbas-url to "" ? | 14:39 |
paulsher1ood | kbas-url: "foo" | 14:40 |
paulsher1ood | i suggest do both | 14:40 |
jjardon | yeah | 14:40 |
paulsher1ood | but not the whole of ci.morph :) | 14:40 |
jjardon | nope, only the minimal system | 14:42 |
paulsher1ood | leeming: i'm guessing your /dev patch doesn't work ? :/ | 14:42 |
leeming | perhaps. did someone test it, other than me? | 14:43 |
jjardon | leeming: did you build any system with it? | 14:44 |
leeming | is this related to jjardon's issue? I wonder if you tried the linux-user-chroot method? | 14:44 |
leeming | yes | 14:44 |
leeming | apart from building a system, there isn't another test to run for ybd right? | 14:45 |
paulsher1ood | leeming: it depends what you're changing | 14:46 |
jjardon | leeming: I meant without using the kbas cache server | 14:46 |
jjardon | so everything gets build | 14:46 |
leeming | oh, i have no idea about the kbas cache | 14:46 |
leeming | i did a full build, clearled the ybd folder | 14:47 |
paulsher1ood | leeming: if you didn't override kbas-url, you may have not actually built any component | 14:48 |
leeming | i did not over-ride kbas no.. but i set "artifact-version: 77" which i understand means it never gets a remote copy? | 14:48 |
leeming | standard config does not upload, correct? | 14:49 |
paulsher1ood | oh, correct. yes overriding artifact-version also works | 14:49 |
paulsher1ood | well, for some reason jjardon can not build any longer, and i think the reason is extra_mounts=[('/dev', '/dev', None)], | 14:51 |
leeming | good, i understand something then :P \o/ | 14:51 |
leeming | as suggested, can he run it with linux-user-chroot? out of interest | 14:51 |
leeming | but yes, that is a possible issue with the fix, running on older sandbox implementations | 14:51 |
leeming | i had not looked at chroot in sandboxlib | 14:52 |
jjardon | leeming: give me one sec | 14:52 |
leeming | but feel free to roll back | 14:52 |
* paulsher1ood is happy to do that, or wait for a fix | 14:53 | |
leeming | i wonder how chroot accesses /dev then, if it isn't mounted? | 14:53 |
leeming | is there some smaller systems to build for testing ybd? | 14:54 |
* tiagogomes_ has a branch where he scraps sandboxlib | 14:54 | |
leeming | so that i could at least force all 3 sandboxes | 14:54 |
leeming | is this a new thing tiagogomes_ ? | 14:54 |
paulsher1ood | tiagogomes_: you mean scrap sandboxlib, or scrap sandboxing altogether? | 14:55 |
leeming | tristan had suggested something similar | 14:55 |
paulsher1ood | leeming: minimal is the smallest. you know you can re-run it on foo, after removing foo artifact? where foo is any chunk/stratum? | 14:55 |
leeming | although i disagree with the concept. sandboxlib interfaces are not strictly implemented and took me a while to fudge for bwrap. May be an issue there? i dont know | 14:56 |
tiagogomes_ | The former | 14:56 |
paulsher1ood | tiagogomes_: by reintroducing the sandboxing into ybd itself, then? | 14:56 |
leeming | but then again, afaik python doesn't support interfaces anyway? | 14:56 |
leeming | (or abstract classes) | 14:57 |
tiagogomes_ | paulsher1ood yes, but main reason was that it was a requirement for builds without being root | 14:57 |
leeming | how long ago was this branch done tiagogomes_ ? | 14:57 |
* paulsher1ood is surprised too... if he'd known someone else was doing this he wouldn't have asked leeming to do so | 14:58 | |
tiagogomes_ | it is a WIP, and I think about it more as a research experience | 14:58 |
paulsher1ood | does it work? :) | 14:58 |
tiagogomes_ | I started this after bubblewrap was added to sandboxlib | 14:59 |
leeming | well, i feel like ive been replicating loads of work lately | 14:59 |
leeming | o hok | 14:59 |
leeming | oh ok | 14:59 |
paulsher1ood | leeming: sounds more like you've been inspiring people :) | 14:59 |
leeming | you should speak with tristan then, he doesn't like sandboxlib either :P | 14:59 |
leeming | but like i said, i dont either, in code, but in concept i do | 14:59 |
* paulsher1ood would be happy enough to drop it... the original idea was that maybe morph and others would use it, but that isn't likely | 15:00 | |
leeming | i dont know what the original use case/ requirements were for it | 15:00 |
anahuelamo | Hi! I have two systems, both using the same bsp: bsp-x86_64-generic.morph and one it's failing but the other works fine. This is failing: https://gitlab.com/Huelamo/definitions/builds/5508372 and this is working: https://gitlab.com/Huelamo/definitions/builds/5508371 | 15:00 |
anahuelamo | does anyone have an idea why is this happening? | 15:01 |
locallycompact | yeah no and then you drop it and the next headache happens that we rewrite everything and suddenly wow I wish all this shit was in a library so I don't have to dismantle this thing | 15:01 |
pedroalvarez | sh: cd: line 1: can't cd to /usr/lib/modules | 15:01 |
locallycompact | and then the opposite again | 15:01 |
locallycompact | actually do it | 15:02 |
leeming | i agree with locallycompact , however.. the current status of sandboxlib is bascially "bubblewrap or chroot" ? | 15:02 |
pedroalvarez | anahuelamo: it looks like the system doesn't have the folder "/usr/lib/modules" | 15:02 |
leeming | is there any intention to ever add anything else? | 15:02 |
leeming | or just a matter of 'evolving' it, to encompassing the next bubblewrap? | 15:03 |
leeming | idk | 15:03 |
anahuelamo | pedroalvarez, but if both systems use the same bsp, why I just get the error in one of them? | 15:03 |
locallycompact | who knows | 15:03 |
leeming | did someone say there was random ordering sometimes? | 15:03 |
leeming | re-run? | 15:04 |
pedroalvarez | nope, this is deterministic | 15:04 |
pedroalvarez | this case | 15:04 |
pedroalvarez | assuming that they are using the same bsp: http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/strata/bsp-x86_64-generic/linux-x86-64-generic.morp | 15:05 |
*** franred has quit IRC | 15:05 | |
pedroalvarez | broken link sorry: http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/strata/bsp-x86_64-generic/linux-x86-64-generic.morph | 15:05 |
pedroalvarez | if you go line 294, you see that those system-integration commands are run for the -misc split of the artifact | 15:06 |
pedroalvarez | my guess is that the -misc split is not included in the minimal system, but it is in all the rest | 15:06 |
anahuelamo | I'll check, thanks pedroalvarez | 15:07 |
pedroalvarez | wait, I'm wrong | 15:07 |
pedroalvarez | minimal system is also trying to run the command | 15:08 |
pedroalvarez | but it looks like it doesn't have depmod, so not running it | 15:08 |
pedroalvarez | that is a bug in ybd | 15:09 |
anahuelamo | the only different thing that I can see now it's the order in which the strata all called, could be that? | 15:09 |
jjardon | Its intentionsl "- if which depmod; then (cd /lib/modules && for version in *; do depmod -a "$version"; done) fi" | 15:10 |
anahuelamo | s/all/are | 15:10 |
jjardon | intentional* | 15:10 |
pedroalvarez | and? | 15:11 |
leeming | sorry cross quoting here "maybe a racing condition in ybd" | 15:11 |
leeming | i remember a runner issue with parallel builds | 15:11 |
leeming | locallycompact, something with .gitlab.ci thiny and max-jobs ? | 15:12 |
locallycompact | that's s-i commands so it shouldn't matter | 15:12 |
pedroalvarez | i take back that it's a bug in ybd, i missunderstood definitions | 15:12 |
leeming | ah right | 15:13 |
pedroalvarez | so, mi final guess is that is not failing in the minimal system because it doesn't have `depmod` | 15:13 |
paulsher1ood | leeming: i'd be be *extremely* surprised if there's a race condition in ybd here, since it's single threading in both of anahuelamo's builds | 15:15 |
pedroalvarez | s/mi/my | 15:16 |
paulsher1ood | randomisation only happens on instances: > 1, and has been shown to work reliably for component builds, with the known exception that overlaps can cause problems during system assembly | 15:16 |
* paulsher1ood can't help thinking that he's seen this depmod thing before | 15:17 | |
leeming | paulsher1ood, it was just an idea, given we've seen similar strange things before | 15:17 |
leeming | in builds that is.... | 15:18 |
jjardon | the devel system builds fine, and it has depmod; anahuelamo can you try and move the bsp lower in the list of strata to build in the gnome system? | 15:19 |
*** jude_ has joined #baserock | 15:19 | |
anahuelamo | jjardon, sure | 15:19 |
* paulsher1ood wonders why the bsp is thougt to have anything to do with this | 15:21 | |
jjardon | paulsher1ood: depmod is run as a s-i command in bsp-*/linux*.morph; for the gnome system fails, but for the devel system, wich uses exactly the same definition, it success | 15:24 |
paulsher1ood | oh, ok. anahuelamo - are you working on definitions, or ybd, or both here? i notice you're not running mainline | 15:25 |
anahuelamo | paulsher1ood, I'm working on definitions | 15:25 |
*** ctbruce has quit IRC | 15:25 | |
paulsher1ood | anahuelamo: ok, so would you be ok using mainline ybd? that woudl at least remove one potential uncertainty | 15:26 |
paulsher1ood | or is there something in that branch you need... in which case i'm happy to look into it, test it, merge .... | 15:27 |
anahuelamo | paulsher1ood, I'm using a different branch in ybd to avoid conflicts after a /usr merge in definitions. I pointed out this before. tiagogomes_ made a branch in ybd to fix this problems | 15:29 |
*** toscalix has joined #baserock | 15:29 | |
paulsher1ood | anahuelamo: i must have missed/misunderstood the conversation then. pls can you raise an issue against ybd documenting the problem? and then i can crip tiagogomes_ solution :) | 15:30 |
paulsher1ood | s/crip/crib/ | 15:30 |
anahuelamo | maybe tiagogomes_ is the one that should raise an issue in ybd, given that he made the patch? | 15:33 |
* pedroalvarez doesn't understand how things work nowadays | 15:35 | |
tiagogomes_ | erm, I don't have much time, but I'll try to do it | 15:36 |
paulsher1ood | pedroalvarez: i agree it's confusing, we should try to iron things out | 15:37 |
tiagogomes_ | anyone using arch can show me the output of `ls -l /usr/bin/bwrap` | 15:38 |
locallycompact | -rwsr-sr-x 1 root root 39744 Sep 12 10:47 /usr/bin/bwrap | 15:39 |
tiagogomes_ | thanks locallycompact | 15:39 |
*** Guest21860 is now known as malinus | 15:49 | |
*** malinus has joined #baserock | 15:49 | |
pedroalvarez | i don't understand how moving the bsp lower in the list of strata would help? | 15:51 |
*** gtristan has joined #baserock | 15:52 | |
*** malinus has left #baserock | 15:57 | |
*** aren has left #baserock | 16:15 | |
*** aren has joined #baserock | 16:16 | |
jjardon | Hi, any idea what can be wrong here? https://gitlab.com/baserock/definitions/builds/5567582 (using current ybd master) | 16:57 |
paulsher1ood | jjardon: not running as root? | 17:07 |
jjardon | first thing I though, but its actually running as root: see the [ 0 -ne 0 ] line in the beggining of the log : "id -u" is 0, so its actually root | 17:08 |
paulsher1ood | that's onlty the install_dependencies? | 17:10 |
paulsher1ood | $ ybd/ybd.py systems/build-system-x86_64-chroot.morph x86_64 | 17:10 |
* paulsher1ood wonders why https://gitlab.com/baserock/ybd/pipelines/4761113 appears to be still 'running' | 17:16 | |
locallycompact | reads passed for me | 17:18 |
jjardon | seems like a bug | 17:20 |
paulsher1ood | oh, passwed for me too now | 17:20 |
* paulsher1ood notes that the arm server which runs artifacts1.baserock.org has been rocksolid for months | 17:29 | |
jjardon | working now! the issue was settting privileged = true in the [runners.docker] section of the config.toml file of the manager of the elastic runners | 17:35 |
*** jude_ has quit IRC | 17:37 | |
jjardon | this means we have our own elastic runners in gitlab.com/baserock/definitions now! | 17:39 |
*** locallycompact has quit IRC | 17:39 | |
paulsher1ood | cool! | 17:47 |
*** toscalix has quit IRC | 18:14 | |
*** rdale has quit IRC | 20:09 | |
*** gtristan has quit IRC | 20:16 | |
aren | I'm brand new to baserock. Can I build projects that have nested submodules? | 20:24 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!