| straycat | speaking of kvm... https://gerrit.baserock.org/#/c/151/ | 06:48 |
|---|---|---|
| *** mike has joined #baserock | 07:07 | |
| *** mike is now known as Guest10273 | 07:07 | |
| *** a1exhughe5 has joined #baserock | 07:14 | |
| *** Albert has joined #baserock | 07:27 | |
| paulsherwood | persia: ybd does sandboxing | 07:43 |
| paulsherwood | (the same sandboxing as morph, iiuc) | 07:43 |
| paulsherwood | however it's still far from 'production quality' | 07:43 |
| paulsherwood | and morph can do a whole load of things that ybd has no concept of | 07:45 |
| paulsherwood | jjardon: i may have misunderstood your chroot question. ybd runs its build commands in a chroot, but doesn't itself need to be in a chroot | 07:48 |
| paulsherwood | jjardon: vs jhbuild i'm not sure. i've never used that | 07:48 |
| *** mdizzle has joined #baserock | 07:56 | |
| *** gary_perkins has joined #baserock | 07:56 | |
| *** mdunford has joined #baserock | 07:59 | |
| *** bashrc_ has joined #baserock | 08:02 | |
| *** jonathanmaw has joined #baserock | 08:04 | |
| persia | paulsherwood: Ah. I misunderstood your chroot comment. | 08:10 |
| paulsherwood | i mis-stated it :) | 08:11 |
| *** rdale has joined #baserock | 08:12 | |
| straycat | hrm, the storage node configuration i'm currently doing at first boot could almost be done at deploy time, but i'd probably have to assume a uid for the 'swift' user, or maybe fiddle with /etc/passwd in a conf ext, maybe there should be an extension that allows you to manipulate users/groups at deploy time? | 08:31 |
| paulsherwood | straycat: there was some discussion about the possibility of standardizing uids on baserock systems (to avoid confusion and possibly security implications) | 08:33 |
| paulsherwood | rjek and others may know more | 08:33 |
| paulsherwood | but i believe some folks are already eastering | 08:34 |
| jjardon | paulsherwood: oh cool, its better than jhbuild then :) | 08:34 |
| paulsherwood | well, i guess jhbuild *works* for more use-cases, so i wouldn't claim anything for ybd yet :) | 08:35 |
| paulsherwood | (except that it has less code than most things) | 08:35 |
| jjardon | SotK: pango-querymodules > /usr/etc/pango/pango.modules you missed the pango folder | 08:37 |
| SotK | jjardon: oops! I'll try that later, thanks :) | 08:40 |
| straycat | /usr/etc/... ? | 08:41 |
| *** edcragg has joined #baserock | 08:52 | |
| *** pdar has quit IRC | 08:58 | |
| paulsherwood | Albert: darnit. i forgot you're called albert | 09:00 |
| Albert | heh | 09:00 |
| paulsherwood | anyways, your patch doesn't apply cleanly, which suggests you may be working on an old version of ybd | 09:00 |
| paulsherwood | please could you check if master already has that issue solved? | 09:01 |
| Albert | I think you're right. I'll have a mess with with it | 09:01 |
| *** Krin has joined #baserock | 09:01 | |
| paulsherwood | also, there are some actual live issues there which you'd be welcome to look at if you're interestedf | 09:01 |
| Albert | Of course. Lets' just straighten this out. I'll look back through the log. | 09:06 |
| franred | edcragg, whooohooo!!! deploy!! deploy!! :D | 09:06 |
| *** pdar has joined #baserock | 09:10 | |
| bashrc_ | is there a callback available for cliapp.runcmd in baserock? | 09:14 |
| paulsherwood | you mean in morph, i assume, bashrc_ - baserock is not a single program | 09:15 |
| *** ssam2 has joined #baserock | 09:16 | |
| *** ChanServ sets mode: +v ssam2 | 09:16 | |
| *** ChanServ sets mode: +o pedroalvarez | 09:18 | |
| tlsa | is there any way to prevent morph from using cached artifacts altogether? (I want to test a change to .meta generation) | 09:23 |
| ssam2 | to ignore remote artifacts, you can pass --artifact-cache-server='' (empty string) | 09:24 |
| ssam2 | to ignore local artifacts as well, 'mv /src/cache/artifacts /src/cache/artifacts/hidden' is the easiest way | 09:24 |
| ssam2 | sorry 'mv /src/cache/artifacts /src/cache/artifacts.hidden' | 09:25 |
| ssam2 | or whatever | 09:25 |
| tlsa | ok | 09:25 |
| tlsa | alternatively, is there a swift way to regenerate .meta files locally without a full rebuild? | 09:27 |
| tlsa | (otherwise I can see this testing taking hours) | 09:27 |
| ssam2 | perhaps commenting out the code that actually runs the configure, build and install commands would be the best way | 09:29 |
| ssam2 | so you get a bunch of empty artifacts with .meta files | 09:29 |
| tlsa | ok, sounds like a good idea | 09:31 |
| *** wschaller has joined #baserock | 09:33 | |
| bashrc_ | looks like the cliapp in baserock/python2.7 doesn't match what I see here http://git.baserock.org/cgi-bin/cgit.cgi/delta/cliapp.git/tree/cliapp/runcmd.py | 09:49 |
| straycat | yeah we kinda forked cliapp a bit | 09:50 |
| richard_maw | and we haven't rebased on top of upstream in a while | 09:50 |
| bashrc_ | so it doesn't support callbacks | 09:50 |
| straycat | which we should do given we fixed a bug in rncmd | 09:50 |
| straycat | *runcmd | 09:51 |
| straycat | bashrc_, no callbacks got added later | 09:51 |
| bashrc_ | this may make it difficult to trap errors | 09:51 |
| straycat | we could rework some of the distbuild logging stuff to use callbacks too, iirc | 09:52 |
| straycat | at the moment we end up using tee somewhere :p | 09:52 |
| *** Guest10273 has quit IRC | 09:54 | |
| *** Guest10273 has joined #baserock | 10:08 | |
| *** mike has joined #baserock | 10:11 | |
| *** mike is now known as Guest50424 | 10:11 | |
| *** Guest10273 has quit IRC | 10:14 | |
| *** ssam2 has quit IRC | 10:18 | |
| *** Krin has quit IRC | 10:24 | |
| *** ssam2 has joined #baserock | 10:31 | |
| *** ChanServ sets mode: +v ssam2 | 10:31 | |
| * SotK wishes Gerrit would give more information than "Merge Conflict" | 10:31 | |
| persia | Fetch both trees (second should be fast because you already have most objects), and try a rebase locally. | 10:36 |
| tlsa | SotK, at the top right, of the patch page, go to the "Conflicts with" tab | 10:37 |
| tlsa | SotK: e.g. on this: https://gerrit.baserock.org/#/c/42/6 | 10:37 |
| SotK | there isn't one on the change with Merge Conflict | 10:39 |
| SotK | persia: "Successfully rebased and updated refs/heads/distbuild" | 10:39 |
| persia | Odd. I've never heard of that before. | 10:40 |
| pedroalvarez | SotK: rebased on top of g.b.o/master or gerrit/master | 10:40 |
| * pedroalvarez hopes this is not the problem | 10:41 | |
| SotK | hm, g.b.o master | 10:41 |
| * SotK tries with gerrit master | 10:41 | |
| SotK | that rebase worked fine too, I'll try pushing the changes again and see if it goes away | 10:42 |
| SotK | or not, it failed because there were no new changes | 10:43 |
| pedroalvarez | :( | 10:43 |
| * pedroalvarez notes that the "Conflicts with" list is for patches that havent been merged yet. | 10:44 | |
| *** ssam2 has quit IRC | 10:46 | |
| *** ssam2_ has joined #baserock | 10:46 | |
| straycat | heh what i didn't realise i can give my own patches a score | 10:47 |
| * straycat proceeds to +2 everything he's submitted | 10:47 | |
| straycat | okay i've merged everything and branched morph | 10:50 |
| straycat | unversioned definitions are now invalid | 10:50 |
| rdale | how does morph know how to turn 'upstream:foobar' into git://git.baserock.org/delta/foobar ? | 10:50 |
| Albert | paulsherwood, I'm running through a fresh ybd build (the actual builds are taking ages). In the meantime, would you like to detail the live issues you referred to? | 10:51 |
| paulsherwood | Albert: github | 10:51 |
| Albert | OK | 10:51 |
| pedroalvarez | rdale: morphlib/util.py:173 | 10:52 |
| straycat | rdale, there's a set of repo aliases that get combined with your trove-host | 10:52 |
| straycat | you can define your own repo aliases too if you want | 10:53 |
| *** ssam2_ has quit IRC | 10:55 | |
| rdale | ah, trove-host defines what upstream: means, and so if i had a different trove host to baserock, i would pick up repos from that | 10:58 |
| straycat | yes | 11:02 |
| straycat | same thing goes for baserock: | 11:02 |
| straycat | "Hello Adam Coldrick, Richard Ipsum, Richard Ipsum," | 11:03 |
| straycat | hehehehe | 11:03 |
| *** ssam2_ has joined #baserock | 11:07 | |
| bjdooks | 3 | 11:17 |
| pedroalvarez | straycat: I think is possible to merge users, do you want me to? | 11:18 |
| pedroalvarez | doesn't look easy, forget it :) | 11:20 |
| straycat | no because gerrit enforces that the committer's email must match the email of the openid that's been authenticated to do the push | 11:20 |
| pedroalvarez | straycat: maybe relevant https://gerrit.baserock.org/#/c/146/ | 11:21 |
| ratmice__ | straycat: about the ability to +2 your own patches, I don't recall seeing anyone invoke an 'obvious patch' rule that some projects use | 11:22 |
| straycat | ratmice__, indeed :) | 11:22 |
| straycat | tbf, this is nothing new, nothing technically stopped anyone with push access to gbo from merging their own patches, they're just trusted not to | 11:24 |
| *** Krin has joined #baserock | 11:25 | |
| ssam2_ | indeed, and I hope we can continue to trust people in the Mergers group to be sensible | 11:29 |
| ssam2_ | gerrit ACLs are pretty flexible but I don't want to have them getting in the way | 11:29 |
| ssam2_ | the thing about enforcing the commiters email can be fixed, in fact | 11:29 |
| ssam2_ | I'd like to think that if you have 2 email addresses registered to the same account, it'll let you push commits with either of them. But I don't want to assert that without checking | 11:30 |
| jjardon | ssam2_: Is it possible to configure gerrit to automatically push when a patch have a +2 (so no need to click "submit")? | 11:33 |
| richard_maw | jjardon: I don't think so, which is why we were looking at zuul | 11:33 |
| ssam2_ | jjardon: it might be possible, actually | 11:34 |
| ssam2_ | I'm not sure it's what we want though | 11:34 |
| petefoth | jjardon there was some discussion about that a few weeks back, but I don't recall the outcome | 11:35 |
| * jjardon search for zuul and an image of a ghostbusters' monster appear :) | 11:35 | |
| radiofree | could someone else review https://gerrit.baserock.org/#/c/152/ please | 11:36 |
| ssam2_ | merged | 11:37 |
| radiofree | it's pointing at a sha1 in the 5.4 branch of qtwebkit | 11:40 |
| jonathanmaw | hrm, I'm having trouble deploying the genivi-demo-platform using clusters/genivi-deploy.morph (http://paste.baserock.org/quveqilano). When I run `morph deploy --upgrade clusters/genivi-deploy.morph genivi-demo-platform.VERSION_LABEL=demo-test`, it seems to have some nasty error when cleaning up http://paste.baserock.org/avikocejur | 11:40 |
| radiofree | i asked in #qt about whether or not those branches are ever rebased (it's not a release...) | 11:40 |
| radiofree | apparently they aren't | 11:40 |
| radiofree | but say the 5.4 branch *was* rebased, what would trove do? | 11:40 |
| radiofree | would trove just mirror it completely? | 11:41 |
| radiofree | or do nothing? | 11:41 |
| richard_maw | jonathanmaw: well, is there enough space on your / device? | 11:42 |
| radiofree | jonathanmaw: are you deploying to that jetson? | 11:43 |
| jonathanmaw | radiofree: I think so, the cluster morphology goes to root@127.0.0.1 | 11:43 |
| richard_maw | jonathanmaw: you should be able to clean it up yourself with a `btrfs filesystem delete /tmp/tmp.lOOJoS/systems/demo-test/orig/tmp` | 11:43 |
| radiofree | ROOT_DEVICE: "/dev/mmcblk0p2" | 11:44 |
| radiofree | BOOT_DEVICE: "/dev/mmcblk0p1" | 11:44 |
| radiofree | jonathanmaw: ^ | 11:44 |
| radiofree | oh wait rsync: write failed on "/tmp/tmp.lOOJoS/systems/demo-test/orig/tmp/AudioManagerTest/AmTelnetServerTest": No space left on device (28) | 11:45 |
| pedroalvarez | problem is not when cleaning up (I believe). It cleans up because it failed, and then drop the error | 11:45 |
| jonathanmaw | richard_maw: it seems /tmp is missing those directories, | 11:45 |
| richard_maw | then there will have been some partial cleanup working then, mount your root device manually | 11:45 |
| *** wschaller has quit IRC | 11:46 | |
| *** Guest50424 has quit IRC | 11:49 | |
| ssam2_ | radiofree: it depends on what the .lorry file for that repo says to do | 11:49 |
| ssam2_ | if the refspec allows force-pushes, lorry would force-update the branch. If it didn't, the job would start failing and the repo would stop being updated until we manually fixed it | 11:49 |
| radiofree | i see, what's the default behaviour? | 11:50 |
| radiofree | jonathanmaw: run the btrfs resize command on the board as well | 11:50 |
| radiofree | 10G | 11:50 |
| ssam2_ | radiofree: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/lorry.git/tree/lorry#n507 | 11:51 |
| ssam2_ | so the default is: don't force-push anything | 11:51 |
| jjardon | sorry I ask this again but, If that's the case, why is it needed to use sha instead tags in definitions? seems that you will be always be able to reproduce a build if you have your own trove | 11:56 |
| *** Guest50424 has joined #baserock | 11:56 | |
| paulsherwood | jjardon: actually, that's a good point, provided you administer the trove for reproducibility | 11:57 |
| richard_maw | jjardon: you'd have to make your own tags though, as upstream could move theirs | 12:02 |
| richard_maw | you need to administer your own trove for both approaches | 12:03 |
| richard_maw | but supposing you have a fault, and need to restore your trove from backups, if you don't have the sha1 then you can't verify that you have the right version of the tag | 12:03 |
| jjardon | richard_maw: You will have the tag that you had in your trove, the one that you trusted | 12:05 |
| *** wschaller has joined #baserock | 12:06 | |
| jjardon | richard_maw: and about creating a new tag if upstream changes: you dont have to do that if you done want. But if you do, you can do that when you are manually fixing your trove. Seems a little effort in comparison to the hassle to deal with sha in your day to day baserock use | 12:06 |
| richard_maw | jjardon: Sorry, I was still on why you can't use upstream's tags even if you had a facility to make automatic backup tags to keep the old version around | 12:06 |
| richard_maw | however, I cannot parse your second comment there, I'm not suggesting you make a new tag if upstream changes, I'm suggesting you *have* to make a new tag so you're not relying on upstream ever | 12:07 |
| richard_maw | not replacing their tags | 12:07 |
| richard_maw | I'm not sure what you mean by manually fixing your trove here | 12:08 |
| richard_maw | oh, you mean fixups as part of the restore | 12:12 |
| jjardon | richard_maw: ok, what I suggest: use upstream tags -> upstream rebase/change tags -> trove doesnt rebase (admin you will get some kind of waring here) -> 2 options: keep using upstream tag (now is local to your trove) / go to your trove, rebase the tag and create a new tag if you still want to point to the old one -> change definitions to point to the new | 12:12 |
| jjardon | <upstream>-trove tag / keep using upstream tag | 12:12 |
| richard_maw | ok, so if you left the tag as it was then you run into reproducibility problems if your last backup was before that tag was first created, since after you restore, you'll get the new version of that tag instead of the version you previously used | 12:16 |
| richard_maw | and you can't create a new tag with the old version and alter definitions to point to that instead, because you would then lose reproducibility of previously created systems, since the tags they were using are now different | 12:18 |
| * richard_maw recalls having this discussion before | 12:19 | |
| richard_maw | so you have to either keep the sha1 of the commit in the definition, or create new tags instead of using upstream's | 12:20 |
| richard_maw | and while I would normally have the time to write up why we either need to make our own tags or store the sha1 on a wednesday, I don't for the next few weeks | 12:21 |
| * straycat notes that the new distbuild command when it does get merged might want to be followed up with a change to remove constants and replace them with cli args | 12:25 | |
| jjardon | thanks richard_maw , I understand the problem better now | 12:32 |
| richard_maw | jjardon: potentially we could make lorry automatically generate tags that we are safe to use, but the only name I can think of that is safe to use is baserock/$UPSTREAM_TAG_NAME/$UPSTREAM_TAG_COMMIT, which includes the sha1 in the definition file anyway | 12:39 |
| *** wschaller_ has joined #baserock | 12:48 | |
| *** wschaller___ has joined #baserock | 12:50 | |
| jonathanmaw | hrm, it seems the genivi-demo-platform's browser-poc doesn't include instructions for how to install it | 12:52 |
| *** wschaller has quit IRC | 12:52 | |
| jonathanmaw | meta-genivi-demo suggests I install the browser, demo UI and test app to /opt | 12:52 |
| jonathanmaw | are there any better suggestions? | 12:53 |
| straycat | "It doesn't seem like cancelling builds ever actually worked right --" | 12:54 |
| straycat | ssam2_, ? | 12:54 |
| *** wschaller_ has quit IRC | 12:54 | |
| jonathanmaw | it also has systemd units. What's the recommended way of adding systemd units to baserock now? | 12:55 |
| richard_maw | jonathanmaw: shove the .service files in /usr/lib/systemd/system, and if it doesn't make sense for them not to be enabled, shove a symlink in /usr/lib/systemd/system/$foo.wants, otherwise put a symlink in /etc/systemd/system/$foo.wants or leave the symlink out for the administrator to enable it later | 12:58 |
| richard_maw | I can't offer any advice on how to install the browser-poc, since while I think putting it in /opt is awful, I don't know if it will work if installed elsewhere | 12:59 |
| jonathanmaw | richard_maw: their systemd units currently hover in their meta-genivi-demo repo. Should I add systemd units in the source code and install them from there, or have them in definitions somehow? | 13:00 |
| * SotK couldn't think of a sensible way of installing it last year | 13:00 | |
| richard_maw | I'd avoid checking them into the chunk's source repo | 13:00 |
| richard_maw | though I prefer putting the units in at build time over install time, so add post-install-commands to the chunk definition | 13:01 |
| richard_maw | and install it with a here-document | 13:01 |
| richard_maw | i.e. embed the systemd unit in the chunk definition file | 13:01 |
| SotK | I think there was something daft like "it only worked if run inside its source directory" when I was looking at it which complicated matters | 13:01 |
| richard_maw | :¬( | 13:02 |
| *** Guest50424 has quit IRC | 13:04 | |
| ssam2_ | straycat: please don't take the commit message personally. I can reword it if you want | 13:06 |
| paulsherwood | 'anyone who advocates ego-less programming hasn't worked with many programmers' :-) | 13:09 |
| jonathanmaw | hmm, this has the browser-poc units installed into /etc/systemd/user | 13:10 |
| ssam2_ | if it helps, i'm pretty sure at least one of the mistakes was introduced by me anway | 13:11 |
| ssam2_ | *anyway | 13:11 |
| jonathanmaw | baserock puts things in /usr/lib/systemd/user, so that'll do for browser-poc. | 13:11 |
| straycat | ssam2_, it's very confusing/ambiguous | 13:12 |
| ssam2_ | i wrote it in about 10 seconds while submitting the patch, as often happens with commit messages | 13:13 |
| * straycat nods | 13:14 | |
| pedroalvarez | edcragg: any news re KVM? | 13:15 |
| richard_maw | jonathanmaw: ah, it's one of those units that should be run under a user session instead of a system session then | 13:17 |
| *** Guest50424 has joined #baserock | 13:18 | |
| ssam2_ | radiofree: have you ever had an issue with a Jetson where the btrfs partition on the MMC becomes read-only, and you can't access it using the 'ums' command any more? | 13:21 |
| ssam2_ | oh, it's worked on remount, I can btrfsck now | 13:21 |
| radiofree | ssam2_: actually yes | 13:24 |
| radiofree | i think using the btrfs resize command buggers it up | 13:24 |
| radiofree | if you use "max" | 13:24 |
| ssam2_ | i think I used 12G rather than max | 13:29 |
| ssam2_ | but maybe that is too much | 13:29 |
| *** wschaller___ has quit IRC | 13:29 | |
| ssam2_ | it's been fine for a while, but died recently | 13:29 |
| radiofree | :\ | 13:29 |
| radiofree | i have a dev board which is totally fine at 10G | 13:30 |
| ssam2_ | funny thing is 'btrfsck' doesn't show any errors, but 'mount' (using ums) hangs forever | 13:30 |
| radiofree | might be better to boot using an sd card and run fsck on the emmc from there? | 13:30 |
| ssam2_ | good idea | 13:31 |
| jjardon | Hi, if you type sys.stdout.write('\033]0;morph:\007') in the python interpreter and exit, the terminal tittle is cleared up but it doesn't happen when you do the same inside morph and exit (https://gerrit.baserock.org/#/c/166/). Any ideas? I tried to catch a KeyboardInterrupt and kill the subprocess in the runcmd command in cliapp but it doesnt seems to fix | 13:44 |
| jjardon | the issue | 13:44 |
| jonathanmaw | ah. It seems installing to /opt will be a problem, since baserock uses that for 'state' | 13:45 |
| pedroalvarez | jonathanmaw: indeed | 13:45 |
| ssam2_ | jjardon: if I type that in a Python interpreter and then exit, the terminal title says as 'morph:' | 13:53 |
| ssam2_ | *stays | 13:53 |
| jjardon | ssam2_: mmm, its cleared up here (gnome-terminal). Maybe depends on the terminal? let me try in xterm | 13:56 |
| jonathanmaw | if /opt's unacceptable, what about /usr/share? | 13:56 |
| richard_maw | jonathanmaw: /usr/lib, since it will have executables | 13:57 |
| richard_maw | /usr/share should theoretically be mountable with noexec | 13:57 |
| SotK | jjardon: its still "morph:" for me (gnome-terminal) | 13:58 |
| richard_maw | but that's because it's supposed to be architecture-independent, hence it's theoretically "shareable" between heterogenous nodes | 13:58 |
| radiofree | jjardon: it stays as "morph" for me | 13:58 |
| ssam2_ | jjardon: I'm using gnome-terminal (3.10.2) | 14:01 |
| radiofree | title stays around in 3.14, and xterm... | 14:02 |
| jjardon | ok, its cleared up in xterm here as well | 14:02 |
| pedroalvarez | "morph:" disappears in gnome-terminal 3.14.1 here | 14:03 |
| pedroalvarez | great! partial builds and morph certify ready to be merged | 14:05 |
| paulsherwood | what is 'morph certify' ? | 14:08 |
| tlsa | a reproducibility certification thing | 14:08 |
| tlsa | that warns for things like ref is branch, ref is not anchored, repo is not on trove-host | 14:09 |
| *** Guest50424 has quit IRC | 14:11 | |
| *** Guest50424 has joined #baserock | 14:24 | |
| bashrc_ | what does it mean for a morph file to be "dirty" ? | 14:28 |
| bwh | jjardon: Are you running the two things on the same system? If not, is your shell prompt configured to set window title in the first? | 14:28 |
| pedroalvarez | bashrc_: changes not commited or pushed to git? | 14:29 |
| bwh | I don't think you *can* save and restore the window title, because that's a security problem (can be used by a remote system to send arbitrary commands into your local shell) | 14:29 |
| * SotK tries it on his laptop rather than his VM | 14:30 | |
| jjardon | bwh: yes, the same. let me check my shell configuration | 14:30 |
| SotK | aha, it reset there | 14:30 |
| jjardon | I have this in my .bashrc: PS1='[\u@\h \W]\$ | 14:31 |
| jjardon | and PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"' in /etc/bash.bashrc | 14:32 |
| ssam2_ | bashrc_: I've never heard anyone refer to a morph file as 'dirty'! | 14:32 |
| ssam2_ | people have called them lots of things, but never that | 14:32 |
| SotK | bashrc_: whats the context of "dirty" morph file? | 14:33 |
| bashrc_ | it looks like in firehose there is a search for "dirty" morphs. morph.dirty looks like its a property | 14:34 |
| richard_maw | that's the in-memory structure | 14:34 |
| richard_maw | it's just to mark that those in-memory structures have changed, so should be written out to disk | 14:35 |
| bashrc_ | ok, that makes sense | 14:35 |
| bwh | jjardon: So the interactive shell will reset the window title. What's happening in the second case - is morph called directly from the interactive shell or to some other program? | 14:35 |
| bwh | s/to/from/ | 14:35 |
| jjardon | bwh: oh, wait a minute, I just realize I was testing morph in a chroot and the commands in my host directly | 14:37 |
| jjardon | ok, seems that the patch is correct and what we have to fix is the shell config :) | 14:38 |
| bashrc_ | I think instead of "dirty" I just would have called the property "changed" or "hasChanged", for readability | 14:38 |
| richard_maw | bashrc_: possibly, but it's analogous to "dirty pages", which is well understood terminology | 14:44 |
| richard_maw | I'm not opposed to a name change if you think it would make it clearer for others who need to look at that code | 14:45 |
| * SotK would find changed clearer than dirty | 14:45 | |
| SotK | changed is obvious at a glance, but dirty requires thought to parse I feel | 14:46 |
| * bashrc_ wasn't familiar with "dirty pages" | 14:49 | |
| * SotK had never heard the term until today either | 14:50 | |
| straycat | Would anyone be against me modifying all devel systems to run the fstab conf ext? | 14:50 |
| straycat | build systems already seem to | 14:50 |
| richard_maw | straycat: +2 | 14:51 |
| straycat | okay, i'll send something through to gerrit | 14:51 |
| jonathanmaw | hrm, system-version-manager seems to have gotten confused. | 14:51 |
| richard_maw | jonathanmaw: it does that when there's subvolumes left behind after a failed deploy | 14:52 |
| jonathanmaw | it seems to think I'm running factory (seems like that to me), but the version I wanted to run is still default. | 14:52 |
| richard_maw | jonathanmaw: does it persist like that after a reboot? | 14:53 |
| jonathanmaw | richard_maw: yes | 14:53 |
| richard_maw | since it gets the current version from /proc/self/mountinfo | 14:53 |
| richard_maw | but the default from the symlink | 14:53 |
| pedroalvarez | IIRC it does't use the symlink to get the default | 14:54 |
| richard_maw | jonathanmaw: that's worrying, since it implies that the bootloader and the kernel see different symlink targets | 14:54 |
| pedroalvarez | I may be wrong | 14:54 |
| richard_maw | pedroalvarez: no, you are correct, it reads the extlinux.conf file for the 'ontimeout' option | 14:54 |
| jonathanmaw | the problem might be that I seem to have a /dev/mmcblk0p1 partition that gets run first, and tells the kernel to use the root in /dev/mmcblk0p2 | 14:54 |
| jonathanmaw | and system-version-manager is reading the extlinux.conf in /dev/mmcblk0p2 instead of the one in /dev/mmcblk0p1 | 14:55 |
| pedroalvarez | ouch | 14:55 |
| pedroalvarez | double ouch | 14:55 |
| richard_maw | jonathanmaw: it shouldn't be, what is BOOT_DEVICE set to in /baserock/deployment.meta | 14:55 |
| jonathanmaw | richard_maw: BOOT_DEVICE isn't set | 14:56 |
| jonathanmaw | though later deployments should have it set, since I altered the cluster morph as per radiofree's instruction | 14:56 |
| jonathanmaw | though I'm not sure how BOOT_DEVICE is used. | 14:56 |
| jonathanmaw | perhaps my morph is too old. | 14:56 |
| richard_maw | system-version-manager uses it, not morph | 14:57 |
| richard_maw | the ssh-rsync deployment calls out to system-version-manager, but otherwise it's not directly related to morph | 14:57 |
| richard_maw | but, if your initial deployment didn't set BOOT_DEVICE, then it may be looking at the wrong place | 14:58 |
| radiofree | jonathanmaw: that sounds like a bug | 14:58 |
| radiofree | the image initially flashed didn't have BOOT_DEVICE set by the sounds of it | 14:58 |
| jonathanmaw | radiofree: ok, so it /baserock/deployment.meta wrong, or the cluster morph? | 15:00 |
| jonathanmaw | s/it/is/ | 15:00 |
| radiofree | /baserock/deployment.meta is wrong in factory | 15:00 |
| radiofree | your cluster should be fine | 15:00 |
| radiofree | maybe you can add BOOT_DEVICE there | 15:01 |
| *** petefoth has quit IRC | 15:02 | |
| ssam2_ | tlsa: with regards to adding the upstream source code to metadata in /baserock, I think that's too hard to do | 15:03 |
| ssam2_ | it would need Morph to tie in with Lorry which would be really awkward | 15:03 |
| ssam2_ | perhaps a better approach is to have a separate tool which can take a manifest that points to repos in the trove, and adds the upstream source URLs at that stage | 15:04 |
| ssam2_ | it would need to read the contents of the $trove/$project/local-config/lorries.git to get this information | 15:04 |
| ssam2_ | e.g. git://git.baserock.org/baserock/local-config/lorries.git for baserock/baserock/definitions | 15:05 |
| * richard_maw yearns to bring the light of context managers to system-version-manager | 15:05 | |
| tlsa | ssam2_: maybe | 15:10 |
| tlsa | ssam2_: is there some defined form for manifests? | 15:11 |
| straycat | sorry | 15:12 |
| straycat | :/ | 15:12 |
| straycat | i just accidentally pushed http://sprunge.us/ZPPZ to master instead of refs/for/master | 15:12 |
| straycat | it should be fine but it wasn't my intention to bypass review | 15:13 |
| radiofree | +1 | 15:13 |
| pedroalvarez | +1 | 15:14 |
| radiofree | although do chroot images really need fstab? | 15:14 |
| radiofree | what exactly does that fstab extension to anyway? | 15:14 |
| pedroalvarez | add entries to /etc/fstab | 15:15 |
| straycat | takes any environment variable that matches FSTAB_ and appends that line to /etc/fstab | 15:15 |
| pedroalvarez | straycat: I'd recommend the use of `git review` to submit patches | 15:15 |
| straycat | okay i'll check that out | 15:16 |
| ssam2_ | tlsa: we have an example to work towards, i'll show you | 15:19 |
| straycat | radiofree, no, but the presence of the conf ext does no harm | 15:19 |
| jjardon | Any idea why morph fail to build when trying to process this: http://paste.baserock.org/eyiqeruyaq ? Error log: http://paste.baserock.org/boyadipoto | 15:37 |
| jonathanmaw | :¬| browser-PoC won't run from a systemd unit because it can't connect to D-Bus. I expect there's no session bus for it. | 15:37 |
| jonathanmaw | and running it straight from command-line fails because it can't find libQt5Widgets.so.5 | 15:38 |
| ssam2_ | jjardon: congratulations!!! | 15:38 |
| ssam2_ | probably a YAML gotcha | 15:38 |
| ssam2_ | maybe you have to escape the backslashes? | 15:38 |
| jjardon | :) | 15:39 |
| jjardon | let me try | 15:39 |
| SotK | jonathanmaw: the first of those issues sounds familiar | 15:39 |
| richard_maw | jjardon: looks like you found a place where a yaml block document isn't like in-lining the text | 15:39 |
| richard_maw | though you also appear to be missing the `cat` which says where to writ ethe contents to | 15:40 |
| jonathanmaw | the second may have something to do with the fact that I can't find qtbase in /baserock | 15:40 |
| jjardon | sorry, the correct morphology is this: http://paste.baserock.org/wikajarera | 15:40 |
| SotK | jonathanmaw: :/ | 15:40 |
| richard_maw | jonathanmaw: presumably you had it as a build-depend, or it wouldn't have built, so you're missing it from your system definition | 15:40 |
| SotK | did you definitely include the qt strata in your system? | 15:41 |
| SotK | snap | 15:41 |
| persia | On "changed" vs. "dirty": I comprehend "changed" as being different than some prior state, and "dirty" being different than the current preserved state. One can have things that are changed, but not dirty. | 15:41 |
| jonathanmaw | somehow the qt5-tools stratum wasn't installed | 15:42 |
| richard_maw | jonathanmaw: if it's not listed in the sytste | 15:42 |
| richard_maw | system morphology, it won't be | 15:42 |
| jonathanmaw | it still said qt5-tools-jetson in the system morphology (though used the morph file for qt5-tools-jetson) | 15:42 |
| jonathanmaw | er, that second qt5-tools-jetson should be qt5-tools | 15:43 |
| jjardon | ssam2_: no luck :( Lets see, maybe I do not need that line in the end | 15:44 |
| richard_maw | jjardon: it's interpreting the \u as the start of a unicode escape | 15:45 |
| richard_maw | jjardon: and then complaining that it doesn't have hex digits | 15:45 |
| jjardon | richard_maw: rigth, is there any other way to introduce verbatim text in a morphology? | 15:46 |
| richard_maw | I'd be very much surprised if you can't just turn it into \\u, but if that isn't working, then there's always !binary | 15:47 |
| richard_maw | though then you need to base64 encode and decode | 15:48 |
| richard_maw | hang on, this is failing in json | 15:49 |
| * richard_maw kicks json.dump | 15:49 | |
| richard_maw | the yaml is leaving it alone, but morph is attempting to "decode" that string because we're doing the wrong thing and put `encoding='unicode-escape'` in write_metadata | 15:50 |
| *** a1exhughe5 has quit IRC | 15:51 | |
| tlsa | gerrit workflow question: https://gerrit.baserock.org/#/c/181/ and https://gerrit.baserock.org/#/c/39/ conflict. 181 adds license to metadata, 39 adds a version guess to metadata. I need to update 39 | 15:52 |
| tlsa | should I continue with the conflict? | 15:52 |
| *** Guest50424 has quit IRC | 15:52 | |
| richard_maw | jjardon: as a work-around, put this in: | 15:53 |
| tlsa | or do one in the same "topic" as the other, as a patch series, loseing review context? | 15:53 |
| richard_maw | base64 -d <<'EOF' >bash.bashrc | 15:53 |
| richard_maw | UFMxPSdbXHVAXGggXFddJCAnCg== | 15:53 |
| richard_maw | EOF | 15:53 |
| SotK | tlsa: can you rebase it so it depends on 181 then update it? | 15:53 |
| tlsa | maybe, not sure | 15:54 |
| paulsherwood | jjardon: Albert tells me that the OSError: [Errno 2] on ccache was fixed - were you using current ydb? | 16:01 |
| jjardon | paulsherwood: what it was in the github repo yesterday | 16:01 |
| jjardon | tlsa: Id say continue, you can rebase locally depending which one is the one that get merged first | 16:02 |
| tlsa | ok | 16:03 |
| persia | As long as you preserve the Change-ID, you can rebase arbitrarily and push as successive revisions, preserving review history. | 16:04 |
| persia | This includes rebases in ways that cause something not to be able to merge until the dependency is merged. | 16:04 |
| jjardon | paulsherwood: seems hardcoded here (and ccache is enabled by default) https://github.com/devcurmudgeon/ybd/blob/master/app.py#L59 | 16:07 |
| Albert | The code change was at https://github.com/devcurmudgeon/ybd/blob/master/app.py#L75 | 16:09 |
| Albert | 'ccache_dir' was not in the list, so I added it | 16:10 |
| jjardon | Albert: paulsherwood I'd change /src/cache/ccache to $XDG_CACHE_HOME/ybd | 16:13 |
| jjardon | http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables | 16:13 |
| jonathanmaw | I'd like to add some lorries. They are GENIVI projects | 16:23 |
| jonathanmaw | looking at git.baserock.org, I don't know where the lorries for delta/genivi/* come from | 16:23 |
| jonathanmaw | since the lorries at ssh://git@git.baserock.org/baserock/local-config/lorries don't include wayland-ivi-extension | 16:24 |
| jjardon | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/tree/open-source-lorries/genivi.lorry and there are some more like http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/tree/open-source-lorries/genivi-wayland-ivi-extension.lorry | 16:25 |
| richard_maw | jonathanmaw: yes they do: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/tree/open-source-lorries/genivi-wayland-ivi-extension.lorry | 16:25 |
| Albert | I can't argue with that jjardon. I added the list element not the literal. What of other literal paths? | 16:26 |
| jonathanmaw | hrm, I had a confused git repo | 16:26 |
| jonathanmaw | it seems I only need one thing lorried. here's the diff http://paste.baserock.org/semorawivo | 16:30 |
| jonathanmaw | is there a preferred way to get this accepted? | 16:30 |
| richard_maw | these days, gerrit.baserock.org | 16:30 |
| jonathanmaw | done on gerrit | 16:42 |
| pedroalvarez | +1ed on gerrit ;) | 16:45 |
| richard_maw | and merged by ssam2_ apparently | 16:47 |
| jonathanmaw | whee! | 16:47 |
| pedroalvarez | this lorry-controller-readconf unit in g.b.o is not behaving pretty well I think | 16:48 |
| *** mdizzle has quit IRC | 16:51 | |
| *** ssam2_ has quit IRC | 16:54 | |
| *** jonathanmaw has quit IRC | 16:59 | |
| *** Albert_ has joined #baserock | 17:01 | |
| *** Albert has quit IRC | 17:01 | |
| *** bashrc_ has quit IRC | 17:02 | |
| jjardon | Albert_: I sent a patch :) | 17:09 |
| jjardon | Is autocompletion working for anyone in a VM? (Its not in my chroot) | 17:10 |
| *** Krin has quit IRC | 17:16 | |
| SotK | jjardon: using the proper pango.modules path worked, thanks! | 17:29 |
| jjardon | SotK: nice! You will probably need to run glib-compile-schemas as well, take a look here: http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-February/011837.html | 17:31 |
| SotK | jjardon: thanks! | 17:36 |
| * SotK reads | 17:36 | |
| *** tiagogomes_ has quit IRC | 17:38 | |
| *** petefoth has joined #baserock | 17:40 | |
| *** franred has quit IRC | 17:42 | |
| SotK | That gives "No schema files found: doing nothing." | 17:46 |
| SotK | I don't know if thats good or bad... | 17:46 |
| pedroalvarez | are these files in /usr/etc? | 17:48 |
| * pedroalvarez didn't like that | 17:48 | |
| SotK | the pango.modules file is | 17:49 |
| straycat | what is usr/etc? | 17:49 |
| straycat | /usr/etc ? | 17:49 |
| straycat | that's not in the fhs? | 17:49 |
| * SotK doesn't know | 17:49 | |
| pedroalvarez | oh, my devel system has that folder | 17:49 |
| pedroalvarez | looks like some chunks are already putting things there | 17:51 |
| * pedroalvarez disappears | 17:51 | |
| straycat | that doesn't seem standard | 17:51 |
| straycat | you're allowed /usr/local/etc | 17:51 |
| straycat | "Note that /usr/etc is still not allowed: programs in /usr should place configuration files in /etc." | 17:53 |
| straycat | http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#THEUSRHIERARCHY | 17:54 |
| straycat | i only skimmed this, so i might be wrong | 17:54 |
| SotK | It does seem weird | 17:55 |
| SotK | Heh, 5.8GB free of 140.7TB... Something not quite right there I think :3 | 17:58 |
| pedroalvarez | Ok, I just merged tlsa patches, that had dependency problems | 18:03 |
| pedroalvarez | This is caused because one of the dependencies is merged, but a new version is sent for the remaining | 18:04 |
| pedroalvarez | so the version of the dependency doesn't match the version of the remaining patches | 18:04 |
| pedroalvarez | but, is possible to rebase the change using gerrit buttons | 18:05 |
| pedroalvarez | I'm not going to do this again with your patches, SotK. I don't want to do this again just in case I'm doing things on the wrong way | 18:06 |
| SotK | sure, its explaining what the conflict is now at least so I can fix it :) | 18:11 |
| jjardon | there are plans to introduce and use /usr/share/etc for "default" configurations: http://0pointer.net/blog/projects/stateless.html | 18:17 |
| *** Albert_ has quit IRC | 18:36 | |
| * SotK wonders if installing VirtualBox guest additions will let him have resolutions above 1024x768 | 18:44 | |
| persia | If you are running under VirtualBox, it should, yes. | 18:48 |
| * jjardon send patches to add bash autocompletion | 18:51 | |
| SotK | persia: yep, that was my understanding of it | 19:16 |
| SotK | now to persuade it to actually build | 19:17 |
| persia | I have a memory of someone trying to do just this thing in Feburary or March. Did the result not make it into a reference system, or did it just bitrot? | 19:17 |
| SotK | it doesn't seem to have made it into master of definitions if they did | 19:18 |
| SotK | the virtualbox-additions-x86_64 stratum is still Kinnison's work from last May | 19:19 |
| SotK | and its rather bitrotted it seems | 19:19 |
| straycat | :( | 19:28 |
| *** HotTopic has joined #baserock | 19:37 | |
| *** HotTopic has left #baserock | 19:38 | |
| *** edcragg has quit IRC | 20:01 | |
| *** gary_perkins has quit IRC | 20:09 | |
| * SotK tries a more recent version | 20:13 | |
| jjardon | Any idea where is possible to change the default shell? (I'd like to use bash instead the one baserock systems use by default) | 20:23 |
| * SotK isn't sure | 20:24 | |
| radiofree | jjardon: /etc/passwd | 20:25 |
| radiofree | ? | 20:25 |
| SotK | jjardon: try `chsh` | 20:26 |
| jjardon | radiofree: yeah!, thanks! | 20:26 |
| SotK | \o/ the most recent VirtualBox tarball builds! | 20:41 |
| pedroalvarez | SotK: maybe you can just change the resolution of the VM? | 20:47 |
| pedroalvarez | SotK: but I understand that integrating guest-additions sounds fun :) | 20:47 |
| SotK | pedroalvarez: the only options appear to be 1024x768, 800x600 or 640x480 | 20:52 |
| SotK | when I've had this problem with non-Baserock VMs on VirtualBox I've just installed the guest-additions to magically enable widescreen resolutions | 20:53 |
| radiofree | SotK: could try adding vga=794 to the kernel args | 20:57 |
| pedroalvarez | radiofree: or that magic value that lets you choose so he test them better | 20:58 |
| pedroalvarez | vga=ask? | 20:58 |
| radiofree | yep | 20:58 |
| * SotK tries | 20:58 | |
| SotK | is there a way to do that without redeploying ooi? | 20:59 |
| bwh | vga= is not a real kernel parameter, it's a boot loader parameter | 20:59 |
| radiofree | SotK: mount /dev/sda /mnt | 20:59 |
| radiofree | then vim /mnt/extlinux.conf | 20:59 |
| SotK | great, thanks | 20:59 |
| radiofree | bwh: according to Documentation/svga.txt it's a real kernel parameter | 21:01 |
| bwh | ...though syslinux is supposed to support it | 21:01 |
| radiofree | yeah, it does | 21:01 |
| bwh | radiofree: It is passed through a structure and not as part of the command line | 21:02 |
| radiofree | ah | 21:02 |
| SotK | that's a little better :) | 21:06 |
| *** rdale has quit IRC | 21:44 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!