IRC logs for #baserock for Wednesday, 2015-04-01

straycatspeaking of kvm... https://gerrit.baserock.org/#/c/151/06:48
*** mike has joined #baserock07:07
*** mike is now known as Guest1027307:07
*** a1exhughe5 has joined #baserock07:14
*** Albert has joined #baserock07:27
paulsherwoodpersia: ybd does sandboxing07:43
paulsherwood(the same sandboxing as morph, iiuc)07:43
paulsherwoodhowever it's still far from 'production quality'07:43
paulsherwoodand morph can do a whole load of things that ybd has no concept of07:45
paulsherwoodjjardon: i may have misunderstood your chroot question. ybd runs its build commands in a chroot, but doesn't itself need to be in a chroot07:48
paulsherwoodjjardon: vs jhbuild i'm not sure. i've never used that07:48
*** mdizzle has joined #baserock07:56
*** gary_perkins has joined #baserock07:56
*** mdunford has joined #baserock07:59
*** bashrc_ has joined #baserock08:02
*** jonathanmaw has joined #baserock08:04
persiapaulsherwood: Ah.  I misunderstood your chroot comment.08:10
paulsherwoodi mis-stated it :)08:11
*** rdale has joined #baserock08:12
straycathrm, 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
paulsherwoodstraycat: there was some discussion about the possibility of standardizing uids on baserock systems (to avoid confusion and possibly security implications)08:33
paulsherwoodrjek and others may know more08:33
paulsherwoodbut i believe some folks are already eastering08:34
jjardonpaulsherwood: oh cool, its better than jhbuild then :)08:34
paulsherwoodwell, 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
jjardonSotK: pango-querymodules > /usr/etc/pango/pango.modules you missed the pango folder08:37
SotKjjardon: oops! I'll try that later, thanks :)08:40
straycat/usr/etc/... ?08:41
*** edcragg has joined #baserock08:52
*** pdar has quit IRC08:58
paulsherwoodAlbert: darnit. i forgot you're called albert09:00
Albertheh09:00
paulsherwoodanyways, your patch doesn't apply cleanly, which suggests you may be working on an old version of ybd09:00
paulsherwoodplease could you check if master already has that issue solved?09:01
AlbertI think you're right. I'll have a mess with with it09:01
*** Krin has joined #baserock09:01
paulsherwoodalso, there are some actual live issues there which you'd be welcome to look at if you're interestedf09:01
AlbertOf course. Lets' just straighten this out. I'll look back through the log.09:06
franrededcragg, whooohooo!!! deploy!! deploy!! :D09:06
*** pdar has joined #baserock09:10
bashrc_is there a callback available for cliapp.runcmd in baserock?09:14
paulsherwoodyou mean in morph, i assume, bashrc_ - baserock is not a single program09:15
*** ssam2 has joined #baserock09:16
*** ChanServ sets mode: +v ssam209:16
*** ChanServ sets mode: +o pedroalvarez09:18
tlsais there any way to prevent morph from using cached artifacts altogether?  (I want to test a change to .meta generation)09:23
ssam2to ignore remote artifacts, you can pass --artifact-cache-server='' (empty string)09:24
ssam2to ignore local artifacts as well, 'mv /src/cache/artifacts /src/cache/artifacts/hidden' is the easiest way09:24
ssam2sorry 'mv /src/cache/artifacts /src/cache/artifacts.hidden'09:25
ssam2or whatever09:25
tlsaok09:25
tlsaalternatively, 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
ssam2perhaps commenting out the code that actually runs the configure, build and install commands would be the best way09:29
ssam2so you get a bunch of empty artifacts with .meta files09:29
tlsaok, sounds like a good idea09:31
*** wschaller has joined #baserock09: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.py09:49
straycatyeah we kinda forked cliapp a bit09:50
richard_mawand we haven't rebased on top of upstream in a while09:50
bashrc_so it doesn't support callbacks09:50
straycatwhich we should do given we fixed a bug in rncmd09:50
straycat*runcmd09:51
straycatbashrc_, no callbacks got added later09:51
bashrc_this may make it difficult to trap errors09:51
straycatwe could rework some of the distbuild logging stuff to use callbacks too, iirc09:52
straycatat the moment we end up using tee somewhere :p09:52
*** Guest10273 has quit IRC09:54
*** Guest10273 has joined #baserock10:08
*** mike has joined #baserock10:11
*** mike is now known as Guest5042410:11
*** Guest10273 has quit IRC10:14
*** ssam2 has quit IRC10:18
*** Krin has quit IRC10:24
*** ssam2 has joined #baserock10:31
*** ChanServ sets mode: +v ssam210:31
* SotK wishes Gerrit would give more information than "Merge Conflict"10:31
persiaFetch both trees (second should be fast because you already have most objects), and try a rebase locally.10:36
tlsaSotK, at the top right, of the patch page, go to the "Conflicts with" tab10:37
tlsaSotK: e.g. on this: https://gerrit.baserock.org/#/c/42/610:37
SotKthere isn't one on the change with Merge Conflict10:39
SotKpersia: "Successfully rebased and updated refs/heads/distbuild"10:39
persiaOdd.  I've never heard of that before.10:40
pedroalvarezSotK: rebased on top of g.b.o/master or gerrit/master10:40
* pedroalvarez hopes this is not the problem10:41
SotKhm, g.b.o master10:41
* SotK tries with gerrit master10:41
SotKthat rebase worked fine too, I'll try pushing the changes again and see if it goes away10:42
SotKor not, it failed because there were no new changes10:43
pedroalvarez:(10:43
* pedroalvarez notes that the "Conflicts with" list is for patches that havent been merged yet.10:44
*** ssam2 has quit IRC10:46
*** ssam2_ has joined #baserock10:46
straycatheh what i didn't realise i can give my own patches a score10:47
* straycat proceeds to +2 everything he's submitted10:47
straycatokay i've merged everything and branched morph10:50
straycatunversioned definitions are now invalid10:50
rdalehow does morph know how to turn 'upstream:foobar' into git://git.baserock.org/delta/foobar ?10:50
Albertpaulsherwood, 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
paulsherwoodAlbert: github10:51
AlbertOK10:51
pedroalvarezrdale: morphlib/util.py:17310:52
straycatrdale, there's a set of repo aliases that get combined with your trove-host10:52
straycatyou can define your own repo aliases too if you want10:53
*** ssam2_ has quit IRC10:55
rdaleah, trove-host defines what upstream: means, and so if i had a different trove host to baserock, i would pick up repos from that10:58
straycatyes11:02
straycatsame thing goes for baserock:11:02
straycat"Hello Adam Coldrick, Richard Ipsum, Richard Ipsum,"11:03
straycathehehehe11:03
*** ssam2_ has joined #baserock11:07
bjdooks311:17
pedroalvarezstraycat: I think is possible to merge users, do you want me to?11:18
pedroalvarezdoesn't look easy, forget it :)11:20
straycatno because gerrit enforces that the committer's email must match the email of the openid that's been authenticated to do the push11:20
pedroalvarezstraycat: 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 use11:22
straycatratmice__, indeed :)11:22
straycattbf, this is nothing new, nothing technically stopped anyone with push access to gbo from merging their own patches, they're just trusted not to11:24
*** Krin has joined #baserock11:25
ssam2_indeed, and I hope we can continue to trust people in the Mergers group to be sensible11:29
ssam2_gerrit ACLs are pretty flexible but I don't want to have them getting in the way11:29
ssam2_the thing about enforcing the commiters email can be fixed, in fact11: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 checking11:30
jjardonssam2_: Is it possible to configure gerrit to automatically push when a patch have a +2 (so no need to click "submit")?11:33
richard_mawjjardon: I don't think so, which is why we were looking at zuul11:33
ssam2_jjardon: it might be possible, actually11:34
ssam2_I'm not sure it's what we want though11:34
petefoth jjardon there was some discussion about that a few weeks back, but I don't recall the outcome11:35
* jjardon search for zuul and an image of a ghostbusters' monster appear :)11:35
radiofreecould someone else review https://gerrit.baserock.org/#/c/152/ please11:36
ssam2_merged11:37
radiofreeit's pointing at a sha1 in the 5.4 branch of qtwebkit11:40
jonathanmawhrm, 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/avikocejur11:40
radiofreei asked in #qt about whether or not those branches are ever rebased (it's not a release...)11:40
radiofreeapparently they aren't11:40
radiofreebut say the 5.4 branch *was* rebased, what would trove do?11:40
radiofreewould trove just mirror it completely?11:41
radiofreeor do nothing?11:41
richard_mawjonathanmaw: well, is there enough space on your / device?11:42
radiofreejonathanmaw: are you deploying to that jetson?11:43
jonathanmawradiofree: I think so, the cluster morphology goes to root@127.0.0.111:43
richard_mawjonathanmaw: you should be able to clean it up yourself with a `btrfs filesystem delete /tmp/tmp.lOOJoS/systems/demo-test/orig/tmp`11:43
radiofreeROOT_DEVICE: "/dev/mmcblk0p2"11:44
radiofreeBOOT_DEVICE: "/dev/mmcblk0p1"11:44
radiofreejonathanmaw: ^11:44
radiofreeoh wait rsync: write failed on "/tmp/tmp.lOOJoS/systems/demo-test/orig/tmp/AudioManagerTest/AmTelnetServerTest": No space left on device (28)11:45
pedroalvarezproblem is not when cleaning up (I believe). It cleans up because it failed, and then drop the error11:45
jonathanmawrichard_maw: it  seems /tmp is missing those directories,11:45
richard_mawthen there will have been some partial cleanup working then, mount your root device manually11:45
*** wschaller has quit IRC11:46
*** Guest50424 has quit IRC11:49
ssam2_radiofree: it depends on what the .lorry file for that repo says to do11: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 it11:49
radiofreei see, what's the default behaviour?11:50
radiofreejonathanmaw: run the btrfs resize command on the board as well11:50
radiofree10G11:50
ssam2_radiofree: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/lorry.git/tree/lorry#n50711:51
ssam2_so the default is: don't force-push anything11:51
jjardonsorry 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 trove11:56
*** Guest50424 has joined #baserock11:56
paulsherwoodjjardon: actually, that's a good point, provided you administer the trove for reproducibility11:57
richard_mawjjardon: you'd have to make your own tags though, as upstream could move theirs12:02
richard_mawyou need to administer your own trove for both approaches12:03
richard_mawbut 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 tag12:03
jjardonrichard_maw: You will have the tag that you had in your trove, the one that you trusted12:05
*** wschaller has joined #baserock12:06
jjardonrichard_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 use12:06
richard_mawjjardon: 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 around12:06
richard_mawhowever, 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 ever12:07
richard_mawnot replacing their tags12:07
richard_mawI'm not sure what you mean by manually fixing your trove here12:08
richard_mawoh, you mean fixups as part of the restore12:12
jjardonrichard_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 new12:12
jjardon<upstream>-trove tag / keep using upstream tag12:12
richard_mawok, 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 used12:16
richard_mawand 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 different12:18
* richard_maw recalls having this discussion before12:19
richard_mawso you have to either keep the sha1 of the commit in the definition, or create new tags instead of using upstream's12:20
richard_mawand 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 weeks12: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 args12:25
jjardonthanks richard_maw , I understand the problem better now12:32
richard_mawjjardon: 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 anyway12:39
*** wschaller_ has joined #baserock12:48
*** wschaller___ has joined #baserock12:50
jonathanmawhrm, it seems the genivi-demo-platform's browser-poc doesn't include instructions for how to install it12:52
*** wschaller has quit IRC12:52
jonathanmawmeta-genivi-demo suggests I install the browser, demo UI and test app to /opt12:52
jonathanmaware there any better suggestions?12:53
straycat"It doesn't seem like cancelling builds ever actually worked right --"12:54
straycatssam2_, ?12:54
*** wschaller_ has quit IRC12:54
jonathanmawit also has systemd units. What's the recommended way of adding systemd units to baserock now?12:55
richard_mawjonathanmaw: 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 later12:58
richard_mawI 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 elsewhere12:59
jonathanmawrichard_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 year13:00
richard_mawI'd avoid checking them into the chunk's source repo13:00
richard_mawthough I prefer putting the units in at build time over install time, so add post-install-commands to the chunk definition13:01
richard_mawand install it with a here-document13:01
richard_mawi.e. embed the systemd unit in the chunk definition file13:01
SotKI think there was something daft like "it only worked if run inside its source directory" when I was looking at it which complicated matters13:01
richard_maw:¬(13:02
*** Guest50424 has quit IRC13:04
ssam2_straycat: please don't take the commit message personally. I can reword it if you want13:06
paulsherwood'anyone who advocates ego-less programming hasn't worked with many programmers' :-)13:09
jonathanmawhmm, this has the browser-poc units installed into /etc/systemd/user13:10
ssam2_if it helps, i'm pretty sure at least one of the mistakes was introduced by me anway13:11
ssam2_*anyway13:11
jonathanmawbaserock puts things in /usr/lib/systemd/user, so that'll do for browser-poc.13:11
straycatssam2_, it's very confusing/ambiguous13:12
ssam2_i wrote it in about 10 seconds while submitting the patch, as often happens with commit messages13:13
* straycat nods13:14
pedroalvarezedcragg: any news re KVM?13:15
richard_mawjonathanmaw: ah, it's one of those units that should be run under a user session instead of a system session then13:17
*** Guest50424 has joined #baserock13: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 now13:21
radiofreessam2_: actually yes13:24
radiofreei think using the btrfs resize command buggers it up13:24
radiofreeif you use "max"13:24
ssam2_i think I used 12G rather than max13:29
ssam2_but maybe that is too much13:29
*** wschaller___ has quit IRC13:29
ssam2_it's been fine for a while, but died recently13:29
radiofree:\13:29
radiofreei have a dev board which is totally fine at 10G13:30
ssam2_funny thing is 'btrfsck' doesn't show any errors, but 'mount' (using ums) hangs forever13:30
radiofreemight be better to boot using an sd card and run fsck on the emmc from there?13:30
ssam2_good idea13:31
jjardonHi, 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 fix13:44
jjardonthe issue13:44
jonathanmawah. It seems installing to /opt will be a problem, since baserock uses that for 'state'13:45
pedroalvarezjonathanmaw: indeed13:45
ssam2_jjardon: if I type that in a Python interpreter and then exit, the terminal title says as 'morph:'13:53
ssam2_*stays13:53
jjardonssam2_: mmm, its cleared up here (gnome-terminal). Maybe depends on the terminal? let me try in xterm13:56
jonathanmawif /opt's unacceptable, what about /usr/share?13:56
richard_mawjonathanmaw: /usr/lib, since it will have executables13:57
richard_maw/usr/share should theoretically be mountable with noexec13:57
SotKjjardon: its still "morph:" for me (gnome-terminal)13:58
richard_mawbut that's because it's supposed to be architecture-independent, hence it's theoretically "shareable" between heterogenous nodes13:58
radiofreejjardon: it stays as "morph" for me13:58
ssam2_jjardon: I'm using gnome-terminal (3.10.2)14:01
radiofreetitle stays around in 3.14, and xterm...14:02
jjardonok, its cleared up in xterm here as well14:02
pedroalvarez"morph:" disappears in gnome-terminal 3.14.1 here14:03
pedroalvarezgreat! partial builds  and morph certify ready to be merged14:05
paulsherwoodwhat is 'morph certify' ?14:08
tlsaa reproducibility certification thing14:08
tlsathat warns for things like ref is branch, ref is not anchored, repo is not on trove-host14:09
*** Guest50424 has quit IRC14:11
*** Guest50424 has joined #baserock14:24
bashrc_what does it mean for a morph file to be "dirty" ?14:28
bwhjjardon: 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
pedroalvarezbashrc_: changes not commited or pushed to git?14:29
bwhI 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 VM14:30
jjardonbwh: yes, the same. let me check my shell configuration14:30
SotKaha, it reset there14:30
jjardonI have this in my .bashrc: PS1='[\u@\h \W]\$14:31
jjardonand PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"' in /etc/bash.bashrc14: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 that14:32
SotKbashrc_: 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 property14:34
richard_mawthat's the in-memory structure14:34
richard_mawit's just to mark that those in-memory structures have changed, so should be written out to disk14:35
bashrc_ok, that makes sense14:35
bwhjjardon: 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
bwhs/to/from/14:35
jjardonbwh: oh, wait a minute, I just realize I was testing morph in a chroot and the commands in my host directly14:37
jjardonok, 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 readability14:38
richard_mawbashrc_: possibly, but it's analogous to "dirty pages", which is well understood terminology14:44
richard_mawI'm not opposed to a name change if you think it would make it clearer for others who need to look at that code14:45
* SotK would find changed clearer than dirty14:45
SotKchanged is obvious at a glance, but dirty requires thought to parse I feel14:46
* bashrc_ wasn't familiar with "dirty pages"14:49
* SotK had never heard the term until today either14:50
straycatWould anyone be against me modifying all devel systems to run the fstab conf ext?14:50
straycatbuild systems already seem to14:50
richard_mawstraycat: +214:51
straycatokay, i'll send something through to gerrit14:51
jonathanmawhrm, system-version-manager seems to have gotten confused.14:51
richard_mawjonathanmaw: it does that when there's subvolumes left behind after a failed deploy14:52
jonathanmawit 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_mawjonathanmaw: does it persist like that after a reboot?14:53
jonathanmawrichard_maw: yes14:53
richard_mawsince it gets the current version from /proc/self/mountinfo14:53
richard_mawbut the default from the symlink14:53
pedroalvarezIIRC it does't use the symlink to get the default14:54
richard_mawjonathanmaw: that's worrying, since it implies that the bootloader and the kernel see different symlink targets14:54
pedroalvarezI may be wrong14:54
richard_mawpedroalvarez: no, you are correct, it reads the extlinux.conf file for the 'ontimeout' option14:54
jonathanmawthe 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/mmcblk0p214:54
jonathanmawand system-version-manager is reading the extlinux.conf in /dev/mmcblk0p2 instead of the one in /dev/mmcblk0p114:55
pedroalvarezouch14:55
pedroalvarezdouble ouch14:55
richard_mawjonathanmaw: it shouldn't be, what is BOOT_DEVICE set to in /baserock/deployment.meta14:55
jonathanmawrichard_maw: BOOT_DEVICE isn't set14:56
jonathanmawthough later deployments should have it set, since I altered the cluster morph as per radiofree's instruction14:56
jonathanmawthough I'm not sure how BOOT_DEVICE is used.14:56
jonathanmawperhaps my morph is too old.14:56
richard_mawsystem-version-manager uses it, not morph14:57
richard_mawthe ssh-rsync deployment calls out to system-version-manager, but otherwise it's not directly related to morph14:57
richard_mawbut, if your initial deployment didn't set BOOT_DEVICE, then it may be looking at the wrong place14:58
radiofreejonathanmaw: that sounds like a bug14:58
radiofreethe image initially flashed didn't have BOOT_DEVICE set by the sounds of it14:58
jonathanmawradiofree: ok, so it /baserock/deployment.meta wrong, or the cluster morph?15:00
jonathanmaws/it/is/15:00
radiofree/baserock/deployment.meta is wrong in factory15:00
radiofreeyour cluster should be fine15:00
radiofreemaybe you can add BOOT_DEVICE there15:01
*** petefoth has quit IRC15:02
ssam2_tlsa: with regards to adding the upstream source code to metadata in /baserock, I think that's too hard to do15:03
ssam2_it would need Morph to tie in with Lorry which would be really awkward15: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 stage15:04
ssam2_it would need to read the contents of the $trove/$project/local-config/lorries.git to get this information15:04
ssam2_e.g. git://git.baserock.org/baserock/local-config/lorries.git for baserock/baserock/definitions15:05
* richard_maw yearns to bring the light of context managers to system-version-manager15:05
tlsassam2_: maybe15:10
tlsassam2_: is there some defined form for manifests?15:11
straycatsorry15:12
straycat:/15:12
straycati just accidentally pushed http://sprunge.us/ZPPZ to master instead of refs/for/master15:12
straycatit should be fine but it wasn't my intention to bypass review15:13
radiofree+115:13
pedroalvarez+115:14
radiofreealthough do chroot images really need fstab?15:14
radiofreewhat exactly does that fstab extension to anyway?15:14
pedroalvarezadd entries to /etc/fstab15:15
straycattakes any environment variable that matches FSTAB_ and appends that line to /etc/fstab15:15
pedroalvarezstraycat: I'd recommend the use of `git review` to submit patches15:15
straycatokay i'll check that out15:16
ssam2_tlsa: we have an example to work towards, i'll show you15:19
straycatradiofree, no, but the presence of the conf ext does no harm15:19
jjardonAny idea why morph fail to build when trying to process this: http://paste.baserock.org/eyiqeruyaq ? Error log: http://paste.baserock.org/boyadipoto15: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
jonathanmawand running it straight from command-line fails because it can't find libQt5Widgets.so.515:38
ssam2_jjardon: congratulations!!!15:38
ssam2_probably a YAML gotcha15:38
ssam2_maybe you have to escape the backslashes?15:38
jjardon:)15:39
jjardonlet me try15:39
SotKjonathanmaw: the first of those issues sounds familiar15:39
richard_mawjjardon: looks like you found a place where a yaml block document isn't like in-lining the text15:39
richard_mawthough you also appear to be missing the `cat` which says where to writ ethe contents to15:40
jonathanmawthe second may have something to do with the fact that I can't find qtbase in /baserock15:40
jjardonsorry, the correct morphology is this: http://paste.baserock.org/wikajarera15:40
SotKjonathanmaw: :/15:40
richard_mawjonathanmaw: presumably you had it as a build-depend, or it wouldn't have built, so you're missing it from your system definition15:40
SotKdid you definitely include the qt strata in your system?15:41
SotKsnap15:41
persiaOn "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
jonathanmawsomehow the qt5-tools stratum wasn't installed15:42
richard_mawjonathanmaw: if it's not listed in the sytste15:42
richard_mawsystem morphology, it won't be15:42
jonathanmawit still said qt5-tools-jetson in the system morphology (though used the morph file for qt5-tools-jetson)15:42
jonathanmawer, that second qt5-tools-jetson should be qt5-tools15:43
jjardonssam2_: no luck :( Lets see, maybe I do not need that line in the end15:44
richard_mawjjardon: it's interpreting the \u as the start of a unicode escape15:45
richard_mawjjardon: and then complaining that it doesn't have hex digits15:45
jjardonrichard_maw: rigth, is there any other way to introduce verbatim text in a morphology?15:46
richard_mawI'd be very much surprised if you can't just turn it into \\u, but if that isn't working, then there's always !binary15:47
richard_mawthough then you need to base64 encode and decode15:48
richard_mawhang on, this is failing in json15:49
* richard_maw kicks json.dump15:49
richard_mawthe 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_metadata15:50
*** a1exhughe5 has quit IRC15:51
tlsagerrit 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 3915:52
tlsashould I continue with the conflict?15:52
*** Guest50424 has quit IRC15:52
richard_mawjjardon: as a work-around, put this in:15:53
tlsaor do one in the same "topic" as the other, as a patch series, loseing review context?15:53
richard_mawbase64 -d <<'EOF' >bash.bashrc15:53
richard_mawUFMxPSdbXHVAXGggXFddJCAnCg==15:53
richard_mawEOF15:53
SotKtlsa: can you rebase it so it depends on 181 then update it?15:53
tlsamaybe, not sure15:54
paulsherwoodjjardon: Albert tells me that the OSError: [Errno 2] on ccache was fixed - were you using current ydb?16:01
jjardonpaulsherwood: what it was in the github repo yesterday16:01
jjardontlsa: Id say continue, you can rebase locally depending which one is the one that get merged first16:02
tlsaok16:03
persiaAs long as you preserve the Change-ID, you can rebase arbitrarily and push as successive revisions, preserving review history.16:04
persiaThis includes rebases in ways that cause something not to be able to merge until the dependency is merged.16:04
jjardonpaulsherwood: seems hardcoded here (and ccache is enabled by default) https://github.com/devcurmudgeon/ybd/blob/master/app.py#L5916:07
AlbertThe code change was at https://github.com/devcurmudgeon/ybd/blob/master/app.py#L7516:09
Albert'ccache_dir' was not in the list, so I added it16:10
jjardonAlbert: paulsherwood I'd change /src/cache/ccache to $XDG_CACHE_HOME/ybd16:13
jjardonhttp://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables16:13
jonathanmawI'd like to add some lorries. They are GENIVI projects16:23
jonathanmawlooking at git.baserock.org, I don't know where the lorries for delta/genivi/* come from16:23
jonathanmawsince the lorries at ssh://git@git.baserock.org/baserock/local-config/lorries don't include wayland-ivi-extension16:24
jjardonhttp://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.lorry16:25
richard_mawjonathanmaw: yes they do: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/tree/open-source-lorries/genivi-wayland-ivi-extension.lorry16:25
AlbertI can't argue with that jjardon. I added the list element not the literal. What of other literal paths?16:26
jonathanmawhrm, I had a confused git repo16:26
jonathanmawit seems I only need one thing lorried. here's the diff http://paste.baserock.org/semorawivo16:30
jonathanmawis there a preferred way to get this accepted?16:30
richard_mawthese days, gerrit.baserock.org16:30
jonathanmawdone on gerrit16:42
pedroalvarez+1ed on gerrit ;)16:45
richard_mawand merged by ssam2_ apparently16:47
jonathanmawwhee!16:47
pedroalvarezthis lorry-controller-readconf unit in g.b.o is not behaving pretty well I think16:48
*** mdizzle has quit IRC16:51
*** ssam2_ has quit IRC16:54
*** jonathanmaw has quit IRC16:59
*** Albert_ has joined #baserock17:01
*** Albert has quit IRC17:01
*** bashrc_ has quit IRC17:02
jjardonAlbert_: I sent a patch :)17:09
jjardonIs autocompletion working for anyone in a VM? (Its not in my chroot)17:10
*** Krin has quit IRC17:16
SotKjjardon: using the proper pango.modules path worked, thanks!17:29
jjardonSotK: 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.html17:31
SotKjjardon: thanks!17:36
* SotK reads17:36
*** tiagogomes_ has quit IRC17:38
*** petefoth has joined #baserock17:40
*** franred has quit IRC17:42
SotKThat gives "No schema files found: doing nothing."17:46
SotKI don't know if thats good or bad...17:46
pedroalvarezare these files in /usr/etc?17:48
* pedroalvarez didn't like that17:48
SotKthe pango.modules file is17:49
straycatwhat is usr/etc?17:49
straycat/usr/etc ?17:49
straycatthat's not in the fhs?17:49
* SotK doesn't know17:49
pedroalvarezoh, my devel system has that folder17:49
pedroalvarezlooks like some chunks are already putting things there17:51
* pedroalvarez disappears17:51
straycatthat doesn't seem standard17:51
straycatyou're allowed /usr/local/etc17:51
straycat"Note that /usr/etc is still not allowed: programs in /usr should place configuration files in /etc."17:53
straycathttp://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#THEUSRHIERARCHY17:54
straycati only skimmed this, so i might be wrong17:54
SotKIt does seem weird17:55
SotKHeh, 5.8GB free of 140.7TB... Something not quite right there I think :317:58
pedroalvarezOk, I just merged tlsa patches, that had dependency problems18:03
pedroalvarezThis is caused because one of the dependencies is merged, but a new version is sent for the remaining18:04
pedroalvarezso the version of the dependency doesn't match the version of the remaining patches18:04
pedroalvarezbut, is possible to rebase the change using gerrit buttons18:05
pedroalvarezI'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 way18:06
SotKsure, its explaining what the conflict is now at least so I can fix it :)18:11
jjardonthere are plans to introduce and use /usr/share/etc for "default" configurations: http://0pointer.net/blog/projects/stateless.html18:17
*** Albert_ has quit IRC18:36
* SotK wonders if installing VirtualBox guest additions will let him have resolutions above 1024x76818:44
persiaIf you are running under VirtualBox, it should, yes.18:48
* jjardon send patches to add bash autocompletion18:51
SotKpersia: yep, that was my understanding of it19:16
SotKnow to persuade it to actually build19:17
persiaI 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
SotKit doesn't seem to have made it into master of definitions if they did19:18
SotKthe virtualbox-additions-x86_64 stratum is still Kinnison's work from last May19:19
SotKand its rather bitrotted it seems19:19
straycat:(19:28
*** HotTopic has joined #baserock19:37
*** HotTopic has left #baserock19:38
*** edcragg has quit IRC20:01
*** gary_perkins has quit IRC20:09
* SotK tries a more recent version20:13
jjardonAny 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 sure20:24
radiofreejjardon: /etc/passwd20:25
radiofree?20:25
SotKjjardon: try `chsh`20:26
jjardonradiofree: yeah!, thanks!20:26
SotK\o/ the most recent VirtualBox tarball builds!20:41
pedroalvarezSotK: maybe you  can just change the resolution of the VM?20:47
pedroalvarezSotK: but I understand that integrating guest-additions sounds fun :)20:47
SotKpedroalvarez: the only options appear to be 1024x768, 800x600 or 640x48020:52
SotKwhen I've had this problem with non-Baserock VMs on VirtualBox I've just installed the guest-additions to magically enable widescreen resolutions20:53
radiofreeSotK: could try adding vga=794 to the kernel args20:57
pedroalvarezradiofree: or that magic value that lets you choose so he test them better20:58
pedroalvarezvga=ask?20:58
radiofreeyep20:58
* SotK tries20:58
SotKis there a way to do that without redeploying ooi?20:59
bwhvga= is not a real kernel parameter, it's a boot loader parameter20:59
radiofreeSotK: mount /dev/sda /mnt20:59
radiofreethen vim /mnt/extlinux.conf20:59
SotKgreat, thanks20:59
radiofreebwh: according to Documentation/svga.txt it's a real kernel parameter21:01
bwh...though syslinux is supposed to support it21:01
radiofreeyeah, it does21:01
bwhradiofree: It is passed through a structure and not as part of the command line21:02
radiofreeah21:02
SotKthat's a little better :)21:06
*** rdale has quit IRC21:44

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