IRC logs for #baserock for Tuesday, 2015-06-09

*** pacon has joined #baserock00:45
*** rdale_ has joined #baserock02:30
*** rdale has quit IRC02:34
*** jjardon has quit IRC03:07
*** zoli__ has joined #baserock05:08
*** zoli__ has quit IRC05:16
*** pacon has quit IRC05:17
*** sambishop has quit IRC05:26
*** jjardon has joined #baserock06:09
*** zoli__ has joined #baserock06:22
straycatwow #perl is hard work07:23
paulsherwoodindeed :)07:26
paulsherwoodah, you mean the channel, not the language?07:26
*** gary_perkins has joined #baserock07:34
*** Stanto has joined #baserock07:36
straycatpaulsherwood, yes the channel :)07:39
*** mariaderidder has joined #baserock07:42
*** edcragg has joined #baserock07:46
KinnisonLarge IRC channels are hard work07:51
Kinnisons'one reason I only tend to contribute to smaller projects07:51
paulsherwoodKinnison: interesting. i had not realized that. how dumb am i?!07:52
KinnisonNo idea, but your shift-key seems to be slightly broken07:53
paulsherwoodyou mean, missing caps at the start of sentences, i assume :)07:56
KinnisonYou, once again, assume incorrectly.  I wonder how long it'll take you to work it out? :-D07:57
paulsherwoodoh dear, that's a puzzler. is there a prize?07:58
paulsherwoods/YBD/ybd/ ?07:58
KinnisonA reduction in my ire, should you get it right; perhaps.07:58
paulsherwoodi give up, already.07:59
KinnisonYour brother has a similar issue, but I managed to correct him on it.08:00
*** mariaderidder has quit IRC08:05
*** sambishop has joined #baserock08:06
*** jonathanmaw has joined #baserock08:14
straycatSotK, I don't exactly get what you're on about with I'm not sure why you think prefixing PYTHONPATH with a colon is a good idea08:20
SotKI guess I can just set PYTHONPATH to $extensions_dir rather than trying to append $extensions_dir to the existing PYTHONPATH?08:24
KinnisonI'd much rather you appended it08:25
Kinnisonor pre-pended it if you're worried about needing to override stuff08:25
SotKstraycat: then what should I do?08:27
straycatif 'PYTHONPATH' in final_env: final_env['PYTHONPATH'] += ':%s' % exstensions_dir else: final_env['PYTHONPATH'] = extensions_dir ... or something?08:27
SotKsure, that just seemed messier and as far as I know having PYTHONPATH start with ':' doesn't harm anything, though I could be wrong08:29
*** edcragg has quit IRC08:30
pedroalvarezheh, so max_connections=100 in postgresql is not enough for openstack08:31
Kinnisonpedroalvarez: erk08:31
Kinnisonpedroalvarez: Surely each API needs 1 connection and that's it08:32
pedroalvarezKinnison: I hope that's true..
KinnisonHoly batshit insanity, Stackman!08:33
straycatyou could always final_env['PYTHONPATH'] = ''.join((pythonpath, ((':%s' if 'PYTHONPATH' in final_env else '%s') % extensions_dir)) ? :308:34
* Kinnison is never quite happy with python's use of if/else as ternary operator08:35
straycati don't know i quite like it08:37
straycatit's certainly more readable to someone unfamiliar with the language08:37
*** zoli__ has quit IRC08:42
*** mariaderidder has joined #baserock08:47
*** ssam2 has joined #baserock08:56
*** ChanServ sets mode: +v ssam208:56
straycatZara, I made a bit of a hash of the change history on your import change, sorry, next time I won't use the web ui to update commit messages >.>08:59
KinnisonWeb UI :(08:59
straycatit needs more vim :(09:00
Kinnisonand vigor09:00
*** zoli__ has joined #baserock09:02
richard_mawstraycat: let's have multiple lines for readability :-)09:10
richard_mawif 'PYTHONPATH' not in os.environ:\n    final_env['PYTHONPATH'] = extensions_dir\nelse:\n    final_env['PYTHONPATH'] = ':'.join((os.environ['PYTHONPATH'], extensions_dir))09:12
*** edcragg has joined #baserock09:16
*** lachlanmackenzie has joined #baserock09:22
straycatrichard_maw, sure :)09:23
radiofree2015-06-09 00:52:49 [build-system-armv8l64] Elapsed time 03:13:3909:28
paulsherwoodradiofree: on mooshot, or mustang?09:36
paulsherwood(or something else?09:36
paulsherwoodaha! w00t!09:36
radiofreeapart from that gcc hitch it went smoothly09:36
radiofree(you have to do something similar with gcc as you do with fhs-dirs, i.e when it fails, start the build again, then it should work)09:36
Kinnisonthat's "not good"(tm)09:37
paulsherwoodradiofree: i think i'll remove the fork, and settle for the slowdown, unless someone has a better idea?09:37
paulsherwoodKinnison: i fork to remove current sandbox, while starting work on next chunk...09:37
KinnisonThat seems.... risky09:37
paulsherwoodit clearly is09:38
KinnisonRemoval of the sandbox shouldn't be that expensive09:38
radiofree+1 remove fork09:38
paulsherwoodbut it saves a significant amount of time on my machine09:38
paulsherwood(eg a few mins over a whole build)09:38
paulsherwoodi'll remove the fork09:38
KinnisonStart by removing the / then /foo.inst/ and then the rest09:38
radiofreei think a few mins is better than the build failing when you're asleep09:38
KinnisonOptimising things like sandbox removal time seems fairly daft IMO09:39
rjekMove it out of the way, unlink it in the background09:39
Kinnisonthe issue is that he's doing background unlinking and the result is failed builds due to disk space issues presumably09:40
SotKthe builds fail trying to mount a non-existent directory if this is the issue I think it is09:41
Kinnisonwhatever it is, it's madness to background the unlinking IMO09:41
paulsherwoodit's not in the way. it's that the sanbox command tries to lock it iiuc09:41
Kinnisonit's not expensive09:41
paulsherwoodanyway, i've pushed the fix. radiofree would you mind re-running from clean on that mustang? i'd really like to know how much time the full process takes on that board09:42
paulsherwoodKinnison: ybd is a series of experiments. this one taught me something :-)09:42
straycatssam2, think the sandboxlib could be useful for the import tool, given we're executing package code in some cases?09:46
radiofreepaulsherwood: ok09:47
Zarastraycat: nw. I'm about to push some changes, so sorry in advance if the commit message goes weird for a bit and there's noise09:50
ssam2straycat: definitely... good thinking09:51
straycatZara, ahh okay, maybe download the new change set and squash your changes into that?09:51
straycatssam2, cool09:52
SotKstraycat: I don't understand, what needs changing in the commit message?09:52
Zarastraycat: if I do git rebase -i and copy the current commit message on gerrit with line breaks, will that work out the same? (given that that's what I just did but I haven't pushed it yet, so there's still time :P)09:53
ssam2perryl: do you fancy putting together a public page somewhere for the bit-for-bit work so we can link to it from ?09:53
straycat"Version 6 allows deployment extensions to depend only on code which is also in definitions and the Python standard library." except I could set PYTHONPATH before running morph deploy?09:53
ssam2perryl: nothing complex, can be a storyboard story, or a wiki page, or anything09:53
richard_mawSotK: perhaps rolling the PYTHONPATH change into version 5 would be more appropriate than adding a version 609:54
perrylssam2: sure, i'll try and get something written down today if possible09:54
straycatZara, sure that'd be fine, just thought it might be slightly more error prone, up to you :)09:55
SotKstraycat: I discussed the "set PYTHONPATH when running morph deploy" change with ssam2 elsewhere and he pointed out that it is still a break in compatibility (even though a work aroundis possible)09:55
SotKrichard_maw: I'd be fine with that09:55
richard_mawSotK: cool. Possibly the best way to do this would be to roll both into one series09:56
paulsherwoodjonathanmaw, radiofree - please note jeremiah's email on GENIVI patch review - would either or both of you care to comment?09:56
paulsherwood(on the list)09:56
straycatSotK, okay, not sure I follow, i'm just saying the commit message doesn't match my understanding, there's nothing in that change that restricts extensions to using only code in the extensions dir and the python standard library09:56
radiofreewell i already replied to him in the other thread09:57
radiofreewill do it later i'm in the middle of something atm09:57
richard_mawSotK: shall I bring your patch into my series?09:57
SotKrichard_maw: sure09:57
paulsherwoodradiofree: ack09:59
SotKstraycat: maybe it needs rewording then, I didn't mean to imply restriction, just that they could now use code which is in the extensions dir (I have a branch which moves into there in the same way as I moved the extensions, and further patches to make the extensions depend on just code in there rather than morphlib and cliapp)09:59
richard_mawSotK: don't you need to conditionalise your code on the version?10:00
Zara(huh, that's weird, I changed the error message but it seems it wasn't saved? gah, gimme a sec)10:00
SotKrichard_maw: why would I need to?10:01
paulsherwoodSotK: iiuc ybd manages to avoid having to think about definitions version so far... will that still be the case after this?10:01
richard_mawSotK: I needed to for my change, I'm just trying to work out for myself whether you need to do so as well, and hoped you'd already thought about it and had an answer.10:02
richard_mawpaulsherwood: AIUI ybd manages that by only caring about needing to build the latest definitions anyway10:02
ssam2paulsherwood: it can ignore the versioning information forever. but users may report bugs that turn out to be due to version mismatches, and you might waste time working out that's what they are10:02
paulsherwoodrichard_maw: correct :)10:02
ssam2it might be better to keep track of which version YBD is tested against10:03
paulsherwoodssam2: that's the approach for the moment,  but it may not scale, of course :)10:03
SotKI figured that the change shouldn't affect anything in older versions10:03
paulsherwoodssam2: yes, or have ybd and definitions in the same repo for example. i wonder what other approaches are possible. neither of these seems *ideal*10:04
SotK(except it would put the definitions repo in PYTHONPATH if being run on defintions from before the extensions were moved)10:04
paulsherwoodgood point, SotK10:05
richard_mawSotK: which theoretically could cause issues, but I'll accept that it's vanishingly unlikely10:05
richard_mawSotK: I'd be happier with it explicitly checking, but I'll accept it not doing so. I'll amend the commit message to mention that this is version 5 rather than 6.10:08
SotKrichard_maw: thanks10:09
paulsherwoodrichard_maw: am i right in thinking that your patches addressed the binary-strip wishlist item at ?10:12
richard_mawpaulsherwood: not entirely. The stripped symbols are currently included in the result system artifact by default, while you wanted them excluded by default.10:13
paulsherwoodah, ok. how would one cause them to be excluded?10:14
richard_mawFor morph I was hoping to amend the artifact splitting rules, and extend the logic so that the split rules for an artifact can declare whether they are included by default.10:14
kejiahu_build of syslinux fails on armv7 using YBD, seems the target platform parameter hasn't been passed to it correctly.
paulsherwoodradiofree: have you seen that before? ^^10:15
paulsherwoodrichard_maw: and for ybd?10:15
richard_mawpaulsherwood: you could just remove everything from /usr/lib/debug10:15
SotKpaulsherwood: why do ybd system artifacts contain /foo-system.inst and /
richard_mawsince you don't support artifact splitting in any meaningful way currently anyway10:15
paulsherwoodSotK: i don't know - iirc Kinnison worked on the system-level processing. i can investigate, though... but not right now10:16
richard_mawSotK: because there's no special case for system artifacts, ybd does all the set up, but sets DESTDIR=/, so the whole thing gets tarred up10:17
paulsherwoodthere is some special-casing for system now iiuc - Kinnison tweaked it because system-integration-commands are different i think10:18
* paulsherwood would prefer no special case, but this may be unreasonable10:18
paulsherwoodkejiahu_: what commandline did you use for ybd, and what are you running on?10:22
paulsherwoods/what are/what hardware are/10:22
radiofreekejiahu_: don't build syslinux on arm10:22
radiofree(it's only needed for x86010:23
kejiahu_paulsherwood: I was building rdale's branch for openwrt on jetson.10:24
kejiahu_radiofree: so syslinux shouldn't be included in the definition at all?10:24
radiofreekejiahu_: not for arm10:25
paulsherwoodright, so this is the issue... rdale's branch has lots of stuff that isn't required for openWRt (eg systemd)10:25
SotKpaulsherwood: why does ybd create /dev/null in its sandbox?10:25
rdale_no it shouldn't have10:26
paulsherwoodybd parses all definitions... and finds multiple build-depeds for some things, and chooses the wrong set in some cases10:26
kejiahu_radiofree: really? as far as I can remember, it seems pxelinux can be used on moonshot to boot it?10:26
radiofreethat usesd u-boots implementation10:27
richard_mawkejiahu_: It uses something that quacks like pxelinux, but ducks don't run on ARM.10:27
radiofreekejiahu_: syslinux is only needed for x86, you can see this if you git grep "syslinux"10:27
kejiahu_radiofree, richard_maw : oh, right. thanks10:27
radiofreeby the looks of it you're trying to build the x86 bsp?10:27
paulsherwoodthing is untangling why ybd chooses wrong sometimes has proved to be beyond me so far. the issue is if you want to add to it or suggest solutions10:28
rjekYou probably need to sort everything10:29
rjekOr are you already doing that?10:29
rjekie, enumerate whole directory, sort, start from first entry10:29
paulsherwoodi'd prefer to remove all the warnings by forcing that a given checkout of definitions can't have multiple instances of foo chunk declared, but that might not work in practice10:29
rdale_trying to prevent foo chunk being defined in more than one stratum?10:30
paulsherwoodrjek: it's not that. it's that foo chunk is declared to depend on bar and bip strata, while alternatively to depend on bobble and bunx10:30
paulsherwoodrjek: i'd prefer that, but i don't think it fits all use-cases10:31
straycatZara, biff,10:31
ssam2because build depends are defined per-strata10:31
paulsherwoodssam2: correct10:31
straycatZara, (alternative suggestion)10:31
kejiahu_radiofree: no. I was building from a definition modified from x86 system, and i didn't remove the syslinux from it. so I need to replace syslinux by u-boot in that case?10:31
ssam2as with many proposed changes to the definitions format, the first step to changing that is probably to produce a migration script that can show us what the current definitions repo would look like if we made that change10:32
radiofreekejiahu_: see the jeston-bsp10:32
kejiahu_radiofree: thanks10:32
radiofreeyou're just checking to see if this builds on arm right?10:32
ssam2thanks to rdale's discovery of ruamel.yaml that's no longer an insurmountable task, I think10:32
radiofreeyou can probably just remove the bsp entirely then, if you're not actually going to use it for anything10:32
paulsherwoodssam2: yup. but no point in going too far down the road if no-one likes the expected destination10:32
ssam2paulsherwood: exactly. I think a migration script is the shorted path to working out whether we like the destination or not10:33
ssam2my concerns are pretty much entirely "will definitions.git be easier or harder to work with after this change"10:33
radiofreekejiahu_: if you want to test it, then just use bsp-jetson
paulsherwoodthe general problem is that we clearly need definition contains n clusters of m systems, and each system may have its own special requirements for foo chunk (including having a different version of foo)10:34
radiofree(instead of bsp-x86)10:34
paulsherwoodssam2: fair10:34
paulsherwoodssam2: i think rdale_'s discovery of the parse thing is worth looking at, i just haven't got around to it10:35
kejiahu_radiofree: ideally, I'd want to deploy it on something to verify it works, yes, I'll use that one. thanks10:35
ssam2paulsherwood: it doesn't *have* to be you :) but for me, I think automated testing and integration is higher on my list of priorities than improving the definitions format10:36
paulsherwoodssam2: i agree, in fact i'd prefer it wasn't :-) but if i don't understand the approach, i'll probably end up grumpy later :)10:37
ssam2perryl: will definitely affect bit-for-bit reproducibility of systems !10:40
ssam2I wonder if the 'random.shuffle(dependencies)' in is a problem..10:41
ssam2certainly removing it might work around bug #2110:41
perrylis it building random extra components or is there some reason to it? i've also noticed erlang in /src/cache/ybd-artifacts10:42
ssam2i'm not really sure10:42
paulsherwoodnope, i'm entirely confident that the shuffling will not affect #21. i'm mostly confident it won't affect b4b either. if it does, something else is wrong10:44
SotKIt parses things in the order it finds them in the filesystem, and the first version of a thing parsed becomes the canonical version, so if it parses something with multiple definitions with the "wrong" defintion first, then it will try to build with the wrong definition AIUI10:44
radiofreekejiahu_: when you come to deploying please shout up, there's some important things you'll have to make sure to set on the deployment cluster10:44
ssam2paulsherwood, SotK: I see. I also see richard_maw has suggested a better workaround in bug #21 now10:44
kejiahu_radiofree: will do10:45
radiofreepaulsherwood: looks like that fixed the issue10:54
radiofree2015-06-09 10:50:41 [gcc] Elapsed time 00:12:0810:54
paulsherwoodkewl! :)10:54
radiofreenext arch.. ppc? :)10:55
paulsherwoodabsolutely :)10:55
paulsherwoodwe have some mips stuff to try, too10:55
paulsherwoodnowster: ^^ ?10:55
paulsherwoodcould you try building interesting definitions with latest ybd on mips at some point?10:56
paulsherwoodalso, i've never tried cross-bootstrap definitions.... i wonder what would happen with those?10:57
nowsterAt some point, yes. I doubt it'll be this week, though.10:57
nowsterDoes ybd do "cross bootstrap" builds?10:57
SotK`morph cross-bootstrap` does all kinds of magic to create the cross-bootstrap tarball I think11:02
SotKpaulsherwood: why does ybd create /dev/null in its sandbox?11:02
SotKI tried to use the tarfile module rather than calling `tar` when extracting system artifacts, but it broke because /dev/null was already there11:04
paulsherwoodSotK: you're asking the wrong person...11:05
paulsherwood6a4aca35 (Sam Thursfield     2015-06-08 18:34:42 +0100  63)         app.log(this, "Creating /dev/null inside sandbox")11:05
SotKpaulsherwood: "0ccf0afe (Paul Sherwood  2015-01-03 15:22:04 +0000 67)             call(['sudo', 'mknod', devnull, 'c', '1', '3'])"11:06
pedroalvarezgit-blame war begins11:06
SotKit was added in the commit which added as far as I can tell11:06
ssam2i don't remember doing that11:07
ssam2I remember adding the log message, but not the /dev/null creation11:07
Zarastraycat: I tried your alternative suggestion and it worked (with a little tweaking due to the npm view command being a bit fussy about its input) :)11:12
* SotK successfully deploys a system with subsystems11:31
SotKs/subsystems/a subsystem/11:31
* SotK notes also that the strip-gplv3.configure extension doesn't work with ybd, since it expects metadata files to be JSON11:32
*** a1exhughe5 has joined #baserock11:34
radiofreei hope the solution isn't to json the ybd metadata files11:48
* radiofree likes how easy they are to parse11:48
rdale_what format are they in?11:49
SotKrdale_: unformatted text I think11:49
straycatweirdly that's what cpan's done with its metadata11:52
straycatthey started out with yaml and then moved to json11:53
straycatZara, cool :)11:53
rdale_unformatted text isn't the same as yaml or json though11:53
radiofreeshouldn't it move to yaml eventually though11:54
* SotK thinks both ybd and morph should use yaml in the metadata files11:54
rdale_it's easy to convert json <==> yaml, but some random invented text format isn't11:55
pedroalvarezisn't that extension coupled to the build tool and how they generate the metadata files?11:56
pedroalvarez-*- SotK notes also that the strip-gplv3.configure extension doesn't work with ybd, since it expects metadata files to be JSON11:57
pedroalvarezwell, if the fact that the metadata files are not in json makes it crash, then I guess it depends on how the build tool generates these files11:59
pedroalvarezI'm not saying it depends on morphlib11:59
SotKah, I see what you are saying12:04
SotKI don't think thats a good thing, given the system definitions say it should be run on some systems (and that list can be used by any build tool)12:05
straycat"Sam Thursfield <> does not identify a registered user or group"12:06
* straycat throws a wooden spoon at gerrit12:06
straycatZara, biff, assuming 'latest' does what i guess it does then +112:07
* SotK sends a pull request12:08
Zarastraycat: should do (I tested it and it worked, anyway). :)12:09
straycatZara, hrm, as long as packagName@latest is equivalent to just passing in packageName then it's fine, if we're not sure about that then we should just pass in packageName (assuming that providing a packageName alone defaults to the latest version)12:11
paulsherwoodSotK: you say 'Building a cluster doesn't make sense' - what if it's not built?12:16
paulsherwoodrdale_: i reckon it would be pretty easy to make the manifest into yaml...
SotKpaulsherwood: building the actual cluster doesn't make sense though... what goes in a "cluster artifact"?12:18
paulsherwoodSotK: oh, yes. agreed. but does ybd still build the systems and subsystems, with your patches?12:19
rdale_paulsherwood: i don't mind if the manifest is either yaml or json, i only mind if it's neither12:19
SotKpaulsherwood: it does12:19
paulsherwoodSotK: merged! :)12:20
SotK\o/ thanks12:20
paulsherwoodrdale_: ack!12:20
* SotK likes how quick upstream is12:20
* paulsherwood does his best12:23
paulsherwooddownside is, upstream changes rapidly, which may be bad for some users/usecases12:23
straycatmaybe you should have a separate development branch if you plan on breaking things a lot12:25
paulsherwoodstraycat: that seems sensible... but then what if i break master?12:25
paulsherwood(ie what if something gets through?)12:26
paulsherwoodthis way, i'm not makign any promises i can't keep :-)12:26
paulsherwoodbut i take your point. am thinkgin about it12:26
paulsherwoodybd really needs ci, and cd12:26
Zarastraycat: yeah, it's the same.12:28
straycatssam2, i tried to add you to but couldn't12:29
straycatpaulsherwood, well it's never going to be perfect :)12:30
* paulsherwood runs the python-free, arch-free commandline '/src/ybd/ release/clusters.morph' for the first time12:30
paulsherwoodstraycat: i agree... but it's gonna be close :-)12:31
straycatZara, btw, one of the comments on 814 was a question :)12:32
straycatpaulsherwood, without a minimal test suite it might be difficult to know when master is broken12:32
paulsherwoodstraycat: yes, but in my worldview at the moment, definitions.git is my test-suite?12:33
paulsherwoodi'm very interested to understand what the practical gaps are in my approach12:34
paulsherwoodincidentally this could be a further reason for bringing the whole of definitions into ybd.git :)12:38
SotKthat sounds like it would be annoying to keep up to date12:38
paulsherwoodi'm wondering if i can somehow get upstream definitions to mirror into the ybd directory somehow12:39
paulsherwood(ie keep up-to-date automatically)12:39
paulsherwoodeverything would be in separate directories, so should be no clashes/conflicts12:40
paulsherwoodanyway, i should get back to my day-job :-)12:40
*** zoli__ has quit IRC12:45
*** zoli__ has joined #baserock12:48
kejiahu_YBD complains depmod not found, but it is exists under PATH, why does this happens?
paulsherwoodkejiahu_: nice find! i don't know, i'm afraid. maybe ssam2 could help?13:01
paulsherwoodkejiahu_: which architecture/os are you running under?13:02
richard_mawkejiahu_: is that depmod in your host system, or in the staging chroot?13:02
kejiahu_paulsherwood: it's on armv7 baserock13:02
franreddoes someone has a minute to review
kejiahu_richard_maw: is in host13:02
richard_mawkejiahu_: you need it to be available in the system you are producing then.13:03
paulsherwoodrichard_maw: you mean in build-essential?13:05
* SotK sends another pull request :)13:06
richard_mawpaulsherwood: no, as part of the system artifact13:06
richard_mawyou need to include the stratum that contains kmod if you want kernel modules13:07
paulsherwoodSotK: will that pr break anything against definitions master?13:07
ssam2edcragg: I notice there's a bunch of patches from you in gerrit now, what do these relate to?13:07
kejiahu_richard_maw: I would expect that's already included, as the some branch built on x86. but I'll check13:07
paulsherwood(that isn't already broken, i mean)13:07
ssam2edcragg: it's hard to get a complete picture looking at the individual commits in Gerrit, might be handy if you could send a summary to the mailing list13:08
SotKpaulsherwood: I don't think so13:08
* SotK can test13:08
radiofreekejiahu_: that's for the nouveau modules13:08
radiofreekejiahu_: which you almost certainly don't need, however it's an interesting case for ybd13:08
paulsherwoodSotK: if you don't mind :) i'll probably merge it anyway... :)13:09
franredrichard_maw, ta!13:09
radiofreekejiahu_: do you have foundation in your system?13:10
kejiahu_radiofree: I've found that, the kmod was included in foundation, but it's not included in definition.13:11
paulsherwoodradiofree: this may be another example of #2113:12
SotKpaulsherwood: seems to work fine13:12
paulsherwoodSotK: merged :)13:12
paulsherwoodyou're on *fire* today :-)13:12
kejiahu_radiofree: I'll remove nouveau13:12
SotKpaulsherwood: thanks!13:12
radiofreekejiahu_: seems sensible, nouveau is for hardware accelerated graphics, which you probably don't need on a router13:15
kejiahu_radiofree: thanks13:15
radiofreekejiahu_: to clarify, the problem was you *didn't* have kmod installed?13:21
*** fay_ has quit IRC13:21
kejiahu_radiofree: yes, the foundation is not included in system definition13:22
radiofreegotcha, NOTABUG13:23
kejiahu_radiofree: yes, with nouveau removed, the build finished. although the resulting rootfs is surprising big.... anyway, should I try jetson-upgrade.morph to deploy it? what's the 'important things' you mentioned just now regarding the deployment13:29
radiofreekejiahu_: what branch were you using?13:30
kejiahu_radiofree: yes13:31
radiofreeok, jetson-upgrade should be fine then (as a template)13:31
radiofreemake sure you change the system morph in there13:31
kejiahu_radiofree: with bsp replaced by jetson-bsp, and nouveau removed13:31
radiofreeyou'll need to change the system on line 4, however the rest of it should be fine13:32
kejiahu_radiofree: thanks13:32
*** mariaderidder has quit IRC13:37
paulsherwoodkejiahu_: make sure you have latest ybd, deployment has been tweaked today :)13:43
kejiahu_paulsherwood: good reminder, just 1 second before I press enter13:44
* paulsherwood is seriously considering making ybd check to update itself on every run13:45
paulsherwoodpedroalvarez: you don't like that idea?13:46
pedroalvarezthat is not good for the user point of view I think13:46
pedroalvarezauto updates without notifiying13:46
* Kinnison wouldn't like that13:47
Kinnisonesp. if I had explicitly checked out a particular ref to check something13:47
KinnisonI wouldn't want it updating13:47
Kinnisonybd --check-for-updates13:48
paulsherwoodheh :)13:49
paulsherwoodok, thanks for the feedback. i'll think of something less invasive13:49
KinnisonSame way proper OSes tell you there's updates but don't auto-upgrade themselves13:49
radiofreepaulsherwood: 2015-06-09 13:28:51 [TOTAL] Elapsed time 03:36:4413:51
paulsherwoodradiofree: w00t! thanks :)13:52
radiofreethat's build-system-armv8l6413:52
paulsherwoodit's not super-fast, though, is it?13:52
radiofreei think that's pretty fast from start->finish13:52
paulsherwoodhow many cores/memory on that thing?13:52
radiofree8 cores, 16G13:52
paulsherwooddid that include pulling the gits?13:52
radiofreei think13:53
radiofreemaybe not13:53
paulsherwoodi think on my MBP it's approx one hour...13:54
paulsherwoodi wonder if anyone from ARM is listening13:54
richard_mawwhat, building Armv8l6413:54
paulsherwoodno, building the equiv x8613:54
persiaFor tooling upgrades: consider the case of the user who wants to use the tool in a place without useful networking, based on local caches (or even local authoritative git repo).  Lots of folk work in this mode, either for temporary reasons (e.g. certain flights), or administrative reasons (e.g. restrictive office firewalls).13:55
radiofreeyour MBP is some i7 monster though?13:55
paulsherwoodthis seems too slow on the Moonshot, tbh. maybe a bug somewhere?13:55
radiofreethis isn't the moonshot, this is a mustang13:55
paulsherwoodradiofree: yup. it's a cruel world13:55
paulsherwoodradiofree: ah. even so. what's it clocked at?13:55
rjekSame CPU I thought.13:55
rjekPlus I'm told that AMCC's ARM implemention... leaves something to be desired.  (It's not an ARM Cortex design.)13:56
KinnisonThey fluffed the pipeline I believe13:56
paulsherwoodi think it's the best there is, as of today? but i may be wrong13:56
Kinnisonso it behaves more like an A53 than an A57 in terms of pipelined performance13:56
radiofreeif ybd actually logged to files i could give you build times of key components13:56
Kinnisonpaulsherwood: It's certainly the most easily acquired13:56
radiofreebut it's gone from my scrollback, i think it did gcc in 12 minutes13:56
rjekThat sounds like a feature.13:56
radiofreewhich i didn't think was too bad13:57
rjekradiofree: ybd | tee juicylogfile.txt ?13:57
DavePagescript ybd13:57
radiofreei'll remember to do that 3 1/2 hours ago13:57
paulsherwoodradiofree: build times should be in all the logs, now. cat ybd-artifatcs/*build-log | grep elapsed_time13:57
radiofreei don't have the build time in my build-logs13:58
paulsherwoodoh? when did you last update ybd?13:59
radiofreeaa71bf2ad5eabb955f058a97986a6d4308be5a11, Tue Jun 9 10:40:4513:59
radiofreeis this a new feature within the last 3 1/2 hours? :)13:59
paulsherwood a few days ago? look at the top of one of the log files please?14:00
paulsherwoodah, no. it's in the manifest14:00
paulsherwoodsilly me14:00
radiofreenope, no times14:00
paulsherwoodi'll add it to the log, too14:00
radiofreeright, so gcc took 00:08:3414:01
paulsherwoodcan you just cutnpaste your terminal log and grep that ?14:01
paulsherwoodactually, this needs more thought, also. sticking the time in the manifest will break b4b14:02
radiofreeterminal log is lost to the aether i'm afraid ( was running in screen )14:03
richard_mawif you stick it in the artifact, yes, but I don't expect the accompanying metadata file to be b4b reproducible14:03
KinnisonMorph drops a metafile alongside the build with timings in14:03
Kinnisonnot part of the artifact, but spare data in the cache14:03
paulsherwoodah, ok. so i could create .meta as well as the artifact and .build-log per build14:04
richard_mawyes, though I'd recommend having a directory per artifact, rather than different suffixes per file14:05
radiofreezlib took 41 minutes14:05
rjekThat seems a long time14:05
* richard_maw has wanted to change the artifact cache format to either ostree, or a directory per source for a while14:06
Kinnisonthat is an insane amount of time14:06
Kinnisonzlib should take seconds to actually build14:06
paulsherwoodmaybe the python recursion is strangling the mustang?14:06
paulsherwood(i have no idea, really)14:07
KinnisonWithout better timing data from the logs I couldn't say14:07
* richard_maw likes to ponder how that sentence would be interpreted by people without computing context14:07
rjekDoes it spit out build output, prefixed with timing information?14:07
DavePagerichard_maw: Euphemistically? "maybe the python recursion is strangling the mustang?" "That's what *she* said!"14:08
radiofreeare you interested in the build times for components paulsherwood?14:09
richard_mawI was imaginging someone being worried about snakes attacking their horses14:09
* radiofree grabs them anyway14:09
rjekybd 2>&1 | awk '{ print strftime() ": " $0 }' | tee myjuicylog.txt14:09
*** mariaderidder has joined #baserock14:09
rjekI assume there's a tool already that does what that awk does, but I don't know its name.14:09
radiofreewhy did zlib take so much time?14:10
* Kinnison wonders if some of the components are including the cost to build what they depend on14:10
Kinnisonstrata-build-essential.morph.meta:elapsed_time: 00:58:3314:10
Kinnisonthe stratum itself should take almost zero build time14:10
Kinnisonso those numbers are wrong14:10
rjekDoes it include unpacking/creating the sandboxes?14:10
Kinnisonit should14:10
* richard_maw wonders whether the zlib times are including all their dependencies14:10
Kinnisonrichard_maw: welcome to the conversation of less than a minute ago :)14:11
radiofreeso 2015-06-09 13:28:51 [TOTAL] Elapsed time 03:36:44 was from the now lost ybd terminal output14:11
* rjek wonders if the times it is reporting also includes all the dependencies.14:11
richard_mawKinnison: I appreciate your hospitality towards time travellers.14:11
radiofreewhich is correct, since i started the build, from scratch, 3 1/2 hours ago14:11
Kinnisonradiofree: Yeah, I think ybd's timing data is not useful14:12
radiofreeindividual components like gcc are really fast though gcc.meta:elapsed_time: 00:08:3414:12
* paulsherwood disagrees14:12
KinnisonI imagine you already had all the rest of build-essential built then14:12
paulsherwoodbuild-essential takes an hour. that's true :)14:12
Kinnison'cause gcc taking 8 mins and zlib taking 40+ is mad14:12
paulsherwoodthat's an actual problem, is my guess14:13
radiofreestrata-nfs.morph.meta:elapsed_time: 02:48:4414:13
paulsherwoodi think that's including the other strata that it needed to build first, so less useful14:13
Kinnisonpaulsherwood: It's one thing for aggregate components to include the build time of their contents, but IMO they shouldn't include the time for their build-dependencies14:13
Kinnisonpaulsherwood: How you make that distinction in ybd's timings is up to you :)14:14
paulsherwoodKinnison: agreed. i don't know if i can fix it14:14
Kinnisonradiofree: Also, FYI, baserock has a pastebin, no need to use fedora's14:15
radiofreei can fpaste < foo to fpaste though14:15
radiofreezlib taking 41 minutes seems wrong14:16
KinnisonIt's including its build-deps14:16
rjekAnd baserock's pastebin randomises syntax colouring and doesn't word-wrap.14:16
radiofreeKinnison: in that case wouldn't gcc's time be much higher?14:16
KinnisonI'm confused a little about that14:16
Kinnisonradiofree: My guess is that since binutils and gcc are early in stage 3, perhaps the build cost of the bootstrap components was somehow not included14:17
Kinnisonradiofree: Diagnosing what went wrong with the timelogging with just a set a timings isn't easy :)14:17
radiofreelemme run the whole thing again and keep the ybd log14:17
radiofreei always forget it's not actually logged anywhere14:18
paulsherwoodacually coming back to this, i think that something may be stuck accessing netwrok or something for ages, leading to lots of waiting. this build should have taken no more than a couple of hours, imo14:21
radiofree3 hours is "a couple of hours" imo14:21
paulsherwoodno, i mean it should build in less than 2 hours14:21
paulsherwoodis muy guess14:22
KinnisonTreat an XGene as straight-line speed similar to an i3 of equivalent clock rate14:22
pedroalvarez<rjek> And baserock's pastebin randomises syntax colouring and doesn't word-wrap.14:24
pedroalvarezwhy today?14:25
rjekpedroalvarez: It does it every day, AFAICT :)14:26
pedroalvarezrjek: your gratuitous complaint, I mean14:26
KinnisonWe were talking about pastebins14:27
rjekKinnison asked radiofree why he wasn't using BR's pastebin.  For radiofree it's convenience, for me it is because I don't want random highlighting and the last bit of the first line being obscured and lack of wordwrap :)14:27
pedroalvarezI sometimes find usefult tath there isn't auto-wraping14:29
pedroalvarezew,, s/tath/that/14:29
pedroalvarezand when I miss it, I just click in the button to see the raw content14:30
persia+1 to no autowrap14:35
persiaBut if there is a tool that can deal with hastebin in the manner of `${tool} < file` or `${command} | ${tool}`, it would be very good to put an appropriately configured binary into the development system.14:36
*** petefoth has quit IRC14:36
radiofreeif i redirect the output, ybd doesn't seem to do anything14:37
radiofreeit gets up to 5-06-09 14:36:31 [python-ceilometerclient] Cache_key is python-ceilometerclient.4ecfbcb575e0252f5cdf8ebdc3ad50c6a48c631bcf14:37
radiofreethen... nothing, at least according to the log14:37
radiofreeoh never mind14:38
pedroalvarezI can add the hastebinit tool to the essential files. would that make sense?14:42
pedroalvarez29 lines of python14:42
Kinnisonradiofree: I imagine ybd isn't force-flushing after log lines14:42
radiofreepedroalvarez: go on then, call it "brpaste"14:43
persiapedroalvarez: If you configure to default to, yes please.14:43
radiofreewould be super useful actually14:43
franredpedroalvarez, +114:46
paulsherwoodybd runs (but may not do very much yet) on MacOS... yay! thanks ssam2 :-)14:57
pedroalvarezwe will be sending soon the OpenStack on Baserock kilo upgrade soon, and following the tradition, it will include a mega-patch (-4453/+6181)14:58
Kinnisonpedroalvarez: cripes14:59
radiofreedo you expect anyone who's not worked on openstack to actually review that?14:59
pedroalvarezI'm happy to discuss better ways to do this14:59
pedroalvarezradiofree: at  least to give a opinion from his point of view, yes15:00
pedroalvarezthat mega commit only sync's configuration files with the new version15:01
paulsherwoodpedroalvarez: really?15:01
pedroalvarezthis is the branch:
paulsherwoodi've been wondering are we missing something here? should each 'system' or 'cluster' be in its own branch, maybe? and then have major release brnaches for applicable systems (eg openstack)15:02
* richard_maw doesn't like that model, but doesn't have time at the moment to articulate why15:03
pedroalvarezI can articulate that15:03
paulsherwoodrichard_maw: ok. it won't happen today, anyway :)15:03
* paulsherwood would like to understand the negatives15:04
pedroalvarezpaulsherwood: I would like to understand the model you are purposing first15:05
radiofreepaulsherwood: wouldn't that require someone to make sure all the branches are in sync?15:05
* persia remembers the branch debate15:05
paulsherwooddefinitions contains many example systems/solutions. i'm suggestign each example could be in its own branch...15:05
radiofreei.e someone updates systemd in the "devel-system" branch, what's the process for merging that to the "build-system" branch?15:05
paulsherwoodeg OpenStack/kilo, OpenStack/juno etc15:06
radiofreepersia: there was some discussion about branching genivi15:06
paulsherwoodradiofree: i don't know, fair question. i was hoping there'd be plenty of git magic for that? :)15:06
persiaradiofree: I meant the definitions branching debate, but that makes sense.15:06
persiaWhy are juno and kilo being simultaneously maintained in master?15:07
paulsherwoodthat's the current situation. i'm suggesting we change it but maybe my idea is dumb15:07
persiaFor all that I'm generally opposed to releases, for that use case, I'd rather see release branches with bugfixes applied.15:07
persiapaulsherwood: Please pick a different example: that particular one is obviously entirely wrong.15:08
paulsherwoodis it? why?15:08
paulsherwoodsorry, i don't understgand OpenStakc's release model15:09
persiaBecause maintaining two different release series of a project in a single git branch is inherently broken: one can't sync.15:09
persiaBut that is independent of the issues inherent in having multiple branches of definitions for different systems.15:10
paulsherwoodi was saying those woudl be two branches?15:10
jjardonpedroalvarez: I guess that (the mega patch) is because we include generated files in the git tree, rigth? I remember discussion that before. Is there still not a way to generate them depending of configuration files?15:10
paulsherwoodbranch1: OpenStack/kilo, branch2: OpenStack/juno, branch3: OpenStack/master or whatever?15:11
persiapaulsherwood: Yes, but the reasons it is bad to have multiple branches apply to circumstances other than the example you picked, which is why I asked for another example.15:11
jjardonand also, is the plan to support only kilo after the merge? or the previous version as well?15:11
paulsherwoodGENIVI/foo-release-0.1 GENIVI/foo-release1.0 GENIVI/foo-release1.1 GENIVI/bar-release 0.1 etc?15:11
franredwe will only support Kilo when it gets merged15:12
persiaSo, in the previous debate, we discussed multiple branches for multiple systems.15:12
paulsherwoodi don't know whether we'd *support* any of these things... just suggesting separate branches as a means of keeping GENIVI apart from OpenStack apart from OpenWRT etc15:12
persiaBut all of current releases.15:12
franredjjardon, there are some configurations files which can not be autogenerated15:12
persiaWe concluded that it was too hard to synchronise base changes in a sensible way, and that it all became too painful.15:13
pedroalvarezjjardon: we actually have removed some of them, and included them at install time of some components15:13
persiaIn an entirely unrelated discussion, there was some talk about having Baserock releases, and a means to have bugfixes to prior releases indpedendent of changes to master.15:13
persiaSo that definitions would have a master branch, and several release branches.15:13
jjardonfranred: pedroalvarez right, thanks for the info15:14
paulsherwoodutltimately i think we'd be best off with OpenStack/latest and GENIVI/latest etc, where we push as close to master on all the things as we can, but those organisations may have imposed their own limits on how close specific components can get to mainline15:14
ssam2persia: that's actually been done with 15.19.1 and 15.19.215:14
persiaIn the case where we want to freeze release systems and do bugfixes, the latter discussion seems relevant.  When upstream follows this model, our alignment with usptream makes sense, and the merge issues with multiple branches go away, because we actively don't want to upgrade underlying components.15:14
paulsherwoodpersia: yup. but several might be many15:14
persiassam2: Excellent.  When the debate happened, I had the impression that folk thought it was a good idea, but nobody wanted to actually implement it.  I'm delighted to hear definitions has useful release series now.15:15
Zarawhat happens if someone later wants to use baserock to build openstack juno? is there a quick way to go back to it? (and is that likely to happen?)15:16
franredZara, why would you like to do that?15:16
paulsherwoodin my dream scenario, there's an OpenStack/juno branch15:16
paulsherwoodfranred: reproducibility?15:16
persiapaulsherwood: Many release branches is fine, if they are all maintained (and there is a point).  Essentially, if one wants to freeze everything except for minor bugfixes, doing this within deinifions master is a recipe for pain.15:16
franredyou may want to have some support but for how long?15:16
franredpaulsherwood, ^^15:17
SotK`git checkout $old_sha` would be fine, surely?15:17
persiaSotK: Up to the point where you need a bugfix, yes.15:17
Zarafranred: I wouldn't like to do it personally, but some groups that use openstack don't have kilo support yet, so I'm just wondering if that would put them off using baserock.15:17
franredZara, you can build juno, it is in the latest release also it is in the definitions repo15:18
franredpaulsherwood, reproducibility is guaranteed, it is in freeze in definitions.git, am I wrong?15:19
SotKThen `git checkout $old_sha -b juno-bugfix && git cherry-pick $bugfix_sha` or similar? I guess at that point you may as well have created the release branch though.15:20
SotKI was mainly commenting on the "how to get back to it" issue15:20
persiaI agree on the getting back to it: for me, the main reason to create the branch is as a marker to indicate which ${old_sha}, and whether there has already been a bugfix.15:21
paulsherwoodat the point that we decide not to 'maintain' a branch, maybe we just tag it and kill the branch?15:23
persiaI'd just leave the branch alone.15:24
persiaIf we formalise lack of support as meaning something other than folk happening to not submit changes, then we can add a commit indicating the lack of support.15:24
persiaBut the process for formal declarations of support by some organisation is really complicated, and not something I think we need to do in baserock today.  We don't have a strong enough meaning for "support" yet anyway.15:25
paulsherwoodso then master becomes baserock-specific systems? build-system, trove etc... and other examples end up in branches? would that work?15:25
* Kinnison worries that those other branches would atrophy15:25
* franred too15:26
paulsherwoodnot if they're in ci/cd?15:26
franredpaulsherwood, what happen when we move components around different strata?15:26
persiapaulsherwood: No.  For the special case of branching to support an upstream release branch, we branch.  For other cases, why would we branch?15:26
paulsherwood(and folks who care are maintainign them... eg Codethink still cares about GENIVI, in spite of all the spats)15:26
Kinnisonpaulsherwood: In that context, it'd be okay15:27
Kinnisonpaulsherwood: But then I'd worry about splitting patches between master and branches for fixes15:27
kejiahu_how does YBD handle extensions? I suppose this is where it gets extensions '        settings['extsdir'] = os.path.join(settings['defdir'], 'extensions')' but it seems there is no such extensions directory exists?15:27
paulsherwoodpersia: because OpenWRT may not be compatible with GENIVI may not be compatible with OpenStack etc15:27
persiaHow not?15:27
paulsherwoodSotK: ^^ re kejiahu_'s question15:27
paulsherwoodpersia: may require different versions of things?15:28
rdale_we can't support custom versions of build-essential for different systems currently, and openwrt and musl need that15:28
persiaThen we offer a service by integrating newer components.15:28
paulsherwoodwho is 'we'?15:28
persiaI seem to recall something about the OpenStack integration being one of the first times newer systemd was used with OpenStack, which led to useful patches to systemd to ease integration with other environments in the future.15:28
persiaWe: The set of folk who care about the content of definitions (I'd claim the set of folk who hack on definitions, but that would exclude me, so make for a strange definition of "we")15:29
KinnisonThe openstack work helped expose a bug in systemd which we (richard_maw) provided a fix for15:29
SotKkejiahu_: the extensions directory is in definitions.git15:29
richard_mawYep, I was able to point someone on the Mailing List at the fix they would need to use OpenVSwitch with systemd15:30
* SotK spots a bit he missed in one of his ybd patches15:30
paulsherwoodSotK: :)15:30
radiofreepaulsherwood: bad news, your fix didn't fix the gcc issue :(15:30
DavePagepersia: There's no I in we15:31
SotKoh, I didn't, I was looking at an old branch15:32
persiaDavePage: Yes, but if I define "we" to be people who regularly commute to the moon, I may not be the most qualified spokesperson.15:32
paulsherwoodradiofree: the MS_BIND issue?15:32
kejiahu_SotK: I see, the particular branch I checked out doesn't have that directory in it. thanks15:33
radiofreesomething entirely different this, it'll occasionally fail with "checking for suffix of object files... configure: error: in `/':"15:33
radiofreeif i run it again it'll be fine15:33
radiofree(run the build)15:33
radiofreei'll take a look at it anyway15:34
paulsherwoodweird. maybe j1?15:34
paulsherwoodor maybe Kinnison knows bettere?15:34
KinnisonYou'll need to get the whole proper error for me to help15:34
Kinnisonperhaps look at the config.log15:34
radiofreehere's the offending config.log15:40
radiofreei'll try and grab one from a working build15:41
Kinnison/ error while loading shared libraries: cannot open shared object file: No such file or directory15:41
Kinnisonthat happened to me last when the right zlib wasn't being build-depended upon15:41
radiofreehmm.. it does work occasionally though15:42
KinnisonIs it configuring gcc to use the internal libz at this point?15:42
radiofreei'll check the log from when it works15:43
*** a1exhughe5 has quit IRC15:50
radiofreeso it is libz related15:51
radiofreegcc is build-depending on "libz!15:52
radiofreegcc is build-depending on "libz"15:52
pedroalvarezright, erlang broken because now tools doesn't depend on foundation15:53
*** fay has joined #baserock15:53
pedroalvarezI wonder what's mason doing these days15:53
*** fay is now known as Guest8604015:54
KinnisonYou mean changing those dependencies had further repercussions beyond that which the submitter could be bothered to test for?15:54
* Kinnison is shocked15:54
* rjek gets the valium15:55
* franred looks at erlang stratum and try to fix it and looks at mason asking for some kind of explanation (no new builds since sunday?)16:00
pedroalvarezfranred: is building things16:04
pedroalvarezI wonder how many times..16:04
*** mariaderidder has quit IRC16:11
franredpedroalvarez, replacing tools.morph by foundation.morph in the erlang stratum, builds erlang16:11
pedroalvarezI wonder why it was depending on tools16:12
rdale_shouldn't it just depend on core?16:13
pedroalvarezrdale_: it needs systemd16:14
richard_mawrdale_: no, it needs systemd's headers16:14
franredrdale_, no erlang but erlang-sd_notify16:14
rdale_i wanted to build minimal systems with erlang and elixir16:15
pedroalvarezfranred: go ahead with that patch. Looks like there wasn't a reason to depend on tools16:15
franredpedroalvarez, yeah, it was long time ago... and tools.morph has been modified a lot to check what did have at that time16:16
pedroalvarezfranred: 081ffc7d16:16
franredrdale_, we could move erlang-sd_notify to openstack because it is required by rabbitmq to be able to use notify in its systemd units16:17
franredI think rebar should remain in the erlang stratum as it is a erlang compiler16:17
radiofreepaulsherwood: if you wanted to improve build times you could make compressing cache artefacts optional for people with lots of space16:18
radiofreefor example, stage1-gcc] Elapsed time 00:08:59 - more than 2 minutes of that was creating the cache artefact16:19
franredpedroalvarez, should I move erlang-sd_notify to openstack-services and make erlang depends on core?16:19
jjardonfranred: I would prefer that, and make the erlang stratum depend on core, if possible16:19
paulsherwoodradiofree: iirc Kinnison added the compression? seemed like a good idea at the time16:19
paulsherwoodradiofree: maybe add that as an option in ybd.def ?16:20
radiofreeit is a good idea, but if you don't care about it then it just slows your build down16:20
persiardale_: As is done with linux, use a marker to indicate the differences between the erlangs (one compiled with systemd support, the other not), and move ahead with a separate entry for your needs.16:20
pedroalvarezfranred: will that stop you from sending the kilo update patches?16:20
paulsherwoodright. i'll make default not compressed16:20
franredpedroalvarez, not at all, I would include this in them16:20
persiaI thought the point of compressing cache artifacts was for folk with limited bandwidth, not limited space.16:21
radiofreewhen i'm building locally i'm not going to be pushing these anyway16:21
paulsherwoodcompressing to upload is a different use-case from build and deploy, interestingly16:21
radiofreedoes ybd support artifact cache servers yet?16:22
pedroalvarezfranred: your call then16:22
persiaI cared about *downloading* cache artifacts, not uploading, but I can see the parallel16:22
paulsherwoodradiofree: you might be, there's code to do it... no server on the receiving end yet though :)16:22
paulsherwoodradiofree: it needs hooking up16:22
paulsherwoodneeds some agreement with baserock upstream i think16:23
paulsherwoodbear in mind, ybd isn't even lorried yet... i'd be surprised if folks would trust its artifacts :)16:23
radiofreeyou also don't want to enable that by default16:24
paulsherwoodradiofree: yup16:24
* paulsherwood tries all the things first by default, to see what breaks16:24
radiofreemaybe you could check to see if it's compressed there, if not, compress, then upload16:24
radiofreeor maybe even on the server side16:24
paulsherwoodthat would be my plan... compress to upload it16:25
radiofreeseems sensible to me16:25
radiofreeand obviously if disk space is an issue you can always enable compression during build16:25
*** zoli__ has quit IRC16:47
ssam2anyone noticed that the Morph test suite fails in baserock 15.19 ?17:00
ssam2I used to see this in Fedora, seems to be present in BR now as well17:01
jjardonDoes anyone heard of ? looks pretty cool project17:03
jjardonfor systemd:
*** bashrc_ has quit IRC17:07
ssam2looks useful. is it open source?17:10
*** gary_perkins has quit IRC17:13
jjardonits what I was trying to know, but it doesn't look like17:13
*** sambishop has quit IRC17:17
*** ssam2 has quit IRC17:20
*** lachlanmackenzie has quit IRC17:36
*** sambishop has joined #baserock17:45
*** edcragg has quit IRC17:51
*** edcragg has joined #baserock19:14
*** edcragg has quit IRC19:37
*** jjardon has quit IRC20:21
*** jjardon has joined #baserock20:24
*** edcragg has joined #baserock20:46
*** edcragg has quit IRC22:04
*** sambishop has quit IRC22:27
*** rdale_ has quit IRC22:35
*** edcragg has joined #baserock22:57
*** edcragg has quit IRC23:10

Generated by 2.15.3 by Marius Gedminas - find it at!