IRC logs for #baserock for Monday, 2014-12-01

*** pedroalvarez [~quassel@ec2-54-191-112-126.us-west-2.compute.amazonaws.com] has joined #baserock00:09
Mode #baserock +v pedroalvarez by ChanServ00:09
Mode #baserock +nt by orwell.freenode.net00:09
Mode #baserock +o pedroalvarez by ChanServ00:12
*** genii [~quassel@ubuntu/member/genii] has joined #baserock00:41
*** elevenarms____ [~elevenarm@58.251.146.229] has joined #baserock00:58
*** elevenarms____ [~elevenarm@58.251.146.229] has quit [Ping timeout: 244 seconds]01:03
*** elevenarms____ [~elevenarm@43.249.130.14] has joined #baserock01:08
*** elevenarms____ [~elevenarm@43.249.130.14] has quit [Remote host closed the connection]01:09
*** elevenarms____ [~elevenarm@43.249.129.254] has joined #baserock01:11
*** persia_ [quassel@ubuntu/member/persia] has quit [Ping timeout: 244 seconds]01:41
*** persia [quassel@ubuntu/member/persia] has quit [Ping timeout: 258 seconds]01:41
*** persia [quassel@ubuntu/member/persia] has joined #baserock01:43
*** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has joined #baserock01:43
*** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has quit [Changing host]01:43
*** persia_ [quassel@ubuntu/member/persia] has joined #baserock01:43
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer]01:58
*** elevenarms_____ [~elevenarm@103.27.224.205] has joined #baserock02:50
*** elevenarms____ [~elevenarm@43.249.129.254] has quit [Ping timeout: 240 seconds]02:51
*** elevenarms______ [~elevenarm@192.64.7.133] has joined #baserock03:20
*** elevenarms_____ [~elevenarm@103.27.224.205] has quit [Ping timeout: 250 seconds]03:24
*** elevenarms______ [~elevenarm@192.64.7.133] has quit [Ping timeout: 256 seconds]03:28
*** elevenarms______ [~elevenarm@183.11.243.87] has joined #baserock03:28
*** elevenarms______ [~elevenarm@183.11.243.87] has quit [Ping timeout: 272 seconds]04:08
*** elevenarms______ [~elevenarm@43.249.130.227] has joined #baserock04:09
*** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock07:52
*** fay [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock08:29
fay is now known as Guest1762508:29
*** rdale [~quassel@host86-143-211-156.range86-143.btcentralplus.com] has joined #baserock08:30
*** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:07
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:07
mike is now known as Guest4010809:07
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:11
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:11
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit]09:13
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:13
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:22
*** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:29
*** Guest40108 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds]09:35
*** Guest40108 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:49
*** elevenarms______ [~elevenarm@43.249.130.227] has quit [Ping timeout: 264 seconds]10:01
*** elevenarms______ [~elevenarm@128.90.88.80] has joined #baserock10:01
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock10:02
*** Guest40108 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]10:04
*** sherm_ [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock10:04
*** sherm_ [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 256 seconds]10:09
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock10:09
Mode #baserock +v ssam2 by ChanServ10:09
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection]10:17
Guest17625 is now known as fay_10:17
*** sherm_ [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock10:18
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock10:21
persiapaulsher1ood: My understanding was that the different morph in cross-bootstrap is a side effect of large strata.  It not being updated before has been reported as an issue by folk using cross-bootstrap.10:23
persiaNote that there exists a counter-argument to always updating cross-bootstrap, that being that cross-bootstrap should only be updated when tested: blind updates have been reported as problematic by folk using cross-bootstrap as well.10:25
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock10:29
pedroalvarezI'd prefer to have it up-to-date, but also I'd like to test cross-bootstrap more fequently10:29
* persia as well10:30
ssam2our mason instances both show lots of 'NONET' errors10:34
ssam2the git server on git.baserock.org seems OK, though (if a bit slow)10:34
ssam2oh, this is the old trap where "no news is good news"10:35
ssam2all the errors are from yesterday and the log shows it's working again now.10:36
tlsatbh, it shouldn't be too hard to clarify that on the generated page.  But the intention was to replace it altogether, rather than polish those shell scripts firther10:37
tlsa*further10:37
pedroalvarezssam2: yeah, there were some problems with the network where the masons are10:39
franredjjardon, why did you replace connectivity stratum by connman-common in enligthnment and virtualization strata? (see commit: 4ef19a1e85252a5d319d0b7158b1bdf3115a674c)10:50
pedroalvarezfranred: that commit looks ok10:52
pedroalvarezhe is replacing just the build dependency10:52
pedroalvarezand in the systems where connectivity was, he added also connman-common10:53
pedroalvarezfranred: have you spotted any error regarding this change>?10:54
franredpedroalvarez, ummm, ok, having a look at it looks sensible10:55
franreds/it/it once again/10:55
pdarheya, I'm trying to update some software on a system I'm using, but the sw on g.b.o is not up to date. This seems to be because the projects have moved their project to github. eg. https://code.google.com/p/leveldb/10:58
pdari guess that to fix this the lorry files migth need updating??10:58
pdarHow can I go about checkign wheter this is what needs to be done?10:59
pedroalvarezpdar: yes, or adding a new one10:59
radiofreelibusbx has moved as well10:59
pedroalvarezpdar: you can explore the lorries, and check from where are we lorrying11:00
pedroalvarezpdar: and if you consider that we need to update some, send a patch requesting the update11:01
pedroalvarezpdar: like this: http://paste.baserock.org/kusibutobu.diff11:02
petefoth re: different ways of entering parameters for write extensions (http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-November/009841.html) - I could a: add bolierplate to *each* extension , b: add some words to the help text in `deploy_pugin.py, or c: both. Any preferences?11:02
petefothrichard_maw: SotK: ^^11:03
ssam2pdar: have you worked with .lorry files before ? If not http://wiki.baserock.org/Trove/reference/#index4h2 should be at least a bit useful11:03
richard_mawpetefoth: I'd probably just go with adding the help text to deploy_plugin.py11:04
ssam2petefoth: duplication is generally bad. Perhaps add the words to the help text in `morph deploy`, and add a single line of boilerplate to each .help file saying "There are several ways to specify these options, see `morph help deploy` for details."11:04
richard_mawsince presumably if someone's looking for help with a specific write extension, they'll have tried `morph help deploy` first11:04
petefothrichard_maw: ssam2:  thanks! Detail in morph help deploy with a single line in each plugin WFM11:05
pdarpedroalvarez: Great, thanks. I shall check the lorries and act accordingly.11:06
pdarssam2: I have, but only briefly. Thanks for the link!11:07
pdarWhere abouts do the lorry files for g.b.o live?11:10
richard_mawhttp://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/11:11
pdarahh, http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/11:11
pdarsnap, thanks richard_maw 11:12
pedroalvarezradiofree: hey! I thought that to get an armv7lhf rootfs you could use the jetson image or the wanboard image11:32
pedroalvarezradiofree: do you find adding a rootfs-only system useful? why?11:32
radiofreepedroalvarez: yes you can but it would contain the kernel11:33
radiofreeplus a load of nouveau crap, the wandboard image would be lighter11:33
radiofreewell nouveau isn't crap! i mean it's not needed on a rootfs image11:33
ssam2it is kind of weird when explaining people who want a generic ARM rootfs that they must use the one labelled 'wandboard'11:33
ssam2but provide their own kernel11:33
radiofreewe also don't provide a tarball anymore on the website11:33
radiofreealso "Download Baserock" should be prominent, i can never find it11:35
radiofreequick start -> set up the development VM ->  'Create a Development VM' guide -> Download the VM image11:35
radiofreeoh right there's a "Get Baserock" link in the menu11:36
perryli've noticed the search results page on the wiki has the old sidebar, is there any way to change that?11:37
perrylpetefoth ^^11:37
petefothperryl: url for the ‘Search results page’11:37
Krinok, if i'm making a .service file for baserock that i want included in the deployment, do i have to put said file into the trove so that it can be grabbed if the deployment wants to also be obtainable by someone else? and if so where do i put it, is there a specific spot for .system files?11:37
radiofreepedroalvarez: but yeah, you can just release the wandboard image as a tarball11:37
radiofreejust call the filename "rootfs" instead of "wandboard"11:38
persiaradiofree: Separately from the "why rootfs" discussion: why a "devel" image?  SHouldn't "build "be smaller, faster to download, and sufficient?11:38
radiofreebut if someone wanted to deploy it themselves they'd have to needlessly sit through an i.mx kernel build, since that won't be cached11:38
radiofreepersia: i don't actually know what a build system is :\11:38
pedroalvarezradiofree: true. I just wanted to know the reasons :) that's all11:39
persiaradiofree: It is intended as a minimal system capable of building other systems.  "devel" has a bunch of extra stuff to make developers happy.11:39
perrylpetefoth: generally? i'm guessing http://wiki.baserock.org/ikiwiki.cgi?P=11:39
petefothperryl: got it. I’ll check11:39
radiofreehmm well, i think devel system suits a rootfs image better then11:39
* persia rather wishes that nobody thought of systems in terms of "kernel" and "rootfs", as it encourages all the wrong behaviours when both building filesystems and building kernels11:39
* petefoth has never used the search’ facility on w.b.o11:40
persiaradiofree: But it's *bigger*.  If people need devel, should they not download build, and then upgrade to devel?11:40
radiofreepersia: that would take ages11:40
persiaI guess.  I wonder how many people really need devel on a target board.11:41
radiofreewell maybe not so long with cache.baserock.org11:41
persiaIsn't it easier to do development on laptop, and deploy to a target board?11:41
radiofreeso if i want to, for example, build a bsp for a board11:41
perrylpetefoth: i think search only returns commit logs presently11:41
radiofreewill i have enough tools in a build system to try that out?11:41
persiaYes.11:42
franredKrin, you can install that systemd service from inside your chunk, http://paste.baserock.org/nexihebete.cmake11:42
radiofreewouldn't it have been better to make the devel systems smaller then, rather than introduce a build system?11:42
Krinfranred, does this create the firle? or is this an installation of the file itself? 11:44
Krinthat paste mostly confuses me but fill me with an odd sence of hope.11:45
Krinoh! damnit i', an idiot, first i need to add the programs that i'll be running to the trove >.<11:45
persiaradiofree: The "build" system was created because of feature-creep in the "devel" system.  Some folk want more useful CLI tools, the ability to lorry locally, etc.  Others want a small system to build things.  It isn't easy to have both.11:46
jjardonfranred: IIRC, connectivity was splitted in connectivitty and connman-common so you can use networkmanager or connman11:46
radiofreeok i'll -1 my own patches then11:47
franredKrin, Im confused about what you want to do... you don't need the trove to create a .service11:47
franredKrin, what do you want to do?11:48
Krini may be using the trove incorrectly terminology wise, but i'v started halfway through on this, i first need to put the programs that i want the .services to run somewhere that baserock can grab them.11:48
petefothperryl: no idea! I have asked in another channel11:49
franredKrin, do you mean that you need that your Baserock system initializes/runs your applications when the system boots?11:50
Krinyes, but at the moment the program that i want to run is not part of baserock XD11:50
Krini thought i'd already done some stuff that i have not done11:50
franredKrin, then what do you have to do is a systemd unit, so you need to tell systemd where are your applications and it will run for you11:51
Krinfirst i need to know how to make a program i have made availiable to baserock11:51
perrylpetefoth: no worries, i'm not sure how used the search function is, just concerned about consistency across w.b.o11:51
franredKrin, you have a repository, you create a chunck for that repository where you compile and install your application, then you create a systemd unit for running it on boot11:52
petefothperryl: it’s a good spot - thanks for pointing it out. Consistency is important IMHO11:52
Krinyes, i need to know how to put it in a repository that baserock can get to, it's on github, can baserock access that ok or do i need a lorry job?11:52
franredKrin, if it is just a test you can use your github repository11:53
franredrepo: github:myrepo11:53
Krinwell, the idea is for it to be a proof of concept, but i'll cross that bridge when my brain has woken up11:55
franredKrin, then use github11:55
ssam2note that 'github:' is a keyed URL shortcut that happens to be built into morph's default 'repo-alias' config setting, you can also use a full URL like https://github.com/me/myrepo11:55
franredwe only lorry the repo when they are going to be in the final system11:55
ssam2(i'm just saying this in case anyone thinks there is magic at work ;)11:55
franredssam2, yeah!! :)11:56
KrinYAY MAGIC!11:56
franredjjardon, I though that the error that I was facing when rebasing was caused because the split of connman from connectivity but it seems that it is because the systemd update: http://paste.baserock.org/amoqomuxuz.vbs11:57
jjardonhttp://mason-x86-64.baserock.org/ and http://mason-armv7lhf.baserock.org/ are orange: known issue?11:57
franredlooks like libsystemd-daemon is not in the system11:57
radiofreetis11:57
jjardonfranred: systend doesnt ship libsystemd-daemon anymore, but only  libsystemd11:57
franredlibvirt is expecting it in :/11:58
radiofreeupgrade libvirt?11:58
pedroalvarezdoes a new version of libvirt don't need libsystemd-daemon?11:59
ssam2jjardon: thanks for pointing it out, but there's no issue. Mason doesn't give any 'network is fine again now!' output on the status page so it's hard to tell11:59
ssam2when someone commits something to definitions it'll go green12:00
jjardonfranred: upgrade libvirt or patch the configure.ac to ask for libsystemd instead libsystemd-daemon12:00
jjardonAs I did in http://git.baserock.org/cgi-bin/cgit.cgi/delta/node-startup-controller.git/commit/?h=baserock/systemd_v216&id=b77fb1dbb280ec45525853e52a362eafd736b40012:00
franredjjardon, cheers, I will do that, Im currently using the latest stable release 1.2.1012:06
franredgit.baserock.org/cgi-bin/cgit.cgi/delta/libvirt.git/refs/heads?h=baserock/v1.2.1012:06
jjardonfranred: you will have to patch, even master is requesting libsystemd-daemon12:06
jjardonfranred: maybe is a good idea to send the patch upstream as well12:06
jjardonjonathanmaw: franred told me you are the maintainer, maybe you want to pick up http://git.baserock.org/cgi-bin/cgit.cgi/delta/node-startup-controller.git/commit/?h=baserock/systemd_v216&id=b77fb1dbb280ec45525853e52a362eafd736b400 to support newer versions of systemd12:15
*** madhu__ [~madhu@202.0.77.198] has joined #baserock12:18
jonathanmawjjardon: does systemd change the format of its version numbers?12:18
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock12:19
jjardonjonathanmaw: newer systemds only ships a systemd.pc file, not ibsystemd-daemon.pc, libsystemd-id128.pc, libsystemd-journal.pc or libsystemd-login.pc12:20
jjardonIts not a problem if you do not plan to support very recent versions of systemd12:21
rdaleenlightenment efl won't build with the new systemd pkgconfig files12:21
rdaleyou can build systemd with a backwards compatibilty option12:22
jjardonrdale: you can, but Id prefer to fix the upstream configure.ac instead12:26
jjardonthat configure option is temporal and can be removed at any point12:27
pedroalvarezjjardon: s/temporal/temporary/ :P12:32
pedroalvarezyeah, is better to fix upstream12:33
franredjjardon, http://git.baserock.org/cgi-bin/cgit.cgi/delta/libvirt.git/commit/?h=baserock/v1.2.10&id=7b1ceec1e2f141d36ed9b7ef3a660ff8bb34fc53 <-- this works, why you haven't included a version? (if I don't add the version number it fails because it tries to compare with nothing)12:36
franreds/a version/the version number on the node-startup-controller fix/12:36
jonathanmawsince I need my changes to work for previous versions of systemd as well, I'm more partial to this as a patch: http://pastebin.com/Wbuaic5x12:38
jonathanmawas advised in https://autotools.io/pkgconfig/pkg_check_modules.html12:38
jonathanmawunfortunately, I don't currently have a system where I can test that it works when I have libsystemd.pc instead of libsystemd-daemon.pc12:39
jjardonfranred: libsystemd was very recently added, so if its there the version will be new enough. If you add the version will be correct as well12:39
jjardonjonathanmaw: yeah, that makes sense12:40
jonathanmawjjardon: Could you test that configure works with it12:40
jonathanmawmy m4-foo is weak, so I don't trust  my code by eye12:40
jjardonjonathanmaw: sure, but you simply have to build a genivi system using current definitions: currently only libsystemd.pc is generated12:43
pedroalvarezI guess franred can test that patch quickly12:44
jonathanmawjjardon: Easier for you than me, since I haven't used baserock for a while, and don't have a fully-stocked artifact cache12:44
pedroalvarezjonathanmaw: everybody has now!!! http://cache.baserock.org12:44
* jonathanmaw doesn't understand what that's showing, following the link shows a cgit site full of repos12:46
persiajonathanmaw: If you add cache.baserock.org:8080 to your morph cache list, all artifacts are up-to-date, so you rarely have to build much.12:46
persiaOr rather, only have to build that which is built as a result of a patch12:46
ssam2adding instructions to http://cache.baserock.org:8080/ would be a neat improvement12:47
persiaSee http://wiki.baserock.org/quick-start/ for the relevant configuration (under "Configure Morph")12:47
ssam2would need a change to morph-cache-server, I guess12:47
pedroalvarezjonathanmaw: I just wanted to spread the word, that not having an artifact cache is not longer an excuse :)12:47
persiassam2: That's a brilliant idea12:48
franredpedroalvarez, sadly libvirt uses their own autotools macros, I could have a look how can I add both checks but I don't have the time to test it right now12:51
pedroalvarezfair enough12:51
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds]13:04
franredpedroalvarez, also looks like libvirt does not expect to have multiples checks for a package: LIBVIRT_CHECK_PKG([NETCF], [netcf], [0.1.4]) --> http://git.baserock.org/cgi-bin/cgit.cgi/delta/libvirt.git/tree/m4/virt-lib.m4?h=baserock/v1.2.10&id=7b1ceec1e2f141d36ed9b7ef3a660ff8bb34fc53 13:05
*** elevenarms______ [~elevenarm@128.90.88.80] has quit [Ping timeout: 245 seconds]13:14
*** elevenarms______ [~elevenarm@58.251.146.236] has joined #baserock13:14
*** elevenarms______ [~elevenarm@58.251.146.236] has quit [Ping timeout: 255 seconds]13:18
*** elevenarms______ [~elevenarm@43.249.128.119] has joined #baserock13:19
paulsher1oodrichard_maw, persia - maybe i'm missing something, but what is the use-case where I should actually worry about security implications in cycle.sh? it's a developer script, not fro production?13:33
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock13:33
persiaGenerally speaking, one should always code defensively.13:34
paulsher1oodpersia: yes. i know. next?13:34
persiaThat said, part of the point is to allow a developer to ignore the implementation, so they can treat your script as a module.13:34
persiaIf you don't quote everything carefully, and protect everything, then a user needs to care how your script is implemented, and how it may interpret arguments.13:35
paulsher1oodnot for the use-cases i'm aiming at, as far as i can tell?13:35
persiaFor example, if I have a local paste error (because my touchpad is annoying), I might run `cycle.sh git commit --amend; tig status system cluster`13:35
paulsher1oodheh13:36
persiaIf I had quotes in that anywhere, it could cause all sorts of unexpected behaviour, rather than just causing an error.13:36
persiaBut if you are sufficiently defensive in your coding practice, I'll just get an error.13:36
* paulsher1ood considers trying `<various baserock commands> foo bar; rm -fr /*` for fun13:37
persiaYou may find "bar; rm -rf /" more effective (with the quotes)13:38
richard_mawin that case it would unconditionally destroy your system, because the ; is interpreted by your shell13:38
robtaylorpaulsher1ood: tbf if richard_maw has been involved, it probably handles quoting correctly13:38
persiarobtaylor: The problem is that richard_maw appears to be human, and so sometimes allows patches he has not reviewed to be merged.13:39
robtaylortrue...13:39
paulsher1oodi was cribbing persia's example, richard_maw13:39
richard_mawyup, but persia mentioned you need some form of escaping in there to actually trigger it to do that, hence why scripts should avoid needing you to escape its arguments13:41
persiamy example was improperly quoted13:41
richard_mawsince that increases the likelihood that you'll pass escaped arguments to a different script by accident13:41
persiaNote that even with the quoting richard_maw typically recommends, one may still need to pass escaped arguments, but one should not need to fear they will become unescaped by the implementation.13:42
* robtaylor notes that bad quoting handling in developer scripts does indeed cause horrendous headaches when you hit them. usually becasue there's no way around the problem.13:42
paulsher1oodthis level of shell-fu is beyond me13:42
persiarobtaylor: That presumes an unwillingness to fix the script.13:42
richard_mawrobtaylor: that's why I'm picky about whitespace safety in shell scripts13:43
richard_mawpaulsher1ood: which means it shouldn't be written in shell13:43
robtaylorpersia: yup, though i've also found that when you hit these sorts of problems, it tends to be hard to find out where the culprit is13:44
paulsher1oodrichard_maw: what does? my lack of shell fu? 13:44
* paulsher1ood disagrees, if that's what richard_maw means :)13:44
richard_mawpaulsher1ood: yes, though that wording implies its your skill level at fault, which I didn't mean to imply.13:45
paulsher1oodrobtaylor: note 'these sorts of problems' are theoretical in this paricular case13:45
persiarobtaylor: No disagreement there: I only reflexively object when people say "no way around" or "foo cannot do bar" in open source :)13:45
* paulsher1ood still sees no *realistic* situation where this level if protection would matter13:46
richard_mawpaulsher1ood: my point is that now your script has grown sufficiently complicated that to continue writing it in shell requires much deeper knowledge, while it could be more safely and easily handled in a more appropriate language13:46
persiaI think the point of shell vs. python is that doing this right in shell requires a level of shell programming that few have, so makes it hard for others to contribute.13:46
persia(much like nobody every submits patches to the programs I write in make)13:46
persias/every/ever/13:46
paulsher1oodrichard_maw: only if your (and persia's) assumption that it needs to be bulletproof vs injection etc is valid13:46
persiaAs I wrote in my latest mail, I'm no longer convinced that a script is the right way to solve the problem.  I have become convinced the existence of the need for the script is a bug in morph.13:47
paulsher1oodnote i am not proposing (and have never proposed) that this script or anything similar should be used in production13:47
persiaBut I've had enough headaches dealing with unsafe code (as a developer), and patching in quotes, etc. to remove bugs that I'm sensitive about trying to do it right.13:48
petefothrichard_maw: I’ve actioned your review comments on the firts bacth of write extension docs - Changes pushed to https://github.com/petefoth/morph/commit/3a3b4f7a31457fa9afd5d47d11d20c5ed4b79683  and visible at http://paste.baserock.org/ukijudasah.md. If you are happy I’ll mege to master in my githup repo and you can pull from there13:48
persiapaulsher1ood: It depends on how one defines "production".  Does a compiler get "used in production"?  Should it be "production quality"?13:48
paulsher1oodfair enough. i'll give up, shall i?13:49
robtaylorpaulsher1ood: yeah, i have no idea what your script is doing, but looks like it takes a command to run13:49
paulsher1oodrobtaylor: it builds $1 and deploys it to $213:49
paulsher1oodoptionally with a new label $313:50
richard_mawpetefoth: looks good to me: +113:50
persiapaulsher1ood: I do believe that your script is an important workflow point: this must be really easy (and it isn't).  I'm just not convinced that as it grows, it isn't starting to try to fix bugs that ought be fixed in morph.13:51
richard_mawMy perspective on whitespace is that any shell script that doesn't handle it properly is buggy, hence it should be fixed. If it's difficult to fix in shell, then a better language should be used.13:53
paulsher1oodi thought i'd already fixed the whitespace stuff. we're now into other things, i thought (eg use of ssh)13:54
* persia isn't sure that "better language" is meaningful in this context, beyond "better at handling whitespace in arguments"13:54
robtayloroh, in which case, doesnt sound so critical, just needs to be safe13:54
* persia read the bits about ssh as a recommendation to use a function to be more whitespace safe13:55
richard_mawthere's two levels of whitespace safety involved, the trivial one can be handled with a function, using ssh adds a more difficult obstacle13:56
petefothrichard_maw: thanks. Now merged and pushed to master on my github repo https://github.com/petefoth/morph13:56
*** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection]13:58
jonathanmawpedroalvarez: node-startup-controller should work with later versions of systemd, now.14:11
*** elevenarms______ [~elevenarm@43.249.128.119] has quit [Ping timeout: 272 seconds]14:21
*** elevenarms______ [~elevenarm@113.87.233.201] has joined #baserock14:22
pedroalvarezjonathanmaw: great, thanks!14:26
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection]14:32
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock14:34
*** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock14:58
pdarHiya, Am trying to use a .morph with the following contents, http://paste.baserock.org/qiqavihode.hs. I get an error complaining that I am trying to write to a 'Read-only file system'. Is there a nice way round this?15:20
radiofreepdar: $DESTDIR$PREFIX in the install15:21
ssam2pdar: you're nearly there, the problem is that you need to install to "$DESTDIR"/"$PREFIX/"15:21
radiofreeis that not the same as "$DESTDIR/$PREFIX/"?15:22
ssam2yeah, 15:23
ssam2I think15:23
pdarssam2: Thanks, I tried that too and got an error... I cant remember which error though.15:23
radiofreepdar: probably $DESTDIR$PREFIX/include doesn't exist15:23
radiofreemkdir -p $DESTDIR$PREFIX/include first15:23
radiofreealthough i think people prefer for you to use install15:24
pdarradiofree: thanks! I shall try this15:24
radiofreeyou'll probably want to do mkdir -p $DESTDIR$PREFIX/lib as well15:25
radiofreebefore the cp to lib15:25
pdarradiofree: there was an install produced by the make before but the newer version didnt produce one... 15:25
radiofreepdar: there's an "install" command that can also be used15:26
paulsher1ood(instead of mkdir etc)15:26
ssam2i believe the advantage of using 'install' is you can set the correct permissions at the same time that you copy the file15:26
ssam2there may be other reasons i'm unaware of15:26
radiofreepdar: e.g http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/bsp-jetson/u-boot@jetson.morph15:27
paulsher1oodpdar - try 'install --help' 15:27
radiofreethough i think i made that morph file so it's probably not the best example of install usage 15:27
pdarradiofree: aha, now I feel silly...15:28
pdarthanks!15:28
persiassam2: It has more options to be careful about things, and change content during install (e.g. --backup or --strip)15:28
pedroalvarezoops, morph check fails because of the latest changes in the docs :/15:28
pdarand thanks paulsher1ood too15:28
radiofreei have actually used mkdir -p "$DESTDIR$PREFIX/bin" instead of install >.<15:28
* paulsher1ood too :)15:28
radiofreei think it's install -d $DESTDIR$PREFIX/bin though15:28
petefothfor my morph documentation changes, I am pushing to my githup repo, and I am trying to work out the best git workflow. Should I do my changes on a feature branch, which I push to githup, get that branch reviewed, then merge to master on github. Or would it b safe to make changes in master on github, seeing as no-one else pushes there?15:31
persiapetefoth: It is only safe to push to master @ github if you never need to take changes from others (from any source).15:34
persiaIf you do need to take changes, you would need to arrange a merge that happened to insert theirs at the right point, which very likely requires -f.15:34
persiaWhich means nobody would be able to trust the SHA1s from your github repo15:35
petefothpersia: I think my only need will be to rebase from g.b.o15:35
persiaYes, but *any* rebase means that you have to push -f, which breaks all subscibers, ruining the point of having published it as a git repo in the first place.15:36
* petefoth needs to think about that - see you all tomorrow15:36
persiaNote that I'm an anti-fan of SHA-preserving merge policies anyway, and prefer always rebasing everything, so that private and candidate repos are disposable, but I recognise that a lot of folk feel differently (and they may be better able to advise you).15:36
*** vmeson [~quassel@128.224.252.2] has quit [Remote host closed the connection]15:41
*** vmeson [~quassel@128.224.252.2] has joined #baserock15:44
*** vmeson [~quassel@128.224.252.2] has quit [Read error: Connection reset by peer]15:50
*** vmeson [~quassel@128.224.252.2] has joined #baserock15:51
franredsomeone know why dd can refuse to use fdatasync as a conv argument? http://paste.baserock.org/aduqehidim.vhdl16:03
*** vmeson [~quassel@128.224.252.2] has quit [Quit: vmeson]16:04
radiofreethe baserock logo in the corner makes it impossible to read the entire line16:04
franredsudo -u cinder sudo cinder-rootwrap /etc/cinder/rootwrap.conf dd if=/dev/zero of=/dev/mapper/cinder--volumes-volume--d2245407--a322--4923--bd40--dccf85bdd2a3 count=1024 bs=1M conv=fdatasync16:05
*** vmeson [~quassel@128.224.252.2] has joined #baserock16:05
persiahttp://paste.baserock.org/efeposipeb.coffee is surprising to me.  What did I do wrong?16:05
ssam2persia: for some reason, at the top of morph.conf you need to add the following line:16:06
ssam2[config]16:06
persiaAh, INI format16:07
radiofreefranred: hm.. works for me :\16:08
ssam2busybox vs gnu dd ?16:09
radiofreessam2: according to franred's log it's coreutils dd16:09
ssam2right16:10
pedroalvarezis there another one?16:11
franredthe one which is using is the coreutils one16:11
franredradiofree, :/16:11
pedroalvarezfranred:  `dd --help | grep fdata`16:12
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]16:13
radiofreeit's probably something to do with all that ciner stuff?16:13
radiofreecinder16:13
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock16:13
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host]16:13
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock16:13
radiofreei just ran dd if.. of... .... conv=fdatasync16:14
franredradiofree, it works running it directly from root16:14
franredyes16:14
persiaDoes morph reporting "ERROR: Unknown host architecture aarch64" mean I have to play with cross-bootstrap?16:15
radiofree:-o16:16
* persia is trying to build armv7lhf binaries in 32-bit16:16
radiofreethat sounds like you're trying to build armv8...16:17
ssam2persia: the code in question is this: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/util.py#n45516:18
radiofreeyou're trying to build armv7lhf binaries on 32-bit what? 32-bit x86?16:18
ssam2persia: it uses uname to guess what your host architecture is16:18
radiofreeyou absolutely can't do that 16:18
pedroalvarezIs detailed here: http://wiki.baserock.org/guides/how-to-cross-bootstrap/16:18
radiofreepersia: unless you mean you're trying to build armv8 on armv7? you probably can't do that either16:19
pedroalvarezhe is cross-building I believe16:19
persiaradiofree: I'm trying to build armv7lhf on aarch64.  I have no problem *executing* binaries16:19
radiofreeooooh16:19
persiaThe problem I'm having is logically equivalent to building x86_32 on x86_6416:19
persiaExcept ARM16:20
radiofreehow exciting to have such problems!16:20
ssam2persia: on x86 i'd use 'linux32 enter-baserock' to enter the chroot16:20
ssam2so that 'uname' returned i686 as the architecture16:21
ssam2I don't know if there's an equivalent to the 'linux32' tool on ARM16:21
* persia checks16:21
ssam2seems it just wraps 'setarch'16:21
ssam2so you should be able to use 'setarch'16:21
persiaI seem to have /usr/bin/linux3216:22
* persia tries16:22
persiaHeh, that works, except it isn't quite flexible enough ("Error: Unknown host architecture armv8l").16:26
* persia tries `setarch armv7l`16:26
* persia crawls into a rabbit hold trying to find the incantation16:30
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 252 seconds]16:31
radiofreepersia: it's probably not going to work http://git.baserock.org/cgi-bin/cgit.cgi/delta/util-linux.git/tree/sys-utils/setarch.c#n14616:32
persiaYes, but https://lkml.org/lkml/2012/8/21/58616:33
* persia just has to find the right setarch16:33
radiofreei can't see how that would work16:38
persiaSo, I know that this machine can run armv7lhf binaries, because I'm running them.16:39
pedroalvarezurgh.. morph test suite is really broken :(16:40
persiaTherefore, it ought be able to lie to itself and pretend to be armv7lhf16:40
franredradiofree, ssam2, pedroalvarez, looks like when we install coreutils, we install them in /usr/bin and busybox still has their applications on /bin, why we don't overwrite them?16:40
radiofreepersia: i meant i don't see how setarch can be used to do that?16:41
radiofreewhat do you get with "setarch linux32 uname -m"?16:41
franredthe error is that, when using cider, it scan for the apps and it looks it take the busybox one because is the first which cinder/rootwrap finds16:42
persiaradiofree: Hrm?  Is it not the same as `setarch i486 foo` when one is running in x86_64, and could do `setarch i686`?16:42
persiaradiofree: armv8l16:42
radiofreepersia: they are defined in the tool though http://git.baserock.org/cgi-bin/cgit.cgi/delta/util-linux.git/tree/sys-utils/setarch.c#n16516:43
radiofree"armv7" isn't16:43
persiaBut I can run binaries of either "/usr/bin/setarch: ELF 64-bit LSB  executable, ARM aarch64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.7.0, BuildID[sha1]=01b22caa7717e8eb7d68b43de3d0b0092fdcb252, stripped" or "/usr/bin/setarch: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped"16:43
persiaTo me, the latter is clearly armv7lhf16:43
persiaIn fact, the latter is from cache-key 1a852e85a25c8ad697eae5b22748fc73b6f29ea877640590bf65e98adbd60c66, so likely built by the armv7lhf distbuild cluster16:45
persia(and so likely the *same* setarch that folk run on jetsons)16:46
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock16:47
robtaylorpersia: i presume you just need to add the arm transitions into setarch16:48
robtaylorpersia: presumably they aren't there because noone has written them yet16:49
persiarobtaylor: So you don7t agree that what I seek is impossible?16:49
robtaylorpersia: prior to armv8 there was no need for setarch to do anything on arm...16:49
robtaylorpersia: no, just requires adding a few lines to sys-utils/setarch.c16:49
robtaylorpersia: which is what i think radiofree is trying to tell you16:50
radiofreeyeah...16:50
persiaThat's what I thought, but I'm trying to get an existing patch if it exists before I write one (to ease upstreaming)16:50
robtaylorpersia: a quick search turns up nothing for me16:51
persiaradiofree: my apologies: I misunderstood16:51
robtaylorpersia: doesn't look like fedora has patches for this yet http://pkgs.fedoraproject.org/cgit/util-linux.git/tree/16:55
persiaNo distro does (I've already checked).  Now chatting with linaro folk to get hints16:55
robtaylorpersia: its just adding a line for target_arch to result_arch16:56
persiaYes.16:56
robtaylorpersia: target_arch is whatever uname is returning for you on your armv8 system16:57
robtaylorpersia: result arch is armv7l16:57
robtaylor(I lost track of the aarch64 arch naming discussion -  is it aarch64 or something sane?)16:58
persiarobtaylor: aarch64 and armv8l16:59
persia(64-bit vs. 32-bit)16:59
robtayloreh?16:59
paulsher1oodrobtaylor: he's working on a 64-bit machine17:00
robtaylorhow does armv8l  differ to armv7l then?17:00
* paulsher1ood reads up, then decides he's out of his depth, as usual17:00
persiaI haven't reviewed the ISA changes.17:00
robtaylorpaulsher1ood: i'm aware of that, i just din't think armv8 in 32bits was any different to armv7 in 32 bits17:00
paulsher1oodwhere is rjek when we need him to split this kind of hair? :)17:01
robtaylorwow yeah, seems so17:01
robtaylorhttps://groups.google.com/d/msg/linux.kernel/vZow60-EFQA/NrSSFcf7TpYJ17:02
flatmushI assume that there are mode changing instructions, minor error fixes and armv8l will likely use a newer version of VFP/NEON17:03
robtaylorso i guess you'll need a aarch64 to aarch32(armv8l) then17:03
persiarobtaylor: That already works17:04
*** elevenarms______ [~elevenarm@113.87.233.201] has quit [Quit: Be back later ...]17:04
robtaylorpersia: it does? thats.. interesting..17:04
radiofreepersia: what does uname -m report (without setarch)17:04
radiofreei guess armv8l working is because of http://git.baserock.org/cgi-bin/cgit.cgi/delta/util-linux.git/tree/sys-utils/setarch.c#n20817:05
persiaRight17:06
robtaylorah, of course, init is 32 bit, so you're getting armv8l17:08
robtaylorsetarch aarch64 will of course fail17:09
persiaAnd it turns out, we don't want to do this.17:09
robtayloryet17:09
persiaOr at least arnd (the author of the lkml mail in question) doesn't think so.17:09
persiaThe problem being that the ISAs are subtly different, and while there is some backwards compatibility, it isn't guaranteed.17:09
robtaylorwell that screws the pooch17:10
robtaylorthough for our cases, any backward compat issues are likely to be highly unlikely to cause an issue17:11
persiaHrm?  How do you mean?17:11
robtaylorwe want to run binaries that build things. The sort of non-backwards compat changes tend to be in things like VFP and freinds17:12
robtaylorwhich you pretty much aren't going to use when compiling, or running shell scripts.17:12
robtaylorum17:13
robtaylorseems he's talking arse though17:13
persiaIf two ISAs differ, I think we ought differ.17:13
robtaylorarm's literature claims backwards compat17:13
robtaylorhttp://www.arm.com/products/processors/armv8-architecture.php17:14
*** genii [~quassel@ubuntu/member/genii] has joined #baserock17:14
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]17:22
pdarpedroalvarez: Earlier you advised that if I think a lorry should be updated I should do so then submit a patch. I've changed two .lorry files, how do I submit a patch?17:23
pedroalvarezyou can either run `git diff` and copy the content to http://paste.baserock.org/, or send the patch to the mail list following http://wiki.baserock.org/contributing/#index7h217:25
robtaylorpersia: so yeah, sorry, i misread what it was doing, it just does th same as linux32/linux6417:25
robtaylorlinux on armv8 aims to be backwards compat to armv617:25
persiaThen we should support that, either by changing morph, or adding kernel support.17:26
robtaylorso all you need is a way to tell morph to build a particular arch 17:26
robtaylorwhich i thought we had..  richard_maw ?17:26
pdarpedroalvarez: thanks!17:26
pedroalvarezI wonder if this failure may be related to the 'git' upgrade: http://paste.baserock.org/umojagucoj.diff17:27
pdargit clone https://code.google.com/p/gperftools/17:27
radiofreei don't think morph likes building when the arch doesn't match the system arch17:27
pedroalvarezpdar: well done :)17:27
pdarwhoops, sorry17:27
radiofreeso trying to build armv7 (this is what you're trying to do right?) won't work17:27
* robtaylor thoight some bits for this happened when the sdk/canadian cross stuff got written17:28
pedroalvarezfranred: I remember you reviewed the git upgrade, did you run morph's ./check?17:28
persiaradiofree: Right.  I need to either change morph, or change the system arch.17:29
radiofreepersia: maybe add armv8l as an alias for armv7l or something as a quick hack17:30
robtaylorpersia: yep, looks like you need some fixes to morph17:31
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection]17:31
robtaylorpersia: probably something like the transition table would make sense. e.g. 'armv6? on arm8? is ok' 'armv7? on armv8?' is ok etc17:31
robtaylorpersia: around about here http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/buildcommand.py#n12717:32
persiarobtaylor: Why not http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/util.py#n45517:33
robtaylorpersia: though as a quick hack, you could try running a qemu --enable-kvm17:34
robtaylorpersia: because that's not where the logic is17:34
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 258 seconds]17:35
robtaylorpersia: i would say _validate_architecture would be the senible thing to say 'and yes you can build arch <x> on arch <y>17:35
persiaHrm?  buildcommand.py#n128 calls util.py#n45517:35
robtaylorpersia: rather than pretend the host is some other arch17:36
persiaOh, that seems reasonable17:36
robtaylor:)17:36
persiaTo confirm, you suggest changing the conditional in line 129?17:37
persiaAnd I'd like to exclude armv6, due to cp15 and potentially setend17:38
persiaUnless you have some usecase that requires it?17:38
robtaylorpersia: yep (129)17:39
robtaylorpersia: agreed on armv6. Usecase would be building for raspberry pi, which would be nice to be able to do but...17:39
persiaThis is why there are virtual machines :)17:40
robtaylorpersia: actually, see arn't's statement17:41
persiaWhat, about kernel traps?17:41
robtaylorpersia: the armv6 stuff could be a kernel version check17:41
persianot for raspbian17:42
persiabecause setend and non-endian-swapping17:42
robtaylornoone would use that in a build system17:42
robtaylorgcc wouldn't emit it17:42
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock17:42
persiaNobody would want to build stuff on a raspberry pi?17:42
robtayloryou'd have to have a tool that explictaly did it, and noone did17:42
robtaylornoone would use setend17:43
persiaExcept raspbian's toolchain does, according to arnd17:43
robtaylor(set endian)17:43
robtaylorpersia: no, thats the cp15 barriers, which are trapped and emulated17:43
robtaylor(at least, that's my reading of the conversation)17:44
radiofreei believe richard dale tried to build qt5 on a raspberry pi, once17:44
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection]17:45
persiaradiofree: If he wasn't using an armv8l machine to do it, it should have worked (if slowly)17:46
radiofreethis was outside of baserock17:46
radiofreei was just giving you an example of how people are crazy and try to do crazy things ;P17:46
radiofree<persia> Nobody would want to build stuff on a raspberry pi?17:46
persiaradiofree: Apologies.  That was me using a cheap rhetorical trick to counter the idea that we could ignore work done in raspbian.17:47
* persia tries harder not to do that sort of thing17:48
robtaylorpersia: ah, no, i misread. Looks like rasbian specifically uses this by using https://github.com/bavison/arm-mem17:48
radiofreewell it would be nice to *build for* a raspbery pie on a decent baserock system17:48
radiofreelike a jetson or something17:48
robtaylorpersia: but that's really just a case of 'well don't do that then' for baserock17:48
persiarobtaylor: Well, there's still virtual machines :)17:48
radiofreei'd like to see the raspberry pi weston backend in action!17:48
robtaylorpersia: no, i think you misunderstand my statement17:49
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]17:49
robtaylorpersia: its a case of 'well dont build a staging area that uses arm-mem'17:49
robtaylorpersia: which is probably reduced just fine to 'don't use arm-mem' in a baserock system. ;)17:50
persiaI don't like the idea of excluding valid sources17:51
persiaSeems more reasonable to require them to be built in specific environments17:51
robtaylorpersia: i supose so17:51
robtaylorpersia: a reasonable approach would be to create an arch name for armv6 without setend and it17:53
persiaIn morph?17:53
persiaOr in the toolchain?17:53
persia(or both)17:53
robtaylorin morph17:54
persiaI don't know if I really understand the details here.  Could you summarise for baserock-dev@ ?  I feel like we need ML consensus on a new arch name.17:55
* persia will use a local dirty hack to work around the current problem17:55
*** sherm_ [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]17:59
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal]18:00
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat]18:01
*** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection]18:01
pedroalvarezI've just sent a patch to fix morph and morph test suite. I think it should be merged soon since mason is failing...18:03
pedroalvarezhttp://mason-x86-64.baserock.org/18:03
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]18:04
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock18:04
radiofreepedroalvarez: looks ok to me, +118:06
radiofreewhy on earth was ... replaced with … in the first place?18:06
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]18:06
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock18:07
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host]18:07
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock18:07
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]18:07
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock18:08
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host]18:08
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock18:08
DavePageAutocorrect?18:10
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]18:13
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock18:13
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host]18:13
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock18:13
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]18:13
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock18:14
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]18:14
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock18:15
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host]18:15
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock18:15
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]18:15
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock18:16
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host]18:16
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock18:16
robtaylorpersia: hopefully the mail i just sent captures your understanding also :)18:28
persiarobtaylor: There's nothing in there that contradicts the subset of things I understood :)18:30
robtaylorwin!18:30
robtaylorah, but did the mail clarify the parts you didn't?18:31
persiaYes, absolutely.  Now I just hope someone more informed comments on your nomenclature :)18:31
* persia has enough to submit a patch that could be morph, excluding the armv6_8 case18:32
robtayloryes, thats clearly the right first step :)18:34
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds]18:39
*** rdale [~quassel@host86-143-211-156.range86-143.btcentralplus.com] has quit [Ping timeout: 265 seconds]19:05
*** rdale_ [~quassel@host86-143-211-156.range86-143.btcentralplus.com] has joined #baserock19:05
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer]19:19
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock19:25
*** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer]19:25
*** genii [~quassel@ubuntu/member/genii] has joined #baserock19:26
*** rdale_ [~quassel@host86-143-211-156.range86-143.btcentralplus.com] has quit [Ping timeout: 252 seconds]19:34
*** rdale [~quassel@host86-143-211-156.range86-143.btcentralplus.com] has joined #baserock19:35
*** De|ta_ [~arc@195.242.156.171] has joined #baserock21:24
*** jmacs_ [~jimmacart@access.ducie-dc1.codethink.co.uk] has joined #baserock21:24
*** radiofree_ [radiofree@2a01:7e00::f03c:91ff:feae:d2f1] has joined #baserock21:26
*** radiofree_ [radiofree@2a01:7e00::f03c:91ff:feae:d2f1] has quit [Changing host]21:26
*** radiofree_ [radiofree@unaffiliated/radiofree] has joined #baserock21:26
*** vmesons [~quassel@128.224.252.2] has joined #baserock21:26
persiaOK.  Worked past that.  Next is http://paste.baserock.org/yizowogeza.py21:42
persiaIs this because I failed to set up my chroot properly?21:42
persiaAlso, I'm a bit worried that an attempt to build "systems/devel-system-armv7lhf-chroot.morph" from definitions 778f4b6a95dc3510d9d2d70866d5142691da1a7821:44
persiaresulted in an actual build: should this not have been cached?21:44
* persia was not expecting any compilation: just cache download and assembly21:45
paulsher1oodpersia: not sure we build the chroot systems21:46
paulsher1oodtry building jetson system, for example?21:46
persiaHrm.  This makes me wonder if building selected systems is indeed the best way to populate cache.21:48
persiaPerhaps we ought be building strata (and all of them), or similar.21:48
persiaBut that's just a side issue, which becomes unimportant if I can build a jetson system from cache.21:49
* paulsher1ood notes that master is broken at the moment21:49
persiaI still wonder about the morph error about / not being a mountpoint21:50
persiajetson crashes at the same point21:50
persia(with the same error, and the same attempt to perform a local build)21:50
paulsher1oodtry resetting to last known good ref? 778f4b6a95dc3510d9d2d70866d5142691da1a7821:51
* persia wonders if running `morph build systems/devel-system-armv7lhf-jetson.morph` can be done entirely from cache on a jetson21:51
paulsher1ood(just to be sure)21:51
persiaI'm on 778f4b6a95dc3510d9d2d70866d5142691da1a7821:52
paulsher1oodok21:52
persiaBut I'm using a hacked morph on an unsupported architecture, which may affect things :)21:53
paulsher1oodat that ref, i also see builds from 129 onwards, for x86_64-chroot.morph21:53
persiaOK, but the jetson system I tried wasn't a chroot21:55
paulsher1oodi had assumed that mason is caching only build-systems, so hence was not surprised by higher-level things building (and they're relatively quick)21:55
* persia tries the jetson build system21:55
persiaI thought it was devel, but it could be build.21:55
* paulsher1ood removes all caches, and starts starts 'building' a devel to see how much is fetched21:58
persiaI suspect it is "build", because the jetson build is now at 171/174 all in cache.21:59
persiaAnd now 174/17421:59
* persia rather wishes morph could notice that it could just download the final product, and didn't bother downloading all the intermediate artifacts22:00
* paulsher1ood wishes that too. and has looked at the code, but did not reach enlightenment22:01
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection]22:04
persiaHurrah.  With a badly constructed chroot and a tiny patch, I can build cached armv7 systems in armv822:05
* robtaylor has vaugue memories of discussing that in the early days. I think the general issue was deploy scripts. it was also thought that downloading the parts would be the same as the whole22:05
robtaylorpersia: awesome :)22:05
persiarobtaylor: Except I seem to *also* download the whole, which defeats the benefit22:05
paulsher1oodpersia: w00t! :)22:06
persiaBut I *want* to download the whole, because it *should* have the results of the system-integration scripts included, which the parts don't, and which I don't trust to run again22:06
paulsher1oodpersia: but for non-cached systems?22:06
robtaylorpersia: well, that does suck22:06
persiapaulsher1ood: I'd need a more capable chroot, which is why I started trying to build the chroot system, as that would give me a capable chroot.22:07
robtaylorpersia: i think i agree, though its bad that sys int isn't safely reproducable22:07
persiarobtaylor: No executable code is safely reproducible.22:07
persiaCosmic rays, etc.22:07
paulsher1oodin other news, devel-system-x86_64-generic artifacts *are* all cached on cache.baserock.org22:07
robtaylorpersia: at that limit, neither is any declaritive structure22:08
* robtaylor wouldn't want to solve that issue22:08
persiaYes, but more seriously, the more different times I run the same commands, the more likely I will have an issue.22:09
paulsher1oodwhile fixing the download logic, a truly smart morph would also download artifacts for other architectures if they exist, rather than saying 'are you trying to cross-build'22:09
persiaSo if I believe them to have run correctly once, I'd rather store the results than run them again.22:09
robtaylorpaulsher1ood: yep22:09
persiapaulsher1ood: Unless there is useful support for cross-execution, that would break the configuration extensions.22:09
robtaylorpaulsher1ood: i'd love that22:10
robtaylorpersia: i though config was run outside of your constructed root anyhow?22:10
* persia wouldn't : qemu-user-static isn't sufficiently reliable22:10
robtaylorpersia: and so it'd make sense for your config to run as host arch22:11
persiarobtaylor: I thought it ran inside chroots, but either way, it may require architecture-specific code22:11
robtaylorpersia: not if you say arch specigfic code isn't supported =)22:11
persiarobtaylor: That breaks most interesting hardware support.22:11
robtaylorhow so?22:11
persiaWe're getting better, but even x86 still requires arch-specific code22:12
paulsher1oodpersia: then i think there is something wrong with that logic too. if an arm system artifact is built, why can't i 'morph build' and 'morph deploy' it to an arm target from an x86 machine?22:12
persiaI haven't looked in a few years, but at that time, there were 10s of key packages that were arch-specific, being generally 3-5 per architecture.  x86 only had three at the time.22:12
robtaylormm, yes, i suppose oe/yocto still cary a few patches for this22:13
persiapaulsher1ood: Because you might have configuration extensions that require execution of ARM code.22:13
paulsher1oodon my machine, not the target?22:13
robtaylorthough, really, qemu really is sufficient22:13
robtaylori have an existance proof22:14
persiaYes, because it is on your machine that the system artifact (a glorified tarball) gets converted into the correct format for deployment (e.g. a disk image)22:14
persiarobtaylor: I used to think so, and spent a fair amount of time writing tools and docs to encourage devs to use qemu-static chroots, and worked with a team fixing lots of bugs we found for x86-on-arm, arm-on-x86, and ppc-on-x8622:14
robtaylorpersia: existance proof22:15
robtaylorpersia: let me give you a pointer22:15
robtaylorhttp://jolla.com/22:15
persiaBut we found some things where it was just way broken, and got upstream involved, and it was in fact way, way, way broken, and I stopped relying on that.22:15
persiaIt depends on what one compiles.  The haskell stack is particularly hard on qemu-static, for example22:15
robtaylorhttps://wiki.merproject.org/wiki/Platform_SDK_and_SB222:15
persiaThese are toy archives, with narrow focus.  Yes, it can work for some systems.  It is not currently general.22:16
robtaylorpersia: for deployment?22:16
persiaI don't believe there are currently any restrictions on what users may run at deployment time.22:16
persiaSpecifically, morph seems to load additional configuration extensions from definitions, so that users can essentially run whatever they like.22:17
* robtaylor thinks there's wayyyy too much 'this can't possibly work becasue of this oscure corner case that noone actually cares about'22:17
paulsher1oodheh22:17
persiaUnless this is guarded in some way, I would not be confident asserting that qemu-static was safe.22:17
robtaylorpersia: if someone does something that doesnt work, they get to keep the peices22:17
robtaylorwell done22:17
* paulsher1ood surrenders for the day22:18
robtaylorall you need to say is 'this should work in qemu static if youre doing cross platform development'22:18
persiaI'm not saying we shouldn't do it: it would be good, and improve things.  I'm just saying we shouldn't force it to be used, or default to it without warning labels.22:18
robtaylorand jobs done22:18
robtaylorpaulsher1ood: night :)22:18
robtaylorpersia: i'm generally all for making warning labels22:19
persiaThen we agree :)22:19
robtaylorpersia: and then gradually removing them as things get fixed22:19
robtaylorany other approach tends to lead to paralysis, i find22:19
persiaIn this specific case, I'm uncertain it is fixable, unless there is a new static execution architecture that someone developers, but I agree with the idea.22:19
robtaylorpersia: that last statment didn't make any sense to me22:20
persiaI agree that adding warning labels to enable folk to do dangerous things, and then removing them as bugs are fixed is a good strategy.22:20
persiaI don't believe that the way qemu works allows a solution for this class of problem, and believe that we cannot remove all the bugs without a new emulation architecture (probably in a new project).22:21
robtaylorpersia: i think ytou are very wrong22:21
persiaNot about the people: they people there are great: just about the way that qemu works.22:21
persiaI'd be happy if you were correct about me being wrong :)22:21
robtaylorpersia: i showed you an existance proof you are wrong22:22
robtaylorfor the classes of problem i care about (and anyone else who wants to do cross arch work, i expect)22:22
robtaylor(and anyone who wants to do things outside of that, gets a warning label)22:23
persiaYou showed me a corner case where it worked.  LIke I said before, I spent several years using this as the basis of development, and encouraging others to do so.  It works in some cases.  It doesn't work in others.  I've been told by upstream that it cannot work in still others.22:23
robtaylorpersia: mer compiles everything we want to compile22:23
robtaylorpersia: you're just saying 'i know better because i know better'. That isn't a good argument.22:23
persiaThen I am not part of your "we", because there are many things I want to compile that mer does not compile22:23
robtaylorpersia: yes, but you aren';t doing cross development22:24
robtaylorpersia: you're doing things for big hefty servers, and hey, you know what? you have big hefty servers to use22:24
persiaNo, I'm saying I found it not to be complete before, and I've been told it can't be complete, and I'd be delighted to be  proved wrong, but examples of the cases where it works are not proof that I have incorrect information.22:24
robtaylorpersia: so, you better give me those before saying its impossible22:25
persiaHrm?  I've compiled plenty of x86 server software on ARM laptops, and enjoyed it.  I don't see why this isn't a meaningful use case.22:25
robtaylorpersia: rather than a vague ' i remmeber there were some issues with something'22:25
robtaylorpersia: its not meaningful becuase noone really needs it22:25
robtaylorarm on x86, definitly is needed22:25
* persia did22:25
persiaIn fact, for years I routinely only carried ARM laptops, and often worked on x86 targets.22:26
robtaylorpersia: that's an obscure corner case, not what mer is doing22:26
persiaI don't want to argue about this.  I think we should support qemu-static for stuff.  I don't happen to beleive it can be made complete, but would be delighted to be proved wrong.22:27
robtaylorpersia: i'd love to hear why you thing it can't be made complete22:27
persiaMy belief should not prevent anyone from using it for cases where it works (like building x86 server software on ARM laptops).22:27
robtaylorpersia: so, can we have less of 'this can't possibly ever work because this oscure corner case can't be fullfilled by this appraoch'? it drives me mad!!!22:28
persiaI only have a vague memory, but my memory is that it is related to how qemu defines specific systems, rather than ISAs, meaning that unless one massively duplicates things, one ends up with a narrow set of targets, which have trouble supporting broad ISAs.22:28
robtaylorpersia: i think that changed a while back22:30
persiaThat is excellent news.  I hope so.22:31

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!