IRC logs for #baserock for Friday, 2014-12-12

jjardonmmm, looking at and, how is possible that the last commit takes ~3 hours in x86 and a little more than 2 hours in arm?00:40
radiofreejjardon: it monitors g.b.o for changes01:03
radiofreethe arm mason uses a separate trove however, since it's also used as a distbuild network, so those changes can take ~2 hours to propagate to the trove it's using01:04
radiofree(separate trove needed for distbuild networks because of the need to push temporary branches)01:05
radiofreei think that's the reason anyway01:05
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer]01:21
*** persia_ [quassel@ubuntu/member/persia] has quit [Ping timeout: 244 seconds]04:34
*** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has joined #baserock04:34
*** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has quit [Changing host]04:34
*** persia_ [quassel@ubuntu/member/persia] has joined #baserock04:34
*** ratmice_________ [] has quit [Ping timeout: 250 seconds]06:01
*** paulsherwood [] has joined #baserock07:15
*** petefotheringham [] has joined #baserock07:28
*** petefotheringham [] has quit [Client Quit]07:29
*** petefotheringham [] has joined #baserock07:29
petefotheringham is now known as petefoth107:38
*** wdutch [] has joined #baserock08:15
*** perryl [] has joined #baserock08:20
*** perryl [] has quit [Quit: leaving]08:25
*** perryl [] has joined #baserock08:27
petefothA comment at LWN on the UbuntuCore announcement includes '...The right way(tm) would in my opinion indeed be a rolling distribution with everything always updated and refreshed and build against the latest everything else. ...' :)08:39
jjardonSooo, archlinux? ;)08:41
*** bashrc [] has joined #baserock09:05
*** SotK [] has joined #baserock09:10
*** franred [] has quit [Quit: Leaving]09:11
rjekDebian Testing? ;-)09:11
rjek(Actually, no.  Debian Testing has had some testing done on it.  Debian Unstable.)09:11
KinnisonUnstable is also fairly carefully curated09:13
*** petefoth [] has quit []09:13
*** petefoth [] has joined #baserock09:13
*** franred [] has joined #baserock09:24
*** SotK [] has quit [Quit: leaving]09:28
*** SotK [] has joined #baserock09:28
*** tiagogomes [] has joined #baserock09:29
*** ssam2 [] has joined #baserock09:49
Mode #baserock +v ssam2 by ChanServ09:49
petefothUpdated help text for the generic write extension parameters
ssam2petefoth: I think the KERNEL_ARGS goes into too much detail -- maybe remove the comments and just show the defualt commandline09:59
ssam2where is this documentation going? I ask because we'll need to be sure it's updated whenever the defaults themselves change09:59
*** rjek [~rjek@gateway/shell/pepperfish/x-yipgojttzsfgxzpj] has quit [Remote host closed the connection]10:00
*** Kinnison [~dsilvers@gateway/shell/pepperfish/x-ipohiqaowqtrqqyr] has quit [Remote host closed the connection]10:00
ssam2so the code its documenting should also get a comment with a note saying 'Please also update the documentation in file xxx if you change this'10:00
petefothSo default command line is 10:01
petefoth'rw init=/sbin/init rootfstype=btrfs rootflags=subvol=systems/default/run ' 'root=[name or UUID of root filesystem]'10:01
petefothsadly it will be in 'files xxx, yyy,..." as this text will be in the .help files for all the wrtie extensions which take KERNEL_ARGS10:02
*** Kinnison [~dsilvers@gateway/shell/pepperfish/x-iumivulvebvqfovj] has joined #baserock10:03
ssam2petefoth: OK. As long that's noted in the code where we define the default KERNEL_ARGS (which I imagine is morphlib/
ssam2nothing worse than documentation that actively lies!10:04
petefothssam2: it will be10:06
petefothSo, I am making doc changes for morph in a feature branch pf-doc-change1. I push that branch to github, and use git 'send-email ... master' to send them for review. If I wanted to submit them to the test Gerrit, can I push to gerrti /refs/for/master, or does it have to be /refs/for/ pf-doc-change1 ?10:11
*** pdar [] has joined #baserock10:12
*** jmacs [] has joined #baserock10:13
persiapetefoth: I believe you'd push to HEAD:refs/for/master10:14
persiaUnless you wanted a long-lived feature branch for some reason10:14
perryloh! i wonder if that was where i was going wrong...10:15
petefothpersia: thanks - I'll try that when the changes are done10:15
persiaNote that I'm not 100% sure.  I always used git-review with gerrit.10:15
pedroalvarezwhich makes it simpler10:16
petefothI plan to install git-review on this 'ere (OS X) MacBook but I will wait until I know I'm doing the right thing for Gerrit using git push10:17
*** mauricemoss_ [] has quit [Ping timeout: 250 seconds]10:18
franredpetefoth, have you clone the repo with the gerrit hook?10:19
*** kejiahu [] has joined #baserock10:24
petefothI beklieve so (though I used git remote add rather than 'git clone'10:24
petefothfranred: ^^10:24
*** flatmush [] has quit [Remote host closed the connection]10:28
*** flatmush [] has joined #baserock10:30
franredpetefoth, not sure then10:30
ssam2seems lorry on the testgerrit has got stuck in a 'git pack-objects' call10:32
*** mauricemoss_ [] has joined #baserock10:32
KinnisonIt'll finish eventually, but it can be high RAM usage10:34
*** petefoth [] has quit [Quit: petefoth]10:34
ssam2Started: 2014-12-11 12:17:28 UTC10:36
Kinnisonpacking objects is a high-ram-usage event sadly10:36
Kinnisonif the system is low on RAMs then it'll be hitting swap a lot10:37
Kinnisonwhich will slow it down dramatically10:37
ssam2it has no swap. but it is competing with Java!10:37
ssam2the default ghost-timeout in the lorry-controller webapp is 600 units10:37
ssam2(I guess seconds?)10:37
*** petefoth [] has joined #baserock10:37
ssam2oh, but there's probably a separate systemd unit that kills ghost jobs, which I haven't turned into a cron job on this machine10:38
*** zarazaimeche [] has joined #baserock10:38
ssam2so that's why this process hasn't been killed10:38
KinnisonHow's the output packs looking in thr repo?10:38
zarazaimeche is now known as Zara10:39
ssam2107MB .idx file and 821MB .pack file10:40
ssam2so, nearly there in fact10:40
ssam2by comparison with the equivalent10:40
perrylattempting to run the firehose command on a test config, have received the following error:
perrylthe fact that the action was prohibited is promising, it means it's doing something right (even if it's not being allowed)10:42
SotKis the firehose user in one of the access control groups who are allowed to push to that repo?10:43
ssam2probably not, we didn't set that up yet10:43
perrylthat would be the reason it was prohibited!10:44
perryls/would be/is probably10:44
ssam2perryl: there's now a Firehose group which has the right to push to refs/for/refs/*10:47
ssam2I think it doesn't have any other rights, we might need to tweak its permissions further10:48
perrylssam2: cool, i'll try the command again and see what happens10:48
petefothfranred: git remote -v gives ssh://, so I guess I do have the gerrit hook10:49
perrylssam2: actually, is there anything i need to do manually before pushing?10:50
ssam2shouldn't be10:50
petefothOk So I dont' have the commit hook :)10:56
SotKpetefoth: put that in .git/hooks/commit-msg10:58
petefothSotK: thanks10:58
SotKyou may have to cause the commits to be recreated somehow to make it add a Change-Id to existing commits10:58
SotK`git commit --amend` for example10:59
petefothSotK: I haven't actually made the changes yet so that won't be a problem : 10:59
jmacsTrying to build stage1-gcc in a baserock chroot, and it fails saying "ERROR: /dev/shm: File exists". Is it really trying to create /dev/shm, or is it missing a path?10:59
ssam2that's a new one.11:00
petefothSotK: do I need an instance of tha file in each repo that I want to work with Gerrit?11:00
ssam2jmacs: stage1 builds run in 'bootstrap' mode, where there's no staging chroot11:00
SotKpetefoth: yes11:00
SotKhowever, if you clone the repo directly from Gerrit rather than elsewhere there is an option on the web UI to show a clone URL which also adds the commit-msg hook11:01
richard_mawssam2, jmacs: it could be that morphlib.stagingarea.StagingArea.runcmd should be sorting out to_mount to make it use the path to the staging area11:03
*** petefoth [] has quit [Ping timeout: 244 seconds]11:04
*** petefoth [] has joined #baserock11:04
richard_mawyeah, that looks like the problem, morph used to join the staging area's dirname and the mount target, but that got lost when we unified the container logic11:05
richard_mawI'm rather surprised that it's failing to make that file, since it checks if it exists before trying to make it.11:12
richard_mawthough it could behave oddly if /dev/shm is a symlink I guess11:12
richard_mawjmacs: can you try the baserock/richardmaw/bugfix/stagingarea-mounts-inside-destdir branch I just pused to git://
jmacsrichard_maw: Sure11:14
jmacsWhat's the difference between devel-system-x86_64-generic.morph and devel-system-x86_64-chroot.morph? (I can diff the files, but I'm not sure why there needs to be a difference)11:15
richard_mawno kernel in the chroot morphology11:15
richard_mawand I guess people didn't want the overhead of building a kernel you're not going to use11:15
Kinnisonthe chroot system carries no BSP indeed11:16
jmacsRight, so building the generic version and using it in a chroot wouldn't be a problem11:16
jmacsrichard_maw: Actually, I'm not sure how to replace morph on an existing baserock system11:17
perrylssam2: is testgerrit down?11:18
SotKjmacs: you can run from git like this:
petefothperryl: just gobne away for me too11:19
ssam2seems Java crashed or was killed on testgerrit11:19
jmacsSotK: So it's just a case of running a different executable?11:20
SotKjmacs: yeah11:20
SotKjmacs: you could also get a checkout of definitions, change the ref of the morph chunk to the version you want and build and deploy an upgrade to your system11:21
jmacsSotK: I can't build :)11:21
jmacsrichard_maw: Your version of morph does appear to fix the problem.11:22
ssam2testgerrit will be down for half an hour or so, I'm going to give it more RAM and CPU so that it can actually mirror stuff11:22
ssam2resizing requires taking a snapshot and then instantiating the snapshot, which is slow11:22
* perryl busies herself with changing the firehose commit message in the meantime11:22
pedroalvarezssam2: the snapshot-ing would be faster if /home were in a different volume11:27
jmacsssam2: It looks like richard_maw has a fix for the problem, so I won't bother sending the bug report11:28
ssam2pedroalvarez: is the snapshotting smart about unused parts of disks?11:30
ssam2jmacs: awesome11:30
ssam2pedroalvarez: it bugs me a bit that in order to get enough RAM I have to give the machine a 160GB root disk or something stupid11:31
pedroalvarezssam2: yes, if the disk is  full it will take longer11:31
pedroalvarezI was just mentioning this because I think is useful info11:31
ssam2yeah, it is11:31
pedroalvarezand if it's too big, it can fail to do the snapshot.11:32
ssam2it's not even started to do the snapshot here11:32
pedroalvarezat least I had problems when doing the baserock-clone snapshot11:32
* ssam2 gives up11:33
richard_mawjmacs: that patch isn't 100% right yet, it currently breaks non-bootstrap builds in the test suite, still working on it11:33
ssam2now the instance won't start again! I 3> OpenStack11:33
CTtpollardssam2, I'm having problems too with it 11:51
jmacsrichard_maw: Yes, I see problems with linux-api-headers now11:54
jmacsI'm happy to send the bug report to record the problem if you've got other stuff to do11:54
richard_mawbaserock/richardmaw/bugfix/stagingarea-mounts-inside-destdir-v2 passes the test suite11:54
richard_mawso it should work for linux-api-headers11:54
jmacsrichard_maw: Is that pushed?11:55
richard_mawit is now11:55
richard_mawsorry, I forgot to push earlier11:55
richard_mawI'd appreciate it if you could remove something like stage1-binutils from your cache so I can tell if it's doing the right thing for non-bootstrap builds for you11:56
ssam2CTtpollard: with OpenStack snapshots, or with testgerrit? 11:57
CTtpollardssam2, snapshots and openstack in general 11:57
richard_mawas I don't have a system where /dev/shm both exists and doesn't11:57
jmacsrichard_maw: OK11:58
richard_mawI've only seen that happen before for broken symlinks11:58
ssam2CTtpollard: apparently even when using Ceph for storage, OpenStack still takes a snapshot locally with QEMU at the moment and then uploads it...11:59
*** mauricemoss_ [] has quit [Read error: Connection reset by peer]11:59
ssam2hopefully in the future it'll be smart enough to use a Ceph snapshot11:59
CTtpollardssam2: +1 11:59
*** mauricemoss_ [] has joined #baserock11:59
ssam2testgerrit should be back12:34
ssam2It's not enlarged, due to my impatience, so we can only hope that it doesn't crash agian12:35
ssam2hopefully next week I can get a more permanent Gerrit set up12:35
* radiofree replies to petefoth's documentation patches12:57
petefothradiofree: biff - but happy to discuss here if you'd rather13:09
petefothSo I have some minor changes to make - should I make them, rebase, then re-send teh whole lot again?13:10
pedroalvarezif the patch is huge, and the changes are small, I sometimes send the new diff13:13
pedroalvarezso, only the new changes13:13
persiaI generally prefer to see the whole thing over again, because it confirms for me that the writer has properly sorted git history, rather than just layered patches randomly (potentially causing merge issues or confusing history)13:15
petefothpersia: I'm inclined to agree - they comments are mostly small changes, spread across 3 of the five changes. I think I should change, rebase to include the new changes with the correct initial patch, and send again13:19
persiapetefoth: That is how I do things in similar situations.  I find it useful to use `git checkout` on each commit, adjust to include comments, and then `git commit --amend`.  I then checkout the next patch in the series (`git log --oneline master..<branchname>` is a handy way to get the list), rebase it on the amended commit (with the SHA git gave me when I checked out a new branch without adding a logical ref to the last one), and move forward, until 13:22
persiaI reach the end.13:22
persiaThis seems awkward and messy compared to adding commits the first couple times, but it makes history nicer to read, and avoids merge pain.13:23
* petefoth will try that on another *different* branch :)13:23
jmacsrichard_maw: Full build of devel-system-x86_64-generic.morph built with your stagingarea-mounts-inside-destdir-v2 branch in a chroot14:02
petefothradiofree: does look more satisfactory?14:06
* persia thinks that BOOTLOADER_CONFIG_FORMAT should not have architecture-specific manditoriness, but isn't confident that this opinion is a critique of the documentation14:07
* petefoth believes that the proposed text matches the current state of the code (if he has understood radiofree correctly)14:08
richard_mawjmacs: I'm sorry that it broke for you, thanks for helping me fix it.14:09
jmacsNo big deal; I was only testing chroots while waiting for something else to build.14:10
jmacsThanks for fixing it so quickly.14:10
ssam2this time, the delta/linux lorry on testgerrit died during 'git gc' (probably due to out-of-memory killer)14:11
ssam2I've stopped the lorry controller processes and am pushing an old git clone of delta/linux manually14:12
perrylssam2: :( at least it's not completely broken this time14:12
*** jmacs [] has quit [Ping timeout: 250 seconds]14:23
*** jmacs_ [] has joined #baserock14:24
jmacs_ is now known as jmacs14:28
*** CTtpollard [] has quit [Quit: Ex-Chat]14:31
*** CTtpollard [] has joined #baserock14:31
ssam2seems it's impossible to push linux to Gerrit in a machine with 2GB of RAM ...14:38
KinnisonGerrit's git implementation is written in Java14:38
* ssam2 tries pulling it inside the machine, instead14:38
ssam2testgerrit will be down while I do this so that hopefully there will be enough RAM14:39
*** genii [~quassel@ubuntu/member/genii] has joined #baserock14:50
ssam2perryl: testgerrit is back and actually has an up-to-date clone of Linux14:57
perrylssam2: brilliant! :) i'll try and get firehose pushing there14:58
ssam2I set 'repack=false' in the lorry configuration which will hopefully mean that lorry manages to update it periodically too14:58
jjardonHi!, is it ok to lorry the current binutils repo?
richard_mawit's called binutils-redhat for legacy reasons, we're not lorrying it from redhat any more15:00
richard_mawbinutils-gdb sounds like they have merged the repos and deprecated the old repository15:00
richard_mawI agree we should update our version of binutils though, so if you're intending to do so I'm happy to +1 the lorry15:01
franredpdar, your boost lorry patch has been merged15:02
pdarfranred: Yay! thanks, and thanks to you and ssam2 for reviews.15:03
franredjjardon, the lorry patch looks ok to me +115:04
ssam2jjardon: yeah, +1 if you update the existing binutils-redhat.lorry rather than adding a 2nd one15:05
richard_mawssam2: I'm not so sure about that15:05
ssam2ah, ok15:05
ssam2i thought that's what you were suggesting too :)15:06
richard_mawif the new repo contains everything from the old repo, then I'd prefer the old lorry being updated to adding a new one, but if we'd lose commits from it, I'm not so sure15:06
franredalso do we want to continue call the repo binutils-redhat? even if it is not lorried from redhat anymore?15:07
richard_mawyou could do it by replacing the url and setting force push refspecs, which wouldn't delete our baserock branches15:07
richard_mawfranred: we don't have a migration strategy for renaming lorried repositories15:08
richard_mawso we'd have to keep the old one around, even if we started a new one15:10
perrylssam2: does the firehose user definitely have push rights? i'm still getting a disallowed message from gerrit...15:13
ssam2we managed to push a branch manually before, I think15:13
ssam2does that still work ?15:13
perrylit should do, will test15:14
ssam2if it still works, then there's something wrong with the command the program is using to push15:15
SotKssam2: which openid providers work with btw?15:16
ssam2launchpad and stackoverflow15:16
ssam2perhaps others15:16
perrylyup, i can manually push15:16
ssam2I'm creating an account for 'mason'15:16
SotKssam2: thanks :)15:17
SotKits building atm15:17
ssam2cool, let me know when it's done and we can deploy it!15:17
SotKperryl: what is the command the program runs to push?15:17
perrylSotK: currently looking at it, what it should be is git push ssh://...... HEAD:refs/for/master/branch/name15:18
perrylwhat it is clearly isn't that15:18
SotKis the actual url definitely correct? (including the magic port number)15:19
perrylSotK: in the firehose plugin push command? it should be the same url15:20
perryli think it's an issue with the branch name15:20
perryl....that's exactly it, augh15:22
SotKssam2: do you mind if I mess with the config on to add the "Verified" review category that Zuul expects?15:23
jjardonrichard_maw: any idea how can be sure the new repo contains everything from the old one?15:24
richard_mawjjardon: I think you could get away with cloning both, running `git for-each-ref` in the old one to get a list of commits, and running `git cat-file -p $commit` in the new one15:25
richard_mawthough you'll want to filter out baserock branches15:25
richard_mawI don't have time to put together a nifty shell one-liner15:26
ssam2SotK: let's do it together so I understand how to do it as well !15:27
rdalei'm getting an error: 'Host rdale@ already has a VM named web-devel-system' - i just want to overwrite the existing web-devel-system - how do i do that?15:29
perrylfirehose almost pushes to gerrit; the only issue is it doesn't add the Change-Id to the commit message...15:32
perryli am so close!15:33
*** ssam2 [] has quit [Ping timeout: 264 seconds]15:35
persiardale: I think you either need to delete the old one first, or --update it15:40
rdaleyes, i've used 'virsh undefine web-devel-system' and that got rid of it15:40
*** ssam2 [] has joined #baserock15:46
Mode #baserock +v ssam2 by ChanServ15:46
jjardonI see we are using tarball in some of our chunks, Is it ok to lorry the tarball version in a different lorry instead or we want to use another strategy?16:13
franredjjardon, if a chunk is lorried for a tarball and you want to add a new tarball you only need to change the URL in that lorry file, if it is not lorried for a tarball you need to create a new lorry with a new name.16:19
jjardonyeah, thats why I ask if thats what we want or not: example libtool is lorried from the git repo but we are compiling a tarball that has been pushed in a branch16:22
pedroalvarezjjardon: I guess that in some projects we found some dificulties16:24
pedroalvarezLike in m4, where you need m4 to compile it from git, but you don't need it when doing from a tarball16:25
jjardonpedroalvarez: sure, so my question is if we want to lorry the tarballs or keep as now and push the tarball in a branch. Or maybe another solution is planned16:26
pedroalvarezI understand what you mean. We are sometimes lorrying the tarball, and sometimes pushing the tarball code into a branch16:27
persiaI think we ought always lorry tarballs, rather than pushing tarball code into branches.16:28
persiaOtherwise we have to trust the person doing the push, and lose traceability.16:28
persiaOf course, I also think we should validate checksums when lorrying tarballs, because it is trivial to cause a lorry controller to lorry the wrong thing with control of the network, but some folk believe me to be overly excitable about having a cryptographically provable chain of custody.16:29
*** zoli_ [] has joined #baserock16:30
*** zoli_ [] has quit [Changing host]16:30
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock16:30
*** mauricemoss_ [] has quit [Ping timeout: 256 seconds]16:41
*** mauricemoss_ [] has joined #baserock17:00
*** sambishop [] has quit [Quit: Leaving]17:03
jjardonAny idea where the Xorg logs are stored in a baserock system?17:06
persiaI thought with systemd-journald everything ended up in the journal17:07
persiaFor non-systemd environments, ought be /var/log/X.log.*17:07
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]17:27
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock17:27
jjardonpersia: yeah, but its not there17:39
persiaNo idea then.  Sorry.17:39
* genii ponders journalctl -e /usr/bin/Xorg 17:43
*** bashrc [] has quit [Quit: Lost terminal]18:13
*** CTtpollard [] has quit [Quit: Ex-Chat]18:13
*** wdutch [] has quit [Quit: Quit]18:16
*** ssam2 [] has quit [Ping timeout: 250 seconds]18:17
*** tiagogomes [] has quit [Quit: Leaving]18:23
*** ratmice [] has joined #baserock19:30
*** CTtpollard [~tom@] has joined #baserock19:39
*** CTtpollard [~tom@] has quit [Client Quit]19:39
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]19:53
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock19:53
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]19:56
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock19:57
jjardongenii: thanks, but not needed anymore20:12
* jjardon is running Xwayland succesfully in his weston session \o/20:13
persiaheh.  That is one way around it :)20:16
jjardonthe log was to know why it was not working, but its fixed now. Expect patches soon ;)20:18
* jjardon has to thanks the people from #wayland for the help20:19
genii is now known as EbenezerScrooge23:09
EbenezerScrooge is now known as genii23:14
*** cosm [Unknown@gateway/vpn/mullvad/x-gzwlyjywzjcqyvnl] has joined #baserock23:24
genii is now known as EbenezerScrooge23:32
EbenezerScrooge is now known as genii23:41

Generated by 2.14.0 by Marius Gedminas - find it at!