IRC logs for #baserock for Thursday, 2014-10-09

*** jamiehowarth [43a10722@gateway/web/freenode/ip.67.161.7.34] has joined #baserock03:20
*** straycat [~straycat@vortis.xen.tardis.ed.ac.uk] has quit [Ping timeout: 240 seconds]06:20
*** straycat [~straycat@vortis.xen.tardis.ed.ac.uk] has joined #baserock06:22
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock06:44
*** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock07:40
*** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock07:44
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]07:59
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock08:00
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock08:01
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit]08:02
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock08:02
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit]08:05
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock08:05
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit]08:06
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock08:06
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock08:40
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock08:48
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock08:58
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds]09:07
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:16
* ssam2 notices http://operatingsystems.io/09:33
ssam2an event about operating systems in London on a tuesday in November09:33
jmacsOh yes, I saw that09:34
ssam2I think I shall see about going, if work will allow it. Sounds interesting09:35
jmacsI'd be up for going09:36
Krinhey all, and morning (ish). Beginning to think this is a lost cause but does anyone know of a way to install a .deb file onto baserock? more precisely a way to port it to something that baserock will understand? I have tried doing it manually with ar -x to unpack the file, I got it to attempt to run, but not joy in the actual continuing to run...10:01
rjekBR people might be interested in the ostree talk10:02
franredrichard_maw, I was talking yesterday with Kinnison about if it is possible to use one repo to build another repo at building time without installing the first repo in the system, and Kinninson told me that could be a possibility using some "devel directory" wich will be not installed...10:02
KinnisonKrin: It's not massively likely you'll get that to work10:03
KinnisonKrin: I'd start by using dpkg-deb on a debian system to unpack the archive and then transfer the contents over, but if you need libraries which are not present in Baserock you won't get it up trivially10:03
ssam2Krin: persia wrote a tool to install a .deb in Baserock, I seem to recall10:04
KinnisonKrin: I take it you don't have source to this deb?10:04
Krinyeah, i was working on that assumption Kinnison, my last ditch effort is to see if anyone knows a way to port it10:04
ssam2https://github.com/persia/debinject10:04
Kinnisonssam2: he wrote something, yes10:04
Krinno source avaialiable Kinnison 10:04
rjekOh, Justin Cormack is organising that OS conference.  He's a good guy.10:04
Kinnisonrjek: ?10:04
Krinno source makes Krin a sad codething10:05
jmacsKinnison: http://operatingsystems.io/10:05
rjekKinnison: http://operatingsystems.io/ mentioned by ssam2 at 1034.10:05
KinnisonKrin: oh dear.  Erm, what platform is this for?10:05
Kinnisonthat conf sounds interesting10:05
KrinUbuntu, mac OS, windows. all individual downloads, but nothing that i think is likely to work with baserock10:06
Kinnisonthe Ubuntu stuff, what platform is it for?10:06
KrinR13 if i recall, but let me go check10:06
Kinnisonintel? arm?10:07
Kinnison32bit?10:07
Kinnison64bit?10:07
Krinrel19.2 arm10:07
Krin64 bit10:07
Kinnisonso aarch64 ?10:07
KinnisonBaserock isn't on aarch64 yet10:08
Krinah. this could explain some things XD10:08
KinnisonWhat are you trying to do with aarch64?  Do you have kit?  If so, we could try and bootstrap a port at some point.10:09
Krinstill trying to get CUDA working on baserock, using a jetson board, baserock installed and updated to the latest for the jetsons10:10
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]10:14
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock10:15
Kinnisonjetson isn't aarch64 it's armv7lhf10:15
Krinwell, i assume it's that architecture then, as it's the CUDA software specificaly designed for the Jetson *blushes*10:16
KinnisonIs it meant to run *on* the jetson?10:20
Krinyes it is a pacakage specificaly designed to run on the jetson Kinnison, however it's designed to run on the jetson default software which is a variation of Ubuntu10:23
richard_mawI think the point was asking how you were offered aarch64 binaries for Jetson10:24
Krinrichard_maw, i dont know how to tell what the binarys are for, i'm still not very experianced in linux or embedded really, i made an assumption, knowing that the Tegra is a 64 bit proccessor, i assumed that the software for it would also be 64bit. 10:32
Krinit also has little to no documentation without installing the software, as it's a seperate thing from te standardly obtainable CUDA toolkits10:34
KinnisonKrin: dpkg-deb -I foofile.deb10:34
Kinnisoncan you put the output of that into a pastebin for me?10:34
richard_mawKrin: http://en.wikipedia.org/wiki/Tegra#Tegra_K1 suggests that are working on an experimental 64-bit core, but the A15 versions are 32-bit10:35
KrinKinnison, https://admin.codethink.co.uk/pnopaste/?192610:36
* Kinnison appreciates this is all a little confusing10:36
KinnisonKrin: Hmm, that's not a public pastebin :-(10:36
Kinnison Architecture: armhf10:37
KinnisonOkay, that's a plausible start10:37
Krinhttp://pastebin.com/fXSdCbNh10:37
KinnisonOkay, so let's start by extracting it10:39
Kinnisonone sec10:39
Kinnisondpkg-deb --fsys-tarfile foo.deb > foo.tar10:39
Kinnisonthen copy foo.tar to your jetson and unpack it10:40
Kinnisonthen try running one of the binaries10:40
Kinnisonif it fails, pastebin the result10:40
jmacsIs /tmp meant to be tmpfs on baserock?10:43
richard_mawthat's the default config for systemd10:43
jmacsThat doesn't really answer my question10:46
richard_mawwe never explicitly decided we wanted /tmp as a tmpfs, it's just that's what systemd does by default10:48
richard_mawso we've gone with it10:48
jmacsLet me rephrase that: /tmp is tmpfs  on my baserock system. Is that what you would expect?10:49
richard_mawyes10:49
jmacsSo morph build is failing because it wants 4GB of free space on /tmp/morph_tmp10:51
richard_mawwe usually put --tempdir=/src/tmp and attach a larger disk on /src, or if we've got a large enough rootfs you could put --tempdir=/var/tmp10:52
KrinKinnison, should i do the same with all the .deb files contained in the original .deb file? 10:53
KinnisonKrin: i'm sorry, you mean they put a bunch of .debs into a .deb?10:54
Krinyes, they have10:54
Kinnisonoh dear10:54
Krinor at least the unpackaged version has more .debs inside it10:54
jmacsrichard_maw: What is --tempdir an arugment to?10:55
richard_mawmorph10:55
jmacsAha10:56
*** tiagogomes [~tiagogome@213.15.255.100] has quit [Quit: Leaving]10:56
richard_mawyou can put "tempdir = /src/tmp" into /etc/morph.conf so you don't need to pass it every time10:56
Krinand if i recall corectly from my earlyer experiments with ar -x Kinnison, some of THOSE .deb files also contain .debs10:56
*** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock10:56
jmacsYes, that's the step I was missing10:56
KinnisonKrin: that sounds horrendous10:57
Krini spent most of last afternoon digging down into the depths of the package to extract the actual meat of the package, and trying to put the results in the right place, got it to run in the end, but it just had the same error as when i got the previous attempt to install but not work10:58
KinnisonI'm afraid that I'm at a loss10:59
Kinnisonif they've made debs which are that horrendous then I'm not sure what to suggest10:59
KrinKinnison,  fly to America, buy a flame-thrower and walk up to the Nvidia office with intent for "polite discussion on correct packaging"?11:01
Krinhell as i say, i'm not that experienced at linux and even i looked at this stuff and went "surely that's not... right?.. whatever..."11:02
KinnisonAs a DD I'm horrified they might do that11:03
KrinDD? debian developer?11:16
KrinKinnison, ^11:17
Kinnisonyes11:18
Krinkay, i'm thinking it's time to throw in the towel on getting CUDA to work on baserock11:18
KinnisonI may be able to assist with the pickapart tomorrow11:19
* Krin goes home to get a towel to throw at the jetson board11:19
Krinthat would be appreciated Kinnison, i'm a long way out of my depth here :)11:19
*** jamiehowarth [43a10722@gateway/web/freenode/ip.67.161.7.34] has quit [Ping timeout: 246 seconds]11:51
jmacsGah, just had another failed self-deployment and it seems to have taken out the root filing system by itself this time :/12:01
SotKI thought Baserock upgrades either worked or didn't do anything? :/12:02
jmacsI'm going to try and mount it outside the VM and investigate12:03
jjardonHi! Can I have some feedback from the patches I sent last week/beginning of this before move to another stuff? ("We are too busy to review them!" Is a perfect valid answer ;))12:42
richard_mawjjardon: are those the llvm and libdrm moving ones?12:43
richard_mawI'd like to review and +1 your changes, but I'm afraid I don't know enough about the graphics stack12:44
* richard_maw is annoyed by how many kernel morphologies we have, and the duplicated information between them12:45
KinnisonIf radiofree were comfortable reviewing jjardon's patches I'd feel okay with merging on his +112:45
richard_mawit makes it more difficult to add generic options to all kernels12:45
jjardonYep, these moves trying to avoid duplication and also avoid unnecessary rebuilds12:46
jjardonKinnison: thanks, I will try to ping him12:47
jmacsI think my previous deploy failed because I ran two deployments with the same VERSION_LABEL12:48
pedroalvarezjmacs: where you deploying as rawdisk?12:49
jmacsWould it be worth me putting in a check to see if you're deploying to your current btrfs volume name (or whatever the term is)?12:49
pedroalvarezs/where/were/12:49
jmacsNo, ssh-rsync12:50
jmacsI don't mean deploy, I mean upgrade12:50
pedroalvarezwhich is the same as depl;oy using ssh-rsync :)12:51
richard_mawit sounds worthwhile, you ought to be able to get the list of systems from `system-version-manager list`12:51
richard_mawthough I think paul added junk to the ends of the lines, making it harder to use the output in a machine parsable way12:52
pedroalvareztrue, but the version label is going to be always in the first column12:52
jmacsCurrently it says "14.40b (running) (default)" which is useful junk12:52
richard_mawperhaps, but it means we can't add a version with those strings in its name12:53
jmacsTrue.12:53
richard_mawpedroalvarez: assuming it's only in the first column means you couldn't have a nice human friendly version name with spaces in12:53
* jjardon just realize his libdrm patches doesn't apply anymore. Will rework it12:54
* richard_maw is a little annoyed that we couldn't have versions with \n in by parsing the output of `system-version-manager list`12:54
jjardonpedroalvarez: do you remember what was the reason for disabling dri3 in mesa?12:55
pedroalvarezjjardon: nope, I just did what James told me to do12:56
pedroalvarezrichard_maw: then we have to change the list command to support an option to show/hide the default and the running bits12:57
pedroalvarezor add another command12:57
wikicatWiki change:  http://wiki.baserock.org/recentchanges/#change-9b64888ca807db163750f7560546e97b6ea7cd3c12:59
richard_maweither another command, which NUL terminates the names, or uses a structured format; or just fix the write extension to fail gracefully if the version already exists12:59
richard_mawah, the isue is that it assumes that if it couldn't make the snapshot, it needs to clean it up13:04
richard_mawcurrently, ssh-rsync can be used to delete a baserock version13:06
pedroalvarezseriously? :S13:07
wikicatWiki change: Adding resolution for insufficient /tmp space error http://wiki.baserock.org/recentchanges/#change-6fec29d0eb9fb03d26efbc9bfb90f98aa57e67e213:07
richard_mawpedroalvarez: yeah, because it tries to mkdir the version root directory, fails, and cleans up the subvolumes and version root directory13:08
richard_mawthough it won't update the extlinux.conf13:08
pedroalvarezthen, checking before that the version doesn't exist, would be great13:10
richard_mawjust fixing it to clean up its resources properly would work13:10
ssam2jjardon: i'll try to look at your patches tomorrow13:16
ssam2jmacs, richard_maw: good spot, I didn't realise that about deploying to an existing VERSION_LABEL13:17
ssam2any volunteers to fix it?13:17
richard_mawI'll do it13:17
jmacsI thought I'd already volunteered, but be my guest :)13:20
paulsherwoodjjardon: yes, sorry i've been offline. +113:39
jjardonpaulsherwood: \o/13:42
* jjardon goes to merge :)13:42
*** genii [~quassel@ubuntu/member/genii] has joined #baserock14:14
franredhi, we were lorrying a repository "python-packages/decorator" from "https://bitbucket.org/pypa/pypi", when we want to use "https://code.google.com/p/micheles/"14:29
pedroalvarezoops14:30
franredchanging the URL in the lorry file will remove the old repo and add the new one without any consecuences?14:30
pedroalvarezI think lorry controller will fail to push some parts of the new lorry14:31
pedroalvarezdue conflicts14:31
franreddo we want to lorry pypi at all? (it is only used for the strata that Im actually working in)14:31
ssam2what's pypi ?14:31
pedroalvarezfranred: if I understood it correctly, it's used in your stratum, but you didn't want to use it14:31
ssam2surely we don't want to import http://pypi.python.org/ ?14:32
franredssam2, it is the same, does it?14:33
pedroalvarezwe can force the lorry controller to force push the new lorry, but I don't know the consequiences in downstream troves14:33
franredbut I think it is not a decorator...14:34
franredssam2, I want a decorator which is in https://code.google.com/p/micheles/14:34
pedroalvarezbut that repo not only contains the decorator source14:35
franredhttps://pypi.python.org/pypi/decorator/3.4.014:35
franredyep... should I use the tarball instead?14:35
franredthe mercurial repository contains more than the decorator14:36
pedroalvarezfranred: couldn't you use this? https://pypi.python.org/pypi/decorator14:36
pedroalvarezbaserock-14.40.1 has been finally released14:42
pedroalvarezthere is a new jetson devel system ready to flash in download.baserock.org14:42
ssam2\o/14:42
franredI need a fast review about this lorry file: http://fpaste.org/140650/66470141/14:54
richard_mawfranred: it sucks that we have to have a tarball import, but +114:55
SotKfranred: +114:56
richard_mawI'm not sure where the micheles name is from though14:56
franredrichard_maw, the other posibility is lorry a whole mercurial repository with other projects on it :S14:56
richard_mawwe've done chunks like that before14:56
richard_mawit's a depressingly popular way of running a project14:57
franredrichard_maw, do you think that is better the mercurial repo than the tarball?14:57
franrednote: this will add also extra work in the chunk morphology14:58
richard_mawyeah, but we're not afraid of that14:58
jmacsssam2: Have you tried running "knife" yet? I just get errors connecting to https://supermarket.getchef.com14:58
franredrichard_maw, then I will change the lorry patch14:59
pedroalvarezthen, makes sense to call it "decorator" when it is going to add more things?15:00
franredpedro, I will called micheles-repository15:00
pedroalvarezbut micheles is a person!15:01
pedroalvarezisn't?15:01
Kinnisonpresumably15:01
franredit is15:01
pedroalvarezI'm going to create a repository with multiple proyects, and then lorry it. so I can have a repo with my name in g.b.o!15:01
richard_mawhm, hold on for a minute15:02
richard_maweww, this repository isn't just decorator, it's a dumping ground for things that are unrelated15:03
pedroalvarezthey are maybe related15:03
Kinnisonfran did say15:03
pedroalvarezsame author15:03
richard_mawit's got things that aren't code or documentation about code in it15:03
pedroalvarezanother point is: what do we do with upstrem:decorator?15:05
ssam2jmacs: I didn't try all 'knife' commands15:05
ssam2might be SSL related15:05
*** pwerner9 [~pwerner9@c-68-61-186-102.hsd1.mi.comcast.net] has joined #baserock15:06
jmacsYes, looks like it15:06
ssam2in fact, you may need an account to contact supermarket.getchef.com and have your private certificate for that account available to Knife somewhere15:06
jmacsI've no idea what the chef server should be either15:06
ssam2no, Chef seem to provide a public instance15:08
franredpedroalvarez, I will change the name from decorator-micheles to python-decorator - and.... lorry the tarball! :S15:08
ssam2jmacs: or, you can install it in a Fedora or Debian machine from their 'megapackage', although I guess it requires some setting up15:08
ssam2you can also run Chef without a server15:08
ssam2there's a tool called `chef-solo` which helps with that15:09
pedroalvarezfranred: I'm not sure about that15:09
pedroalvarezI can't +2 that decission15:09
franredit is just a name - I will sign-off that15:10
pedroalvarezis not just a name15:11
jmacsI'm trying to set up my machine as a chef server now15:11
ssam2cool, let me know how it goes!15:11
franredrichard_maw, SotK, any problem to lorry the tarball and called pytho-decorator rather than decorator-micheles? pedroalvarez think that I should replace the actual decorator by this but I don't know the consequences of that15:12
SotKI don't have an issue with the name, but am interested to know why we need to lorry this if decorator is already lorried?15:16
richard_mawwrong decorator I think15:16
SotKfair enough then I guess15:16
franredyeah, it is the wrong decorator15:20
wikicatWiki change: Update instructions to use latest tag http://wiki.baserock.org/recentchanges/#change-449879c58163562020894bb26e349174194a241215:21
wikicatWiki change: Update baserock-jetson instructions to work with latest release http://wiki.baserock.org/recentchanges/#change-6d0ca92e65cef0b0da658654c938be66b11b19ea15:25
richard_mawoh wikicat is a bot!15:26
* richard_maw thought straycat was playing games15:26
franredsorry to bother you today with this but I need a new review: http://fpaste.org/140662/28685091/ - this has the name changed and an additional repo that we need15:28
ssam2franred: what name has changed? looks like 2 additional repos and no other changes15:30
franredssam2, the second one is the same that I've posted before but with different naem15:31
franredname even15:31
ssam2right, ok15:31
ssam2+115:31
straycatyeah wikicat should point to something more useful though15:48
*** tiagogomes [~tiagogome@213.15.255.100] has quit [Quit: Leaving]15:48
* richard_maw ended up rewriting ssh-rsync to be mostly context managers15:50
rjekwin 815:50
franredanyone could have a look the the fast review I've posted before or should I take the +1 from ssam2 as a +2? :P15:50
rjekbah15:50
richard_mawfranred: go ahead15:50
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection]15:53
wikicatWiki change:  http://source.baserock.branchable.com/?p=source.git;a=commitdiff;h=6ef520b16:05
*** jamiehowarth [~jamiehowa@2607:fb90:1d0e:a276:dd60:e171:b550:85b4] has joined #baserock16:18
*** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit]16:33
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]16:35
richard_mawssam2: added raises and re-tested, worked16:37
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]16:37
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection]16:37
jjardonSo Im trying to upgrade to latest systemd the update will be blocked because I need coreutils (GPLv3) to compile it. Any hint where I have to look at to try to fix this in the correct way?17:07
*** mSher [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]17:11
radiofreejjardon: it'll only be blocked for genivi?17:25
jjardonradiofree: yes17:25
radiofreefor now that shouldn't be a concern really?17:30
jjardonMy understanding is that no-GPLv3 code can go in genivi images. So we can't put coreutils in core to build systemd with them17:35
pedroalvarezour current approach with gplv3 chunks in genivi system is: remove everything installed by them when everything is built17:36
radiofreeas far as i'm aware the gpl3 stuff is removed *after* building17:36
pedroalvarezif we do the same with coreutils we will end up with a system unusable17:36
radiofreeif you build gpl2 stuff with gpl3 things, would you have to remove the gpl2 stuff?17:37
pedroalvarezafact, we are not removing anything else than gplv3 things17:37
KinnisonSo long as no gplv3 code is *linked* into the system you're safe17:40
Kinnisongpl doesn't infect through compilation or you'd never be able to build anything but gpl code with gcc17:40
paulsherwoodrichard_maw: if i may be so bold, what on earth is a 'context manager'?17:44
jjardonmaybe this can be solved putting coreutils in a separate stratum, make foundation depend on it, but do not use that stratum in the genivi systems?18:28
pedroalvarezjjardon: that would work, yeah. not the ideal solution though18:29
jjardonmmm, morph is stuck in "Resolving artifacts", this is the latest log: http://fpaste.org/140717/87946014/ Any idea what is happening/where should I look?18:31
pedroalvarezsome people have reported slow starting times some days ago18:32
radiofreejjardon: it's probably not stuck18:32
radiofreeit just takes absolutely ages18:32
paulsherwoodyes, i blame recent changes :/18:32
pedroalvarezjjardon: please, leave it running and report the log later18:32
jjardonsure!18:33
jjardonits alive!! :)18:33
pedroalvarezjjardon: any useful in the log?18:33
* paulsherwood wonders why 85.199.252.101 has been yellow since Tuesday?18:35
pedroalvarezI only see one yellow18:35
jjardonpedroalvarez:   I do not think so: it continues running normally after 11 min: http://fpaste.org/140722/41287973/18:35
radiofreethat's definitely a regression18:37
paulsherwoodjjardon: are you using latest morph?18:38
jjardonpaulsherwood: latest master, yes18:38
paulsherwoodhmmm.18:38
jjardonnote this is after adding the GNOME stratum18:39
jjardonbut it was no so slow before18:39
paulsherwoodhttp://fpaste.org/140724/18:39
paulsherwoodseems blazingly fast to me, suddenly18:40
paulsherwooderm, has someone been fiddling with deploy?18:42
paulsherwoodhttp://fpaste.org/140727/18:43
pedroalvarezpaulsherwood: I've changed the http://85.199.252.101/ address to point to new mason, which builds also the genivi systems18:43
paulsherwoodpedroalvarez: but it's not working?18:43
paulsherwoodanything i can check before i reboot my busted devel system and pray?18:43
pedroalvarezsystem-version-manager list18:44
paulsherwoodi don't even have ls, never mind system-version-manager18:45
pedroalvarezoh, I missed that18:46
pedroalvarezRichard Maw has sent a patch to fix that18:46
paulsherwoodi'm on latest master morph, definitions18:46
pedroalvarezI think you were running the TEST version when doing the upgrade with version label TEST18:46
paulsherwoodok18:46
pedroalvarezcan be that true?18:47
paulsherwoodyes, it can. well spotted :)18:47
paulsherwoodbut now i haven't even got 'reboot' 18:47
pedroalvarezhahaha18:47
pedroalvarezis an openstack instance?18:48
paulsherwoodi'm laughing here too, but crying inside ;)18:48
paulsherwoodnope, my local vm18:48
pedroalvarezhmm18:48
paulsherwoodnot to worry18:48
pedroalvarezthen you should have a button to reboot it18:48
paulsherwoodyes, that fixed it (rebooting into factory)18:49
paulsherwoodso maybe i wasn't actually in fact running latest morph ...18:49
pedroalvarezthe patch is not merged anyway18:50
pedroalvarez(I think)18:50
pedroalvarezcurrently if you deploy an upgrade with a version label that already exsist, the previous version will be removed and the deployment fail18:50
pedroalvarezwe spotted that today18:51
paulsherwoodinteresting conundrum... if i'm (accidentally) in TEST, do git pull for morph, that won't be the morph i actually get, becasue TEST /usr/bin doesn't have the script to run latest morph in it18:51
* paulsherwood decides to fix this hole in cycle.sh18:58
*** pwerner9 [~pwerner9@c-68-61-186-102.hsd1.mi.comcast.net] has quit [Quit: pwerner9]19:09
*** jamiehowarth [~jamiehowa@2607:fb90:1d0e:a276:dd60:e171:b550:85b4] has quit [Ping timeout: 272 seconds]20:57
radiofreeKinnison: just saw your comment, will take a look at them tomorrow22:31
*** pwerner9 [~pwerner9@d14-69-32-220.try.wideopenwest.com] has joined #baserock23:02
*** pwerner9 [~pwerner9@d14-69-32-220.try.wideopenwest.com] has quit [Client Quit]23:07
*** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection]23:13
* paulsherwood discovers celery, and marvels23:31
*** pwerner9 [~pwerner9@d14-69-32-220.try.wideopenwest.com] has joined #baserock23:40
*** pwerner9 [~pwerner9@d14-69-32-220.try.wideopenwest.com] has quit [Quit: pwerner9]23:54
*** pwerner9 [~pwerner9@d14-69-32-220.try.wideopenwest.com] has joined #baserock23:59

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