IRC logs for #baserock for Monday, 2015-07-27

*** zoli___ has joined #baserock00:06
*** zoli__ has quit IRC00:06
*** zoli___ has quit IRC04:26
*** petefoth has quit IRC05:26
*** zoli__ has joined #baserock06:24
*** petefoth has joined #baserock06:36
*** mike has joined #baserock06:58
*** mike has joined #baserock06:58
*** mike is now known as Guest2407906:59
*** petefoth has quit IRC07:11
*** petefoth has joined #baserock07:12
*** zoli__ has quit IRC07:39
*** zoli__ has joined #baserock07:41
*** fay_ has joined #baserock07:42
*** zoli__ has quit IRC07:44
*** jonathanmaw has joined #baserock07:51
*** mdunford has joined #baserock07:58
*** bashrc has joined #baserock08:05
paulsherwoodis there a general email address for the infra team?08:22
rjekadmin at baserock.org IIRC08:22
* rjek confirms that that is the case.08:22
paulsherwoodtvm08:24
*** SotK_ is now known as SotK08:31
*** gary_perkins has joined #baserock08:31
*** rdale has joined #baserock08:47
*** Guest24079 has quit IRC08:50
*** Guest24079 has joined #baserock09:05
*** ssam2 has joined #baserock09:06
*** ChanServ sets mode: +v ssam209:06
*** edcragg has joined #baserock09:39
nowsterssam2: using a prefix with spaces in it will break lots of naïve scripts...09:42
*** zoli__ has joined #baserock09:42
pedroalvareznowster: yes09:42
ssam2nowster: i don't actually care about this (hence I gave a +1) but others do09:44
ssam2I kind of think that if you use a space in your prefix then you deserve to suffer a little ;)09:45
ssam2nowster: would you mind if i fixed up the quoting of $PREFIX in your patch, then merged it?09:52
nowsterNo problem!09:53
ssam2ok, will do09:53
nowsterssam2: Looking at gerrit 996. Is there anything else that's blocking its inclusion?09:54
nowster(and its friends)09:54
ssam2not that I know of09:54
nowsterJust missing another +1?09:55
ssam2yeah09:55
nowsterShall I trawl the office looking for victims? :)09:55
ratmice___not to overreact or anything, but the 'deserve to suffer' reminds me of typhoid mary for some reason09:55
ratmice___e.g. just because it works you should really avoid spreading the disease :)09:56
ssam2nowster: i'm happy to merge as is, if i have time to double check them again. but "encouraging" reviewers is always welcome!09:56
*** petefoth_ has joined #baserock10:18
*** radiofree has joined #baserock10:21
*** edcragg_ has joined #baserock10:21
*** petefoth has quit IRC10:21
*** radiofree_ has quit IRC10:21
*** Guest24079 has quit IRC10:21
*** petefoth_ is now known as petefoth10:22
*** edcragg has quit IRC10:22
*** Guest24079 has joined #baserock10:22
pedroalvarezheh, a normal user can read all the /baserock metadata except strata metadata :)10:44
ssam2because of permissions? heh10:46
pedroalvarezyes10:46
pedroalvarez644 and 60010:46
pedroalvarezanyway, I wanted to look into chunks metadata, so everything OK here :)10:47
ssam2nowster: I didn't merge change 997 because it turns out it's mirroring a repo that is just a tarball import of the upstream tarball10:55
nowsterssam2: I see.10:55
ssam2i think it's better to do our own tarball import, although there's no real harm in mirroring GStreamer's one10:55
ssam2calling the repo libmad-tarball instead of libmad would be nice too10:55
nowsterok10:55
nowsterssam2: I've found ftp://ftp.mars.org/pub/mpeg/madplay-0.15.2b.tar.gz11:01
ssam2that's the one I found, I think that's "upstream211:01
ssam2"11:01
nowstersorry... you're right about libmad's latest11:01
ssam2the patches in the gstreamer repo look useful, for what it's worth11:02
nowsterlet's see what the differences are11:02
nowsterugh! Nasty nasty repo.11:02
nowsterwarning: remote HEAD refers to nonexistent ref, unable to checkout.11:02
nowsterno branches11:03
nowsteronly tags11:03
nowsterIt looks to me like libmad is not currently under active development (last activity 2006).11:06
nowster...and the patches from gstreamer look useful for any ARM builds.11:06
ssam2yes, that's what I thought11:07
*** mdunford has quit IRC11:07
ssam2but as you say, the GStreamer repo is a little weird, and we can do our own tarball imports11:08
ssam2do you know how to write an appropriate .lorry file? I can do it if not11:09
ssam2thinking a bit more, it'd be hard for you to push those patches to a delta/libmad repo on git.baserock.org without push access to git.baserock.org11:10
ssam2do you have access? I can add you if not11:10
ssam2alternately, we could merge the current lorry but call the repo libmad-gstreamer-sdk or some such thing11:11
nowsterI don't have access.11:13
ssam2ok. which do you prefer out of using the gstreamer fork, or doing our own tarball import? if you're going to be doing more work on the Baserock reference systems, it'd probably be useful if you had push access to git.baserock.org anyway. i think you've been around here long enough we can trust you :)11:15
nowsterssam2: :)11:15
nowsterIf we do the tarball import and then layer patches on top, will that affect the lorry mechanism?11:15
ssam2i'm not quite sure what you mean... it'll mean we need to write a different .lorry file11:16
ssam2easy to do though, e.g. http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/tree/open-source-lorries/autoconf-tarball.lorry11:16
ssam2just give the URL to the tarball11:16
nowsterIf we go with the Underbit tarball, but apply the gstreamer ARM patches on top, how will that work?11:18
ssam2once Lorry has created a delta/libmad repo, you can clone it, apply the patches in a branch based off the libmad-0.15.1b branch, then push that as 'baserock/0.15.1b-gstreamer-sdk-fork' or some such thing11:19
ssam2so we fork it but pretend that we haven't because it's more effort to 'officially' have forked it ;)11:19
ssam2and i doubt anyone from the Baserock project is going to do major changes to it11:19
nowster:)11:20
ssam2it's more effort up front, "cleaner" in a theoretical sense, but i'm happy for us to take the short cut of just mirroring the gstreamer sdk's fork11:20
nowsterright... Let's go with that plan. I'll make a libmad-tarball.lorry if you give me push access to the Baserock repos.11:21
ssam2ok, will do11:21
ssam2please mail me your SSH public key11:21
nowsterwilco11:22
*** mdunford has joined #baserock11:22
ssam2does anyone have thoughts on how we should store default split rules and default build commands in definitions.git ?11:23
ssam2my first idea is to have a file named DEFAULTS at the top level which is YAML11:24
ssam2and has a 'build-systems' list, containing 'autotools', 'cpan', etc. and the configure-commands, build-commands, and so on for each one11:24
ssam2and also a 'split-rules' entry, containing 'chunk' and 'stratum', and the regex patterns for each split rule11:25
ssam2i wonder if it makes sense to put 'repo-alias' in there as well... which raises the question of how we inject 'trove-host' into the URLs (e.g. upstream: prefix expands to git://{TROVE_HOST}/delta)11:26
ssam2i'll come up with a prototype soon, i just wondered if anyone has thought of this already11:26
pedroalvarezssam2: my idea was to do something like:11:26
pedroalvarez  build-system: strata/defaults/autotools.morph11:26
pedroalvarezin the chunk morphologies.11:26
pedroalvarezbut I didn't like the idea of having paths there11:27
ssam2right... one aspect that confused me is how to avoid hardcoding special paths11:27
ssam2I don't really want there to be a magic 'defaults/' directory with magic files inside11:27
pedroalvarezbut then you are going to hardcode the special path to DEFAULTS in the build tool11:28
ssam2indeed, but we already do that with VERSION ;)11:28
pedroalvarezfair11:28
ssam2specifying the 'defaults' path in each .morph file is a good alternative, though11:28
ssam2maybe i'll try both11:28
tiagogomesI would rather hardcode the build tool to read from DEFAULTS11:30
pedroalvarezregarding repo-alias I don't see any benefit on adding a DEFAULT11:30
pedroalvarezdefault*11:30
ssam2yeah, maybe so. I guess the real problem is that it's a pain to change it in morph.conf11:30
ssam2but that could be fixed in Morph11:31
*** radiofree has quit IRC11:31
ssam2and in YBD the repo-alias can already be specified by a file committed in definitions.git11:31
pedroalvarezhm.. but I want to be able to build definitions.git using my local trove without adding a patch11:31
tiagogomesIf you write `build-system: strata/defaults/autotools.morph` that's not defaults anymore, as you are referencing a specific configuration11:31
*** radiofree has joined #baserock11:32
ssam2tiagogomes: it gives a lot more flexibility. which could be good or bad :)11:32
ssam2i see your point that it's not really a 'default' in the same sense11:33
ssam2could be 'build-system: base/autotools.morph' or something11:33
tiagogomesI would call it complexity instead :) If the defaults don't work, for some project, you can always change them in the chunk morph11:34
tiagogomesand if you added `build-system: path-to-build-system`, you would also need to add `split-rules: path-to-split-rules`11:36
ssam2we might be able to make the split rules build-system specific11:36
ssam2but haven't actually tried that11:36
ssam2nowster: you should be in 'baserock-writers' group on git.baserock.org now, try 'ssh git@git.baserock.org whoami' to test11:38
tiagogomesa compromise, could be putting `build-system: path-to-defaults` in the system morphologies11:38
ssam2'defaults: path-to-defaults' would make more sense then!11:38
tiagogomesbetters, `defaults: path-to-defaults` in the system morphologies11:38
ssam2snap11:38
tiagogomesmeh, you typed faster :)11:39
ssam2I think I prefer the DEFAULTS approach, but i haven't tried to write a DEFAULTS file yet, so maybe i'll change my mind :)11:39
nowsterssam2:                baserock-writers: Those with write access to Baserock repositories11:42
nowsterssam2: ta11:42
nowsterssam2: and ta11:51
* paulsherwood would prefer one defaults declaration, rather than having to declare in each morph file, fwiw11:58
paulsherwoodcurrently ybd has https://github.com/devcurmudgeon/ybd/blob/master/ybd.conf, overridable by having a ybd.conf in the definitions directory - could defaults be done in a similar way?11:59
*** Guest24079 has quit IRC12:03
ssam2paulsherwood: that's what I'm proposing with DEFAULTS, really12:07
*** zoli__ has quit IRC12:08
ssam2if a build tool wants to provide a way for users to override them outside of definitions.git, I think that's up to the build tool authors, rather than the definitions format itself12:08
paulsherwood:)12:08
*** zoli__ has joined #baserock12:09
*** zoli___ has joined #baserock12:10
*** zoli__ has quit IRC12:14
*** Guest24079 has joined #baserock12:16
nowsterssam2: does http://git.baserock.org/cgi-bin/cgit.cgi/delta/libmad-tarball.git  look sane to you?12:18
ssam2looks great, thanks for doing that12:32
nowsternow to fix the definitions so that they point at git.baserock, rather than file:///...12:35
ssam2first pass at a DEFAULTS file: http://paste.baserock.org/opevimacoz12:38
persiassam2: Am I correct in assuming that chunk definitons must declare one of those build systems, or include a custom build-system?12:41
nowsterI *think* that there's some sort of autodetection.12:42
persiaI worry a bit if that is true and DEFAULTS is as written.12:44
ssam2persia: definitions version 6 removes autodetection, so every chunk must specify a build-system12:51
ssam2so, from v6, every chunk must declare one of those (although it can be declared in the stratum, to avoid needing lots of extra chunk .morph files)12:51
persiaAh, good.  We'll have to see how well this works in practice, but I don7t see any obvious issues.12:52
*** tiagogomes has quit IRC13:04
*** 7GHAAS8M4 has joined #baserock13:15
*** zoli___ has quit IRC13:17
*** zoli__ has joined #baserock13:18
*** zoli___ has joined #baserock13:19
*** zoli__ has quit IRC13:22
*** zoli___ has quit IRC13:27
*** zoli__ has joined #baserock13:27
*** 7GHAAS8M4 is now known as tiagogomes_13:48
*** rdale has quit IRC13:53
*** rdale has joined #baserock13:53
*** _longines has quit IRC13:54
*** _longines has joined #baserock13:55
*** inara` has quit IRC15:29
*** Guest24079 has quit IRC15:31
*** ssam2 has quit IRC15:34
*** inara has joined #baserock15:37
*** Guest24079 has joined #baserock15:43
*** ssam2 has joined #baserock15:47
*** ChanServ sets mode: +v ssam215:47
* pedroalvarez sends https://gerrit.baserock.org/1005 after seeing Mason failing15:59
*** jonathanmaw has quit IRC16:02
ssam2good catch, thanks16:03
*** robtaylor has quit IRC16:18
*** Guest24079 has quit IRC16:31
*** bashrc has quit IRC16:50
*** ssam2 has quit IRC17:00
pedroalvarezif we ever build something in Go in baserock, we might have some problems17:01
pedroalvarezI might be wrong, but this Go component I'm looking at has some imports with URL's to github17:01
jmacsYes, I think that's a common complaint about Go17:02
pedroalvarez git grep github | wc -l17:02
pedroalvarez34917:02
*** mdunford has quit IRC17:09
*** mdunford has joined #baserock17:37
*** edcragg_ has quit IRC17:39
*** mdunford has quit IRC18:16
*** brlogger has joined #baserock18:35
*** edcragg has joined #baserock21:42
*** edcragg has quit IRC23:20

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