IRC logs for #baserock for Friday, 2016-10-07

*** gtristan has joined #baserock05:01
*** gtristan has quit IRC06:29
*** gtristan has joined #baserock07:05
*** ctbruce has joined #baserock07:34
*** toscalix has joined #baserock07:49
*** rdale has joined #baserock08:11
pedroalvarezSotK: nice108:14
pedroalvarezI mean: nice!08:15
*** gtristan has quit IRC08:26
*** jjardon_matrix has quit IRC08:54
*** jjardon_matrix has joined #baserock09:07
*** gtristan has joined #baserock09:12
paulsherwoodi guess we should have a wholesale conversion of lorries to yaml soon?09:17
SotK\o/ thanks paulsherwood, franred09:17
* SotK would like that, I can send a patch which does it later if people want one?09:18
paulsherwoodyes please... but how will we test it? would be a shame to bork gbo by accident09:19
pedroalvarezthere are quite a few, and some of them are pointing to deprecated repos09:19
paulsherwoodsorry, quite a few what?09:20
pedroalvarezlorries in json09:20
* SotK will turn his vm into a trove and test it there09:20
franredSotK, given that you can use lorry to lorry locally, even if it is a huge task, could you create something that lorries them, one by one into a VM and mark them as succeed or failure?09:20
pedroalvarez"they are" maybe worked better09:20
franredSotK, yeah, same idea :)09:21
paulsherwoodpedroalvarez: ack. my concern was/is that we could apply the change, and maybe not notice some subtle fail, eg svn conversion no longer getting the right branches or similar09:23
*** locallycompact has joined #baserock09:23
pedroalvarezyes, that's my concern too09:27
pedroalvarezand it would be very easy to miss a failure given that they are too many09:28
gtristanleeming, since you've been looking into sandboxlib stuff of late, I had an idea that I've been pondering which might be of use09:28
pedroalvarezI guess that if we prove that python loads the same information from json and yml after the conversion, then we are good to go09:28
gtristanleeming, I asked last week about this I think in #python on freenode, if I wanted to ensure that all python code was loaded and in memory at some point, for the purpose of running code in a chroot where either a.) there is no python environment installed or b.) we dont want to trust/mix with the python environment in that chroot09:29
gtristanthe answer was that I should look into this thing called virtualenv
gtristansuch an approach where one might push a relocatable trusted python environment onto a mount point in a sandbox would allow running more complex python code in the sandbox, without horrible hacks like the one here:
gtristanleeming, possibly it's pie in the sky, but just wanted to hand that idea over09:31
paulsherwoodpedroalvarez: that sounds like a good idea. so maybe run lorry on all json lorries, dump the resulting dicts (sorted) to a yaml output file. Then repeat on the yaml lorries, and diff the output files?09:37
SotKthat sounds faster than turning my VM into a trove :)09:37
paulsherwoodi've used a similar approach for checking how ybd parses definitions09:40
* tiagogomes would prefer to see an admin page on the trove to add new lorries than YAMLizing lorries09:40
tiagogomesrather than09:41
paulsherwoodwhy can't we have both?09:41
SotKwhy not both?09:41
paulsherwoodand tiagogomes please feel free to create one :)09:41
tiagogomesYou can have both. But my point was more about lorries being added through a web page, instead of committing directly in a git repo09:44
SotKI somewhat like the fact that we enforce review on new lorries09:45
pedroalvarezof course09:45
pedroalvarezI can't imagine what could happend09:45
SotKto reduce the chance of duplicate lorries, or lorrying half the world on someone's whim09:46
pedroalvarezalso, the admin interface should only be available to the infra team09:46
tiagogomesYep, but is it really necessary to review lorries? An user would just ask an admin to add the lorry09:46
paulsherwoodactually, it would be better if there was a CI as part of the lorry review, to a) run lorry on it and b) highlight any similar names/content from gbo09:47
SotKthat seems a more annoying process than just sending a patch09:47
pedroalvareztiagogomes: send a patch to admin09:47
paulsherwooda) would be trivial in gitlab i think09:47
tiagogomesSotK there wouldn't be duplicate worries, because we would have input validation...09:47
paulsherwoodand would avoid some of the broken lorries i've 'reviewed' in the past :)09:47
tiagogomesthat ^09:47
paulsherwoodtiagogomes: SotK's comment still stands, we wouldn't want to start lorrying the world on a whim09:48
locallycompactI'd prefer editing definitions in a webview as well09:49
tiagogomesdefinitions are different, because it is something that you will use locally09:50
tiagogomespaulsherwood, the administrators can veto the request09:51
* SotK still doesn't see how pestering a person to make a change is any smoother than sending a patch to make the change yourself09:52
paulsherwood10:50 < tiagogomes> definitions are different, because it is something that you will use locally09:52
paulsherwoodtiagogomes: not necessarily. i think some folks here don't realise that definitions are for centralised projects too, not just local ones09:52
* paulsherwood agrees with SotK on this. a web page for adding lorries to downstream troves would be useful, but in practice i think gbo would still perfer patch review (after CI validataion)09:54
franredremember that it is difficult for svn projects for example. they do not have standard way to describe where branches and trunk live09:55
paulsherwoodfranred: i don't care about them much... git ftw :)09:55
paulsherwoodbut you're right of course09:55
tiagogomesOk. I don't have a strong opinion about this. Just food for thought :)09:56
locallycompactThis is the view I want for definitions
paulsherwoodtiagogomes: ack, and thanks for the input09:56
jmacsI like the seizure-inducing juddering as it starts up, locallycompact09:56
locallycompactme too09:57
locallycompactthat would have arrows in V10 version09:57
locallycompactlines are dependencies, boxes are assemblages09:57
leeminggtristan, interesting. I did wonder what the tradeoff is between having a mounted python env vs having it in memory... my simplistic view of this is to just have some trusted python bundled up on the host, (ideally contained within a common directory structure) and set that as an extra mount [ro]10:03
*** franred_ has joined #baserock10:04
locallycompactpython is printing out the stdout from executor.run_sandox() as "b'checking build system type... x86_64-unknown-linux-gnu\nchecking host system type"10:06
locallycompactwith \n and b10:06
locallycompacthow do I render that better10:06
*** franred has quit IRC10:07
tiagogomeslocallycompact thestring.decode('unicode-escape')10:08
locallycompacttiagogomes, worked, thanks!10:09
*** toscalix has quit IRC10:24
*** toscalix has joined #baserock10:58
*** CTtpollard has quit IRC11:29
*** toscalix has quit IRC11:36
*** toscalix has joined #baserock11:39
gtristanleeming, my python-foo is not very existent especially in terms of how it's implemented under the hood, but after having made some inquiries I'm relatively sure one cannot just assert that "after this point, everything my program will access via import statements etc is loaded into memory, and no disk access will be required", if that's what you mean by having it in memory12:15
gtristanwhich is why I thought the virtualenv thing might help, however; it's only really needed once you want to do complex things in your chroot environment; the existing sandboxlib code with it's ugly hack is enough to run shell commands12:16
*** franred_ has quit IRC12:20
*** franred has joined #baserock12:51
leemingim not sure if i actually copied that ugly hack into the bwrap implementation13:05
*** toscalix has quit IRC13:10
*** gtristan has quit IRC13:10
locallycompactWhat would make a suitable assemblage name for the non-bsp parts of minimal-system13:41
locallycompacti.e reuse of build-essential. core, etc13:42
*** toscalix has joined #baserock13:50
* paulsherwood does not understand the question13:58
leemingdoes anyone know what is used in /dev inside the sandbox when running ybd? Not sure if it needs to map to the host /dev or if just a directory called /dev that is treated as a normal dir?13:59
leemingas i am currently getting permission errors when mounting host /dev13:59
paulsherwoodit shouldn't need host /dev, beyond stage1 and stage2, iirc13:59
paulsherwoodmaybe not even then14:00
leemingybd source disagrees14:00
leemingoh sorry, after bootstrap14:00
locallycompactpaulsherwood, base-system-x86_32-generic would not be able to include minimal-system-x86_64-generic as a component, because of the bsp. What do we call the collection of minimal strata sans any bsp, so that it may be a base collection contained in all systems14:01
leeminghmm so during bootstrap, it is using host /dev... else it creates a sandbox wr /dev14:01
*** ctbruce has quit IRC14:03
* paulsherwood hasn't tried bootstrap, so doesn't know about that path14:08
leemingok, will play around wiht it to see what works14:09
paulsherwoodlocallycompact: i was hoping (and proposed, a couple of years ago) that we'd get to (say) base-system.morph, which would include various target: options (iincluding say jetson:, wandboard: x86_generic: - and have the specific bsps defined there)14:10
paulsherwoodthis doesn't answer your question i guess. could we create a new name, eg base-stack?14:11
paulsherwoodand then base-system = base-stack + arch-specific stuff?14:11
* locallycompact goes with that14:12
locallycompactsent, have at it14:16
*** toscalix_ has joined #baserock14:16
*** ctbruce has joined #baserock14:19
*** toscalix has quit IRC14:20
*** jjardon has quit IRC14:22
*** tardyp has quit IRC14:22
*** jjardon has joined #baserock14:26
*** tardyp has joined #baserock14:30
leemingwhat exactly does lstat doing? I am getting permission errors
leemingit is trying to set the st_mode to 857614:39
leemingwhich, looking at the man pages, suggests the '8' isn't a valid setting anyway14:40
leemingas 7 is the max OR of the 3bit options14:40
jmacsThere's bits in file permissions  other than the 3x3 permission bits14:42
leemingbut isn't the left most, the 'sticky bit' etc for directories? but maxes at 7 also14:43
leeming S_ISUID     04000   set-user-ID bit14:43
leeming           S_ISGID     02000   set-group-ID bit (see below)14:43
leeming           S_ISVTX     01000   sticky bit (see below)14:43
jmacsYeah, I don't know what 08000 is14:44
leemingman page doesn't mention it14:44
leemingbut clearly is reserved for something14:44
jmacsIt's not in the linux 3.16 headers either14:45
jmacsNo, wait, it's S_IFREG, I think14:46
jmacsNo :) S_IFIFO14:46
jmacsDamn octal14:47
leemingah, named pipe?14:47
jmacsWhen you said st_mode was 8576, is that really in octal?14:48
leemingi wonder if that is the bit that is causing permission errors then14:48
leemingi assumed it was14:48
jmacs'8' isn't usually an octal digit...14:48
jmacsI'd check that first14:50
*** toscalix_ has quit IRC15:00
*** ctbruce has quit IRC15:07
*** toscalix_ has joined #baserock15:17
paulsherwoodany objection to merging ?15:36
paulsherwoodit's a new extension, won't hurt any existing definitions afaict15:36
*** lachlanmackenzie has quit IRC15:48
*** toscalix_ has quit IRC15:51
*** toscalix_ has joined #baserock15:51
*** locallycompact has quit IRC16:33
*** rdale has quit IRC16:38
*** rdale has joined #baserock16:39
*** franred has quit IRC16:48
*** rdale has quit IRC17:04
*** anahuelamo_ has joined #baserock17:05
*** anahuelamo__ has joined #baserock17:07
*** anahuelamo_ has quit IRC17:07
*** anahuelamo_ has joined #baserock17:08
*** anahuelamo__ has quit IRC17:11
*** tiagogomes has quit IRC17:11
*** lachlanmackenzie has joined #baserock17:55
*** lachlanmackenzie has quit IRC18:15
*** locallycompact has joined #baserock18:42
*** locallycompact has quit IRC18:56
*** anahuelamo_ has quit IRC18:56
*** JPohlmann has quit IRC18:57
*** bfletcher has quit IRC18:57
*** JPohlman1 has joined #baserock18:57
*** locallycompact has joined #baserock18:57
*** anahuelamo_ has joined #baserock18:57
*** bfletcher has joined #baserock19:05
*** locallycompact has quit IRC19:08
*** jjardon has quit IRC19:08
*** jjardon has joined #baserock19:16
*** toscalix_ has quit IRC19:18
*** tardyp has quit IRC19:18
*** radiofree has quit IRC19:19
*** radiofree has joined #baserock19:19
*** toscalix_ has joined #baserock19:19
*** tardyp has joined #baserock19:27
*** toscalix_ has quit IRC19:28
*** persia has quit IRC19:32
*** persia has joined #baserock19:32
*** jjardon_matrix has quit IRC19:33
*** faybrocklebank has quit IRC19:33
*** JasonA has quit IRC19:33
*** faybrocklebank has joined #baserock19:33
*** JasonA has joined #baserock19:33
*** jjardon_matrix has joined #baserock19:43
*** leeming has quit IRC19:47
*** juergbi has quit IRC19:47
*** rjek has quit IRC19:47
*** anahuelamo has quit IRC19:47
*** bjdooks has quit IRC19:47
*** _longines has quit IRC19:47
*** malinus has quit IRC19:48
*** cyndis has quit IRC19:48
*** paulsherwood has quit IRC19:48
*** perryl has quit IRC19:48
*** malinus has joined #baserock19:48
*** juergbi has joined #baserock19:48
*** leeming has joined #baserock19:48
*** _longines has joined #baserock19:48
*** perryl has joined #baserock19:48
*** cyndis has joined #baserock19:48
*** anahuelamo has joined #baserock19:48
*** paulsherwood has joined #baserock19:48
*** malinus is now known as Guest4252519:48
*** jjardon has quit IRC19:49
*** rjek has joined #baserock19:50
* SotK grumbles about the lack of a --dry-run or similar for lorry19:51
SotKare folk happy with me running the .lorry files through a script which replicates the loading part of lorry/lorry-controller instead of lorrying everything in g.b.o?19:53
*** bjdooks has joined #baserock19:53
*** vgrade has quit IRC19:56
*** vgrade has joined #baserock19:56
*** jjardon has joined #baserock19:59
*** anahuelamo_ has quit IRC20:05
*** brlogger has joined #baserock20:11
*** persia_ has quit IRC20:22
*** pedroalvarez has quit IRC20:22
*** dabukalam has quit IRC20:22
*** pedroalvarez has joined #baserock20:22
*** ChanServ sets mode: +v pedroalvarez20:22
*** dabukalam has joined #baserock20:23
*** persia_ has joined #baserock20:23
*** locallycompact has joined #baserock20:26
*** jjardon has quit IRC20:30
*** jjardon has joined #baserock20:30
*** locallycompact has quit IRC20:32
*** dabukalam has quit IRC20:33
*** benbrown_ has quit IRC20:33
*** cosm has quit IRC20:33
*** vgrade has quit IRC20:33
*** juergbi has quit IRC20:33
*** Guest42525 has quit IRC20:33
*** JasonA has quit IRC20:33
*** perryl has quit IRC20:33
*** leeming has quit IRC20:33
*** jjardon_matrix has quit IRC20:33
*** bfletcher has quit IRC20:33
*** jjardon has quit IRC20:33
*** cyndis has quit IRC20:33
*** _longines has quit IRC20:33
*** persia has quit IRC20:33
*** JPohlman1 has quit IRC20:33
*** inara` has quit IRC20:33
*** rjek has quit IRC20:33
*** jjardon has joined #baserock20:38
*** cyndis has joined #baserock20:38
*** _longines has joined #baserock20:38
*** persia has joined #baserock20:38
*** JPohlman1 has joined #baserock20:38
*** perryl has joined #baserock20:39
*** leeming has joined #baserock20:39
*** jjardon_matrix has joined #baserock20:39
*** bfletcher has joined #baserock20:39
*** dabukalam has joined #baserock20:39
*** benbrown_ has joined #baserock20:39
*** cosm has joined #baserock20:39
*** vgrade has joined #baserock20:39
*** juergbi has joined #baserock20:39
*** Guest42525 has joined #baserock20:39
*** JasonA has joined #baserock20:39
*** inara` has joined #baserock20:40
*** rjek has joined #baserock20:40
* SotK sends and
SotKwe shouldn't merge the second one without first merging the lorry-controller patch ( and updating git.b.o though21:16
SotK(on pain of everything breaking horribly)21:16
*** zoli_ has joined #baserock21:21
*** gtristan has joined #baserock21:40
*** jjardon has quit IRC21:52
*** jjardon has joined #baserock21:58
*** jjardon has quit IRC22:03
*** jjardon has joined #baserock22:11
*** jjardon has quit IRC23:00
*** jjardon has joined #baserock23:21
*** gtristan has quit IRC23:33

Generated by 2.15.3 by Marius Gedminas - find it at!