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

*** zoli__ has joined #baserock03:24
*** zoli__ has quit IRC05:56
*** zoli__ has joined #baserock06:16
*** mariaderidder has joined #baserock06:45
*** ssam2 has joined #baserock06:47
*** ChanServ sets mode: +v ssam206:47
*** a1exhughe5 has joined #baserock07:11
*** Albert_ has joined #baserock07:31
*** zoli___ has joined #baserock07:39
*** zoli__ has quit IRC07:39
petefothThe new guide at http://wiki.baserock.org/guides/ceph-cluster-deploy/ referes in a few places to pdar's github 'working copy' clone of definitions.git. Can this be changed to refer to g.b.o instead?07:41
pedroalvarezI like to have someone checking the wiki :) Thanks petefoth08:01
petefothpedroalvarez: There are a couple of typos that I'll correct but I don't want to mess with the technical stuff ;)08:02
pedroalvarezSTATUS UPDATE of Mason: Cleaning the cache fixed the error, but some weird error happened (kernel panic), so it has started building 3 hours ago08:03
*** sherm_ has joined #baserock08:04
*** bashrc_ has joined #baserock08:05
pedroalvarezpetefoth: IMO yes, we should merge the content of that branch (of that gihub repo) in master of definitions.git on g.b.o08:07
*** edcragg has joined #baserock08:08
pedroalvarezlet's wait for pdar's input and see what we can do08:08
petefothpedroalvarez: but probably best not to change the wiki until the merge is done. That could be added as a comment in gerrit to the review of pdar's patch(es)08:09
*** jonathanmaw has joined #baserock08:19
pdarpetefoth: Thanks for having a look over the new page, hope there wernt too many typos! Yep, aiming to get it merged with master at some point in the coming day/s.08:35
pdarThen i'll update the wiki accordingly08:36
petefothpdar: OK08:36
*** rdale has quit IRC08:48
*** gary_perkins has joined #baserock08:52
*** rdale has joined #baserock08:53
*** ratmice__ has quit IRC09:04
*** ratmice__ has joined #baserock09:04
*** lachlanmackenzie has joined #baserock09:15
*** Krin has joined #baserock09:24
*** mauricemoss_ has joined #baserock09:29
pedroalvarezfranred: you could have sent the patch using the same change ID (git upgrade)10:01
franredpedroalvarez, I though that sending with the same topic it will rewrite the previous one... now I know I can use the same ID - thanks10:02
jjardonweston system built without problem in armv7 as well, time to upgrade to GCC 5.1? :) https://gerrit.baserock.org/#/c/462/110:04
franredjjardon, I've tested git 2.3.7 so you can abandon 2.3.5 patch ;-)10:04
franredjjardon, https://gerrit.baserock.org/#/c/484/10:05
jjardonfranred: nice!, next time rebase and submit again instead open a new change!10:06
franredjjardon, ok!!10:06
Kinnisonfranred: in addition to lorry, things which interface to git on the trove include gitano and the morph cache server10:25
franredKinnison, aham, can we create tests for checking that these interfaces do not break trove when we update git?10:28
KinnisonThe best test is to instantiate a trove, let it populate, and do a system build against it with a morph whose local caches are not populated10:29
KinnisonThe git server does have some tests but its test suite is vastly incomplete10:30
* Kinnison is also unsure if we run that suite (which ought to work during build, providing yarn, ssh etc are available)10:30
franredKinnison, ok, I will set up a trove to test it, but this is a very time consuming way to test that we can upgrade git...10:32
KinnisonAlso you should probably verify that the new git works against gerrit10:33
Kinnisonsince gerrit's internals are special10:33
pedroalvarezfranred giving up in 510:33
pedroalvarez410:33
pedroalvarez310:33
franredKinnison, I've tested gerrit yesterday, I've sent the patch to fix the morph check failure from the new VM :)10:34
Kinnisonfranred: sounds good10:34
Kinnisonso just trove to validate :)10:34
franredKinnison, hehe, I think that is not an easy task ;-)10:35
pedroalvarezit should be! :)10:36
Kinnisonfranred: it should be easy, just perhaps wallclock time consuming10:37
Kinnisonfranred: just deploy a trove, let it populate, and run some builds against it10:37
Kinnisonmost of that is waiting10:37
* pedroalvarez is making a video about deploying openstack on baserock to hardware using pxeboot.write , and then deploying a trove and a devel system to it10:38
franredbuild trove, deploy it and configure trove, wait until populate, change a system to point to that trove ... and build something from it...10:38
pedroalvarezbelieve me, deploying the trove is one of the easier parts of the video10:38
franredit sounds very time consuming10:38
Kinnisonfranred: Yes, but mostly wallclock time, not your brain time10:39
Kinnisonfranred: are you anxious that this patch should be merged very soon?10:39
franredKinnison, no, not really, I prefer that it does not break anything10:40
*** DavePage_ has joined #baserock11:04
*** straycat has quit IRC11:28
*** petefoth has quit IRC11:36
richard_mawHi, I've got a patch to add a `morph anchor` command, that pushes branches to the trove to ensure commits that are needed to build are not lost. https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/morph+branch:master+topic:morph-anchor is the gerrit topic.11:40
richard_mawIt's 7 patches long, but 5 of them are only a couple of lines each11:41
jjardonHi ssam2 ! about https://gerrit.baserock.org/#/c/433/ : I agree with you, but, shouldn't we do the same every time a new extension is introduced in morph as well?11:41
franredI want to move pexpect out from cxmanage and openstack-services strata...it is a python package so even I can move it to python-core, python-common or python-tools... but cxmanage does not have any of these strata as build dependecy nor in the system11:41
richard_mawI'm aware of cases I need to test for and possibly bugfix for the command itself, but I thought I'd send the series now, as its basic functionality works, and I'd like feedback.11:42
richard_mawbtw, the point of `morph anchor` would be to allow reproducibility of a system even if upstream decided to delete those commits11:43
richard_mawjjardon: ^ means that if we only care about reproducibility of releases, we may be able to just use the tag name as the ref11:45
jjardon\o/11:46
richard_mawdon't celebrate yet, we haven't yet decided that only releases are important for reproducibility11:46
jjardon:) sure, but at least we now have the tooling to make the decision possible11:47
richard_mawbut it does mean that in the case of upstream discarding commits, you don't need to grobble around in the repo caches of everyone who has built that system to be able to resurrect the commit11:47
jjardonfranred: Id use python-common11:57
franredjjardon, and add python-common to cxmanage? it would add a lot of python packages not required by cxmanage system11:58
radiofreejjardon: did the gcc 5.1 on arm build work?11:58
jjardonradiofree: yes11:58
ssam2jjardon: yes, every time we make a change that means the last released version of Morph can't build 'master' of definitions we need to wait to merge it until we have done a release11:58
ssam2otherwise we get in situations where people have to hack Morph into working just to be able to upgrade11:59
*** straycat has joined #baserock12:00
radiofreejjardon: nice!12:01
ratmice__richard_maw: an escape hatch allowing history rewrite, for unfortunate 'legal reasons'?12:02
jjardonssam2: ok, IIRC we have introduced and use several extensions in this cycle, so I guess we have to do better in the next one12:04
radiofreeis there a quick way of adding a change-id to an existing set of commits?12:05
richard_mawratmice__: it makes reproducibility possible if upstream had to do a rewrite, but odds are if that happens you're not supposed to have the anchor refs, so you may have to do a point release with the rewritten history and remove the anchors for the release you have to drop12:06
richard_mawradiofree: add the hook and do a git rebase -i and pick reword12:06
radiofreeah, so reword on each commit is sufficient?12:06
radiofreerichard_maw: thanks12:07
ratmice__ssam2: in theory a release could contain a placeholder morph package, upon release of the next delta of baserock release an update to the previous system which turns the placeholder into a version of morph capable of building the delta12:07
ratmice__that might at least get rid of the 'hack morph into working' into a well defined process12:08
jjardonfranred: yeah :( the only solution for that is to create its own stratum :/12:08
radiofreethe "contributing" wiki page is excellent! thanks to whoever wrote that12:21
*** a1exhughe5 has quit IRC12:31
*** sherm_ has quit IRC12:34
*** a1exhughe5 has joined #baserock12:43
*** sherm_ has joined #baserock12:48
jjardonssam2:  hey, when I try to add you as a reviewer, I get this error: "Sam Thursfield <sam.thursfield@codethink.co.uk> does not identify a registered user or group"13:05
jjardon(It doesnt happen with others)13:06
ssam2weird, i don't know why13:11
jjardonssam2: anyway, this is the patch Id like you to take a look when you have some time: https://gerrit.baserock.org/#/c/499/13:15
jjardonradiofree: thanks for the review! I guess you agree with https://gerrit.baserock.org/#/c/461/ as well?13:19
radiofreeyes13:23
*** Albert_ has quit IRC13:28
*** Albert_ has joined #baserock13:33
ssam2jjardon: that will break the next release13:43
ssam2Morph from 15.17-rc doesn't understand version 3 so won't be able to build it13:43
ssam2we need to make a release with Morph that understands version 3, *then* bump the version of our reference definitions13:43
KinnisonI continue to worry that we're incrementing the version number while still not knowing what the current behaviour truly is13:44
ssam2it could be merged to a branch while we wait for that to happen13:44
jjardonssam2: https://gerrit.baserock.org/#/c/499/ is the patch to add support to version 3 in morph :)13:44
ssam2Kinnison: what can we do to remove your worries?13:44
ssam2jjardon: ah, ok. I thought it was a patch for definitions, not morph :)13:44
Kinnisonssam2: sadly the only thing to do is to invest the time to do the documentation13:44
jjardonssam2: this is the one for definitions: https://gerrit.baserock.org/#/c/433/13:45
ssam2Kinnison: in that case, I share your worries.13:45
richard_maw\o/ gertty shows dependency trees like mutt!13:45
ssam2jjardon: could you update http://wiki.baserock.org/definitions/historical/ with V2 and V3 ?13:48
jjardonssam2: sure13:49
radiofreejjardon: how do i add a comment in yaml?13:58
Kinnisonyaml comments are prefixed by #13:59
paulsherwoodradiofree: eg http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/build-essential/stage1-gcc.morph14:00
radiofreeta14:00
* radiofree wonders if adding a comment forces a rebuild14:00
paulsherwoodradiofree: do you want to force a rebuild?14:01
radiofreeno14:02
radiofree"echo hello" is my goto for force-rebuilds14:02
*** zoli___ has quit IRC14:03
paulsherwood:)14:03
persiagertty is workig now?  What was the change that was required?14:04
Kinnisonpersia: proper https IIRC14:05
persiaAh, that would do it.14:05
Kinnisonpersia: and enabling some config or other14:05
radiofreei thought pedroalvarez installed a module?14:05
radiofreejjardon: http://fpaste.org/216739/30316313/ is ok?14:05
jjardonradiofree: sure14:06
radiofreeyou're a tough man to please jjardon, resubmitted14:09
pedroalvarezpersia: proper https and download-commands plugin14:13
persiaAh, the plugin.  That was the confusing bit.  Thanks.14:13
* radiofree will try gerrty14:15
radiofrees/gerrty/gertty/14:15
radiofreenowster: i think you looked into an issue where baserock would dirty the kernel trees?14:18
nowsteryes14:18
radiofreewhat was the cause?14:18
richard_mawradiofree: adding comments doesn't cause a reubild14:19
richard_mawor a rebuild14:19
nowstergit tree in inconsistent state. Cure was to run "git status" before the make xxxx_defconfig14:19
Kinnisonnowster: bleurgh14:20
radiofree:\14:21
jjardonssam2: done, maybe you can take a look to check everything is ok14:30
* radiofree thinks system-version-manager is the best thing ever14:34
jjardonradiofree: whats that?14:38
richard_mawradiofree: it'll be better when I have the time to do live atomic update14:38
*** bashrc_ has quit IRC14:41
*** bashrc_ has joined #baserock14:42
pedroalvarezradiofree: thanks for the compliment14:45
pedroalvarezwell, it has many authors now14:46
paulsherwoodi saw this question and wondered if anyone here might know 'Anyone know how Thrift is implementing their interface-to-C mapping?' ?14:47
*** zoli__ has joined #baserock14:47
paulsherwood(from http://lists.genivi.org/pipermail/genivi-ipc/2015-April/000348.html) - i appreciate it's off-topic here, though14:48
ssam2jjardon: there are two ways to do this I guess14:49
ssam2jjardon: one is to create a http://wiki.baserock.org/definitions-V3/, http://wiki.baserock.org/definitions-V4/, http://wiki.baserock.org/definitions-V5/ etc.14:50
ssam2I prefer the approach of having http://wiki.baserock.org/definitions/current/  http://wiki.baserock.org/definitions/historical/  and   http://wiki.baserock.org/definitions/planned/14:50
ssam2I think will be annoying having the format of definitions spread over N wiki pages14:50
paulsherwoodssam2: +114:50
jjardonyeah, me too, I will move them14:51
ssam2cool14:51
jjardonjonathanmaw: thanks for fixing logind/pam!15:01
radiofreedoes this mean gnome will work now?!15:01
* Kinnison thinks that to have a competent description of the definitions format in a single wiki page will be horrendously unpleasant15:02
jjardonmaybe :)15:02
nowsterwho are the best people to request reviews of a lorry addition?15:03
paulsherwoodus! :)15:03
radiofreeif you're talking about https://gerrit.baserock.org/#/c/501/ i've already +1ed it15:03
nowsteroh! ta, radiofree :)15:04
paulsherwoodmerged15:04
nowsterthat was quick!15:04
paulsherwood:-)15:04
paulsherwoodbaserockers... could/should gerrit notify the list of patches for review? since gerrit i feel out of touch15:05
Kinnisongerrit's notification format is.... unpleasant15:06
SotKpaulsherwood: you can set it to email you if a new patch is submitted15:06
paulsherwoodSotK: wouldn't list members prefer to know in general (ie not just me)? it seems we took this info away without consensus15:09
*** wschaller has joined #baserock15:09
ssam2we could set up a second list for notifications from Gerrit, maybe15:10
* Kinnison would be fine with a second list15:10
* Kinnison wouldn't like to see patch notifications going to -dev given half the reason for gerrit was to get patch discussion *off* the list15:10
* richard_maw would be fine with it going to the current list, provided it is just merges and reverts15:10
ssam2people have complained about how high-traffic baserock-dev was when all patches went through it, so it seems like it'd be good to not send lots of generated emails from gerrit to baserock-dev15:10
KinnisonIf we want another list @baserock.org, please leave me a /msg with the desired name and initial list owner and I'll sort it out later15:11
* Kinnison has to run away now to get his car back15:11
DavePage_This is possibly a philosophical question, but if you're deploying a web app server image with Baserock there are basically three components - (a) the underlying OS, web server and interpreter; (b) the web application code; and (c) the data the web app operates on. Do people think it makes most sense to use the Baserock tooling to create reproducible builds of a, a&b, or a&b&c?15:13
jjardonpaulsherwood: you can select the project you want to watch (and in what detail) here: https://gerrit.baserock.org/#/settings/projects15:14
richard_mawjjardon: notably there is no option for *no* e-mail15:14
jjardonrichard_maw: Not sure I understood you sentence correctly, but I think you achieve that if you uncheck all the boxes?15:17
paulsherwoodDavePage_: depends on the app... what kind of 'data' for example?15:17
richard_mawjjardon: I have no boxes to tick, I never selected to watch any projects, but I get e-mail from gerrit about reviews all the time15:18
DavePage_paulsherwood: As an example, a wiki instance.15:18
persiaDavePage_: I'd do a&b&c, and use different sets of strata for each.  This would give me confidence that I could adjust the strata for c, without changing a&b, or the strata for a, without changing b&c, safely.  If a change in a is low enough to require a rebuild of b or c, morph will manage this for you, but your artifacts will differ, so you can know (but never have to ship an A that provides a different ABI than your B expects, etc.)15:19
* persia adds to the chorus for having a baserock-changes@ or similar list, rather than causing non-patch discussions to be lost in baserock-dev again.15:20
jmacsa&b definitely. C gets interesting - the data would be coming from some existing external source, not git, wouldn't it?15:20
DavePage_Unless you start keeping verbose MySQL dumps in git, I guess15:20
DavePage_Which sounds like it'd get rapidly painful.15:20
rdalei could see how you could define a specific database schema for 'c', and configuration, but not the data itself15:21
paulsherwoodDavePage_: if the wiki is git-backed, a+b+c imo15:21
jjardonrichard_maw: oh, probably because you are one of the reviewers. Not sure you can deactivate that15:21
DavePage_paulsherwood: And if it isn't?15:21
jmacsYes, I suppose you could just treat the wiki's repository as a component and grab the latest version of it15:22
jmacsDump existing MySQL database, then import it as tarball, rather than a repository15:23
DavePage_And then rebuild the whole image when the web app code (b) changes?15:23
SotKDavePage_: yes, but assuming you don't lose the cached artifacts only the web app code and anything which depends on it will actually be rebuilt15:25
DavePage_*nods*15:26
*** jonathanmaw has quit IRC15:26
DavePage_I'm just trying to groupthink what "best practice" is here15:26
gary_perkinsIn a recent project, the web-app code was just ruby, so nothing to buid as such. It might as well be just HTML.15:26
DavePage_Well, building can just be copying files into the right place :)15:26
DavePage_See `man install` for details :)15:27
gary_perkinsSeems a lot easier to maintain the web-app code separately in a differnt repo and have the web-system pull from it15:27
DavePage_Or just lorry it from that different repo?15:27
ssam2DavePage_: in practice, I've found that it's much quicker to develop the web application from a git checkout on the target15:29
jjardoncan I have a quick review of (use latest morph in definitions) https://gerrit.baserock.org/#/c/485/15:30
gary_perkinsDavePage_: That sounds like it could work, but I'm open to suggestions. I've never actully setup lorrying myself.15:30
DavePage_ssam2: Yeah, I'm sure it's quicker, but that doesn't mean it's necessarily right :) Particularly if you're not actively developing, but providing Baserock systems using an upstream.15:30
ssam2DavePage: and so if the web application is reasonably self-contained, I'd recommend deploying the base OS with Baserock, then deploying the web-app after the fact with an Ansible script that you run after deployment15:30
ssam2if the Ansible script is commited to Git, then the process is just as reproducible as if you used Morph, but it makes it much easier to hack on the application if you need to15:31
ssam2when you're done hacking, update the ansible script and rerun it, and your running system is in the same state as if you had redeployed it15:31
ssam2(modulo any bugs in Ansible)15:31
ssam2if you're not actively developing then there probably isn't any advantage to that approach15:32
DavePage_ssam2: And your way does assume the upstream does't disappear...15:34
* radiofree wonders what mason is up to these days15:34
ssam2DavePage_: in my case, I was the upstream, so was pretty confident of that :)15:34
DavePage_ssam2: Yes, that won't always be the case though :)15:35
ssam2tiagogomes: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/commit/morphlib/exts/sysroot.write?id=807e6a90876c5469d2421a47649d15f06e94ca36 has broken sysroot.write for some users15:36
ssam2who are using a cluster like this: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/clusters/sdk-example-cluster.morph15:36
ssam2the errors we get are stuff like "mv: can't rename '/src/tmp/deployments/.../sbin': Directory not empty"15:37
ssam2seems that before, the sdk system contained a bunch of toolchain stuff in /usr/armv7lhf.../sys-root which the sysroot.write extension deleted15:37
ssam2but now that sysroot.write doesn't delete that directory, we get errors moving stuff into place15:38
ssam2i'm struggling to understand why things work this way15:38
ssam2in particular I'm confused why we had armv7lhf-cross-toolchain stratum installing a bunch of stuff into /usr/armv7lhf../sysroot/ that was then deleted again15:41
radiofreepedroalvarez: what's mason doing?15:44
ssam2we have worked around it by changing 'mv' to 'cp', but it seems that something more fundamental is wrong with this approach...15:46
ssam2i'll send a patch to change sysroot.write and we can discuss further what's actually going on with it :)15:46
tiagogomesssam2 IIRC, the reason why I added code to force the directory to not exist was because of you set a sysroot=/ you would delete your host system files. But if we run the configuration extension in a chroot I guess it is safe15:47
ssam2ah, ok15:47
ssam2it's still annoying to delete your whole chroot... it's kind of a problem with .configure and .write extensions in general15:48
ssam2thanks for the explaination, makes sense anyway15:48
radiofreenowster: git status worked for me as well15:49
radiofreex86 images don't seem to suffer from this15:49
radiofreegcc 5.1!15:50
*** a1exhughe5 has quit IRC15:50
ssam2I've sent https://gerrit.baserock.org/#/c/502/ about the sysroot.write issue. would like to investigate more but don't have time right now15:54
*** ssam2 has quit IRC15:56
*** mariaderidder has quit IRC15:59
persiaI missed the good bit, but I'm actively against using a local checkout of code on production systems.16:00
persiaOne should develop it on a development system: running `morph update` to update a target with the new changes in the updated git repo is relatively easy and smooth.16:01
* persia has seen too many cases where the production checkout was dirty, causing all sorts of headaches when troubleshooting production issues16:01
jjardonpedroalvarez: Do you know what was the last commit in definitions mason built correctly?16:11
* jjardon want to use the cache instead build master16:11
rdalecan gerrit patches for different repos have the same topic name?16:14
paulsherwoodrdale: only one way to find out16:20
rdaleyes, i'll try it - i have two related patches for different repos, and it would be nice to be able to tie them together16:20
paulsherwoodam i the only person that thinks extensions might be better in definitions, rather than morphlib?16:21
* radiofree uses baserock on a t51016:23
radiofreei think i'll put a weston system on here16:23
persiapaulsherwood: I don't believe so: I seem to recall someone saying "when we move all the extensions to definitions" at some point in the past.16:25
persiaThat said, I don't really like the mixing of declaratove definition with executable code.16:25
robtaylorpersia: its not too bad as long as you treat the executable  code as 'data' whose use is defined declaritively16:27
robtaylorpaulsherwood: i belive at least me and jjardon also agree that extensions should go in definitions16:29
jjardonradiofree: NICE!!16:29
radiofreemandatory video http://seriousinternetbusiness.com/james/baserock-thinkpad.mp416:31
*** mauricemoss_ has quit IRC16:31
pedroalvarezradiofree: cool16:35
paulsherwoodall your thinkpad r belong to us :-)16:36
paulsherwoodrobtaylor: :-)16:36
pedroalvarezradiofree: sorry, I was busy before, mason is building things :)16:45
pedroalvarezwe had some problems with it yesterday16:46
pedroalvarezjjardon: d4934769e522137f872cece4e86002cfbb45f62d16:46
radiofreemason is red16:46
pedroalvarezjjardon: but it has to have some new cache16:46
pedroalvarezradiofree: yes yes I know16:46
pedroalvareznothing to worry about16:46
jjardonpedroalvarez: thanks!16:46
radiofreetrying to read the log crashed my firefox :(16:47
pedroalvarezhah16:47
pedroalvarezoh, I think mason now needs a newer version of morph16:47
*** Krin has quit IRC16:54
pedroalvarezurgh... I think I upgraded mason to a broken version of morph: https://mason-x86-64.baserock.org/log/e6befc339259a9d45295ae25e575a847033ac420--2015-04-29%2017:12:01.log17:15
radiofree:/17:16
pedroalvarezDon't have time to investigate now, so I moved to a previous version17:17
radiofreecompiling this fedora kernel takes aaaaaages17:19
radiofreeso many modules...17:19
*** De|ta_ has joined #baserock17:22
*** radiofree is now known as Radiofree17:24
*** Radiofree is now known as radiofree17:24
*** wschaller has quit IRC17:30
jjardonCan I have a quick review for: https://gerrit.baserock.org/#/c/529/ (use hash instead tag)17:31
franredjjardon, done17:36
jjardoncheers17:36
*** franred has quit IRC17:39
tlsabenucrush17:58
tlsawrong window!17:58
*** lachlanmackenzie has quit IRC18:31
*** sherm_ has quit IRC20:02
*** gary_perkins has quit IRC20:23
jjardonmmm, seems the btrfs-progs repo has not been updated for the last 3 months: http://git.baserock.org/cgi-bin/cgit.cgi/delta/btrfs-progs.git/20:23
jjardoncurrent upstream: http://git.kernel.org/cgit/linux/kernel/git/mason/btrfs-progs.git20:23
*** flatmush has quit IRC20:24
*** Albert_ has quit IRC20:41
pedroalvarezjjardon: is not pointing to the right one?20:51
jjardonpedroalvarez: the lorry is pointing to the correct one20:52
pedroalvarezBTW, we had some issues the last time that we upgraded it20:52
pedroalvarezjjardon: Ok, I'll take a look20:52
* jjardon thinks found a bug in the install-files extension. will submit a patch21:55
* jjardon files https://gerrit.baserock.org/#/c/530/22:03
*** zoli__ has quit IRC22:11
pedroalvarezjjardon: btrfs-progs was OK, I think23:00

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