| *** pedroalvarez [~quassel@ec2-54-191-112-126.us-west-2.compute.amazonaws.com] has joined #baserock | 00:09 | |
| Mode #baserock +v pedroalvarez by ChanServ | 00:09 | |
| Mode #baserock +nt by orwell.freenode.net | 00:09 | |
| Mode #baserock +o pedroalvarez by ChanServ | 00:12 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 00:41 | |
| *** elevenarms____ [~elevenarm@58.251.146.229] has joined #baserock | 00:58 | |
| *** elevenarms____ [~elevenarm@58.251.146.229] has quit [Ping timeout: 244 seconds] | 01:03 | |
| *** elevenarms____ [~elevenarm@43.249.130.14] has joined #baserock | 01:08 | |
| *** elevenarms____ [~elevenarm@43.249.130.14] has quit [Remote host closed the connection] | 01:09 | |
| *** elevenarms____ [~elevenarm@43.249.129.254] has joined #baserock | 01: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 #baserock | 01:43 | |
| *** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has joined #baserock | 01:43 | |
| *** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has quit [Changing host] | 01:43 | |
| *** persia_ [quassel@ubuntu/member/persia] has joined #baserock | 01:43 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 01:58 | |
| *** elevenarms_____ [~elevenarm@103.27.224.205] has joined #baserock | 02:50 | |
| *** elevenarms____ [~elevenarm@43.249.129.254] has quit [Ping timeout: 240 seconds] | 02:51 | |
| *** elevenarms______ [~elevenarm@192.64.7.133] has joined #baserock | 03: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 #baserock | 03:28 | |
| *** elevenarms______ [~elevenarm@183.11.243.87] has quit [Ping timeout: 272 seconds] | 04:08 | |
| *** elevenarms______ [~elevenarm@43.249.130.227] has joined #baserock | 04:09 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:52 | |
| *** fay [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:29 | |
| fay is now known as Guest17625 | 08:29 | |
| *** rdale [~quassel@host86-143-211-156.range86-143.btcentralplus.com] has joined #baserock | 08:30 | |
| *** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:07 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:07 | |
| mike is now known as Guest40108 | 09:07 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:11 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09: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 #baserock | 09:13 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:22 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09: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 #baserock | 09:49 | |
| *** elevenarms______ [~elevenarm@43.249.130.227] has quit [Ping timeout: 264 seconds] | 10:01 | |
| *** elevenarms______ [~elevenarm@128.90.88.80] has joined #baserock | 10:01 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10: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 #baserock | 10: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 #baserock | 10:09 | |
| Mode #baserock +v ssam2 by ChanServ | 10: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 #baserock | 10:18 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:21 | |
| persia | paulsher1ood: 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 |
|---|---|---|
| persia | Note 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 #baserock | 10:29 | |
| pedroalvarez | I'd prefer to have it up-to-date, but also I'd like to test cross-bootstrap more fequently | 10:29 |
| * persia as well | 10:30 | |
| ssam2 | our mason instances both show lots of 'NONET' errors | 10:34 |
| ssam2 | the git server on git.baserock.org seems OK, though (if a bit slow) | 10:34 |
| ssam2 | oh, this is the old trap where "no news is good news" | 10:35 |
| ssam2 | all the errors are from yesterday and the log shows it's working again now. | 10:36 |
| tlsa | tbh, 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 firther | 10:37 |
| tlsa | *further | 10:37 |
| pedroalvarez | ssam2: yeah, there were some problems with the network where the masons are | 10:39 |
| franred | jjardon, why did you replace connectivity stratum by connman-common in enligthnment and virtualization strata? (see commit: 4ef19a1e85252a5d319d0b7158b1bdf3115a674c) | 10:50 |
| pedroalvarez | franred: that commit looks ok | 10:52 |
| pedroalvarez | he is replacing just the build dependency | 10:52 |
| pedroalvarez | and in the systems where connectivity was, he added also connman-common | 10:53 |
| pedroalvarez | franred: have you spotted any error regarding this change>? | 10:54 |
| franred | pedroalvarez, ummm, ok, having a look at it looks sensible | 10:55 |
| franred | s/it/it once again/ | 10:55 |
| pdar | heya, 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 |
| pdar | i guess that to fix this the lorry files migth need updating?? | 10:58 |
| pdar | How can I go about checkign wheter this is what needs to be done? | 10:59 |
| pedroalvarez | pdar: yes, or adding a new one | 10:59 |
| radiofree | libusbx has moved as well | 10:59 |
| pedroalvarez | pdar: you can explore the lorries, and check from where are we lorrying | 11:00 |
| pedroalvarez | pdar: and if you consider that we need to update some, send a patch requesting the update | 11:01 |
| pedroalvarez | pdar: like this: http://paste.baserock.org/kusibutobu.diff | 11: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 |
| petefoth | richard_maw: SotK: ^^ | 11:03 |
| ssam2 | pdar: have you worked with .lorry files before ? If not http://wiki.baserock.org/Trove/reference/#index4h2 should be at least a bit useful | 11:03 |
| richard_maw | petefoth: I'd probably just go with adding the help text to deploy_plugin.py | 11:04 |
| ssam2 | petefoth: 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_maw | since presumably if someone's looking for help with a specific write extension, they'll have tried `morph help deploy` first | 11:04 |
| petefoth | richard_maw: ssam2: thanks! Detail in morph help deploy with a single line in each plugin WFM | 11:05 |
| pdar | pedroalvarez: Great, thanks. I shall check the lorries and act accordingly. | 11:06 |
| pdar | ssam2: I have, but only briefly. Thanks for the link! | 11:07 |
| pdar | Where abouts do the lorry files for g.b.o live? | 11:10 |
| richard_maw | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/ | 11:11 |
| pdar | ahh, http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/ | 11:11 |
| pdar | snap, thanks richard_maw | 11:12 |
| pedroalvarez | radiofree: hey! I thought that to get an armv7lhf rootfs you could use the jetson image or the wanboard image | 11:32 |
| pedroalvarez | radiofree: do you find adding a rootfs-only system useful? why? | 11:32 |
| radiofree | pedroalvarez: yes you can but it would contain the kernel | 11:33 |
| radiofree | plus a load of nouveau crap, the wandboard image would be lighter | 11:33 |
| radiofree | well nouveau isn't crap! i mean it's not needed on a rootfs image | 11:33 |
| ssam2 | it is kind of weird when explaining people who want a generic ARM rootfs that they must use the one labelled 'wandboard' | 11:33 |
| ssam2 | but provide their own kernel | 11:33 |
| radiofree | we also don't provide a tarball anymore on the website | 11:33 |
| radiofree | also "Download Baserock" should be prominent, i can never find it | 11:35 |
| radiofree | quick start -> set up the development VM -> 'Create a Development VM' guide -> Download the VM image | 11:35 |
| radiofree | oh right there's a "Get Baserock" link in the menu | 11:36 |
| perryl | i've noticed the search results page on the wiki has the old sidebar, is there any way to change that? | 11:37 |
| perryl | petefoth ^^ | 11:37 |
| petefoth | perryl: url for the ‘Search results page’ | 11:37 |
| Krin | ok, 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 |
| radiofree | pedroalvarez: but yeah, you can just release the wandboard image as a tarball | 11:37 |
| radiofree | just call the filename "rootfs" instead of "wandboard" | 11:38 |
| persia | radiofree: Separately from the "why rootfs" discussion: why a "devel" image? SHouldn't "build "be smaller, faster to download, and sufficient? | 11:38 |
| radiofree | but if someone wanted to deploy it themselves they'd have to needlessly sit through an i.mx kernel build, since that won't be cached | 11:38 |
| radiofree | persia: i don't actually know what a build system is :\ | 11:38 |
| pedroalvarez | radiofree: true. I just wanted to know the reasons :) that's all | 11:39 |
| persia | radiofree: 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 |
| perryl | petefoth: generally? i'm guessing http://wiki.baserock.org/ikiwiki.cgi?P= | 11:39 |
| petefoth | perryl: got it. I’ll check | 11:39 |
| radiofree | hmm well, i think devel system suits a rootfs image better then | 11: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 kernels | 11:39 | |
| * petefoth has never used the search’ facility on w.b.o | 11:40 | |
| persia | radiofree: But it's *bigger*. If people need devel, should they not download build, and then upgrade to devel? | 11:40 |
| radiofree | persia: that would take ages | 11:40 |
| persia | I guess. I wonder how many people really need devel on a target board. | 11:41 |
| radiofree | well maybe not so long with cache.baserock.org | 11:41 |
| persia | Isn't it easier to do development on laptop, and deploy to a target board? | 11:41 |
| radiofree | so if i want to, for example, build a bsp for a board | 11:41 |
| perryl | petefoth: i think search only returns commit logs presently | 11:41 |
| radiofree | will i have enough tools in a build system to try that out? | 11:41 |
| persia | Yes. | 11:42 |
| franred | Krin, you can install that systemd service from inside your chunk, http://paste.baserock.org/nexihebete.cmake | 11:42 |
| radiofree | wouldn't it have been better to make the devel systems smaller then, rather than introduce a build system? | 11:42 |
| Krin | franred, does this create the firle? or is this an installation of the file itself? | 11:44 |
| Krin | that paste mostly confuses me but fill me with an odd sence of hope. | 11:45 |
| Krin | oh! damnit i', an idiot, first i need to add the programs that i'll be running to the trove >.< | 11:45 |
| persia | radiofree: 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 |
| jjardon | franred: IIRC, connectivity was splitted in connectivitty and connman-common so you can use networkmanager or connman | 11:46 |
| radiofree | ok i'll -1 my own patches then | 11:47 |
| franred | Krin, Im confused about what you want to do... you don't need the trove to create a .service | 11:47 |
| franred | Krin, what do you want to do? | 11:48 |
| Krin | i 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 |
| petefoth | perryl: no idea! I have asked in another channel | 11:49 |
| franred | Krin, do you mean that you need that your Baserock system initializes/runs your applications when the system boots? | 11:50 |
| Krin | yes, but at the moment the program that i want to run is not part of baserock XD | 11:50 |
| Krin | i thought i'd already done some stuff that i have not done | 11:50 |
| franred | Krin, 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 you | 11:51 |
| Krin | first i need to know how to make a program i have made availiable to baserock | 11:51 |
| perryl | petefoth: no worries, i'm not sure how used the search function is, just concerned about consistency across w.b.o | 11:51 |
| franred | Krin, 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 boot | 11:52 |
| petefoth | perryl: it’s a good spot - thanks for pointing it out. Consistency is important IMHO | 11:52 |
| Krin | yes, 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 |
| franred | Krin, if it is just a test you can use your github repository | 11:53 |
| franred | repo: github:myrepo | 11:53 |
| Krin | well, the idea is for it to be a proof of concept, but i'll cross that bridge when my brain has woken up | 11:55 |
| franred | Krin, then use github | 11:55 |
| ssam2 | note 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/myrepo | 11:55 |
| franred | we only lorry the repo when they are going to be in the final system | 11:55 |
| ssam2 | (i'm just saying this in case anyone thinks there is magic at work ;) | 11:55 |
| franred | ssam2, yeah!! :) | 11:56 |
| Krin | YAY MAGIC! | 11:56 |
| franred | jjardon, 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.vbs | 11:57 |
| jjardon | http://mason-x86-64.baserock.org/ and http://mason-armv7lhf.baserock.org/ are orange: known issue? | 11:57 |
| franred | looks like libsystemd-daemon is not in the system | 11:57 |
| radiofree | tis | 11:57 |
| jjardon | franred: systend doesnt ship libsystemd-daemon anymore, but only libsystemd | 11:57 |
| franred | libvirt is expecting it in :/ | 11:58 |
| radiofree | upgrade libvirt? | 11:58 |
| pedroalvarez | does a new version of libvirt don't need libsystemd-daemon? | 11:59 |
| ssam2 | jjardon: 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 tell | 11:59 |
| ssam2 | when someone commits something to definitions it'll go green | 12:00 |
| jjardon | franred: upgrade libvirt or patch the configure.ac to ask for libsystemd instead libsystemd-daemon | 12:00 |
| jjardon | As I did in http://git.baserock.org/cgi-bin/cgit.cgi/delta/node-startup-controller.git/commit/?h=baserock/systemd_v216&id=b77fb1dbb280ec45525853e52a362eafd736b400 | 12:00 |
| franred | jjardon, cheers, I will do that, Im currently using the latest stable release 1.2.10 | 12:06 |
| franred | git.baserock.org/cgi-bin/cgit.cgi/delta/libvirt.git/refs/heads?h=baserock/v1.2.10 | 12:06 |
| jjardon | franred: you will have to patch, even master is requesting libsystemd-daemon | 12:06 |
| jjardon | franred: maybe is a good idea to send the patch upstream as well | 12:06 |
| jjardon | jonathanmaw: 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 systemd | 12:15 |
| *** madhu__ [~madhu@202.0.77.198] has joined #baserock | 12:18 | |
| jonathanmaw | jjardon: does systemd change the format of its version numbers? | 12:18 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 12:19 | |
| jjardon | jonathanmaw: newer systemds only ships a systemd.pc file, not ibsystemd-daemon.pc, libsystemd-id128.pc, libsystemd-journal.pc or libsystemd-login.pc | 12:20 |
| jjardon | Its not a problem if you do not plan to support very recent versions of systemd | 12:21 |
| rdale | enlightenment efl won't build with the new systemd pkgconfig files | 12:21 |
| rdale | you can build systemd with a backwards compatibilty option | 12:22 |
| jjardon | rdale: you can, but Id prefer to fix the upstream configure.ac instead | 12:26 |
| jjardon | that configure option is temporal and can be removed at any point | 12:27 |
| pedroalvarez | jjardon: s/temporal/temporary/ :P | 12:32 |
| pedroalvarez | yeah, is better to fix upstream | 12:33 |
| franred | jjardon, 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 |
| franred | s/a version/the version number on the node-startup-controller fix/ | 12:36 |
| jonathanmaw | since 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/Wbuaic5x | 12:38 |
| jonathanmaw | as advised in https://autotools.io/pkgconfig/pkg_check_modules.html | 12:38 |
| jonathanmaw | unfortunately, I don't currently have a system where I can test that it works when I have libsystemd.pc instead of libsystemd-daemon.pc | 12:39 |
| jjardon | franred: libsystemd was very recently added, so if its there the version will be new enough. If you add the version will be correct as well | 12:39 |
| jjardon | jonathanmaw: yeah, that makes sense | 12:40 |
| jonathanmaw | jjardon: Could you test that configure works with it | 12:40 |
| jonathanmaw | my m4-foo is weak, so I don't trust my code by eye | 12:40 |
| jjardon | jonathanmaw: sure, but you simply have to build a genivi system using current definitions: currently only libsystemd.pc is generated | 12:43 |
| pedroalvarez | I guess franred can test that patch quickly | 12:44 |
| jonathanmaw | jjardon: Easier for you than me, since I haven't used baserock for a while, and don't have a fully-stocked artifact cache | 12:44 |
| pedroalvarez | jonathanmaw: everybody has now!!! http://cache.baserock.org | 12:44 |
| * jonathanmaw doesn't understand what that's showing, following the link shows a cgit site full of repos | 12:46 | |
| persia | jonathanmaw: 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 |
| persia | Or rather, only have to build that which is built as a result of a patch | 12:46 |
| ssam2 | adding instructions to http://cache.baserock.org:8080/ would be a neat improvement | 12:47 |
| persia | See http://wiki.baserock.org/quick-start/ for the relevant configuration (under "Configure Morph") | 12:47 |
| ssam2 | would need a change to morph-cache-server, I guess | 12:47 |
| pedroalvarez | jonathanmaw: I just wanted to spread the word, that not having an artifact cache is not longer an excuse :) | 12:47 |
| persia | ssam2: That's a brilliant idea | 12:48 |
| franred | pedroalvarez, 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 now | 12:51 |
| pedroalvarez | fair enough | 12:51 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 13:04 | |
| franred | pedroalvarez, 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 #baserock | 13:14 | |
| *** elevenarms______ [~elevenarm@58.251.146.236] has quit [Ping timeout: 255 seconds] | 13:18 | |
| *** elevenarms______ [~elevenarm@43.249.128.119] has joined #baserock | 13:19 | |
| paulsher1ood | richard_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 #baserock | 13:33 | |
| persia | Generally speaking, one should always code defensively. | 13:34 |
| paulsher1ood | persia: yes. i know. next? | 13:34 |
| persia | That 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 |
| persia | If 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 |
| paulsher1ood | not for the use-cases i'm aiming at, as far as i can tell? | 13:35 |
| persia | For 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 |
| paulsher1ood | heh | 13:36 |
| persia | If I had quotes in that anywhere, it could cause all sorts of unexpected behaviour, rather than just causing an error. | 13:36 |
| persia | But 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 fun | 13:37 | |
| persia | You may find "bar; rm -rf /" more effective (with the quotes) | 13:38 |
| richard_maw | in that case it would unconditionally destroy your system, because the ; is interpreted by your shell | 13:38 |
| robtaylor | paulsher1ood: tbf if richard_maw has been involved, it probably handles quoting correctly | 13:38 |
| persia | robtaylor: The problem is that richard_maw appears to be human, and so sometimes allows patches he has not reviewed to be merged. | 13:39 |
| robtaylor | true... | 13:39 |
| paulsher1ood | i was cribbing persia's example, richard_maw | 13:39 |
| richard_maw | yup, 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 arguments | 13:41 |
| persia | my example was improperly quoted | 13:41 |
| richard_maw | since that increases the likelihood that you'll pass escaped arguments to a different script by accident | 13:41 |
| persia | Note 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 | |
| paulsher1ood | this level of shell-fu is beyond me | 13:42 |
| persia | robtaylor: That presumes an unwillingness to fix the script. | 13:42 |
| richard_maw | robtaylor: that's why I'm picky about whitespace safety in shell scripts | 13:43 |
| richard_maw | paulsher1ood: which means it shouldn't be written in shell | 13:43 |
| robtaylor | persia: 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 is | 13:44 |
| paulsher1ood | richard_maw: what does? my lack of shell fu? | 13:44 |
| * paulsher1ood disagrees, if that's what richard_maw means :) | 13:44 | |
| richard_maw | paulsher1ood: yes, though that wording implies its your skill level at fault, which I didn't mean to imply. | 13:45 |
| paulsher1ood | robtaylor: note 'these sorts of problems' are theoretical in this paricular case | 13:45 |
| persia | robtaylor: 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 matter | 13:46 | |
| richard_maw | paulsher1ood: 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 language | 13:46 |
| persia | I 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 |
| persia | s/every/ever/ | 13:46 |
| paulsher1ood | richard_maw: only if your (and persia's) assumption that it needs to be bulletproof vs injection etc is valid | 13:46 |
| persia | As 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 |
| paulsher1ood | note i am not proposing (and have never proposed) that this script or anything similar should be used in production | 13:47 |
| persia | But 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 |
| petefoth | richard_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 there | 13:48 |
| persia | paulsher1ood: It depends on how one defines "production". Does a compiler get "used in production"? Should it be "production quality"? | 13:48 |
| paulsher1ood | fair enough. i'll give up, shall i? | 13:49 |
| robtaylor | paulsher1ood: yeah, i have no idea what your script is doing, but looks like it takes a command to run | 13:49 |
| paulsher1ood | robtaylor: it builds $1 and deploys it to $2 | 13:49 |
| paulsher1ood | optionally with a new label $3 | 13:50 |
| richard_maw | petefoth: looks good to me: +1 | 13:50 |
| persia | paulsher1ood: 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_maw | My 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 |
| paulsher1ood | i 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 | |
| robtaylor | oh, in which case, doesnt sound so critical, just needs to be safe | 13:54 |
| * persia read the bits about ssh as a recommendation to use a function to be more whitespace safe | 13:55 | |
| richard_maw | there's two levels of whitespace safety involved, the trivial one can be handled with a function, using ssh adds a more difficult obstacle | 13:56 |
| petefoth | richard_maw: thanks. Now merged and pushed to master on my github repo https://github.com/petefoth/morph | 13:56 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 13:58 | |
| jonathanmaw | pedroalvarez: 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 #baserock | 14:22 | |
| pedroalvarez | jonathanmaw: 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 #baserock | 14:34 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:58 | |
| pdar | Hiya, 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 |
| radiofree | pdar: $DESTDIR$PREFIX in the install | 15:21 |
| ssam2 | pdar: you're nearly there, the problem is that you need to install to "$DESTDIR"/"$PREFIX/" | 15:21 |
| radiofree | is that not the same as "$DESTDIR/$PREFIX/"? | 15:22 |
| ssam2 | yeah, | 15:23 |
| ssam2 | I think | 15:23 |
| pdar | ssam2: Thanks, I tried that too and got an error... I cant remember which error though. | 15:23 |
| radiofree | pdar: probably $DESTDIR$PREFIX/include doesn't exist | 15:23 |
| radiofree | mkdir -p $DESTDIR$PREFIX/include first | 15:23 |
| radiofree | although i think people prefer for you to use install | 15:24 |
| pdar | radiofree: thanks! I shall try this | 15:24 |
| radiofree | you'll probably want to do mkdir -p $DESTDIR$PREFIX/lib as well | 15:25 |
| radiofree | before the cp to lib | 15:25 |
| pdar | radiofree: there was an install produced by the make before but the newer version didnt produce one... | 15:25 |
| radiofree | pdar: there's an "install" command that can also be used | 15:26 |
| paulsher1ood | (instead of mkdir etc) | 15:26 |
| ssam2 | i believe the advantage of using 'install' is you can set the correct permissions at the same time that you copy the file | 15:26 |
| ssam2 | there may be other reasons i'm unaware of | 15:26 |
| radiofree | pdar: e.g http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/bsp-jetson/u-boot@jetson.morph | 15:27 |
| paulsher1ood | pdar - try 'install --help' | 15:27 |
| radiofree | though i think i made that morph file so it's probably not the best example of install usage | 15:27 |
| pdar | radiofree: aha, now I feel silly... | 15:28 |
| pdar | thanks! | 15:28 |
| persia | ssam2: It has more options to be careful about things, and change content during install (e.g. --backup or --strip) | 15:28 |
| pedroalvarez | oops, morph check fails because of the latest changes in the docs :/ | 15:28 |
| pdar | and thanks paulsher1ood too | 15:28 |
| radiofree | i have actually used mkdir -p "$DESTDIR$PREFIX/bin" instead of install >.< | 15:28 |
| * paulsher1ood too :) | 15:28 | |
| radiofree | i think it's install -d $DESTDIR$PREFIX/bin though | 15:28 |
| petefoth | for 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 |
| persia | petefoth: It is only safe to push to master @ github if you never need to take changes from others (from any source). | 15:34 |
| persia | If 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 |
| persia | Which means nobody would be able to trust the SHA1s from your github repo | 15:35 |
| petefoth | persia: I think my only need will be to rebase from g.b.o | 15:35 |
| persia | Yes, 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 tomorrow | 15:36 | |
| persia | Note 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 #baserock | 15: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 #baserock | 15:51 | |
| franred | someone know why dd can refuse to use fdatasync as a conv argument? http://paste.baserock.org/aduqehidim.vhdl | 16:03 |
| *** vmeson [~quassel@128.224.252.2] has quit [Quit: vmeson] | 16:04 | |
| radiofree | the baserock logo in the corner makes it impossible to read the entire line | 16:04 |
| franred | sudo -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=fdatasync | 16:05 |
| *** vmeson [~quassel@128.224.252.2] has joined #baserock | 16:05 | |
| persia | http://paste.baserock.org/efeposipeb.coffee is surprising to me. What did I do wrong? | 16:05 |
| ssam2 | persia: for some reason, at the top of morph.conf you need to add the following line: | 16:06 |
| ssam2 | [config] | 16:06 |
| persia | Ah, INI format | 16:07 |
| radiofree | franred: hm.. works for me :\ | 16:08 |
| ssam2 | busybox vs gnu dd ? | 16:09 |
| radiofree | ssam2: according to franred's log it's coreutils dd | 16:09 |
| ssam2 | right | 16:10 |
| pedroalvarez | is there another one? | 16:11 |
| franred | the one which is using is the coreutils one | 16:11 |
| franred | radiofree, :/ | 16:11 |
| pedroalvarez | franred: `dd --help | grep fdata` | 16:12 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 16:13 | |
| radiofree | it's probably something to do with all that ciner stuff? | 16:13 |
| radiofree | cinder | 16:13 |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 16:13 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 16:13 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 16:13 | |
| radiofree | i just ran dd if.. of... .... conv=fdatasync | 16:14 |
| franred | radiofree, it works running it directly from root | 16:14 |
| franred | yes | 16:14 |
| persia | Does morph reporting "ERROR: Unknown host architecture aarch64" mean I have to play with cross-bootstrap? | 16:15 |
| radiofree | :-o | 16:16 |
| * persia is trying to build armv7lhf binaries in 32-bit | 16:16 | |
| radiofree | that sounds like you're trying to build armv8... | 16:17 |
| ssam2 | persia: the code in question is this: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/util.py#n455 | 16:18 |
| radiofree | you're trying to build armv7lhf binaries on 32-bit what? 32-bit x86? | 16:18 |
| ssam2 | persia: it uses uname to guess what your host architecture is | 16:18 |
| radiofree | you absolutely can't do that | 16:18 |
| pedroalvarez | Is detailed here: http://wiki.baserock.org/guides/how-to-cross-bootstrap/ | 16:18 |
| radiofree | persia: unless you mean you're trying to build armv8 on armv7? you probably can't do that either | 16:19 |
| pedroalvarez | he is cross-building I believe | 16:19 |
| persia | radiofree: I'm trying to build armv7lhf on aarch64. I have no problem *executing* binaries | 16:19 |
| radiofree | ooooh | 16:19 |
| persia | The problem I'm having is logically equivalent to building x86_32 on x86_64 | 16:19 |
| persia | Except ARM | 16:20 |
| radiofree | how exciting to have such problems! | 16:20 |
| ssam2 | persia: on x86 i'd use 'linux32 enter-baserock' to enter the chroot | 16:20 |
| ssam2 | so that 'uname' returned i686 as the architecture | 16:21 |
| ssam2 | I don't know if there's an equivalent to the 'linux32' tool on ARM | 16:21 |
| * persia checks | 16:21 | |
| ssam2 | seems it just wraps 'setarch' | 16:21 |
| ssam2 | so you should be able to use 'setarch' | 16:21 |
| persia | I seem to have /usr/bin/linux32 | 16:22 |
| * persia tries | 16:22 | |
| persia | Heh, 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 incantation | 16:30 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 252 seconds] | 16:31 | |
| radiofree | persia: it's probably not going to work http://git.baserock.org/cgi-bin/cgit.cgi/delta/util-linux.git/tree/sys-utils/setarch.c#n146 | 16:32 |
| persia | Yes, but https://lkml.org/lkml/2012/8/21/586 | 16:33 |
| * persia just has to find the right setarch | 16:33 | |
| radiofree | i can't see how that would work | 16:38 |
| persia | So, I know that this machine can run armv7lhf binaries, because I'm running them. | 16:39 |
| pedroalvarez | urgh.. morph test suite is really broken :( | 16:40 |
| persia | Therefore, it ought be able to lie to itself and pretend to be armv7lhf | 16:40 |
| franred | radiofree, 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 |
| radiofree | persia: i meant i don't see how setarch can be used to do that? | 16:41 |
| radiofree | what do you get with "setarch linux32 uname -m"? | 16:41 |
| franred | the 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 finds | 16:42 |
| persia | radiofree: Hrm? Is it not the same as `setarch i486 foo` when one is running in x86_64, and could do `setarch i686`? | 16:42 |
| persia | radiofree: armv8l | 16:42 |
| radiofree | persia: they are defined in the tool though http://git.baserock.org/cgi-bin/cgit.cgi/delta/util-linux.git/tree/sys-utils/setarch.c#n165 | 16:43 |
| radiofree | "armv7" isn't | 16:43 |
| persia | But 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 |
| persia | To me, the latter is clearly armv7lhf | 16:43 |
| persia | In fact, the latter is from cache-key 1a852e85a25c8ad697eae5b22748fc73b6f29ea877640590bf65e98adbd60c66, so likely built by the armv7lhf distbuild cluster | 16: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 #baserock | 16:47 | |
| robtaylor | persia: i presume you just need to add the arm transitions into setarch | 16:48 |
| robtaylor | persia: presumably they aren't there because noone has written them yet | 16:49 |
| persia | robtaylor: So you don7t agree that what I seek is impossible? | 16:49 |
| robtaylor | persia: prior to armv8 there was no need for setarch to do anything on arm... | 16:49 |
| robtaylor | persia: no, just requires adding a few lines to sys-utils/setarch.c | 16:49 |
| robtaylor | persia: which is what i think radiofree is trying to tell you | 16:50 |
| radiofree | yeah... | 16:50 |
| persia | That'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 |
| robtaylor | persia: a quick search turns up nothing for me | 16:51 |
| persia | radiofree: my apologies: I misunderstood | 16:51 |
| robtaylor | persia: doesn't look like fedora has patches for this yet http://pkgs.fedoraproject.org/cgit/util-linux.git/tree/ | 16:55 |
| persia | No distro does (I've already checked). Now chatting with linaro folk to get hints | 16:55 |
| robtaylor | persia: its just adding a line for target_arch to result_arch | 16:56 |
| persia | Yes. | 16:56 |
| robtaylor | persia: target_arch is whatever uname is returning for you on your armv8 system | 16:57 |
| robtaylor | persia: result arch is armv7l | 16:57 |
| robtaylor | (I lost track of the aarch64 arch naming discussion - is it aarch64 or something sane?) | 16:58 |
| persia | robtaylor: aarch64 and armv8l | 16:59 |
| persia | (64-bit vs. 32-bit) | 16:59 |
| robtaylor | eh? | 16:59 |
| paulsher1ood | robtaylor: he's working on a 64-bit machine | 17:00 |
| robtaylor | how does armv8l differ to armv7l then? | 17:00 |
| * paulsher1ood reads up, then decides he's out of his depth, as usual | 17:00 | |
| persia | I haven't reviewed the ISA changes. | 17:00 |
| robtaylor | paulsher1ood: i'm aware of that, i just din't think armv8 in 32bits was any different to armv7 in 32 bits | 17:00 |
| paulsher1ood | where is rjek when we need him to split this kind of hair? :) | 17:01 |
| robtaylor | wow yeah, seems so | 17:01 |
| robtaylor | https://groups.google.com/d/msg/linux.kernel/vZow60-EFQA/NrSSFcf7TpYJ | 17:02 |
| flatmush | I assume that there are mode changing instructions, minor error fixes and armv8l will likely use a newer version of VFP/NEON | 17:03 |
| robtaylor | so i guess you'll need a aarch64 to aarch32(armv8l) then | 17:03 |
| persia | robtaylor: That already works | 17:04 |
| *** elevenarms______ [~elevenarm@113.87.233.201] has quit [Quit: Be back later ...] | 17:04 | |
| robtaylor | persia: it does? thats.. interesting.. | 17:04 |
| radiofree | persia: what does uname -m report (without setarch) | 17:04 |
| radiofree | i guess armv8l working is because of http://git.baserock.org/cgi-bin/cgit.cgi/delta/util-linux.git/tree/sys-utils/setarch.c#n208 | 17:05 |
| persia | Right | 17:06 |
| robtaylor | ah, of course, init is 32 bit, so you're getting armv8l | 17:08 |
| robtaylor | setarch aarch64 will of course fail | 17:09 |
| persia | And it turns out, we don't want to do this. | 17:09 |
| robtaylor | yet | 17:09 |
| persia | Or at least arnd (the author of the lkml mail in question) doesn't think so. | 17:09 |
| persia | The problem being that the ISAs are subtly different, and while there is some backwards compatibility, it isn't guaranteed. | 17:09 |
| robtaylor | well that screws the pooch | 17:10 |
| robtaylor | though for our cases, any backward compat issues are likely to be highly unlikely to cause an issue | 17:11 |
| persia | Hrm? How do you mean? | 17:11 |
| robtaylor | we want to run binaries that build things. The sort of non-backwards compat changes tend to be in things like VFP and freinds | 17:12 |
| robtaylor | which you pretty much aren't going to use when compiling, or running shell scripts. | 17:12 |
| robtaylor | um | 17:13 |
| robtaylor | seems he's talking arse though | 17:13 |
| persia | If two ISAs differ, I think we ought differ. | 17:13 |
| robtaylor | arm's literature claims backwards compat | 17:13 |
| robtaylor | http://www.arm.com/products/processors/armv8-architecture.php | 17:14 |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 17:14 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:22 | |
| pdar | pedroalvarez: 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 |
| pedroalvarez | you 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/#index7h2 | 17:25 |
| robtaylor | persia: so yeah, sorry, i misread what it was doing, it just does th same as linux32/linux64 | 17:25 |
| robtaylor | linux on armv8 aims to be backwards compat to armv6 | 17:25 |
| persia | Then we should support that, either by changing morph, or adding kernel support. | 17:26 |
| robtaylor | so all you need is a way to tell morph to build a particular arch | 17:26 |
| robtaylor | which i thought we had.. richard_maw ? | 17:26 |
| pdar | pedroalvarez: thanks! | 17:26 |
| pedroalvarez | I wonder if this failure may be related to the 'git' upgrade: http://paste.baserock.org/umojagucoj.diff | 17:27 |
| pdar | git clone https://code.google.com/p/gperftools/ | 17:27 |
| radiofree | i don't think morph likes building when the arch doesn't match the system arch | 17:27 |
| pedroalvarez | pdar: well done :) | 17:27 |
| pdar | whoops, sorry | 17:27 |
| radiofree | so trying to build armv7 (this is what you're trying to do right?) won't work | 17:27 |
| * robtaylor thoight some bits for this happened when the sdk/canadian cross stuff got written | 17:28 | |
| pedroalvarez | franred: I remember you reviewed the git upgrade, did you run morph's ./check? | 17:28 |
| persia | radiofree: Right. I need to either change morph, or change the system arch. | 17:29 |
| radiofree | persia: maybe add armv8l as an alias for armv7l or something as a quick hack | 17:30 |
| robtaylor | persia: yep, looks like you need some fixes to morph | 17:31 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:31 | |
| robtaylor | persia: probably something like the transition table would make sense. e.g. 'armv6? on arm8? is ok' 'armv7? on armv8?' is ok etc | 17:31 |
| robtaylor | persia: around about here http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/buildcommand.py#n127 | 17:32 |
| persia | robtaylor: Why not http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/util.py#n455 | 17:33 |
| robtaylor | persia: though as a quick hack, you could try running a qemu --enable-kvm | 17:34 |
| robtaylor | persia: because that's not where the logic is | 17:34 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 258 seconds] | 17:35 | |
| robtaylor | persia: i would say _validate_architecture would be the senible thing to say 'and yes you can build arch <x> on arch <y> | 17:35 |
| persia | Hrm? buildcommand.py#n128 calls util.py#n455 | 17:35 |
| robtaylor | persia: rather than pretend the host is some other arch | 17:36 |
| persia | Oh, that seems reasonable | 17:36 |
| robtaylor | :) | 17:36 |
| persia | To confirm, you suggest changing the conditional in line 129? | 17:37 |
| persia | And I'd like to exclude armv6, due to cp15 and potentially setend | 17:38 |
| persia | Unless you have some usecase that requires it? | 17:38 |
| robtaylor | persia: yep (129) | 17:39 |
| robtaylor | persia: agreed on armv6. Usecase would be building for raspberry pi, which would be nice to be able to do but... | 17:39 |
| persia | This is why there are virtual machines :) | 17:40 |
| robtaylor | persia: actually, see arn't's statement | 17:41 |
| persia | What, about kernel traps? | 17:41 |
| robtaylor | persia: the armv6 stuff could be a kernel version check | 17:41 |
| persia | not for raspbian | 17:42 |
| persia | because setend and non-endian-swapping | 17:42 |
| robtaylor | noone would use that in a build system | 17:42 |
| robtaylor | gcc wouldn't emit it | 17:42 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:42 | |
| persia | Nobody would want to build stuff on a raspberry pi? | 17:42 |
| robtaylor | you'd have to have a tool that explictaly did it, and noone did | 17:42 |
| robtaylor | noone would use setend | 17:43 |
| persia | Except raspbian's toolchain does, according to arnd | 17:43 |
| robtaylor | (set endian) | 17:43 |
| robtaylor | persia: no, thats the cp15 barriers, which are trapped and emulated | 17:43 |
| robtaylor | (at least, that's my reading of the conversation) | 17:44 |
| radiofree | i believe richard dale tried to build qt5 on a raspberry pi, once | 17:44 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:45 | |
| persia | radiofree: If he wasn't using an armv8l machine to do it, it should have worked (if slowly) | 17:46 |
| radiofree | this was outside of baserock | 17:46 |
| radiofree | i was just giving you an example of how people are crazy and try to do crazy things ;P | 17:46 |
| radiofree | <persia> Nobody would want to build stuff on a raspberry pi? | 17:46 |
| persia | radiofree: 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 thing | 17:48 | |
| robtaylor | persia: ah, no, i misread. Looks like rasbian specifically uses this by using https://github.com/bavison/arm-mem | 17:48 |
| radiofree | well it would be nice to *build for* a raspbery pie on a decent baserock system | 17:48 |
| radiofree | like a jetson or something | 17:48 |
| robtaylor | persia: but that's really just a case of 'well don't do that then' for baserock | 17:48 |
| persia | robtaylor: Well, there's still virtual machines :) | 17:48 |
| radiofree | i'd like to see the raspberry pi weston backend in action! | 17:48 |
| robtaylor | persia: no, i think you misunderstand my statement | 17:49 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:49 | |
| robtaylor | persia: its a case of 'well dont build a staging area that uses arm-mem' | 17:49 |
| robtaylor | persia: which is probably reduced just fine to 'don't use arm-mem' in a baserock system. ;) | 17:50 |
| persia | I don't like the idea of excluding valid sources | 17:51 |
| persia | Seems more reasonable to require them to be built in specific environments | 17:51 |
| robtaylor | persia: i supose so | 17:51 |
| robtaylor | persia: a reasonable approach would be to create an arch name for armv6 without setend and it | 17:53 |
| persia | In morph? | 17:53 |
| persia | Or in the toolchain? | 17:53 |
| persia | (or both) | 17:53 |
| robtaylor | in morph | 17:54 |
| persia | I 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 problem | 17: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 | |
| pedroalvarez | I'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 |
| pedroalvarez | http://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 #baserock | 18:04 | |
| radiofree | pedroalvarez: looks ok to me, +1 | 18:06 |
| radiofree | why 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 #baserock | 18:07 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 18:07 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:07 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 18:07 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 18:08 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 18:08 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:08 | |
| DavePage | Autocorrect? | 18:10 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 18:13 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 18:13 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 18:13 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:13 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 18:13 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:14 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 18:14 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 18:15 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 18:15 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:15 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 18:15 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 18:16 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 18:16 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:16 | |
| robtaylor | persia: hopefully the mail i just sent captures your understanding also :) | 18:28 |
| persia | robtaylor: There's nothing in there that contradicts the subset of things I understood :) | 18:30 |
| robtaylor | win! | 18:30 |
| robtaylor | ah, but did the mail clarify the parts you didn't? | 18:31 |
| persia | Yes, 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 case | 18:32 | |
| robtaylor | yes, 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 #baserock | 19:05 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 19:19 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 19:25 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 19:25 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 19: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 #baserock | 19:35 | |
| *** De|ta_ [~arc@195.242.156.171] has joined #baserock | 21:24 | |
| *** jmacs_ [~jimmacart@access.ducie-dc1.codethink.co.uk] has joined #baserock | 21:24 | |
| *** radiofree_ [radiofree@2a01:7e00::f03c:91ff:feae:d2f1] has joined #baserock | 21:26 | |
| *** radiofree_ [radiofree@2a01:7e00::f03c:91ff:feae:d2f1] has quit [Changing host] | 21:26 | |
| *** radiofree_ [radiofree@unaffiliated/radiofree] has joined #baserock | 21:26 | |
| *** vmesons [~quassel@128.224.252.2] has joined #baserock | 21:26 | |
| persia | OK. Worked past that. Next is http://paste.baserock.org/yizowogeza.py | 21:42 |
| persia | Is this because I failed to set up my chroot properly? | 21:42 |
| persia | Also, I'm a bit worried that an attempt to build "systems/devel-system-armv7lhf-chroot.morph" from definitions 778f4b6a95dc3510d9d2d70866d5142691da1a78 | 21:44 |
| persia | resulted in an actual build: should this not have been cached? | 21:44 |
| * persia was not expecting any compilation: just cache download and assembly | 21:45 | |
| paulsher1ood | persia: not sure we build the chroot systems | 21:46 |
| paulsher1ood | try building jetson system, for example? | 21:46 |
| persia | Hrm. This makes me wonder if building selected systems is indeed the best way to populate cache. | 21:48 |
| persia | Perhaps we ought be building strata (and all of them), or similar. | 21:48 |
| persia | But 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 moment | 21:49 | |
| persia | I still wonder about the morph error about / not being a mountpoint | 21:50 |
| persia | jetson crashes at the same point | 21:50 |
| persia | (with the same error, and the same attempt to perform a local build) | 21:50 |
| paulsher1ood | try resetting to last known good ref? 778f4b6a95dc3510d9d2d70866d5142691da1a78 | 21:51 |
| * persia wonders if running `morph build systems/devel-system-armv7lhf-jetson.morph` can be done entirely from cache on a jetson | 21:51 | |
| paulsher1ood | (just to be sure) | 21:51 |
| persia | I'm on 778f4b6a95dc3510d9d2d70866d5142691da1a78 | 21:52 |
| paulsher1ood | ok | 21:52 |
| persia | But I'm using a hacked morph on an unsupported architecture, which may affect things :) | 21:53 |
| paulsher1ood | at that ref, i also see builds from 129 onwards, for x86_64-chroot.morph | 21:53 |
| persia | OK, but the jetson system I tried wasn't a chroot | 21:55 |
| paulsher1ood | i 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 system | 21:55 | |
| persia | I 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 fetched | 21:58 | |
| persia | I suspect it is "build", because the jetson build is now at 171/174 all in cache. | 21:59 |
| persia | And now 174/174 | 21:59 |
| * persia rather wishes morph could notice that it could just download the final product, and didn't bother downloading all the intermediate artifacts | 22:00 | |
| * paulsher1ood wishes that too. and has looked at the code, but did not reach enlightenment | 22:01 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 22:04 | |
| persia | Hurrah. With a badly constructed chroot and a tiny patch, I can build cached armv7 systems in armv8 | 22: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 whole | 22:05 | |
| robtaylor | persia: awesome :) | 22:05 |
| persia | robtaylor: Except I seem to *also* download the whole, which defeats the benefit | 22:05 |
| paulsher1ood | persia: w00t! :) | 22:06 |
| persia | But 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 again | 22:06 |
| paulsher1ood | persia: but for non-cached systems? | 22:06 |
| robtaylor | persia: well, that does suck | 22:06 |
| persia | paulsher1ood: 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 |
| robtaylor | persia: i think i agree, though its bad that sys int isn't safely reproducable | 22:07 |
| persia | robtaylor: No executable code is safely reproducible. | 22:07 |
| persia | Cosmic rays, etc. | 22:07 |
| paulsher1ood | in other news, devel-system-x86_64-generic artifacts *are* all cached on cache.baserock.org | 22:07 |
| robtaylor | persia: at that limit, neither is any declaritive structure | 22:08 |
| * robtaylor wouldn't want to solve that issue | 22:08 | |
| persia | Yes, but more seriously, the more different times I run the same commands, the more likely I will have an issue. | 22:09 |
| paulsher1ood | while 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 |
| persia | So if I believe them to have run correctly once, I'd rather store the results than run them again. | 22:09 |
| robtaylor | paulsher1ood: yep | 22:09 |
| persia | paulsher1ood: Unless there is useful support for cross-execution, that would break the configuration extensions. | 22:09 |
| robtaylor | paulsher1ood: i'd love that | 22:10 |
| robtaylor | persia: i though config was run outside of your constructed root anyhow? | 22:10 |
| * persia wouldn't : qemu-user-static isn't sufficiently reliable | 22:10 | |
| robtaylor | persia: and so it'd make sense for your config to run as host arch | 22:11 |
| persia | robtaylor: I thought it ran inside chroots, but either way, it may require architecture-specific code | 22:11 |
| robtaylor | persia: not if you say arch specigfic code isn't supported =) | 22:11 |
| persia | robtaylor: That breaks most interesting hardware support. | 22:11 |
| robtaylor | how so? | 22:11 |
| persia | We're getting better, but even x86 still requires arch-specific code | 22:12 |
| paulsher1ood | persia: 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 |
| persia | I 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 |
| robtaylor | mm, yes, i suppose oe/yocto still cary a few patches for this | 22:13 |
| persia | paulsher1ood: Because you might have configuration extensions that require execution of ARM code. | 22:13 |
| paulsher1ood | on my machine, not the target? | 22:13 |
| robtaylor | though, really, qemu really is sufficient | 22:13 |
| robtaylor | i have an existance proof | 22:14 |
| persia | Yes, 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 |
| persia | robtaylor: 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-x86 | 22:14 |
| robtaylor | persia: existance proof | 22:15 |
| robtaylor | persia: let me give you a pointer | 22:15 |
| robtaylor | http://jolla.com/ | 22:15 |
| persia | But 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 |
| persia | It depends on what one compiles. The haskell stack is particularly hard on qemu-static, for example | 22:15 |
| robtaylor | https://wiki.merproject.org/wiki/Platform_SDK_and_SB2 | 22:15 |
| persia | These are toy archives, with narrow focus. Yes, it can work for some systems. It is not currently general. | 22:16 |
| robtaylor | persia: for deployment? | 22:16 |
| persia | I don't believe there are currently any restrictions on what users may run at deployment time. | 22:16 |
| persia | Specifically, 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 | |
| paulsher1ood | heh | 22:17 |
| persia | Unless this is guarded in some way, I would not be confident asserting that qemu-static was safe. | 22:17 |
| robtaylor | persia: if someone does something that doesnt work, they get to keep the peices | 22:17 |
| robtaylor | well done | 22:17 |
| * paulsher1ood surrenders for the day | 22:18 | |
| robtaylor | all you need to say is 'this should work in qemu static if youre doing cross platform development' | 22:18 |
| persia | I'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 |
| robtaylor | and jobs done | 22:18 |
| robtaylor | paulsher1ood: night :) | 22:18 |
| robtaylor | persia: i'm generally all for making warning labels | 22:19 |
| persia | Then we agree :) | 22:19 |
| robtaylor | persia: and then gradually removing them as things get fixed | 22:19 |
| robtaylor | any other approach tends to lead to paralysis, i find | 22:19 |
| persia | In 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 |
| robtaylor | persia: that last statment didn't make any sense to me | 22:20 |
| persia | I 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 |
| persia | I 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 |
| robtaylor | persia: i think ytou are very wrong | 22:21 |
| persia | Not about the people: they people there are great: just about the way that qemu works. | 22:21 |
| persia | I'd be happy if you were correct about me being wrong :) | 22:21 |
| robtaylor | persia: i showed you an existance proof you are wrong | 22:22 |
| robtaylor | for 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 |
| persia | You 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 |
| robtaylor | persia: mer compiles everything we want to compile | 22:23 |
| robtaylor | persia: you're just saying 'i know better because i know better'. That isn't a good argument. | 22:23 |
| persia | Then I am not part of your "we", because there are many things I want to compile that mer does not compile | 22:23 |
| robtaylor | persia: yes, but you aren';t doing cross development | 22:24 |
| robtaylor | persia: you're doing things for big hefty servers, and hey, you know what? you have big hefty servers to use | 22:24 |
| persia | No, 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 |
| robtaylor | persia: so, you better give me those before saying its impossible | 22:25 |
| persia | Hrm? 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 |
| robtaylor | persia: rather than a vague ' i remmeber there were some issues with something' | 22:25 |
| robtaylor | persia: its not meaningful becuase noone really needs it | 22:25 |
| robtaylor | arm on x86, definitly is needed | 22:25 |
| * persia did | 22:25 | |
| persia | In fact, for years I routinely only carried ARM laptops, and often worked on x86 targets. | 22:26 |
| robtaylor | persia: that's an obscure corner case, not what mer is doing | 22:26 |
| persia | I 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 |
| robtaylor | persia: i'd love to hear why you thing it can't be made complete | 22:27 |
| persia | My belief should not prevent anyone from using it for cases where it works (like building x86 server software on ARM laptops). | 22:27 |
| robtaylor | persia: 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 |
| persia | I 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 |
| robtaylor | persia: i think that changed a while back | 22:30 |
| persia | That is excellent news. I hope so. | 22:31 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!