jjardon | mmm, looking at http://mason-armv7lhf.baserock.org/ and http://mason-x86-64.baserock.org/, how is possible that the last commit takes ~3 hours in x86 and a little more than 2 hours in arm? | 00:40 |
---|---|---|
radiofree | jjardon: it monitors g.b.o for changes | 01:03 |
radiofree | the 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 using | 01:04 |
radiofree | (separate trove needed for distbuild networks because of the need to push temporary branches) | 01:05 |
radiofree | i think that's the reason anyway | 01: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 #baserock | 04:34 | |
*** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has quit [Changing host] | 04:34 | |
*** persia_ [quassel@ubuntu/member/persia] has joined #baserock | 04:34 | |
*** ratmice_________ [bosshog@nightfall.forlorn.net] has quit [Ping timeout: 250 seconds] | 06:01 | |
*** paulsherwood [~paulsherw@access.ducie-dc1.codethink.co.uk] has joined #baserock | 07:15 | |
*** petefotheringham [~petefothe@access.ducie-dc1.codethink.co.uk] has joined #baserock | 07:28 | |
*** petefotheringham [~petefothe@access.ducie-dc1.codethink.co.uk] has quit [Client Quit] | 07:29 | |
*** petefotheringham [~petefothe@access.ducie-dc1.codethink.co.uk] has joined #baserock | 07:29 | |
petefotheringham is now known as petefoth1 | 07:38 | |
*** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:15 | |
*** perryl [~laurenper@access.ducie-dc1.codethink.co.uk] has joined #baserock | 08:20 | |
*** perryl [~laurenper@access.ducie-dc1.codethink.co.uk] has quit [Quit: leaving] | 08:25 | |
*** perryl [~laurenper@access.ducie-dc1.codethink.co.uk] has joined #baserock | 08:27 | |
petefoth | A 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. ...' http://lwn.net/Articles/625252/ :) | 08:39 |
jjardon | Sooo, archlinux? ;) | 08:41 |
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:05 | |
*** SotK [~adamcoldr@access.ducie-dc1.codethink.co.uk] has joined #baserock | 09:10 | |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 09:11 | |
rjek | Debian Testing? ;-) | 09:11 |
rjek | (Actually, no. Debian Testing has had some testing done on it. Debian Unstable.) | 09:11 |
Kinnison | Unstable is also fairly carefully curated | 09:13 |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [] | 09:13 | |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:13 | |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:24 | |
*** SotK [~adamcoldr@access.ducie-dc1.codethink.co.uk] has quit [Quit: leaving] | 09:28 | |
*** SotK [~adamcoldr@access.ducie-dc1.codethink.co.uk] has joined #baserock | 09:28 | |
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:29 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:49 | |
Mode #baserock +v ssam2 by ChanServ | 09:49 | |
petefoth | Updated help text for the generic write extension parameters http://paste.baserock.org/cakaquyuju | 09:54 |
ssam2 | petefoth: I think the KERNEL_ARGS goes into too much detail -- maybe remove the comments and just show the defualt commandline | 09:59 |
ssam2 | where is this documentation going? I ask because we'll need to be sure it's updated whenever the defaults themselves change | 09: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 | |
ssam2 | so 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 |
petefoth | So 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 |
ssam2 | yes | 10:01 |
petefoth | sadly it will be in 'files xxx, yyy,..." as this text will be in the .help files for all the wrtie extensions which take KERNEL_ARGS | 10:02 |
*** Kinnison [~dsilvers@gateway/shell/pepperfish/x-iumivulvebvqfovj] has joined #baserock | 10:03 | |
ssam2 | petefoth: OK. As long that's noted in the code where we define the default KERNEL_ARGS (which I imagine is morphlib/writeexts.py) | 10:04 |
ssam2 | nothing worse than documentation that actively lies! | 10:04 |
petefoth | ssam2: it will be | 10:06 |
petefoth | So, 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 |
petefoth | s/gerrti/gerrit/ | 10:12 |
*** pdar [~patrickda@access.ducie-dc1.codethink.co.uk] has joined #baserock | 10:12 | |
*** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has joined #baserock | 10:13 | |
persia | petefoth: I believe you'd push to HEAD:refs/for/master | 10:14 |
persia | Unless you wanted a long-lived feature branch for some reason | 10:14 |
perryl | oh! i wonder if that was where i was going wrong... | 10:15 |
petefoth | persia: thanks - I'll try that when the changes are done | 10:15 |
persia | Note that I'm not 100% sure. I always used git-review with gerrit. | 10:15 |
pedroalvarez | which makes it simpler | 10:16 |
petefoth | I 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 push | 10:17 |
*** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 10:18 | |
franred | petefoth, have you clone the repo with the gerrit hook? | 10:19 |
*** kejiahu [~kejiahu@access.ducie-dc1.codethink.co.uk] has joined #baserock | 10:24 | |
petefoth | I beklieve so (though I used git remote add rather than 'git clone' | 10:24 |
petefoth | franred: ^^ | 10:24 |
*** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 10:28 | |
*** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:30 | |
franred | petefoth, not sure then | 10:30 |
ssam2 | seems lorry on the testgerrit has got stuck in a 'git pack-objects' call | 10:32 |
*** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:32 | |
Kinnison | It'll finish eventually, but it can be high RAM usage | 10:34 |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: petefoth] | 10:34 | |
ssam2 | Started: 2014-12-11 12:17:28 UTC | 10:36 |
Kinnison | Ouch | 10:36 |
Kinnison | packing objects is a high-ram-usage event sadly | 10:36 |
Kinnison | if the system is low on RAMs then it'll be hitting swap a lot | 10:37 |
Kinnison | which will slow it down dramatically | 10:37 |
ssam2 | it has no swap. but it is competing with Java! | 10:37 |
ssam2 | the default ghost-timeout in the lorry-controller webapp is 600 units | 10:37 |
ssam2 | (I guess seconds?) | 10:37 |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:37 | |
ssam2 | oh, but there's probably a separate systemd unit that kills ghost jobs, which I haven't turned into a cron job on this machine | 10:38 |
*** zarazaimeche [~zarazaime@access.ducie-dc1.codethink.co.uk] has joined #baserock | 10:38 | |
ssam2 | so that's why this process hasn't been killed | 10:38 |
Kinnison | heh | 10:38 |
Kinnison | How's the output packs looking in thr repo? | 10:38 |
zarazaimeche is now known as Zara | 10:39 | |
ssam2 | 107MB .idx file and 821MB .pack file | 10:40 |
ssam2 | so, nearly there in fact | 10:40 |
ssam2 | by comparison with the git.baserock.org equivalent | 10:40 |
Kinnison | cool | 10:41 |
perryl | attempting to run the firehose command on a test config, have received the following error: http://paste.baserock.org/dihuyusuwi | 10:42 |
perryl | the fact that the action was prohibited is promising, it means it's doing something right (even if it's not being allowed) | 10:42 |
Kinnison | :-) | 10:42 |
SotK | is the firehose user in one of the access control groups who are allowed to push to that repo? | 10:43 |
ssam2 | probably not, we didn't set that up yet | 10:43 |
perryl | that would be the reason it was prohibited! | 10:44 |
perryl | s/would be/is probably | 10:44 |
ssam2 | perryl: there's now a Firehose group which has the right to push to refs/for/refs/* | 10:47 |
ssam2 | I think it doesn't have any other rights, we might need to tweak its permissions further | 10:48 |
perryl | ssam2: cool, i'll try the command again and see what happens | 10:48 |
petefoth | franred: git remote -v gives ssh://petefoth@testgerrit.baserock.org:29418/baserock/baserock/morph, so I guess I do have the gerrit hook | 10:49 |
perryl | ssam2: actually, is there anything i need to do manually before pushing? | 10:50 |
ssam2 | shouldn't be | 10:50 |
petefoth | Ok So I dont' have the commit hook :) | 10:56 |
SotK | petefoth: http://paste.baserock.org/sogebikohi | 10:57 |
SotK | petefoth: put that in .git/hooks/commit-msg | 10:58 |
petefoth | SotK: thanks | 10:58 |
SotK | you may have to cause the commits to be recreated somehow to make it add a Change-Id to existing commits | 10:58 |
SotK | `git commit --amend` for example | 10:59 |
petefoth | SotK: I haven't actually made the changes yet so that won't be a problem : | 10:59 |
jmacs | Trying 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 |
ssam2 | that's a new one. | 11:00 |
petefoth | SotK: do I need an instance of tha file in each repo that I want to work with Gerrit? | 11:00 |
ssam2 | jmacs: stage1 builds run in 'bootstrap' mode, where there's no staging chroot | 11:00 |
SotK | petefoth: yes | 11:00 |
SotK | however, 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 hook | 11:01 |
richard_maw | ssam2, jmacs: it could be that morphlib.stagingarea.StagingArea.runcmd should be sorting out to_mount to make it use the path to the staging area | 11:03 |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 11:04 | |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:04 | |
richard_maw | yeah, 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 logic | 11:05 |
richard_maw | I'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_maw | though it could behave oddly if /dev/shm is a symlink I guess | 11:12 |
richard_maw | jmacs: can you try the baserock/richardmaw/bugfix/stagingarea-mounts-inside-destdir branch I just pused to git://git.baserock.org/baserock/baserock/morph.git? | 11:13 |
jmacs | richard_maw: Sure | 11:14 |
jmacs | What'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_maw | no kernel in the chroot morphology | 11:15 |
richard_maw | and I guess people didn't want the overhead of building a kernel you're not going to use | 11:15 |
Kinnison | the chroot system carries no BSP indeed | 11:16 |
jmacs | Right, so building the generic version and using it in a chroot wouldn't be a problem | 11:16 |
Kinnison | indeed | 11:16 |
jmacs | richard_maw: Actually, I'm not sure how to replace morph on an existing baserock system | 11:17 |
perryl | ssam2: is testgerrit down? | 11:18 |
SotK | jmacs: you can run from git like this: http://wiki.baserock.org/using-latest-morph/ | 11:19 |
petefoth | perryl: just gobne away for me too | 11:19 |
ssam2 | seems Java crashed or was killed on testgerrit | 11:19 |
jmacs | SotK: So it's just a case of running a different executable? | 11:20 |
SotK | jmacs: yeah | 11:20 |
SotK | jmacs: 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 system | 11:21 |
jmacs | SotK: I can't build :) | 11:21 |
jmacs | richard_maw: Your version of morph does appear to fix the problem. | 11:22 |
ssam2 | testgerrit 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 stuff | 11:22 |
ssam2 | resizing requires taking a snapshot and then instantiating the snapshot, which is slow | 11:22 |
* perryl busies herself with changing the firehose commit message in the meantime | 11:22 | |
pedroalvarez | ssam2: the snapshot-ing would be faster if /home were in a different volume | 11:27 |
jmacs | ssam2: It looks like richard_maw has a fix for the problem, so I won't bother sending the bug report | 11:28 |
ssam2 | pedroalvarez: is the snapshotting smart about unused parts of disks? | 11:30 |
ssam2 | jmacs: awesome | 11:30 |
ssam2 | pedroalvarez: it bugs me a bit that in order to get enough RAM I have to give the machine a 160GB root disk or something stupid | 11:31 |
pedroalvarez | ssam2: yes, if the disk is full it will take longer | 11:31 |
ssam2 | right | 11:31 |
pedroalvarez | I was just mentioning this because I think is useful info | 11:31 |
ssam2 | yeah, it is | 11:31 |
pedroalvarez | and if it's too big, it can fail to do the snapshot. | 11:32 |
ssam2 | awesome! | 11:32 |
ssam2 | it's not even started to do the snapshot here | 11:32 |
pedroalvarez | at least I had problems when doing the baserock-clone snapshot | 11:32 |
* ssam2 gives up | 11:33 | |
richard_maw | jmacs: that patch isn't 100% right yet, it currently breaks non-bootstrap builds in the test suite, still working on it | 11:33 |
ssam2 | now the instance won't start again! I 3> OpenStack | 11:33 |
CTtpollard | ssam2, I'm having problems too with it | 11:51 |
jmacs | richard_maw: Yes, I see problems with linux-api-headers now | 11:54 |
jmacs | I'm happy to send the bug report to record the problem if you've got other stuff to do | 11:54 |
richard_maw | baserock/richardmaw/bugfix/stagingarea-mounts-inside-destdir-v2 passes the test suite | 11:54 |
richard_maw | so it should work for linux-api-headers | 11:54 |
jmacs | richard_maw: Is that pushed? | 11:55 |
richard_maw | it is now | 11:55 |
richard_maw | sorry, I forgot to push earlier | 11:55 |
jmacs | Cheers | 11:55 |
richard_maw | I'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 you | 11:56 |
ssam2 | CTtpollard: with OpenStack snapshots, or with testgerrit? | 11:57 |
CTtpollard | ssam2, snapshots and openstack in general | 11:57 |
richard_maw | as I don't have a system where /dev/shm both exists and doesn't | 11:57 |
jmacs | richard_maw: OK | 11:58 |
richard_maw | I've only seen that happen before for broken symlinks | 11:58 |
ssam2 | CTtpollard: 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_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 11:59 | |
ssam2 | hopefully in the future it'll be smart enough to use a Ceph snapshot | 11:59 |
CTtpollard | ssam2: +1 | 11:59 |
*** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:59 | |
ssam2 | testgerrit should be back | 12:34 |
ssam2 | It's not enlarged, due to my impatience, so we can only hope that it doesn't crash agian | 12:35 |
ssam2 | hopefully next week I can get a more permanent Gerrit set up | 12:35 |
* radiofree replies to petefoth's documentation patches | 12:57 | |
petefoth | radiofree: biff - but happy to discuss here if you'd rather | 13:09 |
petefoth | So I have some minor changes to make - should I make them, rebase, then re-send teh whole lot again? | 13:10 |
pedroalvarez | if the patch is huge, and the changes are small, I sometimes send the new diff | 13:13 |
pedroalvarez | so, only the new changes | 13:13 |
persia | I 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 |
petefoth | persia: 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 again | 13:19 |
persia | petefoth: 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 |
persia | I reach the end. | 13:22 |
persia | This 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 | |
persia | Heh. | 13:24 |
jmacs | richard_maw: Full build of devel-system-x86_64-generic.morph built with your stagingarea-mounts-inside-destdir-v2 branch in a chroot | 14:02 |
petefoth | radiofree: does http://paste.baserock.org/edalavogah 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 documentation | 14:07 | |
* petefoth believes that the proposed text matches the current state of the code (if he has understood radiofree correctly) | 14:08 | |
richard_maw | jmacs: I'm sorry that it broke for you, thanks for helping me fix it. | 14:09 |
jmacs | No big deal; I was only testing chroots while waiting for something else to build. | 14:10 |
jmacs | Thanks for fixing it so quickly. | 14:10 |
ssam2 | this time, the delta/linux lorry on testgerrit died during 'git gc' (probably due to out-of-memory killer) | 14:11 |
ssam2 | I've stopped the lorry controller processes and am pushing an old git clone of delta/linux manually | 14:12 |
perryl | ssam2: :( at least it's not completely broken this time | 14:12 |
*** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 250 seconds] | 14:23 | |
*** jmacs_ [~jimmacart@access.ducie-dc1.codethink.co.uk] has joined #baserock | 14:24 | |
jmacs_ is now known as jmacs | 14:28 | |
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 14:31 | |
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:31 | |
ssam2 | seems it's impossible to push linux to Gerrit in a machine with 2GB of RAM ... | 14:38 |
Kinnison | :-( | 14:38 |
Kinnison | Gerrit's git implementation is written in Java | 14:38 |
* ssam2 tries pulling it inside the machine, instead | 14:38 | |
ssam2 | testgerrit will be down while I do this so that hopefully there will be enough RAM | 14:39 |
*** genii [~quassel@ubuntu/member/genii] has joined #baserock | 14:50 | |
ssam2 | perryl: testgerrit is back and actually has an up-to-date clone of Linux | 14:57 |
perryl | ssam2: brilliant! :) i'll try and get firehose pushing there | 14:58 |
ssam2 | I set 'repack=false' in the lorry configuration which will hopefully mean that lorry manages to update it periodically too | 14:58 |
jjardon | Hi!, is it ok to lorry the current binutils repo? http://paste.baserock.org/hoqejapise | 14:58 |
richard_maw | it's called binutils-redhat for legacy reasons, we're not lorrying it from redhat any more | 15:00 |
richard_maw | binutils-gdb sounds like they have merged the repos and deprecated the old repository | 15:00 |
richard_maw | I agree we should update our version of binutils though, so if you're intending to do so I'm happy to +1 the lorry | 15:01 |
franred | pdar, your boost lorry patch has been merged | 15:02 |
pdar | franred: Yay! thanks, and thanks to you and ssam2 for reviews. | 15:03 |
franred | jjardon, the lorry patch looks ok to me +1 | 15:04 |
ssam2 | jjardon: yeah, +1 if you update the existing binutils-redhat.lorry rather than adding a 2nd one | 15:05 |
richard_maw | ssam2: I'm not so sure about that | 15:05 |
ssam2 | ah, ok | 15:05 |
ssam2 | i thought that's what you were suggesting too :) | 15:06 |
richard_maw | if 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 sure | 15:06 |
ssam2 | agreed | 15:06 |
franred | also do we want to continue call the repo binutils-redhat? even if it is not lorried from redhat anymore? | 15:07 |
richard_maw | you could do it by replacing the url and setting force push refspecs, which wouldn't delete our baserock branches | 15:07 |
franred | want/care | 15:07 |
richard_maw | franred: we don't have a migration strategy for renaming lorried repositories | 15:08 |
richard_maw | so we'd have to keep the old one around, even if we started a new one | 15:10 |
perryl | ssam2: does the firehose user definitely have push rights? i'm still getting a disallowed message from gerrit... | 15:13 |
ssam2 | we managed to push a branch manually before, I think | 15:13 |
ssam2 | does that still work ? | 15:13 |
perryl | it should do, will test | 15:14 |
ssam2 | if it still works, then there's something wrong with the command the program is using to push | 15:15 |
SotK | ssam2: which openid providers work with testgerrit.baserock.org btw? | 15:16 |
ssam2 | launchpad and stackoverflow | 15:16 |
ssam2 | perhaps others | 15:16 |
perryl | yup, i can manually push | 15:16 |
ssam2 | I'm creating an account for 'mason' | 15:16 |
SotK | ssam2: thanks :) | 15:17 |
SotK | its building atm | 15:17 |
ssam2 | cool, let me know when it's done and we can deploy it! | 15:17 |
SotK | perryl: what is the command the program runs to push? | 15:17 |
perryl | SotK: currently looking at it, what it should be is git push ssh://...... HEAD:refs/for/master/branch/name | 15:18 |
perryl | what it is clearly isn't that | 15:18 |
SotK | is the actual url definitely correct? (including the magic port number) | 15:19 |
perryl | SotK: in the firehose plugin push command? it should be the same url | 15:20 |
perryl | i think it's an issue with the branch name | 15:20 |
perryl | ....that's exactly it, augh | 15:22 |
SotK | ssam2: do you mind if I mess with the config on testgerrit.baserock.org to add the "Verified" review category that Zuul expects? | 15:23 |
jjardon | richard_maw: any idea how can be sure the new repo contains everything from the old one? | 15:24 |
richard_maw | jjardon: 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 one | 15:25 |
richard_maw | though you'll want to filter out baserock branches | 15:25 |
richard_maw | I don't have time to put together a nifty shell one-liner | 15:26 |
ssam2 | SotK: let's do it together so I understand how to do it as well ! | 15:27 |
rdale | i'm getting an error: 'Host rdale@192.168.1.41 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 |
perryl | firehose almost pushes to gerrit; the only issue is it doesn't add the Change-Id to the commit message... | 15:32 |
perryl | i am so close! | 15:33 |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 15:35 | |
persia | rdale: I think you either need to delete the old one first, or --update it | 15:40 |
rdale | yes, i've used 'virsh undefine web-devel-system' and that got rid of it | 15:40 |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:46 | |
Mode #baserock +v ssam2 by ChanServ | 15:46 | |
jjardon | I 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 |
franred | jjardon, 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 |
jjardon | yeah, 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 branch | 16:22 |
pedroalvarez | jjardon: I guess that in some projects we found some dificulties | 16:24 |
pedroalvarez | Like in m4, where you need m4 to compile it from git, but you don't need it when doing from a tarball | 16:25 |
jjardon | pedroalvarez: 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 planned | 16:26 |
pedroalvarez | I understand what you mean. We are sometimes lorrying the tarball, and sometimes pushing the tarball code into a branch | 16:27 |
persia | I think we ought always lorry tarballs, rather than pushing tarball code into branches. | 16:28 |
persia | Otherwise we have to trust the person doing the push, and lose traceability. | 16:28 |
persia | Of 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_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 16:30 | |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 16:30 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 16:30 | |
*** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 256 seconds] | 16:41 | |
*** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:00 | |
*** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:03 | |
jjardon | Any idea where the Xorg logs are stored in a baserock system? | 17:06 |
persia | I thought with systemd-journald everything ended up in the journal | 17:07 |
persia | For 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 #baserock | 17:27 | |
jjardon | persia: yeah, but its not there | 17:39 |
persia | No idea then. Sorry. | 17:39 |
* genii ponders journalctl -e /usr/bin/Xorg | 17:43 | |
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 18:13 | |
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 18:13 | |
*** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 18:16 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 18:17 | |
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:23 | |
*** ratmice [bosshog@nightfall.forlorn.net] has joined #baserock | 19:30 | |
*** CTtpollard [~tom@94.15.178.154] has joined #baserock | 19:39 | |
*** CTtpollard [~tom@94.15.178.154] 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 #baserock | 19:53 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 19:56 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 19:57 | |
jjardon | genii: thanks, but not needed anymore | 20:12 |
* jjardon is running Xwayland succesfully in his weston session \o/ | 20:13 | |
persia | heh. That is one way around it :) | 20:16 |
jjardon | the 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 help | 20:19 | |
genii is now known as EbenezerScrooge | 23:09 | |
EbenezerScrooge is now known as genii | 23:14 | |
*** cosm [Unknown@gateway/vpn/mullvad/x-gzwlyjywzjcqyvnl] has joined #baserock | 23:24 | |
genii is now known as EbenezerScrooge | 23:32 | |
EbenezerScrooge is now known as genii | 23:41 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!