IRC logs for #baserock for Wednesday, 2016-10-26

*** rdale_ct has joined #baserock04:27
*** rdale has quit IRC04:30
*** gtristan has joined #baserock05:37
*** gtristan has quit IRC05:39
*** gtristan has joined #baserock05:39
*** ctbruce has joined #baserock07:32
*** rdale_ct has quit IRC07:44
*** rdale has joined #baserock07:53
*** rdale has quit IRC08:08
*** jude_ has joined #baserock08:14
*** franred has joined #baserock08:16
*** rdale has joined #baserock08:18
*** toscalix has joined #baserock08:19
jjardontiagogomes_: hi! You have upgraded gcc before, I wonder if you have tried the branch to upgrade to gcc6 recently?09:20
pedroalvarezis this the branch I created?09:22
pedroalvarezit would be good to give it a try again09:23
pedroalvarezthe error I hit was a really weird one that we should investigate if we hit it again09:23
jjardonYes09:23
jjardonIIRC, one of the problems is syslinux, again09:24
pedroalvareznope, that wasn't a problem09:24
pedroalvarezor if it was, i worked around it09:25
pedroalvarezyep, this was the workaround: http://git.baserock.org/cgit/delta/syslinux.git/log/?h=baserock/pedroalvarez/gcc609:25
jjardonAh, cool09:32
*** locallycompact has joined #baserock09:33
tiagogomes_jjardon, no I didn't try09:37
tiagogomes_So that branch doesn't build ?09:37
pedroalvarezit builds, or used to09:38
pedroalvarezit had runtime problems09:38
pedroalvarezpython broken because libffi was broken09:38
pedroalvarezand if you re-compiled libffi in the deployed system, everything worked fine09:39
pedroalvarezso, something weird was going on in my testing09:39
jjardonIt 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 changes09:40
*** CTtpollard has joined #baserock09:41
tiagogomes_Gitlab only tests x86_64 right?09:41
pedroalvarezhow do I go from branch to CI results in gitlab?09:43
pedroalvareztook me a while..  :/09:45
jjardontiagogomes_: yep, until we setup ARM runners09:47
tiagogomes_and Power, x86_3209:47
pedroalvareznot sure about power09:48
tiagogomes_Is the opestack system being tested on gitlab ?09:48
pedroalvarezbuilt? yes09:48
tiagogomes_mm, building tftp-hpa is failing to me09:48
pedroalvarezmeh10:03
* pedroalvarez gives up trying to make gitlab test a branch10:03
locallycompactpedroalvarez, it should just run atuomatically10:04
locallycompactpedroalvarez, what branch10:04
pedroalvarezI pushed this branch https://gitlab.com/palvarez89/definitions/commits/baserock/pedroalvarez/gcc6-210:05
pedroalvarezalso commited a change to this one https://gitlab.com/baserock/definitions/commits/baserock/pedroalvarez/gcc610:05
locallycompactis there a .gitlab-ci.yml file in that branch10:05
pedroalvarezcrap10:06
locallycompactnop10:06
pedroalvarezthat's it...10:06
*** toscalix has quit IRC10:42
*** toscalix has joined #baserock10:55
pedroalvarezjjardon: maybe we could go first to 6.1 if 6.2 is going to have more problems11:05
jjardonpedroalvarez: sure11:44
paulsher1oodtiagogomes_: are you ok with me dropping https://gitlab.com/baserock/ybd/merge_requests/254 based on the multi-instance requirement?11:54
jjardonpedroalvarez: stage2-glibc seems to fail: https://gitlab.com/baserock/definitions/builds/555154311:57
jjardonpedroalvarez:  this is the bracnh Im using: https://gitlab.com/baserock/definitions/commits/jjardon/gcc6.111:58
pedroalvarezhm..11:58
pedroalvarezthe branch I pushed a while back builds that fine: https://gitlab.com/palvarez89/definitions/builds/555069511:58
jjardonah, Im missing the --disable-werror for glibc in my branch12:04
*** gtristan has quit IRC12:19
*** CTtpollard has quit IRC12:19
*** CTtpollard has joined #baserock12:21
*** paulw has joined #baserock12:29
tiagogomes_paulsher1ood I would like to rework the patch, but you can drop it for now12:40
paulsher1oodtiagogomes_: np i'll look forward to your rework13:23
jjardonmmm, any idea why Im getting this failure? "RuntimeError: ['mount', '-t', '', '-o', '', '/dev', '/dev'] failed: mount: unknown filesystem type '' https://gitlab.com/baserock/definitions/builds/555476013:44
jjardonIs it because the runner should have btrfs support?13:45
leemingshould it be using linux-user-chroot anyway?13:47
leemingnot sure if normal chroot removes capabilities13:48
leemingi expect it does13:48
tiagogomes_jjardon because '-o' is an invalid mount type13:49
leeming^well yes.. but i thinkg there is a real reason why '' was selected instead of something sensible13: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 IRC14:19
paulsher1oodjjardon: pls can you try wth 16.42 ?14:21
* paulsher1ood merged a patch earlier today featuring /dev... maybe he shouldn't have14:22
jjardonsure, one sec14:22
jjardonpaulsher1ood: 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 IRC14:35
jjardonpaulsher1ood: 16.42 seems to build fine: https://gitlab.com/baserock/definitions/builds/556146514:38
jjardonpaulsher1ood: how can I tell ybd to not use the kbas server?14:39
jjardonset kbas-url to "" ?14:39
paulsher1oodkbas-url: "foo"14:40
paulsher1oodi suggest do both14:40
jjardonyeah14:40
paulsher1oodbut not the whole of ci.morph :)14:40
jjardonnope, only the minimal system14:42
paulsher1oodleeming: i'm guessing your /dev patch doesn't work ? :/14:42
leemingperhaps. did someone test it, other than me?14:43
jjardonleeming: did you build any system with it?14:44
leemingis this related to jjardon's issue? I wonder if you tried the linux-user-chroot method?14:44
leemingyes14:44
leemingapart from building a system, there isn't another test to run for ybd right?14:45
paulsher1oodleeming: it depends what you're changing14:46
jjardonleeming: I meant without using the kbas cache server14:46
jjardonso everything gets build14:46
leemingoh, i have no idea about the kbas cache14:46
leemingi did a full build, clearled the ybd folder14:47
paulsher1oodleeming: if you didn't override kbas-url, you may have not actually built any component14:48
leemingi did not over-ride kbas no.. but i set "artifact-version: 77" which i understand means it never gets a remote copy?14:48
leemingstandard config does not upload, correct?14:49
paulsher1oodoh, correct. yes overriding artifact-version also works14:49
paulsher1oodwell, for some reason jjardon can not build any longer, and i think the reason is              extra_mounts=[('/dev', '/dev', None)],14:51
leeminggood, i understand something then :P \o/14:51
leemingas suggested, can he run it with linux-user-chroot? out of interest14:51
leemingbut yes, that is a possible issue with the fix, running on older sandbox implementations14:51
leemingi had not looked at chroot in sandboxlib14:52
jjardonleeming: give me one sec14:52
leemingbut feel free to roll back14:52
* paulsher1ood is happy to do that, or wait for a fix14:53
leemingi wonder how chroot accesses /dev then, if it isn't mounted?14:53
leemingis there some smaller systems to build for testing ybd?14:54
* tiagogomes_ has a branch where he scraps sandboxlib14:54
leemingso that i could at least force all 3 sandboxes14:54
leemingis this a new thing tiagogomes_ ?14:54
paulsher1oodtiagogomes_: you mean scrap sandboxlib, or scrap sandboxing altogether?14:55
leemingtristan had suggested something similar14:55
paulsher1oodleeming: 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
leemingalthough 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 know14:56
tiagogomes_The former14:56
paulsher1oodtiagogomes_: by reintroducing the sandboxing into ybd itself, then?14:56
leemingbut 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 root14:57
leeminghow 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 so14:58
tiagogomes_it is a WIP, and I think about it more as a research experience14:58
paulsher1ooddoes it work? :)14:58
tiagogomes_I started this after bubblewrap was added to sandboxlib14:59
leemingwell, i feel like ive been replicating loads of work lately14:59
leemingo hok14:59
leemingoh ok14:59
paulsher1oodleeming: sounds more like you've been inspiring people :)14:59
leemingyou should speak with tristan then, he doesn't like sandboxlib either :P14:59
leemingbut like i said, i dont either, in code, but in concept i do14: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 likely15:00
leemingi dont know what the original use case/ requirements were for it15:00
anahuelamoHi! 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/550837115:00
anahuelamodoes anyone have an idea why is this happening?15:01
locallycompactyeah 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 thing15:01
pedroalvarezsh: cd: line 1: can't cd to /usr/lib/modules15:01
locallycompactand then the opposite again15:01
locallycompactactually do it15:02
leemingi agree with locallycompact , however.. the current status of sandboxlib is bascially "bubblewrap or chroot" ?15:02
pedroalvarezanahuelamo: it looks like the system doesn't have the folder "/usr/lib/modules"15:02
leemingis there any intention to ever add anything else?15:02
leemingor just a matter of 'evolving' it, to encompassing the next bubblewrap?15:03
leemingidk15:03
anahuelamopedroalvarez, but if both systems use the same bsp, why I just get the error in one of them?15:03
locallycompactwho knows15:03
leemingdid someone say there was random ordering sometimes?15:03
leemingre-run?15:04
pedroalvareznope, this is deterministic15:04
pedroalvarezthis case15:04
pedroalvarezassuming 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.morp15:05
*** franred has quit IRC15:05
pedroalvarezbroken link sorry: http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/strata/bsp-x86_64-generic/linux-x86-64-generic.morph15:05
pedroalvarezif you go line 294, you see that those system-integration commands are run for the -misc split of the artifact15:06
pedroalvarezmy guess is that the -misc split is not included in the minimal system, but it is in all  the rest15:06
anahuelamoI'll check, thanks pedroalvarez15:07
pedroalvarezwait, I'm wrong15:07
pedroalvarezminimal system is also trying to run the command15:08
pedroalvarezbut it looks like it doesn't have depmod, so not running it15:08
pedroalvarezthat is a bug in ybd15:09
anahuelamothe only different thing that I can see now it's the order in which the strata all called, could be that?15:09
jjardonIts intentionsl "- if which depmod; then (cd /lib/modules && for version in *; do depmod -a "$version"; done) fi"15:10
anahuelamos/all/are15:10
jjardonintentional*15:10
pedroalvarezand?15:11
leemingsorry cross quoting here "maybe a racing condition in ybd"15:11
leemingi remember a runner issue with parallel builds15:11
leeminglocallycompact, something with .gitlab.ci thiny and max-jobs ?15:12
locallycompactthat's s-i commands so it shouldn't matter15:12
pedroalvarezi take back that it's a bug in ybd, i missunderstood definitions15:12
leemingah right15:13
pedroalvarezso, mi final guess is that is not failing in the minimal system because it doesn't have `depmod`15:13
paulsher1oodleeming: 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 builds15:15
pedroalvarezs/mi/my15:16
paulsher1oodrandomisation 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 assembly15:16
* paulsher1ood can't help thinking that he's seen this depmod thing before15:17
leemingpaulsher1ood, it was just an idea, given we've seen similar strange things before15:17
leemingin builds that is....15:18
jjardonthe 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 #baserock15:19
anahuelamojjardon, sure15:19
* paulsher1ood wonders why the bsp is thougt to have anything to do with this15:21
jjardonpaulsher1ood: 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 success15:24
paulsher1oodoh, ok. anahuelamo - are you working on definitions, or ybd, or both here? i notice you're not running mainline15:25
anahuelamopaulsher1ood, I'm working on definitions15:25
*** ctbruce has quit IRC15:25
paulsher1oodanahuelamo: ok, so would you be ok using mainline ybd? that woudl at least remove one potential uncertainty15:26
paulsher1oodor is there something in that branch you need... in which case i'm happy to look into it, test it, merge ....15:27
anahuelamopaulsher1ood, 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 problems15:29
*** toscalix has joined #baserock15:29
paulsher1oodanahuelamo: 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
paulsher1oods/crip/crib/15:30
anahuelamomaybe 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 nowadays15:35
tiagogomes_erm, I don't have much time, but I'll try to do it15:36
paulsher1oodpedroalvarez: i agree it's confusing, we should try to iron things out15: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/bwrap15:39
tiagogomes_thanks locallycompact15:39
*** Guest21860 is now known as malinus15:49
*** malinus has joined #baserock15:49
pedroalvarezi don't understand how moving the bsp lower in the list of strata would help?15:51
*** gtristan has joined #baserock15:52
*** malinus has left #baserock15:57
*** aren has left #baserock16:15
*** aren has joined #baserock16:16
jjardonHi, any idea what can be wrong here? https://gitlab.com/baserock/definitions/builds/5567582 (using current ybd master)16:57
paulsher1oodjjardon: not running as root?17:07
jjardonfirst 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 root17:08
paulsher1oodthat's onlty the install_dependencies?17:10
paulsher1ood$ ybd/ybd.py systems/build-system-x86_64-chroot.morph x86_6417:10
* paulsher1ood wonders why https://gitlab.com/baserock/ybd/pipelines/4761113 appears to be still 'running'17:16
locallycompactreads passed for me17:18
jjardonseems like a bug17:20
paulsher1oodoh,  passwed for me too now17:20
* paulsher1ood notes that the arm server which runs artifacts1.baserock.org has been rocksolid for months17:29
jjardonworking now! the issue was settting privileged = true in the [runners.docker] section of the config.toml file of the manager of the elastic runners17:35
*** jude_ has quit IRC17:37
jjardonthis means we have our own elastic runners in gitlab.com/baserock/definitions now!17:39
*** locallycompact has quit IRC17:39
paulsher1oodcool!17:47
*** toscalix has quit IRC18:14
*** rdale has quit IRC20:09
*** gtristan has quit IRC20:16
arenI'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!